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

Arpad Muranyi (Arpad_Muranyi@ccm.fm.intel.com)
Fri, 03 Apr 98 16:54:00 PST

Text item:

Fred,

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
correct?

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.

Arpad
================================================================================

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

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
fred@apsimtech.com

http://www.apsimtech.com

Text item: External Message Header

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

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

Precedence: bulk Sender: owner-si-list@silab.Eng.Sun.COM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii References: <199804031641.KAA31346@hawk.us-power.com> Subject: Re: [SI-LIST] : Convert an IBIS model to SPICE Model. CC: owner-si-list@silab.Eng.Sun.COM, Andrew Ingraham <Andrew.Ingraham@digital.com>, "'SI_LIST'" <si-list@silab.Eng.Sun.COM> To: jsynesio@us-power.com MIME-Version: 1.0 X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.3 sun4c) Organization: Apsim From: Fred Balistreri <fred@apsimtech.com> Date: Fri, 03 Apr 1998 11:06:19 -0800 Message-ID: <3525332B.7ADF@apsimtech.com> Received: from UNKNOWN(), claiming to be "contec12" via SMTP by InterJet.apsimtech.com, id smtpd011721; Fri Apr 3 11:05:30 1998 Received: (from daemon@localhost) by InterJet.apsimtech.com (8.8.5/8.8.5) id LAA11723; Fri, 3 Apr 1998 11:05:35 -0800 (PST) Received: from InterJet.apsimtech.com ([209.21.21.35]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id MAA18626; Fri, 3 Apr 1998 12:02:17 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) 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 silab.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA12503; Fri, 3 Apr 1998 12:03:55 -0800 Errors-To: si-list-approval@silab.Eng.Sun.COM Received: by silab.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA12507; Fri, 3 Apr 1998 12:04:04 -0800 Received: from silab.eng.sun.com (silab.Eng.Sun.COM [129.146.121.121]) 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 [129.146.1.13]) 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 [192.9.25.1]) by thalia.fm.intel.com (8.8.6/8.8.5) with SMTP id UAA21117 for <Arpad_Muranyi@ccm.fm.intel.com>; Fri, 3 Apr 1998 20:58:11 GMT Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by fmm ail.fm.intel.com (8.8.5/8.7.3) with ESMTP id MAA03526 for <Arpad_Muranyi@ccm.fm. intel.com>; Fri, 3 Apr 1998 12:53:13 -0800 (PST) Return-Path: owner-si-list@silab.Eng.Sun.COM