4

---

Running MDL in Post-processing Mode

---

MDL supports the post-processing mode that enables the user to evaluate measurements after the simulation has completed. This is especially helpful if you would like to use the same language (MDL or .measure statements) that was used for measurements evaluated during the simulation.

In case the measurements were not set up correctly, or more measurements need to be evaluated, the simulation needs to be run repeatedly to get the desired results. With post-processing capability, you can edit the measurements (in a MDL file, or .measure  in the netlist) and then invoke the simulator in a mode, where instead of performing the actual simulation, it reads the simulation results from a specified results directory or file, depending upon the waveform format being used.

The MDL post-processing mode allows you to execute a MDL script on an existing results database. Optionally a netlist can be provided. This allows the MDL script to reference objects in the netlist. For example the parameters in the netlist could be used in the MDL measurements.

mdl

Runs MDL in post-processing mode.

In the following syntax, the vertical bar ( | ) separates alternatives.

Syntax

mdl –batch|-b <file.mdl> [-design|-d netlist] -raw|-r <rawdir> [options]

       mdl –d <netlist containing .measure statement> -raw|-r <rawdir> [options]

Arguments

-batch|-b <file.mdl>	The filename of the MDL file to be executed.
-raw|-r <rawdir>	Location of the results directory.
-design|-d <netlist>	The filename of the netlist to be loaded by MDL. This can also be a netlist containing .measure statemtents.
-measure|-m <file.measure>	The default output filename is taken from the basename of the design argument, and appended with the .measure extension. This option creates an output file with the specified name. If an absolute path is not specified, the output file is created in the directory of the design argument.
+log|+l <logfile>	Copies all messages to logfile.
=log|=l <logfile>	Sends all messages to logfile.
-prec|-p '<format>'	Optional argument to specify the precision of of the measured value output in the measurement file. Example: %.15g will output the measured values to 15 significant digits. The argument is ignored if -engineering argument is used.
-eng|-e <numdigits>	Optional argument to specify the engineering format of the signal value output to the measurement file. <numdig> is a number of significant digits of the signal value. <numdig> is optional. If <numdig> is omitted than value of the <numdig> is 6. -prec argument is ignored.
-tab|-t	Optional argument to specify that the measure file should be displayed in tabular format.
-append|-a	Optional argument to specify that the measure file should be opened in append mode.
-nosort|-n	Optional argument to specify that variables in the measure file should not be sorted.
-outdir|-o	Optional argument to specify an alternate output directory location for all output files. This  does not change the location of the raw directory if explicitly specified with the –raw option.
-warn|-w	Optional argument to issue warning for ignoring unsupported constructs. Default is to issue an error.
-faults	Applies the MDL file to a fault dataset. You can use -ft as an abbreviation of -faults.

Most of the options are consistent with previous versions of spectremdl executable. However, the -warn option allows unsupported constructs (search, mvarsearch) to be ignored and evaluation to proceed.

Examples

Assume that an MDL script, test.mdl was used to generate a raw directory, input.raw using Spectre.

$ spectremdl –batch test.mdl –design input.scs –raw input.raw

To rerun the script on the results, the following command will be used:

$ mdl –b test.mdl –r input.raw

In this case, the measurement results are written out to the test.measure file. The –m command-line option can override the name of the output file.

$ mdl –b test.mdl –r input.raw –m input.measure

If the netlist input.scs was used to generate the results, it is possible that the MDL file references parameters from the netlist. Without the netlist, the MDL measurements cannot be evaluated, hence the netlist must be provided on the command-line so that those parameters and their values can be found.

$ mdl –b test.mdl –d input.scs –r input.raw

Another usage is for users who do not have MDL script, but instead use .MEASURE statements in the netlist (or in a file included in the netlist). Here test.sp may either contain the complete design or may have just .measure statements.

$ mdl –d test.sp –r test.raw

.include "param.sp"  // optional parameter definiton

.include "design.sp" //optional design

.include "test.msr"  // contains measurements 

$ mdl –d test.msr –r test.raw

Here test.msr may contains some parameter definition of the parameters referenced in the .measure statement. There is no need for complete design.

.param VDD=1.8

.meas tran  tfr trig v(a) val='0.5*VDD'  fall=1 targ v(y) val='0.5*VDD' rise=1

.measure tran tranmaxout1 max v(out)

.measure tran tranavg avg v(out)

Some waveform formats do not use the result directory concept. Cadence formats (such as PSF or SST), when generated from Spectre and Spectre APS, place a logFile in the results directory that is used to associate datasets with the physical files containing the simulation data. For formats that do not support this, it is necessary to explicitly specify the file contains the data rather than the results directory itself.

An example using the FSDB format is:

$ mdl –d tran.msr –r input.raw/tran.fsdb

In this example, tran.msr contains the measurements for the specified transient analysis results file, input.raw/tran.fsdb. The content of tran.msr could be

.measure tran tranmaxout1 max v(out)

.measure tran tranavg avg v(out)

In another example, the some measurements are evaluated using a DC analysis results file.

$ mdl –d dc.msr –r input.raw/dc.fsdb

Here, dc.msr contains the measurements to be evaluated, as in

.measure dc dcnmaxout1 max v(out)

.measure dc dcavg avg v(out)

Limitations

There are limitations when using this mdl tool to execute an MDL script.

The primary limitation that exists with the post-processing flow is a result of the nature of this flow. It can only work with the data that is in the netlist, MDL file and results database. Hence, if a signal that is used in an MDL expression is not saved in the database, then the expression will fail to evaluate.

For example, when the netlist is used, device input parameters can be used in expressions; however oppoint parameters cannot be used, unless they were already saved.

Other restrictions are:

• Other consequences of being only able to use information that is readily available in the MDL script, netlist (if supplied) and results database are the following;
  • The mvarsearch and search statements are not currently supported. When these are seen, mdl prints an error message and ignores these statements.
  • For montecarlo, the parameter savefamilyplots=yes must be set during the simulation run. Else, the waveform data for each iteration of the montecarlo run will not be saved.
    • Re-elaboration is not supported. Hence, if the measurement references the process or mismatch parameters, mdl will only see the nominal parameter values.
  • Foreach and montecarlo are only supported for PSF format.
  • Result dataset generated from alter/sweep specified in the netlist have different naming convention. Hence, if a netlist contains alter/sweep then dataset will not be located. It is recommended to use MDL scripts for alter/sweep so that corresponding dataset can be found.
• The MDL post-processing flow works on waveforms rather than on each individual point of a signal as occurs in the SpectreMDL flow. There are following consequences to this:
  • An if statement in a measurement alias can behave differently if the condition depends upon a signal value. In SpectreMDL, this could result in the true or false block being executed multiple times for each datapoint on the signal. In the post-processing flow, the condition is evaluated only once for the complete waveform.

If there is a sweep contained in the netlist, the dataset generated by Spectre is different from the dataset generated by MDL. Hence, MDL will not be able to locate the correct dataset. This is why currently, the .measure flow is supported for a netlist that does not contain sweep in the netlist.

Return to top