A coverage model is only as good as the questions it asks. Bins on raw signals are easy to fill and say little. This topic models the things that cause bugs: how deep the outstanding table was, how soon an ID came back, which legal combinations ran, and which multi-cycle scenarios happened.
Every lesson has a runnable bench. The free simulators here cannot collect covergroups, so each bench checks a procedural mirror of the bins against a hand count, and the page says so. The covergroup code is shown next to it for a commercial tool.
WHAT A REAL-FEATURE COVERAGE MODEL MEASURES
pins ──► monitor ──► transactions ──► derived state ──► covergroup
│ (depth, reuse (bins, filtered
│ distance, latency) crosses)
└──► sequences on the pins ──► cover property
(temporal rows)
per test: coverage database
per regression: merge ──► rank ──► holes ──► stop or spend more seedsLesson | What it covers |
|---|---|
Sample transactions, not signals. Cover derived state such as outstanding depth and ID reuse distance. | |
| |
| |
Merging, greedy test ranking, seed budgets from hit probabilities, and when to stop. |
req_id with four bins reaches 100% in the first test. Why does that tell you almost nothing about an out-of-order controller?Any test that issues four IDs fills it. The bugs live in how IDs interact: how many were outstanding, how soon an ID was reused after its response, and what the response order was. Those are derived quantities, and the bins must be on them.