How to think like a Verification Engineer

To think like a verification engineer is to do far more than write a few tests. After reading the specification you plan the test strategy, decide what to check at which level, and pick the methodology that fits. Strong engineers focus on what to verify and why it matters, rather than jumping straight to how. Once your what and why are clear from the spec, more than half of the job is already done. This post shows how to build that thinking, with the classic prompts interviewers use.

A simple way to picture it

Imagine you are a building inspector, not the builder. The builder (the designer) follows the plan and expects it to work. Your job is to walk through every room, open every door, flip every switch in a strange order, and try the odd cases the builder never thought about: what if two people use the lift at once, what if the power drops mid-cycle, what if someone presses stop and start together. You are paid to find the problem before the customer does. That mindset, curious and a little bit stubborn, is what turns a spec into a test plan.

Why the thought process beats memorising syntax

Syntax you can learn from any tutorial in a weekend. What separates a strong engineer is the ability to look at a design and imagine dozens of ways it could misbehave. Here is why that matters:

• Bugs hide in the cases nobody wrote down. The spec lists the normal behaviour; bugs usually live in the gaps between rules.
• Tools change, thinking does not. Whether you use SystemVerilog or UVM, the same questions apply: what are the inputs, what are the illegal combinations, what happens at the boundaries.
• Good scenarios drive everything else. Your checkers, scoreboard, and functional coverage all come from the list of scenarios you imagined first.
• Interviewers test this directly. They rarely ask you to recite a class definition. They hand you a everyday object and ask you to verify it.

A repeatable method: how to turn any spec into test scenarios

Interviewers love to hand you an everyday object and say “verify it”. The trick is to always follow the same steps, no matter the object:

1. Understand the spec and ask questions. List every mode, input, output, and rule. Write down every doubt and clear it before you start.
2. List normal (positive) scenarios. The things that should work when everyone behaves.
3. List negative scenarios. Illegal inputs, wrong order, values out of range.
4. List corner and boundary cases. The first value, the last value, zero, maximum, and the exact moment a mode changes.
5. List timing and concurrency cases. What happens when two things happen at once, or when an event lands right on a clock edge.
6. Add reset, power, and error recovery. Reset in the middle of activity, brown-out, and recovery after an error.
7. Decide the checks. For each scenario, how will you know it passed? That becomes your checker, scoreboard, or undefined.

Example 1: verify a traffic signal

First, understand the lights. Red means stop before the crossing line. Green means go. Yellow means stop, unless you have already crossed the stop line, or you are so close that braking hard would cause a crash, or you are in the middle of the junction and should clear it. Note that the yellow (amber) has its own colour and timing.

Positive and sequence scenarios

• The lights are on during the expected traffic hours as per the rules.
• The timer for each signal matches the specified duration.
• The colours appear in the correct sequence (for example green, then yellow, then red).
• Stop is shown with red, caution with yellow or amber, and go with green.
• Only one light is on at a time for a given direction.
• During off-hours the signal shows a blinking yellow or amber as the rules require.

Timing, corner, and cross-junction scenarios

• The delay between one light turning off and the next turning on is correct (no gap where all are off unless specified).
• Multiple signal posts at a crossroads stay in sync so opposing directions are never both green.
• What happens on power-up: does it start in a safe state (often all-red or blinking)?
• What happens if the timer input is corrupted or set to zero?
• Pedestrian request handling, if the spec includes a walk signal.

An interviewer may then ask you to write the checker or scoreboard for this, or to describe the coverage you would collect. Coverage here could include every colour, every legal transition, and the off-hours blink mode.

Example 2: verify a coffee vending machine

This one tests whether you think about money, stock, and user mistakes, not just the happy path.

• Positive: insert exact money, pick a drink, receive the correct drink and no change.
• Change handling: insert more than the price and check the correct change is returned.
• Not enough money: the machine waits, shows the shortfall, and does not dispense.
• Out of stock: the selected drink is empty; the machine refuses and refunds.
• Cancel: the user cancels mid-way and gets a full refund.
• Concurrent presses: two buttons pressed together; only one valid selection is honoured.
• Corner cases: exact change unavailable, coin jam, power loss mid-transaction, then recovery.
• Coverage: every drink, every payment path (exact, over, under), every error path.

Example 3: verify a 2×2 port packet switch

A 2×2 switch takes packets on two input ports and routes them to two output ports based on an address field. This checks whether you think about routing, arbitration, and buffering.

• Basic routing: a packet from each input reaches the correct output based on its destination field.
• Both inputs, different outputs: two packets flow at once with no interference.
• Both inputs, same output (contention): both packets target one output; check the arbitration (round-robin or priority) and that no packet is lost.
• Back pressure: the output is not ready; check that the switch stalls the input rather than dropping data.
• Packet integrity: payload and header arrive unchanged; length is preserved.
• Corner cases: minimum and maximum packet length, empty packet, malformed header, buffer full.
• Ordering: packets to the same output keep their order.
• Coverage: every input-to-output pair, contention on each output, and every packet size class.

Example 4: verify a single-port RAM (one port for read and write)

A single-port RAM allows either a read or a write in a cycle, not both. This checks whether you think about address ranges, data integrity, and access conflicts.

• Write then read back the same address returns the same data.
• Walk the full address range: write a known pattern to every location and read it all back (a common memory test).
• Address boundaries: location 0 and the last location behave correctly; out-of-range access is handled per spec.
• Data patterns: all zeros, all ones, alternating 0101 and 1010, and walking-ones patterns catch stuck bits and shorts.
• Read/write conflict: since one port serves both, confirm the design blocks or serialises a read and write to the same cycle.
• Reset behaviour: contents after reset match the spec (some RAMs are undefined, some clear).
• Back-to-back access: write, write, read, read at the same and different addresses.

Example 5: verify a simple 4-bit ALU

A common prompt: an ALU with two 4-bit operands, a 4-bit result, carry and overflow flags, and up to 8 operations selected by a 3-bit opcode (S2, S1, S0). This checks whether you cover every operation and every flag condition.

• Every opcode: exercise all 8 operations (for example add, subtract, AND, OR, XOR, and any shifts) and confirm the result matches a reference model.
• Carry cases: additions that do and do not produce a carry out.
• Overflow cases: signed additions and subtractions that cross the signed range so overflow is set correctly.
• Operand corners: 0, 15 (all ones), 8 (sign bit set), and mid values for both operands.
• Full input sweep: with only 4-bit operands, all 16 x 16 x 8 combinations are small enough to test exhaustively, which is a nice point to raise in an interview.
• Illegal or reserved opcodes: confirm the defined behaviour for any unused opcode.
• Coverage: a cross of opcode against operand corners, plus carry and overflow both high and low.

Because the input space is tiny here, you can compare the design against a golden model over every input. For larger designs that is impossible, which is exactly why constrained random and coverage exist. See the difference between directed and constrained-random testing in our directed vs constrained-random guide.

How do you track progress on a verification project?

Progress is measured against the verification plan, which captures the features to verify as directed tests or as coverage points. The plan also records the testbench pieces to build: stimulus generator, checker, monitor, and scoreboard.

• Early stage: track how complete the environment is (generator, checker, monitor) and how many planned tests and coverage monitors are written.
• Mid stage: once tests and a constrained-random generator exist, run them as nightly regressions on a server farm.
• Ongoing metrics: regression pass rate, bug-find rate over time, and functional coverage numbers.
• Trend reading: a falling bug rate with rising coverage is the healthy sign you are converging.

How do you know when verification is complete?

This is one of the most asked questions. In theory, verification is complete when the design behaves exactly as the specification for every possible input, with no errors. In practice you can never apply every input, and time and resources are limited. So completeness becomes a level of confidence built from a set of metrics and reviews that lower the risk of a hidden bug.

Teams usually rely on this checklist to gain confidence:

• Review the verification plan against the design spec so every detail is understood and captured.
• Confirm the environment, tests, and coverage monitors are all built against the reviewed plan.
• Review the stimulus generator and its constraints, the checkers, the assertions, and the coverage monitors.
• Run every test in regression for weeks with no failures, and reach all coverage goals with each explained.
• Drive open bugs to zero, or clearly understand why any remaining item has no design impact.
• Review waveforms for the important scenarios by eye.
• Complete formal verification wherever it applies.
• Compare the bug-arrival trend against past successful projects of similar size.

For the mechanics of coverage closure, see our functional coverage posts, and for protocol and timing checks see assertions.

Common mistakes that reveal a weak thought process

• Jumping to code before listing scenarios. The list should come first.
• Testing only the happy path and forgetting illegal inputs and error recovery.
• Ignoring reset, power, and clock corner cases.
• Forgetting concurrency: two events at the same time often expose the worst bugs.
• No checker or scoreboard, so a test “passes” without actually verifying anything.
• Not mapping each scenario back to a coverage point, so you cannot prove you tested it.

Expected output, in plain words

The scenario lists above are a way of thinking, not a captured simulator run. When you turn them into real tests, your checker or scoreboard should flag any mismatch between the design and a reference model, and your coverage report should show each planned scenario as hit. The exact numbers and random values depend on your seed and your simulator, so confirm behaviour on your own tool or on EDA Playground.

Frequently asked questions

Share this post: on Twitter on Facebook