Subject: IBIS to Proprietary Simulator Model Conversion Tools

From: Fred Vance <[email-masked]>
Date: Fri, 27 Oct 95 14:18:34 -0700

EDA Companies,

IBIS to proprietary model, conversion tools don't make sense to me. Why not  
have your simulators use IBIS models directly? If your simulation tool does use  
IBIS models directly (without a separate conversion utility), I would like to  
know who you are.

Some of you even plan to charge outrageous (to me) amounts of money for such  
conversion tools.

IBIS is the standard for exchange of information on I/O Buffers. You will need  
to have IBIS capability to be a viable tool vendor in the future (at least for  
signal integrity and timing analysis work). Why put an additional hurdle in the  
way of your customers?

A proprietary model to IBIS conversion tool would make more sense to me than  
converting in the other direction. Such a tool might be worth buying. The most  
important model to IBIS conversion tool, from my perspective, is s2ibis, and I  
believe it is free.

If you are one of the companies that make a variant of SPICE simulator, you  
should be especially eager to provide IBIS compatibility. The use of IBIS  
models will speed up your simulator and narrow the speed gap between you and  
non-SPICE type simulators.

Am I missing something here? I'm aware that there are analog simulations to  
which IBIS models may never be successfully applied, but for digital signal  
integrity work, IBIS is the way of the future.

Fred Vance
FirePower Systems, Inc.

---

From: [email-masked] (Jon Powell)
Date: Fri, 27 Oct 95 16:51:09 PDT

Fred,

I can reply for QUAD DESIGN:

1) We supply an IBIS converter, at no extra cost, as a part of our tool. 

2) Historically, the IBIS standard did not support the same level of information
that an XTK model supports. That is, the XTK models could model certain objects that
IBIS could not model and so if we supported IBIS as our sole language we would either
be reducing our capability or making a "dialect" of IBIS, neither of which we wanted
to do. (we still want to be able to release advanced behavioral simulation constructs
that have not had time for IBIS approval).

3) IBIS is NOT a simulation language but a data exchange mechanism targetted at SI
problems. Translating it into a simulation language seems appropriate under many conditions.

4) IBIS does not contain certain timing information that is essential to the Quad Design methodology
for SI simulation. We insert this information during the translation process.

5) For simple devices, Quad Design models are much easier to write than IBIS models. We have a huge
user base trained in writting Quad Design models and they would kill us if we switched to IBIS.

6) IBIS is God and if a mere SI program touched it directly it would burst into flame.