FSM coverage in simulation environments typically measures state hits: which states were entered during the simulation run. A coverage report showing 100% state coverage on a control FSM is often treated as evidence that the state machine has been fully exercised. It's usually not. State coverage and FSM correctness are measuring different things, and conflating them is how entire classes of state machine bugs persist through sign-off.
We work on RTL verification tooling, and the FSM-related violations we see surface most consistently in two categories that simulation coverage metrics rarely catch: unreachable states and incomplete transition coverage. Both are structural properties of the FSM graph that static analysis can extract from the RTL directly, without simulation.
What State Coverage Actually Measures
State coverage measures whether the simulation exercise visited each state at least once. For an N-state FSM, full state coverage means all N states were entered during the simulation run. This is a useful sanity check — states that are never entered in simulation might indicate dead code or a testbench that isn't exercising enough of the design's operational envelope. But it doesn't tell you much about correctness.
The failure mode: a state that is reachable and frequently visited during simulation can still have incorrect or incomplete outgoing transitions. If a state has three defined outgoing transitions in the spec and the RTL implements two of them, the state will appear fully covered in state coverage metrics. The missing transition will never be exercised in simulation, but the coverage tool has no way to know a transition is missing unless it has the spec to compare against — which it doesn't.
Transition coverage is a better metric than state coverage, but it has its own gap: it measures whether each implemented transition fired at least once. It cannot measure whether the set of implemented transitions is complete according to the design spec. A structurally incorrect FSM with missing transitions will show complete transition coverage for the transitions it has.
Unreachable States: A Structural Problem, Not a Simulation Problem
Unreachable states are states that exist in the RTL but cannot be entered through any reachable sequence of transitions from the initial state. They're a code quality issue and a potential security issue — in some applications, unreachable states can become reachable if a fault, bit flip, or hardware glitch corrupts the state register and deposits the FSM in an illegal state. If the unreachable states don't have explicit handling (a return-to-reset transition, an error assertion), the FSM behavior from that point is undefined.
Simulation can't systematically find unreachable states because simulation can't drive the FSM into a state that's unreachable through its transition graph — the simulation follows the same transition graph as the design. The only way to "find" an unreachable state in simulation is to force the state register to the unreachable value, which requires knowing in advance which states are unreachable. That's circular.
Static FSM analysis extracts the transition graph directly from the RTL, then performs a reachability analysis starting from the reset state. Every state that's not reachable from reset is flagged. This is a polynomial-time analysis on the number of states, tractable for FSMs up to several thousand states, and it produces a definitive list of unreachable states rather than a probabilistic assessment based on what the testbench happened to exercise.
The Encoding Problem and Its Simulation Implications
FSMs in Verilog and SystemVerilog are typically encoded as binary or one-hot registers. The encoding choice has practical implications for simulation coverage that aren't always well understood.
For a one-hot encoded FSM with N states, the state register is N bits wide, with exactly one bit asserted at any time. The valid state space has N states. But the state register can physically hold 2^N values, of which only N are valid one-hot encodings. The invalid encodings — states where zero bits or two-plus bits are asserted — are garbage states that shouldn't be reachable in normal operation but can be reached through reset glitches or SEU (single-event upset) events in space-grade or safety-critical applications.
Simulation state coverage for a one-hot FSM typically measures coverage of the N valid states. It doesn't check what happens if the design enters one of the 2^N - N invalid encodings. A synthesis tool may optimize away the don't-care handling for invalid encodings if the RTL doesn't explicitly handle them — producing a synthesized netlist that behaves unpredictably in those states. Static analysis can flag FSMs where invalid state encoding handling is absent, pointing the verification team toward adding explicit illegal-state assertions or reset recovery logic before synthesis.
Transition Completeness: What the Spec Knows That the RTL Doesn't
Transition completeness — whether the RTL implements all the transitions the design spec requires — can't be verified by static analysis alone, because static analysis works from the RTL rather than the spec. But static analysis can extract the implemented transition graph and make it easy to compare against the spec manually, which is considerably faster than trying to infer the transition graph from a simulation coverage report.
The workflow we've found useful for FSM verification: run static FSM extraction to produce a structured representation of the state machine (states, transitions, encoding), overlay that against the spec transitions, and use simulation to verify the transitions that exist in both. Discrepancies — transitions in the spec that don't appear in the static extraction, or transitions in the static extraction that don't appear in the spec — are candidates for either bugs or undocumented intentional changes.
A practical example: a controller FSM for a PCIe link training block at an early-stage ASIC design shop had a state DETECT_QUIET with four outgoing transitions defined in the PCIe spec. Static extraction of the RTL showed three implemented transitions. The fourth — the transition handling the case where the timer expires without detecting a valid receiver — was missing. Simulation hadn't caught it because the constrained-random testbench was generating stimulus that always produced a valid receiver response before the timer expired. The coverage report showed full state coverage; the missing transition was dark to it entirely.
Synthesis Behavior on Incomplete Case Statements
FSMs implemented with case statements in Verilog synthesize differently depending on whether the case statement is full (covers all possible input combinations) or partial. A partial case statement — one where some input combinations don't have explicit handling — allows the synthesis tool to assume the unspecified combinations are don't-cares and optimize accordingly. The simulation behavior for the unspecified combinations may differ from the synthesized hardware behavior, because the simulator models the RTL semantics while the synthesized hardware reflects the optimizer's don't-care assignment.
This is a well-known discrepancy class between simulation and gate-level behavior, and it shows up with particular frequency in FSMs where the case statement covers the defined states but doesn't handle the illegal encoding states. Static analysis can flag incomplete case statements and distinguish between ones where the incompleteness is intentional (explicitly marked with // synthesis full_case or equivalent pragmas) and ones where it's an oversight.
The distinction matters. An explicitly marked full_case pragma is a deliberate trade-off — the designer is telling the synthesis tool to optimize for the valid state space. An unmarked incomplete case statement is a potential bug. Coverage tools don't differentiate between the two. Static analysis can.
Building FSM Verification Into the Flow
The practical conclusion from the above is that FSM verification needs both simulation and static analysis, applied to different concerns. Simulation exercises the implemented transition graph under realistic stimulus. Static analysis validates the structural properties of the FSM — reachability, completeness of encoding handling, and detection of states and transitions that simulation can't exercise.
The static checks that belong in the pre-simulation gate: reachability analysis from reset, detection of states with no outgoing transitions (dead-end states), flagging of one-hot or binary encoded FSMs without illegal-state handling, and identification of incomplete case statements without full_case pragmas. These run quickly and produce actionable results before simulation starts.
We're not arguing that FSM simulation is low-value. Functional simulation of FSM behavior under constrained-random stimulus is how you validate that the transition logic is correct for the transitions that exist. What we're arguing is that passing FSM simulation coverage targets is not the same as verifying FSM structural correctness — and that treating them as equivalent is a reliable way to find FSM bugs at the worst possible time.
The structural properties of a state machine are fixed once the RTL is written. Static extraction can read them out exhaustively. That exhaustiveness is the thing simulation, by its nature, can't offer — and for FSMs, it's exactly what verification teams need alongside their simulation coverage numbers.