CV32E20 RISC-V Architectural Compatibility Testing using RISCOF

1. Prerequisites
2. Setup Configuration
3. Plugin for the Device-Under-Test
4. DUT Simulation Environment and Testbench
5. Running the Compliance Suite

This repository is a port of the "RISCOF RISC-V Architectural Test Framework" to test the CV32E20 RISC-V Processor for compatibility to the RISC-V ISA specifications. Sail RISC-V is used as reference model. Currently, the following test suites are supported:

• rv32i_m\C - compressed instructions
• rv32i_m\I - base integer ISA
• rv32i_m\M - hardware multiplication and division
• rv32i_m\privilege - privileged machine architecture
• rv32i_m\Zifencei - instruction stream synchronization

💡 The general structure of this repository was setup according to the RISCOF installation guide, and borrows heavily from the NEORV32 Compliance repository.

Prerequisites

• cv32e20 - the device under test (DUT)
• riscv-arch-test - architectural compatibility test cases
• RISC-V GCC toolchain - recommend you follow the installation specified in RISCOF Quick Start
• Sail RISC-V - the reference model (there is a pre-built binary in the bin directory of this repo)
• RISCOF - the architecture test framework
• Verilator to simulate the SystemVerilog RTL model of the CV32E20

This repository uses git submodules to bring in the CV32E20 RTL and the RISC-V Architecture tests.

[back to top]

Setup Configuration

The file config.ini is the RISCOF setup configuration. It specifies the plugins to be used: one for the device-under-test ("DUT") and the reference model ("REF"). The ISA, debug and platform specifications, which define target-specific configurations like available ISA extensions, ISA specification version(s) and platform modules (like MTIME), are defined by YAML files in the according plugin folder.

• DUT: cv32e20 in directory plugin-cv32e20
• REF: sail_cSim in directory plugin-sail_cSim

Each plugin directory also provides low-level environment files like linker scripts (to generate an executable matching the target's memory layout) and platform-specific code (for example to initialize the target and to dump the final test signatures/results).

The official RISC-V architecture tests repository provides test cases for all (ratified) RISC-V ISA extensions (user and privilege ISA). Each test case checks a single instruction or core feature and is compiled into a plugin-specific executable using a RISC-V GCC toolchain.

The reference data is generated by the Sail RISC-V Model. This data is compared against the results of the DUT.

💡 It is recommended you build the toolchain and Sail model from source using the instructions provided by the RISCOF Quickstart (here and here).

[back to top]

Plugin for the Device-Under-Test

The simulation scripts and the makefile for compiling and running the simulation is invoked from a DUT-specific Python script in the DUT's plugin folder (plugin-cv32e20/riscof_cv32e20.py). This Python script makes extensive use of shell commands to move and execute files and scripts.

The plugin-cv32e20/tb directory provides a simple SystemVerilog testbench and Makefile to simulate the CV32E20 processor using Verilator. The general form of the make command is:

$ make -C plugin-cv32e20/tb veri-test TEST_PROGRAM_RELPATH=<path_to_test> TEST=<test>

Note that unless you are debugging a specific test, you will not need to invoke make yourself, the riscof command does this for you.

DUT Simulation Environment and Testbench

The RISC-V Architectural Compatibility Test document specifies that implementers must provide a simulation environment with sufficient resources to run the required ACT tests. What this means is that there exists an interdependancy between the programming environment and the testbench, and you must resolve these interdependancies. There are several key considerations:

1. Memory Capacity: RISCOF assumes a flat memory space of at least 4MBytes. If your simulator supports it, consider using a sparse memory for this.
2. Signaling Test Completion: individual test-programs that run on your core will signal when the test is complete. Your testbench must detect this and terminate the simulation.
3. Writing a "Signature": test-programs generate a test-specific "signature" which is to be written to a file. Your testbench must detect this and direct it to a file.

TODO: READMEs in plugin-cv32e20/tband plugin-cv32e20/env directories of this repo attempt to document how this is done.

Running the Compliance Suite

The framework (running all tests) is invoked via a single shell script run.sh that returns 0 if all tests were executed successfully or 1 if there were any errors.

[back to top]