Goto page 1, 2 Next
valtih1978
Guest
Tue Jun 14, 2011 9:54 am
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?
RCIngham
Guest
Wed Jun 15, 2011 12:42 pm
Quote:
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 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
Morten Leikvoll
Guest
Wed Jun 15, 2011 1:37 pm
"RCIngham" <robert.ingham_at_n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote in
message news:nYadnfl5gelSNWXQnZ2dnUVZ_tOdnZ2d_at_giganews.com...
Quote:
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.
valtih1978
Guest
Wed Jun 15, 2011 3:01 pm
Quote:
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?
Quote:
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?
maxascent
Guest
Wed Jun 15, 2011 3:48 pm
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
RCIngham
Guest
Wed Jun 15, 2011 4:31 pm
[snipped]
Quote:
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
valtih1978
Guest
Wed Jun 15, 2011 4:45 pm
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".
valtih1978
Guest
Wed Jun 15, 2011 4:48 pm
Why do we need _DQS_, I mean.
Thank you for the appreciation.
valtih1978
Guest
Wed Jun 15, 2011 5:00 pm
On 15.06.2011 18:48, maxascent wrote:
Quote:
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?
trag
Guest
Thu Aug 04, 2011 12:23 am
On Jun 15, 11:45 am, valtih1978 <d...@not.email.me> wrote:
Quote:
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
valtih1978
Guest
Sat Aug 20, 2011 9:53 am
Quote:
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!
Quote:
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
Quote:
relationship between DQS and the DDR2 controller clock is not
necessarily the same all the time.
Thanks
Ed McGettigan
Guest
Sat Aug 20, 2011 6:55 pm
On Aug 20, 2:53 am, valtih1978 <d...@not.email.me> wrote:
Quote:
> 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.
valtih1978
Guest
Thu Aug 25, 2011 7:06 am
On 20.08.2011 19:55, Ed McGettigan wrote:
Quote:
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?
Ed McGettigan
Guest
Thu Aug 25, 2011 4:35 pm
On Aug 25, 12:06 am, valtih1978 <d...@not.email.me> wrote:
Quote:
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 -
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.
Mawa_fugo
Guest
Fri Aug 26, 2011 9:09 pm
On Aug 20, 11:55 am, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
Quote:
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.
yup, so the SDRAM will appear as an on chip block.... even though it
locates few inches away...
Goto page 1, 2 Next
