Simulate IBIS Data with Free Spice [Part 1]

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:

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:

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.

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:

IBISAMI_Block

 

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.

IBISAMI_Include

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

IBISAMI_AMIParam

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

IBISAMI_Work

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

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.

IbisRttROn

 

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.

RttTerm

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.

ZMismatch

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.

Harmonics

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

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.

BPro generated spec model will have smooth transitions.

 

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:

DCMismatchMsg

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:

ExtremeIError

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.

PowerGndClamp

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.

Tolerance

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.

Tuning

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;

BPro_ISSO

IBISIT

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

IBISType

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.
    IBISPUPD
    IBISPCGC
  • 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.
    IBISVT
  • 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.
    IBISIT

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

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

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

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.

IBISCComp

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.

IBIS model: What is IBIS

IBIS is short of I/O Buffer Information Specification. The spec. was proposed in early 90’s to promote tool independent I/O models for system level analysis. It’s been evolved since even until this date. It’s now an ANSI standard and are widely supported by different system level EDA vendors, including SPISim.

IBISLogo
IBIS model is created as a behavoiral model for transistor’s buffer deisgn used in system level analysis. Several milestones and its delta improvements have been listed briefly below:

  • Version 3.2, using IV/VT data table to address and meet most signal integrity’s needs.
  • Version 4.0, introduces other language such as Verilog-A, VHDL and Berkeley spice as external circuits to address shortcomings of rigid IBIS syntax, which often is not flexible enough to represent behaviors more advanced buffer design.
  • Version 5.0 introduces power aware features. By introducing ISSO PU/PD and Composite Current which represents currents drawn from power delivery network (PDN), the voltage droop and ground bounce issues during simultaneous switching can be modeled and analyzed.
  • Version 5.1 introduce AMI to account for equalization mechanism which sits transmitter’s analog front end and behind receiver’s buffer output. AMI model is mostly written in C/C++ compiled into .Dll or .so loaded by simulator. This deviation from more high level language such as Verilog-A gave model designers tremendous flexibility in modeling the full EQ + buffer to enable bit-error-rate based analysis. However, it also significantly increase the barriers and difficulties to create a good buffer model.

IBISEvolve

When talking about the term “IBIS””, one needs to distinguish about IBIS Spec, an IBIS file and a IBIS model. The following list gives simple overview:

  • IBIS Spec: Spec. defined by IBIS committee. In addition to the buffer related portion, its general meanings may also include connector spec (ICM, InterConnect modeling Spec). ICM provides standard model format for all electrical interconnects such as cables, connectors, package and printed PCB. Previously, a different spec, EBD… electric board description was used. ICM is to replace EBD.
  • IBIS File: An IBIS file is like a container of models for an IC or chipset. An IC package usually has many pins, with several buffers inside. Thus an IBIS file usually have manufacturer’s info as part of the headers, followed by different pins, pin names and connected buffers, then detailed various buffer models and their modeling data. An IBIS file may also have package models and AMI statements which points to associated .ami and .dll/.so files for corresponding equalizer portion of the design.
  • IBIS Model: An IBIS model is an individual buffer model sits inside the IBIS file. Depending on modeling type and the IBIS version, it may have I/T, V/T, I/V data tables and corresponding operation and loading condition when these model are being excited for modeling. It’s desired the usage of this buffer model should not deviate from the modeling condition too much as the behavior in those range may not cover properly in the constructed model.
IBIS Files vs Models

IBIS Files vs Models

Viewing model data of an IBIS file in SPIBPro

Viewing model data of an IBIS file in SPIBPro

IBIS model: What is buffer model and why IBIS

Before we are going to dive into details about buffer model, we need talk about why we care…

Buffers sit at the driving and receiving ends of a channel. So while the passive channel is composed of models like transmission lines, vias and connectors, the models sit at both ends are buffer.
Channel
If you are a circuit designer, in particular, a chipset designer, you pay attentions to the transistor sizing and the associated process, voltage and temperature corners (so called PVT corners) so that you will be assure that the designed buffer, when connected to the system, will have desired strength, impedance and timing.

Transistor and process info. for a buffer design

Transistor and process info. for a buffer design

However, if you are a system designer, or a signal integrity engineer. You pay attentions to higher level of the system design, such as component placement, routing, topology, termination etc. A buffer or an IC to you is just a component off the shelf. Those design details like transistor sizing, silicon doping concentration etc are too much details for you and are mostly not needed to what you are doing. Just like when software designer make connections between libraries, they make use of application interface (API). A much simplified model to represent these buffers are thus needed to enable system design.

Thus from the perspective of needs to interface between transistor level and system level design, a behavioral model representing a buffer is certainly needed.

System level design use buffer as component.

System level design use buffer as component.

Now when we talk about buffer modeling, there are several requirements derived from different perspectives:
A good buffer model needs to be:

  • Accurate: This is most important consideration. Garbage in, garbage out. By accurate, it’s usually considered to be within 5% tolerance of corresponding original, transistor design.
  • Protect IP: From IC/Chip set manufacturer’s perspective, they release buffer model mostly publicly to enable their customers adopt the design. However, they also do not want to reveal any IP such as how the buffer is designed and the manufacturing process info.
  • Run very fast: From system designer’s view, a buffer needs to run very fast, typically at 100X ~ 1000X of the corresponding transistor design. Only so then system design, which usually includes hundreds’ or even thousands’ of buffer, is made possible.
  • Easy to generate: For a model generation engineer’s perspective, if it takes lots of effort to generate and correlate the buffer model from its transistor counterparts, then the model generation process will become error prone and cause accuracy concern. Black-box type modeling is desired mostly as the model generation engineer does not need to know how these buffers are designed yet he/she can still generate buffer model which matches its original transistor’s performance.
  • Follow industry standard: A good buffer model should follow industrial spec. or format such that it can be simulated with different vendor’s tool, such as Synopsis’s Hspice, Cadence’s SystemSI or Agilent’s ADS. A model locked in to a particular tool is usually just to hide potential accuracy and easy generation issues down the road.Often in such considerations, one may consider using encrypted transistor netlist, such as encrypted Hspice, for model release. However, this will defeat the requirement of speedy simulation performance as encrypted model is usually run at the same speed of their transistor originals.From these considerations, several industrial standard have been proposed and widely used for buffer modeling used in system level analysis. They includes: IBIS and Verilog-A. In which, IBIS is most widely used and has been around since mid 1990. More info. about IBIS spec can be obtained from the ANSI’s IBIS website [HERE].