Package descriptions--Take 1

  Dear Friends of IBIS:

  I've been considering how we can address the package problem. I've
written down some of my thoughts here, with the hope that this will
generate some useful discussion.

  As you'll recall, the current Version 1.1 spec has a fairly simple
package/die model consisting of:

                           Rpin Lpin
                          +-----+ +-----+
           +---------+----| |--| |---+----> to board
           | | +-----+ +-----+ |
       +---+---+ | |
       | i-v | ----- -----
       | curve | ----- -----
       +---+---+ | Ccomp | Cpin
           | | |
           V V V

        (on-chip grounds?) (off-chip ground?)

TRANSMISSION LINES vs. LUMPED MODELS:

  There's been some question about what to do with the Rpin/Lpin/Cpin;
whether to lump them, and if so into how many lumps; or to model them
as (lossy) transmission lines. The transmission line models are
questionable, for the following reasons:

  The basic assumption in the transmission line model is that there's a
TEM wave propagating along the structure, which requires TWO
conductors to support it--one for the signal, and another to act as
the "return" path. A trace on a board presumably has a nice ground
plane nearby. A wire in the lead frame may too, IF the package
contains its own power/ground planes. But in the case of a bond wire
or a pin, there's no return path paired with it. You could select
another bond wire as the "return", but then the situation is so
3-dimensional that the transmission line approach is hopeless anyway.

  A lot of special cases begin to come up. IF the package contains
power/ground planes, THEN use transmission lines, ELSE use lumped
models for the lead frames. Even if transmission lines are used, you
might still want to have lumped caps/inductances at either end to
model bond wires and pins. Another question is what to do with the
"tapering" of the transmission lines and their coupling to one another.
It seems unlikely that we could standardize easily on a model.

LUMPED PACKAGE MODELS

  In order to model simultaneous switching noise ("ground bounce," etc.)
it becomes necessary to have not only pin inductance/capacitance, but
also MUTUAL inductances and coupling capacitances between pins.
Depending upon how aggressive the modelling engineer wants to be, and
on how high-speed the design is, the number of such mutuals/coupling C's
can become very large. Also, a single "connection" might be broken up
into separate inductance elements to model the individual characteristics
of bond wire, package trace, and pin. This increases the number of
internal nodes in the package.

  The complexity of the resulting model rapidly approaches the point
where it can only be described by something like a Spice deck. This is
fine with me, but I doubt that everybody feels this way. So I've tried
to come up with a fairly simple package description which is based upon
SPICE, but includes additional COMMENT-BASED information to make the
parsing easier.

  The way I envision the ".pkg" file is that it would start with a
"declarations" section (in SPICE's *-comments) where the modelling
engineer would declare (strictly in the following order):

1) the set of node names used in the package model;

2) the set of inductance names used

(The point of declaring things this way is to make the parsing as easy as
possible. No need to do 2 passes.)

  Following the declarations, there would be a regular SPICE section
containing the R, L, C, and K (mutual inductance) element values.
I would recommend that we enhance the SPICE syntax a little bit;
we could permit inductances to have a resistance loss value specified
in addition to the self-inductance. This would help to cut down on
the number of the nodes in the package model. (You very often see series
R-L combinations; the "internal" node between the two is really of no
interest to anyone.)

  The format described here is general enough to permit "mutual
resistances" as well, which are used by some crazy packaging modelling
programs. The mutual resistances could be an additional parameter in
the K card.

  If there are no couplings, then the package model is equivalent to
what we have in IBIS already, although admittedly it would be
specified in a different way. I tend to think that if the ".pkg"
file is specified, the simulator will simply ignore whatever Rpin, Lpin,
and Cpin values are specified in the main ".ibs" file. These
values would STILL BE AVAILABLE to do less detailed simulation.

  The package model would be similar to Spice's "subcircuits"--there
would be a set of ports connecting the internal package junk to the
IBIS I-V curves on the inside, and also to the board on the outside.
We'd need a name convention for those port nodes, but I think this
isn't a problem.

  As I've said, I hope these musings inspire some useful discussion
on this subject.

--Eric
Received on Fri Oct 1 08:45:38 1993