-
Notifications
You must be signed in to change notification settings - Fork 10
/
index.html
281 lines (245 loc) · 10.2 KB
/
index.html
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
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>spicelib: modellibrary for gEDA</title>
</head>
<body>
<h1>spicelib: modellibrary for gEDA</h1>
spicelib is a collector and testing framework to get models from
vendors and create a tested spice model library.
<h2>Downloading the spice models</h2>
Some vendors provide spicemodels in the internet. Usually you are
allowed to use them but your not allowed to distribute them. Thus
everybody has to maintain his own model library. To avoid the
distribution of the model files itself, the spicelib package
contains all instructions to download and create a local model
library. <p></p>
The following steps describe howto create a local model
library. All steps are inside the toplevel Makefile.<p></p>
<table>
<tbody>
<tr>
<td>
<img alt="component selector with the spicelib" src="bitmaps/spicelib_creation.png" hspace="20">
</td>
<td valign="top">
<ul>
<li> <b>downloading</b> can be done using wget, curl or
a similar command line program. If the vendor only
provides single modelfiles, it might be necessary to
write a more sophisticated crawler script to download
the models.
</li>
<li> <b>unpack: </b> If the vendor provides zip files or
tar archives this is the step to extract the files out
of it. Sometimes a vendor may even provide zip-files
that contain zips and you have to extract the archives
multiple times.
</li>
<li> <b>checksums: </b> The checksums are created to
make maintainance of the spice library easier. If you
download and extract the spice library archives a second
time, you can easily find out which files have been
changed by the vendor. You can store that file in and
SCM system or create golden checksum files of reviewed
models.
</li>
<li> <b>creating local libraries: </b> The vendor model
files are now in a cluttered temporary storage. There
are several useless files in that storage and some of
the spice files have stupid syntax errors or are
incompatible with your circuit simulator. In this step
the models are moved to a ordered library structure and
the erroneous models can be fixed with patches or other
command line tricks.
</li>
<li> <b> local checksums:</b> The last step is another
set of checksums. This checksums help to detect errors
in the above steps. Example: If you fix a model in the
previous step the checksum will change. After the change
you can manually verify the fix and move the new checksum
to your SCM or golden checksum storage.
</li>
</td>
</tr>
</tbody>
</table>
<h2>Connecting the spicelib to libgeda with gedaparts</h2>
<b>gedaparts</b> is a python script that connects the spice library to libgeda.<p></p>
<table>
<tbody>
<tr>
<td>
<img alt="spicelib/gEDA overview sketch" src="bitmaps/spicelib_overview.png" hspace="20">
</td>
<td valign="top">
The spicelib is connected to gEDA with a scm script. The
script defines how libgeda has to call gedaparts
script. The geda-parts.scm script is located in the
<i>$INSTALLDIR/share/gEDA/gafrc.d/</i> directory. libgeda
calls all scripts inside that directory at startup. <br>
There are two command to access the spicelib through the geda-parts.scm:
<ul>
<li> <b> list command:</b> When calling this command,
gedaparts returns a list off all parts inside a given
library. The list is extracted out of a given indexfiles.
</li>
<li>
<b> part command: </b> When calling this command with
a partname option, gedaparts will lookup that part in
a additionally given library indexfile. Inside the
indexfiles is a variable that defines which symbol
template gets used. The gedapart script combines the
symbol template and a set of variables to a valid gEDA
symbol and returns the symbol to libgeda.
</td>
</tr>
</tbody>
</table>
<br>
<table>
<tbody>
<tr>
<td>
<img alt="component selector with the spicelib" src="bitmaps/component_selector.png" hspace="20">
</td>
<td valign="top">
The connected spicelib files can be used with gschem
now. <br> libgeda loads the libraries at startup and
you'll be able to select the parts from the component
chooser.
</td>
</tr>
</tbody>
</table>
<h2>Tests for the spice library and the spice models</h2>
The picture below shows how the current test setup works. The
library tester takes the indexfiles that contain the part
descriptions. The tester walks through the index files an runs
the appropriate test with every part.
The tester creates a summary htmlfile for each library. <p></p>
Each test template consists of
<ul>
<li> a template schematic </li>
<li> a script that runs all simulations steps (currently written in python)</li>
<li> a file with circuit simulation commands either for gnucap or ngspice </li>
<li> a html template file for the test simulation results </li>
</ul>
The tester first prepares the test schematic with the current
part. It copies all required files to the test directory which is
provided in the head of the library index file. And finally the
tester executes the tester script. <p></p>
<table>
<tbody>
<tr>
<td>
<img alt="model test overview for the spicelib" src="bitmaps/spicelib_test.png" hspace="20">
</td>
<td valign="top">
The test script runs all commands for one test. e.g. to test a bipolar transistor.
<ul>
<li> <b>generate netlist:</b> With the gnetlist call,
gnetlist gets the parts to test from the spicelib
through libgeda and gedaparts. The gnetlist backend
spice-sdb takes the netlist and the attributes of the
test part. It gets the spice model from the spice model
library that is referenced inside the tested part. The
output of gnetlist is a spice netlist.
</li>
<li> <b>run simulation:</b> The test calls the simulator
with provided netlist file and the simulation command
file. The output of the simulation is on or more data files.
</li>
<li> <b>post processing:</b> The test script
postprocesses the simulation data and creates plot
images. As the test script is written in python I can
use numpy and matplotlib (pylab) for the testing and
plotting actions. Several tests are possible:
<ul>
<li> has the simulator created data files or did the simulation fail?</li>
<li> are the simulation results within expected ranges? <br>
e.g. saturation voltage should be positive but not larger than 1.0 voltage</li>
</ul>
<li> <b>generate result file:</b> The test result file
contains a summary of the simulations. All plots are
linked together in a html file. Links to the datasheet,
the model files and some additional metadata about the
tested parts are inserted too. <br> <b> Note:</b> This
file is currently created by the library tester. Thus
it's possible to create that file even if the test script
crashes.
</li>
</td>
</tr>
</tbody>
</table>
<p></p>
All test results and some of the test definitions are linked in
the <a href="../model_tests/spicelib.html">toplevel file</a> in the
test directory.
<h2> Run model tests </h2>
There are differnt ways to run the model tests. All test methods
rely on the tester library <b>scripts/testlibrary.py</b>.
<h3> Command line usages of the tester</h3>
You can use the commandline of the tester to run tests on a single
part or on all parts with a given status.
<table>
<tbody>
<tr>
<td bgcolor="#BBBBBB">
<pre>/spicelib> scripts/testlibrary.py --help
usage is:
-i --index libraryname1 [libraryname2, ..]
-t --test libraryname1 [libraryname2, ..]
-p --part libraryname partname1 [partname2, ..]
-s --status status: check/list only one given status
-c --checksum checksum: check/list only one checksum status</pre>
</td>
</tr>
</tbody>
</table>
<h3> use scons system </h3>
With scons test you can run tests on all devices automatically.
<h3> use the tester gui</h3>
When doing manual model testing, it's good to have all
informations about one device on the screen. To run the gui, just
call it with an indexfile on command line:
<table>
<tbody>
<tr>
<td bgcolor="#BBBBBB">
<pre>> ./scripts/testlibrarygui.py indexfiles/national_opamps.index</pre>
</td>
</tr>
</tbody>
</table>
<p>
<img src="bitmaps/testlibrarygui.png"> <p>
On the left side all devices of the index file are listed. <br> If
you select one device, then you'll see the model text in the
center text widget. <br> On the right top side you'll see the
device definition. You can edit that section to modifiy the
definition. <p>
With the buttons and colored status messages you can run model tests.
If the <b>model checksum</b> is not the same as in the golden
checksum files. You can sign the model. <p>
The button <b>test model definition</b> runs the tests with all
simulators for that device. <b><<</b> and <b>>></b>
will show the next device. <p>
The results of the model test is shown below the simulator. The
<b>view</b> buttons will show the detailed simulation results in a
browser. <p>
With the button <b>good</b> and <b>broken</b> you can give a
manual rating of the model. This will update the fields
<i>model_status_good</i> and <i>model_status_bad</i> in the device
definition.
<h2> Development</h2>
The development of spicelib is hosted at github: <a href="https://github.com/werner2101/spicelib/">github.com/werner2101/spicelib</a>.
<hr>
<address><a href="mailto:[email protected]">Werner Hoch</a></address>
<!-- Created: Sat Dec 29 09:54:35 CET 2007 -->
<!-- hhmts start -->
Last modified: Sun Mar 24 12:04:17 CET 2013
<!-- hhmts end -->
</body>
</html>