Accelerator Value Spectra

Definition

Accelerator Value Spectra are FPGA-relevant runtime value measurements collected from synthesized hardware kernels produced by High-Level Synthesis (HLS). Because HLS implements branching as a pipeline of hardware logic—where each branch executes in parallel as long as prior signals are ready, but untaken branches simply produce unused outputs—branch coverage cannot be derived directly from the synthesized hardware. To overcome this limitation, HeteroFuzz analyzes inserted HLS pragmas and traces their associated FPGA-relevant spectra as accelerator feedback [chunk:58e8345a]. Accelerator Value Spectra are described as a multi-dimensional guidance feedback signal, used alongside host-code branch coverage, to detect platform-dependent divergence between CPU and FPGA execution [chunk:309a4e09].

The mapping from HLS pragma categories to their corresponding Accelerator Value Spectra (as defined in Table 2 of the HeteroFuzz paper) is:

[chunk:4e5adb82]

HeteroFuzz currently supports five kinds of value spectra, and the mapping is user-extensible via a configuration file [chunk:58e8345a].

Purpose and Motivation

Standard fuzzing relies on branch coverage as a guidance metric. However, in heterogeneous applications (CPU host + FPGA accelerator):

• Inputs with the same branch coverage in the host code can still have distinct impacts on hardware characteristics [chunk:58e8345a].
• Heterogeneous platforms often produce divergent behavior because of hardware synthesis assumptions, not host-code structure [chunk:7cb639d7].
• Numerous severe security problems originate from host–accelerator interaction [chunk:58e8345a].

Therefore, accelerator value spectra provide an additional, hardware-relevant guidance signal that helps a fuzzer reach inputs which trigger platform-dependent divergence.

How Accelerator Value Spectra Are Tracked

Tracking mirrors AFL's coverage accounting, but for hardware values [chunk:309a4e09]:

1. In each test execution, HeteroFuzz initializes an array acc_feedback, where each entry has four fields: <value spectra type, name, min value, max value>.
2. It then updates total_feedback to record cumulative value spectra for all seen inputs that can safely execute on the synthesized FPGA.
3. An input is kept in the generated tests if it increases either host branch coverage or accelerator value spectra.

Concrete Example (accumulate kernel, Figure 2c)

For an accumulation kernel accumulate (Figure 2c) declared with custom bitwidth types typedef ap_uint<8> bit8 and typedef ap_uint<9> bit9, HeteroFuzz records three types of value spectra [chunk:58e8345a, chunk:309a4e09, chunk:faf2ea85]:

1. The value range of fpga_data, the output variable sum, and intermediate variable i (variables declared with custom bitwidth types in lines 22–24).
2. The set of accessed offsets in the pre-allocated array data_fpga (declared with maximum size 400 in line 22).
3. The actual loop iteration count, which together with array access offsets helps detect divergence when the size of offloaded data is not a multiple of 2 (unroll pragma at line 29).

HLS data transfer interface pragmas (lines 7–21) are ignored, as they have no impact on kernel logic.

For kernel inputs [1,1,1,253], the tracked hardware feedback (column "FPGA Accelerator Spectra") is exemplified in Table 3 [chunk:309a4e09, chunk:faf2ea85]:

• input_value fpga_data — min 1, max 253
• variable_value i — min 0, max 3
• variable_value sum — min 0, max 3
• mem_offset fpga_data — {0,1,2,3}
• loop SUM_LOOP — iterations 2

Interaction with Other HeteroFuzz Components

Probabilistic Mutations

When a new bitwidth range (or any new accelerator value spectrum) is achieved by a mutation, HeteroFuzz labels that mutation as a favored mutation and increases its activation probability [chunk:7cb639d7]. Given activation probabilities P = {P0, P1, ..., Pl−1} for l mutations, the dynamic update rule is [chunk:95051609]:

Pm = Pm + α        if m is chosen and it increases spectra
Pm = Pm − α/(l−1)  otherwise

with α = 0.05 as the predefined update factor and an initial probability of 1/l for each mutation. For example, when input IDs grow, a mutation M3 that increases the spectra of input_value and variable_value has its probability raised from 0.17 to 0.22, while other probabilities drop to 0.16 [chunk:faf2ea85, chunk:95051609].

Selective Invocation

To reduce the long latency of repetitive hardware simulation, HeteroFuzz maintains the range of seen kernel input values that execute correctly on FPGA (and their data size) [chunk:4b0a7c8b]. It skips hardware simulation if the current kernel input remains within the memorized safe range, because accelerator synthesis is determined and optimized by kernel input values, so multiple invocations within the same value range tend to expose only redundant divergence symptoms. A kernel input that exceeds the previously seen range triggers enable_sim = true and a hardware simulation call.

Why Range-Tracking Is Sufficient

For the purpose of finding new divergence symptoms, it is enough to record only the range (e.g., (2, 5)) of integer-valued kernel variables rather than enumerating all combinations (e.g., {2, 3, 5}) [chunk:4b0a7c8b]. This relies on a property of FPGA synthesis: an integer or fixed-point variable maps to a contiguous range of values, so an error for an unseen combination such as {2, 4, 5} will be identical to symptoms already exposed by executing values less than 2 or greater than 5.

Empirical Impact

Across seven publicly available heterogeneous applications (P1–P7), monitoring accelerator value spectra produces significant gains over branch-coverage-only fuzzing [chunk:36f56142, chunk:95051609]:

• HeteroFuzz finds 7.78× more divergence-inducing inputs (3.7× more unique divergence symptoms) than a version without accelerator spectra monitoring [chunk:4c425771].
• Across all seven applications, the version without spectra takes a total of 21 hours to find 10 unique symptoms, while HeteroFuzz takes only 0.52 hours—a 40× speed-up [chunk:36f56142].
• HeteroFuzz's coverage in host code grows slightly slower than WithoutSpectra, because it steers the fuzz engine to explore more platform-dependent divergence rather than maximizing host branch coverage [chunk:4c425771].
• On average, 56.8% of inputs generated by HeteroFuzz are divergence-inducing, versus 6.48% for WithoutSpectra [chunk:36f56142].

Sub-component: FIFO Queue Size

One specific accelerator value spectrum tracked under the parallelization category is the FIFO queue size, monitored when a #pragma HLS dataflow directive introduces a feedback path. In a FIFO Queue, #pragma HLS dataflow enables task-level pipelining, allowing parallel execution of producer and consumer tasks. HeteroFuzz uses FIFO queue fullness as a feedback signal; the dataflow dataflow directive is the relevant HLS pragma category whose FPGA-relevant value spectra is "The FIFO queue size if feedback path exists" [chunk:4e5adb82, chunk:309a4e09].

Extensibility

The set of supported spectra is "user-extensible by modifying a configuration file" [chunk:58e8345a]. Although HeteroFuzz is designed for FPGA accelerators, its core idea—monitoring platform-specific spectra—can be extended to other heterogeneous platforms by replacing the spectra definitions with platform-relevant ones.