[IBIS] RE: [ibis-macro] Your presentation at Asia Summit

From: Lance Wang <lwang_at_.....>
Date: Thu Nov 09 2006 - 12:22:46 PST
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@freelists.org
[mailto:ibis-macro-bounce@freelists.org] On Behalf Of Muranyi, Arpad
Sent: Thursday, November 09, 2006 1:28 PM
To: ibis@eda.org; ibis-macro@freelists.org
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@freelists.org
  Subject: unsubscribe


--------------------------------------------------------------------
|For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org
|with the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or e-mail a request to ibis-request@eda-stds.org.
|
|IBIS reflector archives exist under:
|
|  http://www.eda-stds.org/pub/ibis/email_archive/ Recent
|  http://www.eda-stds.org/pub/ibis/users_archive/ Recent
|  http://www.eda-stds.org/pub/ibis/email/         E-mail since 1993
Received on Thu Nov 9 12:22:51 2006

This archive was generated by hypermail 2.1.8 : Thu Nov 09 2006 - 12:23:19 PST