Writing an Honest Verification Summary

A verification summary turns results into a bounded argument. Use four parts:

• What I tested: name exact operations, input values, visible outputs, and stored-state checks.
• Corner cases: explain why a varied operand, reset boundary, consecutive request, or write edge could expose a plausible defect.
• Warnings reviewed: identify the warning and classify it as expected, harmless with a reason, or actionable.
• What remains untested: name the limit and the next check you would add.

“All tests passed” hides what the tests observed. For a different design, “the three-bit counter held 6 across two rising edges while its enable was low” connects a hold claim to values, control and timing. Build your capstone claims from your own records rather than copying a sample report.

If the compiler reported no warnings, state that honestly. Separately name an RTL risk you inspected and whether you actually ran synthesis. A simulation run or clean compile is not a physical-timing result.

Finite directed tests cannot exhaust every input and state sequence. Saying so does not weaken your proof; it makes the scope trustworthy. A reviewer can see both what you know and how you would reduce the remaining risk.