8
Models of Device Extraction
A device is an electrical device such as a transistor or capacitor that is intentionally designed into the circuit by the arrangement of mask layers. This is sometimes referred to as a “designed device,” as compared to a parasitic device, which is a side effect of the mask layer arrangement. Designed devices usually appear in the schematic of the circuit.
There are four modes for extracting devices:
Flat Mode
The normal mode for extraction is flat. In flat mode, Diva flattens the hierarchy of the layout. This ensures that all structures and interactions forming devices, parameters, and parasitics are recognized. The result of a flat extraction is a single extracted view representing the complete original circuit.
Macro Cell Mode
Normally, for the extraction of hierarchical structured layouts, Diva expands the contents of each instance of a cell in the hierarchy into a single flat representation. The flattening process continues until all cell instances are gone, leaving only shapes on layers.
Macro cell mode is similar to flat mode, except that Diva treats certain cells as if they are devices. Each macro cell is considered a “black box.” Diva does not flatten a macro cell’s contents into the rest of the layout. The result of a macro cell extraction is a single extracted view in which the macro cells appear only as device instances. When you look at the extracted cellview, instances of macro cells appear the same as normal cell instances. See Chapter 2, “Macro Cell Mode,” for more information on macro cell mode.
Full Hierarchical Mode
In full hierarchical mode, Diva extracts each cell at the lowest level of hierarchy exactly as in flat mode. Diva then extracts each cell at higher levels of hierarchy and treats the instances of lower level cells as device instances. The contents of higher level cells (other than other cell instances) are extracted as in flat mode. Macro cells can be included in hierarchical extraction.
The result of a full hierarchical extraction is a single extracted view for each cell, in which the other cell instances appear only as device instances.You can use the results of hierarchical extraction the same way as flat extraction.
When you process a hierarchical version with the netlister, the program adds extracted to the representationPath so it can switch between views to trace connectivity through the hierarchy. In addition, Diva creates an excell view for each extracted cell. This view provides an interface to the cells that contain it.
Advantages
There are several advantages to running extract in full hierarchical mode.
- Analysis time is reduced for repetitive circuitry because the program analyzes each cell only once, regardless of how many times it appears in the circuit.
- Disk space is reduced because the program maintains only one copy of each extracted cell.
- Virtual memory and graphic display time are reduced because the program partitions the extraction process into smaller sections.
- Errors for a cell are located within the master for that cell rather than on a flattened representation of the circuit.
One of the major advantages of hierarchical extraction is that it reduces the run time. However, reduced run time occurs only if there is cell repetition. Running in hierarchical mode without cell repetition might actually increase run time.
Controlling Hierarchy Selection
You can use the ivCellType property to control the way the program interprets a cell. The ivCellType property can have these values:
Tells the program the cell is not a level of hierarchy, even if the cell has pins.
Declares the cell a macro cell. The cell must have pins to be considered a macro cell. If it does not have pins, it becomes a graphic even if you set this value.
If a hierarchical cell has a ivCellType property of macro
Hierarchical Extraction Tools
Some of the commands available in the Diva environment that are helpful during hierarchical extraction include
-
saveDerived
This command saves layers you can use with the excell version with the cell_view keyword. It copies derived layers into the excell version so you can do checks against the data in the cell containing the excell. See Chapter 5, “saveDerived” for more information. -
geomNoHoles
This command constructs “keep-out” layers that you can save in the excell version using the saveDerived command. See Chapter 5, “geomNoHoles” for more information. -
geomGetPurpose
This command accesses the cell boundary for copying to excell. See Chapter 5, “geomGetPurpose” for more information. -
geomAnd
This command performs a single layer self-and that you can use to check the overlap of one excell boundary onto another. See Chapter 5, “geomAnd” for more information. -
geomGetMacro
This command selects shapes on layers from macro cells. See Chapter 5, “geomGetMacro” for more information.
Limitations of Hierarchical Mode
Hierarchical mode limitations include the following:
- The program does not recognize connections between cells that aren’t connected with pins. To prevent the program from missing design errors, you should create keep-out layers. You can use the keep-out layers to perform dimensional or logical checks between the connection layers and the parent cell data.
- The program performs hierarchical extraction one cell at a time. The excell versions of a cell contain only a skeleton of the data and have no internal connectivity information. Therefore, it is impossible to generate cell-to-cell parasitic measurements during hierarchical extraction. Parasitics and parameters totally contained inside a cell are still valid.
- The program might count parasitic measurements at pins multiple times, once for the original cell, and once for each instance of the excell of that cell. It does this because the area of the pins exists for both. You can avoid this by using the geomGetPurpose command, which allows shapes to be accessed from different levels of the hierarchy. Therefore, you can separate the pins at the current level from pins derived from lower levels of hierarchy.
- The program doesn’t recognize any device formed between cells. You can avoid this by creating “keep-out” layers.
- The hierarchical extraction is only valid with a true hierarchical design methodology. The integrity of the hierarchy and its extraction are violated if cells are modified in any way by the overlay of shapes from other cells, whether they are at the same level or at different levels of hierarchy.
- When processing hierarchical extraction results for LVS, you need separate switching lists for the extracted and schematic circuits. Refer to Chapter 13, “Comparing Layout to Schematic (LVS)” for more information.
How the Program Processes Hierarchically
In hierarchical mode, the programs starts by looking at the master (top level) of the cell containing the entire circuit. Traversing the hierarchy, the program looks for “leaf” cells. Leaf cells contain no instances of other cells.
For each leaf cell, the program performs regular (flat) extraction, creating an extracted version of the cell and an excell view of the cell. The excell view is a simplified version of the original cell containing copies of pins and any other shapes you tell the program to copy from the original cell. You can copy shapes to perform integrity checks on parent cells, or for display purposes.
After the program extracts the leaf cells, it proceeds to the next level up in the hierarchy. At this level, the program replaces instances of cells in the current cell with instances of the excell version of those cells. The program then continues to recognize regular device and connectivity, with the excell pins contributing to the connectivity of the current cell as if they are normal pins to external connections. The result is an extracted version and an excell version of the current cell.
The program continues up the hierarchy until it processes all cells including the top level cell. The program creates an excell view, even at the top level, for extraction at a higher level.
Using Hierarchical Extraction
To start hierarchical extraction for interactive processing from a layout window, select the Extract command from the Verify menu, then select hier for the extract method in the Extract form.
To start hierarchical extraction using SKILL, use the ivExtract command to specify a t value for the ?hier argument.
Incremental Hierarchical Mode
When you make a layout change to a small number of cells, you can run in incremental hierarchical mode to minimize the amount of processing. In this mode, the program re-extracts only those cells that have layout changes within them, as well as cells that contain other cells whose pin connections have changed. Before you can run in incremental hierarchical mode, you must have performed a full extraction on the cell, and an excell view must exist for each original cell.
You can use these properties to determine if the layout or extraction rules have changed since the last time the cell was extracted.
- The instancesLastChanged property on each layout cell indicates when the cell was last modified.
- The extractTime property on the excell view indicates when the cell was last hierarchically extracted.
- The extractSignature property on the extracted view indicates which set of rules was used for the extraction.
Device Recognition
Device recognition is the process by which the program recognizes devices and creates an instance for each device in the extracted version of the circuit.
Using Device Recognition
A single device is recognized by the existence of a single shape on a specific layer. You must use layer processing commands to create a single shape for each device. For example, if you use polysilicon and diffusion shapes in the graphics editor to form a MOS transistor and you use the geomAnd command on these layers in Diva verification, you create a shape that represents the MOS transistor. This shape is the device recognition shape.
Once the device recognition shapes are isolated, you direct the program to create the devices in the extracted version by using either the extractDevice command or the extractMOS command. You use these commands to look at each device recognition shape and determine the electrical connections to the device terminals. To do this, you must have defined the circuit connectivity using the geomConnect command.
After the program recognizes and validates the device terminals, it matches the terminal with devices being extracted and places an instance of the device in the extracted version of the circuit. The instance must reference a device model in the system library, and the devices must exist in a library. The program uses the device model to verify the terminal configuration of your extraction command. You define a device model using either the extractMOS or extractDevice command.
The process of recognizing devices in the circuit automatically creates a cellview containing the extracted representation of the circuit. This cellview is given the default name extracted view.
The process of hierarchical extraction also creates a view for each cell in the hierarchy. These views are given the default name excell view.
You can override the default cellview names of extracted and excell by defining your own names. However, you must ensure that the view names you specify do not conflict with any other existing view names for cells that you wish to keep. Diva only checks that the extracted and excell view names are different.
Device Recognition Polygons
When the program generates devices and interconnects from a layout, it generates an extracted view of the circuit. This version initially contains only devices and nets. The device instances are the symbols that represent the devices. You can make the nets visible by displaying the pin-to-pin direct connections (“fly-lines”). Neither of these displays is associated with the layout mask layers, other than the dimensional location of the device instances.
To see the layout shapes associated with the nets, you use the saveInterconnect command. This command lets you save the derived layers used to define the circuit interconnect. When the program saves interconnect shapes in the extracted view, the shapes are associated with the electrical net they helped create. If you probe one of these shapes, the graphics system can locate the net to which the shape belongs and highlight all the shapes associated with that net.
To make device recognition shapes visible, you use the saveRecognition command. This command lets you save the shapes that are used to recognize the devices in the extractDevice or extractMOS commands. Each recognition shape is associated with the device it created, so you can probe a device shape and have the shape and its device symbol highlighted. More importantly, it allows a cross-probe from the LVS program, so you can highlight the device shape directly.
Saving Device Recognition Polygons
The saveRecognition command works by storing a property on each device instance. This property is the device recognition shape. To save device recognition polygons, you must
- Create a parameterized cell for each device type. You do this in the graphics editor before running any extraction that uses the cell. Default ivpcells are in the samples library. Refer to the Chapter 8, “About Parameterized Cells” for more information.
- Define the device type using the extractDevice or extractMOS commands. The device model (nfet, pfet, and so forth) remains the same, however, you must define the version as ivpcell. Normally, the version default is symbol. ivpcell is detailed in the SKILL procedure description.
- Save the device recognition layer with the option to redefine the graphics layer on which the shapes are displayed. You must do this for each device recognition layer to be saved, using the saveRecognition command. The saveRecognition command looks at each device recognition shape on the specified layer, determines which device instance it represents, and attaches a property to that instance using the shape coordinates as its contents.
Device Instance Property
When you use the saveRecognition command, the program creates a property on the device instance. The property has two parts.
The property format is a string that looks like a SKILL list. The first part of the property format is the layer number on which you display the polygons. The second part of the property format lists one or more polygons that form the device shape. Most devices require only a single polygon, however, you might need to specify more than one polygon. For example, you might have to break very large device recognition shapes into multiple polygons in order to conform to the vertex limit of the graphics system.
The format for specifying the shape coordinates is
( ( x1 y1 ) ( x2 y2 ) ( x3 y3 ) ... )
You specify each coordinate in user units.
For example, the recognitionShape displays a 1 by 3 rectangle on layer 10.
( 10 ( ( 0 0 ) ( 1 3 ) ) )
About Parameterized Cells
A parameterized cell is a special type of cell that has an associated procedure in SKILL. The procedure reads the properties on the cell instance (a device in the extracted cellview) and builds a “variant” of the cell. Instances of the variant are then placed instead of instances of the original cell. For a complete description of parameterized cells, refer to Virtuoso Layout Editor Help.
The system library comes with a number of ready-made parameterized cells with view names of ivpcell. You can use these cells for saving device recognition shapes. Each cell has a resolution of 1000 database units per micron. You can use the ivCreatePCells SKILL procedure to create your own parameterized cells, or to change cells in the system library.
The ivCreatePCells procedure copies the pins and graphics from the symbol view of your device to the ivpcell view and magnifies them by a value you specify, so they are visible when the cell is placed in the extracted view. ivCreatePcells also generates the correct SKILL procedure for storing the recognition shape when you use the saveRecognition command.
When you use extractMOS or extractDevice without the saveRecognition command, the extracted view displays the graphics and pins in the ivpcell for each device instance. When you use the saveRecognition command, you can also see the recognition shape.
The SKILL Procedure
You can use the ivCreatePCells SKILL procedure to create your own parameterized cells. When Extract places a device instance using the saveRecognition command, each logical terminal in the master cell is copied to the variant. The terminals facilitate the circuit connectivity of the device.
- Copies each physical pin from the master to the variant.
- Copies all shapes from the master to the variant.
- Evaluates all recognized properties associated with the instance. In Diva verification, the procedure uses the recognitionShape property to create the defined shape on the required layer. It also creates the shape on the instance layer so that the device can be selected. The instance layer shape also allows the device to be seen in unexpanded graphics mode.
Processing Pins
Normally, pins form part of the interconnect of a circuit. If you want to use this connectivity, you must specify the pin’s layer, or one derived from it, in a geomConnect command.
If you store a pin layer in the extracted view of the circuit using the saveInterconnect command, the system treats the pins as any other shape on that layer and stores them with the net purpose.
During layout extraction, pins are copied to the output cellview (extracted, excell, abstract). Pin instances are copied as pin instances and are not flattened.
Pins have two fundamental uses.
- Pins at the topmost level in the hierarchy are used to label nets and are copied to the output cellview.
- Pins are used during macro-cell and hierarchical extraction. The existence of the pins indicate that a cell is a macro cell or a hierarchical cell and tells the program where connections between the parent and child cells are made.
During hierarchical extraction the pin names might be changed by the program to correctly reflect the true connectivity in a cell. If there are two pins with the same name that are not on the same physical net (intended to imply a connection external to the cell), the program renames the second pin and creates a new net for it. The program also adds a property called connectToTerminal to the changed pin. The property contains a reference to the pin that retains the original pin name.
The Diva verification extraction process and the full abgen analysis place a property called netNumber on each pin in the output cellview. The netNumber and connectToTerminal properties are used by the hierarchical and macro cell extraction programs as follows:
- If two pins are on the same net and neither has a netNumber property, the pins are assumed to be connected inside the cell.
- If two pins are on the same net and both have the same netNumber property, the pins are assumed to be connected inside the cell.
- If two pins are on the same net and they have different netNumber properties or only one of the pins has a netNumber property, the pins are assumed to be unconnected in the cell. However the fact that the pins are on the same net indicates they should be connected. This is commonly known as a “must-connect” and an error is generated if the connections in the parent cell to these pins are on different nets.
- If two pins are on different nets but one pin has the property connectToTerminal referencing the other pin, then the pins must be connected in the parent cell otherwise an error message is generated. This is another example of the “must-connect.”
If, for macro-cell extraction, the macro cell is not generated automatically by Diva’s extraction or by full abgen, the netNumber property does not exist and you must add this property manually if you want to control the connectivity.
Pin Instances
If a cell contains nothing other than a pin, you need to assign that cell a property of ivCellType with a value of graphic. This ensures that during macro cell extraction the cell is not treated as a macro cell and that during hierarchical extraction it is not treated as another level of hierarchy. With the ivCellType of graphic, the pin instance is expanded into a pin in the parent cell.
Device Extraction Commands
The following section discusses the device extraction commands.
The Assura device extraction commands extractBJT, extractCAP, extractDIODE, extractMOS, and extractRES are recognized and parsed as if they were extractDevice commands. The Assura extractMOS command is recognized as different from the Diva extractMOS command by the first parameter being a string with the model name in it.
extractDevice
extractDevice( [model] recLayer termLayer ... [model] [physical] [flagMalformed] [namePrefix(string)] [property(name value) ...] [cellView(model)] [termOrder(string)] [spiceModel(string)] [targetLayer(string)] )
Description
The extractDevice command extracts devices of any type from the layout and stores them in an extracted view of the circuit.
If the Assura syntax is used, with the model string before the recLayer, Diva sets the flag that suppresses error messages about malformed devices. This can be over-ridden by the flagMalformed keyword.
Prerequisite
The terminal layers (termLayer) must be connected layers. The device recognition layer (recLayer) must be a derived layer.
Fields
The device recognition layer name. This must be a merged derived layer name. Each shape on this layer causes the extraction of a separate device. Any shape on this layer from which the tool cannot extract a device is now used as the error marker shape instead of the small square generated in previous versions of Diva.
The device terminal definition. There must be a separate terminal definition for each different terminal type on the device. Each terminal definition consists of a derived layer name and any number of terminal name references enclosed in parentheses.
The terminal layers must be connected layers.
The device model name with a character string enclosed in quotes or the keyword nil. In the Assura form, the keyword nil is not allowed.
If you provide a model name, any device that matches the configuration specified with this command will have an instance of that device model created in the extracted cellview.
If you provide the keyword nil, any device that matches the configuration specified with this command is accepted as valid. However, no instance is created in the extracted cellview and no errors are generated.
All device commands having the same device recognition layer are considered together when the program determines if a device matches the specified configuration. If a device matches any of the configurations specified with this command, the action defined by the command is carried out (either a device is created or is ignored). If a device does not match any of the defined configurations, the tool generates an error.
The character string you use must define the cell name and can optionally define the view name and a library name. If you don’t specify the view name, the program defaults to the name symbol.
Your defined model must be available in a library accessible by the program so that the terminal configurations can be verified and instances of the device can be placed in the extracted view of the circuit. If you specify a library name, the library is searched. Otherwise, the library that contains the layout cellview is searched. If that search fails, all available libraries are searched in arbitrary order.
The following example illustrates model definitions.
Optional keyword which specifies that the tool matches the terminals of this model by the physical terminal count, rather than by the logical terminal count.
The program gathers the terminals of a device by both the figure number and the node number. Each unique figure number represents a physical terminal. Each unique node number represents a logical terminal. Logical terminals must, by definition, be a subset of physical terminals.
For each device that the program detects, it cycles through the provided device definitions and their different terminal types. The program then tries to match either the logical or the physical terminal count as defined by this keyword or lack of keyword.
A device is matched if all its terminals match either the physical or logical counts. A device is not matched if some of its terminals match the physical count and some match the logical net count.
If a device could match more than one model, the program matches whichever one it comes across first. There is no precedence for logical or physical counts.
The use of the “physical” option does not necessarily allow for all possible terminal connection scenarios. The following examples illustrate structures which are ambiguous.
Optional keyword that enables reporting of malformed devices as errors. When the Assura form of the command is used, the default is to not report malformed devices, which can be changed with this keyword. When the Diva form is used, this keyword is the default.
Optional argument that allows you to specify the character string to use as the prefix for the instance name. Instance names are constructed from the prefix and an integer value to create a unique name. If not provided, the default prefix of “+” is used.
The string parameter must be a quoted string or an expression that evaluates to a string.
Optional argument that allows you to specify a property to be attached to each instance that extractDevice rule generates. You can use more than one property option in an extractDevice rule.
The name parameter must be a quoted string or an expression that evaluates to a string.
The value parameter must be a quoted string, integer constant, real constant, or an expression that evaluates to a string, integer or real.
Optional argument that allows you to specify the cellview to use for the device instance. The string must follow the same format as for the model parameter.
Optional argument that allows you to specify the Spice model in the Assura physical verification RCX processing. In Diva, this option is parsed, but ignored.
The string parameter must be a quoted string or an expression that evaluates to a string.
Optional argument that allows you to specify the target layer in the Assura physical verification device extraction. In Diva, this option is parsed, but ignored.
The string parameter must be a quoted string or an expression that evaluates to a string.
Optional argument that allows you to specify the terminal order in the Assura physical verification RCX processing. In Diva, this option is parsed, but ignored.
The string parameter must be a quoted string or an expression that evaluates to a string.
Examples
The following example illustrates the extractDevice command for a four-terminal MOS transistor with terminal names of “S,” “D,” “G,” and “B.” The device recognition layer is gate. The poly layer is used for a single terminal, but the diff layer is used to define both “S” and “D.” The device is recognized, even if the source and drain are shorted together, provided that these terminals are formed by independent shapes.
extractDevice( ngate poly("G") ndiff("S" "D") pwell( "B" ) "nfet ivpcell" physical )
Diva verification is careful in forming devices. In order to extract a device, Diva must find a shape on the recognition layer that touches or overlaps shapes on each of the specified terminal layers.
There must be exactly the right number of terminals of each type, in this case, exactly one each of "poly" and "pwell" and exactly 2 of "ndiff". If any of these conditions are not met, you will get the “cannot match terminal counts ...” message. The cause for this message depends on the particular extraction rules you are using and you will need to check each terminal layer to determine the root cause. Use of saveInterconnect for each layer can help in debugging the error.
extractMOS
extractMOS( recLayer gate s_d [bg] model [length width scale] )
Description
The extractMOS command extracts MOS devices from the layout and stores them in an extracted view of the circuit. The gate width and length parameters are measured and stored on the device instance.
This command is a macro implemented using the following commands:
extractDevice(recLayer gate s_d bg model)
extractDevice(recLayer gate s_d bg model physical)
w = measureParameter(length (recLayer butting s_d) 0.5)
p = measureParameter(perimeter recLayer 0.5)
l = calculateParameter(p - w)
saveParameter(w width)
saveParameter(l length)
Prerequisites
The terminal layers (gate, s_d, and bg) must be derived and must be connected layers. The device recognition layer must have been merged. The options length, width, and scale must be used together and in the order shown.
Fields
Specifies the device recognition layer name. This must be a merged derived layer name. Each shape on this layer causes the extraction of a separate device.
The transistor gate terminal. The definition contains a layer name for the terminal followed by an optional text string in parentheses specifying the terminal name. The default terminal name is “G.” Use this format for the definition.
The transistor source and drain terminals. This definition contains a layer name for the terminals followed by two optional text strings in parentheses specifying the terminal names. The default terminal names are “S” and “D.” Use this format for the definition.
layer [ ( "t_sname" "t_dname" ) ]
The optional transistor back-gate terminal. This definition contains a layer name for the terminal followed by an optional text string in parentheses specifying the terminal name. The default terminal name is “B.” Use this format for the definition.
The device model name, which is a character string enclosed in quotes.
You must define the model name and the view name, and optionally, the library name in the character string. If you don’t specify the view name, the program defaults to the name symbol.
The defined model must be available in a library accessible by the program so that the terminal configurations can be verified and instances of the device can be placed in the extracted view of the circuit. If you specify a library name, the library is searched, otherwise, the library that contains the layout cellview is searched. If that search fails, all available libraries are searched in arbitrary order.
The following example illustrates model definitions.
|
Search for model nfet lvs in the library that contains the layout cellview. If that search fails, all available libraries are searched in arbitrary order. |
|
You can optionally specify a name in quotes for the transistor length property. If you do not define this name, the program uses the default name of l. This option must be used with the width and scale options.
You can optionally specify a name in quotes for the transistor width property. If this name is not defined, the program uses the default name of w.
You can optionally specify a floating-point number defining the scale of the width and length properties. The scale is relative to the user units in use. With user units of microns, the default value of 1.0 implies that the width and length are measured in microns. Similarly, a value of 1.0e-6 converts the units to meters.
Examples
The following example illustrates the extractMOS command for a four-terminal MOS transistor with terminal names of S, D, G and B, and width and length properties of w and l.
extractMOS( gate poly diff substrate "nfet" )
All the terminal names, properties, and model views are defaulted.
The next example illustrates the extractMOS command for the same device, but explicitly defines the previously defaulted values.
extractMOS( gate poly("G") diff("S" "D") substrate("B") "nfet symbol" "l" "w" 1.0 )
Data Storage
saveInterconnect
saveInterconnect( layer_list [ tile ] [ fig ] [ fig(n) ] )
Description
The saveInterconnect command copies shapes into the extracted cellview. If a layer being copied has nodal information because it was being processed in a geomConnect command or because it was being processed by commands that maintain net information, it is saved in the extracted cellview with net purpose. Any other layer, whether an original graphics layer or a derived layer, is saved with drawing purpose.
Fields
A single original layer name enclosed in quotes, or a derived layer name. Shapes from the layer are saved in the extracted view on the graphics layer having the same name.
A parenthesized list consisting of a single original layer name enclosed in quotes, or a derived layer name followed by a graphics layer name in quotes, or a parenthesized layer purpose pair. Shapes from the first layer are saved in the extracted view on the second layer.
By default, if no purpose is given, the “net” purpose is used for connected layers and the “drawing” purpose is used for unconnected layers.
Optional keyword that causes the output layer to be generated as trapezoids. This is the default in Abgen mode.
Optional keyword that causes the output layer to be generated as figures. This is the default in Extract mode.
Optional keyword that causes the output layer to be generated as figures with no more than n vertices.
Examples
The following examples illustrate the saveInterconnect command.
Save a single derived layer poly on the graphics layer “poly.”
saveInterconnect( poly )
Save diffn to the graphics layer “diffusion.”
saveInterconnect( ( diffn "diffusion" ) )
Save two layers in one command.
saveInterconnect( ( metal "cuts" ) (poly "poly1") )
saveInterconnect( poly tile )
Save a layer on a non-standard purpose.
saveInterconnect( ( poly ( "poly1" "pin" ) ) )
saveProperty
saveProperty( deviceLayer propname expression )
Description
This command saves a preset property on devices created using the extractMOS or extractDevice commands.
Fields
A device recognition layer reference previously used in an extractMOS or extractDevice command.
This entry can also be a layer derived from a device recognition layer by a selection command such as geomInside or geomGetTexted. For each shape on this layer, the property is saved on the original device from which the shape was derived.
The name of the property, in quotes, to be saved on the devices formed by the deviceLayer.
The contents of the property to be saved on the devices formed by the deviceLayer. This can be either a character string in quotes or a fixed or floating-point number. The number might include an expression involving preset variables.
Examples
The following examples illustrate the saveProperty command.
saveProperty( gate "type" "nfet" )
saveProperty( pgate "fan-out-limit" 5 )
p = "float-property" x = 2
saveProperty( n_gate p sqrt(x) )
saveRecognition
saveRecognition( recLayer [display_layer] )
Description
The saveRecognition command stores the extracted device recognition shapes used in the extractDevice and extractMOS commands in the extracted cellview and attaches them to the appropriate device instances.
Fields
The device recognition layer used in the extractDevice or extractMOS commands.
You can specify an optional graphics layer name enclosed in quotes. If this layer is specified, the shapes from the recognition layer are displayed on it. Otherwise, the shapes are displayed on a graphics layer with the same name as the recognition layer.
Examples
The following example saves the recognition layer gate and displays it on the original graphics layer “gate.”
saveRecognition( gate )
This example saves the recognition shapes from the layer gate and displays them using the “gate_display” graphics layer.
saveRecognition( gate "gate_display" )
Return to top