Simulator development: Architecture

Effective analysis methodologies and streamlined flows are built on top of core technologies. For system electrical analysis, these core technologies are mostly 2D/3D field solvers, circuit simulator and statistical processing engine. So far as simulator is concerned, HSpice by Synopsis is often considered as a golden reference. While it is more accessible for us in this part of the world, apparently it may not be the case for other areas, particular in Asia. To enable our customers for system analysis not bounded by the availability of HSpice, we embarked the journey of simulator development last year. As it comes to fruition with the release of SSolver in Q1/2016, we would like to share some of the thought process with the coming posts for readers who interested in how it works. Note that the context here is MNA based electrical simulator, mechanical and thermal etc disciplines are not included.

Circuit simulator is an art of combining computer science, physics and mathematics.

Each junior EE undergraduates learned that circuit analysis, in its most fundamental form, can be done with nodal analysis or mesh analysis. One can use KCL and KVL for the nodal cut-sets and loops in the circuits and form equations representing the circuit’s branch current and nodal voltage.


However, not all of the elements can’t be represented with pure voltage or current form. In order to “probe” voltage or current of particular node or branch, the combined analysis, modified nodal analysis (or MNA), is used. Nodal analysis is used as basis here because there are fewer cut-sets than mesh loops. So when writing all the equations into a matrix form, the dimensions of the matrix for nodal will be considerably smaller and thus more efficient for solving. With the matrix form, it’s thus clear that the circuit analysis is basically linear algebra… store and solving MNA matrix many many times. In my mind, this is where mathematics comes into play. All the matrix’s techniques will apply: sparse matrix, pivoting, conditioning etc. If the matrix is ill conditioned such that after certain iterations, the solutions can’t be found, then simulation does not converge. Is also often an insight simulator designer should place at this stage that how to feedback and relate matrix elements which cause non-convergence back to the original branch so that user may look into the model or connection of that device for further inspections.

While it’s easy to write a program to solve matrix and get a solution vector, it takes a lot more thoughts to do this efficiently during simulation. Without touching device’s physics modeling (yet), this is where knowledge from computer science may be very helpful.

There are many types of circuit analysis: DC, DC Sweep, Transient, AC small signal, Sensitive etc. For system analysis, we probably use transient (time domain) most. However, the most fundamental step for all these are “Newton Iterator“, that is using “Newton Raphson (NR)” technique to solve aforementioned matrix repeatedly until solution vector is found. In DC operating point phase, all models are static (e.g. capacitor is open and inductance is short). Several NR iterations later when DC solution is found, than AC model is used for small signal around this DC operating point or transient model is used to start marching into t > 0 domain. Within each time step, matrix is again consider static (respect to that time step) and many NR iteration will be performed. Nodal voltage will adjust during these iteration as tentative solutions changes, so the model’s physical response must also adjust accordingly. In some cases when DC does not converge, simulator will revert back to “Ramp” or “Charge up” in which all voltage/current sources starts from 0.0 (thus no branch current and nodal voltages are all 0.0), then gradually ramp up the value just like transient simulations.


Now there are also many different type of devices (see above), not all of them are non-linear or time varying. So to build an efficient simulator, they need to be architect to minimize function calls and thus matrix element change. For example, one may be able to classify devices into the following several types:

  • Not-time varying: e.v. dc source, whose value will not change during simulation
  • Time-varying:
    • Linear: e.c. PWL source, whose value will not change within that timestep
    • Non-linear: transmission lines, whose value will change in each iteration
  • Frequency dependent or non-frequency dependent

The purpose of this classification is to make matrix “stamping” (i.e. filling in the value) and solving as efficient as possible. These two steps are the “hot-loop” of the circuit simulation. We can then define device interface:

  • Parse: called only once per run, parse the netlist syntax;
  • Initialize: once per run, transfer texture data to counterparts for simulation
  • Model: before DC starts, construct physical model
  • Stamp: depending on device type, called once per simulation, per time step or per iteration
  • Solve: called during each iteration to solve for solution vector
  • Update: concluded and called at the end of the time step to prep for next time step
  • Request: to answer probing request and return device properties
  • Cleanup: clean-up the memory at the end of the run.

In objective-oriented language such as C++, these interfaces are realized as virtual functions to be derived and overwrite by the concrete device classes. In language like “C”, they are defined as struct of functional pointers and the derived class must overwrite and called in the same order to avoid pointer mis-alignment. There may be a predefined linklist at the simulator level which has all types of devices involved in the netlist, then simulator iterates each instantiated device within that link list at different time point or iteration to get updated value for NR matrix solving.

Also needs to be considered is the model placement: same models may be shared by many instances, thus it’s not efficient to have model created for each one of the instance. For example, many transistors may use same BSIM model, thus only the first device using this model need to initialize such model structure but not the rest. So at simulator level, separated linked list or hash map needs to be maintained for the model assignment as well.

Other considerations may include varying simulation timestep and new simulation without re-initialization. For the former cases, a predictor is used to predict error may happen if “Jump” to this time step. When actual solving find to much error due to this big jump, than backtracking to smaller time step will happen… so the book-keeping of old matrix should be at hand. Also, most simulator supports “.alter” type statements such that same netlist can be reuse  for new simulation with updated device values properties. Thus, the simulator or device designer must make sure that the simulation settings in previous run will not “contaminate” next run.

As one can see, these considerations needs to be think through when designing a circuit simulator. Other wise the developed simulator will easily become unstable and un-maintainable, let alone extensible. On the other hand, it’s also this kind of exercise and process which make a humble engineer appreciate the beauty of different disciplines of science and engineering work flawless to solve modern design and analysis challenges.

Interested reader can further explore more details in open source simulators such as Berkeley spice, and/or reference to the books recommended below:SimBooks

Simulate IBIS Data with Free Spice [Part 2]


Interested reader of this post may also want to follow up with the [Part 1] of same topic and try out the [Free Web App] which realizes this conversion flow.

For the motivation behind our Ibis to spice development and Ramp based Ibis2Spice conversion flow, please see [previous post]

Waveform based Ibis2Spice conversion:

Typical IBIS model simulation makes use of its waveform data. Thus a converted spice model from its IBIS model must be able to use these timing related data to have good correlations .

Both voltage and current related data can be timing related: In IBIS model of version 3.2 and up, one ore more “rising” and “falling” waveform may be included. Typically, two set of waveform under two different loading condition will be provided. In case only one waveform is available, simulator may convert ramp data to form additional set of waveform. In IBIS model version 5.1 and up, “composite current” is also included in order to account for simultaneous switching noise. This current information is point-to-point aligned with their voltage counterpart to withdraw current from power supply terminals of the buffer model. Note that what we call “timing” here is actually “elapsed time” after buffer’s input signal switches from low to high or high to low. Two sets of switching coefficients, Ku/Kd for rise and fall transition respectively, are used to mimic the gradually turning on/off the PU/PD branches such that under test load condition, the voltage and current waveform data can be reproduced accurately. By using these swtching coefficients, buffer’s strength will be scaled accordingly depending on the load. User may see [our past s post] for buffer’s operation in more details.

Once we have the related  info. then we can create building blocks and assembled exactly as  they are meant to be used in IBIS model, but now in spice format. So the schematic of our waveform based converted spice model will look exactly like a “stock” IBIS:


To achieve this, i.e. be able to use timing data in converted spice model and run like a stock IBIS, three main challenges need to be overcome:

  • Extract “elapsed time” info. during simulation;
  • Compute the switching coefficients Ku(t)/Kd(t) for both rise and fall transitions;
  • Assembled the block together and mimic actual IBIS operation.

Extract “elapsed time” info. during simulation:

In free spice (e.g. NgSpice)’s ASRC (Arbitrary SouRCe) element, function can be used.  One function parameter which may be used for this timing purpose is the “time” variable:


By using this “time” variable, we can calculate and extract the “elapsed time” info.:

  1. First, we need to be able to differentiate between rising and falling from input. This is because both rising and falling transition needs its own Ku(t)/Kd(t) table. After converting input analog to a digital signal, we can use first directive such that rising and falling can be differentiated. To compute dv/dt, a transmission line (TLine) can be used. Other choice may include using a Laplace equation in control element to mimic the “delay”. The decision of using TLine for the delay is also because in free spice, the control element does not support “delay” parameter like other commercial simulator does. Measurement of voltage differentials across TLine gives us dv and TLine delay is a single simulation step dT. TLine is terminated with its characteristic impedance so no reflection will incur at the far end.Selection_211
  2.  Once rising and falling transitions are separated, we can multiply the converted dv/dt with “time” variable and also use a “latch” to hold the signal at the end of the transition. Again, we use a matched TLine as a “latch”: by feeding near end voltage with the far end one, which is data of previous time step, we can have a latch holding signal indefinitely. The latched signal is show in red of the upper plot below. With another “time” variable subtracting this latched signal, we can then obtain “elapsed” time as show in the lower half of the plot. One caveat is that in typical time domain simulation for SI/PI, time step is pico-second range. Spice will ignore variables of very small value, such as 1E-12 scale, thus a proper scaling will be necessary.Selection_212

Compute the switching coefficients Ku(t)/Kd(t):

With the elapsed time, t, now available, we can compute Ku(t)/Kd(t). There are numerous paper and presentation detailing the algorithms. For example, one may compute this switching coefficients from model data based on the first reference below, or use measured based approach based on spice simulation detailed in second reference:

  1. Extraction of Transient Behavioral Model of Digital I/O Buffers from IBIS, Peivand Tehrani et. al, 1996 Electronic Components and Technology Conference.
  2. General K-table Extraction w/ Spice, Bob Ross, IBIS Summit, DesignCon 2015

In general, waveform data from two different test loads are used to solve two unknowns at each time points during rising/falling transition. This calculation is done offline in advance and the resulting data are again realized in the form of ASRC devices. The PU/PD/PC/GC branches will be exactly PWL based ASRC, only that the PU/PD takes one more input (NKUX, NKDX below) which is the switching coefficients, Ku(t) and Kd(t):Selection_205

Ku/Kd are ASRC with pre-computed coefficients and variable of “elapsed time” computed from the first step:Selection_206

PU/PD branches draw associated  current based on the Ku/Kd value presented as voltage value at node 5 below:Selection_207

Assembled the block together in spice formats:

While netlisting different PU/PD/PC/GC/Ku/Kd blocks together is trivial, a nuance becomes apparent during validation: the assembled spice model will have “spikes” right before and after each transitions which makes the model unusable.

Further investigation reveals how devil is hiding in such details… As explained in our previous post, there is a “hand-off” during transitions:

That is, when we “run out of” Ku/Kd for, say rising transition, we keep using the last point data until buffer is about to switch from high to low state. At that point, “hand-off” happens so that Ku/Kd for falling transition will be used. The “hand-off” process is triggered from input and even a time step delay in terms of table usage switching will cause huge spike and cause problem. With carefully looking into different signals in details and figure out their relation in timing, we have a solution which filters out all the spikes and produce a well correlated results, as shown below:


Both the voltage waveform and drawing current matches quite well. The small delay is insignificant because it’s a constant added to each cycle and will be eliminated in the eye plot.

As we introduce two single time step delay transmission line elements to calculate dv/dt and serve as sample-and-hold functions, they also limit the simulation time step a simulator can take. As a result, the converted model run much slower compare to its IBIS counterpart run in other commercial simulator under test load condition. In extracted channel simulation, the “slow down” becomes less apparent as there are multiple transmission line segments present in the topology. The time step limit introduced by the shortest transmission line is common to all simulators which may not be much longer than the TLines we have introduced.

Another note worth mentioning is that while this post focuses mainly about Ku/Kd and voltage waveform data, Composite current and their ISSO_PU/ISSO_PD are treated similarly: An ASRC constructed from composite current based on time aligned point with voltage counterpart is used to draw current. Another set of scaling table, based on ISSO data ares computed off line in advance in order to take the non-ideal voltage supply into account.

With both ramp and waveform based Ibis to spice flow being available, we are able to perform SI/PI simulation using IBIS on free spice simulators. Such flow has been integrated in our SPIBPro flow as shown below:

Ibis to Spice function is SPIBPro

Ibis to Spice function is SPIBPro

This post is written in preparation for the upcoming IBIS Summit at DesignCon 2016, where we will present this Ibis to spice flow. The presented slides and associated examples are shown below. Reader may also download them from IBIS's official page for this summit.

Presented slides: View externally [HERE]

Example files: [click to download]

Simulate IBIS Data with Free Spice [Part 1]


Interested reader of this post may also want to follow up with the [Part 2] of same topic and try out the [Free Web App] which realizes this conversion flow.

IBIS to Spice:

Most of the buffer modeling flows focus on creating IBIS models from existing transistor buffer design, usually in spice format. However, we also find values in  flow of doing the other way around, namely converting IBIS model to spice format. This is motivated by one or more of the following reasons:

  • System SI/PI analysis support with free spice simulators: There are several simulators, e.g. Berkeley 3f5, eispice, ngspice, LTspice, available in public domain or free of charge. Due to historical reasons, their focus tends to be more on-chip or vendor products specific, like BSim3/4 for Berkeley spice and voltage regulator for LTspice. While they all have certain degree of transmission line support, yet when it comes to IBIS portion, they are totally lack of. Without driver model, which usually comes in the form of IBIS models, one can’t perform system analysis! It’s certainly possible to develop native IBIS support into these simulators, but the immediate available solution is to have a flow to convert existing IBIS model into sub-circuit like format and be able to simulated in these simulators. The added benefit of this approach is that engineer who has ad-hoc need to run SI/PI simulations with IBIS involved can do so quickly with these free available simulators without incurring much overheads.
  • Vendor neutral release of IBIS reference data: IBIS is a non-proprietary data format. When implemented correctly, simulation results from different simulator vendors should correlate with each other very well. To help achieving this, “golden waveform” data can be part of the IBIS model release. In reality, the “golden waveform” is optional and each simulator vendor’s implementation is different, thus the results may be different. We have seem model providers, such as Micron etc, also provide encrypted hspice as part of  the release to provide “golden reference” for the IBIS model. The disadvantage is that encrypted model needs to be run on proprietary simulator which is usually not free. So there is a value to be able to release IBIS, its corresponding data in non encrypted form AND allow user to validate the model with public domain simulator as well. This also encourages (simulator) vendor neutral model release.
  • Explicit IBIS algorithms implementation for educational purpose: There have been many papers and presentations detailing usage of IBIS data inside a circuit simulator. While it’s good for high-level overview, the truth is that these algorithms are often implemented deep inside a circuit simulator. With the developed Ibis to spice flow, we expose these algorithm in the form of plain text (versus C/C++/other programming language) spice compatible subckt format. We believe it will  be very educational and have much reference value.
  • Speed up flow development: Circuit simulator is one of the back-bone of SI/PI analysis (field solver can be one of the others).  To be able to use simulator as part of the developed flow, several options are possible: 1. choose to work with established simulator vendor and require customers to have license accordingly, 2. develop one internally, or 3. make use of tried and proven ones in public domain. Each of these approaches has their pros and cons. As a start-up company focusing on providing flows of high C/P (Performance/Cost) value, we would like to save the cost of other licenses and development efforts for our customers and speed-up the development when possible, thus option 3 is a very attractive solution to us.

There is already a vendor providing Ibis2Spice in their tool. Their free version supports only up to V2.1 IBIS model and the paid version only up to V3.2 IBIS model. Having that said, the model converted by their tool can’t be simulated in free spice directly. The flow we have developed can supports up to V5.1 model which includes the current information like [ISSO] and [Composite Current] keywords. In these two posts, we will explain about our flow in details. We will first review how ramp rate data can be used in free spice, followed by how waveform data can be converted into spice, accompanied with correlation data in both cases.

Goal of developed flow:

  • Run on free simulator, e.g. Spice3F5 and NgSpice
  • Support VT waveform data (IBIS V3.2 and up) and current data as well (IBIS V5.1 and up)
  • Produce very good correlation compare to commercial IBIS implementation.

Ramp based Ibis2Spice conversion:

In this first post, we will review the existing Ibis2Spice flow. We have also re-implemented this IBIS to Spice flow and release it free in our SPILite module. Output from our flow is directly usable in free NgSpice, which is also included in our tool. Basically, it uses ramp rate data only in the given IBIS model and creates a corresponding spice model. The learning here is how behavior source, ASRC (Arbitrary SouRCe) can be used to implement the IV table lookup. This technique will be applied more extensively in waveform based Ibis to spice flow (next post).

Searching from the web will bring you to this post (for original author’s credit): IBIS to Spice Translation (part 1). In this post, author describes the operation, his attempt to modified circuit and the result. He also provided an Awk script to accommodate the the changes needs to be made in order to run on free spice. As this post is written more than twelve years ago, part of the content has been outdated. For example, the NgSpice 26 does accept the syntax like  X + -3.12 so there is no need to convert to X-3.12 any more.

The part 2 of the original post show the schematic of the converted ramp-based spice circuit. It is hard to find on the web, so we post it below to save reader’s effort:

Ibis2Spice Schematic

The key elements here are four IV curve data: XPWRCLAMP, XGNDCLAMP, XPULLUP and XPULLDOWN. These four IV tables from original IBIS have been realized with ASRC sources, as explained in NgSpice manual:


The power clamp and ground clamp branches are always on, so the data is used directly. Their ASRC data is a converted PWL curve shown below. Depending on terminal voltage V(1, 2), current will be output or drawn from terminal 3 and 4.


For pull up  (PU) and pull down branches (PD), they are turned on/off only after buffer has switched, the rate of turning on/off is based on a RC constant (C1 and RB3 in the upper left of the schematic) converted from ramp rate value in the model. This RC value is then used to multiply the PU/PD voltage and finally converted to a current source using G element (VCCS, Voltage Controlled Current Source).



In the original post, author mentioned he has attempted to replace this RC based implementation with his PWL version yet get non-smooth results. We think this is because PU/PD branches are turned-on/off gradually. Only when they are left for certain period of time, static state will be reached. Thus a “time” based parameter must be present. Otherwise, static solution is solved at each time step and thus result will be incorrect. RC multiplier realizes this transition of “gradually” turning on/off the PU/PD branches.

With the RC based implementation, one can mimic the “ramp” data used in other IBIS capable simulator and produce good correlation, as shown below. Due to the simplicity of this implementation, the simulation speed is very fast.


Note that with this implementation, drawing current from VCC/VSS are way off. This is also indicated in the original post. As a result, this approach will not be useful for SSN simulation which includes PDN noise. Further more, it will not capture initial undershoot, final overshoot and other more subtle waveform presented in real buffer switching, also the RC curve (shown in the red above) is not true “linear”. In additional to the ASRC based implementation for IV tables explained above, part of the converted circuit is used to detect and convert input analog signal into digital ones. Lastly, each corner of the model to be used in the simulation needs to have a spice subckt library converted from corresponding corner in original IBIS model.

This post is written in preparation for the upcoming IBIS Summit at DesignCon 2016, where we will present this Ibis to spice flow. Please see the [Part2] and download presented slides and associated example files.

IBIS Model: IBIS AMI modeling flow

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

IBIS AMI’s scope:



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



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

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

What is in IBIS AMI:

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

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



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

IBIS AMI usage scenarios:

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


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

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

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

IBIS model: Debug and performance tuning

In this post, we would like to talk about debugging IBIS model and performance tuning. As discussed in previous posts, one of the first and important steps to make sure IBIS model generated from simulation data is valid is to run with IBIS committee released golden parser. Often times, the parser will output the following errors or warning messages for models with suspicious qualities:

  • DC mismatch: mismatch between VT’s steady state and IV data;
  • Non-monotonic data points in I/V curve;
  • Extreme currents in IV data.

We are going to discuss these in more details below. For performance tuning, we are going to talk about buffer overclocking and the associated accuracy concerns. This is important because it will make sure your buffer will run at desired speed or lower without producing erroneous response. We also briefly talk about solution implemented in our SPIBPro modeling tool to meet the overclocking challenges.

DC mismatch:

One of the most troublesome messages output by golden parser is the DC mismatch warnings/errors:


When the mismatch percentage is small, what’s visible to modeling engineer is that their IBIS model will not produce exactly same dc steady state voltages comparing to those from original transistor buffer design. The usual remedy often is to go back  and check the IV simulation setup and biasing conditions then regenerate model and  check again. The last resort is to use editor like those in our BPro to manually adjust the data points mostly in IV table such that the DC mismatch will alleviate or even go away. To know how to fix this problem, we need to explain what this message means:

Steady state at the beginning and ending of the VT waveform

Steady state at the beginning and ending of the VT waveform

In the figure above, the beginning and ending points of each VT table, be it rising waveform or falling waveform, are assume to have reached steady state. These two steady states are taken by the IBIS parser to perform check for DC mismatch. During steady state, voltages are assumed to stay the same and the time point is irrelevant. Since each VT table comes with test fixture information, one may compute load line current with these two voltage points and the given fixture info.

DC mismatch is due to mismatched steady state and IV data point

DC mismatch is due to mismatched steady state and IV data point

In the figure above, we depict a buffer output to a test load setup, represented by variable R fixture to V fixture to ground in this case at the lower left. The load line current I is V / R. That is, when the nodal voltage at pad is V, the output current I can be computed as:

  • I_LoadLine = (V_Pad – V_Fixture) / R_Fixture

Now this current is contributed by those pull-up (PU, PC) and pull-down (PD, GC) circuits.  At logic high output state, we may assume PD are fully off (current contribution is 0.0), so current at this point is from PU mainly minus small reverse bias current from PC and GC. When looking at the PU’s IV table, we can find this V_Pad, minus Vcc (as PU’s voltage is “Vcc relative”), find out the I_PU for this voltage point. We can then find I_PC and I_GC similarly using PC and GC table if they are present (remember PC is also “Vcc relative”). Finally I_Out is I_PU – I_PC – I_GC. that is, based on these IV tables, this buffer will output current equivalent to I_Out. DC Mismatch means I_LoadLine is not equal to I_Out. That is, the output current computed from the VT’s ending points is not same as that computed based on the given IV tables.

What we just described is for logic high situation, i.e. ending point or rising waveform or starting point of falling waveform. For logic low output situation, the process is similar, only that in this case, PU is assumed to be fully “OFF” so most of the current drawn is from the PD branch.

Knowing the causes of this errors, then the approaches to fix become apparent. Either one may need to adjust (manually or check and re-simulate to generate) IV table, or need to check whether the VT wavform make sense or not. Our experience show that 90% of the case, IV simulation is not done correctly, either because bias condition was not setup properly, or the “pseudo-transient” methods change voltage too fast such that the current measured is not true “steady state” current.


Non-Monotonic Points in I/V data:

This messages means the table is non-monotonic, meaning the sign of its first derivative changes. Our experience shows that these types of warnings are usually OK to ignore. However, strong non-monotonicity may cause simulator trouble to find solutions around that region, thus cause non-convergence issue.

Often time these troubling points are in the non-active region of the device and can be “smooth” out easily by deleting offending or adding points. It should also be noted that some devices do exhibit non-monotonic behavior, so artificially removing them either to make it more appearing visually or to avoid parser warnings may cause concern of the model recipients about accuracy of this model, if they are also knowledgeable about this type of buffer design.


Extreme current in IV data:


This happens most common to power clamp (PC) and ground clamp (GC) data table. However, since PC/GC currents can’t be removed and must be subtracted from the PU/PD (pull-up/pull-down) current during modeling, it may also means that PC/GC currents are not captured properly in PU/PD such that after subtraction, PU/PD data table shows signs of “break down” current like those in the PC/GC.


The picture above shown typical PC/GC curve. As one can see, most of the time (in normal buffer operating region), the curve is relative flat and value is small. This is in reverse bias region and leakage current is small. However, due to the -Vcc ~ 2Vcc requirement of the IBIS modeling to account for total reflection. the ESD circuit may well march into the “break down” region and have exponential like current output or drawn from the pad. It is in this area which may cause extreme current warning.

Since the buffer operate in ESD’s reverse bias region mostly, the approach to fix this can be simple, albeit a little artificial. One may find the data point at least 1 volt beyond points when ESD starts to breakdown and use these two points for extrapolation. This way the exponential like curves are converted to linear with still sufficient current output/drawn to allow ESD circuit, represented by PC/GC, to protect the circuits connecting to the buffer’s output.


Buffer Overclocking:

Each set of rising and falling waveform combined to form a complete period, T. The maximum frequency a circuit simulator can operate this buffer thus is FMax = 1 / T. That is, the longer the T is, the lower speed buffer can operate without letting simulator sacrificing some of model’s original data.

When a buffer is operated at a higher frequency than its models allows, FMax, this buffer is being overclocked. Overclocked buffer may produce inconsistency issue, as explained below.


The figure above shows a typical untrimmed VT simulation data or IBIS model VT waveform. One will find that the steady state portion occupies great portion of the data points. So if we set a tolerance range around these steady states and trim to remove those data points, we may end up with a much shorter duration of the data table which still captures the majority of the transition informatino, yet can be operated at a much higher frequency.

Normally this type of the “trimming” can be done by the circuit simulator automatically. However, being a modeling developer, you would not want to limit your user choice of simulators. Since IBIS spec does not give a clear messages how a circuit simulator should trim the data (e.g, trim from back or from the beginning, with how much tolerance?), one may often find simulation results inconsistent when different simulators are used on the same IBIS model, particular at a higher frequency.

MIN corner has much longer delay

MIN corner has much longer delay

Another example of source of overclocking is shown above. In this case, the min corner waveform, represented in blue, has much longer delay than the other two corners. Since the IBIS spec. requires that all TYP/MIN/MAX corner should share the same set of X-data (time), the MIN corner will then be easily overclocked or even won’t have enough transition information captured in the produced IBIS model.

To address this overclocking issue, SPISim propose letting user gain finer control of the trimming behavior. Also let tool take care of the tuning after trimming is done to avoid aforementioned DC mismatch issue. Another handy solution is to use editor provided by BPro to allow certain degrees of manual editing easily.


SPISim BPro’s manual tuning capabilities

Note that besides the voltage portion we have discussed so far, power aware IBIS 5.0 model also present another challenge: The composite current, which contains crow-bar current as well, usually starts being active even when output voltage is still steady. As a result, simulator can’t trim out the leading steady state voltage because doing so, will sacrifice the current information presented in the model. We will discuss this problem and propose solution further in future post.

IBIS model: How to create an IBIS model

In previous post, we described the required data inside an IBIS model. These data are mostly various IV, VT and IT look-up tables under different test loading conditions. The IBIS modeling process thus is to create these tables from original buffer’s simulation results, then format and output as IBIS compatible syntax. Basically, the IBIS modeling process includes the following steps:

  • Collect: Collect design collateral, such as spice netlist and parameters;
  • Generate: Create schematic net list to excite the buffer into operations mode;
  • Simulate: Simulate the schematic net list using original buffer design;
  • Calculate: Check and post-process simulation waveform, compute data;
  • Model: Output the processed data into IBIS format;
  • Check: Use golden parse to check syntax, fix any errors and address warnings.
  • Validate: Create schematic net list to excite the generated IBIS model, obtain its performance parameters and simulation waveform under test load. Correlate the performance from original buffer design and that from created IBIS model;
  • Report: Document the IBIS model, annotate manufacturer information etc. and ready for release.
SPISim BPro's IBIS modeling flow

SPISim BPro’s IBIS modeling flow

Let’s talk about these steps in more details.

  • Collect:  Take this buffer design as an example. If we are going to create an IBIS model for this buffer, first we need to obtain the original spice net list which mostly contains many transistors. Besides, we also need to know under which condition this buffer is manufactured. That means we will need manufacturing process info. We also need to know its nominal operation condition, i.e. voltage supply. Lastly, we need to know at what temperature this buffer is expected to be operated at… as transistor’s performance is affected by the temperature quite a bit. Together, these are usually called P/V/T corners (Process, Voltage, Temperature). Lastly, we need to know what each of the buffer terminals should connect to (bias condition) in order to operate. Normally, a buffer will have many control “legs” which circuit designers can use to fine tune its performance such as slew rate and output impedance. Different settings for control legs will yield buffer with different performance. As an IBIS modeling engineer, you will need to obtains the settings, usually are series of bits flags, for these control legs. With all these information ready, you then can create schematic net list to excite the buffer for modeling.
Transistor and process info. for a buffer design

Transistor and process info. for a buffer design


  • Generate: In this step, one needs to excite buffer in order to extract simulation data for different IV/VT/IT tables. Different buffer model type requires different tables. The following give simple overview of how buffer needs to behave for different table’s extractions needs:
    • IV for PU: enable the buffer to output high state, sweep voltage at output pad from -Vcc to 2Vcc to get input current;
    • IV for PD: enable the buffer to output low state, sweep voltage at output pad  from -Vcc to 2Vcc to get input current;
    • IV for PC: put it in high Z state while provide input to like it will output high state, sweep voltage at output pad from -Vcc to 2Vcc to get input current;
    • IV for GC: put it in high Z state while provide input to like it will output low state, sweep voltage at output pad from -Vcc to 2Vcc to get input current;
    • ISSO PU: put a variable voltage source between ideal supply voltage and buffer’s pull-up terminals, then measure input current at output pad while the voltage sweep from -Vcc to Vcc. This mimics buffer operating under non-ideal voltage supply condition (i.e. voltage droop).
    • ISSO PD: put a variable voltage source between ideal ground and buffer’s pull-down terminals, then measure input current at output pad while the voltage sweep from -Vcc to Vcc. This mimics buffer operating under non-ideal grounding condition (i.e. ground bounce).
    • VT for rising/falling waveform: Connect buffer’s output to test loads and make buffer operate for low to high and high to low transition. Note that the input stimulus’s ramp rate should be practical (e.g. 100ps) as there is no instantaneous logic transition in real world. Do this again for different test loads. At least two VT simulation should be performed, with these two test loading conditions cover the actual usage range of the generated buffer.
    • IT for composite current: Put a zero-volt voltage source between ideal voltage source and buffer’s pull-up circuitry. Monitor its drawing current as buffer runs during operations for previous VT simulation. Typically IT and VT set-up can be combined in one simulation;



  • Simulate:  The aforementioned net lists file can be generated either separately, i.e. one net list targeted for one IV/IT/VT table extractions, or be combined in one single deck and simulate sequentially using like HSpice’s “.alter” statement. The advantage of doing it separately is that these netlist can be simulated in parallel either using different threads on the same machine or using simulation farm/pool. One might need to perform “pseudo transient” simulation instead of true DC sweep as either some of the buffer design has clock signal or they tends to have convergence issue when doing pure DC sweep.

BPro generated netlist files

BPro generated netlist files


  • Calculate: In this step, the simulation results need to be visually inspected first to make sure the buffer outputs are desired. If not, one needs to go back to the first step and see whether there are missing bias condition needed to apply to buffer or the simulation setup is incorrect. Remember… garbage in, garbage out! If the simulation waveform is as expected, then the calculation step usually involve subtracting the always existed PC/GC reverse bias current portion from IV data for PU and PD, and switch the voltage for PC and PU such that they will be Vcc relative. If there is on die termination, the PC/GC current will be significant and may needs other special treatment. [Linked to Bob Ross’s paper]


  • Model: This step involves translating the calculated data table, along with its operation and loading conditions when the buffer is simulated, into IBIS syntax compatible format. To make data table compact and accurate, an optimization process is usually needed such that best 100 or 1000 points of data are selected from the sometime lengthy time-domain simulation results. Also, all Typ/Min/Max waveform columns have same time point at particular time. so the optimization process needs to take these into account. This optimization process is important for IBIS V3.2 model which only allows 100 data points in the table, and IBIS V5.0 model as well as the composite current is usually very “spiky” and best points need to be selected properly in order to capture most of the current behavior.
BPro's algorithm selects best 100/1000 points

BPro’s algorithm selects best 100/1000 points


  • Check: Once we have generated an IBIS model, the first step of sanity check is to invoke golden parser to check the syntax. Besides, it will also detect possible dc mismatch issue which implies the quality problem of the generated model. If the difference is beyond certain percentage, it will be flagged as error by the golden parser and most industry circuit simulator will refuse to run on these models. So it’s crucial to iron out and fix any errors and minimize the warning messages.
BPro uses golden parser to check syntax and detect errors

BPro uses golden parser to check syntax and detect errors


  • Validation: Once a syntax valid IBIS model is generated, one needs to further validate its performance and ensure it correlates to the original buffer design well. The validation net list contains instantiated IBIS instance alone with same test loading condition used for original buffer excitation. A good IBIS model is not only accurate, compact, but also run very fast without any convergence issue. So this step should run very fast. One can then visually check and correlate the simulation waveform produced by both original buffer in the “simulation” step and those produced by this just created buffer. Except for the leading delay which IBIS model is not intended to capture, the transition waveform shape and dc steady state should correlate very well.


  • Report: A quantitative report is usually expected to demonstrate the quality of the generated buffer. IBIS accuracy handbook and quality spec give spec. on these as industry standard. A “figure of merits” (FOM) is usually used to represent how well the generated IBIS model correlate to original buffer design.
BPro's visual inspection and FOM reporting

BPro’s visual inspection and FOM reporting

The above is a brief overview of the eight-step IBIS modeling process. There are many details which worth further discussion but are beyond the scope of this post. As one can see, there are many steps involved. While creating IBIS model manually is possible, yet it’s time consuming and error prone. That is why we SPISim developed the BPro module to address the needs for the streamlined modeling process.


IBIS model: How does IBIS work

* Buffer model: What is in an IBIS model:


IBIS Spec defines many different buffer model types, as shown above. Different model types requires different modeling data to be included in the IBIS model section. In general, an IBIS model will have the following info.

  • Operational conditions: such as voltage and temperature range for operations
  • Parasitics/Loading conditions: such as C_Comp of the model. This value does not impact buffer performance when output is well terminated.
  • I/V table: These are I vs V tables of different corners for pull-up (PU), pull-down (PD), power clamp (PC) and ground clmap (GC) circuitry. They are general representations of non-linear resistor like those E elements used in the hspice circuit. According to the spec, the sweep range for these table should be from -Vcc to 2Vcc where Vcc is the power supply voltage. The reason is that in case of total reflection from the far side of the loss-less channel, either to do fully open or fully connected to ground, added full Vcc voltage swing will extend the original 0 ~ Vcc range to -Vcc to 2Vcc. Also notice that for IV sweep of pull-up circuitry, i.e. PU and PC, the voltage is Vcc relative. That means value of I when V = 0 is actually when V = 0 to Vcc = Vcc to ground. One usually needs to make such conversion back to be VSS relative during debugging process. SPISim’s IBIS module, SPIBPro, has such a GUI button to translate Vcc relative to Vss relative waveform directly.
  • ISSO PU/PD: These are current tables introduced in V5.0, used when terminal VCC and VSS voltages are not ideal. With lower VCC voltage due to PDN network (i.e. voltage droop), buffer strength will become weaker. So are those caused by ground bounce. This phenomena is usually called “Gate modulation effect”. ISSO/PU and PD data defines the effective current of the pull-up/pull-down structures as a function of the voltage on the pull-up/pull-down reference nodes (ideal is Vcc and Vss/Gnd)
  • V/T table: These are tables representing buffer’s voltage at die output vs elapsed buffer switching time. Under different loading condition, such as test load and test fixture, resulting waveform will be different. An ibis model usually will include at least two such VT tables under different loading condition to provide sufficient coverage during real world operations.
  • I/T table: These are tables representing buffer’s drawing current vs elapsed buffer switching time. It needs to be synchronized with aforementioned VT table so that current drawn happens at the exactly same time point for the same test fixture. This current is usually composed of bypass current, pre-driver current crow-bar current and termination current if present.

* How is IBIS modeling data used during circuit simulation:
With so many tables, one may wonder how they are used in a circuit simulator. To simplify, let’s first remove the ESD protection circuitry PC and GC as they are usually reversed biased and contribute very small amount of current. For the remain PU and PD circuitry, we can imagine them as non-linear resistors, similar to those MOSFET’s channel resistance when terminal voltages varies. How these two table work together during different loading condition decide the resulting transient VT waveform shown in the VT/IT table.

During rising transition, PU circuitry gradually turns to fully ON while PD circuit gradually turns to fully OFF. Similarly, during falling transition, PU gradually turns to fully OFF and PD turns ON. Thus we can define a time dependent parameter, “switching coefficient”, which will be applied to PU and PD separately such that the resulting current from these two branches mimic the gradually turning ON/OFF effect.

Let’s call these two switching parameters Ku(t) and Kd(t). We needs two equations to solve these two unknowns. Now assuming we have to such VT table under different loading condition. At each time point of these two tables, we know the loading condition and instant output voltage of the buffer. Using these, we can solve Ku(t) and Kd(t) in which the time, t, is buffer switched elapsed time. That is, the x-axis of the VT table.

If we don’t have two waveform table, one may make an assumption that Ku(t) + Kd(t) = 1 at all times. This is usually true at the static high or static low output condition but may not be in between. One may also use ramp parameters in the IBIS model to generate an artificial VT table for the same purpose.

For an IBIS model developer for circuit simulator, he/she needs to consider all the branch current to obtain accurate Ku(t), Kd(t) solutions. So reverse bias current from ESD circuit need to be put in and so is the current flowing through C_Comp. For example, i=C_Comp * dV/dt can be sued to subtract current flow through this capacitor from the total output current and avoid double counting.


For power-aware model, another level of scaling parameter needs to be applied. These new parameter need to scale the buffer output strength based on the instant nodal voltages across buffer terminals such that gate modulation effect will be taken into account.

Interested reader may find detailed algorithm in the following two paper.