SystemVerilog Tutorial

Common Misconception: A testbench is not part of the final chip. It exists only in simulation to drive and check the design — none of its code gets synthesized into hardware.

From Separate Languages to One

Design and verification used to rely on entirely separate languages. RTL was written in an HDL like Verilog or VHDL, while verification-focused languages like Vera and e were used to build testbenches around them. Maintaining a design in one language and its testbench in another added friction — different syntax, different tools, and no shared type system between the two.

SystemVerilog collapsed that gap by extending Verilog directly, the most widely used HDL, so both the design and its testbench can live in a single, consistent language. Its OOP support also makes it possible to build verification environments at a much higher level of abstraction than plain Verilog ever allowed, while its synthesizable additions do the same for RTL design.

Design and Verification Working Together

A hardware design typically consists of several Verilog or SystemVerilog files with one top module that instantiates all the sub-modules needed to implement the desired functionality. A testbench, usually written in SystemVerilog, is built around this design to verify it.

The design is instantiated inside the testbench, and its input/output ports are connected to testbench signals. Specific values are driven onto the design's inputs, and the resulting outputs are compared against expected values to confirm the design behaves correctly.

Example: Why SystemVerilog Helps — A Traffic Light Controller

A common design pattern is a state machine that cycles through a fixed set of states — here, a traffic light cycling RED → GREEN → YELLOW → RED. In plain Verilog, states are usually tracked with hand-picked binary numbers:

// File : traffic_light.v
module traffic_light (
    input clk, rst,
    output reg [1:0] state
);
    parameter RED = 2'b00, GREEN = 2'b01, YELLOW = 2'b10;

    always @ (posedge clk) begin
        if (rst)
            state <= RED;
        else case (state)
            RED    : state <= GREEN;
            GREEN  : state <= YELLOW;
            YELLOW : state <= RED;
        endcase
    end
endmodule

This code is correct, but it has a maintenance problem: RED, GREEN, and YELLOW are just numbers you assigned by hand. Nothing stops two states from accidentally sharing the same value in a larger FSM, and when you trace state in a waveform viewer, you'll see 2'b00, 2'b01, 2'b10 instead of readable names.

Here's the same design in SystemVerilog:

// File : traffic_light_sv.sv
typedef enum logic [1:0] {RED, GREEN, YELLOW} state_t;

module traffic_light_sv (
    input  logic  clk, rst,
    output state_t state
);
    always_ff @ (posedge clk) begin
        if (rst)
            state <= RED;
        else case (state)
            RED    : state <= GREEN;
            GREEN  : state <= YELLOW;
            YELLOW : state <= RED;
        endcase
    end
endmodule

The functional behavior is identical, but three real, verifiable benefits come from just the state_t declaration:

• No hand-picked encoding: typedef enum assigns each member a unique value automatically, so there's no way for RED and YELLOW to accidentally collide the way two hand-written parameters could in a larger design.
• Readable waveforms: a waveform viewer displays RED, GREEN, and YELLOW by name instead of raw binary, which makes debugging noticeably faster.
• Real type safety: since state is declared as state_t, assigning it a raw value outside {RED, GREEN, YELLOW} (like state = 2'b11;) requires an explicit cast — the compiler catches an invalid state assignment instead of letting it slip into simulation.

Enum variables also come with a built-in .name() method that returns the current state as a string — useful for $display messages without writing your own lookup logic.

always_ff adds a smaller, complementary benefit: it documents that this block is meant to be sequential only, so tools that check design intent are more likely to flag a mistake (like a stray blocking assignment) as an error or warning instead of letting it pass silently.

Both versions still connect to a testbench the same way — instantiate the module, drive clk/rst from the testbench, and observe state, exactly as described earlier in this article.

Common Beginner Mistakes

typedef enum logic [1:0] {RED, GREEN, YELLOW, ALL_RED} state_t;

// Rest of the module is unchanged - only the case statement below differs
else case (state)
    RED     : state <= GREEN;
    GREEN   : state <= YELLOW;
    YELLOW  : state <= ALL_RED;
    ALL_RED : state <= RED;
endcase
  

module tb_traffic_light ();
    logic clk, rst;
    state_t state;

    traffic_light_sv dut (.clk(clk), .rst(rst), .state(state));

    always #10 clk = ~clk;

    initial begin
        clk = 0; rst = 1;
        #20 rst = 0;
        repeat (4) begin
            @ (posedge clk);
            $display("time=%0t state=%s", $time, state.name());
        end
    end
endmodule