[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnucap-devel] ELEMENT interface question
From: |
al davis |
Subject: |
Re: [Gnucap-devel] ELEMENT interface question |
Date: |
Tue, 20 Nov 2012 20:47:32 -0500 |
User-agent: |
KMail/1.13.5 (Linux/2.6.32-5-amd64; KDE/4.4.5; x86_64; ; ) |
On Tuesday 20 November 2012, Felix Salfelder wrote:
> On Tue, Nov 20, 2012 at 06:29:31PM -0500, al davis wrote:
> > It shouldn't be. The whole "obsolete_callback" mess is
> > incomplete work.
>
> ... which is not even needed.
It sort of is, or was. It is transitional code, intended for
removal. It is the old code wrapped to make it compatible with
the new interface, so the language plugins can be used without
losing functionality that previously existed. You would need to
look at the old code, pre-plugin, to really understand why it is
there.
So, really, "I agree", and that's why it is "obsolete".
bm files should read and write the parameters the same way as
everything else.
Sometimes transitional code looks far worse than what it comes
from. See "spice-wrapper.cc" for an example. It's really
awful, but how else to map the spice interface to the gnucap
interface?
> i'm fine with no standard for fir filter instanciation. if
> some verilog guy comes up with a name for device like that
> (or with a standard for names), its simple to add a subckt
> declaration wrapping my fancy ELEMENT+BM to that name.
It would be resistor+BM or capacitor+BM.
The modelgen diode is really implemented as a resistor+BM and
capacitor+BM. The modelgen mosfet Meyer capacitors ....
Actually, anything from modelgen.
The modelgen mosfets are subckts of primitives, all + BM (sort
of), where the parameters are filled in from the "do_tr" of the
containing subckt.
But the "bm" hierarchy is strictly y=f(x). The evaluators fill
into the master.
You could extend this concept, as the modelgen models do, with a
different set of bm type modules. Make your own base, derived
from COMMON_COMPONENT like EVAL_BM_BASE, or maybe even use
EVAL_BM_BASE.
You might want to look at d_poly_g.cc and d_poly_cap.cc, which
exist specifically to be used this way, and are used in the
modelgen mosfet models.
>
> > A lot can be done that the Verilog people didn't think
> > of. Not sure how to specify it within the scope of the
> > Verilog (or spice or spectre ..) language.
>
> (this is going to be off-topic...)
>
> subcircuits/modules? certainly not everything, but at least a
> lot could be done with them. for example i've come across
> something like S0 (a b c) switch ac_position=1 dc_position=2
> whatever_position=3. if in gnucap a subckt is declared using
> spice, because bm_cond-stuff works here, it can still be
> used to provide that switch for spectre.
That's what the Verilog-AMS people recommend for the spice
devices that can't be specified in Verilog.
> > spice-3 "B" device, not currently implemented in gnucap ..
> > irregular syntax.
>
> don't know about "B". but this of course is more involved.
> some option maybe, changing the behaviour of LANG_SPICE?
With irregular syntax, the LANG files need to do something to
handle specific devices. It's really bad design, but what else
can you do?
I want to keep the core clean, stable, and minimal, but plugins
can be anything you want. Devices, commands, most algorithms
are NOT considered to be part of core, with the intent of
encouraging experiments.
> to me, gnucap also serves as a platform for experiments. for
> most of these, language doesnt matter. if i can read in
> spectre netlists to do formal verification that's fine. if
> for example someone else uses gnucap to simulate electronic
> instruments to fill wavetables, she will mostly need
> features/models, not standard language.
>
> i doubt that anyone will take a language reference manual and
> implement that for gnucap. it might be helpful to maintain a
> set of plugins or libraries that enable some specific subset
> of language compatibility. for this, gnucap must become more
> modular. for end-users. thinking about gnucap-conf, or
> standard locations for include files, RPATH etc.
That is the goal. That is what I was working on in 2010 that
didn't get finished. "autoconf" was/is a big problem. My world
fell apart mid 2010 and is just now coming back together.
I still need to respond to your other post "bsim models
package".