IBIS(I/O Buffer Information Specification)

Frequently Asked Questions

Rev7.0

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 |

IBIS FAQ

 

s2ibis2(Spice-to-IBIS Converter) FAQ:

A compilation of s2ibis related frequently asked questions. This section was borrowed from the man pages generated by North Carolina State Univ.

 

1: What is this IBIS stuff anyhow ?

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

2: What is the "Golden Parser" ?

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.

3: Where can I find the IBIS Golden Parser ?

The parser is freely available in object code format for many platforms, and can be downloaded from IBISCHK page

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, V7.x may be licensed for $3000 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 ?

4: Where can I find available IBIS models ?

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.

5: Can IBIS model best case, worst case models ?

Yes, by using the min, max current with the proper min, max ramp rates, the Best, Typical and Worst case can be modeled.

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 IBISv5.0 to handle SSO defination. Simulating SSO depends on the model provided and the simulator used.

7: Why do we need to sweep -Vcc to 2Vcc ?

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.

8: Can IBIS model GTO(Gradual Turn On) or Slew rate controlled outputs ?

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.

9: Can IBIS model ground bounce ?

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.

10: Can IBIS provide timing information ? ex.propdelays, skew etc

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.

11: Can IBIS model be used to measure propagation delays ?

IBISv5.0 does not support measurement of propagation delays. IBIS is mainly used to simulate transmission lines and analyze signal integrity issues.

12: What type of Input/output structures are supported by IBIS ?

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

Input_ECL, I/O_ECL

Terminator

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.

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 ?

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.

14: Is there a provision for specifying a pad or die resistanc e i.e R_comp in addition to C_comp?

No. The effects of a pad or die resistance are accounted for in the I/V curves.

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?

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.

16: How do I become an active participant in IBIS activities?

To participate in IBIS discussions, go to the Support page and follow instructions for joining the IBIS email reflectors. Notices of upcoming teleconferences, agendas, and meeting minutes are distributed through the IBIS reflector. You may subscribe and send email to the IBIS Users reflector to begin a discussion that will reach all subscribers.

17: How do I report a IBIS Golden Parser or a SPICE-to-IBIS bug ?

To report ibischk parser bugs follow directions at the top of the IBISCHK BUGs page.

18: How do I become an IBIS Forum Member ?

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 organizations.

Paid member organizations 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. Academic institutions are eligible for reduced membership dues (50% of full rate). 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-ITC.

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-ITC and conducts its operations according its Policies and Procedures document, and according to the 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.

19: How do I purchase the source code of the IBIS parser ?

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 IBISCHK page.

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 organizations alike may purchase a parser license at the same cost. The current cost of a parser license in US $ 3000. 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 7 parser source code will receive all upgrades to support IBIS 7.1, 7.2 etc. up to but not including the IBIS 8.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 available on the IBISCHK page If you are interested in purchasing a license, please contact the IBIS Open Forum chair or any of the IBIS Officers.

20: What is the ICM and is there a parser for ICM ?

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.

21: What if I have a question not listed here ?

Send all other questions to info@ibis.org.

1:Why won't s2ibis run on my machine?

 
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.

2: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.

3: We don't have SPICE2, SPICE3, PSPICE, or HSPICE! Can we use s2ibis?

 
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.

4: Tables are missing. What is the matter?

 
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.

5: s2ibis runs, but I'm having convergence problems. What can I do?

 
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.

6: How does s2ibis generate tables?

 
 
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 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.

7: 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.
 


| Home | Articles | FAQ| Models | Roster| Specs | Support |
 ©1995-2020, IBIS Open Forum