OpenAccess 2.2 P028 Source Code and Documentation Release

Contents

• Version 2.2 P028 Source Code and Documentation Release
• Version 2.2.3
• 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 P028 Source Code and Documentation Release

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

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

Release Status

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

• Tcl interface
• Wafer database
• Milkyway to OpenAccess Translator
• Turbo DM System
• Tcl Pcells
• DM interface used by plug-in developers

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

Compatibility with Earlier Releases

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

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

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

Changes and New Features

Improved Error and Warning Messages

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

Plug-In Registration Files on Windows

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

"C:\\work\\designs"

Parasitics

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

New Translator Option

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

Tcl Changes

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

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

• oaTcl This shared library, which can be loaded by a Tcl interpreter through the Tcl load command, has not changed. This shared library depends on the five additional shared libraries.
• oaLangBase This shared library contains support classes to describe OpenAccess classes.
• oaLangInfo This shared library contains the description of OpenAccess classes and functions.
• oaTclCommon This shared library provides general support classes for Tcl bindings of C++ types.
• oaTclBase This shared library provides support classes for Tcl bindings to OpenAccess types.
• oaTclPlugIn This shared library provides support classes for the Tcl script engine, which is used for Tcl Pcells.

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

EMH Changes

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

API Change Reports

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

Fixed Problems

Version 2.2.3

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

Release Status

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

• Tcl interface
• Wafer database
• Milkyway to OpenAccess Translator
• Turbo DM System
• Tcl Pcells
• DM interface used by plug-in developers

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

Compatibility with Earlier Releases

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

Parasitic Objects With AppDefs

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

Changes and New Features

Tcl Changes

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

The following oaString member function bindings were removed.

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

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

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

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

oaString::format Functions

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

verilog2oa Translator

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

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

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

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

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

New getCreateTime Functions

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

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

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

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

Deprecated Primitive Types

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

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

oaViaParams Enhancement

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

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

oaStdViaDef::setParams Enhancement

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

oaScanChain Enhancements

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

New InstTerm getBit() Functions

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

oaTech Attachment Change

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

• The tech database is purged
• The library is closed

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

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

verilog2oa and verilogAnnotate Now Generate Warnings

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

Package Header File for Verilog Translators

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

New EMH Functions

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

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

• void oaInstTerm::hide();

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

New EMH Functionality

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

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

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

Changed oaBusNet Functions

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

Optionally Building LEF and DEF Translators

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

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

Implant Enclosures

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

Improved Documentation System

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

Restructuring of Inline Function Definitions

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

Changed Exception

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

API Change Reports

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

Fixed Problems

Version 2.2.2

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

Release Status

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

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

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

Compatibility with Earlier Releases

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

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

  You must declare the prototypes in the beginning as follows:

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

  Then call them as follows:

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

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

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

• OpenAccess to LEF Mapping Change

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

Changes and New Features

zlib is Statically Linked to Translators

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

Translators are Built as Static Libraries

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

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

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

oa, oaCommon, and oaUtil Restructured

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

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

Tcl Package Support

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

Dependencies for Building Applications on OpenAccess on Windows

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

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

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

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

Building the oa20to22 Translator

The following procedure explains how to build the oa20to22 translator.

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

oa20to22 Translator Change

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

LEF/DEF Translators Take a List of Files

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

lef2oa Translator Change

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

def2oa Translator Changes

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

Calculation of Width for Diagonal Segments by Def Translators

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

Stream Translator Change

oa2strm now translates the following oaTextDisplay objects:

• oaAttrDisplay
• oaPropDisplay
• oaTextOverride

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

Note that oaInstAttrDisplay and oaInstPropDisplay are not translated.

The new command line options are as follows.

oa2spef

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

verilog2oa Translator

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

oaDefNS and oaSpefNS Namespace Changes

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

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

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

Default Parameters for Pcell References

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

This change impacts getParams() calls to the following:

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

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

LPP and layerHeaders in Pcell superMasters

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

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

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

Implementing Pcells Through Tcl (Beta Version)

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

For more information, see Implementing Pcells Through Tcl.

oaPcellScript Plug-In (Development Version)

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

Documentation Change for oaNameMem::getValue()

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

Unbinding Occurrence Hierarchies Has More Consistent Behavior

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

Uninstalling OpenAccess on UNIX Platforms

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

% rm -r <install_dir> 

DM FileSys Plug-In

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

New APIs

The following new APIs are available.

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

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

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

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

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

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

oaBoundary and Derived Classes

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

oaName Utility Classes

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

oaTech Class

The following APIs have been added to the oaTech class:

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

• void oaTech::destroy(oaLib *lib)

• oaLib* oaTech::getLib()

Functions that Take a Database Argument

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

Affected APIs

API Change Reports

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

Fixed Problems

Version 2.2.1

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

Compatibility with Earlier Releases

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

New Features

Translators

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

Spef Translators

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

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

Stream Translators

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

Custom Via Mapping File Syntax

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

Example:

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

oa2lef Translator

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

LEF/DEF Mapping Changes

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

Wafer API Changes

Two new wafer functions have been added:

oaTimeStamp             getTimeStamp(oaWaferDataType    type) const;

oaTimeStamp             getTimeStamp(oaAppObjectDef     *def) const;

New Overload for oaCellView::setView

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

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

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

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

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

New Turbo DM System Attribute

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

FileSys File Locking Use Model

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

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

Constraints

The distance parameter has been added to the oacMinWireExtension constraint.

Default Compiler Environment

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

Removal of Fatal Exceptions

The following fatal exception classes have been removed:

• oaFatal
• oaDesignFatal
• oaTechFatal
• oaDMFatal
• oaWaferFatal

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

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

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

API Changes

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

Fixed Problems

Return to top of page

Copyright © 2003-2005
All rights reserved.