6. SPICE simulation

There are several options for doing SPICE simulations under GNU/Linux; I will highlight three:

There is also a GPL'ed simulator called “gnucap”, which is based upon (or is the descendant of) Al's Circuit Simulator (ACS). I haven't used it very much; information about gnucap is therefore TBD.

6.1. LTSpice

LTSpice was written by Mike Englehardt and others at Linear Technologies, and is given away by LinearTech as a design aid for engineers wishing to simulate the performance of LinearTech's switch mode power supply controllers. The package incorporates a schematic capture front end, fast and powerful SPICE engine, and the capability for plotting the results of many different types of SPICE analysis. Personally, I think the schematic capture front-end is hard to use and clunky; gschem knocks its socks off for ease of use and features. However, the SPICE engine and analysis stuff in LTSpice is simply great.

LTSpice was originally developed to run under Windows, but Mike has tweaked it so that it runs fairly well on GNU/Linux under wine. (Only the help menu system is broken -- the rest of the package runs well.) Another good feature of LTSpice is that it is well supported -- Mike reads the newsgroup sci.electronics.cad regularly and is generally happy to help people who experience problems with it. Therefore, despite its Windoze heritage, I recommend LTSpice as a powerful, professional-quality simulation and analysis back end for gEDA.

6.1.1. Installation and configuration of LTSpice

To install and configure LTSpice, do the following:

  1. Download and install wine. I have had success using Wine-20030219. Later versions probably also work.

  2. Download LTSpice. It is available under http://www.linear.com/software under the name SwitcherCAD-III.

  3. Run the LTSpice installer under wine.

6.1.2. Running LTSpice with gEDA designs

LTSpice can read a file holding a gEDA SPICE netlist. I have had success doing LTSpice simulations in the following way:

  1. First of all, make sure that you are logged in as a normal user -- Wine doesn't like to run when invoked by root.

  2. Create a file in your project directory called “Simulation.cmd”. In this file place your spice analysis commands (e.g. .OP, .AC, .DC, etc.)

  3. Place a SPICE include block into your schematic. For the file attribute, type in “Simulation.cmd”.

  4. Netlist your design.

  5. Create a link from your netlist “output.net” and a netlist in the directory in which SwCADIII lives. Make the netlist suffix .cir. For example:

    ln -s ${DESIGN_HOME}/output.net ${WINE_HOME}/.wine/fake_windows/Program Files/LTC/SwCADIII/MyDesign.cir 
         
  6. Run LTSpice: cd into the directory where SwCADIII lives and say “wine scad3.exe”

  7. From the SwCADIII GUI, do: File->Open->(files of type netlist [.cir]), and select your file.

  8. Run the simulator by clicking on the run button, or doing: Simulate->Run.

  9. Select the variables to graph, and then click OK. SwCADIII does the rest of the work.

Naturally, it is very important to play around with LTSpice to understand how to use it effectively, but the above description should suffice to get you started.

6.2. Ngspice

Ngspice was started at the University of Rome “La Sapienza” by Paolo Nenzi as an attempt to create a GPL'ed version of the standard Berkeley SPICE version 3 by re-writing the entire SPICE package. Plans were also laid to create better, more robust computational algorithms for the simulation engine. More information is available at the ngspice website: http://ngspice.sourceforge.net/. In light of his lofty plans, what Paolo did, however, was a little different: He took the SPICE 3 code which had been floating around the Internet for many years, refactored it, and hacked the build system so that it would compile using the normal GNU make procedure. This was a major achievement for which Paolo deserves great praise. Unfortunately, from the look of the webpage, development on ngspice seems to have ceased at the end of 2001. Indeed, development did slow down considerably after 2001, but recently Paolo has been working on ngspice again. He released the latest version, ngspice-rework-15, in February 2004. This version is available only on the Sourceforge download page; Paolo hasn't updated the rest of the project's website.

6.2.1. Installation and configuration of ngspice

I generally find it best to download, configure, and compile the source of ngspice instead of trying to install a binary package. That's the approach I outline here.

6.2.2. Downloading the source code

Get the latest distribution from: sourceforge. Make sure that you get the latest version for best performance and the most features. As of May 2004, the latest release is ngspice-rework-15. Install the source in the place you typically put your sources. I like to keep my gEDA sources in a separate directory, for example /usr/local/geda/sources/ngspice. You might adopt a similar system.

6.2.3. Extracting the source code

The source code you downloaded is distributed in a “tarball”, a compressed archive. You have to extract archived files by doing:

user@host:~$ cd <directory where you want to extract the source>
user@host:~sources$ tar -xvzf </path/to/package.tar.gz>
user@host:~sources$ cd <extracted dir>
    

At this point you are in the top level directory of ngspice. Read the usual files, like README, and INSTALL, to learn about the simulator and the installation process. Reading NOTES file is also a good idea; it holds information valuable if you want to hack or debug features present in ngspice.

6.2.4. Configuration and compilation of ngspice.

Ngspice uses the typical “configure && make && make install” sequence used by other GNU software. There are numerous configure time options available for ngspice. A complete listing with attendant documentation is TBD; the best way to see them all is to look at configure.ac itself. Many of the configure time options pertain to debugging the simulator, or are to enable experimental analyses. For newbies, three configure time options are worth mentioning:

  • --enable-xspice: This flag compiles in support for XSpice extensions. These extensions allow you to define devices whose behavior is given by arbitrary “code models”. Arguably, the most important code model is spice2poly, which is a model which translates SPICE2 style POLY constructs into an XSpice model usable by SPICE 3.

  • --with-readline: This flag compiles GNU readline support into ngspice, which means that you can use emacs-style key commands, as well as the arrow keys to move around in the command line interface (CLI). Without this feature, the command line interface can be hostile, meaning that if you make a mistake in typing a long command, you have no choice but to type it all over again. Paolo discourages use of the readline feature because it mixes GPL code (readline) with BSD code (ngspice), but he left the option open to other to decide for themselves how pure they wanted to be.

  • --prefix: This flag point to the base directory where you want your binaries to be installed.

Before you run configure, you should check the options you want to include, a brief description is given in appendix TBD. Once ready type:

user@host:~sources/<tld>$./configure --enable-xspice --with-readline  --prefix=/usr/local/geda <other configure options>
    

Of course, “--prefix=” should point to the place where you put your gEDA stuff. After issuing the command, your simulator is configured and ready to be compiled. Compilation is straightforward:

user@host:~sources/<tld>$ make && make install 
    

As always, you will probably need to be root in order to install the packages in a public directory, in such case you should do:

user@host:~sources/<tld>$ make
user@host:~sources/<tld>$ su -c make install
    

6.2.5. Testing the installation

At this point, you should be able to use ngspice. You can test your installation by trying one of the test circuits held in the tests directory. I recommend running the TransImpedanceAmp test, since it tests the SPICE2 POLY functionality.

6.2.6. Using ngspice

Running ngspice is very simple. Just issue the command

user@host:~$ ngspice filename.net
    

at the unix command prompt, and ngspice will load the SPICE netlist called filename.net into its workspace, and leave you at an ngspice command prompt. You can run the simulator by saying “run”. Your results will be stored in SPICE vectors for later printing or plotting. The command set available to you is documented at:

http://newton.ex.ac.uk/teaching/CDHW/Electronics2/userguide/sec5.html#5

To make use of the SPICE2 POLY codemodel, you need to load it into ngspice before you load your netlist. (If you load it after loading your netlist, POLYs in your netlist are not translated, and therefore won't be simulated correctly.) To load the codemodel, just say

codemodel /usr/local/geda/lib/spice/spice2poly.cm
    

(or wherever you put your codemodels) at the ngspice prompt. Note that you must provide the absolute path to the location of the codemodel; ngspice isn't smart enough to look for it in any default locations. (Also note that you should specify the location where spice2poly.cm lives on your machine; the path above is for mine.)

A better way to read in the spice2poly codemodel is to include it in the ngspice initialization file, “spinit”. The initialization file lives in the directory /usr/local/geda/share/ng-spice-rework/scripts (or where ever you placed your gEDA installation). Other ngspice customizations may also be placed into the spinit file.

6.3. Tclspice

While the main branch of ngspice development hibernated in 2002, some friendly people at MultiGig Ltd. (http://www.multigig.com/) were busy developing a branch of ngspice which they called “tclspice”. Tclspice is a superset of ngspice in which much of the SPICE command set is exported as an API to TCL. The purpose of this is to facilitate scripting of SPICE analyses. This is a very powerful tool: With tclspice you can write a TCL script which runs a loop, tweaks component values, runs an analysis, and then evaluates the circuit performance with the tweaked components before looping again. Obviously, this ability can be used to perform automated, multi-dimensional circuit optimization. When complete, tclspice might possibly become a “killer-app” for open-source EDA.

6.3.1. Downloading, installing, and building tclspice

Tclspice's project homepage is at: http://tclspice.sourceforge.net/. The tclspice source lives at http://sourceforge.net/projects/tclspice. Download and installation of tclspice follow the same steps as those detailed for ngspice above. Since tclspice is a superset of ngspice, you can install ngspice alone from the tclspice sources if desired. To build the entire package requires a couple of extra steps. Here, I present a series of steps which will build both ngspice (the stand-alone, CLI driven program) and the TCL API from the tclspice source.

Before building tclspice, you need to have the following packages already installed:

  • TclX (tclx8.3.5 works for me.)

  • tclreadline (tclreadline-2.1.0 works for me.)

  • BLT for TCL (blt2.4z works for me.)

  • TCL/Tk (8.4.3. work for me)

If you don't have these packages already on your Linux box, you need to get and build them. Note that building TclX requires having the sources for TCL and Tk, so you will also need to get those sources if you don't have them installed already. I am running successfully with TCL/Tk 8.4.3, although 8.3.X versions are also supposed to work. Also, if you want to run spice in the background you need to recompile TCL and Tk to enable thread support if they haven't got it enabled already (redhat packages haven't).

Assuming you have downloaded and installed the additional packages mentioned above, the following steps will build both ngspice and the TCL API on your machine:

user@host:~sources/<tld>$ ./configure --enable-xspice --with-readline  --prefix=/usr/local/geda 
user@host:~sources/<tld>$ make && make install     (this makes and installs regular old ngspice)
user@host:~sources/<tld>$ ./configure --enable-xspice --prefix=/usr/local/geda --enable-tcl --enable-experimental --disable-shared
user@host:~sources/<tld>$ make tcl && make install-tcl
    

As always, you will probably need to be root in order to install the packages in a public directory, in such case you should do:

user@host:~sources/<tld>$ su -c make install
user@host:~sources/<tld>$ su -c make install-tcl
    

to install your packages. Now you will be ready to write TCL scripts which incorporate SPICE commands. Information about using tclspice is given below. Finally, if you are interested in hacking tclspice (or even if you are not), it's a good idea to read the NOTES file living in the top source directory for a couple of useful pointers.

6.3.2. Use of tclspice

Tclspice is designed to export SPICE commands to TCL programs. To use tclspice, you just need to say “package require spice” at the beginning of your TCL program. Thereafter, to invoke a SPICE command, you just call it in the spice namespace. For example, the following TCL program will read in a SPICE netlist, command a transient analysis, run the simulation, and then plot the voltage observed over time on net Vout:

#! tclsh 
package require spice
spice::codemodel /usr/local/src/tclspice-0.2.12/src/xspice/icm/spice2poly.cm 
spice::source netlistname.cir 
spice::tran 0.1ns 40ns
spice::run
spice::plot Vout
puts "All done now!" 
    

Note that since tclspice doesn't read the ngspice initialization file “spinit”, you will need to put any initialization commands directly into the TCL program. For example, in the above example we read the spice2poly codemodel directly into the workspace. Many other commands are also available; the entire tclspice commandset is documented at:

http://tclspice.sourceforge.net/docs/tclspice_com.html

6.3.3. Tclspice problems

A major problem with tclspice (which was inherited from ngspice) is that it leaks memory. Therefore, the time over which you may run a simulation is limited. This means that if you want to do an optimization by looping through a circuit many, many times, you may run out of memory before your program has completed its optimization. This is a known issue with tclspice, and efforts are underway to plug the leaks.

Meanwhile, there are some workarounds which can be used on moderate-sized designs to facilitate long optimization runs. One method I have employed is to have the optimizer write its current state into a file after every circuit analysis, and read its starting state from the same file. The optimizer also stores the current list of best components in another file, and reads this file at the start of every run. Then, I have a TCL program called TaskMgr.tcl which runs in a loop; at each iteration of the loop it forks a child process to run the optimizer. Meanwhile, the parent process waits for 5 minutes (a heuristically determined time), and then issues a "KILL" signal to the child before looping and starting the optimizer again. This way, the optimizer never runs long enough to consume all the memory in my machine. The TaskMgr.tcl program is shown here:

#! tclsh 
package require Tclx 
while {1} {
  set PID [fork] 
  if {$PID} {
    # Parent 
    after 300000 
    puts "About to kill child PID = $PID . . . ." 
    kill $PID 
    wait $PID
  } else {
    # Child 
    source Optimize.tcl 
    # If we ever get through this, we can print out the following:
    error "We are done now!!!!!!" 
  } 
} 
    

Note that TaskMgr.tcl needs the TclX package you already installed to run tclspice. Also, you may want to change the wait time to a different value depending upon the memory and speed of your machine. Finally, the parent has to wait on $PID because that causes the child process's corpse to be taken off the Linux kernel's task list when it dies. Otherwise, you will end up with a lot of zombie processes lurking around your machine as the optimizer runs -- a long optimization could turn your system into “the night of the living dead”!

This method of waiting a specific amount of time for the child process is preferable if a single analysis run takes a relatively short time compared to the time required to eat all memory in the machine. If the analysis time is comparable to the time taken to eat all memory in the machine, a better approach is to have the parent keep track of the analysis state, kick off a single analysis run, and then have the run terminate after every iteration. Whether this is preferable depends upon the size and complexity of your design; you may want to experiment with your analysis to see just how long it takes and how much memory it consumes. I have found that a design comprised of six op amps (with corresponding vendor models) and 50 or so passives will run in under 10 seconds on a PIII 333MHz with 128MB RAM. Therefore, your design must be very big before a single analysis will eat a significant amount of RAM.