Re: [ng-spice-devel] Answer to MANU and Arno and design doc.
Paolo Nenzi wrote:
>
> 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".
Not very important - if we are not satisfied with it's speed, then we can
always consider rewriting the functions that we need and optimize them.
The important thing is to get a functionnal simulator quickly.
>
> 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.
I'm not really sure either. I have tried to look for a spice grammar on the
net, but there is apparently nothing. By contrast, i've found several VHDL or
verilog grammars, which tends to show that lex/bison are more useful with
nicely formatted inputs.
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 ?
I am a personnal friend of Daniel Veillard, member of the W3C and author of
libxml. He has often said that an xml netlist would be very useful to us.
I will try to see if he can write something about the advantages of xml
for us. However, I do know the xml is essentially an interchange format, not
really meant to be hacked by hand. The advantage is that xml is fast and
easy to parse (and libxml can be used for that).
>
> 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.
yep.
>
> 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.
OK, LyX and SGML output then.
>
> 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.
Sounds neat.
> 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.
This can all be found in GSL. The online HTML docs for GSL seem to suggest
that code written using it will be quite easy to read.
>
> Modified Nodal Analysis: Yes. Are there other interesting methods ?
yes : have a look at:
http://www.aplac.hut.fi/publications/ecctd-91-2/main.html
you can add it to the docs on the website. Add also:
http://www.iue.tuwien.ac.at:8000/diss/grasser/diss/diss.html
that one is VERY good!
>
> 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 ?
This is what most simulators do. They have a default algorithm, but it can
be changed by the user (under ELDO, you can use : '.options be' for
Backward-Euler
for example)
manu
Partial thread listing: