Re: [ng-spice] Proposal for ngspice development in winter
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:
- Re: [ng-spice] Proposal for ngspice development in winter, (continued)
- xxx,
John Hoelzel 17