LSC-Fuzz: Bayesian Fuzzing for FPGA Synthesizers

• LSC-Fuzz is a guided mutation strategy for FPGA logic synthesis compilers that employs Bayesian optimization to generate diverse, function-preserving HDL test cases.
• It integrates test-program generation, Bayesian diversity selection, and equivalence checking via SMT-based formal verification and simulation-based differential testing.
• Experimental results demonstrate that LSC-Fuzz uncovers new mis-compilation and crash bugs while increasing code complexity compared to blind mutation approaches.

LSC-Fuzz is a guided mutation strategy based on Bayesian optimization for detecting bugs in FPGA logic synthesis compilers. It is presented in “Code Difference Guided Fuzzing for FPGA Logic Synthesis Compilers via Bayesian Optimization” (Xu et al., 25 Aug 2025). The method targets a critical stage in FPGA development—logic synthesis—which translates software designs into hardware net lists for physical implementation, detailed timing and power analysis, gate-level simulation, test vector generation, and optimization and consistency checking. The motivating premise is that bugs or incorrect implementations in FPGA logic synthesis compilers may lead to unexpected behaviors in target applications and thereby pose security risks, particularly because FPGAs are used in safety-critical environments including aerospace, chip manufacturing, and medical devices. LSC-Fuzz addresses the limitation of simple, blind mutation strategies by combining test-program generation, Bayesian diversity selection, and equivalent check in a closed loop.

1. Problem setting and design objective

The system is designed for FPGA logic synthesis compilers such as Yosys, Vivado, Icarus, and Quartus, with the explicit aim of eliminating bugs in logic synthesis compilers. The paper characterizes existing work as limited by a simple, blind mutation strategy, and positions LSC-Fuzz as a guided alternative that produces diverse and complex HDL code for compiler testing (Xu et al., 25 Aug 2025).

A central design constraint is preservation of functional behavior while expanding structural and timing complexity. LSC-Fuzz therefore operates through equivalence-preserving mutations at the model level and then checks whether synthesis preserves equivalence at the netlist level. This suggests that the method is intended to expose deep crashes and mis-compilations not by changing intended functionality, but by stressing optimization, elaboration, and synthesis paths that ordinary test generation may underexplore.

2. Closed-loop architecture

LSC-Fuzz is organized into three tightly-coupled components that execute in a loop: the test-program generation component, the Bayesian diversity selection component, and the equivalent check component (Xu et al., 25 Aug 2025). Starting from a single seed CPS model, described as a Simulink® state-machine, the loop repeatedly mutates the model into an HDL test case, filters for high-diversity variants via Bayesian selection, and checks equivalence of the synthesized netlists.

The inputs to the loop are the seed CPS model $C$, parameters $P$ used as stimulation, an HDL Coder $L$ for Simulink→Verilog translation, and an overview tool $S$. The iterative workflow is specified as follows: generate $H'=\text{TPC}(C,P,L)$, select and possibly optimize $H''=\text{BDS}(H',H,S)$, synthesize $H''$, and compare its functional output to that of the original $H$. On mismatch, the system reports a bug.

This architecture couples metamorphic generation with differential validation. A plausible implication is that LSC-Fuzz treats diversity generation and semantic checking as mutually dependent stages rather than independent modules: the generator produces equivalence-modulo-input variants, the selector prioritizes variants likely to exercise challenging compiler behavior, and the checker determines whether the transformed and original artifacts remain functionally aligned after synthesis.

3. Test-program generation

The test-program generation stage implements “equivalence-modulo-input” metamorphic mutations at the FSM level through structural metamorphosis via path cloning and complexity amplification through dead-state injection (Xu et al., 25 Aug 2025). The stage first profiles all reachable states $s_i$ and variable valuations $V_i$ in the seed FSM. For each chosen insertion point, it wraps the original path in a guard that is always true by construction, $H'=\text{TPC}(C,P,L)$4 thereby preserving functional equivalence while doubling, or further expanding, the FSM topology size.

Complexity amplification is introduced in the dead branch, which is never taken at runtime. Randomly selected modules $P$0 are injected subject to three constraints: data types satisfy $P$1, sampling times satisfy $P$2, and no combinational loops are introduced, expressed as $P$3. The dead branch is then filled with a grammar-safe sequence of modules drawn from the seed’s AST.

The component is summarized in the function $H'=\text{TPC}(C,P,L)$5 where profiling is annotated as signal-range coverage, assertion generation builds an always-true guard, and compilation/execution generates mutated HDL and simulates it. In effect, the generator increases structural richness without changing the runtime path selected under the fixed stimulation.

4. Bayesian diversity selection

After test-program generation produces candidate HDL files $P$4, LSC-Fuzz selects variants that are both maximally distant from the seed and high in timing complexity. The paper states that LSC-Fuzz uses a simple Bayesian selector rather than a full GP-based acquisition function (Xu et al., 25 Aug 2025). The program-distance metric is

$P$5

where $P$6 is the number of net variables, $P$7 is the number of connections, and $P$8 is the number of process structures.

Timing complexity is defined by

$P$9

where $L$0 is the delay of component $L$1. The selector maintains a prior $L$2 for each variant and defines a likelihood $L$3 based on distance $L$4. The posterior is

$L$5

In practice, $L$6 and $L$7, so larger distances and higher timing delays are favored. Variants are sorted by descending $L$8, and the top-$L$9 are selected.

The paper further notes that it does not define a separate formula $S$0, such as EI or UCB. Instead, the posterior itself acts as the score,

$S$1

balancing exploration through structural distance and exploitation through timing complexity. A common misunderstanding would be to read the Bayesian component as a conventional GP-based Bayesian optimization pipeline; the paper explicitly presents a simpler posterior-ranking mechanism.

5. Equivalent checking and bug identification

The equivalent check component determines whether a synthesized candidate $S$2 remains functionally equivalent to the seed’s netlist. LSC-Fuzz applies two complementary techniques: SMT-based formal verification and simulation-based differential testing (Xu et al., 25 Aug 2025).

For SMT-based formal verification, the method extracts a property set $S$3 for each netlist $S$4. It then constructs

$S$5

An SMT check, with examples given as ABC/Z3, is run on $S$6. A satisfiable result implies equivalence. The paper notes, however, that dead-branch structures may cause spurious mismatches and therefore false positives.

For simulation-based differential testing, each netlist $S$7 is simulated under a fixed stimulus $S$8 with multiple engines: $S$9 Bit-level consistency is checked through

$H'=\text{TPC}(C,P,L)$0

The decision rule is conservative: only when both formal and simulation checks pass is no bug assumed; any mismatch is flagged and manually triaged. This dual-check design directly addresses the false-positive risk arising from dead-branch retention in synthesized netlists.

6. Experimental results, baselines, and limitations

The experimental setup uses Ubuntu 22.04 on an Intel i9 2.1 GHz host with 128 GB RAM. The tested compilers, described as latest stable versions, are Xilinx Vivado, Intel Quartus (partial), Yosys, and Icarus Verilog. Baselines are Verismith and LegoHDL. Test-case size is reported as 700–1 000 Verilog lines, and efficiency metrics are count of blocks, connections, and reference relationships, all from the Yosys AST. An ablation compares runs with and without the Bayesian selector (Xu et al., 25 Aug 2025).

In a two-week comparison per compiler, LegoHDL found 3 bugs, consisting of 2 known and 1 new; Verismith found 1 known bug; and LSC-Fuzz found 6 bugs, consisting of 2 known and 4 new. In a three-month campaign, LSC-Fuzz reported 16 bugs in Yosys, Icarus, Vivado, and Quartus, including 4 new crash-type bugs confirmed and 8 new mis-compilation bugs confirmed or pending.

The reported code-complexity measurements place LSC-Fuzz variants at 40–49 blocks, compared with 25–37 for Verismith and 30–41 for LegoHDL; 125–226 connections, compared with 102–117 and 120–210 respectively; and approximately 20 inter-module references, compared with approximately 16 for LegoHDL and approximately 15 for Verismith. In the ablation, enabling the selector yields $H'=\text{TPC}(C,P,L)$1 blocks/connections, $H'=\text{TPC}(C,P,L)$2 references, and only $H'=\text{TPC}(C,P,L)$3 slower generation.

The paper attributes these outcomes to several factors. It states that FSM-level path cloning forces the compiler to explore corner-case optimizations, uncovering deep crashes and mis-compilations, and that the Bayesian selector effectively focuses resources on the most “diverse” and “challenging” variants without undue overhead. At the same time, it identifies clear limitations: equivalent checking via SMT alone can incur false positives when dead-branches remain in the netlist; Quartus was only partially tested because of licensing constraints; and future work could integrate more expressive acquisition functions such as UCB or EI, grammar-aware or LLM-driven module synthesis, and automated reduction of mis-compilation witnesses via AST slicing. The replication package, including seed models, scripts, and generated HDL, is available at https://github.com/cemery123/FPGA_Logic_Synthesis_Compilers_Testing.