OpenAccess 22.41.004 Release

Contents

• Version 22.41.004 Release

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

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

Platform	Compiler
Solaris (x86_64) Operating System 10 with support for STLPort4 C++ standard template libraries	Solaris Compiler: Sun Studio 11 C++ 5.8
Solaris Operating System 10 with support for STLPort4 C++ standard template libraries	Solaris Compiler: Sun Studio 12 C++ 5.9*
Linux (x86 and x86_64) Operating System: Redhat Enterprise 4.0 Compatible with: RHEL50, SLES 10, SLES11	Linux Compiler: gcc 4.4.3
Windows Operating System: Windows 2000/XP	Windows Compiler: Visual Studio 2005
IBM Operating System: AIX 5.3	IBM Compiler: XL C++ 7.0

Notes

* For sun4v systems for Solaris 10, the following variable must be set: setenv OA_COMPILER stl4

32 bit OA libraries are compiled without the PIC option on Solaris and Linux.

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

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

The oacAPIMinorRevNumber  is 201.

About the 22.41 Stream

The 22.41 stream is a separate stream from 22.04. Although both streams support data model 4, 22.41 is built and tested on a different set of build configurations. These streams are data compatible with each other. Databases written by 22.41 kits can be read by 22.04 kits, and databases written by 22.04 kits can be read by 22.41 kits. However, applications built with 22.41 kits should be run with 22.41 kits and applications built with 22.04 kits should be run with 22.04 kits. It is possible to run an application compiled with 22.04 kits against newer 22.41 kits, however this is not recommended.

LEF/DEF parser version

To build the LEF/DEF translators, the lefdef5.7_32_p002 (or later) toolkit is required.

Thread Safety

OpenAccess now supports thread safety on a beta basis. Thread safety is supported for two basic use models: multiple reader threads operating on one or more databases and multiple writer threads operating on a single thread per database basis. The OpenAccess API and implementation only supports thread safety in the form of resource locking and data preconditioning. OpenAccess will not create threads or use them internally.

Applications can turn on thread safety and locking within the session if they have met certain prerequisites and by calling oaSession::setThreadUseModel() with one of the following thread use model enums.

oaThreadUseModel	Enum Prerequisites?	Locking?	Description
oacSingleThreadUseModel	None	No	The application intends to interact with OpenAccess using a single thread. This is the default value.
oacMultipleReadersThreadUseModel	Yes	Yes	The application intends to use multiple read-only threads to access one or more OpenAccess databases concurrently.
oacMultipleWritersThreadUseModel	Yes	Yes	The application intends to use multiple read-write threads to access a single OpenAccess database per thread.

Applications can switch from multi-threaded to single threaded use models (and back) in the same session. However, OpenAccess will not revert any data preconditioning for supporting a multi-threaded use model when switching back to single threaded.

At this point in time, the oacMultipleWritersThreadUseModel does not support traversing data. This will be addressed in an upcoming incremental release. Until then, thread safety should be considered beta and is not intended for production use.

Handling Recursion

This capability enhances OpenAccess to handle recursive designs. In addition, OpenAccess now disallows the introduction of recursion through any of its APIs. Additionally, the applications can also query regarding the existence of recursion in a design hierarchy. The data is loaded in such a way that allows the user or application to fix the data. Recursion here refers to a design containing an instance of itself.

Note: Recursion handling is limited to self-instantiation scenarios. Complex recursion types (like A->B->A) are not currently supported.

The following sections provide a detailed description on enhancements included in this release:

Header Binding

When an attempt is made to bind a header to its master in memory, OpenAccess checks if the master already references the header's design (or module). If it does, the header is left unbound to ensure non occurrence of a recursive loop in the hierarchy. Subsequently, the header is added to the unbound header list and it will remain unbound until adjustments are made to the data to remove the recursive loop.When this situation is detected, OpenAccess issues an on-bind recursion observer notification.

The detection notification will include data that will provide an observer enough information to report a meaningful message to the user.

Recursion Checking for Existing APIs

The following OpenAccess public APIs have been identified for recursion checking to prevent the user from introducing recursion:

• oaInst::setMaster(), oaInstHeader::setMaster(), and oaModDesignInst::setMaster(): If the master is specified, a check now detects whether the master already references the design that owns the instance. If it does, an oaDesignError noting the attempt to create a self-reference is thrown.
• For oaInst::setMaster() and oaModDesignInst::setMaster() versions that accept lib/cell/view names of the new master, if the master is open in memory, the reference check will be done else a minimal self-reference check will be done.
• oaDesign::saveAs() now checks if the new location exists and is already referenced somewhere in the design hierarchy.
• Instance creation APIs - If the specified master is same as the design that the block or module where the instance is being created in, throw an oaDesignError noting the attempt to create a self-reference.

Recursion Checking APIs

The following new functions have been added in this release:

• oaDesign::hasRecursion(): This function returns a Boolean value to indicate whether the design hierarchy contains any recursive loops.
• oaDesign::hasReference(): This function returns a Boolean to indicate whether the design hierarchy (starting at this design) already references the specified design master.

New Recursion Observer

A new observer has been defined to provide notification to applications if recursion is detected. The detection notifications can be of two types. The first type of notification is issued during the explicit oaDesign::hasRecursion check. When recursion is detected, the design where a reference to it already exists in its hierarchy and hierarchy stack is part of the notification. The second type of notification is issued when an instHeader or viaHeader is being bound and one of the design's in the hierarchy portion which instantiates the instHeader's or viaHeaders's owning design already references the design. The list of new functions is as follows:

oaRecursionObserver(oaUInt4 priorityIn, oaBoolean enabledIn = true);
virtual ~oaRecursionObserver();
virtual void onDetect(const oaDesign *design, const oaDesignArray &bottomUpList);
virtual void onBind(const oaRefHeader *header, const oaDesign *master, const oaDesignArray &bottomUpList);
static  void notifyDetectObservers(const oaDesign *design, const oaDesignArray &bottomUpList);
static  void notifyBindObservers(const oaRefHeader *header, const oaDesign *master, const oaDesignArray &bottomUpList);

oaChangeSetObserver Observer Class

A new observer class oaChangeSetObserver is defined for oaChangeSet to provide notifications(as explained below). Applications can choose to derive their own observer from this class and implement the observer methods.

class oaChangeSetObserver 
       {
	public: void onPostCreate(oaChangeSetBase *cs); 
	void onPreDestroy(oaChangeSetBase *cs); 
	void onEmpty(oaChangeSetBase *cs); 
	void onFirstChange(oaChangeSetBase *cs); 
	void onFullExport(oaChangeSetBase *cs); 
	void onIncrementalExport(oaChangeSetBase *cs); 
	};

The detailed description of methods defined by oaChangeSetObserver class is as follows:

• oaChangeSetObserver::onFirstChange(oaChangeSetBase *cs)
  This notification indicates that there are change records in the change set that need to be exported. It is issued for the first change record that gets added in an empty oaChangeSet. It is also issued when the first change record gets added after an incremental export of the change set.
  
• oaChangeSetObserver::onEmpty(oaChangeSetBase *cs)
  This notification indicates that the change set is now empty. This notification occurs as a result of an undo operation that rolls back the changes recorded in a change set. The change set starts without change records and the "empty" state is implied. For example, an explicit onEmpty notification is not sent to the application when the change set gets created.
  
• oaChangeSetObserver::onPostCreate(oaChangeSetBase *cs)
  This notification is sent on creation of the change set.
  
• oaChangeSetObserver::onPreDestroy(oaChangeSetBase *cs)
  This notification is sent on explicit or implicit deletion of the change set. Explicit deletion happens through a call to discardChangeSet on oaChangeMgr. Implicit deletion of the change set occurs when an undo operation goes beyond the beginning of the change set.
  
• oaChangeSetObserver::onFullExport(oaChangeSetBase *cs)
  This notification is sent when a full export is performed on a change set.
  
• oaChangeSetObserver::onIncrementalExport(oaChangeSetBase *cs)
  This notification is sent when an incremental export is performed on a change set.

Restricting APIs in Block Overrides flow

Block Overrides are only allowed on nets with the following sigTypes: "power", "ground", "tieoff", "tieHi", or "tieLo"or on nets that are equivalent to a net with one of these sigTypes. Additional checking has been added to several APIs that restrict the editing of connectivity in the block domain that will break the sigType invariant for Block Overrides. The detailed description of these APIs and related exceptions is as follows:

API Name	Exception	Description
oaInstTerm::addToNet	oacInvalidSigTypeForBlockOverrideNet	This exception is thrown if the instTerm overrides the connectivity of another instTerm and the specified net does not have an appropriate sigType (either directly or through any of its equivalent nets).
oaNet::destroy	oacCannotDestroyNetOnHiddenTerm  or oacCannotDestroyNetOnHiddenInstTerm	These exceptions are thrown if any terms or instTerms were hidden on the net.
oaNet::isEmpty	-	This function returns false if there are no terms or instTerms on the net or if the only terms and instTerms on the net were hidden.
oaNet::setSigType	oacInvalidSigTypeForBlockOverrideNet	This exception is thrown if the net is associated with an overriding instTerm or term and it does not have an equivalent net that has one of the required sigTypes.
oaNet::merge and oaNet::transfer	oacCannotEditNetOnHiddenTerm  or oacCannotEditNetOnHiddenInstTerm	This exception is thrown if any terms or instTerms were hidden on the specified source net.
oaBitNet::breakEquivalence	oacInvalidSigTypeForBlockOverrideNet	This exception prevents an application from inadvertently using breakEquivalence to remove the "power" or "ground" characteristic sigType from a net with hidden or overriding terms or instTerms that inherit that characteristic sigType from an equivalent net. OpenAccess throws this exception in one of the following conditions: The net has one or more overriding terms or instTerms and it does not have one of the following sigType:  "power", "ground", "tieoff", "tieHi", or "tieLo". One of the nets in the equivalent set of nets has an overriding term or instTerm and it does not have one of the following sigType: "power", "ground", "tieoff", "tieHi", or "tieLo. The sigType of the net is "power"/"ground"/"tieoff"/"tieHi" or "tieLo" but no other net in the equivalent net set has one of these sigTypes.
oaTerm::moveToNet	oacInvalidSigTypeForBlockOverrideNet	This exception is thrown if the term is an overriding term and the destination net does not have a "power", "ground", "tieoff", "tieHi", or "tieLo" sigType and it is not equivalent to a net with one of these sigTypes.

oaOccTraverser Changes

A new public class oaOccProducer has been defined. This class separates the traversal of the hierarchy from the production of the contents of a specific occurrence. 

The oaOccTraverser class has also been changed. It now derives from the oaOccProducer class. This helps maintain compile compatibility by preserving the process functions in the public interface of the oaOccTraverser class. Applications should still derive from oaOccTraverser to define the behavior of objects as they are processed or to traverse through the hierarchy.

Both the APIs and the behavior of the oaOccTraverser class have been changed to make the class usable to a wider range of applications. The significant behavior changes are:

• The produce() function can be overridden to customize the production of the objects.
• The produceInsts() function no longer descends through the hierarchy. It has been changed to simply produce the instances.
• The produceInsts() function now calls startInstHeader(), endInstHeader() and startModuleInstHeader(), endModuleInstHeader() functions to allow instance filtering based on headers.
• The produceInstHeaders() function no longer calls startInstHeader() or endInstHeader(). Instead, it now calls processInstHeader().
• The startOccurrence() function controls the production of the contents of the given occurrence. If the function returns false, the contents are not produced. This also controls the descent along with the startInst() function.
• Even if the startOccurrence() function returns false, the corresponding endOccurrence() function will always be called. The same applies to the startInst() and endInst() functions.
• If the startInst() function returns false, the traverser will not descend through that instance, but the instance may still be produced because the traversal is separated from the production. Note that this is similar to the behavior when startOccurrence() returns false, but if startInst() returns false the occurrence hierarchy will not be expanded to the master occurrence.
• If the startInstHeader() function returns false, all instances associated with that header will not be produced. The same applies for startModuleInstHeader().

The OpenAccess Hierarchy Domains section in the Programmer's Guide contains the definitions and examples of pre- and post- order traversals. See the Programmer's Guide for more information on how to use oaOccTraverser.

oaStrm API Changes (for Derived Translators)

View a summary of the oaStrm changes for derived translators.

CMS API Changes (Change Management)

View a summary of the CMS changes.

oaLefDef API Changes (for Derived Translators)

View a summary of the oaLefDef changes for derived translators.

oaSpef API Changes (for Derived Translators)

View a summary of the oaSpef changes for derived translators.

View a summary of the API changes for this release.

Note: The Change Management System is no longer designated as Beta, and is considered to be of production quality. However, the Importer plug-in interface referenced in the documentation is not yet implemented.

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

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

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

Return to top of page

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