Re[2]: [SI-LIST] : Convert an IBIS model to SPICE Model.

Arpad Muranyi ([email protected])
Fri, 03 Apr 98 16:54:00 PST

Text item:


If I understand it correctly from your description, the EIAJ proposal is
basically using a behavioral transistor, meaning that you still have to use a
full netlist to describe a buffer with its predriver and other proprietary
circuitry (which the various vendors would very much like to hide), except the
transistors are described behaviorally instead of a process file. Is this

If yes, I guess many companies are not going to like it...

Don't take me wrong, I am a perfectionist and would like to improve on
everything I can.


I'm not sure what are IBIS extentions? IBIS is just a data sheet that
gives electrical information useful for SI work. Every vendor Spice or
other must then take that data sheet and convert it into a model. Now
some simulators take in table data like that produced by IBIS. And
believe it or not some of those vendors are Spice vendors. But actually
what your'e looking for is an SI solution. As I mentioned before there
is a proposal from EIA in Japan that essentially attempts to standardize
a table spice format. That format is very compatible with IBIS. In fact
IBIS would do well to adapt it. Many of the "birds" and issues of
flexibility, capability and accuracy would go away with this standard.
The standard describes the transistor in table format. No propietary
data is included. The difference between that spec and IBIS is that
this spec is general since its at the transitor level. For IBIS lovers
the data for the I/V is still retained so in essense IBIS becomes a
subset at least for the technical part. Then everybody would be happy
since Spice guys can still use the topologies allowed by Spice and the
transistor data would be there. The data shows nothing of process so
IC vendors would be happy. Current IBIS users should be happy because
the data they want would still be there and non spice vendors who do
not care for transistor level data could make use of the information
that's already in the spec. As those guys become more sophisticated in
their modeling technique they could start incorporating information
about the Gate for example. Which is a BIG problem in IBIS at the

Now what's wrong with this. Can anybody please explain to me why this
should not be implimented? Certainly from a technical standpoint this
would be a great standard. Lets here from both the IBIS and Spice fans
on this one.

Best Regards,

Fred Balistreri
[email protected]

Text item: External Message Header

The following mail header is for administrative use and may be ignored unless there are problems.


Precedence: bulk Sender: [email protected] Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii References: <[email protected]> Subject: Re: [SI-LIST] : Convert an IBIS model to SPICE Model. CC: [email protected], Andrew Ingraham <[email protected]>, "'SI_LIST'" <[email protected]> To: [email protected] MIME-Version: 1.0 X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.3 sun4c) Organization: Apsim From: Fred Balistreri <[email protected]> Date: Fri, 03 Apr 1998 11:06:19 -0800 Message-ID: <[email protected]> Received: from UNKNOWN(), claiming to be "contec12" via SMTP by, id smtpd011721; Fri Apr 3 11:05:30 1998 Received: (from [email protected]) by (8.8.5/8.8.5) id LAA11723; Fri, 3 Apr 1998 11:05:35 -0800 (PST) Received: from ([]) by (8.8.8/8.8.8) with ESMTP id MAA18626; Fri, 3 Apr 1998 12:02:17 -0800 (PST) Received: from (earth.EBay.Sun.COM []) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA00076; Fri, 3 Apr 1998 12:02:17 -0800 Received: from Eng.Sun.COM by (SMI-8.6/SMI-SVR4) id MAA12503; Fri, 3 Apr 1998 12:03:55 -0800 Errors-To: [email protected] Received: by (SMI-8.6/SMI-SVR4) id MAA12507; Fri, 3 Apr 1998 12:04:04 -0800 Received: from (silab.Eng.Sun.COM []) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA10870; Fri, 3 Apr 1998 12:46:41 -0800 Received: from Eng.Sun.COM (engmail1 []) by mercury.Sun.COM (SMI-8.6 /mail.byaddr) with SMTP id MAA10431; Fri, 3 Apr 1998 12:46:52 -0800 Received: from mercury.Sun.COM (mercury.Sun.COM []) by (8.8.6/8.8.5) with SMTP id UAA21117 for <[email protected]>; Fri, 3 Apr 1998 20:58:11 GMT Received: from ( []) by fmm (8.8.5/8.7.3) with ESMTP id MAA03526 for <[email protected]>; Fri, 3 Apr 1998 12:53:13 -0800 (PST) Return-Path: [email protected]