Variables, Scope, Nets & Type Compatibility

📋 Variable Declarations

A variable declaration consists of a data type followed by one or more instances, with an optional initialiser.

// Basic declarations
shortint s1, s2[0:9];   // s1 scalar, s2 unpacked array
int       i = 0;          // declaration with initialiser
const logic flag = 1;    // named constant — cannot be reassigned

// const class object — the handle is fixed; members can still be written
const my_class obj = new(5, 3);

// Variable declaration syntax: [ const ] [ lifetime ] data_type list_of_vars ;
// lifetime: static | automatic
// Outside a procedural context, 'automatic' is illegal.

📋 Default Initial Values

Every SV variable has a well-defined default value if no initialiser is provided.

📋 Scope and Lifetime

SV defines four distinct combinations of scope and lifetime for data declarations:

📋 static vs automatic in Detail

SV lets you override the default lifetime for individual variables within a task, function, or block — regardless of the overall scope’s default.

module msl;
  int st0;          // static — module level

  initial begin
    int           st1;    // static (default inside initial)
    static int    st2;    // explicitly static
    automatic int auto1; // automatic override
  end

  task automatic t1();   // all variables automatic by default
    int           auto2; // automatic (from task qualifier)
    static int    st3;   // explicit static override
    automatic int auto3; // redundant — already automatic
  endtask
endmodule

// Program or module-level lifetime qualifier sets the default for everything inside
program automatic test;
  int i;          // not in a procedural block — remains static
  task foo(int a); // all variables in foo are automatic
  endtask
endmodule

• Class methods and declared for loop variables are always automatic, regardless of the enclosing scope’s lifetime qualifier.
• Automatic and dynamic variables (object handles, dynamic arrays, associative arrays, strings, events) are restricted to the procedural context — they cannot be written with nonblocking or continuous assignments.
• The lifetime of a fork…join block encompasses all spawned processes; the enclosing scope’s lifetime includes the fork block’s lifetime.

📋 Nets, Variables & logic

Verilog-2001 drew a strict line: nets (driven by continuous assignments or ports) and variables (driven by procedural statements) were mutually exclusive. SV relaxes this significantly.

📋 Continuous vs Procedural Assignment Rules

The key rule in SV: a variable may be driven by one continuous assignment or by one or more procedural statements — never both, never by multiple continuous assignments.

For aggregate types (structs and arrays), the rule is applied at the level of the longest static prefix being written:

• An unpacked struct or array can have different elements assigned by different methods — one element continuously, another procedurally — as long as no single element is driven by both.
• A packed struct or array must be driven entirely by one method (all continuous or all procedural). Mixing on any element of a packed aggregate is an error.
• A declared variable initialiser and a procedural continuous assignment both count as procedural for the purpose of this rule.
• A force statement is neither continuous nor procedural — it is exempt from the rule.
• A variable declared as an input port gets an implied continuous assignment — procedural assignments to it are then illegal.
• A variable connected to the output port of an instance gets an implied continuous assignment from the instance — any other procedural or continuous assignment to it is then illegal.
• SV variables cannot be connected to either side of an inout port. Use ref ports for shared variable access across module boundaries.

📋 Legal and Illegal Assignment Examples

struct {
  bit [7:0] A;
  bit [7:0] B;
  byte       C;
} abc;

// ✓ Legal — unpacked struct: each member driven by its own method
assign abc.C = sel ? 8'hBE : 8'hEF;       // C driven continuously
not (abc.A[0],abc.B[0]);                   // A,B bits via primitive
always @(posedge clk) abc.B <= abc.B + 1; // B driven procedurally — different element, OK

// ✗ Illegal — multiple continuous assignments to the SAME element
assign abc.C = sel ? 8'hDE : 8'hED;       // ERROR: C already has a continuous assign

// ✗ Illegal — mixing continuous and procedural on abc.A
always @(posedge clk) abc.A[7:4] <= !abc.B[7:4]; // ERROR: A also has primitive assignment

// Variable driven by continuous assignment — fully legal
logic vw;
assign vw = vara & varb;   // continuous assignment to a logic variable

real circ;
assign circ = 2.0 * PI * R; // continuous assignment to a real

// Declaration initialiser vs continuous assignment — different things
wire  w = vara & varb;    // continuous assignment (wire)
logic v = consta & constb; // initial procedural assignment (NOT continuous)

📋 Signal Aliasing

The alias statement creates a bidirectional short-circuit connection between two or more net signals. Unlike assign (which is unidirectional), aliased signals share the same physical nets — a change on either side propagates immediately in both directions.

// Byte-order swap between two 32-bit buses
module byte_swap (inout wire [31:0] A, inout wire [31:0] B);
  alias {A[7:0],A[15:8],A[23:16],A[31:24]} = B;
endmodule

// Expose only LSB and MSB bytes from a 32-bit bus
module byte_rip (inout wire [31:0] W, inout wire [7:0] LSB, MSB);
  alias W[7:0]   = LSB;
  alias W[31:24] = MSB;
endmodule

// Multiple alias statements are cumulative — the following two are equivalent:
// alias bus16[11:0] = low12; alias bus16[15:4] = high12;
// → low12[11:4] and high12[7:0] share the same wires

// Alias + .* for library cell wrapper — any of lib1_dff, lib2_dff, lib3_dff
macromodule my_dff(rst, clk, d, q, q_bar);
  alias rst = Reset = reset = RST;
  alias clk = Clk   = clock = CLK;
  `LIB_DFF my_dff (.*);
endmodule

Alias rules

• All nets in an alias must be type compatible (same net type — e.g. you cannot alias a wand to a wor).
• Each member must be the same bit size; the layout is independent of the simulation host.
• Variables and hierarchical references cannot be used in alias statements.
• A net cannot be aliased to itself (either directly or through two overlapping statements covering the same bits).
• Alias takes effect at elaboration time and cannot be undone at runtime.
• Alias statements can appear anywhere module instance statements can appear; undeclared identifiers in an alias follow the same implicit net rules as module instances.

📋 Type Compatibility — Four Levels

Different SV constructs require different levels of type compatibility between their operands. SV defines four levels, from strictest to most permissive:

📋 Equivalent Types — The Eight Rules

Two types are equivalent if they match under any of these eight rules. If none apply, they are non-equivalent.

1. Built-in types: any built-in type is equivalent to every other occurrence of itself, in any scope. int in module A is equivalent to int in module B.
2. Simple typedefs: a typedef that renames a built-in or user-defined type is equivalent to that type within the scope of the typedef identifier. typedef bit node → bit and node are equivalent.
3. Anonymous aggregates: an anonymous enum, struct, or union is equivalent only to variables declared in the same declaration statement.
4. Named aggregates: a typedef for an enum, unpacked struct, unpacked union, or class is equivalent to itself and to variables declared with that typedef in the same scope.
5. Packed/integral types: packed arrays, packed structures, and built-in integral types are equivalent if they have the same total bit count, the same state count (2 vs 4), and the same signing.
6. Unpacked arrays: equivalent when element types are equivalent and shape is identical (same number of dimensions, same element count per dimension — not necessarily same range bounds).
7. Signing modifiers: adding unsigned to a type that is already unsigned (or signed to a type already signed) does not make it non-equivalent.
8. Package types: a typedef declared in a package is equivalent to itself regardless of where it is imported — package types carry their identity across compilation units.

// Rule 2: typedef equivalence
typedef bit node;   // bit and node are equivalent

// Rule 3: anonymous struct — AB1 and AB2 equivalent; AB3 is NOT
struct {int A; int B;} AB1, AB2;
struct {int A; int B;} AB3;   // different declaration — not equivalent

// Rule 4: named typedef — AB1 and AB2 equivalent; AB3 is NOT
typedef struct {int A; int B;} AB_t;
AB_t AB1, AB2;
typedef struct {int A; int B;} otherAB_t;
otherAB_t AB3;    // NOT equivalent to AB1/AB2

// Rule 5: packed equivalence
typedef bit signed [7:0] BYTE;   // equivalent to 'byte' (8-bit, 2-state, signed)

// Rule 6: unpacked array shape — A, B, C are all equivalent
bit [9:0] A[0:5];   // shape: 6 elements of bit[9:0]
bit [1:10] B[6];    // same shape (different range notation)
typedef bit [10:1] uint10;
uint10 C[6:1];      // also equivalent

// Cross-instance equivalence — scope matters for user-defined types
package p1; typedef struct {int A;} t_1; endpackage  // rule 8: always equivalent
typedef struct {int A;} t_2;                           // rule 4: equiv within $unit

module top; ...
  s1.v1 = s2.v1;  // legal: both t_1 from package p1 (rule 8)
  s1.v2 = s2.v2;  // legal: both t_2 from $unit (rule 4)
  s1.v5 = s2.v5;  // ILLEGAL: t_5 declared inside each sub instance separately (rule 4)
endmodule

📋 Assignment Compatible

Assignment compatibility is a superset of equivalence. All equivalent types are assignment compatible. Additionally, types with implicit conversion rules defined between them are assignment compatible.

• All integral types are assignment compatible with each other (truncation or extension may occur).
• Compatibility can be one-directional: an enum can be implicitly converted to an integral type (its underlying integer value), but an integral cannot be implicitly converted to an enum — that requires a cast.
• Data loss through truncation or rounding is allowed without error.

📋 Cast Compatible

Cast compatibility is a further superset. All assignment compatible types are cast compatible. Additionally, types that can be explicitly converted using the cast operator type'(expr) are cast compatible, even if implicit conversion is not available.

• An integral type can be explicitly cast to an enum: state_t'(some_int) — requires explicit cast.
• Bit-stream casts between types with the same total bit count — e.g. casting a packed struct to a logic vector of the same width.

📋 Type Incompatible

These are all remaining non-equivalent types with no defined implicit or explicit casting path. Attempting to assign or cast between type-incompatible types is a compile error.

• Class handles are type incompatible with all non-class types. A class handle can only be assigned to a variable of the same class (or a parent class).
• chandle is type incompatible with all other types except null.
• Types from different inheritance hierarchies (unrelated classes) are type incompatible.

📋 Quick Reference

Lifetime and scope at a glance

Net vs variable in SV

Type compatibility summary