Re: [ng-spice-devel] Spice API


To ng-spice-devel@ieee.ing.uniroma1.it
From Paolo Nenzi <pnenzi@ieee.ing.uniroma1.it>
Date Tue, 4 Jul 2000 09:51:51 +0200 (CEST)
Delivered-To mailing list ng-spice-devel@ieee.ing.uniroma1.it
In-Reply-To <20000704000854.A16785@cgmd80028.chello.nl >
Mailing-List contact ng-spice-devel-help@ieee.ing.uniroma1.it; run by ezmlm
Reply-To ng-spice-devel@ieee.ing.uniroma1.it

On Tue, 4 Jul 2000, Arno W. Peters wrote:

> On Mon, Jul 03, 2000 at 08:32:20PM +0200, Paolo Nenzi wrote:

> Another part of the functionality is unique to Spice.  Loading a
> circuit file, starting an analysis, alter device parameters.  These
> are commands that typically don't appear in the nutmeg command list.

Ok, in loading a circuit file you include the parsing of a textual
netlist. But what about the output ? As you have seen, the analyses 
sources contain a lot of "front end functions" (SpBeginPlot and others).
How do you plan to deal whit these ? 

> This cleans up the code
> for the frontend considerably because the SIMULATOR define would no
> longer be necessary.

Yeah, and the not-very-good csh-like interface will be replaced.

> All these symbols come from elsewhere in the spice source.  Remove the
> helper functions, the calls to the X Window System and the libc
> functions and you will be left with an initial version of the Spice
> API.

OK!


> Once we have an API.  A nice test would be to write a wrapper for it
> in Python, for example, and recreate spice or nutmeg functionality in
> it.  
Sounds very good.

> > * What is the level of modularity you plan to achieve ?
> 
> This is not yet very clear in my head.  I can see at least two
> interfaces (API's): a library interface and a device interface.  The
> first is for application programmer that wish to incorporate spice
> functionality in their program.  The latter is for device
> manufacturers/modelers to have a clear-cut interface to the spice
> simulator.

I think that the original Berkeley's interface should be maintained, I do
not think that they will change device interface for us, at least not now.
I have started to experiment with dlopen yesterday night, and would ask
your idea for a couple of changes in the device interface:

* Spice now maintains an array of "known" devices, this should be turned
to a linked list (with the corresponding insert and remove functions).
During the netlist parsing INPtypeLook should be modified to search
locally if a device has already been loaded and linked into the list and, 
if negative, search in a given path. To achieve better modularity, we can
code a function DEVinspect(dir) called during initialization phase to
inspect the devices libraries path and fill a table with summary
description of available devices:

Table entry: NAME VERSION MODEL LEVEL BIND/UNBIND LIBRARY_NAME
ex:          BSIM3 3.1    NMOS   9     1          libbsim3v1.so.0.1

This will enable the netlist parser to see if a needed device in the 
dir and it is possible to DEVbind(library) it or it is necessary to
issue an error.

> It has become quite a long post.  I hope it brings some clarification.

Yes, now I have a cleared idea, my concern was what to consider front end,
simulato and post processor. I noticed that you had a clear idea (or
clearer than mine) and asked you. 

Thanks,
Paolo


Partial thread listing: