Re: [ng-spice] spice3f5 benchmark
> -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:
- Re: [ng-spice] spice3f5 benchmark, (continued)