33 SystemVerilog Interview Questions and Answers

bit is 2-state (0,1), logic is 4-state (0,1,x,z); logic removes the wire-vs-reg confusion: it can be driven by assign or by a procedural block (but only one continuous driver); still use wire for multiple drivers (tri-state buses)

Common mistake: Saying logic can have multiple drivers

Interviewer may ask next: What happens if you drive a bit with x?

• int: 2-state signed 32-bit
• integer: 4-state signed 32-bit
• byte: 2-state SIGNED 8-bit (-128..127)
• Bit [7:0]: 2-state UNSIGNED 8-bit (0..255)

Common mistake: Saying byte is unsigned

• Packed: dimensions before the name (bit [3:0][7:0] a), stored as one contiguous vector, can be sliced and used in arithmetic
• unpacked: dimensions after the name (int a [4]), each element stored separately, any type allowed
• Packed only for single-bit types

Interviewer may ask next: How many bits is bit [3:0][7:0] x [2]?

• Fixed: size known at compile time
• dynamic: size set at run time with new[], good for variable-length packets
• associative: sparse, indexed by any key, good for memory models with large address space
• queue: variable size with push/pop at both ends, good for scoreboards

Interviewer may ask next: Which methods do you use to walk through an associative array (first, next)?

• Dynamic array must be resized with new[] (old content copied only if you pass it)
• Queue grows/shrinks automatically with push_back/push_front/pop
• Queue supports insert/delete anywhere
• Dynamic array is slightly faster for fixed-after-allocation data

always_comb runs once at time 0 even without events, is sensitive to signals inside called functions too, tools warn if it infers a latch, and the variables cannot be written by another process; always @(*) has none of these checks

Common mistake: Saying they are exactly the same

Interviewer may ask next: What are always_ff and always_latch for?

• join: wait for ALL child threads
• join_any: continue when ANY one finishes (others keep running)
• join_none: continue immediately, children run in background
• Use disable fork / wait fork to control leftover threads

Common mistake: Thinking join_any kills the remaining threads

Interviewer may ask next: Inside a for loop with fork-join_none, why do you need an automatic copy of the loop variable?

• Program is testbench-only: cannot contain always blocks, modules or interfaces instances
• Its initial blocks run in the Reactive region, after the DUT settles, so the testbench samples stable values
• $finish is called automatically when all program initial blocks end

Interviewer may ask next: Why is program block rarely used in UVM testbenches?

• Initial runs at time 0
• Final runs at the end of simulation (after $finish), in zero time, used for printing summaries/coverage reports
• Final cannot have delays

• By value: argument copied, changes inside do not affect caller
• ref: the subroutine works on the original variable, changes are visible to caller, saves copying large arrays
• Const ref prevents modification
• Ref only allowed in automatic subroutines

• struct: static data grouping, no methods, value type, synthesizable (packed struct)
• class: dynamic object created with new, has properties and methods, supports inheritance, polymorphism, randomization
• Handle points to object

• Inheritance: extend a base transaction/driver for new tests without editing it
• polymorphism: base handle calls the extended method, enabling factory overrides
• encapsulation: local/protected hide internals
• Reusable layered testbench components

Common mistake: Listing OOP terms without linking to testbench examples

Interviewer may ask next: Give an example of using inheritance to create an error-injection transaction.

• This refers to the current object, used to separate class property from same-named argument (this.addr = addr)
• Super refers to the parent class, used to call parent methods/constructor (super.new(), super.build_phase(phase))

• Virtual method: the call is resolved by the object type, not the handle type, enabling polymorphism
• Pure virtual: declared with no body inside a virtual (abstract) class and must be implemented by any non-abstract child class

Common mistake: Saying a virtual class can be instantiated

Interviewer may ask next: What prints if a base handle points to an extended object and the method is NOT virtual?

• Non-virtual: base version runs (decided by handle type)
• virtual: child version runs (decided by object type)

• Shallow copy (new obj_h) copies the property values and handles, but nested objects are SHARED
• Deep copy also creates new copies of nested objects, so the copy is fully independent
• Deep copy needs a user-written copy() method

• local: visible only inside that class, not even in children
• protected: visible inside the class and its children, not from outside
• Default is public

• Parameterised class takes a type or value parameter (e.g. class fifo #(type T = int)), each specialization is a different type
• :: accesses static members, declares methods outside the class (extern), and accesses package items

• Bundles related signals (e.g. all APB signals) into one object
• Avoids long port lists and connection mistakes
• Can include modports, clocking blocks, tasks, assertions and coverage
• One change in the interface updates every connection

• Defines direction views of an interface for each user (e.g. master, slave, monitor)
• Restricts who can drive which signal
• Can include clocking blocks and tasks
• A module port can be declared as intf.master

• Groups signals synchronous to one clock and defines when the testbench samples and drives them
• Input skew: sample that much BEFORE the clock edge (#1step = just before, in Preponed region)
• Output skew: drive that much AFTER the edge
• Removes testbench-DUT races

Common mistake: Saying input skew delays the input

Interviewer may ask next: What does default input #1step output #0 mean?

• Classes are dynamic and cannot contain static interface instances, so a class holds a virtual interface handle that points to the real interface in the top module
• In UVM it is passed through uvm_config_db

• Mailbox: built-in class for passing messages between threads, get() blocks when empty, put() blocks when bounded and full
• queue: plain data structure, no blocking
• semaphore: key bucket that controls access to a shared resource (get/put keys), e.g. two drivers sharing one bus

Interviewer may ask next: Bounded vs unbounded mailbox?

• Direct Programming Interface lets SV call C functions and C call SV
• import: SV calls a C function (e.g. reference model in C)
• export: SV function made callable from C
• Data types must map (int, byte, chandle)

• A hook method left empty in a base component that users fill in by extending a callback class and registering it
• Adds behaviour (e.g. error injection, extra checks) without editing the original code

• Transaction (data), generator (creates randomized transactions), driver (converts to pin wiggles via interface), monitor (watches pins, rebuilds transactions), scoreboard (compares with reference model), agent (driver + monitor + generator), environment, test, top module

Common mistake: Missing the monitor or scoreboard

Interviewer may ask next: How do generator and driver communicate?

• Covers many combinations directed tests miss, finds corner-case bugs, constraints keep values legal, weights steer distribution, one test can run with many seeds
• Measured with functional coverage

• rand: each value random, repeats allowed
• randc: random-cyclic, goes through all values in the range before any value repeats
• Randc limited to smaller bit widths by tools

Interviewer may ask next: How would you implement randc behaviour without randc?

• Callback functions automatically called before and after randomize()
• pre: set up or turn off constraints
• post: compute dependent fields like CRC/parity from the random values

constraint_mode(0) on a constraint block (obj.c_name.constraint_mode(0)); rand_mode(0) on a variable to freeze it; check randomize() return value; can also use inline constraint with randomize() with { }

• Constraints are solved together, not top to bottom
• A constraint on b can restrict a even if written as a -> b
• Use solve-before to change probability distribution (not the legal set)

Common mistake: Thinking constraints execute line by line

Interviewer may ask next: What does solve a before b change?

• := gives the weight to EACH value in a range
• :/ divides the weight equally across the range
• E.g. [1:4] := 10 gives each value weight 10 (total 40), [1:4] :/ 10 gives each 2.5

Common mistake: Mixing the two

Randomizes variables that are not class members (local variables in a task/module) with inline constraints using with { }; no need to create a class