Re: modelgen & veriloga

[Felix Salfelder]

On Tue, Feb 25, 2020 at 03:01:04PM +0100, Vincent Pinon wrote:
> > The spice templates produce code that computes matrix stamps and current
> > contributions. These represent voltage controlled current sources, and
> > there is considerable overhead in the templates that relates to
> > simulator internals.

> Simulation speed rapidly matters, so we should directly go with something
> efficient

The secret of speed lies in the algorithm, not in early optimisations.
Gnucap implements an early accurate "fast spice" algorithm, and it's
the only free implementation of anything in that area. Other circuit
algorithms with other goals exist, but none of them does Verilog-AMS.

> Is there anything existing beyond an empty repository?

See Als response to your initial mail. I do not know about it.

> I had seen that yosis parses verilog with lex/yacc rules; however I have
> read that these tools also produce quite heavy code.

ADMS uses lex/yacc too. The bottleneck for us is simply not the parsing
speed. (Future) irregularities in the language can make it difficult to
formulate or tweak a grammar.  If the parser is separate from the data
structures -- then it does not really matter which parser you choose.

> Currently, lang_verilog doesn't use anything external? I'm balancing between
> not re-inventing and not over-engineering thing...

The gnucap core has no external dependencies (except readline, and dl).
This is intentional. Extensions are possible, and there is no limit to
the dependencies in extensions. There is a parser library included (CS,
perhaps "command stream"), it is used wherever input is parsed.

As it stands, lang_verilog parses structural verilog (i.e. netlists),
runs commands. it takes input from an interactive shell, and can be
swapped for a different language at any time. all language plugins share
the same internal representation of netlists, (e.g. for translation).
For modelgen-verilog, the multilanguage layer will only get into the
way, so i would start from mg_in.cc. but parts of lang_verilog will be
useful in mg_in.cc, and serve as example.

(that said, starting from mg_in.cc, will lead to a C++ program. If you
prefer Python, you should say so.)

> > - make a subcircuit with components in it, and deal with parameters.
> >    relatively straightforward, but helps with understanding gnucap.
> >    (carefully avoid MODEL_CARD)
> So we would go for a "subcircuit" architecture, not trying to plug directly
> into matrix? I understand it is more generic & flexible, is it as efficient?

yes. especially the matrix should be left alone. example. in spice, the
(adms) components write directly into a global matrix. the spice wrapper
holds back updates to the matrix. gnucap only computes the inverse of
that matrix locally, if and where the matrix has actually changed.
holding back is cheap, inverting a matrix is expensive.

> > - implement some Expression infrastructure (c.f. m_expression.h)
> >    we need some derivatives and dependency tracking. partly nontrivial.
> What do you mean with "dependency"?

variable dependency. models are written in terms of controlled sources.
an expression that is used to control a source may contain variables
that depend on the circuit state. Symbolic derivatives are required
for the iterative solver (as in Newton-Raphson). The model generator
needs to keep track of which derivatives are needed, and eject code
accordingly.

> > - eject components for @analog block. much like modelgen.  perhaps use
> >    or recycle the voltage and current sources from gnucap-adms.
> You mean pass over "subckt" instances?

modelgen components inherit from BASE_SUBCKT, and contain a bunch of
components that share some variables and some control block.
plain "subckt" aka "module" instances (d_subckt.cc) are also
BASE_SUBCKTs, but the components in such a subcircuit are only connected
through ports, not through equations in a model description.

A source instanciated in an analog block will be translated into a
source component, and the analog block will control what it does. so
yes, build some kind of "subckt" but with extras. Read modelgen or
just modelgen output.

> > - make it run faster, in many ways.
> 
> Faster than what? ADMS?

ADMS translates models. can speed it up, but that is boring. it's more
interesting to make the simulator faster.

> How?

Not an easy answer i'm afraid. There is a truckload of techniques, both
for making models more efficient and for faster convergence. some tricks
are intended and not complete. Very common: localise, parallelise,
distribute, all possible but not implemented. Different strategies work
well on different classes of circuits, picking the right strategy is a
problem on its own.

cheers
felix