1. a good beginner's guide: http://homerreid.ath.cx:81/misc/ocean/index.shtml
Some tips:
(1)
The default behavior of the
Spectre simulator is to save the values of node voltages, but not device currents, after an analysis. This behavior can be changed with the save statement. This statement has a number of different usage models, all of which are demonstrated in the following: ocean> save('v "vdd" "outp" "outn")
"outn"
ocean> save('i "fdopamp/M5/D" "fdopamp/M6/D")
"fdopamp/M6/D"
ocean> save('allv)
allv
ocean> save('alli)
alli
ocean> save('all)
all |
save call is 'v or 'i. The third and fourth examples save all node voltages and all device currents, while the last example saves all node voltages and all device currents. The
save command obviously corresponds to the .out statement in Celerity, but has the added feature that output variables saved in one analysis can be removed from a subsequent analysis. In Celerity, once you declare a .out, it's there until you change netlists, which can be inconvenient. For example, you may want to save a large ' number of outputs for a quick DC temperature sweep, but then you don't want all those outputs taking up memory and disk space when you later want to run a long transient analysis. So this is one (the only?) way in which ocean is superior to Celerity. Having used one of the above lines to tell the simulator to save the device currents in which we're interested.
(2) view DC operation points:
ocean> selectResults('dcOpInfo)
stdobj@0x1979408
ocean> report(?name "/fdopamp/M1")
Type : bsim3v3
/fdopamp/M1
cdg= -1.00089e-13 cgb= -9.45704e-15 ids= 9.99962e-05
vgs= 0.854671 vds= 2.57445 vbs= -0.645329
vth= 0.694184 vdsat= 0.165582 gm= 0.000997972
gds= 8.65771e-07 gmbs= 0.000205937 betaeff= 0.00683843
cjd= 3.40119e-14 cjs= 4.54965e-14 cgg= 2.94677e-13
cgd= -7.79803e-15 cgs= -2.77422e-13 gmoverid= 9.9801
cbg= -4.06171e-14 cdd= 7.7983e-15 cds= 1.11609e-13
cdb= -1.93184e-14 csg= -1.53971e-13 csd= 3.85201e-19
css= 1.82945e-13 csb= -2.89743e-14 pwr= 0.000257435
cbd= -6.53294e-19 cbs= -1.71319e-14 cbb= 5.77497e-14
ron= 25745.5 aid= 9.99962e-05 ibulk= -5.53649e-18
reversed= 0 region= 2 type= 0
t
ocean> ocean> report(?name "/fdopamp/M1" ?param "vgs")
Type : bsim3v3
/fdopamp/M1
vgs = 0.854671
tocean> report(?param "vgs")
/fdopamp/M7
vgs = -1.19637
/fdopamp/M8
vgs = -1.19637
...
...
/fdopamp/M13
vgs = 0.567388
/fdopamp/M19
vgs = 0.634848
t report(?type "bsim3v3")
Type : bsim3v3
/fdopamp/M7
cdg = -2.02344e-13 cgb = -4.05936e-14 ids = 6.59845e-05
...
...
reversed = 0 region = 2 type = 1
t
ocean> -
dataTypes(),which prints a list of all possible values you can assign to the?typeparameter in a call toreport(),and -
outputs(),which prints a list of all possible values you can assign to the?nameparameter in a call toreport().
(3) invoke ocean from command lineInvoke ocean from the UNIX command line
with IO redirection. The command line syntax I recommend is:
% ocean < mycirc.ocn > /dev/null &
or, if you want to save the simulator's text output,
% ocean < mycirc.ocn > mycirc.log 2>&1 &
Even better is
% bsub -i mycirc.ocn -o mycirc.log ocean
This farms out your job to a machine in a server farm.
(You have to have LSF set up in your domain for this to work.)Then, having run the ocean job as a background process, you can monitor its progress with % tail -f mycirc.out, where mycirc.out is the name of the file you opened with outfile in your ocean script. (4) an example:;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; oneshot.ocn -- ocean script to analyze delay
; -- and pulse length of a one-shot
; -- multivibrator
; --
; Homer Reid -- 6/19/2002
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; boilerplate code: create output file, print
; greeting message, set some global variables
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
of=outfile("./oneshot.out" "w")
fprintf(of "\n\n** oneshot.ocn (Homer Reid 6/2002)\n\n")
drain(of)
VDD=3.3
CaseList=list("c0" "c1" "c2" "c3" "c4"
"c5" "c6" "c8" "c9" "c10" "c11" "c12")
TempList=list(-40 25 120)
| In this section we're just handling the trivial stuff: creating the output file, writing a greeting message, and initializing some global variables. If we wanted to restrict our case analysis to only a couple of cases, or add more temperatures, we would do it by modifying the CaseList or TempList lists we define here. | |
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; specify netlist and results directory
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
simulator('spectre)
dir="/home/homer/circuits/emerald/spectre/oneshot"
cktfile=strcat(dir "/spectre/schematic/netlist/netlist")
design(cktfile)
resultsDir(dir)
| Here we're telling the simulator where to find the circuit netlist and where to write the results. In the startc0.ocn file, which we used in doing console-based simulations, we used relative path specifications (i.e. referenced from the current working directory) in the design and resultsDir commands. That's fine for console-based interactive stuff, but for batch-mode scripts it's better to use absolute paths. For one thing, you might not always be sure of the current working directory in which you're running, and moreover you may eventually want to fire off ten or twelve versions of a simulation, each with slightly different results directories, so it's good to get in the habit of being explicit. | |
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; loop over process and temperature ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Earliest=1.0 Shortest=1.0 Latest=0.0 Longest=0.0 foreach( Case CaseList foreach( Temp TempList | Here we're initiating our double loop. We use the foreach structure to assign Case and Temp sequentially to each value in their respective lists. | |
; ; Set model file and simulation temperature. ; part1="$ICDS_CKTSIM_SW/lib/$ICDS_TECH/sim/spc/" part2="$ICDS_SIM_DATECODE/$ICDS_TECH.scs" model1=strcat(part1 part2) modelFile( list(model1 Case) ) temp(Temp) | At the beginning if each iteration of the loop, we use the modelFile and temp commands to set the process and temperature for this simulation. | |
;
; Run transient analysis and find start time
; and length of pulse.
;
analysis('tran ?stop 3u ?maxstep 1n)
run()
selectResults('tran)
trise=cross( v("m1g") VDD/2 1 'rising)
tfall=cross( v("m1g") VDD/2 1 'falling)
plength=tfall-trise
if( (trise < Earliest) Earliest=trise )
if( (trise > Latest) Latest=trise )
if( (plength < Shortest) Shortest=plength )
if( (plength > Longest) Longest=plength )
fprintf(of "case %3s, temp %3d: ",Case,Temp)
fprintf(of "pulse comes at ")
fprintf(of "%7.3f ns ",trise*1.0e9)
fprintf(of "and lasts for ")
fprintf(of "%7.3f ns\n",plength*1.0e9)
drain(of)
) ; foreach (Temp TempList)
) ; foreach (Case CaseList)
| This is heart of the loop. We run a transient analysis out to 3 us, then grab the results with selectResults. We use the cross function (see below) to get the times at which the pulse rises and falls. Then we check if the pulse delay or length are the longest or shortest we've seen so far (and save if so) and log the results to the output file. | |
fprintf(of "Earliest / Latest: ") fprintf(of "%7.3f / " Earliest*1e9) fprintf(of "%7.3f ns\n" Latest*1e9) fprintf(of "Shortest / Longest: ")% fprintf(of "%7.3f / " Shortest*1e9) fprintf(of "%7.3f ns\n" Longest*1e9) fprintf(of "\n\nThank you for your support.\n\n"); close(of) | We print the final results and close out with the all-important Bartles & Jaymes Wine Coolers parting salutation. |
Invoke ocean from the UNIX command line
with IO redirection. The command line syntax I recommend is:
% ocean < mycirc.ocn > /dev/null &
or, if you want to save the simulator's text output,
% ocean < mycirc.ocn > mycirc.log 2>&1 &
Even better is
% bsub -i mycirc.ocn -o mycirc.log ocean
This farms out your job to a machine in a server farm.
(You have to have LSF set up in your domain for this to work.)Then, having run the ocean job as a background process, you can monitor its progress with % tail -f mycirc.out, where mycirc.out is the name of the file you opened with outfile in your ocean script. SKILL tutorial:
1. A goole book: CAD Scripting Languages
http://books.google.com.sg/books?id=v8l72QBDzD0C
No comments:
Post a Comment