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

  • From: Scott McMorrow <scott@xxxxxxxxxxxxx>
  • Date: Tue, 10 Sep 2013 12:02:55 -0400

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.  But I'd also want to be sure that trace libraries could be
pointed to by a table with discrete length to file pointers.

There should be no limitation to the size of models

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.

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.


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

Other related posts:

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