System Verilog Interview Questions

SystemVerilog extends Verilog with a full verification language: classes, randomization, functional coverage, and assertions. Interviewers test whether you understand these deeply enough to use them well. Below, each concept has a short answer and a code example. For more depth on any topic, follow the links into the SystemVerilog posts.

A simple way to approach SystemVerilog questions

Think of an interview like a code review. The interviewer is not just checking whether you know a keyword; they want to see that you know when to use it and what breaks if you use the wrong one. So for every answer, say what the feature does, then give the one-line reason it matters. A candidate who says “logic is 4-state, so it catches uninitialized X values that a 2-state bit would hide” sounds far stronger than one who just recites “logic can be 0, 1, X, Z.”

Data types

bit vs logic

A bit is 2-state (0 or 1). A logic is 4-state (0, 1, X, Z). Use bit for fast internal counters and scoreboard maths; use logic anywhere you drive or sample RTL, so uninitialized (X) and floating (Z) values are not silently hidden.

bit   [7:0] count;   // 2-state: starts at 0, fast
logic [7:0] data;    // 4-state: starts at X, models real signals

initial begin
  $display("count = %0d, data = %b", count, data);
  // count = 0,  data = xxxxxxxx  (the X warns you data was never driven)
end

Why it matters: using bit on a DUT interface can mask a real bug where RTL never drove a signal, because bit would read 0 instead of X.

logic vs reg vs wire

• wire is a net; it must be driven continuously (by an assign or a port) and cannot hold a value on its own.
• reg is the old Verilog variable type, assigned inside procedural blocks. It does not imply a hardware register.
• logic is the SystemVerilog replacement for reg. It can be driven procedurally or by a single continuous assign, so you rarely need reg any more. The one limit: logic cannot have multiple drivers, so a multi-driver net still needs wire.

byte vs logic [7:0]

Both are 8 bits, but byte is a 2-state signed type, while logic [7:0] is 4-state and unsigned by default. Use byte for arithmetic on small values; use logic [7:0] when you need X and Z or a plain bit vector.

union vs struct

A struct stores all its members at once, each in its own space. A union stores one member at a time, all sharing the same space, so it is used to view the same bits in different ways or to save memory.

typedef struct packed {
  bit [7:0] addr;
  bit [7:0] data;
} pkt_s;            // 16 bits total: addr and data both exist

typedef union packed {
  bit [15:0] word;
  bit [7:0]  bytes [2];
} view_u;           // 16 bits total, viewed as one word or two bytes

Display and file tasks

$display vs $write vs $monitor vs $strobe

Why $strobe matters: in a time step where a value is still changing, $display may print the old value, while $strobe waits until the step settles and prints the final value.

Arrays

packed vs unpacked arrays

A packed array is a contiguous block of bits you can treat as one number; dimensions are written before the name. An unpacked array is a collection of separate elements; dimensions are written after the name. Use packed for bit vectors and arithmetic, unpacked for memories and collections.

bit [3:0][7:0] packed_reg;   // 32 contiguous bits, usable as one value
bit [7:0] mem [0:255];       // 256 separate bytes, a small memory

Which array type for a large memory (16/32/64KB)?

Use an associative array. A fixed unpacked array of 64KB allocates every location up front, wasting memory when the test touches only a few addresses. An associative array stores only the entries you actually write, so it models a huge sparse memory cheaply.

bit [7:0] sparse_mem [int];   // associative: only written addresses use memory

initial begin
  sparse_mem[32'h1000_0000] = 8'hAB;   // one entry allocated, not 64KB
  if (sparse_mem.exists(32'h1000_0000))
    $display("value = %h", sparse_mem[32'h1000_0000]);
end

Find elements greater than 5 with the array locator “find”

int da[] = '{2, 7, 4, 9, 5, 11, 1};
int result[$];

result = da.find(x) with (x > 5);   // returns the matching elements
$display("%p", result);             // '{7, 9, 11}

Resize a dynamic array from 50 to 100, keeping the lower 50

Call new[100] on the array but pass the old array as the initializer. That copies the existing elements into the new, larger array; the rest default to zero.

int da[];
da = new[50];
// ... fill da[0..49] ...
da = new[100](da);   // grows to 100, preserves the first 50 values

Classes and object-oriented features

private, public, and protected members

• public (the default) members are visible everywhere.
• local (SystemVerilog word for private) members are visible only inside the class that declares them.
• protected members are visible inside the class and its child classes, but not outside.

Why it matters: marking a field local or protected stops other code from changing internal state by accident, which keeps a verification component predictable.

new() vs new[]

new() is the class constructor; it builds one object. new[n] sizes a dynamic array to n elements. They look similar but do completely different jobs.

packet p;
p = new();          // constructor: create one packet object

int da[];
da = new[16];        // dynamic array: allocate 16 elements

Forward declaration of a class

A forward declaration tells the compiler a class name exists before its full body is seen. It is needed when two classes refer to each other, so the first one can name the second before it is defined.

typedef class driver;   // forward declaration

class monitor;
  driver drv;           // legal now, driver is known by name
endclass

class driver;
  // full definition
endclass

Functions, tasks, and arguments

ref and const ref arguments

A ref argument passes the actual variable, not a copy, so changes inside the task are seen by the caller. A const ref passes by reference too but forbids modification, which is used to pass a large object efficiently without allowing the callee to change it.

task automatic add_one(ref int a);       // caller sees the change
  a = a + 1;
endtask

function automatic int sum(const ref int arr[]);  // fast, read-only
  sum = 0;
  foreach (arr[i]) sum += arr[i];
endfunction

Why const ref: passing a big array by value copies the whole thing; const ref avoids the copy while guaranteeing the function cannot corrupt the caller data.

System tasks and functions

System tasks and functions are built-in routines, all starting with a dollar sign, that the simulator provides. Examples: $display and $strobe (printing), $random and $urandom (random numbers), $time (current time), $fopen and $fwrite (file I/O), $finish (end simulation), and $sformatf (format a string).

Control flow

case vs casex vs casez

Prefer casez over casex. casex treating X as don’t-care can hide real X bugs, because an unknown value silently matches a branch it should not.

Which equality operator is used inside case, casex, casez?

The case statements use the identity operator triple-equals (===) style matching, meaning they compare X and Z as real values (a case item must match bit for bit), not the logical double-equals (==) which returns X when either side has an X. That is why plain case needs exact X and Z matches.

forever loop vs for loop

A for loop runs a fixed number of times set by its counter. A forever loop runs endlessly and must contain a timing control (like @ or #) or a disable, so it is used for always-running processes such as a clock generator or a driver main loop.

// for loop: known count
for (int i = 0; i < 8; i++) drive_beat(i);

// forever loop: runs for the whole simulation
forever begin
  @(posedge clk);
  sample_signals();
end

How SystemVerilog simulation regions work

Each time step is split into ordered regions so that hardware-like behaviour is deterministic. The main ones, in order: Active (normal RTL and blocking assignments), then NBA (non-blocking assignment updates), then Observed (assertion evaluation), then Reactive (program blocks and testbench), then Postponed ($strobe and $monitor). Clocking blocks sample in the region that avoids races with the design.

Why regions exist: they stop testbench and design code from racing. A clocking block samples inputs in a safe region so the testbench sees stable values, not mid-update ones.

Interfaces and clocking blocks

Interfaces

An interface bundles a group of related signals into one named block, so a testbench and DUT connect through a single handle instead of dozens of individual ports. It can also hold clocking blocks, modports, and assertions.

interface bus_if(input logic clk);
  logic        valid, ready;
  logic [31:0] data;

  clocking cb @(posedge clk);
    output valid, data;
    input  ready;
  endclocking

  modport TB (clocking cb);
endinterface

modport

A modport gives a named view of an interface that fixes signal directions for one user. The DUT modport might drive ready, while the testbench modport drives valid; the same interface serves both without wiring mistakes.

Clocking block and its advantages

• Race-free sampling. Inputs are sampled at a defined time relative to the clock, so the testbench never sees mid-update values.
• Skew control. Input and output skews model realistic setup and hold behaviour.
• Cleaner code. Drive and sample through the clocking block instead of chasing signal timing by hand.

input #1 step vs input #1ns skew

In a clocking block, input #1step samples the signal one step before the clock edge, meaning at the end of the previous time step (the last settled value). input #1ns samples it a fixed 1 nanosecond before the edge. Use 1step for the standard race-free sample; use an explicit time only when you need a specific offset.

Randomization and constraints

pre_randomize and post_randomize

These are callbacks the solver runs automatically. pre_randomize() runs just before randomization, to set up values or turn constraints on and off. post_randomize() runs just after, to fix up or check the result.

class packet;
  rand bit [7:0] len;
  bit [7:0]      crc;

  function void post_randomize();
    crc = ~len;          // compute a derived field after randomizing
  endfunction
endclass

Enable or disable constraints selectively

Use constraint_mode() to switch a named constraint on or off, and rand_mode() to switch randomization of a variable on or off.

p.c_small.constraint_mode(0);   // turn OFF the c_small constraint
p.addr.rand_mode(0);            // stop randomizing addr (keep its value)
assert(p.randomize());

unique constraint

The unique constraint forces a set of variables or all elements of an array to take different values in one randomize call.

class u_arr;
  rand bit [7:0] vals [5];
  constraint c_uniq { unique { vals }; }   // all 5 elements differ
endclass

Dynamic array of unique random values, with and without the unique constraint

With unique it is one line. Without it, you constrain each element to differ from the earlier ones using foreach.

// With unique
rand bit [7:0] a [10];
constraint c1 { unique { a }; }

// Without unique (manual)
constraint c2 { foreach (a[i]) foreach (a[j]) if (i != j) a[i] != a[j]; }

hard vs soft constraints

A hard constraint must always hold; if it cannot, randomization fails. A soft constraint is a default that the solver drops if it conflicts with a hard constraint or an inline constraint. Use soft for sensible defaults that a test may override.

class cfg;
  rand int mode;
  constraint c_def  { soft mode == 0; }   // default, overridable
endclass

cfg c = new();
assert(c.randomize() with { mode == 3; }); // soft default yields to this

Override a base-class constraint in a child class

Declare a constraint with the same name in the child class. The child version replaces the parent one for objects of the child type.

class base;
  rand int x;
  constraint c_range { x inside {[0:10]}; }
endclass
class child extends base;
  constraint c_range { x inside {[100:200]}; }  // overrides base
endclass

Generate a packet with address greater than 500

assert(pkt.randomize() with { addr > 500; });

Value with exactly 15 ones, no two adjacent ones

Constrain the population count to 15 and forbid any bit being 1 next to another 1 using a bitwise-and of the value with its shift.

rand bit [31:0] v;
constraint c_ones { $countones(v) == 15; }
constraint c_adj  { (v & (v << 1)) == 0; }   // no two adjacent 1s

Dynamic array: each element < 50 and size < 50

rand int da[];
constraint c_sz  { da.size() inside {[1:49]}; }
constraint c_val { foreach (da[i]) da[i] < 50; }

Array size 50 to 100 with values in descending order

rand int da[];
constraint c_sz   { da.size() inside {[50:100]}; }
constraint c_desc { foreach (da[i]) if (i > 0) da[i] < da[i-1]; }

Threads, events, and mailboxes

Counting parallel threads

fork…join starts each statement inside it as a separate thread. A for loop wrapped around a fork…join_none spawns one thread per iteration. To count threads, count how many statements sit directly inside the fork.

fork
  taskA();     // thread 1
  taskB();     // thread 2
  begin        // thread 3 (one begin-end block is one thread)
    step1(); step2();
  end
join
// 3 parallel threads

Merging two events

Assign one event to another with the merge operator so that triggering either one wakes waiters on both. This is done with the event variable assignment.

event e1, e2;
initial e2 = e1;      // merge: e1 and e2 now refer to the same event
// -> e1;  will wake anything waiting on e2 as well

bounded vs unbounded mailboxes

A mailbox passes data between threads. An unbounded mailbox has no size limit, so put() never blocks. A bounded mailbox is created with a size; put() blocks when it is full, which applies natural back-pressure between a fast producer and a slow consumer.

mailbox mb_u = new();     // unbounded: put never blocks
mailbox mb_b = new(4);    // bounded to 4: put blocks when full

Sign-off and project questions

Gate Level Simulation and why it matters

Gate Level Simulation (GLS) runs the netlist produced after synthesis, with real gates and often real timing, instead of RTL. It matters because it catches problems that RTL simulation cannot see: X-propagation from uninitialized flops, reset issues, timing violations with back-annotated delays, and mismatches introduced by synthesis. It is a standard sign-off check before tape-out.

Metrics to track verification progress

• Functional coverage percentage, from the functional coverage model, shows how much planned behaviour was exercised.
• Code coverage (line, branch, toggle, FSM) shows how much RTL the tests touched.
• Assertion pass and fail counts from assertions.
• Bug rate over time, which should fall as the design matures.
• Regression pass rate and number of consecutive clean runs.

When is verification complete?

Verification is complete when the sign-off criteria are all met: functional and code coverage at their goals with justified exclusions, all planned tests passing across several consecutive clean regressions, all known bugs fixed or waived with reasons, and the bug discovery rate flattened. Coverage at 100% with a flat bug curve is the practical signal of maturity.

How to check whether a given constraint is correct

Read it for three things: is the range reachable (no impossible combination), does it avoid contradicting another constraint, and does it use the right operators (for example inside for ranges, and dist for weighting). A common bug is writing overlapping hard constraints that leave no legal value, which makes randomize() fail. When in doubt, relax to a soft constraint or print the solver failure.

Keep practising

Work through these out loud with a whiteboard, then extend each answer with a small example of your own. Pair this page with the wider interview questions, and deepen any weak spot through the assertions and functional coverage guides.

Credit and further reading

These questions and answers are reframed from the knowledge shared by semiconductor industry experts Mr. Robin Garg and Mr. Ramdas Mozhikunnath, whose generosity in sharing with the VLSI community made this collection possible. Credit for the original insight goes to their work.

Books worth reading to learn SystemVerilog in more depth:

• Writing Testbenches using SystemVerilog by Janick Bergeron
• SystemVerilog for Verification by Chris Spear
• Verilog and SystemVerilog Gotchas by Stuart Sutherland
• SystemVerilog Assertions Handbook by Ben Cohen, Srinivasan Venkataramanan, Ajeetha Kumari
• Principles of Functional Verification by Andreas Meyer
• SystemVerilog Assertions and Functional Coverage by Ashok B. Mehta
• A Practical Guide for SystemVerilog Assertions by Srikanth Vijayaraghavan, Meyappan Ramanathan
• Introduction to SystemVerilog by Ashok B. Mehta

Frequently asked questions

Share this post: on Twitter on Facebook