I agree with your statements below, but have issues with the Proposed
Changes within the BIRD itself.
Usage Rules: For each pin listed, a simulation node of the signal_name
connection shall be used as the reference node of measurements at the
pin_name node when comparing simulation results with model thresholds.
We are moving backwards from the progress and defaults in DUT_ref_term. We
should delete "when comparing simulation results with model thresholds".
The 0.0 V reference is technically not correct for certain practical cases.
I assume it is legal to declare a non-zero Vcc as the reference (even if
there are 0.0 V rails. Even this is not a complete solution.
Under Other Notes:
During simulations, unless C_comp is optionally split into the other
reference voltages, C_comp shall be connected between the buffer I/O
terminal and the reference node.
IBIS already has a solution by splitting C_comp. Changing the existing
(bad) C_comp to just go to node that happens to have a 0.0 V rail is
contrary to the actual capacitance distribution for some technologies and
Model_types. The dominant internal electrical circuity for ECL/PECL and
Model_type Open_source is between the Pullup_ref and IO. Therefore the most
accurate connection for C_comp is to the Pullup_ref. The capacitance to the
Hi-Z Gnd_clamp_ref through a "reverse-biased clamp diode" is smaller. So
having C_comp defaulting to a rail that is 0.0 V is not always technically
correct and is a step backwards.
However, one unstated assumption is that during simulation, all of the
applied rail voltages relative to each other should be approximately
constant (e.g. 1005.0 and 1000.0 for a 5 V buffer). Otherwise the driver
simulation might be outside of its predefined PVT model corner conditions.
Then the V(IO) could be shifted relative to any rail that is declared a
reference (whether or not it is for a 0.0 V rail), and the shifted voltage
could be used for threshold testing This assumption would simplify
I have other issues (format and content) with the BIRD, which I will defer.
It should be emphasized that the BIRD is intended for improving power-aware
simulations since IBIS models already work well as is, and [Pin Mapping]
already helps with some PI issues.
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Tuesday, June 28, 2016 3:28 PM
Subject: [ibis-macro] Re: Pin Reference 5
I would like to point out the third paragraph in the "DEFINITION OF THE
During a simulation that uses IBIS Models, the IBIS specification is not
clear what node should be used as the reference node for the voltage att the
buffer I/O. This is not an issue when the simulator supplies rail voltages
Pullup_ref, Pulldown_ref, Power_clamp_ref, Gnd_clamp_ref and Ext_ref
("*_ref") to a model relative to the simulator reference node (e.g. Node 0)
that are same as the reference voltages ("[*Reference]") supplied to the
buffer when generating the IBIS Data (Device Under Test or DUT).
As long as a simulator supplies the [* Reference] voltages to the *_ref
terminals relative to simulator Node 0, then simulator Node 0 is the
reference node for correct measurements of the I/O pad terminal of the
This is what you referred to today as "these models exist and they work
today". And you are correct because they are only required to assume either
DUT conditions or ground referenced power integrity simulations.
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Tuesday, June 28, 2016 4:04 PM
To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
Subject: Pin Reference 5