FreeLists / si-list / [SI-LIST] Re: matching within 1 mil

[Scott McMorrow <scott@xxxxxxxxxxxxx>]

Precisely!
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



Alan Hilton-Nickel wrote:
> Maybe this is gilding the lily, but I think the major objection to 
> extreme matching constraints is the perception that they are applied 
> instead of doing a thorough analysis, and that such tight matching in 
> the absence of analysis gives a false sense of security.  Like the old 
> joke says, it's like peeing in a dark suit - it gives you a warm 
> feeling, but no-one notices.
>
> The experience on this board indicates that if your timing is so tight 
> that such matching is "required", you have serious issues. If you do 
> apply such extreme constraints (even if it's "free" insurance), you 
> need to review that layout (and your timing budget) to ensure you 
> haven't caused more problems than you've solved.
>
> Whenever someone tries to sell me "free" insurance, I have to wonder 
> how much it's going to cost. :-)
>
> Alan
> (who is confident that we ALL do our homework!)
>
> .
> steve weir wrote On 06/04/07 12:23,:
>> Jack I think we are pretty close.  Please see in-line comments.
>>
>> Regards,
>>
>>
>> Steve.
>> Jack Olson wrote:
>>   
>>> Yes, I agree.
>>> I just thought two things about this discussion were humorous:
>>>
>>> 1) complaining that a designer is giving better performance than you asked
>>> for,
>>> not believing him when he says it is no extra trouble, and wanting to
>>> "educate" him because of it
>>>   
>>>     
>> While I suppose one could read it that way, I did not.  I read it as not 
>> understanding how such tight matching could be as easy as the designer 
>> says, and pondering how to educate the designer as to what really 
>> matters.  Maybe I read too much into it.
>>   
>>> 2) complaining that a constraint should be set looser because the inherent
>>> error is looser.
>>> If the router says they match EXACTLY and you take the time to measure a pad
>>> width and discover it is really off by 2mils, setting a rule for 500mils is
>>> still going to have a range of error about the same. So what is the harm in
>>> letting the router shoot for perfection? All you will get is the inherent
>>> error and no slop.
>>>   
>>>     
>> Well, that is sort of a yes and no.  Way back at the start of this when 
>> Bill Owsley offered up that his guys are delivering this ultratight 
>> physical match I noted that if it is free which to me means no adverse 
>> costs or side effects, great.  I hold to that.  Only Bill is in a 
>> position to know if that is really true or not for his designs. 
>>
>> In the case where the lines were are pretty straight and parallel, with 
>> teensy weensie little bends to make the adjustments, then I'll agree 
>> that setting a tighter physical match will yield a closer electrical 
>> match for the reasons you state.  However, that's kind of atypical.  
>> Where the tool puts meanders, and what they look like can just as easily 
>> introduce real skew as reduce it.  I don't know of any tools that are 
>> smart enough yet to do what we really want which is to match phase right 
>> down the entire path.  Even if they could, given current materials and 
>> processes, the value would still be quite limited.  In an inch run a 
>> 10mil match is 1%.  But you've got to work hard to keep material 
>> anisotropy from being twice that.  In a more typical three inch run, 
>> 10mils is 0.3%, while the material anisotropy is pushing you out 2%-6%.  
>> The incremental value of 10mils to 20mils in such a case is very slight, 
>> and that presumes the former example as opposed to the more common 
>> circumstances.    So, I submit that if one is really trying to fit that 
>> extra angel or two on the head of a pin, that person needs to do a lot 
>> more than just tell the tool to match to 10 mils, 1 mil or what have you.
>>
>>   
>>> All I'm saying is, if it is important enough to mention that you want a
>>> match within 500mils, you shouldn't complain if the router gives you less
>>> than 100. silly.
>>>   
>>>     
>> I absolutely agree.  Just it pays to see what the tool is doing to get 
>> you there.  You may well find that loosening the length match, but 
>> tightening the channel area yields better results.  "Set and forget" is 
>> OK for modest performance requirements.
>>   
>>> but on a tight design where the router is struggling to give you what you
>>> asked for (which is USUALLY the case),
>>> your points are right on. (the "if its no trouble" phrase is the key)
>>>
>>> ok, back to "lurking" mode,
>>> Jack
>>>
>>>
>>> On 6/4/07, Scott McMorrow <scott@xxxxxxxxxxxxx> wrote:
>>>   
>>>     
>>>> Jack
>>>>
>>>> Unfortunately, the things that an autorouter does to "easily" route to 1
>>>> mil trace matching can sometimes end up with a solution that has more real
>>>> delay than a larger constraint might.  I have no problem letting the
>>>> autorouter do it's absolute best.  But I find, more often than not, after
>>>> looking at 100's of designs, that autorouters have a tendency to do some
>>>> really wacky things that frak the electromagnetics around pins and pads.
>>>>
>>>> One of the things that autorouters do not innately know, is that for
>>>> differential pairs, matching should be accomplished incrementally across 
>>>> the
>>>> entire pair length, not as something that occurs only at one of the ends.
>>>> Invariably, if the router performs matching at the ends, where it is 
>>>> easier,
>>>> 1/2 of the time, it will be on the receiving end, which is the worst place
>>>> to perform matching, since it guarantees that a common mode signal will
>>>> propagate across the entire path length.
>>>>
>>>> When it comes to wide bus matching, I've seen Mentor's lost-Expedition
>>>> router do some wonderfully "clever" serpentines and jogs to achieve
>>>> matching, that are absolutely guaranteed to create 10's of ps of delay.
>>>>
>>>> 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(r) is the registered service mark of
>>>> Teraspeed Consulting Group LLC
>>>>
>>>>
>>>>
>>>> Jack Olson wrote:
>>>>
>>>> I don't know what software you use, but
>>>> in Mentor's AutoActiveRE constraint editor,
>>>> its easier to type "1" than it is to type "100"
>>>> That's two less keystrokes, bub!
>>>>
>>>> Do all the math you want, but if the router
>>>> can EASILY route to a tighter constraint,
>>>> LET IT.
>>>> If it has trouble, THEN you can loosen the belt.
>>>>
>>>> It doesn't really seem worth "venting" about.
>>>>
>>>> If anyone has constructive ways of educating
>>>> engineers not to out-think a computer, I'd like
>>>> to hear them
>>>>
>>>> regards,
>>>> Jack (a layout guy)
>>>>
>>>>
>>>> On 6/3/07, Bill Wurst <billw@xxxxxxxxxxx> <billw@xxxxxxxxxxx> wrote:
>>>>
>>>>
>>>> <snip>
>>>>
>>>> Today, we now have some interfaces where 100mils is no longer adequate.
>>>> I know that because I take the time to go through the math, and will
>>>> specify what I believe is appropriate given all of the other variations
>>>> that can affect skew.  Here in lies the frustration:  more often than
>>>> not, the layout designer will come back and say to me, "I know you only
>>>> needed this matched to XXmils, but it was just as easy for me to match
>>>> it to 1mil, so that's what I did."  Now, I have a hard time believing
>>>> that it didn't involve a lot of extra work to get down to 1mil, but I'm
>>>> not about to do his job for him nor do I wish to micro-manage him.  In
>>>> all other respects, these folks are excellent at what they do, but this
>>>> typical response makes me wonder why I went through the trouble of
>>>> figuring out a more practical number in the first place.  Judging from
>>>> the various responses, I'm not alone.  And I know that while the tool
>>>> reports the lengths as matching to within 1mil, there may be as much as
>>>> a few mils difference within the pad itself.  I know because I've sat
>>>> down with designers and together we've discovered this.  (As an aside,
>>>> it would be nice if CAD tools could report trace length minus the trace
>>>> segments (or portions thereof) buried in pads.)
>>>>
>>>> Mainly I'm venting and not looking for a response, but if anyone has had
>>>> similar experiences and can think of constructive ways of "educating"
>>>> layout designers, I'd like their opinions.
>>>>
>>>> Regards,
>>>>     -Bill
>>>>
>>>>
>>>>       /************************************
>>>>      /         billw@xxxxxxxxxxx         /
>>>>     /                                   /
>>>>    / Advanced Electronic Concepts, LLC /
>>>>   /           www.aec-lab.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: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:     
>>              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
>>   
>>
>>   
>
> -- 
> Alan Hilton-Nickel
> Signal Integrity Engineer
> Sun Microsystems Inc.
> Netra Systems and Networking
> Newark, CA
>   


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