All,
I think we are getting into the weeds on dotting the eyes and crossing the
tees on the Terminal records. Without getting into the parsing of the
Terminal record, the following is an introduction that gives the reasons
we came up with this syntax, and might belong in the introduction to the
IBIS Interconnect BIRD.
A complete IBIS File Interconnect Model would be an IBIS-ISS subckt with
terminals at all of the [Pins] of the component and terminals at each of
the [Model] (Buffer) instance terminals (A_Signal, A_puref, A_pdref,
A_pcref, A_gcref).
There are also valid subset models of this model for specific [Pin]s, or
specific rail voltages. It is common practice to generate models assuming
all of the rail Buffer terminals are shorted and/or all of the rail [Pin]
terminals are shorted. To do this we can also associate a Terminal with a
rail voltage name (Signal_name on Power and Ground Pins).
Interconnect models are generated from different CAD data bases for the
On-Die Interconnect and for the Package Interconnect. The new packaging
methodology allows the model maker to combine these models into a single
model, or separate models for the On-Die Interconnect and the Package
Interconnect. This is done by allowing Terminals at the Die Pad (Die
Package Interface).
It is also common the generate coupled models for a slice of a bus with
one victim Pin and multiple aggressor Pins. A Terminal can have a flag if
it has the most amount of coupling with other Terminals (Victim Flag).
Generating interconnect models for generic connection on the Die or
Package is often easier for chip or package designer. It is therefore a
convenience to associate an interconnect model with all of the Pins that
use a [Model]. So Terminals can also reference the Buffer terminals for
all Pins associated with a [Model]. These are called Pre-Layout models,
but they can be quite accurate for Post-Layout simulations as well.
Walter
Walter Katz
<mailto:wkatz@xxxxxxxxxx> wkatz@xxxxxxxxxx
Phone 303.449-2308
Mobile 303.335-6156
