Do you have a question? Post it now! No Registration Necessary
- Phil Hays
July 2, 2003, 3:30 am
rate this thread
Yes, this is correct. This delay is the difference between the DQ line
length on the PCB and the DQS line length on the PCB. If the DQ lines
are 1.5 inches, the DQS lines need to be 1.5 inches + 4.2 inches = 5.7
inches, assuming 180ps/inch. The delay of the PCB varies with stackup,
use care. Delay of vias can be significant, make sure the number and
placement of vias match or that this delay is included in the
The timing relationship between DQ and DQS is required for the writes to the
DDR SDRAM; the SDRAM latches the incoming data on DQ on both edges of the
DQS. Presumably the extra delay on the DQS is to ensure that the setup and
hold time of DQ around the DQS is met.
The read timing IS latched using a phase shifted clock; it is not possible
(at high speed) to latched the read data (data coming back from the SDRAM)
using the DQS. The DQS is provided by the RAM as a "clock" for the return
data, but unfortunately, this is useless for an FPGA. The DQS provided by
the SDRAM is not a periodic clock; aside from the fact that it is
bidirectional, it only runs during the data phases of the read data. Since
it is not a periodic clock, it cannot be fed into a DCM; while the DCM
allows for clock stopping and starting, there is a 3 to 4 clock pulse delay
in the DCM, so you would miss the incoming data. Furthermore, it would be
difficult (impossible?) to prevent the outgoing DQS from unlocking the DCM.
Using the DQS as a clock without deskewing it using a DCM results in HUGE
setup/hold requirements for the IOB flops (for some parts, over a 2ns
required valid window); the setup/hold window of the flops is far larger
than the data valid window provided by the RAM at any reasonable clock rate.
Therefore, the soultion in the app note (using a phase shifted internal
clock to capture the read data) is the only way to go. Similarly, since the
DQ/DQS timing relationship is required to do writes to the DDR-SDRAM, it is
necessary to generate a delay, either using a DCM or board delays (as is
done in the app note).