Building an Advanced Script

This chapter first gives a more thorough description (function level) of the different modules which make up the design kit model verification tool. This information is required before you can proceed with creating more advanced scripts.

Module Reference

The perl module files (*.pm) contain the functions used for creating the individual perl scripts. The different modules used by the design kit model verification tool are shown here.

• Template Module

• Parameter Module

• Circuit Module

• Instance and Analysis Modules

• Results Module

For a summary of all template functions provided in the perl modules and their basic functionality, refer to Design Kit Model Verification Tool Perl Modules.

Using the Module Debug Facility

All modules have a debug facility which can be turned on using the command:

dKit <module>->debug(<level>);

A <level> value of 0 turns debugging off. The higher the value of <level>, the more information you will receive. The information you receive will depend on the design kit <module> you are debugging.

The value of <module> can be Template, Parameter, Instance, Analysis or Circuit.

E.g. dKitCircuit->debug(1); will not delete the intermediate files (e.g netlist files).

Currently, the highest debug value is 100; however, not all intermediate values are used.

Quoting your string-variables

Within the perl scripts, it is required to use vertical quoted strings (' <string> ' or "<string>" ) wherever the chosen value happens to be a perl command, otherwise your script will not run correctly. Within the perl scripts, it is highly recommended that you quote all strings to reduce the possibility of generating errors. In perl, single quotes (' <string> ') represent text as is, with no variable substitution. Double quotes ( "<string>" ) perform variable substitution. For example, "$myVar" will be substituted by its value if it is in double quotes, while '$myVar' will just be equal to $myVar if it is in single quotes. Open quotes (` <string> ' or " <string> ") are not allowed for quoting strings in perl and vertical quotes (' <string> ' or " <string> ") should be used instead. While there is a very subtle difference in the appearance of the two styles, perl will not accept open quotes. Perl uses the open quote character for other applications.

Template Module

A template can be considered as the set of rules for how to translate the item defined using the dKit* commands to the simulator netlist dialect (See Understanding Templates).

The template module ( dKitTemplate.pm ) contains functions to perform the following operations:

• Creating a New Template Handle

• Retrieving a Handle of an Existing Template

• Documenting a Template

• Retrieving the Template Documentation

• Setting the Item Name Prefix

• Defining the Translation Rules

• Defining Template Parameters and Nodes/Pins

• Setting a Default Template Parameter Value

• Retrieving the Default Template Parameter Value

• Displaying the Defined Templates

• Saving the Template Definitions to Allow Fast Access

Creating a New Template Handle

To create a handle to a new template, use the function:

$Template = dKitTemplate->new(' <templateName> ');

Note that <templateName> should be a unique name. If a template is redefined using an existing template name, an error will be generated.

Retrieving a Handle of an Existing Template

To retrieve a handle of an existing template use the function:

$Template = dKitTemplate->getTemplate( '<templateName> ');

$Template is undefined if the template with <templateName> does not exist.

Documenting a Template

To document your template, use the function:

$Template->description(" <templateDescriptionText> ");

Where <templateDescriptionText> is the text describing the template.

Retrieving the Template Documentation

To get the documentation of a template, use the function:

$myDescription = $Template->description();

$myDescription will then contain the string describing the template.

Setting the Item Name Prefix

Hspice requires that the name of instances of certain components start with a predefined prefix. This is also implemented in the dKit verification syntax by the function:

$Template->requiredPrefix(" <prefix> ");

For example, Hspice uses the prefix "r" to designate a resistor. Therefore, defining the "r" prefix for a resistor (whose Template Handle is $R) would be done by:

$R->requiredPrefix("r");

The prefixes are case insensitive, this means that in the example above, resistor names can start with R or r.

Note All names are lowercase in the Hspice results file. If you require an Hspice simulation and you want your results dataset to reflect the simulator name, your devices/nodes should only contain lower case. For more information, refer to Viewing Your Results in a Data Display.

Defining the Translation Rules

To define how your template will be translated for each dialect, use the netlistInstanceTemplate function:

$Template->netlistInstanceTemplate(" <dialect> ", " <netlistFormat> ");

where <dialect> is the supported simulator dialect and <netlistFormat> is the defined structure for the netlist. An example for a standard resistor is shown below.

$R = dKitTemplate->new('R');
$R->description("Resistor");
$R->requiredPrefix('r');
$R->netlistInstanceTemplate('hspice', '#instanceName %n1 %n2 <modelName> R=<resistance> 
[[TC1=<tempCoef1>]] [[TC2=<tempCoef2>]] [[SCALE=<scale>]] [[M=<multiplicity>]] [[AC=<acResistance>]] 
[[DTEMP=<dtemp>]] [[L=<length>]] [[W=<width>]] [[C=<capacitanceN2Bulk>]]');
$R->netlistInstanceTemplate('ads', 'R:#instanceName %n1 %n2 R=<resistance> [[Temp=<temp>]] 
[[Tnom=<tnom>]] [[TC1=<tempCoef1>]] [[TC2=<tempCoef2>]] [[Noise=<noise>]] [[M=<multiplicity>]]');
$R->netlistInstanceTemplate('spectre', '#instanceName %n1 %n2 resistor r=<resistance> 
[[trise=<dtemp>]] [[tc1=<tempCoef1>]] [[tc2=<tempCoef2>]] [[isnoisy=<noise>]] [[m=<multiplicity>]]');

When defining the netlist format, the following special directives are available:

• #function : Calls the internally defined function or hook. Currently, #instanceName is the only function supported. #instanceName returns the name of the item. The other #names you will find in the
  dKitTemplateCreate.pl file are hooks, i.e. they direct the netlist function of the Circuit Module to follow a different path in the code. So you need to be a perl expert to modify those within the perl modules of the design kit model verification tool distribution. For information on modifying the source code, refer to Modifying the Source Code.

• %node: Adds the internal node/pin node to this item, e.g. %n1
• <name> : Adds name as a template parameter. If you assign a value to this parameter when defining the item that uses this template, <name> will be replaced by its value in the netlist.
• ~eval( text )end: Means that the text, after all parameters have been substituted by their values, will be passed to the perl eval function. In this way you can do operations on the parameters before they are substituted in the netlist.
  For example, observe the following netlist definition.

  $T->netlistInstanceTemplate(ads, 'TLIN4:#instanceName %in %refin %out %refout 
  [[Z=<Z0>]] [[F=<frequency>]] [[E=~eval(<electricalLength> * 360;)end]]');

  The ADS parameter E equals 360 times the design kit parameter electricalLength. This is a simple example, actually you can include whole perl scripts. If you need additional variables in the text, be sure to use the my declarator, otherwise it will not work! This is a perl specific declarator to say variables are local.
  The previous example with a more explicit definition would be:

  $T->netlistInstanceTemplate(ads, 'TLIN4:#instanceName %in %refin %out %refout 
  [[Z=<Z0>]] [[F=<frequency>]] [[E=~eval(my $electricalLength ="<electricalLength>"; 
  if ($electricalLength ne "") {return  $electricalLength* 360;} else {return "";})end]]');

• [[ test ]]: Means what is between the [[ ]] is optional, and will not be netlisted for the item using this netlist unless all parameters which are listed between the [[ ]] and are not part of an ~eval(text)end expression are defined AND all top-level ~eval(text)end evaluations return non-empty strings.
  If you do not put a parameter definition between [[ ]] then this parameter is required, and you will get an error if you try to netlist an item using this template which does not have a value defined for this parameter. For example, the resistance shown in the preceding resistor example uses R=<resistance>.

If an ~eval(text)end expression is not between [[]] then this expression is required, and you will get an error if the top-level ~eval(text)end evaluation returns an empty string. It is not an error for a nested ~eval(text)end evaluation to return an empty string.

You can find more examples of templates in the dKitTemplateCreate.pl file.

Defining Template Parameters and Nodes/Pins

While parsing the translation rules, the internal nodes/pins and parameters are automatically added to the template. If you want to add additional nodes and parameters, you can use the functions:

$Template->addNode("nodeName");

$Template->addParameter("parameterName");

Setting a Default Template Parameter Value

A parameter of a template can be given a default value, which will be netlisted if the item using this template does not redefine the parameter. By giving a parameter a default value, you make it a required parameter, which will be netlisted always.

You assign a default value by means of the function

$Template->parameterValue(" <parameter> ", " <value> ");

The parameter needs to be defined otherwise this function will return an error.

Retrieving the Default Template Parameter Value

You retrieve the default template parameter value using the function:

$myDefaultValue = $Template->parameterValue('<parameter>');

If no default value is assigned, an empty string is returned.

Displaying the Defined Templates

If you want to display which templates are currently defined, you can use one of the following functions at any time with the perl template definition script:

dKitTemplate->dumpTemplates;

or

print dKitTemplate->templates2perl;

Saving the Template Definitions to Allow Fast Access

For faster access, it is better to have your templates stored in a hash table than having to process them from a file. Therefore, use the function,

dKitTemplate->createTemplateDatabaseFile;

to translate your template definitions into a hash table and add them to the module dKitTemplate.pm in your working directory.

It is a good practice to keep the definition of your templates in a separate file. Optimally - without being annoyed by the error template already defined - use the example shown in Example Template Definition Script for constructing the template definition perl script file.

#!<myPath2Perl>/perl 
# ADD SCRIPT HEADER (see "Developing the Script Header" in "Building a Basic Script"). 
use dKitTemplate; 
if (! ($my_2p = dKitTemplate->getTemplate(my_2p))) 
{ # define your template here 
    $my_2p = dKitTemplate->new(my_2p); 
    $my_2p->requiredPrefix("X"); 
    $my_2p->netlistInstanceTemplate(ads, '<model>:#instanceName %n1 %n2 [[count=<count>]] 
[[xrsub=<xrsub>]] [[xctrench=<xctrench>]] [[w=<w>]] [[l=<l>]] [[rreq=<rreq>]] [[nk=<nk>]] 
[[na=<na>]] [[ng=<ng>]] [[ctcfg=<ctcfg>]] [[dgeo=<dgeo>]] [[sgeo=<sgeo>]]'); 
    $my_2p->netlistInstanceTemplate(spectre, '#instanceName %n1 %n2 <model> [[count=<count>]] 
[[xrsub=<xrsub>]] [[xctrench=<xctrench>]] [[w=<w>]] [[l=<l>]] [[rreq=<rreq>]] [[nk=<nk>]] 
[[na=<na>]] [[ng=<ng>]] [[ctcfg=<ctcfg>]] [[dgeo=<dgeo>]] [[sgeo=<sgeo>]]'); 
    $my_2p->netlistInstanceTemplate(hspice, '#instanceName %n1 %n2 <model> [[count=<count>]] 
[[xrsub=<xrsub>]] [[xctrench=<xctrench>]] [[w=<w>]] [[l=<l>]] [[rreq=<rreq>]] [[nk=<nk>]] 
[[na=<na>]] [[ng=<ng>]] [[ctcfg=<ctcfg>]] [[dgeo=<dgeo>]] [[sgeo=<sgeo>]]'); 
} 
# add other templates definitions here 
dKitTemplate->createTemplateDatabaseFile; 

### end of template creation script file

Parameter Module

The parameter module is used to map different variable names used by the different simulators for the same parameter. For example, the dc voltage of a voltage source is called:

• Vdc for ADS
• dc for Spectre and Hspice.

To avoid conflicts between variable names, you can set up parameter mappings that define the parameter name (name used in the design kit model verification tool), the dialect name (the name used by the simulator), and the result name (the name used when processing the results). See Creating a Parameter Handle.

There are several dialects currently supported by the design kit model verification tool. For information on supported dialects, refer to Supported Simulators.

The parameter module ( dKitParameter.pm ) contains functions to perform the following operations:

• Creating a Parameter Handle

• Documenting a Parameter

• Retrieving the Parameter Documentation

• Defining the Dialect Name for a Parameter

• Defining the Result Name for a Parameter

• Displaying the Defined Parameters

• Saving the Parameter Definitions to Allow Fast Access

• List All Missing Parameter Definitions

Creating a Parameter Handle

To create a handle to a new parameter, use the function:

$Parameter = dKitParameter->new( '<parameterName>' );

Where <parameterName> is the name to be used in the verification tool perl scripts.

Example:

Using the following example to create a parameter which will define the dc voltage of a voltage source:

$VDC = dKitParameter->new('Vdc');

you will have to use "Vdc" as the value of the "parameter" parameter of a Sweep Analysis if you want to sweep the dc voltage of a voltage source.

Documenting a Parameter

To document your template, use the function:

$Parameter->description( "<parameterDescriptionText>" );

Where <parameterDescriptionText> is the text describing the parameter

Example:

$VDC->description("DC Voltage");

Retrieving the Parameter Documentation

To retrieve the documentation of a parameter, use the function:

$myDescription= $Parameter->description;

Defining the Dialect Name for a Parameter

The different dialect names for the parameter are added by using the function:

$Parameter ->dialectReference( '<dialect>' , '<dialectParameterName>');

Example:

$VDC->dialectReference('spectre', 'dc');

$VDC->dialectReference('hspice', 'dc');

$VDC->dialectReference('ads', 'Vdc');

Defining the Result Name for a Parameter

To define the result name for the parameter use the function:

$Parameter->resultName(" <resultName> ");

Because Hspice result files use lowercase, it is advised to use all lowercase resultNames if you want to make comparisons with Hspice results.

Note The resultName names should be chosen in order that $parameter($dialect)->resultName is unique. For example, $VDC(hspice)->dc.

Examples

$VDC = dKitParameter->new("Vdc");
$IDC = dKitParameter->new("Idc");
$IDC->dialectReference('hspice', 'dc');
$VDC->dialectReference('hspice', 'dc');
$IDC->dialectReference('ads', 'Idc');
$VDC->dialectReference('ads', 'Vdc');

Using the following _resultName_s

$IDC->resultName("idc");
$VDC->resultName("vdc");

would create ambiguity, because both have the Hspice reference 'dc'. I.e. in the results file you will find dc, but you do not know whether it stems from IDC being translated to DC or VDS being translated to DC. Instead, use:

$IDC->resultName("dc");
$VDC->resultName("dc");

Displaying the Defined Parameters

To display the parameters which are currently defined you can use one of the following functions at any time with the perl parameter definition script

dKitParameter->dumpDKitXrefs;

or

print dKitParameter->dKitXrefs2perl;

Saving the Parameter Definitions to Allow Fast Access

For faster access, it is better to have your parameters stored in a hash table than having to read them from a file. Therefore, use the function:

dKitParameter->createParameterDatabaseFile;

to translate your parameter definitions into a hash table and add them to the module dKitParameter.pm in your working directory.

List All Missing Parameter Definitions

To list all missing parameter definitions, use the following function after the circuit is simulated:

dKitParameter->listMissingParameterDefinitions;

Circuit Module

To initialize the circuit module, add the following line before using any functions to define your test circuit.

use dKitCircuit;

The circuit module ( dKitCircuit.pm ) contains functions to perform the following operations:

• Creating a New Circuit Handle

• Setting the Circuit Name

• Adding Simulator Options

• Removing Simulator Options

• Retrieving the list of Simulator Option Handles

• Retrieving a Specific Simulator Option Handle

• Adding a Path to a Model Library

• Removing a Path to a Model Library

• Retrieving the list of Model Library Path Handles

• Retrieving a Specific Model Library Path Handle

• Adding Components/Instances

• Removing Components/Instances

• Retrieving the List of Instance Handles

• Retrieving a Specific Instance Handle

• Adding Analyses

• Removing Analyses

• Retrieving the List of Analysis Handles

• Retrieving a Specific Analysis Handle

• Retrieving an Analysis Handle from within the Analysis Hierarchy

• Retrieving a Sweep Plan Handle from within the Analysis Hierarchy

• Retrieving a Output Plan Handle from within the Analysis Hierarchy

• Simulating a Circuit

For dealing with subcircuits the following functions are available:

• Defining a Subcircuit

• Creating the Subcircuit Database File

• Creating a new Circuit by Cloning a Subcircuit

• Defining and Modifying Circuit or Subcircuit Parameters

• Defining a Template using a Subcircuit

• Defining a Subcircuit and its Template

For the more advanced users, additional functions are available to perform the following operations:

• Adding a Startdeck and Enddeck Card

• Creating the Simulator Netlist

• Simulating a Circuit from a Netlist

• Freeing Memory Occupied by the Simulation Results

Creating a New Circuit Handle

To create a new circuit, use the function:

$Circuit = dKitCircuit->new(" <circuitName> ");

See also Setting the Circuit Name.

Setting the Circuit Name

You set the circuitName using the function:

$Circuit->circuitName("<circuitName>");

Where <circuitName> determines where all data will be stored. If <circuitName> contains forward slashes (/), all intermediate files, including the simulator netlists, will be placed in a subdirectory. See also Simulating a Circuit.

Adding Simulator Options

There are some default options given for the different simulators if you do not specify any options. However, if you specify one option for a given simulator, all other default options will be erased.

The following options MUST be set for the verification tool to run correctly:

spectre : rawfmt=psfascii

ADS : UseNutmegFormat=no ASCII_Rawfile=yes

and therefore they will ALWAYS be added to the netlist.

To add simulator options, use the function:

$Circuit->addSimulatorOption($OPTION);

where $OPTION is a reference to an instance. See Instance and Analysis Modules.

Removing Simulator Options

To remove a previously added simulator option from your circuit, use the function:

$Circuit->removeSimulatorOption($Instance);

Retrieving the list of Simulator Option Handles

To retrieve the handles of the local simulator options within the Circuit $CIRCUIT, use the function:

my @handles = $CIRCUIT->getSimulatorOptions;

Retrieving a Specific Simulator Option Handle

To retrieve the handle of a local simulator option named "name" within the Circuit $CIRCUIT, use the function:

my $handle = $CIRCUIT->getLocalSimulatorOption("name");

Adding a Path to a Model Library

To add the path to a modelLibrary, use the function:

$Circuit->addModelLibary($MODELLIBRARY);

where $MODELLIBRARY is a reference to an instance. See Instance and Analysis Modules.

Removing a Path to a Model Library

To remove a previously added path to a modelLibrary from your circuit, use the function:

$Circuit->removeModelLibrary($Instance);

Retrieving the list of Model Library Path Handles

To retrieve the handles of the local model library paths within the Circuit $CIRCUIT, use the function:

my @handles = $CIRCUIT->getModelLibraries;

Retrieving a Specific Model Library Path Handle

To retrieve the handle of a local model library path named "name" within the Circuit $CIRCUIT, use the function:

my $handle = $CIRCUIT->getLocalModelLibrary("name");

Adding Components/Instances

To add components or netlist parameters, use the function:

$Circuit->addInstance($Instance);

where $Instance is a reference to an instance. See Instance and Analysis Modules.

The order in which the instances are added will also be the order in which the instances will be netlisted.

This is for instance important for PARAMETER instances, because in Hspice parameter instances defining an equation should only be netlisted (added) after the elements or parameters within the equation are defined.

If you have the following definition:

$P1 = dKitInstance->new('PARAMETER', 'rsq');
$P1->parameterValue('value', 1);

$P2 = dKitInstance->new('PARAMETER', 'r_l');
$P2->parameterValue('value', 'rsq*r_w');

$P3 = dKitInstance->new(PARAMETER, 'r_w');
$P3->parameterValue('value',1.34e-6);

then, $P2 should be added (using $Circuit->addInstance ) AFTER $P1 AND $P3 have been added.

Removing Components/Instances

To remove a previously added instance from your circuit, use the function:

$Circuit->removeInstance($Instance);

Retrieving the List of Instance Handles

To retrieve the handles of the local instances within the Circuit $CIRCUIT, use the function:

my @handles = $CIRCUIT->getInstances;

Retrieving a Specific Instance Handle

To retrieve the handle of a local instance named "name" within the Circuit $CIRCUIT, use the function:

my $handle = $CIRCUIT->getLocalInstance("name");

Adding Analyses

To add analyses, use the function:

$Circuit->addAnalysis($Analysis);

where $Analysis is a reference to an analysis. See instance/analysis module.

Note Currently only one analysis can be added to a circuit.

Removing Analyses

To remove a previously added analysis from your circuit, use the function:

$Circuit->removeAnalysis($Instance);

Retrieving the List of Analysis Handles

To retrieve the handles of the local analysis within the Circuit $CIRCUIT, use the function:

my @handles = $CIRCUIT->getAnalyses;

Retrieving a Specific Analysis Handle

To retrieve the handle of a local analysis named "name" within the Circuit $CIRCUIT, use the function:

my $handle = $CIRCUIT->getLocalAnalysis("name");

Retrieving an Analysis Handle from within the Analysis Hierarchy

To retrieve an analysis with a given name from the circuit analyses, including its subanalyses, use the function:

my $handle = $CircuitHandle->getFlattenedAnalysis("name");

Because the handle lost all of its hierarchical information, it should ONLY be used to change the values of the parameters of the analysis.

Retrieving a Sweep Plan Handle from within the Analysis Hierarchy

To retrieve an sweep plan with a given name from the circuit analyses, including its subanalyses, use the function:

my $handle = $CircuitHandle->getFlattenedSweepPlan("name");

Because the handle lost all of its hierarchical information, it should ONLY be used to change the values of the parameters of the sweep plan.

Retrieving a Output Plan Handle from within the Analysis Hierarchy

To retrieve an output plan with a given name from the circuit analyses, including its subanalyses, use the function:

my $handle = $CircuitHandle->getFlattenedOutputPlan("name");

Because the handle lost all of its hierarchical information, it should ONLY be used to change the values of the parameters of the output plan.

Simulating a Circuit

To simulate a circuit after it is defined, issue the command

$Circuit->simulate( "<dialect1>", "<dialect2>", "<dialect3>", "..." );

The currently supported dialects are defined in Supported Simulators.

The output of the simulation function creates a dataset ( <circuitNameForDs> .ds) in your working directory. The <circuitNameForDs> is the name you give to your circuit using the function:

$Circuit->circuitName(" <circuitName> ");

where all forward slashes (/) are replaced by underscores (_).

It also creates a citi file ( <circuitNameForCti>.cti). This will be placed in the correct subdirectories if <circuitNameForCti> contains forward slashes (/).
If you only supply one dialect to the simulate function, _<dialect> will be appended to the <circuitName> when creating <circuitNameForCti> and <circuitNameForDs>.

All intermediate files, including the simulator netlists, will be removed unless you set the circuit level debugging to '1' or higher using the debug command:

dKitCircuit->debug( <level> );

Defining a Subcircuit

Once a circuit is defined, it can be cataloged as a subcircuit for subsequent use by means of the function:

$Circuit->addToSubcircuits([nodeList, parameterList [,optionalParameterList]]);

Where:

nodeList = The list of node names of this subcircuit (e.g. ['n1', 'n2', ...]).

requiredParameterList = A list with the required parameters and their initial values (e.g. ['l', 'w=1']).

optionalParameterList = A list with the optional parameters and their initial values (e.g. []).

Note Optional parameters, when added, need to have an initial value, otherwise the simulation will not be successful.

Creating the Subcircuit Database File

To store all currently defined subcircuits within the database file, use the function:

$Circuit->createSubcircuitDatabaseFile;

This will store the currently defined subcircuits in the dKitSubcircuitDB.pl file.

Creating a new Circuit by Cloning a Subcircuit

A completely new circuit can be created from a subcircuit, with the command:

my $Circuit = dKitCircuit->clone("<subcircuitName>");

Its parameters can then be altered as described in Defining and Modifying Circuit or Subcircuit Parameters. Or handles to its items can be retrieved which can be used to modify their parameters as described in Defining and Retrieving the Parameter Values within the Instance/Analysis Module. After which a simulation can be performed as described in Simulating a Circuit.

Defining and Modifying Circuit or Subcircuit Parameters

For subcircuits or circuits created by cloning a subcircuit, it might be necessary to modify circuit parameters.
To get the value of a circuitParameter, use:

$Circuit->parameterValue("<parameterName>");

To set the value of a circuitParameter, use:

$Circuit->parameterValue("<parameterName>", "<value>");

Note It is not possible to assign lists or arrays to a parameter, only simple values or expressions can be assigned.

The parameter needs to be defined otherwise you will get an error. To define a parameter, you can use the function:

$Circuit->addParameter("<parameterName>");

Defining a Template using a Subcircuit

To define a template, which can be used as an instance in other circuits, for a subcircuit only containing instances, use the function:

$Circuit->createSubcircuitTemplateOnly("<templateName>", nodeList, requiredParameterList, optionalParameterList);

Where:

<templateName> = The name of the template.

nodeList = The list of node names (e.g. ['n1', 'n2', ...]).

requiredParameterList = A list with the required parameters and their initial values (e.g. ['l=1e-3', 'w']).

optionalParameterList = A list with the optional parameters and their initial values (e.g. []).

To save this template definition in the template database, use:

dKitTemplate->createTemplateDatabaseFile;

as described in Saving the Template Definitions to Allow Fast Access.

Defining a Subcircuit and its Template

The functionality of "Defining a Subcircuit" and "Defining a Template using a Subcircuit" is for the ease of use combined into one function call:

$Circuit->createTemplateANDaddToSubcircuits("<templateName>", nodeList, requiredParameterList, optionalParameterList);

Adding a Startdeck and Enddeck Card

There is also a possibility to add a startDeckCard and endDeckCard. This is done by changing the defaults for the template CIRCUITSTARTDECKCARD and CIRCUITENDDECKCARD respectively. By default a Spectre file will start with 'simulator lang=spectre', and Hspice will end a file with .end.

Creating the Simulator Netlist

Normally the netlist is automatically created when you simulate your test circuit. However, if you want to have access to the netlist without doing a simulation, you can use the command:

$myNetlist = $Circuit->netlist("<dialect>");

which will assign the netlist to the perl variable $myNetlist, or:

$Circuit->netlist("<dialect>", "<fileName>");

which will write the netlist to the file <fileName>. If you want to simulate the netlist after editing, refer to Simulating a Circuit from a Netlist for information on choosing the fileName.

Note If the <fileName> is equal to the <circuitName> with the default dialect extension, that file will be removed if the same perl script also performs a simulation and is using circuit debug level 0.

Simulating a Circuit from a Netlist

To run a simulation given a netlist file, issue the command:

dKitCircuit->simulate("<netlist1>", "<netlist2>", ...);

where <netlist1>, <netlist2> are the names of the netlist files. The suffixes of the netlists will determine which simulator will be called. They are defined by the parameters <dialect> NetlistSuffix of the default Template CIRCUITNETLISTNAME. They are ".hsp" for Hspice, ".ckt" for the ADS circuit simulator, ".scs" for Spectre. If the basenames (i.e. the name without the suffix) are equal a combined dataset will be created, just like if you would have used the command:

$Circuit->simulate("<dialect1>", "<dialect2>", ... );

See Simulating a Circuit.

Freeing Memory Occupied by the Simulation Results

When the simulation completes, the simulation results are normally kept in memory in order to have fast access to the results when additional statistical operations need to be performed. However, for large circuits the amount of data kept might be substantial and when simulating a lot of circuits from within the same perl file you might encounter an out of memory error during the execution of the perl test circuit script. To prevent this from happening you can issue the command:

$Circuit->deleteResultsFromMemory();

when you do not need the simulation results any more for the circuit. It will free up the memory taken by the results so it can be used by other simulations.

Note Do not change the name of the circuit between the call to simulate and deleteResultsFromMemory, or the deleteResultsFromMemory function will have no effect.

Instance and Analysis Modules

Instances and Analyses are very similar (they are both defined using templates); however, they are put into separate modules because:

• Instances (components/options/...) have a very similar netlist format for the different simulators, Analyses do not.
• Analyses can include subanalyses, Instances cannot include subinstances. A subcircuit is just an instance.

The following operations can be performed by both modules:

• Creating a New Item Handle
• Viewing the Template Definition
• Defining and Retrieving the Parameter Values

The instance module ( dKitInstance.pm ) contains functions to perform the following instance specific operations:

• Retrieving the InstanceName
• Defining and Retrieving Node Names

The analysis module ( dKitAnalysis.pm ) contains functions to perform the following analysis specific operations:

• Retrieving the AnalysisName
• Adding a Sweepplan
• Retrieving the List of Sweep Plan Handles
• Removing a Sweepplan
• Adding an OutputPlan
• Retrieving the List of Output Plan Handles
• Removing an OutputPlan
• Adding a Sub Analysis
• Retrieving the List of Sub Analysis Handles
• Removing a Sub Analysis
• Scale/Offset a Sweep Parameter
• Monte Carlo Analysis

Creating a New Item Handle

An instance is created using the command:

$InstanceHandle = dKitInstance->new("templateName", "instanceName");

Note that the same name cannot be used for two different instances.
An analysis is created using the command:

$AnalysisHandle = dKitAnalysis->new("templateName", "analysisName");

Note that the same name cannot be used for two different analyses.

For a list of standard supported instances and analysis, refer to Template List.

Viewing the Template Definition

To retrieve a description of the template definition use:

$myTemplateDef = $InstanceOrAnalysisHandle->template->dump2str;

To print it to the screen use the standard perl print function, e.g.

print "$myTemplateDef\n";

This will cause the template definition to be printed to the terminal window upon completion of the script.

Alternatively you could use the method described in Displaying_the_Defined_Templates,_or_the_Template_reference_table_in_Template List if it is a standard template.

Defining and Retrieving the Parameter Values

Once an instance or analysis is created, the value of the parameters which are defined by the template need to be set. To set a parameter value, use the command:

$InstanceOrAnalysisHandle->parameterValue("parameterName", "value");

If value is numeric, it should be in engineering or floating notation (1e-3 or 0.001) without units. For example, the value for the capacitance of a 1nF capacitor should be specified as 1e-9.

To retrieve the value of a parameter use:

$myValue = $InstanceOrAnalysisHandle->parameterValue("parameterName");

To know which parameters are available, see Viewing the Template Definition.

Retrieving the InstanceName

The instanceName of an instance can be retrieved using:

$myName = $InstanceHandle->instanceName;

Defining and Retrieving Node Names

If an instance has nodes, which is the case for all components, then you must define the node names using:

$Instance->nodeName("internalName", "circuitNodeName");

This assigns the name of the circuitNode to the internal instance node. For more information, refer to Connecting Instances.

To retrieve the name of the circuitNode use the command:

$myCircuitNode = $Instance->nodeName("internalName");

For information on knowing which internal nodes are defined, refer to Viewing the Template Definition.

Retrieving the AnalysisName

The analysisName of an analysis can be retrieved using:

$myName = $AnalysisHandle->analysisName;

Adding a Sweepplan

To add a sweepplan to an analysis use:

$AnalysisHandle->addSweepPlan($SweepPlanHandle);

Note Sweepplans are expected for all analyses with the exception of TRAN and MONTE.

Sweepplans are a special type of analyses. They are created using:

$SweepplanHandle = dKitAnalysis->new("sweepplanTemplateName", "sweepplanName");

For a list of standard supported sweepplans, refer to Sweepplan Templates.

Retrieving the List of Sweep Plan Handles

To retrieve the handles of the local sweep plans within the Analysis $AnalysisHandle, use the function:

my @handles = $AnalysisHandle->getSweepPlans;

Removing a Sweepplan

To remove a sweepplan from an analysis use:

$AnalysisHandle->removeSweepPlan($SweepplanHandle);

Adding an OutputPlan

To add an outputplan to an analysis use:

$AnalysisHandle->addOutputPlan($OutputplanHandle);

Note Multiple outputplans can be added to an analysis.

Outputplans are a special type of analyses. They are created using:

$OutputplanHandle = dKitAnalysis->new("outputplanTemplateName", "outputplanName");

For a list of standard supported outputplans, refer to Outputplan Templates.

Retrieving the List of Output Plan Handles

To retrieve the handles of the local output plans within the Analysis $AnalysisHandle, use the function:

my @handles = $AnalysisHandle->getOutputPlans;

Removing an OutputPlan

To remove an outputplan from an analysis use:

$AnalysisHandle->removeOutputPlan($OutputplanHandle);

Adding a Sub Analysis

To add a subanalysis to a sweep analysis use:

$AnalysisHandle->addSubAnalysis($SubAnalysisHandle);

Note Currently only one subanalysis / analysis is supported.

Retrieving the List of Sub Analysis Handles

To retrieve the handles of the local sub analyses within the Analysis $AnalysisHandle, use the function:

my @handles = $AnalysisHandle->getSubAnalyses;

Removing a Sub Analysis

To remove a sub analysis from a sweep analysis use:

$AnalysisHandle->removeSubAnalysis($SubAnalysisHandle);

Scale/Offset a Sweep Parameter

There is no specific analysis module function to scale/offset a specific sweep parameter, but the sweepplan templates have parameters <dialect>Scale and <dialect>Offset that are intended for this purpose.

This functionality is for instance needed when you want to do a sweep of the DC voltage of a Port instance. In Spectre the DC-voltage is multiplied by 2, while this is not the case in ADS or Hspice.

So to do a sweep of the dc voltage of a port instance your perl script could look like:

$P1=dKitInstance->new('PORT', 'V1');
$P1->parameterValue('Vdc', 0.7);
$SWEEPPLAN = dKitAnalysis->new('SWEEPPLAN_LIN', 'Plan1');
$SWEEPPLAN->parameterValue('start', 0.5);
$SWEEPPLAN->parameterValue('stop', 1.5);
$SWEEPPLAN->parameterValue('numPts', 5);
$SWEEPPLAN->parameterValue('spectreScale', 0.5);
$SP1= dKitAnalysis->new('SP', 'Sp');
$SP->parameterValue('device', 'V1');
$SP->parameterValue('parameter', 'Vdc');
$SP->addSweepPlan($SWEEPPLAN);

To get the original sweep values in the result file (see Results Module) you should also add to your script:

dKitResults->sweepVariableScale("V1.dc", "spectre", 2.0);

Note The resultName of the parameter should be used to define the sweepvariable not the dKit Parameter name.

Monte Carlo Analysis

Monte Carlo analysis is similar to sweeping a parameter. Both require a main analysis such as DC, AC, Transient, or S-Parameter and both change one or more parameters during successive runs of the main analysis. The main difference is that the parameters are changed in a random manor rather than through a sweep plan.

The purpose of Monte Carlo Analysis in the Design Kit Model Verification tool is to verify that the design kit components and models for each simulator have the same parameters that can vary statistically, that the variation of these parameters is similar, and that the results of analysis with these variations are similar. Since Monte Carlo is varying the parameters randomly the results will not be exactly the same, only similar. Because of this the judgment that the simulators are behaving similar will have to be done visually.

Prior to performing a Monte Carlo analysis you should have completed the non-statistical verification of each component or model. You should also have added the statistical variations to the appropriate parameters in the netlists for each simulator. It is expected that this has been done as there is no provision to add these variations through the Perl scripts.

To create a Monte Carlo verification script you should have a main analysis such as this AC analysis:

$SWEEPPLAN1 = dKitAnalysis->new(SWEEPPLAN_LIN, Plan1);
$SWEEPPLAN1->parameterValue(start,1e8);
$SWEEPPLAN1->parameterValue(stop, 1e9);
$SWEEPPLAN1->parameterValue(numPts, 10);
$AC1 = dKitAnalysis->new(AC, AcSweep1);
$AC1->parameterValue(parameter, 'freq');
$AC1->addSweepPlan($SWEEPPLAN1);

You should then add a Monte Carlo analysis and make the AC analysis a sub analysis to it as follows:

$MONTE = dKitAnalysis->new(MONTE, MSweep1 );
$MONTE->parameterValue("iterations", "250");
$MONTE->parameterValue("variations", "process");
$MONTE->addSubAnalysis($AC1);

The number of Monte Carlo iterations is specified by the "iterations" parameter. The "variations" parameter is specific to Spectre and is used to specify the type of statistical variations to apply. Possible values for the "variations" parameter are "process", "mismatch?, and "all". Then the Monte Carlo analysis should be added to your circuit as follows:

$CIRCUIT->addAnalysis($MONTE);

Output Plans should also exist to save the results of any circuit results that you wish to compare.

Viewing Monte Carlo Results

After running the Monte Carlo analysis, two types of information will be available,

• the parameters that are varying
• the varying output results from the circuit analysis.

To view the parameters you should use the measurement function histogram to see what values of the parameter fall into various data ranges. For more information on the histogram function, refer to the " Measurement Expressions " documentation. A typical example is shown in the following figure.

Example measurement function histogram

This was a parameter with a value of 210 and Gauss distribution with a 30% standard deviation. There are 500 iterations in the Monte Carlo analysis.

The following figure shows a plot of the output results of a Monte Carlo run. Notice the center line of the two traces are not the same. This difference would have previously been seen in verifying the parameter without statistical variations included. Notice that the statistical variations (width) of the two traces are very consistent. This shows that the statistical parameters are operating as expected.

Monte Carlo Results

Results Module

If the perl script you are using is not initialized using:

use dKitCircuit;

then add the following line before using any functions of the results module:

use dKitResults;

The results module ( dKitResults.pm ) contains functions to perform the following operations:

• Set/Get the Offset of a Sweepvariable when Processing the Simulation Results
• Set/Get the Scale of a Sweepvariable when Processing the Simulation Results
• Reading the Simulation Results or Citifiles
• Retrieving a Handle to the Results
• Writing the Results to Citifiles
• Converting Citifiles to Datasets
• Comparing Two Simulator Results
• Performing a Simple Statistical Analysis
• Merging Citifiles into One Big Citifile
• Freeing the Memory taken by the Simulation Results

Set/Get the Offset of a Sweepvariable when Processing the Simulation Results

To set the offset value used when the results module processes the data for a certain parameter use:

$offset = dKitResults->sweepVariableOffset('parameter', 'dialect', offsetValue);

Where:

• 'parameter' is in the format <deviceName>.<parameterName>. < parameterName > should be the same as the <resultName> of the parameter defined using the Parameter Module. 'parameter' is also the name found in the citi file containing the results.
• 'dialect' designates the simulator results for which this offset should be applied.
• offsetvalue is the value of the offset. It normally equals -sweepplanoffset. sweeplanoffset is the offset applied to the sweeplan used to sweep this variable, See Scale/Offset a Sweep Parameter.

To get the offset value, use:

$offset = dKitResults->sweepVariableOffset('parameter', 'dialect');

Set/Get the Scale of a Sweepvariable when Processing the Simulation Results

To set the scale value used when the results module processes the data for a certain parameter use:

dKitResults->sweepVariableScale('parameter', 'dialect', scaleValue);

Where:

• 'parameter' is in the format <deviceName>. <parameterName>. <parameterName> should be the same as the <resultName> of the parameter defined using the Parameter Module. 'parameter' is also the name found in the citi file containing the results.
• 'dialect' designates the simulator results for which this scale should be applied.
• 'scalevalue' is the value of the scale. It normally equals 1.0/sweepplanscale. sweeplanscale is the scale applied to the sweeplan used to sweep this variable, See Scale/Offset a Sweep Parameter.

To get the scale value, use:

$scale = dKitResults->sweepVariableScale('parameter', 'dialect');

Reading the Simulation Results or Citifiles

To read the results from a simulation or a CITI file, use the function:

$Result = dKitResults->readData('<projectName>', '<dialect>');

Where <projectName> would normally be the circuitName of the simulated circuit. The supported dialects include the citi -dialect, as well as the supported simulators. In the case of the citi -dialect, the file <projectName>.cti is read and its content is stored in an item which can be accessed via the handle $Result;

Note The design kit model verification tool is not able to read merged citifiles. For more information, refer to Merging Citifiles into One Big Citifile.

Retrieving a Handle to the Results

When you have lost the handle to some result data, you can retrieve it using the function:

$Result = dKitResults->getResults(<projectName>, <dialect>);

If the result data does not exist, this function will try to retrieve it using:

dKitResults->readData

For more information, refer to Reading the Simulation Results or Citifiles.

Writing the Results to Citifiles

To create a Citifile with the results use the function:

$Result->writeCitifile('fileName'[, 'setName']);

Where fileName is the name of the file to be created and the optional setName is the name of the set to be used when referencing it in the ADS data display server. For more information, refer to Comparing Two Simulator Results. It is advised to use .cti as the filename extension, and use the dialect as the setName. In this case you are compliant with the rules used within the design kit model verification tool.

Converting Citifiles to Datasets

To convert a citifile to a dataset, use the function:

dKitResults->convertCitifile2Dataset('path2CitiFile'[,'setName']);

Where path2CitiFile is the location of the citifile and setName is the name to be used when referencing it in the ADS data display server.

Note The name of the citifile should end with .cti and setName should not be used if a merged citifile is given.

The name of the dataset, will be the name of the citifile with all forward slashes (/) substituted by underscores (_), and the final .cti substituted by .ds.
For viewing the results with the ADS data display server, it is convenient if all data are located in one dataset. To do so, all citi data should be merged before the citifile is converted to a dataset. For more information, refer to Merging Citifiles into One Big Citifile.

Comparing Two Simulator Results

To calculate the difference between the results of two simulators, the following functions can be used:

$ReldiffHandle = dKitResults->compareDataRelative($Result1Handle, $Result2Handle);

$AbsdiffHandle = dKitResults->compareDataAbsolute($Result1Handle, $Result2Handle);

Where $Result1Handle and $Result2Handle are the handles to result items (see Retrieving a Handle to the Results).

$ReldiffHandle will reference the relative differences between the simulation results and $AbsdiffHandle will reference the absolute differences. If you want to display these results using the ADS data display server, first transform the results to citifiles (see Writing the Results to Citifiles), then transform the citifiles to datasets (see Converting Citifiles to Datasets).

The result handles can also be used to obtain some simple statistical information (see Performing a Simple Statistical Analysis). Both simulation results ( $Result1Handle and $Result2Handle ) should have the same sweepvariables, and only the differences between the matching dependent variables will be stored in the ReldiffHandle and/or AbsdiffHandle. Dependent variable names match if they have the same name (case sensitive).

Performing a Simple Statistical Analysis

To get the mean, maximum and minimum values of all dependent variables within a result item, use the command:

$ResultHandle->calculateStatistics(['outputFileName']);

If 'outputFileName' is specified, the mean, maximum and minimum of all dependent variables will be written into the file 'outputFileName'. Otherwise, it will be written to the terminal window.

Merging Citifiles into One Big Citifile

To merge several citifiles into one citifile, use the command:

dKitResults->mergeCitifiles('outputFileName', 'inputFileName1', 'inputFileName2', ...);

This is useful when you want to view the results using the ADS Data Display Server, because all data are available from within one dataset if this merged citifile is converted to a dataset.

Note The citifiles to be merged should all have different set names, otherwise the resulting dataset will be corrupt.

Freeing the Memory taken by the Simulation Results

To free the memory taken by previously run simulations, issue the command:

dKitResults->freeMemory('circuitName' [, 'dialect']);

where circuitName is the name of the circuit and dialect is the name of the simulator dialect. If no dialect is specified, all results for circuitName will be deleted.

Design Kit Model Verification Tool Perl Modules

The following sections contain a summary of the design kit model verification tool Perl Module (*.pm) files that contain the functions used for creating your individual perl scripts. The tables provided can be used as a quick reference when developing your scripts. The following information is provided for each of the functions listed:

• Function name
• Function description
• Function syntax
• Variable definitions (i.e. variables listed in angled brackets < .. >)
• Function limitations
• References to examples

Template Module (dKitTemplate.pm)

The dKitTemplate.pm file contains the functions used for creating the design kit model verification template script.

Parameter Module (dKitParameter.pm)

The dKitParameter.pm file contains the functions used for creating the design kit model verification parameters script.

Circuit Module (dKitCircuit.pm)

The dKitCircuit.pm file contains the functions used for creating the design kit model verification circuit script.

Instance Module (dKitInstance.pm)

The dKitInstance.pm file contains the functions used for creating the design kit model verification parameters script.

Analysis Module (dKitAnalysis.pm)

The dKitAnalysis.pm file contains the functions used for creating the design kit model verification parameters script.

Results Module (dKitResults.pm)

The dKitResults.pm file contains the functions used for creating the design kit model verification simulation results data.

Example Device Test Scripts

The example scripts shown in this section are for reference only. In order to use these scripts, the appropriate model files need to be provided. This involves making changes to the diode_test_dc.pl script to reference the required model files and to designate the correct sections. The create_diode.pl script may also need to be changed to reflect the correct instance line definition for the associated models.

diode_test_dc.pl

The diode_test_dc.pl script is a simulation to compare ADS vs. Hspice using the design kit model verification tool. It is a simple diode in parallel with a DC voltage source. The only variable swept is the forward diode voltage, Vd. The output is intended to be Capacitance and Current vs. Vd.

Note There are required perl scripts, diode_create.pl and diode_parameters.pl that must be executed before this script. This is so that a model with required parameters can be created for a diode. The diode_create.pl and diode_parameters.pl scripts only need to be executed once. For more details, refer to the contents of diode_create.pl and diode_parameter.pl.

This test is written for the forward region (Vdc = 0 to 0.7) for the ndiode and pdiode diodes.

#!/usr/bin/perl 
BEGIN { 
    if ($ENV{DKITVERIFICATION} eq "") 
    { 
        if ($ENV{HPEESOF_DIR} eq "") 
        { 
            print "\nPlease set environment variable DKITVERIFICATION\nto point to the design kit 
verification installation directory\n\n"; 
            exit 1; 
        } else 
        { 
            $ENV{DKITVERIFICATION} = "$ENV{HPEESOF_DIR}/design_kit/verification"; 
        } 
    } 
    $myLibPath = "$ENV{DKITVERIFICATION}/perl/lib"; 
    if ( ! -d $myLibPath) 
    { 
        if ($ENV{DKITVERIFICATION} eq "$ENV{HPEESOF_DIR}/design_kit/verification") 
        { 
            if ( ! -d "$ENV{HPEESOF_DIR}/design_kit/verification") 
            { 
                print "\nERROR: Unable to find verification module directory\nVerification tool not 
installed at default\nlocation \$HPEESOF_DIR/design_kit/verification\n"; 
                print "Please set environment variable DKITVERIFICATION to point \nto the design kit 
verification installation directory\n\n"; 
            } else 
            { 
                print "\nERROR: Unable to find verification module directory at\ndefault location 
\$HPEESOF_DIR/design_kit/verification/perl/lib\n"; 
                print "Please set environment variable DKITVERIFICATION\nto point to the installation 
directory\n\n"; 
            } 
        } else 
        { 
            print "\nERROR : Unable to find verification module directory 
\$DKITVERIFICATION/perl/lib\n\n"; 
            print "Please set environment variable DKITVERIFICATION\nto point to the design kit 
verification installation directory\n\n"; 
        } 
        exit 1; 
    } 
# To find the standard supplied libraries in the local path 
    use Cwd; 
    $curDir = cwd; 
} 
use lib "$myLibPath"; 
use lib "$curDir"; 
use dKitCircuit; 
#dKitCircuit->debug(1); 
# This is a simulation to compare ADS vs. Hspice using the verification tool. 
# It is a simple diode in parallel with a DC voltage source. 
# The only variable swept is the forward diode voltage, Vd. The output is  
# intended to be Capacitance and Current vs. Vd. 
# NOTE: There is a required perl script, diode_create.pl, that must be 
# executed before this script. This is so that a model with required 
# parameters can be created for a diode. This script, diode_create.pl, only 
# needs to be executed once. For more details, please see the contents of the 
# diode_create.pl script. 
# This test is written for the forward region (Vdc = 0 to 0.7) for the ndiode 
# and pdiode diodes. 
# Add instance of Diode and Voltage source. 
$D1=dKitInstance->new('diode', "d1"); 
$D1->parameterValue('width', "300u"); 
$D1->parameterValue('length', "250u"); 
$D1->nodeName('n1', 1); 
$D1->nodeName('n2', 0); 
$vd=dKitInstance->new('V',"vd"); 
$vd->parameterValue('Vdc', .9); 
$vd->nodeName('nplus', 1); 
$vd->nodeName('nminus',0); 
# Add DC Analysis Component 
$DC1 = dKitAnalysis->new('DC',"DC1"); 
$DC1->parameterValue('device',"vd"); 
$DC1->parameterValue('parameter',"Vdc"); 
# Add Sweep Plan for Voltage sweep 
$DCSweep = dKitAnalysis->new('SWEEPPLAN_LIN', "Plan1"); 
$DCSweep->parameterValue('start', 0); 
$DCSweep->parameterValue('stop', .8); 
$DCSweep->parameterValue('numPts', 16); 
$DC1->addSweepPlan($DCSweep); 
$SweepPlan1 = dKitAnalysis->new('SWEEPPLAN_PT', "Plan2"); 
$SweepPlan1->parameterValue('values', "-40 25 125"); 
$TempSweep = dKitAnalysis->new('SWEEP', "Sweep2"); 
$TempSweep->parameterValue('parameter', "temp"); 
$TempSweep->addSweepPlan($SweepPlan1); 
$TempSweep->addSubAnalysis($DC1); 
# Add output plans to measure parameters. 
# $OUTPUTNODES = dKitAnalysis->new('OUTPUTPLAN_NODES', "out1"); 
# $OUTPUTNODES->parameterValue('nodes',1); 
# $DC1->addOutputPlan($OUTPUTNODES); 
$OUTPUTCURRENTS = dKitAnalysis->new('OUTPUTPLAN_CURRENTS', "out2"); 
$OUTPUTCURRENTS->parameterValue('deviceTerminals',"vd:1"); 
$DC1->addOutputPlan($OUTPUTCURRENTS); 
$OUTPUTDOPS=dKitAnalysis->new('OUTPUTPLAN_DOPS', "out3"); 
$OUTPUTDOPS->parameterValue('deviceParameters', "vd:i d1:Cd"); 
$DC1->addOutputPlan($OUTPUTDOPS); 
# Add Options Block 
$OPTION1=dKitInstance->new('SIMULATOROPTION', "myOptions"); 
$OPTION1->parameterValue('spectreOptions', "lang=spectre reltol=1e-5 vabstol=1e-8 iabstol=1e-8 
digits=10 save=lvlpub rawfmt=psfascii"); 
$OPTION1->parameterValue('adsOptions', "ResourceUsage=yes UseNutmegFormat=no ASCII_Rawfile=yes 
I_AbsTol=1e-8 V_AbsTol=1e-8 I_RelTol=1e-5 V_RelTol=1e-5 Temp=27"); 
$OPTION1->parameterValue('hspiceOptions', "ingold=2 numdgt=10 nopage acct=0 dccap=1 abstol=1e-8 
reltol=1e-5 absvdc=1e-8"); 
# Add Library Models 
# The ads, hspice and spectre model files must be placed in the same directory as this script. 
$MODLIB=dKitInstance->new('MODELLIBRARY', "my_model"); 
$MODLIB->parameterValue('adsModelLibrary', "my_model_nom_ads.net"); 
$MODLIB->parameterValue('hspiceModelLibrary', "my_model_nom_hspice.lib"); 
$MODLIB->parameterValue('spectreModelLibrary', "my_model_nom_spectre.scs"); 
$MODLIB->parameterValue('adsSectionName', "nominal"); 
$MODLIB->parameterValue('hspiceSectionName', "nominal"); 
$MODLIB->parameterValue('spectreSectionName', "nominal"); 
# Build the circuit 
$testName = "test_diode_dc";  # Change this circuit name depending upon which 
                              # model you are testing. 
$CIRCUIT=dKitCircuit->new($testName); 
$CIRCUIT->addSimulatorOption($OPTION1); 
$CIRCUIT->addModelLibrary($MODLIB); 
$CIRCUIT->addAnalysis($TempSweep); 
$CIRCUIT->addInstance($D1); 
$CIRCUIT->addInstance($vd); 
@device = ("ndiode", "pdiode"); 
for $device (@device) 
{ 
    $testName = "test_" . $device . "_dc"; 
    $CIRCUIT->circuitName($testName); 
    $D1->parameterValue('model', $device); 
    $CIRCUIT->simulate('ads','hspice','spectre'); 
    #### calculate statistics ... 
     
    $adsDataP = dKitResults->getResults($CIRCUIT->circuitName, "ads"); 
    $spectreDataP = dKitResults->getResults($CIRCUIT->circuitName, "spectre"); 
    $hspiceDataP = dKitResults->getResults($CIRCUIT->circuitName, "hspice"); 
    $diff = dKitResults->compareDataRelative($adsDataP, $spectreDataP); 
    $diff->writeCitifile("$CIRCUIT->circuitName" . "_asdiff.cti", "diffAdsSpectre"); 
    print $diff->calculateStatistics("$CIRCUIT->circuitName" . "_asstat.dat"); 
    $diff = dKitResults->compareDataRelative($adsDataP, $hspiceDataP); 
    $diff->writeCitifile("$CIRCUIT->circuitName" . "_ahdiff.cti", "diffAdsHspice"); 
    print $diff->calculateStatistics("$CIRCUIT->circuitName" . "_ahstat.dat"); 
    $diff = dKitResults->compareDataRelative($hspiceDataP, $spectreDataP); 
    $diff->writeCitifile("$CIRCUIT->circuitName" . "_hsdiff.cti", "diffHspiceSpectre"); 
    print $diff->calculateStatistics("$CIRCUIT->circuitName" . "_hsstat.dat"); 
}

diode_create.pl

The diode_create.pl script will create a two port network that will represent the diode used in the diode simulations. This script must be executed before any of the other diode scripts are ran. It is only required to be executed once. Once the script is executed, it will append dKitTemplate.pm to the template file. This is the required template for the diode.

#!/usr/bin/perl 
BEGIN { 
    if ($ENV{DKITVERIFICATION} eq "") 
    { 
        if ($ENV{HPEESOF_DIR} eq "") 
        { 
            print "\nPlease set environment variable DKITVERIFICATION\nto point to the design kit 
verification installation directory\n\n"; 
            exit 1; 
        } else 
        { 
            $ENV{DKITVERIFICATION} = "$ENV{HPEESOF_DIR}/design_kit/verification"; 
        } 
    } 
    $myLibPath = "$ENV{DKITVERIFICATION}/perl/lib"; 
    if ( ! -d $myLibPath) 
    { 
        if ($ENV{DKITVERIFICATION} eq "$ENV{HPEESOF_DIR}/design_kit/verification") 
        { 
            if ( ! -d "$ENV{HPEESOF_DIR}/design_kit/verification") 
            { 
                print "\nERROR: Unable to find verification module directory\nVerification tool not 
installed at default\nlocation \$HPEESOF_DIR/design_kit/verification\n"; 
                print "Please set environment variable DKITVERIFICATION to point\nto the design kit 
verification installation directory\n\n"; 
            } else 
            { 
                print "\nERROR: Unable to find verification module directory at\ndefault location 
\$HPEESOF_DIR/design_kit/verification/perl/lib\n"; 
                print "Please set environment variable DKITVERIFICATION\nto point to the installation 
directory\n\n"; 
            } 
        } else 
        { 
            print "\nERROR : Unable to find verification module directory 
\$DKITVERIFICATION/perl/lib\n\n"; 
            print "Please set environment variable DKITVERIFICATION\nto point to the design kit 
verification installation directory\n\n"; 
        } 
        exit 1; 
    } 
# To find the standard supplied libraries in the local path 
    use Cwd; 
    $curDir = cwd; 
} 
use lib "$myLibPath"; 
use lib "$curDir"; 
# This script will create a two port network that will represent the diode 
# used in the diode simulations. This script must be executed before any of 
# the other diode scripts are ran. It is only required to be executed once. 
# Once executed, this script will append to the template file, 
# dKitTemplate.pm, the required template for the diode. 
### begin of script file 
use dKitTemplate; 
### add here the perl commands to create the new templates 
$diode = dKitTemplate->new('diode'); 
$diode->requiredPrefix("d"); 
$diode->addNode("n1"); 
$diode->addNode("n2"); 
$diode->addParameter("model"); 
$diode->addParameter("length"); 
$diode->addParameter("width"); 
$diode->addParameter("temp"); 
$diode->netlistInstanceTemplate('ads', '<model>:#instanceName %n1 %n2 Length=<length> Width=<width> 
[[temp=<temp>]]'); 
$diode->netlistInstanceTemplate('spectre', '#instanceName %n1 %n2 <model> length=<length> 
width=<width> [[temp=<temp>]]'); 
$diode->netlistInstanceTemplate('hspice', '#instanceName %n1 %n2 <model> l=<length> w=<width> 
[[temp=<temp>]]'); 
### update new dKitTemplate.pm file 
#print dKitTemplate->componentTemplates2perl; 
dKitTemplate->createTemplateModule; 
### end of script module

diode_parameter.pl

The diode_parameter.pl script will add the Diode Parameter, Cd, to the Design Kit Parameter list for Hspice.

#!/usr/bin/perl 
BEGIN { 
    if ($ENV{DKITVERIFICATION} eq "") 
    { 
        if ($ENV{HPEESOF_DIR} eq "") 
        { 
            print "\nPlease set environment variable DKITVERIFICATION\nto point to the design kit 
verification installation directory\n\n"; 
            exit 1; 
        } else 
        { 
            $ENV{DKITVERIFICATION} = "$ENV{HPEESOF_DIR}/design_kit/verification"; 
        } 
    } 
    $myLibPath = "$ENV{DKITVERIFICATION}/perl/lib"; 
    if ( ! -d $myLibPath) 
    { 
        if ($ENV{DKITVERIFICATION} eq "$ENV{HPEESOF_DIR}/design_kit/verification") 
        { 
            if ( ! -d "$ENV{HPEESOF_DIR}/design_kit/verification") 
            { 
                print "\nERROR: Unable to find verification module directory\nVerification tool not 
installed at default\nlocation \$HPEESOF_DIR/design_kit/verification\n"; 
                print "Please set environment variable DKITVERIFICATION to point\nto the design kit 
verification installation directory\n\n"; 
            } else 
            { 
                print "\nERROR: Unable to find verification module directory at\ndefault location 
\$HPEESOF_DIR/design_kit/verification/perl/lib\n"; 
                print "Please set environment variable DKITVERIFICATION\nto point to the installation 
directory\n\n"; 
            } 
        } else 
        { 
            print "\nERROR : Unable to find verification module directory 
\$DKITVERIFICATION/perl/lib\n\n"; 
            print "Please set environment variable DKITVERIFICATION\nto point to the design kit 
verification installation directory\n\n"; 
        } 
        exit 1; 
    } 
# To find the standard supplied libraries in the local path 
    use Cwd; 
    $curDir = cwd; 
} 
use lib "$myLibPath"; 
use lib "$curDir"; 
use dKitParameter; 
# This script will add the Diode Parameter, Cd, to the DK Parameter 
# list for Hspice. 
$Cd = dKitParameter->new('Cd');  # The diode diffusion capacitance. 
$Cd->description("Diode Diffusion Capacitance"); 
$Cd->dialectReference('hspice', 'lx5ofdevice'); 
$Cd->dialectReference('ads', 'Cd'); 
$Cd->dialectReference('spectre', 'Cd'); 
$Cd->resultName("cd"); 
dKitParameter->createParameterModule;