Re: [ng-spice-devel] Spice API


To ng-spice-devel@ieee.ing.uniroma1.it
From "Arno W. Peters" <a.w.peters@ieee.org>
Date Tue, 4 Jul 2000 22:22:40 +0200
Delivered-To mailing list ng-spice-devel@ieee.ing.uniroma1.it
In-Reply-To <Pine.LNX.3.96.1000704091950.3915A-100000@ieee.ing.uniroma1.it >; from pnenzi@ieee.ing.uniroma1.it on Tue, Jul 04, 2000 at 09:51:51AM +0200
Mailing-List contact ng-spice-devel-help@ieee.ing.uniroma1.it; run by ezmlm
References <20000704000854.A16785@cgmd80028.chello.nl > <Pine.LNX.3.96.1000704091950.3915A-100000@ieee.ing.uniroma1.it >
Reply-To ng-spice-devel@ieee.ing.uniroma1.it
User-Agent Mutt/1.2i

On Tue, Jul 04, 2000 at 09:51:51AM +0200, Paolo Nenzi wrote:

> On Tue, 4 Jul 2000, Arno W. Peters wrote:
> 
> > On Mon, Jul 03, 2000 at 08:32:20PM +0200, Paolo Nenzi wrote:
> >
> > > * 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:

Is there a specific header file that defines the API between spice and
the device models?

> * 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.

I would like to suggest you take it one step at a time.  The first
thing that needs to be done is to eliminate all references to the
global variables DEVices and DEVmaxnum and replace them with
functions.  Almost all uses of DEVices and DEVmaxnum were related to
walking the devices list.  Perhaps you could add a number of functions
to generalize this without exposing implementation detail.  Something
like:

  /* Returns the first device in the list, or NULL if the list is
     empty */
  SPICEDEV *first_device(void);

  /* Returns the next device on the list, or NULL if no more devices
     left. */
  SPICEDEV *next_device(SPICEDEV *current);

  /* Adds a device to the devices list. */
  int add_device(SPICEDEV *device);

  /* Returns the device with NAME, or NULL if no such device */
  SPICEDEV *find_device(char *name);

That could make the transition to a linked list, or any other
implementation much easier.

Make the necessary changes to the source code, get it to compile and
run the tests to see if nothing has broken.

Regards,
-- 
Arno

PGP signature


Partial thread listing: