Simulator development: Abstraction

Posted on April 1, 2016 by Wei-hsing Huang

In previous post regarding simulator development, we mentioned that simulator at its core is linear algebra (with or without relaxation) solving matrices formed to describe netlist’s nodal cutset (KCL) and mesh loops (KVL). We also mentioned that the “hot-loop” of circuit simulation are the “solve” and “stamp” routines, i.e., device solve modeling equations at that particular dc point or time-step then put contents into the aforementioned matrix formation. So a lot of thinking needs to go into formulating these two steps such that simulator developed is stable, maintainable and extensible.

On the p170 of the classic “Computer Methods for Circuit Analysis and Design” book, stamping for basic elements are listed:

Stamp

So the first level of abstraction, also the main work of “Solve” routine within each device, is to solve the modeling equations using terminal conditions (i.e. voltage or current) in a particular iteration, then translate into corresponding I, V, Y (admittance), G (conductance) then put into the circuit matrix for simulator to solve. In addition, because Newton method requires first derivative to progress and find next possible root, the “partial” value (first derivative of matrix) also needs to be computed by the device model and provide to the simulator accordingly. Without this, simulator will need to perform numerical derivative (auto-partial) to call “solve” and “stamp” routine multiple times in order to find the derivative dV/dI, or dI/dV etc at that particular terminal conditions. This will result slowness and instability of the circuit simulation.

Each device, regardless how non-linear it is, may be “linearized” to simple equivalent circuit under certain condition. This “certain condition” can be fixed time point, or fixed terminal condition like voltage supply. That is, within each Newton iteration (thus only belong to that iteration and that time point), one may transform non-linear device model into a simple linear equivalent one. Mostly using Norton or Thevenin theorems:

EqCkt

As to how to represent a device model into such linear circuit depends on the device’s physics. In my mind, this is where (device) physics comes into play in the simulator development.

For example, for simple elements like R, V, I, one can simply “stamp” entries by the book. Control sources can also be considered as (controlled) conductance, admittance and “stamp” accordingly. Complicated devices such as transistor, transmission line or S-parameters certainly need some mathematical derivation in advance. Katzenelson algorithm may be used in some condition to solve PWL network. Even devices like L and C also needs special consideration, such as numerical integration and prediction.

LCDev

The derivative forms for C and L above show that there is no direct solution to find L and C’s conductance or admittance in time domain. So numerical differentiation approach like Backward Euler may be used to calculate conductance value based on circuit history, i,e, result of previous time steps. If this is a fixed-time step simulator, then task will be easier. A variable time step simulator will certainly need much more consideration: how big a time step can be taken, what is the integration or resulted differentiation error etc. Even within device level, such as transmission line and s-parameter, the device it self also must keep track of past history so that reflection from the other end will happen at the right time. From the discussion up to this point, it should be convincing that the simulator development requires multiple disciplines.

CapCode

The second level of abstraction happened at the architecture level. There are only 26 English characters but there are much more for device types… some may be even custom made like antenna or macro circuits. So while elementary devices like R, L, C, I, V, E, F, G, H etc all have their own prefixes in the netlist, a mechanism must be in place such that the simulator can support more (some future) devices. This is mostly done using dynamic link library with predefined interfaces and access. The example below is API from Berkeley spice:

PortType

By defining these port types and access functions, the simulator limits the device’s accessibility to its internal structure and even matrices, thus can be more stable. At the same time, the defined interface also allows extensible for future devices. It is thus the device designers he or she needs to map the device under modeling to the limited, predefined interfaces such that the data can be used by simulator at the top and simulate accordingly.

After all these are sorted out, then the remaining part of the simulator development is to figure out physics of the devices, construct a model, realize that model using numerical techniques, solve and extract equivalent’s values at that particular time and iteration, and pass the data back to main caller functions then wait to see whether this solution converges for this iteration. If so, then perform book keeping either for future time step reference, or predict maximum time step simulator can take based on device’s limitation (e.g. break point in PWL sources or transmission line delay).

In SPISim’s SSolver, we reference the Berkeley architecture profoundly and focus more on the device modeling and integration. Existing spice does not have support of any devices required for system analysis, such as IBIS, Lossy coupled, transmission line, S-parameters. Even S-parameter extraction is also very tedious and limited to only two ports originally. While our experience in the past enables us to grasp the simulator architecture easily and build up functionalities much quickly, it is still respectful for us when reading the relative document and source codes when the Berkeley team developed such simulator in the first place several decades ago.

Simulator development: Architecture

Posted on April 1, 2016 by Wei-hsing Huang

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.

DeviceType

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 [Q & A]

Posted on January 27, 2016 by Wei-hsing Huang

I presented our developed “Ibis to Spice” flow last week at the IBIS summit of 2016 DesignCon. It was well received. In this post, I recapture discussions raised in the Q & A section for those who didn’t attend the summit.

Q: Does free spice have IBIS parser?
- A: Nope. Neither NgSpice nor other free spice simulators that I am aware of come with IBIS parser. As a matter of fact, none of the free spice supports IBIS model at this moment. However, interested user may see what pyIBIS has offered and make use accordingly. Lastly, accordingly to the IBIS website, one can pay about $2500 and obtain source codes of golden parser. In our tool, we do have built-in IBIS parser implemented in cross-platform format to support this Ibis to spice conversion flow.

Q: Where is ASRC? I can’t find it in Berkeley Spice 3f5’s manual.
- A: Please try NgSpice instead. Free spice simulator like NgSpice, EiSpice, LTSpice or even TISpice are all Berkeley spice derivatives. Their syntax may be deviates a little bit but the proposed algorithm should work on these simulators with very small syntax changes.

Q: Does this template only work for buffer with symmetric rising and falling?
- A: Not true. The template we have developed will digitize the analog input to a digital one… one with very sharp rising/falling edges. The detection is based on a voltage threshold. So it does not matter whether the rising and falling time of inputs are symmetric or not.

Q: Can this spice template account for buffer overclocking?
- A: IBIS spec does not specify how a circuit simulator should behave when a buffer is overclocked. So the results of a overclocked buffer maybe already circuit simulator dependent. Ideally, a mechanism will make sure current contributed by the pull-up/pull-down branches stays continuous during buffer clocking. This way voltage will also be continuous instead of sudden jump or drop. I suppose a more complicated mechanism can be added to the template to account for situations like these. However, it is not there at this moment.

Q: Will there be any issue if I simulate the buffer very long, say for 1us?
- A: If the parameter used in ASRC element is too small, for example the original value of time “t” used by switching coefficients, then it will be rounded and cause incorrect results. This is because we usually use ps range as time step. That’s why we scale the value up in the template and also account for for this scaling in the pre-calculated Ku/Kd coefficients. If the scaling is 1E9 (as based line for for 1ns), then 1ps will becomes 1E-3 and 1us will be 1E3, both should not be rounded by the simulator. Thus I think this approach should work for long simulation time, such as 1us.

Q: Why is T-Line needed? Isn’t it the case that simulator has buffer history which can be accessed for the same reason?
- A: Yes, most of circuit simulators have a buffer to record nodal voltage history. This way if one decides to use Trapezoidal rule to calculate first derivative, the previous two points can be used. Note that I am using purely spice syntax and element to mimic the dv/dt and delay effect. I have no access to the underlying C/C++ buffer structure, that’s why lossless T-Line is used. With this approach, if one want to get history data of more than one time step before, cascaded T-Line can be used. At each junction of the T-Elements stores the voltage history of previous n time steps (each T-element is one time step delay long).

Q: Why is “fine tuning” for handing off needed? Ku/Kd should have reached steady state already before transition.
- A: When buffer is not overclocked, Ku/Kd will reach its steady states. For example, Kur will be come 1.0 at the end of rising transition so that pull-up branch is fully “ON”, while Kdr will becomes 0.0 so that pull-down branch is fully “off”. The reason we need the “fine tuning” to make sure “handing-off” between Kur and Kuf (Kdr, Kdf) is smooth is purely due to the spice syntax based implementation. Theoretically, it’s not needed. User may take the provided template and comment out the “fine-tuning” section and observe the spikes. If you find out other simpler method to filter out these spikes, please let me know.

Q: What is next step?
- A: We plan to continue the path to support system simulation using free spice. Take NgSpice as an example, there are three approaches to add support for a new device, such as IBIS:
  1. Add as a native device like R, L, C: this requires knowledge of circuit simulator algorithm, the code structure and flow. Developer needs to codes in c and extend the arrays of existing device structure. It requires lots of effort and may take longer time to complete.
  2. Add a code-model library using XSpice extension: this requires knowledge of XSpice extension to NgSpice. Developer still needs to code in c still and compile code model as dynamic linked library, but the structure and flow is limited to XSpice device. There is no need to touch underlying spice infrastructure. It’s easier comparing to approach “1”. The compiled library is platform and os dependent, and is a little bit tedious in debugging (need to attach to a running process as the code model is loaded library). However, the developed code model library can run on any existing or released NgSpice simulator.
  3. Use ASRC element to model the behavior outside the simulator: This is what we have accomplished so far. It works well but performance is not that great.

In current version of NgSpice, IBIS, W-element and S-parameter device needs to be added to support system analysis. We plan to continue to approach “2” above and provide support of these devices in the form of code-model library.

Simulate IBIS Data with Free Spice [Part 2]

Posted on January 4, 2016 by Wei-hsing Huang

Note:

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:

Selection_209

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:

Selection_210

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

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

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:

Extraction of Transient Behavioral Model of Digital I/O Buffers from IBIS, Peivand Tehrani et. al, 1996 Electronic Components and Technology Conference.
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:

Selection_202

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

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]

Posted on January 4, 2016 by Wei-hsing Huang

Note:

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:

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:

Selection_195

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.

Selection_199

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

Selection_197

Selection_198

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.

Selection_201

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.

Transmission Line Model: Layer stackup and T-Line fundamentals

Posted on October 19, 2015 by Wei-hsing Huang

Most parts of the channel between driver and receiver, usually in the form of multi-segment transmission lines connected together or through different vias, reside on different layers of PCB. Thus it’s important to understand how these layers and transmission lines are modeled for signal/power integrity analysis.

Layer stackup:

A print circuit board (PCB) is usually composed of multiple layers in a modern system. Several sheets of cooper wrapped cores are bonded together with pre-preg in between to form multiple layers. The core and pre-preg are dielectric materials and coppers serve as medium of conducting plane and traces. Copper’s height is often represented by weight in terms of oz, and dielectric is made off lame retardant material (FR4). Depending on the number of routing and plane layers needed, common PCBs are often 6, 8, and 10 layers for desktop or mobile application. Both material and geometry properties of stackup and traces are quite homogeneous and can be simulated with 2D field solver.

Different conducting layers are connected with “via”, which is a barrel of conducting plate and pads/anti-pads at different layers. There are several different types of vias: PTH for plate through hole from top to bottom layers, blind layers (originates from top or bottom and ends at inner layer) and buried via. Via structures are usually non-uniform and require 3D field solver to model, thus is not included in the discussion in the layer/transmission line context.

Layers of copper+core are bonded together…

Different types of vias

Transmission line (T-Line):

Some of the conducting layers in the multi-layer PCB are used for signal traces routing. Depending on which layer they are, different relations respect to the adjacent reference plane may be formed: Microstrip, Stripline and Dual stripline.

Types of traces

In terms of circuit modeling, each short segment of such traces can be represented as a RLGC lumped element. The values of R/L/G/C depends on the cooper conductivity, surrounding dielectric’s permittivity, loss tangent and trace’s geometric properties such as width, height and distance to the reference plan. When propagation time through such small segment is longer than one tenth of the signal rise time, then lumped model is no longer valid. One must use Maxwell equations to explain the signal propagation behavior along this signal trace. Having that said, the circuit model of non-lumped transmission line is still represented by R/L/G/C values or matrices solved by field solver with aforementioned material and geometrical properties according to the Maxwell equations.

Lumped model and T-Line equation

T-Line performance parameters:

Several performance parameters can be defined based on a T-Line’s R/L/G/C model to describe its properties:

Impedance: Energy may be partially reflected at the boundary where impedance becomes discontinuous or mismatched. This is one of dominate factors in signal integrity problems called inter-symbol interference (ISI). Thus a quick scan of characteristic impedance of signal traces along the path can reveal many useful information why signal deteriorates.
Crosstalk: While diagonal terms of R/L/G/C matrices explains the relationship of trace itself to the reference plan, the off-diagonal portion explains the interactions between different traces. The energy is shared between these traces because of the EM fields and thus a nearby aggressor can often cause victim’s signal integrity problem particular when they run in parallel for very long distance.
Propagation delay and attenuation: These are often secondary factors when comparing to impedance and crosstalk. Signal of different frequencies propagate at different speed and suffer from different degrees of attenuation, both contribute to the deterioration of signal.

Extract performance parameters from a T-Line’s model

Stackup and T-Line modeling:

There are often trade-offs between layer stackup and routing T-Line when designing a system. For example, the PCB cost is reduced with fewer layer count yet dense routing or narrow trace width may incur more crosstalk or higher impedance. Also, how to plan trace geometries to make sure impedance is well matched along the channel? All these may need detailed planning in advance before traces or components are lay out. Thus the purpose of stackup and T-Line modeling is to explore the relationship of costs (in terms of layer count or dimensions etc) vs trace performances.

As both material and geometrical properties comes into play, on top of different trace type (microstip, strip-line etc), there are many factors to consider and one needs to identify primary ones vs performance. Basic steps may include:

Decide layer counts and where the traces will be routed
Decide material and geometry variables for the layers and traces
Generate a simulation plan to sweep across these parameters
Execute the sweep plan using field solver and obtain traces’ RLGC models
Extract performance parameters and map input variables to these targets
Identify whether this mapping (prediction model) contains desired solution
Go to step one and try different layer configuration if needed.

Layer and trace modeling

If the layer configuration is used often, one may also record the mapping model as prediction formula for future use. Our experience has shown that such models usually do not require higher order (>2) terms and are very well behaved for prediction purpose.

Prediction model

IBIS Model: IBIS AMI modeling flow

Posted on May 23, 2015 by spisim

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.

Why IBIS AMI:

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

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

What is in IBIS AMI:

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

For an IBIS AMI model developer: IBIS AMI is an interface realized in three functions which you must provide the implementations in whatever language but compiled into .dll or .so. These three functions are Init, GetWave and Close:
- 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.

.dll/.so:

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

IBIS AMI usage scenarios:

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

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: Model parameters and Spec.

Posted on May 21, 2015 by spisim

Given one or more IBIS models, if all of them passed golden parser and meet my speed requirements, how do we know which one will be best fit for my channel? In this post, we are going to propose several IBIS performance parameters. It’s out hope that with these parameters, we can easily make comparison between different IBIS models and will pick the best candidate for our high speed design need.

The basic IBIS data structure is shown above, which we should have been familiar with by now. There is both pull-up (PU) and pull-down (PD) circuits which will decide the steady state output impedance. There are ESD circuits represented by power clamp (PC) and ground clamp (GC) which operates in reverse bias condition normally. How fast the PU turns from OFF to ON state and PD from ON to OFF state determines how the transient rising response of this buffer is, similar for the falling state. Due to the reverse bias condition of PC/GC, the leakage current is usually very small.

Another situation is like the figure above. In this case, there are on-die termination associated with buffer. Thus the current when buffer is in high-Z state will be significant…much larger than the leakage current of PC and GC.

From these two common usage scenarios, it seems reasonable that we can use both output impedance and timing response, represented by rise/fall time and slew rate as bases for our IBIS model performance parameters.

IBIS output impedance:

If the buffer’s output impedance does not match immediate connected output, usually the break out region of package represented by transmission lines. There will be significant reflection and cause damage the signal quality from the very beginning. The usual remedy is to add a series resistor such that the total output impedance will match 50 ohms, the usual characteristics impedance of a transmission line. The figure below show a typical ringing caused by impedance mismatch.

Note that the PU and PD may have different impedance value around reference voltage, say 50% of Vcc, thus one common choice of series resistor to be added is the average of PU/PD impedance around that region.

IBIS timing parameters:

For better signal integrity, it is usually desired to have just fast enough signal with smooth transition edge, rather than fast signal like square wave. We have all seen the following decomposition of a square wave, as shown below. Starting with pure sin wave with same fundamental frequency, the more harmonics are added together, the more the resulting waveform will look like a square wave.

Signals of different frequencies will have different traveling speed along the propagation medium, thus cause the signal distortion. This phenomena has a special term called “dispersion”. So the slower the rising edge, meaning the closer it appears like fundamental sin wave, the less dispersion there will be. And thus our propagated signal will suffer less distortion.

Spec. Parameters:

With the simple discussions above, we propose the following parameters as a measure of a qualified IBIS model:

PVT: i.e. corner, voltage and temperature. These are information given already in an IBIS model. One needs to make sure first that the operation range is within these spec. to have desired performance presented in the IBIS model.
C_Comp: information given in the IBIS model for lumped capacitance at pad.
Z_PU: impedance of PU circuit at the reference voltage;
Z_PD: impedance of PD circuit at the reference voltage;
Z_PU_MM in %: impedance mismatch of PU circuit at some tolerance above and below the reference voltage. It’s like linearity measurement between VOH and VOL for PU circuit.
Z_PD_MM in %: impedance mismatch of PD circuit at some tolerance above and below the reference voltage. It’s like linearity measurement between VOH and VOL for PD circuit.
Z_RTT: This is the impedance representing aforementioned termination resistor(s);
RT: time duration between 20%~80% of voltage swing during rising transition;
FT: time duration between 20%~80% of voltage swing during falling transition;
FREQ: maximum operable frequency without buffer being overclocked.

Note that some people may use Tco, the propagation delay between buffer output and its digital input, as parameters as well. It’s our believe that these Tco parameters are not too meaningful. We mentioned in earlier posts that a modeling engineer or circuit simulator may sacrifice the leading steady state portion of the VT curve in order to capture most portion of the transition behavior in high speed design. Tco is not kept in the model in these case. Also, SI engineers often look at the quality with eye plot, which is folded signal of different bits. There is no eye impact (eye height or eye width) by the Tco parameters as the full response to the input bit sequence has been shifted with the same amount of time, difference of true Tco and model presented Tco value.

With these parameters, one may generate a summarized table when given a library of IBIS models and will be able to find the best candidate for driving signal down the communication channel.

Generate spec. model:

Using these spec. parameters, we may further define and generate IBIS model for our early stage signal study. We can do the sweep on some of these parameters and generate artificial IBIS model accordingly. With this model for simulation and the analysis results, an SI engineer may provide this as a feedback to the circuit designer for desired performance. As a modern buffer is usually controlled by many “legs”, a circuit design should be able to find certain combinations of these “ON” lags to satisfy the system engineer’s need, or use the feedback as a guideline in fine tuning their buffer control circuit.

SPISim BPro’s Spec. model generation

With this concept, SPISim BPro takes one step further to support spec model generation, as shown in screenshot above. User can enter the appropriate settings and the corresponding IBIS model, with rising and falling waveform table included, will be generated instantaneously without any simulation. One then may use the manual waveform editor as needed to fine tune the transition waveform shape based on this spec. model.

BPro generated spec model will have smooth transitions.

IBIS model: Debug and performance tuning

Posted on May 18, 2015 by spisim

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

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

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

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

Posted on May 15, 2015 by spisim

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

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

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

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

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

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

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.