1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
|
<html>
<body>
<h1> 10_bjt_amp_tr: model from the library </h1>
<h2> Scope </h2>
<p>
In this simulation we are going to look at a single-transistor amplifier
in the time domain to verify how it amplifies a sine wave.
<h2> The schematics </h2>
<p>
The single-sheet schematic contains the amplifier, the voltage sources and
the spice command symbol.
<p>
<center>
<a href="10_bjt_amp_tr.rs"><img src="10_bjt_amp_tr.svg" width=600px></a>
<br>Click the image to get the sch-rnd sheet</center>
<p>
<h2> How to specify the model </h2>
<p>
In the previous examples all components used were ideal: simple
resistors, capacitors and sources, without any special characteristics
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.
<p>
A model in spice is really two things:
<ul>
<li> the code that implements how to simulate the given thing (e.g. an npn transistor)
<li> a set of parameters for this model which make the behavior match a specific real world device
</ul>
<p>
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).
<p>
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, 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.
<p>
Furthermore there's a sheet-local library, just like with devmap (and
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.
<h2> Preparing for simulation </h2>
<h3> Q1 </h3>
<p>
This is the usual npn symbol from the stock symbol library shipped with
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.
<p>
The spice-specific aspects are the model and the spice pinout. The model
is specified using the spice/model attribute, with value <i>bc817</i>.
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 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).
<p>
The devmap file could contain the symbol's spice/model and portmap to set
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
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; accordingly, this should not be defined
in the devmap.
<p>
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 <a href="../../../user/07_io/export_spice/pinout.html">mechanisms</a>
to deal with different spice pinouts.
<h3> V1 </h3>
<p>
V1 is generating the input sine wave on the <i>in</I> network.
The syntax for this is (see in V1's spice/params):
<pre>
SINE(0 0.01 1k)
</pre>
<p>
The first parameter is the (dc) voltage offset, the second is the
AC amplitude voltage and the third is the frequency in Hz.
<h3> V2 </h3>
<p>
V2 is an 5V DC power supply for Vcc:
<pre>
dc 5
</pre>
<h3> Raw spice commands </h3>
<p>
It contains the following script:
<pre>
tran 1u 10m
plot v(out) v(in)
</pre>
<p>
which runs the simulation for 10 mS, sampling it once a microsecond. At
the end we are plotting the input and output voltages.
<h2> Export and run ngspice </h2>
<p>
Running ngspice the usual way on the export yields the following graph:
<p>
<img src="10_bjt_amp_tr.png">
<h2> Using other implementations </h2>
<h3> gnucap </h3>
<p>
Gnucap uses a different command syntax. Modify the spice command symbol's
spice/command attribute to:
<pre>
print tran v(out) v(in)
tran 1u 10m > plot.txt
</pre>
<p>
After the export, write the single word <b>spice</b> 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 <i>gnucap 10_btj_amp_tr.cir</i> and it will dump a text
table to plot.txt that can be plotted using a suitable utility, e.g. gnuplot.
<p>
The <a href="gnucap/10_btj_amp_tr.rs">gnucap-modified schematic is also available.</a>
<h3> xyce </h3>
<p>
TODO
|
