OpenAccess 2.2.6-p052 Release Notes

Contents

• Version 2.2.6-p052
• Version 2.2 P049 Source Code and Documentation Release
• Version 2.2 P045 Source Code and Documentation Release
• Version 2.2.6
• Version 2.2.5
• Version 2.2.4
• Version 2.2 P031 Source Code and Documentation Release
• Version 2.2 P028 Source Code and Documentation Release
• Version 2.2.3
• Version 2.2.2
• Version 2.2.1

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

Note: Version 2.2.6-p052 includes all changes that occurred after 2.2.6, including changes outlined in the P045 and P049 source code and documentation release notes.

The current oacDataModelRevNumber remains 3.

• The Huge Database feature was introduced in oacDataModelRevNumber 1.
• New constraints and oaFigGroups were introduced in oacDataModelRevNumber 2.
• Incremental technology databases were introduced in oacDataModelRevNumber 3.

The oacAPIMinorRevNumber remains 33.

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

Tcl Bindings for the OpenAccess API

Applications compiled with oaTcl header files prior to 2.2.6-p052 need to be recompiled with release 2.2.6-p052 or later. For more information, refer to Limitations in Tcl Bindings for the OpenAccess API for more information.

LEF 5.7 Support

The lef2oa and oa2lef translators now partially support LEF 5.7. Any LEF 5.7 constructs that have corresponding OpenAccess built-in constraints are mapped to those constraints. LEF 5.7 constructs that do not currently map to built-in constraints result in warnings in the translators. Refer to the LEF/DEF to OpenAccess Mapping documentation for information mapped constructs.

The lef2oa translator determines the LEF version based on the input file. The oa2lef translator has a -ver option for specifying the output version.

LEF/DEF Mapping

The mapping for the LEF LAYER SPACING attribute with two RANGE keywords has been fixed to also incorporate values from the SPACING attribute with a single RANGE keyword.

oaStrm API Addition (for Derived Stream Translators)

Derived translators can use StrmOut::getTextNS to access the translator namespace in order to write additional labels. Also, functions were added to oaStrm to allow the manipulation of text and statistics.

Supported Platforms and Compilers for OpenAccess Pre-Compiled Libraries

The Itanium Linux platform (AS 2.1) is no longer supported.

Building OpenAccess on Windows

You can now use Microsoft Visual Studio 2005 as well Visual Studio .NET 2003 to compile your environment on Windows. The OpenAccess solution files for Visual Studio 2005 have a  _vc8 extension in their name. For example:

• oaDynamic.sln is for Visual Studio .NET 2003
• oaDynamic_vc8.sln is for Visual Studio 2005

Refer to Optionally Compiling on the Windows Platform for more information.

Optionally Building LEF/DEF Translators

If you need to build the LEF/DEF translators (which is optional), the lefdef5.7 (or later) kits are now required.

There are no API changes in this 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
• Turbo DM System
• Tcl Pcells
• DM interface used by plug-in developers

This release includes partial support for LEF and DEF 5.7 constructs.

The oaPcellScript Plug-In is in development and is not ready for use at this time.

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

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
• Milkyway to OpenAccess Translator
• Turbo DM System
• Tcl Pcells
• DM interface used by plug-in developers

The oaPcellScript Plug-In is in development and is not ready for use at this time.

The current oacDataModelRevNumber is 3.

• The Huge Database feature was introduced in oacDataModelRevNumber 1.
• New constraints and oaFigGroups were introduced in oacDataModelRevNumber 2.
• Incremental technology databases were introduced in oacDataModelRevNumber 3.

New functions were added to this release, so the oacAPIMinorRevNumber was incremented to 33. Programs compiled with the header files in the P048 release or later cannot be used with OpenAccess shared libraries from versions prior to P048. Programs compiled with versions prior to P048 will continue to run unchanged with the shared libraries produced from the current release.

Refer to Compatibility for OpenAccess Applications and Data for more information. In addition, refer to the OpenAccess 2.2 Development Feature List for a list of the features included in each version of OpenAccess.

Potential oaAppDef Issue Resolved

Persistent application-defined data (oaAppDef data) created using versions of OpenAccess between 2.2.3 and P048 (inclusive) might be corrupted. The OpenAccess P049 release contains code to automatically repair the corruption in most cases.

In the problematic window (between 2.2.3 and P048 inclusive), an application reading an OpenAccess database using OpenAccess shared libraries that were newer than the OpenAccess shared libraries used to create the database could crash when performing the following actions:

• Deleting objects that were referred to by oaInterPointerAppDefs
• Attempting to traverse pointers stored in oaInterPointerAppDefs if one of the following was true:
  • The object pointed to by the oaInterPointerAppDef was an oaAppObject.
  • The object that owns the oaInterPointerAppDef was an oaAppObject. 

This issue was more prevalent in oaTech databases.

Note: Even though the P049 release contains code to repair the corruption, there are rare cases in which the repair process fails. If the database cannot be repaired, and the repair process failed on oaAppDef data that the application explicitly registered, an oacCannotRepairCorruptedAppData exception is thrown when the database is opened (regardless of mode). Because any application can use oaAppDefs to define persistent application-specific data, the exception is not thrown unless the application reading the database explicitly registered an oaAppObjectDef for an oaAppObject that contains un-repairable oaAppData. This means that applications can still read the database, even if some portions of it are not repairable, if they do not attempt to access the un-repairable portions.

Enhanced Model for Technology Database Attributes

In previous releases, OpenAccess reported a conflict if the default value of a technology attribute, such as DBUPerUU, conflicted with a user-specified value for the same technology attribute in a graph of incremental technology databases. Now OpenAccess can distinguish between explicitly set values and implicitly assigned default values. In a graph of technology databases, an explicitly set attribute value takes precedence over any implicitly assigned value, and there is not a conflict if they differ.

For more information, refer to Technology Database Attributes in the Programmers Guide.

oaTech::setRefs Prevents Circular References

In previous releases, it was possible to create a circular set of technology database references with oaTech::setRefs. For example:

An oacTechSetRefsCircularReference exception is now thrown if an application attempts to create a circular set of references.

Note: The oacTechCannotSetRefToSelf message ("Cannot set self as reference",) has been obsoleted because the functionality is now part of oacTechSetRefsCircularReference.

oaObserver<oaTech> Changes

In previous releases, the oaObserver<oaTech>::onFirstOpen and oaObserver<oaTech>::onPostOpenRefs observers were invoked after checks for conflicts and for unbound technology database references. These two observers are now invoked before the checks. Accordingly, the oaObserver<oaTech>::onConflict and oaObserver<oaTech>::onUnboundRef observers now appear after the onFirstOpen and onPostOpenRefs observers.

In previous releases, the oaObserver<oaTech>::onPurge observer was invoked after the graph of incremental technology databases was destroyed. This observer is now invoked before the graph of incremental technology databases is destroyed. Accordingly, the onModify observers for the oacUnbind<objectHeader>ModType now appear before the onPurge observer notification.

The Turbo and FileSys DM systems have a new attribute that can be set on read-only reference libraries to indicate that OpenAccess can always perform partial reading of the data.

There are two new exceptions related to the new DM attribute:

• oacNoWriteAccessOnReadOnlyLib is thrown when an application attempts to get write access on a library whose libReadOnly attribute is set to yes.
  
• oacCannotDestroyObjectWithCacheActive is thrown when an application attempts to destroy a DM object (oaDMFile, oaCell, oaCellView, or oaView) that has active caches.

Note: In previous releases, problems could occur when multiple users on NFS accessed the same libraries. Specifically, if a process partially read a file and left the file open, then another process wrote to that file, the reader would encounter problems on attempting to read the file again. This problem has been resolved.

Each OpenAccess translator has the following new options, which are made available by the wrapper scripts for the executables.

For more information, refer to Using OpenAccess Translators.

oa2strm Translator Changes

The oa2strm translator has new options for adding pin text (labels) to nets and terminals. In addition, there is a new option to specify the Stream format for the output file, and a new option that lets you convert path objects to polygons.

Refer to OpenAccess to Stream Translator (oa2strm) for more information about these options.

lef2oa Translator Change

The lef2oa translator issues a warning and does not use the new attribute value if the manufacturing grid or clearance measure values in the file being imported are different than the values already in the database. In previous releases, an error message was issued.

oa2verilog Can Map All tieLow or tieHigh Nets

The oa2verilog -tieLow and -tieHigh options now accept an asterisk (*) to map all tieLow or tieHigh global nets at once.

LEF/DEF API Changes

The openTech function has been removed from LefIn because it was redundant with initTechDBLocal, which provides the same functionality.

Optionally Building lef2oa or oa2lef

If you need to build the LEF translators (which is optional), the lefdefInt05.60-s024 kits are now required.

Refer to the OpenAccess Installation and Configuration Notes for more information about building the translators.

New oaAnalysisPointArray Class

The oaAnalysisPointArray class implements a utility array class used to pass an array of oaAnalysisPoint class pointers to the following function:

oaParasiticNetwork* oaParasiticNetwork::create(oaDesignObject*                 net,
                                               const oaAnalysisPointArray&     aps)  	

Note: The following function is considered deprecated:

oaParasiticNetwork* oaParasiticNetwork::create(oaDesignObject    *net, 
                                               oaUInt4           numAPs, 
                                               oaAnalysisPoint   **aps) 

New oaBuildInfoArray Class

The oaBuildInfoArray class implements a utility array class used to pass an array of oaBuildInfo pointers back to the user with the following function:

void oaBuildInfo::getPackages(oaBuildInfoArray&    packagesIn)

Note: The following function is considered deprecated:

oaBuildInfo** oaBuildInfo::getPackages()

New oaMemoryError Class

The new oaMemoryError class contains information about the exception that OpenAccess throws when it detects that a process is out of memory when oaMemory::get() or oaMemory::resize() are called. This allows an application to print a more helpful message when this error occurs.

The implementation of const APIs that do not modify the database, such as oaInstTerm::getInst() and oaTech::getDBUPerUU(), has been modified to improve performance. The const APIs in the optimized shared libraries no longer validate their arguments (including the this pointer). The non-const APIs that do modify the database, such as oaInstTerm::create() and oaTech::setDBUPerUU(), continue to validate their arguments as before.

Both the const and non-const APIs continue to validate their arguments and throw exceptions when appropriate in the debuggable shared libraries. However, instead of throwing exceptions, these APIs will generate crashes when the optimized libraries are used.

Applications must not rely on OpenAccess to validate arguments in the const APIs.  Application developers should develop and test their applications using the debuggable shared libraries, then use the optimized shared libraries when testing for release and when shipping.

The Tcl Bindings for the OpenAccess API document has been improved and includes new usage examples.

oaTcl API Interfaces

New oaTcl interfaces are provided for the following:

::oa::AnalysisPointArray
::oa::BuildInfoArray 

The following oaTcl interfaces, which do not correspond to public OpenAccess APIs, have been removed.

The OpenAccess programming examples in <install_dir>/examples/oa have been improved. Each example directory now contains a run script, which creates any demo data (if needed), and runs the example. Each example directory also includes a log.ref file that contains the expected output.

For more information, refer to API Programming Examples.

The error and warning messages for the SPEF, Stream, and Verilog translators have been improved. Errors messages now help identify the cause of an error and suggest a corrective action. All messages are output with a unique alphanumeric prefix to ensure an unambiguous reference.

Note: Error and warning messages for the LEF/DEF translators were improved in a previous release.

View a summary  of the OpenAccess P049 source code and documentation release changes with respect to the P045 source code and documentation release.

• Release Status
• Compatibility with Earlier Releases
• API Changes
• Fixed Problems

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
• Milkyway to OpenAccess Translator
• Turbo DM System
• Tcl Pcells
• DM interface used by plug-in developers

The oaPcellScript Plug-In is in development and is not ready for use at this time.

The current oacDataModelRevNumber is 3.

• The Huge Database feature was introduced in oacDataModelRevNumber 1.
• New constraints and oaFigGroups were introduced in oacDataModelRevNumber 2.
• Incremental technology databases were introduced in oacDataModelRevNumber 3.

Refer to Compatibility for OpenAccess Applications and Data for more information. In addition, refer to the OpenAccess 2.2 Development Feature List for a list of the features included in each version of OpenAccess.

There are no API changes since the 2.2.6 release.

• Release Status
• Feature-Based Data Compatibility
• Compatibility with Earlier Releases
• Changes and New Features
• Translator Enhancements
• API Changes
• Fixed Problems
• Known Problems and Solutions

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
• Milkyway to OpenAccess Translator
• Turbo DM System
• Tcl Pcells
• DM interface used by plug-in developers

The oaPcellScript Plug-In is in development and is not ready for use at this time.

OpenAccess includes a new infrastructure to support data compatibility. Data compatibility addresses whether or not the databases written by applications built on one version of OpenAccess can be read or modified by applications using a different version of OpenAccess. In particular, newer OpenAccess releases can include features that have associated data that is not understood by previous versions of OpenAccess.

OpenAccess now provides feature-based data compatibility, which means that new features can be added to OpenAccess in a way that continues to allow newer releases of OpenAccess to be used by older applications.

For example, OpenAccess 2.2.6 includes a new feature called incremental technology databases. This new features allows a design database to reference more than one technology database. Because this means that a new kind of data is added to the data model, the incremental technology database capability is considered a feature. When a database contains one or more instances of this new kind of data, it considered to be using that feature. In many cases, older applications will not be able to use databases that have new features.

When OpenAccess releases a new feature, it increments the data model revision number (oacDataModelRevNumber).

OpenAccess has the ability to control the access that an application has to an OpenAccess database based on

• The version of OpenAccess that the application supports
• The new features used in that database

In addition, OpenAccess allows the applications in a flow to specify their level of support for new features when importing data with the OpenAccess translators.

For information about how an application can use feature-based compatibility, refer to Compatibility for OpenAccess Applications and Data.

The current oacDataModelRevNumber is 3.

• The Huge Database feature was introduced in oacDataModelRevNumber 1.
• New constraints and oaFigGroups were introduced in oacDataModelRevNumber 2.
• Incremental technology databases were introduced in oacDataModelRevNumber 3.

New functions were added to this release, so the oacAPIMinorRevNumber was incremented to 30. Programs compiled with the header files in 2.2.6 or later cannot be used with OpenAccess shared libraries from versions prior to 2.2.6. Programs compiled with versions prior to 2.2.6 will continue to run unchanged with the shared libraries in the current release.

Refer to Compatibility for OpenAccess Applications and Data for more information. In addition, refer to the OpenAccess 2.2 Development Feature List for a list of the features included in each version of OpenAccess.

Reference to vector Removed from oaCommonTypes.h

The following statement has been removed from the oaCommonTypes.h file:

#include <vector>

As a result, you might encounter compilation errors because the class std::vector is no longer defined. To resolve this, add this include statement at the appropriate location in one of your own header files.

OpenAccess 2.2.6 includes three new features in the context of feature-based compatibility (as describe above).

• New Incremental Technology Databases (released as a single feature in data model 3)
• New oaFigGroup Object (released as two features in data model 2)
• New Constraints for 65 Nanometer and Custom Designs and Enhanced Derived Layer Support (released as a set of features in data model 2)

Important: Applications that support data model 2 or 3 must modify their code to handle these new features. In the sections that follow, guidelines for the needed modification are called out for each of the three new features.

More information about these features is available in the OpenAccess 2.2 Feature List.

In addition, this release includes numerous enhancements and fixes that do not affect the data model:

• New Text bBox Plug-in Architecture
• New Default Constraint Groups
• Enhanced Documentation on Extending the Database
• Implementation Change for oaObserver
• Enhancements to Global Nets
• New oaTech Attachment Functions

This release of OpenAccess includes support for using multiple technology databases (oaTechs) for a single design.

In addition, this release includes enhancements to existing code to consistently handle any failures related to the bindings between oaDesign and oaTech databases.

Finally, a new gateGrounded attribute on oaTech returns a boolean value indicating whether or not the gates are considered grounded in this technology database.

New Incremental Technology Databases

Applications can now use incremental technology databases to provide technology information from multiple sources, such as the foundry, an IP provider, or a designer, to the application at different points in the design cycle. OpenAccess lets applications incrementally assemble technology information by creating references from one oaTech database to other oaTech databases.

For more information, refer to Incremental Technology Databases in Using Technology Databases in the Programmers Guide.

Note: There is currently a known issue when using built-in constraint groups across incremental technology databases. Refer to Known Problems and Solutions for details.

Modifying Your Code to Use this Feature

Most applications based on OpenAccess need access to the technology database. For example, any application that examines graphical data must access layers and via definitions. Applications reading technology databases might encounter incrementally defined databases. This requires defining observers to detect and report conflicts that can occur when a technology database is edited out of context of a larger graph in which it is used. The HelloWorld Example contains sample code that creates such observers.

In addition, applications that use technology objects must be aware that two technology objects referenced from the same design might be defined in different technology databases. Applications can no longer assume that the technology database containing the technology object in question is the sole technology database for the design.

Finally, when creating a technology object, an application must be prepared to handle the exception thrown if the object it is attempting to create conflicts with another object in the graph of referenced technology databases.

Binding Between oaDesign and oaTech Databases

When working with oaDesign and oaTech databases, the most efficient flow is to open and edit the oaTech databases as early as possible, then open the oaDesign databases.

OpenAccess has been enhanced to ensure that any binding failures between oaDesign databases and oaTech databases are handled consistently.

• oaDesign functions do not throw any exceptions related to oaTech open operations or technology object binding operations.
• Null pointers are returned by all design header get<TechObject> functions when the oaTech database or the oaTech object cannot be bound. Null pointers are also returned by oaDesign::getTech() when the oaTech cannot be bound. This applies even if the technology object or database does not exist or cannot be opened.
• oaTech::open() is the only function that throws exceptions if there are problems when opening a technology database.

The sections that follow provide more detailed information about these changes.

More Proactive Binding Between oaDesign and oaTech Databases

The binding between oaDesign and oaTech databases is more proactive than in previous OpenAccess releases. When an oaDesign that contains objects that use technology database information (such as vias or rows) is opened, the relevant oaTech database is always opened and bound if possible. All dependent objects are bound as well.

Design Objects That Reference oaTech Objects

When creating a design object that references an oaTech object, a NotInTechAssociatedWithDesign exception is thrown if the referenced oaTech object is not in the technology database to which the design is bound nor in the graph of referenced oaTech databases (if incremental technology databases are used).

For example, the following function throws an oacViaDefNotInTechAssociatedWithDesign exception if the given technology object is not in the technology database to which the design is bound nor in the graph of referenced oaTech databases.

oaCustomVia::create(oaBlock              *block,
                    const oaCustomViaDef *viaDef,
                    const oaTransform    &xform,
                    const oaParamArray   *params)

Other similar cases include:

oaStdVia::create()
oaRow::create() 
oaAnalysisOpPoint::create() 
oaPRBoundary::setCoreBoxSpec() 
oaRowHeader::find() 
oaViaHeader::find() 

In previous releases, an oacCannotFindTechForDesign exception was thrown.

Vias and Via Definitions

When reading in the vias for a design, OpenAccess attempts to bind the vias to their via definitions. This might require binding the design to its technology database. In previous versions, OpenAccess threw an exception if the binding failed. Now OpenAccess leaves the oaViaHeaders unbound instead.

In addition, an attempt to bind a via definition to a via of a different data type results in an exception.

Region Query

Region query now tolerates cases in which a design cannot be bound to its technology database.

Moving or Copying Vias

Copying or moving a via from one design to another does not make sense if doing so results in binding the via to a different via definition. For example, when copying a via, the name of the related via definition might refer to an oaStdViaDef in the source oaTech database, but an oaCustomViaDef in the target oaTech database. Previous versions of OpenAccess did not check for this case, which could cause a crash or corrupt the target design.

OpenAccess now verifies that the source and target designs refer to exactly the same via definition (not equivalent ones). An exception is thrown otherwise.

Graphical design-entry tools can use the new oaFigGroup object to hold a set of figures for easy replication and reuse. An oaFigGroup is purely geometric and does not contain connectivity objects (or anything that is not a figure).

For more information, refer to the documentation for the following classes:

• oaFigGroup
• oaFigGroupMem
• oaFigGroupQuery
• oaFigGroupStatus

Modifying Your Code to Use this New Feature

If your application does not access geometrical data (oaFigs), the oaFigGroup feature does not affect your application. Queries of oaFigs are unchanged, as oaFigs in oaFigGroups are handled by existing region query calls. If your application uses oaFigs solely to query them, you might not need to handle this feature.

If your application handles the selection of graphical objects, you might want to support selection of oaFigGroups by using the new oaRegionQuery class for oaFigGroups. An oaFigGroup can be a member of an oaGroup, so code that iterates through oaGroups must tolerate the presence of oaFigGroups.

OpenAccess provides new constraints to support 65 nanometer and custom designs, and existing constraints have been enhanced. Derived layers have also been enhanced.

• New Layer Constraints
• New Layer Pair Constraints
• New Simple Constraints
• Enhanced Layer Constraints
• New Built-In Constraint Parameter Types
• Constraint IDs and Descriptions
• New Default Constraint Groups
• Enhanced Derived Layers
• Modifying Your Code to Use this Feature

New Layer Constraints

• oacMinParallelViaSpacing
• oacMinEndOfLineSpacing
• oacMaxFloatingArea
• oacMinLargeViaArraySpacing
• oacMinLargeViaArrayWidth
• oacMinLargeViaArrayCutSpacing
• oacRectangularLargeViaArraysAllowed
• oacMinEdgeMaxCount
• oacMinEdgeAdjacentDistance
• oacMaxDiagonalEdgeLength
• oacMaxRoutingDistance
• oacKeepAlignedShapeAndBoundary
  
  See oaType, oaLayerConstraintType.

New Layer Pair Constraints

• oacMinRedundantViaSetback
• oacMinConcaveCornerOverlap
• oacMinConcaveCornerExtension
• oacKeepAlignedShapes
• oacMinEndOfLineExtension
  
  See oaLayerPairConstraintType

New Simple Constraints

• oacHorizontalPlacementGridPitch
• oacHorizontalPlacementGridOffset
• oacVerticalPlacementGridPitch
• oacVerticalPlacementGridOffset

Enhanced Layer Constraints

oacMinDualExtension has the following new valid value type.

oacAntenna has the following new parameters.

oacMinSpacing has the following new parameters.

oacMinClearance has a new parameter and a new valid value type.

New Built-In Constraint Parameter Types

• oacWidthLengthTableTypeConstraintParamType
• oacDistanceMeasureTypeConstraintParamType
• oacCountConstraintParamType
• oacParallelEdgeSpaceConstraintParamType
• oacParallelEdgeWithinConstraintParamType
• oacMaxLengthConstraintParamType
• oacMaxEdgeCountConstraintParamType
• oacMinNumCutsConstraintParamType
• oacAntennaAreaFactorConstraintParamType
• oacAntennaDiffPlusFactorConstraintParamType
• oacAntennaDiffMinusFactorConstraintParamType
• oacAntennaDiffAreaReduceFactorConstraintParamType
• oacAntennaCumRoutingPlusCutConstraintParamType
• oacAlignmentTypeConstraintParamType
• oacEndOfLineSpaceConstraintParamType

Constraint IDs and Descriptions

A constraint ID and a string description can be added to constraints.

New Default Constraint Groups

Default constraint groups have been added to objects that formerly did not have default constraint groups.

For more information, refer to the following:

• oaNet
• oaRoute
• oaGroup
• Applying Constraints to Objects

Enhanced Derived Layers

The oaDerivedLayer class provides several new features:

• Applications can create sized layers or layers based on operations.
• Applications can derive layers from one or two layers.
• Derived layers can have associated parameters.

Refer to the following functions in the oaDerivedLayer class documentation for more information.

oaDerivedLayer* oaDerivedLayer::create(oaTech*                             tech,  
                                       const oaLayer*                      layer1,  
                                       const oaDerivedLayerDef*            def,  
                                       const oaString&                     name,  
                                       oaLayerNum                          number,  
                                       const oaDerivedLayerParamArray *    params = NULL 
                                       )  [static] 

oaDerivedLayer* oaDerivedLayer::create(oaTech*            tech,  
                                       oaLayer*           layer1,  
                                       oaLayer*           layer2,  
                                       oaLayerOp          operation,  
                                       const oaString&    name,  
                                       oaLayerNum         number 
                                       )  [static] 

oaDerivedLayer* oaDerivedLayer::find(const oaTech*                      tech,  
                                     oaLayerNum                         layer1Num,  
                                     oaLayerNum                         layer2Num,  
                                     const oaDerivedLayerDef*           def,  
                                     const oaDerivedLayerParamArray*    params = NULL,  
                                     oaBoolean                          local = false 
                                     )  [static] 


oaDerivedLayer* oaDerivedLayer::find(const oaTech*                      tech,  
                                     oaLayerNum                         layer1Num,  
                                     const oaDerivedLayerDef*           def,  
                                     const oaDerivedLayerParamArray*    params = NULL,  
                                     oaBoolean                          local = false 
                                     )  [static] 

Note: The oaSizedLayer class has been deprecated. This type of layer should be expressed as an oaDerivedLayer.

New Derived Layer Definition

The oaDerivedLayer class defines a derived layer, which is formed from the combination of two layers and a layer operation. Refer to the class documentation for oaDerivedLayerDef for more information.

New Derived Layer Parameters

The oaDerivedLayerParam class describes additional information for derived layers. Some layer operations require one or more parameters, such as shrink or grow operations. In such cases, an array of oaDerivedLayerParam objects can be associated with the derived layer.

New Derived Layer Parameter Definition

The oaDerivedLayerParamDef class enforces the value type of a derived layer parameter.

New Layer Operations

The oaLayerOpEnum includes new enum values for additional operations.

enum oaLayerOpEnum {
    // Existing enumeration values go here.
    oacInsideLayerOp                    = 6, 
    oacOutsideLayerOp                   = 7,
    oacOverlappingLayerOp               = 8,
    oacStraddlingLayerOp                = 9,
    oacAvoidingLayerOp                  = 10,
    oacButtingLayerOp                   = 11,
    oacCoincidentLayerOp                = 12,
    oacCoincidentOnlyLayerOp            = 13,
    oacEnclosingLayerOp                 = 14,
    oacButtingOrCoincidentLayerOp       = 15,
    oacButtingOrOverlappingLayerOp      = 16,
    oacAreaLayerOp                      = 17,
    oacGrowLayerOp                      = 18,
    oacShrinkLayerOp                    = 19,
    oacGrowVerticalLayerOp              = 20,
    oacGrowHorizontalLayerOp            = 21,
    oacShrinkVerticalLayerOp            = 22,
    oacShrinkHorizontalLayerOp          = 23
};

New Layer Array Constraint

The oaLayerArrayConstraint class defines constraints for three or more layers.

New oaValue Subtypes

Four new oaValue subclasses support new constraints and derived layers:

• oaIntRangeValue
• oaIntDualIntArrayTblValue
• oaUInt8Value
• oaUInt8RangeValue

Modifying Your Code to Use These Features

If your application does not query for or create constraints or layers, you do not need to modify your code to handle these new features.

If your application does query for or create constraints, you must complete the following tasks.

• Modify your code to use the new oaDerivedLayer class instead of the oaSizedLayer class. When reading in older data that uses oaSizedLayer, update that data to use the new oaDerivedLayer.
• Does your application create constraints on nets or routes that apply to shapes associated with those objects? If so, modify your code to create the constraints in the new default constraint groups for nets or routes, respectively. Also, if your application searches for these type of constraints, search in the new default constraint groups.
  
• Review the detailed documentation for the new constraints and modify your application to respect those new constraints if appropriate. Also ensure that your code can handle the existing constraints with new parameters or value types. If you created user-defined constraints that replicate the semantics of any of the new constraints, modify your code to update those constraints to the newly defined constraints.

OpenAccess now includes a plug-in infrastructure that lets an application calculate its own bBoxes for text labels. For more information, refer to How to Write a Plug-in to Calculate Bounding Boxes for Text.

Changes to Existing bBox Functionality

For oaAttrDisplay and oaInstAttrDisplay objects, the OpenAccess native bBox implementation (the default) now calculates the bBoxes based on the oaNativeNS mapped string. In previous versions, the bBoxes were calculated based on strings mapped in the namespace used in previous calls to oaAttrDisplay::getText and oaInstAttrDisplay::getText previously (if any). Otherwise, the oaNativeNS mapped string was used.

If a design has oaInstAttrDisplay, oaInstPropDisplay, or oaTextOverride objects, these objects might become unbound when the design is opened and the master design is not already open. In previous versions, OpenAccess did not check if these objects should be unbound.

The OpenAccess documentation has been enhanced to include a list of all classes that can be extended using properties and oaAppDefs. Refer to Which Classes can be Extended in the Programmers Guide for details.

The implementation of the oaObserver class has changed. This change is transparent and applications must continue to use oaObserver as before. This description is provided for informational purposes only.

The oaObserver template class and its specializations have been replaced with the oaVersionedObserver template and corresponding specializations. This template has an additional non-type template argument for the version of the observer. The oaObserver identifier is defined in the header files as oaVersionedObserver. This change was required to add new virtual functions to the specialization of oaTech. Application code must reference oaObserver—direct reference of oaVersionedObserver is not supported.

The behavior of OpenAccess APIs with regards to global nets has been enhanced. The consistency of the global state of a net is now preserved across the OpenAccess hierarchy domains. This statement has several implications:

• Global nets with the same name created in the module domain result in a single global net in the block domain. However, there will be no corresponding net in the top module unless it is explicitly created in the top module. A global net can be created in the top module at any time, regardless of whether or not a global net with the same name was previously created in some other module or in the block.
• All global module nets with the same name are presented as a single global net in the block domain.
• Removing the global state of a net in the block domain removes the global state of every module net with the same name as the global block net. These module nets become ordinary local module nets and are presented in the block domain as disjoint block nets.
• Destroying a global net in the block domain destroys every global module net with the same name as the global block net.
• When a global module net is connected to a local module net through an oaModInstTerm, only the global net is presented in the block domain, but the local module net remains local. The connectivity of the global block net includes the block domain reflection of the connectivity of the local module net that it is connected to through the oaInstTerm.
  

For more information, refer to Global Nets in the Programmers Guide.

This release includes new APIs for working with attached technology libraries. An application can now detach a technology database that is currently open for a design and reattach a different one.

Note: Using attached technology databases is not the same as using referenced incremental technology databases. Refer to the oaTech class documentation for more information.

void oaTech::attach(oaLib              *lib,
		    const oaScalarName &attachLibName
		    ) 


void oaTech::detach(oaLib    *lib) 


oaBoolean oaTech::hasAttachment(const oaLib    *lib) 


void oaTech::getAttachment(const oaLib     *lib,
		           oaScalarName    &attachLibName
	                   ) 

To support backward data compatibility, the previous mechanism for attaching technology libraries is still supported. Namely, a string property called techLibName in a library’s oaLibDMData database still specifies the name of the target library. The oaTech::attach function creates the techLibName property when it is called. In order to construct the name of the library, the techLibName string is interpreted in the oaNativeNS namespace.

New observers are available for the new APIs.

onPostAttach(oaLib *lib,  const oaScalarName &attachLibName)
onPostDetach(oaLib *lib)
onPreAttach(oaLib *lib,  const oaScalarName &attachLibName)
onPreDetach(oaLib *lib)

Support for Incremental Technology Databases

The lef2oa, def2oa, strm2oa, and verilog2oa translators can create incremental technology databases with the -techRefs option. Refer to the individual translator documentation for more information.

Using the lef2oa Translator with Incremental Technology Databases

The lef2oa translator should not add routing layers or default vias in a derived technology database if one of the referenced technology databases has a LEFDefaultRouteSpec constraint group.

The lef2oa translator creates an explicitly named constraint group called LEFDefaultRouteSpec to store information about layers and default vias (VIAs in LEF that have the DEFAULT keyword). Because a graph of technology databases can contain only a single constraint group with that name, lef2oa cannot add or change layers or default vias in a derived technology database if one of the referenced technology databases already contains the LEFDefaultRouteSpec constraint group.  This is not a problem if the layer and default via definitions in the LEF input match the definitions in the referenced technology database.

The base technology database hierarchy should contain a full set of layer and default via definitions, and subsequent derived technology databases created by lef2oa should be used only to add sites, via-rules, non-default vias, non-default-rules, and macros.

Alternatively, you can create an incomplete base technology database with lef2oa, then add layers and default vias to a derived technology database using lef2oa. You need to remove the LEFDefaultRouteSpec using the OpenAccess Tcl bindings after running the first lef2oa operation.

lef2oa and oa2lef Translators

The lef2oa and oa2lef translators now support LEF 5.6 constructs and create OpenAccess constraints (instead of properties) for these constructs. You must set the -dataModel argument to 3 to enable creation of the LEF 5.6 constraints. Refer to the translator mapping documentation for more information.

Optionally Building lef2oa or oa2lef

If you need to build the LEF translators (which is optional), the def_5.6.tar.Z and lef_5.6.tar.Z kits are now required.

Refer to the OpenAccess Installation and Configuration Notes for more information about building the translators.

def2oa Translator

The def2oa translator has a new -layerMap option to specify a layer mapping file. The translator reads the mapping file before looking up layer names in the technology database, which means users can map layer names to existing layer names in the technology database.

Refer to DEF to OpenAccess Translator (def2oa) for more information.

verilogAnnotate Translator

The verilogAnnotate translator now treats "tristate" as equivalent to "output" for consistency purposes. Ports declared as "output" in Verilog that have an existing oaTermType of "tristate" retain the "tristate" oaTermType.

oa2strm Translator

The oa2strm translator now accepts multiple cell names for translation.

Refer to OpenAccess to Stream Translator (oa2strm) for more information.

Translator API Changes

The following changes have been made to the translator APIs. Applications that derive from the OpenAccess translators must modify their code accordingly.

oaStrm API Changes

• The Stream translator components were restructured to handle incremental technology databases.
• The following new functions in the OptionsIn class support the specification of a library path on the command line:
  • getLibPath() const
  • setLibPath(const oaString &value)
• A library reference is no longer stored in the Structure class. The NameMgr class now handles the mapping between the stream and OpenAccess names.
• The populateLimitMap() function was removed from the StrmIn class. The limit map, as a tool for ensuring that the on-disk representation of a library contains no more than 20000 cells, has been eliminated. This functionality is now provided through the NameMgr class.
• To support the ability to accept multiple cell names, the OptionsOut::getCellName() and OptionsOut::setCellName() translator functions were updated.

oaLefDef API Changes

The LEF/DEF translator components were restructured to handle incremental technology databases.

View a summary  of the OpenAccess 2.2.6 release changes with respect to 2.2.5.

Version 2.2.5

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

Release Status

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
• Milkyway to OpenAccess Translator
• Turbo DM System
• Tcl Pcells
• DM interface used by plug-in developers

The oaPcellScript Plug-In is in development and is not ready for use at this time.

Compatibility with Earlier Releases

New functions were added to this release, so the oacAPIMinorRevNumber was incremented to 21. Programs compiled with the header files in 2.2.5 or later cannot be used with OpenAccess shared libraries from versions prior to 2.2.5. Programs compiled with versions prior to 2.2.5 will continue to run unchanged with the shared libraries in the current release.

The current oacDataModelRevNumber number is 1. Refer to Compatibility for OpenAccess Applications and Data for more information.

Changes and New Features

OpenAccess is Available on the Solaris 10 (x86_64) Operating System

OpenAccess is available on the solaris operating system 10 (x86_64). The supported compiler is Forte Developer/Studio 11 C++ 5.8.

Enhancements to Undo and Redo Functionality

OpenAccess provides two use models for performing undo and redo operations:

• Post checkpoint model—Applications set checkpoints after an operation occurs.
• Pre checkpoint model—Applications set checkpoints before an operation occurs.

In previous releases, there was a potential ambiguity in the pre checkpoint model. Consider this example:

If an application issued an undo command after setting checkpoint 3, the expectation might be that checkpoint 3 would be removed, but rect2 would remain intact. In reality, OpenAccess destroys rect2 in this situation.

In order to remove any confusion, OpenAccess provides two new APIs:

• void oaDesign::enableUndo(oaBoolean, oaUndoModel);
  
  This function lets the application specify which model to use, either oacUndoModelPreCheckpoint  or oacUndoModelPostCheckpoint. If an application specifies oacUndoModelPreCheckpoint,  an undo operation destroys the last checkpoint and leaves the results of the preceding operation intact. Using the illustration above, performing undo after checkpoint 3 was created destroys checkpoint 3 but does not destroy rect2. 
  
  
• void oaDesign::unsetCp();
  
  This function removes the last checkpoint in this design assuming that there are no operations after that last checkpoint.
  

OpenAccess also provides new functions that can help applications synchronize the undo state for multiple designs. These functions let applications get and set IDs for checkpoints:

• void oaDesign::setCp ( oaUInt4 cpID );
  
  
• oaUInt4 oaDesign::getCpID ( ) const;

Enhancements to oaInstTerm::create and oaModInstTerm::create

OpenAccess now provides two use models for creating instTerms in the block and module domain:

• Single – Applications create exactly one instTerm with each function call.
• Batch – Applications create all the instTerms on an instance with a single function call.

In previous releases, applications could create only one instTerm with each function call. This single model works well for interactive applications or applications that do not know in advance how many instTerms will be created on a single instance. The new batch model improves performance by optimizing the process of instTerm creation when applications know in advance how many instTerms will be created on the instance.

To support batch instTerm creation, OpenAccess provides the following new public classes and functions. 

Public Classes

• oaNetTermArray– Associates oaNet pointers with oaTerm pointers.
• oaNetTermNameArray– Associates oaNet pointers with the names of terms.
• oaNetTermPosArray– Associates oaNet pointers with positions of terms.
• oaModNetTermArray– Associates oaModNet pointers with oaModTerm pointers.
• oaModNetTermNameArray– Associates oaModNet pointers with names of terms (in the module domain).
• oaModNetTermPosArray– Associates oaModNet pointers with positions of terms (in the module domain).

Public Functions

class oaInstTerm
    static void                create(oaInst                        *inst,
                                      const oaNetTermArray          &connData,
                                      oaBlockDomainVisibility       view = oacInheritFromTopBlock);

    static void                create(oaInst                        *inst,
                                      const oaNetTermNameArray      &connData,
                                      oaBlockDomainVisibility       view = oacInheritFromTopBlock);

    static void                create(oaInst                        *inst,
                                      const oaNetTermPosArray       &connData,
                                      oaBlockDomainVisibility       view = oacInheritFromTopBlock);


class oaModInstTerm
    static void                create(oaModInst                     *inst,
                                      const oaModNetTermArray       &connData);

    static void                create(oaModInst                     *inst,
                                      const oaModNetTermNameArray   &connData);

    static void                create(oaModInst                     *inst,
                                      const oaModNetTermPosArray    &connData);

Minimizing the Use of Virtual Memory

OpenAccess provides new functions for minimizing the amount of virtual memory used by an application on OpenAccess. These functions should be used only when needed because they can significantly impact the performance of subsequent operations.

• void oaSession::minimizeVM()
  
  This function minimizes the amount of virtual memory that OpenAccess uses by releasing memory held in reserve for future use and by releasing dynamically allocated data structures that can be rebuilt as needed.
  
  
• oaDesign::minimizeVM()
  

  This function minimizes the amount of virtual memory this design uses by releasing dynamically allocated data structures that can be rebuilt as needed.

• oaTech::minimizeVM()
  

  This function minimizes the amount of virtual memory this technology database uses by releasing dynamically allocated data structures that can be rebuilt as needed.

Spice Namespace

Name mapping for the OpenAccess Spice namespace is now properly case-insensitive and case-preserving.

Two scalar names initialized with the strings "abc" and "Abc" in a case-sensitive namespace are now mapped to "abc" and "%Abc" in the  Spice namespace. A name initialized in the Spice namespace with the strings "%Abc" or "%abc" is mapped to "Abc" in a case-sensitive namespace, such as the OpenAccess native namespace.

Translator Changes

Change to Translator Argument Names

In previous versions of OpenAccess, each translator used different options and conventions for describing the set of reference libraries and views to translate. For example, verilog2oa used the -leafLibs and -leafViews options, whereas def2oa used -masterLibs and -masterViews. All translators now use standard options named -refLibs and -refViews.

Refer to the documentation for the individual translators for more information.

Note: The old options are still supported, but they generate warnings.

lef2oa Translator

The lef2oa translator can create oaAttrDisplay objects for each pin shape on an oaTerm. You can specify the layer name for the text and the height of the text. If the text layer does not yet exist, it is created (if the technology database is writable). The text is always written with the purpose "drawing".

The following new options are available:

• -pinLabels
  Enables the creation of pin labels.
  
  
• -textLayer
  Specifies the name of the text layer to create (defaults to text).
  
  
• -textHeight
  Specifies the height of the text (defaults to the current DBU value for maskLayout views).

In addition, in earlier lef2oa implementations, the order of SPACING statements in the input file affected the generated spacing table. Now the SPACING statements are sorted before processing so that the spacing tables are the same regardless of the order of the SPACING statements.

def2oa and oa2def Translator

• In previous releases, the def2oa translator exited the translation if the starting layer of a route did not match the vias that followed. Instead, the translator now issues a warning and uses the correct routing layer. For example, ROUTED M1 ( 0 0 ) VIA23 VIA12 is now passed through with a warning.
  
  
• In previous releases, the oa2def translator exited the translation if the viaDirection attribute of an oaVia in an oaRoute did not match the other elements in the route. Now, the translator issues a warning and the correct starting layers are output.

strm2oa Translator

• The strm2oa translator can now accept an asterisk (*) for the library name in the cellMap file, which means that the reference libraries are searched for the mapped cellName. The strm2oa translator searches only for uppercase names when searching reference libraries if the -toUpper option is specified. Similarly, the translator searches only for lowercase names in the reference libraries if the -toLower option is specified. In previous versions, strm2oa searched first for the case-converted name, then for the non-converted name.
  
  
• The strm2oa -detectVias option automatically recognizes GDS structures that are vias, and represents them as oaStdVias rather than oaDesigns.
  
  Note: If you do not have a viaMap file and you do not use the -detectVias option and provide the necessary information in the layerMap file, the translator produces many oaDesigns to represent the vias. This can adversely affect the performance of both the strm2oa translator and other applications running on the oaDesigns that are produced.

oaStrm API

The strmOut class was updated to support via and cell name mapping. In addition, the layerMapIn class was updated to address a problem related to the paths in map files.

There oaStrm translator APIs that involve the name mapping from Stream structures to lib/cell/view names have changed.

LEF and DEF API

The DefInNet::createVia function, which used to take an oaPoint, now takes an oaTransform. This change supports rotated vias in DEF 5.6. Derived translators that inherit from DefInNet need to change the signature of the derived createVia function. They do not have to change calls to this function because an oaPoint can be cast to an oaTransform.

oaVerilog API

The Verilog translator API has been converted to use batch instTerm creation.

API Change Reports

View a summary  of the OpenAccess 2.2.5 release changes with respect to 2.2.4.

Fixed Problems

Version 2.2.4

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

Compatibility with Earlier Releases

Functions were added in this release, so the oacAPIMinorRevNumber was incremented to 17. Programs compiled with the header files in 2.2.4 or later cannot be used with OpenAccess shared libraries from versions prior to 2.2.4. Programs compiled with versions prior to 2.2.4 will continue to run unchanged with the shared libraries in the current release.

The current oacDataModelRevNumber number, which represents the version of the OpenAccess data model, has been incremented to 1 due to the addition of the Huge Database feature. Refer to Feature-Based Compatibility  for more information.

Feature-Based Compatibility

OpenAccess adds new kinds of data to the data model as newer versions are released. For example, OpenAccess might add new kinds of figures or add support for very large databases.

Each new kind of data added to the data model is called a feature. When a database contains one or more instances of the new kind of data, then it is using that feature. In many cases, older applications will not be able to use databases that have new features.

OpenAccess now includes the infrastructure to support feature-based compatibility. Feature-based compatibility addresses whether or not the databases written by applications built on (or running against) one version of OpenAccess can be read or modified by applications on a different version of OpenAccess.

For more information about feature-based compatibility, refer to Applications Can Specify Supported Data Model Revision.

Argument Validation for Connectivity Creation Functions

The argument validation for all connectivity creation functions has been updated for consistency. This affects the validation for creation functions in oaNet, oaBusNet, oaModNet, oaModBusNet, oaTerm, oaBusTerm, oaModTerm, and oaModBusTerm. Applications might now get different exceptions for errors than in previous builds of OpenAccess. However the set of possible exceptions has not changed.

Changes and New Features

Applications Can Specify Supported Data Model Revision

OpenAccess has a new version of its init functions that an application can use to specify the version of the data model (dataModelRev) that it supports. OpenAccess uses this information to determine whether the application can open databases containing features supported in higher data model revisions.

extern void oaDesignInit(oaUInt4  apiMajorRev,
                         oaUInt4  apiMinorRev,
                         oaUInt4  dataModelRev);

extern void oaTechInit(oaUInt4    apiMajorRev,
                       oaUInt4    apiMinorRev,
                       oaUInt4    dataModelRev);

extern void oaWaferInit(oaUInt4   apiMajorRev,
                        oaUInt4   apiMinorRev,
                        oaUInt4   dataModelRev);

extern void oaDMInit(oaUInt4      apiMajorRev,
                     oaUInt4      apiMinorRev,
                     oaUInt4      dataModelRev);

For example, an application might specify a lower dataModelRev in the oaDesignInit() function to indicate that it does not yet support a new feature, such as Huge Databases, which is defined in the OpenAccess shared libraries with a higher dataModelRev that the application is building against.

The application can call these functions multiple times, but the dataModelRev numbers specified in those calls must be consistent or OpenAccess will throw an exception. The release notes for each OpenAccess release will include information about the current dataModelRev number and any new features included in that release. For more information about these functions and how they affect compatibility, refer to Compatibility for OpenAccess Applications and Data

Note: Applications should use the new init functions as the older versions are considered deprecated. For applications that continue calling the older versions of the init functions, OpenAccess will use the data model revision that is defined as the default (oacDataModelRev) in the kit the application was built against, which indicates that the application fully supports the data model defined by the OpenAccess kit.

Opening Very Large Databases (Huge Databases Feature)

OpenAccess now provides the ability to open very large database in which a single type of data takes over 4 Gbytes of memory.  Refer to the OpenAccess 2.2 Feature List for more information about this feature (which is called Huge Databases).

oa2verilog Translator Enhancement

If an OpenAccess module is created without using the verilog2oa translator, it may not be possible to accurately represent the interface to the module in the Verilog language. This commonly occurs when a bit-wise netlist format such as LEF/DEF is used to create leaf cells that have ported busses because the Verilog language does not allow named connections to individual bits of a bus without creating aliases. In such cases, the verilogAnnotate program is used to define the module interface so that it can be expressed using legal port identifiers.

If verilogAnnotate was not used, oa2verilog has been enhanced to take a “best guess” regarding what the interface to the design should be. When guessing, oa2verilog groups the bits of busses together as long as the bits are either monotonically increasing or decreasing.

Improved Error and Warning Messages

The OpenAccess translators have been enhanced to use a standard message format to ensure comprehensive and consistent messaging. In addition, the translator messages have been improved for usability. See the information about interpreting error and warning messages in the individual translator documents for more information.

Plug-In Registration Files on Windows

String values in the OpenAccess plug-in registration files use the backslash (\) as an escape character. The escape character itself is ignored and the next character is used literally. As a consequence, a backslash character in a string must be represented with two backslashes (\\), and a double quote can be represented with a backslash and a double quote (\”). Strings that represent file paths on the Windows platform must have double backslash characters. For example, the path C:\work\designs should be represented as:

"C:\\work\\designs"

Tcl Changes

The shared libraries for the Tcl bindings of the OpenAccess API are reorganized. This affects only C++ code that leverages the Tcl bindings as described in the section of the Tcl Bindings for OpenAccess APIs document titled C++ Access from Tcl. This reorganization does not affect Tcl scripts that employ Tcl OpenAccess commands.

The single oaTcl shared library is now repackaged with five additional shared libraries.

• oaTcl This shared library, which can be loaded by a Tcl interpreter through the Tcl load command, has not changed. This shared library depends on the five additional shared libraries.
• oaLangBase This shared library contains support classes to describe OpenAccess classes.
• oaLangInfo This shared library contains the