RISC-V SoC Verification: A Practical View from IP to Subsystem to Full Chip

Modern RISC-V SoC verification is fundamentally integration- and software-driven. Unlike  traditional SoCs, where peripherals are often treated as independent blocks, a RISC-V SoC tightly couples CPU privilege modes, CSRs, interrupt controllers, and peripherals into one  coherent execution model. 

The SoC architecture consists of a RISC-V core connected via an AHB interconnect, an AHB to-APB bridge, multiple peripherals such as GPIO, SPI, and UART, along with system  controllers like CLINT and PLIC. Verification must therefore evolve naturally from IP  correctness, to subsystem interaction, and finally to software-observed SoC behavior.

IP Verification in the Context of This RISC-V SoC 

At the IP level, verification begins in isolation, but in a RISC-V SoC no IP is truly standalone.  Every peripheral is programmed by software running on the RISC-V core through the AHB to-APB path, and most IPs influence overall system behavior via interrupts. 

For example, the GPIO IP exposes registers such as GPIO_IN, GPIO_OUT, and GPIO_OE.  Verification must ensure correct register behavior, direction control, IO enable functionality,  and proper interaction with external IO logic. 

Key IP-level verification focus areas: 

∙ APB protocol compliance and timing 

∙ Register reset values and access types (RW, RO, W1C, WARL) 

∙ Interrupt generation, masking, and clearing behavior 

∙ Back-to-back software-style accesses 

∙ Error and corner conditions such as overflow or underrun 

Subsystem (SBU) Verification: Integration Validation 

Subsystem verification validates how multiple IPs operate together through shared  infrastructure. In a RISC-V SoC, the uncore region—containing RAM, EEPROM, GPIO, SPI,  UART, CLINT, and PLIC—forms a natural verification subsystem. 

The primary goal at this level is not to re-verify individual IP functionality, but to ensure  correct integration across interconnects, bridges, clocks, resets, and interrupt routing.  Subsystem verification uses firmware-like scenarios without executing full boot software. 

Typical subsystem verification focus areas: 

∙ Correct address decoding across AHB and APB 

∙ AHB-to-APB bridge latency and ordering 

∙ Interrupt routing from peripherals to PLIC (MEIP) 

∙ Simultaneous activity across multiple peripherals 

∙ Reset propagation and recovery behavior 

SoC Verification: CSR and Interrupt-Centric Validation 

At the SoC level, verification becomes software-observed and CSR-centric. The RISC-V core  now actively participates by executing instructions, programming registers, and responding  to interrupts. 

Boot and CSR Configuration Example 

After reset, the RISC-V core enters Machine mode and executes firmware that programs key  Control and Status Registers (CSRs).

If PLIC routing or peripheral interrupt enable is incorrect, the core will never see the  interrupt—something that cannot be fully validated at IP or subsystem (SBU) level alone. 

CLINT Example (Timer Interrupt) 

The CLINT block generates machine timer interrupts (MTIP). A typical flow is shown below: 

1. Software programs mtimecmp 
2. mtime reaches the programmed compare value 
3. MTIP is asserted 
4. Trap occurs to Machine mode 
5. mcause reflects a timer interrupt 

Verifying this flow ensures: 

∙ Correct CLINT register access via APB 

∙ Correct interrupt assertion 

∙ Correct CSR updates (mcause, mepc) 

∙ Proper return from interrupt using mret 

SoC-Level Verification Focus 

∙ Privilege transitions (M → S → U) 

∙ CSR access legality and side effects 

∙ Interrupt prioritization between CLINT and PLIC 

∙ Software-driven peripheral access 

∙ Concurrent interrupt and data activity 

At this level, software acts as the primary stimulus, while UVM provides observability,  checking, and debug support. 

How the Verification Levels Fit Together 

In a RISC-V SoC, verification success depends on clear ownership at each level: 

∙ IP verification ensures each block behaves correctly in isolation 

∙ Subsystem verification validates integration through buses and interrupt paths

∙ SoC verification confirms correct behavior as observed by real software

Key Takeaways 

∙ IP bugs amplify at the SoC level 

∙ Subsystem verification catches routing and integration issues early

∙ SoC verification validates architectural intent 

∙ CSR and interrupt correctness are central to RISC-V verification 

Conclusion 

This RISC-V SoC architecture clearly demonstrates why verification cannot be treated as a  single activity. The tight coupling between the core, CSRs, interrupts, and peripherals  demands a layered and reuse-oriented verification strategy.
Teams that invest in strong IP verification and realistic subsystem scenarios dramatically  reduce SoC bring-up time and post-silicon surprises, ultimately achieving faster and more reliable first silicon.