Re: [ng-spice-devel] [ng-spice] ACS, model compiler, cross-post from gEDA list (fwd)


To ng-spice-devel@ieee.ing.uniroma1.it
From Steve Hamm <Steve.Hamm@motorola.com>
Date Fri, 8 Sep 2000 09:51:48 -0500 (CDT)
CC aldavis@ieee.org
Delivered-To mailing list ng-spice-devel@ieee.ing.uniroma1.it
In-Reply-To <Pine.LNX.3.96.1000908075931.8820D-100000@ieee.ing.uniroma1.it >
Mailing-List contact ng-spice-devel-help@ieee.ing.uniroma1.it; run by ezmlm
References <Pine.LNX.3.96.1000908075931.8820D-100000@ieee.ing.uniroma1.it >
Reply-To ng-spice-devel@ieee.ing.uniroma1.it


>> Another benefit of the model compiler is that using the same front
>> end and a different back end, it could generate code for a different
>> simulator with a completely different architecture, using the same
>> source.

This has been done, and it works. At AT+T, they had a model
development framework that used a description language and a compiler.
We have a compiler like this under development for internal use; it's
a bit crufty, but it works. But first, one needs a well-defined
interface between models and the simulator to make this work at all. I
haven't looked at the ng-spice code, but in SPICE3 there was too much
information about models scattered about the program.

One drawback to the compiled approach: Assuming that one uses an
automatic differentiation technique to generate the required jacobian
entries, the difference between a compiled description and a
hand-coded model can be 3x or worse, depending. So, one approach would
be to consider the compiler to be useful in model prototyping or for
quick functional porting of a model.

The proposed dynamic linking for ng-spice would also be a benefit
here. If done properly, all one would need to do to generate a new
model is to write the description, run it through the compiler, and
put the resulting sharable object in your simulator's path. That's
basically what we have internally.

>> With this in mind, I would like to ask an open question, directed
>> primarily at those involved with NG-SPICE:  Are you interested in
>> participating in this, by developing a back-end for my model compiler
>> that would generate NG-SPICE code from the same source?  You could
>> also influence the input language a bit, in hopes of making it more
>> simulator-neutral.  This would create a powerful tool for model
>> developers that goes way beyond what is available commercially.
>> Ultimately, I would like to make something like this become the
>> standard for model implementation, with compilers that generate
>> native code for all simulators that care to participate.

We use Verilog-A as our model prototyping language; I'd suggest that
it be considered as a possible language. Verilog-A, with a few
additions and some constructs avoided, can easily express any model
one might want to develop. 

[Another reason for using Verilog-A as a model prototyping language is
that it can be executed by simulators that implement Verilog-A, in
addition to the model compiler. Executable specifications are
good. But we have a Verilog-A implementation, so that helps here.]

---"Alan" == Alan Gillespie <alan.gillespie@analog.com> writes:

Alan> My first reaction was "do we really want LOTS of models". There's
Alan> already so many around that it's difficult to keep up to speed. But,
Alan> then I thought of what I've been doing to SPICE over the last few
Alan> years, and it's basically been trying to add compatibility with other
Alan> people's models to Berkeley Spice.

I see the main advantage of a model compiler in adding models for
strange stuff that nobody else wants: integrated accelerometers,
sensors, micromechanical stuff, new semiconductor structures. The
industry doesn't need yet another mosfet model, it just needs one good
one.

<snip again>
Alan> I had originally intended just a simpler C (or C++ if it's not too slow)
Alan> framework for adding models, but maybe a compiler would be more
Alan> general.

This isn't an either/or decision. Both a clean interface and a
compiler would be good, I think.

--Steve

Partial thread listing: