OpenAccess 2.2 Incremental Release Notes

For a complete overview of the new features in OpenAccess 2.2, see What's New in OpenAccess 2.2.

The information that follows describes updates and bug fixes for incremental releases of OpenAccess 2.2.


OpenAccess 2.2 p001

API Change Reports

View a summary  of the OpenAccess 2.2 p001 changes with respect to 2.2 b014.

View a summary  of the OpenAccess 2.2 b014 changes with respect to OpenAccess 2.1.

Database Version Changes

Fixed PCRs


Beta 2.2 b014

API Change Reports

View a summary  of the OpenAccess 2.2 b014 changes with respect to 2.2 b013.

View a summary  of the OpenAccess 2.2 b014 changes with respect to OpenAccess 2.1.

Database Version Changes

Fixed PCRs


Beta 2.2 b013

Release Highlights

Setting the Library Path for Applications Built on OpenAccess

OpenAccess provides a script called oaGetLibPath that returns the path to the shared libraries for LD_LIBRARY_PATH, SHLIB_PATH, and LIB_PATH. Your application can use this script to set the library path for the OpenAccess libraries.

The script in available in <install_dir>/bin. The script has an optional mode, -numBits, that lets you override the bit mode specified by any environment variables.

API Change Reports

View a summary  of the OpenAccess 2.2 b013 changes with respect to 2.2 b012.

View a summary  of the OpenAccess 2.2 b013 changes with respect to OpenAccess 2.1.

Database Version Changes

Fixed PCRs

Beta Exceptions

EMH

When using an occurrence hierarchy that has been expanded into occurrences of lower level designs, undo is not supported for certain combinations of operations. While undo is enabled, you can either change the annotations (properties, groups, appDefs, and parasitics) on the objects in the lower level design occurrences, or change connectivity in the top or lower level designs. Changing both annotations and connectivity while undo is enabled will generally cause a crash in either oaDesign::undo() or oaDesign::redo().

Documentation Status

Release Status

Design Management

oaDMObject::destroy has no effect when called on an oaLib.


Beta 2.2 b012

Release Highlights

File Locking Clarification

When a DM object is to be destroyed, none of the files contained within that object can be locked by another process. If any of the files are locked by another process, the destroy is denied and an exception is thrown.

API Change Reports

View a summary  of the OpenAccess 2.2 b012 changes with respect to 2.2 b011.

View a summary  of the OpenAccess 2.2 b012 changes with respect to OpenAccess 2.1.

Database Version Changes

Fixed PCRs

Beta Exceptions

Design Management

oaDMObject::destroy has no effect when called on an oaLib.

Documentation Status

Examples

The PCells example is not currently working.


Beta 2.2 b011

Beta Exceptions

Design Management

oaDMObject::destroy has no effect when called on an oaLib.

Documentation Status

Examples

The PCells example is not currently working.

Release Highlights

EMH

Collections related to global nets are now supported in the occurrence domain.

DM Changes

Library Transactions

Library transactions have been simplified so that you only need to get access to a library. The commit and rollback functionality that was available previously has been removed. Library changes, when made, are always persistent.

oaLib::startTrans() has been replaced by oaLib::getAccess(), and oaLib::endTrans() has been replaced by oaLib::releaseAccess(). oaLib::commitTrans() has been removed.

The oaLib API has changed from:

   oaBoolean       startTrans(oaDMTransType type,
                              oaUInt4 timeout = 0);
   void            commitTrans();
   void            endTrans();
   oaBoolean       hasTrans() const;
   oaBoolean       hasWriteTrans() const;
   oaDMTransType   getTransType() const;

to:

   oaBoolean           getAccess(oaLibAccess accessType,
                                 oaUInt4     timeout = 0);
   void                releaseAccess();
   oaLibAccessLevel    oaLib::getAccessLevel()
 

The oaLibAccessLevel class has been added. This is an enum wrapper class that represents three levels of library access:

New oaDMData Classes for Associating Properties, Groups, AppDefs, and AppObjects with Container Objects

This release introduces the oaDMData class and four derived classes:

These classes let clients persistently associate properties, groups, appDefs, and appObjects with oaDMContainer objects (oaLib, oaCell, oaView, and oaCellView.)

The new oaDMData class derives from oaObject, and the database objects created using this class are managed objects. A new oaObject::isDMData() method has been added at the oaObject level as a verifier. Also, oaObject::getType() supports the new object types, which are oacLibDMDataType, oacCellDMDataType, oacViewDMDataType, and oacCellViewDMDataType respectively.

To set properties or extensions on DM objects, open the appropriate oaDMData for that object. For example, to read or write properties on an oaCellView, call oaCellViewDMData::open. This returns a pointer to an oaDMData object that you can then use to hold the cellView's properties.

The oaDMData database is treated like any other database; it can be opened, closed, and saved

oaCellView Changes

A new get() method finds an existing cellView or creates and returns a new cellView if one does not exist.

static oaCellView *get(const oaLib *lib,
                       const oaScalarName &cellName,
                       const oaScalarName &viewName,
                       const oaViewType   *viewType);

oaObject Changes

A new query method isDMData() at the oaObject level can be used to confirm whether or not an object is an oaDMData object.

oaBoolean isDMData() const;
File Locking

When a file is locked by the current or any other process and a lock is requested, the lock request is denied.

When a DM object is to be destroyed, none of the files contained within that object can be locked. If any of the files are locked, the destroy is denied and an exception is thrown.

oaObserver<oaDMObject> is Replaced

The class oaObserver<oaDMObject> is replaced by oaObserver<oaCell>, oaObserver<oaView>, oaObserver<oaCellView>, and oaObserver<oaDMFile>. The usage of the observer class remain the same -- it's just more strongly typed now.

Function Arguments Use typedefs

Many function arguments that were formerly oaUInt4 or oaInt4 have been changed to use the typedefs: oaCoord, oaDist, or oaOffset. This typedef provides a better indication of the purpose of the argument.

Tcl User Units

In Tcl, coordinates and distances are floating-point numbers specified in user units, such as microns. These user units are converted to database units by the Tcl bindings.

This affects the following C++ types directly:


Database units are converted to user units directly by the Tcl binding whenever possible. For example, when you call the getWidth Tcl command on a path object, the width return value is converted from database units to user units, and the result is assigned to the Tcl result. This conversion is accomplished with oaTech conversion functions, as follows.

Type

Database to user

User to database

oaCoord

dbuToUU

uuToDBU

oaDist

dbuToUUDistance

uuToDBUDistance

oaOffset

dbuToUU

uuToDBU

These functions require the technology database and the view type. Tcl commands for C++ member functions that are derived from the oaDesignObject class obtain the technology database and the view type from their design. As a consequence of this automatic conversion, a technology database must be available on the design before functions involving this conversion can be called, otherwise a Tcl error results.

All Tcl command arguments that are related to the three types above are specified in user units, and are converted to database units. The procedure for this is similar to that of converting database units to user units.

There are a number of OpenAccess C++ classes that do not have technology databases, and a conversion is therefore not possible. The simplest example is the oaPoint class. This class is represented in Tcl by a list of two double values. The oaBox is another example of such a class that has a pure TCL representation. The oaPointArray is an example of a class that is represented by a user defined Tcl object.

oaDesign API Change

oaDesign::getCellView() was removed because it implicitly accessed library data and required a call to oaLib::getAccess(). It is preferable to make this explicit and require the caller to do this.

Building OpenAccess on UNIX

OpenAccess has a new dependency on liboaCommon.so. You cannot build an executable without adding liboaCommon.so to the link line.

Changes to oaPlacementStatus

Change in Behavior for Undo

New function:

oaBoolean oaDesign::inUndo() const;

Removed function:

oaBoolean oaDesign::isCpNeeded() const;

Changed function:

oaBoolean oaDesign::setCp(); 

changed to:

void oaDesign::setCp();

API Change Reports

View a summary  of the OpenAccess 2.2 b011 changes with respect to 2.2 b010.

View a summary  of the OpenAccess 2.2 b011 changes with respect to OpenAccess 2.1.

Database Version Changes

Fixed PCRs


Beta 2.2 b010

Beta Exceptions

Design Management

EMH

Documentation Status

Examples

The PCells example is not currently working.

Release Highlights

Moving Functions to Bit Classes

EMH

References to the same global signal in different occurrences are now merged into a single oaNet in the block domain.

API Change Reports

View a summary  of the OpenAccess 2.2 b010 changes with respect to 2.2 b009.

View a summary  of the OpenAccess 2.2 b010 changes with respect to OpenAccess 2.1.

Database Version Changes

Fixed PCRs


Beta 2.2 b009

Beta Exceptions

Design Management

EMH

Documentation Status

TCL Bindings

Examples

The following example is not currently working:

Release Highlights

Change to Initialization Functions

The argc and argv arguments have been eliminated from the oaDMInit, oaTechInit, oaDesignInit, and oaWaferInit functions. The new signatures are as follows:

void oaDMInit(oaUInt4 apiMajorRev = oacAPIMajorRevNumber,
              oaUInt4 apiMinorRev = oacAPIMinorRevNumber);
   
void oaTechInit(oaUInt4 apiMajorRev = oacAPIMajorRevNumber,
                oaUInt4 apiMinorRev = oacAPIMinorRevNumber);
 
void oaDesignInit(oaUInt4 apiMajorRev = oacAPIMajorRevNumber,
                  oaUInt4 apiMinorRev = oacAPIMinorRevNumber);
 
void oaWaferInit(oaUInt4 apiMajorRev = oacAPIMajorRevNumber,
                 oaUInt4 apiMinorRev = oacAPIMinorRevNumber);

The translators and the example programs have been updated accordingly.

Information about How Plug-Ins are Loaded

The information in this section doesn't represent new functionality for b009. Rather, it elaborates on existing functionality.

There are two common scenarios for how a plug-in is loaded for OpenAccess:

Scenario 1: Loading a Specific Plug-in by Name
  1. The plug-in system is passed the name of the plug-in that you want to load.
  2. The system finds the path to the oaPlugIn shared library and uses that path to find the data directory.
  3. The system finds the registration file for the plug-in by appending .plg to the name of the plug-in and looks for a file of that name in the data/plugIns directory.
  4. If the system finds the <plug-in_name>.plg file, it loads it to get the root name of the library to load. There is a parameter of the plugIn tag called lib, so you will see ‘lib=”<root_lib_name>”’ in the xml file.
  5. The root name is decorated based on the platform and build mode (opt or dbg).
  6. The system loads the specified shared library (this library only needs to be in the library search path) and gets an entry-point function that allows it to create an instance of the plug-in.
Scenario 2: Loading the Default Plug-in for a Given Category
  1. The plug-in system is passed the category name from which you want the default plug-in. For example, in DM, the category name is oaDMSystem. Note that all DM plug-ins specify this category in their .plg files. This is the name you pass to the plug-in system in place of a specific plug-in name.
  2. The plug-in system finds the <category_name>.plg file as described in scenario 1. At this point, the system has no knowledge of its category name.
  3. The <category_name>.plg file is a little different from a regular plug-in .plg file. Instead of giving the root library name (in a ‘lib=”<root_lib_name>”’ statement), it specifies a treatAs parameter that gives the actual plug-in name to use.
  4. The plug-in system loads this special .plg file, determines that you are asking for a category default, and redirects to the name of the plug-in given in the treatAs field.
  5. The system then proceeds as in Scenario 1, step 5.

Each plug-in package installs its .plg file for use in Scenario 1 to the data/plugIns directory. oaDMTurbo before promotes an additional file called oaDMSystem.plg with the treatAs=”oaTurbo” statement in it. This establishes oaDMTurbo as the default plug-in for that category. In general, when troubleshooting a plug-in problem, look at the data/plugIns directory to see if everything looks correct, then look for the libraries that the .plg files are referring to.

Conversion of Generic Integer Parameters to Special Types

Arguments and return values of functions in various classes, such as oaBox, oaPoint, and oaArrayInst have been changed from a generic oaUInt4 type to special types if the argument or return value represents a coordinate, distance or offset value, as follows:

oaCoord represents a signed coordinate in 2D space.
oaDist represents an unsigned distance in 2D space.
oaOffset represents a signed offset in 2D space.

This conversion of generic integers to special types represents useful information for end-application users.

Note that this change is critical at the TCL level. Specifically, Cadence extension languages use user units, which are user-specified units that can be any units such as microns, mils, meters, angstroms, and so forth, rather than database units. These values therefore go through a conversion from (floating-point) user units to (integer) database units.

Changes to Region Query

DM Changes

New API

The following function returns the write path to this library.

oaLib::getWritePath()

Removed API

The oaLibServer class is obsolete and has been removed.

Changes to Transactions

The ability to perform read locking has been removed.

Removed Topology Attribute from Routes

Topology is used on geometric routes, and geometric routes do not use oaRoutes. Accordingly, the topology attribute has been removed from oaRoute.

Changed API

oaRoute::create() has been changed to:

static oaRoute      *create(oaBlock         *block,
oaNet *net = NULL,
oaBoolean isGlobal = false,
oaRouteStatus stat = oacNormalRouteStatus);
Removed APIs

The following APIs have been removed:

oaRouteTopology          getTopology() const;

void                     setTopology(const oaRouteTopology     &topology);

Changes to Observers

The oaAppDef* (pointer to the definition) is passed to the observer whenever any of its data changes.

Changed the Controlling Flags for oaGuide Iterators and Collections

From:

#define oavGuideIterBeginLayer 0x0001u
#define oavGuideIterEndLayer 0x0002u
#define oavGuideIterBeginAndEndLayers 0x0003u

To:

#define oacGuideIterBeginLayer 0x0001u
#define oacGuideIterEndLayer 0x0002u
#define oacGuideIterBeginAndEndLayers 0x0003u

API Change Reports

View a summary  of the OpenAccess 2.2 b009 changes with respect to 2.2 b008.

View a summary  of the OpenAccess 2.2 b009 changes with respect to OpenAccess 2.1.

Database Version Changes

Fixed PCRs


Beta 2.2 b008

Beta Exceptions

Design Management

EMH

Documentation Status

TCL Bindings

Examples

The following examples are not currently working:

Release Highlights

Design Management (DM) Changes

You need to recreate your old libraries for b008 either by re-translating them or by recreating them from scratch. (This is due to a change in the format of the library description file (.oalib)).

Removed APIs

Now that transactions are fully implemented, the following function is not needed and has been removed:

oaDMObject::release()
New APIs

The following function returns the full path to the library:

void         oaLib::getFullPath(oaString &fullPath) const;

The following function returns the name of the DM system associated with the library at creation time.

void         oaLib::getDMSystemName(oaString &dmSystem) const;
Modified APIs

Previously, the following function returned the library name and the DM system name in the list of attributes. This functionality is no longer needed and has been removed. The library name can be returned directly from an oaLib, and the DM system name can be queried directly.

oaLib::getAttributes()

EMH

You can now destroy a portion of an occurrence hierarchy using a new function, oaOccurrence::destroy(). Applications can use this capability to improve capacity and performance when performing significant edits in the block or module domain, which often invalidate all related occurrence annotations.

In addition, an optional argument has been added to several functions to control whether the occurrence hierarchy is expanded. In each session, an application must expand the occurrence hierarchy as much as needed. After doing so, the application can avoid expanding the occurrence hierarchy further by setting expand to false when calling the following functions:

oaOccInstTerm::getTerm(oaBoolean    expand = true) const  
oaOccInst::getMasterOccurrence(oaBoolean    expand = true) const    
oaOccModuleInstHeader::getMasterOccurrence(oaBoolean  expand = true) const 

oaFSComponent Changes

Changes to oaTerm, oaInstTerm

The default oaRouteMethod for a new oaTerm or oaInstTerm has changed from oacGeometricRouteMethod to oacSymbolicRouteMethod. Specifically, the changes include the following:

Translator Changes

Recompiling LEF and DEF Translators

The liblef and libdef static libraries, which comprise the LEF/DEF parsers, are no longer included in the OpenAccess installation because they are licensed separately. Note that the OpenAccess LEF/DEF translator executables are still available inside the distribution.

If you want to recompile the LEF/DEF translators, you need to download and compile the LEF/DEF parser from https://openeda.si2.org/projects/lefdef/. See Optionally Compiling Translators for instructions.

API Change Reports

View a summary  of the OpenAccess 2.2 b008 changes with respect to 2.2 b007.

View a summary  of the OpenAccess 2.2 b008 changes with respect to OpenAccess 2.1.

Database Version Changes

Fixed PCRs


Beta 2.2 b007

Beta Exceptions

Design Management

EMH

Documentation Status

Examples

Release Highlights

API Change Reports

View a summary  of the OpenAccess 2.2 b007 changes with respect to 2.2 b006.

View a summary  of the OpenAccess 2.2 b007 changes with respect to OpenAccess 2.1.

Database Version Changes

Fixed PCRs

b007 Limitations


Beta 2.2 b006

Beta Exceptions

Design Management

EMH

Documentation Status

Examples

Release Highlights

SPEF to OpenAccess Translator (spef2oa) is Available

spef2oa is the standard translator implementation that reads a SPEF file and annotates an OpenAccess database with parasitic information. The translator only adds parasitic information to an existing database. spef2oa does not create connectivity. The translator runs from the command line and includes options to control what information is read from the SPEF file and how the information is stored in the database.

For more information, see spef2oa Translator.

New APIs for Library Definition Files (lib.defs)

The purpose of this set of APIs is to provide a mechanism to open all the libraries in a library definition file as well as to provide an interface to update the contents of library definition files.

Change to oaPointArray API

oaPointArray now derives from oaArray<oaPoint>.

As a result of this change, any {get,set}NumPoints() methods become {get,set}NumElements() methods.

Non-Shared Library Access Mode in the FileSys DM System

The FileSys DM System now lets you access a library in non-shared mode via the oaLibMode class. When one client accesses a library in non-shared mode, no other client is allowed access to that library (no lock files will be produced for those other clients). This enhancement improves the performance of translators that create or update data in a library.

Note that the FileSys plug-in will not fail to open a library in non-shared mode if other clients have already opened the library.

To use the new non-shared mode, pass the oaLibMode argument with a value of oacNonSharedLibMode to oaLib::create() and oaLib::open() as follows:

 newLib = oaLib::open(scalarLibName, libPath, "", oacNonSharedLibMode);
 newLib = oaLib::create(scalarLibName, libPath, oacNonSharedLibMode, dmSystem);

New Library Mode API

The oaLib::getMode() method is now implemented.

Constraints

oaBooleanValue API Change

oaTechInit() Calls oaDMInit()

oaTechInit() now automatically calls oaDMInit(). This affects the signature for oaTechInit(), adding two new arguments, argc and argv.

void  oaTechInit(oaInt4   *argc,
                 char     *argv[],
                 oaUInt4  apiMajorRev,
                 oaUInt4  apiMinorRev)

Moving Functions to the Bit Classes

As a result of the changes in 2.2 to support bitwise connectivity, all the connectivity classes that have Busses (or Vectors) now have a Bit class for the single-bit objects, such as oaBitNet and oaBitTerm. Many member functions on the parent classes, such as oNet and oaTerm, are only used on single-bit objects, but previously had to be on the parent of the Scalar and Bus sub-classes. Functions that only apply to single-bit objects have been moved to the new Bit classes, and other functions with arguments or return values that refer to single-bit objects have changed to the more specific type.

Changes to oaNet and oaBit

The following member functions have been moved from oaNet to oaBitNet:

oaBoolean                       isPreferredEquivalent() const
 
oaNet*                          getPreferredEquivalent() const
 
oaRoutePattern                  getRoutePattern() const
 
oaFloat                         getVoltage() const
 
oaConnStatus                    getConnStatus() const
 
oaNet*                          getShieldNet1() const
 
oaNet*                          getShieldNet2() const

oaNet*                          getOriginal() const
 
void                            getParasiticConfidence(oaUInt4 &minValue, 
                                                       oaUInt4 &maxValue) const
 
void                            setPreferredEquivalent()
 
void                            setRoutePattern(oaRoutePattern routePattern)
 
void                            setVoltage(oaFloat voltage)
 
void                            setConnStatus(oaConnStatus status) 
 
void                            setShieldNet1(oaNet *shieldNet)
 
void                            setShieldNet2(oaNet *shieldNet)

void                            setOriginal(oaNet *original)
  
void                            setParasiticConfidence(oaUInt4 value)
 
void                            setParasiticConfidence(oaUInt4 minValue,
                                oaUInt4 maxValue)
 
void                            makeEquivalent(oaNet *equivNet)
 
void                            breakEquivalence()
 
oaCollection<oaSteiner, oaNet>  getSteiners() const
 
oaCollection<oaVia, oaNet>      getVias(oaUInt4 filterFlags = oacViaIterNetRoutes) const
 
oaCollection<oaNet, oaNet>      getEquivalentNets() const

The following had return or argument types modified as appropriate for oaBitNet:

oaBitNet*                           getPreferredEquivalent() const
 
oaBitNet*                           getShieldNet1() const
 
oaBitNet*                           getShieldNet2() const
 
void                                setShieldNet2(oaBitNet *shieldNet)
 
void                                makeEquivalent(oaBitNet *equivNet)
 
oaCollection<oaSteiner, oaBitNet>   getSteiners() const
 
oaCollection<oaVia, oaBitNet>       getVias(oaUInt4 filterFlags = oacViaIterNetRoutes) const
 
oaCollection<oaBitNet, oaBitNet>    getEquivalentNets() const

The single-bit member net collection:

oaCollection<oaNet, oaNet>  getSingleBitMembers() const

Was changed to contain oaBitNets:

oaCollection<oaBitNet, oaNet> getSingleBitMembers() const
Changes to oaShape and oaVia

The following member functions on oaShape and oaVia have been modified to refer to oaBitNet.

oaBitNet*        oaShape::getShieldNet1() const
 
oaBitNet*        oaShape::getShieldNet2() const
 
void             oaShape::setShieldNet1(oaBitNet *net)
 
void             oaShape::setShieldNet2(oaBitNet *net)
 
oaBitNet*        oaVia::getShieldNet1() const
 
oaBitNet*        oaVia::getShieldNet2() const
 
void             oaVia::setShieldNet1(oaBitNet *net)
 
void             oaVia::setShieldNet2(oaBitNet *net)
Changes to oaModNet and oaModBitNet

The following member functions have been moved from oaModNet to oaModBitNet:

oaBoolean   isPreferredEquivalent() const
 
oaModNet*   getPreferredEquivalent() const
 
void        setPreferredEquivalent()
 
void        makeEquivalent(oaModNet *equivNet)
 
void        breakEquivalence()

The following had return or argument types modified as appropriate for oaModBitNet:

oaModBitNet*                            getPreferredEquivalent() const

void makeEquivalent(oaModBitNet *equivNet)

oaCollection<oaModBitNet, oaModBitNet> getEquivalentNets() const

The single bit member net collection:

oaCollection<oaModNet, oaModNet> getSingleBitMembers() const

Has been change to contain oaModBitNets:

oaCollection<oaModBitNet, oaModNet> getSingleBitMembers() const
Changes to oaOccNet and oaOccBitNet

The following member functions moved from oaOccNet to oaOccBitNet:

oaBoolean                         isPreferredEquivalent() const

void getParasiticConfidence(oaUInt4 &minValue,
oaUInt4 &maxValue) const
oaCollection<oaOccNet, oaOccNet> getEquivalentNets() const

The following had return or argument types modified as appropriate for oaOccBitNet:

oaCollection<oaOccBitNet, oaOccBitNet> getEquivalentNets() const

The single-bit member net collection:

oaCollection<oaOccNet, oaOccNet> getSingleBitMembers() const

Has been changed to include oaOccBitNets

oaCollection<oaOccBitNet, oaOccNet> getSingleBitMembers() const
Changes to oaTerm and oaBitTerm

The following member functions have been moved from oaTerm to oaBitTerm:

oaRouteMethod                   getRouteMethod() const
 
oaPinConnectMethod              getPinConnectMethod() const
 
oaRoutePattern                  getRoutePattern() const
 
oaTerm*                         getSupplySensitivity() const
 
oaTerm*                         getGroundSensitivity() const
 
void                            getAntennaData(oaAntennaData            &data, 
const oaAntennaDataModel &model() const void setRouteMethod(oaRouteMethod routeMethod) void setPinConnectMethod(oaPinConnectMethod pinConnMethod) void setSupplySensitivity(const oaTerm *term) void setGroundSensitivity(const oaTerm *term) void setMustJoin(const oaTerm *term) void unsetMustJoin() void setAntennaData(const oaAntennaData &data) void unsetAntennaData(const oaAntennaDataModel &model) oaBoolean isAntennaDataSet(const oaAntennaDataModel &model) oaCollection<oaTerm, oaTerm> getMustJoinTerms() const

The following had return or argument types modified as appropriate for oaBitTerm:

oaBitTerm*                          getSupplySensitivity() const
 
oaBitTerm*                          getGroundSensitivity() const
 
void                                setSupplySensitivity(const oaBitTerm *term)
 
void                                setGroundSensitivity(const oaBitTerm *term)
 
void                                setMustJoin(const oaBitTerm *term)
 
oaCollection<oaBitTerm, oaBitTerm>  getMustJoinTerms() const
 

API Change Reports

View a summary  of the OpenAccess 2.2 b006 changes with respect to 2.2 b005.

View a summary  of the OpenAccess 2.2 b006 changes with respect to OpenAccess 2.1.

Database Version Changes

Fixed PCRs


Beta 2.2 b005

Beta Exceptions

Design Management

SPEF Reader

EMH

Documentation Status

Examples

Release Highlights

Changes to TCL Bindings

64-bit versions of the TCL bindings are now available.

Also, the commands to load the oaTcl shared library have changed, as shown in the following table.

Platform
Command
Solaris load oaTcl.so oa
Linux load oaTcl.so oa
IBM load oaTcl.so oa
HP load oaTcl.sl oa
Windows load oaTcl.dll oa

New oaCellView::setView API

void     oaCellView::setView(const oaView    *view);

This API changes the parent view of the cellView. If the viewType is changed, the primary file name also changes. If the primary file exists on disk, it is renamed.

An exception is thrown if another cellView already has the cellName and viewName that this cellView would have after the change is made. (oacCVExists).

An exception is thrown if a file already exists in the cellView with the same name that the primary file is to be renamed. (oacCVSetViewPrimaryFileExists)

An exception is thrown if the primary file cannot be write locked.

Compiling Verilog Translators

Bison 1.875-3 is now required for compiling the Verilog translators instead of Bison++. For more information, see Optionally Compiling Translators in the Installation and Configuration Notes.

Change to oaDesign::getTech()

getTech has been updated to first look for a local technology database, then look for an attached technology database.

If getTech finds a technology database in the library containing the design, it opens that local technology database (if it is not already open) and returns a pointer to that technology database.

If getTech does not find a local technology database, it looks for a library property called "techLibName". The techLibName property specifies a different library containing the technology database, which is called an attached technology database. If this property is found, getTech opens the attached technology database (if it is not already open) and returns a pointer to that technology database.

API Change Reports

View a summary  of the OpenAccess 2.2 b005 changes with respect to 2.2 b004.

View a summary  of the OpenAccess 2.2 b005 changes with respect to OpenAccess 2.1.

Database Version Changes

Fixed PCRs


Beta 2.2 b004

Beta Exceptions

Design Management

SPEF Reader

EMH

Documentation Status

Examples

Release Highlights

TCL Bindings for OpenAccess APIs are Available

The OpenAccess API is available in TCL, for version 8.4.1 and later. In order to use this, you need to install TCL 8.4.1. You can obtain this from:

http://www.tcl.tk

If you compile the TCL bindings (oaLang package), there will be compilation warning messages. The OpenAccess team is aware of this issue and is working to correct it. Note that there is no need to compile the TCL bindings unless you want to work on a platform that is not one of the OpenAccess precompiled platforms.

Note: Only 32-bit versions of the TCL bindings are currently available. 64-bit versions will become available in a subsequent release.

Prerequisites

Before you invoke the TCL shell:

Using the TCL Bindings

You can invoke TCL from the command line. For example:

> tclsh8.4

This starts the TCL shell that came from the TCL distribution. You can now enter TCL commands. To see all available commands in the global TCL namespace, use the info command:

% info commands *

This returns:

tell socket subst open eof pwd glob list exec pid auto_load_index time 
unknown eval lrange fblocked lsearch auto_import gets case lappend 
proc break variable llength auto_execok return linsert error catch 
clock info split array if fconfigure concat join lreplace source 
fcopy global switch auto_qualify update close cd for auto_load file 
append format read package set binary namespace scan trace seek while 
flush after vwait uplevel continue foreach lset rename fileevent 
regexp upvar unset encoding expr load regsub history interp exit 
puts incr lindex lsort tclLog string

All OpenAccess commands are provided in the TCL namespace oa. To view commands in this namespace, enter:

% info commands oa::*

At this point, there aren't any available commands because the oaTcl shared library has not been loaded. To do so, use the TCL load command for your platform:

Platform
Command
Solaris load liboaTcl.so oa
Linux load liboaTcl.so oa
IBM load liboaTcl.so oa
HP load liboaTcl.sl oa
Windows load oaTcl.dll oa

The info command now shows a long list of functions. To see the commands for opening libraries, use:

% info commands oa::Lib*

This returns:

::oa::LibDefFileAddLib ::oa::LibServerGetDefaultPortNum 
::oa::LibDefFileGetLibDefFiles ::oa::LibDefFileIter 
::oa::LibGetOpenLibs ::oa::LibDefFileGetCurrent 
::oa::LibMode ::oa::LibCreate ::oa::LibDefFileRemoveLib 
::oa::LibExists ::oa::LibServer ::oa::LibServerGetLocalHostName 
::oa::LibDefFileCollection ::oa::LibServerFindServerFor ::oa::LibOpen 
::oa::LibDefFileGetDefault ::oa::LibFind ::oa::LibDefFileLoad

Note that oa::LibCreate is in this list. To obtain information on a particular command use oa::help as follows:

% oa::help LibCreate

This returns:

LibCreate        
name oaScalarName
libPath oaString
mode oaLibMode
dmSystem oaString
dmAttrList oaDMAttrArray
==> oaLib

Try creating a library, for example:

% oa::LibCreate myLib myLib

This returns an address such as:

oa:0x80013
Examples

There are sample scripts in your installation hierarchy in <install_dir>/examples/oa/tcl.

Troubleshooting

Changes for Library Definition Files

The following search path is now used by OpenAccess to locate lib.defs files.

Changes to oaLibDefFile::load()

class OA_DM_DLL_API oaLibDefFile {
    public:
        static void load();
        static void load(const oaString &path);
virtual oaBoolean onLoadWarnings(const oaString              &path,
                                 const oaString              &msg,
                                 oaLibDefFileWarningTypeEnum type);

where the enum is defined as:

enum oaLibDefFileWarningTypeEnum {
   oacNoDefaultLibDefFileWarning         = 0,
   oacCannotOpenDefaultLibDefFileWarning = 1,
   oacSyntaxErrorLibDefFileWarning       = 2,
   oacCannotOpenIncludeLibDefFileWarning = 3,
   oacRecursiveIncludeLibDefFileWarning  = 4,
   oacMultiDefinitionsLibDefFileWarning  = 5,
   oacCannotOpenLibLibDefFileWarning     = 6
};

DM Data Transactions

The DM data transactions have not changed between b003 and b004. However, the following information about DM data transactions is more clear than the information in the b003 release notes.

A data transaction on a DM object can exist outside of the library transaction, as follows:

lib->startTrans(oacReadDMTransType);
oaCell *cell = oaCell::find(dmLib, dmCellName);
cell->startDataTrans(oacWriteDMTransType);
dmLib->endTrans();
 

The library transaction is necessary to obtain the pointer for the DM object. A DM data transaction is then started for the DM object. The library transaction can be ended at this time, and other processes can now obtain library transactions and modify the library. However, any DM object that has an active library transaction is protected from destruction by other processes.

The DM object pointer remains valid because of the active DM data transaction.

While the DM object pointer is valid, it can be used to create and access DM data (properties). In addition, some DM APIs on the object that access information about that object can be used. Any other APIs are blocked because the caller does not have a valid library transaction. In particular, any API that returns information about other library objects is disallowed.

When the outermost data transaction is ended, the object pointer becomes invalid if there is no encompassing library transaction.

API Changes for Parasitic Network Partition Support

New APIs:

static oaParasiticNetwork          *create(oaParasiticNetwork      *parent);
static oaParasiticNetwork          *create(oaParasiticNetwork      *parent,
                                           const oaString          &name); 

static oaParasiticNetwork          *find(oaParasiticNetwork       *parent,
                                         const oaString           &name);

void                               setBBox(const oaBox   &bBox);
void                               getBBox(oaBox   &bBox) const;

oaBoolean                          isLoaded();
oaBoolean                          isParent();

oaParasiticNetwork                 *getParent();   

void                               load(oaBoolean  allPartitions = false);

oaCollection<oaParasiticNetwork, oaParasiticNetwork> getPartitions() const;

Changed API:

static oaParasiticNetwork          *load(const oaDesignObject         *net,
                                         const oaAnalysisPoint        *ap,
                                         oaBoolean                    allPartitions = false);

API Change Reports

View a summary  of the OpenAccess 2.2 b004 changes with respect to 2.2 b003.

View a summary  of the OpenAccess 2.2 b004 changes with respect to OpenAccess 2.1.

Database Version Changes

The database version numbers have not changed since b003.

Fixed PCRs


Beta 2.2 b003

Beta Exceptions

Design Management

SPEF Reader

TCL Bindings to OpenAccess

EMH

Documentation Status

Examples

Release Highlights

New Reserved viewTypes

The viewTypes in green are new reserved viewTypes, which are included because they are common viewTypes. There is no corresponding OpenAccess database representation for these new viewTypes.

enum oaReservedViewTypeEnum {
   oacMaskLayout      = 0,
   oacSchematic       = 1,
   oacSchematicSymbol = 2,
   oacNetlist         = 3,
   oacWafer           = 4,
   oacVerilogAMSText  = 5,
   oacVHDLAMSText     = 6,
   oacVerilogText     = 7,
   oacVHDLText        = 8,
   oacVerilogAText    = 9
   };

These are the corresponding viewType names:

oacVerilogAMSText   "verilogAMSText"
oacVHDLAMSText      "VHDLAMSText"
oacVerilogText      "verilogText"
oacVHDLText         "VHDLText"
oacVerilogAText     "verilogAText"

In the FileSys plug-in, there is a specific file name associated with each viewType, as follows:

oacVerilogAMSText  "verilog.vams"
oacVHDLAMSText     "vhdl.vhms"
oacVerilogText     "verilog.v"
oacVHDLText        "vhdl.vhd"
oacVerilogAText    "veriloga.va"

For more information about the new viewTypes, see OpenAccess 2.2 Libraries and DM API.

DM Data Transactions

A data transaction on a DMObject can exist outside of the library transaction, as follows:

lib:startTransaction
lib -> cell
cell -> startDataTransaction
lib:endTransaction

At this point, data cannot be accessed from the library or the cellView. Data can only be accessed from the cell itself. Other users can edit the library while the data transaction on the cell is occurring.

The data transaction can be closed directly from the cell.

For more information, see the Code Example - Referencing DMObjects with Active Data Transactions.

API Changes for Library Definition Files

API Changes for oaLib

Two new APIs have been added to oaLib:

Iterator Copy Constructors

Iterator copy constructors no longer reset the target iterator.

Support for Diagonal PathSegs and Chamfered Ends for Orthogonal and Diagonal PathSegs

Support for diagonal oaPathSegs and chamfered ends in oaSegStyles has been implemented. New constructors for oaSegStyle accommodate PathSegs with one chamfered and one square end. See oaPathSeg and oaSegStyle  for details.

Translator Changes

Updating Library Definition Files
Translator Behavior (Appending, Overwriting, and Creating Designs)

The default mode for all translators is append, which means that the translator can create new designs in the library but cannot overwrite existing designs. There is a new -overwrite option, which lets most translators overwrite existing designs and create new ones in the library. However, the verilogAnnotate translator always appends data to existing designs and does not accept the -overwrite switch.

Notes:

oaDefIn Class Changes

Previously, in order to customize def2oa, you had to derive from the base translator class and the helper classes. Starting with B003, you need only derive from the helper class, then register your user derived helper classes with the base translator class.

Constraint API Changes

Observer API Changes

AppDef Observer Changes

The preModify and postModify methods on oaObserver< oaAppDef > now take the appDef as an argument. Also, the appDef observer no longer has onRead or onWrite methods.

Migrating from oaPcellDataObserver to IPcell

Two new classes, IPcell and oaPcellLink, replace oaPcellDataObserver. IPcell is an interface class that contains the application-specific function for pcell processing. oaPcellLink creates the link between OpenAccess and the IPcell provided by your application. The following listings are excerpts from the oaDesignInterfaces.h and IPcellLink.h header files followed by brief descriptions of the functions.

oaDesignInterfaces.h Excerpt
class OA_DESIGN_DLL_API IPcell ...

  //Public Methods:
  public:
    virtual oaPcellDef		*getPcellDef() = 0;

    virtual void		getName(oaString &name) = 0;

    virtual void		onBind(oaDesign *design, oaPcellDef  *pcellDef) = 0;

    virtual void		onUnbind(oaDesign *design, oaPcellDef *pcellDef) = 0;

    virtual void		onEval(oaDesign *design, oaPcellDef  *pcellDef) = 0;

    virtual void		onRead(oaDesign *design, oaMapFileWindow &mapWindow, oaUInt4 &loc, oaPcellDef *pcellDef) = 0;

    virtual void		onWrite(oaDesign *design, oaMapFileWindow &mapWindow, oaUInt4 &loc, oaPcellDef *pcellDef) = 0;

    virtual oaUInt4		calcDiskSize(oaPcellDef *pcellDef) const = 0;
oaPcellLink.h Excerpt
class OA_DESIGN_DLL_API oaPcellLink ...

  //Public Methods:
  public:
    void	destroy();

  // Static Public Methods:

    oaPcellLink		*find(const oaString &name);

    oaPcellLink		*create(IPcell *pcellIn);

    oaPcellDef		*getPcellDef(const oaString &name);

The find() function is intended for creating pcell links for IPcells that come in as a plug-in. The create() function is intended for creating in-memory IPcells.

class OA_DESIGN_DLL_API oaPcellDef ...

  // Public Methods:
  public:

    oaPcellDef(IPcell *pcellIn);

    virtual ~oaPcellDef();

An application can provide an IPcell for OpenAccess by either creating one in memory or through a pcell plug-in. Information about how you create an IPcell plug-in will be provided in a subsequent release. To create a memory pcell, the application must perform the following steps:

  1. Derive the pcell processor from IPcell instead of deriving it from oaPcellDataObserver. The derived class returns the name through the getName() function.
  2. Change the derived class function name from pcellDefAlloc to getPcellDef.
  3. Change the following function names: