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:
The power clamp and ground clamp branches are always on, so the data is used directly. Their ASRC data is a converted PWL curve shown below. Depending on terminal voltage V(1, 2), current will be output or drawn from terminal 3 and 4.
For pull up (PU) and pull down branches (PD), they are turned on/off only after buffer has switched, the rate of turning on/off is based on a RC constant (C1 and RB3 in the upper left of the schematic) converted from ramp rate value in the model. This RC value is then used to multiply the PU/PD voltage and finally converted to a current source using G element (VCCS, Voltage Controlled Current Source).
In the original post, author mentioned he has attempted to replace this RC based implementation with his PWL version yet get non-smooth results. We think this is because PU/PD branches are turned-on/off gradually. Only when they are left for certain period of time, static state will be reached. Thus a “time” based parameter must be present. Otherwise, static solution is solved at each time step and thus result will be incorrect. RC multiplier realizes this transition of “gradually” turning on/off the PU/PD branches.
With the RC based implementation, one can mimic the “ramp” data used in other IBIS capable simulator and produce good correlation, as shown below. Due to the simplicity of this implementation, the simulation speed is very fast.
Note that with this implementation, drawing current from VCC/VSS are way off. This is also indicated in the original post. As a result, this approach will not be useful for SSN simulation which includes PDN noise. Further more, it will not capture initial undershoot, final overshoot and other more subtle waveform presented in real buffer switching, also the RC curve (shown in the red above) is not true “linear”. In additional to the ASRC based implementation for IV tables explained above, part of the converted circuit is used to detect and convert input analog signal into digital ones. Lastly, each corner of the model to be used in the simulation needs to have a spice subckt library converted from corresponding corner in original IBIS model.
This post is written in preparation for the upcoming IBIS Summit at DesignCon 2016, where we will present this Ibis to spice flow. Please see the [Part2] and download presented slides and associated example files.
How are the ramp control values RISERMP (RTR) and FALLRMP (RTF) derived from the dV/dt values found in the IBIS files?
There are waveform sections in an ibis model, i.e. [Rising Waveform] and [Falling Waveform]. The 20%~80% transition value of these waveform are defined as RTR and RTF. You may also find IBIS spec. for more information about how these can be calculated. The calculated parameters are stored with “RAMP” keywords in an ibis model.
When converting IBIS input to LTSpice, there are only 3 SUBCKT terminals.
The input signal passes through LOPKG and ends at N005.
Shouldn’t it be converted to ’ .SUBCKT name NDIE N005 NVCC NVSS ‘ correctly?
It’s correct to have three terminals only. The conversion does not take package into account so the die-pad input of the converted buffer is the 3rd terminal besides VCC and VSS. Users should connect package outside converted buffer themselves.
Select the IBIS file on the Models tab.
However, the IBIS file is not read.
why is that?
The easiest way is address this is to simplify the .ibs file so that it contains the interested model only (i.e. remove all those header data, model switcher, pin mapping etc). As the converter works at the model level but not the .ibs file as a whole, that will improve the chance of data being parsed correctly.
If still not work, send us the .ibs file.