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

  • From: Scott McMorrow <scott@xxxxxxxxxxxxx>
  • To: Walter Katz <wkatz@xxxxxxxxxx>
  • Date: Tue, 10 Sep 2013 12:38:06 -0400

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
>
> Teraspeed® 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
>
> Teraspeed® 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

Teraspeed® is the registered service mark of
Teraspeed Consulting Group LLC

Other related posts:

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