IBIS Comments and questions about Electrical Descriptions of Boards and Connectors

To IBIS Committee:

Here is an apparently bounced message that was supposed to go out
to the IBIS committee that was not sent. Sorry about the format.
This was how it was received, plus some extra binary stuff at the
end which I deleted. (Hank had indicated some mailer changes.)

Bob Ross
Interconnectix

Dileep,

I am happy that someone is really reading this material. Thank you for
your questions and comments. My response is provided below, following
each one of your questions or comments.

----------
From: owner-ibis[SMTP:owner-ibis@vhdl.vhdl.org]
Sent: Wednesday, November 06, 1996 10:32 AM
To: ibis
Cc: dileep
Subject: Comments and questions about Electrical Descriptions of
Boards and Connectors.

I have some comments and questions about the BIRD regarding the
Electrical Descriptions of Boards and Connectors.

1)
| Note: The simulator must not limit the Number of Pins to
any
| value less than 1,000.
I do not understand why any number should be specified. If the maximum
allowable limit is 1,000 then many high pin count packages cannot be
modeled.
The only reason any number is specified is to prevent an arbitrary
limit from being set by a simulator. For example, it would be a
problem if this value was limited to an 8 bit integer.

2)
|Description: Tells the parser the set of names that are used for the
part's
| external pins and also defines pin ordering. The first
pin name
| given is the "lowest" pin, and the last pin given is the
| "highest".
I do not understand the significance of this. Why is it necessary to
define
pin ordering? The parser needs only the information about pin names.
There needs to be a way for the simulator to match external, or global
pin names to the internal pin names used in the model. This is
especially important in the case of connectors where there are 2 ends
to every contact that need to be appropriately identified and properly
connected to the rest of the system. That is the purpose of this
statement and it is in agreement with the way it is handled in IBIS
version 2.1 (I hope).

3)
| R The series DC (ohmic) resistance of a section, in
| terms of ohms per unit length.
I think in addition to R, specification of G should be allowed. Since
this
is an optional specification, for cases where the dielectric loss is
not
significant, it need not be specified. In fact I would say that we
should
go even one step further and allow an optional sepcification of high
frequency R in addition to the DC value.
I do not see any reason that G can not be included as an additional
option. I do have some concerns about trying to specify a HF R.
        1. First, I would point out that we are dealing with uncoupled models
                at this time and are after fast, first order accuracy.
        2. What frequency would you use for a digital signal and how
                would that R be calculated?
        3. There would be a need to specify a frequency (or bandwidth) for
                any non-DC resistance.
        4. Finally, with respect to connectors in digital signal
applications,
                skin effects are negligible, especially for this first order
                modeling we are pursuing here, and we want the proper
                voltage drop across the connector for any DC circuit.

4)
| A section description begins with the Len subparameter
and
| ends with the backslash (/) character. The value of the
Len, L,
The backslash (/) character mentioned above is actually a forward slash
character. The backslash is \.
Good point! Got me on that one! I think it should be the 'slash' (/),
not the 'backslash' (\). Our syntax experts should check that out.

5)
| A) Len, and one or more of the L, R and C subparameters.
 If
| the Len subparameter is given as zero, then the L/R/C
sub-
| parameters represent lumped elements. If the Len
subparameter
| is non-zero, then the L/R/C subparameters represent
distributed
| elements.
I think the specification should say that if non-zero Len is specified,
then BOTH L AND C MUST be specified. The R (and G) can be optional.
By definition, the physical description of the distributed transmission
line has BOTH L and C.
Another good point. I think this can be fixed by the addition of "and
at least L and C must be specified" to the end of the last sentence.

6)
| B) The first subparameter following the [Path
Description]
| keyword must be 'Pin', followed by one or more section
| descriptions. The path description can terminate in a
node,
| section, another pin or the reserved word, NC.
|
| C) All paths and subpaths (a path between Fork and
Endfork)
| end in a Pin, a Node or NC.
The last sentence in B) and the sentence in C) seem contradictory. B)
allows the path to be terminated in a section also. The only possible
subparameters under the path description are Len, Pin, Node and
Fork/EndFork. I do not see any need to put restrictions on how the path
should end. Also, the need and usage of NC is not clear. Off hand, it
seems that we can do without it. Is it allowed to have another Fork
statement inside a Fork statement before the Endfork?
The NC and the need for a specific end to a path description covers
situations where there may be a stub on a board or a skipped or deleted
pin on a connector where there is more than one pin for a given contact
such as for a shielding plate. I do see your contradiction, however.
 Perhaps the word 'section' should be deleted from B) and paragraph C)
could be eliminated. As far as Fork/EndFork, there was no intent to
limit branching so these parameters can be nested.

7)
| Node pin.reference_designator
This is a minor point, but all the pcb design programs I know, use the
convention reference_designator.pin. Most people are used to seeing
something like U3.17 as opposed to 17.U3.
Again, this is one for our syntax experts. We certainly want to be as
consistent as possible.

Some general comments:

There are cases where a trace forks into two and then the two traces
join
again to form a single trace. How does one describe this?
The re-connect can be accomplished at any pin or node.

It is stated that C is the capacitance to "ground". This assumes that
there
is only ONE ground for ALL the sections of this board as well as all
the
other boards connected to this board by virtue of .eid models specified
in the Reference Designator Map. This precludes the use of this model
for doing ground bounce analysis.
Without distributed ground and power planes, there is only one ground
for a small board or uncoupled connector. If you need a more detailed
model, the board can be described in EDIF format and handled
appropriately. Also, without global interconnect models (ones with
through paths for every contact and no dedicated ground lines) there is
no practical way for any simulator to do ground bounce. Again, please
remember we are only dealing with first order uncoupled models at this
time. They are complicated enough. Coupled models will be dealt with
after we think we can do these so called 'simple ones'.

Since this is supposed to address the full board description, I just
wanted
to mention that there is a tendency (particularly in SIMMs and MCMs) to
add other components on the boards, in addition to the ICs and
connectors. Embedded resistors is an example that comes to mind. Is it
possible to include these components in this description?
I refer you to the last example under the [Reference Designator Map]
keyword. It calls a resistor pack. The .eid model of that resistor
pack could be simply the network of resistors between external pins.

I hope these responses are helpful. Again, thank you for your careful
review of this interim BIRD 36c.

Hank
Received on Fri Nov 8 11:39:06 1996