For verification purposes in different projects (eProcessor, EPI), the BSC Verification team has developed and successfully used the Reusable Verification Environment described in the paper “Reusable Verification Environment for a RISC-V Vector Accelerator” (DVCON, 2022). This effort aimed to create a reusable and expandable verification environment for accelerators connected to different kinds of cores without a standardized interface between them. In this sense, the team has created an UVM-based interface-agnostic base verification infrastructure, reusable for different projects with support for different scalar cores and versions of the vector accelerator. [1]

The implemented verification environment has two main parts:

  • An interface-agnostic environment shared among projects which:

    • Generates vector instructions using an Instruction Set Simulator (ISS, Spike) that mimics a project-specific scalar core. 

    • Compares results between the ISS and the DUT.

    • Provides a continuous integration environment with sanity checks, random test generation and coverage collection.

  • A project-specific environment that implements the behavior of the interface communicating the ISS and the vector accelerator. Communication with the interface-agnostic environment is accomplished using polymorphism.

A proven base environment

The base environment has already proven to work for two different BSC projects: the European Processor Initiative (EPI), which uses the Open Vector Interface (OVI) [2], and eProcessor EuroHPC project, which uses another custom interface.  Figure 1 shows the interface agnostic part of the environment (right side) and the EPI project-specific part of the environment (left side).

EPI project use of DV environment
Figure 1 - EPI project use of DV environment

 

After the success of implementing this approach in the aforementioned projects, we planned to use the same environment in the MEEP project. The MEEP VPU shares some similarities with the EPI VPU. Thus it also features a (modified) OVI interface and preserves the same mode of operation from the EPI project (called ACME classic mode in MEEP project). But it also features additional components and interfaces to work in specific MEEP ACME-mode. Accelerated Compute and Memory Engine (ACME) includes a VPU accelerator that works with long vectors and non-cacheable data. It is not limited to the register space of Vector Register Files (VRF) inside VPU. Instead of VRF, for operations over long vectors in ACME mode, VPU uses a scratchpad memory, termed Long Vector Register File (LVRF) and Micro-engines to move data between vector lanes and LVRF. [3][4] On top of that, VPU also features interfaces to “Network on Chip” (NoC) from OpenPiton [5].

MEEP VPU Design Unter Test (DUT)
Figure 2 shows MEEP VPU Design Unter Test (DUT)

 

As seen in Figure 2, beside the OVI interface, the MEEP VPU implements interfaces to NoC2 and NoC3. In OpenPiton, NoC2 is used for requests from the VPU to the Memory Tile, and the NoC3 channel is used for responses from the Memory Tile to the VPU.

In addition to the VPU, the DUT includes the LVRF (connected to the VPU’s Micro Engines over an AXI4 interface). The memory side interface of the LVRF is also considered the DUT interface for the test bench. Figure 3 shows the differences between the EPI and MEEP versions of the environment. Highlighted in red are new or (in the case of OVI) modified interfaces. In the same figure, we can notice that, as expected, the interface agnostic part of the environment (on the right side of the Figure) stays untouched.

MEEP modification of the environment
Figure 3 - MEEP modification of the environment

 

Some environmental modifications are required.

Testbench adaptations include both preserving the previous VPU mode of functionality (ACME classic-mode) and the new MEEP ACME mode of operation. To achieve this, the following environment modifications are required:

  • Modifying the OVI interface logic to:
    • Not use OVI.memop subinterface signals
    • Not write/read data on OVI.Load/Store data path
    • Pass virtual memory address for memory operation on OVI from scalar core to VPU
  • Adding a new interface and its logic, referred to as OP_if in Figure 3, to listen for Memory requests to NoC2 and send Memory responses from NoC3, as seen in Figure 2.
  • Adding a new interface and its logic to write and read data to and from LVRF, referred to as lvrf_mem_if in Figure 3.
  • Adding a new LVRF backdoor interface, similar to the EPI vector register interface (VREG_IF in Figure 3). While vreg_if is used to backdoor read data from VPU vector register files, LVRF backdoor interface is used to backdoor read data from LVRF. These interfaces are used only for correctness checks vs. the reference model (Spike).

All these interfaces together are part of one larger protocol and project-specific interface, with only one driver and monitor, which simplifies implementation. As mentioned before, this implementation does not require any modification of the protocol-agnostic part of the environment shared among projects. Hence, the MEEP project once again proves the concept and legitimate idea behind the Reusable Verification Environment.

Nevertheless, implementing the support for ACME-mode revealed that the interface-agnostic environment and Spike had some hard-coded restrictions with respect to the length of the vector registers (VLEN parameter of the RISC-V Vector Extension). Since ACME supports longer vectors than the other projects, this required a few changes to spike and the interface-agnostic code to make them also VLEN-agnostic, using DPI features for dynamically sized arrays. Note that these changes have been contributed to the other projects too, and they share the same interface-agnostic environment and Spike.

Simplified diagram of the environment with MEEP VPU DUT instantiated and connected to the protocol interface
Finally, Figure 4 shows a simplified diagram of the environment with MEEP VPU DUT instantiated and connected to the protocol interface.

 

[1]. J. Quiroga et al., “Reusable Verification Environment for a RISC-V Vector Accelerator”, DVCON, Dec 2022.

[2]. R. Espasa, P. Marcuello, A. Moreno, S. Pomata, “OVI: Open Vector Interface Specification” Semidynamics, https://github.com/semidynamics/OpenVectorInterface/blob/master/open_vector_interface_spec.pdf, Dec 2021.

[3]. Fell, A., Mazure, D. J., Garcia, T. C., Perez, B., Teruel, X., Wilson, P., & Davis, J. D. (2021). The MareNostrum Experimental Exascale Platform. Supercomputing frontiers and innovations, Vol. 8(1), 62-81. Superfri.org

[4]. Mahale, G. (2022). A RISC-V VPU for Very Long and Sparse Vectors. MEEP. https://meep-project.eu/results/publications/meep-poster-risc-v-vpu-very-long-and-sparse-vectors

[5]. Wentzlaff Parallel Research Group. (2016, April 2). OpenPiton Microarchitecture Specification. OpenPiton. http://parallel.princeton.edu/openpiton/docs/micro_arch.pdf