Verification Interview Questions

I build four layers. A bound protocol checker catches illegal timing at the interface. Monitors feed a reference model and an ID-aware scoreboard, which catch wrong data, lost beats and illegal reordering. Constrained-random and directed stimulus add adversarial backpressure (stall patterns chosen to stress the design) on every channel. Functional coverage tracks attributes, concurrency and stalls. I call it done when no checker fires, coverage is closed with reviewed waivers, and the bug-find rate has flattened.

It replaces the protocol checker and much of the stimulus and protocol coverage. That holds only once it is configured to match the interface: widths, ID bits, outstanding limits and optional signals. It does not replace the reference model, the scoreboard, or the design-specific legal subset. It also does not replace a review of its own configuration. A misconfigured VIP silently checks a different interface from the one you built.

Break each rule once, on purpose, with a small fault in a test agent. Check that the VIP reports it, at the right edge. A checker whose antecedents never fired has checked nothing. Keep these fault tests in regression, so an upgrade or a config change that silences a rule shows up.

Random traffic misses corners that need one exact value, such as a burst ending exactly at a 4 KB edge. Others are a WRAP in the top address window and the longest burst at the largest size. So are every ID in flight at once, a stall on the last beat, and reset during a burst. Uniform randomness gives each of these about zero probability. Add weighted constraints toward edges, directed tests for the extremes, and coverage bins that name each corner.

Bind a checker on every port, and replace the per-port scoreboards with one end-to-end scoreboard. It models the address decode and the ordering per manager and ID. It also models the ID bits the interconnect adds on the way in and removes on the way out. Add system checks: no response to the wrong manager, decode errors for address holes, and bounds on fairness and starvation. Formal suits the decoder and ID logic, while simulation covers data integrity and performance.

I bring a plan-to-evidence table. It maps every spec rule to a property or scoreboard check, each passing in regression with its antecedent (trigger side) covered. Beside it go closed functional coverage with designer-signed waivers, and explained code coverage holes. I add open bugs at zero or deferred in writing, plus the recent bug-find rate. Then comes the honest part: what was not verified, and why the risk is accepted.

Sample from the passive monitor when a transaction completes, not from the driver when it is issued. Cover the attributes: burst, length, size, alignment, and distance to a 4 KB or wrap boundary. Cover concurrency: outstanding depth, ID reuse and interleaving. Add backpressure (stall length per channel, including the last beat), every response type, and reset mid-transaction. Cross only the fields that interact. A cross of every field gives thousands of bins that nobody closes.

Coverage should record what the design actually did. The monitor sees only accepted transactions, with their real response and timing. It also works the same when the agent is passive (only watching) in a larger environment. Sampling at completion lets a bin record the response and the stall pattern. The driver cannot know these when it sends the item.

Say a write is driven, but reset aborts it before the handshake. The driver has already counted a write of that kind. The bin closes, yet the design never completed it. Driver coverage measures what the stimulus asked for, not what the design did.

Code coverage finds RTL that no test reached, such as an error path or an unused state. Nobody has to think of these in advance. Functional coverage checks that the scenarios the spec and plan care about happened. That includes combinations and sequences that no single line of code represents. Code coverage cannot see a missing feature and functional coverage cannot see dead code, so you need both.

Start from the legal set, not the raw one. On a 32-bit bus Size is 1, 2 or 4 bytes, and INCR allows 256 lengths, FIXED 16 and WRAP 4. That gives 3 x (256 + 16 + 4) = 828 legal combinations, against 6,144 raw. Then bucket the lengths where behaviour does not change: 1, 2 to 15, 16, 17 to 255, and 256. That leaves a few dozen bins, and each one means something.

Most likely the bench kept BREADY and RREADY high, so the subordinate's response-side stall path never ran. Every stall rule then passed vacuously, because no stall ever happened. The coverage model also had no stall-length bins on B or R. Randomise ready with long low runs on every channel the testbench drives, and cover stall length per channel. Also count how often each checker antecedent matched.