Board Support Package

Concept

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.

First seen 5/27/2026

Last seen 6/18/2026

Evidence 2 chunks

Wiki v2

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

2 connections

Core-V-Verif ← uses 95% 1e

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

corev_asm_program_gen.sv ← depends on 95% 1e

corev_asm_program_gen.sv enforces symbols required by the board support package.

LINKED ENTITIES

1 links

corev_asm_program_gen.sv DEPENDS_ON Extracted graph relationship

CITATIONS

8 sources

8 citations — click to expand

[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