Verification of CoreSwap: Replacing ARM Cortex-A5 with RISC-V CVA6 in ARM SoC Environment
Authors: Muhammad Hammad Bashir 10xEngineers, Umer Shahid 10xEngineers, Yazan Hussnain 10xEngineers, M Tahir 10xEngineers, Fatima Saleem 10xEngineers
Department of Electrical Engineering, U.E.T Lahore
Abstract
This paper presents the verification methodology and results of the CoreSwap project, where the ARM Cortex-A5 core in ARM Educational Kit SoC was replaced with the open-source RISC-V OpenHW CVA6 core. The project demonstrates the feasibility of integrating a RISC-V core into an existing SoC ecosystem while maintaining functionality and system stability. We detail the comprehensive verification process, including core-level Architecture Compliance Tests (ACTs), manually written system-level tests, FPGA synthesis on a Kintex-7 platform, and running performance benchmarks. The verification strategy highlights the challenges and solutions to validate such a large-scale System on Chip (SoC). This seamless integration and verification of the CoreSwap underscores the potential of RISC-V in proprietary SoC environments.
Introduction
Methodology
The CoreSwap project involved replacing the ARM Cortex-A5 core with the RISC-V CVA6 core in an ARM Educational Kit SoC. The CVA6 core [2], an open-source, 64-bit RISC-V implementation, was chosen for its compatibility with the existing SoC infrastructure. Furthermore, in replacement of ARM Generic Interrupt Controller (GIC), the Platform Level Interrupt Controller (PLIC) was integrated to multiplex peripheral interrupts onto the external interrupt lines of the HART context, while the Core-Level Interrupt Controller (CLINT) was included to provide inter-processor interrupt (IPI) and timer functionalities. The complete block diagram is shown in Figure 1.
Verification was performed at multiple levels to ensure the correctness of the CoreSwap project.

Core-Level Verification
System-Level Verification
System-level tests were run to validate the interaction between the CVA6 core and the SoC peripherals. These self-checking tests include the verification of the memory map, interrupt handling, and correct configuration setup. The following steps outline the complete test sequence.
- Boot Sequence and Trap Handler setup: The test execution starts from a designated instruction address known as the test entry point. From there, the boot sequence is initiated, involving the initialization of general-purpose registers, control and status registers, stack setup, and the trap handler.
- System Initialization: After the boot sequence, the test proceeds to system initialization, which involves configuring each peripheral (e.g., UART, timers, and GPIO). This test environment requires at least one UART for logging and debugging purposes.
- Interrupts Configuration: External and core-level interrupts are managed by the Platform-Level Interrupt Controller (PLIC) and the Core-Level Interrupt Controller (CLINT), respectively. This step involves configuring the interrupts, such as enabling/disabling them, setting priorities, applying masking, and setting up the corresponding interrupt handlers.
- Main test Entry: The test finally enters the main function, where different test cases are executed. The following table summarizes a subset of the system-level test cases that we executed.
Table 1: Subset of System Level Test cases
Test Case | Test Description | Test Target |
Integration Sanity Test | Generic Test for the verification of correct boot flow and system initialization. | Whole System Integration |
Memory Map Test | Verifies the correct memory configurations | Verifies the correct memory configurations |
Interrupts Test | Verifies the behavior of CLINT, PLIC including generation of timer, software and external interrupts with correct handling. | CLINT, PLIC, External Peripherals |
FPGA Synthesis and Validation
The modified SoC was synthesized on a Xilinx Kintex-7 FPGA to validate its functionality in a real-world environment. The synthesized SoC on the Xilinx Kintex-7 FPGA demonstrated stable operation under real-world conditions. We executed a series of performance benchmarks of Mibench suite [4] in a bare-metal environment, focusing on key metrics such as instruction throughput, memory latency, and computational efficiency in terms of Instruction per cycle (IPC). The results are shown in Figure 2. The IPC results showed that the CVA6 core achieved competitive performance. demonstrating the system’s capability to perform efficiently and reliably under practical conditions.

Conclusion
The CoreSwap project demonstrates the feasibility of replacing a proprietary ARM core with an open-source RISC-V core in an existing SoC while maintaining full system functionality. Our verification strategy ensured correctness at multiple levels, from core-level ISA compliance to full system operation. This work highlights the importance of a robust verification process in enabling the adoption of RISC-V in diverse SoC environments and paving the way for future open-source architecture transitions.
References
[1] Andrew Waterman et al. The RISC-V Instruction Set Manual, Volume I: User-Level ISA, Version 2.0. Tech. rep. UCB/EECS-2014-54. May 2014. Url: http://www2.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-54.html
[2] OpenHW Group. CVA6: An Open-Source RISC-V Out-of-Order Core. https://github.com/openhwgroup/cva6 Accessed: 2025-02-06. 2024.
[3] RISC-V International. RISC-V Architecture Test Framework. https://github.com/riscv-non-isa/riscv-arch-test Accessed: 2025-02-06. 2025.
[4] mibench. GitHub. Accessed: 2025-02-06. Feb. 2025. Url: https://github.com/embecosm/mibench .