[SI-LIST] Re: DDR2 Clock and DQS Lines
- From: "Peterson, James F \(EHCOE\)" <james.f.peterson@xxxxxxxxxxxxx>
- To: <hreidmarkailen@xxxxxxxxx>, <si-list@xxxxxxxxxxxxx>
- Date: Tue, 2 Jan 2007 06:23:04 -0600
Agathon,
I agree with you, nobody was explaining why....my reply must have fell
through the cracks...see below for my take on why CK/CKn must align with
DQS. (it's similar to yours, only I believe it's there because of DRAM
write req's not the controller's read req's).
regards,
jim
<snip>
-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx]
On Behalf Of Peterson, James F (EHCOE)
Sent: Thursday, December 28, 2006 6:06 PM
To: kenny_frohlich@xxxxxxxxx; si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: DDR2 Clock and DQS Lines
Kenny,
yes it needs to be matched......now anticipating that your next question
is : "but why??" (which I would certainly also ask): The reason is that
the DQ info that just was clock into the memory with DQS must now cross
into the SDRAM's internal local clock domain, which is based on CK and
CKn, and you can't cross clock domains, without establishing a
relationship between the clocks (DQS and CK)...(that is, unless you want
to drop bits - and if you just double-register you will drop bits.)
take care.
Jim Peterson
Honeywell=3D20
<snip>
-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx]
On Behalf Of agathon
Sent: Tuesday, January 02, 2007 12:37 AM
To: si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: DDR2 Clock and DQS Lines
Hello,
It's all good, but nobody's explained why the requirement exists. I
used to know, I think... so I'll just contribute 2 cents worth...
DQS/CK matching has alot to do with the read timing budget within the
ctlr.
A burst is captured using DQS (DLL shifted version) but then a
setup/hold is required around CK in order to transfer the longword
(64-bit for example) over to the ctlr's clk domain. It's ctlr-dependent
so the sensible thing is to just give a tight tolerance based on basic
facts using current silicon technologies and an allowable DLL
uncertainty and dram+board budgets for ISI, ck duty cycle, various
skews, and random jitter. Beyond these budgets, the ctlr has to use a
DLL version of CK, too, delayed by a feedback trace usually and once
called "clock mirroring" I believe. This delay matches the round trip
of the CK trace to the dram, so read data arrives with the {CK to dram +
DQ-read trace} delays roughly cancelled and, therefore, better
synchronized to ctlr CK.
Something similar but simpler has a role where write data is involved
(at the dram). It's all boiled down into strict layout rules by
motherboard vendors. This stuff is interesting to fathom and implement
once perhaps...
then it's off to the trees to learn to play the flute.
Apologies for any errors in my tale.
Regards,
Agathon
On 1/1/07, Moran, Brian P <brian.p.moran@xxxxxxxxx> wrote:
>
> Kenny,
>
> The length matching rules for DDR2 interfaces can be broken into=20
> multiple levels. The most stringent rules are for DQ and DM to =
DQS=3D20=20
> strobe, within a byte lane. This is the most critical timing path. =20
> Here you need to match all signals within the byte lane to within a=20
> fairly tight range, and all signals within a byte lane should be=20
> routed on the same layer.
>
> While length matching to CLK is also required, these rules are=20
> generally not as stringent as data to strobe. For example, you might=20
> have a 1" length window around CLK length, in which to route CTRL or=20
> ADR/CMD signals. There is also a length window for all strobes with=20
> respect to CLK.
>
> In the designs I have participated in these length windows are wide=20
> enough to allow the CTRL, ADR/CMD, and DQS signals to be routed=20
> without excessive length tuning.
> Its the byte lanes that require most of the tuning. Then the CLKs need
> to be adjusted in length so as to get the length windows aligned to=20
> the natural routing lengths of CTRL,=3D20 ADR/CMD, and DQS. Of course=20
> every case is different. Where you can run into trouble is if you=20
> have non-standard placements where the controller and the memory=20
> connectors are not placed symetrically. This can create a fairly wide=20
> length variance across the=3D20 connector and make length matching=20
> extremely difficult.=3D20
>
> Consult the design guidelines for the controller you are using for=20
> more details on the width of the length matching windows for different
> signal groups. =3D20
>
>
> Brian P. Moran
> Intel Corporation=3D20
>
>
> -----Original Message-----
> From: si-list-bounce@xxxxxxxxxxxxx=20
> [mailto:si-list-bounce@xxxxxxxxxxxxx]
> On Behalf Of Kai Keskinen
> Sent: Saturday, December 30, 2006 5:42 PM
> To: kenny_frohlich@xxxxxxxxx; si-list@xxxxxxxxxxxxx
> Subject: [SI-LIST] Re: DDR2 Clock and DQS Lines
>
> Kenny:
>
> Read any app note from anyone that makes a DDR or DDR2 controller.=20
> Your AMD app note is telling you the right way to implement your=20
> interface if you want it to work. The strobe has to have some=20
> tolerance to the clock and then the data bits corresponding to that=20
> strobe have to have even tighter tolerance to the strobe. This forms a
> byte lane. You can also check out the DDR or DDR2 JEDEC specs at the=20
> JEDEC site for more details. Micron has a wealth of application notes
too.
>
>
>
> -----Original Message-----
> From: si-list-bounce@xxxxxxxxxxxxx
> [mailto:si-list-bounce@xxxxxxxxxxxxx]On Behalf Of Kenny Frohlich
> Sent: Tuesday, December 26, 2006 10:57 PM
> To: si-list@xxxxxxxxxxxxx
> Subject: [SI-LIST] DDR2 Clock and DQS Lines
>
>
> Hi All,
> I understand that DQ and DQM lines need to match length with DQS=20
> lines, and Addr/Control lines need to length match with clocks. But=20
> do DQS lines need to length match with clocks?
> In AMD design guidelines, they specifies that DQS lines need to=20
> length match with DDR2 clocks. But is this really a requirement=20
> (industry standard)?
>
> Thanks,
> Kenny
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around=20
> http://mail.yahoo.com
>
> ------------------------------------------------------------------
> To unsubscribe from si-list:
> si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
>
> or to administer your membership from a web page, go to:
> //www.freelists.org/webpage/si-list
>
> For help:
> si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
>
> List FAQ wiki page is located at:
> http://si-list.org/wiki/wiki.pl?Si-List_FAQ
>
> List technical documents are available at:
> http://www.si-list.org
>
> List archives are viewable at:
> //www.freelists.org/archives/si-list
> or at our remote archives:
> http://groups.yahoo.com/group/si-list/messages
> Old (prior to June 6, 2001) list archives are viewable at:
> http://www.qsl.net/wb6tpu
>
>
>
> ------------------------------------------------------------------
> To unsubscribe from si-list:
> si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
>
> or to administer your membership from a web page, go to:
> //www.freelists.org/webpage/si-list
>
> For help:
> si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
>
> List FAQ wiki page is located at:
> http://si-list.org/wiki/wiki.pl?Si-List_FAQ
>
> List technical documents are available at:
> http://www.si-list.org
>
> List archives are viewable at: =3D20
> //www.freelists.org/archives/si-list
> or at our remote archives:
> http://groups.yahoo.com/group/si-list/messages
> Old (prior to June 6, 2001) list archives are viewable at:
> http://www.qsl.net/wb6tpu =3D20
> ------------------------------------------------------------------
> To unsubscribe from si-list:
> si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
>
> or to administer your membership from a web page, go to:
> //www.freelists.org/webpage/si-list
>
> For help:
> si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
>
> List FAQ wiki page is located at:
> http://si-list.org/wiki/wiki.pl?Si-List_FAQ
>
> List technical documents are available at:
> http://www.si-list.org
>
> List archives are viewable at:
> //www.freelists.org/archives/si-list
> or at our remote archives:
> http://groups.yahoo.com/group/si-list/messages
> Old (prior to June 6, 2001) list archives are viewable at:
> http://www.qsl.net/wb6tpu
>
>
>
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
or to administer your membership from a web page, go to:
//www.freelists.org/webpage/si-list
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List FAQ wiki page is located at:
http://si-list.org/wiki/wiki.pl?Si-List_FAQ
List technical documents are available at:
http://www.si-list.org
List archives are viewable at: =20
//www.freelists.org/archives/si-list
or at our remote archives:
http://groups.yahoo.com/group/si-list/messages
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
=20
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
or to administer your membership from a web page, go to:
//www.freelists.org/webpage/si-list
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List FAQ wiki page is located at:
http://si-list.org/wiki/wiki.pl?Si-List_FAQ
List technical documents are available at:
http://www.si-list.org
List archives are viewable at:
//www.freelists.org/archives/si-list
or at our remote archives:
http://groups.yahoo.com/group/si-list/messages
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
Other related posts:
