Signal Integrity

Power-aware Signal Integrity and EMI/EMC On High-speed Digital Chip-to-Chip Links

Signal Integrity header image 2

IBIS AMI FAQ

Posted June 14th, 2010 · 4 Comments · Article

Share

Posted by Colin Warwick

Updated 5/10/2011 to reflect AMI support in ADS 2011

Below are some answers to frequently asked questions (FAQs) about IBIS AMI (Input-output Buffer Information Specification, Algorithmic Modeling Interface). But before diving in, you might want to read this general intro that I wrote for Microwave Journal entitled IBIS AMI Standard for Multi-gigabit Links (which has a model user’s perspective). And you can also download our article AMI models: What, why and how?and joint paper with NetLogic Microsystems Automated AMI Model Generation & Validation (which have a model builder’s perspective). All set? OK, here we go:

Q1:What’s so great about IBIS AMI models?

A1: They have a number of benefits to both IC vendors who generate, simulate, and validate SerDes models, and OEMs who use them in a simulation.

  • Interoperability: Models from different semiconductor vendors work together e.g. TI DSP connected to Xilinx FPGA
  • Portability: The same model runs in different IBIS-AMI simulators. IC vendors can ‘write once, run anywhere.’ They don’t have to support a model for every favor of SPICE. An OEMs get to pick the best-in-class simulator, not just the one that happens to support a particular model. Note however, that some models that claim to be AMI models actually use proprietary semantics and are therefore non-portable. Buyer beware.
  • Performance: Ultralow BER contours in seconds not weeks using vendor-specific models in Channel Simulator. (In ADS 2011 the Channel Simulator supports IBIS AMI and generic Tx and Rx models.)
  • Flexibility: Models support both statistical and bit-by-bit simulation (stat mode is faster but doesn’t support time-varying feature called get_wave())
  • Optimization: Models expose control parameters (e.g. equalizer settings) that mimic registers you set set on the actual chip. You can set these in the simulation for rapid design space exploration (batch mode optimization)
  • IP Protection: Models cannot be reverse-engineered, semiconductor vendors control which details are exposed to the user, without the need for proprietary encryption keys.

Q2: What Agilent products support or will support AMI?

A2:(Updated July 12, 2011) Two EEsof products, one for model generation and one for model simulation. 1) SystemVue 2010.07 release will includes W1714 AMI Toolkit for IBIS AMI model generation (now available in Q3). There’s a technical kit you can download. The link is here http://www.agilent.com/find/eesof-ami-model-gen. 2. The next release of ADS 2011 will includes IBIS AMI model simulation. Early Access (beta) is scheduled to begin later in the year. 3. In addition, Agilent’s ‘scopes are used for model validation.

Q3: How does AMI relate to traditional IBIS? Does SystemVue just generate the AMI part or the whole IBIS model?

A3: SystemVue just generates the AMI parts: the *.ami and *.dll file. The IBIS AMI parts adds a new capability to traditional IBIS models. It doesn’t replace the need for traditional capabilities. IBIS AMI only models the signal processing parts of the Tx Rx for example preemphasis, equalization, clock/data recovery. Traditional IBIS I/O which is carried forward from IBIS 4.2 to 5.0 continues to model analog front end. Two new types of file are needed: a .ami file and a *.dll executable. The hierarchy is:

  1. Simulator – ADS 2011.01 or later
  2. .ibs file (text file analog I/O – calls out to .ami and executable file – you can write it by hand by following the “IBIS Cookbook” or hire a consultant like Teraspeed. There is also a free tool s2ibis that generates the file from a SPICE netlist.)
  3. .ami file (text file – kind of a header file for the executable – SystemVue can generate this)
  4. .dll file (Windows) (machine-code executable – SystemVue can generate this)

Here’s how an IBIS 5.0 file looks if it uses the (optional) AMI feature:

| Traditional information is in a *.ibs file
.
.
| IBIS files that use the AMI extension contain
| lines like the three below,
| in additional to the traditional analog I/O lines.
[Algorithmic Model]
Executable Windows_VisualStudio_32 my_ami_model.dll my_ami_model.ami
[End Algorithmic Model]
.
.

Q4: Currently we are seeing equalizer or de-emphasis in several high speed interfaces like HDMI. Would the IBIS AMI target be SI analysis for such a high speed interface? How about DDR?

A4: SerDes standards that allow for signal processing features like preemphasis, equalization, clock/data recovery can be modeled with AMI. Far-future versions of DDR might adopt these, but not present or near future ones. DDR is lower speed per pin and the cost targets per pin are very low. Signal processing is cost-prohibitive.

Q5: The six benefits listed above seem compelling, but can you provide more details in why IC vendors are switching to IBIS and IBIS AMI?

A5: In the old days, with a few dozen transistors in the I/O, IBIS models were only slightly faster than SPICE. But now with preemphasis, equalization, clock/data recovery, SPICE would need to model 30,000 transistors or more. It becomes very slow (50 bits per minute of simulation time). IBIS AMI is behavioral and very fast. The speed gap between SPICE and AMI is huge. IBIS AMI runs inside our fast Channel Simulator with its statistical and bit-by-bit modes. IBIS AMI speeds time-to-volume. Like datasheets, eval boards, and reference designs, IBIS AMI is an application engineering tool for the IC vendor. It makes their OEM customer successful and both benefit from a fast rmap to volume.

Q6:Why should IC vendors should use SystemVue instead of other tool like M-code or C

A6:The full M-code language cannot be automatically converted into a usable IBIS AMI DLL. People have tried to wrap the DLL ouput from MATLAB Compiler into an AMI model but it seems there are issues with speed and runtime library compatibility. A promising approach is to generate efficient standalone C from a math language that is an M-code-like subset of M-code, but presently, if you have M-code, you have to rewrite it by hand into C code first. Hand coding in C is laborious and error prone. In contrast, automatic AMI model generation in SystemVue is a side benefit of a whole top down ESL flow for SERDES design. IC vendors can explore the design space quickly. IBIS AMI model generation became almost just a side benefit.

Tags: ··

4 Comments so far ↓

Leave a Comment