[ibis-macro] Re: Your presentation at Asia Summit

  • From: "Muranyi, Arpad" <arpad.muranyi@xxxxxxxxx>
  • To: <ibis@xxxxxxx>, <ibis-macro@xxxxxxxxxxxxx>
  • Date: Thu, 9 Nov 2006 13:54:29 -0800


Thanks for your reply.  I agree, the ultimate goal is
to get models into the hands of the customer.  But this
is a lot easier said than done...  I also agree that
traditional IBIS is falling short for these high speed
models.  Your summary of the history is also pretty
good, saying that there was SPICE, then IBIS and then
SPICE started to regain strength again.  But I am starting
to disagree with what you say after that.

1)  It is true that there are not too many "push button"
*-AMS solutions out there, but there are some, or some
which come close.

2)  What you don't seem to realize or acknowledge is that
the IBIS macro model library was written in such a way that
those tool vendors who do not have *-AMS engines in their
SI tool could also make use of it BY SUBSTITUTION.  The
only thing these tools need to develop is an *-AMS netlist
reader or converter which takes the Verilog-A(MS) or
VHDL-A(MS) formatted macro netlist (template) and convert
it to the tool's internal netlist syntax.  This could be
achieved with relatively simple Perl scripts.  So there is
no need for extra cost and richness.

3)  Actually ending up with transistor level SPICE under
[External Model] is not completely true either.  Yes, there
may be a lot of these out there, but most everyone agrees
that these are way too slow, and there is an increasing
number of SPICE behavioral models out there too.  These
could very well be written using the IBIS macro library
elements.  In fact your presentation seems to be on this
level, that's why I was wondering why you didn't do it
using the IBIS macro library elements.

4)  The "advanced" IBIS macro modeling project is actually
not talking abut addressing the above problems.  It is mostly
addressing those problems which are most commonly done in
Matlab, C or other languages.

5)  Even if we put aside all of the above arguments and
assume that we want to make your request a reality, how
would you go about it?  Would you make HSPICE legal under
IBIS?  If we did that, all of the non-HSPICE vendors will
start screaming.  Should we make all SPICE flavors legal
under IBIS so we don't hurt anyone's feelings?  If we did
that, we would be back to 1993, when we could not simulate
anything because there were so many different types of 
incompatible models.  Continuing with these thoughts in
the light of the IBIS advanced technology modeling
activities for high speed SERDES modeling, how would
you feel if we also made Matlab, Mathematica, C, C++ and
other favorites legal under IBIS?  Wouldn't that create
a tower of Babel situation in the world of EDA tools and
models?  Would your company be willing to support ALL of
these languages in your SI tool, so that people could
use models written in any of these languages and cosimulate
them together?  I think that would eve cost you more than
supporting only one of the *-AMS languages that your
company already has in your other tools...

6)  How would you propose to solve this language problem?




-----Original Message-----
From: Lance Wang [mailto:lwang@xxxxxxxxxxx] 
Sent: Thursday, November 09, 2006 12:23 PM
To: Muranyi, Arpad
Cc: ibis@xxxxxxx; ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Your presentation at Asia Summit

Hi, Arpad,
Thanks for reading my prez and asking so detailed questions about the
conclusions. :)

Let me give you some backgrounds for making this presentation first. 
As everyone noticed, PCIe/Serdes type devices are more and more shown in
current electronic market especially 2.5/3.125GHz devices. The first
problem the vendors met is how to deliver the SI models to their
customers so they can do the simulations accurately, fast and also IP
protected since the simulation is required for this kind of designs.
What they have in hands first is the Spice transistor-level models
(mainly HSpice compatible models). They would look for IBIS solutions as
well for these models. However, unfortunately, traditional IBIS can't
correctly model them. Then, people looked into IBIS [External model] in
4.1 and 4.2. What they found is that IBIS only allows Berkley-Spice
(3f4?). This is not what they look for. (I think I don't need to list
the issues using Berkley-Spice here.) Will AMS do the trick? Yes or No.
Yes, AMS is functional for this technology. No, not a lot of people
(companies) want to spend extra-cost for the tools expect some rich
companies. (These are not $9.99 products. Correctly me if I am wrong.)
More naturally problem is that there is no push button solution for AMS
SI models now. What did they end up? Using IBIS [External model] with
Spice transistor-level models. Please note these are NOT Berkley Spice
models. Also, there are a lot of parameter settings in PCIe models. For
the ease of use, Parameter passing is required for Spice [External
model] even if IBIS didn't allow them. 

In this stage, simulation performance and IP protection are the big
concerns for the IBIS "Advanced" Spice [External model]. The
macromodeling is kicking in solving these issues, I meant IBIS
"Advanced" Spice Macromodeling.

Yes, the requirements from this presentation conclusion are somehow
related. When IBIS opens for "Advanced" Spice, parameter passing
requirement can be processed. However, "self-containing" capability
should be required for IBIS Macromodeling in general included AMS types
as well.  


Lance Wang
Cadence Design Systems, Inc.

-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Thursday, November 09, 2006 1:28 PM
To: ibis@xxxxxxx; ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Your presentation at Asia Summit


I read your presentation you gave at the Asia IBIS Summits
and I would like to ask you a couple of questions regarding
your "IBIS future enhancement requests" on the "conclusions"
slide (pg. 31).


You are asking for opening the SPICE link in IBIS to other
commercial SPICE simulators, and consequently you are also
asking for the parameter passing capabilities for [External
Model] (and probably [External Circuit] also) which was not
made available in the IBIS specification because Berkeley
SPICE does not have that capability.


1)  The first sentence in Section 2 of the IBIS specification
which is entitled "Statement of Intent" says the following:

| In order to enable an industry standard method to electronically
| IBIS modeling data between semiconductor vendors, EDA tool vendors,
and end
| customers, this template is proposed.  The intention of this template
is to
| specify a consistent format that can be parsed by software, allowing
| tool vendors to derive models compatible with their own products.

In other words, the IBIS specification was intended to provide
a common modeling language for the EDA industry.  Your request
seems to be asking the endorsement of proprietary SPICE languages
in IBIS, which goes in the exact opposite direction of the "IBIS
philosophy" which was to eliminate the need to make zillions of
tool specific models for the same product.  How do you see your
request to be fulfilled?

2)  The very reason the IBIS macro modeling subcommittee spent about
two years to put together the IBIS macro modeling library was to
solve this problem.  We wrote a SPICE compatible library in the *-AMS
languages so that tools which cannot interpret the *-AMS languages
could by substitution use their own native SPICE equivalents.

See pg. 2 in the following presentation:
See pg. 7 in the following presentation:

Everything that you showed in the above presentation could have
been implemented with the IBIS macro modeling library.  Why are
you not making use of this library, and why are you requesting
that features which are already available in IBIS through the
macro library be made available with proprietary SPICE languages
which is what we wanted to avoid with the entire IBIS macro modeling


IBIS Macro website  :  http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector:  http://www.freelists.org/list/ibis-macro
To unsubscribe send an email:
  To: ibis-macro-request@xxxxxxxxxxxxx
  Subject: unsubscribe
IBIS Macro website  :  http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector:  http://www.freelists.org/list/ibis-macro
To unsubscribe send an email:
  To: ibis-macro-request@xxxxxxxxxxxxx
  Subject: unsubscribe

Other related posts: