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:
  4. Create an instance of the derived pcell processor class.
  5. Call oaPcellLink::create() with a pointer to the pcell processor instance.
  6. When the application needs to remove the pcell from memory, call oaPcellLink::destroy() on the link returned by oaPcellLink::create().
  7. Replace the calls to oaDataObserver::find() with either oaPcellLink::find() or oaPcellLink::getPcellDef().

API Change Reports

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

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

Database Version Changes

Fixed PCRs

 

Beta 2.2 b002

Beta Exceptions

This is the second Beta release of OpenAccess 2.2. The majority of the 2.2 functionality is complete, with the following exceptions:

Design Management

Routes

SPEF Reader

EMH

TCL Bindings to OpenAccess

Documentation Status

Release Highlights

Route Purpose Changes

The following changes are required so that OpenAccess can recognize redundant shapes and vias. These changes might require minor source code updates to client code.

Changes in Translators

  1. Translators do not currently update library definition files when creating new libraries. If you don't add the new library to a library definition file, the translators that read OpenAccess libraries will not be able to find that library.
  2. Option names and meanings
  3. Library location

Changes for Callbacks

Nearly all of the individually named oa*Callback classes are replaced by instances of the oaObserver<> template. For example, oaNetCallback becomes oaObserver<oaNet>. The names and signatures of the virtual functions on the observer classes are the same as those on the oa*Callback classes.

The following classes, which do not apply to individual database objects, are not instances of a template. Note that they, too, have been renamed from oa*Callback to oa*Observer:

Update to Source Code Migrator (oa20to22src)

The oa20to22src source code migrator now handles changes for callbacks being replaced by observers.

Automatically Updating Libraries (oa20to22)

The –srcLib argument has been removed. The library name specified by –lib is used for both the source and destination library.

For more information, about updating your libraries, see Automatically Updating 2.0.x Libraries to 2.2

Region Query Enhancements

Region query now supports true overlaps of query regions with object geometries.

Change to Compile Time Directives

OpenAccess code now uses the following compile time directives, which provide support for verbose mode. OpenAccess header files now use:

    #if defined(...)

instead of:

    #ifdef ...

For more information, see Compile Time Directives in the Coding Style Guide and Standards.

Enhanced oaOccTraverser

The oaOccTraverser class has been enhanced such that a concrete oaOccTraverser object is capable of traversing occurrences and occurrence objects across design boundaries. The public interface remains the same except that the traversal now produces all objects in the occurrence hierarchy that might span multiple designs.

Change to Use Model for Library Definition Files

OpenAccess no longer searches for a library definition file during the oaDMInit routine. Instead, a library definition file is loaded with oaLoadLibs. The search path has not changed:

  1. ./lib.defs
  2. $HOME/lib.defs
  3. <install_dir>/data/lib.defs

In addition, the -libDefFile command-line argument is no longer supported.

Temp File for Design Management

A temp file is used as a temporary storage location that is associated with a DM object. An application can obtain a temp file path to use with oaDMObject::getTempFile. This request is passed to the plug-in, which returns a unique path.

The sameFileSystem argument specifies whether the file must be created in the same file system as its associated oaDMObject, or if it can be created in a different file system preferred by the plug-in.

Applications should delete the temp file when done with it. The plug-in will delete the temp file if the DM object associated with the temp file is destroyed. (This is not yet implemented). 

// *****************************************************************************
// oaDMObject
// *****************************************************************************
class OA_DM_DLL_API oaDMObject : public oaObject {
public:
   void getTempFile(oaString  &path,
                    oaBoolean sameFileSystem = false) const;
   };

DM Library and Data Transactions

DM Library and data transactions are available in oaLib and oaDMObject, respectively.

Library and data transactions now support nesting. You can start a transaction within the scope of a current transaction. The new transaction becomes the active transaction. However, transactions cannot be upgraded in scope, so it is an error to start a write transaction within the scope of a read transaction.

Each inner transaction must commit the changes to be saved. However, changes are not actually saved until the outermost transaction commits its changes. If a transaction ends before its changes are committed, the changes are discarded. (Note: This is not yet fully implemented for libraries).

Rollback is not implemented for write transactions that are ended with being committed.

Library data access must occur within the scope of a library transaction.

Similarly, DM data access must occur within the scope of a DM data transaction.

Note: The APIs in green below are new for B002.

DM Library Transactions 
oaBoolean oaLib::startTrans(oaDMTransType   type, 
                            oaUInt4         timeout)

Returns true if a library transaction can be obtained. The timeout is in seconds. Returns FALSE if a library transaction cannot be obtained within the timeout limit. 

void oaLib::commitTrans()

Commits (saves) the effects of the transaction. It is an error if the active transaction is not a write transaction. 

void oaLib::endTrans()

Ends the active transaction. It is an error if there is no transaction. 

oaDMTransType oaLib::getTransType()

Returns the type of the active library transaction. 

oaBoolean oaLib::hasTrans()

Returns TRUE if the there is a transaction of any type on the library. 

oaBoolean oaLib::hasWriteTrans()

Returns TRUE if the outermost transaction of a library is of the type oacWriteDMTransType. 

 
DM Data Transactions 
oaBoolean oaDMObject::startDataTrans(oaDMTransType type, oaUInt4 timeout)

Returns TRUE if a DM data transaction can be obtained. The timeout is in seconds. Returns FALSE if a DM data transaction cannot be obtained within the timeout limit. 

void oaDMObject::commitDataTrans()

Commits (saves) the effects of the transaction. It is an error if the active transaction is not a write transaction. 

void oaDMObject::endDataTrans()

Ends the active DM data transaction. It is an error if there is no active transaction.

oaDMTransType oaDMObject::getDataTransType()

Returns the type of the active DM data transaction (or current transaction). 

oaBoolean oaDMObject::hasDataTrans()

Returns TRUE if there is a DM data transaction of any type on the object. 

oaBoolean oaDMObject::hasWriteDataTrans()

Returns TRUE if the outermost DM data transaction on the object is of the type oacWriteDMTransType. 

oaBoolean   oaDMObject::isDMDataCurrent() const

Returns a boolean indicating whether or not the DM data in the caller's current data transaction is up-to-date with the on-disk representation. A write transaction can modify the DM data such that the read transaction data is no longer current. This function should be called within a data transaction, otherwise it throws an exception.

oaTimeStamp  oaDMObject::getDMDataTimeStamp() const

Returns the timestamp associated with this DM data on this DM object in the current data transaction. This function should be called within a data transaction, otherwise it throws an exception.

Examples

This example creates a cellView, then adds a property to the cellView.

    lib->startTrans(oacReadDMTransType);
 
    cell->startDataTrans(oacWriteDMTransType);
 
    oaIntProp::create(cell, "p_cell_int", 12);
    prop = oaProp::find(cell, "p_cell_int");
 
    cell->commitDataTrans();
    cell->endDataTrans();
 
    lib->endTrans;

This example shows a read transaction being used to get the path to the primary file in a cellView. 

oaNativeNS nameSpace;

oaString filePath(40);

lib1->startTrans(oacReadDMTransType);

oaCell     *cell = oaCell::get(lib1, oaScalarName(nameSpace, "cellName"));
oaView     *view = oaView::get(lib1, oaScalarName(nameSpace, "viewName"));
oaCellView *cv = oaCellView::get(cell, view);

oaDMFile   *cvfile = cv->getPrimary();

cvfile->getPath(filePath);

lib1->endTrans();

DM API Changes

The oaLibDef class has been removed.

The following APIs support an easier library management approach in which you do not need to define a library before using it. All the APIs are new except for oaLib::find, which is modified. 

   // *****************************************************************************
   // This function creates the library using the specified name and attributes.
   // 
   // It is an error if the library with the name already exists, or the libPath
   // directory is not valid or already exists.
   // *****************************************************************************
   oaLib*
   oaLib::create(const oaScalarName    &name,
                 const oaString        &libPath,
                 oaLibMode             mode = oacSharedLibMode,     		      
                 const oaString        &dmSystem = "oaDMTurbo",
                 const oaDMAttrArray   *dmAttrList = NULL)
 
   // *****************************************************************************
   // This function opens an existing library at the given path, using the 
   // specified name and attributes.
   //
   // It is an error if the library is already open, or the given name does
   // not match the real name of the library at the given path.
   // *****************************************************************************
   oaLib*
   oaLib::open(const oaScalarName   &name,
               const oaString       &libPath,
               const oaString       &writePath = "",
               oaLibMode            mode = oacSharedLibMode)
 
   // *****************************************************************************
   // This function attempts to find an open library. If found, a pointer to 
   // that library is returned. If the library cannot be found, NULL is returned.
   // *****************************************************************************
   oaLib*
   oaLib::find(const oaScalarName &name)
 
    // *****************************************************************************
   // This function closes the library. All of its contents become not accessible,
   // all the transactions will end and the non-commited changes will be lost.
   // *****************************************************************************
   void
   oaLib::close()
 
   // *****************************************************************************
   // This function returns true if there's a library on the given libPath.
   // *****************************************************************************
   oaBoolean
   oaLib::exists(const oaString &libPath)

Removed GetLibName, GetCellName, GetViewName

API Consistency

For API consistency, a few object methods have been renamed to make them more predictable and consistent with other API methods:

Changes to oaInstAttrTypeEnum

The following enums have been removed from oaInstAttrTypeEnum:

Changes to oaLayerBlockage

These new methods represent the effective width of a layer blockage for minimum spacing lookup.

Changes to oaConstraintDef

The following changes were made to support symmetry in layer pair constraint defs:

Changes to Reduced-Model Parasitics

Removed APIs:

Added APIs:

API Change Reports

View a summary  of the OpenAccess 2.2 b002 changes with respect to 2.2 b001.

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

Database Version Changes

Fixed PCRs

Beta 2.2 b001

Release Highlights

Design Management (DM)

Library file storage, synchronization, and version-control management is handled through an interface that communicates with a DM system plug-in. OpenAccess provides two DM systems that you can choose from when you create a library:

Creating a Library Definition

Before creating a library, you must define it. A library definition must specify the library name and the library path as well as an optional specification for DM system for the library. If you do not specify a DM system, Turbo DM is the default.

The DM system applies to all the designs in the library.

You can define a library in two ways:

Note: Currently, multi-user access of libraries is not supported.

Defining a Library Using oaLibDef

First, create the library definition:

oaLibDef *libDef = oaLibDef::create(libName, libPath);

Next specify the DM system for your library as an attribute. The default DM system is oaDMTurbo. 

//Replace sysName with either oaDMTurbo or oaDMFileSys
libDef->addAttribute("DMSystem", "sysName");
Defining a Library with a Library Definition File

You can define a library using a library definition file:

DEFINE libName libPath
ASSIGN libName DMSystem sysName

Where sysName is one of oaDMTurbo or oaDMFileSys.

OpenAccess searches for a library definition file during the oaDMInit routine. The library definition is loaded if found. OpenAccess searches for a library definition file in the following order:

  1. ./lib.defs
  2. $HOME/lib.defs
  3. <install_dir>/data/lib.defs
Library Transactions

Library access is now controlled by library-level transactions. There are three functions for controlling transactions: 

void    oaLib::startTrans(oaDMTransType, timeout); 
void    oaLib::commitTrans(); 
void    oaLib::endTrans();

The following functions let you get information about transactions: 

oaBoolean         oaLib::hasTrans() const; 
oaDMTransType     oaLib::getTransType() const;

Before any library structure data (such as oaCells, oaViews, oaCellViews, oaDMFiles, and their attributes) is accessed, the application must obtain a read transaction. Before changing anything in the library structure, the application must obtain a write transaction.

Accessing data on the oaLib class itself does not require a transaction. Transactions cannot be nested. Transactions persist until ended.

Design, wafer, tech, and parasitic database functions have built-in transaction access.

Version Control (VC) System Plug-In

OpenAccess includes a sample VC System plug-in. The sample provides the boiler-plate code required to create a working VC system that can be plugged into an existing DM system (for example, DMTurbo or DMFileSys). The DM system can then present the VC interfaces as though both systems are one unit. The implementation details of this are presented in the sample.

You can copy the sample plug-in code to a development area and fill in the functions that are marked “not yet implemented.” Changing the names of the classes is optional, but changing the name of the plug-in is mandatory. You change the name of the plug-in by changing the name of the oaVCPlugSample.plg file. The root name of this file corresponds to the name of the plug-in. Inside the file, the value in quotations is the root name of the shared library of the plug-in. For example, a VC system called MyVCSystem built in a library named libMyVCSystem.so (on Solaris) would ship with a file called MyVCSystem.plg , which contains the following line of text: 

<<plugIn lib="MyVCSystem"/>

The primary interface that this plug-in implements is IVersionControl, which is the interface that OpenAccess uses to interact with the version control system. The comments in the oaVCPlug.cpp file help identify the purpose of each of these functions.

Note: The example does not currently show the implementation of the IVCSystem interface – this will be shown in a future version of the sample.

Design Management (DM) and Version Control (VC) Plug-In API Documentation Available

Library file storage, synchronization, and version-control management is handled through the DM interface socket, which communicates with a DM System plug-in. OpenAccess provides two DM Systems, as outlined in Design Management. If you want to create your own DM System, or add a version-control system, refer to the Design Manager Plug-In API Documentation for more information.

Automatically Updating 2.0.x Libraries to 2.2

Limitations

The following limitation applies to this release of oa20to22. (This limitation will be removed in subsequent releases.)

New Functionality
-srcCdsLib path         Source Library definition file
-srcLib library         Source Library to translate
-lib library            Destination Library name
[-libPath path]         Path to which the destination library is written
[-DMSystem sysName]     Name of the DM library system, such ‘oaDMFileSys' for Cadence 5.X library mode
[-help | -h]            Prints command-line help
[-logFile name]         Name of the log file
[-version | -v]         Prints version information
Modifications During Translation

The following modifications occur during the translation: 

2.0 Value                                                                             2.2 Simple Constraint Type
viaDefArray                                   oacValidRoutingVias
layerSpecArray                                oacValidRoutingLayer


2.0 Layer Value in the layerSpecArray                                2.2 Layer Constraint Type
layer width in layerSpecArray                 oacMinWidth
layer spacing in layerSpecArray               oacMinSpacing
diagWidth in layerSpecArray                   oacMinDiagonalWidth
diagSpacing in layerSpecArray                 oacMinDiagonalSpacing

The width and spacing values (both regular and diagonal) for each layer in the layerSpecArray become corresponding constraints on the layer. The isHard attributes for these layer constraints are set according to the isWidthFixed and isSpacingFixed values of the layer spec.

The following topics describe changes between between earlier development versions of 2.2 and the current Beta release. For more information about these projects, refer to the OpenAccess 2.2 Development Release Notes.

Change in Translator Behavior

The following translators now have command-line arguments for specifying an optional design library path and DM system, as well as a technology library path and its DM system.

The syntax for the new command-line arguments is as follows:

[-lib name]              Name of the design library to create or use.
[-libPath path]          Path to the design library to create or use. The default is the current working directory.
[-DMSystem sysName]      DM system to use: either oaDMTurbo or oaDMFileSys. The default is oaDMTurbo.
[-techLib name]          Name of the technology library to create or use.
[–techLibPath path]      Path to the technology library to create or use. The default is the current working directory.
[-techDMSystem sysName]  DM system to use: either oaDMTurbo or oaDMFileSys. The default is oaDMTurbo.

1. The def2oa translator doesn't include the -techLib, -techLibPath, or -techDMSystem  options because it doesn't create a technology library.

These options are ignored if the corresponding library is already defined in a library definition file.

To see the complete list of options for any translator, type the name of the executable followed by -h.

For all translators that previously had a -library option (or -oaLib in the case of mw2oa), the option is now called -lib.

LEF to OpenAccess Translator Updates

The lef2oa translator now creates constraints instead of rules. lef2oa also now creates oaViaSpec objects.

oaViaSpec Changes

oaViaSpec has been updated so that there is only one viaSpec object for any layer pair. 

To get the valid viaDefs to use:

Removed 2.1 Restriction on oaModModuleVectorInst

This release eliminates a 2.1 restriction that limited you to creating only single-bit oaModModuleVectorInsts. The majority of the public APIs are new -- the only exceptions are the items in green text, which are unchanged:

class OA_DESIGN_DLL_API oaModModuleVectorInst : public oaModModuleInst {

  public:    

    static oaModModuleVectorInst    *create(oaModule               *module,
                                            oaModule               *master,
                                            const oaScalarName     &baseName,
                                            oaUInt4                start,
                                            oaUInt4                stop); 

    static oaModModuleVectorInst    *create(oaModule               *module,
                                            const oaScalarName     &masterModuleName,
                                            const oaScalarName     &baseName,
                                            oaUInt4                start,
                                            oaUInt4                stop);   


    static oaModModuleVectorInst    *find(const oaModule      *module,
                                          const oaScalarName  &baseName,
                                          oaUInt4             start,
                                          oaUInt4             stop);

    static oaBoolean                isValidName(const oaModule        *module,
                                                const oaScalarName    &baseName,
                                                oaUInt4               start,
                                                oaUInt4               stop);

    oaModVectorInstDef         *getDef() const;
    oaUInt4                    getStart() const;
    oaUInt4                    getStop() const;
    oaModModuleVectorInstBit   *getBit(oaUInt4 bitIndex);


    void                       setBaseName(const oaScalarName  &baseName);
    void                       setRange(oaUInt4 start,
                                        oaUInt4 stop);
};

Bitwise Connectivity - Implicit instTerms

The following new features are available:

Support for Assigned Nets (Inherited Connections) in the Occurrence Domain

OpenAccess now supports the specification and resolution of assigned nets by an application. Applications can specify assigned nets as follows:

These connection definitions and assignments are automatically propagated to the occurrence domain. Applications can then directly query the terminal, instTerm, or net for the corresponding assigned net, which is returned as an occurrence net. OpenAccess also provides a diagnostic feature that applications can use to obtain the set of connection definitions and assignments that were inspected for resolving the assigned net.

The following APIs are now supported for oaOccTerm, oaOccNet, and oaOccInstTerm. 

oaOccNet    *getAssignedNet(oaBoolean           ignoreDefault = false ) const ; 
oaOccNet    *getAssignedNet(oaAssignedNetSpec   &spec, 
                            oaBoolean           ignoreDefault = false ) const ;

Embedded Module Hierarchy

Starting with this release, after expanding the occurrence hierarchy into different oaDesigns, it is possible to change the connectivity within those lower-level oaDesigns .  If the changes are made while the lower-level oaDesign is bound into the top-level occurrence hierarchy, all occurrences of the design will automatically be updated to reflect the changes.  If the lower-level oaDesign is edited in isolation, the next time the top level-design is opened, occurrence-based annotations will be discarded for all occurrences of the design.

Collections in the occurrence domain and collections going between domains are fully supported.  In addition, find() with a hierarchical path name is supported for objects within an occurrence of a lower-level design.  A set of getPathName() methods are now available on occurrence objects; these return the full path name through the occurrence hierarchy to the object.

oaAnalysisLib API Change 

void oaAnalysisLib::getFormat(oaString &format);

replaces:

void oaAnalysisLib::getAnalysisLibType(oaString &type);
void oaAnalysisLib::setFormat(const oaString &format);

replaces: 

void oaAnalysisLib::setType(const oaString &type);

APIs Moved from Route

Removed the following methods from oaRoute: 

oaNet                  *getShielding1() const;
oaNet                  *getShielding2() const;
oaBoolean              isUnShielded() const;
void                   setShielding1(oaNet *net);
void                   setShielding2(oaNet *net);
void                   setUnShielded(oaBoolean unshielded);

The following similar methods have been added to oaShape and oaVia : 

oaNet                  *getShieldedNet1() const;
oaNet                  *getShieldedNet2() const;
oaBoolean              isUnShielded() const;
void                   setShieldedNet1(oaNet *net);
void                   setShieldedNet2(oaNet *net);
void                   setUnShielded(oaBoolean unshielded);

Default Values for viaDefSpecs

The oaViaSpec object has been updated to include both a default value and a width-based lookup table value.

API Changes

This section provides details about specific API changes. For a complete list of all the API changes, see the API Change Reports.

DM API Changes

New API:

oaLib:     

oaCollection<oaView, oaLib> getViewsByName(const oaScalarName   &name) const;
Changed API:

oaView:      

static oaView     *find(const oaLib         *lib, 
                        const oaScalarName  &name, 
                        const oaViewType    *viewType);

replaces:      

static oaView     *find(const oaLib         *lib, 
                        const oaScalarName  &name);

oaViaSpec API Changes

Removed API: 
void          oaViaSpec::getName(oaString &name) const; 
void          oaViaSpec::getViaDefs(oaViaDefArray &viaDefs) const;
oaBoolean     oaViaSpec::getRangeLayer1(oaUInt4  &minWidth,
                                        oaUInt4  &maxWidth) const;
oaBoolean     oaViaSpec::getRangeLayer2(oaUInt4  &minWidth,
                                        oaUInt4  &maxWidth) const;
void          oaViaSpec::setRangeLayer1(oaUInt4  minWidth,
                                        oaUInt4  maxWidth);
void          oaViaSpec::setRangeLayer2(oaUInt4  minWidth,
                                        oaUInt4  maxWidth);
void          oaViaSpec::resetRangeLayer1();
void          oaViaSpec::resetRangeLayer2();
Changed APIs:

These new oaViaSpec APIs: 

static oaViaSpec       *create(const oaPhysicalLayer   *layer1,
                               const oaPhysicalLayer   *layer2,
                               oaViaDefArrayValue      *defaultValue);
    

static oaViaSpec       *create(const oaPhysicalLayer   *layer1,
                               const oaPhysicalLayer   *layer2,
                               oaViaDef2DTblValue      *value);

static oaViaSpec       *create(const oaPhysicalLayer   *layer1,
                               const oaPhysicalLayer   *layer2,
                               oaViaDefArrayValue      *defaultValue,
                               oaViaDef2DTblValue      *value);

static oaViaSpec       *find(const oaPhysicalLayer     *layer1,
                             const oaPhysicalLayer     *layer2);

Replace these oaViaSpec APIs:

static oaViaSpec         *create(oaTech               *tech,
                                 const oaString       &name,
                                 oaPhysicalLayer      *layer1,
                                 oaUInt4              layer1MinWidth,
                                 oaUInt4              layer1MaxWidth,
                                 oaPhysicalLayer      *layer2,
                                 oaUInt4              layer2MinWidth,
                                 oaUInt4              layer2MaxWidth,
                                 const oaViaDefArray  &viaDefs);

static oaViaSpec         *create(oaTech               *tech,
                                 const oaString       &name,
                                 oaPhysicalLayer      *layer1,
                                 oaPhysicalLayer      *layer2,
                                 const oaViaDefArray   &viaDefs);

static oaViaSpec         *find(const    oaTech     *tech,
                               const  oaString     &name);
New APIs:
oaViaDef2DTblValue            *getValue() const;

 

oaViaDefArrayValue            *getDefaultValue() const;

void                          setValue(oaViaDef2DTblValue   *value);

void                          setDefaultValue(oaViaDefArrayValue    *value);

API Change Reports

View a summary  of the OpenAccess 2.2 b001 changes with respect to 2.2 a014.

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

Database Version Changes

PCRs Fixed Between Preview A014 and Beta B001

Preview 2.2 a014

Release Highlights

Change on All UNIX Platforms (Solaris, HP, IBM, and Linux)

The OpenAccess binaries now have wrapper scripts to automatically set appropriate environment variables. Review the Environment Variables section of the Installation and Configuration Notes to understand how this affects you and the changes that you need to make before using OpenAccess.

Change on Linux Platforms

For a014, the libstdc++.so is included in the OpenAccess installation.

Platform Name Changes

The platform directory names in the installation hierarchy have been updated to be more extensible. Refer to Environment Variables in the Installation and Configuration Notes for more information.

Note About Future Releases

The following objects are still included in the code, but are being replaced by constraints and constraint groups in a subsequent release:

Automatically Updating 2.0.x Libraries to 2.2

The following limitations apply to this release of oa20to22. (These limitations will be removed in subsequent releases.)

The following objects are now translated:

The following modifications occur during the translation: 

2.0 Rule Type                                                    2.2 Constraint Type
oacMinAreaRule                      oacMinArea
oacMinEnclosedAreaRule              oacMinEnclosedArea
oacMinDensityRule                   oacMinDensity
oacMaxDensityRule                   oacMaxDensity
oacMinEdgeLengthRule                oacMinEdgeLength
oacMinSpaceRule                     oacMinSpacing
oacMinDiagonalSpaceRule             oacMinDiagonalSpacing
oacMinDiffPontentialSpaceRule       oacMinDiffPotentialSpacing
oacMinEnclosedSpaceRule             oacMinEnclosedSpacing
oacMinFillPatternSpaceRule          oacMinFillPatternSpacing
oacMinProximitySpaceRule            oacMinProximitySpacing
oacMinProtudedProximitySpaceRule    oacMinProtrudedProximitySpacing
oacMinSameNetSpaceRule              oacMinSameNetSpacing
oacMinAdjacentViaSpaceRule          oacMinAdjacentViaSpacing
oacMergeSpaceAllowedRule            oacMergeSpaceAllowed
oacMinWidthRule                     oacMinWidth
oacMinDiagonalWidthRule             oacMinDiagonalWidth
oacMinProtrusionWidtRule            oacMinProtrusionWidth
oacMaxWidthRule                     oacMaxWidth
oacMinNumCutRule                    oacMinNumCut
oacMinProtrusionNumCutRule          oacMinProtrusionNumCut
oacDefaultAntennaRule               Default model in oacAntenna
oacSecondAntennaRule                Second model in oacAntenna
oacPeakACCurrentDensityRule         Converted into layer attribute
oacAvgACCurrentDensityRule          Converted into layer attribute
oacRmsACCurrentDensityRule          Converted into layer attribute
oacAvgDCCurrentDensityRule          Converted into layer attribute
oacMinButtedAreaRule                Obsolete
2.0 Rule Type                                                  2.2 Constraint Type
oacMinClearanceRule                oacMinClearance
oacMinSameNetClearanceRule         oacMinSameNetClearance
oacMinExtRule                      oacMinExtension
oacCoincidentExtRule               oacCoincidentExtensionAllowed
oacMinOverlapRule                  oacMinOverlap
oacViaStackingAllowedRule          oacViaStackingAllowed
oacMinOppositeExtRule              oacMinDualExtension
oacMinButtedClearanceRule          Obsolete

Embedded Module Hierarchy

This release contains significant enhancements to the functionality of the occurrence domain. Previously, the occurrence hierarchy for a top-level oaDesign could only be expanded to the leaf level within the same design (to oaOccDesignInsts). For an oaOccDesignInst, getMasterOccurrence() always returned NULL.

You can now expand the occurrence hierarchy across multiple levels of oaDesign hierarchy.  You can use this capability to create a fully unfolded view of the design hierarchy when the same implementation of a block is reused several times on a chip.  In the block domain, there is only one set of oaObjects for the contents of the block.  In the occurrence domain, there is a set of oaObjects representing the contents of the block for each usage of the block within the chip. The occurrence domain stores all context-dependent information such as timing, power, and signal integrity, such that distinct values are on the oaObjects for each usage of the block.

You can decide how far the occurrence hierarchy should be expanded for your application.  When characterized models for a master are used in analysis, it usually does not make sense to expand into occurrences of that master because there is no unique information about the contents of the master to justify the overhead.  Creating occurrence data for all of the primitive occurrences in a 50 million gate design is unlikely to be desirable. Because characterized models can be created for blocks as well as for gate-level primitives, and the application chooses which set of models to use for a given analysis, OpenAccess requires the application to control the expansion in each session.

An occurrence hierarchy can contain a mixture of oaOccModuleInsts (occurrences of instances of a module) and oaOccDesignInsts (occurrences of instances of a design).  In the OpenAccess module domain, an instance of a module is defined and stored in the same database as that module, while an instance of a design is defined and stored in a different database than that design.  The same is not true in the occurrence domain for instances of oaOccurrences. In the occurrence domain, all objects in a given occurrence hierarchy are stored in the same database as the top oaOccurrence.  However, starting with the current release, the definition of the structure of the full occurrence hierarchy, as well as the set of objects within each level of the hierarchy, can come from multiple design databases.

OpenAccess does not store a complete copy of the contents of the oaDesign database for each occurrence of an oaDesign, as this would use too much memory.  Instead, OpenAccess uses the oaDesign itself as the basis for defining the occurrence hierarchy, leveraging the fact that the structural connectivity within a given oaDesign is applicable to every occurrence of that oaDesign in a chip.

The oaOccInst::getMasterOccurrence() function serves two purposes. 

When descending into the master occurrence for an oaOccDesignInst, OpenAccess automatically loads the oaDesign database containing the definition of the master, if it is not already in memory.  If the oaDesign cannot be bound, getMasterOccurrence() returns NULL indicating that the definition of the connectivity for that portion of the occurrence hierarchy is unavailable.

Current Limitations

After expanding the occurrence hierarchy into different oaDesigns, you cannot currently change the connectivity within those lower-level oaDesigns.  In a subsequent release, OpenAccess will handle connectivity changes to lower-level oaDesigns, both when the lower-level oaDesign is bound into the top-level occurrence hierarchy, and when the lower-level oaDesign is edited in isolation.

Many of the basic collections (for example, all objects of a given type within an oaOccurrence, instTerms on an instance, instTerms and terms on a net, and bus and bundle objects to member objects) are supported in the current release. Some less frequently used collections, such as oaOccNet::getMemberNets(), are not yet supported. Collections going from module or block domain objects to occurrence domain objects, such as oaModInst::getOccInsts() and oaInst::getOccInsts(), are not currently supported.

Most methods on occurrence objects are supported.  However, although some object types allow find() with a hierarchical path name, this is not yet supported when the object is within an occurrence of a lower-level design.

You cannot currently destroy objects in the occurrence hierarchy itself, although it is possible to destroy property, group, extension, and parasitics objects annotated on the occurrence hierarchy.

Safety for OpenAccess Managed Objects

Under the use model for OpenAccess managed objects, all managed objects must be created using the create() method and destroyed using the destroy() method. That is, OpenAccess does not provide the standard C++ constructors, copy constructors, destructors, or assignment operators for the managed object classes.

For example, the following operations are not allowed:

  1. oaPolygon      polygon;
  2. oaPolygon      polygonC(polygon);
  3. oaPolygon      *polygon1   = new oaPolygon;
  4. oaPolygon      *polyArray  = new oaPolygon[10];
    …
  5. polygon = *polygon1;
    …
  6. delete   polygon1;
  7. delete   [] polyArray;

This paradigm is not new in OpenAccess, but it was not stricly enforced before, which sometimes confused new users.

This paradigm will now be strictly enforced as follows:

To enforce this paradigm, the constructor, copy constructor, and assignment operator are now private for the oaObject class that is the root abstract base class for the OpenAccess managed objects. Also, the destructor is protected and will throw an exception if invoked.

Note for Clients Using the Linux GNU C/C++ Compilers

OpenAccess does not subdue compiler warnings that might be important for client code. However, recent versions of the gcc compiler unfortunately (for complex applications) generate warnings for private constructors by default. You can suppress these warnings using the –Wno-ctor-dtor-privacy compiler option. The following is a note from the GNU C++ Renovation Project:

“ The compiler warns when a class contains only private constructors or destructors, and has no friends. At the request of some of our customers, we have added a new option, ` -Wctor-dtor-privacy ' (on by default), and its negation, ` -Wno-ctor-dtor-privacy ', to control the emission of this warning. If, for example, you are working towards making your code compile warning-free, you can use ` -Wall -Wno-ctor-dtor-privacy ' to find the most common warnings.”

LEF and DEF Translators

Verilog Annotation Tool

You can now update existing OpenAccess data with terminal ordering information from a Verilog file. For more information, see Verilog Annotation Tool (verilogAnnotate).

Bitwise Connectivity

This release includes changes to the instance data model to support bitwise connectivity, as follows:

Notes

DM Changes

A new locking API is available on the oaDMFile Class: 

oaBoolean         getLock(oaDMLockType    type = oacDMWriteLock);

Gets a lock on the current file. The type argument specifies which kind of lock to get. If the lock is successfully obtained, true is returned. Otherwise, false is returned. Currently, no lock is taken, and this function always returns true. 

void              releaseLock();

Releases the lock on the current file.

oaDMLockStatus    getLockStatus() const;

Gets the lock status of the current file. Currently, this function always returns the oacNotLocked status.

This class implements an enumerated type, which designates the type of lock:

 // ***************************************************************************** 
 // oaDMLockType 
 // ***************************************************************************** 
 class oaDMLockType { 
   public: 
        oaDMLockType(oaDMLockTypeEnum   valueIn); 
        oaDMLockType(const oaString &name); 
    
        const oaString          &getName() const {return names[value];}     
        operator                oaDMLockTypeEnum() const {return value;} 
  

   private: 
        oaDMLockTypeEnum        value;     
        static const oaString   names[]; 
 };

This class implements an enumerated type, which describes the lock status:

 // ***************************************************************************** 
 // oaDMLockStatus 
 // ***************************************************************************** 
 class oaDMLockStatus { 
   public: 
        oaDMLockStatus(oaDMLockStatusEnum valueIn);     
        const oaString          &getName() const {return names[value];}     
        operator                oaDMLockStatusEnum() const {return value;}   

   private: 
        oaDMLockStatusEnum      value;     
        static const oaString   names[]; 
 };

The following API has been removed: oaLib::getServer();

Important: The following library is new and is required for linking with OpenAccess: oaPlugIn.

getType is Replaced

The getType function name has been changed to be more descriptive: 

void		    getType(oaString &name) const;

changed to 

void		    getAnalysisLibType(oaString &name) const;

Blockage Changes

oaAreaBlockage and oaAreaHalo no longer take an oaBlockageType argument, and their types default to oacPlacementBlockageType. Also, the oacPlacementBlockageType is not allowed for oaLayerBlockage and oaLayerHalo, and an exception will be thrown if this is used.

API Changes

View a summary  of the OpenAccess 2.2 a014 changes with respect to 2.2 a013.

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

Database Version Change

Fixed PCRs

Preview 2.2 a013

Release Highlights

Constraints

In future releases, more functionality will be added: iterators, find methods, and the ability to get constraint groups for various objects.

Accessing Version Information

The infrastructure is in place for providing version information for OpenAccess executables. For example, if you type oaTest -v at a command prompt, you get the following:

 Tool:           oaTest          02.02-a013      Jun 4 2004 06:00 
 Library:        oaBase          02.02-a013      Jun 4 2004 06:00 
 Library:        oaDM            02.02-a013      Jun 4 2004 06:00 
 Library:        oaTech          02.02-a013      Jun 4 2004 06:00 
 Library:        oaDesign        02.02-a013      Jun 4 2004 06:00 
 Library:        oaWafer         02.02-a013      Jun 4 2004 06:00 
 Library:        oaUnitTest      02.02-a013      Jun 4 2004 06:00

Note: Not all the OpenAccess executables have been updated to use this approach yet.

AppDefs

LEF and DEF Translators

Pin Group Replacement

mustJoin terminals are implemented.

InstTerms

Because instTerms will be introduced as part of the needed functionality for creating a multi-bit connection, a query has been added to instTerm objects to check whether instTerms are implicit. Until implicit instTerms are actually available in a future release, this function will return false.

breakEquivalence Changes

The following APIs have been removed because their behavior was problematic for some cases:

Equivalence is transitive, so if nets A and B are equivalent, and nets B and C are equivalent, then A and C are equivalent.  In a set of three or more equivalent nets like this, it is not possible to remove just the equivalence between A and B while preserving equivalence between B and C, and between A and C.  Instead, a net must be completely removed from an equivalent set, breaking all of the equivalence relationships between that net and the other nets in the set.  This capability is still available with the following APIs:

Milkyway to OpenAccess Translator

The translator class name has changed from oaMilkyway::mw2oa to oaMilkyway::MilkywayIn for consistency with the other translators.

The translator now better tolerates errors and unexpected conditions in the incoming Milkyway data.

Updated UNIX Makefiles

The oa/GNUmakefile now supports a large number of targets to assist in building not just the core oa packages, but oaUtil and all the translators. There are a set of build targets that act on everything (the core oa packages, oaUtil, and the translators).

There is another set of targets that you can use to build only a specific package or module. These targets use the four targets above appended with an underscore (_) plus the package name:

Note: Many of the translators require special environment setup for accessing third-party header files and libraries. See Optionally Compiling Translators for details.

Verilog Translators

Files renamed:

Files obsolete:

Classes renamed (within in the oaVerilog:: namespace)

OpenAccess to SPEF Translator

The oa2spef executable now depends on the oaUtil project for argument parsing. This dependency is implemented in the oaSpef translator component library.  Solutions and Makefiles have been changed to reflect this new dependency

API Changes

View a summary  of the OpenAccess 2.2 a013 changes with respect to 2.2 a012.

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

Database Version Change

Fixed PCRs

None.

Preview 2.2 a012

Release Highlights

Installation Change

The OpenAccess installers no longer automatically set required environment variables. For information about setting these variables, see Environment Variables in the Installation and Configuration Notes.

OpenAccess to SPEF Translator

This release includes the OpenAccess to SPEF Translator (oa2spef).

MilkywayTM to OpenAccess Translator

This release includes the Milkyway to OpenAccess Translator (mw2oa). mw2oa translates cells in a Milkyway library to an OpenAccess library. The translator can process all cells and views in a library, or all the cells of one specified view, or all the views of a specified cell, or a single view of a single cell. The translator cannot merge data contained in a Milkyway cell into an OpenAccess design or cellView. Reference library cells are assumed to be in the same library or in a supplied library.

A Milkyway license key is required to run the mw2oa translator.

The supported platforms are listed in the following table.

Milkyway Translator Supported Platforms
Linux (x86) 32-bit
Sun Solaris (Sparc) 32- and 64-bit
Command Line Syntax

The mw2oa command syntax is:

    mw2oa -mwLib library -oaLib library [optional arguments]

You must include the Milkyway source library and the OpenAccess destination library. If a library name does not include a path, the current directory is assumed.

Use the -help or -h argument to display command-line help. The command-line arguments are described in the following table.

Required Arguments
-mwLib library Source Milkyway library
-oaLib library Destination OpenAccess library. The translator creates a new OpenAccess library if the specified library does not exist, or it writes into an existing library. You cannot merge the information from a Milkyway cell into an existing OpenAccess cell, but cells can be added to an existing library. If a cell by the same name already exists for a given view, the cell is overwritten.
Optional Arguments
[-help | -h] Prints help
[-hierDepth number] Hierarchical depth to translate to.The defining cells for cell instances are translated only if they are included in the current library.
Not currently supported.
[-logFile file] Output log file
[-mwCell name] Milkyway cell name. If specified, only Milkyway cells matching this cell name are translated.
[-mwView name] Milkyway view name. If specified, only Milkyway cells matching this view name are translated.
[-techLib library] Technology library. If specified, the technology database is created in an OpenAccess library specified by this name. Otherwise, the technology database is created in the OpenAccess library that is specified by the -oaLib argument.

The technology file information that is transferred to the OpenAccess technology database consists of:

  • DBUperUU information
  • Layer name and layer number information
  • Standard via definitions
[-version | -v] Prints version information

Milkyway to OpenAccess Database Mapping

This section describes how information in a Milkyway database maps to OpenAccess. The mapping is divided into seven sections. Each section shows the Milkyway data and the corresponding OpenAccess object. The function in which the Milkyway data is handled in the standard translator implementation is also included.

Technology Information

Database Units per User Unit

Milkyway OpenAccess Where Implemented in the Standard Translator
DBUperUU DBUperUU convertTech()

Layer Name and Layer Number

Milkyway OpenAccess Where Implemented in the Standard Translator
mwLayerName
mwLayerNumber		 oaString
oaLayerNum		 convertLayers(), convertLayer()

Via Definitions

Milkyway OpenAccess Where Implemented in the Standard Translator
contactCode stdViaDef convertContactCodes(), convertContactCode()

Library Information
Milkyway OpenAccess Where Implemented in the Standard Translator
Library oaLib createOAlib()
Hierarchy Information
Milkyway OpenAccess Where Implemented in the Standard Translator
Cell
View
ViewType		 oaDesign, oaBlock
oaView
 oaViewType		 convertCell()
CellInst oaScalarInst convertInsts(), convertInst()
CellInstMaster oaInstHeader Created automatically
Netlist Information
Milkyway OpenAccess Where Implemented in the Standard Translator
Net oaScalarNet convertNets(), convertNet()
Port oaScalarTerm convertPorts(), convertPort()
PortInst oaInstTerm convertPortInsts(), convertPortInst()
PortInstMaster private Created automatically
Physical Information
Milkyway OpenAccess Where Implemented in the Standard Translator
Pin
no points
rectangles
polygon
points array		 oaPin
oaDot at 0,0
oaRect
oaPolygon
oaPointArray		 convertPins(), convertPin()
convertPinDot()
convertPinRects()
convertPinPolygon()
convertPoints()
Rectangle
layer		 oaRect, oaBox
oaLayer		 convertRects(), convertRect()
Polygon
points array
layer		 oaPolygon, oaPoints oaPointArray
oaLayer		 convertPolygons(), convertPolygon()
convertPoints()
Text Object
layer
justification
position, rotation, mirror font		 oaText oaLayer
oaAlign
oaTransform
oaFont		 convertTexts(), convertText()
Path oaPath convertPaths(), convertPath()
Boundary oaAreaBoundary, oaPRBoundary convertBoundarys(), convertBoundary()
Routing Information
Milkyway OpenAccess Where Implemented in the Standard Translator
Contact (via) oaStdVia convertContacts(), convertContact()
WireMaster (idx)
horizontal wire
vertical wire		 oaSegStyle
oaPathSeg
oaPathSeg		 convertWireMasters(), convertWireMaster()
convertWires(), convertWire()
convertWires(), convertWire()
Extension Information
Milkyway OpenAccess Where Implemented in the Standard Translator
Property on cell   convertCellProps(), convertProp()
Property on cell obj   convertObjProps(), convertProps()
Group oaGroup convertGroups(), convertGroup()

Library Definition Files

New and Changed API

New: oaBoolean oaLib::isMarkedToBeClosed();
This function indicates whether or not this library is marked as to-be-closed. A library marked as to-be-closed is not included in the new set of definitions, so is closed as new library definitions are loaded.

Changed: oaBoolean oaLibDefFileCallback::onPreLoad();
This callback indicates that the library definitions are going to be loaded from the library definition file. In your code, check whether the libraries you are using are marked as to-be-closed. If they are, clean up by closing all the existing databases in those libraries.  At this point, you can also stop the library definitions from reloading by returning false in this callback.

Debugging on Windows

Visual .NET Program Database Files for the OpenAccess libraries are now included in the Complete installation for the Windows platform.  When linking applications against the debug version of the OpenAccess libraries, the Program Database Files enable stepping into the OpenAccess implementation in the debugger.

The Program Database Files contain the full path of the source files in the original hierarchy used to build the OpenAccess libraries. Generally, the path to an installation hierarchy on a user's machine will be different, and in this case, Visual .NET will display the following dialog when first stepping into an OpenAccess function:

Use the dialog to locate the same source file within your installation hierarchy.  This only needs to be done once; other source files in the same installation hierarchy are then found automatically.

Bitwise Connectivity

The following bitwise connectivity features are available:

Important: Code that assumes that there are only single-bit busNets and busTerms to process might not function properly now that busNetBits and busTermBits are explicitly created.

The bitwise connectivity functionality is being made available incrementally in order to allow applications to synchronize their code to the changes. Specifically, the changes are as follows:

LEF/DEF and Verilog Translator Behavior Changes Related to Bitwise Connectivity

Region Query

The following new features are available:

oaDesignInst Changes

oaLayerMap/oaLayerMapArray

These two utility classes implement an array of mapping layers.

Hashing on the Unbound RefHeader List (Performance Improvements)

Packaging Changes

This release includes a new <install_dir>/data directory, which includes platform-independent data files.

Updating 2.0 Application Source Code to 2.2 (oa20to22src)

A script that automatically updates client source code to reflect changes to the object names in OpenAccess 2.2 is available in under <install_dir>/bin/oa20to22src.

Updating 2.0 Libraries to 2.2 (oa20to22)

The oa20to22 translator lets you create an OpenAccess 2.2 design library from an OpenAccess 2.0.x design library.

On Windows, make sure that the Cadence cdsCommon DLLs are in your path. (The cdsCommon DLLs are typically included in <install_dir>/tools/bin.) This is not required on the UNIX platforms.

Usage:
oa20to22 -cdsLib path -lib name -path destPath -log file                      

Required Arguments
-cdsLib path cds.lib file that contains the definition of the 2.0 library to translate.
-lib name Name of the source library to translate.
-path destPath Path to which the destination library is written.
Optional Arguments
[-libMode mode] Name of the library mode, such as for compatibility with the Cadence 5.x library mode.
Not currently supported.
[-log file] Name of the log file. The default is oa20to22.log in the current working directory.
[-help | -h] Prints help.

The following limitations currently apply when converting libraries from 2.0 to 2.2 . These limitations will be removed in a subsequent release.

  1. 2.0 technology rules are ignored.
  2. Application extensions (appDefs) on all databases are ignored.
  3. The supermaster of a parameterized cell is translated into a non-parameterized design. A parameterized cell instance and its parameter values are translated (because its master is not a supermaster, it is treated as a regular instance and no sub-master is created).
  4. All oaDDObjectDBs are ignored.
  5. All 2.2 libraries created by the translator will be “turbo” libraries. The -libMode option for compatibility with the Cadence 5.X library structure is currently not supported.

The following modification occur during the conversion:

API Changes

View a summary  of the OpenAccess 2.2 a012 changes with respect to 2.2 a011.

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

Note: The summaries now include information about enums.

Database Version Change

Fixed PCRs

Preview 2.2 a011

Release Highlights

API Complete

This is the first preview release in which the header files reflect the complete OpenAccess API. While the interfaces themselves are fully defined, some functions are not yet implemented. There are two approaches used for portions of the API that are not yet supported:

The documentation for unimplemented functions looks like this:

Note: The Version Control APIs are an exception to the API complete milestone. Other exceptions might surface as the product groups more fully exercise the API.

Updating Application Source Code

A script that automatically updates client source code to reflect changes to the object names in OpenAccess 2.2 is available in under <install_dir>/bin/oa20to22src. (The script was previously named UpdateToOA22.)

There are several companion files that contain the rules that oa20to22src uses:

You can run the updater in different modes specified by a command-line option.

********************************************************************************
oa20to22src version 02.20
********************************************************************************
Usage:  Updates application source code to reflect changes to class
        names and some other aspects of the API in going from
        OpenAccess 2.0 to OpenAccess 2.2.  Other changes to the API
        are not covered by this utility and must be updated manually.

Syntax: oa20to22src
        -file fileList   Source files to update       
        [-diff]          Show diff of each file without saving changes
        [-query]         Show diff of each file, prompt whether to save changes
        [-silent]        Make changes silently in place
        [-test]          Test changes, saving them in file.oa22 for each file
                         (This is the default)
        [-type
           appDefs       Update for changes to appDef class names
           | enums       Update for changes to enum names
           | design]     Update for changes from oaCellView to oaDesign and
                         other packaging details
                         Important: The design type must be used only once on
                                    a given source file, because oaCellView is
                                    used in the OA 2.2 API for a different
                                    purpose.
        [-help | -h]     Prints help
        [-version | -v]  Prints version information

The –diff option lets you get a quick feel about what will be changed, while the –test option is useful for doing a graphical diff.  The –silent option is useful after confirming that the changes are correct with either –diff or –test.

The script attempts to update class names and variable names in a consistent way, but the changes it makes may not be appropriate for all client code.  Because “Design” contains fewer letters than “CellView”, the script will affect the format of the source code. After running the script, you should inspect the modified files and fix any issues introduced by the script.

Terminal Ordering

OpenAccess has extended its connectivity model to better support the connection semantics of Verilog and other netlist formats. You can now connect nets to an instance terminal that is bound to a terminal position in the instance master rather than by a terminal name or reference.

Terminals can be assigned a position number. The terminal APIs in the block, module, and occurrence domains have been updated as follows: 

      void    setPosition(oaUInt4 position);
      void    unsetPosition(); 
      static  oaModTerm      *find(const  oaModule    *module,
                                   oaUInt4            position); 
      static  oaUInt4        getMaxPosition(const  oaModule   *module); 
      void    getTermsByPosition(oaModTermArray   &array) const ;

You can create InstTerms that connect to a terminal position rather than to a terminal name or terminal reference. Binding to a terminal position succeeds if there is a terminal at the specified position and if the number of bits of the connection matches the number of bits in the associated net. The instTerm APIs in the block, module, and occurrence domains have been updated as follows: 

      static  oaModInstTerm  *create(oaModNet    *net,
                                     oaModInst   *inst,
                                     oaUInt4     termPosition); 
      static    oaModInstTerm  *find(const  oaModInst   *inst,
                                     oaUInt4            termPosition);
                                     oaUInt4            getTermPosition() const ;
                                     oaBoolean          usesTermPosition() const ;

To avoid confusing the interpretation of the connections established by instTerms, OpenAccess adds a restriction that all of the instTerms associated with a particular instance must be connected by name/reference or be connected by position. An exception is thrown if you try to create an instTerm by position on an instance in which the existing instTerms connect by name. Likewise, an exception is thrown if you try to create an instTerm by name on an instance in which the existing instTerms connect by position. A new method has been added to instances that lets you query how an instance is connected. For example, on oaModInst, there is the following method:

oaBoolean     usesTermPositions() const ;

This function returns false if the instance has no associated instTerms.

There are changes in behavior for some of the methods on instTerms.

Enhancements for oaRoute

oaRoute objects have a new purpose attribute that indicates the intended use of the route and is not related to technology purposes. Two new APIs, getPurpose() and setPurpose(), let you query and modify this attribute. By default, every new route has a generic type, which an application can override with a different purpose. All available purposes are contained in a new oaRoutePurposeEnum enumeration that is facilitated by the oaRoutePurpose class.

Refer to the documentation for the oaRoute and oaRoutePurpose classes for more details.

New Technology Bindings for oaLayerHeader

oaLayerHeader objects now bind to the technology oaLayer objects for the layers they represent. Two new APIs, isBound() and getLayer(), are available for public use. You can now get the technology oaLayer object directly from the oaLayerHeader object. getLayer() always makes an attempt to bind the layerHeader if it is unbound and returns NULL on failure.

Refer to the documentation of oaLayerHeader class for more details.

New Technology Bindings for oaLPPHeader

oaLPPHeader objects now bind to the technology oaLayer and oaPurpose objects for the layer-purpose pairs they represent. An oaLPPHeader object is considered bound only if both the layer and purpose bindings are successful. Three new APIs, isBound(), getLayer() and getPurpose(), are available for public use. You can now get the technology oaLayer and oaPurpose objects directly from the oaLPPHeader object. Both getLayer() and getPurpose attempt to bind the LPPHeader if it is unbound and return NULL if the bindings for both layer and purpose cannot be made.

Refer to the documentation of the oaLPPHeader class for more details.

Association of oaLPPHeaders with oaLayerHeaders

oaLPPHeader objects now verify that an oaLayerHeader object exists for the layer in the layer-purpose pair they represent. Thus, the creation of a new oaLPPHeader object might trigger the creation of a new oaLayerHeader object in the design hierarchy, and these two objects continue to propagate in the hierarchy as before (relevant for region query). The collection of oaLayerHeaders for an oaBlock now represents all the layers in use by different objects (that have layer association) in the design hierarchy below and including the block.

A new API in the oaLayerHeader class lets a client access the collection of oaLPPHeader objects associated with the oaLayerHeader. A new API in the oaLPPHeader class allows a client to query the oaLayerHeader object for the oaLPPHeader object being queried. Note that an oaLayerHeader object cannot have any oaLPPHeaders objects associated with it while an oaLPPHeader object will always have an oaLayerHeader object associated with it.

Refer to the documentation of the oaLayerHeader and oaLPPHeader classes for more details.

oaDesign API Change

Database Extensions

The following class names have changed:

Also, the database extension classes are now managed objects. You can no longer create AppDef objects by calling the constructor. For example, instead of creating a new oaIntAppDef, use the oaIntAppDef::get() method to obtain a pointer to the AppDef.

Region Query

Dynamic binding of instance headers is now supported.

Note: Dynamic binding of via headers is not yet supported.

Support For Library Definition Files

Support for Equivalent Nets

With Embedded Module Hierarchy, assignments in the module domain will now result in equivalent nets in the block domain, and layout tools need to handle this in order to properly implement the logic functionality.  The layout information for all of the nets in an equivalent set should be stored on the preferred equivalent.

The oaInstTerm::getNet() and oaTerm::getNet() methods now take an optional argument to specify that the preferred equivalent net should be returned instead of the directly connected net.  In addition, the oaNet::getInstTerms() and oaNet::getTerms() methods now take a filterFlags argument to specify that the collection should include all of the instTerms or terms connected to any of the nets in an equivalent set, in addition to the ones on the directly connected net.

Source Code Changes for Translators

The C++ namespaces for the translators have changed.

Stream Translators
LEF/DEF Translators
Verilog Translators

API Changes

View a summary  of the OpenAccess 2.2 a011 changes with respect to 2.2 a010.

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

Database Version Changes

Fixed PCRs

Preview 2.2 a010

Release Highlights

oaViewType Changes

oaViewTypes are now implemented as oaSessionObjects instead of enumerated types, which allows users to define their own persistent viewTypes.

An oaViewType is an object with a single attribute, a string name. oaViewTypes can be created and found.

Reserved viewTypes

The oaReservedViewType utility class is an enumerated type wrapper that defines the OpenAccess reserved viewTypes:   

The reserved viewTypes are always predefined and available as oaViewTypes. The static oaViewType::get(oaReservedViewType) method allows fast and easy access to the reserved viewTypes.

New API
// *****************************************************************************
// oaViewType
// *****************************************************************************
class OA_DM_DLL_API oaViewType : public oaSessionObject {
  public:
    static oaViewType     *create(const oaString  &name);
    static oaViewType     *find(const oaString    &name);
    static oaViewType     *get(oaReservedViewType type);
 
    void                  getName(oaString &name) const;
 
    static oaCollection<oaViewType, oaSession> getViewTypes();
};

The collection of session viewTypes is the union of all reserved viewTypes, all viewTypes defined by users in the course of the session, and all user-defined viewTypes used in libraries that were opened during the session. ViewTypes are not destroyed.

The following API has also changed: 

static oaDesign    *open(const oaScalarName &libNameIn,
                         const oaScalarName &cellNameIn,
                         const oaScalarName &viewNameIn,
                         const oaViewType   *viewType,
                         oaChar              mode);

When opening a cellView, viewTypes are still restricted to the set of reserved design viewTypes:

You can use the oaViewType::get(oaReservedViewType) API to construct the viewType objects to pass into the oaDesign::open() API.

In addition, all APIs for user units and database units on the Tech class now take an oaViewType pointer. These viewTypes are also restricted to the set of reserved viewTypes for design.

 

The -Z Option for Region Query Has Changed Meaning

When you provide the -Z option on the command line, OpenAccess forces the loading of the built-in region query plug-in rather than other available plug-ins. In previous releases, the -Z option functioned differently and did not load the built-in region query plug-in.

Equivalent Nets in Module and Block Domains

When equivalent nets are created in the module domain, corresponding equivalences are now created properly in the occurrence and block domains.

oaArray Changes

Some of the array utility classes, such as oaRouteObjectArray, have been consolidated to be derived from a template base class, oaArray<T>. Also, three new arrays have been introduced based on the template class:

Clients might need to make minor modifications to their code to make use of the methods of the oaArray<T> template class. Clients might need to replace getNumObjects() with getNumElements(), and setNumObjects() with setNumElements(). The subscript operators will continue to function as before

Region Query Updates

New Functionality
Not Yet Supported

Re-Introduction of oaLayerHeader Objects

In OpenAccess 2.0, oaLayerHeader objects were associated with oaBlockage and route segments. For the early phase of OpenAccess 2.2, oaLayerHeader objects were removed from the hierarchy because all the route objects became managed objects and blockages were moved to be associated with oaLPPHeaders with a fixed purpose. oaLayerHeader objects have been reintroduced in the hierarchy to support the association of guides, Steiners, blockages, and rules to layers without associated technology purposes.

Please refer to the documentation for oaLayerHeader for more details.

Updates for oaBlockage Objects

oaBlockage objects now relate to oaLayerHeader objects. The oaBlockage object interface lets clients query the layerHeader from the blockage. Note that placement-type blockages do not have a layer associated with them and are not related to layerHeaders. The oaLayerHeader interface provides the merged bBox of all blockages on that layer and the collection of blockages on that layer.

Please refer to the documentation for oaBlockage and oaLayerHeader for more details.

Updated for oaGuide Objects

Guides have an optional start and end layer and have been updated to relate to oaLayerHeader objects. Guide objects now provide an interface for clients to query the layerHeaders for the start and end layers. oaLayerHeader now provides an interface for clients to access all guides that start on a specific layer, end on a specific layer, or the unique set of guides that either start or end on a specific layer. The oaLayerHeader interface has also been updated to provide the merged bBox of all the guides that start or end on a specific layer.

New oaSteiner Functionality

Refer to the documentation for oaSteiner, oaNet, and oaLayerHeader for more details.

Updates to the oaViaParam Cut Pattern Interface

The public oaViaParam cut pattern interface has been updated to make it more safe. The oaViaParam object will no longer allow an application to specify a cut pattern that was encoded by the application and might be different than the encoding used by OpenAccess. The encoding is handled internally. Allocating a cut pattern whose size might not match the cut matrix is also no longer permitted.

The following unsafe methods have been removed from the public interface: 

oaByte    *getCutPattern() const;
void      setCutPattern(oaByte *cutPattern);

oaUInt4   getCutPatternSize() const;
void      setCutPatternSize(oaUInt4 size);

void      allocCutPattern(oaUInt4 size);
void      allocCutPattern(oaUInt4 numCutRows, oaUInt4 numCutCols);
void      freeCutPattern();

Two new methods have been added to the cut pattern interface: 

oaBoolean hasDefaultCutPattern() const; 
void           setDefaultCutPattern();

Clients can now directly use setCutPatternVal() to customize the cutPattern and use getCutPatternVal() to retrieve the customized cutPattern. hasDefaultCutPattern() returns FALSE for a customized cutPattern and TRUE for the default cutPattern, which assumes that all cuts exist. A customized cutPattern can be reset to the default by using setDefaultCutPattern().

The row and column bounds for getCutPatternVal() and setCutPatternVal() are determined by the values that the client sets with setCutRows() and setCutColumns(), which are 1 by default. Also, a change to either the number of cut rows or cut columns after the cut pattern has been customized results in resetting the cutPattern to the default cut pattern.

Refer to the oaViaParam documentation for more details.

API Changes

View a summary  of the OpenAccess 2.2 a010 changes with respect to 2.2 a009.

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

Fixed PCRs

Preview 2.2 a009

Release Highlights

Bit Order on Vectored Objects

This release includes the following:

Table of Contents and Database Size Limit

Region Query

Queries are supported for:

Updates are supported for:

oaRouteObjArray Class Renamed to oaRouteObjectArray

The oaRouteObjArray class has been renamed to oaRouteObjectArray. Also, two of its methods – getNumObjs() and setNumObjs() – have been renamed to getNumObjects() and setNumObjects() respectively. See oaRouteObjectArray for more information.

Enhancements for oaRoute Objects

Two new methods have been added:

See oaRoute for more information.

Enhancements for oaVia Objects

oaVia objects have been enhanced to form a logical binding with oaRoute objects when they become part of a route. If the via belonged to a net, it is removed from the net and the route's net applies to the via. If the via is removed from the route, it acquires the route's net. If a via that is part of a route is destroyed, the route is updated to remove the via from it first. An exception is thrown if an attempt is made to add or remove a via from a net if the via belongs to a route. The interface methods, hasRoute(), getRoute(), hasNet(), and getNet(), are now available.

See oaVia for more information.

Enhancements for oaPathSeg Objects

oaPathSeg objects have been enhanced to form a logical binding with oaRoute objects when they become part of a route. If the pathSeg belonged to a net, it is removed from the net and the route's net applies to the pathSeg. If the pathSeg is removed from the route, it acquires the route's net. If a pathSeg that is part of a route is destroyed, the route is updated to remove the pathSeg from it first. An exception is thrown if an attempt is made to add or remove a pathSeg from a net if the pathSeg belongs to a route. The interface methods, hasRoute(), getRoute(), hasNet(), and getNet(), are now available.

See oaPathSeg for more information.

Specialized Collections for Guides, Vias, and Shapes on a Net

To work effectively with route and pin figures, the collection of guides, vias and shapes available off a net can now be customized based on application needs. The getShapes(), getVias(), and getGuides() methods on oaNet now take an additional parameter that customizes their behavior.

The updated oaNet interface for accessing these collection is as follows:

Refer to oaNet for more information.

Pin Group Replacement Changes

There are two new classes under oaFig:

The remaining figures (which are not pin figures or connectivity figures) are directly derived from oaFig. These are oaBoundary, oaMarker, and so forth.

An oaPin is now created without a figure. Figures need to be added to an oaPin using the oaPinFig::addToPin API. This allows for multiple figures on a pin. Removing pin figures is done using oaPinFig::removeFromPin. Importantly, the hasPin/getPin API no longer exists on oaFig. It is now on oaPinFig. This means all existing code accessing pin figures must be changed.

The API for adding/removing connectivity figures from nets is now on oaConnFig instead of on the separate classes.

oaModule Name Changes

In OpenAccess 2.1, modules are named like cellViews, using a lib/cell/view triplet with an optional variant name. The intent was to facilitate tracking of uniquified variants derived from an original module, particularly when the variants are moved from one library to another using oaModule::embed() or oaModule::detach(). However, when EMH, there are cases in which the lib/cell/view/variant naming approach is not robust enough to properly track the variants.

The lib/cell/view approach also implies a relationship to the library data model that does not really exist, which allowed a number of inconsistencies in the data model.  In OpenAccess 2.1, you can create a module named libX/cellY/viewZ in a cellView named libA/cellB/viewC. The library portion of the module's name (libX) did not have to correspond to any real library in the design, and in fact the module is defined within libA, not within libX. Similarly, the cell portion of the module's name (cellY) does not have to correspond to any real cell in the design; the module is actually defined in cellB, not in cellY. Even if there is a cellY in libA, the module would not have to have any relationship to that cell.

A third set of issues arises from the fact that the modules in EMH are often created from Verilog. In a Verilog netlist, modules have a single name, so a Verilog translator that creates an OpenAccess database must make up a lib/cell/view triplet for each oaModule. In OA 2.1, a convention of setting the cell name to the Verilog module name, and the lib name and view name to be same as the containing cellView was used, but that convention is awkward as oaModules are moved from one cellView to another with embed and detach.

OpenAccess 2.2 uses a single name for modules, like other objects contained within an oaDesign. Tracking variants is still possible, but the only information kept is the original module from which a variant was derived. All variants derived from the same module have an origName attribute set to the name of the original module. When a variant is created through oaOccurrence::uniquify(), applications can specify the new module name to be used for the variant, or allow the database to choose a name automatically.

Related methods have been modified on the following classes:

See API Changes for more information.

OpenAccess to Verilog Translator (oa2verilog)

You can translate information from the OpenAccess database to Verilog using the oa2verilog command-line executable.

UNIX Windows
oa2verilog oa2verilog.exe

To export OpenAccess data to Verilog

Enter:

oa2verilog -lib library -cell cell -view view

The oa2verilog command traverses all the modules in the input library, cell, and view and produces a Verilog netlist for each module. By default, the netlist is written to a file named after the input cell name in the current working directory.

Argument Descriptions

The following section describes the arguments for oa2verilog. Optional arguments are shown in square brackets. 

        -lib library
        -cell cell                                 
        -view view              
        [-global modName]       
        [-help | -h]            
        [-output file]          
        [-recursive]                                         
        [-tieLow net]           
        [-tieHigh net]          
        [-version | -v]         
        [-leafFile fileName]
lib library

Specifies the input library name.

cell cell

Specifies the input cell name.

view view

Specifies the input view name.

global modName

Specifies the name of the module in which to define global nets, if any exist.
The default is globals.

help
h

Prints the command summary.

output file

Specifies the name of the Verilog file to create. You can provide a file name or a file/path name.
The default is the name of the cell with a .v extension.

recursive

Writes out all oaDesigns in the hierarchy that are in the same directory and have the same top view name as the top-level design.
By default, only the top module is translated.

tieLow net

Specifies the name of the tie low net. Nets that are equivalent to the tie low net produce assign statements to 1'b0. Instances whose instTerms are tied to one of these nets produce module instantiations with 1'b0 as the connecting net in the list of port connections. If a bus is tied to a bundle that is comprised of the tie low and tie high nets, the connection will be to a constant of the form 'b10001010011101... where bundle members of the tie low net become zeros and bundle members of the tie high net become ones. For example, if net "tie0,2*tie1,tie0" is connected to terminal "a[3:0]" of instance "I1", the module instantiation in the output Verilog file is "I1(.a('b0110)…)"
The default tie low net name is tie0.

tieHigh net

Specifies the name of the tie high net. Nets that are equivalent to the tie high net produce assign statements to 1'b1. Instances whose instTerms are tied to one of these nets produce module instantiations with 1'b1 as the connecting net in the list of port connections. If a bus is tied to a bundle that is comprised of the tie low and tie high nets, the connection will be to a constant of the form 'b10001010011101... where bundle members of the tie low net become zeros and bundle members of the tie high net become ones. See tieLow net above for an example.
The default is tie1.

version
v

Prints out the version information.

leafFile fileName

By default, Verilog module definitions for leaf cells (stubs) are written to the file specified with the output option.  If you supply the leafFile option, the stub module definitions are written to the given file name instead. 

New Session Database Class

The oaSession class implements a session database, which is a non-persistent database used as a parent for session-wide information.

The oaSession database is a VM-only database that serves as a parent to session objects. Session objects are transient objects that are valid for the entire OpenAccess session. The session db is automatically created and maintained as needed by the OpenAccess implementation. There is only one session database per OpenAccess session.

Session objects may have a persistent representation. In some cases, the session objects represent information that is a superset of information compiled from the databases that are opened in the OpenAccess session. An example of a session object is the oaLibDef object.

It is not legal to create properties or appDefs on session objects, nor is it legal to add these objects to groups. (Note that this restriction is not yet implemented.)

oaLibDef Class

oaLibDefs are now implemented as session objects. Previously, libDefs were implemented as static methods on the oaLib object. This means that all code that uses libDefs must be modified to use the oaLibDef object.

You can find, create, and destroy oaLibDefs just like any other oaObject. Because they are oaSessionObjects, oaLibDef objects are valid for the entire OpenAccess session.

Creating an oaLibDef object requires a library name and a library path. Additional information needed for initializing the library is added through attributes on the oaLibDef. Each oaLibDef may have 0 or more attributes. An attribute is a string name/string value pair. If the attribute value is not naturally a string, then the value is interpreted by the user, which is typically the design management (DM) plug-in.

In the reference implementation, there are three supported attributes:

Each of these optional attributes has information specific to server initialization.

Example 
// This code adds a new library definition if it does not already exist.       
oaScalarName    libName(oaUnixNS(), "myLibName");
oaString        libPath("myLibPath);
 
if (!oaLibDef::find(libName)) {
   oaLibDef    *libDef = oaLibDef::create(libName, libPath);
   libDef->addAttribute("serverLogFileName", "./testServer.slog");
}

API Changes

View a summary  of the OpenAccess 2.2 a009 changes with respect to 2.2 a008.

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

Database Version Changes

Fixed PCRs

Preview 2.2 a008

Release Highlights

Starting with the a008 release, all OpenAccess classes and types will be declared in the OpenAccess_4 namespace, where 4 stands for the major API revision number for OpenAccess 2.2. The full namespace, OpenAccess_4, will be aliased to oa, and this is what the application should reference. 

namespace OpenAccess_4 { 
    // Declarations for all public API classes and functions 
} 
namespace oa = OpenAccess_4;

The oa alias provides two benefits:

Applications can promote the oa namespace to the global namespace, which is recommended: 

#include "oaDesignDB.h"
using namespace oa;

Or, applications can choose to fully qualify classes and types in the oa namespace.

Bit Order on Vectored Objects

This release includes the following:

Design Data Management (DM)

Rule Enhancements

The oaRoute::isWellFormed() method has been replaced by oaRoute::isContiguous (), which has similar semantics.

Enhancements to oaGuide Objects

In previous releases, oaGuide was a standalone object that could not be added to a route. oaGuide has been redefined with a different interface, and the new version can be added to a route. When an oaGuide is added to a route, an association is formed between the route and the guide. If the guide belonged to a net, it is first removed from the net, and then the route's net applies to the guide.

When a guide is part of a route, trying to add the guide to a net or remove it from a net will throw an exception. If the guide is removed from the route, it will acquire the route's net. If a guide that belongs to a route is destroyed, it is automatically removed from the route.

Three new methods, hasRoute(), getRoute(), and hasNet() are available. Also, the getNet() method has been updated . See the oaGuide API documentation for more information.

API Changes

View a summary  of the OpenAccess 2.2 a008 changes with respect to 2.2 a007.

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

Fixed PCRs

Preview 2.2 a007

Release date: 3/19/2004

Note: The LEF and DEF translators now depend on the lefdefInt05.60-d005 kit from CAT (as opposed to lefdefInt05.51-s002). This does not mean that LEF/DEF 5.6 is supported.

Release Highlights

Enhancement to Reduced Models

A delay attribute has been added to the oaPoleResidue object to represent the Elmore delay from a particular driver to a receiver (in addition to the existing set of poles and residues).

The oaPoleResidue object is for use with moment-based approaches for using poles and residues to approximate the transfer function for propagating across the parasitic network. These approaches do not use the Elmore delay.  However, the Standard Parasitic Exchange Format (SPEF) syntax requires that an Elmore delay be specified along with the poles and residues.  Including the Elmore delay as part of the oaPoleResidue enables lossless round trips between OpenAccess and SPEF, and it ensures that oaPoleResidues created by other applications can be written out properly to SPEF.

In the oaPoleResidue API, three changes will support the Elmore delay, as shown below.  These changes include an additional constructor argument and two new methods to set and get the delay.

// *****************************************************************************
// oaPoleResidue
// *****************************************************************************
class OA_DESIGN_DLL_API oaPoleResidue : public oaDesignObject {
  public:
    static oaPoleResidue    *create(oaPiPoleResidue                 *model,
                                    oaDesignObject                  *receiver,
                                    oaFloat                         delay,
                                    const oaComplexArray<oaFloat>   &poles,
                                    const oaComplexArray<oaFloat>   &residues);

    static oaPoleResidue    *find(const oaPiPoleResidue *model,
                                  const oaDesignObject  *receiver);

    void                    destroy();

    void                    setDelay(oaFloat    delay);
    void                    setPoles(const oaComplexArray<oaFloat>  &poles);
    void                    setResidues(const oaComplexArray<oaFloat>   &res);

    oaFloat                 getDelay() const;
    void                    getPoles(oaComplexArray<oaFloat>  &poles) const;
    void                    getResidues(oaComplexArray<oaFloat> &res) const;

    oaDesignObject          *getReceiver() const;
    oaPiPoleResidue         *getPiPoleResidue() const;

    enum                    {dtIndex = oacPoleResidueDataType};
    enum                    {domain = oacNoDomain};
};

Manufacturing Grid Enhancements

OpenAccess now supports a technology level value (default value) for the manufacturing grid (not the routing grid):

Bit Order on Vectored Objects

This release includes the following:

API Changes

View a summary  of the OpenAccess 2.2 a007 changes with respect to 2.2 a006.

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

Fixed PCRs

Preview 2.2 a006

Release date: 3/3/2004

Release Highlights

Binding Function Clean Up

oaDesign::bindSuperMaster() has been removed. If there are changes to the code and pCell parameters associated with an existing superMaster, call oaDesign::defineSuperMaster() to redefine that superMaster. The redefinition of a superMaster binds it to the new code and pCell parameter set.

Simplification of oaGuide Object

The simplification of the oaGuide object has a significant impact on its API.

Some APIs Now Take oaDouble for Scale and Angle Arguments

The following APIs now take oaDouble instead of oaFloat for the scale and angle arguments.

void oaPoint::transform(oaDouble       scale,
                        oaDouble       angle,
                        oaPointArray   &result) const;

void oaPoint::transform(oaDouble  scale,
                        oaDouble  angle);

void oaBox::transform(oaDouble        scale,
                      oaDouble        angle,
                      oaPointArray    &result) const;

void oaBox::transform(oaDouble  scale,
                      oaDouble  angle);

void oaShape::transform(oaDouble  scale,
                        oaDouble  angle);

void oaMarker::transform(oaDouble  scale,
                         oaDouble  angle);

void oaBoundary::transform(oaDouble  scale,
                           oaDouble  angle);

void oaBlockage::transform(oaDouble  scale,
                           oaDouble  angle);

void oaPointArray::transform(oaDouble       scale,
                             oaDouble       angle,
                             oaPointArray   &result) const;

void oaPointArray::transform(oaDouble  scale,
                             oaDouble  angle);

API Changes

View a summary  of the OpenAccess 2.2 a006 changes with respect to 2.2 a005.

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

Preview 2.2 a005

Release date: 02/20/2004

Release Highlights

Verilog Translator (verilog2oa)

The verilog2oa command-line executable lets you translate Verilog data into the OpenAccess database format.

For more information, see verilog2oa.

Capacity Improvements for Routes

There are some significant improvements to capacity for routes.

Reticle Database Renamed

The oaReticle database has been renamed to oaWafer.

Occurrence Shapes

This project extends the OpenAccess data model to include new objects that represent unique occurrences of shapes in a design hierarchy. These new oaOccShape objects do not represent new data; they are simply an alternate way of viewing existing data objects. The prototype for the oaOccShape is shown below. 

// *****************************************************************************
// oaOccShape 
// *****************************************************************************
class OA_DESIGN_DLL_API oaOccShape { 

  public: 
	oaShape 	*getShape() const; 
	void 		getBBox(oaBox &bBox) const;
	void 		getHierPath(oaHierPath &hierPath) const;
	oaLPPHeader 	*getHeader() const; 
	oaLayerNum 	getLayerNum() const; 
	oaPurposeNum 	getPurposeNum() const; 
	oaNet 		*getNet();
	oaRouteStatus 	getRouteStatus() const;
	oaBoolean 	hasPin() const; 
	oaPin 		*getPin(); 
	oaBoolean 	hasNet() const; 

	enum {dtIndex = oacShapeDataType}; 
};
Differences Between oaOccShape and oaShape

The oaOccShape class is similar to the oaShape class, but there are a few significant differences:

Each type of shape will have a matching occurrence equivalent. For example, oaPath will have a corresponding oaOccPath : 

// *****************************************************************************
// oaOccPath 
// *****************************************************************************
class OA_DESIGN_DLL_API oaOccPath : public oaOccShape { 

  public: 
	oaUInt4 	getWidth() const; 
	oaUInt4 	getNumPoints() const; 
	void 		getPoints(oaPointArray &points) const; 
	oaPathStyle 	getStyle() const; 
	oaUInt4 	getBeginExt() const; 
	oaUInt4 	getEndExt() const; 
	void 		getBoundary(oaPointArray &boundary) const; 
	oaBoolean 	isOrthogonal() const; 

	static void 	genBoundary( const oaPointArray &points, 
				     oaUInt4            width, 
				     oaPathStyle        style, 
				     oaUInt4            beginExt, 
				     oaUInt4            endExt, 
				     oaPointArray      &boundary); 
}; 

Again note that the oaOccPath object has a read-only interface. Also, the path centerline and boundary point arrays will be returned within the coordinate frame of the specific path occurrence.

The oaOccShape classes are not “first-class” objects in the OpenAccess data model. This means occShapes are not saved persistently, cannot have properties attached to them, and cannot be assigned to groups.

Accessing and Managing oaOccShapes

You can use the oaShapeQuery::getOccShape() method to get oaShapes. When querying a region of a design hierarchy, applications can ask for occShapes that intersect the region. This is a significant convenience because the occShape encapsulates all the information about the shape in its context in the design hierarchy.

occShapes are dynamically generated. This keeps the virtual memory size as small as possible. A specific occShape is not created until an application requests it.

Applications are responsible for freeing the resources associated with each occShape by calling the oaOccShape::release() method.

oaOccShape API

See the oaOccShape.h file for details.

API Changes

New API: 

oaShapeQuery::getOccShape(oaShape *shape) constconst

oaHierPath::setSize(oaUInt4 newSize)
    
oaHierPath::setLevel(oaUInt4   depth,
                     oaRef     *ref,
                     oaUInt4   row,
                     oaUInt4   column) ;

Changed API:

const oaHierPath& oaRegionQuery::getHierPath() const

Is changed to:

void oaRegionQuery::getHierPath(oaHierPath &hierPath) const

Status Enum Consistency

OpenAccess 2.0 and 2.1support several different naming schemes for the public enumerated integral constant identifiers exposed to their clients. Most of these public identifiers follow a suffix style naming scheme such as the following: 

enum oaRouteStatusEnum {
    oacNormalRouteStatus	= 0,
    oacFixedRouteStatus	        = 1,
    oacLockedRouteStatus	= 2
};

The enumeration identifier oaRouteStatusEnum has an ‘oa' prefix and an ‘Enum' suffix and embeds the actual data domain representation (RouteStatus) in between.

The enum-list of identifiers representing integer constants always have the ‘oac' prefix indicating an OA constant followed by a name indicating the datum it represents, and finally being suffixed by the higher level data type representation from the enumeration identifier. Thus, the naming scheme for the fixed type of route status would imply the concatenation of the following oac -Fixed- RouteStatus to form the actual identifier name oac Fixed RouteStatus.

OpenAccess 2.2 will follow and enforce a strict suffix style policy for enumerated identifiers as described above. The goal is to keep these identifiers consistent, predictable, and readable to the OpenAccess community. The suffix style for enumerated identifiers provides good readability (for left-to-right read languages) as the primary user information is available immediately after the ‘ oac ' prefix.

Data Model and API Changes

Enforcing this policy requires that OpenAccess 2.2 redefine the minority of enumerated identifiers that do not follow this policy. A few special cases are allowed as exceptions, including identifiers for exception handling, orientations, view types, and user units.

Features

See Supplementary Information for the list of affected enumerations and their new OpenAccess 2.2 substitutions.

Compatibility Issues

As the execution of this project involves redefining the names for a number of identifiers, the resulting incompatibility requires that all OpenAccess 2.0 and 2.1 clients update their source code to use properly redefined identifier names. The impact of this compatibility issue will be mitigated by providing an automated script that substitutes all affected enumerated identifiers with the correct ones. This script will be bundled with OpenAccess 2.2.

Performance Impacts

There will be no performance impact as this project involves a simple substitution of identifier names.

Supplementary Information

The following list of enumerations will be redefined in OpenAccess 2.2. Both the old and new representations are shown.

Enumerations for oaBase

oaDBTypeEnum


Old Representation

enum oaDBTypeEnum {
    oacDBTypeBase       = UINT_MAX,
    oacDBTypeDesign     = 0,
    oacDBTypeTech       = 1,
    oacDBTypeLib        = 2,
    oacWaferDBType      = 4
};

New Representation

enum oaDBTypeEnum {
    oacBaseDBType       = UINT_MAX,
    oacDesignDBType     = 0,
    oacTechDBType       = 1,
    oacLibDBType        = 2,
    oacWaferDBType      = 4
};


oaDirIterModeEnum

Old Representation

enum oaDirIterModeEnum {
    oacDirIterModeFiles  = 0,
    oacDirIterModeDirs   = 1,
    oacDirIterModeAll    = 2
};


New Representation

enum oaDirIterModeEnum {
    oacFilesDirIterMode  = 0,
    oacDirsDirIterMode   = 1,
    oacAllDirIterMode    = 2
};


Enumerations for oaDesign


oaAssignmentAttrTypeEnum

Old Representation

enum oaAssignmentAttrTypeEnum {
    oacAssignmentAttrName   = 0
};

New Representation

enum oaAssignmentAttrTypeEnum {
    oacNameAssignmentAttrType   = 0
};

oaSymmetryEnum

Old Representation

enum oaSymmetryEnum {
    oacSymmetryNone = 0,
    oacSymmetryX    = 1,
    oacSymmetryY    = 2,
    oacSymmetryXY   = 3,
    oacSymmetryAny  = 4
};

New Representation

enum oaSymmetryEnum {
    oacNoSymmetry   = 0,
    oacXSymmetry    = 1,
    oacYSymmetry    = 2,
    oacXYSymmetry   = 3,
    oacAnySymmetry  = 4
};


oaRowSpacingTypeEnum

Old Representation

enum oaRowSpacingTypeEnum {
    oacRowSpacingTypeEvery	= 0,
    oacRowSpacingTypeEven	= 1,
    oacRowSpacingTypeOdd	= 2
};

New Representation

enum oaRowSpacingTypeEnum {
    oacEveryRowSpacingType	= 0,
    oacEvenRowSpacingType	= 1,
    oacOddRowSpacingType  	= 2
};

oaRowFlipTypeEnum

Old Representation

enum oaRowFlipTypeEnum {
    oacRowFlipTypeNone	= 0,
    oacRowFlipTypeEven	= 1,
    oacRowFlipTypeOdd	= 2
};

New Representation

enum oaRowFlipTypeEnum {
    oacNoRowFlipType	= 0,
    oacEvenRowFlipType	= 1,
    oacOddRowFlipType	= 2
};

oaDesignAttrTypeEnum

Old Representation

enum oaDesignAttrTypeEnum {
    oacDesignAttrLibName	    = 0,
    oacDesignAttrCellName	    = 1,
    oacDesignAttrViewName	    = 2,
    oacDesignAttrCellType	    = 3,
    oacDesignAttrLastSavedTime      = 4
};

New Representation

enum oaDesignAttrTypeEnum {
    oacLibNameDesignAttrType	    	= 0,
    oacCellNameDesignAttrType	    	= 1,
    oacViewNameDesignAttrType	    	= 2,
    oacCellTypeDesignAttrType	    	= 3,
    oacLastSavedTimeDesignAttrType   	= 4
};


oaCellTypeEnum

Old Representation

enum oaCellTypeEnum {
    oacCellTypeNone		     	= 0,
    oacCellTypeBlock			= 1,
    oacCellTypeBlockRing	     	= 2,
    oacCellTypeCover			= 3,
    oacCellTypeCoverBump	    	= 4,
    oacCellTypePad		     	= 5,
    oacCellTypePadSpacer	     	= 6,
    oacCellTypeCore		     	= 7,
    oacCellTypeCoreSpacer		= 8,
    oacCellTypeCoreAntenna		= 9,
    oacCellTypeCorner			= 10,
    oacCellTypeSoftMacro	     	= 11,
    oacCellTypeVia		    	= 12,
    oacCellTypeBlockBlackBox		= 13,
    oacCellTypePadAreaIO	     	= 14
};

New Representation

enum oaCellTypeEnum {
    oacNoCellType		    	= 0,
    oacBlockCellType			= 1,
    oacBlockRingCellType	     	= 2,
    oacCoverCellType			= 3,
    oacCoverBumpCellType	     	= 4,
    oacPadCellType		     	= 5,
    oacPadSpacerCellType	     	= 6,
    oacCoreCellType		     	= 7,
    oacCoreSpacerCellType		= 8,
    oacCoreAntennaCellType		= 9,
    oacCornerCellType			= 10,
    oacSoftMacroCellType	     	= 11,
    oacViaCellType		     	= 12,
    oacBlockBlackBoxCellType		= 13,
    oacPadAreaIOCellType	     	= 14
};


oaDesignCollTypeEnum

Old Representation

enum oaDesignCollTypeEnum {
    oaBaseDesignCollType	     	= 0,
    oaSubMasterDesignCollType		= 1
};


New Representation

enum oaDesignCollTypeEnum {
    oacBaseDesignCollType	     	= 0,
    oacSubMasterDesignCollType	        = 1
};

oaTermModTypeEnum

Old Representation

enum oaTermModTypeEnum {
    oacSetImplicitTermModType		     	= 2,
    oacSetTermTypeTermModType		     	= 3,
    oacMoveToNetTermModType		     	= 4,
    oacSetAntennaDataModType		     	= 5,
    oacUnsetAntennaDataModType		        = 6,
    oacSetPinConnectMethodTermModType		= 7,
    oacScalarTermSetNameTermModType		= 10,
    oacBusTermSetBaseNameTermModType		= 20,
    oacBusTermSetRangeTermModType	     	= 21,
    oacSetRouteMethodTermModType	     	= 22
};

New Representation

enum oaTermModTypeEnum {
    oacSetImplicitTermModType		     	= 2,
    oacSetTermTypeTermModType		     	= 3,
    oacMoveToNetTermModType		     	= 4,
    oacSetAntennaDataTermModType		= 5,
    oacUnsetAntennaDataTermModType		= 6,
    oacSetPinConnectMethodTermModType		= 7,
    oacScalarTermSetNameTermModType		= 10,
    oacBusTermSetBaseNameTermModType		= 20,
    oacBusTermSetRangeTermModType	     	= 21,
    oacSetRouteMethodTermModType	     	= 22
};


oaInstAttrTypeEnum

Old Representation

enum oaInstAttrTypeEnum {
    oacInstAttrLibName	    	= 0,
    oacInstAttrCellName	        = 1,
    oacInstAttrViewName	        = 2,
    oacInstAttrName	       	= 3,
    oacInstAttrOrigin	    	= 4,
    oacInstAttrOrient	    	= 5,
    oacInstAttrTransform 	= 6,
    oacInstAttrParams	    	= 7,
    oacInstAttrNumBits	    	= 8,
    oacInstAttrIsBound	    	= 9
};


New Representation

enum oaInstAttrTypeEnum {
    oacLibNameInstAttrType	= 0,
    oacCellNameInstAttrType    	= 1,
    oacViewNameInstAttrType    	= 2,
    oacNameInstAttrType	    	= 3,
    oacOriginInstAttrType	= 4,
    oacOrientInstAttrType	= 5,
    oacTransformInstAttrType  	= 6,
    oacParamsInstAttrType	= 7,
    oacNumBitsInstAttrType      = 8,
    oacIsBoundInstAttrType    	= 9
};

oaInstTermAttrTypeEnum

Old Representation

enum oaInstTermAttrTypeEnum {
    oacInstTermAttrName	    = 0
};

New Representation

enum oaInstTermAttrTypeEnum {
    oacNameInstTermAttrType	    = 0
};


oaMarkerSeverityEnum

Old Representation

enum oaMarkerSeverityEnum {
    oacSeverityAnnotation               = 0,
    oacSeverityInfo   		        = 1,
    oacSeverityAcknowledgedWarning      = 2,
    oacSeverityWarning                  = 3,
    oacSeveritySignedOffError           = 4,
    oacSeverityError                    = 5,
    oacSeveritySignedOffCriticalError   = 6,
    oacSeverityCriticalError            = 7,
    oacSeverityFatalError               = 8
};

New Representation

enum oaMarkerSeverityEnum {
    oacAnnotationMarkerSeverity               = 0,
    oacInfoMarkerSeverity   		      = 1,
    oacAcknowledgedWarningMarkerSeverity      = 2,
    oacWarningMarkerSeverity                  = 3,
    oacSignedOffErrorMarkerSeverity           = 4,
    oacErrorMarkerSeverity                    = 5,
    oacSignedOffCriticalErrorMarkerSeverity   = 6,
    oacCriticalErrorMarkerSeverity            = 7,
    oacFatalErrorMarkerSeverity               = 8
};

oaDetachVisibilityEnum

Old Representation

enum oaDetachVisibilityEnum {
    oacDetachInheritFromSourceModule	= 0,
    oacDetachVisibleToBlockDomain	= 1,
    oacDetachExcludeFromBlockDomain	= 2
};

New Representation

enum oaDetachVisibilityEnum {
    oacInheritFromSourceModuleDetachVisibility	= 0,
    oacVisibleToBlockDomainDetachVisibility	= 1,
    oacExcludeFromBlockDomainDetachVisibility	= 2
};

oaNetAttrTypeEnum

Old Representation

enum oaNetAttrTypeEnum {
    oacNetAttrName		= 0,
    oacNetAttrSigType		= 1,
    oacNetAttrIsGlobal		= 2,
    oacNetAttrIsImplicit	= 3,
    oacNetAttrIsEmpty		= 4,
    oacNetAttrNumBits		= 5
};

New Representation

enum oaNetAttrTypeEnum {
    oacNameNetAttrType		= 0,
    oacSigTypeNetAttrType	= 1,
    oacIsGlobalNetAttrType	= 2,
    oacIsImplicitNetAttrType	= 3,
    oacIsEmptyNetAttrType	= 4,
    oacNumBitsNetAttrType	= 5
};


oaConnStatusEnum

Old Representation

enum oaConnStatusEnum {
    oacConnStatusDefault     	= 0,
    oacConnStatusFirm	    	= 1,
    oacConnStatusLocked	        = 2
};

New Representation

enum oaConnStatusEnum {
    oacNormalConnStatus     	= 0,
    oacFixedConnStatus	    	= 1,
    oacLockedConnStatus	        = 2
};

oaScanChainSetTypeEnum

Old Representation

enum oaScanChainSetTypeEnum {
    oacOrderedSetType		= 0,
    oacUnorderedSetType		= 1
};


New Representation

enum oaScanChainSetTypeEnum {
    oacOrderedScanChainSetType		= 0,
    oacUnorderedScanChainSetType	= 1
};

oaPinConnectMethodEnum

Old Representation

enum oaPinConnectMethodEnum {
    oacPinConnectMethodDefault	        = 0,
    oacPinConnectMethodRing        	= 1,
    oacPinConnectMethodAbut        	= 2,
    oacPinConnectMethodFeedthru	        = 3
};

New Representation

enum oaPinConnectMethodEnum {
    oacDefaultPinConnectMethod	        = 0,
    oacRingPinConnectMethod        	= 1,
    oacAbutPinConnectMethod        	= 2,
    oacFeedthruPinConnectMethod	        = 3
};

oaTermAttrTypeEnum

Old Representation

enum oaTermAttrTypeEnum {
    oacTermAttrName	     	= 0,
    oacTermAttrHasPins		= 1,
    oacTermAttrNumBits		= 2
};

New Representation

enum oaTermAttrTypeEnum {
    oacNameTermAttrType	= 0,
    oacHasPinsTermAttrType	= 1,
    oacNumBitsTermAttrType	= 2
};


oaTextAlignEnum

Old Representation

enum oaTextAlignEnum {
    oacUpperLeft	    = 0,
    oacCenterLeft	    = 1,
    oacLowerLeft	    = 2,
    oacUpperCenter	    = 3,
    oacCenterCenter	    = 4,
    oacLowerCenter	    = 5,
    oacUpperRight	    = 6,
    oacCenterRight	    = 7,
    oacLowerRight	    = 8
};

New Representation

enum oaTextAlignEnum {
    oacUpperLeftTextAlign	    = 0,
    oacCenterLeftTextAlign	    = 1,
    oacLowerLeftTextAlign	    = 2,
    oacUpperCenterTextAlign	    = 3,
    oacCenterCenterTextAlign	    = 4,
    oacLowerCenterTextAlign	    = 5,
    oacUpperRightTextAlign	    = 6,
    oacCenterRightTextAlign	    = 7,
    oacLowerRightTextAlign	    = 8
};

Enumerations for oaDM

oaDMDataTypeEnum


Old Representation


enum oaDMDataTypeEnum {
    oacLibDataType		= UINT_MAX,
    oacDMAppObjectDataType	= UINT_MAX - 1,
    oacDMPropDataType		= 0,
    oacDMGroupDataType		= 1,
    oacDMGroupMemDataType	= 2,
    oacDataCallbackType	        = 3,
    oacAvatarType		= 4,
    oacCellDataType		= 5,
    oacViewDataType		= 6,
    oacCellViewDataType	        = 7,
    oacDMFileDataType		= 8,
    oacDMFilePurposeDataType	= 9
};

New Representation

enum oaDMDataTypeEnum {
    oacLibDataType		= UINT_MAX,
    oacDMAppObjectDataType	= UINT_MAX - 1,
    oacDMPropDataType		= 0,
    oacDMGroupDataType		= 1,
    oacDMGroupMemDataType	= 2,
    oacDMDataCallbackDataType	= 3,
    oacDMAvatarDataType	        = 4,
    oacCellDataType		= 5,
    oacViewDataType		= 6,
    oacCellViewDataType	        = 7,
    oacDMFileDataType		= 8,
    oacDMFilePurposeDataType	= 9
};


Enumerations for oaTech

oaLayerOpEnum


Old Representation

enum oaLayerOpEnum {
    oaLayerAnd		= 0,
    oaLayerOr		= 1,
    oaLayerNot		= 2,
    oaLayerXor		= 3
};

New Representation

enum oaLayerOpEnum {
    oacAndLayerOp		= 0,
    oacOrLayerOp		= 1,
    oacNotLayerOp		= 2,
    oacXorLayerOp		= 3
};


oaPrefRoutingDirEnum

Old Representation

enum oaPrefRoutingDirEnum {
    oacRouteDirNotApplicable	    		= 0,
    oacRouteDirNone               		= 1,
    oacRouteDirHorz		         	= 2,
    oacRouteDirVert		         	= 3,
    oacRouteDirLeftDiag		    	        = 4,
    oacRouteDirRightDiag	         	= 5 
};


New Representation

enum oaPrefRoutingDirEnum {
    oacNotApplicablePrefRoutingDir	    	= 0,
    oacNonePrefRoutingDir                	= 1,
    oacHorzPrefRoutingDir		    	= 2,
    oacVertPrefRoutingDir		    	= 3,
    oacLeftDiagPrefRoutingDir		    	= 4,
    oacRightDiagPrefRoutingDir	                = 5 
};

oaMaterialEnum

Old Representation

enum oaMaterialEnum {
    oacMaterialOther		    = 0,
    oacMaterialNWell		    = 1,
    oacMaterialPWell		    = 2,
    oacMaterialNDiff		    = 3,
    oacMaterialPDiff		    = 4,
    oacMaterialNImplant	            = 5,
    oacMaterialPImplant	            = 6,
    oacMaterialPoly		    = 7,
    oacMaterialCut		    = 8,
    oacMaterialMetal		    = 9,
    oacMaterialContactlessMetal     = 10
};

New Representation

enum oaMaterialEnum {
    oacOtherMaterial		    	= 0,
    oacNWellMaterial		    	= 1,
    oacPWellMaterial		    	= 2,
    oacNDiffMaterial		    	= 3,
    oacPDiffMaterial		   	= 4,
    oacNImplantMaterial		        = 5,
    oacPImplantMaterial		        = 6,
    oacPolyMaterial		       	= 7,
    oacCutMaterial		       	= 8,
    oacMetalMaterial		    	= 9,
    oacContactlessMetalMaterial   	= 10
};

oaPurposeTypeEnum

Old Representation

enum oaPurposeTypeEnum {
    oacPurposeDrawing		    = 0,
    oacPurposeFill		    = 1,
    oacPurposeSlot		    = 2,
    oacPurposeOPCSerif		    = 3,
    oacPurposeOPCAntiSerif	    = 4,
    oacPurposeAnnotation	    = 5,
    oacPurposeGapFill		    = 6
};

New Representation

enum oaPurposeTypeEnum {
    oacDrawingPurposeType		= 0,
    oacFillPurposeType		       	= 1,
    oacSlotPurposeType		       	= 2,
    oacOPCSerifPurposeType		= 3,
    oacOPCAntiSerifPurposeType	        = 4,
    oacAnnotationPurposeType	       	= 5,
    oacGapFillPurposeType		= 6
};


oaRuleParamTypeEnum

Old Representation

enum oaRuleParamTypeEnum {
    oacDistanceRuleParam	= 0,
    oacFrequencyRuleParam	= 1,
    oacLengthRuleParam		= 2,
    oacNumCutsRuleParam	        = 3,
    oacWidthRuleParam		= 4
};

New Representation

enum oaRuleParamTypeEnum {
    oacDistanceRuleParamType	        = 0,
    oacFrequencyRuleParamType	        = 1,
    oacLengthRuleParamType		= 2,
    oacNumCutsRuleParamType		= 3,
    oacWidthRuleParamType		= 4
};

oaClearanceMeasureEnum

Old Representation

enum oaClearanceMeasureEnum {
    oacClearanceMeasureEuclidian      = 0,
    oacClearanceMeasureMaxXY	      = 1
};

New Representation

enum oaClearanceMeasureEnum {
    oacEuclidianClearanceMeasure      = 0,
    oacMaxXYClearanceMeasure	      = 1
};


oaTechDataTypeEnum

Old Representation


enum oaTechDataTypeEnum {
    oacTechTechDataType           = UINT_MAX,
    oacTechAppObjectDataType      = UINT_MAX - 1,
    oacTechPropDataType           = 0,
    oacTechGroupDataType          = 1,
    oacTechGroupMemDataType       = 2,
    oaTechDataCallbackType        = 3,
    oacTechAvatarType             = 4,
    oacTechLayerDataType          = 5,
    oacTechPurposeDataType        = 6,
    oacTechSiteDefDataType        = 7,
    oacTechViaDefDataType         = 8,
    oacTechOpPointDataType        = 9,
    oacTechAnalysisLibDataType    = 10,
    oacTechViaSpecDataType        = 11,
    oacTechRouteSpecDataType      = 12,
    oacTechRuleDataType           = 13,
    oacTechAntennaRatiosDataType  = 14
};
 

New Representation

enum oaTechDataTypeEnum {
    oacTechDataType               = UINT_MAX,
    oacTechAppObjectDataType      = UINT_MAX - 1,
    oacTechPropDataType           = 0,
    oacTechGroupDataType          = 1,
    oacTechGroupMemDataType       = 2,
    oacTechDataCallbackDataType   = 3,
    oacTechAvatarDataType         = 4,
    oacLayerDataType              = 5,
    oacPurposeDataType            = 6,
    oacSiteDefDataType            = 7,
    oacViaDefDataType             = 8,
    oacOpPointDataType            = 9,
    oacAnalysisLibDataType        = 10,
    oacViaSpecDataType            = 11,
    oacRouteSpecDataType          = 12,
    oacRuleDataType               = 13,
    oacAntennaRatiosDataType      = 14
};

Stream Translators Consistently Named

Stream translator names are now more consistent between Windows and UNIX platforms.

Windows
New Names Old Names
strm2oa.exe strmIn.exe
oa2strm.exe strmOut.exe
UNIX
New Names Old Names
strm2oa oaStrmIn
oa2strm oaStrmOut

API Changes

View a summary  of the OpenAccess 2.2 a005 changes with respect to 2.2 a004.

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

Preview 2.2 a004

Release date: 02/04/2004

Release Highlights

Route API Changes

The oaSegStyle class encapsulates width, the begin extensions and style, and end extensions and style for an oaPathSeg.

Binding Clean-Up

The goal of this API change is to promote the common use model and expected binding mode between techDB and designDB objects: Design objects that refer to tech objects should be bound when the design is in memory.

Changes

For example, the following functions are removed: 

static oaCustomVia *oaCustomVia::create(oaBlock             *block,
                                        const oaString      &viaDefName,
                                        const oaTransform   &xform,
                                        const oaParamArray  *params = NULL);
static oaRow *oaRow::create(oaBlock        *block,
                             const oaString &siteName,
                             const oaPoint  &origin,
                             const oaOrient &rowOrient,
                             oaUInt4        numSites,
                             const oaOrient &siteOrient);

You can use the corresponding create-by-pointer functions instead, for example:

Note: You can still explicitly destroy and recreate def objects, but now the consequences are clearer.

For example, the following function is removed:

void oaSiteDef::setName(const oaString &name);

The following function is removed because techDB is independent of designDB. You can still create a customViaDef by providing the lib/cell/view name of a master.

	static oaCustomViaDef *oaCustomViaDef::create(oaTech          *tech,
                                                     const oaString  &name,
                                                     oaDesign        *master,
                                                     oaPhysicalLayer *layer1,
                                                     oaPhysicalLayer *layer2);
The following functions are removed because changing the def bound to a via essentially changed the binding of that via to the techDB object.
	void oaStdVia::setViaDef(oaStdViaDef *viaDefIn);
       Void oaCustomVia::setViaDef(oaCustomViaDef *viaDefIn);

API Changes

View a summary  of the OpenAccess 2.2 a004 changes with respect to 2.2 a003.

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

Preview 2.2 a003

Release date: 01/21/2004

API Changes

View a summary  of the OpenAccess 2.2 a003 changes with respect to 2.2 a002.

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

Preview 2.2 a002

Release date: 01/08/2004

Release Highlights

You can now perform region queries on vias. Two new public classes are introduced.

API Changes

View a summary  of the OpenAccess 2.2 a002 changes with respect to 2.2 a001.

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

Preview 2.2 a001

Release date: 12/17/2003

Release Contents and Description

This release contains the OpenAccess 2.2 database and supporting software. The data model supported by the current API supports a broad range of IC implementation applications and design data.

The OpenAccess 2.2 release consists of:

Pre-Compiled Binaries

The OpenAccess 2.2 release includes OpenAccess pre-compiled binaries for Sun Solaris 2.8, HP-UX 11.0, IBM AIX 5.1, Linux Redhat 7.2 , Linux Redhat AS 2.1, and Windows 2000/XP. Both 32 and 64 bit versions are included. The pre-compiled binaries include the shared libs containing the database implementation, LEF/DEF translators, and Stream translators.

Source Code

The OpenAccess 2.2 release includes the complete C++ source code used to build the OpenAccess database API. It includes the source for the OpenAccess database, translators, and unit tests.

GNUmakefiles - UNIX Platforms

OpenAccess 2.2 includes GNUmakefiles for building all the OpenAccess software. (You must use GNU make version 3.80.)  If you require a different environment, perform customizations.

For more information about using the GNUmakefiles, see Installation and Configuration Notes.

Unit Tests

The Unit tests are self contained programs that exercise the OpenAccess API and compare the behavior to expected results. The GNUmakefiles shipped with OpenAccess are ready to run at your site. No modification should be required.

Each GNUmakefile runs a Unit test. Each test has a set of reference files (under test/testDir/*.ref). If the results of the test are the same as the reference, it passes.

Microsoft Visual Studio Solution File - Windows Platform

OpenAccess provides solution files that you can use to rebuild OpenAccess. You must use Microsoft Visual Studio .NET 2003.

<install_dir>/oaDynamic.sln
<install_dir>/oaStatic.sln

For more information about using the Visual Studio solutions, see Installation and Configuration Notes.

Unit Tests

The Unit tests are self contained programs that exercise the OpenAccess API and compare the behavior to expected results. When you build OpenAccess, an oaTest.exe executable that can run all the unit tests is created.

For more information about oaTest.exe, see Installation and Configuration Notes.

Documentation

The documentation included in the OpenAccess 2.2 release consists of the following:

Important: See Limitations for information about the state of the documentation for the 2.2 Preview release.

The OpenAccess reference documentation includes an HTML page for each C++ API class. This reference documentation is produced using doxygen version 1.3-rc2, which is a GNU general public license software application that is available as a free download at http://www.stack.nl/~dimitri/doxygen/index.html. Documents produced by doxygen are derivative works derived from the input used in their production. Therefore, the OpenAccess API documentation is not subject to the GNU General Public License and is licensed separately by Cadence Design Systems, Inc. and Silicon Integration Initiative.

Note: The OpenAccess documentation was produced with a modified version of doxygen.

The reference pages are automatically generated by reading the public header files. Human-generated descriptions are added to the automatically generated document framework.

The HTML pages are compatible with Netscape 4.79, but are designed for use with Internet Explorer 6 and Mozilla 1.3.1. The OpenAccess documentation uses JavaScript to implement certain functions such as the navigation bar, which appears on all pages. Your browser must support HTML level 4 and JavaScript. The browser's JavaScript feature must be enabled when viewing the OpenAccess documentation.

Examples

The examples in <install_dir>oaDoc/examples are updated to 2.2. The LibStructure, Route, and Via examples, in particular, exhibit changes found in the 2.2 API.  Depending on your installation and environment, you might need to edit the <install_dir>oaDoc/examples/macro.defs file before you can compile the examples on UNIX platforms.

Information Model

The Information Model is a set of schema diagrams showing the relationships among the major database classes and showing the attributes on each class. Each diagram shows a related set of classes. Each class is either linked to the reference documentation, or to the schema diagram that shows its entire set of relationships.

Note: The schema diagrams have not yet been updated for the OpenAccess 2.2 release.

Release Highlights

The following are highlights of the OpenAccess 2.2 release.

New Design Management API

The OpenAccess DM architecture stores information about the library data and metadata in a library database. With this approach, access to the library data is faster and the information model is more flexible. Access to the library data is controlled through a library server application.

Data Model

An OpenAccess library consists of design data files, auxiliary files, and the relationships between them.

A project contains library definitions (not implemented in this Preview release).

A library is a directory that contains the library database and all library data. The library database contains all information about the on-disk library including the cells, views, cellViews, associated data files on disk, and the relationships between them. The database also stores the properties, groups, and extensions on the library data. A library is also a logical container object that contains cells, views, and files. A library can have a link to the technology file for that library (which must be contained in the library).

A cell is a container object that contains cellViews and files.

A view is a container object that contains cellViews and files.

A cellView is a container object that contains files. A cellView can have a link to a master file.

A file contains data. Every file has a file purpose, which is a string-valued attribute that defines the purpose for the file. OpenAccess has defined a set of reserved file purposes, which include “designDB”, “techDB”, “reducedDB”, “detailedDB”, “maskDB”, and “reticleDB”. These purposes are used to validate data within OpenAccess. Users can create their own file purposes within a library.

Files can be created or imported into the library using the oaDMFile API.

DM Flow

For the Preview release, library definitions must be added using the oaLib API. Each library definition contains the library name, the library path, and the server information.

You can add library definitions with the API oaLib::addDef(name, path, server).

DM API

Class Hierarchy for DM API

Library Server

The library server is a program that controls multiple client access to the library database and library data. Note that in this 2.2 Preview release, only single client access to the library via the library server is supported.

The library server executable is started as a daemon process on the server machine for the library. A single library server can serve multiple libraries.

oaLib:: find() will find a server for the library, if one exists, and use that server for access to the library. If there is no server currently serving the library, oaLib:: find() will attempt to start a server and attach the server to the library.  In this case, the server definition information in the library definition will be used to start the server.

A library server can be controlled through the oaLibServer  API. 

The library server executable is included in the standard executable location on Windows and UNIX (see Build Hierarchy Changes) as oaLibServer.ex (Windows) or oaLibServer (UNIX). You can manually start the library server executable. 

Limitations

Reimplementation of Region Query

This project implements a RegionQuery plug-in mechanism, which allows multiple region querying solutions to be used. An interface socket for region querying capability will be defined. A default plug-in will be implemented for this socket. The default plug-in will use the standard X/Y tree implementation.

Region Query Plug-In API

The plug-in mechanism is implemented using two classes. The primary class is oaRegionQueryPlug , which is an abstract class that must be overridden by all plug-in implementers. One plug-in is created, when necessary, for each oaBlock for which region querying is required. oaRegionQueryPlug has several virtual methods that are called to notify the plug-in of changes to the block's data. The plug-in is responsible for keeping its internal data structures current with these changes. The oaRegionQueryPlugMgr class is also abstract; it is used as a “factory” to build plug-ins as required. Again, the plug-in implementer must override this class to add plug-in specific capabilities.

The plug-in mechanism uses the private classes that are part of the implementation of OpenAccess. Using these private classes requires access to the private class definitions as well as advanced knowledge of OpenAccess.

Region Query API Changes

There will be several changes to the oaRegionQuery class API in order to support plug-ins that don't organize shapes by master.

The result of this change is that you can no longer query instances based on their master. In particular, you can no longer use region query methods like startInstHeader() and endInstHeader() . In typical usage, this should not be a problem for application developers because the code in their routines should be handled on an instance-by-instance basis.

From 2.0 and 2.1 usage, we have found that most applications perform multiple queries, one for each type of object. This means the all-in-one API supported by the current region query is not typically used. Because this type of API requires extra overhead, we are eliminating it in order to improve performance and more directly align the API with the way applications use it.

The new 2.2 region query API has multiple region query objects, one for every type of object that can be queried. All region query objects are derived from the oaRegionQuery base class. Each sub-class (such as oaInstQuery or oaShapeQuery ) is specialized for the types of objects it produces.

Features
Issues

Route API Changes

The goal of this project is to:

The new route API will be easier to understand and use. The previous oaRoute API was difficult to use and inefficient (most code written with the oaRoute API copied information several times to get it into and out of RouteElementArrays). In addition, many of the get methods have been updated to be const.

In the new API, the route elements are managed objects (objects with their own database IDs). Applications can manipulate the route elements as individual objects, and region queries can return the route elements more efficiently.

This means that Vias now exist as standalone objects - they can be created outside of oaRoutes. oaRoutes are now a grouping of regular objects on a given net.

The following objects can now belong to a route:

oaVia - This is now a managed object instead of an element in a RouteElementArray.
oaPathSeg - A 2-pt, orthonormal path-like object (it can be orthogonal or diagonal). Each PathSeg contains its extension values.

Routes contain an array of these elements, which are created independently from the route. Routes have all the same attributes and relationships as in previous releases, including begin and end connection objects, oaRouteSpecs, and belonging to a net. However, begin and end extensions are no longer stored on the route. They are stored on individual oaPathSegs.

oaRouteObjArray Utility Class

Routes are populated and queried using a new oaRouteObjArray utility class, which is a simple array that aggregates the objects belonging to the route.

oaRoute API Changes

Most of the oaRoute API is unchanged. Note that there are no longer different create methods for symbolic and geometric routes. If a route has an oaRouteSpec, then it is a symbolic route.

Because edits to routes are now edits to managed objects, routes must tolerate the inconsistencies that show up as intermediate states. Hence routes may be inconsistent with their RouteSpec, and routes may not be well formed in cases where adjacent elements don't meet at the same location or layer. There are methods to convey this status.

The create methods and the methods that now deal with RouteObjArrays instead of RouteElement arrays are the primary changes to oaRoute.

oaVia API Changes

Much of the oaVia API is unchanged. There are still custom and standard vias, and standard vias are still specified with the same oaViaParam objects. The member functions to set and get ViaParams for standard vias and a ParamArray for custom vias are moved into the appropriate derived class.

oaVia's (oaStdVia and oaCustomVia) are now first class objects (whereas in 2.0, they were utility classes embedded in an oaRouteElement). Being first class objects, they are much easier to manage. The derived Via classes now have create and remove methods instead of public constructors and destructors.

Because Vias are now standalone objects, a ViaHeader has a collection of its Vias. You can get the collection of Vias associated with a ViaHeader.

Issues and Limitations

New Embedded Module Hierarchy Functionality

You can use the oaModule::detach function to create a separate design for a module and all its underlying hierarchy, or you can use the oaModule::embed function to embed a design inside an existing module hierarchy. For more information, see the class reference documentation for oaModule.

This can be useful for partitioning (or unpartitioning) a design for a particular implementation.

CellView Object Renamed to Design Object

In OpenAccess 2.2, the oaCellView object will be renamed oaDesign. This makes it clearer that a design is just one of several types of CellViews. All member functions with names such as getCellView() will be replaced with names such as getDesign().

Build Hierarchy Changes

OpenAccess 2.2 includes a new software installation hierarchy, and some of the names of installed files are different.

The OpenAccess 2.2 installation hierarchy better meets the needs of both end users and developers installing OpenAccess as a software development kit. The revised installation hierarchy is as follows:

install_path_color.gif - 4579 Bytes

As part of the changes to the installation hierarchy, support for both single and multi-threaded applications will be delivered in the same shared library (unlike in OpenAccess 2.1, which had separate libraries for each ).

The new <platform> names will better handle the variety of supported operating systems and hardware architectures, particularly for Linux running on different architectures.

Format: <os_name><os_version>[-<hardware_arch>]

Examples:
sunos58
hpux11
aix51
win32
win64
linux72 (IA-32)
linux21 (IA-32 Enterprise version)
linux21-ia64 (Itanium)
linux21-x86 (Opteron 32 bit)
linux21-x86_64 (Opteron 64 bit)

Including <mode> in the directory structure better handles a mixture of shared libraries built for debug and optimized, single-threaded and multi-threaded, and native compiler versus gcc.

Format: <opt | dbg > [Static] [MT] [-64] [-compiler [compiler_version]]

Examples:
opt,
dbg,
optStatic,
dbgStatic,
optMT,
dbgMT,
optMT-64,
dbgMT-64
opt-gcc3.2.3,
dbgMT-64-gcc3.2.3

In addition, the following name changes for key include files and shared libraries are needed to support several new databases in OpenAccess 2.2.

Primary Include File

Shared Library

OA 2.1

OA 2.2

OA 2.1

OA 2.2

oaBase.h

oaBase.h

liboaBase.so

liboaBase.so

oaDD.h

oaDM.h

liboaDD.so

liboaDM.so

oaTC.h

oaTechDB.h

liboaTC.so

liboaTech.so

oaDB.h

oaDesignDB.h

liboaDB.so

liboaDesign.so
 

oaMaskDB.h

  

liboaMask.so
 

oaReticleDB.h

  

liboaReticle.so

A similar set of changes are needed for  the names of a number of classes.

Class Name

Class Name

OA 2.1

OA 2.2

OA 2.1

OA 2.2

oaTCObject

oaTechObject

oaDBObject

oaDesignObject

oaTCDataType

oaTechDataType

oaDBDataType

oaDesignDataType

oaTCException

oaTechException

oaDBException

oaDesignException

oaTCError

oaTechError

oaDBError

oaDesignError

oaTCFatal

oaTechFatal

oaDBFatal

oaDesignFatal

oaTCCallback

oaTechObjectCallback

 oaDBCallback

oaDesignObjectCallback

oaDBUndoCallback

oaDesignUndoCallback

Update Script

A script that automatically updates client source code to reflect changes to the object names in OA 2.2 is available in under <install_dir>/build/bin/UpdateToOA22.  There is a companion file, UpdateToOA22.sed, which contains the rules that UpdateToOA22 uses.  You can run the updater in different modes specified by a command-line option: 

UpdateToOA22 [-t | -T | -q | -s] <file> ... 
-t	Test changes, showing diffs without saving the changes 
-T	Test changes, saving them in file.oa22 for each file 
-q	Show diff of each file and prompt whether to save changes in place 
-s	Make changes silently in place

The –t option is useful to get a quick feel about what will be changed, while the –T option is useful for doing a graphical diff.  The –s option is useful after confirming that the changes are correct with either –t or –T.

The script attempts to update class names and variable names in a consistent way, but the changes it makes may not be appropriate for all client code.  Because “Design” contains fewer letters than “CellView”, the script will affect the format of the source code. After running the script, you should inspect the modified files and fix any issues introduced by the script.

LEF and DEF  Translators

OpenAccess supports LEF and DEF 5.5.

Limitations

Obsolete Layer Header

Blockage is now associated with an LPP instead of a layer.

Not every purpose makes sense for blockage, so the purpose will be derived from the user-defined blockage type as follows:

User-Defined Blockage Type

Derived Purpose
oacRoutingBlockageType oacPurposeDrawing
oacViaBlockageType            oacPurposeDrawing
oacWiringBlockageType        oacPurposeDrawing
oacFillBlockageType          

oacPurposeFill

oacSlotBlockageType          

oacPurposeSlot

oacPinBlockageType            oaPurposeDrawing
oacFeedthruBlockageType       oacPurposeDrawing
oacScreenBlockage             oacPurposeDrawing

oacPlacementBlockageType

Throw an exception if layer is specified (current behavior).

Miscellaneous Changes

Global Limitations and Known Problems and Solutions

API Changes

View a summary  of the 2.2 API changes with respect to version 2.1.

Return to top of page



Copyright © 2003-2004
All rights reserved.