Subject: EGG for Transmision Line Package Models

From: Stephen Peters <[email-masked]>
Date: Fri, 21 Apr 1995 16:46:35 -0700

Hello All:

     In this egg I am proposing a method of describing the electrical
characteristics of the connection between the die pad and the PCB or
other medium the package is mounted to.  Specifically, I would like to 
describe this connection (referred to as the package 'stub') as one or 
more elements in series. These elements include lumped inductances/
capacitances/resistances, uncoupled transmission lines, or coupled 
transmission lines.  Refer to figure 1 below (it will be used as an 
example throughout this discussion).

                     Bondwire      Package Trace
     ----------------@@@@@@@@--ZZZZZZZZZZZZZZZZZZZZZZZ
     |   DIE      |                                  || 
     --------------                                  || Pin
                                                     ||
     
                       Fig 1 -- A Simple(?) Package

     There are a couple of things to note about the typical package as shown
in Figure 1.  The most obvious is that a package stub is made up of several 
different elements, and these elements can be modeled in different ways.
For example, the bondwire can be represented by a lumped inductor or a 
high impedance transmission line segment.   The package trace itself is 
analogous to a PCB trace and can be described using the same parameters
(length, Zo, trace velocity) as a PCB trace.  In addition, depending on 
package construction or the absence of a ground plane in the package, 
package traces may exhibit significant coupling between themselves and 
nearby traces.  Likewise, the pin itself can be represented as a lumped 
inductor or capacitor.
     As the IBIS spec stands now it cannot describe the above package
stub as anything other than a lumped L, R and C.  Without any
length (or L and C per unit length) information the delay and Zo
characteristics of the stub cannot be modeled.  Furthermore, even though
the IBIS '.pkg' file does allow one to describe the coupling between pins,
it is (again) lumped information without regard to length or the fact that 
different sections have different coupling.  The proposed expansion
of the '.pkg' file description allows both  1) a package stub to be
described as a series of sections made up of different types of electrical
elements and 2) a per unit length description of the L and C information of 
each section.  The proposed changes also allow the complete elimination of the
matrix information if coupling descriptions are not required.

SECTION AND LENGTH INFORMATION:
1.  The first enhancement is to add the keyword [Number of Sections]. This 
keyword occurs before the [Pin number] keyword, and describes the
number of sections (or elements) a package stub is divided into.  It is
a positive integer greater than zero.  Using figure 1 above as an example:

[Number of Sections]  3

2.  The second change is to the [Pin number] keyword.  Currently, this
keyword simply denotes a list of pins numbers and their order.

[Pin Number]
A1
A2
.
.
.
A10

The proposal is to add to the pins listed by this keyword the per unit 
length L/R/C information for each section of the package stub.  This 
information would be listed as follows.

[Pin Number]
A1  Len:0 L: 1.5n, Len: 0.7 L: 8.35n C: 3.34p R: 1.8, Len:0 C:2.0p
A2  Len:0 L: 1.5n, Len: 0.4 L: 8.35n C: 3.34p R: 1.8, Len:0 C:2.0p
.
.
.
A10 Len:0 L: 1.5n, Len: 1.0 L: 6.0n C: 2.5p R: 1.8, Len:0 C:2.0p

     After each pin number comes the physical length of the first 
section (Len:), then the section's per unit length L/R/C.  The Len: 
parameter is optional, as well as the  L/R/C parameters (you'll see why 
in a moment).  If the Len: parameter is missing or it's value is '0', then 
treat the listed L/R/C as a lumped element. Each section description is 
separated by a comma.
     At this point we have all the information required to describe our
simple package example (assume for the moment we are not concerned about 
coupling between pins or package traces).  In our example the bond wire 
is described as a lumped inductor, the package trace is described as a 
transmission line with DC loss, and the pin is described as a capacitor. 
Note that the information is presented in a straight forward and 'natural' 
form; length and the basic parameters of L, R and C. And, since the matrix 
description is not required...

3.  The matrix information now becomes optional.  In other words,
the [Model Data], [End Model Data] and the keywords in between are now
optional and the package description can end with the [Pin Number] keyword.
This may seem radical, but for most IBIS users this makes the whole 
'.pkg' file concept a lot friendlier and usable.

COUPLING:
     Suppose now we DO wish to describe the coupling between package
traces.  The matrix format is used, but we need some way to let
the simulator know that it applies to section 2 of our stub.  The
proposal is to add a 'section' argument to the [Model Data] keyword.

[Model Data] Section 2

     The section argument is followed by a positive integer that refers to
one of the sections defined in the [Pin Number] keyword above.  Note also
that, once a particular section of stub is described using a matrix, the
'self' L/R/C values are included in the matrix and do not need to be 
repeated in the [Pin Number] statement.  This is why the L/R/C values in
the [Pin Number] statement are optional even if a Len: is specified.  
     All the matrix types that have been defined so far are used as 
needed -- the only difference is that now they apply to a section of 
specific length, and the values in the matrix are given as per unit length.
There can be multiple [Model Data]/[End Model Data] keyword per package 
description.

SUMMARY:

In summary, the enhancements are as follows:

     1.  Adding the keyword [Number of Sections]
     2.  Adding Length and L/R/C info to each pin in the [Pin Number]
         keyword
     3.  Making the matrix information optional
     4.  Adding the argument 'Section' to the [Model Data] keyword

     There is one more issue that may arise.  If one has a lot of sections
in a package stub, the description for each pin could run over the 80
character limit.  Because of the difficultly distinguishing between a pin 
number and parameter value, simply allowing a carriage return in the 
middle of a line may not work.  I propose adding the requirement that 
pin numbers MUST start in column one.  If a line is long enough to require 
a continuation line then the continuation line begins with whitespace.

     Since this is an egg, (and a big one at that) I did not try and
formally describe each keyword and the exact rules for usage.  Also,
there are some fundamental technical points about deriving the data for
the matrixes that need to be defined by the forum.  I am saving that topic
for a second egg, after this one has had a chance to digest.

      Best Regards,
      Stephen Peters
      Intel Corp.

---

From: Stephen Peters <[email-masked]>
Date: Tue, 25 Apr 1995 09:47:03 -0700

Hello Kumar:

     Thanks for your comments. You are correct -- what we are trying
to describe is a open ended circuit topology and by incorporating
a full (perhaps SPICE?) netlist description of the interconnection into 
the .pkg  file we would have a general solution.  However, I am 
unsure on one point. How do you describe coupling between transmission 
lines using just a topological description of the circuit?  Does the user have 
to build a circuit where L's and C's are added between all the coupled nodes (and
does this really represent the coupling in the form the simulator tools need
and use) or are the matrixes still required?  If they are required, how do
you indicate which circuit elements the matrix is trying to describe the coupling
between?  Just some food for thought.....

         Regards,
         Stephen

>Kumar Writes:
>
>I have problem with this type of extension to IBIS format . Here we have open
>ended circuit information and we are trying to reinvent a circuit format. 
>The best way to include open ended package information , in my view is in 
>the form of a spice sub circuit. Once you have defined the external terminals 
>and there is a mapping of these terminals to buffer output and device pins, the 
>spice circuit allows you to put any number of transmission line sections, 
>inductances , capacitances and or combination of lumped and transmission line 
>elements. An extension to coupled transmission line sis RLGC matrixes with non 
>zero length.

---

From: [email-masked] (C. Kumar)
Date: Tue, 25 Apr 95 13:12:08 -0400

I alluded to the problem of coupled lines when I said we may need an extension to spice to represent them. The only sure way to represent coupled lines in standard spice today is to break them into sections and represent these sections in terms of circuit capacitances and mutual inductances. This is very unpalatable. However if we are willing to add a coupled line extension to spice, we can represnt these lines is in terms of their short circuit per unit length rlgc matrices.These matrices provide the most compact representation of coupled lines and also many field solvers directly generate these matrices. Following is an example of the essense of this representation. The IBIS contribution will then be the extension to spice to represent coupled lines!!

NTL 1 2 0 3 4 0 L=0.002 rlgc_name=twolines
.data rlgc twolines 
.r matrix
4.01 0
0 4.01
.l matrix
...
.g matrix
...
.c matrix
..
.end data rlgc twolines

Here the key word "NTL" identifies the description as a coupled line . The nodes 1 and 2 represent the input terminals, 3 and 4 rperesent the output and 0 is the refernce terminal. (In this case it is the ground). L=0.002 represent the length. The example here assumes fixed unit (meter for example). The rlgc data immediately follows the transmission line description.

---

From: [email-masked] (Dileep Divekar)
Date: Tue, 25 Apr 1995 11:38:11 +0800

I agree with Kumar that there is no need to reinvent
another format. If IBIS sepcification can make a
provision for specifying a spice subcircuit name
to be attached to a pin or a group of pins, that
may solve this problem.