[SI-LIST] Re: DDR2 Trace Length Margin

I'm sorry, but if you've done your timing/si budget on a high speed 
mission critical bus, then you know exactly what delay matching 
requirements are, and therefore how to constrain your net routing.  It 
takes no time to write down a routing rule.  If you then still specify 
some absurdly small number without thinking of the possible 
implications, then you don't want to work for a boss like me.
If you haven't done your timing/si budget and specify absurdly small 
delay matching requirements, then you are not doing engineering, no 
matter what you call it, or how you justify it.   You're playing a game 
of chance.

regards,

Scott

Scott McMorrow
Teraspeed Consulting Group LLC
121 North River Drive
Narragansett, RI 02882
(401) 284-1827 Business
(401) 284-1840 Fax

http://www.teraspeed.com

Teraspeed® is the registered service mark of
Teraspeed Consulting Group LLC



Robert Washburn wrote:
> Aubrey's later example is a good one, though.  For the majority of
> designs that I do, the advantages of "over-constraining" outweigh the
> negatives.  That hasn't always been true, and I've gone through the
> analysis in those minority cases, but it is generally.  While it might
> be interesting for me to do a series of simulations and measurements in
> a complex experiment to determine exactly how much trace mismatch I can
> tolerate on every design, it's not very practical.  I'm quicker to
> market by bounding that mismatch at some reasonable and conservative
> level and spending my time analyzing parts of the design where the
> tradeoff is less clear and my expertise is therefore better utilized.
>
> Not too many people ship systems with no margin, so we're really asking
> what level of overkill is too much.  The debate, which we've had on this
> list multiple times over the years, is by how much, and the follow-on
> question is how much time and energy is it worth to reduce that amount
> of overkill.
>
> robert
>
> -----Original Message-----
> From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx]
> On Behalf Of Scott McMorrow
> Sent: Thursday, July 24, 2008 3:57 PM
> To: Aubrey_Sparkman@xxxxxxxx
> Cc: leeritchey@xxxxxxxxxxxxx; jeff.loyer@xxxxxxxxx; Dan.Smith@xxxxxxxxx;
> si-list@xxxxxxxxxxxxx
> Subject: [SI-LIST] Re: DDR2 Trace Length Margin
>
> Well, the other possibility is that a proper analysis was not considered
> to be important.
>
> Scott McMorrow
> Teraspeed Consulting Group LLC
> 121 North River Drive
> Narragansett, RI 02882
> (401) 284-1827 Business
> (401) 284-1840 Fax
>
> http://www.teraspeed.com
>
> Teraspeed(r) is the registered service mark of Teraspeed Consulting
> Group LLC
>
>
>
> Aubrey_Sparkman@xxxxxxxx wrote:
>   
>> Lee,
>>
>> So you think the only reason someone would not do what you consider 
>> proper analysis is because they are lazy?=20
>>
>>
>> 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: 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.=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=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=20 
>>> [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=20 
>>> [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. =20
>>>       
>
>   
>>> 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. =20 
>>>> 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
>>>>
>>>>
>>>>         
>
>   


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