[SI-LIST] Re: Macromodeling
- From: "C. Kumar" <kumarchi@xxxxxxxxx>
- To: arpad.muranyi@xxxxxxxxx, si-list@xxxxxxxxxxxxx, owner-ibis@xxxxxxx
- Date: Thu, 24 Mar 2005 13:53:30 -0800 (PST)
actually my thinking is somewhat at varience.
1. I believe that the most attractive language is one
which should include powerful but minimal set of
syntax. From my limited knowledge of ams I tend to
view it as unduly complex for the task. I am
concerned that it will actually stand in the way of
compact modeling and slow down real advnaces. I fear
of "natural" tendency to bloat the models with all
kinds of unnecessary overheads as in the inclusion of
logic preprocessing circuits.
2. Spice is actually a very powerful language
precisely because of its limited constructs. It
provides connectivity information in the most basic,
abstract but elegant manner. That is why it is not a
huge task to go from a circuit schematic to a spice
description
3. The following fundamental additons will make it
unbeatable.
a. arbitrary locally defined parameters and
parameter passing - many commercial simulators already
have this
b. generalized equation element of the form
f(v,i, .....parametrs) = 0;
where v and i are voltage and current vectors.
all the spice elements including EFGH are a
variation of this general variety.
4. as we go into an era with even more serious analog
models (read network equation with node conservation
which spice is all about), I will be loathe to take on
another curve ball, which pretends to be high level
but not really but at the same time too complex for
network description. Such a development can only
obscure and deflect from real advances.
--- "Muranyi, Arpad" <arpad.muranyi@xxxxxxxxx> wrote:
> 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
=== message truncated ===
__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/
------------------------------------------------------------------
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:
