💡 Why SystemVerilog?

Verilog-2001 was an excellent hardware description language but it was showing strain in two areas. On the design side, expressing complex data structures (structs, enums, typedefs) required cumbersome workarounds with integer and reg arrays. On the verification side, writing reliable, reusable testbenches demanded features that simply did not exist: object-oriented classes, constrained-random stimulus, functional coverage, and formal assertions.

SystemVerilog is the answer to both problems. It is a unified language that extends Verilog-2001 upward into the system modelling domain and outward into the hardware verification domain, while remaining fully backward-compatible with existing Verilog code.

🕑 Version History & Timeline

SystemVerilog evolved through several Accellera releases before being absorbed into the IEEE standardisation process. Understanding this history helps explain why some features feel like design extensions (SV 3.0) while others feel like verification additions (SV 3.1).

🏛 The Three Extension Pillars

SystemVerilog extensions fall into three distinct pillars. A single SystemVerilog source file can contain constructs from all three pillars simultaneously — this unification is one of SV’s key advantages over maintaining separate HDL and HVL source files.

🌟 Complete Feature Overview

The following summarises every major addition SystemVerilog 3.1a makes to Verilog-2001, grouped by category. Each item links to the article in this series that covers it in depth.

Data Types & Declarations

Operators & Control Flow

Design Constructs

Verification & OOP

Assertions

⇄ Verilog-2001 vs SystemVerilog Side-by-Side

The most practical way to appreciate SV is to see the same constructs written in both languages. Below are six representative patterns that illustrate the improvement in expressiveness.

// Magic numbers — no type safety
parameter IDLE  = 2'b00;
parameter FETCH = 2'b01;
parameter EXEC  = 2'b10;

reg [1:0] state;

always @(posedge clk)
  case(state)
    IDLE: ...

// Named, type-safe enum
typedef enum logic [1:0] {
  IDLE, FETCH, EXEC, DONE
} state_t;

state_t state;

always_ff @(posedge clk)
  unique case(state)
    IDLE: ...

// Everything flat, error-prone
wire [31:0] addr;
wire [31:0] data;
wire       valid;
wire       ready;
wire [1:0]  burst;

module slave(
  input  [31:0] addr,
  input  [31:0] data,
  ...);

// Encapsulated, reusable
interface axi_if(
  input logic clk);
  logic [31:0] addr, data;
  logic       valid, ready;
  logic [1:0]  burst;
endinterface

module slave(
  axi_if.slave bus);

// Manual, no reuse
initial begin
  addr = 32'h1000;
  data = 32'hDEAD_BEEF;
  we   = 1'b1;
  @(posedge clk);
  we = 1'b0;
  // repeat for every test
end

// Reusable, constrained-random
class AXITx;
  rand logic [31:0] addr, data;
  constraint c_addr {
    addr inside {[32'h0:32'hFFFF]};
  }
endclass

AXITx tx = new();
tx.randomize();

⚙ Compilation & Tool Flow

Understanding how SystemVerilog files are compiled and simulated is important before writing your first module. The SV compilation model adds a few concepts that do not exist in Verilog-2001.

project/
├── rtl/                        ← Design files (.sv)
│   ├── pkg/
│   │   └── bus_types_pkg.sv    ← typedef, struct, enum declarations
│   ├── fifo.sv                 ← DUT: uses always_ff, logic, typedef
│   └── top.sv                  ← Instantiates DUT + interface
├── tb/                         ← Testbench files (.sv)
│   ├── interfaces/
│   │   └── fifo_if.sv          ← interface + modport + clocking block
│   ├── env/
│   │   ├── transaction.sv      ← class with rand fields + constraints
│   │   ├── driver.sv           ← class driving clocking block
│   │   ├── monitor.sv          ← class sampling interface
│   │   ├── scoreboard.sv       ← class checking outputs
│   │   └── coverage.sv         ← covergroup + coverpoints
│   └── top_tb.sv               ← program block + DUT instantiation
└── sim/
    └── filelist.f              ← Compilation order for simulator

# Compile all SV files
iverilog -g2012 \
  rtl/pkg/bus_types_pkg.sv \
  rtl/fifo.sv \
  tb/interfaces/fifo_if.sv \
  tb/env/*.sv \
  tb/top_tb.sv \
  -o sim_out
vvp sim_out

# Compile packages first
vlog -sv rtl/pkg/bus_types_pkg.sv
vlog -sv rtl/fifo.sv
vlog -sv tb/interfaces/fifo_if.sv
vlog -sv tb/env/*.sv
vlog -sv tb/top_tb.sv
# Run simulation
vsim -c top_tb -do "run -all"

👀 First Look: Key SV Code Patterns

Before diving into individual sections, here are five representative SV patterns that you will encounter throughout this series. Each is shown in context so you can see at a glance how the feature is used.

Pattern 1 — logic instead of wire/reg

// Verilog-2001: must choose wire or reg based on assignment context
wire  [7:0] data_in;   // continuous assign or module output
reg   [7:0] data_reg;  // procedural always block

// SystemVerilog: logic works in both contexts
logic [7:0] data_in;   // can be driven by continuous assign
logic [7:0] data_reg;  // can be driven by always_ff — same type!

Pattern 2 — always_ff / always_comb

module counter (
  input  logic       clk, rst_n, en,
  output logic [7:0] count
);
  // always_ff: synthesis tool verifies this is a clocked flip-flop
  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) count <= 8'b0;
    else if (en) count <= count + 1;
  end

  // always_comb: synthesis tool verifies this is purely combinational
  logic at_max;
  always_comb
    at_max = (count == 8'hFF);
endmodule

Pattern 3 — Interface + modport

interface apb_if (
  input logic pclk, presetn
);
  logic [31:0] paddr, pwdata, prdata;
  logic        psel, penable, pwrite, pready;

  // Modport: defines signal directions from master perspective
  modport master (
    input  pclk, presetn, prdata, pready,
    output paddr, pwdata, psel, penable, pwrite
  );
  modport slave (
    input  pclk, presetn, paddr, pwdata, psel, penable, pwrite,
    output prdata, pready
  );
endinterface

// Module uses the interface port directly — no signal list!
module apb_master (apb_if.master bus);
  always_ff @(posedge bus.pclk)
    bus.paddr <= 32'h0000_1000;
endmodule

Pattern 4 — Class with constrained-random

class APBTransaction;
  rand logic [31:0] addr;
  rand logic [31:0] data;
  rand logic        write;

  constraint c_addr_aligned {
    addr[1:0] == 2'b00;       // word-aligned
    addr < 32'h0000_FFFF;     // within peripheral range
  }
  constraint c_write_bias {
    write dist { 1 :/ 70, 0 :/ 30 }; // 70% writes
  }
endclass

// Usage: create, randomize, check
APBTransaction tx = new();
assert(tx.randomize()) else $fatal(1, "Randomization failed");
$display("addr=%0h data=%0h wr=%0b", tx.addr, tx.data, tx.write);

Pattern 5 — Concurrent assertion (SVA)

// Inside a module or bound to a module:
// "If req goes high, ack must follow within 1–4 cycles"
REQACK: assert property (
  @(posedge clk)
  req |-> ##[1:4] ack
) else $error("ACK did not arrive within 4 cycles of REQ");

// Cover property: check this scenario is actually exercised
REQACK_COVER: cover property (
  @(posedge clk)
  req ##1 ack   // fast ack in exactly 1 cycle
);

🗺 Prerequisites

This series assumes you are comfortable with Verilog-2001. Specifically, you should be at ease with all of the following before continuing: