Re: [ng-spice-devel] new simulator: specs


To ng-spice <ng-spice-devel@ieee.ing.uniroma1.it>
From Arno <A.W.Peters@ieee.org>
Date Fri, 3 Dec 1999 22:07:31 +0100
Delivered-To mailing list ng-spice-devel@ieee.ing.uniroma1.it
In-Reply-To <3848712C.342FCFD4@wanadoo.fr >; from emmanuel.rouat@wanadoo.fr on Fri, Dec 03, 1999 at 08:41:00PM -0500
Mailing-List contact ng-spice-devel-help@ieee.ing.uniroma1.it; run by ezmlm
References <3848712C.342FCFD4@wanadoo.fr >
User-Agent Mutt/1.0i

On Fri, Dec 03, 1999 at 08:41:00PM -0500, Manu Rouat wrote:
> OK, supposing that we want to start to code a spice-compatible
> simulator from scratch up, here are a few guidelines that
> I propose:

See also the comments I wrote in an other thread.

> - license: GPL, but allow linking to non-GPL models (a la linux
> modules)

Can anybody tell how BSD with the non-commercial limitation interacts
with the GPL?

> --> this would allow us to reuse some spice code for complicated
> models perhaps.  but technically it could be difficult (is there a C
> coding expert among us?)

I am trying to convert the models et al. to shared libraries.  These
can be shared by a number of programs that use the same API for those
libraries.

> - use the GSL (GNU Scientific Library) for maths (despite the fact
> it is in an unfinished state it seems very usable)

> - code in ANSI-C
> 
> - spice compatible netlist format (but NOT necessarily for
> simulation options)

Also: use flex and bison to generate a parser.

> - use the GNU readline library for the interactive front-end (gives us 
> emacs-like keyboard shortcuts etc)

Very good idea.

> - docs written using LyX (or texinfo? LyX is WYSYWIG which makes it
> easier for contributions I think)

Perhaps directly produce DocBook SGML documentation.  LyX can produce
these.  DocBook is a widely used and well supported SGML style for
writing technical documentation.

> - on-line documentation should be just 'reminder' like ,eg: 'help VCCS'
> gives: 'VCCS: Voltage Controled Current Source - syntax: ....' and
> no more - more extensive docs available in HTML or postscript form

There is a field in the device structure with this information.  You
could use that.

> - autoconf/automake support

Goes without saying.

> - make addition of models really easy (the interface must be well
> thought out, I don't think that a compatibility with spice is
> mandatory, unless it turns out that the spice interface is well
> thought out ;-)

IMHO, the current devices interface only needs to be extended with a
register function to declare the symbols in the shared library to the
rest of the program.  I am not familiar with other parts of the
program.

> - the tool to view the output waves should be separate (dump nutmeg
> - Stephen Tells gwave program could be a good candidate)

Yes, but also make a command-line dump utility for debugging purposes
and for people refusing to install GTK.

> - several ouput waves formats (so that users can use the ones they
> already have!)

Interoperability is a good thing.  The more proprietary spices we can
replace, the lower the threshold for switching to ng-spice.

> - name of the simulator? all simulators that have 'spice' in them are really
> descendants of berkeley spice, if we build from scratch up it is not the 
>case
> for us ---> find an entirely different name?

We could pick a particular spice:

basilicum
chilli
cinnamon
curry
garlic
nutmeg
oregano
parseny
pepper

Partial thread listing: