Customize and export IBIS-AMI models

Bottom-up AMI modeling flow via SpecAMI model generation:

The “bottom-up” modeling flow via Spec. AMI model generation or SPISim_AMI web apps is shown below. It supports customized EQ model composed of one or more cascaded stages. SPISim already has developed many such stages, each with different capabilities, to be used. Tentative model can be driven by built-in stimulus or user provided channel response to see its performance immediately. In modeling suite, Invoke “IBIS”->”Spec. AMI model generation” will bring up this dialog:

Most commonly used SERDES functional blocks have been developed, tested and made available through this GUI:

  • FFE: Feed forward equalizer

This is an FIR based filter, number of taps and their weights can be customized. Industrial spec. such as PCIe usually have pre-determined combinations to achieve desired emphasis level. This “look-up” table like capabilities is also built-in to our AMI models.

  • 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. In addition, the output range can be automatically adjusted to be within certain ranges w/ or w/o soft clipping.

  • 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.

  • SPICE:

Similar to Proxy model, a spice based AMI model include sub-circuit definitions of the EQ circuit. PWL sources will be formed by the model to drive this spice circuit using user specified/licensed spice simulator. Output will be probed and converted back to AMI compatible waveform structure and return to the channel simulator. With AMI, “high-Z” conditions are assumed at both the input and output terminals.

Cascading blocks:

Each stage mentioned above provided basic build blocks.  For more advanced AMI models, usually one ore more such blocks are put together. For example, RX model usually includes FFE + CTLE + DFE+ CDR. Redriver is composed of back-to-back RX model + T xFFE, 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.

For example, the configuration below shows a cascaded CTLE + PTH (VGA) + DFE/CDR each being configurable further:

 

Model validation:

Once one or more cascaded stages have been configured, user may click “Check” button to test drive this newly composed IBIS-AMI model. A dialog like below will show up to let user select either built-in stimulus or pre-prepared input file in csv format.  As all SPISim’s spec model has both AMI_Init and AMI_GetWave defined, they can be operated in dual modes and will be driven in both AMI API calls respectively.

Resulting waveform may be viewed in place within the dialog. Alternatively, it can be displayed in more capable VPro waveform module, allowing user to perform measurement and further analysis. This can be useful in case model works in frequency domain… such as CTLE. As it’s not easy to validate the model’s performance via time domain waveform.

The process above can be iterative. That is, user will be able to update or tune the composed AMI model parameters and test drive again to check the resulting waveform. Once the model delivers desired performance, user may proceed for model generation.

It’s worth noted that the settings presented in our GUI for each AMI model is only one set of values. A typical AMI model will have many “skews”. Each skew corresponds to different set of values. These “skews” are mapped to parameters defined in IC products’ data sheet. In SPISim’s AMI model, we have innovated “look-up table” mechanism allowing user/data sheet defined parameters. For numerical parameters, up to two dimension (bi-linear) interpolation are also supported so table of coarser grids may be used. This will decrease model table size significantly. For more advanced mapping, a general scripting language via JavaScript may also be used to create parameter mappings. This enables many possibilities such as DOE/RSM or even ANN based parameter mapping. All user’s data, including data table and scripts, are encrypted and only decipherable by our AMI models. They can also be compressed in a zip format and our model will decompress when it’s run in the calling process for the first time.

Before model generation, use may choose to edit AMI file for customized information such as model name, descriptions, number of bits to be ignored and jitter etc. SPISim’s tool has built-in ANTLR V4 based IBIS and AMI parser which supports cross-platform .ami editing capabilities such as picture shown above.

The bottom-up flow can complete AMI model generation in seconds… no coding or compilation are required. All Win64, Win32 and Linux64 version of the binary models together with .ami and .ibs file will be generated for user to run. Note that the .ibs file generated here is a “template” model. To model their behaviors accurately, user can use our modeling suite’s functions such as full IBIS modeling flow or Spec. IBIS model generation.