On Tue, Nov 20, 2012 at 08:47:32PM -0500, al davis wrote: > bm files should read and write the parameters the same way as░ > everything else.
this is half-way done. at least the bm_ part. of course LANG_SPICE still needs to be adapted... i have abandoned spice before fixing that. > 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?░ avoiding spice wrapper is why we have ported the admsXml stuff to write plain gnucap devices... this way, i havent used the wrapper for anything :) > > 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. yes, that might be spice, where the idea comes from. a filter, switch, would be vcvs+BM. > 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. if i find some time, ill play with it. maybe. > That's what the Verilog-AMS people recommend for the spice░ > devices that can't be specified in Verilog. but theres nothing wrong about it, is there? > > > spice-3 "B" device, not currently implemented in gnucap ..░ > 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. i.e. install a spice3 plugin that provides LANG_SPICE3 : LANG_SPICE. > 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'm sorry about that 'falling apart'... :| in which way is autoconf a problem? in most (if not all) other cases, autotools is the solution. regards felix _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
