The majority of this topic is leveraged from Keysight ADS documentation.
In this topic:
AMI (Algorithmic Modeling Interface) is the modeling interface for SERDES behavioral models which simulate SERDES functionalities such as equalization and CDR. The AMI flow was added alongside the traditional (SPICE-based) IBIS flow in IBIS version 5.1. The AMI portion is specified in a section of the IBIS file known as the [Algorithmic Model] section. The AMI portion acts as a DSP block which takes an input signal waveform and/or impulse response and outputs a modified waveform and/or impulse response. AMI models are developed by SERDES vendors to match and represent the actual chip behavior. Vendors deliver models in the form of DLL or/and shared object to protect their IP plus the .ami and .ibs text plain files.
See also white paper Explore the SERDES design space using the IBIS AMI channel simulation flow.
An AMI model consists of the following files:
.ibs file: specifies file names (.ami and .dll) and compilation platform in the [Algorithmic Model] section as well as linear analog properties in traditional *.ibs format.
.ami parameter header file: specifies model parameters.
DLL (.dll) or shared object (.so) file: three functions called by the simulator:
AMI_Init (char * params_in, …) - initialization Note Despite its name, AMI_Init also deals with LTI impulse response processing
AMI_GetWave (waveform_in, waveform_out, clock_tick_array) - NLTV waveform processing if needed
AMI_Close ( ) - memory deallocation etc.
The following are types of AMI parameters:
Parameter |
Description |
Reserved |
Reserved parameters are common parameters that are shared by all models. Their names, types, and meanings are defined by the AMI standard. |
Model specific |
Model specific parameters are private to the model. Model makers can define any number of model specific parameters under any name and any type. |
Each AMI parameter has one of the following four usage types:
Usage type |
Description |
Info |
Info parameters are only used by simulators. |
In |
In parameters are only used by models. |
InOut |
These parameters are both used and updated by models. Their returned values will be used by simulators. |
Out |
These parameters are for models to returned values used by simulators. |
Note: Only values of parameters of In and InOut types can be set by model users.
AMI models are applied in channel simulations to take into account effects of SERDES devices on channel performance. As shown below, the AMI methodology divides the channel system into three parts:
Tx AMI block
Analog channel
Rx AMI block
The analog channel includes the transmitter back-end, the physical channel, and the receiver front end.
When both Tx and Rx have NLTV AMI_GetWave functions, during simulation the stimulus signal is first processed by the Tx AMI model. The Tx output signal is subsequently injected into the analog channel. The channel output is then processed by the Rx AMI model. The Rx output is used to calculate the eye and BER. In other cases, the standard sometimes dictates different processing order.
Signals in AMI simulations are assumed to be differential.
For more information, refer to white paper Explore the SERDES design space using the IBIS AMI channel simulation flow.
Channel simulation of SERDES with the IBIS AMI flow offers many advantages over other techniques including:
IP Protection: Models cannot be reverse-engineered because only machine code is shipped. IC vendors control which details are exposed, without the need for the proprietary encryption keys that make models non-portable.
Portability: The same IC model runs in different IBIS-AMI simulators. IC vendors can ‘write once, run anywhere.’ They do not have to support one model for every EDA tool vendor. The signal integrity engineer can choose the best-in-class simulator, and not be forced into using the one that happens to support a particular IC model.
Note: Some models that claim to be AMI models actually use proprietary semantics and are therefore non-portable.
Interoperability: Models from different semiconductor vendors work together, for example: a TI DSP connected to a Xilinx FPGA.
Performance: Ultra low BER contours in seconds not weeks.
Flexibility: The flow offers two modes: statistical and bit-by-bit (also known as “time domain”) modes. Statistical mode is faster but less flexible. Specifically, the IC models must be linear and time invariant (LTI) in statistical mode, whereas they can be non-linear and time varying (NLTV) in bit-by-bit mode. Simple circuits like a de-emphasis filter are LTI, but for more complex circuits like adaptive equalizers and clock/data recoverers, you have to invest in an NLTV representation.
Note: PLTS only supports the bit-by-bit mode right now and doesn’t support the statistical mode.
Optimization: Models expose control parameters (example: equalizer tap settings) that model the registers you set on the actual chip. You can set these manually in the simulator user interface (UI). Or you can allow a batch mode or optimization controller to set these for automatic and rapid design space exploration.
The last five goals are aimed at making the AMI approach technically sound, but the first one is aimed at overcoming an issue related to the supply chain: it is in the interest of both IC vendors and IC consumers (the OEMs) for the IC vendor to supply the information needed to design the chip into a system. Encryption works, but this makes the models non-portable, forcing the IC vendors to create and support one model for each EDA vendor’s encryption key. Thus, in the AMI approach, IC vendors provide only machine code executable representing behavior, not implementation. This gives adequate IP protection and reasonable portability. IC vendors must however provide one executable per computer platform (example: Win32, Win64, and Linux64) because executables are not portable across operating systems.
The AMI flow is based on an entirely new type of simulator, called a Channel Simulator. It uses computationally-inexpensive algorithms like superposition, convolution, and statistical analysis of the end-to-end impulse response. The eye pattern diagram is generated thousands or millions of times faster in a channel simulator compared to a SPICE-like simulator.
PLTS Multi-Channel Enhanced Eye Diagram supports IBIS-AMI models compliant to the IBIS 5.1 specification. It does not support IBIS-AMI models with non-compliant/proprietary features. There exists non-compliant IBIS-AMI models that are not clearly marked as such. It is your responsibility to verify with their vendors to ensure the IBIS-AMI models you plan to use in ADS or PLTS do not contain non-compliant and/or proprietary features outside of the IBIS 5.1 spec.
In general, PLTS Multi-Channel Enhanced Eye Diagram does not support third-party proprietary, non-portable extensions to IBIS and IBIS AMI. Some third-party models include such extensions without any obvious indication that they are present. For example, PLTS does not support models containing the “pipe SiSoft” comments that are in fact proprietary QCD semantics.
| [SiSoft] xxxxxx
Proprietary QCD semantics embedded in the model_specific parameter syntax in the *.ami file, for example:
(Model_Specific
(Voh (Usage Info)(Value 0.9)(Type Float)
(Description "Output open circuit high voltage")
)
(Vol (Usage Info)(Value 0.0)(Type Float)
(Description "Output open circuit low voltage")
)
(Trf (Usage Info)(Value 40e-12)(Type Float)
(Description "20%-80% output rise time")
)
(Rs (Usage Info)(Value 47.75)(Type Float)
(Description "Single-ended output resistance")
)
(Cc (Usage Info)(Value 0.5e-12)(Type Float)(Default 0.5e-12)
(Description "Output Capacitance")
)
)
Such non-portable models require extensive rework to run in PLTS. Contact your IC vendor for a portable version.
The setup of AMI simulation is similar to that of regular Multi-channel Enhanced Eye Diagram.
PLTS provides AMI components of:
Transmitter TX AMI
Receiver RX AMI
Crosstalk transmitter XT TX AMI
Crosstalk receiver XT RX AMI
Learn how to setup AMI in Multi-channel Eye Diagrams.