6. Hierarchical structures

6.1 Overview

Verilog-AMS HDL supports a hierarchical hardware description by allowing modules to be embedded within other modules. Higher-level modules create instances of lower-level modules and communicate with them through input, output, and bidirectional ports. These module input/output (I/O) ports can be scalar or vector.

Verilog-AMS HDL provides a mechanism to customize the behavior of embedded modules using parameters. The embedded module parameter default value can be modified through a higher-level module’s parameter override or a hierarchy independent defparam statement.

To describe a hierarchy of modules, the user provides textual definitions of various modules. Each module definition stands alone; the definitions are not nested. Statements within the module definitions create instances of other modules, thus describing the hierarchy.

6.2 Modules

A module definition shall be enclosed between the keywords module and endmodule, as shown in Syntax 6-1. The identifier following the keyword module shall be the name of the module being defined. The optional list of parameter definitions shall specify an ordered list of the parameters for the module. The optional list of ports or port declarations shall specify an ordered list of the ports of the module. The order used in defining the list of parameters in the module_parameter_port_list and in the list of ports can be significant when instantiating the module (see 6.2.2). The identifiers in this list shall be declared in input, output, or inout declaration statements within the module definition. Ports declared in the list of port declarations shall not be redeclared within the body of the module. The module items define what constitutes a module, and they include many different types of declarations and definitions, many of which have already been introduced.

A module definition may have multiple analog blocks. The behavior of multiple analog blocks shall be defined by assuming that the multiple analog blocks internally combine into a single analog block in the order that the analog blocks appear in the module description. In other words, they are concatenated in the order they appear in the module. Concurrent evaluation of the multiple analog blocks is implementation dependent as long as the behavior in that case is similar to what would happen if they had been concatenated.

A module can have a description attribute, which shall be used by the simulator when generating help messages for the module.

The keyword macromodule can be used interchangeably with the keyword module to define a module. An implementation may choose to treat module definitions beginning with the macromodule keyword differently.

module_declaration ::= // from A.1.2 { attribute_instance } module_keyword module_identifier [ module_parameter_port_list ]

list_of_ports ; { module_item } endmodule

| { attribute_instance } module_keyword module_identifier [ module_parameter_port_list ] [ list_of_port_declarations ] ; { non_port_module_item }

endmodule

port_declaration ;

| non_port_module_item

module_or_generate_item ::=

{ attribute_instance } module_or_generate_item_declaration | { attribute_instance } local_parameter_declaration ;

| { attribute_instance } parameter_override | { attribute_instance } continuous_assign | { attribute_instance } gate_instantiation | { attribute_instance } udp_instantiation

| { attribute_instance } module_instantiation | { attribute_instance } initial_construct

| { attribute_instance } always_construct

| { attribute_instance } loop_generate_construct

| { attribute_instance } conditional_generate_construct | { attribute_instance } analog_construct

module_or_generate_item_declaration ::= net_declaration

| reg_declaration

| integer_declaration | real_declaration

| time_declaration

| realtime_declaration | event_declaration

| genvar_declaration | task_declaration

| function_declaration | branch_declaration

| analog_function_declaration

non_port_module_item ::= module_or_generate_item

| generate_region | specify_block

| { attribute_instance } parameter_declaration ; | { attribute_instance } specparam_declaration | aliasparam_declaration

parameter_override ::= defparam list_of_defparam_assignments ;

Syntax 6-1—Syntax for module

6.2.1 Top-level modules

Top-level modules are modules that are included in the source text, but do not appear in any module instantiation statement, as described in 6.2.2. This applies even if the module instantiation appears in a generate block that is not itself instantiated (see Syntax 6.6).

6.2.2 Module instantiation

Instantiation allows one module to incorporate a copy of another module into itself. Module definitions do not nest. That is, one module definition does not contain the text of another module definition within its module...endmodule keyword pair. A module definition nests another module by instantiating it. The module instantiation statement creates one or more named instances of a defined module.

Syntax 6-2 gives the syntax for specifying instantiations of modules.

Syntax 6-2—Syntax for module instantiation

The instantiations of modules can contain a range specification. This allows an array of instances to be created.

One or more module instances (identical copies of a module definition) can be specified in a single module instantiation statement.

The list of module connections shall be provided only for modules defined with ports. The parentheses, however, are always required. When a list of port connections is given using the ordered port connection method, the first element in the list shall connect to the first port declared in the module, the second to the second port, and so on. See 6.5 for a more detailed discussion of ports and port connection rules.

A connection can be a simple reference to a variable or a net identifier, an expression or a blank. An expression can be used for supplying a value to a module input port if it is a digital port. A blank port connection shall represent the situation where the port is not to be connected.

When connecting ports by name, an unconnected port can be indicated either by omitting it in the port list or by providing no expression in the parentheses [i.e., .port_name ()]

The example below illustrates a comparator and an integrator (lower-level modules) which are instantiated in sigma-delta A/D converter module (the higher-level module).

module comparator(cout, inp, inm); output cout;

input inp, inm;

electrical cout, inp, inm;

parameter real td = 1n, tr = 1n, tf = 1n; real vcout;

analog begin

@(cross(V(inp) - V(inm), 0))

vcout = ((V(inp) > V(inm)) ? 1 : 0); V(cout) <+ transition(vcout, td, tr, tf);

end endmodule

module integrator(out, in); output out;

input in; electrical in, out;

parameter real gain = 1.0; parameter real ic = 0.0; analog begin

V(out) <+ gain*idt(V(in), ic); end

endmodule

module sigmadelta(out, aref, in); output out;

input aref, in; ground gnd;

comparator C1(.cout(aa0), .inp(in), .inm(aa2)); integrator #(1.0) I1(.out(aa1), .in(aa0)); comparator C2(out, aa1, gnd);

d2a #(.width(1)) D1(aa2, aref, out); // a D/A converter endmodule

The comparator instance C1 and the integrator instance I1 in Figure 6-1 use named port connections, whereas the comparator instance C2 and the d2a (not described here) instance D1 use ordered port connections. Note the integrator instance I1 overrides gain parameter positionally, whereas the d2a instance D1 overrides width parameter by named association.