DEF to OpenAccess Translator (def2oa)

The DEF to OpenAccess Translator imports a file in the DEF format into an OpenAccess design. DEF contains the design-specific information about a circuit. DEF to OpenAccess is available from the command line through the executable def2oa. A DEF file, and destination library, cell, and view are required to begin a translation.

Command Syntax

To run def2oa, enter the following:

def2oa -def file -lib library [Optional Arguments]

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

    def2oa ... -DMAttributes "name1=value name2=value name3=value"

   <layerName> <layerNumber> 

# Example layer map file
#layerName  	layerNumber
   Metal1        1 
   Via1          2
   Metal2        3
   Via2          4
   Metal3        5
   Via3          6
   Metal4        7
   Via4          8
   Metal5        9
   Via5          10

# def2oa command line arguments

logFile        mydef2oa.log
oaDMSystem     oaDMTurbo
overwrite
useCustomVias

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.

The following is an example of def2oa command line syntax:

    def2oa -def ac36.def -lib myDesignLib -libPath /db/myProject/cds/myDesignLib  \
    -cell myDesign -view layout -techLib ac36 -optimize -noModHier -useCustomVias

Updating an Existing EMH

If there is an existing design, def2oa attempts to fit the physical information into the existing embedded module hierarchy. def2oa attempts to find the logical equivalent of each object in the DEF file and append its physical information (such as routes, pin shapes, and so forth) to the design. Attempting to update an existing physical design produces duplicate shapes in the design and unpredictable results. To disable this update mode, use the -overwrite option, which causes def2oa to overwrite an existing design.

If there is no existing design, def2oa attempts to create the logical hierarchy based on the hierarchical names in the DEF file. To disable the creation of objects in the module domain, use the -noModHier option.

Soft-Matching

Some net names in the DEF file might not match the net names in the module hierarchy. This can happen in Verilog or DEF-only flows. If a net name in a DEF file cannot be matched to a net name in the module hierarchy, the translator attempts to create a match by finding the first instTerm on the net.

Error Handling

If an error occurs during translation, usually the translator can emit a warning or error message and continue. However, certain translation errors halt further translation. The manner in which translation errors are handled depend on the type of error.

• Parse Error The translator issues *Parse Error* (instead of an error ID and message) and translation is halted.
• OpenAccess Data Creation Error The translator issues an error message, proceeds to the next object, and continues translation.
• Special Case If DEF NET connections are missing, a warning message is issued, translation of the net with missing connections is skipped, and translation of the next connection continues.

DEF Update Mode

When annotating physical information into an existing logical design, any object in DEF that has no logical equivalent produces a warning, and translation continues with the next object. In particular:

• If logical DEF components or DEF pins are missing, the missing components or pins are ignored, a warning message is issued, and translation continues.
• If a logical DEF net is missing, the missing net is ignored, a warning message is issued, and translation continues.
• If an instance-terminal connection is missing in a DEF logical net, the missing connection is ignored, a warning message is issued, and translation continues.

Handling of Physical-only Objects

Physical-only objects are treated differently. No corresponding object is created in the module domain for physical-only objects, and therefore, a subsequent export to Verilog does not include the physical-only objects. Also, when using def2oa to annotate physical information into an existing logical design, these objects are created in the block domain even though a logical equivalent does not exist. Certain DEF objects are considered physical-only. These occur in the following constructs:

• COMPONENTS
• PINS
• NETS, SPECIALNETS

How the Translator Uses Namespaces

A namespace is a set of rules that define the legal characters and determine how names are interpretted. 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 DEF namespace.

Merging Verilog and LEF/DEF Information

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.

Error and Warning Message Format

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 and optional line number element are included, when available, to more precisely identify the source of a problem or condition within the source data file. When present in an error or warning message, the filename and line number correspond to the location of the last line parsed for the object, and therefore, the cause of the error or warning can occur on a line preceding the indicated line number. 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

Copyright © 2001-2010 Cadence Design Systems, Inc.
All rights reserved.