IBIS Model: IBIS AMI modeling flow

In previous several posts, we talked about IBIS modeling of analog buffer front end.  In today’s post, we are going to give an overview of the modeling of the algorithmic portion which provide equalization to both TX and RX. These algorithmic blocks are usually modeled with IBIS AMI, the “Algorithmic Modeling Interface” portion of the IBIS spec.

IBIS AMI’s scope:

IBISAMI_Block

 

The figure above represents the channel from end to end. The passive channel is composed of various passive elements, such as PCB traces modeled with transmission lines and vias, connectors modeled with s-parameters. The pink block is the analog buffer which acts as front end to interface to the channel directly. They are usually modeled in IBIS. In the TX portion before the front end, and RX portion after that, are equalization circuits. They can be modeled in IBIS AMI. So the AMI model actually works with IBIS to complete the both TX and RX path from latch to latch, instead of pad to pad. In an IBIS model which use AMI, one will find a statement like below, which points to the AMI’s parameter file in .ami extension, and the compiled portion in either .dll (dynamic link library on windows), or .so (shared object on linux), and the IDE with which these .dll/.so files are produced.

IBISAMI_Include

Why IBIS AMI:

The main quantitative measure of signal integrity are eye height and eye width  of an eye plot. From eye plot, bit-error rate (BER) or other plot like bath tub curve can be derived. The eye plot is formed by folding many bits in time domain with waveform representing the response of these bit sequences. When doing end-to-end channel analysis with transistor  buffer or traditional IBIS model, one have to go through actual simulation to obtain such waveform. This is very time consuming and can only acquire very limited number of bits. In order to speed up the process, waveform synthesis is desired, thus brings the need of a new spec. and the invention of AMI. With this performance requirement for technical considerations included, the following lists why IBIS AMI is required:

  • Industrial standard: There are several high level modeling language, like matlab or system-vue, which can achieve the same aforementioned purpose within their own environment. However, this will limit the portability and choice of simulators. AMI bridges the gap by defining an open interface which all IC and EDA vendors can interact with to exchange data for system analysis.
  • Performance: As explained in the beginning of this section, very low BER requires data from millions of bits. It’s desired to be able to obtain this data in seconds but not days or weeks.
  • Flexibility: Before IBIS AMI, IBIS committee has attempted to address the equalization needs via now somewhat outdated keywords like driver schedule and bus hold. The time it take to revise these keywords in IBIS committee is just too long to meet the evolution speed of technology. Even in IBIS V4.0 era, other languages like Verilog-A are introduced, yet when million of bits and sensitive IP design (as explained below) are under considerations, compiled libraries in binary form (rather than interpreted like Verilog-A) can meet the demands much better.
  • IP Protection: EQ design is usually considered very sensitive IP to an IC vendor. Thus a model which can’t be reverse engineered and has better control over which design parameters to expose, like AMI spec, is desired.

What is in IBIS AMI:

Now that we know the scope and application of the AMI, let’s take a look at its components in more details. Depending on your perspective:

  • For an IBIS AMI model developer: IBIS AMI is an interface realized in three functions which you must provide the implementations in whatever language but compiled into .dll or .so. These three functions are Init, GetWave and Close:IBISAMI_Header
    • AMI_Init: This function must be implemented. Since lengthy bit sequence will be broken into small chunks and analysis accordingly, there are some data structure may be reused many times. In such usage scenario, the common “initialization” should be done in this function. It is somewhat llik “constructor” of an objective oriented language. When a direct pulse is used to synthesize the BER based on LTI (linear, time-invariant) assumption, computation will be done in this function and implementation of Getwave function is not needed.
    • AMI_Close: This function must be implemented. It acts as “destructor” to clean up and release the memory allocated back to OS.
    • AMI_Getwave: This function is optional to implement. If the channel is non-LTI, direct synthesis to get BER is not possible. In that case, the waveform of lengthy bit sequence is needed. GetWave function’s implementation provides such a mechanism to compute and convert the input bit sequence into their corresponding response.
  • For an IBIS AMI model user: three different files are included in an AMI model release:
    • IBIS file: This is the analog front end of the buffer. An “[Algorithmic Model]” must be used to point to the next two files, .ami and .so/.dll for the algorithmic part of the model.
    • .ami file: This is a plain text file which list the parameters model exposed, their variable types and range. For example, a 4-tap EQ with weights for one pre-cursor and three post-cursors are defined below. Also specified in the .ami file are implementation of the GetWave functions in compiled .dll/.so and the usage modes. When a simulator read the .ami file through pointer from the .ibs file, it will know how to interact with the .dll/.so files for system analysis.

IBISAMI_AMIParam

.dll/.so:

      These are compiled portion of the model. Note that both .dll and .so files also depends on your OS is 32-bit or 64-bit. So to run such AMI models on an 64-bit machine, one must have 64-bit .dll or .so as well.

 
IBIS AMI usage scenarios:

An AMI model developer can’t foresee how the developed models will be used. However, the model’s implementation itself will impose such limitation. There are two modes of AMI operations: Statistical or Empirical. If the “GetWave” function is not implemented, the model will only be able to run in “Statistical Flow”, meaning the passive channel must be LTI. On the other hand, if “GetWave” function is implemented, then the model may also run in “Empirical Flow”, which allows non-LTI channel. The figure below gives an overview of the two modes of AMI operations:

IBISAMI_Work

      • Statistical flow: In this flow, the channel is LTI. That means waveform from different bit sequences may be constructed from single bit’s impulse response using superposition. So provided TD impulse response of the passive channel, the TX and RX models can perform convolution on such single pulse. Once the simulator receive the this from RX model, it can perform peak distortion analysis like superposition to get the BER or eye directly.
      • Empirical flow: In this flow, the channel is non LTI and no waveform superposition should be done. Thus a digital bit sequence must be formed. This sequence may or may not be broken into smaller chunks then convolved with passive channel portion’s impulse response. The results are then called via TX and RX’s getwave function to form actual TD waveform of the full channel. Simulator will then fold the waveform to compute the BER and other parameters.

In reality, TX and RX AMI models may be from different vendors. Thus their combination also set the limits on how the models can be used. Interested user may see the section 10 of the IBIS spec. for detailed operation explanations.

This post gives a brief overview of IBIS AMI. The modeling flow of AMI model impose a challenge to the model developers. They usually need to know more inside details about the EQ design rather than doing black-box modeling approach. Besides, the extracted EQ  algorithms along with their parameters must be coded in C/C++ at least in order to compile and generate required .dll/.so files. Lastly, the flow is more or less EQ implementation dependent (depends on which high-level language the EQ was designed) and the model validation also requires deeper knowledge about the signal integrity. It’s common to have both EDA and SI expertise like what we have here at SPISim to work closely with IC vendors to deliver such models in good qualities. In the future posts, we may come back to cover all these steps and topics in more details.

Leave a Reply

Your email address will not be published. Required fields are marked *