SystemVerilog Interview Questions

? Print / Save as PDF

In short: SystemVerilog interviews probe whether you understand 2-state versus 4-state data, class handles and polymorphism, how the constraint solver behaves, how interfaces and clocking blocks avoid races, and how assertions and coverage close the loop.

Data types: the questions that open almost every round

The first warm-up is usually "difference between logic and reg". Functionally there is none for a single driver: logic is a 4-state variable that may be driven by one continuous assignment or by procedural code, but not both. Its advantage is that you no longer decide between wire and reg by guessing. Multiple drivers still need a net such as wire. For history, see our comparison of Verilog vs SystemVerilog.

Next comes 2-state versus 4-state. bit, byte, int and longint hold only 0 and 1, so an X or Z coming from the DUT silently becomes 0 when you sample it. That is a classic way for a testbench to hide a reset bug. Use 4-state types on DUT-facing signals and 2-state types for internal counters and scoreboard math, where they also simulate faster and use less memory.

Key fact: int is a signed 32-bit 2-state type, while integer is a signed 32-bit 4-state type. Interviewers love this pair because the names look almost identical.

Expect also: dynamic arrays (new[n], resizable), queues (push_back, pop_front, O(1) at both ends), and associative arrays (sparse memory models indexed by address). A good answer says which you would pick: a queue for scoreboard expected-transaction lists, an associative array for a 4 GB address space you touch in only a few thousand places.

Classes, handles and polymorphism

"What does b = a do for class objects?" It copies the handle, not the object, so both names point to one object. A shallow copy (new a) copies fields but shares nested handles; a deep copy needs a hand-written copy() method that clones every member object. Most mid-level candidates stumble here.

For polymorphism, the interview points are: a method must be declared virtual in the base class for the derived override to be called through a base handle; $cast performs a checked downcast at runtime; and pure virtual methods in an abstract class force subclasses to implement an interface. UVM factory overrides depend entirely on this mechanism, which we revisit in UVM interview questions.

class packet;
  rand bit [7:0] len;
  virtual function void show(); $display("base %0d", len); endfunction
endclass
class bad_pkt extends packet;
  function void show(); $display("bad %0d", len); endfunction
endclass
packet p = bad_pkt::new();  // p.show() prints "bad"

Randomization and constraints

Common questions: what is the difference between rand and randc, how does solve a before b change the distribution, and why does randomize() return 0? randc cycles through every value of its range before repeating, so an 8-bit randc gives a 256-item permutation, but the permutation cost grows with width, so tools limit it to small fields. solve before does not change the legal solution set, only the probability of each: it is useful when a one-bit flag would otherwise be hit 1 time in 2³².

A failed randomize() means constraints conflict. Always check the return value with an assertion, because VCS, Xcelium and Questa all return 0 silently when you ignore it. See our deeper guides on constrained randomization and SystemVerilog constraints.

• inside and dist shape values: dist {0:=70, [1:9]:/30} gives 70 percent zero, and the range shares 30 percent in total.
• pre_randomize() and post_randomize() are hooks for setup and derived fields such as CRC.
• randomize() with { ... } adds inline constraints without editing the class.
• Seed stability: the same seed reproduces the same stream only if the thread and object creation order is unchanged.

Key fact: Constraints are bidirectional. a > b restricts both variables at once, and function calls inside constraints are evaluated before solving, so their results act as constants.

Interfaces, modports and race-free sampling

An interface bundles signals and, optionally, tasks and assertions. A modport gives each user a directional view: the DUT sees input req, the monitor sees everything as input. The usual follow-up is "how does the class-based testbench reach a static interface?" Answer: pass a virtual interface handle through the config database or a constructor. Details are in SystemVerilog interfaces and modports.

Race conditions are the deeper question. If a testbench drives signals at the same clock edge the DUT samples them, the result depends on scheduler order. A clocking block samples inputs in the Preponed region (just before the edge) and drives outputs in the Re-NBA region (after the design has settled), so the testbench never races the design. A program block achieves a similar effect by executing in the Reactive region, though most teams now rely on clocking blocks plus UVM.

Assertions: the timing questions

You will be asked to write a property: "grant must arrive within 1 to 4 cycles after request". The idiom is req |-> ##[1:4] gnt. Know the difference between overlapped |-> (consequent starts in the same cycle) and non-overlapped |=> (next cycle). Know that immediate assertions evaluate like a statement, while concurrent ones are sampled on a clock edge using Preponed values.

Bonus questions include $rose, $past, disable iff (rst), and throughout. Remember that an assertion that never has its antecedent true passes vacuously, so pair each one with a cover property. Our article on SystemVerilog Assertions covers sequences in depth.

Functional coverage versus code coverage

Code coverage (line, toggle, FSM, branch) tells you what RTL executed; functional coverage tells you which specified behaviours you exercised. 100 percent code coverage with 40 percent functional coverage means your tests ran the code but never reached the interesting scenarios. A covergroup has coverpoints, bins, cross and optional ignore_bins / illegal_bins.

A cross of a 4-value opcode and an 8-value size creates 32 bins; interviewers ask how you prune it. Answer with binsof filters and by sampling only on valid-transaction events. Read more in functional coverage in SystemVerilog. Teams at Avecas use the same coverage-driven closure loop on customer projects, and ChipXpert trains candidates on it.

Key fact: Coverage-driven verification is a loop: randomize, collect coverage, find holes, tighten constraints or add directed tests, repeat until sign-off. Merged databases come from tools such as Synopsys VCS/Verdi, Cadence Xcelium/IMC and Siemens Questa.

How to answer under pressure

• State the rule first, then a one-line example, then the pitfall.
• Mention the simulator behaviour you have actually seen, such as a silent randomize() failure.
• Draw the scheduler regions when asked about races; it shows depth.
• For DPI and C-model questions, point to SystemVerilog DPI.

Ready to practise these topics hands-on with labs, mock interviews and real simulator runs? Explore the verification tracks in our CourseTron courses and start building an interview-ready portfolio.

FAQ

Is SystemVerilog enough to get a verification job?

It is the foundation, but most employers also expect UVM, basic protocol knowledge such as AXI or APB, and scripting in Python or Perl.

What is the difference between a mailbox and a queue?

A mailbox is a built-in thread-safe FIFO with blocking get and put, ideal for passing transactions between processes. A queue is a plain data structure with no blocking behaviour or synchronisation.

Why does my randomize() keep returning 0?

The constraints are contradictory, a constraint block is disabled while a field is fixed by rand_mode(0), or a state variable has been set outside the legal range. Enable the solver debug option in your simulator to see the conflicting lines.

Should I use a program block?

Most modern flows skip it and use clocking blocks with UVM, because program blocks add restrictions and offer little over a properly written clocking block.