EGG for Transmision Line Package Models

Hello All:

     In this egg I am proposing a method of describing the electrical
characteristics of the connection between the die pad and the PCB or
other medium the package is mounted to. Specifically, I would like to
describe this connection (referred to as the package 'stub') as one or
more elements in series. These elements include lumped inductances/
capacitances/resistances, uncoupled transmission lines, or coupled
transmission lines. Refer to figure 1 below (it will be used as an
example throughout this discussion).

                     Bondwire Package Trace
     ----------------@@@@@@@@--ZZZZZZZZZZZZZZZZZZZZZZZ
     | DIE | ||
     -------------- || Pin
                                                     ||
     
                       Fig 1 -- A Simple(?) Package

     There are a couple of things to note about the typical package as shown
in Figure 1. The most obvious is that a package stub is made up of several
different elements, and these elements can be modeled in different ways.
For example, the bondwire can be represented by a lumped inductor or a
high impedance transmission line segment. The package trace itself is
analogous to a PCB trace and can be described using the same parameters
(length, Zo, trace velocity) as a PCB trace. In addition, depending on
package construction or the absence of a ground plane in the package,
package traces may exhibit significant coupling between themselves and
nearby traces. Likewise, the pin itself can be represented as a lumped
inductor or capacitor.
     As the IBIS spec stands now it cannot describe the above package
stub as anything other than a lumped L, R and C. Without any
length (or L and C per unit length) information the delay and Zo
characteristics of the stub cannot be modeled. Furthermore, even though
the IBIS '.pkg' file does allow one to describe the coupling between pins,
it is (again) lumped information without regard to length or the fact that
different sections have different coupling. The proposed expansion
of the '.pkg' file description allows both 1) a package stub to be
described as a series of sections made up of different types of electrical
elements and 2) a per unit length description of the L and C information of
each section. The proposed changes also allow the complete elimination of the
matrix information if coupling descriptions are not required.

SECTION AND LENGTH INFORMATION:
1. The first enhancement is to add the keyword [Number of Sections]. This
keyword occurs before the [Pin number] keyword, and describes the
number of sections (or elements) a package stub is divided into. It is
a positive integer greater than zero. Using figure 1 above as an example:

[Number of Sections] 3

2. The second change is to the [Pin number] keyword. Currently, this
keyword simply denotes a list of pins numbers and their order.

[Pin Number]
A1
A2
.
.
.
A10

The proposal is to add to the pins listed by this keyword the per unit
length L/R/C information for each section of the package stub. This
information would be listed as follows.

[Pin Number]
A1 Len:0 L: 1.5n, Len: 0.7 L: 8.35n C: 3.34p R: 1.8, Len:0 C:2.0p
A2 Len:0 L: 1.5n, Len: 0.4 L: 8.35n C: 3.34p R: 1.8, Len:0 C:2.0p
.
.
.
A10 Len:0 L: 1.5n, Len: 1.0 L: 6.0n C: 2.5p R: 1.8, Len:0 C:2.0p

     After each pin number comes the physical length of the first
section (Len:), then the section's per unit length L/R/C. The Len:
parameter is optional, as well as the L/R/C parameters (you'll see why
in a moment). If the Len: parameter is missing or it's value is '0', then
treat the listed L/R/C as a lumped element. Each section description is
separated by a comma.
     At this point we have all the information required to describe our
simple package example (assume for the moment we are not concerned about
coupling between pins or package traces). In our example the bond wire
is described as a lumped inductor, the package trace is described as a
transmission line with DC loss, and the pin is described as a capacitor.
Note that the information is presented in a straight forward and 'natural'
form; length and the basic parameters of L, R and C. And, since the matrix
description is not required...

3. The matrix information now becomes optional. In other words,
the [Model Data], [End Model Data] and the keywords in between are now
optional and the package description can end with the [Pin Number] keyword.
This may seem radical, but for most IBIS users this makes the whole
'.pkg' file concept a lot friendlier and usable.

COUPLING:
     Suppose now we DO wish to describe the coupling between package
traces. The matrix format is used, but we need some way to let
the simulator know that it applies to section 2 of our stub. The
proposal is to add a 'section' argument to the [Model Data] keyword.

[Model Data] Section 2

     The section argument is followed by a positive integer that refers to
one of the sections defined in the [Pin Number] keyword above. Note also
that, once a particular section of stub is described using a matrix, the
'self' L/R/C values are included in the matrix and do not need to be
repeated in the [Pin Number] statement. This is why the L/R/C values in
the [Pin Number] statement are optional even if a Len: is specified.
     All the matrix types that have been defined so far are used as
needed -- the only difference is that now they apply to a section of
specific length, and the values in the matrix are given as per unit length.
There can be multiple [Model Data]/[End Model Data] keyword per package
description.

SUMMARY:

In summary, the enhancements are as follows:

     1. Adding the keyword [Number of Sections]
     2. Adding Length and L/R/C info to each pin in the [Pin Number]
         keyword
     3. Making the matrix information optional
     4. Adding the argument 'Section' to the [Model Data] keyword

     There is one more issue that may arise. If one has a lot of sections
in a package stub, the description for each pin could run over the 80
character limit. Because of the difficultly distinguishing between a pin
number and parameter value, simply allowing a carriage return in the
middle of a line may not work. I propose adding the requirement that
pin numbers MUST start in column one. If a line is long enough to require
a continuation line then the continuation line begins with whitespace.

     Since this is an egg, (and a big one at that) I did not try and
formally describe each keyword and the exact rules for usage. Also,
there are some fundamental technical points about deriving the data for
the matrixes that need to be defined by the forum. I am saving that topic
for a second egg, after this one has had a chance to digest.

      Best Regards,
      Stephen Peters
      Intel Corp.
Received on Fri Apr 21 23:06:38 1995