Hello, I have been toying around with IBIS for several weeks now, and am
starting to feel a little bit more comfortable with it, but I am still
new to it, and there are still many questions that I have.
I asked the IBIS mail list previously about pullup input pins, and the
following response
made me wonder more about exactly how to model input pins with pull-up
mechanisms.
> 1. Inputs with pull-up resistors?
> Are these treated in any special way? (ie: different than that of a
> normal input pin?)
>>For general IBIS modeling purposes, I think not. If the pull-up
>>resistors are a permanent part of the input structure (not switchable
>>on and off on-the-fly), then they just become a part of the [GND Clamp]
>>and [POWER Clamp] V/I curves.
>> Pullup resistors would appear in the Clamps. They are not separated
>> out. So there is probable that they will be double counted.
>> For Pullups, the contribution in the [Gnd Clamp] table should be
>> should be subtracted. The [Power Clamp] table should be extended to
>> from 0 to Vcc (and possibly linearly extrapolated to 2Vcc) to provide
>> the separate Pullup resistor component.
>>> How about in S2ibis2 utility? When S2ibis2 generates the tables=20
>>> automatically, are you saying that the tables will be incorrect for=20
>>> inputs with pull-ups on the input? Does this mean that I would have=20
>>> to manually change the IBIS file after the s2ibis2 utility is run? Or=20
>>> is there a way to correct for this in the s2ibis2 command file (*.s2I=20
>>> file)?
>>>>The capability of separating the pullup contribution using s2ibis2 was
>>>>not put in. Yes, you have to do this separately. The ranges of [Gnd
>>>>Clamp] from -Vcc to Vcc, and [Power Clamp] from Vcc to 2 Vcc actually
>>>>work only if the currents of both are at "0 mA" at Vcc and for some
>>>>simulators, their linear Extrapolation remain at 0. Otherwise the
>>>>tables should go the full range from -Vcc to 2 Vcc each. Some Spice
>>>>models for ASICs have a separate control to add Pullups or Pulldowns.
>>>>Again, the capability of dealing with this issue was not put into s2ibis2.
>>>>As a practical matter, most of the pullup contribution is low (e.g., 75
uA).
>>>>So for most analysis, the pullup contribution error is small.
I am dealing with SPICE netlists of an input configuration that uses
MOSFETs to provide the pull-up, not 'actual' resistors. Just to make
sure I am completely clear on the matter, I would have to run s2ibis2 on
the netlist file, and then go back and edit the resulting IBIS file
manually, exactly what subtraction and manipulation would I have to
perform on the clamp tables?
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)
3. Following up on that point, I'm also wondering, when you generate
IBIS models for a whole component, do you use a CAD package to assemble
the individual pins (dummy models)?
I ask this because, at the moment I am thinking of the following
strategy of making an IBIS model for a component, and would appreciate
your comments on this:
component --> break down into BASIS SET of types of pins
--> create a simple IBIS model for EACH member of the
BASIS SET of pins, using s2ibis2 and the
particular pin's
SPICE netlist representing the I/O cell structure.
(each pin type's .s2i file will be really simple,
like
the examples provided with the s2ibis2 utility.)
--> import 'simple' INDIVIDUAL IBIS pin models into a higher level
graphical CAD package, in a modular library
fashion (the pin
models, once created can be used and reused
easily)
--> attach package model (containing data such as
mutual inductances between every pin, etc.)
by linking individual pin models created earlier
to pins on the component package
--> CAD program then creates the finished IBIS file
for the component,
which is more error-free, than if created by hand.
4. Monotonicity warnings: How concerned should I be with these? I
found these when I ran ibischk2 on an IBIS model
for a simple tri-state driver created using s2ibis2. It gave the
following message:
Checking pt5t01.ibs for IBIS 2.1 Compatibility...
WARNING (line 57) - Pulldown Maximum data is non-monotonic
WARNING (line 63) - Pulldown Typical data is non-monotonic
WARNING (line 69) - Pulldown Minimum data is non-monotonic
WARNING (line 155) - Pullup Maximum data is non-monotonic
WARNING (line 157) - Pullup Typical data is non-monotonic
WARNING (line 164) - Pullup Minimum data is non-monotonic
Errors : 0
Warnings: 6
File Passed
The IBISv2.1 spec says the following:
| The clamp curves of an input or I/O buffer can be
measured
| directly with a curve tracer, with the I/O buffer
3-stated.
| However, sweeping enabled buffers results in curves
that are
| the sum of the clamping curves and the output
structures.
| Based on the assumption outlined above, the pull-up and
| pull-down curves of an IBIS model must represent the
| difference of the 3-stated and the enabled buffer's
curves.
| (Note that the resulting difference curve can
demonstrate a
| non-monotonic shape.) This requirement enables the
simulator
| to sum the curves, without the danger of double
counting, and
| arrive at an accurate model in both the 3-stated and
enabled
| conditions.
|
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?
I'm still relatively new to IBIS. I would appreciate any comments you
can offer. I thank you all for your help in the past few weeks, and
hope that you can help me again. I have only approx 2 months left now
to finish creating IBIS models for all components at my company, so any
help at all is always greatly appreciated.
Best Regards,
Roland
******************************************
Roland Chang ext. 2647
PMC-Sierra
Applications Department
105-8555 Baxter Place
Burnaby, BC
V5A 4V7
Tel: (604) 415-6000
email: chang@pmc-sierra.bc.ca
******************************************
Received on Thu Jun 5 14:37:21 1997
This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:53:46 PDT