Re: EGG 1.0 (Package models)

All,

During the last meeting, a number of good ideas were offered for a
package model specification. I'll try to summarize what I heard; if I
forgot something, or if anyone wants to add anything or discuss this
some more, please speak up!

--Eric Bracken (bracken@performance.com)

Package Model Desiderata:
------------------------

1) Re-usability: several different parts may be shipped in the same
    "package". In this case it's desirable not to have to repeat the
    package information in every IBIS file (especially not if that
    information takes up a lot of space...)

    This argues for a special [Package_Model_File] keyword in the IBIS
    deck which is used to indicate the name of a separate file containing
    the package model. One thought is to give these files the extension
    ".pkg".

    The only problem here, as someone pointed out, is how to ensure that
    all of the necessary files get transmitted to the user. ('tar' and
    'pkzip' seem like good solutions...)

2) Support for Several Incarnations of the Same Part: A single IC may
    also be shipped in several DIFFERENT packages. Again, it seems like
    a good idea to have separate .pkg files so that IBIS "components" with
    the same nonlinear characteristics can reference different pkg models.

    One question here is whether or not the NONLINEAR part of the model
    has to be duplicated. I think the answer is "no", since the IBIS
    "models" are global to an entire file. If all of the various
    versions of the same part are described in the same IBIS file, then
    the I-V models only need to be specified ONCE, and then re-used by
    several different "components".

    Anybody know how practical this would be? For instance, would the
    tendency be for the IC vendor to ship an IBIS file containing the
    SMT, Plastic PGA, and Ceramic PGA versions of the Frotz-9000 CPU, or
    would they be more likely to ship out one library for all their
    surface-mount IC's, and another for all the DIP/PGAs, etc.?

3) Completeness: it may be necessary to specify ALL of the mutual
    inductive, capacitive and resistive couplings between EVERY pair of
    pins. Symmetry ensures that only the half of the matrix above (or
    below) and including the main diagonal needs to be provided. But
    even so, this could be a BIG file... (100 pins -> ~150 Kbytes).

4) Multiple representations: in cases where the vendor (or the user)
    wants a quicker, dirtier simulation and doesn't want to specify ALL
    the couplings, both a banded-matrix or a sparse-matrix representation
    can be used to make the package model file a LOT smaller. It would
    be nice to give the modelling engineer different options for specifying
    the package model.

Did I miss anything?
Received on Mon Feb 7 14:37:58 1994