Toggle Coverage

Toggle coverage measures whether each bit of every signal in the design has transitioned in both directions — 0→1 and 1→0 — at least once during simulation. Unlike other code coverage metrics that track whether a line or branch was executed, toggle coverage works at the signal level and is unique in its ability to detect stuck-at signals: bits that never change state throughout the entire regression, regardless of how much other logic was exercised.

What You'll Learn

• How toggle coverage bins work and what each one tracks
• What toggle holes reveal about missing stimulus and dead logic
• Which signals to prioritize and which to safely exclude
• How to interpret toggle coverage reports and close holes efficiently

The Two Bins Per Bit

For every single-bit signal, the simulator tracks exactly two coverage bins:

• 0→1: the signal transitioned from low to high at least once
• 1→0: the signal transitioned from high to low at least once

Both bins must be hit for that bit to be considered fully covered. A signal that powers up at 0 and stays at 0 the entire simulation has zero bins covered. A signal that powers up at 0, goes to 1, and stays at 1 has only one bin covered (0→1). Only a signal that transitions in both directions is fully covered.

module fifo_ctrl (
    input  logic        clk,
    input  logic        rst_n,
    input  logic        wr_en,      // Write enable
    input  logic        rd_en,      // Read enable
    output logic        full,       // FIFO full flag
    output logic        empty,      // FIFO empty flag
    output logic [3:0]  count       // Current fill level
);
    // ... implementation
endmodule

For this module, the simulator generates toggle bins for every input, output, and internal signal. A partial toggle coverage report might look like this:

Signal          0->1        1->0        Coverage
-------         ----        ----        --------
wr_en           HIT         HIT         100%
rd_en           HIT         NOT HIT     50%    << rd_en was never de-asserted
full            HIT         HIT         100%
empty           NOT HIT     NOT HIT     0%     << empty was never asserted
count[3]        NOT HIT     NOT HIT     0%     << FIFO never reached 8+ entries
count[2]        HIT         HIT         100%
count[1]        HIT         HIT         100%
count[0]        HIT         HIT         100%

Three distinct problems are visible immediately. rd_en was never de-asserted after going high — the testbench never tested back-pressure or a stalled read. empty was never asserted — the FIFO was never fully drained. count[3] never toggled — the fill level never reached 8 or above, meaning the upper half of FIFO capacity was never exercised.

Toggle Coverage on Multi-Bit Signals

For a bus or vector signal, the simulator generates two bins per bit. A logic [7:0] data signal produces 16 bins total — two for each of the eight bits. This is where toggle coverage can expose incomplete stimulus at the bit level that would be invisible to any other metric.

module alu (
    input  logic [7:0] operand_a,
    input  logic [7:0] operand_b,
    input  logic [2:0] opcode,
    output logic [7:0] result,
    output logic       carry_out
);

Consider a testbench that only drives small positive values (0x00–0x0F) through operand_a. The lower four bits toggle freely, but bits [7:4] are stuck at 0 throughout. Toggle coverage flags bits [7], [6], [5], and [4] of operand_a as having zero transitions — immediately revealing that the testbench never exercised the upper half of the input range. This class of bug — incomplete input space coverage — is very difficult to detect with branch or statement coverage alone.

For a signal declared as logic [N-1:0], the simulator generates 2×N toggle bins. A 32-bit bus produces 64 bins. Reviewing toggle holes on wide buses bit-by-bit is the most direct way to see which portions of the input or output data range were never driven.

What Toggle Holes Reveal

A toggle coverage hole on a signal can mean one of three things, and identifying which one determines the correct response:

1. Missing Stimulus

The most common cause. The testbench simply never drove the signal into one of its states. This is the actionable case — add or modify stimulus to hit the missing transition.

// error_inject input never driven high in any test
input logic error_inject

// Toggle report:
// error_inject   0->1: NOT HIT   1->0: NOT HIT

2. Dead or Disconnected Logic

The signal is driven by RTL logic that can never produce that transition given the rest of the design — either because the logic is structurally dead, or because a constant upstream feeds into it. This is a design bug, not a testbench gap.

// Example: a signal that should toggle based on a control input,
// but the control input is accidentally tied to a constant
assign flush_en = cfg_reg[4] & 1'b0;   // Bug: always 0, flush_en stuck low

No amount of stimulus will make flush_en go high because it is ANDed with a constant zero. The toggle hole here is pointing at an RTL bug, not a verification gap.

3. Legitimately Unreachable State

Some signal bits are architecturally constrained. For example, a 3-bit opcode field that only encodes values 0–4 will never have bit [2] go high without bit [1] also being set, meaning certain individual-bit transitions may be structurally impossible. These should be formally excluded with documented justification.