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 description of OpenAccess classes and functions.
• oaTclCommon This shared library provides general support classes for Tcl bindings of C++ types.
• oaTclBase This shared library provides support classes for Tcl bindings to OpenAccess types.
• oaTclPlugIn This shared library provides support classes for the Tcl script engine, which is used for Tcl Pcells.

Shared libraries for custom Tcl bindings, which were previously linked to the single oaTcl shared library, must now be linked to oaTclBase, oaLangInfo, oaTclCommon, oaLangBase and oaTclPlugIn. The previous statement to include the header file oaTcl.h must now be replaced with the statement to include oaTclBase.h.

Performance Improvement for oaInstTerm::find() and oaOccInstTerm::find()

The performance of oaInstTerm::find() and oaOccInstTerm::find() are improved for instances in the block domain that have many terminals. In addition, two new oaOccInstTerm::find() methods are added for finding the oaOccInstTerm corresponding to an oaOccInst and either an oaModTerm or an oaTerm.

Parasitics

If an application reads a design with parasitics, but does not explicitly access those parasitics, then the files containing the parasitic data are not opened (as they were in previous releases). This leaves more file descriptors available for other uses.

API Change Reports

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

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.

Fixed Problems

New Known Problems and Solutions (KP&S)

• Setting extensions on databases
• Editing parasitic networks

Version 2.2 P031 Source Code and Documentation Release

This release includes source code and documentation. Binaries and libraries are not included.

• 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 15. Programs compiled with the header files in P031 or later cannot be used with OpenAccess shared libraries from versions prior to P031. Programs compiled with versions prior to P031 will continue to run unchanged with the shared libraries in the current release.

Changes and New Features

Support for Feature-Based Compatibility

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.

At present, the support is in place for feature-based compatibility, but there are no new features included in OpenAccess.

API Change Reports

View a summary  of the OpenAccess 2.2 P031 code and documentation release changes with respect to 2.2.3.

Fixed Problems

Version 2.2 P028 Source Code and Documentation Release

This release includes source code and documentation. Binaries and libraries are not included.

• 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

Functions were added in this release, so the oacAPIMinorRevNumber was incremented to 13. Programs compiled with the header files in 2.2 P028 or later cannot be used with OpenAccess shared libraries from versions prior to 2.2 P028. Programs compiled with versions prior to 2.2 P028 will continue to run unchanged with shared libraries built from the P028 OpenAccess source code.

Applications using OpenAccess 2.2.3 shared libraries cannot read designs with parasitics from previous versions. Applications using P028 and later can read parasitics from any previous version.

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

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"

Parasitics

If an application reads a design with parasitics, but does not explicitly access those parasitics, then the files containing the parasitic data are not opened (as they were in previous releases). This leaves more file descriptors available for other uses.

New Translator Option

OpenAccess is improving the error message format for translators. To preview the new format, use the -newMsgFormat command-line option.

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 description of OpenAccess classes and functions.
• oaTclCommon This shared library provides general support classes for Tcl bindings of C++ types.
• oaTclBase This shared library provides support classes for Tcl bindings to OpenAccess types.
• oaTclPlugIn This shared library provides support classes for the Tcl script engine, which is used for Tcl Pcells.

Shared libraries for custom Tcl bindings, which were previously linked to the single oaTcl shared library, must now be linked to oaTclBase, oaLangInfo, oaTclCommon, oaLangBase and oaTclPlugIn. The previous statement to include the header file oaTcl.h must now be replaced with the statement to include oaTclBase.h.

EMH Changes

The performance of oaInstTerm::find() and oaOccInstTerm::find() are improved for instances in the block domain that have many terminals. In addition, two new oaOccInstTerm::find() methods are added for finding the oaOccInstTerm corresponding to an oaOccInst and either an oaModTerm or an oaTerm.

API Change Reports

View a summary  of the OpenAccess 2.2 P028 code and documentation release changes with respect to 2.2.3.

Fixed Problems

Version 2.2.3

• 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

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

Parasitic Objects With AppDefs

This release fixes a bug with extensions on paged parasitics objects when loading a parasitic network from disk. Previously, applications needed to explicitly create AppDefs for all extensions used in existing parasitic networks to avoid a crash when loading those networks. For databases written by P023 and later, OpenAccess will automatically create any AppDefs needed when loading parasitic networks.

Changes and New Features

Tcl Changes

In order to eliminate redundancy, the oa::String object has been removed from the oaTcl bindings. All bindings with an oaString parameter now accept a Tcl string as the parameter.

The following oaString member function bindings were removed.

• ::oa::index
• ::oa::toDouble
• ::oa::toInt
• ::oa::toLower
• ::oa::toUpper

In addition, all enum values and constant references have been moved from the global Tcl namespace to the the oa:: namespace. For example, $oacMaskLayout is now $oa::oacMaskLayout. This change reduces the size of the list that is returned from the info vars command to a more manageable size. If your Tcl program uses these oa values, you can correct it by adding oa:: to the reference, or you can import these symbols to the global namespace with a command such as

foreach var [info var ::oa::*] {upvar #0 $var ::[namespace tail $var]}

Finally, for consistency with the rest of the OpenAccess code, the name of the TclException class has been changed to oaTclException, and the getMsg() return value has been changed from std::string to oaString.

oaString::format Functions

Three overloaded functions, oaString::format, have been added. These functions format an oaString object according to the given format specification.

verilog2oa Translator

The verilog2oa translator is intended to create new design data, not append to existing design data. Checks have been added to produce an error if you try to use verilog2oa to append to an existing design. Note that verilog2oa has an –overwrite option if you simply want to overwrite an existing design.

Behavior Change for oaNet::setSigType and oaModNet::setSigType

The behavior of the oaNet::setSigType() and oaModNet::setSigType() functions has changed. The sigType attribute of nets is now domain specific. Calling oaNet::setSigType() does not alter the sigType of any related net in either the Module or Occurrence domains. Similarly, calling oaModNet::setSigType() does not alter the sigType of any related net in the Block domain.

The oaNet::getSigType(), oaModNet::getSigType(), and oaOccNet::getSigType() functions each return the sigType of the net in their respective domains. When a net is initially created, the sigType parameter of the create function is copied to all nets implicitly created in other domains.

When reading a database generated with a previous version of OpenAccess, the sigType of the nets in the old database is preserved in the new database. When an old shared library is reading a new database, the sigType of the nets in the Occurrence domain become the sigType of the related nets in all domains with respect to the semantics of the old shared libraries, which supported only a single sigType for all related nets.

New getCreateTime Functions

Previously, the values returned by oaDesign::getTimestamp were seeded by the create time of the oaDesign. In order to provide stable values for testing, oaDesign::getTimestamp now returns the number of changes since the oaDesign was created as the time stamp.

Applications can use oaDesign::getCreateTime to distinguish databases that might be identical but that were created at different times.

The following new functions let you get the creation time for the database objects:

• oaDesign::getCreateTime();
• oaTech::getCreateTime();
• oaWafer::getCreateTime();

Deprecated Primitive Types

The primitive types that were declared in oaCommonTypes.h have been deprecated. Applications should use the equivalent primitive OpenAccess types. The following table shows both the deprecated types and the types that should be used.

All usages of the deprecated types in OpenAccess have been replaced with the equivalent OpenAccess types. This does not affect drop-in compatibility nor compile-time usage for the affected classes. In OpenAccess, the public classes that are affected by this change are defined in the oa/src/common and oa/src/plugin packages.

oaViaParams Enhancement

In the oaViaParam class, the cut height and cut width can be controlled separately by using two new enumeration values, oaViaParamTypeEnum::oacCutWidthViaParamType and oaViaParamTypeEnum::oacCutHeightViaParamType.The enumeration value oaViaParamTypeEnum::oacCutSizeViaParamType was formerly used to control both cut width and height simultaneously. That value is now deprecated, but is still supported for backward compatibility.

Conversely, the numbers of cut columns and cut rows are now controlled simultaneously. Users must either specify them both, or not specify either. Due to the backward compatibility requirements, the OpenAccess API still supports specifying the numbers of cut rows and cut columns separately (using the methods oaViaParam::setCutRows and oaViaParam::setCutColumns). However, specifying only one of them without specifying the other results in undefined behavior.

oaStdViaDef::setParams Enhancement

In the oaStdViaDef class, the logic of the setParams method has changed. Previously, the parameters from the incoming oaViaParam object were directly copied into the oaStdViaDef object, regardless of their flag values. This behavior required that users explicitly specify all the parameters in the incoming oaViaParam object, even if only one was to be modified. The new implementation accounts for the flag values in the incoming oaViaParam objects, so that only the changed attributes are copied into the oaStdViaDef object.

oaScanChain Enhancements

oaScanChain::create(), oaScanChain::setStartObject(), and oaScanChain::setStopObject() now check that the start and stop objects are of type oaBitTerm, oaInstTerm or oaScanChainInst, otherwise an oacInvalidScanChainObject exception is thrown.

New InstTerm getBit() Functions

New oaInstTerm::getBit(), oaModInstTerm::getBit(), and oaOccInstTerm::getBit() functions allow applications to access a specific member instTerm of a multi-bit instTerm.

oaTech Attachment Change

When a tech database is opened for a library, the tech database is associated with the library and remains the tech database for that library until either

• The tech database is purged
• The library is closed

This is true if the tech database is contained in the library, or if it is attached to the library using the library attachment property.

For example, library1 has a property that forms an attachment to the tech database in library2. Once library1 opens this tech database, the association to the tech database in library2 remains in effect even if the attachment property in library1 is changed or removed. The association remains until the tech database in library2 is purged, or library1 is closed.

verilog2oa and verilogAnnotate Now Generate Warnings

OpenAccess requires that all bits of a given port have the same direction. If the Verilog declares a different direction for different bits, the translator issues a warning and picks a single direction to apply to the OpenAccess terminal. Previously, the translator issued an error and exited.

Package Header File for Verilog Translators

The package header file for the OpenAccess Verilog translators has been changed to oaVerilog.h. The contents of the oaVerilog.h  file were previously contained in two header files: oaVerilogIn.h for the verilog2oa translator and oaVerilogOut.h for the oa2verilog translator. If you have your own Verilog translators built on the OpenAccess Verilog libraries, include oaVerilog.h instead of oaVerilogIn.h or oaVerilogOut.h.

New EMH Functions

• void oaBlock::setVisibleToModule();
  
  Specifies that the block is to be visible to the module domain. If the block is already visible to the module domain, this function does nothing. Otherwise, this function creates a top module that inherits all the existing occurrence and block objects in the top occurrence (top block), then sets the top block to be visible to the module domain.
  
  
• oaBoolean oaBlock::isVisibleToModule() const;
  
  Returns a boolean indicating whether or not this block is visible to the module domain.
  
  
• oaCollection oaOccNet::getSpan ( ) const;
  

  Returns a collection of all occNets in the span of this net. The span is defined as the set of nets connected through the module hierarchy within a single oaDesign. Connected nets in other oaDesigns are not included. The span of a net will change as connections to ModTerms and ModInstTerms are changed.
  

• void oaInstTerm::hide();

  Removes the instTerm from the block domain. The instTerm will not appear in any block domain collections and it will not be returned by any find() functions. This function is not the same as the destroy function because the corresponding instTerms in the module domain are unaffected by hide(). An instTerm must be explicit to be hidden and it must have a corresponding instTerm in the module domain. Hiding a multi-bit instTerm causes all the member instTerms to also be hidden. Hiding an explicit single-bit member of a scalarized multi-bit instTerm hides all the multi-bit owners of the instTerm as well as all the member bits of those instTerms.
  

New EMH Functionality

EMH has been enhanced with regards to the production and processing of objects when modules are uniquified, embedded, or detached (regardless of whether the occurrence hierarchy is bound or unbound).

EMH now attempts to copy, create, bind, and unbind multi-bit, scalarized, implicit objects as the data is being processed. For example, previously when a busNet such as A[0:4] was scalarized, if its module was uniquified, only the explicit busNetBits A[0],…,A[4] were processed. Now, the implicit busNet A[0:4] is also processed.

The oaOccTraverser class has been enhanced with a new flag bit to let applications choose whether they want to process implicit objects.

Changed oaBusNet Functions

oaBusNet::setBaseName and oaBusNet::setRange now throw exceptions if the new net name conflicts with an existing net (even if that net is implicit), or if the new connectivity results in an illegal oaTerm connection.

Optionally Building LEF and DEF Translators

Previously, if you rebuilt the LEF and DEF translators, you had to override the default location of the translators with a LEFDEF_HOME environment variable.  Now you can choose to specify the LEF and DEF paths individually with LEF_HOME and DEF_HOME. See Optionally Compiling Translators in the OpenAccess Installation and Configuration Notes.

Note: Very few users need to recompile the OpenAccess translators. You need to do this if you use an operating system that isn’t compatible with one of the pre-built versions, or if you want to modify the distributed translator.

Implant Enclosures

The implant enclosure specified for the params for a StandardVia is now relative to the corresponding layer, not relative to the cut as it was previously. See Implant 1/Implant 2 Enclosures in the Programmers Guide for more information.

Improved Documentation System

The OpenAccess documentation now provides index pages that let you locate classes according to class categories. See OpenAccess Class Selections. In addition, you can access the list of OpenAccess exceptions from the new Exceptions button at the top of each page.

Restructuring of Inline Function Definitions

Inline and template member function implementations have been moved from class header files to inline function files. The behavior of the functions has not changed, so application code is unaffected. The purpose of this change is to inline member functions of two co-dependent classes that need to access each other’s members. This change also resolves issues with some versions of compilers related to co-dependent template classes and their member functions.

Changed Exception

The exception oacCannotFindAttachedTech has been replaced by the oacCannotFindTechForDesign exception. Any code that attempted to catch oacCannotFindAttachedTech must be modified accordingly.

API Change Reports

View a summary  of the OpenAccess 2.2.3 update release changes with respect to 2.2.2.

Fixed Problems

Version 2.2.2

• 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

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

Compatibility with Earlier Releases

• Functions were added in this release, so the oacAPIMinorRevNumber was incremented to 6. Programs compiled with the header files in 2.2.2 or later cannot be used with OpenAccess shared libraries from versions prior to 2.2.2. Programs compiled with versions prior to 2.2.2 will continue to run unchanged with the shared libraries in the current release.
  
  
• A small behavior change affects a number of the “set” functions on the oaBitNet object. The functions are:
  • setConnStatus
  • setRoutePattern
  • setShieldNet1
  • setShieldNet2
  • setVoltage
  • setOriginal
  
  An added check throws an exception if the oaBitNet in question is implicit. The setShieldNet{1,2} and setOriginal functions make an association with another oaBitNet, so an exception is also thrown if the net specified in the argument is implicit.
  
  
• oaPcellLink::getPcellDef() now functions differently when it cannot find the specified Pcell evaluator. Instead of returning NULL, it throws the exception, oacPcellEvaluatorNotFound. Any applications that use this function must include a try/catch block or verify the evaluator existence with oaPcellLink::find() before using it.
  
  
• In prior releases on the Win32 platform, both oaDMTurbo and oaDMFileSys plug-ins were made available as DLLs whether you were using static or dynamic configurations. Now the static configuration generates static libraries for these plug-ins while the dynamic configuration generates DLLs. In static mode, these client-side plugIns are now part of the client execuatble.
  

  On the Win32 platform, if you are using static mode, you must make sure you initialize these plug-ins with the proper init call. If you have stand-alone OpenAccess-based tests or programs, you must add these init calls to your code. This is done after oaDesignInit() is called. See oa/test/main.cpp as an example.

  You must declare the prototypes in the beginning as follows:

      #if defined(OA_STATIC)
      extern "C" void oaDMTurboInit();
      extern "C" void oaDMFileSysInit();
      #endif
      

  Then call them as follows:

          // Initialize.
      oaDesignInit();
  
      #if defined(OA_STATIC)
          oaDMTurboInit();
          oaDMFileSysInit();
      #endif
      

  A similar situation exists if you are using other plug-ins like oaRQXYTree, oaPcellCPP, or oaPcellScript. These have similar init calls that must made in a similar fashion.

  NOTE: This applies only on Win32, only for static builds, and only for your own stand-alone tests. The impacted OpenAccess applications and tests are already updated.

• OpenAccess to LEF Mapping Change

  The PREFERENCLOSURE statement now maps to a soft constraint in the FoundryRules constraint group, as opposed to a hard constraint in the LEFDefaultRouteSpec constraint group. Applications need to adjust their code accordingly.

Changes and New Features

zlib is Statically Linked to Translators

Several translators support reading files in the gzip format by using the zlib open source library. The translator executables delivered with OpenAccess previously linked to zlib as a shared library, which forces end users to download and install zlib on their machines. Unlike some other third-party components such as Tcl, the functionality provided by the zlib library is not directly exposed to end users, and there is no need to have multiple tools use the same version of zlib. The translator executables that read files in gzip format now link to zlib as a static library.

Translators are Built as Static Libraries

Previously, translator components were delivered as shared libraries, and both the translator executables and other applications linked to them dynamically. Unlike the public OpenAccess API, the interfaces into these translators are subject to change. These changes can affect applications that derive from the translator base classes, as well as applications that simply use the translator components as-is.

When new OpenAccess kits ship (including the translator shared libraries) applications need to use the kits with existing applications. A change to the translator API would break existing applications even though the OpenAccess core remains drop-in compatible.

All translators are now built as static rather than shared libraries. This allows applications to link to a fixed version of the translator API while supporting drop-in compatibility for new OpenAccess kits. In some cases, a bug fix requires both a change to the translator API and a co-dependent change to the OpenAccess kits. In that case, applications that link statically to a translator must be rebuilt in order to pick up part of the fix, and existing executables will not work properly with the new kits. To avoid these problems, the overall architecture for how applications use the translators must change. This issue is currently under consideration by the OpenAccess development team.

oa, oaCommon, and oaUtil Restructured

To improve efficiency, avoid inconsistencies between different versions of the modules, and to minimize obscure compilation errors and test failures, oaCommon and oaUtil are now packages within the oa module. The following figure shows the new structure:

Header files from oaCommon are still installed in the top level include/oa directory. Header files from oaUtil were previously installed in include/oaUtil. These are now installed in include/oa for consistency. This should not affect applications that use the translator components because those applications already depend on include/oa. Shared libraries from oaCommon are still installed in the top level lib/<platform>/<mode> directory, and DLLs are still installed in the top level bin/<platform>/<mode> directory. As part of the change to statically link the translator component libraries, oaUtil now installs static instead of shared libraries in the top level directory.

Tcl Package Support

The Tcl binding of OpenAccess supports the Tcl package command, which is preferred over the Tcl load command. Refer to Package Support for more information.

Dependencies for Building Applications on OpenAccess on Windows

OpenAccess depends on the Winsock2 socket technology, and therefore must include Winsock2.h.

If your code files contain #include <Windows.h> statements, adhere to the following rules.

• Place the include statement for the OpenAccess headers before any #include <Windows.h> statement.
  
  or
  
  
• Place the #include <WinSock2.h> statement before the #include <Windows.h> statement.

Note that most users do not specify #include <Windows.h> statements in their code files because OpenAccess code files already contain include statements for Windows.h.

Building the oa20to22 Translator

The following procedure explains how to build the oa20to22 translator.

1. Download the following kits for the platform you want:
   
   cdsCommon executable kit
   cdsCommon development kit
   OpenAccess development kit
   OpenAccess source kit
   
   
2. Expand these four kits in the same directory.
   
   
3. Refer to OpenAccess 2.2 Installation and Configuration Notes for information about how to build OpenAccess.
   
   
4. Set the environment variable OAHOME_2_0 to the directory that contains the expanded kits.
   
   
5. Add the directory that contains the cdsCommon executables (typically tools.<platformName>/bin) to your executable search path.

oa20to22 Translator Change

oa20to22 will now convert 1-bit wide vector objects into the corresponding bit objects. This means that explicit single-bit busNets, busTerms, and vectorInsts are converted into explicit busNetBits, busTermBits, and vectorInstBits.

LEF/DEF Translators Take a List of Files

Both lef2oa and def2oa now take a list of files now and process each file in the specified order. For multiple DEF files, if one DEF refers to one of the other specified DEF files (as COMPONENT), the translator handles this reference in any order. You can use a set of hierarchical DEF files without concern about the order of processing for the files.

lef2oa Translator Change

The lef2oa translator no longer overwrites the oaDesign for existing custom vias.

def2oa Translator Changes

• A -noRouting option is added to the def2oa translator to ignore all routing data and via sections during translation.
• The def2oa translator now sets the viaDirection for oaVias.
• Previously, the def2oa translator incorrectly added the LEF WIREEXTENSION value to path segments beginning or ending at vias. Now def2oa correctly adds a value of half of the width to path segments beginning or ending at vias. Note that this is the default DEF behavior.

Calculation of Width for Diagonal Segments by Def Translators

The DEF translators have been modified to correctly calculate the width of diagonal segments.

Stream Translator Change

oa2strm now translates the following oaTextDisplay objects:

• oaAttrDisplay
• oaPropDisplay
• oaTextOverride

These textDisplays are translated as labels and are written out as Stream TEXT records. The translation is asymmetric, and these objects return as oaText objects in a round-trip translation.

Note that oaInstAttrDisplay and oaInstPropDisplay are not translated.

The new command line options are as follows.

oa2spef

oa2spef suppresses grounded capacitors whose values are 0.0. If there are multiple values on the capacitor (from multiple analysis points), the capacitor is suppressed only if all the values are 0.0.

verilog2oa Translator

The verilog2oa translator has been updated to better handle expanding multi-bit connectivity. See Expanding Connectivity in the Verilog to OpenAccess Mapping document for details.

oaDefNS and oaSpefNS Namespace Changes

A name with a double vector notation (name[1][2]) now becomes a vectorBitName with the first bus notation escaped internally (name\[1\][2]).

A name with a bus notation in the middle of the name now becomes a scalarName with the bus notation escaped internally (name[1]a becomes name\[1\]a).

When getting the string from the name, the escaping is undone, so you get the original name back.

Default Parameters for Pcell References

The handling of default parameters for Pcell references (including instances and custom vias that are Pcells) has changed.

This change impacts getParams() calls to the following:

• oaCustomVia
• oaCustomViaHeader
• oaInst
• oaInstHeader,
• oaModDesignInst
• oaModInstHeader
• oaOccDesignInst
• oaOccInstHeader.

getParams() will now return any parameter that is explicitly specified on the instance regardless of whether or not its value equals the default value.

LPP and layerHeaders in Pcell superMasters

Previously, the LPP and layerHeaders in the Pcell superMaster were filtered out from the parent design that contained instances of the superMaster. This filter has been removed, and the result is that additional LPP and layerHeaders might appear in the parent design if LPP or layerHeaders are in the superMaster, but not in its subMasters.

Behavior Change for oaFig::copy and oaFig::move for Pcells

The behavior of oaFig::copy() and oaFig::move() has changed with regards to copying or moving an unbound Pcell instance across designs. The copy and move functions will now more closely match Pcell instance creation. Accordingly, the copy and move functions will force the master to load to ensure that the instHeader created in the destination design is consistent with the source. The exceptions oacCannotCopyPcellInst and oacCannotMovePcellInst are thrown if the master cannot be found.

Implementing Pcells Through Tcl (Beta Version)

OpenAccess implements Pcells in Tcl using the oaPcellScript and oaTclEngine plug-ins. The oaPcellScript plug-in is a Pcell evaluator that uses a scripting engine to interpret a content generation procedure written in a scripting language that supports the OpenAccess binding. Provided the necessary scripting engine, the Pcell evaluator can work with different types of scripting languages. The oaTclEngine is a scripting engine included with OpenAccess that provides the OpenAccess binding through the oaTcl shared library. The oaTclEngine plug-in supports Tcl version 8.4.1 or later.

For more information, see Implementing Pcells Through Tcl.

oaPcellScript Plug-In (Development Version)

Note that the oaPcellScript Plug-in is included in this release, but it is not ready for use and is still under development.

Documentation Change for oaNameMem::getValue()

The documentation for this function has been updated to state that this function is only intended for use by nameSpaces.

Unbinding Occurrence Hierarchies Has More Consistent Behavior

When an occurrence hierarchy or sub-hierarchy is unbound from the top occurrence hierarchy, OpenAccess now consistently removes the hierarchy from the occurrence domain. The public occObjects in the sub-hierarchy and the non-local occurrence hierarchies are destroyed, and the annotations in the occurrence domain are removed.

Uninstalling OpenAccess on UNIX Platforms

Uninstallers are no longer provided for UNIX platforms. Use the rm command instead:

% rm -r <install_dir> 

DM FileSys Plug-In

If DM FileSys cannot deterimine the viewType of a cellView, the cellView is ignored rather than throwing an exception.

New APIs

The following new APIs are available.

• The new oaScriptEngineLink class is a container class for IScriptEngine, which is the interface for a script engine.

• oaObject::hasProp()
  
  Returns a Boolean indicating whether or not this object has any attached properties.
  
  
• oaObject::hasAppDef()
  
  Returns a Boolean indicating whether or not this object has any associated appDef values.

• oaDouble oaVector::getCosAngle(const oaVector &v ) const
  
  Returns the cosine of the angle between this vector and the specified vector.

• oaFile::getCreateTime ( ) const
  
  Returns the creation time of the file on the disk.

• oaModNet::setSigType(oaSigType sigType)
  
  Changes the sigType on the modNet and all occurrences of the modNet.

• oaDesign::getParams(oaParamArray &params, oaBoolean includeDefaults) const
  
  Fills out the params value with the parameters attached to this design.
  
  
• oaOrient getRelativeOrient(const oaOrient &orient) const
  
  Returns the relative orientation required to transform this orientation to the specified target orientation 'orient'.
  
  
• oaVector::normalize()
  
  Normalizes this vector to a unit vector.

oaBoundary and Derived Classes

Due to code optimizations, the order in which points are returned for a rectangular boundary can differ from the order in which they were entered.

oaName Utility Classes

New operator== and operator!= methods are available on the oaName, oaBundleName, oaSimpleName, oaVectorName, oaVectorBitName, and oaScalarName utility classes. See the API documentation for more information.

oaTech Class

The following APIs have been added to the oaTech class:

• void oaTech::destroy(const oaScalarName &libName)

• void oaTech::destroy(oaLib *lib)

• oaLib* oaTech::getLib()

Functions that Take a Database Argument

All API's that take an oaObject *database now throw a common oacInvalidDatabase exception. Most of these functions previously threw individual exceptions.

Affected APIs

API Change Reports

View a summary  of the OpenAccess 2.2.2 update release changes with respect to 2.2.1.

Fixed Problems

Version 2.2.1

• New Features
• Compatibility with Earlier Releases
• API Changes
• Fixed Problems

Compatibility with Earlier Releases

• Most users will have to rebuild their tech DBs with the OpenAccess libraries and the lef2oa translator in this release for the following reasons.
  • Due to a bug fix, tech DBs that used the default values for User Units and DBUPerUU in 2.2.0 will now contain incorrect values.
  • The LEF mapping for routing rules has changed because these rules were previously placed in the wrong constraint group. In 2.2.1, the oa2lef translator expects this data to be in the LEFDefaultRouteSpec constraint group.
  • In 2.2.0 constraints placed in the foundry constraint group were incorrectly placed in the tech default constraint group.
  • Older versions of lef2oa incorrectly stored X pitch and offset values in the oacHorizontalRouteGridPitch and oacHorizontalRouteGridOffset constraints. Now X pitch and offset are correctly mapped to oacVerticalRouteGridPitch and oacVerticalRouteGridOffset. Y pitch and offset values were also incorrectly mapped and are now correctly mapped to oacHorizontalRouteGridPitch and oacHorizontalRouteGridOffset.
    
• Because new functions have been added in this release, the oacMinorRevNumber has been incremented. This means that programs compiled with the header files in this release cannot be used with OpenAccess shared libraries from previous 2.2 releases. Programs compiled with earlier versions of 2.2 will continue to run unchanged with the shared libraries in this release. For more information about the oacAPIMinorRevNumber, refer to oaDesign Initialization in the Programmers Guide.
• If you used oaFatal exceptions, you need to remove them and recompile your code. (Most applications do not use these exceptions.) See Removal of Fatal Exceptions for more information.

New Features

Translators

The lib, cell, and view names that you supply to the translators on the command line are now in the OpenAccess Native name space.

Spef Translators

The zlib library, which is required by the Spef translators, is no longer shipped with OpenAccess. For information about acquiring and setting up zlib, see the Installation Instructions.

Also, spef2oa now includes a -tolerate command-line option, which tolerates connectivity mismatches between the SPEF input and the target OpenAccess database. Usually, connectivity mismatches result in an error and processing stops. The –tolerate option reduces these errors to warnings, but some coupling capacitance may be dropped from the parasitic network. If the network cannot be properly connected due to connectivity problems with series devices (such as resistors), the entire network is ignored but processing continues. Note that the SPEF translator does not perform exhaustive node to node checking of the network connectivity. It is possible to construct networks that contain electrical opens regardless of whether this option is used.

Stream Translators

The Stream translators include a new -viaMap option to support inputting and outputting custom via mappings.

Custom Via Mapping File Syntax

# Comment
# Blank lines will be ignored
<Structure Name> <oaCustomViaDef Name> <Layer1 Name/Number> <Layer2 Name/Number> 

Example:

# Custom Via Master List for mydesign
via1 m1m2via m1 10 m2 20
via2 m2m3via m2 20 m3 30

oa2lef Translator

The PITCH, DIAGPITCH, and OFFSET constructs have been moved to the LEFDefaultRouteSpec constraint group. Previously generated tech databases are incompatible because oa2lef will no longer find these constructs in the foundry rules group.

LEF/DEF Mapping Changes

• The lef2oa mapping has changed. Older versions of lef2oa incorrectly stored X pitch and offset values in the oacHorizontalRouteGridPitch and oacHorizontalRouteGridOffset constraints. Now X pitch and offset are correctly mapped to oacVerticalRouteGridPitch and oacVerticalRouteGridOffset. Y pitch and offset values were also incorrectly mapped and are now correctly mapped to oacHorizontalRouteGridPitch and oacHorizontalRouteGridOffset.
• LEF vias are mapped to oaCustomViaDefs. If an existing oaStdViaDef is defined in the technology database with the same name, the oaCustomViaDef is renamed by appending _via. For example, <name> is renamed to <name>_via.
• def2oa searches for oaCustomViaDef <name>, oaCustomViaDef <name>_via, oaStdVia (not oaStdViaDef), and DEF VIA (a via defined locally in the DEF file); the search is performed in the order listed.

Wafer API Changes

Two new wafer functions have been added:

oaTimeStamp             getTimeStamp(oaWaferDataType    type) const;

oaTimeStamp             getTimeStamp(oaAppObjectDef     *def) const;

New Overload for oaCellView::setView

void oaCellView::setView(const oaView *view); // Already exists
void oaCellView::setView(const oaView *view, oaBoolean mustExist); // New overload 

These functions modify the cellView that is associated with the specified view.

oaCellView::setView(const oaView *view) accomplishes this by renaming the existing primary data in the cellView to be of the appropriate type. An exception is thrown if the non-primary data already exists in the cellView of the specified type.

oaCellView::setView(const oaView *view, oaBoolean mustExist) assumes the cellView already contains the appropriate type of data, but that it is not currently marked as the primary data for the cellView. This function makes this data primary. The original data is left in the cellView as non-primary data. The argument mustExist should be set to TRUE. If mustExist is set to FALSE, this function operates identically to the first version.

Note: To maintain drop-in compatibility, these functions are implemented separately, but will be merged together at a later date.

New Turbo DM System Attribute

See Turbo DM System in the Libraries and Design Management section of the Programmers Guide for more information.

FileSys File Locking Use Model

The file locking functionality for the FileSys DM system is fully documented. The lock recovery daemon is now called oaFSLockD.

See File Locking in the Libraries and Design Management section of the Programmers Guide for more information.

Constraints

The distance parameter has been added to the oacMinWireExtension constraint.

Default Compiler Environment

There has been a change to the default compiler environment path settings supplied with OpenAccess. See Default Compiler Environment for details.

Removal of Fatal Exceptions

The following fatal exception classes have been removed:

• oaFatal
• oaDesignFatal
• oaTechFatal
• oaDMFatal
• oaWaferFatal

OpenAccess does not throw exceptions using any of these objects, so they have been eliminated. The expectation is that clients are not using these class types to catch OpenAccess exceptions because OpenAccess does not throw these exception objects.

Almost all clients use the base oaException type in the catch block to get a copy or a reference of the thrown object. There should be no drop-in compatibility issues for these clients, and eliminating these classes now will prevent unnecessary confusion in the future.

Clients that have catch blocks to specially handle these fatal exception types should remove them.

API Changes

View a summary  of the OpenAccess 2.2.1 changes with respect to 2.2.0.

Fixed Problems

Return to top of page

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