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 |
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
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.
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 info@ibis.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.
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:
'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 $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.
The
current version of ibischk is 5.1.4. 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.
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.
ANSWER: There are several common problems that cause s2ibis to fail to run.The most common problem is that your PATH environment variable does notinclude 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 errormessage that does not start with: s2ibis: then there is a really big problem. Either your executable is forthe 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 getsomething 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 correctexecutable from the S2IBIS/bin directory into a file named s2ibis ina directory listed in your PATH environment variable. The executablesare in the S2IBIS/bin directory, and have the machine they are intendedfor in the suffix. Thus s2ibis.sparc is for Sun SPARCstations, etc.
ANSWER: s2ibis is probably having trouble locating your SPICE program. Ifyou 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 includethe directory that your SPICE executable is in, or because the name of theexecutable is non-standard. s2ibis expects to be able to call SPICE usingone 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 fromwhich you intend to run s2ibis and invoke SPICE using one of the callslisted above, s2ibis should work. (Note that the spice3 and hspice callswill 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 ofthe executable, or adding a soft link that points to the executable inone of the directories that is in your PATH. If this explanation doesnot make sense to you, talk to your system administrator. He or she willprobably be able to make it work fairly quickly.
ANSWER: Probably. You may not even have to change the code. If your version ofSPICE 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 PATHthat 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 similarcalling sequence to SPICE3: spice3 -b input_file > output_file. If your package doesn't meet one of these criteria, you may need to changes2ibis' calling sequence, or do more serious surgery. Changing the calling sequence is quite easy. Using the *[Spice_Command] directive, you canspecify 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 thatallows the input, output, and message files to be called in that ordercan be accommodated similarly. Calls that cannot be accommodated requirechanging the callspice() routine in the source file src/models.c. This isfairly 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 allclamp tables for low currents. If none of the entries in the typ column exceedthe [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. Anynumber may be used, so you can disable checking by specifying a large negativenumber. *[Clamp_Tolerance] -1.0 should disable checking in all practical cases. Aborted SPICE simulations are more complicated. s2ibis tries to make asyntactically-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 typsimulation 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 reservedword NA in the appropriate column(s). s2ibis reports all aborted simulationson 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 commentexplaining that the associated simulation has aborted, and it is possible tomake it acceptable to IBIS by replacing two NA entries with floating pointnumbers. Transient simulations, which are used to generate [Ramp] tables,are treated differently. Six simulations are run: two typs, two mins, andtwo 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 IBISspecification. s2ibis prints out a warning message to stderr in this case. Ramp simulations are considered aborted if no transition is detected, even ifthe simulation completed without aborting. Currently, s2ibis does not checkthe size of the output transition, so nonsense results are possible if theuser does not check the output data to make sure that the transitions were ofreasonable 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 outputfiles that were generated from SPICE simulations that were not initiated bys2ibis. Thus, you can take the SPICE input decks that are having convergenceproblems, and modify them to help them converge. Anything that you can do tomake them converge is OK, as long as the format of the output file is similarto the output that s2ibis expects. A couple of important caveats are in order. Do not let the length ofthe tables in the outputs exceed 150 points. If you do, s2ibis will surelybomb. Make sure that you use any control cards necessary to keep your SPICEoutputs in scientific notation. For instance, use the .OPTIONS POST INGOLDmechanism in HSPICE to keep HSPICE from putting units at the end of the numbersin the tables. s2ibis does not accept unit specifiers at the ends of anynumbers. Also, s2ibis requires certain units for all variables. Voltagesmust 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 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.
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-2018,
ANSI/EIA-656-B(IBIS)