[SI-LIST] Re: DDR2 Trace Length Margin
- From: "Lee Ritchey" <leeritchey@xxxxxxxxxxxxx>
- To: "Jeff Loyer" <jeff.loyer@xxxxxxxxx>
- Date: Fri, 25 Jul 2008 10:57:13 -0700
Well said.
> [Original Message]
> From: Loyer, Jeff <jeff.loyer@xxxxxxxxx>
> To: <leeritchey@xxxxxxxxxxxxx>
> Cc: <si-list@xxxxxxxxxxxxx>
> Date: 7/24/2008 4:49:03 PM
> Subject: RE: [SI-LIST] Re: DDR2 Trace Length Margin
>
> To be fair, a co-worker pointed out a possible source of confusion, so
> I'll try one more time...
>
> My contention is that, if I am going to constrain a bus routing to
> within 100 mils (or 150 mils, where the original argument began), I
> might as well make that constraint 5 mils. The difference in board
> routing space and/or time is insignificant for these 2 scenarios.
>
> And, this has some practical benefits:
> 1) Less source of confusion/error in translating my requirements to CAD.
> The more consistent my constraints, the faster they can be entered into
> the design, and the less chance for error. For instance, on my designs,
> I specify matching differential pairs to within 5mils. To spend any
> energy deciding to match the 2 halves of the differential pair to
> anything other than within 5 mils is a waste of time. CAD folks say
> they can easily do this, and I believe them. And, if I have multi-board
> designs, I don't have to worry about whether the total tuning will
> exceed some spec. 3 boards at 5mils still won't exceed any spec. I know
> of. Similarly, if I have several busses that call for matching of 150
> mils or less, I would advocate matching them all to within 5 mils, for
> the same reasons.
> 2) Constraints become reusable - no change needed for the next design.
> If they tighten it from 100 to 50 mils, I don't care.
> 3) Less of my time spent on something that doesn't matter.
>
> If, on the other hand, the question was whether to match within 1" or
> 6", then I would strongly agree that analysis was in order. In that
> case, the impact to board space and CAD time is very significant. But
> 150 mils to 20 mils (or 5 mils) is a no-brainer.
>
> I hope this clarifies my position. If there's still contention, I'm
> truly baffled that others designing very complex boards would spend time
> on this kind of minutia when there are much more challenging questions
> to answer.
>
> But then, I'm also baffled by the inflammatory tone of folks' responses.
> Perhaps there's a connection...
>
> And, of course, this is my opinion only, not Intel's.
>
> And now I'm baffled about how I got into this morass of time-sink.
>
> Jeff Loyer
>
> -----Original Message-----
> From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx]
> On Behalf Of Loyer, Jeff
> Sent: Thursday, July 24, 2008 2:27 PM
> To: leeritchey@xxxxxxxxxxxxx
> Cc: si-list@xxxxxxxxxxxxx
> Subject: [SI-LIST] Re: DDR2 Trace Length Margin
>
> 1) I would like to see an example where the tuning to only 100 mils (vs.
> 5 mils) used considerably less board space. I contend that the
> difference in board space is negligible.
> 2) Concerning time, I can only go by what my CAD folks tell me, and my
> experience while looking over their shoulders for many hours. I have
> posed this question to many very experienced and capable CAD people, and
> the answer has been consistently "makes very little difference to me".
> 3) I envy you your infinite bandwidth and energy. For us mere mortals,
> knowing where and when to expend our limited resources is a key quality
> that often separates successful from unsuccessful engineers. If that's
> lazy, I'll accept the charge.
>
> Speaking of limited bandwidth, this will be my last posting on this
> topic.
>
> Cheers,
> Jeff Loyer
>
> -----Original Message-----
> From: Lee Ritchey [mailto:leeritchey@xxxxxxxxxxxxx]=20
> Sent: Thursday, July 24, 2008 11:17 AM
> To: Loyer, Jeff; Dan Smith; si-list@xxxxxxxxxxxxx
> Subject: RE: [SI-LIST] Re: DDR2 Trace Length Margin
>
> The problem with inserting add length arbitrarily is what it does to the
> routing surface. I've seen messes around DDR2 sockets that are totally
> unnecessary and use board space that cold well be used for other things.
>
> Add length is not free nor does it take zero time. It should be used
> only
> when necessary, not when engineers are too lazy to do proper
> analysis.=20
>
>
> > [Original Message]
> > From: Loyer, Jeff <jeff.loyer@xxxxxxxxx>
> > To: Dan Smith <Dan.Smith@xxxxxxxxx>; <si-list@xxxxxxxxxxxxx>
> > Date: 7/24/2008 10:28:16 AM
> > Subject: [SI-LIST] Re: DDR2 Trace Length Margin
> >
> > In my experience, CAD folks have constantly fed back that, if I'm
> going
> > to constrain the lengths, there's not much difference between matching
> > to within 100 mils or 5. Based on that, we often put the constraints
> to
> > 5 mils, even though that number appears ridiculously tight. It also
> > allows them to keep constraints consistent throughout a design, and
> less
> > prone to error. And, if it's over-tight, we don't have to worry about
> > how much of the length matching gets applied to each board (of a
> > multi-board design).
> >
> > For me, it allows me to ignore length matching as a variable in my
> > design; another place I don't have to expend energy. Instead, I can
> > spend it on things that are challenging and critical.
> >
> > Yes, you are correct that often the constraints appear absurd. But,
> > there are practical reasons for having those tight constraints. If
> > there were significant challenges at meeting the tight numbers, often
> > some back-of-the-envelope calculations can be used to provide
> > relaxation.
> >
> > This paradigm has been in place for years, with FSB length matching
> > rules of within 10 mils, for instance. Yes, the design could tolerate
> > much more, but CAD folks had little problem meeting it, and it made
> > length matching a moot point.
> >
> > Disclaimer:
> > The content of this message is my personal opinion only and although I
> > am an employee of Intel, the statements I make here in no way
> represent
> > Intel's position on the issue, nor am I authorized to speak on behalf
> of
> > Intel on this matter.
> >
> > Jeff Loyer
> >
> > -----Original Message-----
> > From: si-list-bounce@xxxxxxxxxxxxx
> [mailto:si-list-bounce@xxxxxxxxxxxxx]
> > On Behalf Of Dan Smith
> > Sent: Thursday, July 24, 2008 9:21 AM
> > To: Lee Ritchey; Moran, Brian P; sreekanthn; si-list@xxxxxxxxxxxxx
> > Subject: [SI-LIST] Re: DDR2 Trace Length Margin
> >
> > The last DDR-2 design I did I had DQS and DQ matched to as sloppy as
> 1"
> > and=3D3D
> > I still had 15% margin on reads and over 50% margins on writes - and
> > this =3D3D
> > included PCB impedance variations and loss due to reflections. I
> > implement=3D3D
> > ed more strict rules than 1" but to me, +/- 20 mils is a way over
> burden
> > on=3D3D
> > the CAD designer.
> >
> > Danno
> >
> > -----Original Message-----
> > From: si-list-bounce@xxxxxxxxxxxxx
> [mailto:si-list-bounce@xxxxxxxxxxxxx]
> > On=3D3D
> > Behalf Of Lee Ritchey
> > Sent: Thursday, July 24, 2008 9:06 AM
> > To: Moran, Brian P; sreekanthn; si-list@xxxxxxxxxxxxx
> > Subject: [SI-LIST] Re: DDR2 Trace Length Margin
> >
> > Length matching to +/- 20 mils means length matching to 3.2 pSec.
> That
> > is
> > unrealistically tight. Why not couch length matching in terms of
> time
> > tolerance and then allow designers to turn this into length.
> >
> > I match 2.4 Gb/S differential paths to +/- 150 mils or +/- 24 pS. How
> > could DDR2 require tighter than that or even that tight?
> >
> > Lee Ritchey
> >
> >
> > > [Original Message]
> > > From: Moran, Brian P <brian.p.moran@xxxxxxxxx>
> > > To: sreekanthn <sreekanthn@xxxxxxxxxxxxxxx>; <si-list@xxxxxxxxxxxxx>
> > > Date: 7/21/2008 9:27:41 PM
> > > Subject: [SI-LIST] Re: DDR2 Trace Length Margin
> > >
> > > Hi Sreekanth,
> > >
> > > There is no single specification for length matching. You generally
> > > need to simulate and
> > > do an AC analysis of each application. However, I can give you some
> > > general rules of thumb
> > > from our DDR2 design guides. However, our guidelines are based on
> > > motherboard rules to the module
> > > connector. If your SDRAMs are down on the motherboard, then you do
> not
> > > need to account for
> > > the length variation on the modules. Which should give you slightly
> > > looser rules then our
> > > guidelines stipulate.=3D3D3D20
> > >
> > > The length matching between DQ and DQS within a byte lane is the
> > > tightest constraint. Here
> > > we receommend +/- 20 mils, but this might be overkill in some cases.
> > I
> > > would recommend no
> > > more than +/-50 between DQs and their associated DQS =
> strobe.=3D3D3D20
> > >
> > > The length matching between CTRL and CLK and between ADR/CMD and CLK
> > is
> > > much looser in terms
> > > of the length window, but the relative offset between each of these
> > > groups and CLK must be
> > > adjusted in some cases, in order to center the valid window. This
> > > offset is very much dependent
> > > on the controller timing. Most controller allow this to be done
> > through
> > > register control.=3D3D3D20
> > >
> > > But is terms of the length mismatch windows you can generally live
> > with
> > > a length window of 1.0"=3D3D3D20
> > > (+/- 0.5") on CTRL to CLK, and perhaps 2.0" (+/-1.0") on ADR/CMD to
> > CLK,
> > > assuming you are using
> > > 2N timing on ADR/CMD.
> > >
> > > DQS to CLK is also constrained. Here the overall length window is
> > > generally 1.0" to 1.5" wide.=3D3D3D20
> > >
> > >
> > > So you start by routing and length matching your CLKs. Then
> establish
> > > your length window around CLK
> > > for CTRL, CMD, and DQS. If you find it hard to route within these
> > > windows, then lengthen CLKs as required
> > > to get the length window in the required range. Usually this is
> > > dictated by the min and max length of
> > > the DQS strobes, since the DQ bus has the largest natural length
> > > variation between the shortest byte lanes
> > > and the longest. =3D3D3D20
> > >
> > > The controllers generally have a timing offset control that will
> allow
> > > you to optimize setup and hold
> > > by shifting CLK, CTRL and CMD, at the source. =3D3D3D20
> > > =3D3D3D20
> > >
> > >
> > > Brian Moran
> > > MPG/MPHD/EDE/PEA Group
> > > Intel Corporation
> > >
> > > -----Original Message-----
> > > From: si-list-bounce@xxxxxxxxxxxxx
> > [mailto:si-list-bounce@xxxxxxxxxxxxx]
> > > On Behalf Of sreekanthn
> > > Sent: Monday, July 21, 2008 5:07 AM
> > > To: si-list@xxxxxxxxxxxxx
> > > Subject: [SI-LIST] DDR2 Trace Length Margin
> > >
> > >
> > >
> > > Hi Experts,
> > >
> > > I would like to know the length matching requirement of a DDR2
> > design.
> > > I have two memory devices in my board (NOT DIMMs).
> > > Each has 16 bit data (Total 32) ,Each byte has its own Data strobe
> and
> > > Mask
> > > signals.
> > >
> > > Datas ,Stobes,Masks,Clk etc are point to point topology.
> > > Address and other common signals ( RAS,CAS,WE,RE,CS,CLKEN etc...)
> has
> > > to be
> > > routed in T topology.
> > >
> > > Could someone please explain the rule of length matching for each
> > > groups.
> > > Is there any standard docs available ? I refered JDEC specs, I
> could
> > > n't
> > > get any routing recommendations.
> > >
> > > How can we engineer the trace length margin ?
> > >
> > > My Max clock would be 667MHz.
> > >
> > > Regards,
> > > Sreekanth=3D3D3D20
> > >
> > >
> > > The information contained in this electronic message and any
> > attachments
> > > to this message are intended for the exclusive use of the
> addressee(s)
> > > and may contain proprietary, confidential or privileged information.
> > If
> > > you are not the intended recipient, you should not disseminate,
> > > distribute or copy this e-mail. Please notify the sender immediately
> > and
> > > destroy all copies of this message and any attachments contained in
> > it.
> > >
> > > Contact your Administrator for further information.
> > >
> > > ------------------------------------------------------------------
> > > 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:
> > > http://www.freelists.org/webpage/si-list
> > >
> > > For help:
> > > si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
> > >
> > >
> > > List technical documents are available at:
> > > http://www.si-list.net
> > >
> > > List archives are viewable at: =3D3D3D20
> > > http://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
> > > =3D3D3D20
> > >
> > > ------------------------------------------------------------------
> > > 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:
> > > http://www.freelists.org/webpage/si-list
> > >
> > > For help:
> > > si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
> > >
> > >
> > > List technical documents are available at:
> > > http://www.si-list.net
> > >
> > > List archives are viewable at:
> > > http://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:
> > http://www.freelists.org/webpage/si-list
> >
> > For help:
> > si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
> >
> >
> > List technical documents are available at:
> > http://www.si-list.net
> >
> > List archives are viewable at:
> > http://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:
> > http://www.freelists.org/webpage/si-list
> >
> > For help:
> > si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
> >
> >
> > List technical documents are available at:
> > http://www.si-list.net
> >
> > List archives are viewable at: =3D20
> > http://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:
> > http://www.freelists.org/webpage/si-list
> >
> > For help:
> > si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
> >
> >
> > List technical documents are available at:
> > http://www.si-list.net
> >
> > List archives are viewable at: =20
> > http://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:
> http://www.freelists.org/webpage/si-list
>
> For help:
> si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
>
>
> List technical documents are available at:
> http://www.si-list.net
>
> List archives are viewable at:
> http://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:
http://www.freelists.org/webpage/si-list
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List technical documents are available at:
http://www.si-list.net
List archives are viewable at:
http://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: