Revision history:

• Revision 1.0 – 3.10.2003, SDB.
• Revision 1.1 – 3.19.2003. Added .SUBCKT stuff & stuff about LTSpice. SDB.
• Revision 1.2 – 3.31.2003. Added stuff about creating hierarchical projects (i.e. creating .SUBCKTs using gschem and incorporating a lower level .SUBCKT into a higher level schematic).
• Revision 2.0 – 7.23.2003. Split doc into sections. Edited netlisting stuff to correspond to gEDA-20030525, which now includes spice-sdb in the distribution. Added new section about ngspice/tclspice.

The most recent copy of this document is always available at http://www.brorson.com/gEDA/SPICE/

Introduction

Overview

spice-sdb netlister installation and configuration

Design/simulation flow summary

Preliminary notes about symbols and SPICE model files

Symbol creation

SPICE file configuration

Schematic capture

Gschem attributes

Component attributes

Refdes conventions

Passives

Transistors and diodes

Actives -- integrated circuits

Independent sources

Dependent sources

SPICE components

Handling hierarchical models

SPICE netlist generation

Creating the netlist

Common netlisting problems

SPICE simulation

LTSpice

ngspice/tclspice

Appendicies

Component attribute summary

Valid types

The purpose of this document is to explain how to use the gEDA tools (running on Linux) to perform SPICE simulations. In particular, this HOWTO documents the usage of spice-sdb, which is an advanced backend for the gEDA netlister (gnetlist) used to create SPICE netlists. This HOWTO also provides advice about using LTSpice and/or ngspice to simulate a circuit netlisted with spice-sdb. I assume that you are already familiar with electronic design, the mechanics of schematic capture using EDA tools, and SPICE simulation in general. I also assume that you are reasonably familiar with the Linux operating system and its development environment.

Note that this is now a multi-page document. To navigate through the document, either use the table of contents as a jump-off point, or use the link at the bottom of each page to get to the next page.

From the top level, SPICE simulation in gEDA proceeds via the following steps:

1. Creation and gathering of schematic symbols and SPICE model files. Oftentimes, the SPICE model files are obtained from the component vendor.
2. Schematic capture using symbols and SPICE models created in step 1.
3. Netlist generation from the schematic created in step 2.
4. SPICE simulation of the circuit described by the netlist created in step 3.

To create a SPICE netlist, the netlister (gnetlist) iterates through the entire schematic and looks at several parts of each component's symbol in order to create a blob of SPICE code. In general, each component can generate one or more lines of SPICE code. Component information needed by the netlister is held in two places:

1. The symbol itself, in the "device" attribute, which is attached when the symbol is created, and is typically accessed through the symbol editor.
2. In attributes manually attached to the component during schematic capture using gschem.

Since there are two places the netlister looks for information, you must make sure that the required information is available in both places.

This document was originally written around gEDA/gaf 20030223, and the SPICE netlister spice-SDB. Starting with gEDA/gaf 20030525, my netlister was incorporated into the main gEDA distribution, and renamed spice-sdb (lower case sdb). For smoothest operation, you are best off just downloading and installing the latest version of gEDA. However, if you have a gEDA version predating 20030525, and you want to hack, you can download and install spice-SDB using the instructions provided on http://www.brorson.com/gEDA/SPICE/SPICEonLinux.html. In any event, it's a good idea to make sure that the file gnet-spice-sdb.scm is present in your scheme directory (usually ${prefix}/geda/share/gEDA/scheme) if you are interested in performing SPICE simulations with gEDA as described in this HOWTO.

The detailed steps required to create a circuit and simulate it with gEDA look like this:

1. Schematic symbol creation with correct "device" attribute. (Usually, the symbols have already been created with the correct "device" attribute, but if you are having problems, it doesn't hurt to check them.)
2. Schematic capture using gschem.
3. Assignment of SPICE attributes (value, model, file, type, etc.) to components using gschem.
4. Assignment of refdes using e.g. refdes_renum.
5. Creation of netlist using "gnetlist -g spice-sdb".
6. Check netlist for correctness (manually open and inspect netlist).
7. Run spice using a simulator such as LTSpice or ngspice.
8. Plot/analyze results (often plotting/analysis tools are incorporated in the simulator).

The SPICE netlister recognizes a particular symbol in two ways: 1. The symbol's "device" attribute, and 2. The symbol's refdes. Both of these attributes are attached to the symbol when the symbol is created.

Each symbol has a "device" attribute attached to it. The "device" attribute is the first thing the netlister examines when processing the symbol. There are a number of devices which are native to the netlister, meaning that the netlister knows exactly how to deal with these types of devices. Native device types include RESISTOR, CAPACITOR, NPN_TRANSISTOR, etc. The entire list of native devices is present in the appendix.

The "device" attribute is hidden during normal use of gschem. Most often, the symbol's creator has already given the symbol the correct "device" attribute. However, because the "device" attribute is hidden from the ordinary user, it can sometimes cause problems with SPICE netlist creation when it is set to an unexpected value. To view the "device" attribute, go into the symbol editor (select the symbol to edit, and do "Hierarchy" -> "down symbol"), and turn on invisible attributes (Edit -> show/hide inv text). If the "device" attribute is incorrect, you may change it by editing the symbol itself using a text editor.

If a symbol is not native (i.e. the netlister doesn't recognize it as a built-in type), the netlister relies upon the first letter of the refdes to determine how to process the symbol. The refdes prefix is also built into the symbol when it is created. Example refdes prefixes are R for resistors, C for capacitors, Q for transistors, etc. Refdes prefixes correct for SPICE are listed in the appendix. Note that relying upon the refdes to identify the component for SPICE is not foolproof -- for example, the netlister cannot distinguish between NPN and PNP transistors based upon the refdes. Therefore, it is always best to use a native "device" in your symbols.

Files holding complicated SPICE models or other SPICE code may be incorporated into the final SPICE netlist by including appropriate symbols into the schematic. SPICE model files are usually obtained from component vendors. Dealing with these files is straightforward. However, some issues should be kept in mind when preparing models for use during schematic capture:

• It is usually prudent to place these files into a dedicated directory distinct from the symbol directories.
• Make sure that the SPICE files pin assignments correctly correspond to the pins as defined in the component's symbol.
• Make sure that the last character in a SPICE model file is a carriage return. If no carriage return exists, then the next component listed in the netlist may be placed on the same line as the last line of the SPICE model file.

Please send comments or questions about this HOWTO to Stuart Brorson at sdb@cloud9.net.