@@ -21,31 +21,31 @@
In the previous examples all components used were ideal: simple resistors, capacitors and sources, without any special characteristics -or side effects. More complex components, like transistors typically -have a large set of parameters that differ per device type. Spice addresses +or side effects. More complex components such as transistors typically +have a large set of parameters that differ by device type. Spice addresses this by using models.
A model in spice is really two things:
- the code that implements how to simulate the given thing (e.g. an npn transistor) -
- a set of parameters to this model to get the behavior match a specific existing device type +
- a set of parameters for this model which make the behavior match a specific real world device
-The former, the code, is typically provided as part of the simulator software, -at least for the most common, basic component types. The latter, model -parameters, is specified by the user (normally acquired from the device -vendor or constructed from the datasheet or measurements). +The first of these, the code, is typically provided as part of the simulator software, +at least for the most common, basic component types. The second of these, the set of +model parameters, is specified by the user (normally acquired from the device +vendor or derived from the datasheet or actual measurements).
In sch-rnd these models are kept in the spice library, which is very much like the symbol or devmap library: a directory tree that holds spice models, -one model per file, models identified by file name. Spice export files +one model per file, with models identified by file name. Spice export files are self-contained and do not rely on external model files. This is achieved by sch-rnd copying the content of these spice model files from the library into the output file.
Furthermore there's a sheet-local library, just like with devmap (and -optionally with symbols), so any spice model used by the sheet is also saved -in the sheet so the sheet is self-contained (and portable) too. +optionally with symbols), so that any spice model used by the sheet is +also saved within the sheet, keeping the sheet self-contained and portable.
Preparing for simulation
@@ -52,20 +52,20 @@Q1
This is the usual npn symbol from the stock symbol library shipped with -sch-rnd, with devmap set up to bc817_sot23 so the sheet can be used in -a PCB workflow as well. +sch-rnd. The devmap has been set to bc817_sot23 so that the sheet can also +be used in a PCB workflow with a sot23 footprint as well.
The spice-specific aspects are the model and the spice pinout. The model is specified using the spice/model attribute, with value bc817. There is a file in the spice model library shipped with sch-rnd called bc817.prm. The pinout is set by the spice/pinnum terminal attributes. -For the BJT model of spice the pinout is always the same, so the stock +For the BJT spice model the pinout is always the same, so the stock library symbol has this attribute hardwired in terminals with a low priority (so that it can be overridden by other mechanisms).
The devmap file could contain the symbol's spice/model and portmap to set -spice/pinnum for each terminal. The former is a bad idea because there may be -different spice models for different complexity of simulation. Simple models, +spice/pinnum for each terminal, but this is not a good idea because there may be +different spice models for different complexities of simulation. Simple models, like bc817.prm, concentrate only on the core of the functionality, while more complex models implemented as "subcircuits" (subckt in spice slang) may add parasitic effects, such as pin inductances and pin/package @@ -72,13 +72,14 @@ related stray capacitances. Such complex models run slower, but may be more accurate in some cases, while the simpler model would cover most of the normal use cases. The user needs to decide which model to use for the given -circuit or even the given simulation, this should not be coming from the devmap. +circuit or even the given simulation; accordingly, this should not be defined +in the devmap.
Specifying the spice pinout from the devmap is unnecessary if both the model and the symbol use the standard spice BJT pinout that matches the model code in spice. However, for subcircuit models the pinout may differ, and sch-rnd offers multiple mechanisms -to deal with spice pinouts. +to deal with different spice pinouts.
V1
@@ -108,7 +109,7 @@ plot v(out) v(in)-which runs the simulation for 10 mS sampling it once a microsecond. At +which runs the simulation for 10 mS, sampling it once a microsecond. At the end we are plotting the input and output voltages.
Export and run ngspice
@@ -127,12 +128,12 @@ tran 1u 10m > plot.txt-After the export, write a single word spice in the first line of the -file (e.g. using a text editor), else gnucap won't know the file is in spice +After the export, write the single word spice in the first line of the +file (e.g. using a text editor), otherwise gnucap won't know the file is in spice syntax. Then run gnucap 10_btj_amp_tr.cir and it will dump a text -table to plot.txt that can be plotted using e.g. gnuplot. +table to plot.txt that can be plotted using a suitable utility, e.g. gnuplot.
-The gnucap-modified schematics is also available. +The gnucap-modified schematic is also available.
xyce