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.

 > 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

On May 7, 2:02=A0pm, valtih1978 <inte...@yandex.ru> wrote:
> I see it in many SDRAM controllers, e.g.ftp://ftp.xilinx.com/pub/applicat=
ions/xapp/xapp608.pdf, and nobody explains
> WHY
>
> The extranal feedback trace must equal to CK len. Ok. This means that SDR=
AM
> 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

On May 11, 1:39=A0pm, 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. =A0That 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

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=.)
--------------------------------------------------------------

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 http://www.FPGARelated.com

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

On May 9, 5:50=A0am, valtih1978 <inte...@yandex.ru> wrote:
> > In the first app note you reference figure 8 shows the feedback for
> > the DCMs. =A0This feedback allows the delay getting to the IO pins to b=
e
> > calibrated out. =A0If the feedback also includes the delay of the clock
> > path from the FPGA to the DIMM this delay will also be calibrated
> > out. =A0I 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

On May 7, 3:02=A0pm, valtih1978 <inte...@yandex.ru> wrote:
> I see it in many SDRAM controllers, e.g.ftp://ftp.xilinx.com/pub/applicat=
ions/xapp/xapp608.pdf, and nobody explains
> WHY
>
> The extranal feedback trace must equal to CK len. Ok. This means that SDR=
AM
> 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 b=
e
> the len of feedback in this case?
>
> In these designs, the read DQ is clocked directly by DQS. Yet, DQ is chan=
ged
> 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 d=
ata
> 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

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