It’s time to upgrade your OpenAccess application to Data Model 4 (DM4). The upgrade from DM3 is smooth enough–you just need to keep your eye on a few things.
Whenever you upgrade to a new OpenAccess version, always read the release notes in What’s New.
Use the Same Version as Cadence Virtuoso
When I want to know which version of OpenAccess to use, I look to Cadence Virtuoso. Virtuoso 6.1.3 is on DM4, so I am too. OpenAccess 22.04_p028 is a good DM4 version.
DM3 OpenAccess Databases Saved as DM4
When you open a design that was saved using DM3, OpenAccess DM4 translates it to DM4. If you save it, it will be saved as DM4, and OpenAccess DM3 will no longer be able to read it. Skip the save, and your persistent database on disk remains DM3.
OpenAccess DM4 also reads DM3 tech objects, but as always, the tech object is not saved when you save a design. You must save it directly in order for the upgraded DM4 version to appear on disk.
oacDataModelRevNumber tells you the data model of the OpenAccess version you are using.
More oaAssert Assertions
The number of assertions doubled from OpenAccess 2.2.5 to 2.2.6, and doubled again from 2.2.6 to DM4 22.04_p028. More assertions is a great thing, but it means that the run time behavior of OpenAccess debug libraries and optimized libraries continues to diverge. Just keep this in mind.
When an oaAssert fires, it throws an exception of type oacInternalError. For example,
Internal OpenAccess Error: Expression [netHashMap.get(netTbl[i]) == i] returned false in file oaGlobalMem.cpp at line 463
If you get an assertion failure from OpenAccess debug code, try running the optimized code to see what happens with assertions elided. If you find an inappropriate assertion, make sure to report it.
Shell Script sysname is Updated
As you know, executables and libraries for different platforms are in directories with names like linux_rhel30_64, or linux_rhel30_gcc411_64 for the GCC 4.1.1 version. It is good form to use the OpenAccess shell script bin/sysname in your makefile to figure out the proper directory name for your platform. However, until recently, sysname relied on you to set the shell variable OA_COMPILER to tell it whether to add the _gcc411 part of the name. Or maybe you just appended the _gcc411yourself.
Now, sysname correctly outputs the _gcc411 without any assistance from you. If you added some workaround in your makefile, you will need to remove it, lest you try linking to libraries in lib/linux_rhel30_gcc411_gcc411_64.
Don’t Dial D for Debug
Up until DM4, the OpenAccess shared libraries compiled for debug had a D appended to their file name. For example, the optimized shared library file name was named something like liboaBase.so, and the debug library was named liboaBaseD.so.
The D has mercifully been dropped in DM4 so that the shared library file names for optimized and debug libraries are the same–the path name alone determines the type of library. To continue the above example, in DM4 the optimized and debug oaBase shared library files are both named liboaBase.so.
The DM4 release contains symbolic links for backward compatability of shared library files. For example, in lib/linux_rhel30_gcc411_64/dbg/, liboaDMTurboD.so is a link to liboaDMTurbo.so. However, there is no link liboaUtilD.a. Further, the DM4 plug-in interface only loads the non-D library. If you link your application so it can load only the D libraries, it will not be able to load any plug-ins. You won’t get anywhere without a DM plug-in. You may never see these problems, but the easiest way to avoid trouble is to simply do it the new way: stop appending a D to the shared library file name when linking to DM4.
{ 0 comments… add one now }