[SI-LIST] Re: Macromodeling
- From: "C. Kumar" <kumarchi@xxxxxxxxx>
- To: scott@xxxxxxxxxxxxx
- Date: Thu, 24 Mar 2005 14:41:52 -0800 (PST)
that will be a good thing.
but my pipe dream is the following
1. I have come to the realization behavioral modeling
is a task no ic desinger is willing to touch because
a. their product cycles are short, they are under
immense pressure and there is no dough in modeling
compared to what they are delivering
b. they put awful amount of effort quite rightly
in detailed analysis of their circuit schematic and
always short of time there.
2. so where does this leave us? Then why is my
idiotic behavirol model pipe dream creeping up?
The reason is ironically high speed compexity. Because
of high speed requirements more and more si is done
done inside the chip. Despite such complexity, these
circuits designs are varients of known architectures
discussed widely in relevent literature.
3. This means that these architectures could be
potentially identified, parameterized and captured in
behavior models. Te final form of this work can even
be a data sheets complete with schematic and golden
waveforms for a given set of parameters. Feasibility o
f such an endeavor should be an excellent news and
will greatly benefit from a standards body. Languages
etc become secondary implementation issues. As long
as golden waveforms are satisfied any language flavor
should be ok.
that is a very loooong shot but the only reasomable
opportunity, in my view.
--- Scott McMorrow <scott@xxxxxxxxxxxxx> wrote:
> 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
>
=== 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:
