Re: [Gnucap-devel] ELEMENT interface question

[Felix Salfelder]

Hi Al.

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.

> > somefilter #(type=fir, coeffs=(1,2,3)) vcvs(a,b,c,d);
> 
> That's a device of type "somefilter".  It's name is "vcvs".

sorry, i wanted to instanciate a vcvs. whatever the syntax is.

> > should be possible/might already work in -uf (after some
> > set_parameter_* hacking).
> 
> What does the standard say?

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.

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

> With the ability to change languages, in general how do you deal 
> with features that are supported by one but not another?
> 
> Some examples ..
> 
> spice current controlled sources, in Verilog.

don't know how they are instanciated in verilog. if it's a device name
and some parameters, then i guess a sckt might do the trick.

> 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?

> VHDL ability to specify multiple "architecture" for single 
> "entity" .... but do that in Verilog.  Gnucap was designed to 
> support this, but long before VHDL-AMS existed.(see footnote)
> 
> The issue is not how to do it (it can be done) but how to 
> specify it within the constraints of a chosen source language.

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.

regards
felix