Re: [Gnucap-devel] ELEMENT interface question

[al davis]

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".