SPISim’s AMI Capabilities Overview:

Design concept:

SERDES based links, such as USB, PCIe and SATA, are now ubiquitous. Their SI analysis poses special challenges as low bit error rate required by their spec. means millions of bits needs to be simulated. In stead of using transistor level design details or proprietorial behavior blocks (e.g. Verilog-A or matalb model), an industrial standard, exchangeable modeling format are usually required. This is because Tx and Rx IPs may not be from the same vendors, nor are the simulator or analysis tools used by IC and system integrator. IBIS-AMI is currently the industrial standard for this purpose. Just like a traditional IBIS, only more cross-domain knowledge demanding and technical challenging. It requires certain flows to be able to test, generate, validate and release IBIS-AMI models.

Comparing to other commercial IBIS-AMI flow offerings, SPISim’s AMI approach covers usage of all scenarios: from modeling to validation, from roles as an AMI user, an AMI model developer to an AMI model publisher. This is achieved without expensive 3rd party tools. We will give an overview of our design concepts and application scenarios in the following sections.

Environment:

SPISim’s AMI provides add-on capabilities integrated to SPIBPro (SPISim’s IBIS analysis module) and SPIXPro (what-if analysis module) on top of SPISim’s framework. All the embedded AMI drivers and spec. models are cross-platform (Windows 32, Windows 64 and Linux 64). With SPISimAMI, SPISim Pro enables cross-platform AMI flows all within one framework.

Flows Overview:

SPISim’s AMI flows covers two main categories: validation and generation.

• Validations: this is essential to a model user and a publisher.  As a:
  • Model user: you will want to test the models at hand and see whether they work properly and generate desired response before running simulations.
  • Model publisher: you will want to be able to exchange data with model users especially when the results produced by your released models are problematic. This data exchange needs be accomplished without the other party using same and/or expensive tools you using.
• Generations: this is essential to a model developer. There are several ways to generate IBIS-AMI models:
  • Spec./datasheet based: simply select modules to be used or assembled as AMI and their parameters. The corresponding AMI models, along with .ami settings and analog front end IBIS models should be generated without any c/c++ compilations.
  • What-if: Alternatively, user can experiment with link performance using generic Tx/Rx blocks and settings to see their performance. When satisfied, a click will transfer the existing settings to the spec./datasheet module and generate spec. AMI models.
  • Custom built: With more complicated Tx/Rx modules, such as multiple predefined CTLE responses and CDR blocks, custom built is still required. However, the modeling architectures should allow model developer to easily create and test such custom built models. In SPISim’s flow, user can either opt to use their chosen script (matlab, python etc) for custom built AMI model without any C/C++ coding or compilation, or charter us for the modeling service.

IBIS-AMI model generation:

While most advanced AMI models need to be custom built, default version should also be available without complicated process. This can also be useful when the design parameters are not yet finalized and one would like to use a “behavioral” AMI model to explore possible solution spaces.

Fortunately, most of the SERDES function block can be modeled with pre-determined behaviors… such as feed forward equalizers (FFE), continuous time linear equalizer (CTLE) and decision feedback equalizer (DFE, CDR) etc. These functional blocks may be selected to form channel stages at the Tx or Rx ends to process input signals in a cascaded manor. Their parameters (number of taps, each tap’s weights and frequency response etc) should not be hard-coded in the AMI C/C++ models. Instead, parameter should be used to allow fully customization without recompilation. With this approach, models can be pre-built to support spec./datasheet settings. This is most economical and efficient way to build IBIS-AMI models.

To support this practice, SPISim has pre-built 10+ analog IPs in cross-platform, AMI-Spec. compatible forms ready to be assembled, tested and released. As of Mar/2017, we have the following Analog IP modules available:

• FFE: Feed forward equalizer

This is an FIR based filter, number of taps and their weights can be customized. Industrial spec. such as PCIe usualy have pre-determined combinations to acieve desired emphasis level

• FFE Optimized: MMSE based FFE

This is optimized version of FFE, the tap weights can be optimized such that best result can be recovered after channel. Different algorithms such as MMSE may be used for the optimal weights selection. Channel response input is required in advanced for the optimization process

• AGC: Automatic gain controller

This will adjust the signal amplitude dynamically to be limited within certain level. In comparison to regular (fixed) gain controller, this will avoid clipping and/or distortion. The rate which gains should be adjusted are part of the parameters.

• VCO: Voltage controlled oscillator

This often works with PLL to provide clock or data recovery. Depending on the voltage amplitude, different oscillator functions or pattern can be used to generate modulated signals.

• AFE: Analog front end

AFE may appear at different location of the channel. As a pulse shaping block, it can translate digital input to input with slew rates etc. As Tx/Rx front end, they can take output/input impedance and C_Comp load into account. Alternatively, the analog front end can be considered as part of the channel response (to be given to Tx) with IBIS’s effects included. In this case, IBIS will serve and provide the AFE functions.

• PTH: Pass through

Pass through module are very in debugging and testing scenario.To enrich its capabilities, we also added gain and level shifting features in the AMI block.

• DSP: Digital filters

We have filter design and effect capabilities built-in in this DSP module. User can select from Bessel, Butterworth, Chebyshev I, II, Legend etc filter categories, specify their low pass, high pass, band pass, band gap etc types, number or orders and parameters such as pass band gain, stop band ripple in dB, cut-off/centered frequencies etc and associated DSP filter will be constructed and used within the assembled AMI model. The constructed DSP’s parameters and frequency response can also be output by user’s request for validation purpose.

• CTLE: Continuous time linear equalization

This is a LTI filter. User can provide desired frequency response or parameters and the filter will be calculated. Multi-set peaking parameters or response functions are possible through proxy/script based prototyping or our modeling service.

• DFE: Decision feedback equalizer

DFE is a NLTV post-cursor only FIR filter. Number of taps are pre-determined and their weights are updated dynamically based on the signal just sampled (sliced). The rate and scaling of the change rate can be specified. Slicer function can range from ideal summing node to IIR based function node. This module needs to work with CDR as clock signals are needed for the slicing function.

• CDR: Clock data recovery

CDR is a phase detector which take continuous time domain waveform as an input and determine the clock edges. There are different types of phase detector… Alexander (Bang-Bang) type is easiest and most often used. Clock tuning rate is also one of the adjustable parameters

• PROXY:

While pre-built models will meet most common usage needs and provide best simulation performance (due to it’s C/C++ coding), sometime customizing and prototyping are still needed to make the AMI model capable and flexible. In this case, SPISim’s Proxy AMI model can also be used. User can use their favorite script, be it Matlab, python or octave, to code AMI functions without any need of C/C++ or cross platform compilation.

• Cascaded:

The modules above provided basic build blocks for more advanced AMI models. For example, RX model usually include FFE + CTLE + DFE+ CDR. Redriver is composed of back-to-back RX model + TxFFE, ReTimer is similar to Redriver only that its Rx output is recovered bit sequence rather than deteriorated analog waveform. All these can be achieved in our framework.

Upon completion of the assembling, user only need one click and SPISim Pro can test drive the model to visualize its response. One “generate” button click will produce the assembled AMI model (cross platform) along with its .ami and .ibs file right away.

IBIS-AMI parameter locking:

To avoid generated models being tampered (as the settings are in the plain text .ami file and is subject to easy manipulated), a “locking” mechanism may also be added to support certain features for certain customers.

IBIS-AMI model validation:

In SPISimAMI, model validation can be accomplished in one of the following two ways:

• Individual model driver:

To validate a model, first one needs to make sure the model received is compatible with the intended operating platform (32 bit, 64 bit etc). Then the model must also be compatible with AMI API. While the latest golden checker provids basic check on the API aspect, it does not “drive” these functions. Thus to complete testing the model, an input response must be provided to feed the model by calling the compatible API functions (e.g. AMI_Init and AMI_GetWave). The input/output results should be captured in non-proprietorial formats for easy inspection. SPISimAMI perform all of these: it allows user to provide customized input in tr0, csv or raw format while also has embedded default rise, fall step and pulse response. It then load and call the model’s API and capture all input/output data. With these, a model user can quickly check the response (e.g. EQ etc) of the AMI models at hand.

Note that SPISim distribute these cross-platform model drivers free of charge. It’s also built-in in the SPILite tool. That means SPISim Pro can be served as a neural/free medium between model publisher, developers and end users to exchange data without involving 3rd party/expensive tools. The model driver alone is also useful as a AMI model loader when developing and debugging the AMI models (i.e. no need to invoke 3rd part tool to load the AMI models under debugging and avoid license usage)

• A proxy model for AMI modeling without C/C++ or compilation

One of the common wishes for AMI modeling is to be able to use their favorite language, be it matlab, python, perl or others without dealing with C/C++ coding or .dll/.so compilations. Another often desired capability is to be able intercept and expose data being exchanged between simulation platform and compiled AMI model for debugging or maintenance purpose.

SPISim’s AMI flow include a proxy model, SPISimProxy, which will support these needs. It’s been pre-compiled into binaries of different platforms and can interact with AMI functions written in your favorite scripting language. In dual mode, it can also work with both AMI model and your scripts such that extra stages of functions can be added on top of existing work. Together with SPISimAMI, they will enable economic yet efficient AMI development process without any front-end cost or being tied to a particular vendor tools.

• Full AMI based link analysis

To further validate the models, one needs to use both Tx and Rx AMI models and run link analysis with user provided channel response. In this process, Tx and Rx may be from different IP vendors or even in different OS format. Channel response can be either impulse, pulse in time domain or S-param through type data. A link analysis will take this channel response to convolve with PRBS sequence and form bit stream before feeding the data to Tx and Rx module respectively. End results can be plot in either time domain or form an eye plot.

IBIS-AMI what-if model generation:

One may also perform full link analysis first before determining parameters of the AMI models to be built. In this case, a link analysis function becomes very useful. It has several considerations:

• Given a passive channel response, how does the channel’s performance look like.?This can be answered with BER analysis for the given channel data
• After adding modules  such as FFE, CTLE, DFE, CDR etc, how does the link performance look like? One can plot the time domain and frequency domain stage by stage and observe their changes. Final data can be plot in eye with statistical data and/or show CDR adaptation process. This is usually an iterative process before the parameters of different stages are finalized.

Once the settings are determined, they can be passed into spec/datasheet model generation module. The end results is AMI model generation with several simple clicks and can be again validated with AMI based full-link analysis.