Re: EGG for Transmision Line Package Models

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.
>
>
>
Received on Tue Apr 25 08:30:08 1995