Skip to content
STIMSMITH

RISC-V Compliance Suites

Concept WIKI v1 · 5/26/2026

RISC-V compliance suites are directed validation test suites used to provide structured architectural and feature coverage in processor verification flows. In the provided evidence, ImperasTS is the main example: it includes TS-ISA architectural validation tests similar to compliance suites, plus targeted suites for vector, MMU, PMP, and ePMP features. These suites are self-checking, compare results against a reference model, and are used with constrained-random stimulus to close coverage gaps across simulation, emulation, FPGA prototyping, and silicon-oriented validation.

Overview

RISC-V compliance suites are directed test suites used in RISC-V processor verification to provide structured architectural validation and feature coverage. The evidence describes ImperasTS as a directed suite family that complements constrained-random generation by targeting areas where random stimulus can leave coverage gaps. [C1]

Within this flow, TS-ISA provides architectural validation tests described as similar to compliance suites and included with ImperasDV licences. Additional ImperasTS suites target vector extensions, virtual memory, and protection features. [C2]

Suite Types

The ImperasTS family described in the evidence includes:

  • TS-ISA: architectural validation tests, similar to compliance suites, included with ImperasDV licences. [C2]
  • TS-VECT: targeted test suites for RISC-V vector extensions. [C2]
  • TS-MMU / PMP / ePMP: directed suites for virtual memory management and memory protection features. [C2]

The vector, MMU, PMP, and ePMP suites are configured to match the user's RISC-V processor. [C3]

Role in Coverage Closure

Directed compliance-oriented suites are used to close coverage gaps left by broader random exploration. The evidence gives an example in which coverage analysis found weak points in Sv39 and Sv48 page-table walks; adding TS-MMU tests exposed a subtle ordering issue in TLB flush logic. [C3]

A typical hybrid verification workflow begins with constrained-random sweeps using STING, then applies functional coverage analysis with ImperasFC, and finally uses targeted directed suites such as ImperasTS where coverage gaps remain. [C4]

Self-Checking and Reference Comparison

ImperasTS suites are described as self-checking and as automatically comparing results against a reference model. This makes them useful for detecting subtle design issues while accelerating coverage closure. [C5]

In a broader flow, ImperasDV can provide lock-step comparison against a reference model, catching errors at instruction retirement. This debug style helps identify mismatches immediately and simplifies root-cause analysis. [C6]

Portability and Lifecycle Use

The evidence describes a portable RISC-V verification approach in which tests can run across simulation, emulation, FPGA prototyping, and silicon. Tests developed during RTL bring-up can remain useful in later validation stages. [C7]

The same stimulus can be reused in environments such as VCS simulation, ZeBu emulation, and HAPS prototyping, with Verdi used for centralized debug in the described flow. [C8]

Benefits

The compliance-suite-oriented directed testing approach contributes to:

  • Faster coverage closure, by combining random stimulus for unexpected behavior with directed suites for precise closure. [C9]
  • Improved debug efficiency, by using self-checking tests and lock-step comparison to identify mismatches early. [C6]
  • Scalability and reproducibility, through logged seeds and directed reruns across regression cycles. [C9]
  • Future-ready compliance coverage, including RISC-V profiles such as RVA22 and RVA23 and privilege-related specifications such as MMU, PMP, hypervisor, and vector extensions. [C9]

Position in a RISC-V Verification Strategy

The evidence recommends using broad constrained-random exploration first, then applying targeted ImperasTS suites for compliance, MMU, PMP, and vector extensions where coverage gaps remain. Coverage and debug results can be integrated by merging ImperasFC or ImperasSC results into Verdi and replaying failing cases deterministically in VCS. [C10]

LINKED ENTITIES

5 links
PMP targets_feature
ePMP targets_feature
ImperasDV integrates_with
STING complements
ImperasFC supports_coverage_analysis

CITATIONS

10 sources
10 citations
[1] ImperasTS directed suites complement constrained-random generation by targeting coverage gaps. source
[2] TS-ISA is an architectural validation test suite similar to compliance suites and included with ImperasDV licences; TS-VECT targets vector extensions; TS-MMU, PMP, and ePMP target virtual memory and protection features. source
[3] Vector, MMU, PMP, and ePMP suites are configured to match the user's RISC-V processor, and TS-MMU tests can expose coverage-gap-related issues such as TLB flush ordering problems after Sv39 and Sv48 page-table-walk coverage analysis. source
[4] A hybrid workflow begins with STING constrained-random sweeps, uses ImperasFC functional coverage analysis, and applies targeted directed suites for remaining gaps. source
[5] ImperasTS suites are self-checking and automatically compare results against a reference model to uncover subtle design issues and accelerate coverage closure. source
[6] ImperasDV supports lock-step comparison against a reference model at instruction retirement, and combining self-checking tests with lock-step comparison improves debug efficiency. source
[7] RISC-V test stimulus can be portable across simulation, emulation, FPGA prototyping, and silicon, supporting shift-left verification and reuse from RTL bring-up into later validation stages. source
[8] The described flow can execute constrained-random programs in VCS, use Verdi for centralized debug, and reuse stimulus in ZeBu emulation or HAPS prototyping. source
[9] The hybrid approach provides faster coverage closure, scalability and reproducibility through seeds and reruns, and support for profiles and privilege-related specifications including RVA22, RVA23, MMU, PMP, hypervisor, and vector extensions. source
[10] Recommended next steps include broad STING exploration, applying ImperasTS suites for compliance and feature gaps, integrating coverage and debug with Verdi, replaying failing cases in VCS, and shifting verification earlier with ImperasSC. source