Where does the spice effort lie?

Hi, I was wondering if anyone can help me figure out where the "effort"
in a given Spice implementation lies, specifically 3fg. For example,
I'm wondering how much total % effort (starting from knowing KCL and
KVL) over the past 25 years was due to:

1. Figuring out newer and better device models on paper
2. Figuring out new simulation, integration, and convergence
techniques
3. Implementing (1) with (2)
4. Implementing linear stuff
5. Defining application-level stuff (netlist format, sub-circuit
semantics, etc.)
6. Implementing application-level stuff like (5), parsers, error
messages, and post-processing tools.
7. Other overhead (making it available to the public, documentation,
etc.)

How much effort do third party spice vendors like EWB, Pspice, Cadence,
HSPICE, etc., have to expend to modify 3fg to suit their needs?

In other words, if I have pre-developed device models on paper,
pre-developed simulation algorithms to work from, and a decent parser,
how hard is it to re-implement the actual equations? I'd like to
"re-do" spice to be a modern 21st century app, and get away from this
batch-mode fundamentally-text-based nonsense... something realtimeish
like EWB (haven't used that in ~10 years), but more geared for
chip-level design, not board level, and without the patronizing "bench
equipment" gear. I'd like to tighten up the simulate-tweak-simulate
loop with something that feels more like turning knobs or building
legos to get what you want, and to be able to do things like point at a
node and get impedance and/or capacitance or figure out the current
through a net on the page (not through a pin, since that's not how "we"
think as engineers) and without adding a fake voltage source to capture
the current. I'd also like to be able to parallelize the thing so it
can run on a multi-processor machine or on multiple machines on the
network. I know it's been done before (Sandia Labs' Xyce for example),
but I'd also like for this to be windows based and user friendly...so
far I've never seen parallel-processing apps for Windoze.

Any comments (aside from it's too hard?)
thanks
Michael

 

[Kevin Aylward]

63q2o4i02@sneakemail.com wrote:

Hi, I was wondering if anyone can help me figure out where the
"effort" in a given Spice implementation lies, specifically 3fg. For
example, I'm wondering how much total % effort (starting from knowing
KCL and KVL) over the past 25 years was due to:

1. Figuring out newer and better device models on paper
2. Figuring out new simulation, integration, and convergence
techniques
3. Implementing (1) with (2)
4. Implementing linear stuff
5. Defining application-level stuff (netlist format, sub-circuit
semantics, etc.)
6. Implementing application-level stuff like (5), parsers, error
messages, and post-processing tools.
7. Other overhead (making it available to the public, documentation,
etc.)

Yes.

How much effort do third party spice vendors like EWB, Pspice,
Cadence, HSPICE, etc., have to expend to modify 3fg to suit their
needs?

Yes.

In other words, if I have pre-developed device models on paper,
pre-developed simulation algorithms to work from, and a decent parser,
how hard is it to re-implement the actual equations? I'd like to
"re-do" spice to be a modern 21st century app, and get away from this
batch-mode fundamentally-text-based nonsense... something realtimeish
like EWB (haven't used that in ~10 years),

Err...there are about 20+ Spice vendors, none of which are
"fundamentally text based". All modern Spices are GUI based. No one
needs to know text input anymore, and its been like that for at least
the last 10 years.

but more geared for
chip-level design, not board level, and without the patronizing "bench
equipment" gear.

I agree, the bench test gear is pretty lame.

I'd like to tighten up the simulate-tweak-simulate
loop with something that feels more like turning knobs or building
legos to get what you want, and to be able to do things like point at
a node and get impedance and/or capacitance or figure out the current
through a net on the page (not through a pin, since that's not how
"we" think as engineers)

Actually, I have been an analogue engineer for er.. some time, and
probing pins is far more useful. Probing wires is a tad problematic to
implement in spice, and not worth the effort, imo.

and without adding a fake voltage source to
capture the current.

Err.. already done. There are indeed GUI spices that probe all pin
currents without having to place ammeters. Click on (on move test point
to) pin, wire and device to plot current, volatage and power is
available in the better spices.

I'd also like to be able to parallelize the
thing so it can run on a multi-processor machine or on multiple
machines on the network. I know it's been done before (Sandia Labs'
Xyce for example), but I'd also like for this to be windows based and
user friendly...so far I've never seen parallel-processing apps for
Windoze.

Do you have 20 years to spare?

Any comments (aside from it's too hard?)
thanks
Michael

Its not worth the effort mate. Spice is a mature product. I get the
felling that you aint actualy googled and found out whats actualy out
there today.

Kevin Aylward
431infoEXTRACT@anasoft.co.uk
http://www.anasoft.co.uk
SuperSpice, a very affordable Mixed-Mode
Windows Simulator with Schematic Capture,
Waveform Display, FFT's and Filter Design.

 

[Stuart Brorson]

Kevin Aylward <see_website@anasoft.co.uk> wrote:
: 63q2o4i02@sneakemail.com wrote:
:> In other words, if I have pre-developed device models on paper,
:> pre-developed simulation algorithms to work from, and a decent parser,
:> how hard is it to re-implement the actual equations? I'd like to
:> "re-do" spice to be a modern 21st century app, and get away from this
:> batch-mode fundamentally-text-based nonsense... something realtimeish
:> like EWB (haven't used that in ~10 years),

Why don't you channel your efforts into improving some analog
simulators which already exist. The cannonical open-source SPICE
simulator is ngspice:

http://ngspice.sourceforge.net/

It is under active (albeit slow) development. New developers with
constructive contributions are always welcome there.

There is also gnucap, which is very close to what you are interested
in -- a modernized analog simulator using up-to-date ideas about
language, algorithms, capabilities, etc:

http://www.gnucap.org/

It is also under active (but slow) development. Click on "development
releases" to get the latest tarball. The main developer is an EE
Prof, and he is very interested in collaborators. I have seen gnucap
used in a couple of graduate school simulator projects.

:> Any comments (aside from it's too hard?)

: Its not worth the effort mate. Spice is a mature product. I get the
: felling that you aint actualy googled and found out whats actualy out
: there today.

*chuckle*

Kev's right. I also recommend you Google around for a while and see
what's going on in the world of open-source EDA. You'd be better off
getting involved in an existing project, rather than starting yet
another soon-to-die simulator project. Another source of open-source
EDA news is OpenCollector:

http://www.opencollector.org/

Check it out.

Stuart

 

Actually I've been involved and/or interested in analog sim for ~6-7
years at least (since grad school) and googled around quite a bit the
past several months and years sporadically,specifically looking for
answers to my frustrations, and my conclusion is that the various spice
implementations look pretty much the same from a what's-under-the-hood
viewpoint, modulo syntax, function definitions, and other
"application-level" things.

What I mean by "text based" is that although there is a GUI front end,
you can still "feel" that it's "really" writing up a text file for you
in the background and calling spice to open it up and run the
simulation. This is what I mean by closing up the design loop. I'd
like the gui stuff to translate directly into the proper data
structures ready for simulation. This would allow things like global
and/or device parameters and such to be available in something like a
properties window. By having this stuff available *outside* the "spice
engine" you could use some scripting language to guide your
simulations. I'm under the impression there are already languages for
that (nutmeg? -- I haven't really looked at that aspect), but it'd be
nice to be able to hook it into python or something, or to use the
equation solving ability in other applications like FEA.

Your comment about it being inconvenient or too diffiult to probe
current except on a pin is exactly my point. The designer has to bend
his thinking to the implementation rather than the other way around.
How many circuit classses draw a current arrow on a pin rather than on
a wire? I admit this is a user-interface problem not a simulator
problem, but it stems from the simulator thinking a certain way, which
bubbles up to the user and presents itself unnaturally.

Also, from the main spices I've used (pspice, cadence virtuoso I think,
Tina, berkeley), you're generally limited in the variations you can run
of any given simulation (eg AC), so that if you have a suite of AC
parameters you want to test out, you have to change it manually.
Actually cadence allows you to have different setups, but it's clumsy
IMO.

I'm really interested in something interactive, which allows you to
modify, for example, the range on an AC plot, zoom in, etc., and the
simulator will recompute what it needs immediately, or if you want to
change the W/L ratio on something, it'll go. There is so much overhead
in setting up the simulation after netlisting it, that for small
exploratory/curiosity/educational circuits you spend most of your time
preparing, and very little time simulating. It would be better if the
matrix were set up with each topology change, and the parameters filled
in realtime, so solving the thing really is the only thing you're
doing, not whatever other overhead there is in opening a (hidden) text
file someplace and going through it all each time you want to try
something.

Anyway, people write equation solvers all the time in academia.
Without entering a PhD program to find out, my original question
remains: how hard is it to implement and solve any given PDE matrix,
relative to all the other stuff that needs to happen for a real
application to work? It'd be nice to have the same engine solving not
only your circuit equation, but as a field-solver for things like PN
junctions/gates/silicon, EM effects, and mechanical FEA sims.

Thank you
Michael

 

And yes, gnucap looks interesting. I'll take a closer look...

 

[Sven Wilhelmsson]

63q2o4i02@sneakemail.com wrote:

And yes, gnucap looks interesting. I'll take a closer look...

Yes, that my opinion, too. Gnucap allows you to do more probing than
ngspice and spice-opus, I believe. It may not be as mature, but still
useful. In most cases use Gnucap as a backend to my own sch-capture
program, where I set up the simulation control parameters in "clickable
simcon symbols".

Screenshot at
<http://w1.318.comhem.se/~u31829222/index.html>

--
Sven Wilhelmsson
http://home.swipnet.se/swi

 

[Kevin Aylward]

63q2o4i02@sneakemail.com wrote:

Actually I've been involved and/or interested in analog sim for ~6-7
years at least (since grad school) and googled around quite a bit the
past several months and years sporadically,specifically looking for
answers to my frustrations, and my conclusion is that the various
spice implementations look pretty much the same from a
what's-under-the-hood viewpoint, modulo syntax, function definitions,
and other "application-level" things.

What I mean by "text based" is that although there is a GUI front end,
you can still "feel" that it's "really" writing up a text file for you
in the background and calling spice to open it up and run the
simulation. This is what I mean by closing up the design loop. I'd
like the gui stuff to translate directly into the proper data
structures ready for simulation.

Text files are quite usefull and powerfull as an interface between
things.

This would allow things like global
and/or device parameters and such to be available in something like a
properties window.
By having this stuff available *outside* the
"spice engine" you could use some scripting language to guide your
simulations.

I thought you didn't like text files?

I'm under the impression there are already languages for
that (nutmeg? -- I haven't really looked at that aspect), but it'd be
nice to be able to hook it into python or something, or to use the
equation solving ability in other applications like FEA.

Your comment about it being inconvenient or too diffiult to probe
current except on a pin is exactly my point. The designer has to bend
his thinking to the implementation rather than the other way around.

Not really, or not much. Been an analogue designer for ...well..some
time.. I have never seen this as an issue in the slightest.

How many circuit classses draw a current arrow on a pin rather than on
a wire? I admit this is a user-interface problem not a simulator
problem, but it stems from the simulator thinking a certain way, which
bubbles up to the user and presents itself unnaturally.

Whats "natual"? Whats common sense?

Also, from the main spices I've used (pspice, cadence virtuoso I
think, Tina, berkeley), you're generally limited in the variations
you can run of any given simulation (eg AC), so that if you have a
suite of AC parameters you want to test out, you have to change it
manually. Actually cadence allows you to have different setups, but
it's clumsy IMO.

Again, you could have a better look at the other simulaters, hint
SuperSpice

So, the sell, in SS you can automatically run ac, tran, dc runs all at
once with any number of components automatically varied. It even does
Worst Case models all with button checks.

In the GUI you can set up which set of r,c, l etc, over which values and
all combinations of those values. For more control you can make a
simple, yes, text (Rerun) file that lists what component has what value.

After the runs, you can even get reports of max/min rise fall times etc,
all without a line of script.

I'm really interested in something interactive, which allows you to
modify, for example, the range on an AC plot, zoom in, etc., and the
simulator will recompute what it needs immediately,

Many already do that, e.g. SS.

or if you want to
change the W/L ratio on something, it'll go.

A no brainer. In SuperSpice, you can even change several transisters W/L
at once from the GUI.

There is so much
overhead in setting up the simulation after netlisting it, that for
small exploratory/curiosity/educational circuits you spend most of
your time preparing, and very little time simulating.

I dont follow you here at all. The setup time before sims is usally
minimal. I have been doing it in SS for 40 hours/week for, well again,
some time now...

It would be
better if the matrix were set up with each topology change, and the
parameters filled in realtime, so solving the thing really is the
only thing you're doing, not whatever other overhead there is in
opening a (hidden) text file someplace and going through it all each
time you want to try something.

Overhead time like this is usually minimal if your doing *real*
pro-sims.

Anyway, people write equation solvers all the time in academia.
Without entering a PhD program to find out, my original question
remains: how hard is it to implement and solve any given PDE matrix,
relative to all the other stuff that needs to happen for a real
application to work?

Its very hard, imo. The other stuff is trivial (excepting the device
equations), even if it is 100k lines of code.

Kevin Aylward
431infoEXTRACT@anasoft.co.uk
http://www.anasoft.co.uk
SuperSpice, a very affordable Mixed-Mode
Windows Simulator with Schematic Capture,
Waveform Display, FFT's and Filter Design.

 

[Joel Kolstad]

"Kevin Aylward" <see_website@anasoft.co.uk> wrote in message
news:w8pKf.26592$DM.10270@fe3.news.blueyonder.co.uk...

Its very hard, imo. The other stuff is trivial (excepting the device
equations), even if it is 100k lines of code.

Having taken a course in circuit simulator design, I'd like to concur with
Kevin's assessment here. Towards the end of the course, what became clear is
that while, sure, it's not particularly difficult at all to get transient
analysis working with "nice" circuits (everyone in the class wrote their own,
and getting .tran working was already a noticeable step up in difficulty from
getting .op/.dc/.ac working) , building a highly robust simulator that can
almost always get its initial operating point set correctly and then continue
time-stepping without underflowing the step is a "hard" problem where at least
as much of the solution if not more is all sorts of bizarre little "tweaks"
and heuristics here and there in the code as it is anything that can be
codified and written up in a journal paper (although those are quite important
too!).

Personally I like SIMetrix -- it seldom has convergence problems. Catena
acquired them (Newbury Tech) a few years back and jacked up the price
(arguably to a level closer to the competition, so I guess I can't really
blame them), although you can also find it buried without various CAD tools
such as Pulsonix.

---Joel Kolstad

 

Text files are quite usefull and powerfull as an interface between
things.

Yeah, I know... it's just the ancient syntax smells of 1970s and I
don't like being reminded all the time there's text going on in the
background.

"spice engine" you could use some scripting language to guide your
simulations.

I thought you didn't like text files?

True!! But sometimes they can be useful... Like I said, I don't like
being reminded of it. If I can get away without scripting something,
then great. Anyway, I think with something like python you could write
the gui/whatever *and* have the scripting language be the same
language. Just the simulator itself can be in C or whatever so it's
fast.

Random question: are there external hardware accelerators for *analog*
simulations? I know they exist for digital, but I haven't seen any for
analog.

problem, but it stems from the simulator thinking a certain way, which
bubbles up to the user and presents itself unnaturally.

Whats "natual"? Whats common sense?

Yes that's very subjective. People think about circuits differently.
Personally, I'd like to see glowing/fading effects and vertical lines
for each voltage on the circuit, so the total height of the line is the
total Vdd and is also the height of the schematic. I'd also like to
see tactile feedback or something knob-ish, so I can associate a finger
movement or feleing to a visual or even audio cue. For learning a new
circuit or playing with ideas, it adds another dimension of experience,
rather than just (boring) plots on a page.

Again, you could have a better look at the other simulaters, hint
SuperSpice

Ok, I'll take a look.

After the runs, you can even get reports of max/min rise fall times etc,
all without a line of script.

A no brainer. In SuperSpice, you can even change several transisters W/L
at once from the GUI.

cool.

There is so much
overhead in setting up the simulation after netlisting it, that for
small exploratory/curiosity/educational circuits you spend most of
your time preparing, and very little time simulating.

I dont follow you here at all. The setup time before sims is usally
minimal. I have been doing it in SS for 40 hours/week for, well again,
some time now...

Overhead time like this is usually minimal if you're doing *real*
pro-sims.

I gues I'm thinking of pspice, where the window pops up, annoying stuff
happens, and eventually you see that of the ~1s it took to display the
new window + results, maybe 1/2th of that was the simulation. Yes, I'm
talking about tiny circuits for DC stuff. Maybe it's my short
attention span, but most of my time spent doing circuits is verifying
"small" ideas. I actually worked at a real san jose company with job
titled analog designer, but it was a shit job and I didn't get to do
anything really too interesting, given that it was my first
post-grad-school job, before I got laid off. I did a sample-and-hold
using HSPICE and some POS schematic entry and layout tools, all the
time wondering why are they paying thousdands of $ for a bullshit
separate schematic tool and simulator, when there is so much
"shareware" style tools that allegedly accomplish the same thing? I
was told HSPICE has really good convergence... well, I still had plenty
of trouble getting things to work... and of course it was all unix...
Anyway, I became horribly embittered about the EDA world -- either
tools were low cost and shit, or high cost and shit. Finally we moved
to Cadence, which was waaay better, but still tedious and clumsy...
it's like you could feel the geologic strata of 20 years of software
all clunking along; some of the interface was written in java, buttons
were different sizes, menu options that lead nowhere, infinite typing
in of library names, people talking about the "database", non-obvious
options, useless "help" system, infinite license problems, postscript
"plotting" (as opposed to this century's concept of "printing" that
never works the first time (zoom, pan, etc., are always f**ed up
without experimenting, and who's ever heard of print preview in the
unix world?)... all for 10's of 1000's of $... Anyaway at that time I
did a bandgap and current references, which was pretty cool but the
only thing I was really doing was sweeping temperature and doing
stability analysis... but a lot of the design was things like "if the
current here goes up then the voltage here goes down, which means the
feeback point must be here... uh, no, here!"... which leads me to want
to be able to see stuff happening in response to my physiological
movements. Seeing plots is great for some things, but not always the
best way to intuit what's going on.

So this, plus some other previous experience in the "real" world with
Mentor Graphics while working in Beaverton at a Big Chip Company, got
me really pissed off at industry-grade tools. Why do they all suck?
Sure, they do the "big" jobs, but all the little details that make
programs fun to use were missing. They sucked the life out of being a
geek. So anyway forever I've been wanting to single-handedly rewrite
the world of EDA with my own ideas, and instead of companies paying
$thousands for it, they could pay me $thousdands-n, where n is small.
I have thoughts of interactive GUIs with audio feedback and possibly
tactile input (such as MIDI knobs), with actually nice graphics (screw
crosshatching! this machine has 32 bit color! and a kick-ass 3d
graphics card. Let's use it! Too bad xwindows can't support the 21st
century...), and useful help systems, realtime interactive stuff for
small circuits, and hardware acceleration (still gotta figure that one
out). I figure the only way to get away from what everyone else has
already done is to start from scratch as much as possible and not let
everyone else's ideas infect my mind. Ok, so you have equations and
models and a general means of setting up and calculating matrices...
that's the inner core part that probably won't be much different. But
everything else needs a major dot-com style interface overhaul. Of
course the real stuff is the backend extraction, verification,
syntheses, timing, bla bla. I'd hire real phd people for that I
suppose... with all the millions I'd make from my killer interface.

Anyway, that's my rant.

thanks for reading

BTW, is anyone you know hiring an anolog designer in the northwest USA?

Michael

 

[Joel Kolstad]

"Charlie Edmondson" <edmondson@ieee.org> wrote in message
news:43fb4e52$1@news.cadence.com...

63q2o4i02@sneakemail.com wrote:
If you want to see something cool, look up Microwave Office, and play with
their stuff. Most of what you are thinking about they have been doing for
about 5 years. They are still a small player, but esp. in the RF area, they
are doing the cutting edge human interface development.

Genesys has a pretty friendly user interface as well, at least compared to
some of the old school standards such as ADS. Apparently Agilent thinks so as
well, having bought Eagleware last year. They're positioning it as their "low
end" offering, even though in some configurations I'd say it competes directly
with ADS. Anyone out there work for a company with ADS licenses? Thinking of
switching?

 

[Joel Kolstad]

<63q2o4i02@sneakemail.com> wrote in message
news:1140507161.292876.85080@o13g2000cwo.googlegroups.com...

Text files are quite usefull and powerfull as an interface between
things.
Yeah, I know... it's just the ancient syntax smells of 1970s and I
don't like being reminded all the time there's text going on in the
background.

Hey, the Interface Du Jour is now XML files! In many cases, their structure
is just as simple as the old "SPICE decks," which used the format a programmer
friend of mine terms LAB -- linear array of bytes.

Seriously, you'd be surprised just how many applications use _some_ form of
text file as an interface between their various pieces. Most
compilers/synthesis tools do, schematic/PCB layout tools, etc. Modularizing
software such that file I/O separates each entity can be quite useful for
debugging and automation, and as others have pointed out, for many SPICE
designs, the netlist generation/parsing time is nothing compared to the
simulation time itself. Still, I take your point, and wouldn't be surprised
if someone has a little SPICE variant out there that eliminates the text file
I/O aspect of the netlisting.

I did a sample-and-hold
using HSPICE and some POS schematic entry and layout tools, all the
time wondering why are they paying thousdands of $ for a bullshit
separate schematic tool and simulator, when there is so much
"shareware" style tools that allegedly accomplish the same thing? I
was told HSPICE has really good convergence...

That has been discussed previously, and my understanding is that it boils down
to:

1) For IC design, HSPICE has been around almost forever, and changing it is
extremely expensive for the companies using it. Everyone can agree that there
are better choices available, but often someone makes the "executive decision"
that it's not worth the price of change. Unfortuntaely -- and this is often a
root cause of many a problem in engineering companies, IMO -- the person
making those decisions is not a person having to use the tools.
2) In HSPICE's defense, it is old and cranky and not very "friendly" (and even
downright buggy), but it is a lot more powerful than you might initially
expect. For instance, a lot of graph measurements/computations can be
performed programmatically with little scripts, which is something you seldom
find in inexpensive tools. This may or may not be of any value to you...
3) Some fabs accept HSPICE as their "golden standard," so if your IC fails and
your simulation using the fab's models say it shouldn't have, they foot the
bill for the re-spin rather than you.

well, I still had plenty
of trouble getting things to work... and of course it was all unix...

HSPICE is the kind of program where I think any good engineering company
hiring someone who'll be using it extensively would send off new hires to a
week long course on its usage. When I was in school using HSPICE, the T/A for
the class went up to the board and drew a pie chart and said something like,
"You really need to be careful with HSPICE and the Cadence Design Suites... in
the entire university, we probably know how to use something like 10% of it
[draws small segment on pie], and personally I probably know no better than 1%
of it [draws tiniest sliver possible on pie]. Be sure to save plenty of
backups, since there are a million configuration options in there and if you
choose to go off experimenting you can mess something up to the point where no
one here will be able to help you recover your design."

it's like you could feel the geologic strata of 20 years of software
all clunking along...

[Excellent description deleted] Yeah, I feel your pain! Things do slowly
improve, though, and as others mentioned joining one of the GNU EDA projects
is a good way to contribute to that change.

Anyway, that's my rant.

I wish you the best in implementing some of your ideas; it would be doing the
engineering community at large a service.

---Joel Kolstad

 

[Charlie Edmondson]

63q2o4i02@sneakemail.com wrote:

thanks for reading

BTW, is anyone you know hiring an anolog designer in the northwest USA?

Michael

Michael,
I snipped a lot of your post, but the important thing to think about is
"Where is the money?" A lot of these companies have been around a long
time. Yep, there is a lot of text based infrastructure in those
programs, but that is because SPICE is text based. All these programs
are based on the original Berkely SPICE, and that is what you have to
work with.

Also, when you are making lots of money, you have to consider, Will I
make MORE money if I do major changes? Or will this cost me money? In
most cases, it is not worth the ROI to make major changes.

If you want to see something cool, look up Microwave Office, and play
with their stuff. Most of what you are thinking about they have been
doing for about 5 years. They are still a small player, but esp. in the
RF area, they are doing the cutting edge human interface development.

Charlie