Re: Voltage Ranges

Arpad and IBIS Committee:

Here are some comments to respond to your last note on the above subject.

1. As we discussed, the 100 point limit still exists on some vendor's
controlled voltage and current sources. What you are saying is that, if
necessary, tables with more than 100 points could be reduced to 100 points
or less.

2. I think it is permissible and useful to extend the voltage ranges
beyond the IBIS limits on either direction to comply with real, practical
considerations, regardless of the interpretation or intent of the
"Points for each curve must span the voltages listed below" statement.
Going beyond the span poses no technical problem with Spice based controlled
elements nor with data table based elements. I also had a situation requiring
modeling a weak, internal non-linear pullup element for an Open device which
I resoved using an extended [Power clamp] table. So I fully support releasing
any model that have tables going beyond the implied limits.

3. I do not think it is necessary to require extending the IBIS ranges
for all tables to the same range because for most devices, it is of no
practical impact when the currents are equal or nearly equal to 0 ma.
Only when there is a need should an extension be considered.

4. By providing tables referenced to various Voltage rails, you along
with others did provide an important architectural contribution for
using IBIS to transfer model information for current and future needs.
The issue of range limits are not dictated by architectural limitations or
acquisition of data, but by some practical considerations needed to
directly map the data into certain simulator constructs. In all cases,
care needs to be taken to decompose any sources of current into the
appropriate tables and to avoid double entries of the same current.
Even the "min" and "max" tables may have some minor, inconsequential
violation of this with a .5 V overlap when Vcc = 4.5V and a .5V gap when
Vcc = 5.5V for a -5V to 5V span of the [GND_clamp] table.

Bob Ross,
Interconnectix, Inc.
Received on Sat Aug 20 14:20:15 1994