Re: [ng-spice] Proposal for ngspice development in winter


To ng-spice@ieee.ing.uniroma1.it, "JWS RH" <jwsrh@hotmail.com>
From Al Davis <aldavis@ieee.org>
Date Fri, 2 Nov 2001 18:51:27 -0700
Delivered-To mailing list ng-spice@ieee.ing.uniroma1.it
In-Reply-To <F176Pf0t4Rek07kKPgR000076ea@hotmail.com >
Mailing-List contact ng-spice-help@ieee.ing.uniroma1.it; run by ezmlm
References <F176Pf0t4Rek07kKPgR000076ea@hotmail.com >
Reply-To ng-spice@ieee.ing.uniroma1.it

On Thursday 01 November 2001 08:20 am, JWS RH wrote:
> The biggest hole I perceive in ACS is its partial
> set of intrinsic models (device models). It has
> some MOS, diodes, but (last I looked) no BJTs, JFET
> or other odds & ends.

I agree.

Actually, there are some "other odds & ends" that go beyond Spice.  
There are things like nonlinear capacitors and some nonlinear 
elements that HSPICE has.  It even accepts HSPICE syntax for them, in 
addition to its native syntax.

The BJT will be there real soon.  I need it for my teaching this 
spring.

> So one very relevant activity, as I see it, would
> be translation of the Spice3 intrinsic models into
> functioning ACS models. Al has been talking about
> some sort of model compiler thing, that might make
> this quite tractable.

Yes.  The purpose of the model compiler is to make this easier.  My 
strategy was (is) to do the model compiler first, then the models.  
The delay in the first few, waiting for the model compiler, will be 
offset by how much easier it is thereafter.  The biggest problem with 
Spice models is untangling the spaghetti code.  You need to do this 
if you want to update the Spice algorithms, too.  The Spice model 
installation is too close to the architecture, which is why it has 
seen no advances in the algorithms in about 15 years.

> Another activity-of-value, more in line with user
> than programmer skills, would be to attack ACS
> with a fine-toothed comb and assess its readiness
> for the design task; 

Yes.

that is, how easy or difficult
> or broken are its command language, 

It is pretty basic, but not broken.  I think the best approach is to 
make a wrapper in some interpreted language, kind of like Emacs uses 
Lisp as an extension language.  The FSF would like it done in 
Lisp/Guile.  My personal preference is Python, but if someone wants 
to do it in a different language I will still say thank you.

> its graphical and list outputs, 

Graphical -- really bad.
List output, typical.  A little better than Spice.  It can feed some 
graphics tools directly.

> its ability to operate from
> input pipe into output pipe/file (key to integration
> w/ a higher-level design manager shell).

It does that well.  Spice doesn't.

> How
> accessible and standard are rawfile and mapfile
> formats (presuming some external results browser
> might be used)? 

It needs a Spice compatible rawfile output.  I don't particularly 
like that format, but it is used enough that it should be supported 
anyway.

> How large a circuit can run without
> choking? 

One circuit I use in the regression suite is over 20000 nodes.  Is 
that big enough?  I have seen benchmarks more than 10x faster than 
Spice for some large circuits.  I have seen 100x faster than some 
commercial simulators for some large circuits.  I have even seen it 
beat Epic's ultra-fast simulator at some benchmarks.  I am still 
working on this.  The algorithms for dealing with large circuits are 
unique and much more advanced than most other simulators.  The 
"implicit mixed-mode" simulation is far ahead of other simulators, 
and there is still lots of room for improvement.  Unfortunately, it 
isn't always faster.  I have some benchmarks that run slower than 
Spice, but they are small. 

The time step and convergence control is stricter than Spice.  I have 
seen benchmarks where Spice quietly gives you the wrong answer, and 
ACS honestly fails and gives a partial answer that is correct as far 
as it goes.  The down side of the stricter control is that it often 
takes more iterations or more time steps for the same problem.  In 
some big circuits, I have seen it take twice as many time steps and 
still run faster.

I would like to know more about what X-Spice offers.  I know the code 
models are primitive compared to ACS/GnuCap.  There appears to be 
advantages both ways on the mixed-mode side.  The ACS/GnuCap implicit 
mixed-mode does not require interface elements, and can take both 
logic and analog models of the same device and automatically 
determine which to use where and when.  X-Spice doesn't do this.  On 
the other hand, X-Spice appears to handle bus structures.  What is 
the performance of X-Spice as a digital simulator?


> Yet another activity-of-value would be a companion
> software, a simulation X-win menu tool which would
> semi-automate (extensibly) the simulation tasks and
> dependencies, and provide schematic-based waveform
> probing, device OP/MODEL, wire NV/TNV output,
> etc. This is not on the map yet for gEDA as far
> as I've seen but a quantum leap in circuit design
> efficiency especially when you get into circuits
> of significant size.

I suggested something like this (hot schematics) a few times on the 
gEDA list, and always got a response of "Yes! let's do it", but 
nothing has happened.

Look at the program "klogic".  It is a hot-schematic logic simulator.


Partial thread listing: