 |
 |
 |
 |
 |
 |
 |
 |
 |
|
|
|
|
|
|
|
|
|
This document describes known problems and solutions for Beta releases of OpenAccess 2.2.
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: Performing an undo operation after a uniquify operation has undefined results.
Solution: Do not use oaDesign::undo after oaOccurrence::uniquify.
Problem: There are outstanding issues with multi-bit instTerms in either of the following scenarios:
IN[0:4],IN[4],IN[4]IN[4] is repeated three times.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
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]. itNet[0:4] and itNet[3:7]. 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:
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.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. module hack({a,a,a});
output a;
endmodule
module top();
hack I1 ({x,y,z});
endmodule 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: 2.0 applications translated with oa20to22 prior to the 2.2.2 release contain empty foundry rules constraint groups, and the route specs are incorrectly included in the default constraint group.
Solution: Translate your application using the 2.2.2 or later version of oa20to22.
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: An oaDMFile attachment, or other DM operation, is not persistent when using the DM Turbo system if the library is opened in "nonShared" mode.
Solution: Perform a close() on the library before exiting the application. Closing the library ensures that all updates are passed from the Turbo client to the server.
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: RegionQuery has poor performance for designs in which there are thousands of overlapping objects.
The performance problem occurs only if there are thousands of objects overlapping each other at the same location.
Solution: Avoid this situation in your design.
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 OpenAccess 2.2 Development Feature List 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: Currently, the function "oa::compress" can cause a segmentation violation when used on pointArrays.
Solution: None currently available.
Problem: Currently, the function "oa::append" can cause a segmentation violation when used on boxArrays.
Solution: None currently available.
Problem: Currently, the member functions of the oaIntRange class are not operable. They report a type mismatch error.
Solution: None currently available.
Problem: If errors are found while parsing the lib.defs file, the oa::LibDefListOpenLibs command prints an error message, but its return code does not reflect the error. On the Windows, platform a segmentation violation occurs.
Solution: None currently available.
Problem: oaTcl may not accept Tcl lists defined using this form:
set box {{0 -6000} {8000 0}}
Solution: Use the Tcl "list" command to define lists for use with oaTcl:
set box [list [list 0 -6000] [list 8000 0]]
Problem: The numerical values of layer purposes differ in C++ and Tcl. This is only noticeable when printing purpose numbers to the terminal. Tcl code continues to behave as expected.
Solution: Avoid using absolute numbers for purpose types. Instead, use predefined enum values, such as $oa::oacDrawingPurposeType.
Problem: The oa::help function has several limitations. It does not show the return type if the return type is a collection. It only reports if the wrong number of arguments are provided, but it does not indicate how many arguments are expected.
Solution: Use the OpenAccess API reference documentation as the ultimate reference for the OpenAccess API.
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
If you debug the problem and run a stack trace, it looks like a gcc issue.
As as example:
=============================================================
Running 'oaAnalysisLib ': Abort (core dumped)
user_1@machine_1:/home/user_1/oa22/bin/linux72/dbg 74 ? gdb ./oaTest
GNU gdb 5.2
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
(gdb) r
Starting program: /home/user_1/oa22/bin/linux72/dbg/oaTest
Running 'oaAnalysisLib ':
Program received signal SIGABRT, Aborted.
0x4069db11 in __kill () at __kill:-1
-1 __kill: No such file or directory.
in __kill
Current language: auto; currently c
(gdb) bt
#0 0x4069db11 in __kill () at __kill:-1
#1 0x4069d8ea in raise (sig=6) at ../sysdeps/posix/raise.c:27
#2 0x4069f092 in abort () at ../sysdeps/generic/abort.c:88
#3 0x406429e7 in __cxxabiv1::__terminate(void (*)()) (handler=0x4069ef34 ) at ../../../../gcc-3.2.3/libstdc++-v3/libsupc++/eh_terminate.cc:47
#4 0x40642a34 in std::terminate() () at ../../../../gcc-3.2.3/libstdc++-v3/libsupc++/eh_terminate.cc:57
#5 0x40642bb6 in __cxa_throw () at ../../../../gcc-3.2.3/libstdc++-v3/libsupc++/eh_throw.cc:77
#6 0x4018924f in oaClientSocket::connect(oaString const&, unsigned short) (this=0x8403800, address=@0x8403838, port=55555) at oaSocket.h:249
#7 0x40187d4f in oaClientConn::initConnection() (this=0x8403800) at oaClient.cpp:200
#8 0x4019502d in oaClient::initConnection() (this=0xbffff1f0) at oaClient.h:188
#9 0x401957b6 in oaLibServer::isActive() (this=0xbffff2a0) at oaLibServer.cpp:144
#10 0x40192a15 in oaClientLibData::create(oaScalarName const&) (name=@0xbffff410) at oaLib.cpp:794
#11 0x40190a6d in oaLib::create(oaScalarName const&) (name=@0xbffff410) at oaLib.cpp:61
#12 0x08338237 in oaUnitTest::openLib(oaScalarName const&) (this=0x83e7f60, libNameIn=@0xbffff410) at oaUnitTest.cpp:360
#13 0x08339f80 in oaUnitTest::openDesign(oaScalarName const&, oaScalarName const&, oaScalarName const&, oaViewType, char) (this=0x83e7f60, libNameIn=@0xbffff410,
cellNameIn=@0xbffff450, viewNameIn=@0xbffff460, viewType=Internal: global symbol `_ZN10oaViewType5namesE' found in oaView.cpp psymtab but not in symtab.
_ZN10oaViewType5namesE may be an inlined function, or may be a template function
(if a template, try specifying an instantiation: _ZN10oaViewType5namesE).
) at oaUnitTest.cpp:983
#14 0x08337cc3 in oaUnitTest::openTestDesign(oaString const&, oaString const&, oaViewType, char, int) (this=0x83e7f60, suffix=@0xbffff560, viewName=@0xbffff570,
viewType={value = 1276308, static names = 0x401a7ee0}, mode=119 'w', createTopBlock=1) at oaUnitTest.cpp:250
#15 0x0814968a in oaAnalysisLibTest::test() (this=0x83e7f60) at tech/oaAnalysisLibTest.cpp:63
#16 0x0833aff6 in oaUnitTest::run() (this=0x83e7f60) at oaUnitTest.cpp:1364
#17 0x083385f4 in oaUnitTest::runAll() () at oaUnitTest.cpp:516
#18 0x08311999 in main (argc=1, argv=0xbffff7c4) at main.cpp:148
#19 0x4068b657 in __libc_start_main (main=0x8311248 , argc=1, ubp_av=0xbffff7c4, init=0x80db734 <_init>, fini=0x833ca00 <_fini>,
rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xbffff7bc) at ../sysdeps/generic/libc-start.c:129
Solution: This problem is caused by incompatible binutils with gcc 3.2.3. See the Prerequisite for Compiling on Some Linux Platforms.
Problem: On the Linux operating system there can be a segmentation violation during oa::RectCreate if the first argument is not a Tcl variable with a reference to an oaBlock.
Solution: When calling oa::RectCreate on Linux, only use a valid Tcl variable with a reference to a valid oaBlock.
Problem: You get a compiler warning when compiling OpenAccess:
Warning 652: "oaAppDefPvt.h", line 442 # Virtual function "unsigned int OpenAccess_4::oaDataTbl::getDataType() const" is hidden by "unsigned int OpenAccess_4::oaAppDefTbl::getDataType(unsigned int) const"; did you forget to override it? Warning 652: "oaDMDataTbl.h", line 132 # Virtual function "void OpenAccess_4::oaDataTbl::preDestroy(unsigned int,int)" is hidden by "void OpenAccess_4::oaDMContainerDataTbl::preDestroy(unsigned int,int,int)"; did you forget to override it? Warning 652: "oaDMDataTbl.h", line 132 # Virtual function "void OpenAccess_4::oaDataTbl::preDestroy(unsigned int,OpenAccess_4::oaDomain,int)" is hidden by "void OpenAccess_4::oaDMContainerDataTbl::preDestroy(unsigned int,int,int)"; did you forget to override it? Warning 652: "oaDMObjectPvt.h", line 46 # Virtual function "void OpenAccess_4::oaObjectV::get(const OpenAccess_4::oaObject *,unsigned int &,OpenAccess_4::oaDataTbl *&)" is hidden by "void OpenAccess_4::oaDMObjectV::get(const OpenAccess_4::oaDMObject *,unsigned int &,OpenAccess_4::oaDMDataTbl *&,OpenAccess_4::oaLibAccess)"; did you forget to override it? Warning 652: "ClassDef.h", line 62 # Virtual function "void cadence::lang::Node::appendChild(cadence::lang::Node *)" is hidden by "void cadence::lang::ClassDefBase::appendChild(std::list > *)"; did you forget to override it? Warning 652: "FunctionCollector.h", line 44 # Virtual function "void cadence::lang::SimpleVisitor::visit(cadence::lang::Node *)" is hidden by "void cadence::lang::FunctionCollector::visit(cadence::lang::TmplClassDef *)"; did you forget to override it? Warning 652: "TCLEmitter.h", line 92 # Virtual function "void cadence::lang::SimpleVisitor::visit(cadence::lang::Node *)" is hidden by "void cadence::lang::TCLConstantVisitor::visit(cadence::lang::ConstDef *)"; did you forget to override it?
Solution: These compiler warnings occur if you have a 'using declaration' in a class definition. You can safely ignore these warnings.
Problem: Error when running applications on OpenAccess
You get an error such as the following when running your application on OpenAccess:
./oadata/lib.defs load warning: Could not access DMSystem plug-in for oaDMTurbo,
library oa: Plug-in Registration File Not Found
Solution: Use the +s option when linking your application.
Problem: Tcl is not working on the HP-UX platforms.
Solution: See Additional Tcl Build Instructions and refer to the HP-UX platform.
insert() functions in HashSet and HashMap fail on the Solaris platform.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
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.
Solution: Make sure that the Cadence cdsCommon DLLs are in your path. (The cdsCommon DLLs are typically included in <install_dir> /tools/bin.)
Copyright © 2003-2006 Cadence Design Systems, Inc.
All rights reserved.