Verification of a RISC-V system with multiple cores

Oscar Palomar¹, Roberto Ignacio Genovese¹, Iván Díaz Ortega¹, Albert Aguiler¹, Abdul Rauf² 1Barcelona Supercomputing Center 2ARM

    Abstract

Verifying complex RISC-V systems, particularly out-of-order cores and their cache hierarchies, presents significant challenges due to the need for thorough functional coverage and reference model validation. This paper presents the verification strategy for a RISC-V system composed of multiple cores and its cache hierarchy. We have implemented a stand- alone UVM environment at the core-level that is then reused at the system-level testbench. Our approach employs a modified version of Spike ISS as a reference model to ensure correct execution and validation of test cases. We use multiple directed tests (riscv-tests, compliance), along with randomly generated binaries using riscv-dv. This work contributes a reusable UVM testbench, an enhanced reference model, and a set of directed and randomized tests that significantly improve coverage and bug detection in RISC-V system verification.

                           Introduction                               complete_if:  Completed               (committed/retired)
                                                                       instructions  state. This interface   has   as       many
             Faced with the challenge to verify a complex RISC-V            entries as instructions can be completed in a cycle.
design, as part of the BZL[1] (Barcelona Zettascale Lab)                     It includes PC of the instruction, value written in
project,  we have   developed     multiple   environments    and             the destination register, content of multiple CSRs,
extended existing RISC-V tools to suit our needs.                     etc.
        The methodology we follow for design verification is the       int_if: Interrupt state  signals.  Injects      interrupt
Universal    Verification  Methodology     (UVM).        We have      requests to the core, and detect when it traps.
created   a  number  of   UVM environments     that   use    co-      dc_if: Data cache interface signals.
simulation (with the RISC-V instruction set simulator Spike            ic_if: Instruction cache interface signals.
[2]) to check the correctness of the design. We have created           The Icache, Dcache and Interrupt agents monitor and drive
environments for     the   scalar cores and   for    the    CPU-        the corresponding interfaces, properly responding to the
subsystem. In general, their specifications and interfaces are            core requests/responses, through dedicated UVM agents.
well-defined and stable, facilitating the verification work.         The Complete agent monitors the complete interface to track
Leveraging   the    reference  model,   we rely   heavily     on      execution of instructions, sending them to the scoreboard,
constrained  random  testing.     More  specifically,  we    use          which compares them with the outcome of Spike, used as
random binary generators (mostly, riscv-dv [3]) extensively        reference model. Note that in a few cases, we force the value
to verify the designs and uncover many bugs. Code and             of the DUT into Spike.
functional coverage is collected and analysed to identify         The simulation of     a test typically  consists in      first
corner cases in the random tests, to be targeted with changes            preloading a binary into the memory model and Spike and
in the configuration of the generator and/or directed tests.           then respond to core requests until a certain position in
          Additionally, we implement a set of assertions (SVAs),  memory is written to signal the end of test. Early termination
mostly in the interfaces of selected modules.                             occurs on scoreboard mismatches, timeout (no completed
      The following sections present the environment at the core   instruction in a long time) or assertions. External, timer or
and the system-level. We then discuss the reference model         software interrupts are randomly generated.
and the tests, and the changes needed in tools to support the        One of the relevant agents of the design is the instruction
verification of the system.                                          manager. Firstly, it unifies the instruction state captured
                                                                           from complete_if in time and format so that it can be
                             Core-UVM                                 processed in the environment for the multiple cores. Also,
                                                                  the instruction manager is in charge of filtering known errors
        Core-uvm is a verification environment for RISC-V cores.          in the design so that they don’t reach the scoreboard.
The DUT is the core itself, excluding all the cache hierarchy.        Furthermore, instruction manager is in charge of filtering
It incorporates Spike as reference model for co-simulation.              false errors, such as time related RISC-V CSRs. This is
We have support for three different designs, one in-order           necessary due to the different nature of simulation and RTL.
(Sargantana) and two out-of-order cores (Lagarto KA and
Lagarto OX).                                                                     CPU-Subsystem UVM
            The following interfaces are used to drive or sample      In the next higher level, the DUT is the system with three
signals from the DUT:                                               cores (one of each kind) and three levels of cache. However,
                                                                      note that although possible, the cores are not meant to be

RISC-V Summit Europe, Paris, 12-15th May 2025                                                                                  1

used simultaneously, so it is effectively a single-core system randomization of key registers (ra, sp, tp, etc.). Apart from at run-time. The interfaces of the system are two AXI-M this, we have fixed several issues in the code of the tool ports (one for memory requests, another for peripherals), regarding aspects affecting the exception and trap handlers, one AXI-S port (for DMA), interrupt inputs and a JTAG while also expanding the customization of the trap interface. The main components of the testbench are: delegation system.  Core-uvm instance configured in passive mode. Concerning the types of tests that we generated we can  AXI - Slave Memories to emulate main memory, divide them in three different types: SRAM and bootrom. Modelled using the axi-mem  Basic scalar tests, which contains mainly the component from the Pulp project [4]. usual scalar instructions together with many  JTAG - VIP to verify JTAG protocol and RISCV different memory operation cases. debug module.  Basic vector tests, similar to the basic scalar ones,  AXI - Master VIP to support verification of DMA but with emphasis on vector instructions and bridge and be able to exchange and access different memory operations. design blocks of RTL through DMA.  Atomic instructions stress tests, which focus on  PLIC / CLINT UVM agents to generate external, generating randomized atomic instructions. timer and software interrupts at the subsystem level Figure below shows an example of a run with multiple and verify its handling by the RTL. randomly generated binaries. All binaries are generated with  UART model. An AXI crossbar from the Pulp a similar amount of static instructions but the execution of project is used to connect both an SRAM and the exceptions and interrupts leads significant differences in the UART to the peripheral bus. number of executed instructions.

                       Reference Model
    Our basic reference model is the RISC-V instruction set

simulator Spike [2]. It has been modified to provide SystemVerilog DPI calls that interact with the UVM environment and to model implementation specific details of the designs. We have implemented a configuration flag (core_type) to indicate which design to model. Core_type=Standard follows the vanilla ISA specifications and upstream spike implementation. Examples of specific behaviour are reset values of some CSRs or which vector instructions are supported. We also modified it to allow the preloading of a bootrom from an .elf file. This provides us the flexibility we need to use Spike with different Our initial set of regression jobs used riscv-tests [5] and a environments and designs. few other directed tests proved to be necessary but not The main DPI call implemented is to execute the next sufficient to detect buggy updates in the code, that would instruction (and return the simulator’s state). This is called cause a high number of failing tests in the following runs. whenever the core commits one instruction. We also have As a solution, we created a batch of random tests to DPI calls to force results into Spike (due to a few known- complement the regression. The initial batch was later bugs of floating point rounding errors, values of hpm improved by selecting a handful of random tests that had counters, etc.), to change the external interrupt signal (in uncovered difficult bugs. This approach ended up being order to mimic the core’s acknowledge of the interrupt), and much robust. to perform a TLB walk without triggering exceptions (used to model VIPT caches in core-uvm). Conclusions Tests We have managed to verify a complex design with multiple cores and a cache hierarchy (currently under We have used a collection of regression tests composed of fabrication). Careful design and implementation of the core the riscv-isa-tests, the riscv-arch-tests (formerly compliance) UVM has allowed using it for multiple cores, and reuse it in and internal RVV ISA tests. Also a number of UVM directed the system level. We have benefitted greatly of tools like tests for verifying the JTAG and DMA interfaces. Spike, riscv-dv or riscv-tests, adapting them as needed. We Nevertheless, the bulk of our tests come from the random plan to contribute the changes that are not only relevant for binary generator riscv-dv [3]. We have modified it to our design, but may be beneficial to the community. provide full support of rvv 1.0.0, vector memory instructions generation with changing values of SEW and vector length. Acknowledgements We have also added options to further modify the kinds of This project is promoted by the Ministry for Digital instructions to generate and provide finer control of the Transformation and the Civil Service, within the framework

RISC-V Summit Europe, Paris, 12-15th May 2025 2

of the Recovery, Transformation and Resilience Plan - Funded by the European Union - NextGenerationEU.

       References

[1] Barcelona Zettascale Lab https://bzl.es [2] Spike RISC-V ISA Simulator https://github.com/riscv- software-src/riscv-isa-sim. [3] RISCV-DV https://github.com/chipsalliance/riscv-dv [4] A. Kurth et al., "An Open-Source Platform for High- Performance Non-Coherent On-Chip Communication," in IEEE Transactions on Computers, vol. 71, no. 8, pp. 1794- 1809, 1 Aug. 2022, doi: 10.1109/TC.2021.3107726. [5] RISCV-Tests https://github.com/riscv-software- src/riscv-tests/

RISC-V Summit Europe, Paris, 12-15th May 2025 3