OpenAccess 22.04.044 Release

Contents

• Version 22.04.044 Source Code and Documentation Release
• Version 22.04.042 Source Code and Documentation Release
• Version 22.04.039 Source Code and Documentation Release
• Version 22.04.037 Source Code and Documentation Release
• Version 22.04.034 Source Code and Documentation Release
• Version 22.04.028 Release
• Version 22.04.021 Source Code and Documentation Release
• Version 22.04.017 Source Code and Documentation Release
• Version 22.04.015 Source Code and Documentation Release
• Version 22.04.012 Source Code and Documentation Release
• Version 22.04.007 Source Code and Documentation Release

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

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

The following table shows the build configurations and prebuilt libraries shipped with OpenAccess.

If you build the LEF/DEF translators, refer to Prerequisites for Compiling LEF/DEF Translators on Windows.

The current data model revision is 4. The following table shows the contents of each data model revision.

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

The oacAPIMinorRevNumber has been incremented to 42.

oaLefDef API Changes (for Derived Translators)

View a summary of the oaLefDef changes for derived translators.

View a summary of the OpenAccess 22.04.044 changes with respect to the 22.04.042 release.

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

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

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

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

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

The following table shows the build configurations and prebuilt libraries shipped with OpenAccess.

If you build the LEF/DEF translators, refer to Prerequisites for Compiling LEF/DEF Translators on Windows.

The current data model revision is 4. The following table shows the contents of each data model revision.

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

The oacAPIMinorRevNumber remains 40.

Updated Makefile Targets

The makefile targets for compiling on UNIX Platforms (Solaris, IBM, and Linux) have been updated.

Previously, these targets were used when building the entire distribution (OA core packages and translators):

• install
• clean
• uninstall

In addition, these targets were used when building only the OA core packages:

• install_oa
• clean_oa
• uninstall_oa

The makefile target names have been changed to be more consistent.

Starting with this release, these targets are used when building the entire distribution (OA core packages and translators):

• install_all
• clean_all
• uninstall_all

In addition, these targets are used when building only the OA core packages:

• install
• clean
• uninstall

The old install_oa, clean_oa and uninstall_oa targets are still supported for backward compatibility. They are equivalent to the install, clean, and uninstall targets.

oaStrm API Changes (for Derived Translators)

View a summary of the oaStrm changes for derived translators.

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
• Tcl Pcells
• Turbo DM System
• Change Management System

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

• Build Configurations
• Compatibility with Earlier Releases
• API Changes
• Fixed Problems
• Incomplete Status

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

The following table shows the build configurations and prebuilt libraries shipped with OpenAccess.

If you build the LEF/DEF translators, refer to Prerequisites for Compiling LEF/DEF Translators on Windows.

The current data model revision is 4. The following table shows the contents of each data model revision.

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

The oacAPIMinorRevNumber remains 40.

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
• Tcl Pcells
• Turbo DM System
• Change Management System

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

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

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

The following table shows the build configurations and prebuilt libraries shipped with OpenAccess.

If you build the LEF/DEF translators, refer to Prerequisites for Compiling LEF/DEF Translators on Windows.

The current data model revision is 4. The following table shows the contents of each data model revision.

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

The oacAPIMinorRevNumber remains 40.

oaLefDef API Changes (for Derived Translators)

• Due to API changes in the oaLefDef package, derived translators must recompile their code.
• The oaLefDef package API changes affect the parsing of enclosure statements.
• View a summary of the oaLefDef changes for derived translators.

Optionally Building LEF/DEF Translators

If you want to build the LEF/DEF translators (which is optional), The lefdefInt05.70-s031 kits contain the latest bug fixes for UNIX platforms. For Windows, the latest kit is lefdefInt05.70-s031.

Prerequisites for Compiling LEF/DEF Translators on Windows

In order to compile the LEF/DEF translators, you must now set the OA_DEP_LIBS environment variable to point to the directory containing your LEF/DEF parser kits (lefdefInt). The default version of the LEF/DEF parser kits is specified in <install_dir>/build/MSVS/dep.vsprops. Modify this file if you need to override the default version.

Note: The OA_DEP_LIBS environment variable overrides any LEFDEF_HOME environment variables.

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
• Tcl Pcells
• Turbo DM System
• Change Management System

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

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

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

The following table shows the build configurations and prebuilt libraries shipped with OpenAccess.

If you build the LEF/DEF translators, refer to Prerequisites for Compiling LEF/DEF Translators on Windows.

The current data model revision is 4. The following table shows the contents of each data model revision.

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

The oacAPIMinorRevNumber has been incremented to 40.

OpenAccess Change Management System (CMS)

Note: This functionality is in beta status. The APIs are not guaranteed to be drop-in or compile-time compatible.

EDA flows often send data between different applications using batch interactions with on-disk files. However, as design and manufacturing issues become more complex and interdependent, a tighter and more incremental integration is needed between many analysis and optimization engines.

OpenAccess now provides a foundation for communicating design data that enables fine-grained collaboration between multiple processes operating on the same design. OpenAccess defines a plug-in based infrastructure that lets software developers create plug-ins for incremental data exchange between cooperating applications. Schema definitions are provided for all the managed objects in OpenAccess to support the data exchange. The complete infrastructure is called the OpenAccess change management system (CMS).

OpenAccess does not provide any production CMS plug-ins, and it does not specify a format for the data to be exchanged. The infrastructure described here requires an application to have access to CMS plug-ins provided by a 3rd party. For information about creating such plug-ins, refer to How to Write Change Management System (CMS) Plug-Ins.

Incremental Data Exchange

The OpenAccess CMS infrastructure provides a standard way for an application to select and configure the plug-ins used to exchange data between applications. The application is not required to have built-in knowledge of any individual plug-in. The application need only know how to follow the protocol specified by the OpenAccess API to provide the plug-in names and other configuration details that are known to the user.

The following example shows two applications using the OpenAccess CMS infrastructure to exchange information about incremental changes to a given design.

An end user of Application 1 starts the process by issuing a command to begin recording changes to the designs. At this point, the tracking plug-in can prompt the user to specify what sort of data should be tracked and what format should be used for recording the changes. The tracking plug-in creates a change set, which is a container for individual changes. The tracking plug-in adds each individual change, known as a change record, to the set and continues with this until the user issues a command to end change tracking.

When it is time to export the data for use by another application, the end user issues a command to initialize the appropriate export plug-in and export the changes. The export plug-in produces a file in a predetermined format that contains the information about the changes.

In application 2, the end user initializes the import plug-in and issues a command to import the changes. The import plug-in verifies that the changes are safe to apply, then applies them to the in-memory representation of the design.

Application 2 can also modify the design and export the changes back to Application 1.

For more information about CMS and the associated APIs, OpenAccess schema definitions, writing CMS plug-ins, and observers related to CMS, refer to the following documents.

• Change Management System (CMS)
• Change Management System (CMS) Class Index
• How to Write Change Management System (CMS) Plug-Ins
• Scoped Observer Notifications in the Programmers Guide
• Creating Schema Definitions

Remastering Design Instances

OpenAccess now lets applications remaster all the instances of a design with one function call:

static void oaInstHeader::setMaster(oaInstHeader          *header   
                                    const oaDesign        *master,   
                                    const oaParamArray    *parameters = NULL);

Where:

• header is the oaInstHeader for the instances to be remastered.
• master is the oaDesign that will become the new master for the instances.
• parameters is an optional parameter array for the new master.

After a remaster operation, the original oaInstHeader is destroyed and the oaInstHeader for the target oaDesign is used to group the instances. When the source or target master is a Pcell, OpenAccess must perform some conversions between parameters and properties as part of the remaster operation. For more information, refer to Remastering Instances in the Support for Pcells document in the Programmers Guide.

Note that the oaInst::setParams and oaInst::setMaster functions have been modified to use the parameter and property conversions described in the above document. The oaInst::setParams function will throw an exception if the provided parameters do not match those of the superMaster.

OpenAccess Documentation Now Includes Flash Animations

The OpenAccess documentation now includes Flash animations. The Remastering Instances section of the Support for Pcells document in the Programmers Guide includes two flash animations that explain the results of remastering design instances to Pcell superMasters.

New oaAppProp::setAppType Function

A new oaAppProp::setAppType function sets the application type for a property. The application type is interpreted by the application, not OpenAccess.

New Observers for Undo and Redo Operations

Two new classes provide observer notifications for undo and redo operations:

• oaDesignUndoObserverBase
• oaDesignUndoObserver

New Observer Notifications of Existing ModTypes

There are several new notifications of existing modTypes to provide previously missing behavior:

The oaGuideModTypeEnum now includes:

• oacAddToRouteGuideModType
• oacRemoveFromRouteGuideModType

The oaShapeModTypeEnum now includes:

• oacAddToRouteShapeModType
• oacRemoveFromRouteShapeModType
  

The oaViaModTypeEnum now includes:

• oacAddToRouteViaModType
• oacRemoveFromRouteViaModType

New Values Added to oaLayerModTypeEnum

The following values have been added to oaLayerModTypeEnum:

• oacSetPeakACCurrentDensityLayerModType
• oacSetAvgACCurrentDensityLayerModType
• oacSetRmsACCurrentDensityLayerModType
• oacSetAvgDCCurrentDensityLayerModType
• oacDerivedLayerSetParamsLayerModType value is added to oaLayerModTypeEnum.

One way in which these values might be used in the future is for issuing observer notifications when setting parameters on a derived layer.

Note: The oaDerivedLayerModTypeEnum is now deprecated.

New oaTechConflictType Enum Wrapper Class

The oaTechConflictType class is an enum wrapper class for oaTechConflictTypeEnum values.

New Translator Features

New Option for Specifying a Named LEFDefaultRouteSpec

Previously, the lef2oa translator issued an error when attempting to create a technology database with a LEFDefaultRouteSpec constraint group that referenced another technology database with its own LEFDefaultRouteSpec constraint group. The current version of lef2oa has been enhanced to better support incremental technology databases.

The lef2oa translator now checks whether or not a LEFDefaultRouteSpec constraint group already exists in the graph of techs. If it does exist, lef2oa generates a constraint group of the constraintGroupDef type LEFDefaultRouteSpec with a name in the format of LEFDefaultRouteSpec_<libName> and provides a message to the user. 

In addition, the translator provides a new option for specifying the name of the LEFDefaultRouteSpec that will be generated. The new option is as follows:

 [-defaultRuleName name] 

Note: If a constraint group named LEFDefaultRouteSpec already exists in a technology database being modified, the translation fails unless the -overwrite option is used. Also, the oa2lef translator looks for the LEFDefaultRouteSpec in the current technology database by constraintGroupDef type first. If not found, the translator looks for a LEFDefaultRouteSpec by name.

Refer to LEF to OpenAccess Translator (lef2oa) for more information.

Information for Derived Translators

oaVerilog API Changes (for Derived Translators)

The CallbacksIn class member functions fitNet() and widthWarning() are revised to provide more details about the source of a warning or error. The Error class is extended to store the context of errors and warnings so applications can use the context for improved error handling.

Refer to Summary of API Changes for more information.

oaLefDef API Changes (for Derived Translators)

• Due to API changes in the oaLefDef package, derived translators must recompile their code.
• The oaLefDef package API changes correct the output of polygons for vias and incorporate LEFDefaultRouteSpec changes.
• View a summary of the oaLefDef changes for derived translators.

Optionally Building LEF/DEF Translators

If you want to build the LEF/DEF translators (which is optional), The lefdefInt05.70-s031 kits contain the latest bug fixes for UNIX platforms. For Windows, the latest kit is lefdefInt05.70-s031.

Prerequisites for Compiling LEF/DEF Translators on Windows

In order to compile the LEF/DEF translators, you must now set the OA_DEP_LIBS environment variable to point to the directory containing your LEF/DEF parser kits (lefdefInt). The default version of the LEF/DEF parser kits is specified in <install_dir>/build/MSVS/dep.vsprops. Modify this file if you need to override the default version.

Note: The OA_DEP_LIBS environment variable overrides any LEFDEF_HOME environment variables.

View a summary of the OpenAccess 22.04.034 changes with respect to the 22.04.028 release.

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

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

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

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

This is a full release that includes binary files as well as source code and documentation. This release is the first to contain binaries for the IBM AIX 5.3 platform (IBM 5.1 binaries are no longer included).

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

The following table shows the build configurations and prebuilt libraries shipped with OpenAccess.

If you build the LEF/DEF translators, refer to Prerequisites for Compiling LEF/DEF Translators on Windows.

The current data model revision is 4. The following table shows the contents of each data model revision.

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

The oacAPIMinorRevNumber has been incremented to 39.

Note that applications compiled on AIX that used OpenAccess versions prior to 22.04.021 must recompile their applications if they use 22.04.021 or later. This requirement is due to the switch to the AIX 5.3 compiler. Applications must also change their library search path to pick up the 5.3 shared libraries.

Refer to the Autosave and Critical-Save section for a potential compatibility issue related to new oaDMFiles in the oaCellView container.

oaPurpose Reserved Types

The OpenAccess built-in purposes have a corresponding range of purpose numbers, which are from 0xffff0000 to 0xffffffff, inclusive. Applications cannot create custom purposes that use purpose numbers in this reserved range. If an older database is loaded by an application that uses shared libraries based on data model 4 or later, any missing built-in purposes are added.

In previous releases, if an older database included a user-defined purpose that used a reserved purpose number, and that database was read by newer OpenAccess shared libraries, all user-defined purposes in the reserved range were removed from the database. In the current release, only the specific user-defined purpose with the conflict is removed.

New oaBundleNet and oaBusNetDef Members

oaBundleNet::getOccMembers, oaBusNetDef::getOccBusNetBits, and oaBusNetDef::getOccBusNets functions enable applications to get a collection of nets in a lower level of hierarchy using a path name in the block domain. In addition, existing functions are enhanced to support:

• Creating nets using a hierarchical name
• Changing the name of a hierarchical net
• Finding a multi-bit net given the actual path names of its members

New oaNet::create and oaNet::find Function Behaviors

Previously, the create functions threw an exception if an hierarchical name was supplied. Now, create functions succeed if given an hierarchical name. The behavior of find functions is also changed. Previously, if find was called with an hierarchical name, NULL was returned even though the name matched an oaOccNet that was in the span of a net reflected in the block domain. Now when an hierarchical name is supplied, if there is an oaOccNet with the given name, find returns a pointer to corresponding oaNet in the block domain. The name that is returned may not be the same as the name that is supplied. For example, if oaScalarNet::find(const oaBlock block, const oaScalarName name) is supplied an hierarchical name that identifies an oaOccScalarNet in the occurrence domain, the specified name is considered an alias, and the corresponding oaNet of the oaOccNet is returned.

New oa2strm Translator Option

The oa2strm translator now provides a -textHeight option to specify the text height for labels.

oaStrm API Changes (for Derived Translators)

Due to API changes in the oaStrm package, derived Stream translators must adapt their code and recompile. The oaStrm API changes are summarized as follows:

• For performance reasons, the close(oaDesign *design) function has been replaced with close(Structure *structIn, oaDesign *design)
• Enhancements have been made for the via detection and save as functionality.

View a summary of the oaStrm changes for derived translators.

Optionally Building LEF/DEF Translators

If you want to build the LEF/DEF translators (which is optional), The lefdefInt05.70-s025 kits contain the latest bug fixes for UNIX platforms. For Windows, the latest kit is lefdefInt05.70-s019.

Prerequisites for Compiling LEF/DEF Translators on Windows

In order to compile the LEF/DEF translators, you must now set the OA_DEP_LIBS environment variable to point to the directory containing your LEF/DEF parser kits (lefdefInt). The default version of the LEF/DEF parser kits is specified in <install_dir>/build/MSVS/dep.vsprops. Modify this file if you need to override the default version.

Note: The OA_DEP_LIBS environment variable overrides any LEFDEF_HOME environment variables.

View a summary of the OpenAccess 22.04.028 changes with respect to the 22.04.021 release.

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

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

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

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

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

The following table shows the build configurations and prebuilt libraries shipped with OpenAccess.

The current data model revision is 4. The following table shows the contents of each data model revision.

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

The oacAPIMinorRevNumber has been incremented to 38.

Refer to the Autosave and Critical-Save section for a potential compatibility issue related to new oaDMFiles in the oaCellView container.

Supported Platforms and Compilers for OpenAccess Pre-Compiled Libraries

• OpenAccess no longer supports the Linux Redhat Enterprise 2.1 (gcc 3.2.3) platform. OpenAccess continues to support the Linux Redhat Enterprise 3.0 platform compiled with gcc 4.1.1, but a version compiled with gcc 3.2.3 is no longer provided.
• OpenAccess now supports IBM Operating System: AIX 5.3 with the XL C++ 7.0 compiler.
  
  • AIX 5.1 is no longer supported. The AIX 5.3 libraries are not drop-in compatible with respect to the AIX 5.1 libraries, so applications that compiled against AIX 5.1 versions (22.04.017 and earlier) must recompile.
• The Solaris x86_64 version of OpenAccess now includes the C++ standard template libraries (STLPort4).

Third-Party Packages

The paths to the external packages Bison, Flex++, Tcl, and zlib used in the compilation process have changed. The new paths are constructed as follows:

  $(OPTDIR)/<package>/v<package_version>[_64]    

Corresponding package version macros have been defined as <package>_VERSION.

For example:

  FLEX_VERSION := 2.5.4a                    
  FLEX_HOME := $(OPTDIR)/flex/v$(FLEX_VERSION)/

The default Tcl version has been updated to version 8.4.6. The TCL_HOME path now defaults to $(OPTDIR)/tcltk/v8.4.6.

Block Domain Overrides

Because OpenAccess automatically maintains the correspondence between the EMH domains, decisions made during the logical specification can restrict the physical implementation, and changing the physical implementation can change the logical specification unless there are mechanisms to break the correspondence.

A global net created in the module domain is, by default, also added to the block domain. Connections that are made to this net are visible in both the block and the module domains. When the net is physically implemented, it might be necessary to implement it as separate but related nets that are logically equivalent but physically disjoint. If the application disconnects the net from an oaInstTerm in the block domain to substitute one of the physical-only nets, the corresponding oaModInstTerm is also disconnected in the module domain, changing the logical representation of the design. In some methodologies, changing the logical design is acceptable, but other design methodologies treat the module and block domains as separable.

To allow implementations of power and ground in the block domain to differ from the logical specification, OpenAccess now provides a means for removing objects in the block domain without reflecting the changes to the module domain. This process of removing an object from the block domain without reflecting the change to the module domain is called hiding.

Designs sometimes require altering the power, ground, and tie connectivity specification that is reflected from the module domain by hiding the corresponding objects in the block domain and effectively removing the objects and connectivity in that domain. Physical-only objects are then created for the power, ground, and tie networks, which do not reflect a corresponding object in the module domain. Physical-only objects can replace the hidden objects and define the physical implementation for connecting the power, ground, and tie networks. The physical-only objects that replace hidden objects are called overriding objects. To create physical-only objects, set the oaBlockDomainVisibilityEnum parameter to oacExcludeFromModuleDomain at creation time.

For more information, refer to Block Domain Overrides and Creating Physical-Only Objects in the Programmers Guide.

New Block Overrides Example

A new block overrides example shows how to perform physical implementation of tie-off nets in the block domain. The program opens a design and replaces all oaTerms and oaInstTerms on tie-high nets with block domain overrides on net vdd. If the net vdd already exists, it is used, otherwise a physical-only version is created. The example is a command line program that takes three arguments for library, cell, and view.

For more information, refer to API Programming Examples in the Programmers Guide.

Change to Supported Connectivity

A connection from a physical-only oaTerm or oaInstTerm to a net across a module boundary is no longer allowed and exceptions are thrown:

• oacPhysOnlyTermNetMustBeInSameOcc
• oacPhysOnlyInstTermNetMustBeInSameOcc

Autosave and Critical-Save Now Supported

OpenAccess now provides functionality to support the automatic and critical saving of databases for applications using the FileSys DM System. Applications can support the auto-saving of designs at regular intervals and can provide critical saving of designs when the application crashes (for example, if they trap a kill signal). The application can also recover these autosaved and critical-saved databases.

The following function saves an oaDesign and creates the side files needed for recovering the state of the design.

oaDesign::save(oaSaveRecoverType type)

There are similar functions for oaTech and oaDMData objects. The new oaSaveRecoverType enumerated type provides the oacAutoSaveRecoverType and oacCriticalSaveRecoverType enum values for specifying the type of save that is occurring.

The oaDesign and oaTech classes, as well as oaDMData and its derived classes also have functions to destroy and recover objects based on the oaSaveRecoverType enum value. The oaDMFile class has a function to destroy objects based on the oaSaveRecoverType enum value. In addition, these classes provide functions for gathering information about objects with regards to their oaSaveRecoverType value.

It is the responsibility of the application to decide when to issue autosave or critical-save commands, as well as when to recover the state of a design.

Refer to the documentation for these functions for details.

Compatibility Notes: This functionality adds new types of files within the FileSys cellview directory. In the current release, OpenAccess can filter out these files as well-known (as is the case with temporary files). However, these new files will show up as additional oaDMFiles in the oaCellView container when running with older OpenAccess shared libraries. This is potentially a compatibility concern.

OA_PLUGIN_PATH Environment Variable

Plug-in developers can use a new OA_PLUGIN_PATH environment variable to specify the location of their plug-ins. This environment variable specifies an ordered list of locations that OpenAccess should search for plug-in files. OpenAccess uses the first matching file found. By default, the data/plugins directory is searched last.

Refer to How to Write a Plug-In for more information.

New oaStringArray Class

A new oaStringArray class implements an array of strings.

Boundary Class Functions Accept an oaStringArray of Edge Names

In previous releases, boundary class functions accepted a string array pointer for the edgeNames argument. In the current release, edgeNames can be provided as oaStringArrays. This change is applicable to any oaBoundary or derived class function that accepts an edgeNames argument.

Note that the older versions of these functions that accept a pointer to a string array are considered deprecated.

New oaByteArray Class

The new oaByteArray class implements an array of bytes.

oaAppProp Functions Accept an oaByteArray for Property Values

The oaAppProp::create, getValue, and setValue functions now accept an oaByteArray argument for the property values. Note that older version of these functions that accept a pointer to an oaByte array are considered deprecated.

oaAntennaData Set Functions

The oaAntennaData class now provides set prefixed functions for specifying attributes. For example, setGate() and setDiff(). Note that in previous releases, non const functions such as gate() and diff() were used to specify attributes. These older functions are now considered deprecated.

Const Versions of Functions

Several functions are deprecated in favor of const versions. The affected functions are as follows:

• oaAppDef::getName
• oaBlockageType::getName
• oaPinConnectMethod::getName
• oaRouteMethod::getName
• oaTermType::getName
• oaTimer::getElapsed

oaTechHeader::getRefLibName() Function Added

Applications can get the simple string name of a tech database in one call using the getRefLibName() function.

New Value Added to oaReservedViewTypeEnum

A new oaReservedViewType enum, named oacSystemVerilogText, is added. An oaViewType of oacSystemVerilogText has the equivalent string representation of systemVerilogText.

Translator Changes

oa2spef Translator Change

The -noInternalCoords option is added to the oa2spef translator to suppress coordinates for internal nodes.

LEF/DEF Mapping Changes

lef2oa Maps Multiple LEF ENCLOSURE Statements to Separate Constraints

The lef2oa translator maps multiple ENCLOSURE statements to separate constraints that are ordered in a precedence constraint group. Each ENCLOSURE statement without WIDTH maps to a separate constraint. However, if two or more statements for the same layer have the same parameters, they map to a single constraint. All constraints with width are stored using an oacDualIntTblValue based on width (in previous releases, constraints were stored using an oacDualIntValue and a width parameter). Constraints without width use an oacDualIntValue.

In the following example a, b and e are set in three separate constraints with an oacDualIntValue. c,d and f are set in the same constraint with an oacDualIntTblValue.

  ENCLOSURE 0.05 0.05 ; # a  
  ENCLOSURE 0.02 0.07 ; # b  
  ENCLOSURE 0.10 0.10 WIDTH 1.0 ; # c 
  ENCLOSURE 0.20 0.20 WIDTH 2.0 ; # d  
  ENCLOSURE 0.05 0.0 LENGTH 0.7 ; # e  
  ENCLOSURE 0.50 0.50 WIDTH 2.0 EXCEPTEXTRACUT 0.3 ; # f  

The precedence is as follows:

• Width and cut distance (#f)
• Width (#c, #d)
• Length (#e)
• Non-width qualified (#a, #b)

Forward LAYER References in Cut Layer SPACING Rules

All forward LAYER references in cut layer SPACING rules are now supported (in OpenAccess data model revision 4).

Changes for Derived Translators

Optionally Building LEF/DEF Translators

If you need to build the LEF/DEF translators (which is optional), the lefdefInt05.70-s020 (or later) kits are now required in order to get the most current warning messages.

oaLefDef API Changes (for Derived Translators)

• The LefDefOut::getGenVia function is replaced by LefDefOut::getViaName, which handles oaCustomVias that are pCell instances. The getViaName function generates unique names for each pCell variant. Any occurrences of the getGenVia function must be replaced by the getViaName function to get this important bug fix.
• In the oaLefDef package, some functions have been removed, split, or renamed in order to more closely match the LEF and DEF syntax.
• API changes were made to support mapping multiple LEF ENCLOSURE statements to separate constraints.
• View a summary of the oaLefDef changes for derived translators.

oaStrm API Changes (for Derived Translators)

• Due to API changes in the oaStrm package, derived Stream translators must recompile – not just relink – with this release. Note that the API changes do not affect the behavior of the translator.
• To make the APIs consistent, the translateInsts functions now take an oaDesign instead of an oaBlock.
• View a summary of the oaStrm changes for derived translators.

View a summary of the OpenAccess 22.04.021 changes with respect to the 22.04.017 release.

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

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

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

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

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

The following table shows the build configurations and prebuilt libraries shipped with OpenAccess.

The current data model revision is 4. The following table shows the contents of each data model revision.

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

The oacAPIMinorRevNumber remains 37.

New oa2strm Functions (for Derived Translators)

The oa2strm translateInsts() and translateVias() functions now include arguments to specify the design. These revised functions support passing the design name in the log file message if warnings and errors occur. For derived translators, source code must be updated and recompiled to include this support.

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
• Tcl Pcells
• Turbo DM System

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

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

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

The following table shows the build configurations and prebuilt libraries shipped with OpenAccess.

The current data model revision is 4. The following table shows the contents of each data model revision.

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

The oacAPIMinorRevNumber remains 37.

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

Compatibility Issue for Code that Uses the std::string Class

The fix for ITS issue 1082 removed the statement using std::string from one of the OpenAccess header files. If your application code contains statements such as string msg("Message") that rely on the using statement in the OpenAccess header file, you need to update your code. For example, add a similar using statement to your code or use statements such as std::string msg("Message").

Solaris (x86_64)

The Solaris x86_64 version of OpenAccess now includes the C++ standard template libraries (STLPort4).

Third-Party Packages

The paths to the external packages Bison, Flex++, Tcl, and zlib used in the compilation process have changed. The new paths are constructed as follows:

  $(OPTDIR)/<package>/v<package_version>[_64]    

Corresponding package version macros have been defined as <package>_VERSION.

For example:

  FLEX_VERSION := 2.5.4a                    
  FLEX_HOME := $(OPTDIR)/flex/v$(FLEX_VERSION)/

The default Tcl version has been updated to version 8.4.6. The TCL_HOME path now defaults to $(OPTDIR)/tcltk/v8.4.6.

lef2oa Maps Multiple LEF ENCLOSURE Statements to Separate Constraints

lef2oa maps multiple ENCLOSURE statements to separate constraints that are ordered in a precedence constraint group. However, if two or more statements for the same layer have the same parameters, they map to a single constraint. Each ENCLOSURE statement without WIDTH maps to a separate constraint. All constraints are stored using an oacDualIntTblValue based on width, except single constraints without width use an oacDualIntValue.

In the following example a, b and e are set in three separate constraints with an oacDualIntValue. c,d and f are set in the same constraint with an oacDualIntTblValue.

ENCLOSURE 0.05 0.05 ; # a
ENCLOSURE 0.02 0.07 ; # b
ENCLOSURE 0.10 0.10 WIDTH 1.0 ; # c
ENCLOSURE 0.20 0.20 WIDTH 2.0 ; # d
ENCLOSURE 0.05 0.0 LENGTH 0.7 ; # e
ENCLOSURE 0.50 0.50 WIDTH 2.0 EXCEPTEXTRACUT 0.3 ; # f

The precedence is as follows:

• Width and cut distance (#f)
• Width (#c, #d)
• Length (#e)
• Non-width qualified (#a, #b)

New Behavior When Setting Attributes on Multi-bit Objects

Background: Setting an attribute on a multi-bit object usually results in setting the attribute on its members and bits. In the case of nets, the attributes can be set on implicit nets as well.

For consistency, the behavior has changed when setting the attribute on a multi-bit object where setting the attribute only affects its implicit members and bits. Pre-existing, explicitly created members and bits are not changed if pre-existing implicit members and bits are updated.

This behavior change extends to when objects are created that overlap other, already existing objects and the attribute is specified at creation time. For example, if net bus[0:4] is created with sigType “analog” and bus[2:6] is created later, the bits bus[2], bus[3], and bus[4] are assigned the default “signal” sigType, instead of retaining the “analog” sigType. However, if bit bus[2] was first created with sigType “analog” and bus[2:6] was later created with sigType “scan”, the bus[2] would retain its sigType “analog” while bits bus[3] through bus[6] would be assigned sigType “scan”.

When a multi-bit net is destroyed and an implicit member or bit survives, because it is a member of another multi-bit net, the attributes on the surviving member/bit are updated from the other multi-bit owner. For example, consider the previous example with bus[0:4] with sigType “analog” and bus[2:6] with sigType “signal”; the bits bus[2], bus[3], and bus[4] also have sigType “signal”. If bus[2:6] were deleted, the bits bus[2], bus[3], and bus[4] remain since they are members of bus[0:4} and they be assigned the sigType “analog” to match.

The following table lists examples of the different attributes of nets and indicates whether those attributes can be set on explicit nets, implicit nets, or both. For each of the objects listed, the attributes apply to both the object and the bits of that object.

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
• Tcl Pcells
• Turbo DM System

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

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

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

The current data model revision is 4. The following table shows the contents of each data model revision.

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

The oacAPIMinorRevNumber was incremented to 37 due to the change to the oaObserver<oaScanChainInst> oaScanChainInstModTypeEnum values. If your code uses the oaObserver<oaScanChainInst> observers, you need to recompile your code in this release. See Observer Changes for more information.

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

Enhanced Scan Chain Functionality

Observer Changes

The oaScanChainSet class has been updated to issue standard observer notifications.

In addition, the existing oaObserver<oaScanChainInst> observer has more useful notification messages. The new enum values for oaScanChainInstModTypeEnum are as follows:

• oacSetInInstTermScanChainInstModType
• oacSetOutInstTermScanChainInstModType
• oacSetInstTermsScanChainInstModType
• oacScanChainSetScanChainInstModType
• oacSetSeqBitLenScanChainInstModType

The following oaScanChainInstModTypeEnum enum values were eliminated in favor of the more useful messages (shown above).

• oacNextInstScanChainInstModType
  
• oacAddInTermScanChainInstModType
  
• oacAddOutTermScanChainInstModType
  
• oacRemoveInTermScanChainInstModType
  
• oacRemoveOutTermScanChainInstModType

New Exceptions for oaScanChainInst functions

In previous releases, it was possible for an oaInstTerm to be on multiple scan chains. In the current release, an oacInstTermAlreadyInScanChain exception is thrown if an attempt is made to call one of the following functions with an oaInstTerm that is already part of a scan chain.

• oaScanChainInst::setInstTerms
• oaScanChainInst::setInInstTerm
• oaScanChainInst::setOutInstTerm
• oaScanChainInst::create

In addition, the previous four functions throw an oacScanChainInstTermsNotOnSameInst exception if an attempt is made to specify input or output oaInstTerms that are not on the same instance.

Supported Platforms and Compilers for OpenAccess Pre-Compiled Libraries

OpenAccess no longer supports the Linux Redhat Enterprise 2.1 (gcc 3.2.3) platform.

OpenAccess continues to support the Linux Redhat Enterprise 3.0 platform compiled with gcc 4.1.1, but a version compiled with gcc 3.2.3 is no longer provided.

New Value Added to oaReservedViewTypeEnum

A new oaReservedViewType enum, named oacSystemVerilogText, is added. An oaViewType of oacSystemVerilogText has the equivalent string representation of systemVerilogText.

View a summary  of the OpenAccess 22.04.012 release changes with respect to the 22.04.007 release.

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

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

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

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

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

This is the first release of data model revision 4.

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

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

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

The release includes the following:

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

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

xx.yy.zzz 

Where:

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

The current OpenAccess release is named OpenAccess 22.04.007.

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

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

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

The following new value types are defined:

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

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

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

New Examples for Constraints

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

The Constraints1 example demonstrates how to:

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

The Constraints2 example demonstrates how to:

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

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

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

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

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

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

New Built-In Purpose Types and Values

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

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

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

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

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

New Constraint Parameter Types

The following new constraint parameter types are defined.

New Constraint Parameter Value Enums

The following enums are added for use with constraint parameters:

• oaConnectivityTypeEnum
• oaShapeAngleTypeEnum
• oaSpacingDirectionTypeEnum
• oaGateOrientationType

Modified Constraint Parameter Value Enum Values

The oaWidthLengthTableTypeEnum parameter value enum is extended to include oacTwoWidthParallelRunLengthTableType.

OpenAccess provides constraint group definitions (oaConstraintGroupDefs) that specify the definitions of constraint groups (oaConstraintGroups). The constraint group definition contains a name, a type, a list of databases in which the constraint group can be created, a list of objects (by type) to which the constraint applies, a relationship type, and an indicator of whether or not there can be only one constraint group that uses this definition in any given database. 

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

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

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

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

Operators for Constraint Groups

Constraint groups can be created with the following operators.

Refer to oaConstraintGroupOperator for more information.

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

New Blockage and Halo Objects

The following new blockage and halo classes are available.

New soft Attribute on oaAreaBlockage and oaAreaHalo Objects

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

Specifying Input Taper Rules Within a Halo

OpenAccess lets applications specify:

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

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

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

New Process Family information for Technology Databases

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

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

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

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

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

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

Excluding Incompatible Layers

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

The following APIs support the layer exclusion capability.

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

oaLayer::setNumber and oaPurpose::setNumber Changes

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

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

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

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

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

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

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

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

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

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

oaCustomVia and oaStdVia Binding Issues Resolved

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

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

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

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

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

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

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

New isBuiltIn Functions

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

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

Added oaViaParam::isEqual() API

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

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

Behavior Change for oaObserver<oaConstraint>

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

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

Region Query Changes

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

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

Cached Pcell subMasters

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

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

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

oaDMPlugInError Class Changes

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

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

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

For example, instead of throwing this exception:

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

Debuggable Libraries

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

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

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

Compiling OpenAccess

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

gmake clean
gmake install
    

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

Updates to Visual Studio 2005 Files

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

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

_SECURE_SCL=0 
_SECURE_ATL=0

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

Enhanced Via Support in Stream Translator

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

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

Optionally Building LEF/DEF Translators

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

oaLefDef API Addition (for Derived Translators)

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

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

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

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

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

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

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

This is the first release of data model revision 4.

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

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

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

The release includes the following:

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

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

xx.yy.zzz 

Where:

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

The current OpenAccess release is named OpenAccess 22.04.007.

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

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

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

The following new value types are defined:

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

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

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

New Examples for Constraints

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

The Constraints1 example demonstrates how to:

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

The Constraints2 example demonstrates how to:

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

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

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

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

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

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

New Built-In Purpose Types and Values

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

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

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

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

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

New Constraint Parameter Types

The following new constraint parameter types are defined.

New Constraint Parameter Value Enums

The following enums are added for use with constraint parameters:

• oaConnectivityTypeEnum
• oaShapeAngleTypeEnum
• oaSpacingDirectionTypeEnum
• oaGateOrientationType

Modified Constraint Parameter Value Enum Values

The oaWidthLengthTableTypeEnum parameter value enum is extended to include oacTwoWidthParallelRunLengthTableType.

OpenAccess provides constraint group definitions (oaConstraintGroupDefs) that specify the definitions of constraint groups (oaConstraintGroups). The constraint group definition contains a name, a type, a list of databases in which the constraint group can be created, a list of objects (by type) to which the constraint applies, a relationship type, and an indicator of whether or not there can be only one constraint group that uses this definition in any given database. 

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

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

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

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

Operators for Constraint Groups

Constraint groups can be created with the following operators.

Refer to oaConstraintGroupOperator for more information.

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

New Blockage and Halo Objects

The following new blockage and halo classes are available.

New soft Attribute on oaAreaBlockage and oaAreaHalo Objects

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

Specifying Input Taper Rules Within a Halo

OpenAccess lets applications specify:

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

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

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

New Process Family information for Technology Databases

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

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

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

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

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

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

Excluding Incompatible Layers

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

The following APIs support the layer exclusion capability.

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

oaLayer::setNumber and oaPurpose::setNumber Changes

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

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

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

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

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

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

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

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

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

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

oaCustomVia and oaStdVia Binding Issues Resolved

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

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

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

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

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

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

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

New isBuiltIn Functions

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

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

Added oaViaParam::isEqual() API

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

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

Behavior Change for oaObserver<oaConstraint>

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

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

Region Query Changes

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

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

Cached Pcell subMasters

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

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

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

oaDMPlugInError Class Changes

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

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

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

For example, instead of throwing this exception:

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

Debuggable Libraries

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

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

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

Compiling OpenAccess

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

gmake clean
gmake install

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

Updates to Visual Studio 2005 Files

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

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

_SECURE_SCL=0 
_SECURE_ATL=0

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

Enhanced Via Support in Stream Translator

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

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

Optionally Building LEF/DEF Translators

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

oaLefDef API Addition (for Derived Translators)

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

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

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

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

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

Return to top of page

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