1. Home
  2. Field-Programmable Gate Arrays
  3. Xilinx, MIG, UCF: timing constraints for DDR2 DRAM

Xilinx, MIG, UCF: timing constraints for DDR2 DRAM

Hi FPGA Group!

I'm struggling to get a fast speed (~ 200 MHz) for the DDR2 DRAM interface, generated with the Xilinx Memory Interface Generator. The complete system consists of a PCI interface, an I/O DMA buffer, a burst module bursting from DMA buffer to the DDR2 DRAM interface.

What is the best way to define setup/hold times for the I/O pads (UCF)? (the RAM interface consists of a bi-dir data bus DQ, some output signals e.g. A and the DRAM clocks CK)

  1. Using the OFFSET = OUT 5 ns AFTER "SYS_CLK_P"? Unfortunately, this does only work using the Input Clock Pin, but it should probably better be in reference to the DRAM clocks CK)
  2. Using TIMESPEC "TS_DDR_OUT" = FROM FFS TO "DDR_OUT" 5 ns; ? Is probably better, but I'm not exactly sure.

Furthermore, how would you tackle the problem if the timing at the pads cannot be met?

Thanks in advance for helpful answers and pointers in the right direction!

Best regards, Simon

Reply to
Simon Heinzle
Loading thread data ...

Hi Simon,

This document may be of assistance:

formatting link

Eric

Reply to
Eric Crabill

Thanks Eric,

I checked the XApp458 and various XApp7** about Virtex 4 DDR2, as we are using a Virtex 4 FX. I'm using the DDR2 controller from the Memory Interface Generator.

The main problem are the output delays. Input delays seem to be calibrated using tap delay lines. I had a working example with output delays between

4.4ns and 5.1ns (Data, Address, Control, DRAM clock). I extended that example (but no changes to the DRAM interface), now the output delays range between 4.4 ns (Data, Control, Dram Clock) and 8.9 ns (Address).

What is are the best constraints to define a tight window? (I'm now using TIMESPEC ... = FROM FFS TO "OUT" 5.3 ns, which cannot be met) What is a good strategy to meet those timing constraints?

Thanks in advance, Simon

Reply to
Simon Heinzle

Hi all,

I found the problem: the "Retiming" option in Synplify Pro caused the address signals to be retimed and they could therefore not be packed into an IOB flip flop. This caused a much higher delay than in the other output signals.

Thanks for your help, Simon

Reply to
Simon Heinzle

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.