A compilation of IBIS related FAQ(Frequently Asked Questions). Issues related to Modeling, Simulations, Support, Features and others are addressed here.
A compilation of s2ibis related frequently asked questions. This section was borrowed from the man pages generated by North Carolina State Univ.
IBIS(Input Output Buffer Information Specification) is a method of providing the Input/Output device characteristics through V/I data without disclosing any circuit/process information. It can be thought of as a behavioral modeling specification suitable for transmission line simulation of Digital Systems and applicable to most digital component
The "Golden Parser" is a program called ibischk6 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. (for the source code see point 3) 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 'ibischk6'
The Golden Parser source code is also available from the 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, V5.x may be licensed for $2500 regardless of IBIS Open Forum membership status.
For information on how to order the IBIS Golden Parser source code see: 19: How do I purchase the source code of the IBIS parser ?
You can access IBIS model directly from the ANSI/EIA-656B 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.
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 IBISv5.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.
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 IBISv5.0 specification for more details.
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.
No, the present IBISv5.0 does not provide timing information. It does allow definition of timing test loads that are required by SI simulators to report correct Flight Time Delay numbers.
IBISv5.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 IBISv5.0 :
Input, Input_ECL, Output_ECL, I/O_ECL
I/O, I/O_open_drain, I/O_open_sink, I/O_open_source
Output, 3-state, Open_sink, Open_drain, Open_source
Input_diff, Output_diff, I/O_diff, 3-state_diff
( these 4 diff structures are for true differential models only, as described in the spec in section 6b )
Refer to IBISv5.0 for a full explanation of the Input/Output structures.
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.
No. The effects of a pad or die resistance are accounted for in the I/V curves.
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.
To participate in IBIS discussions, send your email address to email@example.com . 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.
To report ibischk parser bugs. Fill out: ' The Bug Report Form.' This form resides on server along with all other reported bugs.
To report s2ibis2 and s2iplt bugs, use the Bug Report Forms:
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 $900 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, SAE International.
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 SAE International and conducts its operations according to the SAE AEROSPACE COUNCIL of the SAE Technical Standards Board Organization and Operating Procedures (R).
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 5 parser source code will receive all upgrades to support IBIS 5.2, 5.3 etc. up to but not including the IBIS 6.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.
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.
An ICM parser, icmchk1, is available. As with IBISCHK6, 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.
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:
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:
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:
If you get something like:
s2ibis: mipsel demand paged executable - version 2.10
s2ibis: sparc demand paged dynamically linked executable
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
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 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):
These lines cause s2ibis to try to call SPICE3, PSPICE, and HSPICE,
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:
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.
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
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.
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:
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
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
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.
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
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
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
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 or Open_sink 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.
5) For Open_source pins, the procedure for output
pins is followed, except no [POWER_clamp] or
[Pulldown] simulations are run, and the corres-
ponding tables are not produced.
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.