D
Simulation and Environment Control
The ERC and LVS programs both run under the control of the system simulation environment (se). When you start a job, the se takes control and performs a number of operations. These include running the system netlister if required, running the LVS or ERC program, and translating the output for probing and cross probing.
The netlister produces a text format netlist that provides the input to LVS and ERC. To run the netlister correctly, you must set up the netlist control environment. To understand this environment, read the Simulation Environment Help.
The LVS and ERC system defaults are set up to run the programs without needing to know about the operations of se.
It should be noted that LVS uses different netlisting modules depending on the mode the workbench is running in. In digital mode the Diva module is used. In analog mode the Artist module is used. This leads to differences in behavior and file content in the LVS run directory. Any issues encountered during LVS in analog mode should be addressed to Artist product support, not Diva product support. This chapter only discusses the digitial mode. Please refer to the Analog Artist product documentation for a discussion of analog mode LVS.
Directories and Files
To enable the se to work automatically, you must provide a directory structure. For LVS, you do this by naming the directory in the LVS form or in the ivLVS command. For ERC, you do this by naming the directory in the ERC form or in the ivERC command. These programs then set up the directory and the necessary files and subdirectories.
The run directory for LVS contains two subdirectories, one for the extracted layout circuit data and one for the schematic circuit data. All files specific to a circuit are stored in its subdirectory. All other files are stored in the main run directory.
The LVS run directory contains the following files:
Contains the se variables with their states as set up by the system or the Setup Environment form.
Contains the simulation environment run log.
Contains the simulation environment output.
Subdirectory for extracted layout data.
Subdirectory for schematic data.
The layout and schematic subdirectories contains the following files:
Directory for both extracted and schematic cellviews containing the net and device mapping between the original hierarchical circuit and the flat netlist. The mapping files are in binary format.
Text file for both extracted and schematic cellviews containing the netlist.
LVS unmatched nets for both extracted and schematic cellviews.
LVS unmatched devices for both extracted and schematic cellviews.
LVS nets and devices pruned from both extracted and schematic cellviews.
LVS nets and devices failing the parameter matching for both extracted and schematic cellviews.
Overflow file used with devxfref.out for cross probing parallel device groups.
LVS unmatched terminals and matched terminals that have different I/O directions in the extracted and schematic cellviews.
The ERC run directory contains the following files:
se variables with their states as set up by the system or the ERC form.
Simulation environment run log.
Simulation environment output.
Directory for both extracted and schematic cellviews containing the net and device mapping between the original hierarchical circuit and the flat netlist. The mapping files are in binary format.
Text file for both extracted and schematic cellviews containing the netlist.
ERC nets and devices selected through the run commands either as errors or as requested information.
Variables
The se uses many variables to control LVS and ERC. You can set these variables from the menu forms or automatically through the system.
Although you do not normally change these variables, they are listed for reference. They are shown with their true default values or with dummy values where there is no specific default.
The following variables are contained in the si.env file:
lvsLayoutLibName = "lib"
lvsLayoutCellName = "fflatch"
lvsLayoutViewName = "extracted"
lvsSchematicLibName = "lib"
lvsSchematicCellName = "fflatch"
lvsSchematicViewName = "schematic"
lvsNetlistSchematic = ’t
lvsNetlistLayout = ’t
applyDeviceFixing = ’nil
correspondenceFile = ’nil
useFileCorrespondence = ’nil
useTerminalCorrespondence = ’t
createXref = ’nil
simSimulator = "LVS"
simLibName = "lib"
simCellName = "fflatch"
simViewName = "schematic"
tmp/ff"
The following variables can be added to the .simrc file to override the defaults:
lvsRulesLibName = lvsSchematicLibName
simNlpGlobalLibName = "basic"
simNlpGlobalCellName = "nlpglobals"
disableLikeMatching = ’nil
disableReWire = ’nil
Control Input
The se uses several files. Although you never need to access most of these files, they are listed for reference. If you do need to make changes, see your system administrator.
Setting Up the Netlister
Both LVS and ERC perform their main processing from netlists of the circuit. These netlists are produced by the system netlister program under the control of the se.
For netlisting of low-level devices such as transistors and capacitors, a special cellview of these devices called lvs is available in the system device library. This has the properties preset for the netlisting for both LVS and ERC.
Cellview Switching
Both the schematic and extracted cellviews of the circuit being compared use the same organization of cells and views. The schematic cellview organization is usually a multilevel hierarchy, where each level of cells refers to lower level cells, down to the lowest device level. The extracted cellview, even though it can be described as “flat,” has the same hierarchy, because the network cell refers to device cells placed within it.
Depending upon whether you are working on a schematic or a layout, you might want to reference different views of cells in the hierarchy. For graphic display, you can reference a symbol containing drawing information. For simulation, you need to reference a view containing the required simulation information. The system facilitates such references by having different views available for each cell. First, you must be able to tell the system how to find the correct cell within the computer directory system, and then you must tell the system how to determine which view to use.
In addition to knowing which view to use at each level of hierarchy, the netlister needs to know at which level of hierarchy to stop processing. A netlist for logic simulation needs to process the hierarchy down to the logic gates. A netlist for a circuit simulator, such as Cadence SPICE, needs to process the hierarchy down to the lowest device level, such as transistors.
Both the schematic and layout netlisting must stop at the same device definition. If you stop at an nfet in the schematic, you must stop at an nfet in the layout. Also, these two devices must use the same model with the same terminals in the same order.
Similarly, the netlist for the LVS and ERC programs must be processed to the level being analyzed, which might be the lowest device level, the macro cell level, or a combination of both. The view for the device does not need to contain graphic or symbolic information, but must contain formatting information to tell the netlister which form and information to generate. You can find further details in the “Netlist Formatting” section in this chapter.
To determine where to find specific cells, the program uses the system library path. To determine which views to use, the program uses “switching lists” and “stopping lists.” These variables are initialized to default values.
The switching and stopping lists are used as follows:
- When the master cell is found, the program searches the switching list and tries to match a view name in the list with the views available for that cell. The list is searched left to right, and the first matching view is used.
- The program then searches for this view in the stopping list. If the view is found, the expansion process stops for that cell. If it is not found, the program switches into the view, determines the instances within the view, and repeats the process.
The switching and stopping list variables and their default values are as follows:
lvsSchematicViewList = ’( "lvs" "schematic" gate.sch"
"cmos.sch" )
lvsLayoutViewList = ’( "lvs" "extracted" "schematic"
“gate.sch" "cmos.sch" )
lvsSchematicStopList = ’( "lvs" )
lvsLayoutStopList = ’( "lvs" )
ercViewList = ’( "lvs" "schematic" gate.sch" )
ercStopList = ’( "lvs" )
To override these default values, you can provide a file in your home directory called .simrc. This file can already exist for specifying other information, such as the switching and stopping lists for SPICE netlisting. If the file does not exist, you can create it.
If having a single simulator control file in your home directory leads to conflicts, the same data can be put into a file called .simrc in the directory from which you started Design Framework II.
Netlist Formatting
The output of the netlister is controlled by format strings stored in cellviews as nlpExpr properties. The netlisting process is triggered by specific property names in the cellviews defined by the netlisting stopping list. In the case of LVS and ERC, these cellviews are the lvs cellviews.
The properties consist of netlisting instructions. Each instruction can print something in the netlist, go to another instruction property, or both. Each cell that is encountered in the circuit prints out the correct information in the netlist by using a sequence of instruction properties.
One source of the netlisting instruction properties is the cellview itself. Another source of netlisting instruction properties is a cell called nlpglobals in the system device library. Any netlisting instructions that are common to more than one device are stored in the nlpglobals cell.
The device library supplied by Cadence contains device simulation and global cells for all currently supported simulators. The LVS and ERC programs have their own nlpglobals cell called lvs and their own cellviews, also called lvs, for each of the lowest level devices such as transistors, capacitors, and so forth. If an lvs cellview does not exist for a specific device you need for LVS or ERC, you can either create your own lvs cellview or create an equivalent cellview with any other name. Use that name in the switching and stopping lists.
For LVS and ERC, the predefined lvs cellviews generate one line in the netlist for each device type and two lines for each instance of the device: one for comments and one for device usage. Additional lines are automatically generated for terminals and net names. The next sections detail the process of generating the device type and device instance lines.
Device Type Definition
Each different device type in the netlist must have a single-line definition of its structure. The nlpglobals cell contains a property called NLPcreateModelString. This property starts the sequence of operations that generates the device type definition. In LVS and ERC, this property references a property in the master cell of the device called NLPModelPreamble. The master cell of the device is defined by the stopping list as previously described, for example, nfet lvs.
The NLPModelPreamble property, which determines the specific netlist format for a device, appears in all netlisted devices. Instead of putting the format inside the device cell, the NLPModelPreamble property references a model property (usually found in the nlpglobals cell). This allows multiple devices to have the same netlist format without duplicating information. The model property in nlpglobals has a name, such as NLPMosfetModelCard. This property provides the string to be written to the netlist. It contains a mixture of characters, written directly to the netlist, and substitutions, in which keywords are replaced by other information. There is a different model property for each device type having different netlisting information.
The substitutions used are as follows:
- BlockName. The system automatically places the cell name of the device in the netlist at this point.
- permuteRule. As shown in the example, if the property of permuteRule exists in the device cell, or in the nlpglobals cell, permuteRule is placed in the netlist at this point. If permuteRule does not exist, the default permute rule, following it in the property, is placed in the netlist.
The following is an example of device type formatting:
NLPcreateModelString = "[@NLPModelPreamble:%n]"
NLPModelPreamble = "[@NLPMosfetModelCard]"
NLPMosfetModelCard = "d [@BlockName] D G S B
[@permuteRule:%:(p S D)]"
permuteRule = "(p S D)"
d nfet D G S B (p S D)
In this example, the permuteRule property on the device is the same as the default rule in the nlpglobals model property.
Device Instance Definition
Each different device instance appearing in the netlist must have at least one single line specifying its connections. It can also have an additional comment line.
The nlpglobals cell contains a property called NLPcompleteElementString. This property begins the sequence of operations that generates the device instance line in the netlist. In the case of LVS and ERC, it references a property called NLPElementPostamble in the device master cell. The master cell is defined by the stopping list as described previously (for example, nfet lvs).
The NLPElementPostamble property appears in all netlisted devices and determines the specific netlist format for that device instance. Instead of putting the format inside the device cell, the NLPElementPostamble references an element property (usually found in the nlpglobals cell). This allows multiple devices to have the same netlist format without duplicating information). The element property in the nlpglobals has a name, such as NLPMosfetElementCard. This property provides the string to be written to the netlist. It contains a mixture of characters, written directly to the netlist, and substitutions, in which keywords are replaced by other information. (There is a different element property for each device type having different netlisting information.)
The substitutions used are as follows:
- ElementNumber increments the index. Each device instance written to the netlist has a unique number.
- BlockName places the cell name of the device in the netlist at this point.
- Device terminals provide the net numbers connecting to the netlist.
- LVSmosfetProp. If this property exists in the device cell, it is placed in the netlist at this point. If it is not in the device cell or anywhere higher in the hierarchy, this property is taken from the nlpglobals. The LVSmosfetProp, in turn, contains its own substitutions which are a combination of property names and contents. In this case, the parameters of width (w) and length (l) as contained in the device instance are added to the netlist.
The following is an example of device instance formatting:
NLPcompleteElementString = “[@NLPElementPostamble:%\\n]”
NLPElementPostamble = “[@NLPMosfetElementCard]”
NLPMosfetElementCard = “i [@ElementNumber] [@BlockName]
[|D:%] [|G:%] [|S:%] [|B:%] [@LVSmosfetProp]”
LVSmosfetProp = “ \“ [@l:l %] [@w:w %] \””
w = 3
l = 6
i 26 nfet 26 57 17 87 “ l 6 w 3”
Parasitic Devices
Normally, the schematic representation of a circuit does not contain parasitic devices. Any device referenced is nonparasitic (referred to as a “schematic” device). The extracted representation, on the other hand, can contain parasitic devices. These have usually been created from measured properties using a saveParasitic command and do not appear on the schematic.
If you try to make an LVS run match the extracted parasitics to the schematic, it fails. For LVS to be successful, either the extracted layout must not contain parasitic devices, or these devices must be ignored.
To overcome this problem, you can include special devices as parasitics in the extracted layout. These devices behave exactly the same as normal devices for SPICE simulation, but are ignored by the netlister for LVS (or ERC if so desired). This lets the program process only the schematic devices.
The saveParasitic statement (or extractDevice statement) used during circuit extraction must reference one of these special devices instead of a normal device, whenever that device does not appear in the schematic. The following special devices are available for this purpose.
Equivalent to the normal device capacitor.
Equivalent to the normal device diode.
Each special device has a symbol cellview, which becomes the default referenced in the extracted layout so that it can be viewed. Each special device also has an lvs cellview for the LVS netlister, and a SPICE cellview to permit full simulation. If any other cellview is required, you must copy it, without change, from the normal cellview of that device and add it to the cell.
Netlist Format
The netlister program produces a text format netlist. You can view this netlist to check the netlister control has performed as desired. To understand the format of the netlist, this format guide is provided.
This netlist format is generated by the system device library model entries using the lvs cellview.
The netlist is always flat, that is, all hierarchy is removed. Each line of the netlist defines an item. The items are as follows:
- Net name to number translation
- Device type definition
- Device instance definition
- Terminal definition
- Device fixing
Net Name to Number Translation
Defines the correspondence between the net numbers in the netlist and the net names in the original layout or schematic. This is optional in LVS.
net < net_number> [ = ] <net_name>
This word introduces the net definition line. The word net can be abbreviated to the character n.
The number of the net in the netlist.
An optional character to indicate equivalence between net number and net name.
The name of the net in the layout or schematic.
Device Type Definition
You must define each different device type used in the netlist. Use the following format
d <dev_type> <term_list> <perm> <property>
Introduces the device definition line.
Name of the device type model in the system device library.
List of terminal names that defines the order for net connections to the device.
This order is arbitrary, unless you are reducing MOS transistors into gate configurations, in which case the order must be source-gate-drain.
If the terminal names contain parentheses, for example “pin(1)”, the parentheses must be escaped by proceeding each with a backslash (“pin\(a\)”). The parentheses is reserved in the device type definition to delineate the device terminal permutability.
Defines device terminal permutability.
The definition has as two operators: f (fixed) and p (permutable). A typical property for permuting a transistor source and drain is
An example of a combination fixed and permuted terminal definition is
This means that terminals 1 and 2 are permutable, and terminals 3 and 4 are permutable, but the terminal pair of 1 and 2 is not permutable with the terminal pair of 3 and 4.
This property is a text string containing a series of name pairs that define the default properties of the device type. Each pair consists of the property name and the property contents. The following example contains two pairs, w 10 and l 15.
If the property value contains any special characters (including periods), the property must be included in quotes and each quote must be preceded by a backslash. For example
Device Instance Definition
Each different instance of a device in the netlist must be defined with this line.
i <inst_num> <device_type> <terminal_netlist> <property>
Introduces the device instance line.
A unique identification number for this device instance.
Name of the device type of which this is an instance.
List of net numbers in terminal order that defines the connections to the device.
Text string containing a series of name pairs that define the properties of the device instance. Each pair consists of the property name and the property contents. The following example contains two pairs, w 10 and l 15.
Terminal Definition
Defines the terminals of the circuit. LVS uses terminal definitions to define terminal-based correspondence points and to define net connections that enable the LVS prune command to correctly handle inputs and outputs.
t < net_number > < net_name >
Introduces the terminal definition line.
Number of the terminal net in the netlist.
Name of the terminal net in the layout or schematic.
Terminal names that contain special characters such as “(” used for referencing busses, should be enclosed in double quotes. For example, “pin(1)”. The netlisting should be set up to always enclose terminal names in quotes, in case any name contains these special characters.
Fixing Devices
LVS uses two lines to define the devices are to be fixed or unfixed using the fixing feature. This only applies to the schematic netlist.
f < net_number [order] net_number [order] ... ... > u < net_number [order] net_number [order] ... ... >
List of net numbers used to determine which devices are fixed or unfixed.
Fixing applies to any device occurring in the netlist between the fix and unfix commands that reference a net to which that device is connected.
The fix and unfix commands are considered pairs. Each time you give a fix command you must also give a matching unfix command.
In the following example, the net 23 is defined twice. Devices connected to net 23 are not considered unfixed until both unfix commands containing net 23 are encountered.
f 23 45 56 |
Example of Netlist
The following example illustrates the structure of a netlist. It is not meant to represent a real circuit.
d dep s g d (p s d) ; Depletion load device
d enh s g d (p s d) ; Enhancement device
t 1 gnd
t 2 vdd
t 3 a
t 4 b
t 9 clk
i 1 dep 7 7 2 "l 3 w 2"
i 2 dep 5 5 2 "l 3 w 2"
i 3 dep 6 6 2 "l 3 w 2"
i 4 dep 8 8 2 "l 3 w 2"
i 6 enh 1 4 7
i 7 enh 1 3 7
i 8 enh 1 3 5
i 9 enh 1 4 6
i 10 enh 1 5 8
i 11 enh 1 6 8
i 12 enh 1 7 9
i 13 enh 1 8 9
Return to top