BIRD28 Pkg Extension Comments

Stephen Peters and IBIS team:

I believe BIRD28 is very good. I do have a few points for consideration
and improvement and simplification.

(1) I am wondering whether the [Unit Length] keyword is necessary. It opens
up the door to specifying which units are to be acceptable. It is unclear
who would use this feature since the representation is already in terms of
electrical parameters.

(2) As a comment, there is no limit to the number of sections, just as
there is no limit to the matrix size. At this time, it may be premature to
provide any limits since package sizes and complexity are increasing.

(3) The syntax for [Model Data] section xxx and [End Model Data] section xxx
contains the word "section" which seems unnecessary. Some other keywords
in IBIS ([Bandwidth] xxx, [File Rev] xxx, [Manufacturer] yyyy, etc.), which
do not convey header information are based on a single parameter following
the keyword or other types of data structures composed totally of data and
no "subparameter" text. To maintain some syntactical consistency, it might be
better to introduce [Section Data] xxx and [End Section Data] xxx and not
create a dual mode way of defining [Model Data] and [End Model Data] with
an unneeded subparameter.

(4) The main comment I have concerns some syntactical refinements to the
[Pin Numbers] format.

The example in the BIRD is used as a basis for comments:

|-----------------------------------------------------------------------------
[Pin Numbers]
A1 Len:0 L:1.2n, Len:1.2 Matrix, Len:0.47 L: 8.35n C:3.34p R:0.01
A2 L:1.2n, Len:0.7 Matrix, Len:0.47 L: 6.21n C:3.34p R:0.01
A3 , , Len:1.3 Matrix, ,
A4 Len:0 L:1.2n, Len:1.0 Matrix, Len:0.47 L: 8.35n \
  C:3.34p R:0.01
A5 Len:0 L:1.2n, Len:1.2 Matrix, Len:0.47 L: 8.35n C:3.34p R:0.01
| .
| .
| .
A10 Len:0.1 1.2n, Len:1.2 Matrix, Len:0.47 L: 8.35n C:2.2p R:0.01

(a) Three new characters are introduced ("," ":" and "\") all of which
can exist as [Comment Char] choices. To introduce these would also require
an exclusion of these as comment character choices.

(b) The line continuation method using "\" is inconsistent with the method
used for [Full_matrix] and [Banded_matrix] data. Since the number of
sections is known, it would be more consistent to rely on a similar
counting method. This can be achieved through a termination
character for each section. I would propose using "/" since it is already
disallowed as a comment character in place of "," and also at the end of
the last section. The extended line ends when all of the "/" entries
are encountered.

(c) Based on the example, there is implication that no white space is
permitted after the subparameters "Len:", "L:", "C:", "R:". Is ":" part of
the subparameter or is it a separator. Is Len : 0 acceptable?. Is Len:123
acceptable where there is no space between the subparameter and the data?
I would propose using "=" in place of ":" and permit white space or no white
space on either side of "=" in the familiar manner that "=" is used.

(d) The syntactical flexibility using ", ," to zero out a section creates
parsing complication and encourages some formatting sloppiness with no
necessary technical benefit. I would encourage a fixed, more rigid
structure such that each section must start with "Len" and end with "/".
Shorted, zero-length sections would still require the Len=xxx or Len=0, but
contain no other entries. Similarly, lumped element begins with Len=0 and
per unit length elements begin with Len=xxx as the designate beginning. The
"/" always terminates each section.

With these comments, the revised example may look like this:

|-----------------------------------------------------------------------------
[Pin Numbers]
A1 Len=0 L=1.2n / Len=1.2 Matrix / Len=0.47 L= 8.35n C=3.34p R=0.01 /
A2 Len=0 L=1.2n / Len=0.7 Matrix / Len=0.47 L= 6.21n C=3.34p R=0.01 /
A3 Len=0 / Len=1.3 Matrix / Len=0 /

A4 Len=0 L=1.2n / Len=1.0 Matrix / Len=0.47 L= 8.35n
   C=3.34p R=0.01 /

A5 Len=0 L=1.2n /
     Len=1.2 Matrix /
     Len=0.47 L= 8.35n C=3.34p R=0.01 / | Another possible grouping
| .
| .
| .
A10 Len=0.1 1.2n / Len=1.2 Matrix / Len=0.47 L= 8.35n C=2.2p R=0.01 /

(e) Also the syntax should support one of "L", "C" and "R" in any order and
with any or all of these optional. This is consistent with the order
flexability of L_pkg, C_pkg and R_pkg and of L_pin, C_pin, and R_pin.

(5) As a final note, there is a practical, technical trap associated with
Matrix and Len. A primary assumption with respect to matricies of parameters
per unit length is that the coupling matrix applies to physical, parallel
sections that are of the SAME length.

Suppose this is a portion of the package layout:
    ____________________
B1 |___________________|
    ______________________________
B2 |_____________________________|
    __________
B3 |_________|

    | 1 | 2 | 3 |

The specification might be:

B1 ... Len=2 Matrix / ...
B2 ... Len=3 Matrix / ...
B3 ... Len=1 Matrix / ...

An APPROXIMATE way to handle the analysis at B2 is to assume ALL nearby
sections are of equal length, Len=2. The matricies reference by Matrix
would be scaled by 2 assuming that they are derived using the cross section
topology at "1". You do not scale rows or columns of "Matrix" matricies
individually by the respective actual lengths.

A more accurate way of handing this would be to use Len=1 and the "Matrix"
matricies for the first parallel segment, derive a DIFFERENT cross-section
"Matrix" set, scale by Len=1 to be cascaded. Unfortunately, I understand
that the "Matrix" set for the second section cannot be derived from the
original "Matrix" set. The third section would be treated as a single,
uncoupled line, using another set of parameters that are NOT available from
the original "Matrix" set.

So, even though there is individual length resolution, the information
provided is not sufficient to exactly process these individual differences.
An AVERAGE Len for the nearby topology should give a very good approximation
when the lengths are approximately the same, and be less accurate when there
are significant differences.

Bob Ross,
Interconnectix, Inc.
Received on Tue May 30 18:56:40 1995