4 Writing Diva Verification Rules

Introduction

The verification rules files contains DRC and Extraction rules, ERC rules, and LVS rules. You write these rules into the verification rules file using the SKILL commands described in this manual.

There are times when you might make changes for a particular verification run. You do this by using commands that apply only to that run, and you put these run-specific commands in a separate file that you call when you perform a DRC or an extraction.

The following sections describe the rules you need for a verification rules file and also the commands you need for a run-specific file.

Creating a Verification Rules File

To run Design Rule Checking (DRC) and Extraction on your design, you must define your DRC and extraction rules. You use a text editor to write these rules into a verification rules file using the SKILL commands defined in this manual. You can place these rules in a technology library or anywhere else in your system. When you start DRC or Extraction, the program prompts you for the location of the rules.

You can create a verification rules file by doing the following.

Use the SKILL commands described in this manual to create your rules and control their processing.
Place all DRC and Extraction rules in the drcExtractRules( ) command, even though DRC and Extraction are unrelated processes you run separately. Diva verification uses SKILL commands to define the verification tasks it will execute.
Use the ivIf commands to control the processing of the verification rules.
Store the rules file in the required location. The default file names are divaDRC.rul and divaEXT.rul, and the default location is in the technology library. However, you can store the rules anywhere with any name you choose. If you store the rules in a technology library, the rules file name must contain a dot to distinguish it from other library entries. If you use a standard convention of adding .rul to your file names, you can always identify the Diva verification rules files.

Grouping Commands

When you create a verification rules file, you must group the commands defining the rules under three SKILL commands that correspond to the three Diva verification programs (DRC/Extract, ERC, and LVS). For example, you must put all rules commands pertaining to extraction under the drcExtractRules() command. The table shows the processes associated with each SKILL command.

Program	Command	Process
DRC/Extract	drcExtractRules( )	Layer Processing
		Design Rule Checking
		Connectivity Extraction
		Device Extraction
		Parameter Extraction
		Parasitic Extraction
		Resistance Extraction
ERC	ercRules( )	Electrical Rule Checking
LVS	lvsRules( )	Layout Versus Schematic Comparison

Nesting Commands

When creating verification rules, you can save time and effort by nesting commands inside other commands. Instead of creating two or three separate commands, you can combine them. You can nest commands to any depth.

This is particularly useful when you need to specify derived layers. A derived layer is a symbolic name for the result of a verification command. When you create a rule that uses a derived layer, you can do it in two ways. The first is to write the command that creates the derived layer and then use the name of the derived layer in a second command. A second and easier method is to write only one command, substituting the command that generated the derived layer for the derived layer name.

In this example, the command geomAnd("poly" "diff") creates a derived layer and is nested within the drc command.

drc( geomSize( geomAnd( "poly" "diff") 2.0 ) 
 "cut" sep < 2 )

Another way of nesting commands is to define multiple layers in a command. You can use the geomCat command to group the layers. In this example, geomCat is nested within the geomAnd command and groups the layers poly1, poly2, and poly3.

gate = geomAnd( geomCat( "poly1" "poly2" "poly3" )"diff" )

You can also substitute the value resulting from a layer property command anywhere a dimension is specified in a DRC. For example, instead of specifying an integer as the width dimension in the command

drc( "poly” width <3 )

you can nest the layer property command techGetLayerProp( techId "poly" "minWidth" ) within the DRC command

cvId = ivGetCellView()

techId = techGetTechFile(cvId)

drc( "poly" width < techGetLayerProp( techId "poly" "minWidth" ))

For more information, see ivGetCellView ().

Compiling and Optimizing Commands

Diva uses a compiled and optimized version of the rules you provide. Compilation and optimization is the first step in the execution of DRC or extraction. However, Diva does not have to compile and optimize the rules for every run. By saving the compiled form of a rule file time is saved in following runs in the same workbench session. Compilation and optimization is done only when you reference a new rule set for the first time, when you change the rules, when you change the switch (ivIF switches) settings, or if your rules use the ivGetCellView SKILL procedure.

Optimization reduces run time, is usually invisible to you, and has no effect on the final results of the run. In some cases, you may observe changes in the order of command execution.

You should be aware of the following optimizations.

A rule is eliminated if its output layer is not referenced by any other rule.
All DRC checks to be performed on the same input layers are combined and processed in a single pass.
All derived layer operations to be performed on the same input layers using the same internal engine are processed in one pass.
All duplicate nested commands are extracted and performed only once.
All parameters and parasitics on the same layer are extracted in a single pass.

Derived layers are deleted immediately after completion of the last task that references them. You can save disk space by arranging your rules to minimize the number of tasks between the task which generates a layer and the last task that uses the layer.

Compilation and optimization are performed after you have defined the ivIF switch settings so Diva knows which commands are to be executed and can process them accordingly.

Using Wildcards

You can specify names using wildcard characters for various Diva verification commands. There are two levels of wildcards:

Simple wildcards
You can use the character “*” as a prefix or suffix to any label.
This form of wildcards is easy to use, but does not allow the complex substitution available in regular expressions.
Regular expression wildcards
This format is the same as the format used in UNIX and in the SKILL procedure rexMatch. This level of wildcards allows far more complex expressions than the “*” wildcards described above.

Diva can confuse special symbols in regular expressions with simple wildcards or with special symbols normally used in network names. To distinguish between simple wildcards and regular expressions, you must prefix all regular expressions with a “?”. For example, gnd* uses a simple wildcard evaluation. ?gnd* uses the general expression evaluation.

The following table summarizes wildcard expressions:

Wildcard	Meaning
gnd*	The program recognizes any characters for “*”
*gnd	The program recognizes any characters for “*”
gnd	The program recognizes any characters for both “*”s
*	Matches any string
**	Matches any string
?gnd*	Interprets gnd* as a regular expression

Limitations

If you have a normal label containing the character “*” at the beginning or end of its name, Diva interprets it as a simple wildcard character. To avoid this, you must convert the references to each label in Diva’s commands into a regular expression by placing a “\” before the “*”. For example, reference clk* as ?^clk\*. Diva recognizes this as a regular expression and translates it back to the original form. The “^” in this expression specifies that no other clk expressions match this one.

Regular expressions take up considerable CPU time. Do not use regular expression if you can avoid them.

Sample Verification Rules File

This is a sample verification rules file for a standard pwell CMOS process. This file contains both DRC and extraction rules and uses the default switches drc? and extract?.

drcExtractRules(

/* The first section contains the geomOr statements that associate symbols with the physical layers to create derived layers. You can use these symbols in the rest of the rule set. You must put the geomOr statements before any switches so they are executed regardless of which switch you use at run time.

*/

bkgnd = geomBkgnd()
 poly = geomOr( "poly" )
 active = geomOr( "active" )
 gate = geomOr( "gate" )
 contact = geomOr( "contact" )
 metal1 = geomOr( "metal1" )
 via = geomOr( "via" )
 metal2 = geomOr( "metal2" )

/*

DRC RULES FOR PWELL CMOS
The first ivIf switch is the drc? switch. If you use this switch, 
the DRC part of the file automatically executes during a DRC run.

*/

ivIf( switch( "drc?" ) then

/*

 * POLY RULES

*/

 drc( poly width < 3 "Poly width < 3.0 " ) 
 drc( poly sep < 3 "Poly to Poly spacing < 3.0" ) 
 drc( poly notch < 3 "Poly to Poly spacing < 3.0" ) 
 drc( poly active sep < 2 "Field Poly to Active spacing < 
     2.0" )

/* The next three lines define the gate area and its edges.

*/

gate = geomAnd( poly active ) 
gatew = geomGetEdge( gate inside poly ) 
gatel = geomGetEdge( gate coincident poly )

/* The next two commands check the gate extension onto the field and the source/drain enclosure of the gate. */

*/

drc( poly gatew enc < 3 opposite "Poly gate overlap onto field < 3.0" ) 
drc( active gatel enc < 3 opposite "Source/Drain enclosure of gate < 3.0" )

/*

 * CONTACT RULES

/* The saveDerived statements output bad contact geometries to the error layer. The first command outputs parts of the contacts that are not covered by the poly or active shapes; the second command outputs parts of the contacts that are not covered by metal.

*/

saveDerived( geomAndNot( contact geomOr( active poly ) ) 
"Contact not inside Active or Poly" ) 
 saveDerived( geomAndNot( contact metal1 ) 
"Contacts not covered by Metal1" ) 
 drc( contact width < 3 "Contact width < 3.0" ) 
 drc( contact sep < 3 "Contact to Contact spacing < 3.0" ) 
 drc( poly contact enc < 2 "Contact inside Poly < 2.0" ) 
 drc( metal1 contact enc < 2 "Contact inside Metal1 < 2.0" ) 
 drc( active contact enc < 2 "Contact inside Active < 2.0" )

/*

 * METAL1 RULES

*/

 drc( metal1 width < 3 "Metal1 width < 3.0" ) 
 drc( metal1 sep < 4 "Metal1 to Metal1 spacing < 4.0" ) 
 drc( metal1 notch < 4 "Metal1 to Metal1 spacing < 4.0" )

/*

 * VIA RULES
 drc( via width < 3 "Via width < 3.0" ) 
 drc( via sep < 3 "Via to Via spacing < 3.0" ) 
 drc( via contact sep < 3 "Via to Contact spacing < 3.0" )

/* This saveDerived statement outputs vias that overlap onto contacts.

*/

saveDerived( geomOverlap( via contact ) "Via not allowed over contacts" ) 
 drc( via poly sep < 2 "Via to Poly spacing < 2.0" )

/* This saveDerived statement outputs vias that overlap onto poly.

*/

saveDerived( geomOverlap( via poly ) "Via not allowed over Poly" ) 
 drc( metal1 via enc < 2 "Via inside Metal1 < 2.0" ) 
 drc( metal2 via enc < 2 "Via inside Metal2 < 2.0" )

/* The next two saveDerived statements output the parts of vias that are not covered by metal1 or metal2. */

*/

saveDerived( geomAndNot( via metal1 ) "Via not inside 
Metal1" ) 
saveDerived( geomAndNot( via metal2 ) "Via not inside 
Metal2" )

/*

 * METAL2 RULES

*/

 drc( metal2 width < 5 "Metal2 width < 5.0" ) 
 drc( metal2 sep < 5 "Metal2 to Metal2 spacing < 5.0" ) 
 drc( metal2 notch < 5 "Metal2 to Metal2 spacing < 5.0" )
 )

/*

 * EXTRACT RULES FOR PWELL CMOS

/* The second ivIf switch is the extract? switch. If you use this switch, the extraction part of the file automatically executes during an extract run.

*/

ivIf( switch( "extract?" ) then

/* The first section of the extraction part of the rules contains the geomOr statements that change the physical layers used only for extraction to symbols that you can use in the rest of the extraction rule set. 
You must precede special characters used in layer names with a backslash, so layer “p+” is renamed “p\+” and layer “n+” is renamed “n\+”.

*/

 well = geomOr( "well" )
 ngate = geomOr( "ngate" )
 pgate = geomOr( "pgate" )
 psd = geomOr( "psd" )
 p\+ = geomOr( "p+" )
 nsd = geomOr( "nsd" )
 n\+ = geomOr( "n+" )

/* This section contains boolean commands such as geomAnd and geomAndNot that create new layers for device recognition and define interconnections between layers.

*/

 nwell = geomAndNot( bkgnd well ) 
 pdiff = geomAnd( active p\+ )
 ndiff = geomAnd( active n\+ )
 pgate = geomAnd( poly pdiff ) 
 ngate = geomAnd( poly ndiff ) 
 psd = geomAndNot( pdiff poly ) 
 nsd = geomAndNot( ndiff poly )
 ptap = geomAnd( well psd ) 
 ntap = geomAnd( nwell nsd )
 ptie = geomOr( ptap )
 ntie = geomOr( ntap )

/* The geomConnect statement defines the connections between the layers and establishes the network to be extracted.

*/

 geomConnect(
 via( via metal1 metal2 )
 via( contact psd nsd poly metal1 )
 via( ntie nsd ntap )
 via( ptie psd ptap )
 )

/* The geomStamp statement transfers connectivity information from one layer to another. The following example transfers the well tie connectivity to the well itself. This prevents the well from acting as a connection layer forming soft connects.

*/

 nwell = geomStamp( nwell ntap error )
 well = geomStamp( well ptap error )

/* The extractDevice statements define the devices used in the circuit.

*/

 extractDevice( pgate (poly "G")(psd "S" "D") (nwell "B")
 "pfet ivpcell" )
 extractDevice( ngate (poly "G") (nsd "S" "D") (well "B")
 "nfet ivpcell" )

/* The measureParameter commands extract device parameters. These parameters can then be checked when you run an LVS.  

Use the coefficient 0.5 to measure the gate width and gate length parameters because the measureParameter command measures the length of all edges defined in the rule and you only want the length of one edge. For example, to measure the length of a gate, measure the length of the gate edges that are inside and not coincident with poly. Two edges satisfy that requirement. If you do not multiply by 0.5, you are counting the gate length twice.

*/

 pgateWidth = measureParameter( length ( pgate coincident poly ) 0.5 )
 pgateLength = measureParameter( length ( pgate inside poly ) 0.5 )

/* Add the parameters to the devices by using the saveParameter command. The parameter names must be the same as the names that are used in the LVS rules.

*/

 saveParameter( pgateWidth "w" )
 saveParameter( pgateLength "l" )
 ngateWidth = measureParameter( length ( ngate coincident poly ) 0.5 )
 ngateLength = measureParameter( length ( ngate inside poly ) 0.5 )
 saveParameter( ngateWidth "w" )
 saveParameter( ngateLength "l" )

/* The saveInterconnect command writes layers to the extracted cellview. Save the layers defined in the geomConnect command so that you can cross-probe your nets after running LVS.

*/

 saveInterconnect( nsd psd poly contact metal1 via metal2 )

/* The saveRecognition command creates the device recognition polygons in the extracted cellview. It is used in conjunction with the Model view name ivpcell in the extractDevice or extractMOS command.

*/

 saveRecognition( ngate "ngate" ) 
 saveRecognition( pgate "pgate" ) 
 )
)

ERC and LVS Verification Rules

To run Electrical Rules Check (ERC) or Layout Versus Schematic (LVS) on your design, you must define your ERC and LVS rules. You write these rules into a text format verification rules file using the SKILL commands defined in this manual. You can place these rules files in a technology library or anywhere else in your system. When you start ERC or LVS, the program prompts you for the location of the rules.

To create verification rules files, you do the following:

Use the SKILL commands described in the ERC and LVS chapter to create a separate text rules file for each program.
Put all ERC rules in the ercRules( ) command. Diva verification uses SKILL commands to define the verification tasks it will execute.
Put all LVS rules in the lvsRules( ) command.
Enter the commands in the correct order, because this porduct processes the commands as it encounters them.
Enter SKILL commands for parameter reduction and comparison before the ERC and LVS verification commands.
Store the rules files in the required location. There are no default names for these files, and you can store them in the technology library or anywhere else with any name. If you store the rules in a technology library, the rules file name must contain a dot to distinguish it from other library entries. If you use a standard convention of adding .rul to your file names, you can always identify the Diva verification rules files.

Unlike DRC/Extract, there is no if-then-else capability for ERC and LVS. In addition, ERC and LVS verification commands are not optimized or rearranged.

During ERC and LVS processing, the rules are copied to the run directory you define and are stored with the pre-set names divaLVS.rul and divaERC.rul.

Sample ERC Rules File

This section contains a sample ERC verification rules file.

ercRules(
setPower( "vdd!" ) 
setGround( "gnd!" )

/* Identifies vdd! nets as power nets and gnd! nets as ground nets. */

twoWayPath( "pfet" "S" "D" )  
twoWayPath( "nfet" "S" "D" )

/* Defines all pfets as having bidirectional current paths from Source to Drain and all nfets as having bidirectional current paths from Source to Drain. */

checkPullUp( ) 
checkPullDown( )

/* Checks all nets for a path from the net through devices to nets identified as power nets. Then checks all nets for a path from the net through devices to nets identified as ground nets. */

checkFloatingDevices( )
checkOneNetDevices( )

/* Flags all devices with no connection to any part of the circuit. Then flags all devices with only one connection to any part of the circuit. */

checkFloatingNets( )
checkOneTerminalNets( )

/* Flags all nets with no connection to any part of the circuit. Then flags all nets with only one connection to any terminal of a device. */

checkNotConnected( "pfet" "B" "vdd!" )
checkConnected( "nfet" "S" "vdd!" )

/* Flags all devices with the specified terminal not connected to the named net. Then flags all devices when the specified terminal is connected to the named net. */

reduceDevice( MOS "pfet" )

/* Reduces the specified device to a logically equivalent gate-level circuit. (You must use setPower and setGround to identify supplies.) */

reduceDevice( MOS "nfet" logic )

/* Reduces the specified device to a logically equivalent gate-level circuit. Uses keyword logic to signal device types used to form the logic portion of gates. (You must use setPower and setGround to identify supplies.) */

/* The right parenthesis terminates the ercRules. */

Sample LVS Rules Files

This section contains two sample LVS verification rules files.

Sample CMOS Rules File

The following is a sample LVS verification rules file for CMOS devices.

lvsRules(
procedure( compareFet( layPlist, schPlist )

/* The first SKILL procedure, compareFet, compares the width and length of active devices. The compareFet procedure uses two variables, layPlist, which contains the parameter list from the layout device being checked, and schPlist, which contains the parameter list for the schematic device being checked. */

prog( ( )
    if( layPlist->w != nil && schPlist->w != nil then
     if( layPlist->w != schPlist->w then
       sprintf( errorW,
        "Gate width mismatch: %gu layout to %gu schematic",
          float( layPlist->w ), float( schPlist->w ) )
       return( errorW )
     )
    )

/* First, compareFet checks that both lists contain the property w and, if they do, compares the values of the properties. If the values are not the same, compareFet returns an error. */

   if( layPlist->l != nil && schPlist->l != nil then
     if( layPlist->l != schPlist->l then
       sprintf( errorL,
        "Gate length mismatch: %gu layout to %gu schematic",
          float( layPlist->l ), float( schPlist->l ) )
       return( errorL )
     )
    )
 return( nil )
 ) ; prog
) ; compareFet

/* Next, compareFet checks that both lists contain the property l and, if they do, compares the values of the properties. If the values are not the same, compareFet returns an error. */

 procedure( parallelMOS( m1Plist, m2Plist )

/* The next SKILL procedure, parallelMOS, combines the parameters of parallel MOS transistors in the netlist for the parameter comparison done by the preceding procedure. parallelMOS uses two variables, m1Plist, which contains the parameter list from the first device of the pair of devices to be consolidated, and m2Plist, which contains the parameter list for the second device of the pair of devices to be consolidated. */

prog( ( parMos )
 parMos = ncons( nil )
    if( m1Plist->l != nil && m2Plist->l != nil then
     parMos->l = ( m1Plist->l + m2Plist-> l ) / 2.0
    )

/* First, parallelMOS checks that both lists contain the property l and, if they do, adds the values of the two properties together and divides them by 2. */

   if( m1Plist->w != nil && m2Plist->w != nil then
     parMos->w = m1Plist->w + m2Plist->w
    )

/* Next, parallelMOS checks that both lists contain the property w and, if they do, adds the values of the two properties together. */

return( parMos )
 ) ; prog
 ) ; parallelMOS

/* The new device created by parallel consolidation contains the properties l and w, set to the values calculated by the procedure. If the properties l or w do not exist, or have no value for the devices being consolidated, the new device does not have the l or w properties. */

 /* The third part of this file contains the actual LVS rules for device permutation and parameter comparison. */

permuteDevice( parallel "pfet" parallelMOS )
permuteDevice( parallel "nfet" parallelMOS )
permuteDevice( MOS "pfet" )
permuteDevice( MOS "nfet" )

/* The permute parallel statements reference the procedure parallelMOS to consolidate the parameters of devices being permuted. */

compareDeviceProperty( "pfet" compareFet )
compareDeviceProperty( "nfet" compareFet )
) ; lvsRules

/* The compare statements reference the compareFet procedure and cause parameter comparison to take place. */

Sample Bipolar Rules File

The following is a sample LVS verification rules file for bipolar devices.

lvsRules( 
 procedure( parallelRes( r1Plist, r2Plist )

/* The SKILL procedure parallelRes combines the resistance values of parallel resistors. First, the procedure reads the list of properties from the first resistor in the parallel reduction (r1Plist) and compares that list to the list of properties from the second resistor in the parallel reduction (r2Plist). */

    prog( ( parPlist myPort )
    parPlist = ncons( nil )
    myPort = outfile( "/user/project/LVS/Resistors.val"    
      "a")
    if( r1Plist->r != nil && r2Plist->r != nil then
    parPlist->r = 
      ( r1Plist->r * r2Plist->r ) / ( r1Plist->r + r2Plist->r )

/* If parallelRes finds the property r in both lists, it divides the product of r1Plist x r2Plist by the sum of r1Plist + r2Plist. The result of the calculation is returned to the new parallel-resistor device as the value of its property r. */

   if( myPort == nil then
     printf( "Can’t open parallelRes IO port - myPort") else
     fprintf( myPort,
       "Parallel Resistor value is %g \n", float( 
      parPlist->r) )
     close( myPort )
    )
    return( parPlist )
 )
 )
 procedure( seriesRes( r1Plist, r2Plist )

/* The seriesRes procedure combines the resistance values of series resistors. First, the procedure reads the list of properties from the first resistor in the series reduction (r1Plist) and compares that list to the list of properties from the second resistor in the series reduction (r2Plist). */

prog( ( serPlist myPort )
    serPlist = ncons( nil )
    myPort = outfile( "/user/project/LVS/Resistors.val" "a" )
    if( r1Plist->r != nil && r2Plist->r != nil then
     serPlist->r = ( r1Plist->r + r2Plist->r )
    )

/* If seriesRes finds the property r in both lists, it then adds (+) the values of the two properties. The result of the calculation is returned to the new series-resistor device as the value of its property r. */

   if( myPort == nil then
     printf( "Can’t open seriesRes IO port - myPort") else
     fprintf( myPort, 
       "Series Resistor value = %g \n", float( serPlist->r ) )
     close( myPort )
    )
 return( serPlist )
 )
 )
 procedure( compareRes( layRes, schRes )

/* The compareRes procedure compares the resistance values calculated during the parallel and series consolidation of resistors. First, the procedure reads the list of parameters from the [consolidated] resistor in the layout (layRes) and compares it to the list of parameters from the [consolidated] resistor in the schematic (schRes). */

prog( ( )
    if( layRes->r != nil && schRes->r != nil then
     if( abs( layRes->r - schRes->r ) > 0.02 * schRes->r then
       sprintf( error, 
        "Value mismatch: %g ohms (layout) vs %g ohms
       (schematic)",
     float( layRes->r ), float( schRes->r ) )
       return( error )

/* If compareRes finds the property r in both lists, it subtracts the value of r in layRes from the value of r in schRes. If the difference between the values is greater than 2%, compareRes returns an error; if not, the resistor values are considered matched. */

    ) 
    return( nil )
    )
 )
 )

/* Parallel and Series Permutation and Parameter Consolidation */

 permuteDevice( parallel "npn" )
 permuteDevice( parallel "pnp" )
 permuteDevice( parallel "resistor" parallelRes )
 permuteDevice( series "resistor" seriesRes )

/* Parameter Comparison */

 compareDeviceProperty( "resistor" compareRes )
)

Creating a Run-Specific File

You use a run-specific file when you want to specify commands that apply only for a particular verification run. You put these run-specific commands in a separate file that you call when you perform a DRC or an extraction.

You can use the SKILL commands to create a run-specific file:

To...	Use...
Add text labels to the verification run without adding them to the original graphics data.	layerText
Define an area of the circuit to be processed by DRC.	verifyArea
Treat all nets having the same name as a single net.	joinableNet
Change the name of one label to another for this verification run only.	changeLabel
Treat labels from lower-level cells as if they were on the top level.	globalLabel
List all marker shapes created during the current or previous Diva verification run.	drcLogFile
Force the area checking halo to be set to zero.	drcZeroHalo
Define the name of the ground net.	groundNet
Define a file of cell names for macro cell extraction.	macroCellFile
Define a SKILL procedure to return the type of a cell instance.	macroCellFunc
Define a SKILL procedure to return the include value of a cell instance.	includeValueFunc

You can put the run-specific file in any directory that is accessible through normal UNIX file conventions. You then specify the name of this file when you use the menu to set the DRC or extraction options or when you use the ?rsf option in the ivDRC and ivExtract commands.

The following sections describe the SKILL commands listed in the table above.

changeLabel

changeLabel( ( oldLabel newLabel ) ...)

Description

Temporarily changes the name of a label without affecting the database. You can use changeLabel as:

An entry in the run specific file.
A property on the cell being verified.
An entry in the verification rules file.

The name change applies only to original labels. If label “a” is changed to “b” and label “b” is changed to “c,” label “a” is never changed to “c.”

The name change applies to labels recognized through the label command and pin names in the geomConnect command in the technology file. For labels, the command changes the name of the net to which it is applied. For pin names, the command generates the pin in the extracted and excell cellviews with the new name.

The label changes every time you run DRC or extraction with those rules if you use changeLabel in the verification rules file. When you use changeLabel in the verification rules file, you must place it before any geomConnect commands.

Fields

oldLabel newLabel

Specify two text names, each enclosed in quotation marks, defining the old (existing) label name and its new (replacement) name.

Use the new name in place of the old name (except for the geomGetTexted and geomGetUntexted commands). The name change is global, affecting all cells in the circuit.

You can specify as many name pairs in one changeLabel command as you want.

You can use wildcards only for oldLabel following the Diva verification conventions for wildcards. (See Using Wildcards.) The command changeLabel( "gnd*" "gnd" ) means that both gnd1 and gnd2 are changed to gnd. You cannot change the name of a label to a name that contains wildcards.

Property

You can also use changeLabel as a property of the cell. Only one changeLabel property is allowed per cell. For flat extraction, place the property on the top-level cell. Diva verification ignores any changeLabel property on lower-level cells. For hierarchical extraction, all cells can have this property, and the label affects only the cell where it was placed.

The property uses this format:

changeLabel = "oldLabel newLabel [ oldLabel newLabel ] ..."

This example illustrates the changeLabel property.

changeLabel = VDD vdd! GND gnd!

Example

This example illustrates the changeLabel command.

changeLabel( ( "VDD" "vdd!" ) ( "GND" "gnd!" ))

In this case, the original names of VDD and GND are changed to conform to the local conventions of vdd! and gnd!.

drcLogFile

drcLogFile( file_name [precision [page_width [page_length [line_limit]]]])

Description

Produces a DRC log file that lists all marker shapes created during the current or previous Diva verification run. The log file is created only in DRC and extraction modes. To generate this file, you must add the drcLogFile command to your run-specific file.

While running Diva verification DRC, if you get an error message stating that the the drcLogFile command is only allowed in the run-specific rules (and Diva generates this error message even if you run the command directly in the CIW), it is because you have put the drcLogFile command in the rule file (divaDRC.rul). The run-specific file is different from the rule file. So create a file with the following in it:

drcLogFile( <filename>.log)

where <filename>.log is the name of the file and can have any name.

Then run Diva verification DRC and in the DRC form turn on the Run-Specific Command File field and enter the name of the above file. Depending on the location of the file, you may have to enter the path along with the file name. Now when you run DRC, the <filename>.log is created in the directory you started the tool from. This is true for both the 4.3.4 and 4.4.x releases.

Fields

file_name

Name of the log file. This file is deleted before any text is written to it, so that existing data in the file is overwritten.

precision

Number of digits to the right of the decimal point to be used when the numbers are printed. For example, a value of 2 might cause coordinates to be printed such as 5.25, while a value of 3 might produce 5.252. The default value is 2.

In order to conserve disk space, a number such as 5.000 is always printed as 5, no matter what the precision.

page_width

Page width. The default is 80 characters. Lines that exceed 80 characters are broken into multiple lines.

page_length

Page length. The default is 0, which disables this feature. If you use this argument, the system inserts a page header at the top of each page.

line_limit

Specifies the limit at which the program stops printing to the log file. The default is no limit.

If this command is used without arguments, the drcLogFile log is written to the CIW.

Example

drcLogFile( "DRC.log" )

drcZeroHalo

drcZeroHalo( status )

Description

Sets (or resets) the halo to be used in area processing to zero. This halo is the distance added around the checking area to ensure all interactions and relationships that could affect the data in the area are included.

The halo distance normally used depends on the dimensions in the rules file. For some rule sets, the halo can be very large and can have a serious impact on run time.

This command can miss true violations, so use it carefully.

This command is disabled when running in hierarchical or incremental modes. This command overrides the ivVerify command -z option for this run.

Placing the drcZeroHalo command in the .cdsinit file sets the mode for the duration of the interactive session. Used in a run-specific file, this command sets the mode for a single Diva verification invocation.

Fields

status

Options used for status.

t

Sets the status to true and turns on the zero halo option, which sets the halo to a value of zero.

nil

Sets the status to false and turns off the zero halo option, which leaves the halo value at its automatic calculated value.

Examples

drcZeroHalo( t )

drcZeroHalo( nil )

globalLabel

globalLabel( layer label [label] )

Description

Treats labels as if they are on a top-level cell even though they actually come from lower level cells. For example, you can use power and ground labels inside subcells for net labeling.

The default purpose for the layer is drawing. To specify other purposes, you can use this command.

globalLabel( (layer purpose) label )

The label is always considered to be the drawing purpose, regardless of the original purpose of the text.

You can also use this command in the verification rules file. When you use it in a verification rules file, you must place it before any geomConnect command. Other commands that process text, such as geomGetTexted, are also affected by this command.

Prerequisite

The globalLabel command must precede the command that uses the labels.

Note: Other commands that process text, such as geomGetTexted, are also affected by this command.

Fields

layer

Original graphics layer containing the label you want treated as if it is on a top-level cell. You can define the textLayer in two formats:

`"layer"`	The label is accessed from the drawing purpose and remains on the drawing purpose.
`("layer" "purpose")`	If you specify a purpose, such as pin or text, the labels are accessed only from that purpose and remain on that purpose. If you specify the purpose all, the labels are accessed from all purposes and remain on their original purposes.

label

Label you want treated as if it is on a top-level cell.

You can use wildcard characters following the Diva verification conventions for wildcards. (See the “Using Wildcards” section.)

Examples

In this example, power and ground are properly labeled even though there are no vdd! or gnd! labels at the top-level cell.

globalLabel( "met1_lab"
"vdd!"
"gnd!" )

geomConnect(

 via( via metal1 metal2 )

 via( cus diff poly metal1 )

 label( "met1_lab" metal1 )

If two globalLabel commands apply to the same layer, you can combine them into a single command. For example,

globalLabel( “l1” “a” )

globalLabel( “l1” “b” )

is the same as

globalLabel( “l1” “a” “b” )

groundNet

groundNet( "net_name" )

Description

Defines a specific net name to be used by programs that make connections to the circuit ground net. If you specify this command, the net name it defines is used instead of the default global ground net, which has the name “0!”.

This command creates the defined net in the extracted circuit regardless of whether the net name exists in the original layout.

The net is defined as a global net, and all nets with the same name are assumed to be joined (as if you defined a joinableNet command). This means any open circuits in the net are not seen in LVS processing.

You can also use this command in the verification rules file. When you use it in a verification rules file, you must place it before any geomConnect command.

If you specify this command more than once, the first command is accepted. Diva verification ignores the remaining occurrences of the command. If you use this command in the RSF, it takes precedence over this same command in the rules file.

When you use this command, a property called ivGroundNetName is added to the extracted and abstract cellviews. The content of the property is a string whose value is the defined net name.

Fields

"net_name"

The name of the ground net. Enclose the net name in double quotation marks.

Example

You can define a ground net as follows:

groundNet( "gnd" )

The following example shows parasitic measurement:

x = measureParasitic( area metal one_net )
saveParasitic( x "PLUS" "MINUS" "c" "capacitor" )

If you do not specify the groundNet command, a parasitic capacitor is created for each area of metal, with one terminal of the capacitor connected to the net to which the metal belongs, and the other terminal connected to “0!”. If you specify the groundNet command, the second terminal of the capacitor is connected to the net specified in the command (in this case, gnd).

joinableNet

joinableNet( [net ...] )

Description

Specifies that selected nets with the same name are to be considered as a single net, not an error. You can use joinableNet as:

An entry in the run specific file.
A property on the cell being verified.
An entry in the verification rules file.

Any two or more nets with the same label that are not specified as joined with a joinableNet command are flagged by a warning.

The nets you selected will be joined every time you run DRC or extraction with those rules if you use joinableNet in the verification rules file. When you use joinableNet in the verification rules file, you must place it before any geomConnect commands.

Fields

net

Any number of net names enclosed in quotation marks. For each name, all separate nets with that name are considered part of a single net. If you do not specify a list, DRC joins all nets.

You can use wildcard characters following Diva verification conventions for using wildcards. (See the section, Using Wildcards.) Only nets with the same name are joined. For example, if you use wildcards to specify gnd*, all nets labeled gnd1 are joined together, and all nets labeled gnd2 are joined together. Nets labeled gnd1 are not joined to nets labeled gnd2.

Examples

This example illustrates the joinableNet command.

joinableNet( "vdd!" "gnd!" "clock1" )

joinableNet( )

This example uses the joinableNet command with the changeLabel command to join nets with different names.

changeLabel(( "vdd1" "vdd" ) ( "vdd2" "vdd" ))

joinableNet( "vdd" )

The separate nets vdd1 and vdd2 are both renamed to vdd with the changeLabel command, and then all nets with the name vdd are specified to be the same net with the joinableNet command.

Property

You can also add joinableNet as a property of the cell. Only one joinableNet property is allowed per cell. For flat extraction, place the property on the top-level cell. Any joinableNet property on lower level cells is ignored. For hierarchical extraction, all cells can have this property, and the property affects only the cells on which it was placed.

The property uses this format:

joinableNet = "net_name1 [ net_name2 ] ..."

This example illustrates the joinableNet property.

joinableNet = vdd! gnd! clock1

layerText

layerText( textLayer xy text [cell] ...)

Description

Temporarily adds text labels to a text layer. The labels appear on the drawing purpose at one user unit in length and in standard orientation.

Fields

textLayer

Layer on which you want to place the label. The labels appear on the drawing purpose at one user unit in height and in standard orientation.

You can define the textLayer in two formats:

`"layer"`	Places text on the drawing purpose.
`("layer" "purpose")`	Places text on the purpose you specify. You cannot specify the purpose all for this layer.

xy

x and y coordinates where you want to place the label, expressed in user units, such as microns. You can use floating point numbers or integers, separated by a colon.

text

Label you want to place. Use a character string enclosed in quotation marks.

cell

Optional cell name defining the name of the cell in which the text is placed. It can have the form

[cellName [viewName [libName ]]]

You must place the names in quotation marks in the following format:

"cell" "cell view" "cell view lib"

If you do not use the cell option, the label is placed in the top-level cell. The default view and library are those of the top-level cell.

If you specify a cellview combination that does not exist, the program ignores the layerText command and issues a warning message. A run generates a maximum of 100 warning messages.

Examples

This example places the label clock_1 on the text layer at coordinates 34:25.

layerText( "text" 34:25 "clock_1")

This example uses a SKILL procedure to loop through the generation of 32 names for a bus. The resultant names become bit_0 to bit_31 in a vertical column at x = 100, with y varying from 200 to 386 in 6 unit steps.

prog( ( i y label )
   for( i 0 31
      y = 200 + 6 * i
      sprintf( label "bit_%d" i )
      layerText( "metalText" 100:y label )
   )
)

macroCellFile

macroCellFile( "filename" )

Description

Provides a file of cell names that controls whether a cell becomes a macro cell or not.

You can use this file in addition to the ivCellType property on a cell. However, the values you define for each cell using the macroCellFile command override the ivCellType property on the cell.

Fields

"filename"

The name or path, in quotation marks, of a text file containing one line per cell with the following format:

# libName cellName viewName value

`#`	Indicates a comment. If you do not specify # on a line, the line is active. If you specify # on a line, that line is ignored. Blank lines are also ignored.
`libName`	Name of the library from which the cell is accessed.
`cellName`	Name of the cell.
`viewName`	Cellview name.

You can define any of the names using wildcard characters following Diva’s conventions for using wildcards. See the “Using Wildcards” section for more information about wildcards.

Value

This argument can have the following values:

macro

Forces the cell to become a macro cell.

graphic

Forces the cell not to become a macro cell.

none

Ignores the ivCellType property and lets the cell become a macro or not based on its prCellType property.

Examples

macroCellFile( "macrocells" )

macroCellFile( "/tmp/mydata/cells" )

The following examples illustrate possible file contents:

 myLib myMacro   layout macro
 myLib nonMacro* routed graphic
#     myLib anyCell   * none

macroCellFunc

macroCellFunc( procedure )

Description

Defines a SKILL procedure that controls whether a cell becomes a macro cell or not.

You can use this command in addition to the ivCellType property on a cell. However, the values the procedure returns for each cell override the ivCellType property on the cell.

Fields

procedure

The name of the SKILL lambda procedure you specify.

The tool passes a list to the procedure. This list contains a database identifier for the instance being tested, or a list containing the database identifier and the number of row and columns if a mosaic instance is being tested.

The procedure return value value can be:

macro	Forces the cell to be a macro cell providing the cell has pins.
graphic	Forces the cell not to be a macro cell.
none	Ignores the procedure and lets the cell become a macro or not based on its pins and prCellType property.

Examples

; procedure to emulate the ivCellType instance
; property using the user defined property myCellType
macroCellFunc( lambda( ( instPath )
   let( ( instId result )

  ; get the leaf instance from the path
   instId = car( instPath )

   ; check for a mosaic stored as ( instId row column )
   when( listp( instId ) instId = car( instId ) )

   ; check if we know what the value should be 
   result = cond(
      ( instId->myCellType instId >myCellType )
      ( t "" )     ;indicate that we don’t know the value

      ); cond

   ; send the answer back
   result
   )
))

includeValueFunc

includeValueFunc( procedure )

Description

Defines a SKILL procedure that can specify the value to use in place of the ivIncludeValue property on the instance or master.

You can use this command in addition to the ivIncludeValue property on a cell. However, the value the procedure returns for each cell override the ivIncludeValue property on the cell.

Fields

procedure

The name of the SKILL lambda procedure you specify.

The procedure return value value can be nil or an empty string to indicate that the procedure is not providing a value, a string representing a number, an integer, or a real number which is rounded to an integer. If a number is returned, it is used instead of an instance or master ivIncludeValue property.

Examples

; procedure to emulate the ivIncludeValue instance
; property using the user defined property myIncludeValue
includeValueFunc( lambda( ( instPath )
   let( ( instId result )

  ; get the leaf instance from the path
   instId = car( instPath )

   ; check for a mosaic stored as ( instId row column )
   when( listp( instId ) instId = car( instId ) )

   ; check if we know what the value should be 
   result = cond(
      ( instId->myIncludeValue instId >myIncludeValue )
      ( t "" )     ;indicate that we don’t know the value

      ); cond

   ; send the answer back
   result
   )
))

verifyArea

verifyArea( ( box [ hole ] ...) ...)

Description

Defines those areas of the circuit you want checked by DRC. You can define the area as one or more rectangles. You can optionally specify that each rectangle has one or more holes in it. The area processed by the DRC program is the area of each rectangle minus the area of the holes.

This command is only available for DRC, it may not be used for Extraction.

Fields

box

Two pairs of coordinates enclosed in parentheses, defining the bottom left and top right of a rectangular area to be checked. Separate the two pairs by at least one space. Each coordinate pair consists of an x and y value in user units, separated by a colon. For example,

( 10:100 5000:2500 )

hole

Pairs of coordinates defining holes in the rectangle. You place the hole coordinate pairs after the box pair but within the same set of parentheses. The format for each hole coordinate pair is the same as for the original box. For example,

( 10:100 5000:2500 50:500 1000:1250 )

Examples

This example illustrates a simple rectangular verification area.

verifyArea( ( 0:0 1000:1400 ) )

This example illustrates a simple rectangular verification area with a single cutout.

verifyArea( ( 0:0 1000:1400 50:100 356:420 ) )

This example illustrates two simple rectangular verification areas.

verifyArea( ( 0:0 1000:1400 ) ( 2000: 2300 4000: 5000 ) )

This example illustrates a combination of areas and holes.

verifyArea((20:100 900:850 30:150 100:600) (1000:950 2000:2110 ))

Sample Run-Specific File

This is a sample run-specific file.

/* The first command checks a rectangular area with a lower left coordinate of (10:100) and an upper right coordinate of (500:250). The next two coordinate pairs establish a (200:120) by (220:150) hole in the rectangle that is not checked. */

verifyArea( ( 10:100 500:250 200:120 220:150 ) )

/* This command places the string out1on the text layer at the xy location (30:50). It also specifies the cell sreg in which the text label is to be placed. */

layerText( "text" 30:50 "out1" "sreg" )

/* This command changes all VDD and VCC labels to vdd! for the current run only. */

changeLabel( ("VDD "vdd!" ) ( "VCC" "vdd!" ) )

/* This command joins all disjoint nets of the same name. */

joinableNet( )

/* This command brings all labels to the top-level of the current 
design. */

globalLabel( "text" "vdd!"
"gnd!" )

/* The last command lists all marker shapes created during the current or previous Diva run. */

drcLogFile( "DRC.log" )

Writing Rules for use by Diva and Assura

This is a sample rule file that implements macros which allow one rule deck to support both the Diva and Assura products.

procedure( myLayerDefs(@rest list) let( (cmd layer)

    if( ivCompilingFor("diva")

    then

        foreach( layer list

            cmd = sprintf(nil "%s = geomOr(\"%s\")" layer layer)

            evalstring(cmd)

    else

        cmd = "layerDefs(\"dfII\""

        foreach( layer list

            cmd = sprintf(nil "%s %s = layer(\"%s\")" cmd layer layer)

        cmd = sprintf(nil "%s )" cmd)

        evalstring(cmd)

))

procedure( myLatchupCheck(tie tub gate dist err) let( (cmd)

    if(ivCompilingFor("diva")

    then

        cmd = sprintf(nil "tmp = geomSizeInTub(%s %s %d 16 edge)" tie tub

dist)

        evalstring(cmd)

        cmd = sprintf(nil "tmp = geomAndNot(%s %s)" gate tmp)

        evalstring(cmd)

        cmd = sprintf(nil "saveDerived(%s \"%s\")" tmp err)

        evalstring(cmd)

    else

        cmd = sprintf(nil "tmp = geomSepInside(%s %d %s %s anyOutside)" gate

dist tie tub)

        evalstring(cmd)

        cmd = sprintf(nil "keepLayer(%s \"%s\")" tmp err)

        evalstring(cmd)

))

 drcExtractRules(

    ; collect graphic data

    myLayerDefs("well" "diff" "poly" "cont" "met1" "via1" "met2")

    sub = geomEmpty()

    foreach( layer list( "well" "diff" "poly" "cont" "met1" "via1" "met2" )

        sprintf(cmd "sub = geomOr(sub geomExtent(%s))" layer)

        evalstring(cmd)

    ; generate substrate as a bounding box around the data

    sub = geomExtent(sub)

    sub = geomSize(sub 10)

    ; remove well from substrate

    sub = geomAndNot(sub well)

    ; derive gate, diff and tap

    gate = geomAnd(diff poly)

    diff = geomAndNot(diff poly)

    tap = geomAvoiding(diff gate)

    diff = geomAndNot(diff tap)

    ctap = geomOr(tap)

    ; connect it all up

    geomConnect(

        via(cont met1 poly diff tap)

        via(via1 met2 met1)

        via(ctap tap well sub)

        soft(well sub)

    ; do latchup checks

    myLatchupCheck(tap well gate 50 "no tie within 50 of gate")

    myLatchupCheck(tap sub gate 50 "no tie within 50 of gate")

Return to top

Diva ReferenceProduct Version IC23.1, June 2023

4

Writing Diva Verification Rules

Introduction

Creating a Verification Rules File

Grouping Commands

Nesting Commands

Compiling and Optimizing Commands

Using Wildcards

Limitations

Sample Verification Rules File

ERC and LVS Verification Rules

Sample ERC Rules File

Sample LVS Rules Files

Sample CMOS Rules File

Sample Bipolar Rules File

Creating a Run-Specific File

changeLabel

Description

Fields

Property

Example

drcLogFile

Description

Fields

Example

drcZeroHalo

Description

Fields

Examples

globalLabel

Description

Prerequisite

Fields

Examples

groundNet

Description

Fields

Example

joinableNet

Description

Fields

Examples

Property

layerText

Description

Fields

Examples

macroCellFile

Description

Fields

Examples

macroCellFunc

Description

Fields

Examples

includeValueFunc

Description

Fields

Examples

verifyArea

Description

Fields

Examples

Sample Run-Specific File

Writing Rules for use by Diva and Assura

Diva Reference
Product Version IC23.1, June 2023