Subject: bird 37.1

From: Stephen Peters <[email-masked]>
Date: Tue, 03 Sep 1996 17:07:48 -0700

Hello All:

   I posted this a few weeks back, but seeing that
it's been 6 weeks between meeting I thought I'd
post it again as a refresher.  We will vote on
this Friday.

              Regards,
              Stephen Peters
              Intel Corp.

=============================================================================

                 Buffer Issue Resolution Document  (BIRD)
BIRD ID#:        37.1
ISSUE TITLE:     Enhancement To The Package Model (.pak file) Specification
REQUESTER:       Stephen Peters
DATE SUBMITTED:  August 12, 1996
DATE ACCEPTED BY IBIS OPEN FORUM:  Pending

******************************************************************************
******************************************************************************
STATEMENT OF THE ISSUE:  The current package model electrical description,
(as proposed in Bird 28.3 and accepted by the forum) has the restriction
that all the sections of a package stub connect in a series fashion, with 
no branches or stubs allowed.  This limits the usefulness of the
description when trying to describe BGA or other packages where branches
or forks off the main package stub may be present.  This BIRD corrects
this deficiency by adding two new subparameters to the [Pin Numbers] keyword
called 'Fork' and 'Endfork'
******************************************************************************
STATEMENT OF THE RESOLVED SPECIFICATIONS:  Following are the specific changes
to the specification (spec as amended by Bird 28.3).

1.  The Sub-params list of the [Pin Numbers] keyword is changed to that
shown below

|Sub-Params: Len, L, R, C, Matrix, Fork, Endfork

2.  The text following the first paragraph of the Usage Rules section of the
[Pin Numbers] keyword is replaced by the following:
|
|             Subparameters:
|             The Len, L, R, and C subparameters specify the length, 
|             inductance, capacitance and resistance of each section of
|             each stub on a package. If a particular section 
|             exhibits coupling to an adjacent (same numbered) section of 
|             a different package stub then the Matrix subparameter is used.
|             The Fork and Endfork subparameters are used to denote branches
|             from the main package stub. 
|             Len     The of a package stub section.  Lengths are given
|                     in terms of arbitrary 'units'.
|             L       The inductance of a package stub section, in terms of
|                     'inductance/unit length'.  For example, if the total
|                     inductance of a section is 3.0nH and the
|                     length of the 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 section, in terms of
|                     capacitance per unit length.
|             R       The DC (ohmic) resistance of a package stub section, in
|                     terms of ohms per unit length.
|             Matrix  Use of this subparameter means that this package stub
|                     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.
|             Fork    This subparameter indicates that the sections
|                     following (up to the Endfork subparameter) are part
|                     of a branch off of the main package stub.  This 
|                     subparameter has no arguments.
|             Endfork This subparameter indicates the end point of a
|                     branch.  For every Fork subparameter there must be
|                     a corresponding Endfork subparameter.  As with the
|                     Fork subparameter, the Endfork subparameter has no
|                     arguments.
|
|             Specifying a Len 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. However, if a non-zero length section
|             is specified, the L and C for that section should be treated
|             as distributed elements.
|
|             Using The Subparameters to Describe Package Stub Sections:
|             A section description begins with the Len subparameter and
|             end with the backslash (/) character.  The value of the Len, L,
|             R and C subparameters and the subparameter itself are 
|             separated by an equals sign (=); whitespace around the equals 
|             sign is optional.  The Fork and Endfork subparameters
|             are placed between section descriptions (i.e. between the
|             concluding backslash of one section and the 'Len' parameters
|             that starts another).  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 /').
|             
|             Legal Subparameter Combinations for Section Descriptions:
|             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
|             backslash. 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.
|
|             D)  Single Fork or Endfork subparameter.  Normally, a package
|             stub is described as several sections, with the Fork and Endfork
|             subparameters surrounding a group of sections in the middle of
|             the complete package stub description.  However, it is legal
|             for the Fork/Endfork subparameters to appear at the end of a 
|             section description.  The package pin is connected to the 
|             last section of a package stub description not surrounded by
|             a Fork/Endfork statements.  See the examples below. 
|
|             Package Stub Boundaries:
|             A package stub description starts at the connection to 
|             the die and ends at the point at which the package pin 
|             interfaces with the board or substrate the IC package 
|             is mounted on.  Note that in the case of a component
|             with thru-hole pins, the package stub description should
|             include only the portion of the pin not physically 
|             inserted into the board or socket.  It is legal for
|             a package stub description to include both the component
|             and socket together if this is how the component is 
|             intended to be used.
|             

3.  The following examples are added to the examples for bird 28.3
|
|A section description using the Fork and Endfork subparameters.  Note
|that the indentation of the Fork and Enfork subparameters are for
|readability and are not required.
|
A1 Len=0 L=2.3n /        | bondwire
Len=1.2 L=1.0n C=2.5 /   | first section
 Fork                    | indicates the starting of a branch
 Len=1.0 L=2.0n C=1.5p / | section 
 Endfork                 | ending of the branch
Len=0.5 L=1.0 C=2.5/     | second section 
Len=0.0 L=1.5n /          | pin
|
|Here is an example where the Fork/Endfork subparameters are at the
|end of a package stub description
|
B13 Len=0 L=2.3n /       | bondwire
Len=1.2 L=1.0n C=2.5 /   | first section
Len=0.5 L=1.0 C=2.5/     | second section, pin connects here
Fork                     | indicates the starting of a branch
Len=1.0 L=2.0n C=1.5p /  | section 
Endfork                  | ending of the branch

******************************************************************************
ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:
     This bird grew out of the need to describe a particular structure found
in BGA type packages.  In these packages, the trace that connects the die 
pad to the via for the 'ball' does not stop there.  For manufacturing
reasons the trace continues out to the edge of the board and thus forms
a 'stub' or branch off the main pad to ball (or pin) connection.  Because
of the need to stick with the existing section based description, the 
fork and Endfork subparameters were chosen.

REVISIONS FOR 37.1:
   Based on comments received, removed backslash ("/") from the Fork and 
Endfork syntax, added a description of the package stub boundaries, and
added two examples.  I also added a recommendation that non-zero length
section descriptions be treated as distributed elements.

---

From: Jon Powell <[email-masked]>
Date: Thu, 05 Sep 1996 15:23:01 -0700

I see two issues with bird 37.1 that I think we should conciously
address. Not to say that we shouldn't pass this bird, but we should only
pass it if we are willing to live with these limitations:

1) This only describes point to point connections. It cannot be used for
SIMMS or connectors that use multiple connections. It cannot be used for
any package that might (for instance) route two ground pads to the same
pin).

2) It can only be used to describe packages that are single layer. While
it could describe some multi-layer packages I can give a few quick
counter examples of easy to imagine scenarios that can only occur (and
probably would occur) with 2 level packageing. Here is one:

(these lines don't touch but the verticle lines do couple)

______________
             _|___________
            | |
            | |___________
____________| 

If you think that you can represent this then think about the following
and how it would be Different: (once again, only the verticle lines
coupled)

__________________
________________  |
                | |
                | |
                | |___________
                |_____________

I think that the bird37.1 description of these two examples would be the
same circuit even though they are clearly electrically different.

The question of whether we want to "go ahead" and do this even though it
has some basic limitations is I think what we need to decide.

regards,
jon