[SI-LIST] Re: Macromodeling
- From: "Muranyi, Arpad" <arpad.muranyi@xxxxxxxxx>
- To: <si-list@xxxxxxxxxxxxx>, <owner-ibis@xxxxxxx>
- Date: Thu, 24 Mar 2005 12:49:28 -0800
Todd, and all,
Excellent summary! In fact this is the best description I
have seen so far for the fundamental problem we have in IBIS.
"Both the building blocks AND
the structure are pre-defined."
The good news is that we did recognize this problem and
acted on it. That's why we have IBIS4.1 now. With the
new keywords [External Circuit], [Circuit Call] and [Node
Declarations] we can basically instantiate and define
building blocks and build structures as needed.
The problem I see now is that being so new it will take
some time before these capabilities will be widely used
and supported by tool vendors. And Chris' thread and
Don's proposal makes us painfully aware of the need,
RIGHT NOW. So what should we do?
Don's macromodeling proposal is an attempt to bridge over
this time gap for the immediate future. I can't help, but
I have some concerns. Readers, please feel free to comment,
or contradict on any of these points, because I am also
looking for answers as I am writing this.
1) The faster the macromodeling proposal is attempted to be
realized, the fewer features it will define. (Remember, the
EFGH elements have a very wide variety of syntax features, at
least in HSPICE). How useful is it going to be with a limited
set of capabilities? We already had a similar experience
when we worked on the IBIS-X (Al Davis SPICE) proposal.
2) On the other hand, if more features are implemented, it
may take too long to finish the specification for it to be
useful in the time frame it was intended to help.
3) If (and that is a big IF) we succeed in this step towards
basically standardizing some SPICE features, no matter how small
this first step is, I am pretty sure that there will be a flood
of requests towards standardizing the rest of SPICE. This in
itself may not be a bad idea if it were not for the same
limitations I mentioned in the thread Chris started. (SPICE
has the same problem as IBIS when it comes to adding new models
and equations to its primitives, they are all pre-defined, using
Todd's words). Of course, I have yet to see how the various SPICE
vendors would react to the idea of standardizing SPICE.
4) I am a fan of the AMS languages because it solves the problems
of IBIS as well as SPICE. Also, it can be used as if it was SPICE,
BUT IT CAN DO A LOT MORE. Because of that, I feel that ultimately
AMS will be the choice of modeling language in the long run.
However, I feel that Don's macromodeling proposal, if it succeeds,
will slow down and delay the acceptance of the AMS languages. Why
should we delay the inevitable? Why wouldn't we want to help
it by promoting it?
5) I agree, there are immediate needs TODAY for which AMS
solutions may not be available yet. However, as Don pointed
out, Cadence has done this macromodeling for years around their
IBIS2.1 primitive. It can also be done the same way in HSPICE
around their B-element. I am pretty sure Mentor and other
companies may have similar capabilities. Since workarounds
are available, the real question in my mind is: how much are
we benefiting by standardizing the workarounds? Is it worth
spending the time and energy to make this an official
specification while we could promote the acceptance of AMS
using the same energy?
6) I have another idea! Based on Todd's definition of what the
problem is with IBIS (pre-defined building blocks and structure),
and the fact that we have a solution for that in the new keywords
[External Circuit], [Circuit Call] and [Node Declarations], why
don't we write a few AMS primitives, such as the EFGH elements
and the B-element so that they could be macromodeled together
any whichever way, using the above keywords? This would provide
the same capability Don's proposal is suggesting without having
to change the IBIS specification at all! I have already posted
a B-element equivalent in VHDL-AMS on the IBIS web site a long
time ago, a Verilog-AMS equivalent of it is also available
(courtesy of Ron Vogelsong, Cadence) and I don't think it would
take too much effort to write up the EFGH element equivalents
in *-AMS either. (Any takers?)
Arpad
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx] =
On Behalf Of Todd Westerhoff (twesterh)
Sent: Thursday, March 24, 2005 8:48 AM
To: si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Macromodeling
I'm weighing in a bit late here, but I'm hoping I'll be able to =
underscore
the point Donald was trying to make with the original use of the term
"macromodeling".
Macromodeling to me, is nothing more than a syntax that allows me to =
combine
pre-existing elements (which are behavioral in their implementation)
arbitrarily. I can make whatever I want, as long as I use the building
blocks I already have.
The issue with IBIS is that we can't do that. Both the building blocks =
AND
the structure are pre-defined. You have a few opportunities to change
things, I grant you [Series Pin Map and such] ... but the structures =
are, by
and large, pre-defined.
Donald was making the case for adding some "building blocks" (controlled
sources and such) to IBIS, and then allowing a syntax that would allow =
those
building blocks to be combined freely by the model maker. He offered up
that Cadence had implemented the B-element in the SPECCTRAQuest =
simulation
engine years ago, and then handled each extension to IBIS since then =
using
this macromodeling technique.
Whether others agree or not - this makes good sense to me.
Todd.
Todd Westerhoff
High Speed Design Group Manager
Cisco Systems
1414 Massachusetts Ave - Boxboro, MA - 01719
email:twesterh@xxxxxxxxx
ph: 978-936-2149
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
or to administer your membership from a web page, go to:
//www.freelists.org/webpage/si-list
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List FAQ wiki page is located at:
http://si-list.org/wiki/wiki.pl?Si-List_FAQ
List technical documents are available at:
http://www.si-list.org
List archives are viewable at:
//www.freelists.org/archives/si-list
or at our remote archives:
http://groups.yahoo.com/group/si-list/messages
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
Other related posts:
