4

---

OpenAccess Technology Data Changes

---

This chapter describes the mapping between OpenAccess and Virtuoso for your technology data:

• OpenAccess Data Models
• Virtuoso Support for OpenAccess Data Models
  • Support for Incremental Technology Database
  • Constraint Support for 45/65 nm Process Rules
  • Constraint Support for 32 nm Process Rules
  • Support for Using Group Definitions
  • Support for Predefined Via Parameters
  • Purpose-Aware Constraints
  • Reserved Purposes
  • Support for New ITDB Constructs
  • Moving Your Data to OpenAccess Data Model 4
  • Opening an IC6.1.1 Database
• Virtuoso Support of Technology File Constraints
  • Types of Constraint Groups
    • Foundry Constraint Group
    • Setup Constraint Group
    • Specialized Constraint Groups
  • Hard and Soft Constraints
  • Coincident Allowed Parameter
  • Constraint Group Properties
  • Constraint Group Semantics
  • Technology Database File Name
  • Technology File Updates Using Merge and Replace
  • Changes to Table Spacing Syntax
  • Translation of the resistancePerCut Property
• Conversion of Technology File controls Class
• Conversion of Technology File layerDefinitions Class
• Conversion of Technology File layerRules Class
• Conversion of Technology File physicalRules Class
• Conversion of Technology File electricalRules Class
• Conversion of Technology File prRules Class
• Conversion of Technology File leRules Class
• Conversion of Technology File lxRules Class
• Conversion of Technology File devices Class
• Technology File Via Definitions and Via Specifications
• Technology File Site Definitions

OpenAccess Data Models

With every new version release (data model revision), OpenAccess adds new kinds of data to the previous data model. The following table lists the prominent features associated with each data model revision.

Virtuoso Support for OpenAccess Data Models

This section describes the features of OpenAccess and The table below maps the Virtuoso support for OpenAccess data models in the various IC releases.

Support for Incremental Technology Database

IC6.1.x releases see the introduction of incremental technology databases (ITDB). This method of handling technology data allows technology information from multiple sources, such as the foundry, an IP provider, or designer at different times in the design cycle. Applications can incrementally assemble technology information by creating references from one technology database to other technology databases. This will allow the appropriate design team the rights to manage only the specific section of technology information that is relevant to them.

In the following example, the LEF technology database, referenced by the Design Library, references two technology databases, the Foundry Variant technology database and the Standard Cell technology database. This means that the design constraints and process information in the referenced databases are applicable to the Design Library design. The Design libraries technology database is a derived technology database because it is, in effect, inheriting information from the technology databases that it references. Furthermore, both device technology databases reference the Foundry technology database, which references the default technology database. This chain of references is known as the technology database graph.

Each reference is created separately, and the technology database graph is created incrementally.

Setup

If incremental technology databases are not applicable to your design needs, your current technology database requires no setup or modification. The software, however, now handles all technology databases as incremental technology databases. Consequently, it will automatically remove system-reserved layers and purposes from your technology database and add a reference to cdsDefTechFile, the default technology database that defines system-reserved layers and purposes.

Conflict Checking

Since a technology library can inherit information from other technology libraries through an ordered set of references, conflicting objects are not allowed in a technology database graph. When a technology file is compiled, checks are done to determine if the objects with the same matching characteristics already exist within the database graph.

New Technology File Subsection

A technology file section has been added which lists the ordered technology libraries. For example,

controls(
   techParams( ... )
   viewTypeUnits( ... )
   mfgGridResolution( ... )
   refTechLibs(
      "StdCells"
      "PRtech"
      "Foundry"
   )

)

For information, see the Virtuoso Technology Data User Guide.

Constraint Support for 45/65 nm Process Rules

From IC6.1.2, Virtuoso leveraged the new OpenAccess data model 4 constraints to support the constraints for 45 nm and 65 nm processes for constructing correct layouts and to support the new LEF constructs.

Constraint Support for 32 nm Process Rules

From IC6.1.4, Virtuoso leveraged new constraints that have been added to OpenAccess data model 4 to support the 32 nm foundry design rules. Some existing constraints have also been enhanced to provide support for 32 nm processes. The new constraints and constraint options also support the new LEF 5.8 constructs. The new constraints are Cadence-specific and therefore, the prefix cdc is used for those constraints.

For writing a technology file that uses the new constraints, you need to start from a previous technology file from the same foundry, such as use 65 nm technology file to write a 45 nm technology file.

Support for Using Group Definitions

The oaGroupDef allows you to specify the definiton of a group. You can restrict the membership of the group by defining the object types that can be placed in the group as well as the databases in which the group can be created. For example, you can define a group that contains only oaNets.

Virtuoso leverages some of the OpenAccess built-in groups definitions for grouping nets. You can define the net groups using the Virtuoso Constraint Manager. You can create process constraints on these net groups using the Process Rule Editor.Using the Process Rule Editor, the process rules can be created either in the design or in the technology database.

ConstraintGroupDef

An oaConstraintGroupDef is a public object that specifies a definition for a constraint group. The definition contains a name, a type, a list of databases that the constraint group can be created in, a list of objects (by type) that the constraint applies to, a relationship type, and an indicator of whether or not there can be only one constraint group that uses this definition in any given database.

There are a set of built-in ConstraintGroupDefs with associated semantics:

• oaImplicit
• oaDefault
• oaFoundry
• oaTaper
• oaInputTaper
• oaOutputTaper
• oaShielding
• oaTransReflexive
• oaReflexive
• oaInterChild
• oaUserDefined

Support for Predefined Via Parameters

OpenAccess lets you store predefined parameterizations of oaStdVias and oaCustomVias. These predefined parameterizations of the via constraints are known as via variants. Thus, the oaViaVariant object represents a named pairing of an oaViaDef reference and a specified set of parameters. oaViaVariants can be stored in technology and design databases.

The ASCII technology file reader and writer support the oaViaVariants to preserve technology data integrity. Though Virtuoso supports these objects, it does not create them automatically.

Purpose-Aware Constraints

OpenAccess data model 4 supports purpose-aware constraints. This allows applications to limit the scope of a layer-based constraint to a specific set of purposes. These constraints are aimed for the fillOPC rules.

Reserved Purposes

In data model 4, OpenAccess has introduced built-in purpose types for matching a layer with a constraint. The oaFillopcPurposeType built-in purpose type specifies whether or not a fill shape requires OPC.

Support for New ITDB Constructs

processFamily

Foundries can set the this technology database attribute to ensure that technology databases in the same graph are from the same process family.

exclusiveLayers (layer attribute):

OpenAccess allows you to exclude layers by name from a graph of technology databases. This helps you prevent inadvertent references to incompatible layers in a graph of technology databases.

From IC6.1.2, you can create such constructs by explicitly adding them to your ASCII technology file and compiling it. These constructs are not mandatory. Virtuoso does not create these constructs automatically.

Constraint Parameters

There are new built-in oaConstraintParamTypes for which applications can create corresponding oaConstraintParams.

• oacSpacingDirectionParamType
• oacCutDistanceConstraintParamType
• oacDistanceWithinConstraintParamType
• oacNoSharedEdgeConstraintParamType
• oacNotchLengthConstraintParamType
• oacNotchSpacingConstraintParamType
• oacNotchWidthConstraintParamType
• oacConnectivityTypeConstraintParamType
• oacPGNetConstraintParamType
• oacCenterToCenterConstraintParamType
• oacAreaConstraintParamType
• oacStackConstraintParamType
• oacExceptSamePGNetConstraintParamType
• oacNoSingleCutViaConstraintParamType

The following constraint parameter has been modified:

• oacWidthLengthTableTypeConstraintParamType
  This parameter is extended to accept a third integer value to designate that the constraint value stores the LEF SPACINGTABLE PARALLELRUNLENGTH TWOWIDTHS specification.

Huge String/Name Data

OpenAccess provides the ability to open very large databases containing over 4 GB of string data or over 2GB of string data from object names represented using oaName.

oaPartitions

OpenAccess provides the ability to access only the data that an application needs, improving both capacity and performance. Specifically, the oaPartition class lets an application organize data of a given data type into different partitions, which can then be loaded individually.

Huge oaPointArray Data

OpenAccess supports the ability to create more than 4GB of pointArray data on any one of the following design database objects: polygons, lines, paths, blockages, boundaries, and markers.

Huge oaAppProp Data

OpenAccess supports the ability to create more than 4GB of AppProp data in any OpenAccess database.

Moving Your Data to OpenAccess Data Model 4

When you open a database in IC6.1.2, it gets stamped as data model 4. For example, the use of the following constraints or features in IC6.1.2 triggers a data model 4 uprev on your data. When you save the design or technology database using these constraints or features, the data model 4 stamp will be attached to your database.

• When a technology database that contains purpose-specific rules is loaded, the database is uprev’ed to data model 4.
  For example,

  minSpacing ( metal1 0.4)               => will not trigger DM4

  minSpacing ( ('metal1' 'fillOPC') 0.5) => will trigger DM4

  minSpacing ( ('metal1' 'drawing') 0.4) => will trigger DM4

• Any technology database referring to the oaFillopcPurposeType purpose in an LPP-based rule or any design database containing shapes on this purpose are uprev’ed to data model 4 when loaded; the DFII reserved purpose number is uprev’ed to the OpenAccess system reserved purpose.
  If a database created before data model 4 includes a user-defined purpose that uses a purpose number in the reserved range, and that database is loaded by newer OpenAccess shared libraries, the user-defined purposes in the reserved range are removed from the database.
• Use of the 'select operator in a derived layer construct of the ASCII technology file results in the corresponding technology database to be a data model 4 technology database.
  For example,

  techDerivedLayers(
    ; use purpose name allowed
      ( drv3   10003   (metal2  'select  drawing) )
    ; use purpose name allowed
      ( drv4   10004   (via     'select  label) )
    ; purpose number allowed
      ( drv5   10003   (metal2  'select  10) )
  ; techDerivedLayers
  

• Setting the following attributes to anything different than the default value triggers data model 4 stamping for the design database.
  

  pinId ~> type

  layerBlockageID ~> allowPGNet

  layerBlockageID ~> spacing

  areaBlockageID ~> isSoft

  areaHaloID ~> isSoft

Opening an IC6.1.1 Database

Whether or not a data model 4 feature is added to your database in IC6.1.2 and you attempt to open the technology or design database in IC6.1.1, you will receive one of the following messages based on the action you are trying to perform:

• If you open a technology database that contains "do not open" DM4 features, you get the following warning message:
  

  *WARNING* techGetObjTechFile: Tech database contains features defined in OpenAcess data model version 4, and cannot be opened by software that supports data model version 3

• If you open a design database that contains "do not open" DM4 features, you get the following warning message:
  

  *WARNING* dbOpenCellViewByType: Design database contains features defined in OpenAcess data model version 4, and cannot be opened by software that supports data model version 3

• If you open a design database that contains "do not append" DM4 features, you get the following warning message:
  

  *WARNING* dbOpenCellViewByType: Design database contains features defined in OpenAcess data model version 4, and cannot be opened for edit by software that only supports data model version 3. It can be opened for read.

Virtuoso Support of Technology File Constraints

Types of Constraint Groups

Foundry Constraint Group

Setup Constraint Group

Specialized Constraint Groups

Hard and Soft Constraints

Coincident Allowed Parameter

Constraint Group Properties

Constraint Group Semantics

Technology Database File Name

Technology File Updates Using Merge and Replace

Changes to Table Spacing Syntax

Translation of the resistancePerCut Property

In DFII on CDB, the technology file rules were implemented as hard foundry technology rules. In the Virtuoso Studio design environment, technology rules are replaced with technology constraints which are grouped into constraint groups.

Each constraint group contains subsections which are used to divide similar types of constraints into smaller sections. These sections closely correspond with the CDB rule sections. For example, the following CDB technology file class is mapped to the Virtuoso environment technology file as follows;

For information about types of constraint groups, see Types of Constraint Groups.

Constraints and constraint groups (containers that hold constraints and references to constraint groups) can be defined in the technology file or are created when technology data is translated from an external application. Constraints that have been created by an external application (with proper name and definition) and translated into the Virtuoso environment are mapped to an appropriate constraint and constraint group in the technology file.

Whether or not a constraint group is applied to an object, depends on the application. Constraints are obeyed only in the event an application is designed to adhere to them. The Virtuoso application support is based on the applicable constraint group (and thus the contained constraints) and of the constraints in that group, which are designated to be enforced or obeyed by the application.

In the diagram below, minArea is defined as single layer spacing constraint in the Virtuoso technology file and is mapped to the constraint type oacMinArea. The LEF technology data {AREA minArea} also maps to the constraint type oacMinArea. Using the predefined name and explicit definition allows interoperability between tools.

User Defined Constraints

CDB rules translated to the Virtuoso environment can be added to two types of sections within a constraint group.

• CDB rules that map correctly to the Virtuoso environment constraint definitions and are interoperable with other applications on OpenAccess.
• User defined constraints which are CDB rules that have a unique name and can not be mapped to an OpenAccess constraint. User defined constraints are only accessible to Virtuoso applications and are not interoperable with other tools. This includes layer purpose pair (LPP) based constraints. Technology file constraints that are defined for LPPs are stored as a private extensions and are only available for Virtuoso applications.
  For information about how rules are mapped, see Mapping CDB Physical Technology File Rules to OpenAccess Constraints.

OpenAccess constraints support an implicit order of precedence. User defined constraints do not support an order of precedence. Because of this, user defined constraints are grouped below all OpenAccess constraints that do require order.

For example, a CDB technology file containing spacingRules, orderedSpacingRules, and tableSpacingRules, when translated and dumped, could contain six sections,

• user defined spacingRules
• OpenAccess spacingRules
• user defined orderedSpacingRules
• OpenAccess orderedSpacingRules
• user defined tableSpacingRules
• OpenAccess tableSpacingRules

The user defined spacing rule, minMosWidth, is defined as:

constraintGroups(
( "foundry"
;physical constraints
   spacings(
   ( minSpacing tx_layer g_value )
   ) ;spacings
   spacings(
   ( minMosWidth tx_layer g_value )
   ) ;spacings
) ;foundry
) ;constraintGroups

The value of a user defined constraint is applied as a string. The interpretation of the string is handled by individual applications.

t_userConstraint lt_layer1 [lt_layer2] t_value )

(userConstraint metal1 "myValue")

Types of Constraint Groups

There are different types of constraint groups which are supported: foundry and setup constraint groups. Constraint groups are applied to the design associated with the attached technology library.

Foundry Constraint Group

The foundry constraint group consists of the set of technology constraints that must always be satisfied. These constraints are implicitly applied to all designs that are associated with a technology database containing this set of constraints. For example:

constraintGroups(
   ( "foundry"

The name of the hard foundry constraint group defined in the ASCII technology file is foundry. The name foundry is only defined in the Virtuoso environment. The OpenAccess foundry constraint group is not associated with a specific name.

Setup Constraint Group

Setup constraint groups are used by the XL layout editor and the chip assembly router. The default names of the setup constraint groups are:

• virtuosoDefaultExtractorSetup: XL layout editor
• virtuosoDefaultSetup: chip assembly router.

The virtuosoDefaultExtractorSetup constraint group lists the valid layers to be used for XL layout editor connectivity extraction and the layers to be used by the Create Wire command within the XL layout editor.

Setup constraint groups can be created using any name and can be selected from the options form of the corresponding application.

Specialized Constraint Groups

The following user-defined constraint groups are created by OpenAccess LEF and DEF translators:

• LEFDefaultRouteSpec: Stores routing information, such as information about layers and vias
• LEFSpecialRouteSpec: Stores information about power routing vias

The specialized constraint groups can be stored in either technology or design database. If stored in a technology database, the constraints apply across any design that is associated with that technology. If stored in the design database, the constraints apply only to that particular design. Design-specific constraints take precedence over constraints in the technology database.

A single technology can have only one LEFDefaultRouteSpec and one LEFSpecialRouteSpec. However, each technology in a graph of technology databases can have its own set of these constraint groups. In addition, a design can have its own LEFDefaultRouteSpec and LEFSpecialRouteSpec constraint group. Therefore, an application can have multiple LEFDefaultRouteSpecs and multiple LEFSpecialRouteSpecs in a graph of referenced technology databases. An application creates overriding constraints in the more derived technology.

Older databases do not allow multiple constraint groups named LEFDefaultRouteSpec because they conflict by name. In OpenAccess data model 4, by using the constraint group definition, a graph can have multiple constraint groups of these types as long as the constraint groups names are unique in the graph.

For information about how OpenAccess LEF and DEF translators map constructs into LEFDefaultRouteSpec and LEFSpecialRouteSpec, see Design Data and Technology Data Preparation in the Mixed Signal (MS) Interoperability Guide.

Member Constraint Group

A constraint group can be created as a member of another constraint group. When multiple member constraint groups are specified, their order of precedence is from top to bottom; that is, the first member constraint group specified has the highest precedence, and the last has the lowest.

Built-In Constraint Group Types

Most of the built-in constraint group types are for the design database only. However, some of them can be specified in the technology database as well.

constraintGroups(
; name [override] [type]
  ( "group" [t | nil] [nil | "taper" | "inputTaper" | "outputTaper"]
  ...
  ) ; group
) ;constraintGroups

Hard and Soft Constraints

In Virtuoso, soft constraints saved to Virtuoso or translated to Virtuoso are preserved in the technology file. However, Virtuoso applications do not support soft constraints. The hard and soft indicators are as follows:

( t_constraint [lt_layers] g_value 'hard )

( t_constraint [lt_layers] g_value 'soft )

Coincident Allowed Parameter

The coincident allowed parameter, which can be specified for several constraints, is defined using the 'coincidentAllowed symbol. It cannot be specified for user-defined or layer-purpose pair constraints.

( t_constraint [lt_layers] g_value 'coincidentAllowed 'hard)

( t_constraint [lt_layers] g_value 'soft 'coincidentAllowed)

Constraint Group Properties

In the Virtuoso environment, properties can be associated with a constraint group. The following is an example of a property applied to a constraint group:

constraintGroups(
;( group 
( "constraintGroupName" 
...
   properties(
   ( t_propName g_value )
   ); properties
) ;constraintGroupName
); constraintGroups

Constraint Group Semantics

Constraint groups follow the precedence semantic as per which, the first hard constraint found in the constraint group must be satisfied. If a soft constraint is encountered and not satisfied, the search for constraint continues until either a constraint that can be satisfied is found or a hard constraint that cannot be satisfied is found.

To handle the more complex rules of 45/65 nm processes where constraints are specified as either a series of circumstances in which a given constraint applies or a set of exception conditions in which the constraint does not apply, the following constraint group semantics are used:

• AND: This operator specifies that all constraints within the same constraint group must be satisfied.
• OR: This operator specifies that only one of constraints within the same constraint group must be satisfied.

The precedence semantic is the default semantic followed by constraint groups.

constraintGroups(
; name [override] [type] [semantic]
  ( "group" [t | nil] [nil] ['and | 'or | 'precedence]
  ...
  ) ; group
) ;constraintGroups

For example, the following LEF representation of minimum protrusion number of cuts constraint for layer VIA 1:

MINIMUMCUT 2 WIDTH 0.419 LENGTH 0.419 WITHIN 5.000;

MINIMUMCUT 4 WIDTH 0.979 LENGTH 0.979 WITHIN 6.000;

would map to the following constraint group using the AND operator:

constraintGroups(
  ( "myAndConstraintGroup" nil nil 'and
     spacings(
     ( minProtrusionNumCut VIA1 'distance 5.000 'width 0.419 'length 0.419 2 )
     ( minProtrusionNumCut VIA1 'distance 6.000 'width 0.979 'length 0.979 4 )
     ) ;spacings
  ) ;myAndConstraintGroup
) ;constraintGroups

Technology Database File Name

The name of the technology database file has changed from techfile.cds to tech.db; however, do not hard code the filename. Applications that use a hard-coded technology filename should no longer do so. Instead, if you require the technology filename, retrieve it as follows:

• For SKILL, use the new SKILL function techGetDefaultTechName
• For C and C++, use the # define techcDefaultTechFileName constant

Technology File Updates Using Merge and Replace

The following describes the behavior of loading a technology library with an ASCII technology file using the Merge and Replace options on the Load Technology File form.

• Using Merge does not manipulate constraint groups.
  When updating a technology library using the Merge option, existing constraint groups that are not referenced in ASCII version of the technology file are not manipulated.
• Using Replace removes constraint groups.
  When updating a technology library using the Replace option, existing constraint groups that are not referenced in ASCII version of the technology file are removed.

For example, if the existing technology file contains constraint groups A, B, and C, and the ASCII version contains A’ and D (A’ being a modified constraint group) the results of updating would be:

• Using the Merge option would result in a technology library containing constraint groups A’, B, C and D.
• Using the Replace option would result in a technology library containing constraint groups A’ and D.

When updating the technology library using both Merge and Replace option,

• new constraint groups referenced in ASCII version of the technology file are added.
• same name constraint groups in the existing technology file are replaced with the ASCII version of the technology file.

Changes to Table Spacing Syntax

Virtuoso Environment Syntax

In the spacingTables() syntax, each table index definition is given by:

l_index1Definitions is a list defining the name, predefined index values, and user defined match function for the first table dimension. The format of the list is as follows:

( [nt_indexName] [(lg_indexValue...)] [t_userMatchFunction] )

• • where nt_indexName is the name of the first dimension of a two dimensional table or the only dimension of a one dimensional table. Valid values: Any number or string.
  • The g_indexValue is a list of predefined indexes, specifying the indexes that can be used in the table. Valid values: Any number or string.
  • The t_userMatchFunction is the name of a user-defined match function. Valid values: Any string.

CDB Syntax

In CDB, entries in the table are defined in the following way:

the l_table is a list defining the table entries, in the following format:

( g_index1 [t_matchType1] [ g_index2 [t_matchType2] ] g_value ... )

• • where g_index1 is the first index in a two dimensional table or the only index in a one dimensional table. Valid values: Any number, string, or list.
  • The t_matchType1 is the match type to use for index1. Valid values: One of the following: < , <=, ==, >=, >, userMatchFunction or nil where userMatchFunction is a user-defined match function. Default: ==.
  • The g_index2 is the second index in a two dimensional table. Valid values: Any number, string, or list.
  • t_matchType2 is the match type to use for index2. Valid values: One of the following: <, <=, ==, >=, >, t_userMatchFunction or nil where userMatchFunction is a user-defined match function Default: ==.
  • g_value is the value to use when the application finds a match to the index or pair of indexes during table lookup. Valid values: Any number or string.

In the Virtuoso environment technology file of any table, a unified "match function” is defined, either ">=" (">") or "<=" (<), depending on the semantic defined for the constraint the table is representing, except for on the index boundaries (lowest or highest index value) which you may specify differently. The indexes of the table are sorted in ascending order.

Currently, the match function, if it is defined, is ignored. All tables are predefined with ">=" look up. When the technology file is translated from CDB to Virtuoso environment, the translation does not convert the match function since this is not supported. During translation, the table is populated by the correct values from the CDB table taking into consideration any match functions which may be defined.

Translation of the resistancePerCut Property

If the property resistancePerCut exists on cellview, the value of the property is translated to resistancePerCut of the via definition.

If the property res exists on cellview, the value is translated to resistancePerCut of the via definition as the value of property multiplied by the number of cuts.

If the electrical rule resistancePerCut exists on the via layer, the value is translated to resistancePerCut of the via definition.

Conversion of Technology File controls Class

Layers

constraintGroups(
( "virtuosoDefaultSetup" 
   interconnect( 
   (validLayers (tx_layer)... )
   ) ;interconnect
) ;virtuosoDefaultSetup
) ;constraintGroups

layerRules(
   functions(
      ( tx_layer tx_material g_maskNumber)
   ); functions
);layerRules

iccLayers = list(
   list(lt_layer t_function t_direction f_width f_spacing [g_ref [g_translate]]) 
   [list(...)]...
) 

Vias

constraintGroups(
( "virtuosoDefaultSetup" 
   interconnect( 
   (validVias (tx_layer)... )
   ) ;interconnect
) ;virtuosoDefaultSetup
) ;constraintGroups

For cdsViaDevices: standardViaDefs()

viaDefs(
standardViaDefs(
   ( t_viaDefName tx_layer1 tx_layer2
      ( t_cutLayer n_cutWidth n_cutHeight [n_resistancePerCut] )
      ( x_cutRows x_cutCol ( l_cutSpace ) )
       l_layer1Enc ) ( l_layer2Enc ) ( l_layer1Offset )
      ( l_layer2Offset ) ( l_origOffset )
      [tx_implant1 (l_implant1Enc) [tx_implant2 (l_implant2Enc]]
   )
) ;standardViaDefs
) ;viaDefs

viaDefs( 
   customViaDefs(
       ( t_viaDefName t_libName t_cellName t_viewName
      tx_layer1 tx_layer2 [n_resistancePerCut] )
   ) ;customViaDefs
) ;viaDefs
For more information about mapping CDB vias, see Mapping of CDB Devices. 

iccVias= list(
   list(
       list([list(t_libName t_cellName t_viewName)] | 
       t_pseudoViaName list(lt_layer ....)
       [g_translate])
           [list(...)]...
)

DBUPerUU Stored in the Technology File

Unlike CDB, OpenAccess provides a single location for database units per user unit (DBUPerUU) and user unit information (userUnit) stored in the technology file. The following is an example of the ASCII technology file syntax.

controls(
   viewTypeUnits(
   ( maskLayout          "micron"        2000            )
   ( schematic           "inch"          160             )
   ( schematicSymbol     "inch"          160             )
   ( netlist             "inch"          160             )
   )
)

When migrating data from CDB to the Virtuoso environment, the values for user units (userUnits) and DBUPerUU are obtained from various locations and consolidated at a single location in the technology file.

The value of 0.0 is accepted in the technology file. If the value of 0.0 is unintentionally set in the technology file, the bbox of a new cellview and the initial window zoom level would be infinite. Also, the technology file API (see below) would return a value of (NAN:NAN:NAN:NAN).

DBUPerUU Access

The APIs listed below are provided to access DBUPerUU and userUnit information in order to meet the new model. These new APIs are implemented only for OpenAccess-based technology file APIs.

techGetDBUPerUU(d_techFileId t_cvType)

techSetDBUPerUU(d_techFileId t_cvType f_dbuperuu)

techGetUserUnit(d_techFileId t_cvType)

techSetUserUnit(d_techFileId t_cvType t_userUnit)

Using lib~>DBUPerUU or lib~>userUnits will report a warning. Also, lib~>prop will not return DBUPerUU and userUnits as properties. Any SKILL procedures depending on these calls should be modified.

For example, if the original SKILL code set the dbu/uu as

lib~>DBUPerUU~>maskLayout = 2000.0

the code based on OpenAccess should be

techSetDBUPerUU(techGetTechFile(lib) "maskLayout" 2000.0)

Manufacturing Grid

In CDB, the manufacturing grid was stored in the physicalRules class. In Virtuoso, the manufacturing grid is stored in the controls section of the technology file.

Manufacturing Resolution

controls(
   mfgGridResolution( g_resolution )
) ;controls

physicalRules(
   mfgGridResolution( g_resolution )
) ;physicalRules

Conversion of Technology File layerDefinitions Class

Technology File Changes for Layer Purposes

The purpose 0 is “unknown” (reserved).

For OpenAccess, the number of purposes has been increased as follows:

• You can define purposes numbered 1 through 128.
• If you want to define more purposes, you need to define purposes between 256 through 2³² - 65535.
  If you need to define more than 128 purposes, start with purpose number 256 and increment it by one to avoid conflict with purpose numbers at the high end of the range that are reserved by Cadence for future system use.
  
  

Virtuoso Studio design environment Technology File Reserved Purpose Types

The following table lists the Virtuoso reserved purposes that support control of display and selection of specific objects. The LPPs for the objects must be present in the technology file and the corresponding packets must be present in the display.drf file. Highlighted system reserved purposes are new in the Virtuoso Studio design environment.

Changing the Number of Characters for LSW Purpose Abbreviation

To change the display from 3 to 2 characters for the purpose abbreviation in the LSW, use the layout environment variable lswLPIconPurposeLength. For example,

envSetVal("layout" "lswLPIconPurposeLength" 'int 2)

LEF In Changes for Valid Layer Purposes

When translating data into the Virtuoso environment using LEF In, the following layer purposes are by default not valid, meaning they do not appear in the LSW. These purposes are used for display of objects only and the LPPs will not be available for shape drawing from the Layer panel of the LSW. Control selection and display of objects through the Object panel of the LSW.

net
pin
slot
fill
gapFill
blockage
boundary

The lefin option -pinPurp allows you to specify a specific purpose for pins, such as "pin", when translating data. By default, pins are created on the purpose "drawing". You can specify any purpose name. If the purpose does not exist in the technology library then lefin will create the purpose and add the name to the technology file. The purpose chosen as the pin purpose will be valid by default. This change only effects technology files newly created by LEF In.

OpenAccess Constants for Reserved Purposes

The following table shows the Cadence-defined constants for reserved purposes for the OpenAccess database. These predefined purposes are always available, and may not be changed nor removed. The Constant for Purpose Name always has the data type of string, while the Constant for Purpose Number has its data type determined by the typedef, dbPurpose.

Different Purpose and Layer Numbers Values

In CDB, the drawing purpose is represented by the number 252. In OpenAccess the drawing purpose is represented by 2³² - 1, which in hexadecimal is the number 0xffffffff.

The range of values for both purpose and layer numbers is much higher for OpenAccess than for CDB, due to the larger number of bits available. And for OpenAccess, the values of some reserved purpose numbers are assigned differently than for CDB.

• CDB uses 8-bit unsigned characters to represent positive numbers, in the range 0 through 255, which can also be stated as 0 through 2⁸ - 1.
• OpenAccess uses 32-bit unsigned integers to represent positive numbers, in the range of 0 through 2³² - 1. Large numbers in this range are represented in hexadecimal.

Purpose and Layers Numbers Can Appear as Negative Numbers.

SKILL can handle only signed numbers; therefore, in OpenAccess, large, unsigned numbers appear as negative numbers in SKILL, and when printed out by SKILL to ASCII.

For example, in OpenAccess, the drawing purpose is represented by 2³² - 1, which in hexadecimal is the number 0xffffffff.

In C or C++, the unsigned number 0xffffffff is available “as is”, however, in SKILL and ASCII produced by SKILL, it is not. In SKILL or ASCII, the number 0xffffffff is treated as signed and appears as -1, a negative number.

Updating User-Defined Purpose Names

Updating User Defined Purposes and Hard Coded Values

You will need to update your code if your code contains hard-coded purpose number such as 252 to represent the drawing purpose. If your code contains user defined purposes that conflict with OpenAccess purposes or CDB-specific hard-coded purpose numbers, your code will not work correctly with the OpenAccess database until you replace them.

Ideally, you should replace hard-coded numbers with their Cadence-defined names; for example, replace the number 252 with the string name, drawing. It is less desirable to replace CDB-specific hard-coded numbers with OpenAccess-specific hard-coded numbers, since hard-coded numbers are likely to require more maintenance in the future.

However, if you must use the purpose number instead of the purpose name in OpenAccess, you will have to use the negative number, which in SKILL, is equivalent to the large, unsigned number in OpenAccess. For example, you would have to use -1 for the drawing purpose.

In C and C++ code replace user defined purposes that conflict with OpenAccess purposes or hard coded values or with the OpenAccess-specific constant for the purpose name or purpose number. See OpenAccess Constants for Reserved Purposes.

Reload your code before you translate your data, especially if it includes SKILL-based Pcells.

Updating Data Type Definitions

You will need to update your code if your code contains CDB specific base data type definitions for purpose (such as unsigned char) instead of a Cadence-defined typedef (such as techLayerNum)

In SKILL, there are no Cadence-defined constants for purpose and layer numbers; nor are there typedefs. Typedefs are not needed, because SKILL automatically determines the data type for purpose and layer numbers, so no change is needed to SKILL code for data types

For C and C++ Code, Use Cadence-Defined Constants and typedefs

Cadence-Defined Constants

The drawing purpose is the only Cadence-defined purpose name that is common to both CDB and OpenAccess; however, it is defined by different purpose numbers. To make your C and C++ code database independent for the drawing purpose, use the following Cadence-defined constants for the drawing purpose:

• The database constant is dbcDrawingPurpose
• The technology file constant is techDrawingPurpose

These two constants are common to CDB and OpenAccess; using them helps your code run on both databases, and makes moving from CDB to OpenAccess easier.

In addition to drawing, CDB has numerous other Cadence-defined constants for purpose numbers, while OpenAccess has only a few. There are new Cadence-defined constants for the new OpenAccess reserved purpose names, but they are specific to the OpenAccess database, as those purposes are not defined by Cadence for CDB.

Cadence-defined constants for the values of database purpose numbers appear as hash define (#define) statements that look like this:

For CDB:

For OpenAccess:

For the location of the files containing the Cadence-defined constants for both CDB and OpenAccess, see “Location of Cadence-defined Constants and typedefs”.

Example of Constant for a Purpose Number

For example, for the drawing purpose in CDB, the purpose number is represented by the integer constant 252. But instead of setting the drawing purpose to a specific number for either CDB or OpenAccess, you should set it to the Cadence-defined constant for the drawing purpose, which is dbcDrawingPurpose or techDrawingPurpose, as shown below. Then your code will work with both databases.

For information about the Cadence-defined constants for purposes reserved by OpenAccess, see “OpenAccess Constants for Reserved Purposes”.

Cadence-Defined Constants typedefs

Cadence provides predefined typedefs that let you indicate the data type for the variables you declare for purpose and layer numbers. These typedefs are common to both CDB and OpenAccess. To make your C and C++ code database independent for the data types of your variables for purposes and layers, use the following Cadence-defined typedefs:

• The database typedefs are dbPurpose and dbLayer.
• The technology file typedefs are techPurpose and techLayerNum.

The Cadence-defined typedef statements for database purpose and layer numbers look like this:

For CDB:

For OpenAccess:

And for technology file purpose and layer numbers, they look like this:

For CDB:

For OpenAccess:

For the location of the files containing the Cadence-defined typedefs for variables for both CDB and OpenAccess, see “Location of Cadence-defined Constants and typedefs”.

In CDB, the data type for purpose number is unsigned char. But instead of using the base data type to declare variables, you should use the Cadence-defined typedefs; then your code will work with both CDB and OpenAccess.

Example of typedef for Purpose Numbers

For example, you need to declare a variable to contain the value of a purpose, such as drawing. The Cadence-defined typedef for purpose is dbPurpose. For purpose numbers, the base data type for CDB is unsigned char, while for OpenAccess, it is unsigned int. Instead of using the database-specific base data type, use dbPurpose, as shown below:

You do not even need to know what the data type of your variable for purpose is; the Cadence system will determine which database is being used and assign the appropriate data type to dbPurpose.

Location of Cadence-defined Constants and typedefs

For both CDB and OpenAccess, you can view the Cadence-defined constants and typedefs in the following locations:

• For database purpose and layer numbers, in your local Cadence hierarchy:
  

  ...tools/itkDB/include/itkDB.h

• For technology file purpose and layer numbers, in your local Cadence hierarchy:
  

  ...tools/itkDB/include/itkTechdb.h

Technology File Changes for Layers

• User-defined layers are 0 through 194 and 256 through 2³² - 1025.
• Cadence reserves the layers numbered 196 through 255 for system use, with layer 195 as the “null” layer and layers numbered 2³² - 1024 through 2³² - 1.
  
  

System Reserve Layers

When loading an ASCII technology file that contains user defined layers or obsolete layers within the reserved layer range, warning messages are issued and the layers are not created. For example, the following layers are obsolete as of the 4.4 release. If any of these layers still exist in your technology file you must remove them and re-load the technology file.

( winActiveBanner        240     winActi     )
( winAttentionText       241     winAtte     )
( winBackground          242     winBack     )
( winBorder              243     winBord     )
( winBottomShadow        244     winBott     )
( winButton              245     winButt     )
( winError               246     winErro     )
( winForeground          247     winFore     )
( winInactiveBanner      248     winInac     )
( winText                249     winText     )
( winTopShadow           250     winTopS     )

To remove obsolete layers or layers that are incorrectly defined in the reserved layer range, do the following.

1. In the CDB database, dump the ASCII technology file.
2. Using a text editor, find and delete incorrectly defined layers.
3. Load the ASCII technology file back into the technology library in Replace mode.
4. Translate the library to the Virtuoso environment.

Virtuoso Environment Layer Purpose Pairs Support

In the Virtuoso environment technology file it is possible to define technology rules for layer purpose pairs (LPP). For example, if you have a purpose named highPower for metal1 then you could define a different minimum width constraint for metal1 shapes with the highPower purpose from the minimum width for the metal1 layer shapes with no purpose specified.

OpenAccess rules/constraints are only applicable to layers, not layer purpose pairs. Currently in the Virtuoso environment, any technology rule which is defined for a layer purpose pair is stored as a private extension and is available for Virtuoso applications. However, the private extension is not visible outside Virtuoso applications.

Layer purpose constraints are supported in any constraint group. Although it is not permitted to define the same layer purpose pair constraint within a constraint group.

Technology File and LPP SKILL Attribute Changes

Technology File Attributes Name Changes

The names of the following technology attributes are different for CDB and the Virtuoso environment.

The attribute layers only returns a list of layers in the Virtuoso environment, not LPPs. For example, to return the list of layer IDs on the layer purpose pin:

CDB:

pinLayers = setof(lp techId~>layers lp~>purpose == "pin")

Virtuoso Studio design environment:

pinLayers = setof(lp techId~>lps lp~>purpose == "pin")

Layer Purpose Attributes

The attribute techLayer is replaced by layer for both technology file attributes and LPP attributes.

Derived Layers

Derived layer shapes are considered to be only an error if they are within a specific oaAreaBoundary and the oacErrorLayer constraint is true. The oaAreaBoundary is defined by the oaConstraintGroup to which the oacErrorLayer constraint belongs applied to the boundary layer object.

In the following example, the technology file contains one poly layer and two diffusion layers, diff and diff2. The combination of diff 'and diff2 gives one oxide model and the combination diff 'not diff2 gives a second oxide model. To identify the gate over the two oxide models, the syntax is shown below:

layerDefinitions(
   techDerivedLayers(
  ;( derivedLayerName layer# composition )
   ( oxide1           1000   (diff 'and diff2 ) )
   ( oxide2           1001   (diff 'not diff2 ) )
   ( gateOxide1       1002   (poly 'and oxide1 ) )
   ( gateOxide2       1003   (poly 'and oxide2 ) )
   ) ;techDerivedLayers
) ;layerDefinitions

The derived layer identifying oxide1 is then used in a second derived layer, so more complex derived layers can be represented. Once the derived layer has been defined in the layerDefinitions section of the technology file, the error layer constraint can be defined as:

constraintGroups
   ( "nameOfGroup"
   ;layer constraints
   interconnect(
      ( errorLayers (tx_derivedLayer)... )
   ) ;interconnect
) ;nameOfGroup
) ;constraintGroups

You can specify the following types of derived layers:

• Two-Layer Derived Layers
• Purpose-Aware Derived Layers
• Sized Layers
• Area-Restricted Layers

Two-Layer Derived Layers

The logical operation symbol can be one of 'or, 'and, 'not, 'xor, 'butting, 'buttOnly, 'coincident, 'coincidentOnly, 'buttingOrCoincident, 'overlapping, 'buttingOrOverlapping, 'touching, 'inside, 'outside, 'avoiding, 'straddling, and 'enclosing. For information about the logical operators, see Operator Definitions in the Virtuoso Technology Data ASCII Files Reference.

Layer purposes are not supported in this syntax and only one logical operation can be used to represent the composition of the derived layer.

layerDefinitions(
   techDerivedLayers(
      ( tx_derivedLayer x_derivedLayerNum ( tx_layer1 s_operation tx_layer2)        [x_contactCount | t_rangeVal] ['diffNet | 'sameNet] ['exclusive] )
   ) ;techDerivedLayers
) ;layerDefinitions

constraintGroups(
("foundry"
   interconnect( 
      ( errorLayers (tx_derivedLayer)... )
   ) ; interconnect
) ;foundry
) ;constraintGroups

Purpose-Aware Derived Layers

The 'select derived layer operation selects all shapes on the specified layer that have the required purpose. The purpose cannot be all or none and should be a specific purpose.

layerDefinitions(
   techDerivedLayers(
      ( tx_derivedLayer x_derivedLayerNum ( tx_layer 'select tx_purpose)
   ) ;techDerivedLayers
) ;layerDefinitions

constraintGroups(
("foundry"
   interconnect( 
      ( errorLayers (tx_derivedLayer)... )
   ) ; interconnect
) ;foundry
) ;constraintGroups

Sized Layers

You can specify sized layers derived from sizing up or down existing layers. Although this is stored as an oaSizedLayer as opposed to an oaDerivedLayer, a sized layer can be considered to be a type of derived layer.

The operators used to derive sized layers include: 'growHorizontal, 'growVertical, 'shrinkHorizontal, 'shrinkVertical, 'grow, and 'shrink. The sign of the value defined indicates whether the layer should grow or shrink by the amount specified. The horizontal and vertical directions are defined with respect to the x and y coordinates of the top-level cell.

layerDefinitions(
   techDerivedLayers(
      ( tx_derivedLayer ( tx_layer s_sizeOp g_value ) )
   ) ;techDerivedLayers
) ;layerDefinitions

Area-Restricted Layers

This constraint specifies the value to be applied to shapes on a particular layer, which are either less than or greater than the specified area.

layerDefinitions(
   techDerivedLayers(
      ( tx_derivedLayer ( tx_layer 'area x_area ) )
   ) ;techDerivedLayers
) ;layerDefinitions

Characterization Rules Stored as Layer Properties

This section describes the set of LEF layer attributes that are not used as constraints by OpenAccess, but are stored as properties of the physical layers. These are considered to be properties of the layer itself rather than a constraint applied to the layer.

There can only be one property on a layer of a given name. When multiple properties of the same name are given, the last value found will be taken and no warning is issued.

Single Layer Area Capacitance

layerDefinitions(
   techLayerProperties(
      (areaCapacitance tx_layer g_value )
   )
) 

electricalRules(
   characterizationRules( 
   ("areaCap" tx_layer g_value ) ... )
)

electricalRules(
   characterizationRules( 
   ("areaCapacitance" tx_layer g_value ) ... )
)

Two Layer Area Capacitance

layerDefinitions(
   techLayerProperties(
      (areaCapacitance tx_layer1 tx_layer2 g_value )
   )
) 

Single Layer Edge Capacitance

layerDefinitions(
   techLayerProperties(
      (edgeCapacitance tx_layer g_value )
   )
) 

electricalRules(
   characterizationRules( 
   ("edgeCap" tx_layer g_value ) ... )
)

electricalRules(
   characterizationRules( 
   ("edgeCapacitance" tx_layer g_value ) ... )
)

Two Layer Edge Capacitance

layerDefinitions(
   techLayerProperties(
      (edgeCapacitance tx_layer1 tx_layer2 g_value )
   )
) 

Layer Sheet Resistance

layerDefinitions(
   techLayerProperties(
      (sheetResistance tx_layer g_value )
   )
) 

electricalRules(
   characterizationRules( 
   ("sheetRes" tx_layer g_value ) ... )
)

electricalRules(
   characterizationRules( 
   ("sheetResistance" tx_layer g_value ) ... )
)

Cut Layer Resistance per Cut

layerDefinitions(
   techLayerProperties(
      (resistancePerCut tx_layer g_value )
   )
) 

electricalRules(
   characterizationRules( 
   ("sheetRes" tx_layer g_value ) ... )
)

Layer Height

layerDefinitions(
   techLayerProperties(
      (height tx_layer g_value )
   )
) 

electricalRules(
   characterizationRules( 
   ("height" tx_layer g_value ) ... )
)

Layer Thickness

layerDefinitions(
   techLayerProperties(
      (thickness tx_layer g_value )
   )
) 

electricalRules(
   characterizationRules( 
   ("thickness" tx_layer g_value ) ... )
)

Shrinkage Factor

layerDefinitions(
   techLayerProperties(
      (shrinkage tx_layer g_value )
   )
) 

electricalRules(
   characterizationRules( 
   ("shrinkage" tx_layer g_value ) ... )
)

Capacitance Multiplier

layerDefinitions(
   techLayerProperties(
      (capMultiplier tx_layer g_value )
   ) ;techLayerProperties
) ;layerDefinitions

electricalRules(
   characterizationRules( 
   ("capMultiplier" tx_layer g_value ) ... )
)

Conversion of Technology File layerRules Class

Via Layers

In CDB, via layers were identified in the viaLayers section of the layerRules group as follows:

viaLayers(
;( layer1     viaLayer      layer2   )
;( ------    --------       ------   )
( poly          cont         m1      )
( ndiff         cont         m1      )
( pdiff         cont         m1      )
( diff          cont         m1      )
( m1            via1         m2      )
( m2            via2         m3      )
( m3            via3         m4      )
( m4            via4         m5      )
) ;viaLayers

In the Virtuoso environment, the via layers information is determined from via definitions. See Technology File Via Definitions and Via Specifications.

If the layerFunctions class is not defined in CDB, mask numbers and function of layers are mapped according to the viaLayers section. See Mask/Layer Functions.

Equivalent Layers

In the Virtuoso environment, the technology file continues to support layers which are considered equivalent in the equivalentLayers() construct in the layerRules() section of the technology file. This section is used to define different layer purpose pairs which represent the same type of material. However, this section can be used to define layers which connect by overlap instead of through a via. An example of this is local interconnect layers such as where li connects directly to metal1 and Vdd is a layer which has the same mask number as metal1.

Translation of Technology File Stream Rules

Translation rules in your CDB technology file are written to a separate layer mapping file called libName.layermap, located in the same directory as the technology file, in the Virtuoso environment format shown above.

In CDB, stream translation rules can exist in both the technology file and in one or more separate layer mapping files (for different vendors or customers). CDB does not have a convention for naming layer mapping files.

When creating the stream layer mapping file from the technology file, check both layer mapping files and delete or rename them as required to ensure that you are using the correct stream layer rules in the Virtuoso Studio design environment version of the library.

Differences Between PIPO and XStream

For information about the differences in the functionality and use model of PIPO and XStream, see Migrating from PIPO to XStream.

Mask/Layer Functions

The layerFunctions class name has been changed to functions. It is recommended that all layers have a maskNumber defined. When not set, the maskNumber attribute of a layer defaults to oacUnsetMaskNumber = 0xffffffffu.

Layer mask numbers must be fully specified. Meaning a layer set in which part of the layers have mask number set and part of them do not will not be accepted. This would include layers that are derived from iccLayers rules or prRules.

Defining the layer mask numbers in the technology file functions section, gives explicit information about which layers are adjacent to each other. Layer function are used by the extractors of applications such as the XL layout editor to determine interconnecting layers. The Create Wire command also uses the functions list to determine routing layers and adjacent vias. Specify mask numbers for all inter-connect layers in the technology file.

functions(

 ;( layer     function   [maskNumber])
;( -----      ---------------------)
( diff         "ndiff   "1   )
( ndiff        "ndiff   "2   )
( pdiff        "pdiff   "3   )
( poly         "poly    "4   )
( cont         "cut     "5   )
( m1           "metal   "6   )
( via1         "cut     "7   )
( m2           "metal   "8   )
( via2         "cut     "9   )
( m3           "metal   "10  )
( via3         "cut     "11  )
( m4           "metal   "12  )
( via4         "cut     "13  )
( m5           "metal   "14  )
) ;functions

Valid Values: cut, li, metal, ndiff, pdiff, nplus, pplus, nwell, pwell, poly, diff, recognition, other, unknown

If the layerFunctions class is not defined in CDB, mask numbers and function of layers are mapped according to the viaLayers section.

If the material number is not defined, the following layer types are grouped according to their name in the following order:

1. well
2. implant
3. diffusion
4. poly

All layers that can not be classified are specified at the end of the list or without a number.

prRules or iccRules can reset the mask numbers of layers, however the order of layers will be kept when the viaLayers section is processed.

In past releases a user defined layer property such as iccMaskNumber could be used for user defined purposes. Mask numbers are now handled with a native OpenAccess construct. To avoid conflicting information, this type of property is no longer supported and should be removed from technology data.

Layer CDB Function to OpenAccess Material Mapping

Manufacturing Resolution (layer)

layerRules(
   mfgResolutions( tx_layer g_value )
) ;layerRules

layerRules(
   layerMfgResolutions( 
   ( tx_layer g_value ) ... )
) ;layerRules

Layer Routing Grids

Previously, routing grid information was specified as a layer attribute. In the Virtuoso Studio design environment, routing grid information is specified as a constraint. See Single Layer Routing Grids.

Preferred Routing Direction

constraintGroups(
("foundry"
   routingDirections(
      (tx_layer      "horizontal")
      (tx_layer      "vertical")
      (tx_layer      "leftDiag")
      (tx_layer      "rightDiag")
      (tx_layer      "none")
   ) ;routingDirections
) ;foundry
);constraintGroups

Previously, the routing directions were specified as layer attributes. In the Virtuoso Studio design environment, routing direction information is specified as a constraint. Because routers can specify an override to the default preferred routing direction within a defined region, the routing direction information specified as a constraint meets this requirement of routers.

Current Density Rules

The current density rules in the electricalRules section of the CDB technology file are mapped to attributes of a layer in the Virtuoso environment.

Peak AC Current Density

layerRules(
   currentDensity(
      ( peakACCurrentDensity tx_layer g_value )
      ...
      ) ;currentDensity
   currentDensityTables(
      ( peakACCurrentDensity tx_layer
      ( ("frequency" nil nil ["width"|"cutArea" nil nil] )
          [g_defaultValue ] )
      ( g_table )
      ...
       );peakACCurrentDensity 
   ) ;currentDensityTables
) ;layerRules

electricalRules( 
   tableCharacterizationRules( 
      ("ACCURRENTDENSITY PEAK" tx_layer
      ( "FREQUENCY"  (g_freqValue1 g_freqValue2...)   nil ) 
      "WIDTH" (g_widthValue1 g_widthValue2 )... nil
      ( g_table ) 
      )   
   ) 
) 

electricalRules( 
   tableCharacterizationRules( 
      ("peakACCurrentDensity" tx_layer
      ( "FREQUENCY"  (g_freqValue1 g_freqValue2...)   nil ) 
      "WIDTH" (g_widthValue1 g_widthValue2 )... nil
      ( g_table ) 
      )   
   ) 
) 

The LEF AC and DC current density in routing layers were mapped to the tableCharacterizationRules subsection in the electricalRules section of the technology file. 

Average AC Current Density

layerRules(
   currentDensity(
      ( avgACCurrentDensity tx_layer g_value )
      ...
   ); currentDensity
   currentDensityTables(
      ( avgACCurrentDensity tx_layer
      ( ("frequency" nil nil ["width"|"cutArea" nil nil] )
          [g_defaultValue ] )
      ( g_table )
      ...
       ) ;avgACCurrentDensity
   ) ;currentDensityTables
) ;layerRules

electricalRules( 
   tableCharacterizationRules( 
      ("ACCURRENTDENSITY AVERAGE" tx_layer
      ( "FREQUENCY"  (g_freqValue1 g_freqValue2...)   nil ) 
      "WIDTH" (g_widthValue1 g_widthValue2 )... nil
      ( g_table ) 
      )   
   ) 
)

electricalRules( 
   tableCharacterizationRules( 
      ("avgACCurrentDensity" tx_layer
      ( "FREQUENCY"  (g_freqValue1 g_freqValue2...)   nil ) 
      "WIDTH" (g_widthValue1 g_widthValue2 )... nil
      ( g_table ) 
      )   
   ) 
) 

RMS AC Current Density

layerRules(
   currentDensity(
      ( rmsACCurrentDensity tx_layer g_value )
      ...
   ); currentDensity
   currentDensityTables(
      ( rmsACCurrentDensity tx_layer
      ( ("frequency" nil nil ["width"|"cutArea" nil nil] )
          [g_defaultValue ] )
      ( g_table )
      ...
       ) :rmsACCurrentDensity
   ) ;currentDensityTables
) ;layerRules

electricalRules( 
   tableCharacterizationRules( 
      ("ACCURRENTDENSITY RMS" tx_layer
      ( "FREQUENCY"  (g_freqValue1 g_freqValue2...)   nil ) 
      "WIDTH" (g_widthValue1 g_widthValue2 )... nil
      ( g_table ) 
      )   
   ) 
) 

electricalRules( 
   tableCharacterizationRules( 
      ("rmsACCurrentDensity" tx_layer
      ( "FREQUENCY"  (g_freqValue1 g_freqValue2...)   nil ) 
      "WIDTH" (g_widthValue1 g_widthValue2 )... nil
      ( g_table ) 
      )   
   ) 
) 

Average DC Current Density

layerRules(
   currentDensity(
      ( avgDCCurrentDensity tx_layer g_value )
      ...
   ); currentDensity
   currentDensityTables(
      ( avgDCCurrentDensity tx_layer 
      ( ("frequency" nil nil ["width"|"cutArea" nil nil] )
          [g_defaultValue ] )
      ( g_table )
      ...
       ) ;avgDCCurrentDensity
   ) ;currentDensityTables
) ;layerRules

electricalRules( 
   tableCharacterizationRules( 
      ("DCCURRENTDENSITY AVERAGE" tx_layer
      ( "FREQUENCY"  (g_freqValue1 g_freqValue2...)   nil ) 
      "WIDTH" (g_widthValue1 g_widthValue2 )... nil
      ( g_table ) 
      )   
   ) 
) 

electricalRules( 
   tableCharacterizationRules( 
      ("avgDCCurrentDensity" tx_layer
      ( "FREQUENCY"  (g_freqValue1 g_freqValue2...)   nil ) 
      "WIDTH" (g_widthValue1 g_widthValue2 )... nil
      ( g_table ) 
      )   
   ) 
) 

Cut Classes

For more information, see cutClasses in Virtuoso Technology Data ASCII Files Reference.

layerRules(
   cutClasses(
   [t_constraint_group_name]
   ; ( layer (className    ['numCuts numCuts]   ['minWidth] ['minLength]
   ; (width length) )... )
   ;( ----------------------------------------------------------------- )
     (lx_cutLayer (tx_name ['numCuts g_numCuts] ['minWidth] ['minLength]
      g_width | (g_width g_length))... )
   ) ;cutClasses
) ;layerRules

CUTCLASS className WIDTH viaWidth [LENGTH viaLength] [CUTS numCut];

Conversion of Technology File physicalRules Class

Translation Processes

The Virtuoso Studio design environment converts DFII on CDB technology file rules to constraints during any of the following processes:

• loading (compilation) of an ASCII technology file
• automatic updating performed by the software on already-loaded technology libraries to keep them up to date with the latest OpenAccess software

Mapping CDB Physical Technology File Rules to OpenAccess Constraints

Technology file constraints in the Virtuoso environment are designed to be interoperable with rule definitions on other applications on OpenAccess. In order to be interoperable, OpenAccess supports a set of well defined constraints and constraint definitions. For example, when correctly defined, the constraint minArea is a one layer constraint. If you attempt to defined minArea with two layers rather than one, the definition is inconsistent with the OpenAccess constraint definition.

There are several situations that can occur when mapping CDB technology file rules.

CDB Rules with Proper Syntax and Name

CDB Rules with Proper Syntax and Mapped Rule Name

CDB Rules with Proper Name and Incorrect Syntax

CDB Rules with a Unique Name

CDB Rules Using Layer Purpose Pairs

CDB Rules that are no Longer Supported

CDB Rules with Proper Syntax and Name

In this situation, the CDB rule name and definition comply with the OpenAccess definition of a constraint. These rules map correctly to OpenAccess constraint definitions and are interoperable with other applications on OpenAccess.

CDB Rules with Proper Syntax and Mapped Rule Name

In this situation, the CDB rule definition complies with the OpenAccess definition of a constraint and the rule name has been supported in past releases. For example, minEnclosedArea and minHoleArea were both used to specify the minimum area size limit for metal that enclosed an empty area. These rules names are mapped to the proper constraint name minHoleArea when compiling, or dumping and re-loading a technology file and are interoperable with other applications on OpenAccess. Names of rules that were previously used in the CDB technology data are listed in the mapping tables for each constraint.

If the CDB rule that is being mapped is an LPP rule, the name is mapped to the OpenAccess constraint name, but is only available for Virtuoso applications. See CDB Rules Using Layer Purpose Pairs.

CDB Rules with Proper Name and Incorrect Syntax

These are CDB rules that do not follow the OpenAccess constraint definition but have the same name as the OpenAccess constraint. These rules will not be mapped. For example, when correctly defined, the constraint minArea is a one layer constraint. If you attempt to defined minArea with two layers rather than one layer, the CDB rule definition is inconsistent with the OpenAccess constraint definition and the rule will fail to map or translate to the technology file.

In the Virtuoso Studio design environment, it is important in terms of sharing code across releases and databases that you define constraints/rules using the proper name, and definition.

CDB Rules with a Unique Name

These are CDB rules that have a unique name and can not be mapped to an OpenAccess constraint. These rules are stored as user defined constraints. These user defined constraints will only be accessible to Virtuoso applications and are not interoperable with other tools. User defined constraints are preserved in order to prevent Pcell code from breaking. These constraints are grouped in a separate section below the OpenAccess constraints. For example, the user defined spacing rule, minMosWidth, is defined as:

constraintGroups(
( "foundry"
;physical constraints
   spacings(
   ( minSpacing "METAL1" 0.2)
   ) ;spacings
   spacings(
   ( minMosWidth "METAL1" 0.3)
   ) ;spacings
) ;foundry
) ;constraintGroups

CDB Rules Using Layer Purpose Pairs

OpenAccess rules/constraints are only applicable to layers, not layer purpose pairs. Technology rules that use layer purpose pairs are stored as a private extension and are only available for Virtuoso applications.÷š

constraintGroups(
( "foundry"
;physical constraints
   spacings(
   ( minSpacing ("metal1" "drawing" ) 2.9 ) )
   ) ;spacings
   spacings(

In the example below, two CDB rules are mapped to the same constraint name. See CDB Rules with Proper Syntax and Mapped Rule Name. Since these specific rule names are mapped to the proper OpenAccess constraint name minSameNetSpacing, two constraints are created because they are LPP rules.

CDB rules:

constraintGroups(
( "foundry"
;physical constraints
   spacings(
   ( minStepEdgeLength ("metal1" "drawing" ) 2.9 ) )
   ( minEdgeLength ("metal1" "drawing" ) 1.9 ) )
   ) ;spacings
   spacings(

After translation to OpenAccess:

constraintGroups(
( "foundry"
;physical constraints
   spacings(
   ( minSameNetSpacing ("metal1" "drawing" ) 2.9 ) )
   ( minSameNetSpacing ("metal1" "drawing" ) 1.9 ) )
   ) ;spacings
   spacings(

A work-around is to remove duplicate rules such as these, is to dump the translated ASCII file and re-load the file. This will eliminate the duplicates. However, re-loading the technology file can cause the rules to be re-ordered.

After translation to OpenAccess:

constraintGroups(
( "foundry"
;physical constraints
   spacings(
   ( minSameNetSpacing ("metal1" "drawing" ) 2.9 ) )
   ( minSameNetSpacing ("metal1" "drawing" ) 1.9 ) )
   ) ;spacings
   spacings(

After dump and re-loading the technology file only one minSameNetSpacing remains.

constraintGroups(
( "foundry"
;physical constraints
   spacings(
   ( minSameNetSpacing ("metal1" "drawing" ) 1.9 ) )
   ) ;spacings
   spacings(

The CDB technology file is essentially defining the same rules with different values. In this situation, different rules could potentially be referenced in CDB and OpenAccess by applications such as DRD. Always check the technology file after translation for duplicate rules with the same value.

CDB Rules that are no Longer Supported

The only constraint names that can be mapped to an OpenAccess constraint are those listed in “Supported Constraints”. CDB rules that are no longer supported are treated as user defined rules and stored in Virtuoso private storage. See “User Defined Constraints” for more information.

Supported Constraints

The mapping of CDB rules to the Virtuoso Studio design environment constraints can be found in the code installDir/dfII/group/techfile/src/gnTechRules/techRuleMap.cpp

Mapping Table Conventions

The following table describes the naming conventions used in mapping the CDB rules to the Virtuoso Studio design environment technology file constraints.

Single Layer Spacing Constraints

The following describes the mapping of the single layer rules section of the DFII on CDB technology file to the Virtuoso Studio design environment technology file.

Gate Orientation

All gates below a certain width must be created in the same orientation, horizontal or vertical. This constraint applies to a derived layer that specifies the gate. If no width is specified, the constraint applies to gates of any width.

constraintGroups(
("foundry"
   spacings( 
      ( gateOrientation tx_derivedLayer 'width g_width "horizontal" )
      ( gateOrientation tx_derivedLayer 'width g_width "vertical" )
      ( gateOrientation tx_derivedLayer 'width g_width "any" )
   );spacings 
) ;foundry
) ;constraintGroups

NA

Minimum Gate Extension Constraint

This constraint specifies the poly gate extension over diffusion when an L-shaped oxide is within a given distance. For more information, see minGateExtension in Virtuoso Technology Data ASCII Files Reference.

constraintGroups(
("foundry"
   orderedSpacings( 
      ( minGateExtension tx_layer1 tx_layer2 'distance g_distance
       'length g_length g_extension )
   );orderedSpacings 
) ;foundry
) ;constraintGroups

NA

Minimum Perimeter Constraint

This constraint specifies the perimeter of a shape. For more information, see minPerimeter in Virtuoso Technology Data ASCII Files Reference.

constraintGroups(
("foundry"
   spacings(
      ( minPerimeter tx_layer g_perimeter )
   ) ;spacings
) ;foundry
);constraintGroups

Minimum Area Constraint

constraintGroups(
("foundry"
   spacings( 
      ("minArea" tx_layer g_area)
      ...
   );spacings 
) ;foundry
) ;constraintGroups

physicalRules(
   spacingRules( 
      ("minArea" tx_layer g_area)
   ) ;spacingRules
);physicalRules

Minimum Area Edge Length Constraint

This constraint specifies the perimeter of a shape. For more information, see minAreaEdgeLength in Virtuoso Technology Data ASCII Files Reference.

constraintGroups(
("foundry"
   spacings( 
     (minAreaEdgeLength tx_layer
       ['exceptEdgeLength g_length]
       ['exceptMinSize (g_width g_length)]]
       g_area)
   );spacings
);foundry
);constraintGroups

AREA minArea [
  [EXCEPTEDGELENGTH edgeLength]
  [EXCEPTMINSIZE minWidth minLength];

Minimum Size Constraint

constraintGroups(
("foundry"
   spacings( 
      ("minSize" tx_layer (g_width g_length) [ ( g_width g_length ) ...] )
      ...
   );spacings
);foundry
);constraintGroups

physicalRules(
   spacingRules( 
      ("minSize" tx_layer (g_width g_length) )
   );spacingRules
);physicalRules

Minimum Enclosed Area (Hole) Constraint

constraintGroups(
("foundry"
   spacings( 
      "minHoleArea" tx_layer g_area)
      ...
   );spacings
);foundry
);constraintGroups

constraintGroups(
("foundry"
   spacingTables( 
      ("minHoleArea" tx_layer 
         ( ("edge2edgeWidth" nil nil) [ g_defaultValue ])
         (l_table)
      )
   );spacingTables
);foundry
);constraintGroups

physicalRules(
   spacingRules( 
      ("minHoleArea" tx_layer g_area)
   );spacingRules
);physicalRules

physicalRules(
   spacingRules( 
      ("minEnclosedArea" tx_layer g_area)
   );spacingRules
);physicalRules

physicalRules(
   tableSpacingRules( 
      ("minEnclosedArea" tx_layer)
      ("width" nil nil) 
      (l_table)
   );tableSpacingRules
);physicalRules

Minimum Enclosed Area (Hole) Width Constraint

constraintGroups(
("foundry"
   spacings( 
      ("minHoleWidth" tx_layer g_width)
      ...
   );spacings
);foundry
);constraintGroups

constraintGroups(
("foundry"
   spacingTables( 
      ("minHoleWidth" tx_layer 
      ( ("edge2edgeWidth" nil nil) [ g_defaultValue ] )
      (l_table)
      )
   );spacingTables
);foundry
);constraintGroups

physicalRules(
   spacingRules( 
      ("minHoleWidth" tx_layer g_width)
   );spacingRules
);physicalRules

Minimum Cut Class Spacing

For more information, see minCutClassSpacing in Virtuoso Technology Data ASCII Files Reference.

For the same cut layer, there can be up to two minCutClassSpacing constraints defined, one with either 'sameNet or 'sameMetal and the other constraint without the 'sameNet or ‘sameMetal. Only viaSpacing, minParallelWithinViaSpacing and minSameMetalSharedEdgeViaSpacing cut spacing constraints should be used in conjunction with the minCutClassSpacing constraint.

constraintGroups(
("foundry"
   spacingTables( 
      (minCutClassSpacing tx_cutLayer
      ( ( “cutClass” (g_index...) nil “cutClass” nil|(g_index...) nil)
      ['sameNet|'sameMetal] ['paraOverlap [g_overlap]] [g_default])
      (g_table)
      )
   );spacingTables
);foundry
);constraintGroups

SPACINGTABLE [DEFAULT defaultCutSpacing]
  [SAMENET|SAMEMETAL] [CENTERTOCENTER {{className1|ALL} TO {className2|ALL}}...]
  CUTCLASS
    {{className1|ALL} [SIDE|END]}...
    {{className2|ALL} [SIDE|END] {-|cutSpacing}{-|cutSpacing}...}...;

Minimum Cut Class Clearance

For more information, see minCutClassSpacing in Virtuoso Technology Data ASCII Files Reference.

constraintGroups(
("foundry"
   spacingTables( 
      (minCutClassSpacing tx_cutLayer1 tx_cutLayer2
      ( ( “cutClass” (g_index...) nil “cutClass” (g_index...) nil)
      ['sameNet|'sameMetal] ['paraOverlap [g_overlap]] [g_default])
      (g_table)
      )
   );spacingTables
);foundry
);constraintGroups

SPACINGTABLE [DEFAULT defaultCutSpacing]
  [SAMENET|SAMEMETAL]
  LAYER secondLayerName
  [CENTERTOCENTER {{className1|ALL} TO {className2|ALL}}...]
  CUTCLASS
    {{className1|ALL} [SIDE|END]}...
    {{className2|ALL} [SIDE|END] {-|cutSpacing}{-|cutSpacing}...}...;

Minimum Density Constraint

constraintGroups(
("foundry"
   spacings( 
      ("minDensity" tx_layer g_density)
      ...
   );spacings
);foundry
);constraintGroups

constraintGroups(
("foundry"
   spacingTables( 
      ("minDensity" tx_layer 
      ( ("step" nil nil) [ g_defaultValue ] )
      (g_table)
      )
   );spacingTables
);foundry
);constraintGroups

physicalRules(
   spacingRules( 
      ("minDensity" tx_layer g_density)
   );spacingRules
);physicalRules

physicalRules(
   spacingRules( 
      ("minimumDensity" tx_layer g_density)
   );spacingRules
);physicalRules

Maximum Density Constraint

constraintGroups(
("foundry"
   spacings( 
      ("maxDensity" tx_layer g_density )
       ...
   );spacings
);foundry
);constraintGroups

constraintGroups(
("foundry"
   spacingTables( 
      ("maxDensity" tx_layer 
         ( 
         ( ("step" nil nil) [ g_defaultValue ] )
         (l_table)
         )
      )
   ) ;spacingTables
);foundry
);constraintGroups

physicalRules(
   spacingRules( 
      (maxDensity tx_layer g_density)
   );spacingRules
);physicalRules

physicalRules(
   spacingRules( 
      (maximumDensity tx_layer g_density)
   );spacingRules
);physicalRules

Minimum Step Edge Length Constraint

constraintGroups(
("foundry"
   spacings( 
      ("minStepEdgeLength" tx_layer [g_lengthSum] g_length) )
      ...
   );spacings
);foundry
);constraintGroups

physicalRules(
   spacingRules( 
      ("minEdgeLength" tx_layer [g_lengthSum] g_length) )
   );spacingRules
);physicalRules

physicalRules(
   spacingRules( 
      ("minStep" tx_layer g_length)
   );spacingRules
);physicalRules

Minimum Diagonal Edge Length Constraint

constraintGroups(
("foundry"
   spacings( 
      ("minDiagonalEdgeLength" tx_layer g_length)
      ...
   );spacings
);foundry
);constraintGroups

physicalRules(
   spacingRules( 
      ("minDiagonalEdgeLength" tx_layer g_length)
   );spacingRules
);physicalRules

Manhattan Corner Enclosure or Spacing Constraint

Spacing constraints define a minimum spacing at any angle around a particular shape. This means that the spacing halo round a shape is an arc at the corner as defined in figure A. Constraints have been enhanced to support a larger spacing at the corners and define the spacing as the manhattan distance from the corner as defined in figure B.

constraintGroups(
("foundry"
   spacings(
      ( minSpacing tx_layer g_spacing ['manhattan] )
   ) ;spacings
   orderedSpacings(
      ( minEnclosure tx_layer1 tx_layer2 g_enclosure ['manhattan] )
      ( minSpacing tx_layer1 tx_layer2 g_spacing ['manhattan] )
   ) ;orderedSpacings
   spacingTables(
       ("minSpacing" tx_layer1 [tx_layer2]
      (("width" nil nil ["length" nil nil] ))
       ( g_table )
      ['manhattan] )
   ) ;spacingTables
) ;foundry
);constraintGroups

Minimum Spacing Constraint

This constraint specifies the minimum spacing between any two adjacent geometries on a specified layer. The spacing can be measured either in manhattan or euclidean metric (see Manhattan Corner Enclosure or Spacing Constraint). The value of the constraint can be based either on the width of the wider of the two shapes, on the width of the wider of the two shapes plus their parallel run length, on the width of both the shapes, or on the width of both the shapes plus their parallel run length. An optional parameter determines the spacing direction, horizontal or vertical, in which the constraint applies. Another optional parameter determines whether the constraint applies to power and ground nets.

constraintGroups(
("foundry"
   spacings( 
      ( minSpacing tx_layer ['horizontal | 'vertical | 'any]         ['sameNet ['PGNet] | 'sameMetal] g_space 

        ['manhattan] )
      ...
   ) ;spacings
) ;foundry
)

constraintGroups(
("foundry"
   spacingTables( 
      ( minSpacing tx_layer 
         ( ("width" nil nil ["length"|"width" nil nil] ) ['horizontal |            'vertical | 'any] ['sameNet ['PGNet] | 'sameMetal]              [g_defaultValue] )
             (g_table)
             ['soft | 'hard] ['coincidentAllowed] ['manhattan] ['ref t_ref]
             ['description t_description]
      )
      ( minSpacing tx_layer 
         ( ("twoWidths" nil nil "length" nil nil) ['horizontal |            'vertical | 'any] ['sameNet ['PGNet] | 'sameMetal]              [g_defaultValue] )
             (g_table) ['manhattan]
      )
      )
   ) ;spacingTables
) ;foundry
) ;constraintGroups

Minimum Center Spacing Constraint

constraintGroups(
("foundry"
   spacings( 
      ("minCenterToCenterSpacing" tx_layer g_value)
      ...
   );spacings
);foundry
);constraintGroups

physicalRules(
   spacingRules( 
      ("minCenterToCenterSpacing" tx_layer g_value)
   );spacingRules
);physicalRules

Minimum Diagonal Spacing Constraint

constraintGroups(
("foundry"
   spacings( 
      ("minDiagonalSpacing" tx_layer g_value)
      ...
   );spacings
);foundry
);constraintGroups

constraintGroups(
("foundry"
   spacingTables( 
      ("minDiagonalSpacing" tx_layer 
         (
         ( ("width" nil nil ["length" nil nil] ) [ g_defaultValue ])
         (l_table)
         )
      )
   );spacingTables
);foundry
);constraintGroups

physicalRules(
   spacingRules( 
      ("minDiagonalSpacing" tx_layer g_value)
   );spacingRules
);physicalRules

Minimum Diagonal Width Constraint

constraintGroups(
("foundry"
   spacings( 
      ("minDiagonalWidth" tx_layer g_width)
      ...
   );spacings
);foundry
);constraintGroups

physicalRules(
   spacingRules( 
      ("minDiagonalWidth" tx_layer g_wdith)
   );spacingRules
);physicalRules

Minimum Different Potential Spacing Constraint

constraintGroups(
("foundry"
   spacings( 
      ("minDiffNetSpacing" tx_layer g_value)
      ...
   );spacings
);foundry
);constraintGroups

physicalRules(
   spacingRules( 
      ("minDiffNetSpacing" tx_layer g_value)
   );spacingRules
);physicalRules

Minimum Space between Fill Pattern and Real Design Object Constraint

constraintGroups(
("foundry"
   spacings( 
      ("minFillToShapeSpacing" tx_layer g_value)
      ...
   );spacings
);foundry
);constraintGroups

physicalRules(
   spacingRules( 
      ("minFillToShapeSpacing" tx_layer g_value)
   );spacingRules

physicalRules(
   spacingRules( 
      ("fillActiveSpacing" tx_layer g_value)
   );spacingRules
);physicalRules

Minimum Proximity (Influence) Spacing Constraint

Constraint name: minInfluenceSpacing

constraintGroups(
("foundry"
   spacings( 
      ("minInfluenceSpacing" tx_layer g_value)
      ...
   );spacings
);foundry
);constraintGroups

constraintGroups(
("foundry"
   spacingTables( 
      ("minInfluenceSpacing" tx_layer
         (
         ("width" nil nil ["distance" nil nil] ) [ g_defaultValue ] )
         (l_table)
         )
      )
   )
);foundry
);constraintGroups

physicalRules(
   tableSpacingRules( 
      ("minInfluenceSpacing" tx_layer )
      ("width" nil nil ["distance" nil nil])
      (l_table)
   );tableSpacingRules
);physicalRules

Minimum Proximity (Influence) Spacing Constraint for Protruding Wires or Stubs

constraintGroups(
("foundry"
   spacings( 
      ("minStubInfluenceSpacing" tx_layer g_spacing
      ...
   );spacings
);foundry
);constraintGroups

constraintGroups(
("foundry"
   spacingTables( 
      ("minStubInfluenceSpacing" tx_layer
         (
         ( ("width" nil nil ["distance" nil nil] ) ) 
         (g_table)
         )
      )
   ) ; spacingTables
);foundry
);constraintGroups

physicalRules(
   spacingRules( 
      ("minStubInfluenceSpacing" tx_layer g_value)
   );spacingRules
);physicalRules

physicalRules(
   spacingRules( 
      ( minSpacingRange   tx_layer ("minSpacingValue RANGE minWidth maxWidth INFLUENCE infvalue")
   ) ;spacingRules
) ;physicalRules

Minimum Spacing Constraint (sameNet)

Constraint name: minSameNetSpacing

constraintGroups(
("foundry"
   spacings( 
      ("minSameNetSpacing" tx_layer g_value)
      ...
   spacingTables( 
      ( "minSameNetSpacing" tx_layer
      (( "width" nil nil ))
      ( g_table )
      )
   ) ;spacingTables

   );spacings
);foundry
);constraintGroups

physicalRules(
   spacingRules( 
      ("minSameNetSpacing" tx_layer g_value)
   )
)

physicalRules(
   spacingRules( 
      ("minNotch" tx_layer g_value)
   );spacingRules
);physicalRules

physicalRules(
   spacingRules( 
      ("sameNet" tx_layer g_value)
   );spacingRules
);physicalRules

Minimum Adjacent Via Spacing Constraint

This constraint specifies the required minimum distance between adjacent via cuts and depends on the number of adjacent cut shapes within the specified distance. A via cut is adjacent if it is within the specified distance from another cut in any direction including a 45-degree angle. Optional parameters can be used to determine the following:

• Whether the cut spacing is to be measured edge-to-edge or center-to-center
• Whether the constraint applies to shapes having any connectivity, to shapes having only same-net connectivity, or only to cut shapes on the same metal
• Whether the constraint applies to vias on power and ground nets

The constraint can optionally apply only if the cut shapes are either on the same net or are overlapped by the same metal shape or are overlapped by the same metal shape above and below which cover the overlap area between the cuts. The number of neighboring cuts can also be specified.

This constraint supports 32 nm design rules. The cutClass constraint must be defined before this constraint. For more information, see viaSpacing in Virtuoso Technology Data ASCII Files Reference.