Q&A: Strategy Questions

Q: How would you verify a block from scratch?

Walk the lifecycle, not the testbench. Read the spec and extract a feature list; risk-rank it; write a plan with feature/approach/coverage/owner per row and get it reviewed with the designer. Choose the methodology mix per feature class — constrained-random for the wide datapath space, formal for handshakes and FIFO-control properties, directed for bring-up and exact scenarios. Build the environment (interface, stimulus, monitors, scoreboard, assertions, coverage), bring up smoke, then drive to feature-complete, coverage closure with hole analysis, and bug-rate convergence before sign-off.

spec → features → risk rank → plan + review
       → methodology mix → TB build → bring-up
       → feature-complete → closure (+ hole review)
       → convergence → sign-off review

Follow-up: "What do you do before writing any testbench code?" — Read the spec three times, log every ambiguity for the architect, and get the plan reviewed. Plan-review feedback is 100x cheaper than testbench rework.

Junior vs senior: a junior starts describing the driver and monitor immediately. A senior spends the first half of the answer before any code exists — features, risk, plan, review — because that is where projects are actually won or lost.

Q: How do you know when verification is done?

Done is evidence, not a feeling : (1) every verification-plan row is closed or explicitly waived; (2) merged functional coverage meets goal and every hole has a written disposition; (3) code coverage holes are reviewed; (4) the bug rate has converged — N consecutive weeks of full-volume regression without a new priority bug; (5) all open bugs are dispositioned. Any single metric alone is gameable; the combination is the sign-off case.

Follow-up: "Coverage is 100% but a bug arrives from silicon — what happened?" — Coverage measures what you planned to look for. The bug was outside the plan (missed feature), or the bin was too coarse to distinguish the buggy case, or the checker was too weak to fail when the bin was hit. Coverage closure proves the plan was executed, not that the plan was complete.

Junior vs senior: a junior answers "when coverage hits 100%." A senior lists the evidence bundle and immediately volunteers the limits of coverage as a proxy.

Q: Four weeks left and you cannot finish everything — how do you prioritize?

Re-rank by risk and descope explicitly . First protect the never-cut list: reset, CDC, power sequencing, and any feature with an open bug. Then rank remaining open plan rows by bug likelihood × silicon cost and cut from the bottom — typically redundant crosses, long-tail performance scenarios, and corners of well-proven reused IP. Every cut becomes a written waiver with an owner's approval, presented at sign-off. Finally, communicate the residual risk upward with a concrete ask, while there is still time to act on the answer.

Follow-up: "Your manager says cut the reset testing." — Push back with data: reset bugs are a top silicon-respin category and reset verification is cheap relative to that cost. Offer an alternative cut of equal schedule value and lower risk. If overruled, get the waiver in writing with the risk spelled out.

Junior vs senior: a junior works overtime and cuts silently whatever did not get done. A senior makes the cut list explicit, risk-ranked, approved, and documented — the project decides, not the calendar.

Q: Directed or constrained-random — how do you decide?

By the shape of the scenario space. Directed wins when the scenario is exact and enumerable — bring-up, spec-mandated sequences, bug reproduction. Constrained-random wins when the space is wide and the bugs are in combinations you would not enumerate — but it only pays off with a scoreboard to catch failures and coverage to prove what ran. In practice every block gets both: random as the workhorse, directed to seed bring-up and to fill coverage holes random cannot reach economically.

// The pragmatic hybrid: directed setup + random hammer in one scenario
task corner_scenario(mailbox #(fifo_txn) gen2drv);
  fifo_txn t;
  // directed: drive exactly to full
  repeat (DEPTH) begin
    t = new();
    assert(t.randomize() with { op == PUSH; });
    gen2drv.put(t);
  end
  // random: hammer the full boundary with mixed ops
  repeat (200) begin
    t = new();
    assert(t.randomize() with { op dist {PUSH := 6, POP := 4}; });
    gen2drv.put(t);
  end
endtask

Follow-up: "When is constrained-random the wrong choice?" — When the scenario count is small and exact (a 5-step register init sequence), when there is no checker to exploit the random volume, or when constraint-tuning costs more than writing the three directed tests the feature actually needs.

Junior vs senior: a junior picks a side. A senior describes the decision criteria, the hybrid pattern, and the precondition that random without a scoreboard is just expensive heat.

Q: What metrics do you report weekly, and which do you distrust?

Four trends: regression pass rate, merged functional coverage, open bug count by priority, and RTL churn — plus the phase-specific extra (seeds per night during closure, weeks-since-last-P1 during convergence). I report trends, not snapshots, and I pair each metric with its audit: pass rate with periodic bug-injection checks, coverage with bin-quality review, bug rate with stimulus-freshness checks (are new seeds still finding new bins?).

Follow-up: "Pass rate is 100% for three weeks — good news?" — Suspicious news. Either the design has converged (check bug-rate history and stimulus freshness) or the checkers are too weak to fail (inject a known bug and confirm a test catches it) or failing tests got disabled (check test counts). 100% is an invitation to audit, not to celebrate.

Junior vs senior: a junior reports the numbers. A senior reports the trends, names which number is most likely lying this week, and shows the audit that keeps it honest.

Key takeaways

• Lifecycle answers beat testbench answers for every strategy question.

• Done = plan closed + coverage closed with hole review + bug-rate convergence — combined evidence.

• Prioritization under pressure = explicit risk-ranked descoping with written waivers.

• Pair every reported metric with the audit that keeps it honest.

Common pitfalls

• Answering "how do you verify X" with driver/monitor details and no plan or sign-off story.

• Claiming coverage alone proves completeness — interviewers will hand you the silicon-bug follow-up.

• Describing descoping as "working harder" — seniors manage scope, juniors absorb it.