A week before tape-out, the system architects ask for one change to DCRouter: make the idle threshold before sleep programmable, instead of fixed at 8 cycles, because a customer's traffic pattern sleeps and wakes too often. It is a small RTL change: a register field and a comparison. It also touches the sleep logic that holds three Bug Zoo bugs' worth of risk, the coverage model's sleep bins, the driver and the register map. "Small change" describes the edit, not the risk.
A late change lands a week before tape-out. What do you do?
Two obvious answers. "Make it, the regression will catch anything" assumes the regression covers what the change affects; the new behaviour (thresholds other than 8) is untested by definition. "Refuse every late change" ignores that some changes fix real problems customers would otherwise hit. Each change needs an impact assessment: what it touches, what must be re-verified, what it costs, and what not making it costs.
Step | Questions |
|---|---|
Impact analysis | Which features, rules, checks, coverage bins, proofs and software does it touch? What new behaviour does it add? |
Re-verification plan | Which existing tests and proofs must re-run? What new tests, checks and bins does the new behaviour need? |
Cost and risk | How long will that take? What is the risk if it is rushed? What is the cost of not changing? |
Decision | Make it now, make it with a restriction (for example, a fixed safe default), defer to a later revision, or refuse |
Record | Update the specification, plan and evidence ledger; note any residual risk for sign-off |
Affected | Re-verification needed |
|---|---|
R13 sleep rule and the CTRL or a new register | Specification update; register table and register app re-run |
Sleep assertions (lesson 5.3) | The "asleep within 10 cycles of idle" assertion must use the programmed threshold |
Coverage model (lesson 6.9) | New bins: threshold at minimum, default and maximum; sleep entered at each |
Formal properties (lesson 7.9) | Re-run: credit conservation spans sleep (it catches BUG_22), and the harness must leave the new threshold field free or constrain it; no property states the threshold itself, and one would be cheap |
Driver | Must program the threshold, or rely on the reset default |
Bug Zoo runs | Re-run to show the testbench still catches all 24 |
A defensible decision: make the change with the reset value equal to the old fixed threshold of 8, so existing behaviour is unchanged unless software opts in; verify the new behaviour at minimum, default and maximum thresholds; and record "non-default thresholds verified at three points only" as residual risk in the sign-off ledger. If the week cannot absorb even that, defer the change and give the customer a software-side mitigation.
Every change gets an impact analysis, however small the edit.
Re-verify what the change touches, plus the regression: the regression alone covers only old behaviour.
Prefer changes that preserve existing behaviour by default (reset values, disabled options).
Freeze progressively: as tape-out approaches, the bar for accepting a change rises.
Make residual risk visible: anything accepted without full verification goes to the sign-off ledger.
Practice | Purpose |
|---|---|
Change control boards with verification represented | Impact on verification part of every decision |
Feature freeze and RTL freeze milestones | Rising bar for late changes |
Impact analysis linked to the plan's traceability | Affected features and checks found mechanically |
A team (illustrative) accepted a one-line late fix to a FIFO's almost-full threshold, re-ran the full regression, saw it pass and taped out. The regression had never tested the threshold value the fix introduced, because no test drove that exact occupancy with the downstream stalled. The fix was correct for the case it targeted and broke a back-pressure case two entries away. A re-verification plan for the change would have asked for tests at and around the new threshold.
The regression tests only the old fixed threshold; behaviour at every other threshold is new and untested.
So the design behaves exactly as verified unless software opts in, limiting the change's risk to the new, opt-in behaviour.
Judge a change by what it touches, not by the size of the edit.
Assess impact, plan re-verification, compare costs, decide, and record residual risk.
Prefer default-preserving changes and raise the bar as tape-out approaches.