[ibis-macro] Re: [IBIS] RE: Re: Your presentation at Asia Summit
- From: Bob Ross <bob@xxxxxxxxxxxxx>
- To: "Muranyi, Arpad" <arpad.muranyi@xxxxxxxxx>
- Date: Fri, 10 Nov 2006 21:23:01 -0800
Arapd and all:
Everybody has good points. The choice is between purity of the
Berkeley SPICE linkage versus practical and useful implementations.
I would support adding parameter passing for SPICE for several
reasons.
1. It is needed, useful, and is equivalent to the AMS and A(MS)
feature set.
2. By specifying it, we control the definition and interpretation
to a lower common subset that is already compatible with most
tools. For example, it would link to a .param statement within
"SPICE", and not to any other proprietary syntax.
3. I suspect that all vendors with "IBIS" linkages to SPICE are
already forced to add vendor-specific "IBIS" extensions for
parameter passing or use some other non-compliant and awkward
work-around superset implementation such as introducing
artificial nodes for parameter control.
4. Technically, the IBIS parameter syntax becomes a harmless no-op
in pure Berkeley SPICE.
Yes, this will promote vendor-specific SPICEs, but that is already
a required and dominant business reality. Ignoring this reality
is like winning the battle, but loosing the war. Without an IBIS
solution, vendors will continue the next immediate path of supporting
proprietary, self contained "kit" solutions and thereby slow the
adoption of IBIS for model portability - in all languages.
Pure Berkeley SPICE is too limited to be of value for complex
buffers. However, it still remains the lowest common denominator
level of SPICE for maximum portability for some practical situations.
So, I support some functional extensions beyond Berkeley SPICE including
passing parameters. I would try to limit the syntax and intepretation,
if possible, to the most popular methods for model portability.
That way, IBIS remains (mostly) vendor-neutral, but becomes a real
option for solving more problems with existing tools and methods.
Where needed and valuable, other language solutions then follow
more easily in future evolution plans.
Bob
Muranyi, Arpad wrote:
Ian,
I think your observation in the last paragraph of your message
is correct, but this is exactly the problem. Whether we make
this practice legal in IBIS or not is not the issue. The issue
is that these proprietary solutions only work with their corresponding
proprietary tools. IBIS was started and motivated exactly to
eliminate that situation. These requests you and Lance are talking
about is going in the exact opposite direction of the original
goal IBIS was invented for. We might as well get rid of IBIS
and all other efforts to have any industry standard modeling
languages (*-AMS) then...
Arpad
=====================================================================
-----Original Message-----
From: Dodd, Ian [mailto:ian_dodd@xxxxxxxxxx]
Sent: Friday, November 10, 2006 2:52 PM
To: Muranyi, Arpad; ibis@xxxxxxx; ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: Your presentation at Asia Summit
Arpad,
I want to support the customer to be provided with the best solutions.
I have said many times, that I believe AMS is the best technical
solution for full circuit simulation of the newer technologies.
Unfortunately, there are two barriers to AMS adoption: the first is
getting the majority of the EDA vendors to make their best technology
available in their SI tools, the second is the training of model
creators to use a new languages. Progress is being made on both these
fronts, but it is not as fast as I would like to see.
Switching from the AMS issue to SPICE:
I think we have all agreed that for us to try to create a standard for
SPICE is not a fruitful activity.
I do believe that SI tools should be able to pass parameters to SPICE
syntax sub-circuits that represent the behavior of IBIS components. The
SI tools that implement this feature will have to know the exact syntax
(and parameter data types) to be used for each simulator that is
supported.
Correct me if I am wrong, but I believe that at least two SI tool
vendors already have proprietary enhancements to allow parameters to be
passed to SPICE sub-circuits.
Ian
--------------------------------------------------------------------
|For help or to subscribe/unsubscribe, e-mail majordomo@xxxxxxxxxxxx
|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@xxxxxxxxxxxxx
|
|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
--
Bob Ross
Teraspeed Consulting Group LLC Teraspeed Labs
121 North River Drive 13610 SW Harness Lane
Narragansett, RI 02882 Beaverton, OR 97008
401-284-1827 503-430-1065
http://www.teraspeed.com 503-246-8048 Direct
bob@xxxxxxxxxxxxx
Teraspeed is a registered service mark of Teraspeed Consulting Group LLC
---------------------------------------------------------------------
IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
Other related posts:
