OpenAccess 2.2 Installation and Configuration Notes

This document describes

• Installation Components
  • Platform-Independent Kits
  • Platform-Specific Kits (or Installers)
  • What to Download
• Runtime Requirements
  • Windows Platform
• Configuration Information
  • Supported Platforms and Compilers for OpenAccess Pre-Compiled Libraries
  • Environment Variables
  • Optionally Compiling on UNIX Platforms (Solaris, HP, IBM, and Linux)
  • Optionally Compiling on an Unqualified Linux Platform
  • Optionally Compiling on the Windows Platform
  • Developing Applications on Windows
  • Optionally Compiling Translators
• Uninstalling OpenAccess
  • UNIX Platforms (Solaris, HP, IBM, and Linux)
  • Windows Platform

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

Installation Components

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_2.2<rel>_all.tar.gz

oaInc_2.2<rel>_all.tar.gz

oaDoc_2.2<rel>_all.tar.gz

oaMwy_2.2<rel>_all.tar.gz

The tarkits containing the libraries and binaries are platform specific. (Note that on Windows, the download file is an InstallShield installer, not a tarkit.)

Platform-Specific Kits (or Installers)

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
• (Optional) oaMwy

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.

Runtime Requirements

Windows Platform

Platform Requirement for SPEF Translators

The SPEF translators require zlib to run.

• 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 the following path entry.

C:\zlib1.2.1\lib;

Note: Modify the path through the Windows GUI.

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.

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

If you accept the default OpenAccess installation path, <install_dir>  is C:\Program Files\OpenAccess.

UNIX Platforms

The OpenAccess UNIX binaries have wrapper scripts to automatically set appropriate environment variables. However, there is one environment variable that you must set manually -- set your path variable to point to the location of the OpenAccess wrappers in the top-level bin directory of your installation:

• <install_dir>/bin/

Important: You need to install as root on UNIX in order to use the default installation path.

Default Environment Variables Set by the Wrapper Scripts

The following table shows the default environment variables that are set automatically by wrapper scripts when your run any OpenAccess binaries. By default, all binaries run in optimized mode with the bit specification listed in the Platform column. For information about overriding the environment variables, see Overriding Environment Variables.

Platform	Environment Variable	Default Value set by Wrapper
SunOS 5.8, 32-bit	LD_LIBRARY_PATH	<install_dir>/lib/sunos_58_32/opt
	PATH	<install_dir>/bin/sunos_58_32/opt
HP-UX B. 11.00, 32-bit	SHLIB_PATH	<install_dir>/lib/hpux_11­_32/opt
	PATH	<install_dir>/bin/hpux_11_32/opt
Linux Redhat Enterprise 2.1, 32-bit Redhat	LD_LIBRARY_PATH	<install_dir>/lib/linux_rhel21_32/opt
	PATH	<install_dir>/bin/linux_rhel21_32/opt
Linux AS 2.1 (Itanium), 64-bit	LD_LIBRARY_PATH	<install_dir>/lib/linux_rhas21_ia64_64/opt
	PATH	<install_dir>/bin/linux_rhas21_ia64_64/opt
Linux Redhat Enterprise 3.0 (Opteron), 64-bit	LD_LIBRARY_PATH	<install_dir>/lib/linux_rhel30_64/opt
	PATH	<install_dir>/bin/linux_rhel30_64/opt
IBM AIX 5.1, 32-bit	LIBPATH	<install_dir>/lib/aix_51_32/opt
	PATH	<install_dir>/bin/aix_51_32/opt

The generally accepted installation location for <install_dir>  is /opt/OpenAccess.

Notes on Linux Platforms

On some Linux machines, OpenAccess cannot determine which Linux operating system is in use. In these cases, OpenAccess uses the machine type (retrieved with uname -m) on the Linux machine to determine the correct Linux version to use.

The following is a mapping of the uname output to the resulting Linux platform.

Machine Type	Linux Version to Use
*86	linux_rhel21
*86_64	linux_rhel30
ia64	linux_rhas21_ia64

Note that the asterisk (*) represents a wildcard.

If OpenAccess does not recognize one of the above, it echos unknown. In this case, use the OA_UNSUPPORTED_PLAT variable to change the value. See the following section for more information.

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_rhel21, 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

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, HP, or IBM platforms only):

setenv OA_BIT 64

Note: If you are using Itanium, the bit is automatically set to 64. 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, HP, or IBM platforms only). For example:

setenv DEF2OA_BIT 64
  

Optionally Compiling on UNIX Platforms (Solaris, HP, 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.)

Notes:

For Linux users:
• The path to the gcc 3.2.3 compiler libraries must be in your LD_LIBRARY_PATH.
• If you will be Compiling on Linux Redhat Enterprise 2.1 32-bit or Linux AS 2.1 (Itanium) 64-bit, do not proceed without reading Notes on Compiling on Linux Platforms Without gcc 3.2.3.
• Currently, the Opteron platform can be compiled only on 64-bit.
• For HP users, you must use the HP install version 72.3 when building on HP. The install (fileutils) 4.1 will not work.
• For Solaris users:
  To ensure proper compilation, set this compiler flag:   -features=tmplife.    
  The OpenAccess development team uses the following patches for Forte 8. (However, these patches are not strictly required.)
  • 112763-11: Compiler Common S1S8CC: Patch for S1S8CC C C++ F77 F95
  • 112760-08: C 5.5: Patch for S1S8CC C compiler
  • 113817-06: C++ 5.5: Patch for S1S8CC C++ compiler

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.

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 and Itanium, this is automatically set to _64 for you. On Opteron, you can force it to _32.
   
2. cd <install_dir>/oa
   
   
3. gmake <command> OPTMODE=<mode> VERBOSE=<state>

where <command>  is one of: 
    clean           Commands affect OpenAccess core package and all subpackages
    uninstall       including translators.
    install


    clean_oa        Commands affect only OpenAccess core package.
    uninstall_oa
    install_oa

    You can also build the translators and subpackages individually using the 
    following suffixes for the clean, uninstall, and install commands: _spef,
    _strm, _verilog, _lefdef, _lang
    
where <mode>  is one of: 
    dbg	    Debug compile, which is the default
    opt	    Optimize compile
    
where <state>  is one of:
    false   Hide compile commands, which is the default
    true    Show compile command

Compilation Errors:

• Unless you have the LEF/DEF parser kits and zlib installed, you will get errors on LEF/DEF translator compilation. If you want to compile the LEF/DEF translators, refer to Optionally Compiling Translators.
• 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.
• Unless you have a 2.0 OpenAccess installation, you will get errors for the oa20to22 translator. For information about using the oa20to22 translator, see Automatically Updating 2.0.x Libraries to 2.2.

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 &

   where <mode>  is one of:
   dbg     Debug compile, which is the default
   opt     Optimize compile
   
   where <state>  is one of:
   false   Hide compile commands, which is the default
   true    Show compile commands

Notes on Compiling on Linux Platforms Without gcc 3.2.3

The procedure outlined in this section is recommended for compiling OpenAccess code and application code built on OpenAccess for the Linux Redhat Enterprise 2.1 32-bit or Linux AS 2.1 (Itanium) 64-bit platforms. If you do not follow this procedure, your application will likely have interoperability problems, such as segmentation faults, with other applications built on OpenAccess. You must install and build gcc and binutils in a specific manner. The general process is outlined below, followed by the specific steps to build gcc and binutils.

General Process:

• Build a new, tightly-integrated compiler package for GCC 3.2.3 and BINUTILS 2.13.2.
  Verify that the ld binary picked up by gcc is version 2.13.2. Type the following at a command prompt to verify the version of ld being used:
  gcc -v

• Rebuild (or at least relink all executables) with the new version of gcc.
  

Build Process

Downloading the Packages

• Download files from GNU FTP server locations below:
         ftp://ftp.gnu.org/gnu/binutils/binutils-2.13.2.tar.gz
         ftp://gcc.gnu.org/pub/gcc/releases/gcc-3.2.3/gcc-3.2.3.tar.gz
         ftp://gcc.gnu.org/pub/gcc/releases/gcc-3.2.3/gcc-core-3.2.3.tar.gz
         ftp://gcc.gnu.org/pub/gcc/releases/gcc-3.2.3/gcc-g++-3.2.3.tar.gz
• Extract the files.

Setting Up a Clean Build Environment

• set finaldir=/local/gcc-3.2.3  => where compiler will be installed
• set pass1dir=/local/stage1          => Temp dir for bootstrapping gcc/binutils
• mkdir /local
• mkdir $finaldir
• mkdir $pass1dir
• bash:
export PATH=/bin:/usr/bin
export LD_LIBRARY_PATH=
   or
csh or tcsh:
setenv PATH /bin:/usr/bin
unsetenv LD_LIBRARY_PATH
• cd <1_level_above_compiler/binutils_source> 
  (if you type ls, you should see binutils-2.13.2 and gcc-3.2.3.

Build Binutils - Pass 1

Note: There will be numerous warnings in the next three sections. This is not unusual.

• rm -rf binutils-build
• mkdir binutils-build
• cd binutils-build
• ../binutils-2.13.2/configure --prefix=$pass1dir --disable-nls
• make LDFLAGS="-all-static"
• make install
• cd ..

Build GCC - Pass 1

• rm -rf gcc-build
• mkdir gcc-build
• cd gcc-build/
• ../gcc-3.2.3/configure --prefix=$pass1dir --with-local-prefix=$pass1dir --disable-nls --enable-shared --enable-languages=c --with-gnu-as --with-as=$pass1dir/bin/as --with-gnu-ld --with-ld=$pass1dir/bin/ld
• make BOOT_LDFLAGS="-static" bootstrap
• make install
• cd ..

Build Binutils - Pass 2:

• rm -rf binutils-build2
• mkdir binutils-build2
• cd binutils-build2
• setenv PATH $pass1dir/bin:${PATH}
• ../binutils-2.13.2/configure --prefix=$finaldir --enable-shared
• make tooldir=$finaldir
• make tooldir=$finaldir install
• cd ..

Build GCC - Pass 2

• setenv PATH $finaldir/bin:${PATH}
• rm -rf gcc-build2
• mkdir gcc-build2
• cd gcc-build2 ../gcc-3.2.3/configure --prefix=$finaldir --with-local-prefix=$finaldir
--with-gnu-as --with-as=$finaldir/bin/as --with-gnu-ld
--with-ld=$finaldir/bin/ld --enable-clocale=gnu --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-languages=c,c++
• make
• make install
• cd ..

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

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, HP, 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. You might also want to use a different compiler of your choosing.

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 .NET 2003 to compile your environment on Windows

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.sln

To build:

1. Double click on oaDynamic.sln.
   Microsoft Visual Studio .NET 2003 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.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 .NET 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, adhere to the following rules.

• Place the include statement for the OpenAccess headers before any #include <Windows.h> statement.
  
  or
  
  
• 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.

Optionally Compiling Translators

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. (See the sections that follow for more information.)

• LEF and DEF

Download and compile the 5.60 or later LEF/DEF parser from https://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/lefdef<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/lefdef<version>/tools.<platform>/include.
  • The 32bit LEF/DEF parser libraries must be copied into /opt/lefdef<version>/tools.<platform>/lib.
  • The 64bit LEF/DEF parser libraries must be copied into /opt/lefdef<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.1.

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/zlib1.2.1 (for 32-bit execution) and /opt/zlib64bit1.2.1 (for 64-bit execution).

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.1.

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/zlib1.2.1 (for 32-bit execution) and /opt/zlib64bit1.2.1 (for 64-bit execution).

• OpenAccess to Verilog Translators

Pre-compiled translators for Verilog are available in:

<install_dir>/bin/<platform>/<mode>/

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

• Bison 1.875-4 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/bison1.875-3
FLEX_HOME	None	/opt/flex2.5.4

• oa20to22 Translator

The following procedure explains how to build the oa20to22 translator. If you do not already have a OpenAccess 2.0 installation, download and install the 2.0 kits before proceeding.

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

Uninstalling OpenAccess

UNIX Platforms (Solaris, HP, IBM, and Linux)

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

% rm -rf <install_dir>

Windows Platform

1. From the Start menu, choose Programs > OA > Uninstaller or
   Programs > OA > Developer Uninstaller.
2. Follow the Wizard to complete the uninstallation.

Return to top of page

Copyright © 2003-2005
All rights reserved.