[SI-LIST] SPICE vs IBIS
- From: "Kai Keskinen" <kalevi@xxxxxxxxxx>
- To: <Chris.Cheng@xxxxxxxxxxxx>, <arpad.muranyi@xxxxxxxxx>,<si-list@xxxxxxxxxxxxx>
- Date: Thu, 6 May 2004 19:34:32 -0400
Chris:
I've had HSPICE files provided by major chip companies that are literally
garbage. They have used HSPICE options and commands that are global that
affect other models in the spice deck. Trying to debug an encrypted model is
not easy. The sample file they provided didn't run. After several hours or
days of grief trying to get the spice model to run, you end up getting a
model that runs from the chip vendor and a weak apology for the bugs. The
only trouble is it takes hours to run a 256 bit pattern. However, if they
can't provide a spice file that runs properly, they probably can't provide
an IBIS file which is usually created from the spice model.
Given a good company with people that understand how to create models, I'll
take the IBIS file over the SPICE file for most cases to save time. Thanks
should go to those folks who created IBIS.
-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx
[mailto:si-list-bounce@xxxxxxxxxxxxx]On Behalf Of Chris Cheng
Sent: Tuesday, May 04, 2004 9:30 PM
To: 'arpad.muranyi@xxxxxxxxx'; si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: [SI-LIST]: Which tool is the best
Arpad,
At the end of the day, our differences lie in your believe that abstracting
an accurate I/O model is trivia and running the analysis dominates the
design process.
I believe the tasking of abstracting an accurate I/O takes longer time than
the actual analysis itself especially when the I/O is constantly tuned to
optimized for the best performance.
Whose right or wrong ? I don't know. All I know is when presented with the
same set of design accuracy criteria and given a choice of SPICE or other
tools, ALL my customers turned to SPICE instead of a behavioral model and
those who tried to abstract the I/O into behavioral models takes longer time
to generate the abstraction model than the actual topology simulation time.
And by the way, behavioral vs. SPICE models is even less than days in a week
and I can still go to church on Sunday, not the 300 times you claim.
Believe it or not, I am not as single minded as you think. I actually spent
the time to benchmark both cases because I want ALL my customers to be
successful. Had they wanted SPICE, I provided them, had they wanted IBIS, I
sent them IBIS too. That's why I have the comparison between them and have
the data to back up my claims.
Whether I need a hole punch or missile is a subjective discussion we won't
go in. But like I say above, when given a choice between SPICE or IBIS, ALL
my customers want SPICE and no one end up using IBIS model. That says
something about the nature of the project isn't it ?
I always suspect many SI engineers are closet SPICE fans but their vendors
just limited their choice to IBIS only models. It may work a few years ago,
but at the speed I am dealing with nowadays, many vendors realize the
importance and start handing out HSPICE encrypted models. That's a right
step in direction in my book. Give them a choice and let's see what the use.
I know, I know, NIH and you certain don't get to go to standards conferences
in exotic places.....
-----Original Message-----
From: Muranyi, Arpad [mailto:arpad.muranyi@xxxxxxxxx]
Sent: Tuesday, May 04, 2004 1:19 PM
To: si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: [SI-LIST]: Which tool is the best
Chris,
I don't have the time and energy to respond to every thought you wrote
in your message. However, I would like to reiterate that we (IBIS
proponents) never claimed that IBIS (up to version 4.0) was good or
capable of modeling everything. One example is the predriver ground
connection you mentioned. Predriver noise, return path, etc... are
not considered in "legacy" IBIS models. Regardless, IBIS did and does
have areas where it works well. Like with everything in life, you have
to use the correct tool for the particular job you are working on. You
can't use a hole punch where you need a missile, but you would be =
foolish
to use a missile when you only need a hole punch.
On the other hand, starting with IBIS 4.1 we can now model practically
everything we want using the new language extensions. However, I would
like to quote someone from one of the tool vendors which support these
languages: "Model what you need, not what you can", because I fully
agree with you that the bigger the equations are and the more of them
you have, the slower the simulations will be.
Regarding the 300x speed improvement I mentioned before, it depends
on many factors. It depends on how big the original transistor model
is, and it also depends on how complicated the behavioral model's
equations are. I didn't claim that you will always get such speed
differences.
It is also true that you can build simulation netlists in which the
interconnect models dominate the simulation time due to their =
complexity.
But this doesn't mean that people are going to be more willing to waste
unnecessary simulation time using elaborate transistor level buffer
models just because their interconnect models are already so large.
On the contrary, people are usually looking for ways to reduce their
simulation time by turning to BEHAVIORAL INTERCONNECT models also, i.e.
using S-parameter "black boxes" instead of huge networks of RLGC and
W-elements...
By the way, I find it quite interesting that I don't hear people
complaining about S-parameter models, which are actually behavioral
models if you really think about it! So what is wrong with using
behavioral models for drivers and receivers then? True, writing
behavioral buffer models may be more difficult and complicated
than pressing the button of a number crunching tool to generate
S-parameters for a linear interconnect, but this doesn't mean
that it is not possible. And the benefits are very similar...
Arpad
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
or to administer your membership from a web page, go to:
//www.freelists.org/webpage/si-list
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List FAQ wiki page is located at:
http://si-list.org/wiki/wiki.pl?Si-List_FAQ
List technical documents are available at:
http://www.si-list.org
List archives are viewable at:
//www.freelists.org/archives/si-list
or at our remote archives:
http://groups.yahoo.com/group/si-list/messages
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
or to administer your membership from a web page, go to:
//www.freelists.org/webpage/si-list
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List FAQ wiki page is located at:
http://si-list.org/wiki/wiki.pl?Si-List_FAQ
List technical documents are available at:
http://www.si-list.org
List archives are viewable at:
//www.freelists.org/archives/si-list
or at our remote archives:
http://groups.yahoo.com/group/si-list/messages
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
Other related posts:
