Bird 10.1

All,

 Included below is the revised version of Bird 10. It incorporates
some changes that were discussed at the last meeting, regarding the
ability to put package models EITHER in the .ibs file or in the .pkg
file. Also included is specific language which permits alphanumeric
pin names and "suffix" notation for numbers.

 I've also included notes about the definition of signs for currents
and voltages, on scope rules for package model definitions, about
what's allowed and not allowed in a .pkg file, etc.

 If you have access to "diff" and the old version of the BIRD, that
might be an efficient way to evaluate this revision.

================================================================
 Eric Bracken
 Performance Signal Integrity, Inc.
================================================================

*******************************************************************************
*******************************************************************************

                       Buffer Issue Resolution Document (BIRD)

BIRD ID#: 10.1
ISSUE TITLE: Describing coupling effects in package models (revised)
REQUESTOR: Eric Bracken, Performance Signal Integrity, Inc.

DATE SUBMITTED: 17 March 1994
DATE REVISED: 17 April 1994
DATE ACCEPTED BY IBIS OPEN FORUM: {status or date BIRD accepted}

*******************************************************************************
*******************************************************************************

STATEMENT OF THE ISSUE:

  For a more thorough signal integrity analysis, a mechanism is needed
for describing electromagnetic couplings between the different pins of
a package.

*******************************************************************************

STATEMENT OF THE RESOLVED SPECIFICATIONS:

Summary:
-------

A new keyword, [Package Model], is added to the .ibs file. This
keyword is used within a [Component] to indicate (by name) the package
model that should be used for a part. Package models can be found
either in separate package model files, which bear the .pkg extension,
or within the same .ibs file as the [Component]. An additional new
keyword, [Define Package Model], is also added to the specification;
this is used to mark the beginning of the actual package model data.
The purpose of breaking up the package model and the component model
is to make associations between the two more flexible: several
components may share a single package model, or one component may have
several different incarnations which use different packages (and thus,
different package models).

Use of [Package Model] is OPTIONAL. If it is not provided, then the
table of RLC values listed in the [Pin] section of the [Component] is
used as the "package model" for the part. On the other hand, if the
[Package Model] IS given, then the R_pin, L_pin and C_pin values in
the [Pin] section may either be ignored, or may be used for less
detailed simulations without coupling. Probably this data will simply
be left out of the [Pin] section when a [Package Model] is used;
this practice is permitted by the IBIS Ver. 1.1 specification since
[Pin] data may contain either 3 or 6 columns.

A .pkg file is just an ordinary IBIS file, with the restriction that
it cannot contain [Component]'s or [Model]'s. Only package models
declared by the [Define Package Model] keyword may be contained within
these files. Of course, all of the necessary components of an IBIS
file ([IBIS Ver], [File Name], [File Rev], etc. through [End]) must
still be included within a .pkg file.

The package model to be used treats every package as a collection of
current carrying "paths," which lead from the board, through the
packages pins, leadframe traces and bonding wires to a bonding pad on
the die itself. Each path has a self-resistance, self-inductance and
self-capacitance associated with it. In addition, there is the
flexibility to describe mutual inductance, mutual resistance and
coupling capacitance drops between every path. This data can be
listed concisely as three RLC parameter matrices. This BIRD describes
how these matrices are to be formatted.

I. Syntax for the .IBS File.
----------------------------

The following syntax is used for specifying a package model:

|==============================================================================
|
| Keyword: [Package Model]
|
| Required: No
|
| Description: Used to indicate the name of the package model
|
| Usage Rules: The Package_Model_Name is limited to 40 characters.
| Spaces are allowed in the name.
|
|------------------------------------------------------------------------------
|
[Package Model] Package_Model_Name

The [Package_Model] keyword is used within a [Component] to indicate
which package model should be used for that part.

The resolved specification permits .ibs files to contain [Define
Package Model] keywords as well. These are described in Section II,
"Syntax for the .PKG file", below. When package model definitions
occur within a .ibs file, their scope is "local"--they are known only
within that .ibs file and no other. In addition, within that .ibs file,
they override any globally defined package models which have the same
name.

II. Syntax for the .PKG File
-----------------------------

Package models are stored in a file whose name looks like

        <filename>.pkg

The <filename> provided must adhere to the venerable MS-DOS file name
conventions: it must not exceed 8 characters in length. All of these
characters must be lower case. The extension ".pkg" is used to
identify files containing package models.

The .pkg file must contain all of the Required elements of a normal
.ibs file, including [IBIS Ver], [File Name], [File Rev], and the [End]
keywords.

Optional elements include the [Date], [Source], [Notes], [Disclaimer]
and [Comment char] keywords.

All of the above elements follow the exact same rules as those for a
normal .ibs file.

Items which are FORBIDDEN in the .pkg file are [Component] and [Model]
keywords. The .pkg file is only for package models.

A. Package Models
------------------

Each package model is preceded by the [Define Package Model] keyword.

|==============================================================================
|
| Keyword: [Define Package Model]
|
| Required: Yes
|
| Description: Used to mark the beginning of a package model description.
|
| Usage Rules: If the .pkg file contains data for more than one package,
| each section must begin with a new [Define Package Model]
| keyword. The length of the Package_Model_Name must not
| exceed 40 characters in length and blank characters ARE
| allowed.
|
|------------------------------------------------------------------------------
|
[Define Package Model] Package_Model_Name

The [Manufacturer] keyword is used to declare the manufacturer of
the part(s) which use this package model. This would typically
be the name of the semiconductor vendor. The syntax is identical
to that of the [Manufacturer] keyword in the .ibs file, e.g.

[Manufacturer] Bozonics Semiconductors Ltd.

An additional optional keyword, [OEM], is used to indicate the name of
the PACKAGE's manufacturer. This is useful if the semiconductor
vendor sells a single IC in packages from different manufacturers
(e.g. AMP, Kyocera). The [OEM] keyword's syntax is analogous to that
of the [Manufacturer] keyword.

[OEM] Pkgs'R'Us

The [Description] keyword is used to indicate to a human being what
the model is describing.

|==============================================================================
|
| Keyword: [Description]
|
| Required: Yes
|
| Description: This is used to provide a concise yet easily human-readable
| description of what kind of package the [Package_Model]
| is representing. An example Description_Text might be:
| "220-Pin Quad Ceramic Flat Pack".
|
| Usage Rules: The description must be less than 60 characters in length,
| must fit on a single line, and MAY contain spaces.
|
|------------------------------------------------------------------------------
|
[Description] Description_Text

The [Number of Pins] keyword identifies how many pins the package has.

|==============================================================================
|
| Keyword: [Number of Pins]
|
| Required: Yes
|
| Description: This is used to tell the parser how many pins to expect.
|
| Usage Rules: The How_Many field must be a positive integer less than 60
| characters long.
|
|------------------------------------------------------------------------------
|
[Number of Pins] How_Many

The [Pin Names] keyword is used to list the names of the pins of the
package, and to define an "ordering" among them. If the integers 1,
2, 3, ... are used as pin names, then the ordering is probably the
obvious one. However, this is not the case when alphanumeric pin names
are used. Since the ordering is very important for the RLC matrix
information to be described shortly, we require that it be made
explicit before those matrices are given.

|==============================================================================
|
| Keyword: [Pin Names]
|
| Required: Yes
|
| Description: This is used to tell the parser the set of names that
| will be used for the package pins, and to define an
| ordering of them. The first pin name given is the
| "lowest" pin, and the last pin given is the "highest."
| The pin names may not exceed 5 characters in length.
|
| Usage Rules: Following the [Pin Names] field, the names of the pins are
| listed. There must be as many names listed as there are
| pins (as given by the preceding [Number of Pins].)
|
|------------------------------------------------------------------------------
|
[Pin Names]
|
A1
A2
| .
| .
| .
A22
B1
| .
| .
| .
| etc.

The beginning of the actual model data is marked with the [Model Data]
keyword.

|==============================================================================
|
| Keyword: [Model Data]
|
| Required: Yes
|
| Description: This is used to indicate the beginning of the formatted
| model data.
|
| Usage Rules: This is pretty simple.
|
|------------------------------------------------------------------------------
|
[Model Data]

Similarly, the end of the model data is marked with an [End Model Data]
keyword:

|==============================================================================
|
| Keyword: [End Model Data]
|
| Required: Yes
|
| Description: This is used to indicate the end of the formatted
| model data.
|
| Usage Rules: This is pretty simple too.
|
|------------------------------------------------------------------------------
|
[End Model Data]

In between these two keywords is the package model data itself.
The data to be supplied is a set of 3 matrices: the resistance (R),
inductance (L), and capacitance (C) matrices. Each matrix may be
formatted differently (see below). A special keyword is used to
mark the beginning of each new matrix:

|==============================================================================
|
| Keywords: [Resistance Matrix], [Inductance Matrix], [Capacitance Matrix]
|
| Required: [Resistance Matrix] is optional. If it's not present, its
| entries are assumed to be zero. [Inductance Matrix] and
| [Capacitance Matrix] are required.
|
| Description: These are used to mark the beginning of a matrix, and to
| specify how the matrix data will be formatted.
|
| Usage Rules: There are 3 choices for the Format_Keyword:
| Banded Matrix, Sparse Matrix, and Full Matrix.
|
| After each of these keywords, the matrix data will follow
| in the appropriate format.
|
| These formats are described in detail below.
|
|------------------------------------------------------------------------------
|
[Resistance Matrix] Format_Keyword
[Inductance Matrix] Format_Keyword
[Capacitance Matrix] Format_Keyword

C. Matrix Formats
------------------

For each [Resistance Matrix], [Inductance Matrix], or [Capacitance
Matrix] a different format may be used for the data. The choice of
formats is provided to satisfy different simulation accuracy and speed
requirements. Also, there are many packages in which the resistance
matrix may have no coupling terms at all; in this case, the most
concise format (Banded_Matrix) may be used.

One common aspect of all the different formats is that they exploit
the symmetry of the matrices they describe. This means that the
entries below the main diagonal of the matrix are identical to the
corresponding entries above the main diagonal. Therefore, only
roughly one-half of the matrix needs to be described. By convention,
the main diagonal and the UPPER half of the matrix will be provided.

The available formats are Banded_Matrix, Sparse_Matrix, and Full_Matrix.
We describe each of the formats separately below.

In the following, we use the notation [I, J] to refer to the entry in
row I and column J of the matrix. Note that I and J are allowed to be
alphanumeric strings as well as integers. An ordering of these
strings has been defined earlier in the [Pin Names] section. The
reader is advised that the following text sometimes refers to "Row 1",
by which we mean the row corresponding to the first pin.

Also, please note that the numeric entries of the RLC matrices are
standard IBIS floating point numbers. As such, it is permissible to
use metrix "suffix" notation. Thus, an entry of the C matrix could
be given as "1.23e-12" or as "1.23p" or "1.23pF".

1. Full_Matrix

When the Full_Matrix format is used, the couplings between every pair
of elements will be specified explicitly. We assume that the matrix
has N rows and N columns. The Full_Matrix is specified one row at a
time, starting with Row 1 and continuing down to Row N.

Each new row is identified with the Row keyword.

|==============================================================================
|
| Keyword: [Row]
|
| Required: Yes
|
| Description: This is used to indicate the beginning of a new row of
| the matrix. The Row_Number field must be a pin name,
|
| Usage Rules: This is pretty simple.
|
|------------------------------------------------------------------------------
|
[Row] Row_Number

Following a [Row] keyword is a block of numbers which represent the
entries for that row. Suppose that the current row is number M. Then
the first number listed is the diagonal entry, [M,M]. Following this
are the entries of the upper half of the matrix that belong to row M:
[M, M+1], [M, M+2], ... up to [M,N].

For even a modest-sized package, this data will not all fit on one
line. Since each line of an IBIS file must be 80 characters long or
less, it is permissible to break the data up with newlines so that
this limit is observed.

An example: suppose the package has 40 pins and that we are currently
working on Row 19. There will be 1 diagonal entry, plus 40 - 19 = 21
entries in the upper half of the matrix to be specified, for 22 entries
total. The data might be formatted as follows:

[Row] 19
5.67e-9 1.1e-9 0.8e-9 0.6e-9 0.4e-9 0.2e-9 0.1e-9 0.09e-9
8e-10 7e-10 6e-10 5e-10 4e-10 3e-10 2e-10 1e-10
9e-11 8e-11 7e-11 6e-11 5e-11 4e-11

In the above example, the entry 5.67e-9 is on the diagonal of row 19.

It will be observed that Row 1 always has the most entries, and that
each successive row has one fewer entry than the last; the last row
will always have just a single entry.

2. Banded_Matrix

A Banded_Matrix is one whose entries are guaranteed to be zero if they
are farther away from the main diagonal than a certain distance, known
as the "bandwidth." Again let the matrix size be N, and let the bandwidth
be B. An entry [I,J] of the matrix will be zero if

        | I - J | > B

where |.| denotes the absolute value.

The bandwidth for a Banded_Matrix must be specified using the [Bandwidth]
keyword:

|==============================================================================
|
| Keyword: [Bandwidth]
|
| Required: Yes (for banded matrices only)
|
| Description: This is used to indicate the bandwidth of the matrix.
| The BW field below must be a nonnegative integer. This
| keyword occurs after the [Resistance Matrix], etc.
| keyword, and BEFORE the matrix data is given.
|
| Usage Rules: This is pretty simple.
|
|------------------------------------------------------------------------------
|
[Bandwidth] BW

The banded matrix is specified one row at a time, starting with row 1
and working up to higher rows. Each row is marked with the [Row]
keyword, as above. As before, symmetry is exploited: entries below
the main diagonal are never given.

The first row will only need to specify the entries [1,1] through
[1,1+B] since any other entries are guaranteed to be zero. The second
row will need to specify the entries [2,2] through [2, 2+B], and so
on. In general, for row M the entries [M,M] through [M,M+B] are
given.

Unlike the Full_Matrix, each successive row will _typically_ have the
same number of entries, except for the last few rows. When M + B finally
exceeds the size of the matrix N, then the number of entries in each row
will start to decrease; the last row (row N) will have only 1 entry.

As in the Full_Matrix, if all the entries for a particular row will
not fit into a single 80-character line, the entries may be broken
across several lines.

It is possible to use a bandwidth of 0 to specify a diagonal matrix
(a matrix with no coupling terms.) This is sometimes useful for
resistance matrices.

3. Sparse_Matrix

The final option for specifying the entries of the matrix is the
Sparse_Matrix format. A sparse matrix is expected to consist mostly
of zero-valued entries, except for a few nonzeros. Unlike the
Banded_Matrix, there is no restriction on where the nonzero entries
may occur. This is useful in certain situations, such as for Pin Grid
Arrays (PGA's.)

As usual, symmetry may be exploited to reduce the amount of data by
eliminating from the matrix any entries below the main diagonal.

An N x N Sparse_Matrix is specified one row at a time, starting with
row 1 and continuing down to row N. Each new row is marked with [Row]
keyword, as in the other matrix formats.

Data for the entries of a row is given in a slightly different format,
however. For the entry [I, J] of a row, it is necessary to explicitly
list the name of pin J before the value of the entry is given. This
serves to indicate to the parser where the entry is put into the matrix.
The proper location is not otherwise obvious because of the lack of
restrictions on where nonzeros may occur. Each (Index, Value) pair is
listed upon a separate line. An example follows. Suppose that row 10
has nonzero entries [10,10], [10,11], [10,15] and [10,25]. The
following row data would be provided:

[Row] 10
| Index Value
10 5.7e-9
11 1.1e-9
15 1.1e-9
25 1.1e-9

Please note that each of the column indices listed for any row must be
greater than or equal to the row index, because they always come from
the upper half of the matrix. When alphanumeric pin names are used,
special care must be taken to ensure that the ordering defined in the
[Pin Names] section is observed.

Also, please note that it is again necessarily the case that the N'th
row of an N x N matrix will have just a single entry (the diagonal
entry.)

D. An Example

The following is an example of a package model file following the
above specifications. For the sake of brevity, an 8-pin package has
been described. For purposes of illustration, each of the matrices is
specified using a different format.

|
|================================================================
|
[IBIS Ver] 2.0
[File Name] example.pkg
[File Rev] 0.1
[Date] 17 April 1994
[Source] fervid imaginings
[Notes] Example for a BIRD on couplings in packaging
[Disclaimer] The models given below may not represent any physically
                realizable 8-pin package. They are provided solely for
                the purpose of illustrating the .pkg file format.
                Read at your own risk. See your dentist regularly.
|
|================================================================
|
[Define Package Model] Bozo-SMT-cer-8-pin-pkgs
[Manufacturer] Bozonics Semiconductors Ltd.
[OEM] Pkgs'R'Us
[Description] 8-Pin ceramic SMT package
[Number of Pins] 8
|
[Pin Names]
1
2
3
4
5
6
7
8
|
[Model Data]
|
| The resistance matrix for this package has no coupling
|
[Resistance Matrix] Banded_Matrix
[Bandwidth] 0
[Row] 1
10.0
[Row] 2
15.0
[Row] 3
15.0
[Row] 4
10.0
[Row] 5
10.0
[Row] 6
15.0
[Row] 7
15.0
[Row] 8
10.0
|
| The inductance matrix has loads of coupling
|
[Inductance Matrix] Full_Matrix
[Row] 1
3.04859e-07 4.73185e-08 1.3428e-08 6.12191e-09
1.74022e-07 7.35469e-08 2.73201e-08 1.33807e-08
[Row] 2
3.04859e-07 4.73185e-08 1.3428e-08 7.35469e-08
1.74022e-07 7.35469e-08 2.73201e-08
[Row] 3
3.04859e-07 4.73185e-08 2.73201e-08 7.35469e-08
1.74022e-07 7.35469e-08
[Row] 4
3.04859e-07 1.33807e-08 2.73201e-08 7.35469e-08
1.74022e-07
[Row] 5
4.70049e-07 1.43791e-07 5.75805e-08 2.95088e-08
[Row] 6
4.70049e-07 1.43791e-07 5.75805e-08
[Row] 7
4.70049e-07 1.43791e-07
[Row] 8
4.70049e-07
|
| The capacitance matrix has sparse coupling
|
[Capacitance Matrix] Sparse_Matrix
[Row] 1
1 2.48227e-10
2 -1.56651e-11
5 -9.54158e-11
6 -7.15684e-12
[Row] 2
2 2.51798e-10
3 -1.56552e-11
5 -6.85199e-12
6 -9.0486e-11
7 -6.82003e-12
[Row] 3
3 2.51798e-10
4 -1.56651e-11
6 -6.82003e-12
7 -9.0486e-11
8 -6.85199e-12
[Row] 4
4 2.48227e-10
7 -7.15684e-12
8 -9.54158e-11
[Row] 5
5 1.73542e-10
6 -3.38247e-11
[Row] 6
6 1.86833e-10
7 -3.27226e-11
[Row] 7
7 1.86833e-10
8 -3.38247e-11
[Row] 8
8 1.73542e-10
|
| All done!
|
[End Model Data]
[End]

III. Note on Measurement
-------------------------

When measuring the entries of the RLC matrices, either with laboratory
equipment or field solver software, the following fact should be kept
in mind:

    Currents are defined as ENTERING the pins of the package from
    the board. The corresponding voltage drops are to be measured
    with the current pointing "in" to the "+" sign and "out" of the
    "-" sign.
             
            I1 +-----+ I2
          -----> | | <------
  board 0--------| Pkg |---------0 board
         + V1 - | | - V2 +
                 +-----+
                                
    It is important to observe this convention in order to get the
    correct signs for the mutual inductances and resistances.

*******************************************************************************

ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:

This is an attempt to add more electromagnetic information to the
packaging models. The main element missing from the original IBIS
packaging models are couplings between pins. These couplings can
change the effective inductances of power and ground pins, affecting
the amount of ground bounce that occurs in the model. The couplings
can also lead to increased noise between signal pins. For these
reasons (and more), they are worth considering.

There are many ways one might approach the description of the coupling
information. The choices made will certainly impact the efficiency
and the accuracy of the signal integrity simulations that are carried
out. To meet a wide variety of needs, several different options have
been provided for specifying the coupling data. Full-matrix formats
may be used for maximum electromagnetic rigorousness, or descriptions
with limited amounts of coupling can be used to speed up simulation.

This BIRD permits detailed package model information to be stored
either in the .ibs file, along with [Component]'s and [Model]'s, or in
a separate .pkg file. In the case where the package model is defined
in the .ibs file, that definition is local to that single file. When
a .pkg file is used, the model definition is exported, so that it can
be used by IBIS [Component]'s in other files.

Note that this is a departure from standard IBIS practice--in .ibs
files, the "model" names, at least, are not exported from the file
that contains them. Keeping package model data in separate files
leads to the possibility of naming conflicts when different vendors
(or even different groups within a large vendor company) provide files
independently. Hopefully this can be managed by using long names for
package models, and by using an official "name server" which keeps
track of existing model names and warns of conflicts.

What is still missing from this spec is the ability to handle models
with arbitrary topologies of RLC circuit elements. This would be
useful, for example, in the modelling of large packages where the
traces are long enough to exhibit some "transmission-line" effects.
In these cases, it would be useful to be able to break the single
series RL element up into a ladder (or some more complex structure) of
RLC elements. This capability will become more important as the
signal speeds of the IC's rise. Therefore, this spec may need to be
overhauled and updated at some time in the not-too-distant future.

It is certainly true that the Full_Matrix format is a special case
of both the Banded_Matrix and the Sparse_Matrix formats. It can
be regarded as "syntactic sugar" which may or may not appeal to
everyone.

*******************************************************************************

ANY OTHER BACKGROUND INFORMATION:

The classic electromagnetics text by Ramo, Whinnery and Van Duzer
provides some nice background theory on how one goes about defining
resistance, inductance and capacitance values for arbitrary
structures, and also describes the high-frequency limitations to this
approach.

*******************************************************************************
Received on Sun Apr 17 14:55:26 1994