Defending the Assertion Plan for a Block

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

WhyWhat IfProve ItBreak ItCompareScale It

1. Defending the Assertion Plan for a Block
2. WhyWhy Assertions Come from the SpecL2 Mid-LevelL3 Senior

   Why should assertions be written from the specification instead of from reading the RTL?

   Reveal the Model Answer

   An assertion written from the RTL describes what the code does. So it agrees with the code even when the code is wrong. An assertion written from the spec is an independent second opinion. That independence is the whole value of a check.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 An assertion written from the RTL describes what the code does. Key point 2 So it agrees with the code even when the code is wrong. Key point 3 An assertion written from the spec is an independent second opinion. Key point 4 That independence is the whole value of a check.

   Half-Truth

   "The designer knows the RTL best, so the designer should write every assertion."

   Designer assertions catch local mistakes well. Spec-level rules need someone reading the spec separately, or both sides share the same mistake.

   • Lesson A1.1Why Assertions
3. What IfWhen the Designer Says Read the RTLL2 Mid-LevelL3 Senior

   What if the spec is vague on a rule, and the designer tells you to read the RTL?

   Reveal the Model Answer

   Do not copy the RTL into the assertion. Write the question down and get the architect to answer it in the spec or a decision log. Then write the assertion from that answer. If the RTL disagrees, one of them has a bug, and you found it early.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 Do not copy the RTL into the assertion. Key point 2 Write the question down and get the architect to answer it in the spec or a decision log. Key point 3 Then write the assertion from that answer. Key point 4 If the RTL disagrees, one of them has a bug, and you found it early.

   Misconception

   "The RTL is the real spec, so write the assertion from it."

   Then the assertion agrees with the code even when the code is wrong. A check needs an independent source.

   Source Mehta, SystemVerilog Assertions and Functional Coverage (3rd ed.), §2.2

   • Lesson A1.1Why Assertions
4. CompareOrdering Checks: Assertions or the Scoreboard?L3 Senior

   For a block with outstanding, tagged transactions, which ordering and completion rules do you put in assertions and which in the scoreboard?

   Reveal the Model Answer

   Assertions take the local, cycle-level rules: an ID is not reused while outstanding, every response matches an outstanding ID, deadlines are met. They report the exact cycle and also run in formal. The scoreboard takes end-to-end data correctness and anything needing a reference model. Overlap is deliberate: a lost response should be caught by both, at different distances from the bug.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 Assertions take the local, cycle-level rules: an ID is not reused while outstanding, every response matches an outstanding ID, deadlines are met. Key point 2 They report the exact cycle and also run in formal. Key point 3 The scoreboard takes end-to-end data correctness and anything needing a reference model. Key point 4 Overlap is deliberate: a lost response should be caught by both, at different distances from the bug.

   What Interviewers Listen For (Senior)

   A good senior answer splits the rules by how local they are and by reuse in formal. It wants both the assertions and the scoreboard to catch a lost response, on purpose.

   Wrong Altitude

   "The scoreboard already checks everything, so assertions are redundant."

   A scoreboard reports a missing response at the end of the test, far from the cause. An assertion names the cycle, and only properties carry over to formal.

   • Lesson A8.2Capstone: A Tagged request/response Channel
   • Lesson 7.4Build the Monitor and Scoreboard
5. Scale ItAssertion Quality Sign-Off Across an IPL3 SeniorL4 Staff

   Your IP has several hundred assertions. How do you show in sign-off that they actually checked something?

   Reveal the Model Answer

   Pair every implication with an antecedent cover. Make "every antecedent hit in regression" a sign-off item, and review zero-hit covers like failures. In formal, run the covers too, and treat an unreachable antecedent as a vacuous proof. Track the counts per assertion in the verification plan. Then a property that stops firing after a design change is caught.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 Pair every implication with an antecedent cover. Key point 2 Make "every antecedent hit in regression" a sign-off item, and review zero-hit covers like failures. Key point 3 In formal, run the covers too, and treat an unreachable antecedent as a vacuous proof. Key point 4 Track the counts per assertion in the verification plan. Key point 5 Then a property that stops firing after a design change is caught.

   Misconception

   "The formal tool says proven, so the property is meaningful."

   A proof can pass because constraints rule out the antecedent. Without a reached cover, proven may mean vacuous.

   Source Seligman, Schubert and Kiran Kumar, Formal Verification (2nd ed.) ch. 9 "Vacuity issues" (PDF p310), Tip 9.11 (p318)

   • Lesson F3.2Over-Constraint and Vacuity
6. Break ItWhen Assertions Slow the RegressionL3 Senior

   After adding the suite, the regression runs twice as slowly. What do you look for?

   Reveal the Model Answer

   Look for properties that keep many attempts alive. Typical causes are level antecedents that start an attempt every cycle, and long or unbounded ranges such as ##[1:$]. Rewrite them with edge antecedents and the spec's bound. Keep the expensive checks in nightly runs if they still cost too much. Measure per property with the simulator's profiler before changing anything.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 Look for properties that keep many attempts alive. Key point 2 Typical causes are level antecedents that start an attempt every cycle, and long or unbounded ranges such as ##[1:$]. Key point 3 Rewrite them with edge antecedents and the spec's bound. Key point 4 Keep the expensive checks in nightly runs if they still cost too much. Key point 5 Measure per property with the simulator's profiler before changing anything.

   What Interviewers Listen For (Senior)

   A good senior answer names the number of open attempts as what drives the cost. It keeps the checks by fixing them, instead of switching them off.

   Wrong Altitude

   "Turn the assertions off in regression and run them weekly."

   Bugs then sit unnoticed for a week. Fix the few expensive properties instead.

   • Lesson A2.1Delays and Ranges: One Attempt, Many Threads
7. Prove ItSolve 6.6.13: A Tagged Channel Assertion SuiteSimulator-graded

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

   Open Problem 6.6.13