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

Reply to
63q2o4i02
Loading thread data ...

Yes.

Yes.

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.

I agree, the bench test gear is pretty lame.

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.

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.

Do you have 20 years to spare?

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 snipped-for-privacy@anasoft.co.uk

formatting link
SuperSpice, a very affordable Mixed-Mode Windows Simulator with Schematic Capture, Waveform Display, FFT's and Filter Design.

Reply to
Kevin Aylward

Kevin Aylward wrote: : snipped-for-privacy@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:

formatting link

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:

formatting link

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:

formatting link

Check it out.

Stuart

Reply to
Stuart Brorson

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

Reply to
63q2o4i02

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

Reply to
63q2o4i02

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

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

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

I thought you didn't like text files?

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

Whats "natual"? Whats common sense?

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.

Many already do that, e.g. SS.

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

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 your doing *real* pro-sims.

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

Kevin Aylward snipped-for-privacy@anasoft.co.uk

formatting link
SuperSpice, a very affordable Mixed-Mode Windows Simulator with Schematic Capture, Waveform Display, FFT's and Filter Design.

Reply to
Kevin Aylward

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

Reply to
Joel Kolstad

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.

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.

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.

Ok, I'll take a look.

cool.

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

Reply to
63q2o4i02

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.

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.

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." :-)

[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.

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

---Joel Kolstad

Reply to
Joel Kolstad

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

Reply to
Charlie Edmondson

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?

Reply to
Joel Kolstad

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.