Skip to content
STIMSMITH

Board Support Package

Concept WIKI v2 · 6/18/2026

A Board Support Package (BSP) is a platform-specific layer of support files, configuration, and routines that adapts software (including RTOSs and verification test programs) to run on a particular board, DUT/testbench, or virtualized hardware environment. In Core-V-Verif, the BSP aligns test-program resources with the DUT/testbench virtual peripherals and may include linker scripts, CSR configuration files, and startup assembly. The BSP also serves as the hardware/software boundary exploited by firmware re-hosting, and is part of the vendor-supplied enablement package for automotive software-defined vehicle platforms.

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 memory module in the core testbench implements a set of virtual peripherals by responding to read or write cycles at specific addresses on the data bus. To align the resources used by the test program with those supported by the DUT, the testbench uses additional files that are called the Board Support Package (BSP). The cited material describes these as "test-program environment" files that must match testbench resources.

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

  • linker scripts that define program sections and memory regions;
  • control and status register (CSR) configuration files;
  • assembly files that perform the bare minimum that is 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. Five categories are recognized: pre-existing self-checking, pre-existing not self-checking, generated self-checking, generated not self-checking, and "None" (a UVM test with no test program, such as accessing CSRs via the debug module interface in debug mode). Types 1 (pre-existing, self-checking) and 4 (generated, not self-checking) are expected to predominate.

Pass/fail outcomes are affected by other checker-monitors that are not part of the status-flags virtual peripheral; any such checker-monitors shall signal an error condition with uvm_error, and these will cause a simulation test to fail, independent of what the test program may or may not write to the status-flags virtual peripheral.

Role of the BSP in Core-V-Verif's corev-dv generator

corev-dv is a library of extensions to Google's riscv-dv instruction-stream generator. A non-core-specific version of corev-dv resides at $COREV_VERIF/lib/corev-dv and provides a set of extensions intended to be common across all (or at least most) CORE-V cores. When a Make target requires it, a specific hash of riscv-dv is cloned to $COREV_VERIF/$COREV_CORE/vendor_lib/riscv-dv, and the compile Makefiles compile in the required extensions to generate the core-specific corev-dv needed for a test.

Because each core's verification environment is likely to use a core-specific BSP, it is expected that each core will need to implement core-specific extensions to corev_asm_program_gen.sv. For example, $COREV_VERIF/lib/corev-dv/corev_asm_program_gen.sv implements an override of riscv_gen_program_header::gen_program_header() to enforce the use of common symbols required by the board support package. Core-specific corev-dv extensions are placed in $COREV_VERIF/$COREV_CORE/env/corev-dv.

Role in firmware and virtualization workflows

For firmware re-hosting, BSPs sit at 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 (static binary-level porting) identifies BSP and driver code in target firmware and patches it with pre-built replacement BSP routines and drivers that work with existing emulators, enabling minimal-modification migration from the original hardware into a virtualized environment without changing the emulators themselves.

In automotive software-defined vehicle (SDV) architectures, chipset vendors consolidate diverse automotive workloads on a shared hardware platform through virtualization. To support this, vendors provide BSPs together with hypervisor setups and resource-allocation guidelines. Adapting these static configurations to varying system requirements and workloads is a significant challenge for Tier 1 integrators, motivating automated scenario-generation frameworks that profile runtime behavior and integrate theoretical models and vendor heuristics to produce optimized hypervisor configurations.

Summary

Across these contexts, the BSP consistently serves as the platform-adaptation layer: it defines the memory map, startup code, and CSR/device-driver interfaces required to bridge generic software (whether an RTOS, a verification test program, or an automotive workload) with the specific resources of a board, testbench, or virtualized environment. In Core-V-Verif, this contract is further enforced by corev_asm_program_gen.sv, which overrides riscv_gen_program_header::gen_program_header() to ensure generated test programs use the common symbols required by the BSP.

LINKED ENTITIES

1 links
corev_asm_program_gen.sv DEPENDS_ON

CITATIONS

8 sources
8 citations
[1] The memory module in the core testbench implements a set of virtual peripherals by responding to read or write cycles at specific addresses on the data bus, and BSP files align test-program resources with the resources supported by the DUT/testbench. UVM based design verification of a RISC-V CPU core - POLITesi
[2] In Core-V-Verif, the BSP can include linker scripts defining program sections and memory regions, control and status register configuration files, and assembly files that perform the bare minimum required to run a C program. 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, so long as they are compatible with the BSP; the UVM environment recognizes pre-existing vs. generated and self-checking vs. not self-checking test programs, with types 1 (pre-existing, self-checking) and 4 (generated, not self-checking) expected to predominate. UVM based design verification of a RISC-V CPU core - POLITesi
[4] Pass/fail outcomes in Core-V-Verif are also affected by checker-monitors outside the status-flags virtual peripheral; any such checker-monitors must signal an error condition with uvm_error, which will cause a simulation test to fail independent of what the test program writes to the status-flags virtual peripheral. UVM based design verification of a RISC-V CPU core - POLITesi
[5] corev-dv is a library of extensions to Google's riscv-dv instruction-stream generator; a non-core-specific version lives at $COREV_VERIF/lib/corev-dv and a specific hash of riscv-dv is cloned per Make target to $COREV_VERIF/$COREV_CORE/vendor_lib/riscv-dv, with core-specific extensions placed in $COREV_VERIF/$COREV_CORE/env/corev-dv. COREV-DV — CORE-V Verification Strategy documentation
[6] $COREV_VERIF/lib/corev-dv/corev_asm_program_gen.sv implements an override of riscv_gen_program_header::gen_program_header() to enforce the use of common symbols required by the board support package, and each core is expected to implement core-specific extensions to corev_asm_program_gen.sv. COREV-DV — CORE-V Verification Strategy documentation
[7] In embedded RTOS contexts, developers create a BSP and device drivers to make the RTOS run on their platform; static binary-level porting identifies BSP and driver code in target firmware and patches it with pre-built replacement BSP routines and drivers adapted to existing emulators, enabling firmware re-hosting with minimal modification. Firmware Re-hosting Through Static Binary-level Porting
[8] In automotive software-defined vehicle architectures, chipset vendors provide BSPs together with hypervisor setups and resource-allocation guidelines to consolidate diverse automotive workloads on a shared hardware platform; adapting these static configurations to varying system requirements and workloads is a significant challenge for Tier 1 integrators. Toward Automated Hypervisor Scenario Generation Based on VM Workload Profiling for Resource-Constrained Environments

VERSION HISTORY

v2 · 6/18/2026 · minimax/minimax-m3 (current)
v1 · 5/27/2026 · gpt-5.5