Every verification team has seen a report at 94 percent functional coverage and asked: where is the remaining 6 percent, and does it matter? The second answer is rarely simple. The first is more consistent in our work with early-access teams: the missing coverage usually sits in state machine transitions the testbench was never designed to reach.
Review-surviving coverage gaps are systematic, not random. They reflect the order of RTL and testbench development, along with human blind spots that arise when engineers inspect code instead of the stimulus space.
Why Testbenches Start Too Early
Most chip projects follow a familiar sequence: architecture is defined, RTL implementation starts, and verification begins against a specification that may be incomplete or changing. When the RTL finally settles, the testbench is already fixed around assumptions from that earlier specification.
This produces a structural weakness. The most complicated state machines, including those added late for corner cases or protocol recovery, receive the least testbench coverage. The verification engineer who wrote the original UVM sequences did not know those states were coming. The engineer who added them to the RTL six weeks later often did not revisit the coverage model.
We observed this while supporting a team verifying a PCIe controller block. During RTL development, its TLP error recovery state machine was expanded twice for two additional error categories. Both changes received RTL review, but neither prompted a review of that module's coverage groups. The block's database reported 91 percent closure, while both added error paths remained entirely untested. They were absent from the coverage model, so they did not technically reduce functional coverage, yet they were precisely the sort of gap that can cause post-silicon bugs.
Why Code Review Misses Stimulus Gaps
RTL review effectively finds structural defects: invalid state transitions, incorrect output assignments, absent resets, and combinational feedback loops. Reviewers inspect the code and follow its logic. They do not enumerate the stimulus sequences needed to exercise every path.
A reviewer examining a state machine with 12 states and 30 transitions will confirm that its transitions behave correctly. They will not normally model the input sequence needed for every transition or verify that the testbench can generate it. Linking transitions to required stimulus is the work of coverage closure analysis. It differs from code review, and relying on mental analysis during review is unreliable.
The harder problem is that complex RTL can contain implicit cross-block dependencies that determine reachability. Reaching memory-controller error state S17 may require putting the cache coherency unit into a particular eviction state, then issuing a conflicting request at a specific cycle boundary. A human reviewer focused on RTL rarely tracks that entire stimulus dependency across blocks.
What Automated Stimulus Generation Targets
When BigEndian examines a coverage database, it does not begin by listing new tests. It first maps uncovered arcs to reachability dependencies that the current test suite cannot satisfy.
An arc may be reachable in simulation, but can an existing test produce the required sequence? Deeply nested error states may need ten to fifteen ordered events with timing constraints between them. A constrained random generator without coverage feedback will seldom reach such arcs, since randomly producing the complete sequence has extremely low probability.
We work backward from the uncovered arc. Starting with the target, we identify its predecessor states and the stimulus needed to reach each one. This backward reachability analysis yields a stimulus template, not a finished test, but provides enough direction for constraint generation to pursue the target instead of relying on chance.
Internal pilot data from three early-access teams shows that targeted arc analysis repeatedly found 15 to 30 uncovered arcs per block that were present in the coverage model but had never been hit in any regression run. The result points to a basic mismatch between typical random constraints and the demands of deep error paths, not to a failure by those teams.
The Design Understanding Gap
This issue is not solely about tooling. RTL authors know more about their designs than the documentation records, and that knowledge is not transferred systematically to verification. The engineer defining coverage groups works from specifications describing intended behavior, not every behavior the RTL may produce.
Error handling illustrates the problem. Specifications commonly detail the happy path while describing errors broadly. As the RTL author implements error handling, they make state-transition decisions that never enter the specification. Those transitions are verifiable, but only when someone knows they exist and adds coverage for them.
Automated stimulus generation does not directly resolve missing design knowledge. It can identify reachable RTL paths that remain untested and present them for a human decision: were they intentionally excluded from the coverage plan, or are they gaps to close? That decision should be made during coverage review, not after tape-out.
What Automation Cannot Replace
The limit is straightforward: automated stimulus generation cannot replace a well-structured coverage model. If a coverage group lacks a bin for a behavior, no generated stimulus will expose that omission. The tool follows the defined model and cannot determine what the model should include.
Coverage planning, deciding which behaviors require observation and which bins will track them, therefore remains the central verification activity. Automation closes gaps within a defined model, but does not create that model. Teams that plan coverage in detail before simulation gain more from targeted stimulus generation than teams that add coverage groups later.
On complex RTL, gaps survive review because code review and coverage planning are separate activities that are seldom synchronized adequately. Closing them begins by making that synchronization explicit, rather than by simply running more simulation cycles.