SystemVerilog Design Hierarchy Enhancements

SystemVerilog introduces numerous extensions to Verilog that significantly improve how designers represent and work with hardware design hierarchy. This article explores the key constructs that enable more efficient modeling of complex digital systems, from module prototypes to parameterized types.

Module Prototypes

In traditional Verilog, compiling module instances presents challenges for tool developers. When a module instance appears in the design, the compiler must locate and parse the complete module definition to determine port count, types, dimensions, and ordering. This requirement complicates compilation tools and increases processing overhead.

SystemVerilog addresses this by supporting module prototypes declared with the extern keyword. These prototypes provide advance information about module ports, enabling compilers to process instances more efficiently. The prototype declaration can use either the older Verilog-1995 style or the more expressive Verilog-2001 format that includes parameter definitions and port type specifications.

Consider this prototype example demonstrating both declaration styles:

// Prototype using legacy Verilog-1995 declaration style
extern module counter (count_out, data_input, clk, reset_n);

// Prototype using modern Verilog-2001 declaration style
extern module counter #(parameter WIDTH = 15)
                       (output logic [WIDTH:0] count_out,
                        input wire [WIDTH:0] data_input,
                        input wire clk, load_enable, reset_n);

Beyond compilation benefits, prototypes serve important documentation purposes. Large designs spanning multiple files can benefit from having module prototypes placed alongside instances, reducing the need to search through numerous files to understand interface requirements.

Scope visibility rules govern prototype accessibility. An extern module declaration exists within its containing scope, whether that is a module, interface, or the compilation unit ($unit) space. Declarations placed at the $unit level remain visible to all modules sharing that compilation space, effectively providing global accessibility.

A notable characteristic of prototypes is the ordering flexibility they provide. Unlike some language constructs, extern declarations need not precede their corresponding module instances within the source code.

Prototype and Definition Consistency

SystemVerilog enforces strict matching between extern prototype declarations and actual module definitions. The port lists must correspond exactly in terms of port names, ordering, dimensions, and types. Any discrepancy between the prototype and definition results in a compilation error, ensuring interface consistency throughout the design.

Eliminating Port Declaration Redundancy

SystemVerilog offers a useful shorthand mechanism to avoid repeating port declarations when a prototype exists. The .* wildcard in the module port list instructs tools to automatically populate port declarations from the extern prototype. This approach eliminates duplicate declarations while maintaining design clarity.

extern module counter #(parameter WIDTH = 15)
                       (output logic [WIDTH:0] count_out,
                        input wire [WIDTH:0] data_input,
                        input wire clk, load_enable, reset_n);

module counter ( .* );
    always @(posedge clk, negedge reset_n) begin
        if (!reset_n) count_out <= 0;
        else if (load_enable) count_out <= data_input;
        else count_out <= count_out + 1;
    end
endmodule

Named Ending Statements

As designs grow in complexity, source code readability becomes increasingly important. Nested module definitions create situations where multiple endmodule keywords appear in close proximity, potentially causing confusion about which module each closing statement terminates.

SystemVerilog allows explicit naming of closing statements using the endmodule : name syntax. This naming convention creates self-documenting code that clearly associates each module end with its corresponding beginning. The named closing statement must use the exact module name for proper association.

Beyond modules, SystemVerilog extends this naming capability to other code block constructs including packages, interfaces, tasks, functions, and begin-end blocks. This enhancement proves particularly valuable in verification codebases where complex procedural blocks frequently require clear delineation.

Nested Module Declarations

Verilog traditionally treats all module names as globally accessible throughout the design hierarchy. While this approach provides straightforward instantiation capabilities, it introduces several significant challenges for large-scale designs and intellectual property reuse.

Global Namespace Limitations

Verilog's global namespace model presents two primary difficulties. First, it provides no mechanism for restricting module access. When an IP core contains internal submodule definitions, those submodule names become globally visible and could potentially be instantiated by unrelated portions of the design, compromising the encapsulation principles that IP vendors require.

Second, global namespace visibility creates potential naming conflicts. When multiple IP providers deliver modules with identical names such as fsm, name collisions occur in the global scope, requiring modification to either the IP source code or the instantiation context. While Verilog-2001 configurations provide some relief for duplicate module name conflicts, these constructs remain verbose and do not address access restriction requirements.

Nested Module Definition Solution

SystemVerilog introduces nested module definitions as an elegant solution to both namespace control and naming conflict avoidance. A module definition can be contained entirely within its parent module, creating a hierarchical namespace that limits accessibility and prevents external conflicts.

module system_top (input wire clk);
    dff i1 (clk);
    processor i2 (clk);
endmodule : system_top

module dff (input wire clk);
    // DFF implementation
endmodule : dff

module processor (input wire clk);
    sub_unit u1 (...);
    sub_unit u2 (...);
    
    module sub_unit (...); // Nested module definition
        // Sub-unit implementation
    endmodule : sub_unit
endmodule : processor

In this example, sub_unit exists only within processor's namespace. The same module name could be defined in other parts of the design without conflict, and external modules cannot directly instantiate the nested module.

File Organization Considerations

Nested module definitions can span multiple source files using the ``include` compiler directive, promoting maintainability while preserving namespace benefits:

module processor (input logic clk);
    // Processing logic
    
    `include "sub_unit_one.v"
    `include "sub_unit_two.v"
    
endmodule

module sub_unit_one (...); // Contained in sub_unit_one.v
    // Implementation
endmodule

module sub_unit_two (...); // Contained in sub_unit_two.v
    // Implementation
endmodule

Nested Module Name Visibility and Instantiation

Nested module names reside in their parent module's namespace rather than the global namespace. This localization means nested modules can share names with globally defined modules without conflict.

Visibility restrictions limit nested module instantiation to the parent module and its descendants in the hierarchy tree. A nested module cannot appear in an unrelated portion of the design, providing strong encapsulation guarantees.

Nested modules maintain standard hierarchical path capabilities. Variables, nets, and other declarations within nested modules remain accessible through hierarchical references for verification and debugging purposes.

A nested module can instantiate other modules from three possible namespaces: the global module namespace, its parent's namespace, or other nested modules within itself. This flexibility supports hierarchical design patterns while maintaining clear namespace boundaries.

Instantiation syntax for nested modules mirrors that of regular modules, with the restriction that they can only be instantiated within their parent hierarchy or below. The following example demonstrates nested modules instantiated at different hierarchy levels:

module processor (input clk);
    stage_one inst_a (...); // Nested module instance

    module stage_one (...); // Nested module definition
        stage_two inst_b (...);
        // Additional logic
    endmodule : stage_one
    
    module stage_two; // Nested module definition
        stage_three inst_c (...);
        // Stage two implementation
    endmodule : stage_two

    module stage_three (...); // Nested module definition
        // Stage three implementation
    endmodule : stage_three
endmodule : processor

Nested Module Name Resolution

Nested modules follow distinct name resolution rules compared to regular modules. Similar to task definitions, nested modules can access their parent module's declarations. When an identifier is not found in the nested module's local scope, the search progresses to the parent module's scope, then to the compilation unit scope if necessary.

This upward search through the source code parent differs from regular modules, which search upward through the instantiation hierarchy. The distinction becomes important when designing parameterized modules or creating reusable verification components.

Simplified Netlist Connections

Netlists connect module instances through signal networks, ranging from high-level block interconnect to gate-level implementation details. Managing these connections efficiently becomes critical as design complexity grows.

Verilog provides two connection mechanisms: ordered port connections and named port connections, each with distinct characteristics and limitations.

Ordered Port Connections

Ordered connections rely on port position to establish signal associations. The first port connects to the first signal, the second port to the second signal, and so forth. While concise, this approach requires precise knowledge of port ordering and creates opportunities for subtle connection errors that prove difficult to debug.

// Ordered connection example - error-prone with complex modules
dff flipflop (output_q, , input_data, clock, reset);

Modules with numerous ports increase error probability significantly, and connection intent becomes obscured in the source code.

Named Port Connections

Named connections explicitly associate each port with its corresponding signal using dot notation:

// Named connection example - explicit and self-documenting
dff flipflop (.q(output_q), .qb(),
              .d(input_data), .clk(clock), .rst(reset));

This approach clearly documents design intent and reduces connection errors, which explains why many organizations mandate named connections in their coding standards. However, verbosity becomes a concern in large netlists with hundreds of module instances and dozens of ports per instance.

Implicit .name Port Connections

SystemVerilog addresses verbosity concerns with the .name connection syntax, which combines the conciseness of ordered connections with the clarity of named connections. When a signal name exactly matches its corresponding port name, the signal name alone suffices:

// Traditional named connection (verbose)
pc_stack pcs (.program_counter(program_counter),
              .program_address(program_address),
              .clk(clk), ...);

// SystemVerilog .name connection (concise)
pc_stack pcs (.program_counter,
              .program_address,
              .clk, ...);

Connection inference requires exact matching of names, dimensions, and compatible types between ports and signals. Mismatches can be handled explicitly using traditional named connection syntax when intentional differences exist.

Implicit .* Port Connections

SystemVerilog provides further simplification through the .* wildcard, which automatically connects all ports and signals sharing identical names within a module instance:

// Automatic connection of all matching ports and signals
pc_stack pcs (.*);

prom module_prom (.*, .data_out(program_data), .addr(program_address));

instruction_decode decoder (.*, .option_flag(flag), .tris_out(tris));

The .* wildcard infers connections for all matching name/size/type combinations, while explicitly named connections handle signals requiring different names or special treatment.

These implicit connection mechanisms extend to SystemVerilog's interface and program blocks, aswell as function and task calls, providing consistent connection simplification throughout the language.

Net Aliasing

SystemVerilog introduces the alias statement, enabling multiple names to reference the same physical net. This capability proves valuable when different design contexts prefer different naming conventions for identical signals.

wire clk_signal;
wire clock;
alias clock = clk_signal; // Both names reference the same net

Unlike assignment statements that copy values between signals, an alias creates true synonym references. Changes to either aliased name appear immediately on the other, reflecting the underlying shared physical net.

Alias Characteristics

The alias mechanism differs fundamentally from continuous assignments. Assignments perform one-way value propagation from right to left, while aliases create bidirectional equivalence where either name's state reflects on the other.

Multiple signals can participate in a single alias statement:

wire rst, reset_n, resetb, reset_bar;
alias rst = reset_n = resetb = reset_bar; // All names equivalent

Order of names within an alias statement does not matter, as the statement defines name equivalence rather than assignment precedence.

Aliasing Restrictions

SystemVerilog imposes specific constraints on alias declarations. Only net types can be aliased—variables cannot participate in alias statements. Allowed net types include wire, uwire, wand, wor, tri, triand, trior, tri0, tri1, and trireg.

Aliased nets must share identical net types and vector dimensions. While bit and part selects can be aliased, the resulting aliased sections must maintain consistent dimensions:

wire [31:0] data_bus;
wire [7:0] byte_select, check_byte;
alias byte_select = data_bus[7:0];       // 8-bit alias
alias check_byte = data_bus[31:24];      // 8-bit alias

Implicit Net Declaration from Aliases

Alias statements can infer implicit net declarations following standard Verilog rules. Undeclared identifiers in alias statements create implicit nets of wire type, inheriting port dimensions when declared in module port lists:

module register_unit (output [63:0] data_out,
                      input [63:0] data_in,
                      input clk, rst);
    
    alias input_bus = data_in;    // Infers 64-bit wire
    alias output_bus = data_out;  // Infers 64-bit wire
    alias reset_n = rst;          // Infers 1-bit wire
    // ...
endmodule

Enhancing Implicit Port Connections with Aliases

Aliasing proves particularly valuable when using .* connections across modules with inconsistent port naming conventions:

module top_level (input wire master_clk,
                   input wire master_rst,
                   ...);
    
    wire [31:0] addr_bus, next_addr, curr_addr;
    
    // Define aliases to align different module port names
    alias clk = clock = master_clk;
    alias rst = reset_n = master_rst;
    alias next_addr = addr_out = next_address;
    alias curr_addr = addr_in = current_addr;
    
    memory_unit mem (.*);
    counter_unit cnt (.*);
    address_register reg_unit (.*);
endmodule

module memory_unit (output wire [31:0] data,
                    input wire [31:0] addr,
                    input wire clk);
    // ...
endmodule

module counter_unit (output logic [31:0] next_address,
                     input wire [31:0] jump_addr,
                     input wire clock, reset_n);
    // ...
endmodule

module address_register (output wire [31:0] current_addr,
                         input wire [31:0] next_addr,
                         input wire clk, rstN);
    // ...
endmodule

Module Port Value Passing

Verilog historically imposed significant restrictions on value types that could traverse module ports. SystemVerilog relaxes these constraints considerably, enabling more flexible design patterns.

Port Type Restrictions in Traditional Verilog

Verilog allowed only net types on the receiving side of ports, prohibited variable connections except through procedural assignments, required explicit conversion for real values using $realtobits and $bitstoreal, and restricted unpacked array passage entirely.

SystemVerilog Port Flexibility

SystemVerilog removes nearly all type restrictions on port connections. Any value type can traverse ports in either direction, including real values. Packed and unpacked arrays of any dimension pass freely, and structures and unions with both packing styles connect without restriction.

typedef struct packed {
    logic [3:0] operation;
    logic [15:0] operand_value;
} instruction_struct;

module decoder_unit (output logic [23:0] microcode,
                     input instruction_struct instruction,
                     input logic [23:0] lookup_table [0:(2**20)-1]);
    // Processing logic using structure and array
endmodule

module dsp_processor (input logic clk, rst_n,
                      input logic [3:0] op_code,
                      input logic [15:0] operand,
                      output logic [23:0] result);
    
    logic [23:0] lookup_table [0:(2**20)-1];
    instruction_struct current_instruction;
    logic [23:0] decoded_microcode;
    
    decoder_unit decoder_inst (decoded_microcode, current_instruction, lookup_table);
    // Additional processing
endmodule

SystemVerilog Port Limitations

Despite relaxed restrictions, SystemVerilog maintains two important constraints. Variables must receive values from a single source at any simulation time, ensuring deterministic behavior matching hardware semantics. Multiple drivers require net types with appropriate resolution semantics.

Unpacked types require identical layouts on both sides of port connections. Structures and unions must use matching typedef definitions, and arrays must have consistent dimensionality and dimensions. This requirement ensures structural compatibility across module boundaries.

Packed types pass through ports as contiguous bit vectors, following standard vector size matching rules without the unpacked layout restrictions.

Reference Ports

SystemVerilog introduces ref ports, representing a fourth port type alongside input, output, and inout. A ref port passes a hierarchical reference to a variable rather than its value, creating direct aliasing between the port name and source variable.

typedef struct packed {
    logic [3:0] operation;
    logic [15:0] operand;
} instruction_struct;

module decoder (output logic [23:0] code_output,
                input instruction_struct instruction,
                ref logic [23:0] lookup_table [0:(2**20)-1]);
    
    // lookup_table is directly referenced, not copied
    code_output = lookup_table[instruction.operand];
endmodule

module dsp (input logic clk, rst_n,
            input logic [3:0] opcode,
            input logic [15:0] operand,
            output logic [23:0] data_out);
    
    logic [23:0] lookup [0:(2**20)-1];
    instruction_struct instr;
    logic [23:0] decoded;
    
    decoder decoder_inst (decoded, instr, lookup);
endmodule

Reference Port Behavior

Ref ports create shared variables accessible by multiple modules, which does not reflect standard hardware behavior. Multiple modules writing to a shared ref variable produce last-write-wins semantics, unlike net types that resolve multiple drivers according to technology-specific rules.

Importantly, ref ports are not synthesizable and should be reserved for abstract modeling and verification contexts where synthesis compatibility is not required.

Enhanced Port Declarations

Port declaration syntax has evolved across Verilog versions, with each iteration improving conciseness and clarity.

Verilog-1995 Declaration Style

The original Verilog style separated port lists from their declarations, requiring distinct statements for direction, type, and implicit net inference:

module accumulator (data_bus, result_out, carry_out, a_in, b_in, carry_in);
    inout [31:0] data_bus;
    output [31:0] result_out;
    output carry_out;
    input [31:0] a_in, b_in;
    input carry_in;
    
    wire [31:0] data_bus;
    reg [31:0] result_out;
    reg carry_out;
    tri1 carry_in;
    // Implementation
endmodule

Verilog-2001 ANSI-C Style

Verilog-2001 introduced combined declarations integrating direction, type, and size directly in the port list:

module accumulator (inout wire [31:0] data_bus,
                    output reg [31:0] result_out,
                    output reg carry_out,
                    input [31:0] a_in, b_in,
                    input tri1 carry_in);
    // Implementation
endmodule

This syntax requires explicit direction for all ports and cannot change direction or type without re-declaration.

SystemVerilog Declaration Enhancements

SystemVerilog introduces default behaviors that further simplify declarations. The first port without explicit direction defaults to inout, and subsequent ports inherit the previous port's direction when type is specified without direction:

module accumulator (wire [31:0] data_bus,
                    output reg [31:0] result_out, reg carry_out,
                    input [31:0] a_in, b_in, tri1 carry_in);
    // Implementation
endmodule

Here, data_bus defaults to inout, carry_out inherits output direction, and a_in, b_in, and carry_in use their explicit directions with implicit wire types.

SystemVerilog maintains backward compatibility with Verilog-1995 when the first port has neither direction nor type specified, detecting the legacy style automatically.

Parameterized Types

While Verilog's parameters enable instance-specific customization of constants and dimensions, SystemVerilog extends this capability to type definitions, enabling true polymorphic module implementations.

Parameterized types use the parameter type declaration, allowing different instances to use different net or variable types while maintaining shared logic structures:

module adder #(parameter type SUM_TYPE = shortint)
               (input SUM_TYPE operand_a, operand_b,
                output SUM_TYPE sum_result,
                output logic carry_out);
    
    SUM_TYPE temporary;
    // Adder implementation
endmodule

module complex_chip (...);
    shortint a_val, b_val, result_16;
    int c_val, d_val, result_32;
    int unsigned e_val, f_val, result_unsigned;
    wire carry1, carry2, carry3;
    
    // 16-bit signed adder using default type
    adder inst_16bit (a_val, b_val, result_16, carry1);
    
    // 32-bit signed adder with type override
    adder #(.SUM_TYPE(int)) inst_32bit (c_val, d_val, result_32, carry2);
    
    // 32-bit unsigned adder
    adder #(.SUM_TYPE(int unsigned)) inst_unsigned (e_val, f_val, result_unsigned, carry3);
endmodule

Each adder instance operates identically in terms of functionality but uses different underlying types, demonstrating how parameterized types enable flexible, reusable hardware components.

Parameterized types remain synthesizable when using synthesizable default or redefined types, making them suitable for production hardware design alongside their verification applications.