Two weeks before RTL freeze, the architects change one sentence of the DMA specification. Today it says KEY writes while BUSY are ignored. The new version says a KEY write while BUSY takes effect at the next packet boundary, because firmware wants to queue the next job's key early. The designer estimates a day. Your manager asks how long verification needs. A month later, in a different project, silicon comes back with a stream peripheral that misbehaves because an end-of-packet flag is wrong, and someone asks the question every DV lead dreads: why did we miss it? Both are senior questions, and both are answered by tracing a change through the plan, the bench and the process.
A spec change is never one edit. Every sentence in the spec has copies: in the plan, in the reference model, in the scoreboard, in the register model, in coverage, in assertions, in tests that expect the old behaviour, and in waivers that exist because of it. Impact analysis is the job of finding every copy before you promise a date. A bug escape is the same tracing done backwards: starting from the bug, find which copy was missing or wrong, and then ask why the process allowed it. Think of changing a word in a contract that has been photocopied into twenty files: the work is not the edit, it is finding the photocopies.
Walk every artefact and write down what changes, who owns it and how long it takes. On the DMA bench the KEY change touches a surprising amount, much of it already familiar from war story 9:
Artefact | Impact | Effort |
|---|---|---|
Plan | New rows: KEY written while busy, applied at the next packet; KEY written twice while busy (last write wins?); KEY written while busy then reset | Half a day, plus spec questions |
| Hold a pending key while busy and apply it at job end. Today they apply it at once (war story 9), which is closer to the new rule than the DUT is, but still wrong | One to two days |
| Same rule in the C model, kept identical to the SV predictor | Half a day |
Register model and backdoor | Spec question first: does a KEY read while busy return the new value or the one in use? The mirror and | Blocked on the answer |
Assertions and coverage | A property for "the key in use changes only at a job boundary"; a cover for a KEY write while busy | Half a day |
| The waiver's root cause changes meaning. Re-derive the expected result under the new rule and remove the waiver | Half a day |
Regression | Run the whole old regression on the new RTL; every failure is either an expected behaviour change or a finding | One nightly |
That is roughly a week of verification for a one-day design change, with one open spec question. Saying "a week, and I need an answer on KEY reads by Wednesday" is a better response than "a day" followed by a slip. Three habits make the analysis fast and complete:
Search for the old rule, not the feature. Grep the plan, the bench and the tests for "busy" and "KEY". Every hit is a candidate copy of the sentence.
Let the old regression find the rest. Running the unchanged regression on the new RTL lists every test that encoded the old behaviour; each failure becomes a line in the impact table.
Write the questions down before the code. The KEY-read question is cheap to answer now and expensive after the register model and firmware have each guessed differently.
When a bug escapes to silicon, the useful question is not who made the mistake but which layer of the process let it through. Walk the layers in order and stop at the first one that failed:
Layer | Question | Escape type |
|---|---|---|
Specification | Did the spec state the correct behaviour? | Spec gap |
Plan | Was there a plan row for it? | Plan gap |
Checker | Did any checker compare that output? | Checker gap |
Stimulus and coverage | Did any test create the condition, and did coverage say so? | Stimulus gap |
Waivers and demotions | Did a check fire and get silenced? | False pass |
Review and sign-off | Was the gap visible, and was it accepted knowingly? | Process gap |
The course's own fault campaign is a rehearsal of exactly this review. Treat its three misses as if they were silicon escapes:
TLAST stuck at 0 (fault 7): a checker gap. The plan had stream rows, but no row said "TLAST is on the LEN-th word and only there", so no checker compared TLAST at all. Every test passed with the wrong TLAST.
DONE stuck at 1 (fault 6): a checker gap on internal state: nothing checked when DONE may rise.
LEN bit 4 stuck at 0 (fault 8): a stimulus gap, and a visible one. The plan-item tally had printed len=16 and len>16 as holes all along; the process allowed sign-off numbers to be read without requiring those holes to close or be explained.
The natural response to a TLAST escape is a directed test that reproduces the silicon failure: LEN = 8, check TLAST on word 8. It passes on fixed RTL, the bug ticket closes, and the next escape is TLAST on a one-word job, or on a truncated packet, which the new test never touches. The test fixed one symptom; the process that allowed an unchecked output is unchanged. The process fix for a checker gap is an output-checking matrix: for every DUT output and every register field, name the checker that compares it, and treat an empty cell as a plan gap at the next review. On the DMA, that matrix would have had an empty cell for m_tlast on the first day. The process fix for the stimulus gap is equally concrete: sign-off requires every plan hole to be closed or explained, and a fault campaign runs before the review, so checker gaps show up as misses before silicon does it for you. With both fixes the scratch campaign in Where Assertions Live went from 5 to 7 of 8 faults caught.
Keep the review blameless. If the conclusion is "the engineer should have been more careful", the review has failed, because the same gap will open under the next engineer. The conclusion should name a change that would have caught the bug no matter who wrote the code.
The impact table: seven artefacts with owners and estimates, one of them blocked on a spec question about KEY reads. Show that the old regression on the new RTL already lists the tests that expected the old rule. Offer what can be cut and the risk of cutting it, for example deferring the reset-while-pending case with a written risk acceptance.
It changes nothing that would stop the next person making the same omission. The real failure is that no artefact required TLAST to be checked: no plan row named it and nothing mapped outputs to checkers. The conclusion should be an output-checking matrix reviewed at each milestone, plus a fault campaign before sign-off.
len=16 len>16 as holes for weeks. Which layer failed?Review and sign-off. The evidence was visible in every coverage log, so the stimulus gap was known; the process let sign-off proceed without requiring the holes to be closed or explained. The fix is a rule, not a test: every plan hole is closed, excluded with a reason, or accepted by name before sign-off.
Next: most of this work happens across team boundaries. Working with Design and Architecture covers the spec questions, the bug reports and the negotiations that make it go smoothly.