[SI-LIST] Internal package aggressors/PCB routing

  • From: "Jerry Martinson" <jmartinson@xxxxxxxxxxxxxxxxx>
  • To: <scott@xxxxxxxxxxxxx>, <james.f.peterson@xxxxxxxxxxxxx>
  • Date: Fri, 12 Jan 2007 09:50:37 -0800

Scott,

You said in the SI-LIST Hyperlynx vs. Signal Explorer thread:

>I've worked with quite a few cases where reverse crosstalk was already=20
>saturated within the package.  It did literally did not matter what you

>did to trace spacing externally, if you kept the same aggressors as in=20
>the package, you couldn't produce any more timing jitter. In fact,
since=20
>the reverse crosstalk in the package reflected off the drivers during=20
>the transition edges, it was an even larger impediment than any reverse

>crosstalk on the board, which was not time correlated with the edges.

Current IO signaling standards are often de-rated to account for
"reasonable" amounts of "random" noise in the package.  However, as you
know, much of this "random" noise isn't really "random" at all but
crosstalk between specific aggressors and specific victims in the
package.  Right now, the problem of our industry failing to accurately
account and optimize (by keeping aggressor/victim pairs the same in the
package as on the PCB) for this is handled by requiring excessive
margin.  Requiring margin where it's not really needed may reduce the
amount of analytical work we have to do but it is wasteful and sand-bags
the system performance/cost.

I've often wondered how to effectively request a list of internal
aggressors for each victim pin from component vendors.  Most have no
idea what you're asking for when you request this since most package
designers are even less aware of the concept of saturation than most PCB
designers.  Those that do understand it often don't have the script
writing skills to effectively handle this for packages with hundreds of
pins so it is kind of written off as an impractical optimization method.

It would be nice if there's some standard way of presenting this
information to us board designers as we could get a lot more
margin/flexibility/density on our boards if we had this information as
we could then route on the PCB those nets that are already mostly
saturated together.  If the pin-by-pin internal package crosstalk is in
a standardized format, we could then automate generation of better
net-by-net prescriptive routing clearance rules and we could automate
generation of better net-by-net crosstalk checks on the actual routes
post-layout.

On high-volume components targeting high-volume boards, component
vendors already often take some time up front in working the pinout to
minimize the required PCB routing layers by doing trial PCB maze routes.
Having them go through the exercise of considering the combining package
crosstalk with PCB crosstalk would probably go a long way to improving
system signal integrity.

















-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx]
On Behalf Of Scott McMorrow
Sent: Thursday, January 11, 2007 12:19 PM
To: james.f.peterson@xxxxxxxxxxxxx
Cc: si-list
Subject: [SI-LIST] Re: Hyperlynx vs. Signal Explorer

Jim
The reality is that with 100 ps of margin you may already be SOL.  Most=20
board level signal integrity tools do not take package crosstalk, SSI,=20
SSO and power bounce effects into consideration ... and the=20
manufacturers often do not derate their timing to account for this
either.=20

I've worked with quite a few cases where reverse crosstalk was already=20
saturated within the package.  It did literally did not matter what you=20
did to trace spacing externally, if you kept the same aggressors as in=20
the package, you couldn't produce any more timing jitter. In fact, since

the reverse crosstalk in the package reflected off the drivers during=20
the transition edges, it was an even larger impediment than any reverse=20
crosstalk on the board, which was not time correlated with the edges.

Oh, and don't get me started on I/O power system resonance phenomenon at

exceedingly high single-ended bus speeds.  No amount of conventional=20
board level SI simulation will even acknowledge that a problem exists. =20
But you should watch how we can make parts sing and dance in the lab.


best 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(r) is the registered service mark of
Teraspeed Consulting Group LLC




------------------------------------------------------------------
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 FAQ wiki page is located at:
                http://si-list.org/wiki/wiki.pl?Si-List_FAQ

List technical documents are available at:
                http://www.si-list.org

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: