Re: [ng-spice-devel] Re: [ng-spice-frontends] how many?


To ng-spice-devel@ieee.ing.uniroma1.it, ng-spice-frontends@ieee.ing.uniroma1.it
From Al Davis <aldavis@ieee.org>
Date Sun, 19 Nov 2000 22:31:33 -0800
Delivered-To mailing list ng-spice-devel@ieee.ing.uniroma1.it
In-Reply-To <20001119224846.A26364@cgmd80028.chello.nl >
Mailing-List contact ng-spice-devel-help@ieee.ing.uniroma1.it; run by ezmlm
References <00111722530800.00661@localhost.localdomain> <20001119224846.A26364@cgmd80028.chello.nl >
Reply-To ng-spice-devel@ieee.ing.uniroma1.it

The idea of developing a front end separately is a good one.  Some of 
the commercial and in-house already do it this way.  I am aware of 
one that uses a lisp variant, and another that uses TCL.
------------------------------
On the language .....

It should be done in an interpreted language, so that users can write 
extensions in the language and use them immediately.  I think this is 
a requirement.

On choosing the language, consider what types of languages circuit 
designers are likely to know.  From this view, I think lisp is rather 
low on the list.  A language that looks more like C, Pascal, C++, 
Basic, Fortran, or whatever will be more familiar.

I have a personal preference for an object oriented language.  This 
combination seems to point to Incr-TCL or Python.  Neither of these 
is GPL, but both are open-source, free licenses that seem ok with me.

As a sideline ....  Some of the TCL libraries (including Incr-TCL and 
BLT) that you can download were developed by people in the group that 
did that simulator that uses TCL, and were done with analog 
simulation in mind.
-------------------------
Another decision -- client-server vs. direct linking. ............

The next decision is how to attach the scripting engine to the 
numeric engine.  

One approach is for the numeric part to be subroutines that are 
called by the scripting language (direct linking). This requires an 
interpreter for the scripting language to be linked with the numeric 
code.  By taking this approach, the issue of compatible licenses 
becomes critical.  It has the advantage that once compiled, the user 
does not need to explicitly have installed the interpreter language, 
but the disadvantage that someone building the program will need to 
be able to build the interpreter, too.

The other approach is a client-server model.  In this case, the front 
end and numeric engine are completely separate executables.  They 
could communicate through sockets, pipes, files, or whatever.  This 
one is my preference.  The engine can be pure, in the sense that it 
has nothing linked from the interpreter.  This would relieve some of 
the license stress, and would make it so the same engine could be 
used with several different front ends.  It also makes it more 
portable.

The idea of having multiple front ends could be more important that 
it seems at first.  There could be a few legacy front ends.  One that 
is Spice2g6 compatible, one Spice3f4 compatible, one that mimics 
HSpice, one that mimics PSpice.  Personally, I really dislike the 
Spice3 user interface.  These legacy front ends would all be variants 
of the same thing, written in the same scripting language.  Then 
there is the REAL one, with all the features, interactive plotting, 
postprocessing goodies, etc.
----------------------

The next question is how deep into the algorithms should the 
scripting language go.  One thought is to pass on rather high level 
commands, and have the compiled code engine fill in the details.  
Another thought is to try to move as much to the script (interpreted) 
language as possible.  Example: which side is transient step size 
control on?  In that commercial one that uses TCL, it is on the TCL 
side.  Which side is the netlist parsing on?  In this case, for speed 
and maintainability, it probably should be on the compiled side.

In general, I think it is best to have as much as possible on the 
interpreted side.

--------------------

I think licensing is the least of the worries.  The engine will need 
some redesign to accomodate this approach.  ACS will need a little, 
which will be small considering the total.  For the client-server 
approach, it is very little.  For the direct link approach, a bit 
more, basically making a linkable library.  I may be a bit prejudiced 
here, but I think Spice would need quite a bit more rework, for 
either approach.

I have deliberately avoided any work on a front end for ACS, in hopes 
that somebody might take the time to do it right.

al.

Partial thread listing: