Coverage tells a verification team which parts of the plan have been exercised. In simulation, coverage monitors watch every signal for free.
On silicon, almost nothing is visible, so measuring coverage takes planning: monitors built into an emulator model, events counted by performance counters, and a few coverage points built into the chip. This article explains why silicon coverage is hard, the ways teams measure it, and how coverage results steer what runs in the lab.
6 min read | Intermediate
What You'll Learn
- Explain why coverage is hard to measure on silicon
- Describe three ways to estimate coverage of silicon tests
- Use emulator coverage to choose which tests run on silicon
- Track plan coverage across platforms
Why Coverage Is Hard on Silicon
A coverage point records whether something happened: a buffer became full, two requests collided, a state machine visited a state. In simulation, a monitor checks every cycle at no cost to the design.
On silicon, a monitor needs real hardware, its result must be read out, and both cost area and power. A chip cannot carry the thousands of coverage points a simulation uses. Coverage on silicon is therefore estimated from a few sources.
Three Sources of Coverage
1. Monitors on the emulator
Coverage monitors can be synthesized into the design model running on an emulator or accelerator, without adding anything to the silicon. Each silicon test, for example each exerciser template, is run there first, and its coverage is recorded.
This gives a pre-silicon estimate of what each test will cover on silicon. Large processor programs have used exactly this to develop silicon tests with a coverage-driven method like pre-silicon verification.
2. Performance counters on silicon
The event counters of Monitors on the Die count many coverage-like events: cache misses, evictions, branch mispredictions, queue-full conditions, retries. Reading them after each run shows which events a test actually caused on silicon.
3. Coverage points in the chip
A small number of sticky bits or counters for rare, important events can be built into the silicon. They are chosen carefully, for events that matter most and that counters cannot already show.
Quick Check
Q: Why are coverage monitors added to the emulator model but not to the silicon?
Show Answer
On the emulator they cost nothing in the product: no area, power or timing impact on the chip. They measure what each silicon test covers before silicon exists. Adding the same monitors to silicon would cost real area and power in every chip shipped.
Choosing What Runs on Silicon
Silicon time is scarce, so the choice of tests matters. Emulator coverage helps:
- Templates that reach new coverage points are kept; those that add nothing are dropped.
- Shortly before silicon, a regression suite is assembled from the templates that together cover the most of the plan.
- Plan items no template reaches show where new tests are needed.
On silicon, counter data then confirms that the tests behave as expected at full speed, and shows events that occur far more often, or less often, than on the emulator.
Tracking the Plan
Each plan item in The Post-Silicon Validation Plan records how it is covered and where: in simulation, on the emulator, on silicon, or by electrical measurement. A coverage report by item, not just a percentage, is what supports the production release decision. "92 % covered" means little; "all items covered except these three, which are accepted for these reasons" means a lot.
Quick Check
Q: On silicon, a counter shows that a queue-full event happens a thousand times more often than on the emulator during the same test. Is that a problem?
Show Answer
Not necessarily a bug, but worth understanding. Silicon runs much longer and with real memory latencies, so traffic patterns differ. It confirms the event is well covered on silicon, and it may reveal a performance issue or a difference between the emulator's memory model and the real system.
In Practice
Teams keep one coverage database for all platforms, so a plan item can be marked covered by whichever platform reached it. When a silicon failure is reproduced on the emulator, its coverage there also shows which other templates reach the same area, which helps find related bugs.
Common Mistakes
Mistake #1: Assuming silicon covers everything because it runs long
Long runs repeat common behaviour. Measure what tests actually reach.
Mistake #2: Reporting only a percentage
Report coverage per plan item, with reasons for anything not covered.
Mistake #3: Ignoring counter data on silicon
Counters confirm that tests do on silicon what they did on the emulator.
Practice Exercise
Challenge: Pick the Suite
Four templates cover these plan items on the emulator: T1 covers items 1-40; T2 covers 30-60; T3 covers 55-90; T4 covers 1-20 and 85-100. Which two templates cover the most items together, and which items remain uncovered?
Hint
Count the union for each pair.
Solution
T1 with T3 covers 1-40 and 55-90: 76 items, leaving 41-54 and 91-100. T2 with T4 covers 1-20, 30-60 and 85-100: 67 items.
T3 with T4 covers 1-20 and 55-100: 66 items. T1 and T3 is best; a third template, T2 for 41-54 or T4 for 91-100, closes the gaps.
Summary
- Silicon has too little visibility for simulation-style coverage.
- Coverage is estimated from emulator monitors, silicon counters and a few built-in coverage points.
- Emulator coverage selects the templates that run on silicon.
- Coverage is reported per plan item, across all platforms.
