Why feedback clock in SDRAM controllers?

"Calibrate out" is too general term. I understand that DCM allows to have some points "in phase". I want to know why this is done in these cases.

It is a XUPV2p board and the extranal feedback trace length is identical to CK.

ions/xapp/xapp608.pdf, and nobody explains

AM

ged

TO

it

ata

In the first app note you reference figure 8 shows the feedback for the DCMs. This feedback allows the delay getting to the IO pins to be calibrated out. If the feedback also includes the delay of the clock path from the FPGA to the DIMM this delay will also be calibrated out. I expect this is important in reading data from the DIMM.

But I'm a bit unclear about why the feedback does not include the delay of the read data PCB traces as well. Data going to the DIMM does not need to consider the trace delay because both clock and data see the same delay (if the board is designed that way). But the read data path delay actually consists of the clock path to the DIMM as well as the read data path back to the FPGA.

Perhaps I didn't read the app note correctly. These things can be a little hard to interpret until you completely understand their terminology.

Rick

to

If you don't adjust the phase to align the clock to the timing of the return data your clock speed will be limited by the round trip delay path. That's also why they use a 90 degree phase relationship between the output clock and the input clock. That puts the sample time in the middle of the data stable time.

Rick

What exactly should be adcjusted? Which round trip? Let's start by the addr/cmd delivery to the SDRAM. How matching FB length with the trace to SDRAM clock helps the command to arrive closer to the falling edge?

I believe the 90 degree-shift is independent from the feedback. I more or less under stand how it works. It is discrete and logical. I do not understand the feedback. How should I adjust it in the FPGA and how does it help.

You dont actually need this pcb trace. Just clock the SDRAM using the clock output of a DCM and clock the data from a 90 degree output. That will give you ample setup time.

Jon

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

The problem is that you don't know the delay between the output of the flipflop and the signal arriving at the SDRAM.

When reading appnotes on memory controllers you should bear in mind that FPGA vendors want to push their devices to the limits and come up with overcomplicated solutions. Like Rickman said, if don't push the design to the limits and do a proper timing analysis you can come up with a much simpler solution.

it

Draw a timing diagram of the clock, address and data, including the path delays on the PCB. The round trip is the clock plus address/data leaving the FPGA (include the internal delays as well as external) going to the ram, then the read data returning. What does the delay through the IO pins and on the PCB do to the setup and hold timing of the read data at the FFs inside the FPGA? Remember that the FFs are being clocked by the internal clock. Now consider that the read data FFs are being clocked by a DCM that is sync'd to a signal that is going out of the chip, through a trace equal to the path to the ram and back in the chip IO pins. The IO delays are multiple nanoseconds while the PCB trace is likely less than a single nanosecond, but at the speeds they push memory every fraction of a nanosecond counts.

On the newer ram modules the interface includes a clock going to the ram, regenerated on the module and back to the memory interface. That's how important compensation of these delays are.

If this is still not enough, maybe I can draw a diagram for you, but I'm away for the weekend. It will be likely Tuesday before I can look at this.

Rick

ions/xapp/xapp608.pdf, and nobody explains

AM

I think I can explain to this point. rest of question I don't know

The DCM needs to "see" what the clock looks like at the memory, so it can adjust the phase accordingly, for this purpose whoever wrote that app notes thinking that the ext. feed back need to be same length as the CK length

Really? Why do you think people care about the DLLs? Is it because they do not understand the importance of nanoscale timing?

Also, let me remind you, that in my question I pointed out that DCM feedbacks require that the FPGA-external feedback trace length matching the CLK trace length from FPGA to ram.

I keep reminding about this because do not see any reason for this design. Yet, I feel that it is a key and want anybody to explan.

You see, the dialog goes on:

A: The path delays must be taken into account these days. You know, they are important. B: Ok. How this example design works? A: Hm. Look at my first statement: things are very complicated now. We must take the delays into account.

This is an infinite loop. How can I break out of it and understand the design examples?

yes, please

I agree. The first problem is that there will be FPGA-internal part of the loop, which increases this length. But the thing I want to know in the first place - why do we need the phase adjustment?

Which phase is adjusted? The DCM drives internal FFs, making them all in phase. The internal feedback is distributed via DCM-generated clock three and therefore matches the DCM-to-regs clock delay, making childern regs in-phase with the DCM input clock. Also, vendor tools can ensure that combinatorial logic delays are shorter than the period.

Now, the feedback goes through external path. The DCM input is in phase with the rest of FPGA system. The output is adjusted so that something distant (i.e. DRAM CLK input) is also in phase.

If this picture is right, I see no reason of this "phase matching". We cannot benefit from it because the tools ignore the fpga-external data paths. Even worse: the adjusted clock will arrive earlier than it would naturally. Normally, you would have data and clock changing simultaneouly (ok, clock raises in the middle of data slot) at FPGA outputs and, having the same external path delays, would arrive to SDRAM with low skew. I see that using DCM "adjustment" just breaks this natural "source synchronous" phase matching.