Rev3.2
A compilation of IBIS related FAQ(Frequently Asked Questions). Issues related to Modeling, Simulations, Support, Features and others are addressed here.
| IBIS | SPICE-to-IBIS |
A compilation of s2ibis related frequently asked questions. This section was borrowed from the man pages generated by North Carolina State Univ.
The "Golden Parser" is a program called ibischk4 that parses the model file to verify that the file conforms to the IBIS specification. The executable code is publically available as a free download. The parser is developed by contractors for the IBIS Open Forum. All model files must pass the parser before a model can be released. The IBIS forum recommends using the latest version of the parser even though the model may be an older version.
The parser is freely available in object code format for many
platforms, and can be downloaded from 'ibischk4'
The Golden Parser source code is also available from the GEIA
IBIS committee for a fee. In addition to checking syntax, it creates data structures
from model data that simulators can use.
The IBIS Golden Parser source code, V4.x may be licensed for
$2084 regardless of GEIA IBIS Open Forum membership status.
In any case, submit a request to: 3: Where can I find the IBIS Golden Parser ?
GEIA
2500 Wilson Blvd.
Arlington, VA 22201
(703) 907-7554 (phone)
(703) 907-7501 (fax)
Enclose a check in
the appropriate amount made out to GEIA. GEIA will take care of distributing the
source.
You can access
IBIS model directly from the ANSI/EIA-656A site by clicking on 'Models' This provides
all the websites known today from semiconductor vendors providing IBIS models.
Yes, by using the min, max current with the proper min, max
ramp rates, the Best, Typical and Worst case can be modeled. 5: Can IBIS model best case, worst case models ?
6: Can IBIS model SSO(Simultaneous Switching Output) ?
IBIS as a model, has the key parameters required to model an SSO event. These are mainly the package inductance, other associated parasitics and the number of buffers switching. IBIS specifies R, L and C in matrix format and the use of a matrix for the inductance accounts for the "loop"inductance i.e. the mutuals between the pins. Specifying the mutual inductance is necessary to account for SSO event simulation.
[Pin Mapping]
keyword was specifically defined in IBISv4.0
to handle SSO defination. Simulating SSO depends on the model provided and the
simulator used.
Simulation accuracy is greatly enhanced by the "beyond-the-rail"
data. Overshoot and undershoot generally fall within this range, and the range
encompasses the forward-biased regions of protection diodes often used on buffers.
Also, reflections caused by improper terminations can produce voltages at the
driver/receiver terminals from -Vcc to 2Vcc. The drivers and receivers, therefore,
need to be modeled over this entire range.
Since measurement of diodes over the entire range is often
not possible, measurement over a reasonable range and extrapolation of data
to the end-point values is permitted to produce IBIS models.
Most non-SPICE based simulators will do their own extrapolation
to get to the end point. Most Spice simulators truncate data to the table end-points.
The -Vcc to 2Vcc range ensures consistent performance for both types of simulators.
7: Why do we need to sweep -Vcc to 2Vcc ?
IBISv2.1 can model RTC(Rise Time Controlled), GTO(Gradual Turn
on) or Slew rate controlled outputs. These are defined under [Rising Waveform]
and [Falling Waveform] keywords.
The waveform tables can also serve as "golden waveforms" to
check simulator accuracy, since the load conditions that produced the tables
are specified. That is, the simulator should produce these waveforms when the
model is connected to the specified loads. See IBISv4.0
specification for more details. 8: Can IBIS model GTO(Gradual Turn On) or Slew rate controlled
outputs ?
Yes, IBIS contains the the package parasitic information necessary
to simulate ground bounce. Even though the data is available within the model
file, not all simulators may be able to use it to simulate ground bounce. Refer
to your respective simulator for support. 9: Can IBIS model ground bounce ?
No, the present IBISv4.0
does not provide timing information. It does allow defination of timing
test loads that are required by SI simulators to report correct Flight Time
Delay numbers. 10: Can IBIS provide timing information ? ex.propdelays,
skew etc
11: Can IBIS model be used to measure propagation delays
?
IBISv4.0 does not support measurement of propagation delays. IBIS is mainly used to simulate transmission lines and analyze signal integrity issues.
Following is a list of the output model types supported by
IBISv4.0 :
Input, Input_ECL, Output_ECL, I/O_ECL
I/O, I/O_open_drain, I/O_open_sink, I/O_open_source
Input_ECL, I/O_ECL
Terminator
Output, 3-state, Open_sink, Open_drain, Open_source
Refer to IBISv4.0
for a full explanation of the Input/Output structures. 12: What type of Input/output structures are supported by
IBIS ?
The IBIS standard specifies that the pullup and pulldown curves
contain pullup and pulldown data ONLY, i.e. in the region where the clamp diodes
are active the current due to the clamp diodes must be subtracted from the pullup/pulldown
current. This is where the non-monotonic curves come from -- at the extremes
of the I/V curves where you are subtracting a large diode current from the combined
diode/on-state-IV curve. In practice, a simulator sums the two currents together
(power clamp and pullup or gnd clamp and pulldown) thereby making the result
monotonic. 13: It is rightly pointed out that the pulldown and pullup
characteristic for tristate outputs may be non-monotonic. The standard says
that this can happen in at most one place. The i-v characteristic may then locally
have a negative resistance. Will this not pose a problem to simulators ?
No. The effects of a pad or die resistance are accounted for
in the I/V curves. 14: Is there a provision for specifying a pad or die resistanc
e i.e R_comp in addition to C_comp?
IBIS does not provide an Input pulse specification for deriving
Ramp rates (and Waveform Tables). A reasonable guideline is to mimic actual
conditions for which the device would be used. Therefore it is probably better
not to mandate a specific condition. The voltage swing should be appropriate
for the technology, e.g., 0 to 5V for CMOS and about 0 to 3V for TTL. A signal
faster than the expected Ramp rates is my preference, although a case could
be made to provide a response that mimics the data book input ramps specified
for timing tests. Possibly a 50 Ohm series resistance approximating the pulser
source impedance and trace environment to the device input should be included.
However, since the actual thresholds are narrow (several 100 mV), the Ramp rates
and Waveform tables should not differ significantly for any reasonable, appropriate
Input. 15: The standard does not explicity specify the nature of
the input ramp in obtaining ramp rates. What should be the input rise time as
well as the high and low values of the input pulse?
To participate in IBIS discussions, send your email address
to ibis-request@vhdl.org . You will be added to the IBIS reflector, which
is a mail group used by IBIS partipants to exchange ideas and data. Notices
of upcoming teleconferences, agendas, and meeting minutes are also distributed
through the IBIS reflector. 16: How do I become an active participant in IBIS activities?
To report ibischk4 parser bugs. Fill out: '
The Bug Report Form.' This form resides on vhdl.org along with all other
reported bugs.
To report s2ibis2 and s2iplt bugs, use the Bug Report Forms:
17: How do I report a IBIS Golden Parser or a SPICE-to-IBIS
bug ?
'The s2ibis2 Bug Report Form.'
You may E-mail
the completed forms to: 'ibischk-bug'
The IBIS Open Forum
is the industry organization responsible for the management of the IBIS
specification. The Open Forum meets every three weeks by teleconference.
Membership is open to all interested companies. Paid member companies
may cast votes regarding specification changes and approvals, financial matters,
election of officers and other organizational issues involving the Open Forum.
Dues are US $750 per year. Membership dues go directly to maintain the organization's
web site, pay for specification balloting, legal and bookkeeping services and
the like as provided by our parent organization, the GEIA. The Open Forum
also holds IBIS Summits several times per year around the world, to give our
members an opportunity to meet face-to-face and exchange technical information
and elect officers. Summit announcements and presentations are posted on our
web site; summit activities are also financed through member dues and sponsorships. The IBIS Open Forum
is an official subcommittee of the GEIA
and conducts its operations according to the GEIA
Manual of Organization and Procedure. Copies of this document are available
through the GEIA. If you are interested
in joining the IBIS Open Forum, please contact the IBIS
Open Forum chair or any of the IBIS Officers. The IBIS Open Forum
is also responsible for the ibischk IBIS Golden Parser. The golden parser is
a syntax checking program to aid the development and verification of IBIS data
files. Executables, compiled for a variety of operating systems, are available
free of charge through the IBIS
website. The Open Forum
also makes the source code of the ibischk
Golden Parser available through a paid license. Licenses are separate from
Open Forum membership; member and non-member companies alike may purchase a
parser license at the same cost. The current cost of a parser license in US
$ 2500. A parser license entitles the purchaser to receive and use the source
code in their own products. A license also entitles the purchaser to both the
current parser code and all minor revisions within the same major revision of
the specification. For example, current purchasers of the ibischk version 4
parser source code will receive all upgrades to support IBIS 4.2, 4.3 etc. up
to but not including the IBIS 5.0 specification. The license agreement is available
for review on the IBIS website. Parser license
fees are used exclusively for development of parser source code upgrades. Parser
code development is externally contracted by the Open Forum through an "open
bid" process. The current version
of ibischk is 4.1.1. If
you are interested in purchasing a license, please
contact the IBIS Open Forum chair or
any of the IBIS Officers. In addition to
the IBIS Specifications,
the IBIS Open Forum has recently introduced the IBIS
Interconnect Modeling (ICM) Specification, which establishes a standard
behavioral means of describing interconnects, such as connectors, cables and
printed circuit traces.18: How do I become an IBIS Forum Member ?
19: How do I purchase the source code of the IBIS parser
?
20: What is the ICM and is there a parser for ICM
?
An ICM parser, icmchk1, is available. As with IBISCHK4, the source code of icmchk1 is available through a paid license. Licenses are separate from Open Forum membership; member and non-member companies alike may purchase a parser license at the same cost. The current cost of a parser license in US $ 1000. A parser license entitles the purchaser to receive and use the source code in their own products. A license also entitles the purchaser to both the current parser code and all minor revisions within the same major revision of the specification. For example, current purchasers of the icmchk version 1.1.1 parser source code will receive all upgrades to support ICM 1.2, 1.3 etc. up to but not including the ICM 2.0 specification.
The icmchk1 license agreement is available on-line.
ANSWER:
There are several common problems that cause s2ibis to fail to run.
The most common problem is that your PATH environment variable does not
include the directory in which you have the s2ibis executable located.
To check for this on UNIX systems, type:
which s2ibis
at the command prompt in the directory in which you want to invoke s2ibis.
If the system responds with:
s2ibis: Command not found.
then this is your problem. Move s2ibis to a directory in your PATH.
If your operating system can find s2ibis, and you get any error
message that does not start with:
s2ibis:
then there is a really big problem. Either your executable is for
the wrong type of computer or it has been corrupted somehow. Go to
the directory that the executable is in and type:
file s2ibis
If you get something like:
s2ibis: mipsel demand paged executable - version 2.10
or:
s2ibis: sparc demand paged dynamically linked executable
or:
s2ibis: executable (RISC System/6000 V3.1) or object module
it should work OK, so if it doesn't it must be corrupted. If you get
something like:
s2ibis: data
your operating system doesn't think s2ibis is a program, so it is
probably an executable for another type of computer. Copy the correct
executable from the S2IBIS/bin directory into a file named s2ibis in
a directory listed in your PATH environment variable. The executables
are in the S2IBIS/bin directory, and have the machine they are intended
for in the suffix. Thus s2ibis.sparc is for Sun SPARCstations, etc.
s2ibis
runs, but no .out files are created, and the model is incomplete. What is the
matter?
ANSWER:
s2ibis is probably having trouble locating your SPICE program. If
you do not put one of the following lines in your s2ibis input file header,
s2ibis will try to use Berkeley SPICE 2 (using the call spice infile outfile):
*[Spice] 3
*[Spice] P
*[Spice] H
These lines cause s2ibis to try to call SPICE3, PSPICE, and HSPICE,
respectively.
If you have specified the correct version of SPICE, and
s2ibis still can't find it, it may be because your PATH does not include
the directory that your SPICE executable is in, or because the name of the
executable is non-standard. s2ibis expects to be able to call SPICE using
one of the following calls:
spice inputfile outputfile
spice3 -b inputfile >outputfile 2>messagefile
pspice inputfile outputfile /D0
hspice inputfile >outputfile 2>messagefile
UNIX systems are case-sensitive; every letter in the command you type
must match the corresponding letter in the name of the executable exactly.
Thus if your SPICE executable is:
/bin/SPICE3
s2ibis will not be able to find it. If you can go to the directory from
which you intend to run s2ibis and invoke SPICE using one of the calls
listed above, s2ibis should work. (Note that the spice3 and hspice calls
will only work in Bourne shells. In c-shells [csh] or tc-shells [tcsh]
leave off the 2>messagefile ) If these calls do not work you can fix the
problem by adding the appropriate directory to your PATH, changing the name of
the executable, or adding a soft link that points to the executable in
one of the directories that is in your PATH. If this explanation does
not make sense to you, talk to your system administrator. He or she will
probably be able to make it work fairly quickly.
ANSWER:
Probably. You may not even have to change the code. If your version of
SPICE is compatible with any of the standard SPICE packages directly supported,
you can probably just put a soft link into one of the directories in your PATH
that points to your version of SPICE. For instance, if your package, MYSPICE,
can understand a SPICE3 netlist (and control cards), you can probably just
issue the command:
ln -s /directory_myspice_is_in/MYSPICE spice3
in a directory that is in your PATH. This assumes that MYSPICE has a similar
calling sequence to SPICE3: spice3 -b input_file > output_file.
If your package doesn't meet one of these criteria, you may need to change
s2ibis' calling sequence, or do more serious surgery. Changing the calling
sequence is quite easy. Using the *[Spice_Command] directive, you can
specify the calling sequence that s2ibis uses to anything you want.
Here is an example for a package named MYSPICE that is compatible with SPICE3
but uses the calling sequence:
MYSPICE -input input_file -output output_file
Just put the line
*[Spice_Command] MYSPICE -input %s -output %s
just before or after the *[Spice] 3 line in your input file. Any call that
allows the input, output, and message files to be called in that order
can be accommodated similarly. Calls that cannot be accommodated require
changing the callspice() routine in the source file src/models.c. This is
fairly straightforward.
If your package is not compatible with any of the standard packages, you
will need to change the routines that make up the SPICE decks and/or the
routines that interpret the results as well. This could be quite simple, or
very complicated, depending on how big the differences are. If your package can
accept standard SPICE decks, but has a different output format, it may be pretty
easy to deal with. The routines that read in the SPICE output data are fairly
simple. They are called getspicedata() and getrampdata(), and they are also in
the file models.c. The routine getspicedata() reads in the data for all the DC
simulations. The part that reads in SPICE3 outputs is about 50 lines long, so
it may be pretty easy to modify. The getrampdata() routines are not much more
complicated. If you need to change the SPICE decks, it will be more work, but
it may still be pretty easy. The problem there is that the code for generating
the SPICE decks is spread out over a large routine called makemodel() (about
3000 lines...). It was written that way to make it easy to customize each
simulation type if the need arose. If your SPICE has a different format for its
.PRINT statement, for instance, you could just search through the makemodel()
routine for all the .PRINT cards and edit them to do the right thing.
ANSWER:
Missing tables result for two different reasons: aborted SPICE
simulations and low clamp currents.
The second case is the simplest. s2ibis checks the typ column of all
clamp tables for low currents. If none of the entries in the typ column exceed
the [Clamp_Tolerance] limit, the table is suppressed. (Please note: for pins of
[Model_type] Output, no clamp tables are ever generated.) The [Clamp_tolerance]
limit can be changed by putting the following line in the s2ibis header:
*[Clamp_Tolerance] amps
where amps is a floating point number specifying the new limit in Amperes. Any
number may be used, so you can disable checking by specifying a large negative
number. *[Clamp_Tolerance] -1.0 should disable checking in all practical cases.
Aborted SPICE simulations are more complicated. s2ibis tries to make a
syntactically-correct IBIS model even when SPICE simulations abort. The
strategy is fairly straightforward. For DC simulations, [Pullup], [Pulldown],
etc., s2ibis will always generate a syntactically correct table if the typ
simulation works. If s2ibis detects an aborted min and/or max simulation for a
table for which the typ simulation completed, it will use the IBIS reserved
word NA in the appropriate column(s). s2ibis reports all aborted simulations
on stderr. s2ibis checks the number of points in the output decks of min and
max simulations against the number of points in the associated typ simulations.
If the number disagrees, the min or max simulation is considered aborted and the
entire column is assigned NAs. If the typ simulation aborts, The resulting
table will not meet the IBIS specification, but it will contain a comment
explaining that the associated simulation has aborted, and it is possible to
make it acceptable to IBIS by replacing two NA entries with floating point
numbers.
Transient simulations, which are used to generate [Ramp] tables,
are treated differently. Six simulations are run: two typs, two mins, and
two maxes. Any simulation that works results in an entry in the [Ramp]
table. Any simulation that fails will result in an NA entry in the [Ramp]
table. If either typ simulation fails, the table will not meet the IBIS
specification. s2ibis prints out a warning message to stderr in this case.
Ramp simulations are considered aborted if no transition is detected, even if
the simulation completed without aborting. Currently, s2ibis does not check
the size of the output transition, so nonsense results are possible if the
user does not check the output data to make sure that the transitions were of
reasonable size.
ANSWER:
First, make sure you understand the operation of the *[Iterate] switch,
which is explained in the man pages.
You can use the *[Iterate] switch to get s2ibis to read in SPICE output
files that were generated from SPICE simulations that were not initiated by
s2ibis. Thus, you can take the SPICE input decks that are having convergence
problems, and modify them to help them converge. Anything that you can do to
make them converge is OK, as long as the format of the output file is similar
to the output that s2ibis expects.
A couple of important caveats are in order. Do not let the length of
the tables in the outputs exceed 150 points. If you do, s2ibis will surely
bomb. Make sure that you use any control cards necessary to keep your SPICE
outputs in scientific notation. For instance, use the .OPTIONS POST INGOLD
mechanism in HSPICE to keep HSPICE from putting units at the end of the numbers
in the tables. s2ibis does not accept unit specifiers at the ends of any
numbers. Also, s2ibis requires certain units for all variables. Voltages
must be specified in Volts, currents in Amperes, time in seconds.
ANSWER:
s2ibis uses the following scheme for determining what tables need to be
generated for a particular pin:
0) For POWER, GND, and NC pins, no tables are
generated.
1) For each Input pin, s2ibis automatically
runs SPICE jobs for [GND_clamp] and [POWER_clamp]
tables. If the typ column in either of the
resulting tables exceeds the clamp tolerance
limit (default 1 microamp, changeable by user),
that table is printed.
2) For each Output (*Not* I/O, 3-state, or
Open_drain) pin, s2ibis generates [Pulldown]
and [Pullup] tables only. Clamp simulations
are not even attempted for Output pins.
[Ramp] tables are generated by causing the
output to transition while attached to the
IBIS-specified load, reading the 20% and 80%
points of the transition, and calculating
the slope in between these points.
3) For each I/O or 3-state pin, s2ibis generates
SPICE simulations for [Pulldown], [Pullup],
[GND_clamp], [Power_clamp], and [Ramp] tables.
Generation of the [Ramp] tables uses exactly
the same procedure as described above under
Ouput pins. Generation of the [Pulldown],
[Pullup], [GND_clamp], and [Power_clamp] tables
involves a current partitioning scheme.
First s2ibis runs the [GND_clamp] and
[Pulldown] simulations. The [Pulldown] table
is generated as follows:
pulldown(-5->0):subtract the associated
ground clamp table from the pulldown table
pulldown(0->Vcc):just use the pull-
down table as simulated
pulldown(Vcc->2*Vcc):extrapolate using
the point at Vcc and the point five points
before Vcc in the pulldown table.
The [GND_clamp] table is not modified.
The [Pullup] and [POWER_clamp] tables are
created using an analogous procedure.
Then s2ibis runs the [POWER_clamp] and
[Pullup] simulations. The [Pullup] table
is generated as follows:
pullup(-5->0):subtract the associated
power clamp table from the pullup table
pullup(0->Vcc):just use the pull-
up table as simulated
pullup(Vcc->2*Vcc):extrapolate using
the point at Vcc and the point five points
before Vcc in the pulldown table.
The [POWER_clamp] table is not modified.
4) For Open_drain pins, the procedure for output
pins is followed, except no [POWER_clamp] or
[Pullup] simulations are run, and the corres-
ponding tables are not produced.
I'm having
trouble getting s2ibis to deal with my open-drain I/O pin!?!
ANSWER:
This is a problem with the IBIS v1.1 spec. IBIS v1.1 sees open-drain
pins as output only. You need to go to a newer IBIS version.