Schedules rarely die from coding speed. They die from late spec changes, broken third-party IP, and regression compute running out exactly when closure needs it. All three strike nearly every project, so the plan covers them from day one.
THE USUAL SUSPECTS
Risk │ Typical timing │ Mitigation planned up front
──────────────────────┼────────────────────┼────────────────────────────
Late spec change │ 60-80% through │ change-impact process:
│ schedule │ plan rows tagged by feature
│ │ → re-open affected rows only
3rd-party IP broken │ at integration │ IP acceptance smoke suite
│ │ BEFORE depending on it
Regression capacity │ closure phase │ measure seeds/night early;
shortage │ (when demand 10x) │ book compute at planning
Key engineer pulled │ anytime │ owner column + docs, no
│ │ single-owner critical paths
RTL freeze slips │ end │ coverage results time-tagged
│ │ vs RTL version — stale
│ │ closure is re-run, not arguedSpec changes get an impact drill, not archaeology. Tagging each plan row with its spec section at writing time keeps the drill a query.
Grep the plan for the changed sections and revert those rows from closed to open.
Re-estimate constraints, bins, assertions, and scoreboard model updates.
Report the cost in the same review that approves the spec change, not two weeks later.
Coverage closure is a compute problem: merged coverage grows with seeds times nights, and demand peaks when every project hits closure together. Measure the seeds-per-night burn rate early and book compute at planning time.
CAPACITY ARITHMETIC (example)
regression: 400 tests × 3 avg seeds = 1200 sims/night wanted
sim runtime: avg 25 min → 1200 × 25 = 500 cpu-hours/night
available: 15 licenses × 12h window = 180 cpu-hours/night → 2.8x short
levers, in order of preference:
1. cut sim waste — profile slowest 5% of tests; cap runaway tests
2. rank tests — coverage-per-cpu-hour; drop redundant ones nightly,
full sweep weekly
3. stagger — smoke per-checkin, full nightly, soak weekend
4. buy/borrow — escalate WITH this arithmetic, not with vibesWhen the schedule cannot fit the plan, something gives. Done well, descoping is an explicit risk-ranked decision with a waiver. Done badly, it is silent test deletion found after tape-out.
Candidates: low-risk features such as pass-through paths, well-proven reused IP, redundant crosses, and long-tail performance scenarios.
Never candidates: anything clock, reset, or power related, features with open bugs, or new logic of any perceived simplicity.
Each waiver records what stays unverified, why the risk is acceptable, who approved it, and the silicon-debug plan if it bites.
The waiver list is presented at sign-off review. Descoping is a project decision, not a team secret.
Done is evidence, not a feeling. Five items together make the sign-off case; any single metric alone is gameable.
Every verification-plan row is closed or explicitly waived.
Merged functional coverage meets goal, and every hole carries a written disposition.
Code coverage holes are reviewed.
The bug rate has converged: consecutive weeks of full-volume regression with no new priority bug.
All open bugs are dispositioned.
Risk travels upward in decision-grade form: status, root cause, cost, risk if ignored, and a concrete ask. Bad news reported early builds the credibility that buys schedule and compute later.
RISK ESCALATION — A FORMAT THAT WORKS
BAD: “Coverage is at 74% and the arbiter is concerning.”
GOOD: “Arbiter fairness coverage is 40% and flat for 2 weeks.
Root cause: random stimulus cannot create 4-master
contention; needs a directed scenario layer.
Cost: ~1 engineer-week.
If we skip it: starvation bugs of the class that caused
chip X's field recall stay unverified.
Ask: keep RK on arbiter 1 more week, slip reg-model
closure (low risk, reused IP) by the same week.”
status + root cause + cost + risk-if-ignored + a concrete askPush back with data: reset bugs rank among top respin causes while reset verification is cheap. Offer an equal-schedule lower-risk cut, and if overruled, record the waiver in writing with the risk spelled out.
Only the rows tagged with that spec section. Tagging at writing time turns impact analysis into a query instead of a dig.
No. Results are time-tagged against the RTL version, and stale closure is re-run, not argued.