 |
 |
 |
 |
 |
 |
 |
 |
 |
|
|
|
|
|
|
|
|
|
This document describes
If a Verilog construct is listed as not mapped, or if a given Verilog construct is not explicitly described in this document, the OpenAccess verilog2oa translator does not support this feature of the Verilog language. This does not prohibit a different implementation from using or mapping that feature.
Arithmetic expressions (including unary operators) are not mapped. In particular, the verilog2oa translator requires all integers to be unsigned.
This document includes the following sections:
This document uses the following conventions to describe Verilog language features:
<>) 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. bold are literal Verilog keywords or syntax characters. The OpenAccess namespace that maps OpenAccess names to Verilog identifiers is oaVerilogNS.
Verilog Construct |
Mapping Section |
|---|---|
| module, endmodule | Module Declarations |
| input, output, inout | Port Declarations |
| wire, tri, tri0, tri1, triand, trior, wand, wor, supply0, supply1 | Net Declarations |
| reg, int | Register Declarations |
| assign | Net Assignments |
| parameter | Parameter Declarations |
Preprocessor directives (statements that begin with a backtick) are not mapped.
A Verilog module maps to an OpenAccess oaModule. All Verilog modules are added to the same design by default.
The module might be the only module in the design, or it might be an embedded module. The module declaration describes the connectivity interface for the oaModule. This interface is described as a list of ports for the module. A variety of styles for the port list must be handled.
module <moduleName> (<list_of_ports>? ) ; ... endmodule
Where:
<moduleName> is the name of the Verilog module (cell).
<moduleName> corresponds to the cell name of the oaModule (and to the name of the oaDesign if the module is not embedded). The view type will be set to oacNetlist for all designs created by verilog2oa. The view name for the oaModule defaults to netlist.
The name of a library is also required to create an oaModule or an oaDesign . This is supplied with a command-line option.
verilog2oa can build either
In order to build an EMH, the translator must create the oaDesign that will contain the modules before the modules are built. For example:
// Get the library name from the command-line option.
oaScalarName libName(options.getLibName());
// Get the view name from the command-line option.
// The default name is "netlist".
oaScalarName viewName(options.getDefaultViewName());
if (options.buildEMH()) {
// Get the top-level module name as supplied by the customization
// and create a Design to contain all Modules and the topModule
// that will contain the embedded hierarchy.
oaScalarName topModuleName(vns, options.getTopModName());
topDesign = oaDesign::open(libName, topModuleName, viewName,
oacNetlist, 'w');
topModule = oaModule::create(design, cellName);
}
If not building an EMH, the translator creates an oaDesign with a single oaModule for each Verilog module. The following example shows code to support either mode. (This example assumes that the top-level oaDesign and oaModule have already been created as shown in the previous example.)
// Get the Cell name from the oaString that represents the name of
// the Verilog module.
oaScalarName cellName(vns, verilogModuleName);
// Create the new Module in a separate Design or in the Design of
// the top Module, depending on the mode.
oaDesign *design;
if (options.buildEMH()) {
design = topDesign;
} else {
design = oaDesign::open(libName, cellName, viewName,
oacNetlist, 'w');
}
oaModule *module = oaModule::find(design, cellName);
if (!module) {
module = oaModule::create(design, cellName);
}
The <list_of_ports> in the module declaration can be one of the following:
module <moduleName> (<list_of_ports>? );
...
endmodule
Where:
<list_of_ports> = <portInterface><,<portInterface>>>*
Where:
<portInterface> = <portName>
Where:
<portName>is the name of the Verilog port.Or:
<portInterface> = .<portName>(<netName>)Where:
<portName>is the name of the Verilog port.
<netName>is the name of the net to connect to the port.
Or:
<list_of_ports> = <portSpecification><,<portSpecification>>*
Where:
<portSpecification> = <portType> <netType>? <range>? <portName><,<portName>>*Where:
<portType>is a Verilog port type keyword: input, inout, or output.
<netType>is a Verilog net type keyword (see the Net Type Mapping table.)<range> = [ <startBit>:<stopBit> ]Or:
<range> = [ <singleBit> ]
<portName>is the name of the Verilog port.
module simple (a, b); input a; output [1:0] b; endmodule
|
oaTerm |
oaTermType |
oaNet |
|
a |
oacInputTermType |
a |
|
b [1:0] |
oacOutputTermType | b[1:0] |
module ansi (input a, output [1:0] b); endmodule
|
oaTerm |
oaTermType |
oaNet |
|
a |
oacInputTermType |
a |
|
b [1:0] |
oacOutputTermType | b[1:0] |
module same (.a(i), .b(i)); input i; endmodule
|
oaTerm |
oaTermType |
oaNet |
|
a |
oacInputTermType |
i |
|
b |
oacInputTermType | i |
module rename (.a({b,c}), f, .g(h[1]));
input b,c;
input f;
output [7:0] h;
endmodule
|
oaTerm |
oaTermType |
oaNet |
Notes |
| a[1:0] | oacInputOutputTermType | b,c | The width of "a" is determined by the number of bits in the b,c bundle. |
| b | |||
| c | |||
| f | oacInputTermType | f | |
| g | oacInputOutputTermType | h[1] | This is the only bit of h that is ported. |
| h[7:0] | The individual bits (h[7], h[6], h[5], and so forth ... ) can also exist as separate nets. |
The <portInterface> styles above, as found in Verilog-1995 (IEEE 1364-1995), do not provide sufficient information for mapping module ports to oaModTerms, so the oaModTerms must be created later as described in Port Declarations.
The <portInterface> style lets you optionally declare in parentheses a net with a different name than the associated port. This indicates that the named net is to be the oaModNet that is connected to the oaModTerm created for that Verilog port. This is referred to as an explicit connection and is how Verilog can connect a net to a port with a different name. The association of the <netName> with the <portName> must be stored until the oaModTerm is created. You can use this syntax to connect the same net to several different terminals.
The <portSpecification> style, sometimes referred to as an ANSI-style port list, is allowed in Verilog-2001 (IEEE 1364-2001). This style includes sufficient range and port type information to create each oaModTerm and its paired oaModNet of the same name in the oaModule. For more information about mapping Verilog ports to OpenAccess objects, see Port Declarations.
verilog2oa supports implicit connections by order and explicit connections by name. Ports are arranged in the order they are listed in <list_of_ports>. The <list_of_ports> can contain the same port listed multiple times, and it can have gaps in the port list. In these cases, verilog2oa generates a unique name for a terminal at the position of each gap. For example:
module complex_ports(a, a, , c);
endmodule;
Becomes
module complex_ports(.a(a), ._oaVerilogIn1_a(a), ._oaVerilogIn2_(_oaVerilogIn2_), .c(c));
Generated terminals used to represent gaps are connected to nets that have no connectivity within the module.
You can place Verilog port declarations inside the module declaration when using Verilog-2001 (IEEE 1364-2001). See Module Declarations for more information. Otherwise, you need to specify the necessary details of the ports in a port declaration section after the module declaration according to the Verilog-1995 (IEEE 1364-1995) standard.
<port_declarations> = <portDeclaration><;<portDeclaration>>* ;
Where:
<portDeclaration> = <portType> <range>? <portName><,<portName>>*
Where:
<portType>is a Verilog port type keyword: input, inout, or output.
<range>= [<startBit>:<stopBit>]Or:
<range> = [ <singleBit> ]
<portName>is the name of the Verilog port.
Each Verilog port maps to an oaModTerm. OpenAccess requires that an oaModNet be created for each oaModTerm. Unless you explicitly connect to a net with a different name, the paired oaModNet has the same name as its associated oaModTerm.
If you specify a <range>, both the oaModNet and oaModTerm use the same <range>, and an oaModBusNet and oaModBusTerm are used. Verilog supports multidimensional arrays, but OpenAccess does not. Multidimensional arrays are explicitly not mapped.
<portType> is used to select the <oaTermType> for the oaModTerm. The following table shows the mapping of input, output, and inout keywords.
|
Verilog Port Type Keyword <portType> |
oaTermTypeEnum <oaTermType> |
|
input |
oacInputTermType |
|
output |
oacOutputTermType |
|
inout |
oacInputOutputTermType |
OpenAccess requires that all bits of a given port have the same direction. If the Verilog declares a different direction for different bits, the translator emits a warning and picks a single direction to apply to the OpenAccess terminal.
The translator creates the names for the oaModTerm and its oaModNet first. Unless there is an explicit connection, <netName> is the same as <portName>.
oaScalarName termName(vns, portName); oaScalarName netName(vns, netName);
When the port and associated net have no <range>, an oaModScalarNet and oaModScalarTerm are created.
oaModScalarNet *net = oaModScalarNet::create(module,
netName);
oaModScalarTerm *term = oaModScalarTerm::create(net,
termName,
<oaTermType>);
When you specify a <range>, an explicit oaModBusNetDef (or oaModBusTermDef) is created, and the direction of the range is recorded as either oacAcendingBitOrder or oacDescendingBitOrder, dependent on whether the bits of the range are ascending or descending. Although OpenAccess supports declaring bus ranges that are independent of the bit order of the bus def, the Verilog translator generates an error if the bits of a port are used inconsistently.
oaModBusNetDef *netDef = oaModBusNetDef::create(module,
baseName,
oacDescendingBitOrder);
oaModBusNet *net = oaModBusNet::create(module,
netName,
startBit,
stopBit,
1);
oaModBusTermDef *termDef = oaModBusTermDef::create(module,
baseName,
oacDescendingBitOrder);
oaModBusTerm *term = oaModBusTerm::create(net,
termName,
<oaTermType>,
startBit,
stopBit,
1,
oacSymbolicRouteMethod);
if (startBit < stopBit) {
netDef->setBitOrder(oacAscendingBitOrder);
termDef->setBitOrder(oacAscendingBitOrder);
}
If you specify only a <singleBit>, a single oaModBusNet and a single oaModBusTerm are created:
oaModBusNet *net = oaModBusNet::create(design, netName, <singletBit>); oaModBusTerm *term = oaModBusTerm::create(net, termName, <oaTermType>, <singleBit>);
Finally, the port declaration for a multi-bit port might not include a <range> specification if the subsequent declaration of the associated net has a range. This can occur if the associated net (the owner oaModBusNet) has the same name or a different name that was specified explicitly. The resulting oaModTerm must be an oaModBusTerm in such cases. This case does not change the mapping, but it might affect the implementation choices when using the API methods.
For example, in the following case, p1 is an 8-bit port.
module foo (.p1(x)); inout [7:0] x; endmodule
The Verilog net (or wire) maps to the OpenAccess oaModNet.
<net_declarations> = <netDeclaration><;<netDeclaration>>* ;
Where:
<netDeclaration> = <sigType> <range>? <netName><,<netName>>*
Where:
<sigType> = <netType>Where:
<netType>is a Verilog net type keyword from the Net Type Mapping table.Or:
<sigType> = <dataType>Where:
<dataType>is a Verilog data type keyword from the Data Type Mapping table.And:
<range> = [ <startBit>:<stopBit> ]Or:
<range> = [ <singleBit> ]And:
<netName>is the name of the Verilog net.
The <netType> specifications in structural Verilog are associated with the oaSigTypeEnum class as follows.
|
Verilog Net Type Keywords <netType> |
oaSigTypeEnum <oaSigType> |
|
wire |
oacSignalSigType |
|
supply1 |
oacTieHiSigType |
|
supply0 |
oacTieLoSigType |
The <dataType> declarations in structural Verilog are also associated with the oaSigTypeEnum class.
|
Verilog Data Type Keywords <dataType> |
oaSigTypeEnum <oaNetType> |
|
reg, tri, triand, trior, tri0, tri1, wand, wor |
oacSignalSigType |
Verilog functional primitives, such as transistors and gates, do not map to the current OpenAccess information model. However, a single-bit register declaration can be handled with oaModNet. An integer declaration can be handled with an oaModBusNet with range of [31:0] (or 32 one-bit bus nets with indices ranging from 31 down to 0 if multi-bit nets are expanded). See Net Declarations for information on how to create these net objects.
|
Verilog Keywords |
OpenAccess DB object(s) |
|
reg |
oaModNet |
|
int |
oaModBusNet[31:0] |
|
cmos, rcmos, bufif0, bufif1, notif0, notif1, |
not mapped |
Verilog signal concatenations are very similar to OpenAccess bundled nets. Even though the oaVerilogNS namespace does not directly support the Verilog concatenation syntax, verilog2oa maps these signal concatenations to oaModBundleNets and oaModBundleTerms. A Verilog multi-concatenation is expanded by repeating the listed signals the number of times specified by the integer multiplier in the concatenation. The mapping only supports an integer-constant value for this multiplier and does not map more general expressions.
<netSignal_concatenation> = { <netName><,<netName>>* }
Or:
<netSignal_concatenation> = {<multiplier> { <netName><,<netName>>* }}
Where:
<multiplier>is an integer constant (general multiplier expressions are not mapped).
For example:
{4 {a, b, c} } maps to "a,b,c,a,b,c,a,b,c,a,b,c"
Concatenations may be nested:
{ 2 { { 3 { a, b } }, c } } maps to "a,b,a,b,a,b,c,a,b,a,b,a,b,c"
Verilog can express multi-dimensional ranges by specifying a multi-bit range in the <range> declaration and in the <netName> specification. For example, the following wire declaration specifies a two-dimensional range with a total of 16 bits.
wire [7:0] a[1:0];
However, such Verilog multi-dimensional ranges are not mapped to the OpenAccess database.
Note: The Verilog int keyword maps to a 32-bit range, so ranges of int are not mapped.
Nets can be assigned to other nets with the same range. Net assignment is implemented as net equivalence in OpenAccess.
assign <sigName1> = <sigName2>
Where:
<sigName1> and <sigName2> are previously declared Verilog nets or ports.
For example, the Verilog statement assign netA = netB is mapped to the following:
netA->makeEquivalent(netB);
Assignment to an expression is not mapped to OpenAccess, but assignment to a number or a concatenation of literal numbers is mapped:
assign b = a + c; // Not mapped
assign b = 1'b1; // OK
wire [31:0] c;
assign c = 32'h80000000; // OK
wire [63:0] d;
assign d = {2{{4{4'b1001}}, {2{2'b01}}}}; // OK
wire [63:0] f;
assign f = 64’hfedcba9876543210; // OK
See Numerical Constants as Global Nets for information about how to map a number value to a net. See Signal Concatenations for information about how to map a concatenation to a signal name.
When a constant value is assigned to a net, the net is made equivalent to the global tieHigh (or tieLow) signal. This is not the same as declaring the net as a supply1 or a supply0. Declaring a net as supply1 or supply0 does not change the global state of the net nor does it make it equivalent to any other net. Assigning a constant value to a net does make the net equivalent to a global tieHigh net.
For example
module sample(vcc);
output vcc;
wire x;
supply1 vcc; // vcc is a local signal with oacTieHiSigType.
assign x = 1’b1; // x is equivalent to the global tie1 signal with
// oacTieHiSigType. vcc is not equivalent to x
// or to tie1.
endmodule
There are different ways to express a connection to a tieHi or tieLo signal in Verilog. The signal can be declared as a supply1, or a continuous assignment can be made to a 1’b1 constant. However, there are subtle differences between these expressions, and it is worthwhile to understand how each expression maps to the OpenAccess model. Consider the following input Verilog:
module top();
supply1 VCC;
wire y;
assign y = 1’b1;
mid I1(.A(y));
mid I2(.A(VCC));
mid I3(.A(1’b1));
endmodule
module mid(A);
input A;
supply1 VCC;
wire x;
assign x = 1’b1;
BUF I4(A);
BUF I5(x);
BUF I6(VCC);
BUF I7(1’b1);
endmodule
In the module domain, this produces the following nets:
| Module top | |||
|---|---|---|---|
| Net Name | sigType | isGlobal | Equivalences |
| VCC | tieHi | no | |
| y | signal | no | tie1 |
| tie1 | tieHi | yes | y |
| Module mid | |||
|---|---|---|---|
| Net Name | sigType | isGlobal | Equivalences |
| A | signal | no | |
| VCC | tieHi | no | |
| x | Signal | no | tie1 |
| tie1 | tieHi | yes | x |
In the block domain of the same design, there will be:
| Block | |||
|---|---|---|---|
| Net Name | sigType | isGlobal | Equivalences |
| VCC | tieHi | no | |
| y | signal | no | I3/x, I2/x, I1/x, tie1 |
| tie1 | tieHi | no | y, I3/x, I2/x, I1/x |
| I1/VCC | tieHi | no | |
| I2/VCC | tieHi | no | |
| I3/VCC | tieHi | no | |
| I1/x | signal | no | tie1, y, I3/x, I2/x |
| I2/x | signal | no | I1/x, tie1, y, I3/x |
| I3/x | signal | no | I2/x, I1/x, tie1, y |
Notes:
1’b1 become usages of a global tieHi net named tie1 in OpenAccess.1’b1 continuous assignments (such as I1/x and y) retain their original signal sigType.1’b1 continuous assignments (such as I1/x and y) are equivalent nets in the block domain.
oaNet::getInstTerms(oacInstTermIterNotImplicit | oacInstTermIterEquivNets)
oaNet::getTerms(oacTermIterNotImplicit | oacTermIterEquivNets)
The specification of hierarchical connectivity in Verilog uses the module instantiation construct.
<moduleName> <instanceName> <instRange>? <list_of_connections>;
Where:
<moduleName> is the name of the master cell for the Verilog instance.
<instanceName> is the name of the Verilog instance.
<instRange> = [ <startPart> : <stopPart> ]
<list_of_connections> = (<connection <,<connection>>*)
Where:
<connection> = <netSignal>,which is an implicit connection by port order.Where:
<netSignal> = <netName> <range>?Where:
<range> = [ <startBit> : <stopBit> ]Or:
<range> = [ <singleBit> ]Or:
<connection> = .<masterPortName> (<netSpec>?), which is an explicit connection.Where:
<masterPortName>is the identifier of the port in the master Verilog module.<netSpec> = <netSignal>Or:
<netSpec> = <netSignal_concatenation>as specified in Signal Concatenations.
The <moduleName> refers to the master module of the hierarchical child, and the <instanceName> identifies this instantiation of the master module. Module instantiations can be design instances (oaModInst) or module instances (oaModModuleInst).
For example, the following code creates a scalar module instantiation while building an EMH:
// Get the module that is being instantiated.
oaModule *master = oaModule::find(topDesign, moduleName);
if (!master) {
// Code to find leaf cells or create forward references
// goes here. When this code returns, the master will refer
// to an actual oaModule.
}
// Create an instance of this module in the currentModule.
// The instance name is taken from the Verilog input.
oaModInst *inst = oaModModuleScalarInst::create(currentModule,master, instName);
When explicit connectivity is specified with the instance, <masterPortName> refers to the name of the oaModInstTerm associated with the oaModTerm with the same name in the master module. When implicit connectivity by port order is used, <masterPortName> is omitted, and <netSpec> identifies the oaModNets to which the oaModInstTerm is connected. Each <netSignal> can describe scalar, bus, or bundle nets. A <netSignal> can be blank in the implicit connection style to indicate that there is no connection at the given position of the ordered connection. The <netSpec> can be a numerical constant such as 1'b1 (see Numerical Constants as Global Nets ).
If no <netSignal> is connected to <masterPortName> (the oaModInstTerm), the oaModNet is created. This is an implicit net declaration, and the type is derived from the oaModTerm that the connected oaModInstTerm references in the master Module of the instance.
verilog2oa might require access to an OpenAccess database for each module instantiated. The information in the database is needed to determine port ordering, port width, bus-bit ordering, and so forth.
Modules instantiated as references to external designs are called leaf cells, and users might be required to supply information needed to find these cells.
The Verilog language does not specify library and view names for modules or module instantiations. By default, verilog2oa creates module instances of modules (internal to the design being created) so library and view names are not necessary. However, there are some circumstances when references to external designs are appropriate—for example, when creating leaf cells with lef2oa and then instantiating those leaf cells with verilog2oa.
When a Verilog module is instantiated, each library in the library list is searched for a cell with the same name as the Verilog module. If such a cell is found, the module being instantiated is considered a leaf cell and the module is instantiated as a design instance. The first view of the leaf view list that exists for that cell is chosen as the view for the instantiation. If no view exists, the instantiation is still considered a leaf, (and the view selected is the first view in the leaf view list).
Leaf cells that are found in these libraries are given preferential treatment over module definitions in the Verilog input. Neither the module definition of the leaf cell nor any modules used exclusively by leaf cells appear in the output design.
In some cases, a leaf cell has insufficient information to be used in a Verilog module instantiation. For example, the leaf cell might lack terminal ordering information and the Verilog module instantiation might use connection by order. In this case, if a Verilog module definition does exist for this leaf cell , the Verilog module will supply any required information missing from the leaf cell if there are no inconsistencies to prevent this. Regardless of whether or not there is a Verilog module definition for a leaf cell, the leaf cell in the leaf library is the cell that is instantiated (as a Design instance).
For leaf cells with Verilog definitions, verilog2oa also checks their interfaces against the Verilog definition. It is an error if the Verilog definition contains terminals that are not part of the leaf cell. It is an error if the leaf cell specifies terminal order and that order is different than the terminal order specified in the Verilog input. It is not an error if the Verilog definition omits terminals that are part of the leaf cell.
It is also possible to specify that all instances should be Design instances by using the designPerMod option. When you use this option, all Verilog modules are created as separate oaDesigns and all Verilog module instantiations become design instances. The same rules for leaf selection still apply, so Verilog instances that are leaf cells always refer to the same oaDesign regardless of whether or not the designPerMod option is used. (See verilog2oa Translator for more information.)
verilog2oa searches for leaf cells using the following rules:
Stub references occur when a module is instantiated and there is no definition for the module either as a leaf cell or as a module in the Verilog input. When this occurs, verilog2oa creates an unbound module design instance. The terminal interface to the stub is assumed to be the union of all module instantiations of the stub. Different module instantiations can connect to different terminals of
the stub. Because the presence of stub modules usually indicates an incomplete specification, and
because the connectivity to the stub is prone to error, a warning is displayed
if stub modules are present.
Some assumptions are made for stub modules. Bus ranges are assumed to be descending, and the widths of all connections to stub ports are assumed to be exact.
When explicitly connecting hierarchically by name, both the net name and the child's port name are supplied by the input Verilog. The only special consideration is that scalar names can refer to either of the following:
When a scalar name is used to represent a ported bus, the master Module of the child instance might be used to determine the order and specific range of the bus terminal. If the instance is not bound, the master Module can be a leaf cell or a forward reference, and verilog2oa must store the information and resolve the binding when appropriate.
For example, when a scalar net is connected to a scalar term of a scalar instance, the code to create the explicit connectivity might look like this:
oaModInst *inst = oaModModuleScalarInst::find(module, instName); oaModule *master = inst->getMasterModule(); oaModNet *net = oaModScalarNet::find(module, netName); oaModTerm *term = oaModScalarTerm::find(master, termName); oaModInstTerm *iterm = oaModInstTerm::create(net, inst, term);
The Port Order section described how to record the position of terminals. When connections by order are needed, the port ordering information in the master Module of the instance is used to get the correct terminal name, which is then used to create the connecting oaModInstTerm. Again, if the instance is not bound, the master Module may be a leaf cell or a forward reference, and verilog2oa must store the information and resolve the binding when appropriate.
Multi-bit connectivity in the input Verilog is preserved as much as possible during translation. If scalar connectivity is required by a downstream application, that application should call oaDesign::scalarize() on the database produced by the Verilog translator. However, there are circumstances when the OpenAccess multi-bit semantic needs to be mapped to the Verilog multi-bit semantic. This mapping is required when:
For example, the following Verilog input with a scalar net, w , and bus net, y
module child (inout a, inout [1:0] b);
endmodule
module top ();
wire w;
wire [3:0] y;
child I1[1:0] (.a(w), .b(y));
endmodule
maps to an OpenAccess representation where:
oaModScalarNet w is connected to oaModScalarTerm a of inst I1[1] oaModScalarNet w is connected to oaModScalarTerm a of inst I1[0] oaModBusNet y[3:2] is connected to oaModBusTerm b[1:0] of inst I1[1] oaModBusNet y[1:0] is connected to oaModBusTerm b[1:0] of inst I1[0]
Example 2, given the following Verilog input with a bus net, x
module child (inout [8:5] a); endmodule module top (); wire [3:0] x; child I1 (.a(x)); endmodule
maps to an OpenAccess representation where:
oaModBusNet x[3] is connected to oaModBusTerm a[8] of inst I1 oaModBusNet x[2] is connected to oaModBusTerm a[7] of inst I1 oaModBusNet x[1] is connected to oaModBusTerm a[6] of inst I1 oaModBusNet x[0] is connected to oaModBusTerm a[5] of inst I1
Example 3, given the following Verilog input with a bus net, x
module child (inout [3:0] a);
endmodule
module top ();
wire [7:0] x;
child I1 (.a(x));
endmodule
maps to an OpenAccess representation where:
oaModBusNet x[3:0] is connected to oaModBusTerm a[3:0] of inst I1
A warning is printed.
Example 4, given the following Verilog input with a bus net, x
module child (inout [3:0] a);
endmodule
module top ();
wire [1:0] x;
child I1 (.a(x));
child I2 (.a(x));
endmodule
maps to an OpenAccess representation where:
oaModBundleNet {UNCONNECTED_oaVerilog0_[1:0], x[1:0]} is connected to oaModBusTerm a[3:0] of inst I1
oaModBundleNet {UNCONNECTED_oaVerilog1_[1:0], x[1:0]} is connected to oaModBusTerm a[3:0] of inst I2
A warning is printed.
Some Verilog code implements global nets as follows:
module globals;
wire gwire;
endmodule
module local;
child m1(globals.gwire);
endmodule
Here, the port of the m1 instance should connect to the gwire wire in the globals. module. Global nets are the only type of hierarchical connections that must be mapped. Nets that are identified as global are set global using oaModNet::setGlobal(), and the hierarchical portion of the name (globals.) is discarded. By convention, a module named globals is assumed to be a repository for global nets, and all nets found in this module are declared global. Other Verilog to OpenAccess translators should provide a mechanism to optionally specify the names of global nets.
Numerical constants map to global nets. By default, 1'b1 maps to a global net named tie1, and 1'b0 maps to a global net named tie0. Numerical constants that consist of multiple bits map to concatenations of these nets. For example, 3'b101 maps to {tie1,tie0,tie1}. The Verilog translator that is distributed with OpenAccess does not restrict the number of bits that may be used with binary, hexadecimal or octal numerical constants. A different Verilog to OpenAccess translator might restrict the number of bits allowed in numbers to some reasonable value like 32. However, even with this restriction, connections using a larger number of bits are still possible. For example, a 64-bit bus can be assigned without violating the 32-bit restriction on numbers:
wire [63:0] bus;
assign bus = {32'h80000000, 32'h00000001};
Parameters are not mapped to properties, OpenAccess extensibility classes, or Pcells in OpenAccess, but they can be used in the construction of oaModNets, oaModTerms, and oaModInsts. Parameter names are evaluated only if they are used in the module in which they are declared. Even then, only the default values of the parameters are used. Parameter overrides are not mapped.
parameter <assignment> <,<assignment>>*;
Where:
<assignment> = <paramName>=<paramValue>
Copyright © 2004-2010 Cadence Design Systems, Inc.
All rights reserved.