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

  • From: "Lance Wang" <lwang@xxxxxxxxxxx>
  • To: <arpad.muranyi@xxxxxxxxx>, <ibis@xxxxxxx>, <ibis-macro@xxxxxxxxxxxxx>
  • Date: Fri, 10 Nov 2006 15:44:31 -0500

Hi, Arpad,
I am trying to answer the questions in your email below. Please note
these may not be necessary Cadence views but my personal's.

Thanks,

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 4:54 PM
To: ibis@xxxxxxx; ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Your presentation at Asia Summit

Lance,

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.
[LW] this might be the key to get *-AMS really take off in the future. 

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.
[LW] You are under-estimates how I looked closely to the IBIS Macro
model library works, especially your works inside. However, these are
just templates or suggestions or recommendations. The issue for them is
that users may easily go out of them to make the functionalities they
needed. IBIS didn't specify AMS usage limitations in multilingual
extensions. (I don't know how IBIS could do so.) This is out of Perl
scripts or simple translations to Spice syntax. 

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.
[LW] You are right. The end should not be the transistor-level models.
Spice Macromodeling is about to solve this problem. The reason to not
use Macro library elements is because there is no Spice syntax element
and practically Spice is the most popular syntax for now at least. I
would love to make a presentation using these AMS elements when it is
getting more mainstream.  

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.
[LW] I pointed out the case study is for 2.5/3.125GHz PCIe. Beyond of
this, due to more algorithms used inside, Matlab, C or other languages
will be needed. 

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...
[LW] my view is to open IBIS to allow all languages as long as it will
fit in for the ports/nodes requirements/definitions in IBIS. This solves
immediate needs, I think. About supports, vendors usually not support
all but mainstreams and strategic ones. (Again, this is my personal
view.) For example, if HSpice is the most popular one, the HSpice
compatibility project will be launched. If AMS is the strategic one in
your company, it will be supported.

6)  How would you propose to solve this language problem?
[LW] To be honestly, I don't have an obviously solution for this.
However, open IBIS multilingual to others would solve some immediate
needs. Ideally, I would like to see some enhancements inside native IBIS
not through multilingual extensions in the future. Please remember the
recent IBIS' growing is not because of IBIS linked with AMS. Using AMS
to solve all the issues IBIS has is not helping IBIS grown at all.
(Actually it is killing IBIS in the long run, as my personal view.)     


Thanks,

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

 

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

Thanks,

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

Lance,

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

http://www.vhdl.org/pub/ibis/summits/oct06b/wang.pdf

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.

Questions:

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
transport
| 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
EDA
| 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:
http://www.vhdl.org/pub/ibis/summits/mar06/muranyi2.pdf
See pg. 7 in the following presentation:
http://www.vhdl.org/pub/ibis/summits/feb06/westerhoff.pdf

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

Thanks,

Arpad
======================================================================
---------------------------------------------------------------------
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

---------------------------------------------------------------------
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: