Why feedback clock in SDRAM controllers?

[valtih1978]

I see it in many SDRAM controllers, e.g.
ftp://ftp.xilinx.com/pub/applications/xapp/xapp608.pdf, and nobody explains
WHY

The extranal feedback trace must equal to CK len. Ok. This means that SDRAM
will be clocked in phase with the FPGA system. How does it ensure that
cmd/addr arrives to SDRAM in proper time, half cycle earlier of CK?

In the more recommended xapp266 and xapp253, the external feedback is not
used. Why? What is the purpose of the second, internal DLL? What should be
the len of feedback in this case?

In these designs, the read DQ is clocked directly by DQS. Yet, DQ is changed
simultaneously with DQS. This ensures the setup/hold violation! The "HOW TO
USE DDR SDRAM" says: "when controller receives read data from DDR SDRAM, it
will internally delay the received strobe to the center of the received data
window." I do not see any delay!

Thanks

 

[valtih1978]

I have also reconstructed the EDK 10.1 inferred controller from example NGR
file is available at https://wiki.ittc.ku.edu/rtrjvm/EDK_and_MD

The circuit is
http://4.bp.blogspot.com/-
lbrLUp89H50/TcgOHuzzEEI/AAAAAAAAACw/j2WU_uNrxOk/s1600/feedback%2Bclocking.png

I do not see it among the Xilinx Memory Interface App Notes. Is it better?
Here again, commands are generated in phase with sys_clk andthe length of
the internal feedbacks is the thing to know.

The FB pin seems to be in phase with CLK0 at SDRAM. Why its 90 deg shifted
version is used for clocking the receiving part? Since it does not account
for the backward trace length from SDRAM to FPGA (the time traveled by data)
but CLK and strobes must be in phase, wouldn't it be better to use one of
the strobes for clocking? Instead, they use the strobe as clock enable in
FIFO! Isn't it curious?

 

[valtih1978]

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.

"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.

 

[rickman]

On May 7, 3:02 pm, valtih1978 <inte...@yandex.ru> wrote:

I see it in many SDRAM controllers, e.g.ftp://ftp.xilinx.com/pub/applications/xapp/xapp608.pdf, and nobody explains
WHY

The extranal feedback trace must equal to CK len. Ok. This means that SDRAM
will be clocked in phase with the FPGA system. How does it ensure that
cmd/addr arrives to SDRAM in proper time, half cycle earlier of CK?

In the more recommended xapp266 and xapp253, the external feedback is not
used. Why? What is the purpose of the second, internal DLL? What should be
the len of feedback in this case?

In these designs, the read DQ is clocked directly by DQS. Yet, DQ is changed
simultaneously with DQS. This ensures the setup/hold violation! The "HOW TO
USE DDR SDRAM" says: "when controller receives read data from DDR SDRAM, it
will internally delay the received strobe to the center of the received data
window." I do not see any delay!

Thanks

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

 

[rickman]

On May 9, 5:50 am, valtih1978 <inte...@yandex.ru> wrote:

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.

"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.

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

 

[valtih1978]

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.

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?

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.

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.

 

[maxascent]

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

Jon

---------------------------------------
Posted through http://www.FPGARelated.com

 

[Nico Coesel]

valtih1978 <intellij@yandex.ru> wrote:

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.

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?

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.

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.

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.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

 

[rickman]

On May 11, 1:39 pm, valtih1978 <intel...@yandex.ru> wrote:

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.

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?

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.

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.

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

 

[Mawa_fugo]

On May 7, 2:02 pm, valtih1978 <inte...@yandex.ru> wrote:

I see it in many SDRAM controllers, e.g.ftp://ftp.xilinx.com/pub/applications/xapp/xapp608.pdf, and nobody explains
WHY

The extranal feedback trace must equal to CK len. Ok. This means that SDRAM
will be clocked in phase with the FPGA system

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

 

[valtih1978]

That's how important compensation of these delays are.

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?

If this is still not enough, maybe I can draw a diagram for you, but

yes, please

 

[valtih1978]

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.