Re: ELEMENT interface question + off-topic

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