Board Support Package

Concept

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.

First seen 5/27/2026

Last seen 5/28/2026

Evidence 1 chunks

Wiki v1

WIKI

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

READ FULL ARTICLE →

NEIGHBORHOOD

No graph connections found for this entity yet. It may appear in future ingestion runs.

explore full graph →

RELATIONSHIPS

1 connections

Core-V-Verif ← uses 95% 1e

Core-V-Verif uses a Board Support Package to align test program resources with DUT resources.

LINKED ENTITIES

1 links

Core-V-Verif USES Extracted graph relationship

CITATIONS

5 sources

5 citations — click to expand

[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