[ibis-macro] Re: Overview of EMD, package and on-die interconnect IBIS Component modeling

  • From: "Walter Katz" <wkatz@xxxxxxxxxx>
  • To: "'Scott McMorrow'" <scott@xxxxxxxxxxxxx>
  • Date: Tue, 10 Sep 2013 11:49:53 -0400 (EDT)

Scott,

 

Thanks for the input. I believe that all of the functionality you are
using falls into the various categories that the solution I have proposed
supports. I think we all have different opinions of the priorities of the
various types of models we need to support. But, all we are debating are
our individual priorities, the bottom line (in my opinion) is we need a
solution that supports all of the types I indicated.

 

Walter 

 

From: Scott McMorrow [mailto:scott@xxxxxxxxxxxxx] 
Sent: Tuesday, September 10, 2013 9:40 AM
To: Walter Katz
Cc: IBIS-ATM; Randy Wolff
Subject: Re: [ibis-macro] Overview of EMD, package and on-die interconnect
IBIS Component modeling

 

Walter

 

Some thoughts with respect to package and on-die modeling for custom
designs.  I am working with 2 types of models in a current design.  On-die
RLC interconnect extraction for DDR signalling,which covers all of the
signal bump sites in a quadrant of a package is performed with typical
silicon tools available. In this case the RLC SPICE model is converted to
an s176p Touchstone file for ease of simulation.  To match this, the
package extraction from bump to PCB pad through the balls is also
extracted with Ansys SIwave as an s176p file, from DC to 10 or 20 GHz, at
a step size of 10 MHz.   This is in no way a unique case. I've been
creating and working with these sorts of models for quite a few years now.

 

From this, we identify the worst case victims throughout the package and
reduce the combined touchstone file to the appropriate size and low
frequency step size.  This can end up being anywhere from 1 victim line
and 2 aggressors, all the way up to 6 or more aggressors.  (if you think
about the constellation of signal balls surrounding one victim ball in
it's local vicinity you'll get the idea.)  The number of aggressors that
must be swept into a victim simulation will depend upon the level of
crosstalk resolution that is required in eye width analysis. The resulting
models can be run in conventional time domain, frequency domain, and
statistical simulators.

 

For SERDES, we do the same, but also run into "non-locality" problems.
Above 10GHz, it is quite easy to design a package that exhibits
non-locality problems, whereby crosstalk between pairs can "skip" across
the package, in a sympathetic fashion, much like tuning forks.
Unfortunately, the nearest neighbor from a crosstalk perspective might not
be next door.  As a result, the "nearest neighbor" aggressor field can
become fairly large in both number and physical area.  Simple single pair
analysis is useful for first order link analysis approximations, but is
fairly useless for determining whether a link will actually work in
system.  Even the analysis of small numbers of pairs (2,3,4) has limited
usefulness for many high performance applications.  For a robust
backplane-based system, the constellation of aggressors within both
packages, all via fields, and both connectors, along with traces must be
evaluated.  This ends up becoming a fairly interesting interconnect to
work with.  Flexibility in the modeling will be important.

 

For what-if sweep analysis, we often use ultra high resolution libraries
of trace models that have been extracted in HFSS at the high-nominal-low
impedance corners at various lengths, and saved in Touchstone s-parameter
format.  These are used along with smaller HFSS extractions of die bump
and ball areas, along with connector via fields, to form the basis for
sensitivity sweep simulations.  Incorporating enough aggressors to model
the crosstalk profile of the link in the face of channel resonances is
extremely important for robust designs.

 

Finally, the ability to model variable skew (for laminate weave) at
various interconnect segments within the design is important in the final
end-to-end link evaluations, since skew affects not only insertion loss,
but also the signal-to-noise ratio adversely, due to common mode to
differential crosstalk conversion.  This can cause up to a 3:1 decrease in
SNR, when compared to the common mode conversion seen with skew on just
insertion loss.

 

Do not disregard the possibility of having models large enough that all
major signal paths can be characterized in simulation.  Then, it is not
necessary to "know" the victims and aggressors.  All signals can be
considered either victims or aggressors, as long as the original
extraction process does not truncate the physical model abruptly at the
edges.  It is a fairly straightforward procedure to then scan a huge
interconnect model and algorithmicly determine the appropriate aggressors
for each and every victim, and determine the absolute worst case system
paths w.r.t. specific criteria such as crosstalk, loss, ICR ... etc.

 

Today these sorts of models are custom, used in-house at a few advanced
OEMs and semiconductor manufacturers, or in my house.  However, support
for these sorts of studies and model order reductions would most likely
trickle down to better models available for the majority of users. 

 

 

regards,

 

Scott

 

 

 

 

On Tue, Sep 10, 2013 at 7:19 AM, Walter Katz <wkatz@xxxxxxxxxx> wrote:

All,

 

I am enclosing a presentation (based on one given to the IBIS Open Forum
on March 15) updated with the status of discussions in the IBIS Packaging
committee of applying EMD methodology to package and on-die interconnect
IBIS Component modeling.

 

Walter

 

Walter Katz

wkatz@xxxxxxxxxx

Phone 303.449-2308

Mobile 303.335-6156

 





 

-- 

Scott McMorrow
Teraspeed Consulting Group LLC
16 Stormy Brook Rd
Falmouth, ME 04105

(401) 284-1827 Business

http://www.teraspeed.com

TeraspeedR is the registered service mark of
Teraspeed Consulting Group LLC

Other related posts:

  1. Home
  2. ibis-macro
  3. Archive
  4. 09-2013