Choosing a RISC-V evaluation board starts with the software you need to run

RISC-V evaluation boards can look comparable because they share an instruction-set family. Their ability to run the same application, library or accelerated workload needs a more specific comparison.

EPCC's ExCALIBUR testbed illustrates the range. Its published inventory includes server-oriented hardware, Linux single-board computers and FPGA-hosted processors. The testbed configurations are useful examples rather than a current retail catalogue or a performance ranking.

The memory capacities above are the systems documented by EPCC. They should not be assumed to describe every variant available from a manufacturer.

Treat the vector version as a compatibility field

The RISC-V ratified Vector Extension 1.0 specification defines the available operations and programmer's model. It also permits implementation-defined parameters, including the number of bits in a vector register, VLEN, and the maximum supported element width, ELEN.

The specification supports portable vector code under stated constraints, provided each processor implements the required element types and instructions. That is more precise than assuming all RISC-V processors provide the same vector execution environment.

EPCC lists an older vector implementation for Pioneer and RVV 1.0 for Jupiter and BPI-F3. A build or library selected for one version should therefore not be presumed suitable for the other. The actual target and instruction requirements need to be established before interpreting either a successful benchmark or an illegal-instruction failure.

Vector register width is a separate variable. Code designed to adapt to the implementation can remain portable while delivering different performance. Code that assumes a fixed width may have a narrower set of valid targets.

Define what the board is meant to answer

For an application-porting exercise, the first result is whether the required software builds, runs correctly and has the necessary dependencies. Kernel support, libraries and peripheral drivers are part of that result.

For a throughput comparison, hold the input, correctness criteria and compiler settings steady. Record the compiler version and target options with the output. Otherwise a change in optimisation or library implementation can be mistaken for a hardware advantage.

For multicore work, compare scaling rather than only the maximum thread count. Memory capacity, access patterns and network traffic can become the limits before every core is usefully occupied. A larger board may be valuable because it can host a realistic dataset, even when a smaller board is sufficient to prove that the program is portable.

The RISC-V Vector C Intrinsic Specification, ratified in April 2025, supplies a standard interface for writing vector operations in C. It is an additional software-layer reference, not a guarantee that every packaged library on every board uses vector acceleration.

Keep the evaluation reproducible

A compact evaluation record should identify the SoC and board revision, implemented ISA extensions, operating-system image, compiler, libraries, test data and measured power conditions. Save the build instructions and correctness checks with the timings.

That record gives the board a clear role. It can establish whether a software dependency is viable, whether a vector path works or whether an application scales across more cores. Each is a useful outcome, but none should be confused with a complete qualification of a different production platform.

Sources

EPCC hardware inventory; Ratified Vector Extension 1.0; Vector C Intrinsic Specification.