Here is an example of "spice" description of the package
> ____
> |-------- Pin1 sig1
> |-------- Pin2 sig2
> |-------- Pin3 GND
> |-------- Pin5 sig5
> |-------- Pin6 sig6
> |-------- Pin7 sig7
> |-------- Pin8 PWR
> |-------- Pin9 sig9
> |-------- Pin10, sig10
> ____|
The top level subckt is a black box of external terminals
> ________
>Die1 --- | |-------- Pin1 sig1
>Die2-----| |-------- Pin2 sig2
>Die3-----| |-------- Pin3 GND
>Die5---- | |-------- Pin5 sig5
>Die6---- | |-------- Pin6 sig6
>Die7---- | |-------- Pin7 sig7
>Die8---- | |-------- Pin8 PWR
>Die9---- | |-------- Pin9 sig9
Die10--- | |-------- Pin10, sig10
>_ |___ ____|
The subcircuit called "package" has the following form:
.subckt Package Die1......Die10 Pin1....Pin10
[Subcircuit description]
.ends Package
the subciruit is simply a black box with external terminals.
The [Subcircuit description] can in turn be composed of hierarchichal subcircuits.
The key points here are
1 - We are borrowing a way of describing networks in the form of subcircuits
from spice which is elegant, simple and completely flexible.
2. IBIS does not and probably should not mandate what is contained inside the
subcircuits. The subcircuit descriptions can be as complex or simple and it is
totally left to the model developer.
3. The only convention the subcircuit has to obey is the EXTERNAL terminals
naming convention. For example the names Pin1 and Die1 has to mean something
in IBIS.
4. I want to emphasize it is not even necessary for us to invent a coupled
transmission line description. Because the model developer can create
a equivalent coupled transmission line description using
sectioned lines containing mutual
inductors and capacitors. However it may be nice if an acceptable coupled
line description can be standardized.
Let us follow an example of the subcircuit.
Let us say that the pins are described like in
the example shown by Stephen
DIE--@@@@@@@@--ZZZZZZZZZZZZZZZZZ--zzzzzzz
Let us assume Pins 1-3 are coupled and all other pins are simple lumped inductances
Top Level:
The package subcircuit completely describes this package
.subckt Package Die1......Die10 Pin1....Pin10
X1 Die1 Die2 Die3 Pin1 Pin2 Pin3 SingleAndCoupledLines
L4 Die4 Pin4 4.2nh
......
L10 Die10 Pin10 4.2nh
.ends Package
.subckt SingleAndCoupledLines Die1 Die2 Die3 Pin1 Pin2 Pin3
* Single transmission lines
T11 Die1 0 1 0 td=0.5n z0=50
T22 Die2 0 2 0 td=0.45n z0=70
T33 Die3 0 3 0 td=0.4n z0=100
* coupled line
X 1 2 3 Pin1 Pin2 Pin3 CoupledLine
.ends SingleAndCoupledLines
.subckt CoupledLine A B C Pin1 Pin2 Pin3
* sample coupled line
TCoupled A 0 B 0 C 0 Pin1 0 Pin2 0 Pin3 0 Rlgc=3lineRlgcData Length=0.001m
,Data RLGC 3lineRlgcData
.RMATRIX
4.0 0 0
0 4.0 0
0 0 4.0
.LMATRIX
420nh 10n 0.8n
--- --- .CMATRIX --- -- .end Data RLGC .ends CoupledLine An alternate form of coupled line uses mutual inductances and capacitances .subckt AlternateCoupledLine 11 21 31 Pin1 Pin2 Pin3 * 3 sections of line X1 11 21 31 12 22 32 CoupledSection X2 12 22 32 13 23 33 CoupledSection X3 13 23 33 Pin1 Pin2 Pin3 CoupledSection .ends AlternateCoupledLine .subckt CoupledSection 1 2 3 1out 2out 3out r1 1 11 0.001 l1 11 1out 1.2n k 1 2 0.02 cmut 1 2 0.3p ..... .ends CoupledSection > > 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 > > >Received on Fri May 5 13:00:12 1995
This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:52:29 PDT