Subject: Re: EGG for Transmision Line Package Models

From: [email-masked] (C. Kumar)
Date: Tue, 25 Apr 95 11:24:03 -0400

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.

> 
> 
> 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: [email-masked] (Jon Powell)
Date: Tue, 25 Apr 95 09:28:13 PDT

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

In general, I do not find that SPICE subcircuits address the issues
sufficiently. I would be happy to see some good counter-examples however.

jon