[ng-spice-devel] Some ideas
This mail is dedicated to technical ideas for NGSpice
which come from previous discussions with Paolo.
On the parser the discussions say that a revision
of spice language is pursued by several people.
Despite the backward compatibility is required,
my opinion is that could lead up to the risk of confusion.
I mean that giving many *spice language compatibility
could be risky. Everybody knows that the existing
implementations are slightly different, while maintaining
the same kernel.
The idea to make ng-spice HSPICE compatible, is the most
important because it's the industry standard spice
in the sense that it is widely used in actual design cycles.
Now Hspice have been mentioned, it's important to point out
that its main contribution is the accuracy of models.
Therefor the compatibility with it should be thought merely at
two different level the less important of which is the parser.
Anyway I would go ahead, I pursue an in-depth revision
of spice language while trying to maintain the most common futures.
The main problems I believe exists with the language/parser are
+ netlist is not so easy understandable which lead to
trky problems when trying to discover design bugs
+ device in netlist may vary widely and this may
increase netlist confusion
+ little changes lead on to a complete parsing process
My ideas deal with what follows:
+ Simplifying: the netlist should describe the essential
information for the circuit, i.e. interconnections and
general parameters referred as global variables,
and should not be flat.
+ Structuring: as a program is structured in procedures
the netlist should grant the possibility to define a hierarchy,
mind you different files are not implied all circuit information
as well as spice directions my be on a single large text file
each sub-circuit could be referenced as an n-port device
in the father circuit.
+ Templating: essential in the structuring process a general
n-port device that could be either a sub-circuit or an actual device
could grant an even more clean netlist. Template should only
report interconnections and target device model if it refers to
an actual device.
+ Selective parsing: this is the most important point with regard to
circuit dimension and optimization time, the idea is simple
the parser should have as target a metafile, something like
a database in which only changed references or parameters should
actually modified. This metafile could be used even to avoid the netlist
generation and parsing process when the circuit is part of a wider
project in which a comprehensive design tool is used and this one
calls the spice analysis/optimization routines.
Something described above is done by frontends, but is not
implied in/by the netlist structure itself, indeed.
Last but not least to write the parser may be used lex and yacc
or their gnu implementations flex and bison, we can write
the parsing roles even introducing several sophisticated
syntactic checking and error recovery features
letting the tools generating the C code.
Models. New trends in circuit design include Nanometer Technology
and microwave design roles for digital circuits.
Is well known that spice models are almost inadequate for these
applications someone like direct silicon access suggest something
called technology files. The process these models are generated with
widely differ from spice one.
(see for an overview IEEE Spectrum June99 pp.77-82)
If we want to leave open the possibility to include such kind of
models the structuring and templating directions described above
could be required. I mean that making the netlist/parser independent
from the model nature is essential in order to have an open tool.
This concept could be improved in other circumstances to cover
the entire tool structure, I will give some detail later.
Also the usage of spice at microwave frequencies requires
several changes in the behavior of the tool.
There are spice developments in this fields (in which I'm
interested in) by several groups we could try to establish
some contacts and a joint program with them.
Now what I consider the tricky core of the technical discussion
if we are still up, it's late Saturday so I hope not to sleep :-)
Current supercomputing researches, btw mainly done in US
with several commercial and technical implications the first of
which is the new vBNS network for research and educational community,
are going in the directions of client server design methodologies.
This mean designing the circuit within a web interface
that could become our universal collaborative interface,
thought we are, in one way or another, rewriting the parser
I consider the web interface module a little effort at this stage.
Now circuit parsing, analysis and optimization could be done
in a concurrent collaborative client server environment,
both as simple as possible and as deep as required.
Several depth levels may be discovered, these two represent the
turning point of the application.
Different circuit blocks or sub-circuit can be easily
parallel processed on the same computer or over several systems;
studying the salability of spice methods and writing the code
in a widely structured modular and multithreaded way would lead
up to the possibility of a virtually infinite spread up to single
devices to single processor.
Paolo, who had the possibility to read carefully the original
spice documentation suggested as follow.
The matrix MNA (modified nodal anal....) is the merge of stamp matrix
which represent the single device. Each of those stamp matrix is
independent from the others (supposed that we are not considering
electromagnetic interactions and of course non microwave applications).
If the t time evaluation of the circuit depends on the one at t-1
than the devices may read its data and at the end of its process
a matrix sum may be performed for the time t.
This idea could work, but we require to answer several questions
covering the aspects of real life designs.
For instance how could be processed a circuit and its building blocks
when we work with electromagnetic interacting devices, or when we deal
with microwave frequencies. Which are the implication on models
and on overall circuit parameters.
Whatever direction we will take, i believe our rework should
start with modularization of code pointing out what could be
useful in order to easily add piece of code in the future,
mainly with regard to models diversity compatibility.
I looked with interest to the implementation of
Dynamic Shared Object in Apache (see http://www.apache.org/dso.html)
what I had in mind is a core which give you the possibility
to define extensions or include models with their own methods
without having to rebuild spice at all. Just using a run time
configuration script file. Nothing new, indeed.
Last but not least the testing methodology we should all apply
to evaluate the functionality of our work.
My opinion is that using the CVS database, we need to choose
some representative circuit trying to cover all the aspect
of a design. Despite a program could be compiled and run even
on several different computers this not imply that result
are correct at all. Also the processor architecture may lead to
differences due to real numbers implementation joint with iterations.
Having said that, we need to compare testing results all
together and with a reference that could be hspice.
BTW, if we will include new models like technology files
not covered by a reference tool the results should be tested
against actual realizations, in this case manufacture
or research centers collaboration as well as funds
would be required.
Bye now
franz
Partial thread listing:
- [ng-spice-devel] Some ideas, (continued)