Topics In Demand
Notification
New

No notification found.

Getting started with RISC-V Verification using SPIKE library
Getting started with RISC-V Verification using SPIKE library

November 21, 2024

125

0

RISC-V is an open-source instruction set architect (ISA) based on reduced instruction set computing principles. The architecture is designed to be simple, modular and customizable, allowing for flexibility in designing chips and systems across various applications. It was first introduced in 2010 by researchers at the University of California, Berkely. However, its recognition and broader acknowledgment within the technology industry started to escalate noticeably around the mid-2010s and continued to grow in subsequent years. Initially there was only academic interest, but later it was recognized by larger industry after the emergence of IOT applications. Another advantage was the very fact that the instruction set was open source, thus enabling industry and government bodies to develop specific cores to cater to their application area.

RISC-V is a modular and extensible instruction set architecture, allowing for optional extensions to the base instruction set, enabling customization based on specific application requirements. Some of the extensions are as below:

  1. Integer Extensions
  2. Floating Point Extensions
  3. Vector Extensions
  4. Cryptographic Extensions
  5. Supervisor and Privileged Modes
  6. Memory Management Extensions
  7. Platform-Specific Extensions

These extensions have their own instruction set architecture. The implementation of these extensions over an SoC or FPGA is purely based on its requirement.

RISC-V processors can have multiple pipeline stages to optimize instruction execution. The architecture can also support instruction level parallelism to improve performance. The basic pipeline structure consists of Fetch, Decode, execute, memory access and write back tasks.

 

Fig 1: Basic pipeline structure  Source

 

The instruction which is stored inside a memory is fetched based on the pointer address (PC). The fetched instruction is then moved to a Register file and decoded to identify the nature of instruction for example, Arithmetic Logic Instruction, Memory Access Instruction or Control Instruction. Once the true nature of instruction is identified, if it is an Arithmetic instruction it is moved to Arithmetic Logic Unit (ALU) where arithmetic operation is executed and answer is stored into the memory. The arithmetic operation result stored inside memory can be used as final answer or can be written back to memory for further operations. For Memory access and Control instruction it is executed by specialized unit within the above pipeline.

After implementation of RISC-V based pipeline processor with a hardware descriptive language like Verilog/VHDL, the bigger task is to verify the working of the implemented code. The verification testbench could be created using various methodologies. Here we are going to discuss one of the methods to verify the RISC-V based design.

With this method, we are targeting to get the verification completed faster and in a more efficient way. The idea is to use open-source prediction logic available on GitHub called Spike. Spike is an open-source RISC-V simulator, which implements a functional model of RSIC-V. Spike supports all the extensions supported by the RISC-V ISA. It also has huge community support on GitHub. This makes Spike more trustworthy and free of bugs.

Spike is implemented in C++ language and needs to be integrated with Testbench. In this example we are considering our core testbench is implemented using UVM infrastructure. However, it can be integrated with any testbench methodology that can support C++ language. Below figure shows the top-level architecture of the UVM testbench integrated with SPIKE.

 

 

Fig 2: Spike testbench integration

DPI-C functionality is used to import the C function from the Spike Library. The sequence containing all the instructions needs to be provided to the agent to drive into DUT. A copy of instruction is shared with the Spike Library function. Here spike library C function acts as our prediction logic.

The instruction provided to spike returns a signature. A signature is a structure of data available as the output from the c function inside SPIKE. This structure contains the value of the program counter, input register value, instruction opcode and output register value. The struct obtained could be stored inside a file or can be shared to scoreboard for comparison. Several internal signals from DUT could be probed and assigned to a structure containing values to be compared with spike structure. Once the actual and expected data is available inside a scoreboard a report could be generated for the number of instructions getting executed correctly inside DUT.

Instructions like arithmetic and memory instructions could be verified very easily with the struct containing output register values, whereas control instructions could be verified with the subsequent instructions or program counter value based on the instruction.

With this approach, we would be able to verify our DUT in a short period of time. In testbench major time is consumed for creation of the prediction logic. SPIKE reduces this time significantly. Another benefit of using SPIKE is its reusability. As the SPIKE repository gets updated along with every version of RISC-V, verification engineers need not worry about updating the prediction logic and the testbench could be used with minimal or no changes.

 

References:

GitHub – riscv-software-src/riscv-isa-sim: Spike, a RISC-V ISA Simulator
Specifications – RISC-V International (riscv.org)
Reusable Verification Environment for a RISC-V Vector Accelerator (upc.edu)


That the contents of third-party articles/blogs published here on the website, and the interpretation of all information in the article/blogs such as data, maps, numbers, opinions etc. displayed in the article/blogs and views or the opinions expressed within the content are solely of the author's; and do not reflect the opinions and beliefs of NASSCOM or its affiliates in any manner. NASSCOM does not take any liability w.r.t. content in any manner and will not be liable in any manner whatsoever for any kind of liability arising out of any act, error or omission. The contents of third-party article/blogs published, are provided solely as convenience; and the presence of these articles/blogs should not, under any circumstances, be considered as an endorsement of the contents by NASSCOM in any manner; and if you chose to access these articles/blogs , you do so at your own risk.


Ignitarium

© Copyright nasscom. All Rights Reserved.