BIRD 31.1

Bob Ross has done an excellent job of providing a connector/cable model
structure proposal in BIRD31.1. I have greatly appreciated discussions with
him on this subject and he has helped me gain a better understanding of the
EDA world's problems. Having completed that first level of exchange with
Bob, I think it is now appropriate to share what is left of my questions and
comments with the full group. I hope that they spark further discussion
that will help to bring significant advances to this IBIS modeling effort.

I have attached the full text of BIRD 31.1 with my comments and questions
inserted and marked off with ">>>" symbols so they are easy to find.

Hank Herrmann
Technical Staff Member
AMP Incorporated, Electromagnetic Technology
M.S. 106-14
P.O. Box 3608
Harrisburg, PA 17105-3608

            Phone: 717-986-5534
                 FAX: 717-986-5643
   INTERNET: hank.herrmann@amp.com

[[ Cmts_02_00.txt : 2654 in Cmts_02_.00t ]]

3/28/96

Comments & Questions to BIRD 31.1 They are inserted in the text of the BIRD
and are set off with ">>>>>>>>>>" symbols.

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

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.)

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> General Questions & Comments:
> 1. The Minimum Edge Rate for a package, connector or cable model should be
> specified as a required parameter. A required Keyword, such as
> [Minimum Edge Rate], should be added. Eventually, simulators should
> generate a warning message if faster signals are impinging on the model.
> 2. The word "STUB" is used to mean a conductive or transmission path
> through a model. Is that normal EDA / IC / IBIS terminology? It
> is confusing to connector modelers because a "STUB" to us is a passive
> tap off of a transmission path. The word "PATH" would be preferred.
> 3. How can connections be established between pins and internal matrix
> tie points? Transmission and shielded type connectors require them.
> Shielded cables, and transmission paths over ground planes can also
> require them.
> 4. Un-mated connector models are not the same as a mated model that is
> not connected to something. Empty sockets and un-used bus slots
> present a reduced capacitance and there may be no significant
> inductance. There are also backplane connectors that have pin fields
> that penetrate through the PCB and provide a 'back panel connection
> point'. They too, are often not connected. A much more simple single
> sided model would be the preferred structure for such device models.
> 5. This appears to describe an entire connector without the use of
> reusable sub-matrixes. Is that correct? If so, is that really an
> acceptable general solution?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

|=============================================================================
|
|* 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

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> Where are the boundaries for a Package model? Do they extend to the end of
> the pins or SMT legs or do they stop short somewhere?
> A standard boundary should be established. We use the plane at the top of
> the socket. We find that necessary because of the interaction of the IC
> pin with the Socket Contacts when C & L parameters are extracted. It is
> also a reasonable boundary, from the IC perspective, since it coincides
> with the plane of a PCB surface. The IC pins always go into a PCB or into
> a socket below that boundary.
> It is also important to define boundaries for the .mmf models.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

|* 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.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> There could be several reasons not to exclude these sections. How can we
> add additional connections (See comments under Keyword: [Pin Numbers]) or
> additional components like capacitor filters, ESD clamps and even active
> devices, to our connector models? We do manufacture connectors that
> contain such devices. Maybe this makes this .mmf a .ibs for those kinds
> of devices but since you separated active device models (.ibs) and passive
> device models (.pkg & .mmf) I need to understand the reasons and consider
> all of the implications.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

|
|==============================================================================
| 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.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> It should be clarified that there is also an [End 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.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> It should be clarified that there is also an [End Define Mated Model]
> keyword.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

|*-----------------------------------------------------------------------------
[Define Mated Model] CONN4X40
Cpad_1 = .5pF
Cpad_2 = 1.0pF
|*

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> Perhaps some clarification would be helpful here. This is understood to be
> a manufacturers suggested default value. A value of zero (0) is allowed.
> This is a parameter that falls outside of the boundaries of the model and
> is provided as a first level estimate only. Simulators can replace
> this value as needed.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

|==============================================================================
| 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.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> I think this Pin Numbering can become very complicated for connectors and
> cables. e.g., A cable wire can go from pin 2 to pin 3 and possibly to
> pin 4 also. A connector can have a different footprint on each side with
> some pins being on one side only and not on the other. e.g., A ground
> blade could be connected to several pins in a column on one side and a
> different number of pins in a row on the other side. Or the pins could
> be in a row on both sides but numbered differently.
> I am not sure how these complications can be handled. We will need a very
> generalized interconnection capability within the model. We need to be
> careful that we do not accept something that will make backward
> compatibility difficult in the future when more advanced interconnection
> structures need to be accommodated.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

|
| 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 +
| +-----+
|

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> I think I understand, and agree with, the current conventions but I am
> confused by the voltage references. Can you elaborate?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

| 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.
|

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> 1. Why is "K" used for capacitance instead of "C"? This causes confusion
> with the inductive coupling coefficient in SPICE which is "K".
> 2. Why do we care HOW these Matrixes are CREATED if they give valid model
> performance? After all, these matrixes just represent a set of
> capacitance and inductance values. As long as the matrix values
> provided, do not require a simulator to handle them any differently,
> does it matter? If that is what is really important, how can we say
> that clearly?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

|******************************************************************************
|******************************************************************************
|* 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:

******************************************************************************
Received on Wed Apr 3 07:34:56 1996