Отправьте статью сегодня! Журнал выйдет ..., печатный экземпляр отправим ...
Опубликовать статью

Молодой учёный

Architecture of a solution for verification processor cores based on the official Riscof framework

Информационные технологии
Препринт статьи
20.04.2026
11
Поделиться
Аннотация
This article focuses on the development of an automated verification environment for checking the compliance of RISC-V processor cores with architectural standards. It describes the modular architecture of the solution based on the official Riscof framework, which provides full automation of the verification cycle from test compilation to the generation of an HTML report. The results of experimental testing on the SCR1 core are presented.
Библиографическое описание
Смирнов, Н. А. Architecture of a solution for verification processor cores based on the official Riscof framework / Н. А. Смирнов. — Текст : непосредственный // Молодой ученый. — 2026. — № 17 (620). — URL: https://moluch.ru/archive/620/135505.


The open RISC-V instruction set architecture has become widely used in academic and industrial development due to the lack of licensing fees and modular structure. However, verification of developed processor cores remains a labor-intensive task requiring significant time and human resources. According to industry estimates, verification takes 60 to 80 % of the total time for system-on-chip development [1].

Existing verification approaches include formal verification, UVM verification, and architectural testing. Formal verification uses mathematical methods to prove the correctness of system properties but does not scale well to a complete processor. UVM verification is an industry standard but requires deep expertise and weeks of setup for each core. Architectural testing focuses on checking compliance with the ISA specification through a set of official riscv-arch-test tests [2].

The goal of this work is to develop a universal verification environment that lowers the entry barrier for developers into RISC-V core architectural verification through maximum automation of the process.

Verification Environment Architecture

The developed environment is built on the principle of a vertical stack of loosely coupled components. The central element is the Riscof framework (RISC-V Compatibility Framework) developed by RISC-V International. Riscof implements the concept of a plugin architecture: a specific core (DUT) is connected through a Python plugin, and the reference model is set through a separate plugin for the Spike simulator [3].

The environment architecture includes three levels. The top level is the Riscof framework, organizing the verification flow from configuration loading to report generation. The middle level consists of Python plugins for DUT and reference, implementing initialise(), build() and runTests() methods. The bottom level includes simulation tools: a compiled Verilator model for DUT and the Spike interpreter for reference.

The link between Riscof and the Verilator simulator is the Verilator wrapper — a C++ file implementing the simulation cycle. The testbench is written in SystemVerilog and consists of tb_top (test control) and tb_memory (memory model with AXI4 interface) modules. The dual-port memory organization (instruction and data port) allows the core to operate under conditions as close to real as possible.

Configurability is provided through YAML files (isa.yaml and platform.yaml) describing core capabilities: supported ISA extensions, bit width, system register addresses. The plugin reads these files and generates test compilation commands. This means that to adapt the environment to a new core, it is sufficient to write a plugin and update YAML — the entire remaining stack remains unchanged.

Verification Environment Algorithm

The verification life cycle begins with the riscof run command and includes the following stages.

Stage 1. Initialization. Riscof parses the config.ini configuration file, imports plugin Python classes, and calls constructors, passing configuration parameters. In the scr1 plugin constructor, validation of all paths to RTL files, simulator, and YAML specifications occurs.

Stage 2. YAML specification validation. The riscv-config library performs semantic validation: checks ISA extension compatibility, register value validity, and address space correctness. For SCR1, ISA is described as RV32IMC

Stage 3. Simulator build. In the scr1 plugin build() method, the Verilator model is built through a subprocess.run(). Verilator translates the SystemVerilog description into C++ classes, which are compiled into the Vtb_top executable. Build time is 60–90 seconds.

Stage 4. Test list formation and parallel compilation. Riscof forms a testList based on the core ISA specification. The plugin forms a make target for each test, including gcc compilation, conversion to.hex via objcopy, symbol address extraction via readelf, and simulator launch. The makeUtil utility accumulates targets and executes make with the -j8 parameter, running up to eight tests in parallel.

Stage 5. Single test simulation. The simulator is launched with the +test_name= key. The testbench loads the.hex file into memory, applies reset and starts program execution. Upon reaching PC value SCR1_SIM_EXIT_ADDR, the testbench reads the signature from memory byte by byte and writes it to a.signature file in 128-bit lines.

Stage 6. Hang protection. The whatchdogs counter increments every cycle. Upon reaching TIMEOUT, simulation is forcibly terminated. This is critical for automated testing: a hung test should not block the entire test suite execution.

Stage 7. Signature comparison and report generation. After all simulations complete, Riscof compares DUT and Spike.signature files byte by byte. A Passed or Failed verdict is issued for each test. The HTML report contains a detailed results table with links to signature files.

Experimental Efficiency Evaluation

A full verification run was performed for the SCR1 core with RV32IMC configuration. The parallelism parameter was set to jobs=4.

Run results: 112 tests executed, 112 completed with Passed status, 0 Failed.

Run time profile: Verilator model build — 74 s, compilation and simulation all tests took 480 s, signature comparison and report generation — 5 s. Total time was ~560 seconds (~9 minutes).

The degree of automation of the repeatable verification cycle is 100 %: all operations from simulator build to report generation are performed without manual intervention. When adapting the environment to a second core, code base reuse was >80 %, adaptation time was about 4 hours.

Result reproducibility was confirmed by 5 repeated runs: in all cases, the result was 112/112 Passed, signature files were identical byte by byte.

Conclusion

A modular verification environment for RISC-V processor cores has been developed and experimentally tested. Main results: ISA architectural coverage 100 % (112/112 Passed for RV32IMC), full run time ~9 minutes at J=4, code base reuse >80 % when changing cores, complete reproducibility of results regardless of host platform, no dependencies on commercial tools.

References:

  1. Waterman A., Asanović K. The RISC-V Instruction Set Manual, Volume I: User-Level ISA.
  2. The RISC-V Instruction Set Manual, Volume I: Unprivileged ISA. RISC-V International.
  3. RISC-V International. Riscof — RISC-V Compliance Framework. — URL: https://riscof.readthedocs.io/.
Можно быстро и просто опубликовать свою научную статью в журнале «Молодой Ученый». Сразу предоставляем препринт и справку о публикации.
Опубликовать статью
Молодой учёный №17 (620) апрель 2026 г.
📄 Препринт
Файл будет доступен после публикации номера

Молодой учёный