Coverage-Driven Verification
Coverage-driven verification is a hardware verification approach in which the verification process is guided by coverage metrics and coverage goals. In the provided UVM-based RISC-V evidence, simulation-based verification is described as a central part of the verification plan, and coverage metrics are used to determine whether a sufficient portion of the design under test (DUT) has been exercised.[1]
Coverage metrics
Coverage-driven verification depends on metrics that show how thoroughly the DUT has been exercised. The evidence distinguishes two major classes of coverage:[1]
- Structural coverage checks whether RTL code has been exercised. Examples include code coverage, toggle coverage, branch coverage, and finite-state-machine coverage. These metrics are automatically measured during simulation.[1]
- Functional coverage is specified by the verification user and cannot be inferred automatically from the design. It targets semantic aspects of the design by counting architecturally interesting events, checking that requirements and scenarios have been tested, and indicating how effectively stimuli exercise critical design behavior.[1]
Functional coverage is especially important in this methodology because it connects coverage results to intended design functionality rather than only to executed RTL structure.[1]
Verification flow and UVM testbenches
The evidence describes simulation-based verification as a fundamental ingredient of the overall verification plan. Once a testbench structure is fixed, the verification process is organized around a verification plan that begins with required tests and evolves toward more complex test scenarios.[1]
A UVM-style testbench contains two broad parts: stimulus generation and checking. Sequence generators create test sequences; the driver decodes sequence items and drives the DUT through an interface; the monitor observes communication at the DUT interface; and the scoreboard consumes monitor responses to check observed behavior against expected design behavior.[1]
SystemVerilog support for this style includes testbench constructs such as classes and constrained randomization, functional coverage constructs such as covergroups and coverpoints, and SystemVerilog Assertions constructs such as sequences, properties, assertions, and coverage statements.[2]
Coverage closure and automation
Coverage-driven verification often leads to a coverage-closure problem: given available tests or sequences and functional coverage goals, decide how to apply stimuli so that coverage improves efficiently. The provided RISC-V superscalar-processor thesis formulates this as choosing among direct or parameterized constrained-random sequences of uncertain quality in order to maximize verification coverage over multiple trials.[3]
The same evidence identifies automation needs in two phases: creating functional coverage models and applying tests for autonomous coverage closure with small regression-test time.[3]
Reported feedback-directed approaches include:[3]
- using a recurrent neural network to alter pseudorandom-generator constraints based on coverage-analysis data, including functional, statement, branch, expression, and FSM coverage;
- using feedback-adjusted Markov models, as in the StressTest tool, to optimize stimulus constraints toward higher activity at engineer-specified probe nodes and obtain better coverage in fewer cycles than random generation;
- using reseeding and checkpointing so that simulation continues with seeds that improve an objective function and rolls back when a seed does not improve it.
The Takakis thesis proposes two additional automation techniques for UVM-based verification of a RISC-V superscalar processor: a multi-armed-bandit model that suggests which constrained-random or direct sequences to apply, and a feedback-based mechanism that adjusts the simulation time allocated to constrained-random sequences based on their observed quality.[4]
RISC-V and UVM examples
The provided evidence includes two RISC-V verification contexts. One thesis, UVM-based verification of RISC-V superscalar processors: A reinforcement learning approach, applies coverage-driven automation ideas to a non-trivial 2-way superscalar out-of-order RISC-V processor, with the goals of increasing functional coverage and decreasing test-application time.[4]
Another RISC-V CPU verification source describes UVM as a standardized methodology built on SystemVerilog for constructing reusable digital-design testbenches. It identifies common UVM components such as drivers, monitors, stimulus generators, and scoreboards, and shows functional coverage and coverage monitoring as part of the SystemVerilog/UVM verification environment.[2]