Subject: Clarifing example for Packaging EGG

From: Stephen Peters <[email-masked]>
Date: Thu, 04 May 1995 14:38:19 -0700

Hello Fellow IBISains:

     As promised, here is a (I hope) clarifying example of how one would
describe a package using the proposed xmission line package concept.
In this example I've listed the rules for describing 'sections', and
I've also added a [Unit Length] keyword.  Why?  Read on.....

     Suppose you have a package with the following pinout:

____
    |-------- Pin1   sig1
    |-------- Pin2   sig2
    |-------- Pin3   GND
    |-------- Pin5   sig5
    |-------- Pin6   sig6
    |-------- Pin7   sig7
    |-------- Pin8   PWR
    |-------- Pin9   sig9
    |-------- Pin10, sig10
____|

     Each package stub (for the signals) is modeled as follows:

DIE--@@@@@@@@--ZZZZZZZZZZZZZZZZZ--zzzzzzz
     bondwire      Trace            Pin
     (lumped L) (coupled xmission (uncoupled xmission
                  line)              line)

Also assume that the GND and PWR connections are modeled as a 
lumped 2.0n inductance.

     This package would be described as follows:

-----  content of .pkg  file --------

[IBIS Ver]      2.1
[File name]     example.pkg
  .
  .
  .
[Define Package Model]  10pin_pkg
  .
  .
  .
|  First, I believe a [Unit Length] keyword is needed.  I realize that
|  as long as all the L/R/C parameters are given in terms of
|  unit length, and the physical length is specified in that same, consistent
|  unit (inches, cm, etc.) one can calculate the propagation velocity or 
|  time delay of the section.  However, the
|  user is going to be integrating this package description into the
|  boards netlist or topology.  Therefore, the user has to know what units
|  the package description is in so the board extraction can use the same.
|  Permissible values are 'in', 'cm', 'ft'.
|
[Unit Length] in
|
|
[Number of Pins]     10
|
|
[Number of Sections] 3
|
| In the example above each package stub has three sections.
| The sections are in series and represent the following elements; the 
| bondwire (modeled as a lumped inductor), the trace between the bondwire
| and the external pin (modeled as a coupled transmission line), and the
| external pin (modeled as a non-coupled transmission line).  The pin
| number keyword is used to describe each section.  
|
| For reference, here are the rules for section descriptions and using 
| the the Len:, C:, L:, R: and Matrix arguments (Thanks to Kellee 
| Crisafulli for suggesting the Matrix argument.)
| 1. Each section description is separated by a comma
| 2. The legal argument combinations are
|    a)  If the [Number of Sections] keyword is absent, then NO arguments to
|        the [Pin] keyword are permitted. It is assumed that there
|        is one section of lumped elements whose values are listed under
|        the [Matrix] keyword. This is the backwards compatibility option.
|    a)  Len: and a single 'Matrix' argument.  The L, R and C values are
|        listed in the Matrix description of that section.
|    b)  Len: and any combination of the L:, C: and R: arguments.  This 
|        option is for modeling uncoupled transmission lines.
|    c)  No Len: and any combination of the L:, C: and R: arguments. This
|        option is for modeling lumped elements.
|    d)  Specifying a length of zero (i.e. Len:0) is permitted.
|  3. When a non zero length is specified then L:, R: and C: must be expressed
|     in terms of unit length.
|  4. A consistent unit of length (i.e. inches, cm, feet, etc.) must 
|     be used throughout the package file.  
|
|
[Pin Number]
Pin1   Len:0 L:1.2n, Len:1.2 Matrix, Len:0.47 L: 8.35n C:3.34p R:0.01
Pin2   Len:0 L:1.2n, Len:1.2 Matrix, Len:0.47 L: 8.35n C:3.34p R:0.01
Pin3   Len:0 L:0n  , Len:1.2 Matrix, Len:0 L:0
Pin4   Len:0 L:1.2n, Len:1.2 Matrix, Len:0.47 L: 8.35n C:3.34p R:0.01
Pin5   Len:0 L:1.2n, Len:1.2 Matrix, Len:0.47 L: 8.35n C:3.34p R:0.01
Pin6   Len:0 L:1.2n, Len:1.2 Matrix, Len:0.47 L: 8.35n C:3.34p R:0.01
Pin7   Len:0 L:1.2n, Len:1.2 Matrix, Len:0.47 L: 8.35n C:3.34p R:0.01
Pin3   Len:0 L:0n  , Len:1.2 Matrix, Len:0 L:0
Pin9   Len:0 L:1.2n, Len:1.2 Matrix, Len:0.47 L: 8.35n C:3.34p R:0.01
Pin10  Len:0 L:1.2n, Len:1.2 Matrix, Len:0.47 L: 8.35n C:3.34p R:0.01
|
|  The bondwire is described as 'Len:0 L:1.2n' -- a 1.2nH lumped
|  inductance.  The package trace (section 2) is a coupled transmission line
|  so is described using the Len: and Matrix format.  Section 3, the 
|  actual pin, is described as 'Len:0.47 L:0.835n C:3.34' -- an 
|  uncoupled transmission line 0.47 'units' long with 
|  8.35nh/unit_length of inductance and 3.34pF/unit_length of capacitance.
|       Also, note the power and ground connections (pins 3 and 7).  
|  As mentioned above these stubs are modeled as a lumped inductor.
|  To keep it simple, section 2 MUST still use the 'Matrix' word.
|  I have chosen to lump all the inductance into the 'self L' term in
|  the matrix and "zero out" the rest of the sections.
|  Setting all the values in a section to zero is legal.
|
|  Now comes the matrix description.  It is assumed that pins 1 and 2 are
|  isolated (by the GND connection) from pins 4, 5, 6 and 7, which are in
|  turn isolated (by the PWR connection) from pins 9 and 10.  A sparse
|  Matrix format is used.  To save typing I am only going to show the C
|  matrix.
|
[Model Data] section 2
[Capacitance Matrix] Sparse_matrix
[Row] 1
1    1.0p
2    1.5p
[Row] 2
2    1.7p
[Row] 3
3    0.0p | the L matrix would show the self inductance of the stub 3
[Row] 4
4    5.2p
5    3.7p
6    1.1p
7    0.1p
[Row] 5
5    2.7p
6    1.0p
7    0.9p
[Row] 6
6    2.1p
7    1.1p
[Row] 7
7    3.3
[Row] 8
8     0.0p | again, use the L matrix to  show self inductance
[Row] 9
9     1.0p
10    1.5p
[Row] 10
10    1.7p
|
|
|  Then follows the Inductance matrix (and R matrix if needed).
|

     I hope this example clarifies my proposal.  Hope to hear from
everyone Friday.

       Best Regards,
       Stephen

---

From: [email-masked] (Jon Powell)
Date: Thu, 4 May 95 16:25:59 PDT

I find the recommended methodology quite appropriate (in fact it is amazing like
the coupling file used in XTK, I guess function does define form). There is one situation
we want to make sure and plan for and that is where there are a hundred pins each of which
couples to its immediate neighbors but doesn't really couple to pins a few pins away. (I think
the propose format covers this syntactically but we want to be ready to simulate it also).

1
2
3
4
5
6
7
8
9

so

123 couple

234 couple

345 couple

567 couple

etc.

This is important because it allows the database to be partitioned into simulation segments that overlap but are
smaller than simulating the entire pin coupling set. (which is essential for efficient simulation).

jon