Verilog to OpenAccess Translator (verilog2oa)


Overview

You translate Verilog data to the OpenAccess database format by using the verilog2oa application. A destination library and a Verilog file are required to begin a translation. The translator reads Verilog-2001 (IEEE 1364-2001), which is a superset of Verilog-1995 (IEEE 1364-1995). Therefore, the translator also reads Verilog-1995. verilog2oa translates the netlist information in a Verilog file to one or more OpenAccess Designs.

The basic command-line syntax for using the translator is:

    verilog2oa -lib library -verilog file [Optional Arguments]

Running verilog2oa using the default behavior (without optional arguments) translates all the modules in the Verilog into oaModules in a single oaDesign. The translator accomplishes this automatically by selecting the top module using the following algorithm:

You can override this automatic selection by using the –top option. Any modules that are never instantiated underneath the top module’s hierarchy are deleted before the design is saved.

verilog2oa is designed for structural Verilog. Not all features of the Verilog language are handled. By default, unimplemented features of the language cause an error. The tolerate option reduces these errors to warnings, but the result might not be a complete or accurate representation of the netlist.

See Verilog to OpenAccess Mapping for details about how Verilog statements and constructs map to OpenAccess database objects.

Use the -help or -h argument to display command-line help. The command-line arguments are described in the following table.

Required Arguments
-lib library

Specifies the destination OpenAccess library for the translated Verilog data. The destination library is created if it does not already exist. For information about how the translator finds a library using the library definitions file, see How Translators Use Libraries. See also the -libDefFile option for specifying a particular lib.defs file.

-verilog fileList

Verilog file to translate. You can specify multiple files with a quoted, space-separated list.

Optional Arguments
-blackBox Creates a separate design for each empty Verilog module. Empty Verilog modules are modules that have no instances and no assign statements. Empty Verilog modules can have ports, wires and (if running with tolerate) non-structural Verilog statements. Instances of black box modules become design instances. This option is used when leaf libraries are not available as OpenAccess Designs, and the input Verilog contains definitions for the leaf cells.
-dataModel dataModel value Specifies a dataModel value of 0, 1, 2, or 3, which determines the data model for the OpenAccess database and determines how properties are mapped to the database. If this option is omitted, the default dataModel value of 1 is used unless the OA_DATAMODEL environment variable is set or a file named OA.DATAMODEL is found in the data directory of your OpenAccess installation hierarchy. See the discussion Specifying a DataModelRev for a Flow for more information.
-designPerMod Creates a separate design for each Verilog module.
-DMAttributes attributeList Specifies a list of DM attributes that are used for the library that verilog2oa creates when it creates a new library. Attributes are specified as name=value pairs. There must be no space on either side of the equal sign, two or more pairs must be space-separated, and the list must be enclosed in quotes. For example:
    verilog2oa ... -DMAttributes "name1=value name2=value name3=value"
-DMSystem sysName Specifies the DMSystem to use when verilog2oa creates a new library. The DM plug-ins included with OpenAccess are oaDMTurbo or oaDMFileSys. The default DM system is oaDMSystem, which automatically selects between oaDMTurbo or oaDMFileSys. Use of the oaDMTurbo plug-in is not recommended.
-globals module Specifies the name of the module in which to define global nets if global nets exist. If unspecified, the module name defaults to globals.
-help | -h Prints command-line help.
-leafLibs libraryList If you use this option, a warning is issued. This option is deprecated. Use the -refLibs option instead.
-leafViews viewList If you use this option, a warning is issued. This option is deprecated. Use the -refViews option instead.
-libDefFile filename Specifies the lib.defs file to load. The path to the lib.defs file can be a full or relative path. If this option is omitted, the default search order is used to find and load the lib.defs file.
-libPath path Specifies the full path name (including the library name) for the library. Use this argument only if the library does not exist. If not specified, the new library is created at ./<library>, where <library> is the value of the -lib argument.
-logFile file Specifies the log filename. If this option is omitted, the log filename defaults to verilog2oa.log.
-noInfo msgIds Suppresses the specified INFO messages. msgIds is a quoted, space separated list of numbers. Each number in the list represents the numerical portion of the ID for the message you want to suppress. None of the numbers in the list may be zero. Suppressed messages do not appear on the terminal or in the log file.
-noWarning msgIds Suppresses the specified WARNING messages. msgIds is a quoted, space separated list of numbers. Each number in the list represents the numerical portion of the ID for the message you want to suppress. None of the numbers in the list may be zero. Suppressed messages do not appear on the terminal or in the log file and are not included in the total of WARNING messages displayed in the summary. You can browse the list of error and warning messages to determine which you want to suppress.
-overwrite Replaces an existing design with the translated data. If this option is omitted, and the specified design exists, an error is generated.
-refLibs libList Specifies one or more libraries in which to search for leaf cells. You can specify multiple libraries with a quoted, space-separated list. By default, the refLibs list is empty.

The translator can attach technology information to the output library if the first reference library is a technology database. See Attaching Technology Information to a Library.

refLibs are searched in the order they appear on the command line. If the leaf name is not found, the optional refViews are searched next. The output library is not part of the refLibs list unless you explicitly specify it. If any cell name in the refLibs library matches the Verilog module name, the module is considered a leaf cell.

Refer to Searching for Leafs in refLibs and refViews for more information.
-refViews viewList Specifies a particular view in which to search for leaf cells. You can specify multiple views with a quoted, space-separated list.

The default view list has a single view name: abstract.

refViews are searched in the order they appear on the command line. refViews are searched after the arguments for -refLib are searched. If no appropriate view is available, a stub module with the name of the first view name in the refViews list is generated for the leaf.

Refer to Searching for Leafs in refLibs and refViews for more information.
-shared Allows other applications to access the output library while this application is running.
Note: The additional synchronization overhead required for shared library access can increase translation time.
-tieLow net By default literal zeros, such as 1'b0 connected to ports, are mapped to a global net named tie0 with the oaSigType of TieLo. Literal numbers larger than a single bit are mapped to bundles of the tie0 and tie1 nets by using the number's bit pattern. You can change the name of this global net with this tieLow option.
-tieHigh net By default literal ones, such as 1'b1 connected to ports, are mapped to a global net named tie1 with the oaSigType of TieHi. Literal numbers larger than a single bit are mapped to bundles of the tie0 and tie1 nets by using the number's bit pattern. You can change the name of these global nets with this tieHigh option.
-templateFile file

Specifies a file containing arguments to verilog2oa. You can specify a template file instead of entering a string of arguments on the command line.

If you specify a template file, arguments on the command line have precedence over arguments specified in the file. So, if the same argument exists in the template file and in the command line, the translator uses the argument on the command line.

Specify arguments in a template file as follows:

  • Enter arguments in the template file without a dash (-) before the argument.
  • Enter each argument and value pair on a single line.
  • Separate the argument from its value using a space or a tab.
  • Designate comment lines with a # sign as the first character in the line.

Sample Template File

# verilog2oa command line arguments

logFile        myverilog2oa.log
noWarnings     "40019 40068"
overwrite
-tolerate verilog2oa is designed for structural digital Verilog.  Not all features of the Verilog-2001 language are handled.  By default, unimplemented features of the language cause errors. The tolerate option reduces these errors to warnings, but the result may not be a complete or accurate representation of the netlist.
-top module Turns off the automatic top-module detection capability of verilog2oa and lets you explicitly select the top-module you want.
-validateInstTerms Turns on additional validation to verify that all oaModInstTerms are bound to oaModTerms. Using this option forces binding, which can slow the translation.
-v Prints tool, format, and library version information.
-version Prints tool and format version information.
-view view Specifies the view name for all created modules. If not specified, the default name is netlist.
-viewType viewTypeName Specifies the view type for all created modules. viewTypeName is a string that corresponds to a valid oaReservedViewType. The default view type is netlist.

Note: While the data created by verilog2oa is netlist data, the designs it creates should be set to the viewType that is appropriate for the intended use. If these designs will go into implementation, the viewType should be maskLayout.

Note: Command line arguments specifying library, cell, and view names are interpreted according to the Native name space. See Native Name Space in the Name Mapping article of the Programmers Guide for details about the native name space.

-lib and -libPath Arguments

The -lib argument is required to specify the OpenAccess library you want to create. If the library with the logical name you specify is defined to the library server, the new OpenAccess data is written to that existing library. The –lib argument is required to specify the name of the output library. If the library named by the –lib option is defined in the specified lib.defs file, verilog2oa appends to that library. Otherwise, verilog2oa creates the library and adds an entry for the library to the specified lib.defs file.

If your library definitions file has errors, or any of the referenced libraries cannot be opened, either an error message is generated and translation halted or, if the library is not required to complete the translation, translation proceeds without an error or warning. For more information about this behavior, see the Handling Errors in lib.defs Files section in the Programmers Guide chapter How Translators Use Libraries.

The –libPath option is used only when the library is being created (although it is a valid but ignored option when the library is not being created). When the library is being created, if the directory specified by the –libPath option exists, it must be empty. A library is created using the specified logical library name and the specified file system library path. The -libPath value is interpreted as a complete path. The basename of that path becomes the OpenAccess library. For example, if the -libPath value is /usr/mySpace/lib1, the directory lib1 is created under /usr/mySpace and /usr/mySpace/lib1/lib.db is written. If "." is given as the -libPath value, the current working directory becomes an OpenAccess library. By default, the translator sets the -libPath value to ./<libName>, where <libName> is given by the –lib command line argument.

Attaching Technology Information to a Library

verilog2oa can attach technology information to the library it creates if:

verilog2oa creates a reference to the Tech DB in the first library that is specified by the -refLibs option.

Creating a Design by Merging Verilog and LEF/DEF Information

If you need to create a design from Verilog and LEF/DEF information, you must use verilogAnnotate, verilog2oa, and the LEF/DEF translators in the proper sequence in order to achieve the correct results.

To create the tech library, annotate correct port order and port structure, create the design library, and create the design database.

  1. Use the command string:

    lef2oa -lib lib1 -lef lib.lef

    This creates views named abstract in library lib1. View names default to abstract if the lef2oa -view option is not specified. Each entry in lib.lef represents one cell.

  2. Use the command string:

    verilogAnnotate -verilog lib.v -libs lib1

    verilogAnnotate annotates the port ordering, port structure, and buses of the cells in lib1. lib.v must have a Verilog module defined for every cell in library lib1. The -refViews option is not needed unless lib1 includes other layout types that must be annotated with the correct port order.

    Note: verilogAnnotate does not create a new design; it only annotates an existing design.

  3. Use the command string:

    verilog2oa -lib lib2 -verilog design2.v -refLibs "lib1"
    -view layout -cell top -viewType maskLayout


    This assumes that design2.v has a definition of cell top (and possibly some intermediate modules) and the leaf cells it references are the cells defined in lib1. Notice that the -refViews "layout" option is not needed since the views created in the first step are named abstract not layout. verilog2oa assumes views are named abstract if -refViews is not specified. In this case, specifying -refViews layout would create separate views in lib2 for those leaf cells if definitions of the same leaf cells in design2.v exist in lib.lef.

  4. Use the command string:

    def2oa -lib lib2 -def design.def -techLib lib1 -cell top -view layout

    This assumes that design.def has a definition of cell top, all of the leaf cells that it references are in lib1 (because lib1 is specified as the techLib library), and the leaf cells are named abstract. Options such as -masterViews and -masterLibs must be used if these assumptions are not correct.

How the Translator Uses Namespaces

A namespace is a set of rules that define the legal characters and determine how names are interpreted. This translator uses 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 Verilog namespace. The filename that the translator uses as its input or output is always a simple string and is not interpreted in any namespace.

Consider the following example where you want to:

The word “medium” is a keyword in Verilog but the translator does not interpret library names in the Verilog namespace, so there is no need to escape the library name. The filename is a simple string, so there is no need to escape it. However, the tie-off nets and the top level module name are interpreted in the context of the Verilog namespace, and these names contain illegal characters in that context; so these names must be escaped. The command line to perform this translation is:

    verilog2oa –lib medium –verilog medium.v –tieHigh ‘\!VDD ‘ –tieLow ‘\!VSS ‘ –top ‘\a/b ‘

The trailing spaces after the escaped name are required by the Verilog escaping rules.

Error and Warning Messages

Translators emit messages that report translation progress, report warnings about unusual data or conditions, or report problems with files or data that caused partial or complete translation failure. These messages are written to a log file so you can review translation status, identify error and warning conditions, and consider whether additional actions are needed.

OpenAccess translators use a standard message format to ensure comprehensive and consistent messaging. This message format consists of three elements, which are: message type keyword, message prefix, and message text. The message text can be further divided into three parts. The first part indicates what caused the message, the second indicates the consequence of the problem or condition, and the third part suggests an action you can take to remedy the problem or condition.

In addition to the three standard elements, messages can also include two optional elements. An optional filename/line number element is included, when available, to more precisely identify the source of a problem or condition within the source data file. A context string is another optional element that is included, when available, to identify the type of data object that caused the message to be emitted. The following example shows a typical error message that includes the optional filename and line number element.

    ERROR: (OALEFDEF-50004): file.lef(123): A cell was not specified. Translation was terminated. 
    You must specify a cell.

One benefit of this message format is that it allows you to sort, filter, and examine only those types of messages that interest you. The keyword at the start of each message is either ERROR or WARNING and is always all uppercase. The message prefix identifies the translator family and the specific message source within the translator. The message prefix is a stable value that will not change between versions even when the message text gets updated. This makes it suitable for routine sorting and filtering.

If you seek assistance for resolving an issue related to a translator error or warning message, be sure to retain the message type keyword (ERROR or WARNING), and retain the message prefix to identify the translator family and the message source. Also make note of the filename/line number and context information if these are included in the message.

Return to top of page