OpenAccess 2.2 Known Problems and Solutions (KP&S)

This document describes OpenAccess KP&S.

All Platforms (UNIX and Windows)
UNIX Platforms (All UNIX)
Solaris Platform
Windows Platforms

All Platforms (UNIX and Windows)

Problem: Obtaining a string from a mapped name returns incorrect results.

The namespace classes use library functions that depend on the currently set locale. Certain locales cause the namespaces to return incorrect results when obtaining a string from an oaName.

Solution: OA applications written in C++ should always use the C locale, which is the default. When using the TCL bindings, unset the LANG environment variable before starting the TCL interpreter.

Problem: A crash occurs when closing a superMaster design.

The following scenario results in a crash. An application creates an in-memory Pcell evaluator, then calls oaPcellLink::create() to notify OpenAccess of this evaluator. The application creates (or opens) a superMaster design that uses this evaluator. Next the application calls oaPcellLink::destroy() to destroy the link to the evaluator. When the application closes the superMaster design, OpenAccess crashes.

Solution: Applications must be responsible for keeping the evaluator link active while in use. This means closing all superMasters that use the evaluator link before destroying the link.

Problem: In certain situations, applications might experience performance or capacity degradation when opening large oaDesigns.

Solution: Set the libReadOnly attribute on read-only reference libraries to yes to indicate that no one has write access to that library. Accordingly, OpenAccess can always perform partial reading of the oaDesigns, which improves performance.

Problem: When opening a library with an attached technology database, the software hangs.

Solution: This situation occurs when technology database attachments form a loop. Such a situation might arise if libraries were edited out of context. Use oaTech::getAttachment to examine the attachments and break the loop such that the final target library contains a technology database. Also, in order to prevent a loop from occurring, use oaTech::attach to create technology database attachments. The oaTech::attach function throws an exception when it detects a loop. (Using the deprecated techLibName string property to create attachments does not prevent the attachment loop.)

Problem: There are outstanding issues with multi-bit instTerms in either of the following scenarios:

The instTerm has repeated members because its corresponding terminal or terminal name has repeated members. An example of this is an instTerm that connects to a terminal named IN[0:4],IN[4],IN[4]

where bit IN[4] is repeated three times.
Two multi-bit instTerms share overlapping bits because the corresponding terminals or terminal names have overlapping bits. An example of this is two instTerms that connect to terminals named DATA[0:4] and DATA[3:7], where bits DATA[3] and DATA[4] are shared between the two bus terminals.

The connection is allowed if

The corresponding bits in the nets match.
- In the first scenario above, the instTerm can be created if the net matches the repeated pattern in the corresponding terminal. For example, an instTerm to terminal IN[0:4],IN[4],IN[4] can be created if the net has a name of the form itNet[0:4],itNet[4],itNet[4].
- In the second scenario, the instTerm can be created if the nets used to create the instTerms also overlap in a similar pattern. For example, instTerms to each of the terminals can be created if the nets have names of the form itNet[0:4] and itNet[3:7].
The corresponding bits in the nets do not match, but the mismatching bit nets are marked as being equivalent.
- In the first scenario, a net named A[0:6] is legal for creating an instTerm to terminal IN[0:4],IN[4],IN[4] if the bit nets A[4], A[5], and A[6] are equivalent to each other.

The issues with supporting this are as follows:

The instTerm create functions throw exceptions if the bit nets do not match, regardless of whether or not the bit nets are equivalent.
The instTerm addToNet function currently does not perform any validation of the contents of the net. If you add a multi-bit instTerm to the multi-bit net, OpenAccess does not throw an exception or attempt to resolve the relationship between the mismatched bit nets. The result is that some of the bit nets that appear to be connected are not.

For example:

If you add an instTerm for terminal IN[0:4],IN[4],IN[4] to a net named A[0:6], OpenAccess processes the first bit in the instTerm for terminal bit IN[4] and associates it with bit net A[4]. OpenAccess processes the next bit in the instTerm and identifies that the instTerm bit already has a net (because it represents a connection to the same bit terminal in the master) and no action is taken. This leaves the bit nets A[5] and A[6] unconnected, and the application must address what to do with these bits. Some applications choose to explicitly make A[4], A[5], and A[6] equivalent.
Assume there are instTerms for two overlapping terminals DATA[0:4] and DATA[3:7], initially with NULL nets. When adding the instTerm for DATA[0:4] to net A[0:4], and adding the instTerm for DATA[3:7] to net B[0:4], there is a problem resolving the implicit bit instTerms that are common to both connections that match the terminal bits DATA[3] and DATA[4]. This situation can arise in a Verilog description, and the verilog2oa translator currently does not establish equivalence for the nets associated with these types of connections to terminals.

Consider this example:

module hack({a,a,a}); output a; endmodule module top(); hack I1 ({x,y,z}); endmodule

In this example, the nets y and z will not be connected to anything. The application that created this connectivity might expect the nets y and z to be made equivalent to net x, and it might expect that a signal driven onto x will also be driven onto y and z. However, in our connectivity model, neither of these are true.

Solution: The application must ensure that the mismatching bit nets are equivalent in order for consistent evaluation of the connectivity. (This issue will be fixed in a future release.)

Problem: When using a technology database created by lef2oa prior to 2.2.1, the DBUPerUU for any viewType is set to 0, or the user units for any viewType is incorrectly set to oacMicron.

Solution: Due to a bug fix, technology databases that used the default values for User Units and DBUPerUU in 2.2.0 will now contain incorrect values. You need to recreate your technology database.

Problem: The pcell generator definition manager (IPcellCPPDefMgr) form oaPcellCPP cannot modify IPcellGen definitions when any oaPcellCPP supermaster is opened in the library.

Solution: Complete the modifications to IPcellGen definitions before any oaPcellCPP supermaster is opened.

Problem: OpenAccess cannot load your libraries.

You get an error message such as " ERROR: lib.defs: Error at line 1 : Syntax error in libDefFile."

Solution: Check the syntax of your lib.defs file. Note that cds.lib files supported in previous versions of OpenAccess that include double dash (--) comment characters are no longer allowed. Remove the comment characters or replace the double dashes with the pound (#) comment character.

In general, renaming cds.lib files as lib.defs files is not supported: SOFTINCLUDE and UNDEFINE statements are not supported, and the $compute() syntax is not supported in library paths.

For more information, see Library Definition Files.

Problem: There are length limits on the names used for files stored in OpenAccess FileSys libraries:

Cell names and view names cannot be longer than the maximum length of a file name allowed by the operating system. For example, that max is 255 on UNIX.

Solution: This limitation existed in the 2.0 release, and there are no plans to change this.

Problem: The default or foundry rules constraintGroup contains a member that has an unbound constraintGroupHeader even though all the technology databases that are referenced are open in memory.

This situation occurs if the originally referenced technology database is replaced by one with a different data model revision number. Specifically, this occurs if a referenced tech database with a data model revision number of 2 or earlier is replaced by a tech database with a data model revision number of 3 or later (or vice-versa).

Refer to the Features By Data Model for information about data model revision numbers.

Solution: Use the oaTech::setRefs function to recreate the relationships for all technology databases that refer to the replaced technology database.

Problem: oaDMData that uses new features (as outlined in Features By Data Model) might lose data when opened in an OpenAccess release prior to 2.2 P047.

Solution: Do not use new features in the DMData database if you think your data might be used with a pre-2.2 P047 release.

UNIX Platforms (All UNIX)

Problem: Rational Tools (Purify, PureCov, Quantify) cannot find "load on demand" libraries

Solution: To use the Rational tools with OpenAccess, you need to create links in the directories inside the Purify/PureCov/Quantify cache directories (that correspond to the top-level installation directory) to the bin and data directories of the installation.

For example:

/user/oa/lib
/user/oa/data
/user/Cache/user/oa

Create these links:

/user/Cache/user/oa/data@ -> /user/oa/data
/user/Cache/user/oa/bin@ -> /user/oa/bin

Solaris Platform

Problem: Calls to insert() functions in HashSet and HashMap fail on the Solaris platform. If you have multiple calls to insert() in the same function or in a function that calls itself recursively, calls after the first one fail.

Solution: This occurs because the Solaris C++ compiler does not destroy function return values when it should. To resolve this problem, set the following compiler flag:

-features=tmplife

Windows Platform

Problem: When statically linking an OpenAccess based executable, the linker reports the unresolved symbol _GetProcessMemoryInfo@12.

Solution: Add psapi.lib to the link line of the executable.