Electronic Design

Spice Programs: Computerized Circuit Analysis For Analog EEs

This month we follow up on the Feb. 9th column's general topic of Spice. We're also going to look at some of the programs available, and learning aids convenient to the analog-oriented EE. In the earlier column, the main focus was a couple of Spice-oriented book reviews. Now I'd like to share with you some of the comments I received.

Spice Training Programs: In addition to the previously mentioned RCG Research Inc. training programs, there are other sources suitable for those interested in learning Spice. Charles Hymowitz of Intusoft wrote making this point.

I am attaching flyers on our Spice class that we have been teaching for over 10 years now, with over 1000 students during that time. We are the only Spice vendor that does their own classes, and have had a lot of experience with the "Spice learning curve." One flyer describes some great-selling, Spice-related books, especially the "SMPS Simulation with Spice 3."

You might also want to check out our web site (www.intusoft.com) for more information and lots of Spice goodies. Unlike other EDA sites that are primarily advertising, we have posted a wealth of technical literature, articles on Spice, and related modeling topics, application notes, and free models.

Thanks for the useful information, Charles. I noted from a visit to your web site that the Spice book list which you forwarded is available under the "Spice Reference Books" button. Numerous working Spice program files are under the "Demos" button, and the class descriptions are at http://www.intusoft.com/classes.htm. I was also impressed with the number of technical articles you have online, and the issues of your newsletters. You have a very useful and information-rich site.

Spice Vendors: Several months ago, before the great PC crash of Fall 1997 (see the April 6th column), I had been working on accumulating and evaluating a number of demo Spice packages. Well, frankly, the PC crash wiped out much of that work. So, for this article I simply decided to list a number of commercial and public domain Spice program sources. All are available for web download. Most commercial packages mentioned are "suites," meaning integrated schematic capture and simulation, and in some cases, PCB design capability.

The MicroSim web site is at www.microsim.com, and it offers demo programs via the "Download" button. These are not only the latest releases of the main program PSpice, plus the related schematic capture and PCB design files, but also the associated user guides, in PDF format. Numerous tech support files, newsletters, Spice bibliographies, and book lists can also be found, under the "Tech Info" button.

MicroSim has recently merged with OrCad, and there is a news item addressing this point. The main MicroSim site is loaded with lots of tech info, but other (older) PSpice versions can be found at various EE web sites (see below).

Another Spice simulator which has long been popular with the design community is Micro-Cap, from Spectrum Software (www.spectrum-soft.com). The web site features a demo version of the current release, Micro-Cap 5, version 2, which runs under Windows 3.1, 95, and NT. It appears that the authors of Micro-Cap have made great efforts toward interfacing compatibility with other simulators. For example, they state that Micro-Cap reads, writes, creates, and analyzes standard Spice and PSpice text files, as well as its own schematic files. This feature is not a minor point, if you have older ASCII circuit files.

Interactive Image Technologies Ltd., Toronto, Canada, has a popular, under-$1000, integrated Spice program called Electronics Workbench. It is available in full-featured professional, and more- limited versions (http://www.interactiv.com). These simulators include a schematic capture program and an interactive simulator, but PCB layout is separate. A distinguishing feature of the program is the "workbench" look and feel, using a virtual oscilloscope and signal generators. A demo version of the software is available.

Ron Tipton of TDL Technology reported his experiences with another Spice vendor, Penzar.

Penzar Development (http://www.penzar.com) offers an inexpensive Spice (compared to PSpice and Intusoft). They call their version TopSPICE, with both DOS and Windows versions available. I've been using it six-to-seven years, and it is very satisfactory, as it includes both mixed-mode and analog behavioral modeling.

The Intusoft Newsletter is a good model info source, as are EDN and Electronic Design. I've been clipping and saving models, and have a thick notebook full of them. Enjoyed your Spice comments.

Thanks for your comments, Ron. I checked out the Penzar web site, and as you say, their programs are relatively inexpensive. The full Windows 95 version, TopSPICE/Win32 5.4, sells for under $500. There are demo versions available for Windows 3.1 and 95, and DOS platforms. I also noted that the packages include schematic capture and simulation.

A literal cornucopia of free Spice simulators is available on the web. Just point your browser to http://www.paranoia.com/~filipg/HTML/FAQ/BODY/F_Free_Spice1.html#FREESPICE_001. Here you will find Spice simulators for numerous operating systems, DOS, Windows, OS2, and even several PSpice versions back. You'll also find Berkeley Spice in several flavors.

Reader Reactions To Spice Issues: February's column ended with queries on these Spice issues: the general appeal of simulation as a design tool, the adequacy of current simulators and models, and the move toward integrated suites.

Wilfried Adam, a German consulting engineer, answered thusly:

I am responding to your call for reactions on Spice. Before dealing with your questions, I consider myself a semiprofessional engineer mainly for audio electronics, and I use simulators only occasionally, i.e., once a week to once a month.

I find simulation indispensable, especially because the next electronic components shop is 55 km away, and ordering special one-off parts by mail order isn't particularly cost effective. As for the adequacy of simulators, yes, they offer much more than I need.

Regarding suites, for the professional engineer, the answer is probably "Yes," whereas in my case, suites are too difficult to handle. It is difficult enough for me already to learn how to use a simulator because the learning curve is usually very steep—the MicroSim design center in particular—and even more so if used only on an occasional basis. The more educationally oriented simulators do not cover my needs, although they are much easier to handle. The best compromise for my needs was, and still is, Micro-Cap, where I could even master the DOS version (when used only occasionally).

Simulators have surely come a long way from command-line and net-list DOS programs to the more user-friendly GUI versions of today. The user interface still needs attention, and the introduction of (optional) wizards as seen in modern word processors, might be a very good idea for simulators too.

Thanks for the comments Wilfried. I find your reactions to GUI-oriented simulators interesting, as I don't always find them an ideal working environment, either.

The comments below by Dave Graff of Electronic Consultants, Inc. touch in this area as well.

In response to your request for Spice opinions, I offer my experiences and comments. As a design consultant, I do a lot of circuit analysis, and find Spice transient analysis a very valuable tool for many analog circuits. The two areas that you touched on in your article, however, are the major problems with Spice.

First, and foremost, is the model problem. At best, models supplied by device manufacturers are barely adequate for evaluating nominal circuit performance. No vendor provides best- and worst-case model parameters. It is up to the analyst to determine the appropriate model parameters to vary (and by how much), and to match data sheet tolerances. This is no easy task.

Even worse, the nominal models don't always work. I've seen cases where adding a small resistor in series with the power-supply pin causes an op amp output voltage to rise tens of volts above the supply voltage. After looking into the model, I found that the problem was caused by a current source in a behavioral model for the output stage. There was nothing to limit the output voltage to realistic values. The bottom line is that all models need testing, to verify that they produce realistic results.

The other major problem is convergence. Adjusting tolerances and time steps sometimes solves the problem, but not always. I'm interested in Ron Kielkowski's comments on this.

Regarding integrated packages, my only experience has been with the MicroSim Windows version 7 product. I found the schematic capture unfriendly and difficult to use. I couldn't even find simple switch models on their parts menu. I decided not to use that product, using the older 6.1 DOS version instead, finding it much easier editing a net list. I'm against integrated packages, because they force you to use a single vendor's product, when that vendor may only be superior in one phase of the problem (e.g., simulation). I prefer using the best products for each task. Of course, it would be nice if all packages from different vendors could communicate with each other.

Thanks, Dave. I'd like to add some perspective on models. My company (Analog Devices Inc., Norwood, Mass.) offers IC models, as do most other semiconductor suppliers. While not directly involved with these models, I have had past modeling experience.

To best understand a basic model limitation, let it be said that virtually all available vendor-supplied models are macromodels, for reasons of simplicity, speed, and proprietary interests. As such, they mimic a real part with controlled sources, passive parts, and a minimal number of junctions. Sometimes, controlled sources don't offer the same dynamics of real transistors, for example in an output stage (an inherent weakness of this type of model). But still, the example you cited should not have happened, and it simply sounds like you ran into a defective model.

But, models can indeed be made to mimic real parts with regard to worst-case offsets, gains, etc. Taking the ADI library as one example, there is an "A" suffixed OP177A, etc., documented as: "This version of the OP-177 model simulates the worst-case parameters of the A grade. The worst-case parameters used correspond to those in the data book." A user of this op amp can employ the proper suffix model to simulate appropriately.

That said, it is also true that more complex models with many bells and whistles for various device operating modes will in turn, run slower and be more difficult with convergence. So, model fidelity is not a simple issue!

As for the comments on convergence, I forwarded your letter to Ron Kielkowski, who offered this:

Regarding Dave Graff's comments: Most designers today fail to realize that Berkeley Spice and all of the derivatives based on it have been compromised. The original authors decided that fast simulation was one of the primary program design goals. As a result, the time-step control and numeric integration algorithms, plus the device model equations are in many ways less than optimum for accurate, convergent simulation. While better, more-accurate algorithms exist, they weren't ever implemented, because they all slow down simulations. Therefore, our simulations are often plagued with time-step control errors, numeric integration instabilities, and of course, nonconvergence.

But, before throwing up our hands, let's remember two points: The original authors of Spice (and Cancer) pulled off a minor programming miracle when they produced the code which is now the mainstay for circuit simulation, and when a user takes the time to understand the inner working of Spice, many of the problems are easily overcome.

Dave Graff mentioned that setting tolerances and adjusting time steps sometimes helps nonconvergence. But he failed to mention any of the other nonconvergence aids available in Spice. Nonconvergence can be caused by no fewer than six different mechanisms. It is unfortunate that more engineers don't understand what causes nonconvergence, because understanding of those causes allows us to prevent 80% to 90% of the typical nonconvergence cases we see.

Our "Successfully Simulating Circuits with Spice" course has been on hold since 1995 because of a flood of requests received for our two MicroSim PSpice Workshops. But we may be able to start offering this course again soon. Until then, it is my hope that the information in my "Inside SPICE" book will be benefit all Spice users. The second edition just came out, and it has new Windows-based programs to replace the first edition's DOS versions.

Thanks for the clarifying comments, Ron. Readers should note the new book constitutes another Spice source, in addition to those above.

Gary Huntress of the Newport Naval Undersea Warfare Center wrote in with some interesting ideas fpr running Spice (and other things) on a PC, but under Linux (a UNIX-for-PCs OS ), in contrast to Windows 95.

Walt, I enjoyed your recent Spice tutorial and book article. I hadn't used it for some time, and now you've prompted me to pick it up again.

Although not mentioned in your article, I suppose that you know Spice is available for the Linux operating system? For about $30, you can have a world-class operating system with wonderful simulation tools. The fact that Linux runs great on a 486 motherboard that you can rescue from the trash is a plus too! I haven't found anything that can't be done better, faster, and cheaper under Linux. The biggest obstacle is the learning curve.

Thanks for some insight into an alternate way, Gary. Obviously, a hands-on Linux piece isn't something to do quickly, so I'll defer signing up for now.

TIP: On the seminar trail, I hope to personally meet some of you Electronic Design readers during April and May, while travelling around the U.S. and Canada to selected sites. I'll be presenting material, along with the rest with the 1998 Analog Devices seminar team.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.