Asked how long DCRouter's verification will take, an engineer counts testbench components, tests and checkers, multiplies by typical days each, and answers "six weeks". The answer leaves out the parts this course has spent most of its time on: the arbitration checker that needed three versions (lesson 5.5), the coverage holes that needed a new test phase (lesson 6.9), the formal properties that failed on the clean design at step 2 (lesson 7.9). Building things is predictable. Finding out they are wrong is not.
How long will verification take, and how do you say so honestly?
The obvious estimate adds up the things to build. It is usually accurate for building and badly wrong overall, because building is often the smaller part of the work. The rest is debugging failures (in the design and the testbench), closing the last coverage and corners, re-verifying after changes, and reviews. These depend on how many bugs there are, which is exactly what is unknown at the start.
Component | How to estimate | Typical uncertainty |
|---|---|---|
Environment build (agents, scoreboard, models) | Per component, from past projects | Low |
Tests, sequences and properties | Per feature from the plan, by risk and method | Medium |
Debug | Proportional to expected bugs; reuse past bug rates per feature type | High |
Coverage closure and corners | From past closure curves (lesson 6.5): the last few percent cost the most | High |
Change absorption | A share of the schedule for specification and design changes | High |
Reviews and sign-off | Fixed points in the schedule | Low |
Give a range, with what drives it: "8 to 12 weeks; the upper end if arbitration bugs are as frequent as on the last router."
Hold an explicit reserve for the high-uncertainty components, rather than padding every task invisibly.
Use history: past projects' bug counts per feature type and closure curves are the best predictor.
Re-estimate at milestones, from the bug discovery rate and the closure curve (Part 12).
The DCRouter testbenches in this course give a small, honest example of the split. Writing each environment piece was fast. Most of the time went to finding out that something was wrong and why:
Step | Planned as | What actually took the time |
|---|---|---|
Back-pressure test (lesson 4.8) | One testbench | A first version that found nothing extra, then an audit that failed the clean design until the sinks were drained first |
Arbitration checker (lesson 5.10) | One checker | Three versions: false failures in 17 of 30 seeds, then misattributed failures, then a correct model of timing |
Coverage model (lesson 6.9) | A bin list | Reading 30 holes and writing a phase of tests from them |
Formal proofs (lesson 7.9) | A property file | Tool limits (no bind, no hierarchical references, no |
None of these surprises was in an estimate made from a list of components; every one of them is the kind of work an honest estimate reserves time for.
Practice | Purpose |
|---|---|
Bottom-up estimates from the plan's features, by method | Estimates tied to scope |
Historical databases of bug rates and closure times | Debug and closure estimated from evidence |
Ranges and explicit reserves in schedules | Uncertainty visible to management |
Re-estimation at every milestone | Schedules corrected by measured progress |
A team (illustrative) estimated a block at ten weeks by summing component estimates and committed to the date. Building finished in week five. Bugs then arrived at a steady rate for eight more weeks, and the last coverage holes took three. The estimate was not wrong about any task it contained; it simply contained none of the work that dominated.
Building is the predictable minority of the work; debug, closure and change absorption dominate and are left out.
It makes the uncertainty visible and manageable: everyone can see what it is for and how much remains, instead of hidden padding that is spent invisibly.
Building is predictable; debug, closure and change absorption dominate and are not.
Estimate bottom-up from the plan and from history; give ranges with named drivers.
Hold an explicit reserve and re-estimate from measured bug rates and closure curves.