OpenAccess 2.2 Installation and Configuration Notes

This document describes

• Installation Kits
  • Platform-Independent Kits
  • Platform-Specific Kits (or Installers)
  • What to Download
• Installation Hierarchy
• Runtime Requirements
• Compatibility
  • Specifying a DataModelRev for a Flow When Importing Data
• Configuration Information
  • Supported Platforms and Compilers for OpenAccess Pre-Compiled Libraries
  • Environment Variables
  • Optionally Compiling on UNIX Platforms (Solaris, IBM, and Linux)
  • Optionally Compiling on an Unqualified Linux Platform
  • Optionally Compiling on the Windows Platform
  • Developing Applications on Windows
  • Prerequisites for Compiling Translators and Other Non-Core Packages
• Uninstalling OpenAccess

For information about problems and workarounds, see the Known Problems and Solutions.

Installation Kits

Before installing, first close all applications that use OpenAccess libraries. Then make sure that there are no oaLibServer or oaFSLockD processes running (kill these processes with the kill command).

The tarkits containing source code, public includes, and documentation are platform independent.

Platform-Independent Kits

oaSrc_<rel>_all.tar.gz

oaInc_<rel>_all.tar.gz

oaDoc_<rel>_all.tar.gz

The tarkits containing the libraries and binaries are platform specific.

Platform-Specific Kits (or Installers)

oaDev_<rel>_<platform>.tar.gz

oaRun_<rel>_<platform>.tar.gz

What to Download

If you want a runtime version of OpenAccess, simply download the oaRun tarkit for your platform.

If you want a developers version including the documentation and examples, download the oaDev tarkit for your platform, plus the following platform-independent tarkits:

• oaSrc
• oaInc
• oaDoc

Important: Do not move directories or files within the OpenAccess installation hierarchy. This will result in problems with your installation. Also, do not mix kits from different releases.

Installation Hierarchy

The following figures shows the main components of the OpenAccess 2.2 installation hierarchy.

For information about the naming conventions for <platform> and <mode>, refer to OpenAccess Installation Hierarchy in What's New in OpenAccess.

Runtime Requirements

The SPEF and LEF/DEF translators require zlib to run (Windows platform only).

• Install the zlib package from http://www.gzip.org/zlib/.
  
  
• Add the path to the zlib installation's lib directory to your PATH environment variable.
  For example, if you install zlib into C:\zlib1.2.1, use:
  C:\zlib1.2.1\lib;

Compatibility

OpenAccess provides specific levels of compatibility between releases. Two types of compatibility are provided:

• API compatibility - Allowing an old application to run on new OpenAccess releases without changing the code or recompiling
• Data compatibility - Addresses whether or not the databases written by applications built on one version of OpenAccess can be read or modified by applications using a different version of OpenAccess.

For more information, refer to Compatibility for OpenAccess Applications and Data.

Specifying a DataModelRev for a Flow When Importing Data

All applications in a flow must be capable of supporting the highest data model used in that flow. There are several ways you can specify the supported data model when importing data using OpenAccess translators.

• Create a text file containing containing a single numeric value that represents the supported data model. Save the file as OA.DATAMODEL in the data directory of your OpenAccess installation hierarchy.
  
  
• Set the OA_DATAMODEL environment variable to specify the highest data model supported by your flow. For example, set the environment variable as follows to indicate that your flow does not yet support the incremental technology database feature:
  
  OA_DATAMODEL 2
  
  Note: The incremental technology database feature was first available in data model revision 3, as described in the OpenAccess 2.2 Development Feature List.
  
  
• Use the -dataModel option of the strm2oa, lef2oa, or def2oa translator to specify the data model when importing data into OpenAccess.

The OA_DATAMODEL environment variable overrides a value set in the OA.DATAMODEL file. In addition, the individual -dataModel translator options override the value set by either the environment variable or an OA.DATAMODEL file. If you use the OA.DATAMODEL file or the OA_DATAMODEL environment variable to specify the highest data model supported by your flow, the translators default to this value when importing data into OpenAccess.

When reading data into OpenAccess, the translators adjust their output based on the specified data model. For example, if data model 1 is specified (by any of the three mechanisms above), and the design data to be imported contains new constraints from data model 2, those constraints will either be saved as properties instead of as OpenAccess constraints or dropped. For more information about how data is handled in such situations, refer to the mapping documentation for the translators.

Configuration Information

Supported Platforms and Compilers for OpenAccess Pre-Compiled Libraries

If you want to link against the OpenAccess pre-compiled libraries, you must use the compilers in the following table.

Redist kit	Platform	Compiler
sol86	Solaris (x86_64) Operating System 10 with support for STLPort4 C++ standard template libraries	Solaris Compiler: Sun Studio 11 C++ 5.8
sun4v	Solaris Operating System 10 with support for STLPort4 C++ standard template libraries	Solaris Compiler: Sun Studio 12 C++ 5.9*
lnx86	Linux (x86 and x86_64) Operating System: Red Hat Enterprise Linux 4.0 Compatible with: RHEL50, SLES 10, SLES11	Linux Compiler: gcc 4.4.3
wint	Windows Operating System: Windows 2000/XP	Windows Compiler: Visual Studio 2005
ibmrs	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 now compiled without the PIC option on Solaris and Linux.

The required GNU make utility is:

GNU make version 3.80

Earlier versions of the GNU make utility do not work correctly with the GNU makefiles supplied with OpenAccess. Refer to http://www.gnu.org/software/make for information about downloading the GNU make utility.

Important: It is recommended that you rename the make utility as gmake. This will prevent older, incompatible versions of make from being called.

Environment Variables

Windows 2000/XP

Set your path variable to point to the location of your OpenAccess binaries so that you can execute the binaries from any directory:

<install_dir>/bin/win32/opt

UNIX Platforms

The OpenAccess UNIX binaries have wrapper scripts to automatically set appropriate environment variables. On Linux, you must set the LD_LIBRARY_PATH variable to include the directory containing the correct version of libstdc++.so, which is described in Optionally Compiling on UNIX Platforms (Solaris, IBM, and Linux).

You can set your path environment variable to point to the location of the OpenAccess wrappers in the top-level bin directory of your installation:

<install_dir>/bin/

The generally accepted installation location for <install_dir>  is /opt/OpenAccess. You need to install as root on UNIX in order to use the default installation path.

Unsupported Platforms

For UNIX platforms, you can build on an unsupported platform by setting the environment variable OA_UNSUPPORTED_PLAT for your platform. Note that this environment variable will not override a recognized supported platform.

To determine how to set OA_UNSUPPORTED_PLAT, do the following:

1. In the bin directory, type ./sysname.
   This script returns the string that must be overwritten with the OA_UNSUPPORTED_PLAT variable.
   
   
2. Set the environment variable to the correct string.
   
   For example, if the binary directory that exists is linux_suse9_32, but the wrapper scripts are looking for linux_rhel30_gcc411, you should set OA_UNSUPPORTED_PLAT to linux_suse9. (The _32 portion is automatically set and should not be part of the name you use.)

Overriding Environment Variables

The debug versions of the shared libraries perform additional checking that is not available in optimized libraries. For more information, see OpenAccess Overview.

To run all the binaries in debug mode:

setenv OA_MODE dbg

To set the mode to debug for a single binary, use the name of the executable in all capital letters, followed by _MODE. For example:

setenv DEF2OA_MODE dbg

To set the mode to 64-bit for all binaries (SUN, or IBM platforms only):

setenv OA_BIT 64

Note: On Opteron, the default is 32, but will revert to 64 if the 32-bit version is not available.

To set the mode to 64-bit for a specific binary, use the name of the executable in all capital letters, followed by _BIT (SUN, or IBM platforms only). For example:

setenv DEF2OA_BIT 64

Optionally Compiling on UNIX Platforms (Solaris, IBM, and Linux)

Pre-compiled versions of all the OpenAccess libraries are included in your installation. You might want to recompile these libraries in order to port to a new platform or verify a bug fix. You might also want to use a different compiler of your choosing. When you recompile the OpenAccess libraries, the translators, extensions, and the package containing the functions common to the translators are also recompiled.

Important:

• GNU make version 3.80 is required. (It is recommended that you rename the make utility as gmake. This will prevent older, incompatible versions of make from being called.)
• There are prerequisites for building the translators. Refer to Optionally Building Translators for more information.
• For Linux users:
  • The path to the gcc compiler libraries must be in your LD_LIBRARY_PATH.
  • The elfutils-devel package is required.

Default Compiler Environment

The following table shows the default compiler environments for OpenAccess. The compiler environment is controlled with a platform-specific configuration file included in your installation.

If your compiler is in a location other than the default, create a symbolic link from the default path in the table to the location of your compiler.

The compiler versions indicate the minimum version. To determine the compiler version for a system, use the following commands.

Compiling OpenAccess

You compile OpenAccess as follows. (If you want to compile on a Linux platform not listed above, refer to Optionally Compiling on an Unqualified Linux Platform before proceeding.)

1. (Optional) If you want to compile a 64-bit version, set the following environment variable. (Otherwise, the default is a 32-bit compilation.)
   
   setenv SYSNAME_OPTIONS _64

Note: On Opteron, this is automatically set to _64. You can force it to _32.
   
   
2. cd <install_dir>/oa
   
   
3. gmake <command> OPTMODE=<mode> VERBOSE=<state>

<command> can operate on the entire OpenAccess distribution including all subpackages and translators, or just the OpenAccess core packages.
install_all	Entire distribution*
clean_all
uninstall_all
install	Core packages
clean
uninstall
<mode> is one of:
dbg	Debug compile, which is the default
opt	Optimize compile
<state> is one of:
false	Hide compile commands, which is the default
true	Show compile command

*	There are prerequisites for building the translators and other non-core packages. Refer to Prerequisites for Compiling Translators and Other Non-Core Packages for more information.

Recompiling the OpenAccess libraries does not mean that you must also recompile the translators. However, note that the translators and the OpenAccess libraries must be built with the same compilers in order to work together.

*	There are prerequisites for building the translators and other non-core packages. Refer to Prerequisites for Compiling Translators and Other Non-Core Packages for more information.

Compilation Errors

Refer to Prerequisites for Compiling Translators and Other Non-Core Packages if you get compilation errors related to the translators, oaTcl, or other non core packages.

Testing Your Environment

After you compile OpenAccess, you can test your build by running the supplied unit tests.

1. cd <install_dir>/oa/test
2. gmake unitTest OPTMODE=<mode> VERBOSE=<state> > & test.out &

Optionally Compiling on an Unqualified Linux Platform

If you want to compile OpenAccess on a platform not listed in Supported Platforms and Compilers for OpenAccess Pre-Compiled Libraries, complete the following:

1. Do one of the following:
   
   
   • Modify the sysname shell script to return the <platform_name> for your platform. Note that this script is overwritten when you install a new version of OpenAccess.
     
     The sysname shell script is located at <install_dir>/build/bin.
     
     
   • Set the OA_UNSUPPORTED_PLAT environment variable. See Unsupported Platforms for more information. With this approach, the information is not lost when you install a new version of OpenAccess.
     
     
2. Create a file to define the path to your C++ compiler, C compiler, C++ compiler flags, path to linker, applicable linker flags, and so forth.

• Name the file: <platform_name>_<bit>.variables

  Where: <platform_name> is the name you chose in Step 1, and <bit> is either 32 or 64 (to represent either a 32 or 64-bit operating system).
  
  
• Use the example files available in <install_dir>/build/make to determine the content required for your file.

Proceed to Optionally Compiling on UNIX Platforms (Solaris, IBM, and Linux).

Optionally Compiling on the Windows Platform

Pre-compiled versions of all the OpenAccess libraries are included in your installation. You might want to recompile these libraries in order to port to a new platform or verify a bug fix.

Note: Recompiling the OpenAccess libraries does not mean that you must also recompile the translators, such as verilog2oa. However, note that the translators and the OpenAccess libraries must be built with the same compilers in order to work together.

Use Microsoft Visual Studio 2005  to compile your environment on Windows. The OpenAccess solution files for Visual Studio 2005 have a  _vc8 extension in their name.

Sample Solution File Names

• oaDynamic_vc8.sln is for Visual Studio 2005

Rebuilding the OpenAccess Source

OpenAccess provides a solution file that you can use to rebuild OpenAccess. You might do this if you want to test changes to the OpenAccess API on your local machine.

The following solution lets you compile and build dynamically on all source packages, and includes an oaTest.exe that includes all the unit tests (oaBaseTest, oaDesignTest, oaReticleTest, oaTechTest).

<install_dir>/oa/oaDynamic_vc8.sln

To build:

1. Double click the solution file you want, for example:
   
   oaDynamic_vc8.sln (for Visual Studio 2005)
   
   Microsoft Visual Studio opens the solution file.
   
   
2. On the configuration menu, select the mode you want:
   
   optDLL for an optimized build.
   dbgDLL for a debug build.
   
   
   
   
3. Choose Build > Build Solution or Rebuild Solution.
   The code is built on all packages and an oaTest.exe is created.
   

You can also build on the command line. For example, the following command creates an optimized version of OpenAccess and outputs the build information to out.log:

devenv oaDynamic_vc8.sln /build optDLL /out out.log

Testing Your Environment

Run oaTest.exe to test your environment. The testLog.txt log file and the unit test libraries are at <install_dir>/oa/test/testDir. The oaStrm, oaLefDef, and oaVerilog translators can be compiled similarly. However, it is rarely necessary to compile the translators. The executables have already been provided.

Developing Applications on Windows

If you want to develop an application using OpenAccess, you can create your own Visual Studio solution to include the headers and libraries that you want. Provide Visual Studio with the following OpenAccess paths:

To set these paths in Visual Studio:

1. From the Visual Studio menus, choose Tools > Options.
2. In the Options dialog, highlight Projects, then VC++ Directories.
3. Under Show directories for, choose Executable files, Include files, or Library files (depending on which path you want to set).
4. Double click in the field containing the paths, then click the browse button to navigate to the directory you want.

Dependencies

OpenAccess depends on the Winsock2 socket technology, and therefore must include Winsock2.h.

If your code files contain #include <Windows.h> statements, you must do one of the following:

• Place the include statement for the OpenAccess headers before any #include <Windows.h> statement.
  
  
• Place the #include <WinSock2.h> statement before the #include <Windows.h> statement.

Note that most users do not specify #include <Windows.h> statements in their code files because OpenAccess code files already contain include statements for Windows.h.

Prerequisites for Compiling Translators and Other Non-Core Packages

Very few users need to recompile the OpenAccess translators. You need to do this if you use an operating system that is not compatible with one of the pre-built versions, or if you want to modify the distributed translator. Third-party packages are required in order to build the translators.

LEF and DEF

Unless you have the LEF/DEF parser kits and zlib installed, you will get errors on LEF/DEF translator compilation.

Download and compile the 5.70 or later LEF/DEF parser from http://openeda.si2.org/projects/lefdef/. The makefiles for the LEF/DEF translators supplied by OpenAccess expect the LEF/DEF parser to be installed in /opt/lefdefInt/v<version>. To satisfy this requirement, do one of the following:

• Specify a LEFDEF_HOME environment variable to override the default location. You can also specify LEF and DEF paths individually with LEF_HOME and DEF_HOME.
• Copy the files to the correct locations:
  • The LEF/DEF parser header files must be copied into /opt/lefdefInt/v<version>/tools.<platform>/include.
  • The 32bit LEF/DEF parser libraries must be copied into /opt/lefdefInt/v<version>/tools.<platform>/lib.
  • The 64bit LEF/DEF parser libraries must be copied into /opt/lefdefInt/v<version>/tools.<platform>/lib/64bit.

You must also install the zlib package from: http://www.gzip.org/zlib/

The OpenAccess LEF and DEF translators were qualified using zlib version 1.2.3.

On UNIX, the ZLIB_HOME variable defaults to /opt/zlib/v1.2.3 (for 32-bit execution) and /opt/zlib/v1.2.3_64 (for 64-bit execution).

On Windows, you must set the ZLIB_HOME environment variable to point to the zlib installation directory. In addition, set the OA_DEP_LIBS environment variable to point to the directory containing your LEF/DEF parser kits (lefdefInt). The default version of the LEF/DEF parser kits is specified in <install_dir>/build/MSVS/dep.vsprops. Modify this file if you need to override the default version.

Note: The OA_DEP_LIBS environment variable overrides any LEFDEF_HOME environment variables.

See the OpenAccess release notes for information about limitations for LEF and DEF in this release.

OpenAccess to SPEF Translator

If you want to compile your own version of the SPEF translator, you must install the zlib package from: http://www.gzip.org/zlib/

The OpenAccess SPEF translator was qualified using zlib version 1.2.3.

On Windows, you must set the ZLIB_HOME environment variable to point to the zlib installation directory. On UNIX, the ZLIB_HOME variable defaults to /opt/zlib/v1.2.3 (for 32-bit execution) and /opt/zlib/v1.2.3_64 (for 64-bit execution).

OpenAccess to Verilog Translators

If you want to compile your own versions of the Verilog translators, you need the following tools:

• Bison 1.875 source and executables (http://sourceforge.net/project/showfiles.php?group_id=23617&package_id=22822)
  
• Flex++ 2.5.4 source (http://www.gnu.org)
  Note: Flex++ is included with the Flex package.

Use the environment variables BISON_HOME and FLEX_HOME to specify the installation root of the Bison and Flex executables.  (It is expected that the executables will be in the bin directory under the installation root).

Environment Variable	Windows Default	UNIX Default
BISON_HOME	C:\Program Files\GnuWin32	/opt/bison/v1.875
FLEX_HOME	None	/opt/flex/v2.5.4

OpenAccess Tcl bindings

Unless you have Tcl installed, you will get errors for oaLang compilation, which contains the OpenAccess Tcl bindings. For information about compiling the OpenAccess Tcl bindings, refer to Tcl Bindings for OpenAccess APIs.

The Tcl OpenAccess API is available in Tcl version 8.4.6. and later. In order to use the Tcl OpenAccess API in Tcl, you must install Tcl 8.4.6. or later. You can obtain Tcl from:

http://www.tcl.tk

Set the TCL_HOME environment variable to the location of your Tcl installation. The default TCL_HOME path is: /opt/tcltk/v8.4.6.

oa20to22 Translator

1. If you do not already have a OpenAccess 2.0 installation, download and install the 2.0 kits.
   
   
2. Download the following kit for the platform you want:
   
   OACommon
   
   
3. Expand this kit in the directory that contains your OpenAccess 2.0 hierarchy.
   
   
4. Set the environment variable OAHOME_2_0 to the directory that contains the expanded kits and the OpenAccess 2.0 hierarchy.
   
   
5. Add the directory that contains the cdsCommon executables (typically tools.<platformName>/bin) to your executable search path.
   

Uninstalling OpenAccess

UNIX Platforms (Solaris, IBM, and Linux)

Use the rm -r command to remove your installation hierarchy:

% rm -rf <install_dir>

Return to top of page

Copyright © 2003-2006
All rights reserved.