Re: [ng-spice] spice3f5 benchmark
Cadence cdsSpice, which started life as Harris Semiconductor's
SLICE, is rigged this way. The "kernel" is an ancient (pre-2g6)
Berkely SPICE, hacked with extensions, improved intrinsic
device models, hooks, etc. Layered onto it is a command
language that gives you things like the ability to make
variable- and function-based models, perform logic/math
operations on input and output data, maintain and run
with elaborate statistical process models, and plot out
data in many ways.
As an example, I have designed laser-trimmed analog circuits
using this language, which required me to run Monte Carlo
process/mismatch simulations, multiple times per process shot,
to find the trim point, save this trim point by process shot,
and then reuse it for exhaustive parametric performance
simulations (30 or so precision analog params). Huge runs,
practical only because the command language permitted me
to script, calculate, and do file I/O cleanly and easily.
Imagine doing that with manually entered SPICE headers? Ick.
The CAE guys roll their eyes and mumble about RATFOR when I prod
them about updating it. But it does have, I think, the nicest
wrapper language I've ever seen. Especially from the view of
a circuit designer, which I am. Saber/MAST might have more power,
but you have to really, really like writing code. SLICE was
a captive simulator written to the demands of a few hundred
IC designers over a span of 10 years, by guys who later
were hired into Cadence as vice presidents and directors.
As we talk about wrappers and such, I would really, really
like to see some involvement with the geda people. Al
(ACS Al) is asking for the same kind of help (basically
"wrapping" ACS, or at least bookending it with front-end
and backend tools). Two points here; first, if you're
going to try to "plug and play" with simulator sockets,
it would be nice to pick the other free development to be
your compatibility focus; second, the geda tool set is
(to me) several steps away from usability as a design
environment - and the first step is completion of a
simulator, a simulation environment that is useful in
an iterative circuit optimization and exhaustive circuit
verification process. To this point, simulator language
("wrapper") is key.
> > -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
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
Partial thread listing: