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 _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
