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

V

valtih1978

Guest
The data arrives with some unknown phase shift relatively to system
(synchronized to SDRAM) clock. DQ can be captured more reliably if we
route the data clock, DQS, along the data. They suggest that it is easy
to transport the received data bursts into the system clock domain using
a FIFO afterwards. This is great. I just see a one small problem:

How do you know that the read operation takes place so that
the captured data are valid for submission into FIFO?


A READ_EN signal must be delivered from the SDRAM write/command part
(CLK domain) into asynchronously running receiver in DQS domain (the
period is the same but phase is unknown) with one DQS clock precision.
Remember that we run away from strobing DQ by CLK phases because we do
not know the data arriving phase relatively to CLK. That is why we
introduced the DQS. But now, we still must figure out the phase shift.
It looks like our attempt to do without the phase difference has failed.

Why people still use DQS for strobing data instead of some CLK-derived
phase?
 
The data arrives with some unknown phase shift relatively to system
(synchronized to SDRAM) clock. DQ can be captured more reliably if we
route the data clock, DQS, along the data. They suggest that it is easy
to transport the received data bursts into the system clock domain using
a FIFO afterwards. This is great. I just see a one small problem:

How do you know that the read operation takes place so that
the captured data are valid for submission into FIFO?


A READ_EN signal must be delivered from the SDRAM write/command part
(CLK domain) into asynchronously running receiver in DQS domain (the
period is the same but phase is unknown) with one DQS clock precision.
Remember that we run away from strobing DQ by CLK phases because we do
not know the data arriving phase relatively to CLK. That is why we
introduced the DQS. But now, we still must figure out the phase shift.
It looks like our attempt to do without the phase difference has failed.

Why people still use DQS for strobing data instead of some CLK-derived
phase?
Click to expand...
Some DDR2 SDRAM controllers require a feedback clok input, being thei
output clock via a loop of track that goes the same distance as to th
SDRAM and back. Others go through a training phase where they work out th
"time-of-flight" from the controller to the SDRAM and back. Either work
well enough. If your FPGA is from Xilinx, use their MIG tool to generat
the controller.


---------------------------------------
Posted through http://www.FPGARelated.com
 
"RCIngham" <robert.ingham@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote in
message news:nYadnfl5gelSNWXQnZ2dnUVZ_tOdnZ2d@giganews.com...
The data arrives with some unknown phase shift relatively to system
(synchronized to SDRAM) clock. DQ can be captured more reliably if we
route the data clock, DQS, along the data. They suggest that it is easy
to transport the received data bursts into the system clock domain using
a FIFO afterwards. This is great. I just see a one small problem:

How do you know that the read operation takes place so that
the captured data are valid for submission into FIFO?


A READ_EN signal must be delivered from the SDRAM write/command part
(CLK domain) into asynchronously running receiver in DQS domain (the
period is the same but phase is unknown) with one DQS clock precision.
Remember that we run away from strobing DQ by CLK phases because we do
not know the data arriving phase relatively to CLK. That is why we
introduced the DQS. But now, we still must figure out the phase shift.
It looks like our attempt to do without the phase difference has failed.

Why people still use DQS for strobing data instead of some CLK-derived
phase?


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.
Click to expand...
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 <1clk delay (and I think that is specified
in the std).
Imho, dq's should be single direction and separate for r/w.. Maybe they did
that to later DDR standards.
 
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.
Click to expand...
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?


If your FPGA is from Xilinx, use their MIG tool to generate
the controller.
Click to expand...
My board is http://www.xilinx.com/univ/XUPV2P, routed for Xilinx
http://www.xilinx.com/support/documentation/ip_documentation/plb_ddr.pdf
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 th
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 the
reading it back and using a IO delay inside the FPGA to alter th
relationship between the data and internal clock.

Jon

---------------------------------------
Posted through http://www.FPGARelated.com
 
[snipped]
My board is http://www.xilinx.com/univ/XUPV2P, routed for Xilinx
http://www.xilinx.com/support/documentation/ip_documentation/plb_ddr.pdf
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?"

[snipped]
Click to expand...

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 http://www.FPGARelated.com
 
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.
 
On 15.06.2011 18:48, maxascent wrote:
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.
Click to expand...
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 Jun 15, 11:45 am, valtih1978 <d...@not.email.me> wrote:
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".
Click to expand...
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
 
either
through data training (testing data samples and seeing what timing
works) or through a timing feedback pathway
Click to expand...
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!


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

This contradicts to the first statement

relationship between DQS and the DDR2 controller clock is not
necessarily the same all the time.
Click to expand...

Thanks
 
On Aug 20, 2:53 am, valtih1978 <d...@not.email.me> wrote:
 > either
 > through data training (testing data samples and seeing what timing
 > works) or through a timing feedback pathway

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!

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

This contradicts to the first statement

 > relationship between DQS and the DDR2 controller clock is not
necessarily the same all the time.

Thanks
Click to expand...
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.
 
On 20.08.2011 19:55, Ed McGettigan wrote:
On Aug 20, 2:53 am, valtih1978<d...@not.email.me> wrote:
either
through data training (testing data samples and seeing what timing
works) or through a timing feedback pathway

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!

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.

This contradicts to the first statement

relationship between DQS and the DDR2 controller clock is not
necessarily the same all the time.

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.
Click to expand...
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?
 
On Aug 25, 12:06 am, valtih1978 <d...@not.email.me> wrote:
On 20.08.2011 19:55, Ed McGettigan wrote:





On Aug 20, 2:53 am, valtih1978<d...@not.email.me>  wrote:
  >  either
  >  through data training (testing data samples and seeing what timing
  >  works) or through a timing feedback pathway

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!

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

This contradicts to the first statement

  >  relationship between DQS and the DDR2 controller clock is not
necessarily the same all the time.

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?- Hide quoted text -

- Show quoted text -
Click to expand...
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.
 
On Aug 20, 11:55 am, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
On Aug 20, 2:53 am, valtih1978 <d...@not.email.me> wrote:



 > either
 > through data training (testing data samples and seeing what timing
 > works) or through a timing feedback pathway

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!

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

This contradicts to the first statement

 > relationship between DQS and the DDR2 controller clock is not
necessarily the same all the time.

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.
Click to expand...
yup, so the SDRAM will appear as an on chip block.... even though it
locates few inches away...
 
yup, so the SDRAM will appear as an on chip block.... even though it
locates few inches away...
Click to expand...
Nope. On chip, you know when data arrives with respect to clock.
 
On Aug 30, 5:34 am, valtih1978 <d...@not.email.me> wrote:
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.
Click to expand...
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?
 
On Sep 1, 11:16 am, valtih1978 <d...@not.email.me> wrote:
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.
Click to expand...
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,
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top