OpenAccess to Verilog Mapping

This document describes

How OpenAccess 2.2 database objects map to structural Verilog statements and constructs.
The implementation requirements for all OpenAccess to Verilog translators in order to ensure interoperability.

If a Verilog construct is listed as not mapped, the OpenAccess oa2verilog translator does not support this feature of the Verilog language. This does not prohibit a different implementation from using or mapping that feature.

There are two styles of structural Verilog: Verilog-2001 (IEEE 1364-2001) and Verilog-1995 (IEEE 1364-1995). All OpenAccess to Verilog translator implementations should support the Verilog-1995 style, and may optionally support the additional features in the Verilog-2001 style. An implementation that supports both Verilog styles must default to write in the Verilog-1995 style.

Conventions for Verilog Syntax Descriptions
Name Mapping
How OpenAccess Entities Map to Verilog Constructs
Module Declaration (oaModule)
Port Declarations (oaModTerms)
Net Declarations (oaModNets)
Instance Declarations (oaModInsts)
End Module Declaration
Verilog-2001 (IEEE 1364-2001)

Conventions for Verilog Syntax Descriptions

This document uses the following conventions to describe Verilog language features:

White space separates lexical tokens.
Angle brackets (<>) surround descriptions of items and are not literal symbols.
<name> is a syntax construct.
<name>? is an optional, single item (zero or one).
<name>* is zero or more items.
<name>< , <name>> * expresses a comma-separated list of items with at least one item in the list.
<name>+ is one or more items.
Items in bold are literal Verilog keywords or syntax characters.

Name Mapping

The OpenAccess oaVerilogNS namespace maps OpenAccess names to Verilog identifiers.

How OpenAccess Entities Map to Verilog Constructs

OpenAccess Entity	Verilog Construct
oaModule	module, endmodule
oaModTerm	input, output, inout
oaModNet	wire, supply0, supply1
oaModNet::makeEquivalent ()	assign

Module Declaration (oaModule)

The Verilog module declaration describes the connectivity interface to the oaModule and is used when the module is instantiated in other modules. The module's structural definition consists of port, net, and instance declarations.

The OpenAccess oa2verilog translator traverses all modules in an oaDesign and writes a separate Verilog module for each oaModule. When a design has multiple modules, they are written with a bottom-up approach, meaning they must be defined before they are used.

module <moduleName> (<list_of_ports>? ) ;
	<port_declarations>
	<net_declarations>
	<instance_declarations>
endmodule

Where:

<moduleName> is the cellName of the module to be defined in Verilog.

<list_of_ports> = (<portName><,<portName>>*)

Or:

<list_of_ports> = (.<portName>(<netName>)<,.<portName>(<netName>)>*)

Where:

<portName> is the name of an oaModTerm.

<netName> is the name of the oaModNet connected to the paired oaModTerm (of a different name).

<port_declarations> is specified in Port Declarations (oaModTerms).

<net_declarations> is specified in Net Declarations (oaModNets).

<instance_declarations> is specified in Instance Declarations (oaModInsts).

Port Order

Data imported with verilog2oa can include implicit connections by order and explicit connections by name. verilog2oa stores enough information in the OpenAccess database for oa2verilog to reconstruct the original port ordering. However, oa2verilog always creates connections by name to instantiated modules, even modules that were originally connected by order, unless there is no way to express the connectivity without resorting to port order.

When producing a module interface, oa2verilog outputs the ports according to the following rules:

If a terminal has a position index, the position index is used as the primary sort key.
All terminals that have position indices appear before terminals without position indices.
Terminals that do not have position indices are ordered as follows:
- Scalar terminals are ordered alphabetically.
- Bus terminal bits are ordered first by base name and second by index. The order of the indices depends on the order of the bits on the bus. For example, if the bit order of the bus is descending, then b[7] appears before b[0].
- Scalar and bus terminals are ordered by comparing the scalar name to the base name of the bus. For example:
b[1:0], a, c

Sorts to:

a, b[1], b[0], c

Named Port Connections Versus Ordered Port Connections

The oa2verilog translator attempts to form all connections to module instantiations as named connections regardless of how the connection is actually expressed in the OpenAccess database. It falls back on ordered port connections if the connection cannot be expressed as a named connection in Verilog. When possible, the translator uses the original port names of the master module whether or not the master module was scalarized. Consider the following original Verilog input file:

module example1 ( A1, Z1 );
      input [3:0] A1;
      output Z1;
endmodule 
 
module example2 ( A2[3], A2[2], A2[1], A2[0], Z2 );
      input [3:0] A2;
      output Z2;
endmodule

 

module top ();
      wire [3:0] a2;
      wire  z2;
 
      // Both of these example instances use ordered connections.
      example1 i1 (a2, z2); 
      example2 i2 (a2[3], a2[2], a2[1], a2[0], z2);
endmodule

Whether or not this design is scalarized, oa2verilog generates the following netlist:

module example1 ( A1 , Z1 );
      input [3:0] A1;
      output Z1;
endmodule
 
module example2 ( A2[3], A2[2], A2[1], A2[0], Z2 );
      input [3:0] A2;
      output Z2;
endmodule


module top ();
      wire [3:0] a2;
      wire z2;
 
      // Instance i1 uses named connections because the identifiers A1 and Z1
      // are legal port identifiers.
      example1 i1 (.A1(a2), .Z1(z2));
 
      // Instance i2 uses ordered connections because A2[3], A2[2], A2[1] and
      // A2[0] are not legal port identifiers. 
      example2 i2 (a2[3], a2[2], a2[1], a2[0], z2);
endmodule

If an OpenAccess module is created without using the verilog2oa translator, it can have terminals with names that are not legal port identifiers in Verilog. This commonly occurs when a bit-wise netlist format such as LEF/DEF is used to create leaf cells that have ported busses (the module example2 in a previous example represents this type of connectivity). In such cases, the verilogAnnotate program is used to define the module interface using legal port identifiers. If verilogAnnotate was not used, oa2verilog makes a “best guess” regarding what the interface to the design should be. When guessing, oa2verilog groups the bits of busses together as long as the bits are either monotonically increasing or decreasing.

For example, consider the scenario where LEF/DEF is used to import a design that consists of a ROM macro and a top level cell that instantiates the ROM. Since the ROM is imported from LEF, there is no multi-bit connectivity, and all the bits of the ROM are defined separately. Suppose the ROM terminal bits are A[0], A[1], A[2]… A[7], CLK, B[0], B[1], B[2] … B[7]. When the ROM is instantiated in DEF, the connections to the terminals are also bitwise connections. Suppose net a[0] is connected to terminal A[0], a[1] is connected to A[1], clk is connected to CLK, b0 is connected to B[0], b1 is connected to B[1], and so on.

When oa2verilog produces a netlist for this design, it is assumed that all the A[0…7] terminal bits are grouped together and all the B[0...7] terminal bits are grouped together, so a netlist is produced that looks like the following:

module ROM (A, CLK, B);
    input [7:0] A;
    input CLK; 
    output [7:0] B;
endmodule 

 

module top ();
    wire [7:0] a;
    wire clk; 
    wire b0, b1, b2, b3, b4, b5, b6, b7;
 
    ROM I1 (.A(a[7:0]), .CLK(clk), .B({b7, b6, b5, b4, b3, b2, b1, b0});
endmodule

If this guess is incorrect, use the verilogAnnotate program to define the intended interface to the ROM design.

Note that this feature, when combined with the –leafFile option of oa2verilog, can be used to conveniently produce a Verilog stubs file for use with verilogAnnotate.

Explicit Connections in Port Declarations

oa2verilog can write out ports in an explicit connection format. This is the only way to represent the connection of an oaModTerm to an oaModNet with a different name.

In the following example, oaModNet n1 is connected to oaModTerm p1, oaModNet n2 is connected to oaModTerm p2, and oaModNet net_z is connected to oaModTerm p3. In this example, p1, p2, p3, n1, n2 and z might be scalar names representing busses that will be defined later.

module foo ( .p1(n1) , .p2(n2), .p3(z ) ;
. . . 
endmodule

Port Declarations (oaModTerms)

Port declarations describe the interface signals for a module. For each oaModTerm, a Verilog port is written (unless the oaModTerm is of type oacUnusedTermType). A port can be connected to an internal net with a different name. See Explicit Connections in Port Declarations for more information.

The preferred style for port declarations is one port declaration per line.

<port_declarations> = <portDeclaration>*

Where:

<portDeclaration> = <portType> <range>? <list_of_ports>

Where:

<portType> is a Verilog port type keyword.

<range> = [ <startBit>:<stopBit> ]

Where:

<startBit> and <stopBit> are the start and stop positions of a multi-bit oaBusNet range.

<list_of_ports> = <portName> <,<portName>>*

Where:

<portName> is the name of an oaModTerm.

oaTermTypeEnum to Port Type Mapping

oaTermTypeEnum <oaTermType>	Verilog Port Type Keywords <portType>
oacInputTermType	input
oacOutputTermType	output
oacInputOutputTermType	inout
oacSwitchTermType	input
oacJumperTermType	input
oacUnusedTermType	not mapped
oacTristateTermType	output

Net Declarations (oaModNets)

Net declarations describe the internal signals for a module. Each Verilog net declaration is mapped from the associated oaModNet. There are two types of nets: interface nets (ports) and internal nets. Although Verilog allows implicit declarations of internal nets, it is not recommended.

The oa2verilog translator let's you optionally expand multi-bit nets. By default, all Verilog translators must write multi-bit nets in bus format.

The preferred style for net declarations is one net declaration per line.

<net_declarations> = <netDeclaration>

Where:

<netDeclaration> = <net_type> <range>? <list_of_nets> ;

Where:

<net_type> is a Verilog net type keyword.

<range> = [ <startBit>:<stopBit> ]

Where:

<startBit> and <stopBit> are the start and stop positions of a multi-bit oaBusNet range.

<list_of_nets> = <netName> <,<netName>>*

Where:

<netName> is the name of an oaModNet.

When mapping an oaModScalarNet, oaModBundleNet, or an expanded oaModBusNet, the <range> is not used. When mapping an oaModBusNet there are two options:

Expanding the bus into individual bits and writing them without the range specification.
Writing the bits in a bus format with the range.

Signal Type to Net Type Mapping

oaSignalTypeEnum <oaNetType>	Verilog Net Type Keywords <net_type>
oacPowerSigType	supply1
oacTieHiSigType	supply1
oacGroundSigType	supply0
oacTieLoSigType	supply0
oacTieoffSigType	wire
oacSignalSigType	wire
oacClockSigType	wire
oacAnalogSigType	wire
oacScanSigType	wire
oacResetSigType	wire

In order to map to Verilog keywords other than wire and supply*, additional information is required. Therefore, the tri , wor , trior , wand , triand , trireg , tri1 , and tri0 keywords are not mapped from any oaSignalTypeEnum or other combination of OpenAccess data.

Global nets are output as out-of-module references from the module specified with the global option of oa2verilog. For example, if you specify -global myGlobals on the command line and a global net named clk exists in the OpenAccess database, this net is written as myGlobals.clk wherever it appears in the Verilog netlist. The only exceptions to this rule are the tie high and tie low nets, which (although they are global), are always represented by constant numbers. See Connections to Constants for more information about tie high and tie low nets.

Instance Declarations (oaModInsts)

Instance declarations describe the hierarchy and the structural connectivity for a module. Each Verilog instance declaration is mapped from the associated oaModInst regardless of whether it is a design instance (oaModScalarInst, oaModVectorInst) or a module instance (oaModModuleScalarInst, oaModModuleVectorInst).

There is no requirement on the order of the instance declarations. However, the preferred style is to have a one-to-one correspondence between the module identifier and each declaration of an instance. Verilog allows several instantiations to share the same <module_identifier>, however using this feature is not recommended because it is less readable.

<instance_declarations> = <instanceDeclaration>*

Where:
<instanceDeclaration>= <module_identifier> <module_instance> <,<module_instance>>*

Where:
<module_identifier> is the cellName of the master module of the specified instances.

<module_instance> = <instance_name> <range>? ( <list_of_port_connections>* )

Where:
<instance_name> is always the oaSimpleName of the oaModInst.

Where:
<range> = [ <startBit> : <stopBit> ]

Where:
<startBit> and <stopBit> are the start and stop positions of a multi-bit oaBusNet range.

<list_of_port_connections> = <port_connection> <,<port_connection>>

Where:
<port_connection> = <ordered_port_connection>

Where:
<ordered_port_connection> = <connection_expression>

Or:
<port_connection> = <named_port_connection>

Where:
<named_port_connection> = .<port_identifier> (<connection_expression>)

Where:
<port_identifier> is the name of the oaModTerm of the master module

And:
<connection_expression> = <net_identifier>

Or:
<connection_expression> = <constant_expression>

Where:
<net_ identifier> is the name of the connected oaModNet
<constant_expression> is a Verilog constant such as 1'b1.

verilog2oa does not use or write arrayed instances. This should also hold true for any OpenAccess to Verilog translator implementation.

Connections to Constants

In many designs, certain nets are identified as global tie-offs to either a logical 1 or a logical 0. These nets are called tie high and tie low nets. Nets assigned to tieLo must be marked as either oacTieLoSigType or oacGroundSigType. Nets assigned to tieHi must be marked as either oacTieHiSigType or oacPowerSigType. When translating from OpenAccess to Verilog, using -tieLo * assigns all global nets marked oacTieLoSigType and oacGroundSigType as tieLo, and using -tieHi * assigns all global nets marked oacTieHiSigType and oacPowerSigType as tieHi. When writing a connection that involves one or more of these nets, oa2verilog uses a constant binary number to represent the connection.

The interface to the oa2verilog translator must support a mechanism to specify the names of the tieHigh and tieLow nets. By default, the net named tie0 is assumed to be the tie low net, and the net named tie1 is the tie high net. Any OpenAccess oaNet that matches one of these names is treated as a constant value. If a bus is tied to a bundle that is comprised of the tie low and tie high nets, the connection is to a constant of the form 'b10001010011101... where bundle members of the tie low net become zeros and bundle members of the tie high net become ones.

For example, if net "tie0,2*tie1,tie0" is connected to terminal "a[3:0]" of instance "I1", the module instantiation in the output Verilog file looks like this: "I1(.a('b0110)....)".

Examples

oaModScalarNet Connections

module foo1 ( a , b , z  );
	input a;
	input b;
	output z;
	.
endmodule

module D1 ( A1 , B1 , Z1  );
	input A1;
	input B1;
	output Z1;
	foo1 U1 ( .a( A1), .b(B1), .z(Z1) );
	.
endmodule

oaModBusNet Connections

module foo2 ( a , b , z  );
	input [1:0] a;
	input [3:0] b;
	output [7:0] z;
	.
endmodule

module D2 ( A2 , B2 , Z2 );
	input [1:0] A2;
	input [3:0] B2;
	output [7:0] Z2;
	foo2 U1 ( .a( A2), .b(B2), .z(Z2) );
	.
endmodule

oaModBundleNet Connections and Verilog Concatenations

module D3 ( A3 , B3 , C3 , D3, Z3 );
	input A3;
	input B3;
	input [1:0] C3;
	input [1:0] D3;
	output [7:0] Z3;
	foo2 U1 ( .a( {A3, B3}), .b({C3, D3}), .z(Z3) );
	.
endmodule

End Module Declaration

There is no information required from OpenAccess for the end module declaration. Verilog requires that all module declarations end with the Verilog keyword:

endmodule

Verilog-2001 (IEEE 1364-2001)

oa2verilog does not currently map the Verilog-2001 (IEEE 1364-2001) standard.

Return to top of page