[SI-LIST] Re: DDR2 Trace Length Margin

  • From: <Aubrey_Sparkman@xxxxxxxx>
  • To: <Dan.Smith@xxxxxxxxx>, <leeritchey@xxxxxxxxxxxxx>, <jeff.loyer@xxxxxxxxx>, <si-list@xxxxxxxxxxxxx>
  • Date: Thu, 24 Jul 2008 15:10:28 -0500

I totally agree that overdesign requires less thought.   And I would add
that it also takes less *engineering* time.   My point was on the "Lazy"
comment.  Good engineering is about making design trade-offs and
resource allocation.  Which engineer would you prefer to have you your
team; one who spent a month doing simulations to find out exactly what
lengths could be tolerated or one who spends a day to figure out that
you would still have to use the same number of layers, components, etc
regardless of how tight the traces were matched.

When I get a recommendation, I get to decide whether I follow it and
move on, challenge the recommendation, or do my own work to develop my
own rules.  Personally, I want to see a "pay-back" for my efforts.


Aubrey Sparkman=20
Enterprise Engineering Signal Integrity Team=20
Dell, Inc.=20
Aubrey_Sparkman@xxxxxxxx=20
(512) 723-3592=20
"The single biggest problem in communication is the illusion that it has
taken place." -- George Bernard Shaw



-----Original Message-----
From: Dan Smith [mailto:Dan.Smith@xxxxxxxxx]=20
Sent: Thursday, July 24, 2008 2:43 PM
To: Sparkman, Aubrey; leeritchey@xxxxxxxxxxxxx; jeff.loyer@xxxxxxxxx;
si-list@xxxxxxxxxxxxx
Subject: RE: [SI-LIST] Re: DDR2 Trace Length Margin

Overdesigning always requires less thought.

-----Original Message-----
From: Aubrey_Sparkman@xxxxxxxx [mailto:Aubrey_Sparkman@xxxxxxxx]
Sent: Thursday, July 24, 2008 12:15 PM
To: leeritchey@xxxxxxxxxxxxx; jeff.loyer@xxxxxxxxx; Dan Smith;
si-list@xxxxxxxxxxxxx
Subject: RE: [SI-LIST] Re: DDR2 Trace Length Margin

Lee,

So you think the only reason someone would not do what you consider
proper analysis is because they are lazy?


Aubrey Sparkman
Enterprise Engineering Signal Integrity Team Dell, Inc.
Aubrey_Sparkman@xxxxxxxx
(512) 723-3592
"The single biggest problem in communication is the illusion that it has
taken place." -- George Bernard Shaw



-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx]
On Behalf Of Lee Ritchey
Sent: Thursday, July 24, 2008 1:17 PM
To: Jeff Loyer; Dan Smith; si-list@xxxxxxxxxxxxx
Subject: [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.


> [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=20
> going to constrain the lengths, there's not much difference between=20
> matching to within 100 mils or 5.  Based on that, we often put the=20
> constraints to
> 5 mils, even though that number appears ridiculously tight.  It also=20
> allows them to keep constraints consistent throughout a design, and=20
> less prone to error.  And, if it's over-tight, we don't have to worry=20
> 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=20
> design; another place I don't have to expend energy.  Instead, I can=20
> spend it on things that are challenging and critical.
>
> Yes, you are correct that often the constraints appear absurd.  But,=20
> there are practical reasons for having those tight constraints.  If=20
> there were significant challenges at meeting the tight numbers, often=20
> some back-of-the-envelope calculations can be used to provide=20
> relaxation.
>
> This paradigm has been in place for years, with FSB length matching=20
> 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=20
> 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=20
> represent Intel's position on the issue, nor am I authorized to speak=20
> 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=20
> this =3D3D included PCB impedance variations and loss due to=20
> 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=20
> > design guides. However, our guidelines are based on motherboard=20
> > rules to the module connector. If your SDRAMs are down on the=20
> > motherboard, then you do not need to account for the length=20
> > variation on the modules.  Which should give you slightly looser=20
> > rules then our guidelines stipulate.=3D3D3D20
> >
> > The length matching between DQ and DQS within a byte lane is the=20
> > tightest constraint. Here we receommend +/- 20 mils, but this might=20
> > 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=20
> > groups and CLK must be adjusted in some cases, in order to center=20
> > the valid window.  This offset is very much dependent on the=20
> > 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=20
> > generally 1.0" to 1.5" wide.=3D3D3D20
> >
> >
> > So you start by routing and length matching your CLKs.  Then=20
> > establish your length window around CLK for CTRL, CMD, and DQS.  If=20
> > you find it hard to route within these windows, then lengthen CLKs=20
> > 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=20
> > shortest byte lanes and the longest. =3D3D3D20
> >
> > The controllers generally have a timing offset control that will=20
> > allow you to optimize setup and hold by shifting CLK, CTRL and CMD,=20
> > 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=20
> > 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...)=20
> > has to be routed in T topology.
> >
> > Could someone please explain the rule of length matching for each=20
> > groups.
> > Is there any standard docs available ? I refered JDEC  specs, I=20
> > 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,=20
> > 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=20
> > 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 technical documents are available at:
> >                 http://www.si-list.net
> >
> > List archives are viewable at:    =3D3D3D20
> >               //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=20
> > 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 technical documents are available at:
> >                 http://www.si-list.net
> >
> > 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 technical documents are available at:
>                 http://www.si-list.net
>
> 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 technical documents are available at:
>                 http://www.si-list.net
>
> 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 technical documents are available at:
>                 http://www.si-list.net
>
> 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 technical documents are available at:
                http://www.si-list.net

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 technical documents are available at:
                http://www.si-list.net

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: