Introduction: Why Coverage is the True Metric
Verification engineers understand that raw simulation cycles or bug counts are not a complete measure of progress; we also need to consider coverage of requirements and specifications. This is typically provided by functional coverage, structured evidence that the requirements and specifications are covered. For RISC-V-related projects, functional coverage refers to ISA extensions, privilege transitions, safety requirements, etc. Coverage is a sign-off metric and a safety case artefact for configurable and extensible architectures such as RISC-V. Without closure, verification risks remain hidden [1].
This blog presents a verification-first flow for functional coverage using Synopsys VCS, Verdi, and ImperasDV. It explains how coverage models are built for RISC-V, how gaps are detected and closed, and how Synopsys’ integrated toolbox enables engineers to achieve closure efficiently and present audit-ready evidence [2].
1. Functional Coverage in RISC-V Verification
In practice, applying functional coverage to RISC-V means defining bins across the base instruction set, the optional extensions, the privilege mode transitions, exception handling, and the CSR accesses [1]. Once defined, these bins become the quantitative contract between the verification environment and the design specification. Without this, it is impossible to demonstrate that the verification plan has been fully executed.
2. Building Coverpoints and Cross Coverage
Coverage models are constructed in SystemVerilog, with coverpoints tracking individual events and cross coverage capturing meaningful combinations. For example, a covergroup for CSR access might define bins for machine-mode CSRs and supervisor-mode CSRs, then cross them with read/write operations.
covergroup csr_access @(posedge clk);
cp_csr: coverpoint csr_addr {
bins machine_csrs[] = {12’h300, 12’h305, 12’h341};
bins supervisor_csrs[] = {12’h100, 12’h105};
}
cp_access: coverpoint csr_op; // read / write
cross cp_csr, cp_access;
endgroup
Manual creation of these coverage models is time-consuming and error-prone. Complex RISC-V cores can require multiple lines of SystemVerilog code spread across multiple files.. This is where the Imperas functional coverage (ImperasFC) library, integrated with Synopsys flows, is essential. It can automatically generate coverage models from machine-readable ISA specifications, including custom instructions, ensuring that even extended cores are tracked consistently [2].
Figure 1: Synopsys VCS testbench integrated with ImperasDV reference model and riscvISACOV functional coverage, auto-generating coverage models from the RISC-V ISA [2].
3. Coverage in the Synopsys Verification Flow
Coverage does not stand alone; it must be embedded within a complete verification flow. Synopsys VCS collects coverage as part of simulation, whether driven by directed tests or constrained-random stimuli. ImperasDV integrates as a lock-step reference model, supplying functional coverage models and advanced pipeline synchronisation for asynchronous events. Coverage results are then consumed by Synopsys Verdi, which not only visualises results but also correlates bins with waveform data and produces closure reports [1].
Figure 2 (workflow diagram) shows functional coverage as the heart of the DV lifecycle after feature scoping, testbench development, checkers, and final sign-off.
Figure 2: RISC-V verification workflow highlighting Step 4 – Functional coverage modelling within the DV lifecycle
4. Closing Coverage Holes
In practice, constrained-random regressions often leave holes in coverage. Some scenarios are rare, others structurally unreachable. Engineers must actively close these gaps. The main techniques include directed tests for rare sequences, formal analysis to prove bins unreachable, and mutation or fault seeding to validate the completeness and quality of the coverage model. [2]. With this approach, coverage reports evolve from red and amber gaps to a fully justified, defensible closure state. Engineering judgment meets metrics in this closure activity: exclusions must be justified, and holes must be explained.
5. Coverage Closure: Metrics and Reports
Coverage closure requires clear metrics and reporting. Verification teams typically track percentage coverage per ISA extension, privilege mode transitions, CSR and exception coverage, and assertion coverage (to prove properties are not vacuous). These reports, consolidated through Verdi Verification Manager, confirm that verification intent has been fulfilled [1].
Figure 3: Synopsys RISC-V processor verification toolbox combining VC Formal, VCS, Verdi, ZeBu, and ImperasDV for complete coverage closure [1].
6. Debug & Analysis with Verdi
When coverage bins remain unhit, Verdi provides a powerful debug path. Engineers can drill into missed scenarios, cross-probe coverage points against waveforms, and export detailed gap reports. Linking coverage failures back to specific stimuli enables teams to add or refine tests efficiently. Verdi’s ability to export Markdown and CSV summaries ensures coverage data is not trapped in a tool but can flow into project-level verification plans and compliance documentation [1].
7. Optional Acceleration with ZeBu
Coverage closure often requires very long regressions, especially for rare events. By mapping the same coverage-driven testbenches onto ZeBu emulation, teams can accelerate throughput while maintaining observability. Coverage metrics are collected similarly, ensuring consistency across simulation and hardware-assisted platforms [1].
8. Results & Sign-Off
At the end of the campaign, functional coverage serves as the contract between the verification environment and the design specification. With Synopsys VCS, Verdi, and ImperasDV, teams can automatically generate coverage models, close gaps with a combination of simulation, formal, and directed tests, and deliver structured reports. These artefacts provide the audit-ready evidence that the verification plan has been fully executed and that the RISC-V core is ready for silicon sign-off.
Conclusion
In RISC-V processor design verification, coverage is proof. Because coverage models are derived directly from the ISA and the specification, engineers can ensure no instruction, extension, or privilege feature slips through untested. By centring the flow on functional coverage and leveraging the Synopsys toolbox, coverage metrics become defensible evidence for sign-off. Coverage metrics are not just numbers. They are the structured evidence that links the ISA specification, the testbench, and the final safety or product certification.
To explore the complete Synopsys verification and safety toolchain, visit synopsys.com.
Next Steps
- Deploy Synopsys ImperasFC coverage models in your UVM environment.
- Run constrained-random and directed campaigns in VCS.
- Use Verdi dashboards to triage gaps and sign off coverage reports.
Appendix A: Definitions
- Functional Coverage: A Metric that measures whether verification scenarios map to the design specification.
- Coverpoint: A tracked item or event in coverage.
- Cross Coverage: Tracking combinations of two or more coverpoints.
- Coverage Hole: A scenario not yet exercised.
- Coverage Closure: Filling holes or proving bins unreachable.
- Imperas Functional Coverage (ImperasFC): Auto-generates SystemVerilog coverage models from the RISC-V ISA specification, including custom extensions.
- ImperasDV Reference Model: A fast RISC-V reference model integrated with Synopsys flows via RVVI for lock-step checking and functional coverage capture.
Appendix B: Synopsys Products
- Synopsys VCS® - Industry‑standard RTL simulator with SystemVerilog Assertions (SVA). Used for executing workloads, scripted fault‑injection campaigns and collecting coverage.
- Synopsys Verdi® - Advanced debug and visualisation platform for waveform alignment, cross‑probing, cone‑of‑influence tracing, and generating reproducible audit artefacts for safety cases.
- Synopsys ImperasDV - RISC‑V front‑end verification environment using reference models and RVVI‑TRACE for pipeline synchronisation and asynchronous stimulus coverage.
- Synopsys ZeBu® - Hardware‑assisted emulator for accelerating long regressions and rare‑event scenarios, with smooth integration to Verdi for debug.
References
[1] Synopsys, “RISC-V Processor Verification Requires the Full Toolbox,” 2025.
[2] Randle Brian, “RISC-V DV with RVVI-TRACE & Asynchronous Stimulus – ImperasDV presentation,” 2023.
Top comments (0)