[SI-LIST] Re: Macromodeling

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:
http://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:     
                http://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: