This course spent one lesson building DCRouter's shared test environment (lesson 4.1). Every later DCRouter testbench, from directed tests to the covered hunt, reused it unchanged, and each new test was a few dozen lines. The arbitration checker, the assertions and the coverage model became includes that any test could add. That first investment did not find a single bug by itself. It made every later bug cheaper to find.
Where would you invest next quarter?
The obvious use of verification time is writing tests, because tests find bugs and bugs are the visible output. Teams that only write tests rebuild the same drivers, checkers and scripts for each block, run slow regressions, and debug by hand. Infrastructure is invisible in a weekly bug count and decisive across a year: it changes the cost of every test that follows.
Investment | Pays back through | DCRouter example |
|---|---|---|
Reusable environment (drivers, monitors, scoreboard) | Every test becomes short | dcr_env.svh: all Part 4–6 testbenches |
Shared checkers and assertions | Every test checks more, for free | dcr_sva.svh and dcr_fair.svh |
Coverage models | Holes show where to spend effort | dcr_cov.svh found both escaped bugs |
Reference models and generated register models | Oracles written once (lessons 2.3, 2.4) | The Python reference model and register table |
Regression speed and parallelism | More runs per day, faster feedback | bug-zoo.mjs running builds in parallel |
Debug and triage tools | Hours saved per failure | Failure messages naming rules; signature bucketing (lesson 13.5) |
Testbench self-checks (planted bugs, mutation) | Confidence the checks work | The Bug Zoo itself |
Count the uses: how many tests, blocks or projects will use it? One use rarely justifies infrastructure.
Count the time per use: minutes saved per test or hours per debug, times the uses.
Count the bugs it enables: checkers and coverage find bugs tests alone miss (the matrix of lesson 6.9).
Count the risk it removes: a generated register model removes a whole class of copy errors.
Prefer what travels: assets usable at block, subsystem and chip level and on the next project (lesson 8.3).
Practice | Purpose |
|---|---|
A verification infrastructure team or a share of each team's time | Infrastructure is planned, not squeezed in |
Libraries of agents, checkers and coverage per interface | Reuse across blocks and projects |
Metrics on regression throughput and time-to-debug | Infrastructure value made visible |
A team (illustrative) wrote a new scoreboard for each of five similar blocks, each by a different engineer, each with slightly different matching rules. Two of the five had ordering bugs of their own; a shared, reviewed scoreboard written once would have been better than all five and cost less than two of them.
Every later testbench reused it, so each new test cost a few dozen lines and gained the scoreboard's checks automatically.
Generating register models, RTL and headers from one machine-readable register map, which removes copy errors between them.
Infrastructure makes every future bug cheaper to find.
Judge investments by uses times time saved, plus bugs and risk they remove.
Environments, checkers, coverage, regression speed and triage tools usually pay best.