Hierarchy

Hierarchy

Verilog HDL has a simple organization. All data, functions and tasks are in modules except for system tasks and functions, which are global, and can be defined in the PLI. A Verilog module can contain instances of other modules. Any uninstantiated module is at the top level. This does not apply to libraries, which therefore have a different status and a different procedure for analyzing them.

A hierarchical name can be used to specify any named object from anywhere in the instance hierarchy. The module hierarchy is often arbitrary and a lot of effort is spent in maintaining port lists.

SystemVerilog adds many enhancements for representing design hierarchy:

» Packages containing declarations such as data, types, classes, tasks and functions
» Separate compilation support
» A compilation-unit scope visible only within a compilation unit
» Nested module declarations, to aid in representing self-contained models and libraries
» Relaxed rules on port declarations
» Simplified named port connections, using .name
» Implicit port connections, using .*
» Time unit and time precision specifications bound to modules
» A concept of interfaces to bundle connections between modules.
Packages:

SystemVerilog packages provide an additional mechanism for sharing

» parameters
» data type
» task
» function
» sequence
» property declarations amongst multiple SystemVerilog modules
interfaces and program Packages are explicitly named scopes appearing at the outermost level of the source text. Types, variables, tasks, functions, sequences, and properties may be declared within a package. Such declarations may be referenced within modules, macromodules, interfaces, programs, and other packages by either import or fully resolved name.

Above can be shared across SystemVerilog modules, macromodule interfaces and programs. Few rules that should be followed with packages are.

» Packages can not contain any assign statement.
» Variable declaration assignments within the package shall occur before any initial, always, always_comb, always_latch, or always_ff blocks
» Items within packages cannot have hierarchical references.
» Assign statment on any net type is not allowed.
Accessing data, functions or types in packages there are two ways.

» By class scope resolution operator ::
» By import statement : The import statement provides direct visibility of identifiers within packages.
package ComplexPkg;
typedef struct {
float i, r;
} Complex;
function Complex add(Complex a, b);
add.r = a.r + b.r;
add.i = a.i + b.i;
endfunction
function Complex mul(Complex a, b);
mul.r = (a.r * b.r) - (a.i * b.i);
mul.i = (a.r * b.i) + (a.i * b.r);
endfunction
endpackage : ComplexPkg

Referencing data in packages

Packages must exist in order for the items they define to be recognized by the scopes in which they are imported. One way to use declarations made in a package is to reference them using the scope resolution operator “::”.

ComplexPkg::Complex cout = ComplexPkg::mul(a, b);

An alternate method for utilizing package declarations is via the import statement.

Compilation unit support

SystemVerilog supports separate compilation using compiled units. The following terms and definitions are provided:

compilation unit: a collection of one or more SystemVerilog source files compiled together
compilation-unit scope: a scope that is local to the compilation unit. It contains all declarations that lie outside of any other scope
$unit: the name used to explicitly access the identifiers in the compilation-unit scope
Top-level instance:

The name $root is added to unambiguously refer to a top level instance, or to an instance path starting from the root of the instantiation tree. $root is the root of the instantiation tree.

For example:
$root.A.B // item B within top instance A
$root.A.B.C // item C within instance B within instance A