ACS, model compiler
Paolo Nenzi included:
> The real plan is to complete the model compiler, then translate the
> model code to its input language. This is much easier than
> translating it directly to what the simulator wants, and it allows
> the simulator to evolve without the need to change all of the models.
> Then there could be LOTS of models.
My first reaction was "do we really want LOTS of models". There's
already so many around that it's difficult to keep up to speed. But,
then I thought of what I've been doing to SPICE over the last few
years, and it's basically been trying to add compatibility with other
people's models to Berkeley Spice.
The fact is that there are already too many models around, and we'll
never change that. It would be nice to be able to use as many as
possible with NG-SPICE, but adding models is a very tricky business.
I had already intended to push for a better structure for the models
in NG-SPICE, 'cos I had a helluva time trying to add the BJT level
2 model. (Which, due to my mistake, has not made it in to NG-SPICE
yet).
IMHO, one of HSPICE's strengths is the variety of models it
supports. But it's main weakness is the number of bugs in each
of those models. If we are going to support lots of models, we
definitely need a better structure for incorporating new models.
>
> 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.
>
If this part of the suggestion works, and was accepted by a variety
of different simulators, then it could partly solve another problem.
From what I've seen, the BSIM models from Berkeley are the only
freely available models that actually come with an implementation.
The others seem to come with either psuedo-code, a "DC solver",
or just a set of equations. If a "standard" model implementation
language could be defined, then the folk's who create these
models would have one less excuse for not releasing a real
implementation. There are lot's of other reasons why they don't
release a real implementation, though.
>
> 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.
>
If all Al's asking us to do is the back end for NG-SPICE, then I think
that it would be unreasonable not to at least bear it in mind while we're
trying to make model implementation easier. In fact, the more I think
about it, it sounds like Al must have been thinking along the lines
of simpler model implementation for a while. He's probably further
down that line than I am. Maybe we should tap his expertise.
In summary, then, I think it's worth talking to ACS more about this.
I had originally intended just a simpler C (or C++ if it's not too slow)
framework for adding models, but maybe a compiler would be more
general.
Cheers,
Alan
Partial thread listing:
- ACS, model compiler, (continued)