RISC-V Verification IP: What It Covers and What CPU Teams Must Still Verify

RISC-V verification IP is reusable technology that helps verify a processor implementation. It may include reference models, instruction-stream generators, trace interfaces, checkers, functional-coverage assets and UVM components. These assets can reduce duplicated engineering effort and strengthen verification evidence, but they do not replace a project-specific verification strategy. CPU teams must still own requirements, configuration, model qualification, implementation-specific verification, coverage interpretation, defect closure, SoC integration and the final sign-off decision.

What Is RISC-V Verification IP?

Verification intellectual property, or verification IP, is reusable verification functionality rather than the processor design itself.

For a RISC-V CPU project, that functionality may help generate programmes, observe instruction retirement, predict architectural behaviour, compare a device under test (DUT) with a reference model, collect functional coverage or integrate those capabilities into a larger verification environment. The important word is reusable. Verification IP can prevent every processor team from rebuilding the same infrastructure from first principles. The RISC-V Verification Interface (RVVI), for example, is intended to make interfaces between processor RTL and verification components more reusable. Its current repository describes RVVI as a draft open standard, not a ratified RISC-V specification.

Reuse, however, is not the same as delegated responsibility. Verification IP can provide mechanisms and evidence. The project team decides which requirements matter, how the processor is configured, which scenarios must be covered and whether the total evidence is sufficient for release.

Processor IP, Verification IP and Protocol VIP: The Difference

These terms solve different engineering problems.

RISC-V processor IP is the CPU implementation being designed, licensed or integrated. It contains the RTL or another implementation representation of the processor.

RISC-V verification IP operates around that implementation. Examples include an architectural reference model, instruction-stream generator, retirement interface, checker or coverage library.

Protocol VIP verifies an interface protocol such as AXI, TileLink or another interconnect. Protocol VIP can be essential around a CPU, but proving that bus transactions obey a protocol does not demonstrate that the processor executes the RISC-V ISA correctly.

A CPU project may therefore use all three: processor IP as the DUT, processor-oriented verification components for architectural behaviour, and protocol VIP around memory or system interfaces.

Why RISC-V Processor Verification Needs More Than ISA Tests

Architectural testing answers an important but narrower question: does the implementation exhibit the architectural behaviour targeted by those tests?

The current RISC-V Architectural Certification Tests repository is unusually explicit about the boundary. It describes ACTs as assembly-language tests for architectural certification and states that they are not verification tests and that additional processor verification should be performed. The current ACT4 framework uses implementation configuration information and RISC-V Sail to calculate expected results for self-checking tests. That means a passing architectural suite cannot, by itself, establish that the implementation correctly handles every pipeline interaction, hazard, asynchronous interrupt, debug sequence, microarchitectural corner case, power transition, security mechanism or CPU-to-SoC interaction.

Architectural certification evidence and full processor-verification evidence should therefore be treated as related but different artefacts. Alpinum’s discussion of compliance, certification and verification distinctions covers that wider terminology.

What Each RISC-V Verification Component Can and Cannot Establish

The value therefore comes from combining evidence sources rather than looking for one component that can issue “automatic sign-off”.

Reference Models and Instruction-Set Simulators

A RISC-V reference model predicts the architectural result expected from the configured processor. An instruction-set simulator (ISS) is often used in this role, although “reference model” and “ISS” should not automatically be treated as identical terms. The model must match the architectural configuration being verified: XLEN, implemented extensions, privilege behaviour, relevant CSRs and any other architecturally visible options. Custom behaviour must also be represented if it is to be compared.

More importantly, a reference model needs qualification. Agreement between RTL and a model shows that they agree for the observed case. It does not logically prove that both interpreted the specification correctly. A correlated error is possible if the RTL and model were built from the same incorrect requirement interpretation. Model independence, review history, configuration control and focused directed tests therefore remain important even in a strong ISS-comparison flow.

RVVI and Architectural-State Comparison

Processor pipelines complicate direct cycle-by-cycle comparison. Two implementations can produce the same architecturally correct result while using different internal timing, issue order or pipeline structures. Retirement-level checking instead concentrates on architecturally committed effects.

The current RVVI project defines mechanisms for communicating processor state, retirement information and asynchronous events between RTL and verification components. RVVI-API is intended to decouple a testbench from a specific reference-model implementation, while RVVI-TRACE provides processor-observation information. The project remains documented as a draft open standard.

OpenHW’s CORE-V verification documentation makes the boundary particularly clear: RVVI itself does not verify processor functionality; checking belongs in the surrounding verification environment.

For more detail on retirement comparison, see Alpinum’s RISC-V lockstep co-simulation guide.

Useful architectural-state comparison may include the retired instruction and PC, register changes, relevant CSR changes, traps, privilege state and memory effects. Asynchronous interrupts and debug events require particular care because the DUT and reference model must remain aligned even when an external event arrives between architectural retirements.

Generating Instruction Streams with riscv-dv

The CHIPS Alliance riscv-dv repository describes riscv-dv as an open-source SystemVerilog/UVM-based random instruction generator for RISC-V processor verification. Its documented capabilities include constrained instruction generation, privilege modes, exceptions, interrupt handling, illegal instructions, debug-related generation, directed-instruction mixing and co-simulation hooks for several ISSs. That makes riscv-dv a valuable stimulus-generation component. It is not a complete verification strategy.

A team still has to decide what to generate, constrain illegal or irrelevant scenarios correctly, introduce directed stimulus where probability is insufficient, connect generated programmes to checking and determine whether the generation space actually addresses the verification plan. Random generation without verification intent can create enormous regressions while leaving important scenarios untouched.

Functional Coverage for Instructions, Privilege and Exceptions

Functional coverage should describe the scenarios the verification plan intends to observe.

For processor verification, useful coverpoints and crosses might address instruction classes, operand categories, dependency patterns, privilege modes, CSR operations, exceptions, interrupts, legal and illegal behaviours or relevant architectural transitions.

For a particular implementation, the plan may also need microarchitectural coverage around hazards, stalls, forwarding, branch behaviour, cache/MMU behaviour or other implementation features.

Coverage does not prove correctness. A bin records that its sampling condition occurred. Correctness still depends on suitable checking. Likewise, 100% code coverage does not mean 100% architectural verification. Structural coverage asks whether implementation structures were exercised; functional coverage asks whether planned scenarios occurred. Neither metric independently answers whether the observed behaviour was correct.

Alpinum’s RISC-V functional-coverage article examines coverage modelling and closure in greater depth.

Architectural Tests, Compliance and Full Processor Verification

The current ACT4 approach represents a significant architectural-testing framework, but its own documentation preserves the boundary between architectural certification tests and full processor verification.

A project should therefore maintain separate evidence for:

• Required architectural behaviour
• Project-specific architecture configuration
• Microarchitectural requirements
• Custom extensions
• Safety or security requirements where applicable
• Performance requirements
• Debug behaviour
• Memory ordering and atomics
• Power and reset behaviour
• CPU integration into the SoC

Passing one category must not silently waive another.

Integrating Verification IP into a UVM Environment

UVM gives verification teams a standard framework for reusable verification components. Accellera states that UVM is intended to improve interoperability and component reuse; its current download page provides the UVM 2020-3.1 reference implementation for IEEE 1800.2.

In a RISC-V UVM verification environment, teams may combine agents, monitors, scoreboards, architectural-state collectors, reference-model interfaces, functional-coverage collectors and assertion results. UVM organises these components. It does not decide the verification intent. A sophisticated UVM environment with weak requirements, incomplete checking or poor coverage modelling remains a weak verification environment.

For engineers who need to practise how CPU architecture, UVM, riscv-dv, coverage, architectural checking and software-driven SoC verification fit together, Alpinum’s practical RISC-V CPU and SoC verification programme includes hands-on exercises and review rather than treating any one tool as the complete flow. The live curriculum includes CPU-level instruction generation, riscv-dv, functional coverage, architectural compliance and CPU-in-SoC verification.

What Verification IP Cannot Verify Automatically

Reusable verification components cannot determine all project-specific intent.

A verification-IP package does not automatically know:

• Which optional features the product has committed to implement
• Which implementation-specific behaviours are requirements
• Which failures represent RTL defects, model defects or environment defects
• Which coverage holes are acceptable
• Which exclusions are technically justified
• Which performance conditions matter
• Which safety and security requirements apply
• Whether debug and power-management behaviour is adequate
• Whether system firmware interacts correctly with the completed SoC
• Whether the collected evidence meets the organisation’s release criteria

These remain engineering and project-governance responsibilities.

Formal verification is similar. Frameworks such as riscv-formal demonstrate how formal properties can be used to verify defined processor behaviours, with bounded or unbounded tasks depending on the problem. A formal result applies to the properties, model and assumptions actually analysed. It should not be generalised into an unsupported claim that a complex CPU or SoC is “fully proven”.

Custom Instructions and Implementation-Specific Behaviour

Custom instructions expand the ownership boundary immediately.

A proprietary operation needs an architectural contract, reference behaviour, legal and illegal encoding rules, stimulus, expected results, coverage and regression impact analysis. Depending on the feature, it may also affect exceptions, privilege, memory behaviour, debug, toolchains or software. The standard ISA remains relevant too: adding a custom instruction must not accidentally reinterpret a standard encoding or corrupt existing behaviour.

Alpinum’s custom-instruction verification guide treats this as a separate verification problem because it deserves deeper coverage than a general verification-IP article can provide.

From CPU Verification to SoC Integration

A CPU can have strong processor-level evidence and still fail when integrated into an SoC.

CPU-to-SoC verification introduces another set of observable contracts: reset and boot sequencing, memory maps, interrupt routing, timers, peripherals, interconnect behaviour, clock and power control, firmware interfaces and product use cases. Software-driven tests become especially valuable here because software can exercise the processor through the same system-visible paths that firmware will later use. However, software self-checking should not be the only observation mechanism for critical results. External monitors, assertions, scoreboards, signatures or architectural comparison can strengthen the evidence.

Alpinum’s article on C and Assembly for RISC-V SoC verification covers this CPU-in-system boundary in detail.

RISC-V CPU Verification Evidence Stack

A defensible sign-off argument is easier to review when evidence is connected from requirement to result.

Verification IP contributes at several layers. It does not own the stack.

How to Evaluate RISC-V Verification IP

Before selecting or integrating a verification solution, a CPU team should ask:

1. Which ISA specification versions, profiles and extensions are supported?
2. How is the exact implementation configuration represented and version-controlled?
3. How are custom instructions and implementation-specific architectural state added?
4. Which reference models or ISSs can be used?
5. How independent is the reference implementation from the RTL interpretation?
6. Which architectural state is compared at retirement?
7. How are exceptions, traps and asynchronous interrupts aligned?
8. How is debug-mode entry, execution and exit handled?
9. Which RVVI, trace or proprietary interfaces are required?
10. What instruction-generation capabilities and constraints are supplied?
11. What functional coverage is included, and can engineers extend and review it?
12. How does the solution integrate with the existing UVM environment and regression infrastructure?
13. What failure artefacts are produced: first mismatch, retire index, architectural state, waveform correlation or reproducible seed?
14. How are model, specification, generator and coverage versions controlled together?
15. Which tasks explicitly remain the project team’s responsibility, and what evidence will the sign-off review expect?

A feature checklist is useful only when it leads to this second question: what verification claim can the resulting evidence actually support?

CPU Sign-Off Evidence Checklist

Before a RISC-V CPU is considered ready for project sign-off, the review should be able to establish that:

• Architecture and implementation requirements are version-controlled and traceable
• The implemented ISA configuration matches the verification configuration
• Directed and generated regressions address the agreed verification plan
• Reference-model scope, configuration and limitations have been reviewed
• Architectural comparison and other checkers have reproducible failure diagnostics
• Exceptions, interrupts, privilege behaviour, CSRs and relevant memory behaviours have targeted evidence
• Custom and implementation-specific features have their own stimulus, checking and coverage
• Functional and structural coverage gaps are closed or technically justified
• Formal properties have explicit assumptions, scope and closure status
• Known defects and waivers have owners and documented dispositions
• CPU-in-SoC reset, boot, interrupt, memory-map and firmware interactions have separate evidence
• Acceptance criteria have been reviewed by the responsible engineering authority

“Sign-off” is therefore not a percentage emitted by a tool. It is a project-governed decision based on a body of reviewed evidence.

Key Takeaways

RISC-V verification IP can make processor verification substantially more reusable. Reference models provide architectural prediction, riscv-dv generates instruction stimulus, RVVI can standardise important integration points, UVM organises reusable verification components and coverage helps measure whether planned scenarios occurred. None of these assets removes the need for a project-owned verification plan.

The CPU team remains responsible for configuration, implementation-specific behaviour, reference-model qualification, coverage interpretation, custom extensions, microarchitecture, defect closure and the transition from CPU-level evidence to SoC-level evidence. The strongest verification argument is therefore not “which VIP did we use?” but “which independent evidence supports every important requirement, and what remains unverified?”

Engineers wanting to practise this complete workflow can review Alpinum’s RISC-V Verification Training programme, which connects CPU architecture, UVM, riscv-dv, functional coverage, architectural compliance and software-driven SoC verification through practical exercises and feedback.

References

1. [1] RISC-V International, “RISC-V Ratified Specifications Library,” RISC-V International, 2026. [Online]. Available:https://docs.riscv.org/.
2. [2] RISC-V International, “RISC-V Architectural Certification Tests (ACTs),” GitHub. [Online]. Available: https://github.com/riscv/riscv-arch-test.
3. [3] RISC-V Verification Interface Project, “RISC-V Verification Interface (RVVI),” GitHub. [Online]. Available: https://github.com/riscv-verification/RVVI.
4. [4] CHIPS Alliance, “riscv-dv: Random Instruction Generator for RISC-V Processor Verification,” GitHub. [Online]. Available: https://github.com/chipsalliance/riscv-dv.
5. [5] OpenHW Group, “CORE-V-VERIF: Functional Verification Project for the CORE-V Family of RISC-V Cores,” GitHub. [Online]. Available: https://github.com/openhwgroup/core-v-verif.
6. [6] OpenHW Group, “CORE-V Verification Strategy: RISC-V Verification Interface,” CORE-V-VERIF Documentation. [Online]. Available: https://github.com/openhwgroup/core-v-verif/blob/master/docs/VerifStrat/source/cv32_env.rst.
7. [7] Accellera Systems Initiative, “Universal Verification Methodology (UVM),” Accellera Systems Initiative, 2026. [Online]. Available: https://www.accellera.org/downloads/standards/uvm.
8. [8] YosysHQ, “riscv-formal: RISC-V Formal Verification Framework,” GitHub. [Online]. Available: https://github.com/YosysHQ/riscv-formal.

FAQs