Part 11 · Senior Prep · Intermediate

Verification Done Interview Q&A

Model answers on defining verification complete, plan compliance, risk communication to stakeholders, and the evidence package for tape-out review.

Defining done

Q: PM asks 'are we done verifying?' — you answer?

diagram

[INT][SENIOR][UVM] MODEL ANSWER

Q: Are we done verifying?

A:
  MECHANISM:  Done = plan compliance — merged functional coverage, P0 holes
              closed or waived, critical assertions green, known bugs tracked.
  MOTIVATION:  'Done' is not a feeling — it's evidence against the plan.
  ANSWER:     Show merged func cov by plan section, open P0 holes list, waiver
              audit, last-week trend. State risks explicitly.
  PITFALL:    Quoting code coverage % as sole sign-off metric.
  EXAMPLE:    "AXI 98% plan coverage, 1 P0 hole with closure test in flight,
              2 approved waivers — not done until P0 closes Thursday."

Q: What is the difference between 'done' and 'good enough'?

diagram

[INT][SENIOR][UVM] MODEL ANSWER

Q: Done vs good enough?

A:
  MECHANISM:  Done = all plan requirements met or formally waived. Good enough =
              risk acceptance with documented holes and executive sign-off.
  MOTIVATION:  Schedule pressure creates gray zone — seniors document risk explicitly.
  WHEN:       Good enough only with written risk acceptance — never verbal.
  PITFALL:    Senior engineer unilaterally declaring good enough — needs lead chain.
  EXAMPLE:    Tape-out with 1 P1 hole on rare corner — VP sign risk memo attached.

diagram

[INT][SENIOR][UVM] verification done checklist

  [ ] merged func cov meets plan threshold per section
  [ ] P0 holes = 0 (or waived with audit)
  [ ] assertions / SVA green on sign-off regression
  [ ] open bugs triaged — no silent P0
  [ ] waiver log reviewed by design lead
  [ ] trend shows closure velocity (not flat 2 weeks)
  [ ] emulation / FPGA results aligned (if in scope)

Key takeaways

'Done' = plan evidence package — func cov, holes, waivers, trends.
Good enough requires written risk acceptance — not verbal shortcuts.
State risks explicitly when not fully done — builds trust.

Common pitfalls

Telling PM 'almost done' without P0 hole enumeration.
Code coverage 95% cited as done — wrong metric.

Risk communication and tape-out review

Q: How do you present residual risk at tape-out review?

diagram

[INT][SENIOR][UVM] MODEL ANSWER

Q: Residual risk presentation?

A:
  MECHANISM:  Rank open items by product impact (boot fail, data corruption, perf)
              and likelihood from coverage gap analysis.
  MOTIVATION:  Executives need impact language — not bin names alone.
  FORMAT:     Risk register: ID, scenario, impact, mitigation, owner, date.
  PITFALL:    Hiding P1 holes in appendix — reviewers find them anyway.
  EXAMPLE:    "IRQ storm under DMA load — P1, firmware workaround exists, post-silicon
              monitor planned."

Q: Block sign-off vs chip sign-off — different evidence?

diagram

[INT][SENIOR][UVM] MODEL ANSWER

Q: Block done vs chip done?

A:
  MECHANISM:  Block done = block plan + block merged cov + block assertions.
              Chip done = chip plan + merged block+chip cov + system scenarios.
  MOTIVATION:  Block sign-off does not imply chip sign-off — integration adds scope.
  BLOCK:      Active agent stress, local SB, block-level crosses.
  CHIP:       Passive integration, end-to-end SB, SW-like vseqs, merged UCDB.
  PITFALL:    Chip sign-off citing only block coverage merge — missing chip bins.
  EXAMPLE:    AES block 100% plan at block; chip adds DMA path crosses still open.

Whiteboard: draw monitor → check pipeline for done discussion

diagram

[INT][SENIOR][UVM] whiteboard scenario

  Draw and narrate:
    stim → DUT → monitor.ap ─┬→ scoreboard actual
                             ├→ coverage subscriber
                             └→ ref_model → scoreboard expected

  Label: sample coverage on monitor only
         scoreboard compares at transaction granularity
         RAL predictor may share monitor stream
         DONE = all plan bins hit on this DUT-visible path

systemverilog

// end-of-test gate in report_phase — senior sign-off pattern
function void report_phase(uvm_phase phase);
  super.report_phase(phase);
  if (!cov_mgr.plan_compliance_met())
    `uvm_error("SIGNOFF", "Plan compliance not met — see merged_holes.rpt")
  if (ral_model.get_coverage() < 100.0)
    `uvm_warning("SIGNOFF", "RAL reg coverage below target")
endfunction

Q: Post-silicon bug escaped — how do you update the done definition?

diagram

[INT][SENIOR][UVM] MODEL ANSWER

Q: Escape drives process change?

A:
  MECHANISM:  Root cause escape: missing plan row, wrong sampling point, waiver
              error, or checker gap. Update plan + coverage + regression permanently.
  MOTIVATION:  Done definition evolves from escapes — blameless postmortem.
  ACTION:     Add plan feature, coverpoint, directed regression, checklist item.
  SENIOR SIGNAL: systemic fix — not "we got unlucky."
  EXAMPLE:    Escape on W1C status bit — add field semantic test + predictor fix.

Key takeaways

Residual risk = impact-ranked register with mitigation — not hidden appendix.
Block done ≠ chip done — cite correct merged DB for scope asked.
Escapes update plan + regression — blameless systemic fix.

Common pitfalls

Signing off without report_phase compliance hooks — no automated gate.
Escape postmortem with no plan update — repeat escape likely.

Practice this lessonQuestions tagged for this topic in the bank