<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"
lang="en" dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>geda:sdb_howto</title>
<meta name="generator" content="DokuWiki Release rc2007-05-24" />
<meta name="robots" content="index,follow" />
<meta name="date" content="2007-05-24T22:27:25-0400" />
<meta name="keywords" content="geda,sdb_howto" />
<link rel="search" type="application/opensearchdescription+xml" href="http://geda.seul.org/wiki/lib/exe/opensearch.php" title="geda Wiki" />
<link rel="start" href="http://geda.seul.org/wiki/" />
<link rel="contents" href="http://geda.seul.org/wiki/geda:sdb_howto?do=index" title="Index" />
<link rel="alternate" type="application/rss+xml" title="Recent Changes" href="http://geda.seul.org/wiki/feed.php" />
<link rel="alternate" type="application/rss+xml" title="Current Namespace" href="http://geda.seul.org/wiki/feed.php?mode=list&ns=geda" />
<link rel="alternate" type="text/html" title="Plain HTML" href="http://geda.seul.org/wiki/_export/xhtml/geda:sdb_howto" />
<link rel="alternate" type="text/plain" title="Wiki Markup" href="http://geda.seul.org/wiki/_export/raw/geda:sdb_howto" />
<link rel="stylesheet" media="all" type="text/css" href="lib/exe/css" />
<link rel="stylesheet" media="screen" type="text/css" href="lib/exe/001css" />
<link rel="stylesheet" media="print" type="text/css" href="lib/exe/002css" />
</head>
<body>
<div class="dokuwiki export">
<div class="toc">
<div class="tocheader toctoggle" id="toc__header">Table of Contents</div>
<div id="toc__inside">
<ul class="toc">
<li class="level1"><div class="li"><span class="li"><a href="#spice_on_geda_howto" class="toc">SPICE on gEDA HOWTO</a></span></div>
<ul class="toc">
<li class="level2"><div class="li"><span class="li"><a href="#introduction" class="toc">Introduction</a></span></div>
<ul class="toc">
<li class="level3"><div class="li"><span class="li"><a href="#overview" class="toc">Overview</a></span></div></li>
<li class="level3"><div class="li"><span class="li"><a href="#spice-sdb_netlister_installation_and_configuration" class="toc">Spice-sdb netlister installation and configuration</a></span></div></li>
<li class="level3"><div class="li"><span class="li"><a href="#design_simulation_flow_summary" class="toc">Design/simulation flow summary</a></span></div></li>
</ul>
</li>
<li class="level2"><div class="li"><span class="li"><a href="#preliminary_notes_about_symbols_and_spice_model_files" class="toc">Preliminary notes about symbols and SPICE model files</a></span></div>
<ul class="toc">
<li class="level3"><div class="li"><span class="li"><a href="#symbol_creation_for_spice_netlisting" class="toc">Symbol creation for SPICE netlisting.</a></span></div></li>
<li class="level3"><div class="li"><span class="li"><a href="#spice_file_configuration" class="toc">SPICE file configuration</a></span></div></li>
</ul>
</li>
<li class="level2"><div class="li"><span class="li"><a href="#schematic_capture" class="toc">Schematic capture</a></span></div>
<ul class="toc">
<li class="level3"><div class="li"><span class="li"><a href="#gschem_attributes_for_spice_netlisting" class="toc">Gschem attributes for spice netlisting</a></span></div></li>
<li class="level3"><div class="li"><span class="li"><a href="#handling_hierarchical_models" class="toc">Handling hierarchical models</a></span></div></li>
</ul>
</li>
<li class="level2"><div class="li"><span class="li"><a href="#spice_netlist_generation" class="toc">SPICE netlist generation</a></span></div></li>
<li class="level2"><div class="li"><span class="li"><a href="#creating_the_netlist" class="toc">Creating the netlist</a></span></div></li>
<li class="level2"><div class="li"><span class="li"><a href="#common_netlisting_problems" class="toc">Common netlisting problems</a></span></div></li>
<li class="level2"><div class="li"><span class="li"><a href="#spice_simulation" class="toc">SPICE simulation</a></span></div>
<ul class="toc">
<li class="level3"><div class="li"><span class="li"><a href="#ltspice" class="toc">LTSpice</a></span></div></li>
<li class="level3"><div class="li"><span class="li"><a href="#ngspice_and_tclspice" class="toc">Ngspice and tclspice</a></span></div></li>
</ul>
</li>
<li class="level2"><div class="li"><span class="li"><a href="#appendix" class="toc">Appendix</a></span></div>
<ul class="toc">
<li class="level3"><div class="li"><span class="li"><a href="#component_attribute_summary" class="toc">Component attribute summary</a></span></div></li>
<li class="level3"><div class="li"><span class="li"><a href="#valid_type_values" class="toc">Valid "type" values</a></span></div></li>
</ul>
</li>
<li class="level2"><div class="li"><span class="li"><a href="#document_history" class="toc">Document History</a></span></div></li></ul>
</li></ul>
</div>
</div>
<h1><a name="spice_on_geda_howto" id="spice_on_geda_howto">SPICE on gEDA HOWTO</a></h1>
<div class="level1">
</div>
<!-- SECTION "SPICE on gEDA HOWTO" [1-34] -->
<h2><a name="introduction" id="introduction">Introduction</a></h2>
<div class="level2">
<p>
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.
</p>
</div>
<!-- SECTION "Introduction" [35-708] -->
<h3><a name="overview" id="overview">Overview</a></h3>
<div class="level3">
<p>
From the top level, SPICE simulation in gEDA proceeds via the following steps:
</p>
<ol>
<li class="level1"><div class="li"> Creation and gathering of schematic symbols and SPICE model files. Oftentimes, the SPICE model files are obtained from the component vendor.</div>
</li>
<li class="level1"><div class="li"> Schematic capture using symbols and SPICE models created in step 1.</div>
</li>
<li class="level1"><div class="li"> Netlist generation from the schematic created in step 2.</div>
</li>
<li class="level1"><div class="li"> SPICE simulation of the circuit described by the netlist created in step 3.</div>
</li>
</ol>
<p>
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:
</p>
<ol>
<li class="level1"><div class="li"> The symbol itself, in the “device” attribute, which is attached when the symbol is created, and is typically accessed through the symbol editor.</div>
</li>
<li class="level1"><div class="li"> In attributes manually attached to the component during schematic capture using gschem.</div>
</li>
</ol>
<p>
Since there are two places the netlister looks for information, you must make sure that the required information is available in both places.
</p>
</div>
<!-- SECTION "Overview" [709-1877] -->
<h3><a name="spice-sdb_netlister_installation_and_configuration" id="spice-sdb_netlister_installation_and_configuration">Spice-sdb netlister installation and configuration</a></h3>
<div class="level3">
<p>
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). <strong>For smoothest operation, you are best off just downloading and installing the latest version of gEDA.</strong> 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 <a href="http://www.brorson.com/gEDA/SPICE/SPICEonLinux.html" class="urlextern" title="http://www.brorson.com/gEDA/SPICE/SPICEonLinux.html" rel="nofollow">http://www.brorson.com/gEDA/SPICE/SPICEonLinux.html</a>. 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 <strong><code>${prefix}/geda/share/gEDA/scheme</code></strong>) if you are interested in performing SPICE simulations with gEDA as described in this HOWTO.
</p>
</div>
<!-- SECTION "Spice-sdb netlister installation and configuration" [1878-2744] -->
<h3><a name="design_simulation_flow_summary" id="design_simulation_flow_summary">Design/simulation flow summary</a></h3>
<div class="level3">
<p>
The detailed steps required to create a circuit and simulate it with gEDA look like this:
</p>
<ol>
<li class="level1"><div class="li"> 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.)</div>
</li>
<li class="level1"><div class="li"> Schematic capture using gschem.</div>
</li>
<li class="level1"><div class="li"> Assignment of SPICE attributes (value, model, file, type, etc.) to components using gschem.</div>
</li>
<li class="level1"><div class="li"> Assignment of <strong><code>refdes</code></strong> using e.g. refdes_renum.</div>
</li>
<li class="level1"><div class="li"> Creation of netlist using “gnetlist -g spice-sdb”.</div>
</li>
<li class="level1"><div class="li"> Check netlist for correctness (manually open and inspect netlist).</div>
</li>
<li class="level1"><div class="li"> Run spice using a simulator such as LTSpice or ngspice.</div>
</li>
<li class="level1"><div class="li"> Plot/analyze results (often plotting/analysis tools are incorporated in the simulator).</div>
</li>
</ol>
<p>
The purpose of this HOWTO is to provide the detailed understanding necessary to successfully navigate this process.
</p>
</div>
<!-- SECTION "Design/simulation flow summary" [2745-3673] -->
<h2><a name="preliminary_notes_about_symbols_and_spice_model_files" id="preliminary_notes_about_symbols_and_spice_model_files">Preliminary notes about symbols and SPICE model files</a></h2>
<div class="level2">
</div>
<!-- SECTION "Preliminary notes about symbols and SPICE model files" [3674-3739] -->
<h3><a name="symbol_creation_for_spice_netlisting" id="symbol_creation_for_spice_netlisting">Symbol creation for SPICE netlisting.</a></h3>
<div class="level3">
<p>
The SPICE netlister recognizes a particular symbol in two ways:
</p>
<ol>
<li class="level1"><div class="li"> The symbol’s “device” attribute</div>
</li>
<li class="level1"><div class="li"> The symbol’s <strong><code>refdes</code></strong>. Both of these attributes are attached to the symbol when the symbol is created.</div>
</li>
</ol>
<p>
Each symbol has a <strong><code>device</code></strong> attribute attached to it. The <strong><code>device</code></strong> 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 <a href="#appendix" title="geda:sdb_howto ↵" class="wikilink1">Appendix</a>.<br/>
The <strong><code>device</code></strong> attribute is hidden during normal use of gschem. Most often, the symbol’s creator has already given the symbol the correct <strong><code>device</code></strong> attribute. However, because the <strong><code>device</code></strong> 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 <strong><code>device</code></strong> 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 <strong><code>device</code></strong> attribute is incorrect, you may change it by editing the symbol itself using a text editor.<br/>
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 <strong><code>refdes</code></strong> to determine how to process the symbol. The <strong><code>refdes</code></strong> prefix is also built into the symbol when it is created. Example <strong><code>refdes</code></strong> prefixes are R for resistors, C for capacitors, Q for transistors, etc. <strong><code>refdes</code></strong> prefixes correct for SPICE are listed in the <a href="#appendix" title="geda:sdb_howto ↵" class="wikilink1">Appendix</a>. Note that relying upon the <strong><code>refdes</code></strong> to identify the component for SPICE is not foolproof – for example, the netlister cannot distinguish between NPN and PNP transistors based upon the <strong><code>refdes</code></strong>. Therefore, it is always best to use a native “device” in your symbols.
</p>
</div>
<!-- SECTION "Symbol creation for SPICE netlisting." [3740-5819] -->
<h3><a name="spice_file_configuration" id="spice_file_configuration">SPICE file configuration</a></h3>
<div class="level3">
<p>
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:
</p>
<ul>
<li class="level1"><div class="li"> It is usually prudent to place these files into a dedicated directory distinct from the symbol directories.</div>
</li>
<li class="level1"><div class="li"> Make sure that the SPICE files pin assignments correctly correspond to the pins as defined in the component’s symbol.</div>
</li>
<li class="level1"><div class="li"> 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.</div>
</li>
</ul>
</div>
<!-- SECTION "SPICE file configuration" [5820-6689] -->
<h2><a name="schematic_capture" id="schematic_capture">Schematic capture</a></h2>
<div class="level2">
<p>
Schematic capture is the process by which one uses a special-purpose drawing program to draw a schematic diagram of the circuit under design. In the gEDA environment, the schematic capture program is called “gschem”. I assume you already know how to use gschem. For the purposes of creating SPICE netlists, you must use gschem to attach attributes to components, and possibly also incorporate other SPICE directives into your netlist. After you are done with schematic capture, you create the SPICE netlist by running gEDA’s netlister “gnetlist” on your design.
</p>
</div>
<!-- SECTION "Schematic capture" [6690-7282] -->
<h3><a name="gschem_attributes_for_spice_netlisting" id="gschem_attributes_for_spice_netlisting">Gschem attributes for spice netlisting</a></h3>
<div class="level3">
<p>
There are several ways that spice attributes may be associated with a component using gschem. The way you choose to do this depends upon many factors, including the type of component, and the size and format of the SPICE model.
</p>
</div>
<h4><a name="component_attributes_and_meanings" id="component_attributes_and_meanings">Component attributes and meanings</a></h4>
<div class="level4">
<p>
The following attributes are meaningful for SPICE netlisting, and may be attached from within gschem:
</p>
<table class="inline">
<tr>
<td><strong><code>refdes</code></strong></td><td>The reference designator of the component. Valid values depend upon the component type and are given in the appendix.</td>
</tr>
<tr>
<td><strong><code>value</code></strong></td><td>For passives, this is the component value. For actives, this is the type (model no) of the component (e.g. 2N3904, uA741). When a model for an active is instantiated separately from the component itself, the “value” attribute holds the name of the spice model.</td>
</tr>
<tr>
<td><strong><code>model</code></strong></td><td>This holds a one line spice model for the component.</td>
</tr>
<tr>
<td><strong><code>file</code></strong></td><td>This holds the name of a file. Typically, this is a file holding e.g. a SPICE .MODEL, .SUBCKT, or other SPICE code.</td>
</tr>
<tr>
<td><strong><code>model-name</code></strong></td><td>This holds the name of the spice model referred to in a .MODEL or .SUBCKT statement. “model-name” is mainly used to identify the spice model name in the symbol “spice-model-1.sym”. Active components should call out this name in the “device” attribute to associate the component with its particular spice model or subcircuit.</td>
</tr>
<tr>
<td><strong><code>type</code></strong></td><td>This specifies the type of component and is used by spice when interpreting the model parameters. Valid values depend upon the device being modeled.</td>
</tr>
</table>
</div>
<h4><a name="refdes_conventions" id="refdes_conventions">refdes conventions</a></h4>
<div class="level4">
<p>
As a prerequisite to handling SPICE-related attributes, the SPICE netlister requires that all components must have a refdes attached to them. The refdes may be attached either by hand (which is laborious), or using the program refdes_renum included in the gEDA distribution.<br/>
Note that the first letter of the refdes must correspond to the appropriate letter for spice simulation. The refdes convention is given in the <a href="#appendix" title="geda:sdb_howto ↵" class="wikilink1">Appendix</a>.
</p>
</div>
<h4><a name="passives" id="passives">Passives</a></h4>
<div class="level4">
</div>
<h5><a name="basic_passives" id="basic_passives">Basic passives</a></h5>
<div class="level5">
<p>
The most basic components which one encounters in spice are passive components like resistors and capacitors which have numeric values, but no other modeling attributes. In this case the following attributes must be filled in:
</p>
<table class="inline">
<tr>
<td><strong><code>refdes</code></strong></td><td>The correct <strong><code>refdes</code></strong> for the component.</td>
</tr>
<tr>
<td><strong><code>value</code></strong></td><td>For passives, this is the numeric value of the component (e.g. 100pF). For actives, this attribute may be filled in, but if no model attribute is available elsewhere in the schematic, the value is not used (in SPICE netlisting, anyway).</td>
</tr>
</table>
<p>
If only a <strong><code>refdes</code></strong> and value attribute are encountered, the netlister will write a single line into the output file.<br/>
Example resistor:
</p>
<pre class="code">refdes = R2
value = 220
SPICE line generated: R2 0 4 220</pre>
<p>
Note that “0” and “4” correspond to the net nodes connected to the component, and are generated automatically by gnetlist.<br/>
Example capacitor:
</p>
<pre class="code">refdes = C22
value = 1UF
SPICE line generated: C22 4 23 1UF</pre>
</div>
<h5><a name="passives_with_additional_attributes" id="passives_with_additional_attributes">Passives with additional attributes</a></h5>
<div class="level5">
<p>
Oftentimes, passive components have additional attributes attached to them for spice simulation. Examples of such attributes are temperature coefficients (for resistors) and initial conditions (for reactive components). These additional components may be incorporated into the SPICE file by simply attaching them to the component’s “model” attribute. Specifically, the required attributes are:
</p>
<table class="inline">
<tr>
<td><strong><code>refdes</code></strong></td><td>Correct component <strong><code>refdes</code></strong>.</td>
</tr>
<tr>
<td><strong><code>value</code></strong></td><td>Numerical component value, as always.</td>
</tr>
<tr>
<td><strong><code>model</code></strong></td><td>One line string holding additional parameters, formatted as a valid SPICE string.</td>
</tr>
</table>
<p>
This string is placed after the component value in the line generated by gnetlist. Therefore, it is important to format the string placed in the <strong><code>model</code></strong> line to be valid SPICE code. Otherwise, you will risk causing the SPICE simulator to barf.<br/>
Example resistor:
</p>
<pre class="code">refdes = R5
value = 1MEG
model = TC=0.001,0.015
SPICE line generated: R2 0 4 220 TC=0.001,0.015</pre>
</div>
<h4><a name="transistors_and_diodes" id="transistors_and_diodes">Transistors and diodes</a></h4>
<div class="level4">
<p>
Transistors and diodes are generally accompanied by a device-specific model – otherwise, SPICE simulation is pointless. The SPICE model may be either a short, one-line string of parameters, or a multi-line set of SPICE parameters. A typical one-line parameter string is a short list of parameters describing a small-signal diode. Typical multi-line models come from component vendors, who often provide models for their components in a text file. Since there are two broad formats of SPICE information, there are two approaches to incorporating these parameters into the schematic:
</p>
</div>
<h5><a name="one_line_string_of_spice_parameters" id="one_line_string_of_spice_parameters">One line string of SPICE parameters</a></h5>
<div class="level5">
<p>
To incorporate a one line string of SPICE parameters into the netlist, the following attributes must be attached to the component:
</p>
<table class="inline">
<tr>
<td><strong><code>refdes</code></strong></td><td>Correct component refdes.</td>
</tr>
<tr>
<td><strong><code>value</code></strong></td><td>The model number or part number of the component.</td>
</tr>
<tr>
<td><strong><code>model-name</code></strong></td><td>The name you wish to give the SPICE model. This is usually the model number or part number of the component. If you have already attached a “value” attribute to the component, this parameter is optional.</td>
</tr>
<tr>
<td><strong><code>model</code></strong></td><td>One line string holding additional parameters. Do not place the model parameters in parentheses – gnetlist will do this for you.</td>
</tr>
</table>
<p>
Example diode:
</p>
<pre class="code">refdes = D5
model-name = 1N1004
model = IS=0.5UA RS=6 BV=5.20
SPICE lines generated:
D5 2 6 1N1004
MODEL 1N1004 D (IS=0.5UA RS=6 BV=5.20)</pre>
</div>
<h5><a name="spice_model_file" id="spice_model_file">SPICE model file</a></h5>
<div class="level5">
<p>
To incorporate a file-full of SPICE parameters into the netlist, the following attributes must be attached to the component:
</p>
<table class="inline">
<tr>
<td><strong><code>refdes</code></strong></td><td>Correct component refdes.</td>
</tr>
<tr>
<td><strong><code>value</code></strong></td><td>The model number or part number of the component.</td>
</tr>
<tr>
<td><strong><code>model-name</code></strong></td><td>The name you wish to give the SPICE model. This is usually the model number or part number of the component. If you have already attached a “value” attribute to the component, this parameter is optional.</td>
</tr>
<tr>
<td><strong><code>file</code></strong></td><td>The file name of the SPICE model which you wish to incorporate into the netlist. This file name may specify either a relative or an absolute path, but it is probably better to use an absolute path to avoid problems if you ever move your schematic directory.</td>
</tr>
</table>
<p>
Note that you need to make sure that the model name held in your SPICE model file is the same as the <strong><code>value</code></strong> or <strong><code>model-name</code></strong> attributes you attached to the component. It is also a good idea to verify that the pin assignments in the model file correspond to the pin assignments made by the component symbol.
</p>
</div>
<h4><a name="actives_--_integrated_circuits" id="actives_--_integrated_circuits">Actives -- integrated circuits</a></h4>
<div class="level4">
<p>
Integrated circuits are incorporated into the netlist similarly to transistors and diodes. As such, you may incorporate the spice information either as a one-line parameter string, or as a model file.
</p>
</div>
<h5><a name="one_line_string_of_spice_parameters1" id="one_line_string_of_spice_parameters1">One line string of SPICE parameters</a></h5>
<div class="level5">
<p>
To incorporate a one line string of SPICE parameters into the netlist, the following attributes must be attached to the component:
</p>
<table class="inline">
<tr>
<td><strong><code>refdes</code></strong></td><td>Correct component refdes.</td>
</tr>
<tr>
<td><strong><code>value</code></strong></td><td>The model number or part number of the component.</td>
</tr>
<tr>
<td><strong><code>model-name</code></strong></td><td>the name you wish to give the SPICE model. This is usually the model number or part number of the component. If you have already attached a “value” attribute to the component, this parameter is optional.</td>
</tr>
<tr>
<td><strong><code>model</code></strong></td><td>One line string holding additional parameters. Do not place the model parameters in parentheses – gnetlist will do this for you.</td>
</tr>
</table>
</div>
<h5><a name="spice_.model_or_.subckt_file" id="spice_.model_or_.subckt_file">SPICE .MODEL or .SUBCKT file</a></h5>
<div class="level5">
<p>
To incorporate a file-full of SPICE parameters into the netlist, the following attributes must be attached to the component:
</p>
<table class="inline">
<tr>
<td><strong><code>refdes</code></strong></td><td>Correct component refdes. <strong>Note that if the file holds a .MODEL, the refdes should start with U; if the file holds a .SUBCKT, the refdes should start with X.</strong> The netlister checks for the file type and tries to “do the right thing”, but problems can arise if you don’t follow this rule.</td>
</tr>
<tr>
<td><strong><code>value</code></strong></td><td>The model number or part number of the component.</td>
</tr>
<tr>
<td><strong><code>model-name</code></strong></td><td>The name you wish to give the SPICE model. This is usually the model number or part number of the component. If you have already attached a “value” attribute to the component, this parameter is optional.</td>
</tr>
<tr>
<td><strong><code>file</code></strong></td><td>The name of the file holding the SPICE .MODEL or .SUBCKT which you wish to incorporate into the netlist. This file name may specify either a relative or an absolute path, but it is probably better to use an absolute path to avoid problems if you ever move your schematic directory.</td>
</tr>
</table>
</div>
<h4><a name="independent_sources" id="independent_sources">Independent sources</a></h4>
<div class="level4">
<p>
There are two independent sources: voltage sources and current sources. For incorporation into a SPICE netlist, they both work the same way. To incorporate an independent source into your SPICE netlist, do the following:
</p>
<ol>
<li class="level1"><div class="li"> Place the independent source on your schematic. (Do “Add” → “Component” → “spice” → "<independent source name>.sym”)</div>
</li>
<li class="level1"><div class="li"> Double click on the block and add/edit the following attributes:</div>
<ul>
<li class="level2"><div class="li"> <strong><code>refdes</code></strong>: V? or I?</div>
</li>
<li class="level2"><div class="li"> <strong><code>value</code></strong>: A one line string in SPICE format describing the source.</div>
</li>
</ul>
</li>
</ol>
</div>
<h4><a name="dependent_sources" id="dependent_sources">Dependent sources</a></h4>
<div class="level4">
<p>
There are four dependent sources:
</p>
<ul>
<li class="level1"><div class="li"> This section remains TBD.</div>
</li>
</ul>
</div>
<h4><a name="spice_components" id="spice_components">SPICE components</a></h4>
<div class="level4">
</div>
<h5><a name="spice_model_block" id="spice_model_block">Spice model block</a></h5>
<div class="level5">
<p>
In certain situations, you may wish to embed a spice model block directly into your schematic. This is done when you have several devices with a “value” attribute calling out for a spice model. Depending upon whether the spice block is one line or multi-line, you may embed the code in one of two ways:
</p>
<ol>
<li class="level1"><div class="li"> One line SPICE model:</div>
<ol>
<li class="level2"><div class="li"> Place a spice model block on your schematic. (Do “Add” → “Component” → “spice” → “spice-model-1.sym”)</div>
</li>
<li class="level2"><div class="li"> Double click on the block and add/edit the following attributes:</div>
<ul>
<li class="level3"><div class="li"> <strong><code>refdes</code></strong>: a?</div>
</li>
<li class="level3"><div class="li"> <strong><code>model</code></strong>: model name (i.e. the model name used in the components being modeled.)</div>
</li>
<li class="level3"><div class="li"> <strong><code>type</code></strong>: One of the valid spice component types defined in the spice <acronym title="specification">spec</acronym>.</div>
</li>
<li class="level3"><div class="li"> <strong><code>value</code></strong>: The corresponding one-line spice model</div>
</li>
</ul>
</li>
</ol>
</li>
<li class="level1"><div class="li"> Multi-line SPICE model:</div>
<ol>
<li class="level2"><div class="li"> Place a spice model block on your schematic.(Do “Add” → “Component” → “spice” → “spice-model-1.sym”)</div>
</li>
<li class="level2"><div class="li"> Double click on the block and add/edit the following attributes:</div>
<ul>
<li class="level3"><div class="li"> <strong><code>refdes</code></strong>: a?</div>
</li>
<li class="level3"><div class="li"> <strong><code>model-name</code></strong>: model name</div>
</li>
<li class="level3"><div class="li"> <strong><code>file</code></strong>: Name of file holding SPICE model code (i.e. .MODEL or .SUBCKT).</div>
</li>
</ul>
</li>
</ol>
</li>
</ol>
</div>
<h5><a name="include_block" id="include_block">Include block</a></h5>
<div class="level5">
<p>
The include block places a .INCLUDE directive into your netlist.
</p>
<ol>
<li class="level1"><div class="li"> Place a spice model block on your schematic. (Do “Add” → “Component” → “spice” → “spice-include-1.sym”)</div>
</li>
<li class="level1"><div class="li"> Double click on the block and add/edit the following attributes:</div>
<ul>
<li class="level2"><div class="li"> <strong><code>refdes</code></strong>: a?</div>
</li>
<li class="level2"><div class="li"> <strong><code>file</code></strong>: The name of the file to include.</div>
</li>
</ul>
</li>
</ol>
</div>
<h5><a name="spice_directive_block" id="spice_directive_block">SPICE directive block</a></h5>
<div class="level5">
<p>
Placing a SPICE directive block into your schematic creates an arbitrary block of SPICE code in the netlist. The directive may be either statements held in a file, or a one-line string held in the “model” attribute. Examples of situations where this is useful include:
</p>
<ul>
<li class="level1"><div class="li"> .TEMP statement</div>
</li>
<li class="level1"><div class="li"> .IC statement</div>
</li>
<li class="level1"><div class="li"> Other SPICE statements for which gschem has no symbol.</div>
</li>
</ul>
<p>
To place a SPICE directive on your schematic, do the following:
</p>
<ol>
<li class="level1"><div class="li"> Place a SPICE directive block on your schematic. (Do “Add” → “Component” → “spice” → “spice-directive-1.sym”)</div>
</li>
<li class="level1"><div class="li"> Double click on the block and add/edit the following attributes:</div>
<ul>
<li class="level2"><div class="li"> <strong><code>refdes</code></strong>: a?</div>
</li>
<li class="level2"><div class="li"> <strong><code>file</code></strong>: The name of the file to include.</div>
</li>
</ul>
</li>
</ol>
</div>
<!-- SECTION "Gschem attributes for spice netlisting" [7283-18697] -->
<h3><a name="handling_hierarchical_models" id="handling_hierarchical_models">Handling hierarchical models</a></h3>
<div class="level3">
<p>
In SPICE modeling, there are often situations where you wish to create a schematic representation of some particular component as a .SUBCKT, and then embed that component’s model in a higher level schematic. A common example might be as follows: You are doing a microwave simulation, and want to use a capacitor model which includes parasitic inductances and resistances, as well as the capacitance. Capacitor manufacturers often supply a printed schematic showing a circuit topology incorporating parasitics, and specify values for the parasitics. You would like to draw the capacitor model using gschem, netlist it to create a .SUBCKT, and then use the .SUBCKT to model capacitors in a higher lever schematic.<br/>
Since this kind of task is very common in SPICE simulation, gnet-spice-sdb now supports it (starting with rev 20030331). To create a lower level .SUBCKT and use it in a higher level schematic, do the following:
</p>
<ol>
<li class="level1"><div class="li"> Draw the schematic of the lower level component (e.g. the capacitor + parasitics) using gschem.</div>
</li>
<li class="level1"><div class="li"> On the lower level schematic, place a spice-subcircuit-LL block (spice-subcircuit-LL-1.sym). This alerts the netlister that the schematic is a Lower Level .SUBCKT. Attach the following attributes to the symbol:<br/>
<br/>
<strong><code>model-name</code></strong> = cap_with_parasitics<br/>
<br/>
(Of course, “cap_with_parasitics” is the example we use here. Use your own model name in your schematic.) Upon netlisting, this schematic symbol will cause the netlist to insert ".SUBCKT cap_with_parasitics " into the first line of the netlist file.</div>
</li>
<li class="level1"><div class="li"> On the lower level schematic, attach a spice-subcircuit-IO symbol (spice-subcircuit-IO-1.sym) to each IO net (i.e. connection to the upper level). Number the refdeses of the IO symbols in the same order as you would like the IO nets to be listed in the .SUBCKT line in the output file. (i.e. P1 = first, P2 = second, etc.)</div>
</li>
<li class="level1"><div class="li"> When you are done with the lower level schematic, netlist it in the usual way. For example, if your schematic is called cap_with_parasitics.sch, netlist it by saying:<br/>
<br/>
<strong><code>gnetlist -g spice-sdb -o cap_with_parasitics.cir cap_with_parasitics.sch</code></strong><br/>
<br/>
This will dump the SPICE netlist into the file called “cap_with_parasitics.cir”. Visually inspect the .cir file to make sure that netlisting worked correctly.</div>
</li>
<li class="level1"><div class="li"> Next, create a symbol for the upper level schematic which will point to the .SUBCKT. Note that the symbol must have a refdes starting with the letter “X”. To ensure that this happens, do the following:</div>
<ul>
<li class="level2"><div class="li"> Use gschem to draw the symbol. I usually draw a box around a model symbol to distinguish it from a normal component. Make any other annotations desired.</div>
</li>
<li class="level2"><div class="li"> In the symbol, make sure that the pins are ordered identically to the order in which you have placed the pins in the .SUBCKT. This is done by editing the symbol with a text editor and setting the “PINSEQ” attribute. The netlister will output the pins in the order determined by the “PINSEQ” attribute.</div>
</li>
<li class="level2"><div class="li"> Using a text editor, give the symbol a “DEVICE” attribute like “capacitor-model”. Do not assign the symbol one of the native device types listed in the appendix! The goal is to create a symbol whose refdes starts with “X”, and if the “DEVICE” is a recognized type, this will not happen.</div>
</li>
<li class="level2"><div class="li"> Using a text editor, give the symbol the “REFDES” attribute “X?"</div>
</li>
</ul>
</li>
<li class="level1"><div class="li"> Create the upper level schematic. Place your newly created symbol on the schematic as many times as required & wire up the schematic in the usual way.</div>
</li>
<li class="level1"><div class="li"> To point your symbol to the lower level .SUBCKT, double click on the symbol and set the following attributes:<br/>
<br/>
<strong><code>file</code></strong> = cap_with_parasitics.cir<br/>
<strong><code>model-name</code></strong> = cap_with_parasitics<br/>
<br/>
as well as any other attributes required (e.g. refdes).</div>
</li>
<li class="level1"><div class="li"> Now netlist your upper level schematic the usual way. The contents of each .SUBCKT file is dumped into the main netlist. Inspect your netlist visually using a text editor to ensure that it is correct. It is a good idea to pay particular attention to the following:</div>
<ul>
<li class="level2"><div class="li"> Verify that the ordering of the nets connecting the upper level netlist to the lower level .SUBCKT is correct.</div>
</li>
<li class="level2"><div class="li"> Make sure that the upper level model-name and the lower level model name (on the .SUBCKT declaration line) are the same.</div>
</li>
</ul>
</li>
</ol>
<p>
Once the netlist is created, you may simulate your design using any SPICE simulator desired.<br/>
</p>
<p>
One final note: The netlister writes the contents of the lower level .SUBCKT file into the main netlist <strong>every time</strong> it encounters a component with “FILE” attribute pointing to that file. Therefore, if you use the same component with the same model more than once in a design you should instantiate the model file using a “spice-model” symbol and point to it with each component. This is described in the “multi-line SPICE model block” section above.
</p>
</div>
<!-- SECTION "Handling hierarchical models" [18698-23545] -->
<h2><a name="spice_netlist_generation" id="spice_netlist_generation">SPICE netlist generation</a></h2>
<div class="level2">
<p>
Once the schematic is captured, a SPICE netlist can be generated running the gEDA utility “gnetlist” on the schematic files. Gnetlist is built to be customizable, and is able to generate a netlist of any desired format using a Scheme back-end, which does the real heavy-lifting of creating the netlist. The back-end Scheme file which implements SPICE netlisting is called gnet-spice-sdb.scm, and it lives in the ${PREFIX}/geda/share/gEDA/scheme directory.
</p>
</div>
<!-- SECTION "SPICE netlist generation" [23546-24039] -->
<h2><a name="creating_the_netlist" id="creating_the_netlist">Creating the netlist</a></h2>
<div class="level2">
<p>
Creating a netlist from a schematic is easy. To generate a SPICE netlist, just do the following:
</p>
<ul>
<li class="level1"><div class="li"> Save your schematic to <filename.sch></div>
</li>
<li class="level1"><div class="li"> Create the SPICE netlist by doing “gnetlist –g spice-sdb <filename.sch>". The output is a netlist held in the file output.net. Alternatively, if you wish to give your output file a different name, set the output name using the -o switch. For example:<br/>
<br/>
<strong><code>gnetlist -g spice-sdb -o amplifier.cir amplifier.sch</code></strong> <br/>
<br/>
takes the design schematic called “amplifier.sch” and outputs a SPICE netlist named “amplifier.cir”.</div>
</li>
<li class="level1"><div class="li"> Inspect your SPICE netlist using a text editor. Verify that there are no missing attributes or other netlist problems.</div>
</li>
</ul>
</div>
<!-- SECTION "Creating the netlist" [24040-24765] -->
<h2><a name="common_netlisting_problems" id="common_netlisting_problems">Common netlisting problems</a></h2>
<div class="level2">
<p>
It is important to manually inspect your SPICE netlist prior to using it in simulation. Please remember that the netlister is still “alpha” quality, and some problems may still exist in netlist generation. The following list attempts to catalog common problems with the netlist and the associated fixes.
</p>
<ul>
<li class="level1"><div class="li"> ERROR_INVALID_<acronym title="Personal Identification Number">PIN</acronym>: This can happen if the symbol’s PINSEQ attributes don’t start at 1, or have gaps in the numbering. This must be fixed by editing the symbol itself in a text editor.</div>
</li>
</ul>
</div>
<!-- SECTION "Common netlisting problems" [24766-25301] -->
<h2><a name="spice_simulation" id="spice_simulation">SPICE simulation</a></h2>
<div class="level2">
<p>
There are several options for doing SPICE simulations under Linux; I will highlight two:
</p>
<ul>
<li class="level1"><div class="li"> <strong>LTSpice</strong>, which is a freeware SPICE simulator originally released by Linear Technologies as a component selection/design tool running under Windows. Because its SPICE engine is very fast and powerful, it has become a popular SPICE simulator amongst hobbyists and design engineers who prefer to use free tools. LTSpice has been tweaked to run under Linux using wine; I recommend using it if you need a robust, <strong>professional-quality</strong> SPICE simulator.</div>
<ul>
<li class="level2"><div class="li"> <strong>Ngspice/tclspice</strong>, which is a component of the gEDA distribution. Ngspice provides a simulation engine, a command-line driven front-end, and the capability to plot simulation results graphically under X. The main branch of ngspice development has been arrested since late 2001. However, a fork of the development tree, called “tclspice”, remains under active development. Tclspice is the package I recommend if you want to use a <strong>Linux-native</strong> SPICE simulator. </div>
</li>
</ul>
</li>
</ul>
<p>
There is also a <acronym title="GNU General Public License">GPL</acronym>‘ed simulator called “gnucap”, which is based upon (or is the descendent of) Al’s Circuit Simulator (ACS). I haven’t used it at all; information about gnucap is therefore TBD.
</p>
</div>
<!-- SECTION "SPICE simulation" [25302-26547] -->
<h3><a name="ltspice" id="ltspice">LTSpice</a></h3>
<div class="level3">
<p>
LTSpice was written by Mike Englehardt at Linear Technologies, and was originally 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.<br/>
LTSpice was originally developed to run under Windows, but Mike has tweaked it so that it runs fairly well on 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.
</p>
</div>
<h4><a name="installation_and_configuration_of_ltspice" id="installation_and_configuration_of_ltspice">Installation and configuration of LTSpice</a></h4>
<div class="level4">
<p>
To install and configure LTSpice, do the following:
</p>
<ol>
<li class="level1"><div class="li"> Download and install wine. I have had success using Wine-20030219.</div>
</li>
<li class="level1"><div class="li"> Download LTSpice. It is available under <a href="http://www.linear.com/software" class="urlextern" title="http://www.linear.com/software" rel="nofollow">http://www.linear.com/software</a> under the name SwitcherCAD-III.</div>
</li>
<li class="level1"><div class="li"> Run the LTSpice installer under wine.</div>
</li>
</ol>
</div>
<h4><a name="running_ltspice_with_geda_designs" id="running_ltspice_with_geda_designs">Running LTSpice with gEDA designs</a></h4>
<div class="level4">
<p>
LTSpice can read a file holding a gEDA SPICE netlist. I have had success doing LTSpice sumulations in the following way:
</p>
<ol>
<li class="level1"><div class="li"> First of all, make sure that you are logged in as a normal user – Wine doesn’t like to run when invoked by root.</div>
</li>
<li class="level1"><div class="li"> Create a file in your project directory called “Simulation.cmd”. In this file place your spice analysis commands (e.g. .OP, .AC, .DC, etc.)</div>
</li>
<li class="level1"><div class="li"> Place a SPICE include block into your schematic. For the file attribute, type in “Simulation.cmd”.</div>
</li>
<li class="level1"><div class="li"> Netlist your design.</div>
</li>
<li class="level1"><div class="li"> 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</div>
</li>
<li class="level1"><div class="li"> Run LTSpice: cd into the directory where SwCADIII lives and say “wine scad3.exe”</div>
</li>
<li class="level1"><div class="li"> From the SwCADIII <acronym title="Graphical User Interface">GUI</acronym>, do: File → Open → (files of type netlist [.cir]), and select your file.</div>
</li>
<li class="level1"><div class="li"> Run the simulator by clicking on the run button, or doing: Simulate → Run.</div>
</li>
<li class="level1"><div class="li"> Select the variables to graph, and then click OK. SwCADIII does the rest of the work.</div>
</li>
</ol>
<p>
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.
</p>
</div>
<!-- SECTION "LTSpice" [26548-29363] -->
<h3><a name="ngspice_and_tclspice" id="ngspice_and_tclspice">Ngspice and tclspice</a></h3>
<div class="level3">
<p>
Ngspice was started at the University of Rome by Paolo Nenzi as an attempt to create a <acronym title="GNU General Public License">GPL</acronym>‘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 <a href="http://ngspice.sourceforge.net/" class="urlextern" title="http://ngspice.sourceforge.net/" rel="nofollow">ngspice website</a>. Unfortunately, development on ngspice seems to have ceased at the end of 2001. Moreover, my initial experiences with ngspice were not good – it crashed and burned when run on many of my netlists, and it couldn’t deal with SPICE 2’s POLY construct in dependent sources. Dependent sources with PLOY attributes are common in vendor models, so this represents a real deficiency.
</p>
<p>
Fortunately, some friendly people at <a href="http://www.multigig.com/" class="urlextern" title="http://www.multigig.com" rel="nofollow">MultiGig Ltd.</a> were busy developing a branch of ngspice which they called “tclspice”. The purpose of tclspice is to enable SPICE commands to be embedded into TCL scripts, thereby enabling automated circuit optimization. The project homepage is at <a href="http://tclspice.sourceforge.net/" class="urlextern" title="http://tclspice.sourceforge.net/" rel="nofollow">http://tclspice.sourceforge.net/</a>. Since the tclspice branch of the code was alive, I decided to work on it, instead of the seemingly dead main ngspice branch. During spring 2003, I fixed tclspice in three useful (IMNSHO) ways:
</p>
<ol>
<li class="level1"><div class="li"> I fixed the parser so that it would handle netnames with non-numeric/non-alphabetic characters like "+" or "-" which are common in real netlists (e.g. “Vin+", or “Vout1_pull-up”).</div>
</li>
<li class="level1"><div class="li"> I fixed the parser so that it would correctly handle hierarchical schematics, and correctly deal with the netnames inside the blocks.</div>
</li>
<li class="level1"><div class="li"> I got the POLY translation code (which exists in XSPICE) working so that one can now run SPICE 2 netlists with tclspice.</div>
</li>
</ol>
<p>
Tclspice seems to work nicely now (although there are still some issues with memory leaks). Moreover, because the tclspice code is a superset of ngspice, <strong>if you build tclspice, you will also build the command-line driven ngspice program</strong>. Therefore, I recommend getting and installing tclspice if you want to do Linux-native SPICE simulations.
</p>
</div>
<h4><a name="installation_and_configuration_of_ngspice_and_tclspice" id="installation_and_configuration_of_ngspice_and_tclspice">Installation and configuration of ngspice and tclspice</a></h4>
<div class="level4">
<p>
To install ngspice and tclspice, do the following:
</p>
<ol>
<li class="level1"><div class="li"> Get the latest tclspice distribution from <a href="http://tclspice.sourceforge.net/" class="urlextern" title="http://tclspice.sourceforge.net/" rel="nofollow">http://tclspice.sourceforge.net/</a>. As of this writing, the latest version is tclspice-0.2.12. This version incorporates the fixes I mentioned above, as well as other improvements made by the hard-working people at MultiGig, so make sure that your version is equal or greater than 0.2.12.</div>
</li>
<li class="level1"><div class="li"> Do the usual “gunzip ; tar -xvf” dance to create a source directory for tclspice.</div>
</li>
<li class="level1"><div class="li"> First build ngspice. Do "./configure –enable-xspice –prefix=/usr/local/geda” in the source directory. Of course, "–prefix=" should point to the place where you put your geda stuff. Note that you also must do "–enable-xspice” to be able to use SPICE 2 POLYs (and other XSpice goodies).</div>
</li>
<li class="level1"><div class="li"> Do “make && make install” to compile and install ngspice. As always, you will probably need to be root in order to install the packages in a public directory.</div>
</li>
<li class="level1"><div class="li"> 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. Information how to use ngspice is provided in the next section below.</div>
</li>
<li class="level1"><div class="li"> If you only want to use ngspice, you can stop now. Otherwise, next build tclspice. To build tclspice, you need to have the following other packages already installed:<br/>
<br/>
* TclX (tclx8.3.5 works for me.)<br/>
* tclreadline (tclreadline-2.1.0 works for me.)<br/>
* BLT for TCL (blt2.4z works for me.)<br/>
<br/>
If you don’t have these packages already on your Linux box, you need to get them 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.</div>
</li>
<li class="level1"><div class="li"> Assuming you have gotten the additional packages mentioned above installed, Do "./configure –enable-xspice –prefix=/usr/local/geda –enable-tcl –enable-experimental –disable-shared” to configure the Makefiles for tclspice. (If you don’t have the additional packages installed correctly , configure will complain and barf, so this step acts as a check on your installation.)</div>
</li>
<li class="level1"><div class="li"> Do “make tcl && make install-tcl” to compile and install tclspice.</div>
</li>
<li class="level1"><div class="li"> Now you will be ready to write TCL scripts which incorporate SPICE commands. Information about using tclspice is given below.</div>
</li>
</ol>
<p>
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.
</p>
</div>
<h4><a name="use_of_ngspice" id="use_of_ngspice">Use of ngspice</a></h4>
<div class="level4">
<p>
Running ngspice is very simple. Just issue the command “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 <a href="http://newton.ex.ac.uk/teaching/CDHW/Electronics2/userguide/sec5.html#5" class="urlextern" title="http://newton.ex.ac.uk/teaching/CDHW/Electronics2/userguide/sec5.html#5" rel="nofollow">http://newton.ex.ac.uk/teaching/CDHW/Electronics2/userguide/sec5.html#5</a>.<br/>
To make use of the SPICE2 POLY codemodel, you need to load it into ngspice <strong>before</strong> 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/src/tclspice-0.2.12/src/xspice/icm/spice2poly.cm” at the ngspice prompt. Note that you must provide the <strong>absolute path</strong> 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.)<br/>
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.
</p>
</div>
<h4><a name="use_of_tclspice" id="use_of_tclspice">Use of tclspice</a></h4>
<div class="level4">
<p>
The tclspice package is a superset of ngspice. Not only does the package include the ngspice interactive environment; tclspice also provides a facility which exports the ngspice command set as TCL commands for inclusion into a TCL script. 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.<br/>
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 namesapce. 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:
</p>
<pre class="code">#! 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!"</pre>
<p>
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 <a href="http://tclspice.sourceforge.net/docs/tclspice_com.html" class="urlextern" title="http://tclspice.sourceforge.net/docs/tclspice_com.html" rel="nofollow">http://tclspice.sourceforge.net/docs/tclspice_com.html</a>.<br/>
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.<br/>
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:
</p>
<pre class="code">#! 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!!!!!!"
}
}</pre>
<p>
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 kernal’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”!<br/>
This method of waiting a specific amout of time for the child process is preferable if a single analysis run takes a relativly 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.
</p>
</div>
<!-- SECTION "Ngspice and tclspice" [29364-40393] -->
<h2><a name="appendix" id="appendix">Appendix</a></h2>
<div class="level2">
</div>
<!-- SECTION "Appendix" [40394-40415] -->
<h3><a name="component_attribute_summary" id="component_attribute_summary">Component attribute summary</a></h3>
<div class="level3">
<p>
Native components and their attributes are given in the table below. <strong>Bold faced</strong> attributes are <strong>required</strong>, normal typeface attributes are optional. Note that the “device” attribute is invisible, and is normally attached to the symbol when it is created. The other attributes are attached to the symbol during schematic capture using gschem.
</p>
<table class="inline">
<tr>
<th><strong><code>device</code></strong></th><th><strong><code>refdes</code></strong></th><th><strong><code>value</code></strong></th><th><strong><code>model</code></strong></th><th><strong><code>file</code></strong></th><th><strong><code>model-name</code></strong></th><th><strong><code>type</code></strong></th><th>Comment</th>
</tr>
<tr>
<td><strong>RESISTOR</strong></td><td><strong>R?</strong></td><td><strong>Numeric comp. value</strong></td><td>One line of spice model parameters (e.g. TC)</td><td> </td><td>Name of model.</td><td> </td><td>“model” parameters are placed inside parentheses after the component value.</td>
</tr>
<tr>
<td><strong>CAPACITOR</strong></td><td><strong>C?</strong></td><td><strong>Numeric comp. value</strong></td><td>One line of spice model parameters (e.g. IC, POLY, etc.)</td><td> </td><td>Name of model.</td><td> </td><td>“model” parameters are placed inside parentheses after the component value.</td>
</tr>
<tr>
<td><strong>POLARIZED_CAPACITOR</strong></td><td><strong>C?</strong></td><td><strong>Numeric comp. value</strong></td><td>One line of spice model parameters (e.g. IC, POLY, etc.)</td><td> </td><td>Name of model.</td><td> </td><td>“model” parameters are placed inside parentheses after the component value.</td>
</tr>
<tr>
<td><strong>INDUCTOR</strong></td><td><strong>L?</strong></td><td><strong>Numeric comp. value</strong></td><td>One line of spice model parameters (e.g. IC, POLY, etc.)</td><td> </td><td>Name of model.</td><td> </td><td>“model” parameters are placed inside parentheses after the component value.</td>
</tr>
<tr>
<td><strong>SPICE-ccvs</strong></td><td><strong>H?</strong></td><td><strong>String describing source behavior</strong></td><td> </td><td> </td><td> </td><td> </td><td> </td>
</tr>
<tr>
<td><strong>SPICE-cccs</strong></td><td><strong>F?</strong></td><td><strong>String describing source behavior</strong></td><td> </td><td> </td><td> </td><td> </td><td> </td>
</tr>
<tr>
<td><strong>SPICE-vcvs</strong></td><td><strong>E?</strong></td><td><strong>String describing source behavior</strong></td><td> </td><td> </td><td> </td><td> </td><td> </td>
</tr>
<tr>
<td><strong>SPICE-vccs</strong></td><td><strong>G?</strong></td><td><strong>String describing source behavior</strong></td><td> </td><td> </td><td> </td><td> </td><td> </td>
</tr>
<tr>
<td><strong>SPICE-nullor</strong></td><td><strong>E?</strong></td><td><strong>String describing source behavior</strong></td><td> </td><td> </td><td> </td><td> </td><td> </td>
</tr>
<tr>
<td><strong>DIODE</strong></td><td><strong>D?</strong></td><td>Part number</td><td>One line SPICE model.</td><td>Model file name.</td><td><strong>Name of model.</strong></td><td> </td><td>For modeling, one must include either “model” or “file”.</td>
</tr>
<tr>
<td><strong>PMOS_TRANSISTOR</strong></td><td><strong>M?</strong></td><td>Part number</td><td>One line SPICE model.</td><td>Model file name.</td><td><strong>Name of model.</strong></td><td> </td><td>For modeling, one must include either “model” or “file”.</td>
</tr>
<tr>
<td><strong>NMOS_TRANSISTOR</strong></td><td><strong>M?</strong></td><td>Part number</td><td>One line SPICE model.</td><td>Model file name.</td><td><strong>Name of model.</strong></td><td> </td><td>For modeling, one must include either “model” or “file”.</td>
</tr>
<tr>
<td><strong>PNP_TRANSISTOR</strong></td><td><strong>Q?</strong></td><td>Part number</td><td>One line SPICE model.</td><td>Model file name.</td><td><strong>Name of model.</strong></td><td> </td><td>For modeling, one must include either “model” or “file”.</td>
</tr>
<tr>
<td><strong>NPN_TRANSISTOR</strong></td><td><strong>Q?</strong></td><td>Part number</td><td>One line SPICE model.</td><td>Model file name.</td><td><strong>Name of model.</strong></td><td> </td><td>For modeling, one must include either “model” or “file”.</td>
</tr>
<tr>
<td><strong>PFET_TRANSISTOR (JFET)</strong></td><td><strong>J?</strong></td><td>Part number</td><td>One line SPICE model.</td><td>Model file name.</td><td><strong>Name of model.</strong></td><td> </td><td>For modeling, one must include either “model” or “file”.</td>
</tr>
<tr>
<td><strong>NFET_TRANSISTOR (JFET)</strong></td><td><strong>J?</strong></td><td>Part number</td><td>One line SPICE model.</td><td>Model file name.</td><td><strong>Name of model.</strong></td><td> </td><td>For modeling, one must include either “model” or “file”.</td>
</tr>
<tr>
<td><strong>MESFET_TRANSISTOR</strong></td><td><strong>B?</strong></td><td>Part number</td><td>One line SPICE model.</td><td>Model file name.</td><td><strong>Name of model.</strong></td><td> </td><td>For modeling, one must include either “model” or “file”.</td>
</tr>
<tr>
<td><strong>IC</strong></td><td><strong>U?</strong></td><td>Part number</td><td>One line SPICE model.</td><td>Model file name.</td><td><strong>Name of model.</strong></td><td> </td><td>IC with .MODEL file</td>
</tr>
<tr>
<td><strong>IC</strong></td><td><strong>X?</strong></td><td>Part number</td><td> </td><td>Model file name.</td><td><strong>Name of model.</strong></td><td> </td><td>IC with .SUBCKT file</td>
</tr>
<tr>
<td><strong>model</strong></td><td colspan="2"><strong>A?</strong></td><td>One line spice model</td><td>Model file name.</td><td><strong>Name of model pointed to by other components.</strong></td><td><strong>Corresponding SPICE model type (valid types given below)</strong>.</td><td>For modeling, one must include either “model” or “file”.</td>
</tr>
<tr>
<td><strong>include</strong></td><td><strong>A?</strong></td><td> </td><td> </td><td><strong>Include file name.</strong></td><td> </td><td> </td><td>Places .INCLUDE directive in SPICE netlist.</td>
</tr>
<tr>
<td><strong>options</strong></td><td><strong>A?</strong></td><td><strong>Line of options to include.</strong></td><td> </td><td> </td><td> </td><td> </td><td>Places .OPTIONS directive in SPICE netlist.</td>
</tr>
<tr>
<td><strong>directive</strong></td><td><strong>A?</strong></td><td><strong>One line string holding SPICE statements for inclusion in netlist.</strong></td><td> </td><td> </td><td> </td><td> </td><td>For modeling, one must include either “model” or “file”.</td>
</tr>
<tr>
<td><strong>VOLTAGE_SOURCE</strong></td><td><strong>V?</strong></td><td><strong>One line string holding voltage source behavior.</strong></td><td> </td><td> </td><td> </td><td> </td><td>Independent voltage source</td>
</tr>
<tr>
<td><strong>CURRENT_SOURCE</strong></td><td><strong>I?</strong></td><td><strong>One line string holding current source behavior.</strong></td><td> </td><td> </td><td> </td><td> </td><td>Independent current source</td>
</tr>
</table>
<p>
“Native to the netlister” means that there is a corresponding blob of scheme code which knows exactly how to handle these components and is guaranteed (almost) to generate correct spice code. Symbols having “device” attributes not on the above list are handled using the scheme function “spice-sdb:write-default-component”, which looks at the refdes of the component to make a decision about how to treat the component. In general, this function will “do the right thing” when generating spice code, but it is not guaranteed. In particular, this function cannot distinguish between N and P type transistors, and will generate an <unknown> type for the .MODEL string in the netlist. This will probably cause your SPICE simulator to barf. Therefore, it is best to make sure that all devices used have the proper “device” attribute.
</p>
</div>
<!-- SECTION "Component attribute summary" [40416-45184] -->
<h3><a name="valid_type_values" id="valid_type_values">Valid "type" values</a></h3>
<div class="level3">
<p>
The “type” attribute is a flag signaling the spice engine the component type, and prepares it to accept model parameters specific to that component type. The following values are valid SPICE “type”s:
</p>
<table class="inline">
<tr>
<th>Component</th><th>“type”</th><th>Comment</th>
</tr>
<tr>
<td>RESISTOR</td><td>RES</td><td> </td>
</tr>
<tr>
<td>CAPACITOR</td><td>CAP</td><td> </td>
</tr>
<tr>
<td>POLARIZED_CAPACITOR</td><td>CAP</td><td> </td>
</tr>
<tr>
<td>INDUCTOR</td><td>IND</td><td> </td>
</tr>
<tr>
<td>DIODE</td><td>D</td><td> </td>
</tr>
<tr>
<td>PMOS_TRANSISTOR</td><td>PMOS</td><td> </td>
</tr>
<tr>
<td>NMOS_TRANSISTOR</td><td>NMOS</td><td> </td>
</tr>
<tr>
<td>PNP_TRANSISTOR</td><td>PNP</td><td> </td>
</tr>
<tr>
<td>NPN_TRANSISTOR</td><td>NPN</td><td> </td>
</tr>
<tr>
<td>PFET_TRANSISTOR</td><td>PJF</td><td> </td>
</tr>
<tr>
<td>NFET_TRANSISTOR</td><td>NJF</td><td> </td>
</tr>
<tr>
<td>MESFET_TRANSISTOR</td><td> </td><td> </td>
</tr>
</table>
</div>
<!-- SECTION "Valid type values" [45185-45703] -->
<h2><a name="document_history" id="document_history">Document History</a></h2>
<div class="level2">
<table class="inline">
<tr>
<td>Revision 1.0</td><td>3.10.2003</td><td>SDB</td><td>Document creation.</td>
</tr>
<tr>
<td>Revision 1.1</td><td>3.19.2003</td><td>SDB</td><td>Added .SUBCKT stuff & stuff about LTSpice</td>
</tr>
<tr>
<td>Revision 1.2</td><td>3.31.2003</td><td>SDB</td><td>Added stuff about creating hierarchical projects (i.e. creating .SUBCKTs using gschem and incorporating a lower level .SUBCKT into a higher level schematic).</td>
</tr>
<tr>
<td>Revision 2.0</td><td>7.23.2003</td><td>SDB</td><td>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.</td>
</tr>
</table>
<p>
The most recent copy of this document is always available at <a href="http://www.brorson.com/gEDA/SPICE/" class="urlextern" title="http://www.brorson.com/gEDA/SPICE/" rel="nofollow">http://www.brorson.com/gEDA/SPICE/</a>
</p>
</div>
<!-- SECTION "Document History" [45704-] --></div>
</body>
</html>
distrib
>
Mandriva
>
2010.0
>
i586
>
media
>
contrib-release
>
by-pkgid
>
917b12189aa1c35ab526605d1d1ac12b
>
files
>
272
