Re: [ng-spice] Command language
>From: Paolo Nenzi <pnenzi@ieee.ing.uniroma1.it>
>On Fri, 13 Aug 1999, James Swonger wrote:
> > Command lanuguage is something I'd also like to expand upon,
> > but I'll save that for another time. Suffice to say that for
> > hard-core design, being able to script execution, parameterize
> > models and control automatic instantiation of components, and
> > extract results, the command language is what makes the tool
> > high-leverage - beyond single-point circuit simulation.
>
>Spice already have scripting capabilites, it's interactive interface is
>built uopn a c-shell and you can start it with a control file". Can you be
>more specific ?
>
>Paolo
I should say that I haven't been using SPICE3 for my work, so
my understanding of its improvements over SPICE2, and how much
of what I'm looking for is already implemented, is not great.
I'm used to working with a command language that has a lot of
access to the input and output of the simulator. This includes
allowing parameter passing and variables/functions within
.MODEL cards, access to analysis and operating point results
via variables, definition of and operations on arrays, etc.
Models: being able to put the model statements inside a
called file gives you the flexibility to do things like
geometry-dependent (parameterized) device models for
all devices (unlike MOS, which have L= and W=, BJT and
diode models support only a crude AREA term which does
not work well for operating regions where Rb, Rc are
significant factors, nor does it accurately affect junction
cap geometry dependence.
Here's what I can do with cdsSpice: geometry and process
dependent models with per-device mismatch.
usem rsgqn1 Q1 1 2 3 11 16 11
rsgqn1.m file is invoked, parameters Q1 ... 11 passed as &1 ... &7.
rsgqn1.m:
&1 &2 &3 &4 &1 (instantiates device, Q1 1 2 3 Q1)
.model &1 NPN BF=mp("kbfn")*mmbfn(&5,&6) IS=mp("kjsn")*&5*&6
+ RC=rcn1(mp("knepir"),&5,&6,&7)) ....
(basic params depend on process variables/functions and
geometry args, mismatch functions)
You can get to very detailed representation of geometry,
temperature (leave the temp set to 27, and use a second variable
as a pointer to temperature functions if you're not satisfied
with SPICE's temperature functions), enable and disable
random process and mismatch variations, and so on. This is
what we do as part of validating product designs.
On the output side, the result of interest is often not the
simple analysis voltage or current result. For example, in
transient analysis I'm often interested in things like
settling time. I'd run an analysis and then want to derive
some values from the output vector. In my simulator, the
analysis results are accessible as arrays (or more like
functions, I guess, because there is interpolation between
explicit timepoints to as fine a granularity as I've
ever used). Voltage is obtained as v(node) at whatever the
value of the sweep variable is set to (this could be TIME,
or V13 (DC analysis swept V13 element). Typically, I'd write
a little .s file (this being the suffix foe both subcircuit
and executable files that the simulator would go and look
for by root name along its search path).
tsettle.s
set time=0 vinit=v(ampOut)
set time=10u vfinal=v(ampout)
loop time from 0 to 500n by 1n
if v(vin)>2.5 then break
endloop
set tin=time
set errh=vfinal+1m errl=vfinal-1m
loop time from 10u to 500n by -1n
if v(ampOut)>errh or v(ampOut)<errl then break
endloop
if time=10u or time=500n
then set tsettle=-999
else set tsettle=time-tin
print "settling time = " tsettle
This little script might also be called on as part of the guts
or a much larger activity, say, a 50 iteration * 3 temperature
Monte Carlo job; for each iteration, the settling time along
with other loop index and results data would be appended to
a data file, for later crunching (also using the simulator
native language statistics and plotting features; I often did
things like scatter plots of one job's AC results vs. another's
supply current, etc.
File I/O, being able to read, skip, print data, is also very
good to have. Getting stored data to & from the variable / array
space, not just a "printvs" of results vectors.
Finally, but of primary importance, is the ability to define,
and redefine, the search paths for model/data/executable
files. There should be multiple entries allowed, with
search taking the first occurence encountered, not just a
single home directory. This enables things like having
both generic component and process-related component
libraries in separate locations, as well as the user's own
script library; the ability to redefine dynamically
enables things like running the same circuit with different
environmental or process models within a single session,
even within a larger loop (if the path definition is a
true language feature, subject to conditional statements
etc.). Example, a 3 temp, 4 process corner simulation:
sweep time from 0 to 10u
keep all
function ttable(t)=table(t,1,-55,2,25,3,125)
loop t from 1 to 3
set tempdc=ttable(t)
loop x from 1 to 4
if x=1 then
altqual off
altqual ~/CMOS6/modelsbb
endif
if x=2 then
altqual off
altqual ~/CMOS6/modelsbw
endif
if x=3 then
altqual off
altqual ~/CMOS6/modelswb
endif
if x=4 then
altqual off
altqual ~/CMOS6/modelsww
endif
go
tsettle
append 1 tsettle.d
print.1 t x tsettle
close
endloop
endloop
_______________________________________________________________
Get Free Email and Do More On The Web. Visit http://www.msn.com
Partial thread listing: