Again, these are comments from one who doesn't use the s2ibis*
utility.
> 1. Inputs with pull-up resistors?
The two Clamp tables, [Gnd Clamp] and [Power Clamp], are supposed to
represent ALL currents when the device is not driving. For an
input-only pin, that's everything, including pullup resistors.
Don't let the "Clamp" in the name fool you into thinking they are
only for clamps; they aren't.
The reason there are two clamp tables rather than one, is that the
currents into a real power clamp diode are dependent on the power
supply voltage; they track it as it goes up and down. The easiest
way to do that in a model is to split the current into two tables
and make one of them Vcc-relative, which is exactly what IBIS does.
Because the currents into a pullup resistor (or FET) connected to
Vcc, also track Vcc as it goes up and down, these currents
(associated with the pullup resistor/FET) also technically should
go in the [Power Clamp] table.
By the same token, if you had a pulldown resistor/FET, all of its
currents should technically go in the [Gnd Clamp] table and none of
it in the [Power Clamp] table.
Now if you take a real part, or a SPICE model as a black box, and
you sweep the input voltage and measure the current, you will get
one curve, which you want to split into [Gnd Clamp] and [Power
Clamp] tables. With no further information, i.e., treating your
device as a black box, you can't tell how much is due to pullups,
pulldowns, transistors, clamp diodes, etc. About all you can do is
split the curve at Vcc and put everything below Vcc in the [Gnd
Clamp] table, and everything above Vcc in the [Power Clamp] table.
This is probably what s2ibis* does.
On the other hand, if you have a way to separately measure or
characterize JUST the pullup FET current, and if you want to be
technically correct (which gives you a slightly more accurate IBIS
model), then what you should do is (a) subtract the pullup current
from the [Gnd Clamp] table since the pullup contributes no current
that is not Vcc-relative, (b) extend the [Power Clamp] table to both
sides of Vcc, probably all the way from -Vcc to 2*Vcc, and (c) put
the currents you subtracted from the [Gnd Clamp] table into the
[Power Clamp] table.
Just make sure that when you add the [Gnd Clamp] and Vcc-adjusted
[Power Clamp] currents, you always end up with the total current
into the input pin.
Whether you need to do this, depends on the magnitude of the pullup
current. If it's a 100k resistor, the currents are in the 50uA
range. The "error" happens only when Vcc is not the same as it was
when you ran s2ibis* (or measured a real part). If the difference
in Vcc is about half a volt, and the MOSFET looks like a 100k
resistor, the error is around 5uA. Is that enough to worry about?
You decide.
(On the other hand, half a volt can make a HUGE difference with a
real clamp diode.)
> 2. My second question pertains to how one would set up an s2ibis2 [pin]
> list for creating a single bidirectional pin? (in a similiar fashion as
> the tri-state pin is modelled in example two that came with s2ibis2
> utility)
The entry in the [Pin] list should point to a model_name that is
bidirectional.
For example, in the IBIS spec "ver2_1.ibs":
> [Pin] signal_name model_name R_pin L_pin C_pin
> |
> 1 RAS0# Buffer1 200.0m 5.0nH 2.0pF
> 2 RAS1# Buffer2 209.0m NA 2.5pF
> 3 EN1# Input1 NA 6.3nH NA
> 4 A0 3-state
Pin 4 is probably a bidirectional pin. Elsewhere in the IBIS model,
the "[Model] 3-state" section would define its characteristics.
Bidirectional (I/O) just means tri-state with input capabilities.
Thus, Vinl and Vinh must be specified.
> 4. Monotonicity warnings: How concerned should I be with these?
Monotonicity warnings are only warnings. They are not errors. Note
that IBIS does not require monotonicity! IBIS talks about non-
monotonicity simply because some simulators don't like it; so it's
good to know at the time you create your models.
> {paragraph quoted from IBIS v2.1 spec}
>
> But the [Pullup] and [Pulldown] Curves that I generated were generated
> using s2ibis2, not measured on the bench. What should I do about the
> monotonicity warnings?
The paragraph you quoted from the IBIS spec applies equally to
SPICE-generated models, as it does to lab-measured models. It just
happens to have been written with a bias toward lab measurements.
The process of creating pull-up and pull-down curves that are "the
difference of the 3-stated and the enabled buffer's curves" is done
regardless of where the data comes from. s2ibis* does it.
Don't worry if your individual tables are non-monotonic. Look at
the overall curves (either the swept data before being picked apart
into IBIS tables, or after combining them back together again). If
these are monotonic, don't worry.
(It's unfortunate that ibischk* doesn't bother piecing the curves
back together before checking for monotonicity ... and equally
frustrating that the IBIS spec actually instructs ibischk* and
any similar program to NOT piece the curves back together! How
bass-ackwards!)
IBIS models ought to be run through some tests on a simulator before
releasing them. If there were monotonicity problems to worry about,
that MIGHT catch some of them. (But it's no guarantee, since some
simulators don't care, while others do.)
Regards,
Andy
Received on Fri Jun 6 06:58:56 1997
This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:53:46 PDT