Layout verification on Assura
Assura Physical Verification Tool Suite
The Assura verification suite is optimized for large, hierarchical, repetitive designs
such as memory, microprocessor, and mixed-signal circuits. The software upholds
the Cadence verification tradition of accuracy established by its Dracula® and
Diva® products. The Assura tools ensure accuracy and leverage the layout
hierarchy of leading-edge designs to provide faster physical verification runtimes.
The advantages of Assura physical verification software include
Efficient hierarchy handling
❑ The Assura tools provide the performance benefits of hierarchical verification
without sacrificing the accuracy associated with flat verification.
❑ Exception-only data processing accelerates the verification process. Assura DRC
and LVS analyze the interior of each cell in detail, then apply the results to other
instances of the cell in the layout design. Prior results are re-evaluated only when
the cell is impacted at higher levels of the hierarchy.
❑ The software checks cell-to-cell configurations such as touching, overlapping,
and nesting. The Assura tool speeds through regular structures such as memory
arrays commonly found in memory, microprocessor, and microcontroller chips.
The Assura software is easy to use
❑ The software includes a graphical user interface to simplify tool setup and usage
and the debugging of verification error or mismatch results. Assura LVS
discrepancy reports are extremely easy to debug, but retain the information report
environment familiar to the Dracula user.
The graphical user interface is designed to make each user’s work as
efficient as possible
❑ The error layer window (ELW) lets users step through DRC errors. The user can
interactively view errors and correct the layout in the same Virtuoso® layout
editing session.
❑ The LVS verification layer window (VLW) lets the user modify the visibility and
selectability of original and derived layers to simplify dense layout editing. The
visibility of each layer is reflected graphically as a reminder of the current status.
❑ Cross-probing between the schematic and layout is available with Assura LVS.
When Assura LVS is used with the Virtuoso layout editor, the user can view the
design graphically and probe nets and devices to locate and correct mismatches.
Note: Users can probe the schematic design if it is a Cadence Design FrameWork
II (DFII) schematic. If the schematic is in SPICE, Verilog or CDL netlist format, the
user can probe the netlist.
❑ The standalone avview tool, bundled with the Assura program , is a view-only
tool that allows the user to run the Assura program and view the physical
verification results.
The Assura software offers a suite of integrated applications that verify IC layout
designs. The suite includes the following tools:
Design rules checker (Assura DRC)
❑ Includes a comprehensive set of commands to check conformance of layout
geometric shapes and relationships to foundry process design rules
❑ Allows complex resizing of layout geometries prior to checking and the
production of the final mask geometries
Layout versus schematic comparison (Assura LVS)
Assura LVS processing includes layout device and net extraction, layout netlist
generation, and schematic versus layout netlist comparison. LVS layout extraction
functions can handle both simple and complex device designs. There are no
restrictions on how devices are constructed. Assura LVS
❑ Can compare the extracted layout netlist with the schematic netlist, then report
discrepancies
❑ Can compare two extracted layout netlists or two schematic netlists, then report
discrepancies
Resistance, capacitance, and inductance extraction (Assura RCX)
❑ Extracts parasitic components from the layout, including parasitic resistance,
capacitance, and inductance
❑ Lets the user produce an extracted view that includes parasitic results, which
can be viewed from Virtuoso and used for simulation and delay analysis.
Assura Task and Data Flow
Assura Inputs
Input data in the form of schematic netlists and layout geometry data are the
primary input source to the Assura tools. In addition, Assura tools have two
required input files, the run-specific file (RSF) that directs a particular Assura run,
and the rule file that contains technology specific design rules.
You can organize rule files and other technology specific information into
technology directories and rule sets to help users run proper verification checks for
a given fabrication process. In addition, you can preset run-time options if
necessary by creating GUI templates for your users.
Overview of the Assura Run-Specific File (RSF)
The Assura RSF is a required control file in text format that directs the Assura DRC,
LVS, or RCX run. It specifies input data files, rule files, run-specific options, and
commands to invoke the tool. The Assura RSF follows Cadence SKILL language
syntax. Options in an RSF are specified as parameters, which begin with a “?”
followed by a keyword. RSF parametersmight take arguments, which can consist of
true (t) or nil values, quoted strings or lists, or unquoted variable names.
When you use the Assura Graphical User Interface (GUI), the GUI creates the RSF
for you using the settings you specified in the forms, and invokes an Assura tool
using this RSF. Alternatively you can create your own RSF. You can specify the RSF
file name in the GUI run form, or you can specify the RSF file name on the command
line if you run an Assura tool in batch mode.
The Assura RSF consists of several sections:
 A mandatory avParameters section that sets run-time options for Assura DRC
and LVS
 One or more avCompareRules sections that specify controls and rules for an
LVS run
 An rcxParameters section that sets run-time options for an RCX run
 Optional statements outside the above sections
 One or more mandatory Assura tool invocation commands
The avParameters Section
The Assura RSF contains amandatory avParameters section that specifies the input
layout and rules file associated with the Assura run, plus various global RSF
options. Below is anexample of an avParameters section.
avParameters(
?workingDirectory "/usr1/drc/"
?runName "peakDetect"
?inputLayout ( "df2" "design" )
?cellName "peakDetect"
?technology "gold"
?techLib "/usr1/amancuso/rcx/assura_tech.lib")
The avCompareRules Section
The RSF contains one or more avCompareRules sections if the RSF is for an Assura
LVS run. The avCompareRules section specifies the input schematic, an optional
binding file for mapping layout device and net names to schematic names, and
other rules and options.
Below is an example of an avCompareRules section.
avCompareRules(
schematic( netlist( dfII "netlist.dfII" ))
bindingFile("bindings")
mergeSplitGate( mergeAll )
showErrorNetwork()
unmatchedNetDetail()
verifyTopSchPins(nil)
compareParameter(MOS percent("w" 5 "l" 5))
compareParameter("res_poly" percent("r" 5))
compareParameter("res_nwell" percent("r" 10))
)
The rcxParameters Section
he RSF contains an rcxParameters section if the RSF is for an RCX run. Below is an
example rcxParameters section.
rcxParameters(
?runName"peakDetect"
?extract"cap"
?minR0.001
?maxFractureLength"infinite"
?fractureLengthUnits"microns"
?capExtractMode"decoupled"
?capGround"vss!"
?capCouplingFactor1.0
?type"full"
?netNameSpace"layout"
?outputFormat"spice"
?output"peakDetect.sp"
?groundNets
("vss!" "gnd!")
?powerNets
("vdd!")
?tempdir
"/tmp"
?parasiticResModels
"comment"
?subNodeChar
"#"
?outputNetNameSpace
"schematic"
?parasiticCapModels
"yes"
?capModels
"no"
?hierarchyDelimiter
"/"
?resModels
"no"
)
RSF Statements Outside Sections
You can place optional statements in the RSF outside an avParameters,
avCompareRules or rcxParameters section. These statements include several
Assura rules that can optionally be placed in an RSF, user-supplied SKILL functions,
and Assura tool invocation commands.
Assura Tool Invocation Commands
The Assura RSF must end with one or more Assura tool invocation commands that
launch the appropriate verification tasks.
When an Assura tool is run from the GUI, the appropriate invocation command is
placed at the end of the RSF.
Rule Files
Assura tools require a set of rules to guide their operation. Rule files are text files.
Rules are grouped together in the rule file within separate sections enclosed in
parentheses. Assura rules follow the syntax of the Cadence SKILL programming
language. Assura rule files can be located anywhere in your file system, and they do
not have default names. The files listed below represent typical names and
organization of Assura rule files:
Tool
Rule File(s)
DRC
drc.rul: contains rules for layout width
and separation checks
LVS
extract.rul: contains rules for defining
and extracting devices and nets from the
layout data
RCX
Assura DRC Rules
compare.rul:
contains
rules
for
comparing the schematic netlist to the
extracted layout netlist
binding.rul: optional binding rules to
help Assura LVS match the schematic to
layout
deviceinfo.rul: a support file that can be
used to import a schematic netlist
process file: contains the layer stackup
specification and design rules for the
specific fabrication technology of the
design.
runName.xcn: the LVS extract.rul file
converted into a format compatible with
capgen
p2lvsfile: a mapping file that associates
one or more LVS layers specified in the
extract.rul to a single layer specified in
the process file.
The first step in a typical physical verification flow is a design rule check, which
verifies that layout geometries conform to the minimum width, spacing and other
fabrication process rules required by an IC foundry. Each foundry specifies its own
process-dependent rules that must be met by the layout design. The CAD developer
specifies the foundry rules in a DRC rules file, typically named drc.rul.
Within an Assura drc.rul file, DRC rules are contained in a drcExtractRules section.
The drcExtractRules section can contain both DRC rules as well as LVS extraction
rules. To create a DRC rules file, only the DRC-specific rules are required. Therefore,
LVS-specific rules are normally not included in the drcExtractRules section of the
DRC rules file.
Layer Definition Rules
The DRC rules are specified in logical order to allow the tool to test the foundry
design rules against the input layout data. The first step is identifying the physical
design layers contained in the input layout data. This is accomplished in the
layerDefs subsection—this is the first subsection in the drcExtractRules section of
drc.rul. This section identifies (assigns a name to) the layers contained in the input
layout database. To allow the DRC rules to be used with different layout databases,
separate layerDefs subsections can be specified (for example, one listing DFII layer
names and another listing GDSII stream layers).
drcExtractRules(
layerDefs( "df2"
nwell = layer( "nwell" type("drawing"))
poly1 = layer( "poly1" type("drawing"))
pwell = layer( "pwell" type("drawing"))
metal1 = layer( "metal1" type("drawing"))
metal2 = layer( "metal2" type("drawing"))
contact = layer( "cont" type("drawing"))
via = layer( "via" type("drawing"))
ndiff = layer( "ndiff" type("drawing"))
pdiff = layer( "pdiff" type("drawing"))
text = text("text" type("drawing"))
) ;end layerDefs
layerDefs( "gds2"
nwell = layer( 12)
poly1 = layer( 35)
pwell = layer( 6)
metal1 = layer( 45)
metal2 = layer( 50)
contact = layer( 55)
via = layer( 8)
ndiff = layer( 1)
pdiff = layer( 2)
text = text(62)
) ;end layerDefs
Layer Derivation Rules
The next step in specifying DRC rules is to derive additional layers from the original
input layers to allow the tool to test the design against specific foundry
requirements. The Assura program provides several logical operation rules that
can be applied to existing layers to derive new layers. For example, MOSFET gate
regions, well taps and substrate ties, as well as the substrate bulk, can be derived
from the original layer information with Assura logical operation rules (layer
derivation rules also are called layer processing rules).
Here are some examples:
ngate = geomAnd( ndiff poly1 ) ngate layer = ndiff AND poly1
pgate = geomAnd( pdiff poly1 )
ndiff = geomAndNot( ndiff poly1 )
pdiff = geomAndNot( pdiff poly1 );pdiff = orig pdiff not including pdiff under poly1
ptap = geomAndNot( pdiff nwell ) ;ptap = derived pdiff less pdiff in nwell
ntap = geomAnd( ndiff nwell )
psub = geomBkgnd( )
DRC Design Check Rules
After identifying original and processing derived layers, the DRC rules list the
various design checks to be applied to the layers. The Assura tool provides a robust
command syntax to allow the specification of design checks for each foundry rule.
check poly1
errpolysep = drc(poly1 sep<1 "poly1 spacing lt 1")
errorLayer(errpolysep)
errpolywid = drc(poly1 width<1 "poly1 width lt 1")
errorLayer(errpolywid)
errpolynotch = drc(poly1 notch<1 "poly1 notch lt 1")
errorLayer(errpolynotch)
errpolycont = drc(poly1 contact enc < .5 "poly1/contact enclosure lt .75")
errorLayer(errpolycont)
errpolydiffsep = drc(poly1 diff sep< 1 "poly1/diff spacing lt 1")
errorLayer(errpolydiffsep)
end poly1 checks
check metal1
errmet1sep = drc(metal1 sep<1 "metal1 spacing lt 1")
errorLayer(errmet1sep)
drc(metal1 width<1 "metal1 width lt 1")
drc(metal1 notch<1 "metal1 notch lt 1")
drc(metal1 contact enc < .5 "metal1/contact enclosure error")
drc(metal1 via enc < .5 "Metal1/via enclosure error")
end metal1 checks
Assura LVS Rules
The Assura LVS tool, like Assura DRC, follows developer-supplied rules. LVS can use
extract rules, compare rules, binding rules and deviceinfo rules. Below is an
overview of the two most essential LVS rule sets: extract rules and compare rules.
These two rule sets are required for all full LVS runs (to extract layout devices and
connectivity, then compare the extracted layout netlist to the schematic netlist).
LVS Extract Rules
The LVS extract rules, typically contained in an extract.rul file, contain the
information necessary for Assura LVS to extract drawn devices and connectivity
information from the layout geometry data input to Assura LVS. This extracted
device and connectivity information is output by the Assura program in a layout
netlist, which Assura LVS compares to the input schematic netlist.
LVS Compare Rules
Assura LVS comparison rules include all the rules associated with comparing a
layout netlistto a schematic netlist. The rules include run control options, input
schematic specification, and rules governing device parameter comparison.
An example of an avCompareRules section within an RSF file is as follows:
avParameters (
?inputLayout ()
?cellName ()
<other_avParameters>
; end of avParameters
avCompareRules (
general_rules
schematic (
;netlist specification--required
netlist ()
other network_specific_rules
)
layout (
network_specific_rules
)
bindingFile ("/usr1/gold_tech/bind.rul")
); end of avCompareRules
Running Assura
You can run Assura as an interactive graphical tool or as a batch tool from the Unix
command line. Assura requires a text input file called the run-specific file (RSF) for
each run. When you use the Assura graphical user interface (GUI), the GUI creates
the RSF and starts the Assura run. When you start Assura as a batch tool you must
specify an RSF.
Run Mode
Assura Start Command
Interactive mode from Virtuoso Layout Assura > Run DRC
Editing window
Assura > Run LVS
Standalone graphical mode from Unix avview
command line
Non-graphical batch mode
assura rsf_filename
from Unix command line
Running Assura Tools From the DFII GUI
1. Launch the Cadence DFII executable (icfb)
2. Select File->Open... from the DFII Command Interpreter Window (CIW)
as shown below.
3.
Select the library, and top cell name of the design, then select layout
view, then click OK to open the layout view in the Virtuoso Layout
Editor (see below).
4.
After you have selected the design, the layout view opens in the
Virtuoso layout editor.
DRC Graphical User Interface Run Guide
Run Name is the Name you want to use to refer to this Assura DRC run. If you do
not specify a run name, the Assura program uses the cell name of the design. All
output files contain this name as a prefix.
Run Directory is the full or relative path to the run directory. If the directory you
specify does not exist, Assura DRC creates the directory.
Run Location is where you can select either a local or remote machine for a DRC
run.
Switch Names Identifies the section of statements in the rules file that you want to
use for a specific Assura DRC or circuit extraction to control the command stream.
To identify the switches that you want to use for an Assura DRC run, type the switch
names in the Switch Names field. You must type at least one space between multiple
switch names. For example:drc1 substratecheck.
Set Switches Click on Set Switches to open the Set Switches form to view the
available switches in the specified rules file. Select a switch by clicking on the name
of the switch; select more than one switch by holding down the Control key and
clicking on each switch name and then click OK.
RSF Include
The RSF Include field allows you to specify an additional RSF file to be included into
the top-level RSF being created by the DRC User Interface. When the specified
Technoloy defines an include file using the DrcInclude keyword, this file is
automatically loaded into the RSF Include field, and the field is grayed out so that it
cannot be modified.
If a Technology has not been selected (and is -undefined-) the RSF Include file will
not be grayed out, and you can manually specify a file to include in the RSF. The
contents of the file specified will be included at the beginning of the RSF file created
by the DRC Run form.
Click OK to close the dialog box.
LVS Graphical User Interface Run Guide
Click ok
Show this window
Click OK
Then show the below window
RCX Graphical User Interface Run Guide