RISC-V Summit China 2026: What Verification Engineers Should Watch

Introduction: RISC-V Adoption Changes the Verification Problem

As RISC-V adoption extends across embedded systems, application processors and high-performance computing, verification teams must address more than instruction execution. Processor configurations, optional extensions, privilege models, memory systems and software environments determine whether an implementation behaves correctly within its intended application.

RISC-V verification therefore requires a distinction between architectural compliance, functional correctness and system-level readiness. A processor may execute the required instruction set correctly yet still exhibit errors when handling interrupts, sharing memory with another hart or communicating with SoC peripherals.

The forthcoming RISC-V Summit China 2026, scheduled for 18–20 October in Shenzhen, provides a useful point at which to examine these engineering questions. Its published programme includes processor architecture, software ecosystem, security and chip design and verification discussions [1].

For verification engineers, the central question is not simply which processor capabilities are being developed. It is how implementation teams establish that those capabilities operate correctly across configurations, execution states and integrated systems.

RISC-V Verification: Why ISA Compliance Is Not Enough

The RISC-V instruction set architecture establishes the architectural behaviour that compliant implementations must provide. However, compliance testing and complete functional verification serve different purposes. Architectural Certification Tests check selected architectural requirements against the relevant specification and configured extensions. The RISC-V Architectural Certification Tests project explicitly distinguishes these tests from comprehensive processor verification [2].

A processor can pass applicable architectural tests while retaining defects in pipeline control, speculative execution recovery, memory transactions or interrupt handling. Such defects may appear only under particular instruction sequences or environmental conditions. Consequently, verification teams need several complementary approaches. Architectural tests establish selected compliance evidence. Constrained-random instruction streams exercise combinations of legal operations. Assertions check important invariants, while reference models compare architecturally visible behaviour. Directed tests address conditions that random generation may rarely encounter.

The open-source riscv-dv environment illustrates this approach through SystemVerilog/UVM instruction generation, privilege-mode testing, exception handling and instruction-set simulator co-simulation [3].

Layers of RISC-V processor verification

Figure 1: Complementary verification layers address different classes of processor defects. Passing one layer does not establish correctness in the others.

Figure 1 illustrates why verification evidence must extend beyond ISA compliance. Each layer adds observable behaviour, environmental interactions and failure modes that the preceding layer does not fully cover.

Custom Instructions and Extension Verification

RISC-V permits implementations to combine standard extensions with application-specific instruction functionality. This flexibility creates verification obligations at both architectural and microarchitectural levels.

For example, consider a custom instruction that performs a specialised arithmetic operation. Verification must check instruction encoding, operand handling, destination updates and illegal-instruction behaviour where applicable. It must also examine pipeline stalls, data dependencies, exceptions and interaction with existing instructions. A reference instruction-set simulator may not support the custom operation without modification. Therefore, the verification team needs an independently reviewed architectural model or another suitable checking mechanism.

Coverage should distinguish instruction execution from meaningful behavioural combinations. Executing a custom instruction thousands of times offers limited assurance if tests never exercise operand boundaries, back-to-back dependencies or relevant interruption conditions.

Extension verification also introduces configuration risk. Two compliant implementations may support different extension sets or parameters. Test generation, reference models and coverage expectations must reflect the actual design configuration rather than an assumed general-purpose processor profile. The summit’s architecture and processor discussions provide an opportunity to examine how projects handle these configuration-dependent verification requirements [1].

Privilege Modes, CSRs, Interrupts and Exceptions

Privilege handling creates a verification problem in which correctness depends on both the current processor state and the event being processed. The RISC-V Privileged Architecture defines execution modes, control and status registers, traps and related control mechanisms [4]. Depending on the supported configuration, the processor may also implement virtual memory, supervisor-level functionality and hypervisor-related features. Verification engineers must confirm that CSR access permissions, trap delegation, exception priorities and return instructions behave as specified.

For example, an interrupt arriving during a privilege transition may interact with pending exceptions, interrupt-enable state or a change in the execution context. Testing each feature independently cannot establish that all relevant combinations work correctly. A useful verification plan therefore relates stimulus to architectural state. It should cover permitted CSR accesses, rejected accesses, exception entry, trap-handler execution and return to the interrupted context.

The Advanced Interrupt Architecture adds further considerations for implementations using APLIC or IMSIC components [5]. In such systems, verification must cover interrupt routing and delivery across the hart and surrounding interrupt infrastructure. The principal challenge is state-space management. Teams must prioritise legal transitions, architectural corner cases and realistic concurrent events rather than attempting indiscriminate combinations of every CSR and interrupt source.

Multicore, Cache-Coherency and Memory-System Risks

Moving from a single processor hart to a multicore SoC changes the verification problem substantially. Each hart may execute instructions correctly in isolation while the system returns incorrect data under concurrent memory activity. Cache-coherency protocols, atomic operations, memory ordering and interactions with DMA-capable peripherals introduce additional behaviours. The RISC-V RVWMO memory model defines permitted memory-ordering behaviour. It does not require every hart to observe all memory operations in simple programme order [6].

Verification must therefore distinguish outcomes that the architecture permits from genuine ordering violations.

For example, two harts may access shared memory while one performs an atomic update and the other executes ordinary loads. A checker that assumes sequential consistency in all circumstances may incorrectly reject legal behaviour. Conversely, a checker with an overly permissive memory model may miss real defects. A multicore verification environment should combine architectural memory-model checks with fabric, cache and transaction-level checking. Tests should exercise contention, atomic sequences, synchronisation, cache-line sharing and relevant reset or power-management transitions.

Multicore RISC-V verification boundaries

Figure 2: Multicore correctness depends on interactions between harts, caches, the interconnect and external memory masters. The verification environment must observe and check the relevant boundaries.

Figure 2 shows the main verification boundaries in a representative coherent RISC-V system. The actual checking strategy depends on the selected cache architecture, coherency protocol and SoC topology. RISC-V ISA compliance alone cannot establish correctness across these components.

Hardware–Software Interaction and Processor Debug

Processor verification increasingly depends on observing how hardware responds to executable software, rather than relying exclusively on synthetic instruction streams. Boot code, operating-system components, interrupt handlers and device drivers exercise sequences that directed processor tests may not reproduce. For instance, an operating system might expose an error in page-table updates or interrupt delivery that remains invisible during isolated instruction testing.

However, software execution alone does not provide sufficient checking. A successful boot indicates that a particular execution path completed, not that all relevant architectural requirements were satisfied. Verification teams should combine software-driven tests with independent observability, assertions, architectural traces and suitable reference models. Debug functionality also needs explicit verification. The RISC-V Debug Specification defines common mechanisms for external debugging, including access to processor state and control of execution [7].

Engineers should examine halt and resume behaviour, register access, debug entry during exceptional conditions and interactions between debugging and normal execution. The engineering trade-off concerns fidelity and observability. Software-driven workloads provide realistic interactions, while targeted RTL simulation offers better control of rare conditions. Emulation and FPGA prototyping extend execution capacity but typically require additional instrumentation to maintain useful diagnostic visibility.

Security, Safety and Production-Readiness Evidence

Security and safety requirements must influence verification planning from the outset, particularly when a processor controls privileged software, shared resources or safety-relevant functions. Security verification should examine privilege isolation, memory protection, debug access restrictions and the handling of malformed or unauthorised transactions. A correct instruction implementation does not establish that a system prevents access across protection boundaries. Safety verification introduces related but distinct obligations. Where applicable, engineers must verify fault detection, error reporting, recovery mechanisms and the behaviour of the system after a detected failure.

For designs subject to functional-safety standards such as ISO 26262, teams must also establish traceability between applicable safety requirements, verification activities and collected evidence. Functional correctness alone does not demonstrate safety compliance. Production-readiness evidence should therefore include requirements traceability, test results, functional coverage, assertion results, formal verification findings where appropriate, defect status and documented exclusions.

Coverage closure is a particularly important distinction. A high coverage percentage has limited value if the verification plan omits meaningful behaviours or if the checking mechanisms cannot detect incorrect outcomes. Ultimately, verification leaders need to know which requirements have supporting evidence, which risks remain open and what assumptions limit the scope of sign-off.

Verification Skills Required as RISC-V Adoption Expands

RISC-V processor verification requires engineers to connect architectural understanding with practical verification methods. SystemVerilog and UVM remain relevant for constructing reusable testbenches, generating transactions and checking processor or SoC behaviour. However, engineers also need to understand assembly language, privilege architecture, instruction-set simulators, memory models and embedded software execution. Formal verification provides complementary methods for establishing selected properties, particularly where exhaustive reasoning is practical. Software-driven verification helps exercise complete boot and application workflows, while coverage analysis identifies gaps between executed tests and intended requirements.

The central skill is choosing and combining techniques according to the failure modes being addressed.

Evidence-driven RISC-V verification workflow

Figure 3: Verification closure requires a continuous connection between architectural requirements, checking mechanisms, coverage results and engineering sign-off.

Figure 3 illustrates a requirements-led workflow in which coverage and defect analysis feed back into verification planning. The process does not rely on a single tool or methodology.

What Verification Engineers Should Watch at RISC-V Summit China 2026

The summit’s published programme includes sessions relating to processor verification, MMU verification, integrated SoC verification and security architecture. The Chip Design & Verification Forum, scheduled for 20 October, is particularly relevant [1].

Engineers assessing technical presentations should consider several questions:

• Does the proposed methodology verify architectural behaviour, microarchitectural behaviour or both?
• How does the verification environment handle configurable and custom ISA extensions?
• Which privilege, memory-system and multicore interactions receive explicit coverage?
• What independent checking mechanisms detect incorrect results?
• How do projects demonstrate meaningful verification closure rather than simply reporting test counts?

Answers to these questions will be more useful than isolated performance figures or descriptions of new processor features.

The wider RISC-V technology market also requires careful interpretation. Increasing implementation diversity does not imply a uniform verification process. Application requirements, supported extensions, microarchitecture and integration context continue to determine the appropriate verification strategy.

Conclusion: Verification Confidence Must Extend Beyond ISA Compliance

RISC-V Summit China 2026 provides an opportunity to examine how processor development teams approach the relationship between architectural compliance and system-level correctness. For verification engineers, the fundamental challenge remains consistent: determine the required behaviour, identify credible failure modes, implement independent checking and collect evidence that supports engineering decisions.

ISA compliance establishes an important foundation. Nevertheless, privilege transitions, custom instructions, multicore memory behaviour, software interactions and security boundaries require additional verification. As RISC-V implementations become more varied, the quality of verification evidence will depend less on the volume of testing and more on how effectively engineers connect requirements, coverage and observed behaviour.

Further Technical Learning: RISC-V Verification

Engineers seeking a structured treatment of these subjects can review Alpinum Consulting’s RISC-V Verification Training programme. The syllabus covers CPU architecture, RISC-V processor verification, UVM-based workflows, architectural compliance and software-driven SoC verification.

References

[1] RISC-V Summit China 2026, Official Event Website and Agenda. https://riscv-summit-china.org/en/agenda/ 

[2] RISC-V International, Architectural Certification Tests (ACTs).https://github.com/riscv/riscv-arch-test 

[3] CHIPS Alliance, riscv-dv: Random Instruction Generator for RISC-V Processor Verification.https://github.com/chipsalliance/riscv-dv 

[4] RISC-V International, RISC-V Privileged Architecture.https://docs.riscv.org/reference/isa/priv

[5] RISC-V International, Advanced Interrupt Architecture. https://docs.riscv.org/reference/aia/index.html 

[6] RISC-V International, RVWMO Memory Consistency Model. https://docs.riscv.org/reference/isa/unpriv/rvwmo.html 

[7] RISC-V International, RISC-V Debug Specification. https://docs.riscv.org/reference/debug/introduction.html 

FAQs