 |
 |
 |
 |
 |
 |
 |
 |
 |
|
|
|
|
|
|
|
|
|
This document describes
This section explains how to set up the translators and optionally specify a bit mode. For details about running individual translators. refer to the documentation for those translators.
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/ If you want to run OpenAccess binaries on a Linux platform, you must have a compliant version of the gcc runtime shared libraries in your LD_LIBRARY_PATH. In most cases on Linux, these are not the standard C++ runtime libraries supplied with the operating system.
setenv LD_LIBRARY_PATH <gcc4.1.1_compliant_installDir>/lib
If you do not have access to the libraries, you can build them.
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/optOpenAccess executables come in both 32-bit and 64-bit versions on the platforms that support both process widths. In general, if you might use large data sets that might run out of virtual memory when run with 32-bit executables, you should set the bit mode so that the 64-bit executable is used.
To set the bit mode 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
For more information about overriding environment variables for OpenAccess binaries, see the following section Using Wrapper Script Options. See also Overriding Environment Variables in the OpenAccess 2.2 Installation and Configuration Notes.
All of the OpenAccess executables use wrapper scripts to set the proper environment for the platform they are running on. The executables for all supported platforms are provided in the OpenAccess installation hierarchy. When you run a translator, or other executable, the wrapper script for that translator determines which executable to run. Using wrapper script option switches, you can override the environment variable settings that determine the executable bit modes and whether debug or optimized versions of the executables are used. The switches you can use for controlling the executable environment are described in the following table.
| Option | Description |
|---|---|
| -64 | Selects the 64-bit version of the translator executable (if available). This option takes precedence over the <executable>_BIT and OA_BIT environment variables. |
| -32 | Selects the 32-bit version of the translator executable (if available). This option takes precedence over the <executable>_BIT and OA_BIT environment variables. |
| -dbg | Selects the debuggable version of the translator executable. This option takes precedence over the <executable>_MODE and OA_MODE environment variables. |
| -opt | Selects the optimized version of the translator executable. This option takes precedence over the <executable>_MODE and OA_MODE environment variables. |
| -debug3264 | Provides diagnostics regarding the executable actually selected based on the environment variables, command line options, and the executables available on the platform. |
OpenAccess translators use OpenAccess libraries to map and convert data from one format into another. All of the OpenAccess translators share certain common functionality and use a common subset of command-line options to find libraries defined on your system and to determine the design management (DM) system that is used during a translation. This document describes how all OpenAccess translators find and use the libraries on your system.
All OpenAccess translators use a library definition file (lib.defs file) to find the libraries that are available on your system and to record new library definitions if new libraries are created. The lib.defs file is an ASCII file that contains a symbolic name for each library and the path to each library. The library path can be either relative or absolute. Relative paths are in relation to the location of the library definition file.
The following is a simple example of a lib.defs file that includes one definition that specifies a relative path to a library and a second that specifies an absolute path to another library. The # character at the beginning of a line identifies the line as a comment.
#tools/oa/demo library definition file
DEFINE lib ./lib
DEFINE techlib /opt/OABuilds/sun4v/oa/tools.sun4v/oa/demo/technology
A library definition consists of a line that starts with the DEFINE keyword, followed by a space, followed by a symbolic name for the library, followed by a space, and followed by the path to the directory containing the cells. Although you can edit or create a lib.defs file with a text editor, you do not need to because translators manage this for you. For additional information about the content and syntax of statements used in lib.defs files, see the Library Definition Files section of the OpenAccess Libraries and Design Management article.
One command-line option you can use when you start a translator is -libDefFile, which specifies a library definition file to load. If a library definition file is not specified by using this option, the translator uses the default search mechanism defined by OpenAccess to find and load a library definition file. The default paths, in the order searched, are: ./lib.defs, ~/lib.defs, <install_dir>/data/libraries/lib.defs. You can use any filename that is legal on your system for the library definition file, but if you rely on the OpenAccess default search mechanism, the filename is lib.defs.
Library definition files can include other definition files. The file you specify using -libDefFile, or the first default lib.defs file that is found, is identified as the top library definition file. As a result of loading this library definition file, all the libraries found in or included by that file are opened.
If a default lib.defs file is not found, or a lib.defs file recursively includes itself, a warning message is printed and the translator continues. All other problems encountered while loading a library definition file, such as a syntax error or multiple definitions for the same library, result in an error message and the translator application terminates.
If a translator application creates a library, it attempts to add a definition for the library to the top library definition file. If the top file is not writable, the translator application tries to add the definition to lib.defs in the current working directory. If ./lib.defs did not previously exist, this file is created and a statement to include the top library definition file is added.
Translators handle errors in the lib.defs file as follows:
lib.defs file is always an error that stops the translation. lib.defs file that does not correspond to an existing library on disk and is not required for the translation is not an error. spef2oa translator assume that every entry in the lib.defs file is needed for the translation. Specifically, the following translators handle entries in the lib.defs file that do not correspond to existing libraries on disk as errors: spef2oa, oa2lef, oa2def oa2verilog, oa2spef.The -lib option specifies the library to read or write. This option specifies the symbolic name for an input or output library. If the named library already exists, it must be defined in the library definition file. If the library is being created by the translator, the path to where the library is created can be supplied using the -libPath option. All translators that create libraries include -libPath as an option. This option specifies the full path to the library directory. The base portion of the path is everything up to the library directory and must already exist. For example, if the full path to the library is:
/designs/user/oa/test/newlib
The base path /designs/user/oa/test must already exist. The specified library directory must either be empty or not exist. If the library directory does not exist, OpenAccess creates it. The full path usually ends in a directory that has the same name as the library, but that is not a requirement. -libPath is used only when the library specified with the -lib option does not already exist. If the –libPath option is not supplied when a library is created, the library is created in the current working directory as ./<library name> where <library name> is the name specified with the –lib option. OpenAccess never appends the library name to the specified path. "–libPath ." is almost never an appropriate argument.
Each OpenAccess library is handled by a specific DM System that must be selected when the library is created. OpenAccess provides two design management (DM) systems that you can choose from, or you can use a DM System from other providers that is installed in your OpenAccess installation hierarchy. OpenAccess translators use a default DM system if you do not specify one.
The -DMSystem option is included with all translators that create an OpenAccess library. This option specifies which DM system to use when creating the library. The OpenAccess DM system names that you can use are oaDMTurbo, and oaDMFileSys. To learn more about oaDMTurbo and oaDMFileSys, see the OpenAccess Libraries and Design Management article. If –DMSystem is not provided, OpenAccess selects the default DMSystem for your installation.
The -DMAttribute option is also included with translators that create an OpenAccess library. This option specifies one or more attributes that are associated with every library that the translator creates. Attributes are supplied as name=value pairs. The attribute name and value are separated by an equal sign with no intervening spaces, and the attribute list must be enclosed in quotation marks. If more than one attribute pair is supplied, each pair must be separated by a single space, and the entire attribute list enclosed in quotation marks.
A namespace is a set of rules that define the legal characters and determine how names are interpretted. Translators use the oaNative namespace to interpret library, cell, and view names in the command line. Other names that refer to name-mapped OpenAccess objects, such as net and module names, use the namespace that is appropriate for the translator’s file format.
Return to Programmers Guide topics
Copyright © 2001-2010 Cadence Design Systems, Inc.
All rights reserved.