SystemVerilog Interview Questions for RTL and Verification Roles

Someone asks you to write a two-stage pipeline in SystemVerilog, and you type <= without thinking. Then they ask why, and what would happen if you used = instead. If your answer is "that's the rule," you have the habit but not yet the explanation.

This guide draws on Cliff Cummings' paper on nonblocking assignments, Sutherland HDL's paper Synthesizing SystemVerilog, ChipVerify's public tutorials on clocking blocks, randomization, and assertions, and a Verification Academy forum thread on testbench races. The practice prompts are ours, not questions reported from any employer.

What do logic and bit really mean?

Sutherland's paper says SystemVerilog added bit (2-state) and logic (4-state) keywords, and that synthesis treats the two the same. The 2-state and 4-state distinction only matters in simulation. It recommends logic for almost all declarations in RTL, and notes that 2-state types can hide design problems because a 2-state variable starts at 0 in simulation while real hardware may power up as either value.

"In RTL I use logic so an uninitialized register shows up as X instead of quietly looking like a clean zero." The paper adds that randomly generated testbench values are often better declared as bit, which is a nice detail for a verification interview.

Also mention that logic removes the old wire versus reg decision for most signals, but neither keyword creates a flip-flop by itself.

Blocking, nonblocking, and the always blocks

Cummings' paper lists guidelines that most style guides still echo: use nonblocking assignments for sequential logic, blocking assignments for combinational logic in an always block, do not mix the two in one block, and do not assign the same variable from more than one always block. His explanation is the part interviewers want. A nonblocking assignment evaluates the right-hand side early in the time step and updates the left-hand side later, so other blocks triggered by the same clock edge still see the old value.

Sutherland's paper covers the SystemVerilog blocks. It says always_comb lets tools infer a complete sensitivity list, runs once at time zero, and lets tools warn if the code actually infers a latch. always_ff needs an explicit clock edge because a tool cannot guess it, and tools can warn if no flip-flop results. It also says those warnings are optional in the standard and that, at the time of writing, lint and synthesis tools gave them while simulators did not. Its recommendation is to use the specialized blocks in all RTL and keep plain always for testbenches and models that will not be synthesized.

Say what the standard guarantees and what your own flow actually reports.

Verification constructs interviewers probe

For verification roles, expect the conversation to move into the testbench. The table below summarizes the public sources and pairs each topic with a practice prompt.

Topic	What the source says	Practice prompt
Nonblocking assignments	RHS evaluated early, LHS updated later in the time step (Cummings)	Why does a swap between two registers work with <= but not with = in separate blocks?
always_comb and always_ff	Tools infer sensitivity, document intent, and can check it (Sutherland)	What goes wrong with an incomplete if inside always_comb?
Clocking blocks	Input skew defaults to #1step, sampling just before the edge; drive through the block handle (ChipVerify)	Why does driving the interface signal directly reintroduce a race?
Randomization	Constraint blocks combine with AND, and randomize() returns 0 when they conflict (ChipVerify)	What happens to your variables if you ignore the return value?
Assertions	Concurrent assertions use sampled values and a clock; ##[1:4] gives a bounded delay (ChipVerify)	Write a check that an acknowledge follows a grant within four clocks.
Classes	Not from the sources above; our framing is that randomized items are class objects with constraint blocks	How would a derived item narrow a base class constraint?

For the class and constraint side, see our UVM interview guide. For how assertions fit alongside simulation, see formal verification versus simulation.

What does a good answer sound like?

Aim for a one-line definition, the reason it exists, and one way it fails. For clocking blocks that might be: "It defines when the testbench samples and drives relative to the clock, so the testbench and design do not touch the same signal in the same instant. If I bypass it and drive the raw signal, I lose that protection."

Do not oversell it. The Verification Academy thread says sampling inputs or using nonzero skews does not eliminate every race, especially across multiple clocks, and that program blocks run in the Reactive region, after design events are processed. People in that thread also disagree about whether program blocks are worth using. Saying "it depends on the testbench style, and here is what I would check" is more credible than a flat claim.

One debugging scenario: a race you can talk through

This scenario is illustrative and adapted from the feedback example in Cummings' paper. It is not a reported interview question.

Two always blocks are triggered by the same clock edge. One does y1 = y2 and the other does y2 = y1, both with blocking assignments. Cummings notes the standard allows either block to run first, so the result changes with execution order.

1. State the symptom: results differ between runs, tools, or tool versions, with no code change.
2. Ask what both blocks read and write on the same edge, and spot the shared variables.
3. Explain why order matters: with blocking assignments, the second block may see the already updated value.
4. Propose the fix: nonblocking assignments inside always_ff, so both blocks sample old values.
5. Say how you would check it: run lint for mixed assignment styles and compare against the gate-level result.

Then offer a second variant yourself: a testbench driving a signal at the same edge the design samples it is the same kind of race, and a clocking block is the usual fix.

Prepare the answers you will actually say

Pick one RTL block and one testbench you have really built, and be ready to explain the assignment choices, the reset style, and what you randomized. Our RTL design question guide and digital design guide on FSMs and pipelining give more practice on the design side. To see how these skills differ by job, read verification versus RTL design engineer roles, and use our role-by-role study index to plan the rest.

You can book a mock interview on MockVise to practice explaining a race out loud, which is harder than reading about one.

Sources: Cummings, Nonblocking Assignments in Verilog Synthesis (MIT copy), Sutherland and Mills, Synthesizing SystemVerilog, ChipVerify, Clocking Blocks, ChipVerify, Randomization, ChipVerify, Assertions, Verification Academy forum. This article offers general technical preparation guidance, not an official interview process or reported company questions. Tool behavior and standards details vary, so confirm them against the IEEE 1800 standard and your own tools, and confirm interview format with your recruiter. MockVise is not affiliated with or endorsed by Sutherland HDL, ChipVerify, Verification Academy, or any author cited here.

FAQ

Q: Why use nonblocking assignments for sequential logic? A nonblocking assignment evaluates the right-hand side early in the time step and updates the left-hand side later, so other blocks triggered by the same clock edge still see the old value. That avoids order-dependent races between blocks.

Q: Should I declare RTL signals as bit or logic? Sutherland's paper recommends logic for almost all RTL declarations, since 2-state types can hide design problems by starting at 0 in simulation. Randomly generated testbench values are often better declared as bit.

Q: How should I structure an answer to a SystemVerilog question? Give a one-line definition, the reason it exists, and one way it fails. Do not oversell it, since saying it depends on the testbench style and what you would check is more credible than a flat claim.

Q: What happens when randomization constraints conflict? Constraint blocks combine with AND, and randomize() returns 0 when they conflict. If you ignore the return value, your variables may not be randomized as you expect.