[SI-LIST] Re: matching within 1 mil

  • From: Alan Hilton-Nickel <Alan.Hiltonnickel@xxxxxxx>
  • To: weirsi@xxxxxxxxxx
  • Date: Mon, 04 Jun 2007 13:10:24 -0700

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

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