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

From: Muranyi, Arpad <arpad.muranyi_at_.....>
Date: Fri Nov 10 2006 - 13:59:47 PST
Ian,

And what is the poor customer going to do if he gets
an IBIS file from Intel, say for a memory controller,
that links to an (encrypted) HSPICE model, and he gets
another IBIS file from a memory chip vendor which links
to a TLsim model (that is incompatible with the HSPICE
controlled sources) and there is no simulator that can
simulate the two models together?

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

-----Original Message-----
From: Dodd, Ian [mailto:ian_dodd@mentor.com] 
Sent: Friday, November 10, 2006 1:51 PM
To: Muranyi, Arpad; ibis@eda.org; ibis-macro@freelists.org
Subject: RE: [ibis-macro] Re: Your presentation at Asia Summit

Arpad,

I would only be really happy if it were an encrypted Eldo model :-)

 ... Ok before you all flame me, I was only joking!

We have always tried to make IBIS vendor neutral.
In my opinion, if we decide to support parameter passing, it must
equally support all of the major SPICE (or SPICE like) simulators. That
includes HSPICE, Spectre, Eldo, Tlsim etc (my apologies if your favorite
commercial simulator is not here).

I don't see a difference as to whether the SPICE netlist is partially or
completely encrypted.
Is there something I have missed?

Ian 

-----Original Message-----
From: ibis-macro-bounce@freelists.org
[mailto:ibis-macro-bounce@freelists.org] On Behalf Of Muranyi, Arpad
Sent: Friday, November 10, 2006 2:32 PM
To: ibis@eda.org; ibis-macro@freelists.org
Subject: [ibis-macro] Re: Your presentation at Asia Summit

Ian, and Lance,

Neither one of you said anything on how you would go about this SPICE
support, and which SPICE?

Even if we say that on the interface level in IBIS, [External Model] and
[External Circuit], there is no need to know which SPICE language is
inside the external SPICE file, what happens if I made an IBIS file that
references as encrypted HSPICE model and distributed it to my customers?
Would Mentor and Cadence be happy?

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

-----Original Message-----
From: Dodd, Ian [mailto:ian_dodd@mentor.com]
Sent: Friday, November 10, 2006 1:14 PM
To: lwang@cadence.com; Muranyi, Arpad
Cc: ibis@eda.org; ibis-macro@freelists.org
Subject: RE: [ibis-macro] Re: Your presentation at Asia Summit

Lance,

I agree with the majority of your statements.
There is a need to better support SPICE macro-modeling.

I support giving the High Speed user the option to use either SPICE
macro-modeling or AMS.
As part of this I support parameter passing into SPICE models (macro or
otherwise).

I do very much disagree with your comment about needing to be a rich
company to afford to purchase AMS enabled tools. At least one of the big
three EDA vendors is presently offering a full VHDL-AMS option with all
of their SI tools. The charge for the additional AMS functionality is
around 15% of the SI product base price. 

Incidentally, let's not let marketing and the internal politics of EDA
companies get in the way of the user having the best tools. Many EDA
companies have developed AMS simulation technology. Those that have not,
can almost certainly license it from third parties. When safeguards are
put in place, so that tools intended for High Speed Analysis cannot be
used for IC design, the EDA vendor has the opportunity to set a very
aggressive price for AMS functionality.

I have been very careful not to try to use this as a marketing platform.
I hope you take my statements in the way they were intended: about
technology and its availability, not about selling a particular brand.
Note again that, with the exception of your comments about the price
charged for AMS, I agree with your initiative.

Ian Dodd
Mentor Graphics Inc.

-----Original Message-----
From: ibis-macro-bounce@freelists.org
[mailto:ibis-macro-bounce@freelists.org] On Behalf Of Lance Wang
Sent: Thursday, November 09, 2006 1:23 PM
To: arpad.muranyi@intel.com
Cc: ibis@eda.org; ibis-macro@freelists.org
Subject: [ibis-macro] Re: 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@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

---------------------------------------------------------------------
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
---------------------------------------------------------------------
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 Fri Nov 10 14:00:23 2006

This archive was generated by hypermail 2.1.8 : Fri Nov 10 2006 - 14:00:42 PST