******************************************************************************* ******************************************************************************* Buffer Issue Resolution Document (BIRD) BIRD ID#: 10.2 ISSUE TITLE: Describing coupling effects in package models REQUESTOR: Eric Bracken, Performance Signal Integrity, Inc. DATE SUBMITTED: 17 March 1994 DATE REVISED: 15 April 1994 DATE ACCEPTED BY IBIS OPEN FORUM: April 29, 1994 ******************************************************************************* ******************************************************************************* 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 .pkg The 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], [Copyright], 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 [End Package Model] keyword marks the end of a complete package model. For every [Define Package Model], a corresponding [End Package Model] keyword is required. |============================================================================== | | Keyword: [End Package Model] | | Required: Yes | | Description: Used to mark the end of a package model description. | | Usage Rules: The keyword must come at the end of each complete package | model description. | | It is suggested that a comment follow the [End Package Model] | to clarify which package model has just ended. For example, | | [Define Package Model] My_Model | | | | ... content of model ... | | | [End Package Model] | end of My_Model | |------------------------------------------------------------------------------ | [End Package Model] Between the [Define Package Model] and the [End Package Model] keywords, a package model description is provided. This consists of several keywords described below. 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] Quality 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] Acme Packaging Co. 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 metric "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] Quality Semiconductors. Data derived from Helmholtz Inc.'s field solver, using 3-D Autocad model from Acme Packaging. [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. | |================================================================ | [Define Package Model] QS-SMT-cer-8-pin-pkgs [Manufacturer] Quality Semiconductors Ltd. [OEM] Acme Packaging Co. [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 Package Model] | QS-SMT-cer-8-pin-pkgs [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. *******************************************************************************