OpenAccess 22.04.007 Source Code and Documentation Release

Contents

• Compatibility with Earlier Releases
• Changes and New Features
• API Changes
• Fixed Problems
• Incomplete Status

Note: Release notes for previous versions of OpenAccess are available in the Archived OpenAccess Release Notes document.

This is the first release of data model revision 4.

Refer to the Features by Data Model document for a full list of the features included in each data model revision of OpenAccess.

New functions were added to this release, so the oacAPIMinorRevNumber was incremented to 35.

Refer to Compatibility for OpenAccess Applications and Data for more information about oacDataModelRevNumber and oacAPIMinorRevNumber changes.

The release includes the following:

• Versioning Changes for OpenAccess
• Detecting the Data Model Revision and Features for Databases
• New Value Types
• New and Updated Constraints
• Purpose Aware Constraints
• Constraint Parameters
• Constraint Group Definitions (oaConstraintGroupDefs)
• Defining Routing Blockages, Blockage Spacing, and Fill Shapes
• Technology Database Enhancements
• Group Definitions (oaGroupDefs)
• Via Variants (oaViaVariants)
• New pinType Attribute on oaPin
• Miscellaneous Changes
• Build and Link Process Changes
• OpenAccess Translators

The versioning mechanism for OpenAccess has been enhanced to include information about the data model revision. The new version numbering uses this format:

xx.yy.zzz 

Where:

• xx is the major revision number, as in OpenAccess 22
  
• yy is the data model revision number, such as data model revision 4
  
• zzz is the build number, such as 001
  

The current OpenAccess release is named OpenAccess 22.04.007.

OpenAccess now provides functions for determining which features are present in a database that is in memory. An application can call one of the getFeatures functions, which return an array of oaFeature object pointers. The application can then iterate through the array to get the ID for each feature present. Each feature ID corresponds to an oaFeatureIDEnum value. The getFeatures functions also return the minimum data model revision of the database based on the features it includes.

• oaDMData::getFeatures
• oaDesign::getFeatures
• oaTech::getFeatures
• oaWafer::getFeatures

OpenAccess also provides an oaFeature:getDataModelRev function to get the data model revision number for a particular feature.

The following new value types are defined:

• oaIntRangeArrayValue
• oaIntRangeArray1DTblValue
• oaIntRangeArray2DTblValue
• oaStringValue
• oaViaTopologyArrayValue
• oaViaTopology2DTblValue
• oaPurposeValue

This release includes the following new constraints that support routing for 45 and 65 nanometer processes.

In addition, the following constraints have been updated to support routing for 45 and 65 nanometer processes.

New Examples for Constraints

Two new code examples demonstrate how to work with constraints, derived layers, constraint groups, and groups. These examples are located in <install_dir>/examples/oa/.

The Constraints1 example demonstrates how to:

• Create a constraint and add it to an oaConstraintGroup
• Create a custom oaConstraintDef
• Create oaConstraintGroups with AND and OR semantics
• Create derived layers
• Create constraints and derived layers that are scoped to a particular purpose

The Constraints2 example demonstrates how to:

• Create a differential pair including reflexive and transreflexive constraints and associated connectivity and groups
• Create a shielding oaConstraintGroup and associated connectivity and constraints
• Create a taper oaConstraintGroup and associated connectivity and constraints

The Constraints2 example also includes a constraint traverser/checker that demonstrates the constraint scoping and precedence rules.

Some foundries and applications apply different constraints to the shapes on a layer depending on the shape purpose. For example, shapes with the fill purpose might require a different minimum spacing than the minimum spacing required between shapes with the drawing purpose on the same layer.

In OpenAccess, all layers associated with constraints can now be further scoped to a purpose. Applications can limit the scope of a layer-based constraint to shapes with a specific purpose by creating a constraint with both layers and purposes. The oaLayerConstraint, oaLayerArrayConstraint, and oaLayerPairConstraint classes include create() functions to specify both layers and corresponding purposes. The create() functions take one or more layerNum arguments and one or more purposeNum arguments. The layer constraint classes also provide getPurpose() functions that return the purpose number or an array of purpose numbers for a constraint, and they provide find() functions that return constraints that match the specified layerNum and purposeNum arguments.

New oaPurposeArray and oaPurposeValue classes support this functionality. The oaPurposeArray class is used to create a purpose aware oaLayerArrayConstraint. The oaPurposeValue is used to create a derived layer using oaSelectShapesWithPurpose.

For more information, refer to Scoping to Purpose in Creating and Modeling Process Rules and Constraints in the Programmers Guide.

New Built-In Purpose Types and Values

New built-in purpose types capture the semantics of any and no purposes, which support foundry rules that depend not only on the layer but also on the purpose of shapes. In addition, the oaFillOPC built-in purpose type specifies whether or not a fill shape requires OPC.

The Any and No purpose numbers have restricted uses. Shapes cannot be created with the Any or No purpose numbers. The No purpose can only be used when creating or finding constraints. The Any purpose can only be used when finding constraints.

Purpose numbers in the range of 0xffff0000 to 0xffffffff (inclusive) are reserved for built-in purposes. OpenAccess throws an oacPurposeNumberIsReserved exception if an application attempts to do either of the following:

• Create a user-defined purpose using a number in this range
• Set the purpose number of an existing purpose to a value in this range

If an older database is loaded by an application that uses the shared libraries from 22.04.002 or later, any missing built-in purposes are added. If a database created before 22.04.002 includes a user-defined purpose that uses a reserved purpose number, and that database is read by newer OpenAccess shared libraries, the user-defined purposes in the reserved range are removed from the database.

New Constraint Parameter Types

The following new constraint parameter types are defined.

New Constraint Parameter Value Enums

The following enums are added for use with constraint parameters:

• oaConnectivityTypeEnum
• oaShapeAngleTypeEnum
• oaSpacingDirectionTypeEnum
• oaGateOrientationType

Modified Constraint Parameter Value Enum Values

The oaWidthLengthTableTypeEnum parameter value enum is extended to include oacTwoWidthParallelRunLengthTableType.

OpenAccess provides constraint group definitions (oaConstraintGroupDefs) that specify the definitions of constraint groups (oaConstraintGroups). The constraint group definition contains a name, a type, a list of databases in which the constraint group can be created, a list of objects (by type) to which the constraint applies, 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. 

The oaDesign and oaTech databases each have getConstraintGroups() functions that take a pointer to an oaConstraintGroupDef and return a collection of oaConstraintGroups associated with the given oaConstraintGroupDef.  Alternatively, these constraint groups can be found by name using the oaConstraintGroup::find() function.

OpenAccess provides the following built-in constraint group definitions, which are specified using an oaConstraintGroupType enumeration. The built-in oaConstraintGroupDefs have oa prefixes to avoid name collisions with application-defined types.

The oaConstraintGroupDef::isBuiltIn function identifies whether or not a particular definition is one of the OpenAccess built-in definitions.

For more information about using oaConstraintGroupDefs and the built-in constraint group definitions, refer to Using Constraint Group Definitions in the Programmers Guide.

Operators for Constraint Groups

Constraint groups can be created with the following operators.

Refer to oaConstraintGroupOperator for more information.

New constructs and attributes provide more flexibility for defining routing blockages, blockage spacing, and fill shapes.

New Blockage and Halo Objects

The following new blockage and halo classes are available.

New soft Attribute on oaAreaBlockage and oaAreaHalo Objects

• The soft attribute on oaAreaBlockage specifies that standard cells should not be placed within the blockage area, but later optimization phases can use the blockage area. 
• The soft attribute on oaAreaHalo indicates that standard cells should not be placed within the halo, but later optimization phases can use the halo area.

Specifying Input Taper Rules Within a Halo

OpenAccess lets applications specify:

• How wide wires should taper down to minimum-width spaced pins.
• How wide pins should taper down to minimum-width spaced wires.

This is done with two new oaConstraintGroupTypes, oacInputTaperConstraintGroupType and oacOutputConstraintGroupType. The oacTaperHalo constraint lets applications specify a halo around the figures of a pin in which tapering should be performed (according to the spacing and width constraints specified in a taper constraint group).

Refer to Using Taper Constraint Group Definitions in the Creating and Modeling Process Rules and Constraints document in the Programmers Guide for more information.

New Process Family information for Technology Databases

Foundries often use sets of technology databases where each set corresponds to a process base and its variants. It is important to distinguish one set of databases for one process from sets for other processes. OpenAccess includes an API to designate the processFamily attribute for a database.

New APIs on oaTech let applications set, query, and unset the processFamily attribute for a technology database.

getProcessFamily(oaString &processFamily) const 
hasProcessFamily() const 
setProcessFamily(const oaString &processFamily) 
unsetProcessFamily() 

The getProcessFamily and hasProcessFamily functions operate across a graph of referenced technology databases by default. The setProcessFamily and unsetProcessFamily functions operate on the local technology database.

An oacConflictingProcessFamilyInTech exception is thrown if you attempt to set the processFamily attribute on a technology database that is part of a graph of technology databases in which one of the other tech databases already has this attribute set to a different value. In addition, the following observer notification is triggered when a mismatched processFamily attribute value is detected in a graph of techs.

virtual void oaObserver<oaTech>::onProcessFamilyConflict(const oaTechArray &conflictedTechs)  

Excluding Incompatible Layers

Layers can be excluded by name from a graph of technology databases. This capability provides safeguards to ensure that a graph of technology databases does not have inadvertent references to incompatible layers.

The following APIs support the layer exclusion capability.

For more information, refer to Excluding Incompatible Layers in the Programmers Guide.

oaLayer::setNumber and oaPurpose::setNumber Changes

When an application uses oaLayer::setNumber to modify a layer's number, OpenAccess now unbinds the layer from old layer and LPP headers in all the designs that bind to the layer's oaTech and binds the layer to existing layer and LPP headers with the new number in those designs. The function also destroys any derived layers, sized layers, oaViaDefs or oaViaSpecs in the same oaTech that is dependent on this layer. The dependent objects are destroyed because they are bound to the layer by number. When the layer number changes, the binding is no longer valid. (Previously, layers and vias that were derived from the modified layer were preserved.)

When an application uses oaPurpose::setNumber to modify the purpose number of an oaPurpose, OpenAccess now unbinds the purpose from the old LPP header in the designs that are bound to the layer's oaTech and binds the purpose to existing LPP headers with the new number in those designs.

OpenAccess provides an oaGroupDef object that specifies the definition of an oaGroup.

An application can use the oaFlatGroupDef class to specify that a group includes only a specified set of objects, excluding other groups. The oaHierGroupDef class lets an application specify that a group can contain a mixture of objects and groups, or only groups. The oaHierGroupDef object can be unrestricted, meaning that groups of any type can be included. A restricted oaHierGroupDef object can contain only groups of a specific type (as specified by an oaGroupDef).

The oaDesign, oaTech, oaDM, and oaLib databases have getGroups functions that return collections of groups that are associated with a given oaGroupDef.

OpenAccess supports several built-in group definitions, which are defined in the following table. The built-in group definition enums are on the oaGroupPurposeType Class Reference page in the API documentation. The built-in oaGroupDefs have oa prefixes to avoid name collisions with application-defined types.

The oaGroupDef::isBuiltIn functions let applications determine if a particular definition is one of the OpenAccess built-in definitions.

For more information about oaGroupDefs, refer to Using Group Definitions in the Programmers Guide.

Applications can now store predefined parameterizations of oaStdVias and oaCustomVias as via variants (oaViaVariants). An oaViaVariant object represents a named pairing of an oaViaDef reference and a fully specified set of via parameters.

For more information, refer to Representing Vias in OpenAccess in the Programmers Guide.

oaCustomVia and oaStdVia Binding Issues Resolved

In previous releases, it was possible, though incorrect, to bind an oaStdVia to an oaCustomViaDef. The following actions caused the incorrect binding:

• An oaStdViaDef was created, and an oaStdVia was created with that oaStdViaDef.
• The oaStdViaDef was destroyed.
• An oaCustomViaDef was created with the same name as the destroyed oaStdViaDef.

The oaStdVia would be incorrectly bound to the oaCustomViaDef because the binding was done by oaViaDef name. The same could occur for the case of an oaCustomVia and an oaStdViaDef.

In the current release, the incorrect binding described above will no longer occur in this situation, and no exception will be thrown. The incorrect binding is also prevented for oaViaTopologyArrayValues and oaViaDefArrayValues that would potentially include cases of this problem.

Because the binding no longer occurs, there can be a situation in which an oaStdVia is not bound and the oaStdViaHeader still exists. In this situation, if an attempt is made to create an oaCustomVia with an oaCustomViaDef with the same name as the existing oaStdViaHeader, an oacCustomViaDefSameNameasStdViaDef exception is thrown. Similarly, an oacStdViaDefSameNameasCustomViaDef exception is thrown if, in similar circumstances, an attempt is made to create an oaStdVia with an oaStdViaDef with the same name as an existing oaCustomViaHeader. The oaViaTopologyArrayValue and oaViaDefArrayValue create functions also throw these exceptions when appropriate.

A new pinType attribute on oaPin specifies the connection type for a pin:

• "none"
• "core" to indicate that the connection is to the core of the pin.
• "bump" to indicate that the connection is to the bump of the pin.

New isBuiltIn Functions

The following functions let applications determine if a particular definition is one of the OpenAccess built-in definitions.

• oaGroupDef::isBuiltIn
• oaConstraintGroupDef::isBuiltIn
• oaConstraintDef::isBuiltIn
• oaConstraintParamDef::isBuiltIn
• oaDerivedLayerDef::isBuiltIn
• oaDerivedLayerParamDef::isBuiltIn

Added oaViaParam::isEqual() API

This function compares the parameters of two oaViaParam objects. It does not compare the flags.

Note: The oaViaParameter operator== function does compare the flags and returns false if the values in one of the viaParam objects were set explicitly and the other values were left at the default even if the actual values are the same. The new isEqual function compares only the actual values and ignores the explicitness of the values.

Behavior Change for oaObserver<oaConstraint>

Observer notifications are now sent for calls to oaConstraint::setValue even if the constraint is already set to the given oaValue. This allows applications to receive oacSetValueConstraintModType pre and post modify observer notifications. In the expected use model, applications that set constraint values will call oaConstraint::setValue after every call to oaValue::set in order to trigger the appropriate observer notifications. Applications that receive observer notifications must be aware that the oaValue pointer might not actually change when an oacSetValueConstraintModType observer notification is received.

Note: Observer notifications for this kind of modification will be sent during undo and redo operations as well.

Region Query Changes

The following changes to region query are available in this release:

• The oaRegionQuery::getCurrentRegion() function has been updated. In previous versions, the returned bBox was based on the specified query region and the current transform. It is now based on the intersection of the specified query region and an instance box in the hierarchy. For example, assume an instance lies completely within the query region. When the query is producing objects in the master, the master's bBox is used as the current region.
• Support for querying the new oaLayerRangeBlockage and oaLayerRangeHalo objects has been added. There is a separate query object, oaLayerRangeBlockageQuery, for querying the layer range blockage objects independently of layer. For consistency with this, a new query object, oaPlacementBlockageQuery, has been added for querying placement blockage objects independently of layer. Applications should deprecate their usage of oaBlockageQuery::queryPlacementBlockage in favor of using oaPlacementBlockageQuery.

Cached Pcell subMasters

A new IPcellFile utility class allows applications to write and read Pcell subMaster data to and from a cache file. An application that implements a Pcell evaluator (using the IPcell interface) can use the IPcellFile functionality to write and read the contents of Pcell subMasters to and from a cache file of their choosing.

Note: An application that has an IPcell interface is not required to support cached Pcell subMasters.

For more information about cached Pcell subMasters, refer to Storing and Retrieving subMasters in How to Write a Pcell Evaluator Plug-in in the Programmers Guide.

oaDMPlugInError Class Changes

In previous versions, the FileSys DM system threw exceptions of IDMException class, which were initialized with message IDs defined in the DM package; whereas the Turbo DM system defined its own set of message IDs and message strings. In order to share message IDs, the enums for the plug-in IDs were declared in the DM package, which is inconsistent with the way other OpenAccess packages are handled.

The FileSys and Turbo DM plug-ins now only throw exceptions derived from IException. The oaDMError derived class is used to wrap any exceptions received from the DM plug-ins. This class represents an oacInterfaceException error ID, which reports a plug-in error and includes information about the originating plug-In exception.

Specifcially, in previous releases, errors originated by the DM plug-ins were converted into either oaDMPlugInExceptions or oaDMErrors. In the FileSys DM plug-in, the message ID and the error message string were those originated from the plug-in code. In the current release, all exceptions that originate from DM plug-ins are caught by DM, wrapped, and rethrown as special oaDMPlugInErrors with the message ID oacInterfaceException. The error message and the message ID from the originating DM plug-in error is embedded as part of the new DMPlugInError message.

For example, instead of throwing this exception:

The DM plug-in now throws a message such as this:

Debuggable Libraries

The OpenAccess debuggable libraries no longer contain the letter "D" as part of the library name, making it easier for developers to switch between optimized and debuggable libraries.

For example, the oaDesignD.lib debuggable library has been renamed to oaDesign.lib.

For compatibility purposes, links from the old library names to the new library names are provided in OpenAccess installations. However, these links will eventually be removed.

Compiling OpenAccess

If you compile the OpenAccess source code, you must manually delete the debug libraries with the old names from any UNIX installation, or the compilation will fail. The following will accomplish this:

gmake clean
gmake install

On the Windows platform, you must update your project file to include the new debuggable library names and re-link your program to access the new debuggable library names. In addition, it is recommended that your delete the debuggable libraries with the old names from your hierarchy.

Updates to Visual Studio 2005 Files

Visual Studio 2005 enables buffer security checking by default. The extra code added by these checks does not allow application code compiled in debug mode to be linked against optimized code where these checks have been added (this could be done with .NET 2003 optimized code). OpenAccess has updated the Visual Studio project files to disable buffer security checking in the optDLL, optStatic, and dbgStatic configurations.

To accomplish this, two new preprocessor define statements are added to the configurations mentioned above:

_SECURE_SCL=0 
_SECURE_ATL=0

These changes were made to the core OpenAccess packages, the plug-ins, oaLang, oaLefDef, oaSpef, oaStrm, and oaVerilog.

Enhanced Via Support in Stream Translator

The oa2strm translator now produces a more compact AREF-based representation of vias with large cut arrays. The strm2oa translator will also recognize such a cell as a standard via.

Refer to How Vias Map in the Stream to OpenAccess Mapping document for more information.

Optionally Building LEF/DEF Translators

If you want to build the LEF/DEF translators (which is optional), the lefdef5.7-s001 (or later) toolkit is now required.

oaLefDef API Addition (for Derived Translators)

• Changes were made to the LEF/DEF translator API to support the data model 4 constraints.
• The utility functions for attaching technology databases have been removed from oaLefDef because this functionality is now available on the oaTech class itself. Any derived translator that was using these functions in oaLefDef must use the native OpenAccess functions instead.
• The template functions for setting constraint values now take a message string so that error messages can provide more detail.
• The LEF/DEF translators now handle oaViaTopology data. The translators can store both the new oaViaVariants as well as oaViaDefs. Any derived translator must adapt to the changes in the signatures of functions.
• Blockage handling has been separated into different functions.
• The setProp functions for each type have been replaced by a single templatized version.
• The DefOutOptions class has a new checkCellType option. When set to true, only instances for which the master design has an oaCellType other than oacNoCellType or oacViaCellType are output to the DEF file.
• The LefDefOut::getGenVia function has been replaced by LefDefOut::getViaName in order to handle customVias that are pCell instances. The getViaName function generates unique names for each of the different pCell variants. Any use of the getGenVia function must be replaced by the getViaName function to get this important bug fix.

View a summary  of the OpenAccess 22.04.007 release changes with respect to the 2.2.6-p062 source code and documentation release.

Some parts of this release are still in development and are considered to be of Beta quality. They are subject to changes in their use and interface. This includes:

• Tcl interface
• Wafer database
• Tcl Pcells
• Turbo DM System

The Turbo DM System is not considered to be of production quality and is not be supported.

Return to top of page

Copyright © 2003-2006 Cadence Design Systems, Inc.
All rights reserved.