Re: [ng-spice] spice3f5 benchmark


To ng-spice@ieee.ing.uniroma1.it
From Reid van Melle <reid@ada-works.com>
Date Tue, 21 Mar 2000 12:44:31 -0600
Delivered-To mailing list ng-spice@ieee.ing.uniroma1.it
Mailing-List contact ng-spice-help@ieee.ing.uniroma1.it; run by ezmlm
Reply-To ng-spice@ieee.ing.uniroma1.it

> -1- you mention that the spice3f5 code is quite bad. Can you quantify this?
>     What about the kernel code: stamp generation, sparse matrix code, 
>analysis code?
>     Is this easy to structure and optimize these specific parts? 

I am not an expert when it comes to evaluating numerical algorithms.  I am
trusting that the people who wrote Spice put a lot more thought and effort 
into
these portions of the code than I ever could.  I mean "bad" from a software
point of view: structure of the code, programming practices, architecture ... 
There are numerous "crimes against software" committed in the source code.

> -2- It is nice to know that we are on the same wavelength with respect to 
>the 
>     wrapping of the simulator kernel. I also agree for 100% that python has 
>all
>     the features for the front and back-end. I MUST admit that 1/2 year ago 
>I
>     did not would have stated this, however, I have become much impressed 
>by python lately.
>     Python is simple and efficient and has modules for parsing, internet 
>interfacing,
>     plotting facilities, GUI and numerical analysis.

I agree that wrapping is a very nice way to go.  Script front ends are a lot
easier to start modifying and enhancing.  Once you develop a good C or C++
interface, you can use tools like SWIG to write wrapper routines for python,
TCL, or Perl.  You can then develop using a scripting language.  If a highly
efficient version is needed in the end (which the top-level usually does not
require), a C front end can be tacked on top of the same library interface.

> -3- I think it is in everybody's interest to seperate the kernel code from 
>the
>     from and back-end. This will allow many specialists to work on various 
>parts of
>     the simulator. Some people are interested in GUI and post-processing, 
>whereas
>     others are more interested in simulator issues. Personally I would 
>suggest that
>     the ng-spice team should draw up a specification of the kernel code 
>interface,
>     which could address:
>       - a minimal and efficient syntax/grammer for the input specification 
>(input string)
>       - address multiprocessing issues (for efficient monte carlo analysis, 
>sweep , ...)
>       - error reporting
>       - output vector structures
>     I think there is a synergy with your work/product. What are the view 
>points of the ng-spice team?

There was an effort made in the Berkeley version of Spice to have plug & play
front-ends.  However, it was based on C-style function pointers and I don't
know if any front ends (other than nutmeg) have ever been developed.  It would
be nice if the input specification divorced itself from Spice netlists.  A
circuit is really a graph structure which is how it is represented internally
in Spice.  Parsing a spice netlist is basically a conversion of a textual
version of the graph to a binary representation.  If there was a generic
circuit/graph building interface on Spice, then input circuits could be 
entered
directly from a schematic entry tool, from a standard Spice netlist, or an
XML-based format.

> -4- Maybe ng-spice should keep on supporting spice3f5, but parallel work 
>out a new kernel
>     code with a wel specified interface. The old spice3f5 could be improved 
>for memory
>     leaks and other small bugs without putting into much effort. 
>Personnally I think that the
>     ng-spice team allready made a very nice effort to structure the code 
>under autconf, which will
>     allow more users to install the code succesfully (it took me three days 
>to get spice3f5 running
>     under solaris, ngspice took only 1 hour!). Reid, could you help to 
>remove the memory leaks?

I agree that the ng-spice team has done excellent work to-date.  I certainly
understand the concerns and questions with regards to moving in new 
directions.
 It may be easier to use spice3f5 as a starting point and try to migrate
towards a new simulator:
- develop a library version of spice with a well-defined interface for
front-ends and back-ends
- break off pieces of the simulator into well-defined components.  It is
possible to migrate a C code base to a C++ code base by slowly breaking off
modules.

I would love to be involved in this, but I am somewhat constrained in how my
time can be spent by my company.  We are still in the process of determining 
if
we will continue to use/develop spice3f5 (requires us working under a BSD or
LGPL licence) or move to a commercial simulator.  I DO NOT work for a 
simulator
company; we simply use a simulator within our product.  Therefore, we have no
problem in sharing simulator code with the software community.

I could certainly share my memory-fixed spice code.  However, it would 
probably
be easier to add it into the current ng-spice build than integrate my code 
into
ng-spice.

                                        Reid van Melle

> I think that your 'pipe dream' is a very fascinating idea, because it could 
>help liberalize
> the simulator market!

I think I have to do a little more research.  I think there have been some
efforts to develop socket-level simulator interface, but I'm not sure exactly
where they got to.  It seems like it is easier to push a de-facto standard 
than
a real standard, which is basically what Berkeley spice did for the spice
netlist specification and model definitions.

                                Reid

Partial thread listing: