Interview Question · Concept

Full Code Coverage and a Bug Escape

L0 FresherL1 JuniorL2 Mid-Levelfunctional coveragecode coveragemethodology

The interviewer asks

Your block reached 100% code coverage, yet a bug escaped to silicon. How is that possible, and what does functional coverage add?

Reveal the Model Answer

Code coverage measures which lines, branches and toggles of the RTL ran. It cannot see a check that was never written, or conditions that never happened together. Functional coverage measures the cases in the spec and the plan, such as "push while full". A missing feature then shows up as an empty bin. You need both: code coverage finds RTL nobody exercised, and functional coverage finds intent nobody tested.

Two Reports, Two QuestionsThe level counter from the run. Arrows show what each report is built from.

Read the diagram as text

Spec: A push into a full counter is ignored
RTL: Reset, increment and decrement lines; no full check
Coverage plan: Row: push while full
Code coverage: Every line ran at least once
Bin push_full: 0 hits, so a test is missing
The missing check: No line exists, so nothing is counted

Spec → Coverage plan: listed in
Coverage plan → Bin push_full: coded as
RTL → Code coverage: lines counted
Code coverage → The missing check: cannot see

In the run every line ran, yet the push-while-full bin has 0 hits. Code coverage counts the RTL that exists; functional coverage counts the cases in the spec.

Self-Check

Tick each key point you covered in your answer.

Key point 1 Code coverage measures which lines, branches and toggles of the RTL ran. Key point 2 It cannot see a check that was never written, or conditions that never happened together. Key point 3 Functional coverage measures the cases in the spec and the plan, such as "push while full". Key point 4 A missing feature then shows up as an empty bin. Key point 5 You need both: code coverage finds RTL nobody exercised, and functional coverage finds intent nobody tested.

What Interviewers Listen For (Fresher)

A good fresher answer says code coverage can only count lines that exist in the RTL. It gives one example, such as a full check that nobody wrote.

Cross-Questions

Where the interviewer goes next. Open a node to practise that follow-up.

WhyWhat IfProve ItCompareScale It

Full Code Coverage and a Bug Escape
WhyWhy Code Coverage Cannot See Missing LogicL0 FresherL1 Junior
Why can't code coverage find a feature that was never implemented?

Reveal the Model Answer

A code coverage tool adds counters to the lines and branches that exist in the RTL. A check that was never written has no line, so there is nothing to count. The report can only ever say "this code ran" or "this code did not run". Functional coverage starts from the spec, so it can list cases the code does not handle.

Self-Check
Tick each key point you covered in your answer.
Key point 1 A code coverage tool adds counters to the lines and branches that exist in the RTL. Key point 2 A check that was never written has no line, so there is nothing to count. Key point 3 The report can only ever say "this code ran" or "this code did not run". Key point 4 Functional coverage starts from the spec, so it can list cases the code does not handle.

Misconception

"Branch coverage finds it, because the missing if leaves a branch untaken."

A branch that was never written has no counter. Branch coverage measures the branches the RTL has.

Source Mehta, SystemVerilog Assertions and Functional Coverage (3rd ed.), §25.1.1 (PDF p442)
- Lesson C1What Coverage Measures

CompareLine, Branch, Toggle, Expression and FSM CoverageL1 Junior

Compare line, branch, expression, toggle and FSM coverage. Which one would have caught the missing full check?

Reveal the Model Answer

Line coverage counts executed statements, and branch coverage counts each way through an if or case. Expression coverage checks that each term of a condition changed the result. Toggle coverage checks each bit went to 0 and 1, and FSM coverage counts states and arcs. None of them catches the missing check, because the condition count == 4 does not exist in the code.

Kind	What it counts	Sees the missing full check?
Line	Statements that executed	No
Branch	Each way through an `if` or `case`	No
Expression	Each term of a condition changing the result	No
Toggle	Each bit going to 0 and to 1	No
FSM	States and arcs of a state machine	No

The condition count == 4 is not in the code, so no kind of code coverage has anything to count.

Self-Check

Tick each key point you covered in your answer.

Key point 1 Line coverage counts executed statements, and branch coverage counts each way through an if or case. Key point 2 Expression coverage checks that each term of a condition changed the result. Key point 3 Toggle coverage checks each bit went to 0 and 1, and FSM coverage counts states and arcs. Key point 4 None of them catches the missing check, because the condition count == 4 does not exist in the code.

Misconception

"Expression coverage would flag the missing count == 4 term."

Expression coverage measures the terms that are written. A term that is absent from the condition is invisible to it.

Source Mehta, SystemVerilog Assertions and Functional Coverage (3rd ed.), §25.1.1 (PDF p442)

Lesson C1What Coverage Measures

Prove ItThe Bin That Would Have Caught ItL1 Junior
Prove it: write the functional coverage that would have exposed the missing full check.

Reveal the Model Answer

Cover the operation crossed with the fill state, sampled only outside reset. For example, push_full: coverpoint (push && count == 4) iff (!rst) { bins seen = {1}; }. A fuller model crosses push and pop with empty, partial and full. The empty bin forces someone to write the test, and that test finds the overflow.

Self-Check
Tick each key point you covered in your answer.
Key point 1 Cover the operation crossed with the fill state, sampled only outside reset. Key point 2 For example, push_full: coverpoint (push && count == 4) iff (!rst) { bins seen = {1}; }. Key point 3 A fuller model crosses push and pop with empty, partial and full. Key point 4 The empty bin forces someone to write the test, and that test finds the overflow.

Missed Corner

"Cover the count value from 0 to 4; that includes full."

The count does reach 4. The missing case is a push while it is 4, which is an operation crossed with a state.

Source Mehta, SystemVerilog Assertions and Functional Coverage (3rd ed.), §27.1 (PDF p502)
- Lesson C5Cross Coverage
- Problem 7.5.8Two Coverpoints for the FIFO
What IfCode Holes in an Error-Recovery BranchL2 Mid-Level
Asked if they ask about the remaining code holes

Code coverage is 97%. The holes are in an error-recovery branch. What do you do with them?

Reveal the Model Answer

Find out first whether the branch can be reached. If it can, the plan missed a feature: add it to the plan and write the test, often with error injection. If it cannot, because of a tie-off or a parameter, mark it unreachable with a reason the designer agrees to. Never waive a hole just because it is hard to hit.

Self-Check
Tick each key point you covered in your answer.
Key point 1 Find out first whether the branch can be reached. Key point 2 If it can, the plan missed a feature: add it to the plan and write the test, often with error injection. Key point 3 If it cannot, because of a tie-off or a parameter, mark it unreachable with a reason the designer agrees to. Key point 4 Never waive a hole just because it is hard to hit.

Wrong Altitude

"Error paths are rare in silicon, so waive them."

Recovery logic runs exactly when something has already gone wrong. A bug there turns a recoverable error into a hang.

Source Spear & Tumbush, SystemVerilog for Verification (3rd ed.), §9.2.1 (PDF p363)
- Lesson C7Closing Holes
- Lesson F5.7Unreachability and Coverage Closure
Scale ItClearing Hundreds of Code HolesL3 Senior
At sign-off, hundreds of code coverage holes remain across a subsystem. How do you clear them without writing hundreds of tests?

Reveal the Model Answer

Run a formal unreachability check on the holes first. It proves many of them dead, such as logic behind tied-off inputs or unused parameter values. Those can be excluded, with the proof as the reason. Review the rest with the designers, grouped by feature. Each group becomes a test, a plan update or a reviewed waiver.

Self-Check
Tick each key point you covered in your answer.
Key point 1 Run a formal unreachability check on the holes first. Key point 2 It proves many of them dead, such as logic behind tied-off inputs or unused parameter values. Key point 3 Those can be excluded, with the proof as the reason. Key point 4 Review the rest with the designers, grouped by feature. Key point 5 Each group becomes a test, a plan update or a reviewed waiver.

What Interviewers Listen For (Senior)
A good senior answer first uses a formal tool to shrink the list of holes. It then reviews the rest with the designers, feature by feature, and gives each waiver an owner.

Half-Truth

"Formal says the hole is unreachable, so the design is fine there."

Unreachable under the formal setup only. Wrong assumptions or tie-offs can make reachable logic look dead, so review the constraints too.

Source Seligman, Schubert, Kiran Kumar, Formal Verification (2nd ed.), ch. 9, vacuity and wrong assumptions (PDF p310)
- Lesson F5.7Unreachability and Coverage Closure
- Lesson F7.4Formal with Simulation
Prove ItSolve 7.5.8: Two Coverpoints for the FIFOSimulator-graded

Show it, don't just say it: this Silicon Lab problem is graded by the simulator.
Open Problem 7.5.8

What People Get Wrong

Common wrong answers and why they fail. Run It shows the wrong belief failing on a real simulator.

Misconception

"Every line ran, so the design is verified."

The twin runs every line of a counter whose full check was never written. Functional coverage of push-while-full is 0%, and a fifth push overflows.

Run It

A counter with a missing full check. Line hits are counted by hand, as a line-coverage report would.

RUNVerilator (coverage build) · simulator service

Edit the code, then run it

Expected: line hits: reset=1 increment=4 decrement=4 (every line ran) functional coverage, push while full: 0.00 after a fifth push: count=5 (the spec says 4) FAIL: every line ran, but no test pushed into a full counter, where the missing check lives

// The spec: count holds at 4 when full; a push into a full counter is ignored.
module level_ctr(input logic clk, rst, push, pop, output logic [2:0] count);
  int hit_reset = 0, hit_inc = 0, hit_dec = 0;   // hand-counted line hits, like a line-coverage report
  always @(posedge clk)
    if (rst)                begin count <= 0;         hit_reset++; end
    else if (push && !pop)  begin count <= count + 1; hit_inc++;   end   // the full check is missing
    else if (pop && !push)  begin count <= count - 1; hit_dec++;   end
endmodule
module tb;
  logic clk = 0, rst = 1, push = 0, pop = 0;
  logic [2:0] count;
  always #5 clk = ~clk;
  level_ctr dut(.*);
  covergroup cg @(posedge clk);
    push_full: coverpoint (push && count == 4) iff (!rst) { bins seen = {1}; }
  endgroup
  cg c = new();
  initial begin
    @(negedge clk) rst = 0;
    repeat (4) @(negedge clk) push = 1;      // fill to 4
    @(negedge clk) push = 0;
    repeat (4) @(negedge clk) pop = 1;       // drain to 0
    @(negedge clk) pop = 0;
    $display("line hits: reset=%0d increment=%0d decrement=%0d (every line ran)", dut.hit_reset, dut.hit_inc, dut.hit_dec);
    $display("functional coverage, push while full: %0.2f", c.get_coverage());
    // The belief: every line ran, so the design is verified.
    repeat (4) @(negedge clk) push = 1;
    @(negedge clk) push = 1;                 // one push too many
    @(negedge clk) push = 0;
    $display("after a fifth push: count=%0d (the spec says 4)", count);
    if (count != 4) $display("FAIL: every line ran, but no test pushed into a full counter, where the missing check lives");
    $finish;
  end
endmodule

Half-Truth

"Functional coverage is the better metric, so skip code coverage."

Code coverage finds RTL the plan forgot, such as an untested mode or a dead branch. Each metric sees holes the other cannot.

Source Spear & Tumbush, SystemVerilog for Verification (3rd ed.), §9.2.1 (PDF p363)

Misconception

"100% toggle coverage means every value of the bus was seen."

Toggle coverage only checks that each bit went to 0 and to 1. It says nothing about which combinations of bits appeared.

Source Spear & Tumbush, SystemVerilog for Verification (3rd ed.), §9.2.1 (PDF p363)

Find Your Next Track

Put Your Skills to Work

Prepare to Explain Your Thinking

An Idea to Try? Pick a Tool.

Full Code Coverage and a Bug Escape

Your Answer

Self-Check

What Interviewers Listen For (Fresher)

What Interviewers Listen For (Junior)

What Interviewers Listen For (Senior)

Cross-Questions

Your Answer

Self-Check

Your Answer

Self-Check

Your Answer

Self-Check

Your Answer

Self-Check

Your Answer

Self-Check

What Interviewers Listen For (Senior)

What People Get Wrong

Learn It, Then Prove It

The Question

Your Answer

Self-Check

What Interviewers Listen For (Fresher)

What Interviewers Listen For (Junior)

What Interviewers Listen For (Senior)

Cross-Questions

Your Answer

Self-Check

Your Answer

Self-Check

Your Answer

Self-Check

Your Answer

Self-Check

Your Answer

Self-Check

What Interviewers Listen For (Senior)

What People Get Wrong

Learn It, Then Prove It