Skip to content
STIMSMITH

Board Support Package

Concept WIKI v1 · 5/27/2026

A Board Support Package (BSP) is a board- or platform-specific software support layer that helps software run against the resources provided by a target platform, testbench, or virtualized environment. In Core-V-Verif, BSP files align RISC-V test programs with DUT/testbench resources and can include linker scripts, CSR configuration files, and startup assembly needed to run C programs.

Definition

A Board Support Package (BSP) is a platform-specific set of support files, routines, and configuration used to make software run correctly on a particular board, device under test (DUT), or virtualized hardware environment. In embedded RTOS contexts, developers create a BSP and device drivers to make an RTOS run on their platform. In verification contexts such as Core-V-Verif, BSP files align the resources expected by a test program with the resources supported by the DUT and testbench.

Role in Core-V-Verif

In the Core-V-Verif UVM environment, the core testbench memory module implements virtual peripherals by responding to reads or writes at specific data-bus addresses. The BSP is the set of additional “test-program environment” files that must match those testbench resources. This allows test programs to be compatible with the resources that the DUT/testbench actually supports.

The cited Core-V-Verif material describes BSP contents as including:

  • linker scripts that define program sections and memory regions;
  • control and status register configuration files;
  • assembly files that perform the minimum startup work required to run a C program.

Core-V-Verif can support test programs regardless of how they are created, as long as they are compatible with the BSP. The environment distinguishes whether a program is pre-existing or generated at run time, and whether it is self-checking or not.

Role in firmware and virtualization workflows

For firmware re-hosting, BSPs are part of the hardware/software boundary: firmware is tightly coupled to non-standard embedded hardware, and RTOS-based firmware commonly depends on BSP routines and device drivers. One re-hosting approach identifies BSP and driver code in target firmware and patches it with replacement BSP routines and drivers that can work with existing emulators.

In automotive software-defined vehicle architectures, vendors may provide BSPs together with hypervisor setups and resource-allocation guidelines. This reflects the BSP’s role as part of the vendor-provided platform enablement package for deploying workloads on shared or virtualized hardware.

LINKED ENTITIES

1 links
Core-V-Verif USES

CITATIONS

5 sources
5 citations
[1] In Core-V-Verif, BSP files align test-program resources with resources supported by the DUT/testbench. [PDF] UVM based design verification of a RISC-V CPU core - POLITesi
[2] Core-V-Verif BSP contents can include linker scripts, memory-region definitions, CSR configuration files, and assembly files needed to run a C program. [PDF] UVM based design verification of a RISC-V CPU core - POLITesi
[3] Core-V-Verif can support test programs regardless of how they are created, provided they are compatible with the BSP. [PDF] UVM based design verification of a RISC-V CPU core - POLITesi
[4] In RTOS firmware contexts, developers create a BSP and device drivers to make the RTOS run on their platform, and firmware re-hosting can identify and replace BSP routines and drivers. Firmware Re-hosting Through Static Binary-level Porting
[5] In automotive software-defined vehicle contexts, chipset vendors may provide BSPs together with hypervisor setups and resource allocation guidelines. Toward Automated Hypervisor Scenario Generation Based on VM Workload Profiling for Resource-Constrained Environments