Subject: BIRD31.1 MATED MODELS

From: [email-masked] ( Bob Ross)
Date: Mon, 18 Mar 96 18:57 PST

To IBIS Members:

Finally I have gotten around with the long promised BIRD31.1.  Based on 
initial comments and concerns, the original BIRD31 was not acceptable because
it required splitting up the electrical model.  The name of BIRD31.1 is
changed to "Mated Model" to be more inclusive of connector, cable and
socket alternatives which can use the proposed description.

BIRD31.1 is a total rewrite of BIRD31.  The contents of this extension are
blended with the existing PACKAGE MODELING text plus BIRD28.3 extensions.  
Because this extension is not yet finalized, the writeup may be somewhat
rough.  The key points of this extension are elaborated in the ANALYIS
PATH ... section.  Briefly they are:

(1)  The mated model extension applies to connectors, cables and sockets.

(2)  The mated model uses the same package model electrical extensions.

(3)  The mated model introduces the [Define Mated Model] and [End Mated
Model] keywords with the following differences from the package model: 

  (a)  It has optional pad capacitance subparameters Cpad_1 and Cpad_2.

  (b)  Mated models must exist in a separate .mmf file.

  (c)  Mated models are not reference by any [Component] in a .ibs file.
  
  (d)  The "mated model" contains two columns of pins versus one in package
       models.
       
(4)  The mated model captures the electrical data.  However, its connection
and usage syntax is simulator dependent.  Mated models can be used to attach 
boards through connectors, attach boards through cables, and attach 
components through sockets to boards.                
                                                     
Bob Ross,
Interconnectix, Inc.

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

BIRD ID#:      31.1
ISSUE TITLE:   Mated Models
REQUESTER:     Bob Ross, Interconnectix, Inc.
DATE SUBMITTED:                       11/22/95, 3/18/96
DATE ACCEPTED BY IBIS OPEN FORUM:     Pending

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

STATEMENT OF THE ISSUE:

No guidance is given within IBIS with respect to modeling connectors, cables
and sockets used to connect boards to boards and boards to components.

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

STATEMENT OF THE RESOLVED SPECIFICATIONS:

"Mated model" text is blended within the original PACKAGE MODELING section,
and the section is renamed as PACKAGE, CONNECTOR, CABLE AND SOCKET MODELS.  
The whole section is presented with BIRD28.3 extensions and additional 
changes noted by "|*" lines.  (References to the "PACKAGE MODELING" section
elsewhere would be changed to the new title.  These are not shown.)

|=============================================================================
|
|*              PACKAGE, CONNECTOR, CABLE, AND SOCKET MODELING
|*
|*  This section describes the [Define Package Model] syntax and its matrix,
|*  transmission line, and discrete element extension formats.  This section
|*  also describes [Define Mated Model] as a generic class of I/O terminal 
|*  extensions which can be used to describe the electrical characteristics
|*  of connectors, sockets, and cables.  These can be referred to as "mated
|*  models" because the are used to provide the interconnection between circuit
|*  boards through connectors or cables, and also between boards and components
|*  through sockets. 
|*
|*  The electrical format for data is identical.  Some operational details
|*  and syntax are noted.
|*
| The [Package Model] keyword is optional.  If more than the default RLC
|* package model is desired, use the [Define Package Model] keyword.  There
|* is no reference within the [Component] keyword to any connector model.
|* The information within the [Define Mated Model] is available to 
|* simulators to define the interconnections using the simulator-specific
|* syntax and interfaces.
|
| Use the [Package Model] keyword within a [Component] to indicate the package
| model for that part.  The specification permits .ibs files to contain the
| following additional list of package model keywords.  Note that the actual
| package models can be in a separate <package_file_name>.pkg file or can
| exist in the IBIS files between the [Define Package Model]...
|* [End Package Model] keywords for each package model that is defined.  
|* However, the mated model keywords can exist only in a separate 
|* <mated_model_file_name>.mmf, and not in a .ibs or .pkg file.  It exits 
|* between the [Define Mated Model] ... [End Mated Model] keywords for each
|* connector that is defined.  For reference, the keywords are listed
|* below.  Full descriptions follow.
|* Simulators that do not support these keywords will ignore all entries between
|* the [Define Package Model] and [End Package Model] keywords or between the
|* [Define Mated Model] and [End Connector Model] keywords.
|*
|
|* [Define Package Model]      Required if the [Package Model] keyword is used
|* [Define Mated Model]        (note 3)
| [Manufacturer]              (note 1)
| [OEM]                       (note 1)
| [Description]               (note 1)

|** BIRD28.3 ADDITION BELOW
|**  [Number of Sections]       (optional)

| [Number of Pins]            (note 1)
| [Pin Numbers]               (note 1)
|* [Model Data]                (note 4)
|* [Resistance Matrix]         (note 4, optional)
|* [Inductance Matrix]         (note 4)
|* [Capacitance Matrix]        (note 4)
|* [Bandwidth]                (note 4, required for Banded_matrix matrices only)
|* [Row]                       (note 4)
|* [End Model Data]            (note 4)
|* [End Package Model]         (note 2)
|* [End Mated Model]           (note 3)
|
|* (note 1) Required when the [Define Package Model] or [Define Mated Model] 
|*          keyword is used
|* (note 2) Required for ending a package model definition
|* (note 3) Required for beginning and ending a mated model definition
|* (note 4) Used only when the [Model Data] ... [End Model Data] is used
|*
| 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 that have the same name.
|
|* USAGE RULES FOR THE .PKG AND .MMF FILES
|
| Package models are stored in a file whose name looks like:
|   <filename>.pkg.
|* 
|* Mated models are stored in a file whose name looks like:
|   <filename>.mmf.
|
| The <filename> provided must adhere to the General Syntax Rules.  Use the
|*  ".pkg" extension to identify files containing package models.  Use the 
|*  ".mmf" extension to identify files containing mated models.  The .pkg and
|*  .mmf files
| 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 elements follow the same rules as those for a normal .ibs file.
|
| Note that the [Component] and [Model] keywords are not allowed in the .pkg
|* or .mmf files.  The .pkg file is for package models only.  The .mmf file
|* is used for mated models only.
|
|==============================================================================
|     Keyword:  [Define Package Model]
|    Required:  Yes
| Description:  Marks 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.  Blank characters are
|               allowed.  For every package model name defined under the
|               [Package Model] keyword, there must be a matching [Define
|               Package Model] keyword.
|------------------------------------------------------------------------------
[Define Package Model]     QS-SMT-cer-8-pin-pkgs
|
|*=============================================================================
|*     Keyword:  [Define Mated Model]
|*    Required:  Yes
|*  Sub-params:  Cpad_1, Cpad_2
|* Description:  Marks the beginning of a mated model description.
|* Usage Rules:  If the .mmf file contains data for more than one mated model,
|*               each section must begin with a new [Define Mated Model]
|*               keyword.  The length of the mated model name must not
|*               exceed 40 characters in length.  Blank characters are
|*               allowed.
|*  
|*               The Cpad_1 and Cpad_2 subparameters are optional and define 
|*               default pad capacitances at sides 1 and 2 of the mated model.
|*               The values default to 0 pF if omitted.  However, in all case 
|*               the simulator may override the default values based on
|*               actual geometrical pad dimensions.               
|*------------------------------------------------------------------------------
[Define Mated Model]   CONN4X40
Cpad_1 = .5pF
Cpad_2 = 1.0pF
|*
|==============================================================================
|     Keyword:  [Manufacturer]
|    Required:  Yes
| Description:  Declares the manufacturer of the part(s) that use this package
|*               or mated model.
| Usage Rules:  The length of the manufacturer's name must not exceed 40
|               characters (blank characters are allowed, e.g., Texas
|               Instruments).  In addition, each manufacturer must use a
|               consistent name in all .ibs and .pkg files.
|------------------------------------------------------------------------------
[Manufacturer]  Quality Semiconductors Ltd.
|
|==============================================================================
|     Keyword:  [OEM]
|    Required:  Yes
|* Description:  Declares the manufacturer of the package or mated model.
| Usage Rules:  The length of the manufacturer's name must not exceed 40
|               characters (blank characters are allowed).  In addition, each
|               manufacturer must use a consistent name in all .ibs and .pkg
|               files.
| Other Notes:  This keyword is useful if the semiconductor vendor sells a
|               single IC in packages from different manufacturers.
|------------------------------------------------------------------------------
[OEM]           Acme Packaging Co.
|
|==============================================================================
|     Keyword:  [Description]
|    Required:  Yes
| Description:  Provides a concise yet easily human-readable description of
|*               what kind of package the [Package Model] or mated model is 
|*               representing.
| Usage Rules:  The description must be less than 60 characters in length,
|               must fit on a single line, and may contain spaces.
|------------------------------------------------------------------------------
[Description]   220-Pin Quad Ceramic Flat Pack
|

|******************************************************************************
|******************************************************************************
|* BIRD28.3 ADDITION
|******************************************************************************
|******************************************************************************
|==============================================================================
|    Keyword: [Number of Sections]
|   Required: No
|Description: Defines the maximum number of sections that make up a 'package
|*             stub' or mated model.  
|            A package stub is defined as the connection between
|             the die pad and the corresponding package pin; it can include
|             (but is not limited to) the bondwire, the connection between 
|             the bondwire and pin, and the pin itself.  This keyword must 
|             be used if a modeler wishes to describe any package stub as 
|             other than a single, lumped L/R/C.  The sections of a package
|             stub are assumed to connect  to each other in a series fashion.
|*             This keyword also defines the number of sections that make up
|*             a mated model.   
|Usage Rules: The argument is a positive integer greater than zero.  This 
|             keyword, if used, must appear in the specification before the 
|             [Pin Numbers] keyword.
|-----------------------------------------------------------------------------
[Number of Sections] 3
|
|******************************************************************************
|******************************************************************************
|* END OF BIRD28.3 ADDITION
|******************************************************************************
|******************************************************************************

|==============================================================================
|     Keyword:  [Number of Pins]
|    Required:  Yes
| Description:  Tells the parser how many pins to expect.
| Usage Rules:  The field must be a positive decimal integer.
|------------------------------------------------------------------------------
[Number of Pins]   128
|
|******************************************************************************
|******************************************************************************
|* BIRD28.3 REPLACEMENT BELOW
|******************************************************************************
|******************************************************************************
|=============================================================================
|    Keyword: [Pin Numbers]
|   Required: Yes
|Description: Tells the parser the set of names that are used for the package
|*             or mated model
|             pins and also defines pin ordering.  If the [Number of Sections]
|             keyword is present it also lists the elements for each section
|*             of a pin's die to pin connection or mated model connection.
| Sub-Params: Len, L, R, C, Matrix
|Usage Rules: Following the [Pin Numbers] keyword, 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] keyword).  Pin names
|             can not exceed 5 characters in length.  The first pin name
|             given is the "lowest" pin, and the last pin given is the
|             "highest."  If the [Number of Sections] keyword is used then 
|             each pin name must be followed by one or more of the legal 
|             subparameter combinations listed below.  If the [Number of 
|             Sections] keyword is not present then subparameter usage is 
|             NOT allowed.
|*
|*            For package models, the first column is used for listing each
|*            pin.  For mated models, the first and second columns are used
|*            to list the side 1 pins and the corresponding side 2 pins.  
|*            Normally the side 2 listing is the same as the side 1 listing.
|*            However, for cables and connectors that crossover or have
|*            different pin names or groupings at either end, the two columns
|*            will have different entries.  All Matrix references will be 
|*            based on the first column notation and order.
|             
|             Subparameters:
|             The subparameters specify the length, inductance, capacitance
|*             and resistance of each section of each stub on a package or mated
|*             model.  If
|             a particular section exhibits coupling to an adjacent (same
|             numbered) section of a different package stub then the Matrix
|             subparameter is used.  The subparameters are defined as 
|             follows:
|*             Len     The length of a package or mated model stub section.  
|*                     Lengths are given
|                     in terms of arbitrary 'units'.
|*             L       The inductance of a package stub or mated model section, 
|*                     in terms of
|                     'inductance/unit length'.  For example, if the total
|                     inductance of a package stub section is 3.0nH and the
|                     length of this section is 2 'units', the inductance 
|                     would be listed as L = 1.5nH  (i.e. 3.0 / 2). 
|*             C       The capacitance of a package stub or mated model section, 
|*                     in terms of
|                     capacitance per unit length.
|*             R       The DC (ohmic) resistance of a package stub or mated 
|*                     model section,in
|                     terms of ohms per unit length.
|             Matrix  Use of this subparameter means that this package stub
|*                     or mated model                     
|                     sections electrical parameters are presented as part of
|                     a coupling matrix.  The data for the matrix is included 
|                     between the [Model Data]/[End Model Data] keyword pairs
|                     as described below.  
|
|             Specifying a length or L/R/C value of zero is allowed.  If
|             Len = 0 is specified, then the L/R/C values are the total
|             for that section.  If a non-zero length is specified, then
|             the total L/R/C for a section is calculated by multiplying 
|             the value of the Len subparameter by the value of the L,
|             R or C subparameter.
|
|*             Using the Subparameters to Describe Package or Mated Model
|*             Sections:
|             Each section description must begin with the Len subparameter and
|             ends with the slash (/) character.  The value of a sub-
|             parameter and the subparameter itself are separated by an equals
|             sign (=); whitespace around the equals sign is optional.  All 
|             package stub descriptions must contain the same number of 
|             sections however, a particular section description can contain 
|             no data (i.e. the description is given as 'Len = 0 /'.  See the 
|             example below).  
|
|             Legal Subparameter Combinations:
|             A) A single Len = 0 subparameter, followed by a slash.
|             The is used to describe a section with no data.
|
|             B)  Len and a single Matrix subparameter, followed by a
|             slash. The Len subparameter specifies the length of that 
|             section while the Matrix subparameter indicates that this 
|             section of this package stub is electrically coupled to the 
|             corresponding (same numbered) section of an adjacent package 
|             stub (or stubs) and the coupling terms are listed in a matrix
|             format.  The matrix description must include both the 'self' 
|             inductance/capacitance/resistance (as required) of a section 
|             as well as the mutual coupling terms.  If one section is
|             described using the the Matrix subparameter then the 
|             corresponding (same numbered) sections on ALL other package 
|             stubs must use the Matrix subparameter. 
|
|             C)  Len, and one or more of the L, R and C subparameters.  If
|             the Len subparameter is given as zero, then the L/R/C sub-
|             parameters represent lumped elements.  If the the Len sub-
|             parameter is non-zero, then the L/R/C subparameters represent
|             distributed elements.
|
|
|             In the example below the first section is a lumped inductor,
|             the second section is described using a matrix, and the third
|             section is modeled using distributed elements.  Pin A3 shows
|             an example of sections with no data.  Pins A4 and A5 illustrate
|             how a section description can be broken across multiple lines
|             and how each section description is delimited by the slash.
|-----------------------------------------------------------------------------
[Pin Numbers]
A1   Len = 0 L=1.2n / Len = 1.3 Matrix / Len=0.47 L=8.35n C=3.34p R=0.01 /
A2   Len = 0 L=1.4n / Len = 1.2 Matrix / Len=0.47 L=6.21n C=3.34p R=0.01 /
A3   Len = 0        / Len = 1.1 Matrix / Len = 0                         /
A4   Len = 0 L=1.2n / Len = 1.0 Matrix / Len=0.47 L=8.35n 
     C=3.34p R=0.01/
A5   Len = 0 L=1.2n /  
     Len=1.2 Matrix / 
     Len=0.47 L= 8.35n C=3.34p R=0.01 /
|
|    Note that the actual length for each section is reported, even for
|    those sections that use the Matrix subparameter.
|
|*    Note that there are two columns of pin numbers if this is for a 
|*    mated model definition.
|=============================================================================
|    Keyword: [Model Data]
|*   Required: Yes, if any of the sections in a package stub or mated model
|*             description
|             use the 'Matrix' subparameter or if the [Number of Sections]
|             keyword is not used.
|*Description: Indicates the beginning of the matrix data used to describe
|*             a package stub or mated model section.  
|Usage Rules: If the [Number of Sections] keyword is used then the [Model
|             Data] keyword must be followed by the word 'section' and the 
|             section number the matrix data applies to.  There must be a 
|             [Model Data] keyword for every section in a package stub 
|*             or mated model
|             description that uses the Matrix keyword.  Note that if the 
|             [Number of Sections] keyword is used but no package stub 
|*             or mated model
|             sections use the Matrix subparameter then the [Model Data]
|             and [End Model Data] keyword are not required.
|-----------------------------------------------------------------------------
[Model Data] section 2
|
|=============================================================================
|    Keyword: [End Model Data]
|   Required: Yes, if the [Model Data] keyword is present. 
|Description: Indicates the end of the matrix data used to describe
|*             a package stub or mated model section.  
|Usage Rules: In between the [Model Data] and [End Model Data] keywords is
|             the matrix data itself.  The data is a set of three matrices:
|             the resistance (R) , inductance (L) , and capacitance (C),
|             matrices.  Each matrix can be formatted differently (see
|             below).  Use one of the matrix keywords to mark the
|             beginning of each matrix.  As with the [Model Data] keyword
|             the [End Model Data] keyword is followed by the word 'section'
|             and the section number.
|-----------------------------------------------------------------------------
[End Model Data] section 2
|
|******************************************************************************
|******************************************************************************
|* END OF BIRD28.3 REPLACEMENT OF EXITING VERSION 2.1 TEXT
|******************************************************************************
|******************************************************************************
|==============================================================================
|    Keywords:  [Resistance Matrix], [Inductance Matrix], [Capacitance Matrix]
|    Required:  [Resistance Matrix] is optional.  If it is not present, its
|               entries are assumed to be zero.  [Inductance Matrix] and
|               [Capacitance Matrix] are required.
|  Sub-Params:  Banded_matrix, Sparse_matrix, or Full_matrix
| Description:  The subparameters mark the beginning of a matrix, and
|               specify how the matrix data is formatted.
| Usage Rules:  For each matrix keyword, use only one of the subparameters.
|               After each of these subparameters, insert the matrix data in
|               the appropriate format.  (These formats are described in detail
|               below.)
| Other Notes:  The resistance, inductance, and capacitance matrices are also
|               referred to as "RLC matrices" within this specification.
|
|               When measuring the entries of the RLC matrices, either with
|               laboratory equipment or field-solver software, currents are
|*               defined as ENTERING the pins of the package or mated model 
|*               from the board
|               (General Syntax Rule #11).  The corresponding voltage drops are
|               to be measured with the current pointing "in" to the "+" sign
|               and "out" of the "-" sign.
|
|                                  I1   +-----+    I2
|                                -----> |     | <------
|                        board o--------| Pkg |---------o board
|                               +  V1 - |     | -  V2  +
|                                       +-----+
|
|               It is important to observe this convention in order to get the
|               correct signs for the mutual inductances and resistances.
|
|------------------------------------------------------------------------------
[Resistance Matrix]     Banded_matrix
[Inductance Matrix]     Sparse_matrix
[Capacitance Matrix]    Full_matrix
|
|==============================================================================
|
| RLC MATRIX NOTES
| For each [Resistance Matrix], [Inductance Matrix], or [Capacitance
| Matrix] a different format can 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 can have no coupling terms at all.  In this case, the most
| concise format (Banded_matrix) can be used.
|
|******************************************************************************
|******************************************************************************
|* BIRD28.3 ADDITION
|******************************************************************************
|******************************************************************************
| There are two different ways to extract the coefficients that are reported
| in the the capacitance and inductance matrices.  For the purposes of this
| specification, the coefficients reported in the capacitance matrices shall
| be the 'electrostatic induction coefficients' or 'Maxwell's capacitances'.
| The Maxwell capacitance Kij is defined as the charge induced on conductor "j"
| when conductor "i" is held at 1 volt and all other conductors are held at 
| zero volts. Note that Kij ( when i /= j) will be a negative number and 
| should be entered as such.  Likewise, for the inductance matrix the 
| coefficients for Lij are defined as the voltage induced on conductor "j" 
| when conductor "i"'s current is changed by 1amp/sec and all other 
| conductors have no current change.
|
|******************************************************************************
|******************************************************************************
|* END OF BIRD28.3 ADDITION
|******************************************************************************
|******************************************************************************
| 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 are provided.
|
| In the following text, 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 is defined in the [Pin Numbers] section.  In the following text,
| "Row 1", means the row corresponding to the first pin.
|
| Also 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.
|
| Full_matrix
|
| When the Full_matrix format is used, the couplings between every pair of
| elements is specified explicitly.  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:  Indicates the beginning of a new row of the matrix.
| Usage Rules:  The argument must be one of the pin numbers listed under the
|               [Pin Numbers] keyword.
|------------------------------------------------------------------------------
[Row]           3
|
|==============================================================================
| Following a [Row] keyword is a block of numbers that 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
| number 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 or mated model, 
|* this data will not all fit on one line.
| You can break the data up with new-line characters so that this limit is
| observed.
|
| An example: suppose the package has 40 pins and that we are currently
| working on Row 19.  There is 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.
|
| Observe that Row 1 always has the most entries, and that each successive row
| has one fewer entry than the last; the last row always has just a single
| entry.
|
| 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."  Let the matrix size be N x M, and let the bandwidth
| be B.  An entry [I,J] of the matrix is zero if:
|
|        | I - J | > B
|
| where |.| denotes the absolute value.
|
| The Banded_matrix is used to specify the coupling effects up to B pins
| on either side.  Two variations are supported.  One allows for the coupling
| to circle back on itself.  This is technically a simple form of a bordered
| block diagonal matrix.  However, its data can be completely specified
| in terms of a Banded_matrix for an N x M matrix consisting of N rows
| and M = N + B columns.  The second variation is just in terms of an N x N
| matrix where no circle back coupling needs to be specified.
|
| The bandwidth for a Banded_matrix must be specified using the [Bandwidth]
| keyword:
|
|==============================================================================
|     Keyword:  [Bandwidth]
|    Required:  Yes (for Banded_matrix matrices only)
| Description:  Indicates the bandwidth of the matrix.  The bandwidth field
|               must be a nonnegative integer.  This keyword must occur after
|               the [Resistance Matrix], etc. keywords, and before the matrix
|               data is given.
| Usage Rules:
|------------------------------------------------------------------------------
[Bandwidth]     10
|
|==============================================================================
| Specify the banded matrix one row at a time, starting with row 1 and
| working up to higher rows.  Mark each row with the [Row] keyword, as
| above.  As before, symmetry is exploited: do not provide entries below the
| main diagonal. 
|
| For case where coupling can circle back on itself, consider a matrix of 
| N pins organized into N rows 1 ... N and M columms 1 ... N, 1 ... B.
| The first row only needs to specify the entries [1,1] through [1,1+B] since
| all 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.  For row K
| the entries [K,K] through [K,K+B] are given when K + B is less than or
| equal to the size of the matrix N.  When K + B exceeds N, the entries in the
| last columns 1 ... B specify the coupling to the first rows.  For row K, the
| entries [K,K] ... [K,N] [K,1] ... [K,R] are given where R = 
| mod(K + B - 1, N) + 1.  All rows will contain B + 1 entries.  To avoid
| redundant entries, the bandwidth is limited to B <= int((N - 1) / 2).
|
| For the case where coupling does not circle back on itself, the process is
| modified.  Only N columns need to be considered.  When K + B finally exceeds
| the size of the matrix N, the number of entries in each row starts to
| decrease; the last row (row N) has only 1 entry.  This construction
| constrains the bandwidth to B < N.
|
| As in the Full_matrix, if all the entries for a particular row do not fit
| into a single 80-character line, the entries can 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.
|
| Sparse_matrix
|
| 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 can occur.  This feature is useful in certain
| situations, such as for Pin Grid Arrays (PGAs).
|
| As usual, symmetry can 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
| specification 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 can 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
|
| 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 Numbers] section is observed.
|
| With this convention, please note that the N'th row of an
| N x N matrix has just a single entry (the diagonal entry).
|
|==============================================================================
|     Keyword:  [End Package Model]
|    Required:  Yes
| Description:  Marks the end of a package model description.
| Usage Rules:  This keyword must come at the end of each complete package
|               model description.
|
|               Optionally, add a comment after the [End Package Model] keyword
|               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]
|
|*=============================================================================
|*     Keyword:  [End Mated Model]
|*    Required:  Yes
|* Description:  Marks the end of a mated model description.
|* Usage Rules:  This keyword must come at the end of each complete mated
|*               model description.
|*
|*               Optionally, add a comment after the [End Package Model] keyword
|*               to clarify which package model has just ended.  For example,
|*
|*               [Define Mated Model]   My_Model
|*               |
|*               |  ... content of model ...
|*               |
|*               [End Mated Model]     | end of My_Model
|*
|*----------------------------------------------------------------------------
[End Mated Model]
|*
|==============================================================================
|                           Package Model Example
|
| The following is an example of a package model file following the
| package modeling 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.1
[File Name]     example.pkg
[File Rev]      0.1
[Date]          December 13, 1995
[Source]        Quality Semiconductors.  Data derived from Helmholtz Inc.'s
                field solver using 3-D Autocad model from Acme Packaging.
[Notes]         Example of 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 Package Co.
[Description]           8-Pin ceramic SMT package
[Number of Pins]        8
|
[Pin Numbers]
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
|
[End Model Data]
[End Package Model]
|
|==============================================================================

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

ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:

BIRD31.1 is a total rewrite of BIRD31 which proposed connector models split
and attached directly on [Component] models.  It was impractical, limiting,
and burdensome to provide split models.

"Mated models" is introduced as a general term to describe connectors, cables
and socket.  Its electrical format is the same as the package model format.
The final form will track any further developments in package model syntax.
Thus the mated model text was merged with the existing package model text
to form a combined section.

The interconnection is based on simulator dependent interfaces.  The 
[Component] pins for the connector footprint must contain reference to 
Model_names or NC, POWER, or GND.  The package model elements can
be used to approximate the termination effects if the connector is NOT
mated.  The mated model elements override these package parameters when
the interconnection is made.

The electrical model of cables contain the effects of the connectors 
at both ends along with the cable wire descriptions.

For [Components] modeled on sockets, the package model of the [Component]
model will be used.  Here the simulator interface could distinguish between
a connection made to another board, and a connection made to just a
component.

(3)  The mated model introduces the [Define Mated Model] and [End Mated
Model] keywords because it differs from the package model in the following
ways: 
     
 (a)  It adds optional Cpad_1 and Cpad_2 subparameters for pad capacitance.
      Most connector model do not include these effects.
 
 (b)  The mated model is NOT referenced by any [Component] directly.  The
      simulator interface determines how a mated model is connected (or not
      connected as in the case of an empty socket for optional memory.
 
 (c)  The mated model must exist only in a separate file since it cannot 
      be determined which mated model file to use if it also exists within
      a .ibs file.  (In contrast, the [Package Model] keyword provides the
      direct reference, and its model is searched first in the .ibs file and
      then in any .pkg file.)
 
 (d)  The mated model contains two columns of pins so that the pins on one
      side can be defined differently than the pins on the other side.  Thus
      cables which have cross-over connections, or which can be split and
      feed several different connectors can be described.
      
******************************************************************************

ANY OTHER BACKGROUND INFORMATION:

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