I do not memorize a perfect answer. I use a simple shape: clarify the requirement, choose a mechanism, give one concrete example and name the evidence or tradeoff.

A sample answer

For “assertion or scoreboard,” I would say that an assertion suits a local timing rule such as grant within three cycles. A scoreboard suits an ordered result that needs prediction and state. On a bus agent I may use both because protocol legality and data correctness are different questions.

Key takeaway: the interviewer is listening for judgement. Show why you chose the technique and what you would inspect when it fails.

I use this before writing a test plan. The goal is to separate stated behavior from assumptions and to expose the conditions that are easy to miss in normal traffic.

Practical example

For a FIFO, “supports simultaneous read and write” is incomplete. Ask whether it applies at empty and full, whether occupancy changes, what data appears on the output and when flags update. Each answer becomes either a test, an assertion or a coverage point.

Key takeaway: an unanswered question is safer in a review list than as silent behavior inside a reference model.

A clocking block declares when the testbench samples and drives interface signals relative to a clock event. That removes accidental dependence on simulator scheduling order and makes driver and monitor intent visible in the interface.

How I use it

The driver writes through clocking block outputs. The monitor reads clocking block inputs. I still decide the protocol timing explicitly. A clocking block prevents a race; it does not decide whether request should remain high until grant.

Key takeaway: consistent sampling removes testbench ambiguity, so a cycle mismatch is more likely to expose a real protocol misunderstanding.

clocking cb @(posedge clk);
  default input #1step output #0;
  output req, wdata;
  input  gnt, rdata;
endclocking

cb.req   <= 1'b1;
cb.wdata <= payload;
@cb;
if (cb.gnt) begin
  // The monitor sees a stable sampled value.
end

I think of build as creating the testbench structure and connect as wiring communication after that structure exists. This is not ceremony. It gives structural failures a predictable place.

A useful debug order

If the scoreboard receives nothing, first print the topology. Then confirm the monitor exists and has the expected virtual interface. Next inspect the analysis port connection. Only after those checks should you debug transaction contents.

Key takeaway: prove hierarchy, configuration and connectivity before blaming run phase behavior.

Say the requirement first: “When request rises, grant must arrive one to three cycles later, unless reset is active.” Then map the clock, reset, trigger, implication and response window one phrase at a time.

Boundary traces

Write four tiny waveforms before coding. Grant at one, two and three cycles must pass. Grant at four cycles must fail. Also test a request just before reset so you know whether the active attempt should be aborted.

Key takeaway: operators are easier to choose after the pass and fail boundaries are unambiguous.

property p_req_gets_grant;
  @(posedge clk)
  disable iff (!rst_n)
  $rose(req) |-> ##[1:3] grant;
endproperty

a_req_gets_grant:
  assert property (p_req_gets_grant);

Do not write a new random test until you know what kind of hole you are looking at. Start with one uncovered bin and trace the evidence from stimulus to accepted interface event to monitor sample.

Practical example

Suppose the cross of full, read and write is empty. A transaction log may show both commands were generated, while the interface trace shows read was blocked before acceptance. That is a stimulus or sequencing issue, not a covergroup issue.

Key takeaway: coverage closure is an investigation. The outcome can be a new test, a monitor fix, a model correction, a design bug or a justified exclusion.

When a test fails, the log points at the last check that fired. By then the design may have been wrong for hundreds of cycles. Everything after the first wrong cycle is a consequence, and consequences make poor clues, because they show the damage the original divergence caused rather than the divergence itself.

A worked example

Suppose a scoreboard reports wrong data at cycle 940 and two assertions fire at cycles 955 and 990. The instinct is to open the waveform at cycle 940. Instead, take the earliest failing check and walk backwards from it. Imagine the trace shows the grant still high at cycle 812, one cycle after the request dropped. The divergence sentence is: the grant stayed high one cycle after the request dropped. Everything at 940, 955 and 990 follows from that one extra cycle of grant. One sentence, one place to look, instead of three symptoms competing for attention.

Where assistance helps and where it does not

Tools, including AI assistants, are good at the clerical half of triage: clustering failures by the first check that fired, summarising long logs, and listing which tests share an earliest timestamp. They are not good at the judgement half: deciding which divergence came first in causal terms, or whether the checker or the design moved. Keep the clustering mechanical and the cause human.

Key takeaway: name the first divergence in one plain sentence before touching the fix. If the sentence cannot be written, the failure is not yet understood.

A synchronizer does not make CDC safe in general. First name what crosses and what the destination must preserve. Then choose a structure and verify its protocol assumptions.

Practical example

A one cycle pulse from a 200 MHz source can fall entirely between edges of a 50 MHz destination. Two flops reduce metastability risk only if an edge samples the level. A toggle converts the event into a persistent state change; a handshake also provides backpressure when events may arrive quickly.

Key takeaway: metastability, event loss, incoherent data and reconvergence are related but different failure modes.

Every team that tapes out has a story about the bug that reached silicon. I am never that interested in the bug. I am interested in the door it walked through. A bug that survives to silicon has usually had several chances to be caught, and those chances belong to different parts of the flow: the specification, the stimulus, the checking, the triage, and the model. When I look at an escape, I sort it into one of five doors before I look at the fix, because each door has a different fix, and fixing the wrong door feels productive while changing nothing.

Door one: the spec never said it

The requirement was missing, ambiguous, or read in two different ways by two teams, each of them faithfully. Suppose a register description says a status bit is cleared on reset. The design team reads reset as the power on reset. The verification team reads it as any reset, including the warm reset the software team uses every day. Both implementations agree with the sentence. The bug is in the sentence.

The smell is agreement everywhere except at the system level: the block is right, the test is right, and the chip still misbehaves. The countermeasure is to read the specification as an adversary. Every sentence that two engineers can read two ways becomes a written question to the architect, asked before the testplan is agreed, not after the failure.

Door two: the stimulus never went there

The design was exercised hard, just never in the one state where the bug lives. Random testing is good at common behaviour and poor at coincidences. Suppose a FIFO misbehaves only when a push and a pop arrive in the same cycle while it holds exactly one entry. Each condition alone is ordinary. Together they are rare, and a single constraint written to keep tests simple, one that quietly forbids simultaneous push and pop, removes the combination from the space entirely.

The smell is coverage that looks complete at the level of single bins while the crosses between bins were never a target. The countermeasure is to name the corners before trusting the random: write the directed test, or the covergroup cross, for every combination the design team mentions with the words that can never happen. Then read every constraint and ask what legal behaviour it forbids, and whether you truly want it forbidden.

Door three: the check never looked

The stimulus reached the bug, the design produced the wrong answer, and nothing complained. The scoreboard compared the data but not the order it arrived in. Or the assertion existed and passed every night because it was vacuous: its trigger never fired, so it checked nothing, politely, for months.

The smell is a test that cannot fail. The countermeasure is to prove that every important check can fail. Take a scratch copy of the design, break it on purpose, and watch the check fire. An assertion that has never failed has never really been tested, and a checker that has never caught anything is a decoration.

Door four: the check fired and nobody listened

This is the door nobody wants to own, because it is a process failure wearing a technical costume. The failure appeared in a regression, was labelled a known issue or blamed on the testbench, and was carried from one milestone to the next until it shipped. Nothing about the design hid it. The organisation filed it.

The smell is a waiver list that only grows, where entries have no owner and no date. The countermeasure is discipline, not tooling: every waived failure carries a name, a reason, and an expiry, and a waiver that survives two milestones is reviewed again as if it were a new bug, because by then it is one.

Door five: the environment lied

The reference model shared the design team's misunderstanding, so the design and the model were wrong in the same way and every comparison passed. Or the testbench treated the hardware more kindly than silicon will: resets released too cleanly, unknown values resolved optimistically, a clock crossing exercised only at a friendly ratio.

The smell is perfect agreement, early, between a model and a design that were both written from the same reading of the same document. The countermeasure is independence. Build the model from the specification text, not from the RTL and not from the designer's slides, and treat a long run of perfect agreement at the start of a project as a warning rather than a comfort. Models earn trust by disagreeing sometimes and being right.

Keep an escape log

When a bug escapes, write down the door, not only the bug. Across one project the log starts to show a pattern, and the pattern is almost never that we need more tests. It is one door, opened again and again by the same habit. Fix that habit and the next project starts stronger than the last one did.

Key takeaway: an escape is a flow failure with a bug attached. Every escape should leave two things behind: a regression test that would have caught it, and one line on the checklist the team actually reads.

Chips keep getting bigger and schedules do not. So the interesting question in verification is no longer who can write the most tests. It is which new methods actually hold up on real projects. These are the six technologies I see changing daily DV work, explained the simple way I would explain them to a colleague who asked me what is new.

1. AI assistants in the testbench

The simple version: a language model reads your code, your specification, and your logs, and drafts the clerical parts of the job. A first version of a driver. An assertion for a behaviour you describe in words. A summary of a failure log that runs to thousands of lines. Machine learning also works quietly inside regressions, learning which tests have historically caught bugs and running those first.

What it changes: the sorting and drafting get faster, the judgement does not move. The model does not know your design intent, and it will hand you a confident wrong answer if you let it. The engineers getting real value treat it as a fast junior colleague whose work always gets reviewed.

2. Formal verification for everyone

The simple version: instead of writing tests and hoping one of them reaches the bug, you state a rule, this FIFO never overflows, and a solver proves the rule for every possible input, or hands you the one sequence that breaks it.

What it changes: formal used to belong to specialists. Packaged formal apps now check the common problems, clock crossings, register behaviour, connectivity, stuck states, with far less setup, so ordinary block teams run them as routine. Formal proves small control heavy blocks and rare corners that random testing reaches slowly. It complements simulation. It does not replace it.

3. Emulation: running the chip before it exists

The simple version: the design is mapped onto special hardware and run there, fast enough to boot software and execute real workloads long before tapeout, work that would take a simulator an unreasonable time.

What it changes: the bugs that only appear after millions of cycles become findable: firmware interacting with hardware, long packet streams, power state sequences. In most companies emulation time is a shared and scarce resource, so teams plan it the way they plan anything precious, and the planning itself improves the tests.

4. Portable stimulus: write the scenario once

The simple version: a standard from Accellera lets you describe what a test should achieve at a high level, as a scenario, and then generate the real test for simulation, for emulation, or for silicon from that one description.

What it changes: today the same scenario is rewritten at block level, again at chip level, and again on silicon, and the three versions quietly drift apart. Portable stimulus carries the intent across all three, so system level coverage connects back to the block level work instead of starting over.

5. Open source tools grew up

The simple version: Verilator compiles a design into a fast software model. cocotb lets you write a testbench in Python. Both are free, both are used on real projects, and both are good enough that the licence budget is no longer the gate it was.

What it changes: students and small teams can build a serious flow from nothing, and large teams use these tools for fast checks and experiments outside the main flow. It is also how a generation of engineers is learning verification in public, sharing testbenches the way software engineers share code.

6. Chiplets changed the unit of verification

The simple version: instead of one large die, companies now combine several smaller dies, called chiplets, in a single package, connected by standard links such as UCIe.

What it changes: verification must now prove that dies from different teams, sometimes different companies, behave together: the interconnect, the power behaviour, and the error handling when one die misbehaves. The block level skills stay exactly the same. The system level questions multiply.

The pattern underneath

Look at the six together and one pattern shows. Verification is moving from writing more tests to aiming the tests better. Formal aims by proof. AI aims by sorting and drafting. Emulation runs the long scenarios simulation cannot. Portable stimulus carries the aim from one stage to the next. The tools keep changing. The judgement about what to aim at stays yours.

Key takeaway: innovation in DV is not one tool. It is a shift: prove what you can prove, automate the clerical work, run the long scenarios on hardware, and spend your own hours on the judgement calls none of these tools can make.