Subject: BIRD9 AND RSERIES COMMENTS

From: [email-masked] ( Bob Ross)
Date: Tue, 15 Mar 94 17:15:43 PST

To IBIS Committee and Stephen Peters and Bob Ward

Stephen, you have raised a very significant point in asking the question
"How do we specify what pins in a resistor package are the 'common' or
associated pins?"  

Secondly, you raised some questions on how to connect a straight thru resistor
in a DIP or SIP pack.

The simple answer is that IBIS Version 1.1 and proposed extensions including
BIRD9.1 DO NOT FULLY support "associating" a [Model] of one pin to any other
pin, even if that pin is a POWER or GND pin.  The connectivity function is
EXTERNAL to IBIS.  In fact, all of the POWER and GND pins can be removed
from any [Component], and it will still pass IBIS_CHK

On one hand it would be nice to enlarge IBIS to include power connectivity
information to pass into the [Model].  Other types of net connectivity 
might also be nice, but may actually be less applicable for long trace
connection problems where the geometrical layout is the dominant 
consideration, not just the connectivity.  For example, a DIP or SIP
resistor pack series terminator may be designed with matching pin alignment
to a driver component to be connected to AND positioned next to the driver.  

The partial solution [RSERIES] terminator proposal in BIRD9.1 is intended
for that situation as a minimal cost APPROXIMATION of a series terminator
by positioning it in series with R_pin in the driver [Model].  As Will Hobbs
pointed out last Friday, the package elements may distort the analysis 
because this series element is on the wrong side of the package.  However,
the dominant consideration is that it provides a termination to a long
net and the degradations may be second order relative to the overall analysis. 

In general, IBIS itself does not provide arbitary connection mechanisms
of any [Component] in a netlist specification sense.  It just provides the
[Pin] interface through which connections can be made external to IBIS to
ONE pin which has a [Model].  Extentions to IBIS either through [Model] or
another [Pin_Mapping]_type table could be considered to handle specific
straight thru resistor topologies within packages.  Perhaps other elements
could be handled as well.

With respect to [Model], the [Voltage reference], GND, and optional other
reference voltages (e.g., [POWER_CLAMP reference] per BIRD 3) provide a
set of Voltages which can be used as rails to reference the VI data tables
and [Ramp].  So, for simulation, an internal model can be constructed with
respect to these specified VOLTAGES.  The proposed [Rgnd] and [Rpower]
elements would also be connected to VOLTAGES.  Any assignment of these
VOLTAGES to the [COMPONENT] pins for POWER and GND is done EXTERNAL
to IBIS.  In specific cases with one POWER and one GND, one can assume
a connection.  Through such a connection, one could override the internal
reference voltages with externally applied voltages. 

The [Pin_Mapping] keyword per BIRD5.2 offers another opportunity to do pin
association.  It may work very well for resistor packs used as terminators
to "gnd" or to "pwr", or resistor packs with parallel terminators to both
"gnd" and "pwr" to associate through the GNDBUS or PWRBUS names the 
[Model] connection and the rails.  To date, this keyword is optional and
cannot be guarenteed to be provided in the [Component].  Furthermore,
this keyword would have to be expanded by two columns to include
the multiple rail connection possiblities that exist per BIRD3 to fully
support connections of I/O and Output Models to any of the supply pins. 
For example, the [Pullup] may be referenced to the 3.3V rail, but the
[POWER_clamp] may be referenced to the 5V rail.

Bob, regarding a non-linear internal series resistance, my first approach
would be to try to absorb it or at least the non-linear portions of it
into the [PULLUP] and [PULLDOWN] tables as a first order APPROXIMATION to
its effect.  There may be some absortion in to the clamping tables as well.
I would hope to avoid if possible the need for another set of VI tables,
especially one that may be hard to extract.

Thank you for the comments in these areas.  I feel I have just touched the
surface of some larger issues.

Bob Ross
Interconnectix, Inc.