Writing assertions is half the job. The other half is living with them: decoding failures, distrusting green suites, keeping regressions quiet, and placing checks where they survive.
Symptom | The question | Lesson |
|---|---|---|
An assertion fired | Is the RTL wrong, or my assertion? | Debugging failures: start time, fail time, sampled values |
An assertion is silent | Is it passing, or never trying? | Vacuity and coverage: a cover on every antecedent |
The regression is slow or noisy | Which checks cost the most? | Performance and noise: precise antecedents, bounded windows |
Where should it go? | Who owns it, and does it survive synthesis? | Placement: inline, interface, bound checker |
Sign-off | Is every check actually checking? | The review checklist |
Lesson | What it covers |
|---|---|
Attempt start vs fail time, the preponed off-by-one, and sampled action-block messages. | |
Vacuity audits, assert and cover pairs, and cover-first development. | |
Attempt cost, bounded liveness, phase control, and readable regressions. | |
Inline, interface, and bound checkers, plus synthesis and formal reuse. | |
Six review checks applied to a flawed module, with a repaired version. |
A failing check may be disabled by a scoped control that was never re-enabled, and a passing implication may be vacuous: its antecedent never fired, so the consequent was never examined. Both need cover and vacuity data to rule out.