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

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

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

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.

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.

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

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.

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=A0am, 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".

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