A channel analysis trilogy

Posted on by
Reply

Preface:

We SPISim recently developed and released free web apps for various channel analysis tasks [Click HERE for overview]. While their product page each gives good descriptions and demo about what each tool can do individually, we think it will also be beneficial to put them all together in one flow so that user may have better picture about our ideas behind these developments. Thus this post is written for dual purposes: First we would like to explain how a channel analysis is usually performed. Secondly we want to show how one can perform such process using apps even directly from the web browser. Just for comparison, creating AMI models and license for this type of simulator usually costs tens of thousands of dollars up front. Now it can be done for free!

The big picture:

[Fig. 1, A SERDES system]

Let’s use a SERDES system, shown in Fig. 1 above, as an example. For other interface’s such as DDR, please see our previous blog post for considerations about similar application.

A SERDES system uses a point-to-point topology. In Fig. 1, the middle block enclosed in blue represents the channel. It mainly contains passive interconnect such as package, transmission line, vias, connectors or even cable. However, the channel may also include active components such as Tx and Rx devices. These active components are usually represented by IBIS or spice models. Alternatively, we can pull these active components out from the channel and “merge” them into the EQ as “analog front end” stages. In that case, the channel become pure passive. One of the reasons why one may want to do it this way may be either that the IBIS models are not be ready, or there are no simulators available to have them included as part of the simulation. This is usually the case when a free spice simulator is used as none of them that I am aware of supports IBIS out of the box. In general, unless analog front end AMI models and a pure passive channel, represented as a S-parameter, are used together for the analysis, the active devices do need to be part of the channel characterization in order to obtain accurate time domain response.

The next step is to obtain or generate AMI models for each Tx and Rx EQ circuits. Interested reader may refer to several posts we have written about possible software architecture and methodologies.

Regarding the channel analysis process, a simulator will first convert the characterized channel in s-param, or step response into impulse response first, then depending on the simulation mode being specified, this response or convoluted bit sequence will be fed into Tx and Rx respectively to obtain the overall response. For LTI system, a permutation process will be performed for all possible bit combinations to calculate the PDF of each sampling point statistically, then integrate to obtain the CDF and thus create a bath tub plot. For  a NLTV system, bit-by-bit waveform is accumulated and overlapped to plot the eye and BER may be extrapolated from there. While not mentioned here and also not yet implemented, various jitter and noise components are also important when creating the stimulus or calculating final results.

Following the analysis procedure detailed on Section 10.2 of IBIS spec, to summarize them briefly, a channel analysis includes three tasks: channel characterization, EQ model creation and putting them all together for channel simulation.

Task 1. Channel Characterization:

The first step of channel analysis is to characterize the channel, the blue block of Fig. 1, in order to obtain is time domain response. Even with active Tx/Rx front end being involved, the assumption here is that the characterized response will be linear time invariant (LTI). With a LTI input, a channel simulator can either perform statistical analysis if other EQ components are also LTI, or it can have the impulse convolved with PRBS bit sequence to generate full time domain waveform, finally procees to process with NLTV EQ components to get the final time domain waveform for further eye analysis.

If the passive channel is from post-layout, then user will need to use other 3D extraction tool to obtain the interconnect’s s-parameter. Devil’s details here will then include making sure the S-parameter is in good qualities such as being passive, causal, symmetric and asympotic etc. Also depending on the simulator, converting the single ended s-parameter to mixed-mode/differential one may also be needed. On the other hand, for pre-layout case, user will then first obtain or generate each component’s simulation model. Assuming what user have here are Tx and Rx IBIS model, transmission line and other R/L/C based behavioral models for package, via and connectors, then first one can use our [SPISim_IBIS web app] to convert those IBIS model into free simulator compatible spice subcircuits:

Then head over to LTSpice, offered by Analog device, to download and install the free simulator.

Either create schematic or a text netlist of the channel them perform a transient simulation to get its step response. The output will be a raw file in compressed format which can be viewed either in place in LTSpice or use SPISim’s free SPILite:


Task 2. Tx/Rx EQ Modeling:

If no EQ circuit is involved, then user can simply tinker the circuit/simulation settings completed in task 1 to perform conventional time domain based SI analysis. The reason stat-eye like channel analysis comes to play is because EQ circuits (represented in green block for Tx EQ and orange block for Rx EQ in Fig. 1) are involved to open the eyes and many more bits need to be “simulated” to obtain/extrapolate low BER, thus can’t be done easily using nodal based spice simulator as it will simply take too much time. EQ circuits can come in different models such as behavioral, spice or AMI, with AMI being the common denominator supported by almost all channel analysis tools from different vendors. Thus in the second task, we need to generate IBIS-AMI models for Tx and Rx EQ.

IBIS-AMI modeling usually involves C/C++ coding or compilation into .dll/.so if starting from scratch. However, user may use [SPISim_AMI web app] to generate AMI models instantly without going through those steps:

Test driving the model and view its response in place to verify the model’s parameters meet the performance needs:

Then click “Generate” button and the AMI model will be generated instantly. If cross platform models are desired, use [SPILite] instead and all Windows 64, Windows 32 and Linux 64 models will be generated in one shot.

At the beginning of this section, we mentioned that the EQ model can also be in the form of spice circuit, whether encrypted or not. In that case, its detailed behaviors will not be able to be described exactly by template based  or pre-defined models. However, a spice wrapper AMI model supported by SPILite can still be used, it will make this spice model “AMI compatible” and can be used in other channel simulators. User’s licensed/installed simulator will be called during the channel simulator.


Task 3. Channel analysis:

With both Tx/Rx EQ models plus channel response being ready, we can then perform the StatEye based channel analysis using [SPISim_Link web app]:

Detailed usage about this tool is demonstrated in a video on its product page. Basically, user can specify the generated AMI models in the “Tx EQ” and “Rx EQ” tab respectively, then do the same for the step response waveform to the “channel tab”. Both “statistical” mode and “Bit-by-bit” modes are supported here, yet if NLTV EQ such as DFE is used in part of the receiver, then “statistical” model can not be performed. With these set-up ready, a “Simulate” click will show the results in place within seconds:

The bath tub curve representing the CDF is also ready for inspection/eye measurement:

Alternatively, task 1 and 2 are also directly supported in the SPISim_LINK function alone so user may choose to experiment with different settings and see their response first before generating corresponding AMI model. For example, a simple change of post-tap value in Tx can be done in the UI:

Then the re-simulation will quickly show its effect in resulting eye:

For a system developer, he/she may obtain corresponding AMI models from their IC vendors and follow the same process to give these model a try. For an IC vendor, the AMI model generated here will also be compatible with other vendor’s tool and you may provide these models to your system clients before committing to perpetual version of the model.

Here you have it…. an economic yet efficient channel analysis which can be done directly through the web has been enabled for your design needs without any cost!

IBIS/AMI: Equalization in coming DDR standard

Posted on by
1

Preface:

At the DesignCon IBIS summit this year, the second half of the meeting focused on the trend and possible approaches for equalization modeling for DDR interface. For the past several years, IBIS-AMI modeling and stat-eye like link analysis have been applied widely and successfully on the SERDES interfaces. DDR, on the other hand, didn’t consider EQ much until recent DDR4 3200 or faster or upcoming DDR5/DDR6 standard. Whether AMI like model and SERDES like flow can be applicable to DDR are still topics of discussion, as the AMI spec itself still doesn’t support DDR properly yet. Nevertheless, the trend indicates that EQ model being part of the DDR simulation will be inevitable.

At the summit, representatives from EDA vendors focusing on AMI and VHDL based approaches and a DDR manufacturer have shared their studies. Interested reader may find related presentation at the IBIS website. Following up these discussion, we at SPISim also performed several experiments of AMI on DDR. In this blog post, we would like to share some of the considerations on this topic as well.

Some major differences between SERDES vs DDR:

There are several major differences between SERDES and DDR interfaces which will affect how EQ models being used as part of the simulation:

  • Point-to-point vs Multi-Drop:

A SERDES channel is point-to-point, as shown above. Signals started from a TX propagate through the channel are received by one RX. This Tx-Rx connection may be cascaded in several stages with repeater being used in the middle. A repeater itself contains a Rx and Tx.  Repeater may be required as SERDES interfaces may extend very long…from controller to the edge of the board and beyond to connect to external devices (USB, SATA etc). Nevertheless, a SERDES channel looks like a single long “chain”. Thus the nature of the SEDES is “long” and “lossy”.

DDR, on the other hand, is multi-dropped by nature. There is usually one controller on board but several “DIMM”s connections on the other ends. For example, a typical laptop has two SO-DIMMs at least which has combinations of being soldered on board or plug-able through memory sockets. The desktop or server board will have more DIMMs to allow more installed memory. Depending on it’s dual channel, 3-channel or quad-channel etc, they may come in pairs of 2, 3 or 4 respectively. These memory modules usually do not reside too far away from the controller in order to avoid latency, thus no repeater mechanism is needed. The DDR’s topology presents a “short” yet “reflective” nature due to the impedance change at branch points and different termination within each DIMM modules.

  • Differential vs Single-ended, Embedded clock vs source synchronous:

SERDES interface are differential, that means they are more immune to noises such as voltage droop or ground bounces, as both P and N signals are susceptible to the same effect so the overall noise is cancelled out. That’s why power-aware models starting from IBIS V5.1 are rarely needed for SERDES. DDR, on the other hand, has many single-ended signals. All the DQ byte lanes are singled-ended so power noise is of a major concern.

Another architecture difference is clocking mechanism. SERDES uses embedded clock so clock signals need to be recovered at Rx from encoded bit-stream (e.g. 8b/10b), which is also part of the transmitted data. A CDR is needed to recover such clock signals and it itself is level sensitive/dependent. DDR uses source synchronous so clock is transmitted separately.

  • Operation modes:

For SERDES, there is one direction of signal propagation. Schematic-wise, Tx located at the far left while Rx sit at the far right. Some of the DDR (e.g. DQ) has both read and write modes. Both the controller and memory module can serve as Tx and Rx roles in different modes so the signal is bi-directional. In addition, there are different on-die-termination (ODT) in DDR so the impedance of different DDR module will be different depending on which one is receiving/driving. This “combinatorial” characteristics increases the complexities of EQ optimization as more dimensions need to be swept or analyzed.

Various EQ methods for DDR:

Until recent years, the analysis methods for  DDR and non-DDR interfaces are very similar. Topology (either pre-layout or post-layout) are composed or extracted for spice-like analysis in time domain. Worst case pattern may be decided in advanced or just perform long enough simulation to cover sufficient bit sequences. Time based or related performance parameters are than processed and compared against spec. to determine the channel performance.

With the higher bit-rate and low BER requirement, this approach is no longer valid for SERDES. StatEye like convolution based simulation has replaced spice simulation and EQ modeling are also changed to accommodate this analysis requirement. That is why the AMI are getting popular and important these days. We start seeing EQ in DDR4 3200 and will sure to see that being part of upcoming DDR5 and DDR6 etc. So what are the EQ modules we often used in SERDES can be applied to DDR?

  • FFE: Feed-forward equalizer. It uses various numbers of taps and weight to eliminate or de-emphasize the signals at different UI. As DDR is quite “reflective”, this EQ method should improve the link performance as it can be used to cancel ISI. The challenging part is that FFE tap weight is pre-defined and may not be adaptive during communication.

The screen-cap below show FFE effect on either single-ended (SE) or differential (DP) signals of different tap location.

  • CTLE: Continuous time linear equalizer. This is usually used to amplify signals of a particular frequency and/or provide DC boost. For example, USB3 operates mainly around 5GHz, thus a CTLE of boost at this frequency can help improving lossy channel for better signal quality. CTLE usually resides at the RX side, its another capabilities is to provide DC boost so that voltage swing received can be amplified to meet the eye requirement. Giving a data sheet:

  A set of CTLE curves are often available to boost these performance parameters in frequency domain:

As DDR channel is short but not that lossy, it’s been shown that CTLE is not that useful comparing to its role in SERDES.

  • DFE: Decision feedback equalizer. In SERDES, DFE comes with CDR as a DFE needs clock signals to preform “slicing” for tap adaptation:

While this is another form of ISI cancellation, it can be applied dynamically based on the link condition. So there is a period before the DFE will “lock-in” with stabled tap weights. For this reason, it has similar effect as FFE for a reflective channel yet may be more versatile. However, the DFE itself is non-linear so it can only perform in bit-by-bit mode. In contract, FFE is a FIR and can be used in both statistical and bit-by-bit mode simulation.

As both FFE and DFE show similar effects of ISI cancellation, there may be redundancies if both are used at the same time. Our study validates this assumption in one of the case whose results are shown below:

Both FFE and DFE alone will open the closed eye significantly yet when used both together, the results is not much different from only using one of them. If this is the case for most DDR cases, then the important topics is to perform “sweep” efficiently in order to find out number of taps and weights required in either FFE and DFE module used.

Insufficiencies of current AMI spec for DDR:

As of today, IBIS-AMI being applicable to DDR is still questionable. This is because IBIS-AMI so far is SERDES focused and it’s spec. need to be revised before DDR can be covered. Here are some of these shortcomings that we are aware of:

  • Step response/RF response:

In the spec, the “statistical” simulation flow describes that a channel’s impulse response is sent into Tx in the AMI_Init call. Practically, such impulse response only exists in theory and is not easily obtainable with circuit simulation. Instead, most link analysis use step response then post-process by taking derivative to obtain the impulse response. The assumption of this approach is that channel’s rising and falling transition are symmetric, which is usually not the case for single ended signals such as DDR. Thus in order to perform StatEye like convolution based link analysis more accurately, one may need to forgo the single impulse based statistical analysis flow but resolving to full sequence based (e.g. PRBS sequence) bit-by-bit flow.

  • Clocking:

IBIS spec. assumes the signaling is clock embedded as the only place where clock is mentioned is the function signature of AMI_GetWave:

The usage of this clock_time is “output” from the AMI model. That is, the (RX) model can optionally recover the clock from the “*wave” array then return the clock data back to circuit simulator. As mentioned previously, DDR is source synchronous so a clock signal is already available outside the “*wave” data. In my opinion, this is an easy change as the spec. can simply indicate that the “clock” data can be bi-directional, meaning that simulator may receive clocks elsewhere then pass its data into the AMI model using this clock_time signature while calling the AMI API. Then the RX’s DFE can make use of the pre-determined clocks to perform slicing and tap adaptation. Nevertheless, this clocking difference has not yet been addressed in the spec. as of today.

  • Signaling:

In the IBIS-AMI spec, user will find differential signal being assumed as the description below indicates stimulus is from -0.5 ~ 0.5:

By definition, a LTI EQ model’s transfer function is independent of the inputs being scaled and shifted, thus it basically behaves the same regardless of single-ended (SE) or differential (DP). A NLTV model, like RX DFE, does depend on the proper threshold to determine signal data bits. Thus whether it’s SE or DP does make difference just like whether the encoding scheme is NRZ or PAM4. Besides those descriptions change like shown above, a simulator/link analyzer can theoretically perform signal shift before calling AMI model then restore afterward automatically so that most of the developed AMI model mechanism can still be used. Alternatively, an AMI model can achieve similar effect using a level shifter if the spec. indicates that such adjustment will not be performed by the link simulator.

  The waveform shown above is a 3rd party vendor’s link simulator being applied to DDR analysis using IBIS-AMI. As one can see in the left, the channel characterization shows that the voltage swing of the single ended model is 0.4 volt ranging from 0.95 ~ 1.35. However, the waveform sent to IBIS-AMI models has been re-centered around 0.0 so the swing range is -0.2~0.2. Apparently, what the simulator has done is taking the ground based channel characterization result to convolve with differential stimulus required by the spec. This vendor’s simulator then does smartly restore the output from AMI model back to single ended so the final eye presented are shown at correct voltage level.

Other EQ modeling methods:

In this DesignCon IBIS summit, a VHDL/Verilog-A based modeling approach was also presented to show that with such EQ model/mechanism available, the traditional time-based simulation flow can still be used and for DDR, the million bit simulation (thus requires AMI like models) are not necessarily needed. That paper show comparable results such as eye margin etc obtained by this VHDL based model. Personally, I don’t think this result is viable too much beyond that particular study. The reason is that VHDL/Verilog-A as a modeling language has great limitations when being compared to C/C++ based language which AMI uses. This is particularly true in the following aspects:

  • Libraries: performing numerical computation in C/C++ is quite routine and many libraries have been developed so very rarely one needs to start from scratch. For example, GNU and LAPACK are both widely used as foundations of C/C++ based numerical analysis. Where are these counter parts in VHDL/Verilog-A? Without these, model development beyond simple sequential programming will be almost impossible or too tedius.
  • IP Protection: Compiled C/C++ codes are basically machine codes and can’t be easily de-compiled. This is why AMI is considered as IP protected while IBIS is only abstract to the behavioral level. VHDL/Verilog-A are mostly plain-text based and even when encryption/obfuscation is possible, the model soon becomes vendor simulator specific because only they can decrypt/interpret the scrambled codes. This defeats the purpose of the shareable model.
  • Speed/Flexibility: Interpret language will not be as efficient as compiled ones. While whether there is really needs for a compiled language such as C/C++ can be discussed, VHDL/Verilog-A will still be the less likely choices regardless. In my opinion, a possible direction may be language such as Python because it not only is open sourced, but also supports C API and has rich numerical libraries support (NumPy, SciPy)

The discussion above summarizes my understanding and observation of EQ or AMI’s usage for DDR. While the implementation may not necessarily be the same, I believe we can rest assured that EQ will be part of DDR spec to come. Even if it’s not AMI, it will just be built on top of existing modeling methodologies so far just like AMI stands on the shoulder of transitional IBIS.

IBIS-AMI: Using IBIS-AMI in COM Analysis

Posted on by
Reply

[This blog post is written in preparation for the presentation of the same title to be given at the 2018 DesignCon IBIS Summit. Presentation slides and audio recording are linked at the bottom of this post.]

Motivation:

An AMI model is in the binary form of .dll (dynamic link library) or .so (shared object). It itself is not an executable and can’t be used directly. To load or run the AMI models, one needs to have a “driver”. Commercial tools like HSpice has a license required utility called “AMICheck” to test drive the given AMI models with rise/fall/single bit response. We SPISim also provide a free utility called SPISimAMI.exe which does pretty much the same. These small drivers are good when you want to quickly check whether the AMI models at hand are “run-able”. However, to validate or test model’s full function, such a simple tester is often insufficient. In an ideal situation, a link analysis simulator, which will load Tx and Rx AMI models involved and perform calculation/optimization, is preferred as a driver. If a model developer can use IDE to attach to this simulator process and have access to the simulator codes as well, then he/she can set a break point within both simulator and the loaded AMI model to step through and debug during the whole analysis process.

Even if one doesn’t have access to simulator’s codes or debug build, theoretically, an IDE can also “attach” to a process before it loads the AMI dlls in which we have break points set (as a model builder, we have access to the model codes). However, thing is not so straight forward in real world. Most of the EDA tools I have seen allow user to interact different link analysis settings via GUI, then when a “simulate” button is clicked, a separated process is launched/forked and that process will do the work such as characterizing channel, loading AMI models and simulation etc before giving results back to the front-end GUI for further display. It is not easy (if even possible) to automatically attach dll files being debugged to these “spawn/forked” process. No to mention that if both Tx and Rx models are involved in a optimization process (such as back-channel), then simply stopping at a breaking point within one of the AMI models is not enough… one can’t observe and see the interactions for full picture. With these limitations, develop and testing AMI models within a full link analysis flow become challenging.

For a model developer who does not have access to these full link simulator’s sources, open source platform is a direction. There are several ones out there already… PyBert and COM are two such examples. From what I have seen, most of them already have some generic Tx/Rx algorithm blocks in place. So these EQ operating portions may be replaced to support AMI models to meet our needs. Being able to do so will shorten the model design cycle and enable the possibility to develop blocks with more advanced capabilities (such as back-channel communication). As PyBert already has some sort of AMI modeling support, this paper intends to explore possibilities to add similar capabilities in IEEE 802.3 spec. supported channel operating margin (COM) flow.

Background:

Channel Operating Margin (COM) is a ratified IEEE802.3 spec. Interested reader can find an overview slides given by the COM main author (also my former colleague at Intel) linked here: [Channel Operating Margin Tutorial] More detailed technical details are available in the IEEE 802.3BJ spec document and Richard’s 2013 DesignCon paper of same title. Further more, its matlab source codes are also available at the 802.3 website.

Given such technical depth like COM’s, to describe it in several paragraphs in this post will not be meaningful. So I will try to just give an overview from AMI builder’s perspective and help reader to see how AMI models can be plugged-in to the flow.

COM’s reference model is shown above. The upper half of the right side represent the through inter-symbol-interference (ISI) channel and the lower half is for the crosstalk (XTK), which can be near end, far end or both. Simply put, COM is an evaluation of signal to noise ratio for the full system. Most of the noise terms, such as mentioned ISI, XTK, jitters etc have all been taken into account. The signal part is the peak of the single bit response (SBR, i.e. pulse response). COM itself has published algorithms for many different blocks above and also interface specific default parameters for different 803.2 interfaces. EQ portion such as FFE in Tx, CTLE in Rx and even DFE are also implemented.

For a SERDES designer or AMI model builder, channel S-param (with or without package portion) is assumed given and COM flow will select best selection of FFE tap weights, CTLE pole/zero location and DFE tap weights as well. The searching flow for these parameters are exhaustive… full combination of FFE taps and CTLE dc gains are used to apply for toward the channel. A figure of merit (FOM) is then calculated for each combination. Best case is then decided based on the FOM value. Once EQ settings have been decided, then a SBR is formed and a full blown BER like analysis is applied with DFE involved to calculate final COM value.

For a link analysis flow, the first step is to “characterize” the channel, i.e. obtain impulse response. There are many devil’s details behind this step… single-ended s-param may be need to converted to mixed mode, package models of different sections needs to be cascaded, and finally the cascaded s-param needs to be “conditioned” before doing IFFT (not using an IBIS model or analog front-end in COM). All of these are important yet may be out of an AMI model builder’s direct concern… then just want this channel to “work”. Fortunately, these steps have all been included in COM flow already and can be used as they are.

Regarding Tx and Rx EQ, original COM implementation (circa. 2014) only supports one FFE pre-tap and one post-tap for TX. Recently, it have been extended to support two pre-tap and three post-taps. For CTLE, two poles and one zero equation is used and user can only sweep DC gain. The analysis flow is very similar to what’s described in IBIS spec section 10.2 but only with LTI assumption. That is, impulse response obtained from conditioned S-param is sent to Tx EQ, then pass through Rx CTLE before further processing. DFE taps are not optimized within each iteration of FOM calculation, it’s calculated only after optimized FFE + CTLE settings have been found.

As mentioned previously, the searching algorithm of these EQ is exhaustive. So if one open the published COM matlab codes, he/she will find the multi-level loops for different Tx EQ taps and Rx CTLE Gdc settings as shown above. To replace these generic EQ functions with our AMI models, codes need to be changed here.

Using AMI in COM flow:

To use AMI model in a COM flow, one need to replace collect the replace these FFE and CTLE calls in the COM codes with the corresponding AMI model invocation. Here shows two possible modifications routes:

  • LTI (Linear, time invariant) design: As COM flow use impulse response by default, it’s easier to plug-in LTI AMI model (i.e. models which don’t use AMI_GetWave to process data) directly.

The first step is to “combine” or “collapse” those multi-level loops into single loop. This single loop can be iteration which go through an array which contains all the AMI parameters combinations to be tried (may not be exhaustive) or has a “stopping-criteria” which will “break” the loop such as optimization within this single loop has reached solution. Tx and Rx may not be FFE/CTLE respectively or can have different format (for example, CTLE can iteration list of frequency response curves rather than pole/zero data). For the later case (optimization), Tx and RX can be calculated together if needed. original COM’s package length and DFE can still be used to calculate FOM of different condition if needed.

  • NLTV (Non-linear, Time variant) design: In this case, a PRBS like bit-pattern is needed first in order to convolve with the channel’s impulse response. Bit-stream response is then formed to feed into model’s AMI_GetWave function within each loop. Just like what’s described in IBIS’s spec, Tx and Rx’s GetWave functions are called sequentially and model’s DFE and FOM function (not COM’s) may be used at the end to decide when to finish the iteration.

  Regarding implementation details, as COM was originally written in matlab, so matlab’s corresponding mechanism to load and call external DLL functions need to be used to replace original FFE/CTLE function call. Basically (as shown in the right part of the picture above), mex -setup needs to be called to determine which IDE environment is installed in the working computer. A header file which include the definitions of the AMI API function is also needed. Then the following functions are called in sequence:

  • Load AMI model using: load(‘XXXXXX.dll’, ‘ami.h’)
  • check libisloaded(‘XXXXXX’) and list functions in the library using libfunctions(XXXXXX’)
  • Call AMI library function using calllib(‘XXXXXX.dll’, ‘ami_init’, htInput, rowSize…)
  • Finally unloadlibrary(‘XXXXXX’)

Also worth mentioned is that if we are doing this for AMI models being developed, not a generalized AMI-capable link simulator, then parser for .ami to form parameter tree is not necessarily needed to form argument passing into ami_init functions etc. We can form a string of parsed “key-value” pairs in advance manually and pass into AMI function. Other open platform like PyBert does have AMI parser built-in for its AMI capabilities.

Results:

In our experiment, we want to avoid the multi-level loops for all possible FFE tap weight combinations by using our AMI FFE model capable of self-optimization. The concept is simple: if we already have an channel’s impulse response, then the optimal weight to obtain same output as input (recover signal) in the minimum mean-squared error sense can be solved by using pseudo-inverse and linear algebra technique. We want to validate this approach work and can find similar (if not same) solution comparing to full exhaustive search.

Result is shown above. Red dot represents original COM’s sweeping results (FOM value). There are 13 Gdc values each with 24 one pre-tap and one-post tap combination possible… so total 312 run is needed. Blue dots are our AMI results… since we still use COM’s CTLE, so 13 run is performed. However, for each Gdc run, AMI model computes only once based on the self-optimization algorithm mentioned and finally report best results together with best CTLE Gdc. As seen that blue dots are almost at the top of all 13 original ” COM chunks”, we validate that this algorithm/our Optimization-capable FFE does work.

Summary:

To summarize this study, first we want to emphasize that for a model developer, who can be an individual model provider or a SERDES designer being asked to develop AMI models, a full flow capable of being used to debug AMI model being developed is needed. This can’t be covered by the simple utility driver particular when optimization such as back-channel come into play.

To meet our needs, open-source link-analysis platform is worth considering. In particular, COM flow of IEEE802.3 is attractive because it’s been ratified, well documented, widely used and support BER-like flow with source codes. While its Tx and Rx block functions may be generic, it’s not difficult to replace those function calls with our own AMI models’ API functions in either LTI or NLTV scenarios. This process not only help shortening model development cycles, but also is very beneficial in further understanding how link analysis is actually performed.

Links:

Presentation: [HERE] (http://www.spisim.com/support/paperetc/20180202_DesignConSummit_SPISim.pdf)

Audio recording (English): [HERE]

IBIS-AMI: “Paring-off” of the models in three scenarios

Posted on by
Reply

Here at SPISim, we provide AMI modeling service in addition to the developed EDA tools. Companies interested in AMI service are mostly IC/IP vendors. They need to provide AMI model in particular so that their user, system companies which use their ICs, can perform the design and analysis. Oftentimes, our client is only interested in AMI modeling for either Tx or Rx circuit because that’s where their IC design resides. However, they also often found later on that in many scenarios, it actually takes “two” models to be useful for their users. In this post, I will talk about some of such “paring-off” cases so that interested reader may be well informed when such modeling needs arise.

Tx and Rx:

The topology shown above is most commonly used for link analysis. At the Tx and Rx ends, user often is asked to specify corresponding IBIS models. Most definitely, they need to specify AMI model and associated AMI parameters. The interconnect in the middle is generalized here… it can be Tx package, main route, connector and Rx package etc represented in either separate models or cascaded S-parameter. The whole purpose of interconnect here is to provide an impulse response so that when link simulator is operating in either “Statistical” or “Bit-By-Bit” modes, AMI models at the Tx and Rx ends will be able to process accordingly. The analysis flow an AMI-compatible simulator should follow is described in details in section 10.2 of the IBIS spec. User should find that in those descriptions, and almost all the tutorial documents on-line such as the one below from KeySight, both Tx and Rx AMI models are both required to be part of the analysis.

Thus, the first “paring-off” in AMI modelings is each Tx needs an Rx AMI models to work… at least mostly. From this perspective, this is very different from traditional spice-based simulation, where you may have Tx/Rx part in either IBIS, transistor circuit or behavior/Verilog-A modeling format and can simulate without any issue.

So what if you have only either Tx or Rx AMI model? It will be tricky (depends on the simulator) if not possible in many cases. So we here at SPISim often have to provide a “dummy” AMI model in additional to the one ordered. As a “dummy” model, it is a simple pass-through without doing anything. When combined with pass-through S-param or interconnect, it will be very straight forward and clear to test and validate delivered AMI model’s performance. When all the spec. are met (e.g. EQ levels), then the user can add real interconnect and Tx/Rx AMI models from other vendors to proceed the design process.

(A pass-through “Dummy” AMI model implements AMI API but without any implementation body or just don’t change those variables passed by reference)

Repeater:

IBIS version 6.0 includes technical advances such as mid-channel repeaters documented in BIRD 156.3. Repeater is often used in longer SERDES channel such as PCIe or HDMI etc. There are two types of repeaters: redriver and retimer.

  • Redriver: A redriver performs signal conditioning through equalization, providing compensation for input channel loss from deterministic jitter such as inter-symbol interference.
  • Retimer: A retimer is a mixed-signal device that includes equalization functions plus a clock data recovery (CDR) function to compensate both deterministic and random jitter, and in turn transmit a clean signal downstream.

It’s easy to see the “paring” part within a repeater:

Within a repeater, Rx sits at the front to receive signals from upstream, then pass to Tx part of the repeater to transmit again toward the downstream. So one really can’t work without the other. Plus also “paired” Tx AMI at upstream and final Rx AMI at the end of the downstream, it takes at least four AMI models in most cases to start the analysis. More than one repeaters are also allowed so the number of “paired” AMIs can grow. The proper analysis sequence when repeater(s) is involved is also documented in 10.7 of the spec.

So far as repeater being an “electrical” component is concerned, there may be no such needs to probe signals between Rx and Tx within a repeater. However, when we model an optical link as a repeater (shown below from Agilent slides), then thing becomes much more interesting:

We handled such a case just recently… an optical transceiver used in an (electrical) system may be modeled as a repeater. Having that said, please note that in “optical” world, Tx is now again at the front of the repeater as laser is used to light the optical fiber to transmit signal toward Rx (now the 2nd part of the repeater). So a potential confusion may happen here when optical and electrical worlds meet. In addition, there might be two other considerations:

  1. There may be needs to probe signal between optical’s Tx and Rx ends, which can be single-ended-like (optical pulse in mili-watt)
  2. Users of such optical module based repeater may only focus on design at the upstream side, the downstream side or both. In the former two situations, they may not have AMI models at the other side.

The first one above is tricky to solve… mainly due to the non-differential nature of signals in a link simulator. Until now, if one reads the AMI portion of the IBIS spec, he/she should notice that the signal mentioned are always differential. So while there is no problem to create an AMI model handling single ended signals, how the probing/analysis goes really depends on simulator being used. Having that said, with DDR adopting AMI methodology, the single-ended signal support should happen very soon.

To accommodate needs of different possible users of our clients, we make use of the “pass-through” dummy model again and proposed the following different AMI models combinations:

In usage scenario 1: The modeled Tx and Rx optical ends (each have their own circuitry) are assembled accordingly. Thus if a simulator can handle “single-ended-like” optical signal in between, then this model can be used directly.

In usage scenario 2: The signal between optical ends within a redriver is not of concern and the support of single-ended-like signal is uncertain. In this case, we “lumped” the TxRx together and put it at the front of the redriver. The second half of the redriver is a simple pass-through. As input and output from the first part are always differential, it will meet the expectation of the simulation flow documented in the spec.

In usage scenario 3: we assume the user is only interested in the downstream end and have only Rx AMI model. In such a case, a repeater will not work because it’s lack of the up-stream. So we combined the created TxRx here and make it a transmitter AMI.

In usage scenario 4: we assume the user is only interested in the upstream portion and only have Tx model. Similar to scenario 3, we combine the TxRx of the optical models and make it a receiver AMI.

In the “paring-off” for a repeater, there are two points worth mentioning:

  • Unless DFE/CDR are being modeled and thus retimer, distinction between Tx and Rx EQ are often blur particular when they both are LTI. For example, either Tx or Rx can have a FFE EQ and CTLE of a Rx is also just a passive filter. In such case, a model can be used as either a Tx or Rx (like scenario 3 and 4). The only thing needs to pay attention to is the jitters assignment as AMI parameters for Tx and Rx’s jitters are different.
  • We want to cover all usage scenarios and make our client happy. However, we also don’t want to over burden SPISim engineers too much in creating too many different AMI models. Thus as mentioned in previous post, the architecture of AMI modeling becomes important. When done properly.. (such as in our cases 🙂 ), we can simply cascade stages easily at the .ami file level without even rewriting C/C++ codes or any re-compilation.

IBIS-AMI and IBIS:

When we focus on more technically challenging AMI models, we often forgot still important role a traditional IBIS model will play in link analysis. Simply put, the accuracy of an IBIS model still impacts the final results (e.g. BER eye) greatly.

The normal process of the link analysis starts with “link characterization”. Mostly this involves a time domain simulation of driver driving through interconnect with receiver analog front-end (no EQ) connected to obtain the pad to pad step response. Then this step response is differentiated to obtain the impulse response. Finally AMI models are brought into play by convolving with impulse response (LTI or statistics mode) or processing with bit response sequence (NLTV or bit-by-bit mode). In this characterization stage, no EQ (i.e. no AMI) is involved. It’s is their “analog front-end”, i,.e. IBIS models or corresponding spice/behavioral models being used. Thus, the accurate modeling of this portion does impact the processed link analysis results.

In the picture above, eye plots of identical AMI model yet each with different IBIS models are shown. It’ clearly seen how IBIS’s VT waveform and IV curves affect the eye openings width and height. Thus the third scenarios we want to emphasis of IBIS/AMI “paring-off” is the AMI model and their corresponding IBIS model.

SPISim is a relative small EDA/consulting company comparing to others such as Agilent, Cadence or Mathsoft (matlab). These companies each have their own AMI modeling solutions and cost much much higher when comparing to our offerings. However, when we look into their AMI product details, it’s not easy for us to find (or maybe even not there?) how the IBIS portion will be handled. As an AMI model is mostly used for SERDES application, differential or current-mode-logic (CML) design is often involved. If one reads chapter 4 of IBIS cookbook carefully (available at the IBIS website), he/she should find that the process of differential IBIS modeling is more complicated than the simple single-ended IBIS buffer. Thus when considering the importance of “paring” between AMI and IBIS, one should really take this into account. An AMI model without proper analog front end will definitely come back to haunt you during validation stage. Interested reader regarding differential IBIS modeling may also refer to our previous post or our 2016 Asian IBIS summit paper.

IBIS-AMI: AMI Modeling Using Scripts and Spice Models

Posted on by
Reply

Preface:

This blog post is written in preparation for the upcoming IBIS summits at EPEPS (San Jose, Oct/18/2017), Shanghai (Nov/13/2017) and Taipei (Nov/15/2017), where I will present paper of the same topic. Slides, example models and audio recording will be made available below:

Motivation:

Many years ago when I entered the signal integrity field, we analyzed the channel by performing spice-like simulation for several hundred nano-seconds at most. Post-process were then done to get FOM metrics. At that time, the bus speed was barely around 1Gbps. These days, high speed-IO SERDEs are common among various computing devices and their speed reaches multi-Gbs or higher easily. Not to mention the several new 802.3 network protocols which have even higher speed (50G~ >100GB). With such high data rate, one needs to “simulate” number of bits at 1E12 level to reach certain bit-error-rate (BER, say 1E-12) with certain confidence level (CI, say 99%) . As such, traditional SI analysis method is no longer valid because it is simply inpossible to simulate so many bits in reasonable time using spice-based simulator. A new channel analysis methodology, like link analysis, is thus needed and invented around year 2003 to address this problem (e.g. StatEye). For link analysis, traditional buffer models such as IBIS are not much useful as they mostly time-domain based. Algorithmic modeling interface (AMI, a subset of IBIS) models are used mostly instead.

AMI modeling is very technically challenging, it requires cross domain expertise such as simulation, modeling and C/C++ programming across different OSes and platforms. Thus it usually takes much longer for an engineer to ramp up to be able to develop and deliver a model when comparing to traditional IBIS. Two of the big hurdles which cause this slow ramp-up for AMI modeling are the requirements to express the circuit’s behaviors in C/C++ language and then be compiled according to Spec’s API requirements. To lower such barriers, we are asked often: 1. Can we create an AMI model using scripting languages? 2. Can I simulate existing spice models using link simulator before committing to develop a full blown C/C++ version?

We propose approaches to meet these two common requests in this presentation.

Background:

Channel analysis: Nowadays the high speed link analysis most definitely includes stages such as Tx/Rx EQ, which are beyond traditional IBIS. Equalization is needed to compensate channel noise such as inter-symbol interference (self-channel interference) and crosstalk (co-channel interference). These EQ stages can open “eye” from a closed one of a noisy channel, represented by S-parameter interconnect.

There are two analysis methodologies for modern link analysis:

  • Statistical: If the circuit is linear time-invariant (LTI), one can obtain many information about channel’s limit by using a single pulse or impulse response. In this flow, a channel is assumed LTI (s-parameter may need to be enforced/fixed in terms of causality, passivity etc first). Its impulse response is then “fed” into Tx/Rx circuitry to obtain the response. By using superimpose (or superposition), response of the channel + circuitry of  different UIs are added together and probability of various BER level can be computed from there.
  • Bit-by-bit: If a circuit is non-linear time variant (NLTV), then such superposition is not allowed. In that case, a bit-stream may be fed into Tx/Rx circuitry by link tool/simulator to obtain their continuous time-domain response. These outputs are then “convoluted” with LTI channel to obtain overall channel response. In order to do this for many millions of bits, some assumption needs to be made (high-z, to be discussed later) in order to gain speed performance when comparing to same time-domain spice-like nodal analysis. Also, the link tool may break bits to several chunks and feed to Tx/Rx separately before combining them together, with “aliasing” of adjacent chunks of bits being taken care of properly at the link tool level.

AMI models support both of these two channel analysis methodologies.

AMI Model: an IBIS-AMI model contains several parts:

  •  .ibs file: In the .ibs file, there is a section called “Algorithmic Model” which points to the paths where the .ami and .dll/.so files reside. This keyword block also provides info such as bit, OS platform and the compiler used to generate the .dll/.so files. Other than these info, the .ibs file and AMI model it points to are basically independent. Further more, in the link analysis, traditional IBIS part are often considered “analog front end” and is “absorbed” into either the AMI portion or the channel portion of the data.
  • .dll/.so file: This is compiled binary format. The language MUST be plain old C and it must be compatible defined AMI API spec. in order to be able to loaded by the link simulator.
  • .ami file: This is the plain text file which contains “config. settings” for the binary .dll/.so files. As shown in the picture below, it has two main sections:

  • Reserved Parameters: This block is usually at the top of the .ami file. These settings are for link simulator only. Depending on part of the settings in this block, such as “Resolve_Exists” or “GetWave_Exists” set to true or false, the associated API functions are invoked by the link tool.
  • Model Specific: This block is usually at the bottom of the .ami file. It contains AMI model developed defined parameters which link tool and API spec does not interfere with. While there are many “text” in this block, when the .dll/.so portion of the AMI model received their info. passed by the link tool, they have been “filtered” and converted to simple “name-value” pair as shown above. So while the depth of the “tree structure” for this model specific section can have many levels, the parameters received inside the model can be just two levels at its simplest form with model name (RX_model above) at the root and the other name-value pairs as “leaves”.

AMI-API functions: As of IBIS Spec. V6.1, there are up to five API functions can be used in a compiled AMI model:

Among which, AMI_Resolve and AMI_Resolve_Close are for string parameter pre-processing which can be ingored in a lot of cases. AMI_Close is like garbage collection/clean-up to release allocated memory, so is trivial is most cases as well. Modern OS may reclaim memory space back even one does not do any “Free” or “Delete” there in AMI_Close. Two most important ones, AMI_Init and AMI_GetWave, are marked in red.  In particular, they participate in the aforementioned “Statistical (for LTI)”  and “Time-domain bit-by-bit (for NLTV)” models. That is, for a LTI model, its AMI model must/should implement the AMI_Init function call. A LTI model can also implement AMI_GetWave function call but this is optional. On the other hand, a NLTV model must implement AMI_GetWave function while implementing AMI_Init as “initialization” rather than “computing” portion of the codes. The bit-by-bit convolution part of a NLTV model should be implemented in the AMI_GetWave part of the codes.

When looking at the function declaration part of the spec, as boxed in red in right part of the image above, one should also realized that the first arguments (an array represented by double pointer) serves as both input and output purpose. These are “pass by reference” arguments as they are pointer. So at the beginning of the AMI_Init/AMI_GetWave calls, the model can obtain either impulse response of the channel or digital bit sequence from the simulator via this pointer. Then the model perform necessary computing using info from the rest of the arguments (some of them also serve as output purpose, such as char **msg, but is not that important in this context). At the end of the computation of this function call, the modified response must be filled in back to the address where the first arguments points to, so that the link simulator will retrieve the values and carry on the rest of the analysis.

AMI Modeling Flow:

A typical AMI modeling flow involves the following steps:

  1. Identify the behaviors of circuits being modeled. As we are going to use a computer language to describe the model’s behavior, we must know how it works first. These behaviors can be obtained via either mathematical derivation, simulation results or measurements. In the last two cases, a look-up table may be used inside the model.
  2. Code the behavior and IBIS-AMI API: There are two parts of this section. The API part MUST be implemented in C (not even C++). The other part of the codes can be in any language, shape or form as long as the developed C codes know how to communicate and exchange the data. That is, the actual computing part, can be in language other than C/C++ if you like or even be completed via circuit simulation.
  3. Compile and link as .dll/.so: This is the compilation of the strict C portion of the API. In windows, one usually needs to compile for both 32 and 64-bit. On Linux, on top of different bits, one should also test on various distros (debian or red-hat based) as they may use different version of GNU C (and thus support different version of C spec. e.g. C99 (1999) or C11 (2011)

Now let’s talk more about item 2 above. There are many considerations on how you should code this part. A specifically C/C++ coded model for one circuit will mostly run very fast. However, it may requires frequent re-compilation/re-testing when new design comes. If we can make this part as simple as possible and non design specific, such as calling external scripts, then this work may only need to be done once as all the variation are now external to the compiled .dll/.so.

Modeling with Scripts:

Knowing the requirements of the AMI API, we can now propose a flow to create an AMI model using user’s favorite scripting language:

Flow:

To support script based AMI modeling, we need to have a thin API implementation (in C, as required by AMI Spec) whose sole task is to translate all the received arguments into a text format and write as a text file. It will then pass the path of the text file to user defined scripts or batch file via system call. Location and type of the script is defined in advance in plain-text .ami file. The script needs to retrieve the argument information first by parsing the plain text file, perform necessary computing, then write into another or same text file which this AMI model with thin layer knows where to find. So when the script completes, the AMI model will parse the text file generated by the script, fill the information back to the aforementioned “passed by reference” pointer array, then complete this step. As discussed, whether the scripts is needed for either AMI_Init or AMI_GetWvae or both are pre-defined based on circuit behavior. And since this is developer chosen favorite language, parsing and writing to text file should not be an issue when comparing to say C language. Lastly, should there be any information need to be passed between API calls (such as model member’s values between AMI_Init and AMI_GetWave), they can also be file based. To summarize, the AMI model with thin layer completes the API calls with upper simulator like other regular AMI models. However, its “transactions” with underlying user’s scripts are all file based.

Example:

A matlab example of the AMI_Init is shown above. In the matlab codes, it first calles parseInput function, which is a text file prepared by the thin AMI model and contains input waveform. It then performs computation such as convolve with FFE, then the result matrix is written back to the text file via storeOutput function call which thin AMI model know where to find. Since matlab’s “conv” function is used directly, the model developer does not need to deal with c-based implementation details such as memory allocation FFT/iFFT in some cases or other math library linking/compilation.

Considerations:

While script based AMI development is simple and handy, there are several considerations before deciding to release such models:

  • Performance and distributional: Since all communications between thin AMI model and user’s script are file based, it inevitably will suffer some performance issue. If this is AMI_Init, it’s only called once by simulator during analysis and such performance penalty is less of a concern. Next, one must also consider the how the mode can be distributed? If the script is in matlab .m file, then model clients need to have matlab environment installed as well. If it’s in compiled matlab, then client needs to install matlab compiled runtime (MCR). If the scripting language is in perl, then perl interpreter, which is usually installed by default on linux but not Windows, is needed. To distribute such interpreter, one must also check the license terms and then also think about the elegance of such model release.
  • Consider Python!: Python is a very worthy candidate here because it has rich math or matlab like libraries such as SciPy or NumPy. More importantly, there is a mechanism called “embedded python” in which the whole python interpreters together with math libraries used can be bundled and distributed in a single zip file. That is, the end user does not need to install python environment first as the thin AMI model already linked with C-Python and can find all required functions in either user’s scripts or bundled zip file.

Modeling with Spice circuits:

Now that we know a thin layer can call external script either directly or via its interpreter, we may also come to the conclusion that it can also call external program such as a circuit simulator. This is of course true!.

An assumption we mentioned at the beginning of the post is the “High-Z” condition. In a typical spice-like nodal analysis, there are many “Newton-Raphson” iteration going on within same time step. At the beginning of each Newton iteration, tentative voltages are given at each node. Each components then compute the drawing or output current into these nodes based on these voltages and its own behaviors. At the end of the iteration, circuit simulator solves the system matrix to see whether KCL/KVL reaches balance and then determine either another Newton iteration is needed or it can march into next time step.

In channel simulation, such iteration is not needed as there is a “High-Z” assumption… and that’s why it can run much faster than nodal spice simulation. In High-Z assumption, each blocks is assume to have high input impedance and output impedance so it will not draw any current at the input and the output is set once determined. Since the thin layer AMI model can obtain the inputs from simulator via API call, if it can perform another task… such as convert this inputs input PWL source with time step equal to UI/number_sample_per_UI (both are know and passed by the simulator), then it can theoretically call a simulator to drive user provided spice subckt like above. Note that the input waveform is just voltage which represents potential difference of two nodes. So there is no reference to GND at all. It’s subject to user’s spice circuit to determine what the reference is and provide GND reference if needed.

Flow:

The picture above shows the flow to simulate/model AMI with spice subcircuit. It is very similar to the flow for AMi with scripting language. First the thin layer AMI model need to generate a PWL source dynamically based on the provided inputs. Then form (either write out as a file or internally in  memory) a netlist as a driving circuit and probe at the output. This driving circuit will use user provided spice subckt with possible value overrides defined at the .ami file. Then thin layer AMI will call external spice simulator (or internal API) to perform nodal based simulation. The output (like .tr0 for HSpice) is then processed and its value is again filled back to the initial API pointer array to return back to upper circuit simulator.

Example:

An example is shown above. The template is pre-defined with the PWL source and path to user’s spice circuit being left to be filled-in. The thin AMI generates the netlist with all values filled properly upon being called by simulator. It then call external simulator to do nodal simulation. Resulting waveform are post-processed and filled-in to the API argument memory address and complete this API call.

Considerations:

Similar to the AMI modeling with script language case, there are several considerations when adopting the spice-based AMI modeling approach. First is the performance… as each AMI API call involves nodal simulator initialization (allocate matrix, solve for DC, Newton iteration between each time sample etc), it will be significantly slower than pure C implementation. However, this is less of a concern if only AMI_Init is needed as it’s called only once. More over, one does not need derive any equation or do any coding at all and can get accurate link performance using this Tx/Rx circuitry directly… so development time is saved significantly there. If one decides to implement such block in C/C++, then simulation results obtained during this process can serve as a very good reference or correlation data for C/C++ based model to be developed.

Another consideration is again the distribuability: If this spice model has particular MOSFET model and requires say HSpice, then the AMI model recipient also needs to have HSpice in their environment in order to run. While commercial simulator like HSpice may not provide API or serve as shared library, many open source ones do. Examples are NgSpice and/or QUCS. In these case, the compiled thin AMI model is basically a simulator in .dll/.so form and can perform simulation all by itself. The binary size is around 8MB larger then without as it also needs to link with all simulator supported device models as well.

Summary:

Using either scripts or existing spice circuits for AMI modeling is actually doable. The presentation I give here is not just talk on paper. The implemented “thin-layer AMI” and examples are also provided together with the slides. These flows can be considered as part of the AMI development process as they can shorten the modeling cycle significantly while providing data for correlation should one decide to go full C/C++ implementation at the later stage. The consideration points includes performance, elegance of released models and distributability of either the script’s interpreter or simulator. Also a thin layer AMI models is needed. This thin layer API is called Proxy model in computing science terms. As a matter of fact, SPISim has implemented such proxy models and made them available for public to use free of charge. [Link Here] Having that said, this API model only needs to be done once as all the model variation are located externally in user scripts/spice models. and thus require no re-compilation when design changes. Nevertheless, these two possible modeling approaches provide an AMI model developer alternative ways to decide on how a model can be developed more efficiently and effectively.

IBIS-AMI: A case study

Posted on by
Reply

IBIS-AMI modeling is a task usually executed at the end of IP development process. That is, hardward IPs are created first, then associated AMI models are developed and released to be accompany with this hardware IP since the IPs vendor usually does not want to expose the design details to the their customers. On the other hand, it is also likely the case that a user may have received behavioral or encrypted spice models first, or even obtain measurement data from the lab, then would like to create corresponding AMI models for channel analysis. Such needs arise usually because either original IP vendor does not have AMI model or may charge too much. It is also possible that end user would like to explore different design parameters before determining which IP/part to use.

In this post, we would like to discuss how such an usage demands can be accomplished with SPISim’s AMI flow without any C/C++ coding or compilation for AMI. Here are the topics for this case study:

  • Collateral
  • Design spec. and modeling goals
  • Modeling process
  • Model release
  • Other thoughts

Collateral:

For this design, we received a testbench for a typical SERDES channel using this IP. The schematic is shown below:

Both Tx and Rx are encrypted hspice models with adjustable parameters. When picking one set of parameters to test run the channel test bench, we get valid simulation results.

As this is a hspice netlist, we have the freedom to probe different points and change the simulation options as needed (for example, from transient to ac or transfer-function).

Design Spec. and modeling goals:

The original IP vendor only provides simple descriptions for various blocks and design parameters. The Tx and Rx packages are spice sub-circuits and channel is a s-parameter file. Both Tx and Rx model has typ/min/max corners. On the Tx side, there are settings for voltage supply which is independent with the corner settings, a 7-bit resolutions for a multiplier to work with the swing amplitude, a 6-bit resolution for a de-emphasis and a flag for turning-on/off the boost.

With these IP design spec, the modeling goal is to create associate AMI models which will allow end users to fine tune performance with similar parameters like original IP. Further more, SPIPro is used for its spec. AMI model so that model developer should not need to write any C/C++ codes or perform any .dll/.so compilation for this AMI modeling.

Modeling process:

If one needs to create AMI models from simulation or measurement results, that usually means he/she does not have original design details or even design spec. available. So the so called “top-down” approach will not work simply because there is no design at all to translate to corresponding C/C++ code. Instead, we need to create an architecture via trial-and-error to “reverse engineer” the design so that the performance will match what’s given. Here are the steps we used in this case:

  • Create Tx/Rx test bench:

While the full channel test bench demonstrate how the Tx/Rx work, it also includes information not needed in the AMI modeling. For example, package and channel are usually separated from the AMI model because they are usage or client specific. Besides, as mentioned in previous posts, one assumption of AMI model is high-Z input and output. So the first step of the modeling is to separate channel from driver/receiver and create Tx and Rx only test bench together with inputs and outputs.

For Tx, it’s a simple PRBS input with output connecting to 50 ohms loads.

And its input/output should look like this:

When we modify the test bench to connect Tx directly to Rx, i.e. bypass all the package and channel models, we get such input/output eyes:

From these eye plot, we do not see DFE like abrupt force-zero output, thus the Rx model seems to be a CTLE like boost filter. So we created Rx test bench like below and obtain its frequency response:

Note that in order to perform what-if analysis of next step, we also use VPro to capture inputs to these Tx and Rx models so that they are evenly spaced.. as required by AMI’s Init and GetWave function. These evenly spaced inputs will be used later on by SPISimAMI.exe to drive the model. For HSpice, the following option may be needed so that the .tr0 file will have evenly spaced data points even simulation is various time-step sized:

  • Define architecture:

Now that we have input data and desired output for this particular set of parameters, next step is to explore whether SPISim’s existing spec. model is sufficient to meet the performance.

Tx: for tx module, we observed the following two characteristics:

  1. Has de-emphasis, happened after the peak
  2. Swing range and offset are different between input (0 ~ 1) and outputs (-0.5 ~ 0.5). Also there are loading effect so rising and falling have RC charging/discharging like behaviors.

For the de-emphasis part. We can use Spec. AMI’s what-if analysis to see how different pre/de-emphasis settings will cause difference responses:

We change these pre and post cursors one at a time only, using -0.1 for value .

We then test drive using built-in PRBS with same UI time, 200ps:

From the summary plot above, and correlate with the Tx output, it’s apparently that this Tx has one post-cursor FFE beause only this set-up gives de-emphasis after one UI after the peak.

For the output swing and slew rate, it’s the sign of AFE (analog front-end). So we can simply add an AFE stage right after FFE, with high/low rail voltage “clamped” to the simulated peaks:

With several trial-and-errors, all within SPISim’s Spec-AMI GUI, we obtained the following Tx correlation between spice test bench and AMI results for this particular set of parameters:

Similarly, as Rx behaves like a continuous filter, we use a CTLE stage to mimic its behavior:

With several tuning, we obtain such Rx correlations:

From these correlations, we believe that the stages built-in to the SPISim’s AMI are sufficient to meet the performance needs. So next step is to find the parameters to support all these design specs.

As similar process between Tx and Rx, we will use Tx as an example to demonstrate the flow.

  • Simulation/Sweep plan:

Before generating a simulation plan, we first also make sure these design parameters are independent with each other. We performed simple 1D sweep (several points) in particular for the swing and de-emphasis level.

Notice that the slew rate and peaks are not affected by de-emphasis level much. In addition, the spacing seems linearly spaced according to the bit settings. With this, we can sweep them independently.

Now for Tx, a full factorial sweep will require 2^6 (de-emphasis level) * 2^7 (swing level) * 2 (boost flag) * 3 (corner) * 3 (voltage levels) ~= 150000 runs. Due to the linearity, we do no need to sweep full 6 and 7-bits of de-emphasis and swing levels. Instead, we increase step interval for simulation because SPISim’s model’s built-in interpolation can be applied automatically, more about this at the model release section.

For these five variables, we use MPro to generate 2403 test case (1/60 of full factorial). We then create a template from the Tx spice test bench so that parameters can be updated according to the table and its column header above:

Noticed that variables are enclosed with “%” (e.g. %XVPTX%). Their values are replaced by corresponding values in each row of the table to generate a new spice file. With all these 2403 spice file generated, each for different combinations of parameters, we kicked-off the batch mode simulation and obtained all two thousand cases within one hour.  This is done all within MPro and can also be done using user’s script.

  • Parameter tuning:

With all results being available, next step is to find corresponding AMI parameters for each of the case. SPISim’s model driver, SPISimAMI.exe, is a must have here. It will take the collected, evenly spaced inputs to drive the AMI parameters together with the SPISim’s spec. model, output results can then be correlated with the .tr0 file simulated with HSPice for that particular case. In case when the correlation is not good, AMI parameters should be updated again for another iteration of performance matching. This process is summarized in the flow below:

Apparently, such as task is too tedious and error prune for a human to perform. Since the input pattern is the same, relative timing locations of different properties (such as peak and de-emphasis levels) are also the same even between different test cases, we can process these data automatically. Regarding “adjusting” AMI parameters, a simple bi-section search will quickly converge to the desired de-emphasis tap values for the given test case.

In our process, we first parameterized the .ami file as shown below. This ami file is based on the architecture identified in the second step… only that now we need to find different values for different parameters. In particular, the swing level and FFE post tap are unknowns and need to be swept.

Because these two variables are independent, we can first identify the peak value as “Swing” from the .tr0 simulation results, then use bi-section to adjust the FFE_PARM_POS1 such that the output from SPISimAMI for this .ami file settings and SPISim’s spec .dll/.so will match the tr0 data.

With this flow and process, we use our SPIProcPro to bath process the simulation results and get all 2403 fine-tuned AMI parameters within one hour:

Here is the partial config. settings for SPIProcPro of this modeling process:

For each of the test cases, the post-processed AMI result is saved to an individual .csv file. All these csv files are also combined and then concatenated side-by-side with original input condition. The end result is a table with input condition at the left and associated AMI parameters at the right. This table will serve as pre-set data table for our AMI models to be released.

 Model release:

The combined table looks like below:

The columns boxed in blue above are those required for SPISim’s AMI spec models. These columns has header named exactly the same as those in the ami file green boxed below. The row entries for settings of each test case in the csv table is filled in to the boxed in red in ami file below.

Now this is not the format to be released to the AMI user. In stead, the design parameter we want to expose to the end user are listed in the red box in the csv table. They have the column headers matching original IP’s design parameters. Also note that this csv table only contains partial results as we didn’t perform full factorial sweep for all ~150000 cases.

The design parameters, boxed in red in csv file, need to be able to be mapped to those boxed in blue, the AMI stage’s parameters.

One unique feature of SPISim’s AMI model is it supports of table look up and up to two dimensional linear interpolation for numerical values not found. The set-up is easily done from model config. GUI. The example below is for PCIe with 11 preset tables.

In this case, we do not use preset index. Instead, we set the preset index value to “-1” to signify that model’s table look-up will be used:

In the final .ami file above, the exposed parameters (boxed in red) are exactly those defined in the original given IP. Their name and values will be used to look-up from the table to find matching row. If up to two rows have no exact match in terms of numerical value, linear interpolation will be performed by the model during initialization. A final matching row or values will be used to assign to the parameters required by spec model.

The final results of the create model is one .ami file, one .csv file (plain or encrypted), and one set of .dll/.so file. There is no need to write any C/C++ codes or even compilation for the AMI modeling purpose and the SPISim’s spec. models can be used directly. For the post-processing portion, a python/perl/matalb scripts can be used instead if SPIProPro is not sufficient.

Other thoughts:

In this case study, a look-up table based approach is used to create AMI model via reverse engineering. Alternatively, we can create a spice simulation session using our SSolver/ngspice spice engine to simulate these given Tx/Rx spice model directly. The pre-requisite for this approach is that the given hspice model is not encrypted, can be converted to the SSolver/NgSpice based syntax and has no process file involved. Regarding search mechanism, a bi-section searching algorithm is used in our modeling process here as there is only one value (EQ variable) needs to be determined. The amplitude/swing is deterministic and can be found once tr0 simulation results is post-processed. If there are more than one variable involved for optimization , such multi-tap EQs, then a gradient descent based algorithm may be needed if full surface sweep is not practical.

IBIS-AMI: The black box magic

Posted on by
Reply

In AMI modeling domain, several “black box” magics or techniques are very useful. They exist to make the modeling process more streamlined yet flexible. In this blog post, I will share some experiences and thoughts we have during the development of our SPISimAMI flow. Modeling examples from some major companies will also be reviewed

Why the black box magic?

In contrast to other system models such as T-Line’s RLGC data, S-parameters or even traditional IBIS model, the AMI model itself is a black box. AMI models are both platform and OS dependent. They are in compiled binary format in the form of shared library… “.dll” (dynamic linked library) on windows and .”so” (shared object) on linux-like system. The other part of the ami model, the .ami file, is indeed in plain text holding model settings. However, it needs to work closely with the associated .dll/.so AMI model and can’t be changed arbitrarily.

For a model developer, even if he/she has the skills of the C/C++ coding and .dll/.so compilation, the whole process is still very tedious and error prune. For example, the same compilation and testing need to be done twice on windows due to the 32/64 bit difference. It’s even worse on linux. Different machines or OS need to be tested separately because no only there are different linux “distros”, different environments or IT set-ups may also cause discrepancies. As an example, the usage of “boost” or some other libraries like GSL are very common and widely used in C++ engineering/scientific computing development. However, they may not be included in all IT-built, production oriented environment. As a result, AMI models running perfectly fine on the developer’s system may fail to load on others. To be on the safe side, one usually needs link these “non-essential” libraries statically into the .so file, strip symbols to reduce size, and then test on different machines (virtual or not) to be assure for maximum compatibility. These details may explain why AMI modeling charge has been very high in the past and somewhat monopolized by very few companies.

In previous posts, we mentioned the similarities we felt between a circuit simulator and an AMI model. While a purposely built circuit simulator (like those for cache or memory circuit etc) may run very fast and efficient, a general purpose (e.g. MNA based) simulator usually is suffice for most of the design work. In these simulators, primitive device model such  R/L/C/V/I are built-in, even more complicated ones such as MOSFET, T-Line, IBIS are also included and configurable via external files (.snp file, .ibs file and .tab). This simulator, compiled to native format to maximize the performance, are also platform and OS dependent. However, they do not need to be design specific. Those configurable aspects are left in the netlist file…similar to the plain text .ami file. When more sensitive information needs to be provided to the simulator, such as the process file or design IP, they can be encrypted such as “encrypted hspice” does.

From this point of view, we can see that “magic” or modeling techniques can happen in both places… i.e. the .dll and .ami files

Black box magic in binary .dll/.so files:

While there are five AMI API functions defined in the spec., most important ones are AMI_Init and AMI_Getwave. From their signature shown above, we can see that the same pointer (impulse_matrix for AMI_Init and wave for AMI_GetWave) are used for both input and output. That is, the data are passed-in, the AMI functions need to calculate the response based on this black box’s behaviors, then fill the output response back in to the same pointer to return to the simulation platform on top. This can be depicted with a schematic to depict more or less like the one below:

The assumptions implied implicitly in AMI channel simulation is that the input impedance to the AMI model (black box above, such as Rx model) are infinitely high, same for the output stage of a AMI Tx circuit. So we can imagine two voltage controlled voltage sources (VCVS) with gain = 1 are used at both input and output ends, with the AMI model sitting in the middle to transfer circuit block’s response between stages.

The content inside the “black box” are not visible to outsiders, so a model developer can write spaghetti C/C++ codes to mangle everything together and produce module used only once. Or he/she can does a better job by architecting it in a modular way like the one below:

If we image this with a spice netlist, it will be something like a .subckt:

Parameters to different modules are apparent and omitted here. Construct an AMI model this way will enable module being reused more easily. With that said, the example above still has two assumptions: the first one is that only three stages (i.,e. CTLE, DFE, CDR) are used and their order are fixed. What if user want an AGC up front or LPF filter in between? Do we need to rewrite the codes and compile/test again? The second assumption is that these module are cascaded stage by stage (mostly true for SERDES design) and each block has only one input and output (not necessarily true even for SERDES), These two assumptions are not necessarily true for other design. So we believe that they do not need to be “hard coded” and compiled into the rigid AMI model.

In normal modeling process, one usually need to translate a circuit or a module’s response into describable behavior before its C/C++ codes can be written. For example, if we know this is module is a LPF (low pass filter) then we only need to get its frequency response in order to do IFFT and perform convolution in time domain. However, some blocks may not have close form formula or an easily describable behavior. Is it possible to embed a “mini circuit simulator” in a block so that its input and output will be calculated automatically? This is certainly possible. In fact, one can even implement a S-parameter block or T-Line block to serve as analog front end of the AMI model (for example, to represent a package model). In SPISim’s case, because we have developed an in house circuit simulator and associated device model, we simply need to construct a time domain PWL source representing input “impulse_matrix” or “wave” data, then run mini circuit simulation and retrieve output from simulator’s API (or even waveform on disk) and give back to the channel simulator on top.

As one can see, there are a lot of techniques or magics can be applied to this .dll/.so black boxes. Because compiling platform/OS dependent binary are not a fun, it’s our belief and practice that we should compile a comprehensive AMI model and reuse it as much as we can. The configurable part should be put in the .ami file.

Black box magic in plain text .ami file:

An .ami file has settings for both channel simulator and more importantly, the .dll/.so models being called. It contains two parts:

The “Reserved_parameters” (boxed in green) are for channel simulator to consume. The keywords used here are defined in the spec. and need to be used accordingly. All spec-compliant channel simulator needs to be able to process info. in this part (in reality, we do see individual companies defining their own keywords due to aforementioned monopoly situation).

The “Model_Specific” (boxed in red) portion, on the other hand, are only for model to consume. It’s not channel simulator’s business to judge and interfere how they should be defined and be used. As a result, we can perform many creative techniques here.

We proposed some of the techniques first late last year in previous posts. It’s to our pleasant surprise that other company, such as IBM/GlobalFoundaries also has similar thoughts. Please see their presentation at DesignCon this year linked below (Topic time is 10:15AM)

The AMI_Resolve: A Case Study for 56G PAM4   (http://ibis.org/summits/feb17/)

Simply speaking, one can embed lots of information in the .ami file to convey to the underneath .dll/.so models. Common encryption can be used to protect sensitive information. For example, the reason why SPISim can release our AMI models for free to generate and use is because our AMI .dll/.so files require a license setting and a time stamp and/or data dependent values are part of the license info. Thus, a model will expire after certain time, the parameters can be changed if locked, and the license info can’t be tampered.

The paper presented by IBM demonstrate the intercommunication between unresolved .ami file and the AMI_Resolve API function. The “netlist” or “equation” is encrypted and embedded as part of the .ami file. In the IBIS spec, a table format is also supported in the .ami model_specific syntax yet it may be a hassle to produce and use. In practice, we prefer to point to an external file directly like below:

This external file can also be encrypted up front and decrypted by the .dll/.so file on the fly. It can be a setting table, a frequency response, a S-parameter or a netlist to support the “mini-simulator” block within the AMI model. From this point of view, while the .ami file is plain text, it can still be like a black box and many aforementioned techniques to minimize the re-coding/re-compilation of the .dll/.so file can be used.

Real world examples & considerations:

While these “black box” magic are intriguing and wonderful, at the end of the day, we need to see how well they work in real world. Lets see two examples:

The first model is from Altera. Not only do they provide AMI models and documentation, they also provide a GUI tool to let user check what combination of parameter are valid. In this case, they only provide one .ami file with all possible values inside.

The second example is also from Altera but with different approach. There are many different .ami files, each supporting different usage scenarios.

In our approach, we let user to assemble a csv table first with needed columns to provide settings for different modules, each row is a pre-defined configuration so no further check of valid combination is needed.

With this approach, customer only need to change the row index, rather than different settings of different taps or modules. More over, the table is encrypted and the model publisher can provide different set of configuration to different customers, all with same set of data and .dll/.so models.

With our approach, user use our GUI front end to perform settings, then associated .ami file and pre-built .dll/.so files will be generated instantly. The .ami file contain minimized settings to make sweeping AMI parameters more easily. This minimized .ami settings will also make configuration within other EDA tool more convenient. As a result, with the help of front-end GUI, the “black box” magics resides in both the .ami file and .dll/.so models.

Check before use AMI:

It’s worth mentioning that the latest golden checker published by IBIS are now both OS and platform dependent. This is because they support embedded .dll/.so file checking on the most basic level now as well. Regardless whether you are a model developer or a model user, three steps need to be performed to validate the given or modified AMI models:

  1. Use IBIS’s golden checker (IbisChk6) to check the .ibs file. If this ibis file contains algorithmic model section, then the associated .ami and .dll/.so file will also be checked based on the platform. This will identify compatibility issue up front.
  2. Use a test driver to drive the .dll/.so and .ami file. This step is like connecting an ibis model to a test load and run simulation. A model may pass the golden checker, yet if the test load waveform is not meaningful, then there is no need to put into the full channel simulation. This step makes sure not only the model can be loaded (has all required API function defined), but it can also function properly. In HSpice and Ansys, this test driver is called “amicheck.exe” and require respective license to run. We SPISim also provide free checking/driver tool call SPISimAMI.exe for this purpose.
  3. The last step is to put into channel simulator such as HSpice, Cadence’s SystemSI, Mentor’s HyperLynx or sort. They will provide simulation measurement such as eye, BER and bath-tub plot for further validation. These features will also be in our SPICPro later this year (2017)

IBIS-AMI: An economical yet efficient modeling flow

Posted on by
Reply

Preface:

It has been often believed that IBIS-AMI modeling imposes a comparably high cost and technical barriers to get started. An AMI modeling engineer certainly has the due diligence to be familiar and understand the basic of link analysis or AMI flow. However, the requirements of implementing the models in C/C++ codes, compiling them into .dll/.so libraries, and being able to run on third party (often expensive) EDA tools with consistent results are often too much to ask for… or at least will increase the design cycle. To meet these challenges, several big EDA companies have provided top-down based flow for AMI generation directly from architecture codes. In exchange with the “click-button” convenience, SERDES needs to be designed in its environment first and tool’s up-front expense also needs to be considered. Further more, the long term cost of the generated AMI models (in terms of model support, maintenance and extensibility) are often ignored. It’s also true that even with these top-down flows, compilation on different platforms (win32, win64, linux) etc are still inevitable.

We published several free tools recently and presented a paper at the recent IBIS summit regarding AMI modeling. Together with other open source/free link analysis tool to be mentioned at the end of this post, we think it’s now a good time to consider an alternative AMI modeling flow. This proposed methodology in this post will be economic (no front end tools cost) and efficient (give SERDES/AMI developer most control).

[Note that in this post, we use link tool/simulator alternatively to represent the application loading IBIS-AMI models and calling their functions.]

Concepts:

Engineers familiar with Spice-like simulator know that we usually only need one platform specific simulator (binary). Schematics netlist is in plain text format and can be used cross different platforms (assuming good practice such as relative modeling path, file line endings are followed). A general purpose spice simulator is not design specific so there is no need to have different simulators for different circuit or IC design. This compatibility is achieved by building on simple rules, i,e KCL and KVL and linear algebra. This way a simulator can decoupled from the implementation details of design specifics.

In the “AMI-modeling” world, are there such simple rules to be found so that we don’t need to compile a binary just because the design is different? Understood that there are always trade-offs: e.g. simulation speed of design specific binary model vs slower yet convenience during modeling cycle, then at least we should find a way so that modeling engineers can focus more on the basic of the algorithmic blocks and hopefully, still find a way in a later stage to generate a speedy model with minimum extra tasks (C/C++,dll etc)

AMI model, at its current scopes, is mainly for SERDES application. They are mostly point-to-point system or can be processed stage by stage. We may also think it this way by looking at the defined AMI-API function prototypes:

AMI_Init and AMI_GetWave are two main processing routines defined in the API spec. Various arguments are passed-in and the AMI models are responsible to perform designed algorithmic within the model then return these values in place. By “in place”, we mean the impulse_matrix’s and wave’s content will be modified in the same memory address before returning back to the calling application… which is mostly simulation platform or circuit simulator.

Based on these observations, we can liberate the couplings between 1) link tool and models, and 2) models and underline algorithmic processing. Via these decoupling, an economic yet efficient flow can be made possible.

Decoupling within the model:

First, we want to observe how data are being passed from the link tool to the model. In the schematic above, the input to the Tx stage is either channel’s response (LTI mode) or bit pattern (NLTV). If the Tx is a simple pass through, then Rx will receive similar information without being affected by Tx:

Take AMI_Init as an example, we can achieve this decoupling using SPISim’s free SPISimProxy model. SPISimProxy will write the argument received from the link tool to a plain text file. After the AMI model’s processing, it will again write out the processed data to another text file before finally giving back to the link tool. This way data being exchanged between link tool and the model are now exposed… even if they both are compiled binaries. The two blue boxes above represent such generated text data. The main function of the AMI_Int function, purple block in the middle and existed in the model’s .dll/.so file as a form of the C function, is to transform input to output response.

With this, we can now replace the AMI_Init function with our own… we can write this function in matlab, python, perl, java etc language instead of more demanding C/C++ form. It only needs to interface with two text files just exposed with the following operation sequence:

  1. SPISimProxy will expose the calling arguments into a text file, the top blue box
  2. User’s script will read the text file and perform necessary processing
  3. User’s script will write out the data in similar text format
  4. SPISimProxy will read the generated text data, form argument and pass back to simulator.

Because each of these steps can be customized by Proxy’s .ami settings, a configuration file or even environment variables, AMI developers are now liberated to use what ever languages they preferred without dealing any C/C++ if they like. There is also no need for .dll/.so compilation as SPISimProxy has been pre-compiled to support most of the platforms.

The example above uses AMI_Init as an example, other API calls, such as AMI_GetWave or AMI_Resolve can be done in similar fashion. Clean-up calls such as AMI_Close or AMI_Resolve_Close are also supported in SPISimProxy model so if needed, AMI modeler can also clean-up all these file traces at the end.

Part of the arguments passed from the simulator is the model pointer. This model pointer (void*) is supposed to be persistent during the AMI process. The script author may use file based persistence mechanism across AMI_Init/AMI_GetWave calls to store constructed data structure or settings etc. By avoiding using C/C++ specific pointers or data structures, the process becomes neutral and can support many different languages.

Decoupling with the EDA tool:

The aforementioned process requires an application to drive the proxy model, and thus the modeling scripts. This can be achieved with our free SPISimAMI.exe. It’s again pre-compiled to support most platforms. Its built-in pulse response enable user to model LTI based AMI process directly. For bit-by-bit based input data, user may use our SPILite or other free simulator such as our SSolver or NGSpice to generate bit sequence, then feed this input in .csv format to the application. SPISimAMI will then take this user’s input, form the proper arguments and send to underlying AMI models… it can be modeling script current under development, or an existing IBIS-AMI models for testing or validation purpose. SPISImAMI can also be used to drive an existing AMI models via SPISimProxy so that user may get insights about this process. In the demo video we posted on SPISimProxy page, a matlab script has been used to demonstrate the AMI_Init process.

Test drive with open-source link tool:

Once the given response work properly with the prototype implemented in modeling scripts, next step is to run them in a link tool for BER like analysis. For this purpose, pyBert may be used as it also load IBIS-AMI models, including our SPISimProxy.

Up to this point, there is no front-end cost involved in the AMI modeling process and a developer only needs to use his/her own favorite language to deal with plain-text input/output. In addition, the debugging and testing of the model prototype can be done with direct command call instead of multi-step GUI operation/invocation. This not only avoid license needed with 3rd party tool, but also ensures an efficient work flow with easily repeated consistent results.

Optimization and model release:

There are several possibilities to release the models from on this process:

  • The model publisher may encrypt the script if needed, then distribute as they are. This will produce most accurate results as they have been validated by the author during the modeling process. The disadvantages include that: 1) it’s less efficient as the data exchanged between the SPISimProxy and the modeling scripts are file based, 2) the model recipient may need to install other run time interpreters such as perl, python etc in order to run the encrypt/compiled script, and 3) the client also needs to download the SPISimProxy from our site as unlicensed redistribution is strickly prohibited.
  • We can work with the model publisher to provide specific API to the prototype model such that the IP and accuracy are still maintained, yet the performance will be improved dramatically. We can also remove the unlicensed terms and add the proxy class to have your company’s name so that you can distribute SPISimProxy together with your model.
  • We can also create the corresponding AMI model with pure C/C++ codes to that there is only one model to be released with best performance and convenience for the clients.

The modeling flow suggested above is not proprietary and can also be implemented within the corporation or the modeling team. We believe that with the liberation of the modeling engineers from these unrelated AMI modeling process, they will be able to focus more on the core business logic, i.e. the algorithmic part and deliver the best quality model for the industry’s progress. Those non directly related tasks can be left for other EDA professionals (* cough *) if needed.

S-Param: Analysis report

Posted on by
Reply

Preface:

A S-parameter model can be obtained from lab measurement using VNA, full-wave field solved from a 3D structure, analytically computed via AC simulation or analysis process such as cascading of various stages. There are many situations when more than one s-parameters will be generated for similar setup. When dealing with multiple s-parameters, one should be able to quickly batch process and generate a summarized report for desired performance or measurements. Equality important is to be able to investigate and debug on a case by case basis. Both of these functions are also must haves for an EDA tool supporting S-parameter models.

Example report from the PLTS tool

In this post, we would like to discuss points of considerations when planning for these types of analysis and reporting capabilities. We would also demonstrate how they are accomplished in our SPIPro tool. Most of the mathematics for these processing can be found on website such as RFCafe or matlab RF toolbox.

 

Analysis:

There are many analyses often used so far as s-parameter is concerned.  They can be classified into several categories:

  • Conversion: such as converting a single ended S-parameter to a differential one or one with mixed mode (mixed single and differential), converting between S and Y, Z, ABCD formats, etc
  • Extraction: such as trimming unwanted frequency data points, extracting subset of S-parameter, or calculating physical properties such as impedance, effective inductance etc
  • Generation:  such as cascading different stages together, either assuming generalized 2N port in a point-to-point topology, or arbitrary ports branching out like those multi-drop situations in DDR, combining S-parameter data in other fashions such as merging, synchronizing frequency samples etc.
  • Processing: such as smoothing the data using moving average, extrapolating toward DC and high frequency based on physical properties, renormalizing reference impedance to different values.

10 of 30 SPIPro’s S-Param analysis capabilities.

Based on our experience, Convert, Cascade, Renormalization and Quality check are most frequently used. For mixed mode conversion, several port ordering scheme should be supported: incremental, interleaved or even-odd mode.

The outcome of the processing above are mostly another s-parameter. Thus one should be able to inspect selected individual Sij element either visually or textually further. For the same set of data, it can be plot in different format to reveal different properties or behaviors. For example, X-Y format by default, polar plot for causality inspection and smith chart in either Y or Z format etc. Since only several Sij elements are plot instead of the full S-parameter, some analysis can be done almost in real time to provide feedback: time domain reflection (TDR), time domain transmission (TDT), worst case eye analysis based on pulse distortion analysis or even passivity plot etc.

Texture representation can be useful when one needs to copy part of the calculated data for further analysis, such as taking effective inductance for power integrity simulation. Color coded matrix at the first and last frequencies are also useful for quickly checking connectivity or high inductance ports.

 

Report figure:

The analysis process mentioned above are good for investigation or experiment purpose. When there are more than several s-parameters need to go through similars sequence of operations, being able to batch process and report becomes important. In this case, the input conditions such as number of ports, their mode (single ended or differential etc) port ordering and reference impedance etc are specified up front (via GUI or a template). This settings will be applied to all the given s-parameter such that after they are read in by the tool, this sequence of actions will be performed automatically. After calculation,  report in the form of various figures, statistics and csv can be generated:

  • Frequency domain figure: one or more selected Sij traces from the processed data can be plot in the X-Y chart in linear or log scale. Waveform calculation using real or complex number with various operator including log and power should also be supported. Multi stage limit line can be added to identify boundaries which signal traces should not cross.

One or more such figures can be defined for different data and measurements.

  • Time domain figure: For time domain, Sij needs to be converted using iFFT first. To achieve certain time domain resolution, extrapolation to higher frequency and data smoothing using moving average may be needed. There are several time domain metrics often used: TDT, TDR, crosstalk, inter-pair and intra-pair skews etc. Input pulse’s rise time may affect the resulting slew rate so it needs to be part of the settings. Again, one or more such time domain figures can be pre-configured so that their settings will be applied to all s-parameter data.
  • Statistics figure: The timing or skew measurement can be summarized using a histogram with distribution curve. Their data in csv format can provide more detailed info. for individual cases.

Allowing further customization such as various font size, frequency unit, grid line etc will make the generated reports more appealing aesthetically. Finally, these settings should be allowed to be imported or exported for later use. Resulting report can be in html or pdf format with indexing at the top of the page. With this kind of capability, analyzing a set of s-parameters become easy and efficient.

 

Report data:

When there are even more s-parameters to be processed, such as hundreds or even thousands of cases from analysis methodology such as design-of-experiment or multi-dimensional sweep, even visually check with reporting becomes time consuming. In this situation, batch processing to extract performance value, summarized in a multi-column csv fashion to be used for statistic tool such as our MPro or JMP is more practical.

User first specify all the files to be processed, then specify one or more time domain or frequency domain performance targets. The processed results can be visualized as a summary plot. Interested cases or outliers can then be selected to generate more detailed report or investigate individually.

Unless specified, all the screen captures used in this post are from our SPIPro product. All the mentioned functions and capabilities are also supported in this product.

S-Param: Quality checklist

Posted on by
4

Preface:

In a typical system, there are usually three type of models involving in simulation or analysis:

  1. IBIS/IBIS-AMI: At the both ends of the channel are driver and receiver models, usually in the forms of spice, IBIS and/or AMI.
  2. RLGC: Interconnects with homogeneous structure such as transmission line and/or layer stackup are usually 2D/2.5D field solved and represented with frequency dependent RLGC matrices
  3. S-Parameter: Complicated passive structures such as package, connector or via must be solved with full-wave simulation to have accurate representations, which are almost always S-parameter.

In the recent years, due to the popularity of link analysis for low BER requirement (i.e. various SERDES interfaces), S-parameter has become more and more important. A s-parameter is now often used to represent the full channel (package + t-line + via + connector etc). In addition, there are lab measurements from VNA which are also in the form of S-parameter. Even when behavior models (broadband spice circuit) of these components are used for time domain simulation, they are also converted originally from S-param via algorithms like rational fitting.

Each of these S-parameter may have their own noise sources, bandwidth limitation or numerical inaccuracies. As a result, one has to check the quality of the S-parameter models to avoid numerical errors or instability (e.g. simulation convergence) of the analysis at the later stages.

There have been several documents floating on the web discussing about checking list for a given S-parameter, albeit lack of systematic approach or industrial support across different vendors. For this purpose, IEEE P370 committee was formed in 2015 to discuss and define a spec. as a reference. Task group 3 of this committee focuses in particularly on the S-parameter quality check. As a participating company in this joint effort since the very beginning, also as the spec. draft is coming into shape at this moment, we think it’s a good time now to share the collective thoughts and also demonstrate how these ideas are implemented in tool like our flag ship product, SPIPro.

 

S-Parameter quality check:

A S-parameter checking list can usually be classified into two categories: generic check and application specific check. This post focuses on the generic check, which is defined as checking based on their physical properties. For the latter one, application specific condition such as signaling speed, typologies, modulation method or even coding are further imposed. Generally speaking, there are several generic checks need to be done:

  • Passivity: to make sure data is passive and has no amplification
  • Causality: to make sure properties of cause and consequence are maintained
  • Reciprocity: to make sure data is symmetric
  • Even/Odd/Asymptotic behavior: to make sure even and odd behaviors are maintained at both DC and high frequencies
  • Connectivity: to make sure connectivity of structure extracted is correct and has no broken link(s)

In addition, reports from all of these check should be presented clearly with an overview and further details available. The overview summary should also use a single number for each check as well as quality metric coded with color for different level:

  • Good: Green
  • Acceptable: Blue
  • Inconclusive: Yellow
  • Bad: Red
  • NA: for information only, such as connectivity

Numerical criteria for these levels depends on the types of check. Lastly, visual checks should also be used in some cases to provide frequency specific information such as where the issue happened.

Full mathematical details and explanations of the sections below will be in IEEE P370 spec.. It will be made available free to public upon completion. We will not duplicate the details here but only giving high level description and demonstration usage below.

 

Passivity:

Power injected into a S-parameter, which includes those from incident and reflected waves, should be preserved without amplification. When this is true, then S-parameter is passive and does not contain any energy source. Mathematical requirement is:

Visually, we can plot the given traces (Sij) and see whether they cross threshold of 1.0:

And/or compute a summarized metric, Passive Quality Metric (PQM):

reported as a single value:

One way to fix a non-passive system can be use the largest (violated) value to normalize the rest such that no value is larger than 1.0, thus passive.

 

Causality:

Causality check is the most important, yet more complicated one for a S-parameter. A necessary but non sufficient condition of being causal is that the even and odd function behavior of the real and imaginary data at DC should be satisfied. Adding being passive across full frequency range will make the condition sufficient. So a causality check essentially includes many of the other checks needed for a s-param.

Due to the complexity of the math, such comprehensive check is not easy. As a result, a visual check (heuristic) may be used. This check is based on the observation that a polar plot of a causal system rotates mostly clockwise and is often very smooth. The small inner circle is usually where resonant happens which may degrade the causality of the overall data:

The progress of phase between two adjacent vectors (Sf0, i, j to Sf1, i, j) can be calculated and normalized with their dot product and magnitude. The results should be a value falling between -1 ~ 1. Negative value represents decreasing group delay and thus a counter-clockwise phase change between these two vectors. This is where resonance has occurred. One can plot such measure against each frequency and got its visual representation:

Often time, through type traces of a given s-parameter (S12 or S21) are used for iFFT for corresponding pulse or impulse responses. One can calculate this for each frequency of each through through type signal and have a summarized metric: Causality Quality Metric (CQM)

And report can contain more details about violations of different frequencies:

The fix of a non-causal system usually involves reconstructing a causal system with parameters fit the given data. Vector fitting or rational approximation are such approaches, which will be discussed in future post in more details.

 

Reciprocity:

As a s-parameter is passive, it should not be directional regarding input and output ports. Thus a S-parameter’s content should be symmetric across the diagonal part. Note that this may not be the case for materials which has non-diagonalizable property such as ferrites, yet it should hold true for most of the materials used in system elements and materials.

For a large multi-port system, color coded cell values can be used as a visual check for symmetry (reciprocity):

This needs to be done at least at the first (low) and last (high) frequency content. Regarding an overall evaluation, a Reciprocity Quality Metric (RQM) can be used:

A reciprocity violation’s fix is usually the easiest… one may average values from both sides of diagonal and replace in place.

 

Even/Odd/Asymptotic behavior:

This check is based on the fact that a transfer function should be equal to its conjugate in the negative frequency domain:

As a result, the real part of the data should be an even function while the imaginary part should be an odd one. That means at the dc level, the real data should be flat across freq = 0 axis while the image should cross origin point. Also at the highest frequency, the imaginary data should approach zero. One can think of all the inductive and reactive elements such as capacitors and inductors are either open or short at the lowest (DC) and highest (infinity) frequency point, thus make the transfer function real only.

This even/odd/asymptotic behavior is very useful when the extrapolation toward DC and highest frequency points are needed, such as the case for TDR/TDT from iFFT. DC point in frequency domain will affect the corresponding DC value at the time domain, while the highest frequency available will decide the resolution in the converted data in the time domain.

 

Connectivity:

This is to make sure the structure the s-parameter extracted from does not contain any broken channel. A simple conversion of S-parameter to Y or Z parameter and check their value should reveal the connectivity. Usually doing so at the first data point (low frequency) is enough. Color coded matrix value again will be very useful especially for large s-parameter matrix:

The example shown above is for a full DDR byte lane which involves many DQ and a pair of DQS signals. As DQS is differential, it may also be useful to separate them from the rest of the data with proper scaling for better distinction.

 

Report and summary:

To apply these checks to more than one  s-parameter, a batch mode process is often preferred and will save lots of mouse clickings:

The produced summary should contain with color coded cell and various quality metric number, plus further details for each check of different data. This will certainly gives user better idea about the quality of their s-parameter files.

All the screen captures used in this post are from our SPIPro product, which also implemented all the checks according to the IEEE P370 spec. draft.