Answer to MANU and Arno and design doc.
Dear Manu and Arno,
This message is a reply for your messages. It's rather long.
GPL definitively. There is no problem in linking models which are not GLP:
the simulator must work without them to not infringe the GPL license. I
think that almost any model can be made a module, apart from resistors,
capacitors, sources, etc. In my opinion even theese devices can be made
modules, but they will always be loaded. Making them modules will
simplify the simulator to device insterface. Rewriting complex models
(BSIMs) is not a very good idea (in my opinion), they are continuosly
developed by Berkeley (BSIM3, BSIM3SOI).
GSL: it' is a good library, it does contain a lot of functionalities (at
least on paper) but I do not know anything about its "speed". I think
that for FFTs, we should use the FFTW (the fastest FFT code in the west,
as they state). GLS can be the base library and then we can substitute
new routines if we found something faster (in a later stage of
development). I have read something about stiff sistem in GSL, this make
it a good library for circuit simulation.
ANSI-C: YES! C++ is a good candidate for parser structures, but if we do
not have C++ programmers we have to use plain C.
Netlist format: sure, it is a standard.
Flex and Bison are interesting tools but modelcards and devices card line
are not very regular in their structure. I do not know if these tools are
useful in this case. By the way, if they can be used, they will make
easier the process of input parsing. Is there someone with good knowledge
of these tools ? The new simulator can use XML to load and save its files,
as base format, and import/export other formats (spice, hspice, etc.). I
do not know anything about XML but I have seen a lot things that can be
made with it. It can be used as base format for everithing in ng-spice
and use other formats as import/export options. Is there anyone that
knows something about XML ?
Simulator options: Yes, I agree with Manu to not necessarily use spice
options, but I would like that people can use this new simulator without
modifying their netlists too much. I am thinkg of "wrappers". We define a
set of "proprietary" options and then provide wrappers to interpret the
options of commercial simulators.
Interactive front-end: GNU Readline is good! I am thinking at a
(front-end)-(back-end) structure. The user sees a front-and and
communicate commands to a back-end via it. This can let the user choose
the front-end they prefer. It's like a DBMS structure, think at
Postgresql.
Documentation: Daniele Foci has dome some work on F.A.Q. to translate them
in SGML. I think that we can write everithing in SGML and the convert it
in HTML, TXT, TeXinfo, etc. DocBook is a good choice an LyX is a powerful
editor. I agree with Arno.
ON-Line docs: Yes, the simulator should give a minimal set of information,
help is a front and issue. The device field was intended for "one line
comments". But it can be used for that. Output formatting routines may
have to be modified a bit.
Autconf/Automake: as Arno wrote: goes without saying! I have seen two
other commands that seems interesting:
autoproject that simplify the creation of a source package for a new
program.
gengetopt that create a skeleton main.c.
Devices: Yes Arno, a register function is needed. There is a document on
type 2 Interface. I still do not remember where I found it.
I am writing about the IBM document in my previous message. I hope to find
the file, by the way, if you are interested in this field give a look at
the www.eigroup.org/cmc, the compact model council. CMC has an intersting
ftp site at ftp://ftp.sematech.org/pub/CMC.
Coding Standard: I agree with Manu. We can use the standard of gEDA. We
should also limit the maximum number of indirections, and write macros
for operations on vectors and matrices, to improve code comprehension.
Modified Nodal Analysis: Yes. Are there other interesting methods ?
Reinventing the wheel: Yes, techniques developed 20 years ago are still
valid. We may design a flexible structure so that whenever new techniques
appear and someone wants to port them, can do this without too much
troubles. We should also design it to allow the application of differents
algorithms, a sort of linked list of function pointers each pointing to
an "algorithms". The user can select the algorithm to use with
an option like: .USE FPH or .USE Newton-Raphson. What do you think about ?
Postprocessor: YES, we have to separate the simulator to the postprocessor
system. Again why not let users the postprocessor they want ? We can
design a way for the simulator to communicate with it's postprocessor.
Gwave can be one of the possible postprocessors.
Compatibility: Input/Output compatibility with existing simulators.
Name: well, this is the less urgent issue, by the way we can call it Mr.
Simulator, for now. ;-)
I would like to express some other ideas:
Multithreaded programming: We can design the new simulator in a
multithreaded fashion, exploiting parallelizable operations. It can speed
up the simulator on SMP machines and make it an interesting program (to
attract users, beta testers and programmers).
Before starting to write any code, we should prepare a "design doc".
Included in this message you will receive a ps file containing an
incomplete document.
Paolo
NG-SPICE_en.ps
Partial thread listing: