Electronics Guide

IBIS and IBIS-AMI Modeling

The Input/Output Buffer Information Specification, universally shortened to IBIS, is the format in which the electronics industry exchanges models of the circuits that drive and receive signals at the edge of an integrated circuit. Its algorithmic extension, IBIS-AMI, does the same job for the equalizers, adaptive filters, and clock recovery loops inside a modern serializer-deserializer. Together they are the reason a system designer can simulate a multi-gigabit link assembled from three vendors' silicon without any of those vendors disclosing a transistor.

The two halves answer different questions. A plain IBIS model answers an analog one: given a voltage on the pad, how much current does this buffer source or sink, and how fast does its output edge move? An AMI model answers an algorithmic one: given the impulse response of the channel, or a stream of samples arriving at the receiver, what does the transceiver's signal processing do to it, and where does the recovered clock place the sampling instant? The first is a table of numbers; the second is compiled code that the simulator loads and calls.

Both are behavioral by design. Neither reveals the circuit that produced the behavior, and that concealment is the commercial premise of the format rather than a limitation grudgingly accepted. Understanding what an IBIS or AMI model contains, what it deliberately omits, and where each abstraction stops being safe is a core competence for anyone who signs off on a high-speed interface.

Why Behavioral Buffer Models Exist

The obvious way to simulate an output buffer is to simulate the transistors. A transistor-level netlist evaluated with accurate process models is the reference answer, because it is the real circuit. Three obstacles keep that approach out of most system-level work.

The first is speed: a transistor deck for a wide bus, evaluated over the thousands of switching events a signal integrity study needs, consumes hours or days and must be re-run for every topology variation. The second is availability, since a transistor netlist is worthless without device models for the process it targets, and those are among the foundry's most closely guarded assets. The third, and the decisive one, is intellectual property. An output driver netlist discloses drive-strength segmentation, slew control, pre-emphasis structure, and electrostatic discharge protection topology, and no semiconductor vendor distributes that to customers.

Vendors sometimes respond with encrypted circuit models: a netlist that one particular simulator can decrypt and evaluate but that no human can read. Encryption preserves accuracy and protects the design, but it binds the customer to a single tool, it gives the user no way to inspect a suspicious result, and it does nothing about simulation speed. IBIS takes the opposite route. Rather than hiding the circuit, it discards it, keeping only a description of what the circuit does at its terminals: two current-versus-voltage tables for the active output structures, two more for the clamping diodes, a description of how fast the output transitions, a die capacitance, and the parasitics of the package. The result is a plain text file that any conforming simulator can read, that simulates far faster than the netlist it replaces, and that a vendor's legal department will approve.

The specification emerged from an industry working group in 1993. Version 2.1 was ratified as ANSI/EIA-656 on December 13, 1995, and version 3.2 as ANSI/EIA-656-A in September 1999, the latter becoming the document forwarded into the IEC 62014-1 process and published internationally on April 13, 2001. Development is carried out by the IBIS Open Forum, affiliated with SAE ITC since July 18, 2013, which meets every three weeks and publishes the specification, the free parsers, and the supporting documents at no charge.

Anatomy of an IBIS File

An IBIS file, conventionally carrying the extension .ibs, is human-readable ASCII organized around bracketed keywords. Reading one is a genuinely useful skill, because most model defects are visible on inspection to someone who knows what the columns mean.

File Header and Component Description

The file opens with administrative keywords. [IBIS Ver] declares the specification version the file conforms to, and therefore which later keywords are legal inside it; [File Name], [File Rev], [Date], [Source], [Notes], [Disclaimer], and [Copyright] follow. A careful model maker records how the data was derived in [Source] and [Notes], which is the first place to look when a model behaves oddly.

Each device appears under a [Component] keyword, with [Manufacturer], a default [Package], and a [Pin] table. The [Pin] table is the pin-to-model map: pin name, data-book signal name, then the buffer model for that pin, with POWER, GND, NC, and CIRCUITCALL reserved rather than user-defined. A six-column form adds R_pin, L_pin, and C_pin values that override the component-wide [Package] defaults for that pin alone. Supporting keywords describe structure the flat table cannot: [Diff Pin] pairs pins into differential channels, [Pin Mapping] associates signal pins with their supply and ground rails so that power-aware analysis is possible, and [Model Selector] offers a menu of programmable drive strengths.

The Current-Voltage Tables

Four keywords carry the direct-current behavior of the buffer. [Pulldown] and [Pullup] describe the active output structures; [GND Clamp] and [POWER Clamp] describe the protection diodes that conduct when the pad is driven beyond the rails. Each is a table of four columns, a voltage followed by typical, minimum, and maximum current, with current positive when it flows into the component. Data is required only in the typical column, the reserved word NA is permitted elsewhere, and a table must have at least two rows and no more than one hundred.

Two conventions catch newcomers. The [Pullup] and [POWER Clamp] tables are supply-relative: their voltage column holds the supply voltage minus the output voltage. That is the physically correct choice, since a pullup structure's current depends on the difference between the pad and the supply, and it keeps the table valid at a different rail. The tables must also span from the negative of the supply voltage up to twice the supply, so that the simulator has real data for the overshoot and undershoot a reflection produces rather than having to extrapolate.

The tables also interact. Clamp currents are always present, whether or not the driver is enabled, while the pullup and pulldown tables apply only when the buffer drives, so a simulator sums the clamp tables into the appropriate driver table when evaluating a driving buffer. For that summation to avoid double counting, the [Pullup] and [Pulldown] tables of a three-statable buffer must contain the difference between the enabled and the high-impedance measurement. A buffer that cannot be three-stated cannot be characterized that way, so its driver tables carry the combined behavior and the clamp keywords must be omitted or zeroed.

Switching Behavior

Direct-current tables say nothing about edge rate, so the [Ramp] keyword supplies it. Its subparameters give the rising and falling slew rates as an explicit, unreduced fraction of a voltage swing over a time, measured between the twenty and eighty percent points of the final value. The default characterization load is fifty ohms, and any other load must be declared with the R_load subparameter. The ramp figure excludes package parasitics but includes the effect of the die capacitance.

A single slew rate is a crude description of a real edge, so IBIS 2.1 added [Rising Waveform] and [Falling Waveform], tables of voltage against time taken under declared fixture conditions. Every table must begin at the settled direct-current level before the transition and end at the settled level after it, and all tables in a model must be time-correlated to a single reference instant on the input stimulus, so that differences in internal buffer delay show up honestly as differences in lead-in time. Two tables taken into different loads let the simulator separate the buffer's internal behavior from its loading, which is why serious models supply more than one. The older [Ramp] keyword remains mandatory regardless, so that models stay usable in flows that do not process waveform tables.

Die Capacitance

The C_comp subparameter of [Model] represents the parasitic capacitance of the die itself, excluding the package. Because one lumped value cannot express the fact that the pullup, pulldown, and clamp structures each contribute capacitance referenced to a different rail, later versions added C_comp_pullup, C_comp_pulldown, C_comp_power_clamp, and C_comp_gnd_clamp, each placed in parallel with its own table. A model may declare the single value or the split values, and a simulator must never use both at once. IBIS 7.1 went further with [C Comp Model], which allows a frequency-dependent description in place of a fixed capacitance.

What the Corners Actually Mean

Every table in an IBIS file has typical, minimum, and maximum columns, and the naming misleads almost everyone at first encounter. For the model data proper, the minimum column describes slow, weak behavior and the maximum column describes fast, strong behavior. It is not a minimum and maximum of the tabulated quantity, and it is not a voltage corner. The minimum column pairs the low supply voltage with whichever temperature aggravates weakness, which for a CMOS buffer is the high temperature and for a bipolar buffer is the low temperature. When temperature is not declared, the specification assumes a default of fifty degrees Celsius nominal, zero minimum, and one hundred maximum, understood as junction temperatures, and vendors may apply a further proprietary derating percentage they are not obliged to publish. Die capacitance is treated as an independent variable, because it includes bond pad capacitance that does not follow the fabrication process; the specification advises pairing large capacitance with the slow, weak model, but does not enforce it.

Package Parasitics and Interconnect Description

Silicon does not connect to a board directly, and the path between them is often the dominant discontinuity in a link. IBIS offers three levels of description for it.

The simplest is the [Package] keyword, which declares one resistance, one inductance, and one capacitance for the whole component, per corner; it is required, and must carry valid data even when a better description exists elsewhere. The six-column form of [Pin] improves on it by giving each pin its own lumped triple, distinguishing a short corner ball from a long peripheral bond wire, but it still models each path as a single lumped element and ignores coupling between neighbors.

The third level is a real package model. The [Package Model] keyword points to a description, inside the same file or in a separate one, carrying resistance, inductance, and capacitance matrices divided into cascaded sections, with a declared bandwidth over which it is claimed valid. Because the matrices are full rather than diagonal, this form represents mutual inductance and capacitance between neighboring paths, which is where package crosstalk and simultaneous switching noise originate.

IBIS 7.0 replaced the ceiling entirely. Its [Interconnect Model Group] keyword allows the package, and on-die interconnect as well, to be described by an IBIS-ISS subcircuit or by a Touchstone S-parameter file, associated with pins, pads, and buffer terminals through an explicit node syntax. IBIS-ISS, the Interconnect SPICE Subcircuit specification, was ratified on October 7, 2011 and defines a portable SPICE subcircuit dialect precisely so that this kind of reference can be exchanged between tools. For anything above a few gigabits per second, a lumped resistance-inductance-capacitance triple is no longer a description of a package; it is a placeholder. The behavior of these structures is developed further in IC Package Effects.

Where IBIS Stops and AMI Begins

A classical IBIS model describes an analog buffer and nothing else. It has no representation of a feed-forward equalizer at the transmitter, no continuous-time linear or decision feedback equalizer at the receiver, no automatic gain control, no adaptation, and no clock and data recovery loop. For a source-synchronous parallel bus at a few hundred megabits per second per pin, that omission costs nothing. For a serial link at ten, twenty-eight, or more gigabits per second, the equalizers are the design, and a simulation that ignores them describes a closed eye and predicts a link that cannot work.

A second obstacle is throughput. Serial standards specify bit error ratios of one in a trillion or lower, and observing that rate directly requires on the order of ten trillion bits, which no transient circuit simulation will deliver. Any credible margin statement must come from a method that extrapolates from a channel description rather than from counting errors, which means the transceiver has to be represented as a mathematical operator on a response rather than as a circuit.

The Algorithmic Modeling Interface answers both problems at once. Ratified with IBIS 5.0 on August 29, 2008, it splits the transceiver in two. The analog front end, meaning the output stage impedance and the receiver termination with their parasitics, stays where it was, described by the IBIS buffer model or by a Touchstone file. Everything algorithmic moves into a compiled shared library, written to a defined C interface, that the simulator loads at run time and calls. The library performs the equalization and clock recovery internally, using whatever proprietary algorithm the vendor wishes, and returns only its effect. The vendor ships a binary, so the algorithm stays secret; the simulator calls a standard interface, so the model runs in any conforming tool. The equalizer families this mechanism carries are described in Active Equalization, and the transceiver blocks they belong to in SerDes Architecture.

The Structure of an IBIS-AMI Model

An AMI model is less a separate file format than an attachment to an existing IBIS model. Inside a [Model] section, the keyword pair [Algorithmic Model] and [End Algorithmic Model] declares the association; it may appear at most once per model and is illegal on models of type Terminator, Series, or Series_switch. Whether the buffer is single-ended or differential, the algorithmic model always processes exactly one waveform, and for a differential model that waveform is the difference of the two sides.

The Executable subparameter carries three fields on each line: a platform string, the shared library, and the parameter file. The platform string names the operating system, the compiler, and the architecture width, separated by underscores, in forms such as Windows_VisualStudio7.1.3088_32 or Linux_gcc3.2.3_32. A model may repeat the subparameter to ship libraries for several platforms from one file, and the simulator selects the line matching the machine it runs on. Bidirectional buffers use Executable_Rx and Executable_Tx instead, and each direction must reference its own parameter file even when one library serves both.

[Algorithmic Model]
Executable Windows_VisualStudio_32 tx_getwave.dll tx_getwave_params.ami
Executable Solaris_cc_32           libtx_getwave.so tx_getwave_params.ami
[End Algorithmic Model]

Two practical rules govern the files themselves. Both the library and the parameter file must sit in the same directory as the .ibs file or in a relative path beneath it, which is what makes a model directory portable. And although the specification calls the library an "executable model file," it is a compiled library of functions and is usually not itself runnable; the specification warns model makers to test each release on a clean machine using a dependency-checking tool, because a library that silently depends on the developer's toolchain will fail at the customer's site.

The AMI Function Set

The library exposes up to five functions with fixed names and signatures, conforming to the ANSI C calling interface. Two of them, AMI_Init and AMI_Close, are always required. AMI_GetWave is optional, as are AMI_Resolve and AMI_Resolve_Close, which resolve dependent parameters before initialization and became legal at AMI version 6.1. A sixth function, AMI_Impulse, was added at AMI version 7.1 for statistical link training.

AMI_Init carries the heaviest signature in the specification:

long AMI_Init (double *impulse_matrix,
               long    number_of_rows,
               long    aggressors,
               double  sample_interval,
               double  symbol_time,
               char   *AMI_parameters_in,
               char  **AMI_parameters_out,
               void  **AMI_memory_handle,
               char  **msg)

The impulse matrix is both input and output. The simulator fills it with the impulse response of the analog channel, and the model modifies it in place by applying its filtering. It is stored column by column in a single flat array, so an element is found at the offset column multiplied by the row count, plus the row. Column one always holds the through channel; the remaining columns hold crosstalk aggressor responses, in no particular order. A transmitter sees the responses that originate from it; a victim receiver sees the responses that arrive at it, which is a different set. Any filtering applied to the through channel must be applied to the aggressor columns as well, or the crosstalk contribution will be wrong.

The sample interval and the symbol time are chosen by the simulator and passed in; the symbol time is the unit interval, the reciprocal of the baud rate. The parameter strings are parenthesized trees, described below. The memory handle is the model's own state: the model allocates what it needs during initialization, writes the address into the handle, and receives the same handle on every subsequent call. The message pointer returns human-readable diagnostics to the tool's log.

AMI_GetWave is the time-domain entry point:

long AMI_GetWave (double *wave,
                  long    wave_size,
                  double *clock_times,
                  char  **AMI_parameters_out,
                  void   *AMI_memory)

Here the waveform is modified in place as well. The simulator decides the block length, and the specification is explicit that the block size may change from one call to the next and need not contain a whole number of symbols; a model that cannot cope with an arbitrary block length is defective. For a receiver, the returned waveform is the signal at the decision point, or the equivalent waveform at such a node in architectures that have no single physical one. AMI_Close takes only the memory handle and releases everything the model allocated.

All of these functions return one for success and zero for failure, and the specification restricts failure to genuine execution errors: a null pointer, an invalid data type, anything that prevents the code from running. A functional problem is not a failure. If the model's clock recovery loop never achieves lock, it must still return success and communicate the difficulty through the message string. Tools rely on that distinction to separate a broken model from an unlockable channel.

The AMI Parameter Definition File

Every algorithmic model is accompanied by a parameter definition file with the extension .ami. It is a parenthesized tree with a single root name, and only two branches may attach to that root: a required Reserved_Parameters branch declaring facts the simulator itself must understand, and an optional Model_Specific branch declaring whatever settings the vendor chooses to expose, which the simulator passes through without interpretation. The file is case sensitive, uses the pipe character for comments regardless of what the calling .ibs file uses, and permits scientific notation but forbids engineering suffixes such as p or n.

Each parameter is a branch carrying leaves, and three attributes do most of the work. Usage declares the direction of travel through the values In, Out, Info, InOut, and Dep: an input is passed to the model, an output is returned by it, an informational parameter is for the tool or the user and is never passed in, and a dependent parameter is assigned by AMI_Resolve. Type selects among Float, Integer, String, Boolean, Tap, and UI. Format declares how the value is presented: a single Value, a continuous Range, a discrete List, a Corner triple the tool selects from automatically, an Increment or Steps grid, a multi-column Table, or the statistical forms Gaussian, Dual-Dirac, and DjRj used for jitter.

Two conventions repay attention. The Corner format is what allows a single model to track the simulator's process corner without user intervention, and a model that omits it forces the engineer to change settings by hand. The Tap type, combined with the convention that individual taps are named by their tap number, with negative names for precursors and zero for the main cursor, tells the tool that a parameter group is a tapped delay line and licenses an optimization sweep over the coefficients. A vendor who declines that convention gets a model whose equalizer the tool cannot automatically tune.

(mySampleAMI
  (Description "Sample AMI File")
  (Reserved_Parameters
    (AMI_Version          (Usage Info) (Type String)  (Value "8.0"))
    (Ignore_Bits          (Usage Info) (Type Integer) (Value 21))
    (Max_Init_Aggressors  (Usage Info) (Type Integer) (Value 25))
    (Init_Returns_Impulse (Usage Info) (Type Boolean) (Value True))
    (GetWave_Exists       (Usage Info) (Type Boolean) (Value True))
  )
  (Model_Specific
    (txtaps
      (-1 (Usage InOut) (Type Tap) (Range 0.2 -0.4 0.4)
          (Description "First Precursor Tap"))
      (0  (Usage InOut) (Type Tap) (Range 1 0.4 1)
          (Description "Main Tap"))
      (1  (Usage InOut) (Type Tap) (Range 0.2 -0.4 0.4)
          (Description "First Postcursor Tap"))
    )
  )
)

Reserved Parameters That Decide the Simulation Flow

A handful of reserved parameters do more than describe the model: they determine which analyses the simulator is permitted to run.

Init_Returns_Impulse is a required Boolean that tells the tool whether AMI_Init returns the channel impulse response convolved with the model's equalization, or leaves it untouched. GetWave_Exists, also required, tells the tool whether the time-domain entry point is implemented. A single rule ties them together: if Init_Returns_Impulse is false, then GetWave_Exists must be true. That rule guarantees that at least one filtering path always exists, and it produces three legal configurations. A model that returns an impulse response but has no waveform function supports statistical analysis only. A model that implements only the waveform function supports time-domain analysis only. A model that does both is called a dual model and supports either.

Dual models carry a subtlety worth stating plainly. The specification declares the filtering in the two functions to be independent representations of the same device, to be used one or the other and never combined; a tool that filtered through the initialization result and then passed the same waveform through the waveform function would apply the equalization twice. Older models could adjust this through Use_Init_Output, a parameter now legacy and illegal at AMI version 5.1 and later.

Two integers govern practical limits. Ignore_Bits declares how many unit intervals of waveform-function output the tool should discard while the model's adaptation settles, which matters because an adaptive receiver produces meaningless output until its loops converge. Max_Init_Aggressors declares how many crosstalk impulse responses the initialization function can process. Both default to zero when absent, and the second default is a trap: a model that simply omits Max_Init_Aggressors is telling the tool that it can accept no aggressor columns at all, so the statistical flow silently proceeds without crosstalk.

Around these sit the rest of the reserved set, which the specification tabulates together with the first AMI version in which each became legal. AMI_Version has been required since 5.1 and is what lets a tool decide which later parameters it may honor. Supporting_Files, DLL_Path, and DLL_ID handle auxiliary data files and multiple instances. A further group covers jitter and noise, including Tx_Rj, Tx_Dj, Tx_Sj, Rx_Noise, and Rx_Receiver_Sensitivity, and another covers modulation, where Modulation_Levels, added at AMI version 7.2, generalized the earlier four-level parameters to arbitrary pulse amplitude modulation orders. The multilevel schemes these parameters serve are treated in Advanced Modulation Schemes.

Statistical Versus Bit-by-Bit Analysis

The specification defines a reference flow for each of the two analysis styles, and states that other calling orders are permitted so long as they reproduce the reference result. That requirement is what makes results portable at all.

In the statistical flow, the tool first obtains the impulse response of the analog channel, meaning the transmitter's output stage, the interconnect, and the receiver's front end, deliberately excluding any equalization. It passes that response to the transmitter's initialization function, passes the result to the receiver's, and performs its probabilistic analysis on what comes back. Because the returned response is a complete linear description of the equalized channel, the tool can convolve the probability distributions of every symbol combination into an eye contour and a bathtub curve at error ratios far below anything a simulation could observe directly. The machinery involved is developed in Statistical Channel Modeling.

The price of that reach is an assumption. Statistical analysis requires the model's algorithm to be linear and time-invariant, because only then can the equalizer be represented as an impulse response at all.

In the time-domain flow, the tool generates a stimulus bit pattern, divides it into blocks, and calls the transmitter's waveform function on each block. It combines that output with the channel response, typically by convolution, and passes the result to the receiver's waveform function. The receiver returns the waveform at its decision point along with the recovered clock times, and the tool accumulates an eye and a bit error ratio estimate from those. A one-million-bit run is a common working size; it takes far longer than a statistical solve and bounds direct observation at around one error in a million before any extrapolation, but it makes no linearity assumption whatever.

Several common transceiver features force that flow. A decision feedback equalizer is nonlinear by construction, because its feedback path is driven by sliced decisions rather than by the analog signal, and because a wrong decision propagates into the taps that follow. Adaptation of any kind is time-variant by definition, as is a clock recovery loop that tracks jitter, whose bandwidth interacts with the jitter spectrum in a way no static response captures. Whenever the receiver's behavior depends on the data it has already seen, the statistical assumption has been violated.

In practice, tools commonly offer a statistical treatment of decision feedback equalization anyway, by letting the initialization function report its tap values so that the tool can cancel the corresponding post-cursor interference exactly. The approximation is useful and well understood, but optimistic: it assumes perfect decisions, so it omits error propagation and the adaptation transient. When a statistical and a bit-by-bit result disagree on a link with a deep feedback equalizer, the bit-by-bit answer is the one to believe.

The productive discipline is to use both: statistical analysis to sweep equalizer settings, channel lengths, and via structures across a large design space, and bit-by-bit analysis to confirm the chosen operating point with the nonlinear and adaptive behavior included. Both styles are treated at length in Channel Simulation.

Clock Ticks, the Recovered Clock, and Adaptation

The third argument to the waveform function is a vector of clock times, and it carries more meaning than its plain name suggests. The simulator allocates the memory; the receiver model fills it with the times, in seconds and referenced to the start of the whole simulation rather than to the current block, at which its recovered clock ticks. The convention that matters most is the offset: the sampling instant is the clock time plus one half of a unit interval, adjusted by any declared eye offsets. A model that reports edges and a tool that assumes centers, or the reverse, produces an eye shifted by half a symbol.

The vector is terminated by a value of minus one after the last valid entry, and a model that returns only that terminator on every call is declaring that it does not generate clock times at all. Values must be strictly monotonic both within a single call and across successive calls, and any violation, including two identical times, is to be treated as a model failure. The specification also warns implementers to maintain full double precision across multi-million-symbol runs, where the accumulated absolute time grows large enough for careless arithmetic to lose the resolution that matters.

Not every receiver recovers its own clock. Rx_Use_Clock_Input, added at AMI version 7.1, takes the values None, Times, or Wave, and the latter two turn the same vector into an input, so that a forwarded-clock architecture can be driven by the strobe accompanying the data. That change is what made AMI usable for source-synchronous memory interfaces as well as embedded-clock serial links, a subject taken up in DDR Interface Design. For statistical analysis, where there are no individual ticks to report, the same information arrives as distributions through Rx_Clock_PDF and the clock recovery parameters that separate mean sampling offset from random, deterministic, sinusoidal, and duty-cycle-distortion components. The loops that produce this behavior are described in Clock and Data Recovery.

A receiver that never locks is a legitimate outcome, and the specification acknowledges it: the loop may go out of lock, leaving clock times with no definite relationship to the waveform, and it may be suppressed for an undefined number of symbols before the first tick appears. IBIS 8.0 added Adaptation_Valid, an output Boolean by which the receiver tells the tool that its equalization has converged and the current block may now be accumulated into the eye, making adaptation length something discovered rather than guessed, with Ignore_Bits serving as the ceiling instead of the answer.

Repeaters, Link Training, and Analog Buffer Interoperability

Real links are not always a single transmitter, channel, and receiver. IBIS 6.0 introduced repeater support through the [Repeater Pin] keyword and the Repeater_Type reserved parameter, which distinguishes a redriver from a retimer. The distinction is behavioral rather than cosmetic. A redriver amplifies and equalizes continuously and has no sampling latch, so the specification directs tools to ignore any clock times, jitter parameters, and noise parameters its receiver half reports. A retimer recovers the clock, samples, and re-transmits, breaking the link into independent segments, and its receiver half must therefore implement the waveform function. IBIS 7.2 repaired the flows around these devices and added Tx_Impulse_Input, which declares what the impulse matrix handed to a transmitter in such a chain actually contains.

The most ambitious extension is back-channel link training, added in IBIS 7.0. Modern serial standards, among them PCI Express, USB, Fibre Channel, and the Ethernet family defined by IEEE 802.3, negotiate transmitter equalizer settings at start-up: the receiver measures what it sees and asks the far-end transmitter to adjust. AMI models this by letting the two models exchange messages through files whose contents the simulator neither generates nor interprets. BCI_Protocol names the agreed protocol, which both ends must declare identically, with names beginning "IBIS" reserved for protocols the Open Forum approves; BCI_ID gives the models a collision-free filename namespace, which matters when several channels are analyzed concurrently; and BCI_State reports progress through the values Off, Training, Converged, Failed, and Error. IBIS 7.1 extended training into the statistical flow with the AMI_Impulse function, so that optimization no longer requires a full time-domain run.

Finally, AMI can dispense with the classical IBIS analog description altogether. The Ts4file reserved parameter, added at AMI version 7.0, points to a four-port Touchstone file describing the analog buffer as a network. For a transmitter, the file sits between an ideal stimulus source and the buffer terminals, with the swing declared by the required Tx_V parameter and an optional series resistance in Tx_R; for a receiver, it sits between the terminals and the high-impedance input of the algorithm, with an optional termination in Rx_R. The port ordering is fixed by the specification, with ports one and three on the source or input side and the odd ports carrying the non-inverting path, and IBIS 8.0 added Tx_Port_Order and Rx_Port_Order so that a file produced with another convention can be used without being re-ordered by hand. Touchstone is itself a separate Open Forum specification, with version 2.0 ratified on April 24, 2009 and version 2.1 on January 26, 2024.

Model Qualification and Correlation to Measurement

A model that has never been checked is a claim, not a tool. Qualification proceeds on three fronts: syntax, internal reasonableness, and correlation to something real.

Syntax is handled by the free parsers the Open Forum distributes. The IBIS file checker, universally called the golden parser and distributed as ibischk, is the reference implementation of what the specification permits, and a companion checker, tschk, does the same for Touchstone files. Passing the parser is necessary and nowhere near sufficient: it validates form, not physics, and cannot tell a plausible pullup table from an implausible one.

Reasonableness is handled by the IBIS Quality Specification, whose version 3.0 was ratified on September 15, 2023. It defines a quality designator that a model maker embeds in the file itself, as a comment or in the [Notes] section, in forms such as IQ3S or IQ4X. The numeric part records how far the checking went. IQ0 means unchecked. IQ1 means the file passes the parser with zero errors and every remaining warning explained. IQ2 adds the checks that make waveform simulation trustworthy, covering corner ordering, sweep ranges, die capacitance plausibility, and freedom from stair-stepped tables. IQ3 adds what timing analysis needs, chiefly per-pin package data and correct receiver threshold and differential timing keywords. IQ4, new in version 3.0, adds what power-aware analysis needs, including [Pin Mapping], the [ISSO PD] and [ISSO PU] tables, and [Composite Current].

Letters appended to the number record correlation. A "G" means the file carries golden waveforms, the [Test Data] and [Test Load] keywords introduced in IBIS 4.0, against which a user can compare a simulation of the model under an identical load; the specification is emphatic that those waveforms must come from source simulation or bench measurement and never from simulating the IBIS model itself. An "M" means the model has been correlated against hardware measurement and an "S" against a reference circuit simulation, with the methods documented; the Open Forum's I/O Buffer Accuracy Handbook supplies overlay and envelope metrics for grading those comparisons. An "X" means an explained exception, and it is a signal to open the file and read the notes before trusting it.

Qualifying an AMI model is harder, because its algorithm is opaque by design and the usual recourse of inspecting the data does not exist. IBIS 8.0 addresses this with the [AMI Test Configuration] keyword, which lets a model maker ship a complete self-test alongside the library: a declared analysis type and direction, a file of simulator and model parameters, input impulse response or waveform files, and the golden impulse response, waveform, and clock output the model maker's own run produced. A simulator can then run the library under exactly those conditions and compare. The scope is deliberately narrow: the channel is supplied as part of the input, so the keyword qualifies the model and the tool's calling of it, not the channel extraction.

None of this substitutes for correlating the assembled simulation against hardware. Comparing a pre-layout estimate with an extracted post-layout result, and both with a measured eye on a real board, is what turns a modeling flow into a trusted one; that discipline is developed in Pre/Post-Layout Correlation and the instrument side in Measurement and Test.

The Open Forum, BIRDs, and Specification Evolution

Changes to IBIS arrive through a single documented mechanism. A Buffer Issue Resolution Document, invariably called a BIRD, is a proposal written against a published template and submitted to the Open Forum. BIRDs are numbered sequentially and tracked in a public index recording the submission date, the acceptance date where one exists, and the specification version into which each accepted proposal was folded; rejection is a normal outcome. Discussion happens in the Open Forum's regular meetings and at the summits held around the world through the year, and accepted BIRDs accumulate until they are published as a specification release. By the middle of 2026 the numbering had passed two hundred and thirty, with recent entries covering power integrity modeling and single-ended analog models referenced through a two-port Touchstone file.

The release history is a compact summary of what the industry needed when. Version 4.0, ratified July 19, 2002, opened the door to external models expressed in hardware description languages and SPICE. Version 5.0, ratified August 29, 2008, introduced the Algorithmic Modeling Interface, and version 5.1, on August 24, 2012, delivered the clarifications the young format badly needed. Version 6.0, on September 20, 2013, added redriver and retimer support, and version 6.1, on September 11, 2015, the resolve functions and four-level modulation. Version 7.0, on March 15, 2019, brought interconnect models based on IBIS-ISS and Touchstone together with back-channel training; version 7.1, on December 10, 2021, added on-die power distribution models and statistical back-channel optimization; version 7.2, on January 27, 2023, repaired the repeater flows and generalized multilevel modulation; and version 8.0, ratified December 5, 2025, added AMI test data, the alternate Touchstone port ordering, and an ignore-block mechanism.

The practical consequence for a user is that two numbers must always be read together. A model's [IBIS Ver] declares which keywords are legal in the file, and its AMI_Version declares which reserved parameters the algorithmic model expects to be honored. A tool that implements the earlier of the two will not act on the later parameters, and it is under no obligation to warn loudly that it has ignored them.

Common Failure Modes

Most lost days in an IBIS or AMI flow trace back to a small number of recurring problems.

Corner Mismatch

The single most productive source of wrong answers is the meaning of the minimum and maximum columns. They are slow-weak and fast-strong, not numerical extremes and not supply extremes. An engineer who reads them as low and high current will pair the wrong buffer with the wrong supply voltage and produce a corner that does not exist. Related mistakes include pairing a fast-strong buffer with a fast-strong package when the conservative pairing is the opposite, and simulating a model whose analog description carries a full corner triple while its model-specific equalizer settings carry only a typical value, so that the tool's corner setting moves half the model and leaves the other half fixed.

Missing or Inadequate Package Data

The [Package] keyword is mandatory, so it is always present, but frequently with the reserved word NA in the minimum and maximum columns and a single lumped value standing in for every pin. A model with no per-pin data cannot support timing analysis, which is why the quality specification places per-pin parasitics at IQ3, and a model with no coupled description cannot show package crosstalk or simultaneous switching noise at all: the simulation simply reports that the problem does not exist.

Models That Do Not Run or Do Not Converge

Non-monotonic current-voltage tables are the classic convergence hazard, which is why the specification defines monotonicity precisely and the parser checks it. Tables that stop at the supply rails rather than spanning the required range leave the simulator extrapolating exactly where a reflection drives the pad, and omitted clamp tables give an undershoot no conduction path, producing ringing the real device would have damped.

Algorithmic models fail in a different register. A shared library compiled against a runtime the customer's machine lacks will refuse to load, which is why the specification recommends verifying each release on a clean operating system installation with a dependency checker. A thirty-two-bit library cannot be loaded by a sixty-four-bit tool. A model that assumes a fixed block size violates the requirement to accept any block length, and one that allocates state during initialization but never releases it will exhaust memory in a long crosstalk sweep.

Statistical and Time-Domain Results That Disagree

Disagreement is expected when the model is genuinely nonlinear or time-variant, and in that case the time-domain result is the meaningful one. Disagreement is a defect when the model claims to be linear and time-invariant, and the usual cause in a dual model is that the two implementations of the equalization drifted apart during development. A quick diagnostic is to run the time-domain flow with adaptation disabled and a short, repetitive pattern; if the two answers still differ, the model rather than the physics is the problem.

Interoperability Between EDA Tools

The specification fixes the interface and the reference flows, but a great deal is left to the tool. The sample interval, the block size, the stimulus pattern, which aggressors are selected, where jitter is injected, how many bits are discarded, and how a statistical treatment of a feedback equalizer is approximated are all vendor decisions. Two conforming tools can therefore return different eye heights for the same model and the same channel, and neither is wrong in a specification sense. The remedies are procedural: fix the sample interval and the pattern explicitly when comparing, compare at the same declared corner, obtain [AMI Test Configuration] data where it exists, and treat any material difference as something to explain rather than average away.

Silent Misuse of a Valid Model

Finally, a perfectly good model can be used wrongly. Simulating outside the declared [Voltage Range] or [Temperature Range] extrapolates data that was never characterized. Running an AMI model at a data rate its adaptation was never tuned for produces convergence behavior that means nothing. Treating the absence of Max_Init_Aggressors as permission to pass crosstalk, when the specification makes its default zero, quietly removes the aggressors. Each produces a clean-looking result with no error message, which is what makes them dangerous.

Conclusion

IBIS solved a commercial problem with a technical format. By reducing a buffer to tables of terminal behavior, it let semiconductor vendors publish usable models without publishing their circuits, and it let system designers simulate whole interfaces fast enough to iterate. IBIS-AMI extended the same bargain to the algorithms that make multi-gigabit serial links work, moving equalization and clock recovery into compiled code behind a defined interface so that the algorithm stays secret while its effect remains portable. Neither format substitutes for understanding what it abstracts. An IBIS model is valid only inside the voltage and temperature envelope it was characterized in, and its corners mean slow-weak and fast-strong rather than low and high. An AMI model supports a statistical flow only when its algorithm really is linear and time-invariant, and the parameters that declare this are assertions by the model maker, not properties the tool can verify. The engineer who reads the file, checks the quality designator, confirms which flow the reserved parameters permit, and correlates the result against hardware gets far more from these models than the engineer who loads them and accepts the eye that appears.

Related Topics