What is the advantage of source-syncronization (in SDRAMs)?

Some DDR2 SDRAM controllers require a feedback clok input, being their output clock via a loop of track that goes the same distance as to the SDRAM and back. Others go through a training phase where they work out the "time-of-flight" from the controller to the SDRAM and back. Either works well enough. If your FPGA is from Xilinx, use their MIG tool to generate the controller.

--------------------------------------- Posted through

"RCIngham" wrote in message news:nYadnfl5gelSNWXQnZ2dnUVZ snipped-for-privacy@giganews.com...

I think the point was:If you dont know the timing between outclk and inclk (or dqs) - It could be >1clk in theory - how do you know when data is valid on a read? I guess you can't trust DQS as it is floating when not active.. You just need to assume there is

I do believe that this works very well. I just want to know one thing: how all this stuff helps to strobe nothing but valid data bits?

My board is

routed for Xilinx memory controller It involves the on-board clock feedback trace, which matches the FPGA-to-SDRAM trace length. Can you explain the advantage of this design in 7.05.2011 topic "Why feedback clock in SDRAM controllers?"

There are two problems to use EDK controller:

1. The CoreGen of ISE10.1 (latest for XCv2p) does not include the memory generator and
2. plb_ddr.pdf says: "Due to the variation in board layout, the DDR clock and the DDR data relationship can vary. Therefore, the designer should analyze the time delays of the system and set all of the attributes of the phase shift controls of the DCM as needed to insure stable clocking of the DDR data."

I just do not understand how to measure these timings and, at the first place, why do we need these DQS if phase shift with respect to system clock still must be adjusted manually? Why not to strobe DQ by this manually adjusted system clock phase right away?

With DDR memory you would use some sort of calibartion scheme so that the data coming from the memory was calibrated to the clock inside the FPGA. This usually consists of writing a 1010 pattern into the memory and then reading it back and using a IO delay inside the FPGA to alter the relationship between the data and internal clock.

Jon

--------------------------------------- Posted through

[snipped] [snipped]

Oh the old Virtex-2PRO stuff. Bad luck! It all works lovely on Virtex-4 and Virtex-5 with recent ISE and CoreGen.

--------------------------------------- Posted through

In your explanation, only one thing is missing: DQS. Why do we need data if we still need to calibrate "memory to the clock"? One could calibrate DQ directly "to the clock inside FPGA".

Why do we need _DQS_, I mean.

Thank you for the appreciation.

BTW, why the static installation of FPGA-SDRAM on a single board needs the dynamic calibration? 1010 is produced by DQS. Do you mean that duplicaiton is needed because all DQ bits, in one DQS group, must be treated separately?

On a Read, the DQS signals are generated by the memory chip. The relationship between the DQ and DQS signals stays fairly constant (for a given circuit board layout and operating frequency). However, the relationship between DQS and the DDR2 controller clock is not necessarily the same all the time.

Once the relationship between DQS and DQ has been determined, either through data training (testing data samples and seeing what timing works) or through a timing feedback pathway) that timing relationship can be used reliably to perform read operations.

In my experience, once the timing parameters have been determined, they're usable on all instantiations of the same circuit board using the same parts at the same speed.

Jeff Walther

People always say that feedback pathway can be used but never explain which way? I guess that you can give a pulse and catch response fronts by tuning the DCM phase, thus measuring the equivalent delay to mem. This looks simpler than feeding real SDRAM with test data and interpreting responses. However, it is more risky also - computation is less reliable than really working design. Also, I see that the external feedback becomes a part of DCM FB path in PLB memory controller. Nobody can explain the purpose of it!

This contradicts to the first statement

Thanks

Back in the Virtex/Virtex-II families the DCM with an external feedback path was used with SDRAM memory to increase the maximum data rate.

The original clock would come into a DCM that would feed an output buffer. On the PCB the net would be routed from the FPGA to the SDRAM memory for 50% then split in two with one route continuing to the SDRAM and the other returning to the FPGA. This would present the same clock at both FPGA pin and the SDRAM memory. Inside the FPGA the clock feedback pin would be routed to the original DCM to remove all of the internal and PCB delay and compensate for any voltage and temperature variations.

Ed McGettigan

-- Xilinx Inc.

Ok, this matches my reading of xilinx appnotes. However again, you describe the way to get the thing and the purpose of thing but not the way the thing should be used to achieve the purpose.

How do you make use of FPGA phase-aligned with distant SDRAM to struggle the variations? Jedec says that DQS must be in line with DQ and addr/cmd switching at clock fall edge. But, this must happen at the SDRAM side!

THat is, SDRAM has 3 domains: clock, addr/cmd and DQS data lanes. You explained only one thing, how to get known when clock reaches the remote SDRAM. But, what does it give to you if you do not know the delays of cmd and data lines?

iming

s l y

ined,

M

The external DCM feedback was used for the clocks only it was not (and can't be) used for the DQS. The second DCM aligns to the external clock feedback that is now the same for both the FPGA and the DDR- SDRAM and a 90 degree phase shift is used to shift the DQS outputs from the DQ outputs.

This is clearly shown in Figure 8 of XAPP608.

Ed McGettigan

-- Xilinx Inc.

yup, so the SDRAM will appear as an on chip block.... even though it locates few inches away...

Nope. On chip, you know when data arrives with respect to clock.

In theory you are able to know everything even before you can touch the hardware...

Your theory proves everything true. It is known as 'determinism'.

In reality, FPGA tools ensure the data not too late. Because they know the length of both clock and data. You tell the length of board clock trace to SDRAM by the feedback. But, there is no information about DQ/addr delays. Therefore, the on-chip-like timing analysis is impossible. The external clock feedback makes no sense at all.

I know that secondary DCM must be used to get the 90 deg time shift. You specify the clock routing very clearly. But, I do not see any info about _data line_ delays. Saying about clock makes no sense if you data line has indefinite length. Must they exactly match with clock or calibration is desired anyway and the only advantage of external FB is voltage-temperature compensation?

OK, you make me to rethink about this.. what I'm going to do next is to reroute the DCM not to use external feedback, and see if the sdram still operate correct or not,