Coverage Interview Q&A

Q1. Functional coverage vs code coverage?

Junior answer: "Functional coverage uses covergroups; code coverage is lines and toggles from the tool." True, but it describes the mechanism, not the meaning.

Senior answer: "They answer different questions from different sources. Code coverage is derived automatically from the RTL and measures which structure executed — it can reach 100% without any interesting scenario occurring. Functional coverage is written by the engineer from the spec and measures whether planned scenarios happened — it is only as good as the plan. They cross-check each other: unhit code at 100% functional means the plan missed logic; low functional at 100% code means execution without intent. Sign-off needs both."

Q2. illegal_bins vs ignore_bins?

Senior answer: "Both remove values or cells from the coverage goal; the difference is what a hit means. ignore_bins marks combinations that are irrelevant or impossible — a hit is silently discarded. illegal_bins marks combinations forbidden by the spec — a hit is a runtime error, so the bin doubles as a protocol check. My decision rule: if I would file a bug when it occurs, illegal; if I would shrug, ignore. Both need a documented reason, because both change the denominator." The junior version knows the error/no-error difference but misses the goal-math effect and the documentation duty.

Q3. What is cross coverage and when do you use it?

Senior answer: "A cross generates bins for combinations of coverpoint bins — the product matrix. I use one when design logic actually examines the fields together: opcode with operand corner, burst type with length and alignment, FSM state with input event. Two coverpoints at 100% individually prove nothing about combinations — every add may have been short and every div long, leaving div-with-short empty. The discipline is shaping the product: binsof to name the cells the plan demands, ignore_bins for impossible cells, illegal_bins for forbidden ones, because cross size multiplies and closure effort lives in the empty cells."

Q4. A hole you cannot hit — what do you do?

Junior answer: "Write a directed test for it." — which assumes the answer to a question that has not been asked yet.

Senior answer: "Triage before effort, cheapest check first. First: is the bin itself correct — right range, right signal, right sampling event? A wrong bin invalidates its history. Second: is the scenario reachable — spec plus a designer conversation; if it is structurally impossible, the action is ignore_bins with a documented waiver, not a test. Third: can current random stimulus produce it — if it is just starved, I steer with inline constraints or distribution weights. Only when it is reachable and structurally beyond random do I pay for a directed test, and that test checks the behavior, not just hits the bin."

THE ANSWER IN ONE PICTURE

  unhittable hole
       │
       ├─ bin wrong?        → fix model (minutes)
       ├─ unreachable?      → waiver + ignore_bins (documented)
       ├─ starved random?   → steer constraints / dist (hours)
       └─ structural corner → directed test (days) — last resort

  junior: jumps to the bottom row, pays days for minutes-problems
  senior: walks the rows top-down, with the designer at row two

Q5. Describe coverage-driven verification (CDV)

Senior answer: "CDV inverts test-list thinking: the plan defines measurable goals first, constrained-random stimulus does the broad work, and coverage feedback decides what happens next. The loop is: spec to plan, plan to covergroups, regression across seeds, merge, hole triage, then targeted action — steering, directed tests, or waivers — and repeat until per-feature goals close. The merged database, not any single run, is the source of truth, and progress is measured in newly-hit bins per unit effort, which naturally surfaces the diminishing-returns decision points."

Q6. Covergroup in a class vs in a module?

Senior answer: "A module-context covergroup typically samples on a clocking event and watches signals — good for protocol and FSM coverage close to the pins. An embedded class covergroup is constructed in the class constructor — exactly once, with cg = new(args) — and is usually sampled procedurally with cg.sample() when a transaction completes, often using the with-function-sample form to pass fields. The class form parameterizes per instance — constructor arguments for bounds and names, option.per_instance for separate report rows — which is why transaction coverage lives in classes and signal-timing coverage lives in modules or interfaces."

Q7. Your covergroup reports 100% — are you done?

Senior answer: "Not on that evidence alone. Is that a single seed or the merged regression? Is it the aggregate or per-feature — an aggregate can hide a 0% feature with few bins? Were at_least thresholds meaningful, or is one lucky hit counting as covered? Does code coverage corroborate, or is there unhit RTL the plan never mentioned? Did the assertions actually activate? And what does the exclusion diff look like — was anything bulk-waived to get here? 100% on a well-reviewed model, merged, per-feature, with corroborating instruments — then yes, that feature is done."

JUNIOR vs SENIOR — the pattern across all answers

  junior signals                    senior signals
  ───────────────────────────────────────────────────────────────
  defines the construct             explains what the metric MEANS
  one tool for every problem        triage first, tool second
  single-run percentages            merged, per-feature numbers
  coverage as a report              coverage as a feedback loop
  100% = done                       converging evidence = done
  silent exclusions                 documented, approved waivers

Key takeaways

• Every strong coverage answer connects mechanism to meaning: what the number proves and what it cannot prove.

• Triage-before-effort is the recurring senior pattern — model correctness, reachability, distribution, then directed tests.

• Always specify merged and per-feature when discussing percentages; single-run aggregates are the junior tell.

• Treat 'are you done?' questions as evidence questions: merge, per-feature goals, corroborating instruments, defended exclusions.

Common pitfalls

• Defining constructs without their goal-math consequences — ignore vs illegal is a denominator question, not just an error question.

• Answering hole questions with 'directed test' before triaging reachability and bin correctness.

• Claiming 100% coverage means done — the interviewer is waiting for the plan-completeness caveat.

• Forgetting the once-only construction rule for embedded class covergroups — a favorite follow-up trap.