Though I agree with most of Fred's facts I do have a few observations
that I feel constrained to make. First, If you are really interested in
IBIS you should send questions to the ibis reflector at email@example.com.
There are many IBIS experts on line there (both from SPICE houses and
SI-specific simulation houses) and they are an excellent source of IBIS
Then a few specific comments on Freds Data.
> Hello Yehuda, my name is Fred Balistreri. I have done extensive studies of IBIS and Spice
> models. I have compared the models for accuracy and speed. There is a lot of mis-
> understanding of IBIS and Spice models. The previous email was only partially right.
> IBIS models have been implimented in Spice programs rather easily. Intel who invented
> the IBIS data sheet used to qualify IBIS vendors by comparing their internal Hspice
> IBIS model to the vendors simulation. It is a very big mis conception that a simulator
> other than Spice is needed for IBIS models. I suspect this rumor is started by simulation
> companies that do not support Spice. IBIS models will run at speeds of 10x to 15x faster
> than "comparible" Spice transistor level models. IBIS only models the I/O stage. If the
> same is done with Spice transistor level then the speed improvement is 15X at most.
> If behavioral models are used in Spice (IBIS is a behavioral model) then that speed
> advantage disappears. So the rumor that IBIS is faster than Spice is only partially true.
> Using Spice transistor level models in a simulation is not the same as using IBIS models.
> Spice transistor level models many entities not possible with IBIS. Many of these are
> suttle and not important to SI engineers. However there are several distinct areas where
> using Spice transistor level models have a big advantage.
You get into a difficult area here of what you are actually trying to
compare. IBIS models are only I/O models and in the SI simulation this
is only part of the story. So now you must ask, how fast and accurately
can you simulate the interconnect. This is, of course, a simulator
vendor specific issue and there are adherents to both the SPICE and
SI-specific simulators. I think it is important to look at your specific
goals and your specific tool at this point instead of "should I use
SPICE or not".
> So it comes down to the application. IBIS models are fine to predict reflections and
> crosstalk in digital circuitry where the noise margins are typically in hundreds of
> millivolts. IBIS data is based on DC I/V curves. The rise/fall times are included in the
> data sheet. This is fine for gross approximations but has many limitations. As mentioned
> in a previous email if the I/O stage has ramp control circuitry or feedback forget about
> using IBIS.
This is inaccurate. Many non-spice SI simulation vendors have
demonstrated the accuracy of their approach for simulating Rise Time
Control or Slew Rate Control devices. Though you can create feed-back
devices that IBIS cannot model, the majority of RTC devices on the
market do not fall into this category.
>Spice transistor level models work fine for this. Despite what you may have
> heard, Spice transistor level models are much more accurate than IBIS can ever hope to
> be. If the proper transistor level model is obtained from the vendor (usually propietary)
> this would be the most accurate model one could use.
Thereis lies the rub. You simulation is only as accurate as you input
data. If the known accuracy of that data is only (say) 5%, then running
a simulation beyond that accuracy is not only a waste of time and
effort, but is no more "accurate".
>Even when hundreds of data points
> are used for IBIS, it still cannot match the Spice accuracy. This is for several reasons.
> First IBIS assumes DC I/V curves at one bias point. Secondly IBIS approximates the
> shape of the rise and falling edges from Spice or measurement data. Doing this assures
> inaccuracies during the transistors switching times. Unfortunetly this is precisely what
> we are interested in. IBIS has worked around this problem by incorporating voltage time
> points under a certain loading condition. Again, the problem with this is only one data
actually, the VT curves must be made with multiple measurement points
that then allow accurate interpolation over the entire operational
range. Various Companies have demonstrated the effectiveness of this and
INTEL has verified this accuracy for their family of components. In
fact, if INTEL had not been able to verify this accuracy they would not
have promoted IBIS as they have.
>This makes the IBIS data applicable only for that condition. The rest is
> interpolated. One hopes that the I/V curve is enough to get one close. In many instances
> it is. But in some its not. The point is the user does not know when IBIS is accurate
> or not because of this. And since the topology is not included there is no way of telling
> if there is feedback or ramp control circuitry.
> IBIS falls short in another very important area, Ground bounce. As mentioned IBIS is
> based on DC I/V curves measured under certain power supply levels. During simutaneous
> switching one cannot count on the power supplies being stable. In fact two things are
> happening. The power supplies cannot be counted on and at the same time the voltage at
> the gate that controls the transistors on/off transistion is not stable because of the
> PS problem. When several I/O's are switching then the bias points of the transistors
> are not known with an IBIS model. More importantly there is no way to account for this
> with an IBIS type model.
I am aware of at least 2 SI specific simulation engines that can predict
ground bounce effects from IBIS models. The information is there,
whether it is used is another question. IBIS even contains an area to
place specific ground and vcc to output pin maps for dedicated ground
structures. Of course, you must ask yourself, can I really get this
data? Will an IC vendor really supply me with the necessary on-chip
grounding information that is necessary to do a really complete and
accurate Ground Bounce simulation? If such data is available it is still
>The only way to properly model this condition is with Spice
> transistor level models or rely on the semiconductor vendors data concerning simutaneous
> switching. So although IBIS models can be used for ground bounce the results are largely
> unknown. My experience is that IBIS models tend to over estimate the ground bounce
> And lastly because of the above and more I would tend not to trust IBIS models at 100Mhz
> or above.
Once again, INTEL seems to think that IBIS models are accurate for their
designs with output risetimes in the .2-.5 ns range.
>There are some redeeming factors to IBIS. If one can get the IBIS models it is
> a good starting point to at least check the designs in a rather fast manner. The data
> can be incorporated into a higher level simulator as mentioned previously. Again
> accuracy is the key. Crosstalk at the hundreds of millivolt levels is ok with IBIS.
> Critical timing and ground bounce issues need to be resolved by using a more robust model
> such as Spice transistor level.
The hundred of millivolt accuracy of IBIS statement confuses me. The
Crosstalk accuracy of IBIS is unlimited, since IBIS has nothing
what-so-ever to do with Crosstalk. Crosstalk simulation is more a
function of your interconnect simulation, which you may be doing using
SPICE or a SI-specific simulator.
To conclude and get out of your hair:
IBIS is a device model information passing mechanism. It is not a
simulator, it is not an interconnect specification. It does not even
recommend what simulator or interconnect mechanism you use. Its main
purpose is to give IC vendors a safe non-proprietary mechanism for
supplying useful SI device simulation data to customers without giving
away the shop. Though IBIS does have some difficulties, these are being
The use of SI specific simulators over SPICE has some very strong
engineering advantages (which is why SI-simulators exist and sell well)
just as SPICE has definite advantages in certain areas. I belive that
most experienced designers would benefit from using both methodologies
using the strengths of each appropriately.