Building a Coverage Plan from a Spec

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

WhyWhat IfProve ItBreak ItCompareScale It

1. Building a Coverage Plan from a Spec
2. WhyWhy the Plan Starts from the SpecL1 JuniorL2 Mid-Level

   Why build the coverage plan from the spec and not from the RTL?

   Reveal the Model Answer

   A plan read from the RTL only lists what was built, so it repeats the designer's understanding, mistakes included. A missing feature never appears in it. Code coverage already measures the RTL's structure. The spec is the independent source, so a plan built from it can find what the RTL left out.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 A plan read from the RTL only lists what was built, so it repeats the designer's understanding, mistakes included. Key point 2 A missing feature never appears in it. Key point 3 Code coverage already measures the RTL's structure. Key point 4 The spec is the independent source, so a plan built from it can find what the RTL left out.

   Half-Truth

   "The RTL is more detailed, so it gives a better plan."

   Detail is not independence. Implementation corners from the RTL are worth adding, but on top of a spec-based plan, not instead of it.

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

   • Lesson C1What Coverage Measures
3. CompareCoverage Plan vs Test PlanL2 Mid-Level

   Compare a coverage plan with a test plan. Why keep both?

   Reveal the Model Answer

   A test plan lists the stimulus: which tests exist and what each one drives. A coverage plan lists what must be observed before a feature counts as done. With random tests the mapping is many to many: one test fills bins from many features, and one feature needs many tests. The coverage plan measures whether the tests did their job.

   	Test plan	Coverage plan
   Lists	Tests and what each one drives	Cases that must be observed
   Answers	What did we send?	What did the design actually see?
   Done when	Every test exists and passes	Every item is hit in passing runs
   Mapping	One test fills bins of many features	One feature needs many tests

   With random tests the two plans map many to many, so one cannot replace the other.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 A test plan lists the stimulus: which tests exist and what each one drives. Key point 2 A coverage plan lists what must be observed before a feature counts as done. Key point 3 With random tests the mapping is many to many: one test fills bins from many features, and one feature needs many tests. Key point 4 The coverage plan measures whether the tests did their job.

   Misconception

   "If every test in the test plan passes, the features are covered."

   A passing random test may never have produced the case it was written for. Only coverage shows what actually happened.

   Source Spear & Tumbush, SystemVerilog for Verification (3rd ed.), §9 introduction (PDF p361)

   • Lesson C1What Coverage Measures
   • Lesson U15.1Coverage Architecture and Planning
4. Break ItCovered but Never CheckedL2 Mid-LevelL3 Senior

   How can a plan item reach 100% coverage and still be unverified?

   Reveal the Model Answer

   Coverage says the case happened; it does not say anyone checked the result. If the scoreboard ignores a field, or an assertion is missing, the case passes with any behaviour. So each plan row needs both a coverage item and a named checker. Review the checkers as carefully as the bins.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 Coverage says the case happened; it does not say anyone checked the result. Key point 2 If the scoreboard ignores a field, or an assertion is missing, the case passes with any behaviour. Key point 3 So each plan row needs both a coverage item and a named checker. Key point 4 Review the checkers as carefully as the bins.

   What Interviewers Listen For (Senior)

   A good senior answer adds a "checked by" column to the plan. It rejects any row that has coverage but no checker.

   Misconception

   "High coverage with no failures means high quality."

   It means many cases ran without a reported failure. Weak checkers produce exactly that picture.

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

   • Lesson C1What Coverage Measures
   • Lesson U8.1Predictor, Comparator, Scoreboard
5. What IfA Corner the Spec Does Not DefineL2 Mid-Level

   Asked if they say the spec is unclear

   What if the spec is silent on one corner? For example, a push and a pop arrive in the same cycle while the FIFO is full.

   Reveal the Model Answer

   Raise it as a spec question with the architect, in writing, and don't guess. Cover the case anyway, because unclear corners are where designers and verifiers disagree. Once the answer is agreed, update the spec, the checker and the plan together. Until then, mark the row as open.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 Raise it as a spec question with the architect, in writing, and don't guess. Key point 2 Cover the case anyway, because unclear corners are where designers and verifiers disagree. Key point 3 Once the answer is agreed, update the spec, the checker and the plan together. Key point 4 Until then, mark the row as open.

   Missed Corner

   "Check what the RTL does and use that as the answer."

   Then the bench agrees with the RTL by definition. If the designer guessed wrong, nothing will catch it.

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

   • Lesson 7.1Start from the FIFO Rules
   • Lesson C8Capstone: A Coverage Model That Finds Holes
6. Scale ItThe FIFO Plan Inside a SubsystemL3 SeniorL4 Staff

   The FIFO now sits inside a subsystem with a DMA and an interconnect. How does the coverage plan change?

   Reveal the Model Answer

   Don't re-close the FIFO's block corners; they were closed at block level. Keep the block covergroups running passively, so you can see which corners real traffic reaches. Add integration items: connections, the FIFO full while the DMA retries, and the interconnect stalling the APB side. Add system scenarios from the use cases too. Each level covers what only it can reach.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 Don't re-close the FIFO's block corners; they were closed at block level. Key point 2 Keep the block covergroups running passively, so you can see which corners real traffic reaches. Key point 3 Add integration items: connections, the FIFO full while the DMA retries, and the interconnect stalling the APB side. Key point 4 Add system scenarios from the use cases too. Key point 5 Each level covers what only it can reach.

   What Interviewers Listen For (Staff)

   A good staff answer splits the coverage effort between block and subsystem levels. It names the risks that only the subsystem bench can reach.

   Wrong Altitude

   "Reuse the block plan unchanged at subsystem level."

   Block corners are hard to reach through a DMA and slow to close there. Integration cases, which the block plan never listed, are left out.

   Source Mehta, ASIC/SoC Functional Design Verification, §2.2 (PDF p34)

   • Lesson U12.2Vertical Reuse: A Block Environment Inside a Subsystem
   • Lesson C8Capstone: A Coverage Model That Finds Holes
7. Prove ItFrom a Plan Row to a CoverpointL1 JuniorL2 Mid-Level

   Prove it: turn the "overflow sticky bit" row into coverage. What does this print for the two tests?

   module tb;
     bit ovf;                         // the overflow sticky bit
     covergroup cg;
       sticky: coverpoint ovf { bins set = (0 => 1); bins held = (1 => 1); bins clear = (1 => 0); }
     endgroup
     cg full_test = new(), no_clear = new();
     bit a[$] = '{0, 0, 1, 1, 0};     // set, held, then cleared by an APB write
     bit b[$] = '{0, 1, 1, 1};        // set and held, never cleared
     initial begin
       foreach (a[i]) begin ovf = a[i]; full_test.sample(); end
       foreach (b[i]) begin ovf = b[i]; no_clear.sample(); end
       $display("set-hold-clear test: %0.2f", full_test.get_inst_coverage());
       $display("test that never clears: %0.2f", no_clear.get_inst_coverage());
     end
   endmodule
   

   Reveal the Model Answer

   It prints 100.00 for the first test and 66.67 for the second. The row says the bit is set by an overflow, stays set, and is cleared by a register write. Each of those is a transition, so each gets a transition bin. The second test never clears the bit, and the report names that hole.

   RUNVerilator (coverage build) · simulator service

   Edit the code, then run it

   OutputWaves

   RunReset codeExpected: set-hold-clear test: 100.00 test that never clears: 66.67

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 It prints 100.00 for the first test and 66.67 for the second. Key point 2 The row says the bit is set by an overflow, stays set, and is cleared by a register write. Key point 3 Each of those is a transition, so each gets a transition bin. Key point 4 The second test never clears the bit, and the report names that hole.

   Half-Truth

   "A value bin for 1 is enough; it shows the bit was set."

   The row is about behaviour over time: set, hold and clear. A value bin is covered by the first overflow and says nothing about clearing.

   Source IEEE 1800-2017 §19.5.2

   • Lesson C4Transitions
   • Lesson C8Capstone: A Coverage Model That Finds Holes