RE: [ng-spice-devel] Ng-spice and SMP was: Re: [ng-spice-devel] Catching up


To <ng-spice-devel@ieee.ing.uniroma1.it>
From "Jon Engelbert" <jon@beigebag.com>
Date Thu, 15 Feb 2001 13:32:18 -0500
Delivered-To mailing list ng-spice-devel@ieee.ing.uniroma1.it
Importance Normal
In-Reply-To <0102111055210V.01056@hobbes >
Mailing-List contact ng-spice-devel-help@ieee.ing.uniroma1.it; run by ezmlm
Reply-To ng-spice-devel@ieee.ing.uniroma1.it

Here is a set of questions that I (Jon Engelbert) posed to Al Davis and his
responses.  I thought that the group would like to see it.

> 1) Memory Leaks: Berkeley Spice is full of memory leaks.  Years
> ago, when I tried tracking them down and fixing them, I was
> frustrated by the tangled web of pointers.  How is your code with
> respect to pointers and memory leaks?

Compile Spice with the warnings on, you will see lots of warnings
like "variable may be uninitialized", "unused", or similar symptoms
of sloppyness.  This indicates the type of lack of attention that
causes memory leaks.

I don't have good tools to check but I am not aware of any memory
leaks in normal use.  I did check a few years ago and found none.

There can be a leak sometimes when exceptions are thrown.  Since I am
still using the old setjmp/longjmp exception handling, occasionally
throwing an exception will cause a leak.  I have chosen not to worry
about this, for now, until the exception handler is converted to the
try/throw/catch style.


> 2) models:  Berkeley Spice is dead, but the mosfet modeling groups
> are alive and still churning out new spice model code.  Will it be
> easy to take their code, written for Spice, and port it into ACS?

It is a royal pain, to put it mildly.  It is a pain to move it to any
modern simulator.  Much of the code can just be moved over, but the
parsing is all Spice specific, and Spice parsing is a mess.  The
"load" functions do gather, limit, solve, scatter, all in one.  To
move on, they must be separated, which is hard considering such
spaghetti code.

It would be just as much work to modify Spice to support real mixed
mode or multi-rate.

Looking beyond Berkeley, models are often first coded in languages
like MAST and VHDL-AMS.  It is universally agreed that all you need
to do to make a model for Spice is a major obstacle to making models
available.  Try to find good Spice models for POWER semiconductors.
They are not available.  The researchers are intimidated by Spice...

Adding a model to ACS, directly, is a little easier, provided you are
starting from the equations.  Adding a model to ACS using the model
compiler is MUCH easier.  It takes a high level description and
generates simulator specific code, almost totally insulating the
modeler from simulator specifics.


> 3) Use by for-profit companies:

It all depends what you want to do.  As it stands now, ACS is all my
work, so I can grant whatever license I want.  If you don't ask, it
is GPL.  I believe the ng-spice group prefers GPL, but sticks to the
Berkeley license only because they inherited it.  With a group
effort, the entire group must agree to the licensing terms and
exceptions.  I would guess that all of those involved don't want to
do free development for Avanti or Cadence, and prefer a license that
protects the free-ness of the work.  I certainly feel that way.

Having said that, I believe a small company like yours could have a
more flexible business model, perhaps building a service company
around GPL software, sort of like Red Hat.

One point NOT to copy from Red Hat is that it should remain a private
company.  Getting stockholders involved will just sap resources and
profit away, that should all go to the developers.

Steve Rubin (Static Free Software) supposedly makes his living on
Free software.  (a layout and schematic program "Electric").


> 4) What do you see as the main work that needs to be done to ACS to
> catch up to Berkeley spice / xspice?

You also need to ask what work needs to be done to Spice/Xspice to
catch up to ACS, and what further work on both is needed moving
forward.

To answer your question ....

1. Untangling the models.
2. Pole-zero and distortion analysis.
3. Some boring algorithm enhancements.
4. Testing.

To move Spice forward ....

1. Untangling the models.
2. Re-architecture to for latency and dormancy support.
3. Efficiency on large linear and transmission line networks.


> 5) This is an aside and it's related to something I saw in an
> earlier message.  One strategy that is similar to saving all of the
> data, but not as burdensome on memory or on processor time (large
> memory
> allocations/reallocations can eat up a lot of time) is to store the
> output data to a database.  Database engines are reasonably fast in
> general, and this makes it possible for the back-end to grab just
> what the user wants. Anyway, just some food for thought for now.

ACS saves nothing.  It outputs as it goes, or lets the user select
what to save.  As circuits get bigger, this is the only logical
approach.

Using a database engine opens up more licensing issues.


Partial thread listing: