[SI-LIST] Re: Internal package aggressors/PCB routing
- From: "Ray Anderson" <ray.anderson@xxxxxxxxxx>
- To: "si-list" <si-list@xxxxxxxxxxxxx>
- Date: Fri, 12 Jan 2007 10:07:59 -0800
Jerry-
I can't speak how other silicon vendors provide the data, but we perform
a full package extraction on all of our package designs to generate RLC
data for nets operating below about 1GHz (for MGT nets we provide
s-parameter data). We typically generate mutual coupling data for the 4
nearest neighbors since we feel that crosstalk coupling from lines more
than 4 away from the victim contribute negligible crosstalk. The L and C
mutual coupling values are available in IBIS .pkg file format as a data
item we make available for each package type. Given that data you can
simulate or calculate crosstalk voltages.
Besides the standard IBIS .pkg file format we can also provide customers
the data in a number of other formats upon request (with > 4 neighbors
coupling if desired).
-Ray
Raymond Anderson
Senior Signal Integrity Staff Engineer
Advanced Platforms Group
Advanced Products Division
Product Technology Department
Package Design Engineering
Xilinx Inc.
2100 Logic Drive
San Jose, California 95124
(408) 626-6277
=20
-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx]
On Behalf Of Jerry Martinson
Sent: Friday, January 12, 2007 9:51 AM
To: scott@xxxxxxxxxxxxx; james.f.peterson@xxxxxxxxxxxxx
Cc: si-list
Subject: [SI-LIST] Internal package aggressors/PCB routing
... several paragraphs deleted...
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.
------------------------------------------------------------------
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:
