OpenAccess 2.2.2

Contents

• Version 2.2.2
• Version 2.2.1

Note: For an overview of the new features available in 2.2.0, refer to What's New.

Version 2.2.2

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

Release Status

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

• Tcl interface
• Wafer database
• Milkyway to OpenAccess Translator
• Turbo DM System
• Tcl Pcells

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

Compatibility with Earlier Releases

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

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

  You must declare the prototypes in the beginning as follows:

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

  Then call them as follows:

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

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

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

• OpenAccess to LEF Mapping Change

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

Changes and New Features

zlib is Statically Linked to Translators

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

Translators are Built as Static Libraries

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

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

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

oa, oaCommon, and oaUtil Restructured

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

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

Tcl Package Support

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

Dependencies for Building Applications on OpenAccess on Windows

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

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

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

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

Building the oa20to22 Translator

The following procedure explains how to build the oa20to22 translator.

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

oa20to22 Translator Change

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

LEF/DEF Translators Take a List of Files

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

lef2oa Translator Change

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

def2oa Translator Changes

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

Calculation of Width for Diagonal Segments by Def Translators

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

Stream Translator Change

oa2strm now translates the following oaTextDisplay objects:

• oaAttrDisplay
• oaPropDisplay
• oaTextOverride

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

Note that oaInstAttrDisplay and oaInstPropDisplay are not translated.

The new command line options are as follows.

oa2spef

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

verilog2oa Translator

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

oaDefNS and oaSpefNS Namespace Changes

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

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

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

Default Parameters for Pcell References

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

This change impacts getParams() calls to the following:

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

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

LPP and layerHeaders in Pcell superMasters

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

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

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

Implementing Pcells Through Tcl (Beta Version)

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

For more information, see Implementing Pcells Through Tcl.

oaPcellScript Plug-In (Development Version)

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

Documentation Change for oaNameMem::getValue()

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

Unbinding Occurrence Hierarchies Has More Consistent Behavior

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

Uninstalling OpenAccess on UNIX Platforms

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

% rm -r <install_dir> 

DM FileSys Plug-In

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

New APIs

The following new APIs are available.

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

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

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

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

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

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

oaBoundary and Derived Classes

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

oaName Utility Classes

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

oaTech Class

The following APIs have been added to the oaTech class:

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

• void oaTech::destroy(oaLib *lib)

• oaLib* oaTech::getLib()

Functions that Take a Database Argument

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

Affected APIs

API Change Reports

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

Fixed Problems

Version 2.2.1

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

Compatibility with Earlier Releases

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

New Features

Translators

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

Spef Translators

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

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

Stream Translators

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

Custom Via Mapping File Syntax

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

Example:

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

oa2lef Translator

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

LEF/DEF Mapping Changes

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

Wafer API Changes

Two new wafer functions have been added:

oaTimeStamp             getTimeStamp(oaWaferDataType    type) const;

oaTimeStamp             getTimeStamp(oaAppObjectDef     *def) const;

New Overload for oaCellView::setView

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

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

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

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

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

New Turbo DM System Attribute

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

FileSys File Locking Use Model

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

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

Constraints

The distance parameter has been added to the oacMinWireExtension constraint.

Default Compiler Environment

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

Removal of Fatal Exceptions

The following fatal exception classes have been removed:

• oaFatal
• oaDesignFatal
• oaTechFatal
• oaDMFatal
• oaWaferFatal

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

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

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

API Changes

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

Fixed Problems

Return to top of page

Copyright © 2003-2005
All rights reserved.