[SI-LIST] Re: Macromodeling
- From: Scott McMorrow <scott@xxxxxxxxxxxxx>
- To: kumarchi@xxxxxxxxx
- Date: Thu, 24 Mar 2005 17:12:38 -0500
Kumar
In that case, I would expect that you are an advocate of including some
your proposed additions to SPICE into the IBIS 4.1 Multi-Lingual
Extensions specification section.
regards,
scott
Scott McMorrow
Teraspeed Consulting Group LLC
121 North River Drive
Narragansett, RI 02882
(401) 284-1827 Business
(401) 284-1840 Fax
http://www.teraspeed.com
Teraspeed® is the registered service mark of
Teraspeed Consulting Group LLC
C. Kumar wrote:
>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
>
>
>
>
>
------------------------------------------------------------------
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: