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