[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 12:55:44 -0400 (EDT)

Scott,

 

When we fill in the details of the package interconnect model we need to
take this into account. In the example we know Terminals (1,4) (2,5) and
(3,6) are "connected", and from the IBIS model we know which Pin (and
therefor Pad) are Tx, Rx, or IO. In this case, DQ are IO but always are
FEXT, although one can certainly have cases (e.g. a controller) where
there can be NEXT coupling. I know there are cases where some of the
aggressor terminals a earmarked for FEXT coupling and some for NEXT
coupling.  I have added an example which demonstrates one way this can be
done.

 

Walter

 

(sdram

  (DQ  | Signal interconnect - all DQ the same, one victim, 2 aggressors

    (Tstonefile_File (Corner DQ_typ.s6p DQ_min.s6p DQ_max.s6p))

    (Terminals  

      (1 (Pin (Model DQ)(Aggressor 1)) 

      (2 (Pin (Model DQ)(Victim 1)) 

      (3 (Pin (Model DQ)(Aggressor 2)) 

      (4 (Pad (Model DQ)(Aggressor 1)) 

      (5 (Pad (Model DQ)(Victim 1)) 

      (6 (Pad (Model DQ)(Aggressor 2)) 

)))

 

(Controller

  (DQ  | Signal interconnect - all DQ the same, one victim, 2 aggressors

    (Tstonefile_File (Corner DQ_typ.s6p DQ_min.s6p DQ_max.s6p))

    (Terminals  

      (1 (Pin (Model DQ)(NEXT 1)) 

      (2 (Pin (Model DQ)(Victim 1)) 

      (3 (Pin (Model DQ)(FEXT 2)) 

      (4 (Pad (Model DQ)( NEXT 1)) 

      (5 (Pad (Model DQ)(Victim 1)) 

      (6 (Pad (Model DQ)( FEXT 2)) 

)))

 

 

 

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

 

Walter

 

Pin and pad is not enough for me.  When a package and die interconnect
model is extracted, the type of I/O cell applied at the pad is known
(except in the case of programmable devices like FPGAs).  In the best
case, there should be a container to carry this information along,
separate from the conventional IBIS model. This is one of those "things"
that becomes lost in the full-wave model extraction process.  The Net
Names and even the Pin/Pad designation may very well be documented as
comment lines in the Touchstone file, but the purpose of the die pad is
usually lost.

 

scott

 

 

On Tue, Sep 10, 2013 at 12:30 PM, Walter Katz <wkatz@xxxxxxxxxx> wrote:

Scott,

 

Comments below:

 

Walter

 

From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Scott McMorrow
Sent: Tuesday, September 10, 2013 12:03 PM
Cc: IBIS-ATM; Randy Wolff
Subject: [ibis-macro] Re: Overview of EMD, package and on-die interconnect
IBIS Component modeling

 

Walter

 

I thought as much.  I understand the need to prioritize.  I would just
want to be sure that the most general of cases are covered.  For example,
traces could certainly be w-element type where the length is passed as a
parameter.  

 

WMK> Parameter passing is supported when a model references an IBIS-ISS
subckt.

 

But I'd also want to be sure that trace libraries could be pointed to by a
table with discrete length to file pointers.

 

WMK> IBIS-ISS supports .include. So the include file can either be
specified in the subckt, or can be passed in as a parameter.

 

There should be no limitation to the size of models

 

WMK> There is no such limitation.

 

Victim and Aggressor designations should be optional.  In fact, I would
argue that Tx-side and Rx-side designation is more important and
universal.  An appropriate worst case victim can be determined
algorithmically.

 

WMK> The "(Terminal" branch indicates which terminals are Pin and which
are Pad, so I believe this is covered.

 

Ports should have Tx-side and Rx-side designations for automated
determination of port assignments for NEXT/FEXT/PSXT configuration, and/or
for checking against assigned die models.

 

WMK> The "(Terminal" branch indicates which terminals are Pin and which
are Pad, so I believe this is covered. Although we can add another leaf to
the terminal with such an indication.

 

 

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

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





 

-- 

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





 

-- 

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