You can update existing OpenAccess data with terminal ordering information from a Verilog file.
Enter:
verilogAnnotate -refLibs libraryList -verilog fileList [Optional Arguments]
The verilogAnnotate
executable updates existing OpenAccess designs with information from a Verilog netlist. Only the top module of any given OpenAccess design is annotated. Module instances are not created and connectivity is not changed.
For each Verilog module in the Verilog file, verilogAnnotate
performs the following:
libraryList
looking for an oaCell with the same name as the Verilog module. viewList
. Each view in the viewList
is tried in the order specified on the command line. Otherwise, the oaDesign that corresponds to the oaCell and oaView is opened for editing. verilogAnnotate
updates the top module of the oaDesign with the module interface information from the input Verilog module. If this information already exists in the oaModule, it is overwritten. It is not an error if there are more terminals in the top oaModule than there are ports in the Verilog module. It is an error if there are Verilog ports that do not have corresponding oaModTerms in the top oaModule. If there is no top module, the top module will be set according to the verilog2oa
top module detection rules.
verilogAnnotate treats "tristate" as equivalent to "output" for consistency purposes. Ports that are declared "output" in Verilog, but have an existing termType of "tristate", retain the "tristate" termType.
verilogAnnotate
is based on verilog2oa and has the same mappings and restrictions.
Required Arguments | |
---|---|
-refLibs libraryList | Specifies a quoted, space-separated list of OpenAccess libraries in which to search for oaDesigns to annotate. verilogAnnotate searches for a matching oaCell for each Verilog module.
|
-verilog fileList | Quoted, space-separated list of Verilog files. The files are processed in the order they are specified. |
Optional Arguments | |
-help | -h | Prints command-line help. |
-leafLibs libList | 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 mechanism of the DM system is used to find and load the lib.defs file. |
-logFile file | Names the logfile. If not specified, the default filename is verilogannotate.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. |
-refViews viewList | Specifies a quoted, space-separated list of views that verilogAnnotate searches in the oaCells that match the Verilog module name. All specified views are searched for a possible match, all found matches are used, and all found Verilog modules are updated. If you omit this option, the default abstract view is used. |
-templateFile file | Specifies a file containing arguments to 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:
Sample Template File # verilogannotate command line arguments logFile myverilogannotate.log refLibs "mylibA mylibB" tolerate |
-tolerate | Tolerate unimplemented features and non-structural Verilog in the input. Warnings are issued when these features are encountered. Using this option can cause unexpected results. By default, this option is off. |
-v | Prints tool, format, and library version information. |
-version | Prints tool and format version information. |
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.
If you need to merge Verilog and LEF/DEF information, you must follow a particular sequence of steps. Refer to the verilog2oa documentation and the section Creating a Design by Merging Verilog and LEF/DEF Information for the steps you must follow.
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.
Copyright © 2004-2010 Cadence Design Systems, Inc.
All rights reserved.