PaperlayerView exact revision on arXiv

Source-linked AI summary

Fuzzing Hardware Like Software

Timothy Trippel, Kang G. Shin, Alex Chernyakhovsky, Garret Kelly, Dominic Rizzo, Matthew Hicks

arXiv:2102.02308v1cs.ARcs.CR

TL;DR

Adapting software fuzzing to hardware verification requires accounting for hardware-specific inputs and harness needs. The paper translates RTL designs into software models and fuzzes them, reporting over two orders-of-magnitude less time to reach full FSM coverage than conventional CRV.

  • Problem

    Adapting software fuzzers to hardware requires handling hardware-specific input processing, initialization, and meaningful mutation.

    Source: §I · p. 2

  • Method

    The authors translate RTL designs into software models and fuzz those models directly.

    Source: §I · p. 2

  • Results

    Over two orders-of-magnitude reduction in time to reach full FSM coverage versus conventional CRV; three of four OpenTitan cores exceeded 88% HDL line coverage after one hour without seeds.

    Source: §I · p. 2

  • Takeaways & Limitations

    The authors conclude that hardware fuzzing is an effective solution to coverage-driven hardware design verification.

    Source: §IX · p. 14

    Without hardware sanitizers, DV engineers must create invariants or gold models for the fuzzer to find crashing inputs.

    Source: 4) Limitations · p. 13

Abstract

from arXiv · show

Hardware flaws are permanent and potent: hardware cannot be patched once fabricated, and any flaws may undermine any software executing on top. Consequently, verification time dominates implementation time. The gold standard in hardware Design Verification (DV) is concentrated at two extremes: random dynamic verification and formal verification. Both struggle to root out the subtle flaws in complex hardware that often manifest as security vulnerabilities. The root problem with random verification is its undirected nature, making it inefficient, while formal verification is constrained by the state-space explosion problem, making it infeasible against complex designs. What is needed is a solution that is directed, yet under-constrained. Instead of making incremental improvements to existing DV approaches, we leverage the observation that existing software fuzzers already provide such a solution, and adapt them for hardware DV. Specifically, we translate RTL hardware to a software model and fuzz that model. The central challenge we address is how best to mitigate the differences between the hardware execution model and software execution model. This includes: 1) how to represent test cases, 2) what is the hardware equivalent of a crash, 3) what is an appropriate coverage metric, and 4) how to create a general-purpose fuzzing harness for hardware. To evaluate our approach, we fuzz four IP blocks from Google's OpenTitan SoC. Our experiments reveal a two orders-of-magnitude reduction in run time to achieve Finite State Machine (FSM) coverage over traditional dynamic verification schemes. Moreover, with our design-agnostic harness, we achieve over 88% HDL line coverage in three out of four of our designs -- even without any initial seeds.

I. INTRODUCTION

The introduction argues that hardware’s complexity and lack of general-purpose patching make pre-fabrication verification vital, and proposes fuzzing software models of RTL with a generic harness. It reports faster FSM coverage than conventional random verification and high HDL line coverage on several OpenTitan cores.

I. INTRODUCTION

  • Hardware flaws are costly and reputationally damaging to repair, cannot be generally patched, and can undermine formally verified software running above the hardware.The introduction links increasing design complexity to greater verification complexity and the possibility of flaws reaching products.Source: §I · p. 1
  • Random dynamic verification struggles to explore deep design states, formal verification fails on larger designs, and prior CDG faces costly coverage tracing and DUT-specific test generation.RTL must be simulated as part of a hardware simulation binary, and hardware inputs often require structured transaction sequences tailored to the DUT.Source: §I · p. 2
  • Hardware Fuzzing translates RTL designs into software models and fuzzes them directly, enabling compile-time coverage instrumentation; maximizing DUT-model code coverage maximizes hardware code coverage.The introduction presents this as an alternative Coverage Directed Test Generation approach.Source: Figure 1 · p. 1, §I · p. 2
  • The approach addresses hardware-specific challenges by interfacing with HSBs, mapping test cases into input sequences, and using a bus interface with a generic harness and grammar for meaningful mutations.Reusing the harness across designs that speak the same bus protocol supports design-agnostic fuzzing.Source: §I · p. 2
  • Over two orders-of-magnitude reduction in run time achieved comparable or better FSM coverage than state-of-the-art CRV; unseeded fuzzing reached over 88% HDL line coverage on three of four OpenTitan cores after 1 hour.The FSM comparison covered over 480 variations of a sequential FSM circuit.Source: §I · pp. 2–3

II. BACKGROUND · A. Dynamic Verification of Hardware · 2) Hardware Simulation:

Dynamic verification remains the scalable standard for complex hardware, and the paper adapts software fuzzing to improve it. Hardware simulation translates HDL into a software model compiled with a testbench and simulation engine as an executable HSB.

II. BACKGROUND

  • Dynamic verification remains the gold standard for complex designs because of its scalability, motivating the paper’s focus on software-fuzzing advances for dynamic verification.Source: §II · p. 3

A. Dynamic Verification of Hardware

  • Dynamic verification repeatedly generates input sequences, simulates the DUT, and evaluates behavior, measuring functional and HDL code coverage to track explored behaviors.Source: A. Dynamic Verification of Hardware · p. 3
  • CRV randomly combines manually defined inputs and requires tuning without coverage feedback, while CDG mutates prior sequences to target uncovered design regions.CRV remains popular; CDG has faced slow coverage tracing and limited applicability, hindering widespread adoption.Source: A. Dynamic Verification of Hardware · p. 3
  • Dynamic verification test generation aims to use as few test vectors as possible while still closing coverage.Source: A. Dynamic Verification of Hardware · p. 3

2) Hardware Simulation:

  • Hardware simulators translate HDL into a software model, compile it with an HDL- or software-based testbench, and link both with a simulation engine to form an HSB.The HSB runs with testbench inputs to capture design behavior.Source: 2) Hardware Simulation · p. 3, Figure 2 · p. 3
  • The paper uses Verilator’s transparent HSB generation to intercept the translated hardware model and instrument and compile it for coverage-guided fuzzing.Source: 2) Hardware Simulation · pp. 3–4
  • The hardware-fuzzing workflow translates the DUT, instruments the HSB for coverage, creates seed inputs with a design-agnostic grammar, and fuzzes the binary with a coverage-guided greybox fuzzer.Source: Figure 3 · p. 4

3) Test Evaluation: … III. HARDWARE FUZZING

Hardware Fuzzing translates RTL designs into software models and fuzzes them directly, adapting software-fuzzing methods to hardware verification. It treats invariant violations and mismatches with a golden model as crash analogues.

3) Test Evaluation:

  • Invariant violations and mismatches with a golden model serve as software-crash analogues for evaluating hardware correctness.Invariant checking uses assertions; model checking compares simulated DUT behavior with a separate software model of correct behavior.Source: 3) Test Evaluation · p. 4

B. Software Fuzzing

1) test generation,

  • Fuzzing generates inputs, feeds them to the program under test, monitors execution, and analyzes crashes to identify root causes.The process repeats until all or most of the target has been explored.Source: 1) test generation · p. 4
  • Most fuzzers generate test cases either with a human-crafted grammar – that enforces target-specific structural requirements, or by mutating a correctly formatted seed test to create new tests.Source: 1) test generation · p. 4
  • The work favors mutational, coverage-guided fuzzers because they are design-agnostic and regionally generic.These fuzzers prioritize exploring as much of the target as possible.Source: 1) test generation · p. 4

2) Test Execution Monitoring:

  • Because Verilator converts RTL to C++ source, the approach can use blackbox, whitebox, or greybox fuzzing and currently deploys greybox.Blackbox fuzzers monitor inputs and outputs, whitebox fuzzers analyze execution paths and solve constraints, and greybox fuzzers use lightweight analysis such as coverage tracing.Source: 2) Test Execution Monitoring · p. 4

III. HARDWARE FUZZING

  • Hardware Fuzzing translates hardware designs into software models and fuzzes them directly, addressing design-agnostic adaptation challenges.The approach leverages software fuzzing for hardware design verification and scalable coverage tracing.Source: §III · p. 4

A. Why Fuzz Hardware like Software? … 2) Interpreting Fuzzer-Generated Tests:

RTL can be translated into a software model and fuzzed with software coverage tracing; a generic harness converts one-dimensional fuzz inputs into hardware input sequences across space and time.

A. Why Fuzz Hardware like Software?

1) Translating HDL to Software:

  • Verilator translates SystemVerilog HDL into a cycle-accurate C++ model, enabling hardware to be fuzzed in software.The paper leverages Verilator, an open-source hardware simulator, for this translation.Source: 1) Translating HDL to Software · p. 5
  • The generated model exposes top-level inputs and outputs as public variables and advances state through eval() calls, with two calls representing one clock cycle.Signal variables use bool, uint32_t, or uint64_t types depending on signal width.Source: 1) Translating HDL to Software · p. 5

2) Tracing Hardware Coverage in Software:

  • Prior CDG approaches use custom RTL-instrumented coverage metrics such as multiplexer coverage, [16], but require FPGA simulation and lack evidence that these metrics reflect DV-relevant coverage.Hardware coverage tracing during software simulation can also be slow because software-domain coverage must be mapped back to hardware.Source: 2) Tracing Hardware Coverage in Software · p. 5
  • Optimizing edge coverage in Verilator-generated C++ implicitly optimizes both hardware code and functional coverage.Verilator emits straight-line code for SystemVerilog statements and conditional blocks for assertions and coverage points, making software edge coverage a proxy for hardware coverage.Source: 2) Tracing Hardware Coverage in Software · p. 5

B. Adapting Software Fuzzers to Fuzz Hardware

  • Directly fuzzing a hardware software model can degrade performance by instrumenting the testbench and simulation engine, and requires resetting and initializing the DUT before inputs.Large DUTs may require snapshotting the simulation process after reset and initialization.Source: B. Adapting Software Fuzzers to Fuzz… · p. 5

2) Interpreting Fuzzer-Generated Tests:

  • A generic harness maps bytes from a fuzzer-generated file to hardware ports and advances the simulation clock until no bytes remain.This transforms a single-dimensional test into a two-dimensional sequence of hardware inputs across space and time.Source: 2) Interpreting Fuzzer-Generated Tests · p. 6

3) Bus-Centric Harness:

The bus-centric harness makes hardware fuzzing portable across DUTs by driving IP cores through a bus interface. It decodes fuzzer-generated inputs into structured bus transactions so syntax-blind fuzzers can produce valid traffic.

3) Bus-Centric Harness:

  • A bus-centric harness avoids requiring DV engineers to build a unique fuzz harness for each DUT, enabling DUT portability.The authors propose fuzzing IP cores at their SoC bus interface because hardware-model ports are not iterable.Source: 3) Bus-Centric Harness · p. 6
  • Mapping test-file bytes directly to bus-signal values risks an exploration barrier because mutational fuzzers generally lack syntax awareness.The harness instead decodes generated files into sequences of properly structured bus transactions using a bus-centric grammar.Source: 3) Bus-Centric Harness · p. 6
  • The harness reads binary Hardware Fuzzing Instructions, decodes them, and performs TL-UL transactions to drive the DUT.The grammar is intended to help syntax-blind coverage-guided greybox fuzzers generate valid bus transactions; the implementation uses a 32-bit TL-UL data bus.Source: Figure 4 · p. 6, Table I · p. 6, 3) Bus-Centric Harness · p. 6

4) Bus-Centric Grammar: · IV. HARDWARE FUZZING PIPELINE · V. EVALUATION - PART 1

The paper defines a compact, bus-centric grammar for turning fuzzer inputs into TL-UL transactions and builds an open-source pipeline to fuzz RTL software models at scale. Its first evaluation examines how to interface software fuzzers with hardware simulation binaries and compares coverage convergence with CRV across digital-lock designs.

4) Bus-Centric Grammar:

  • Hardware Fuzzing instructions use an 8-bit opcode, 32-bit address, and 32-bit data field to encode TL-UL bus transactions.The opcode determines the transaction performed by the harness; the grammar uses a compact binary format compatible with formats produced by popular greybox fuzzers –.Source: 4) Bus-Centric Grammar · p. 6
  • The grammar leaves harnesses to map byte-sized opcode values and choose fixed- or variable-size instruction frames, with encoding performance studied in §VI-B.It defines three opcodes; the byte-sized field supports compact seed-file utilities and leaves room for additional TileLink operations.Source: 4) Bus-Centric Grammar · p. 6

IV. HARDWARE FUZZING PIPELINE

  • The open-source Hardware Fuzzing Pipeline, modeled after Google’s OSS-Fuzz [34], enables RTL verification at scale using open-source tools.The paper notes that using open-source tools is unusual in hardware DV.Source: §IV · p. 6, Figure 5 · p. 7
  • The pipeline translates RTL with Verilator, instruments and links the model with a generic harness and simulation engine, fuzzes it, traces HDL coverage, and stores results.It runs in Docker containers on GCP VMs; the implementation uses AFL but is designed to be fuzzer-agnostic.Source: §IV · p. 7
  • Using open-source tools lets DV engineers spend less on licenses and more on compute, supporting deployment alongside existing hardware-verification workflows.The paper argues that adoption benefits from overlap with proven techniques because verification mistakes can have costly repercussions.Source: §IV · p. 7

V. EVALUATION - PART 1

  • The first evaluation investigates how software fuzzers interface with HSBs and how their time to coverage convergence compares with CRV across more than 480 digital-lock designs.The configurable lock varies in number of states and input-code width; HSB testbenches and simulation engines are components the fuzzer must manipulate but are not testing targets.Source: §V · p. 7, Figure 6 · p. 7

A. Digital Lock Hardware · B. Digital Lock HSB Architectures

The digital lock provides configurable state-space and code-search complexity for comparing CRV with hardware fuzzing. CRV retries random valid sequences, while hardware fuzzing uses coverage-guided input mutation and process forking.

A. Digital Lock Hardware

  • 480 digital-lock state machines vary in state-register size N, comparator/mux size M, and randomly selected correct code sequences.These configurable dimensions make the design suitable for stress-testing verification methodologies.Source: A. Digital Lock Hardware · p. 7
  • The lock’s complexity is adjustable through the number of states, set by N, and the probability of selecting the correct code sequence, adjusted by M.N controls the single state register’s size; M controls the comparator/mux checking inputs against hard-coded random values.Source: A. Digital Lock Hardware · p. 7

B. Digital Lock HSB Architectures

  • CRV brute-forces the lock with random code sequences, resetting after failures and terminating simulation when success violates an SVA.Sequences are constrained to valid code values and exactly 2N−1 input codes for locks with 2N states.Source: B. Digital Lock HSB Architectures · p. 7
  • The CRV testbench uses cocotb, with simulations run in Verilator.Source: B. Digital Lock HSB Architectures · p. 7
  • Hardware fuzzing checkpoints and forks the HSB process for candidate sequences; failures trigger another fork, while successful unlocking is registered as a crash through SVA violation.Unlike CRV, the fuzzer traces coverage and saves sequences that approach unlocking for mutation into future inputs.Source: B. Digital Lock HSB Architectures · p. 8
  • A C++ harness reads fuzzer-generated bytes from stdin into the lock’s code input, and the DUT-containing HSB is instrumented with afl-clang-fast++.Source: B. Digital Lock HSB Architectures · p. 8

C. Interfacing Software Fuzzers with Hardware

This section examines which HSB components to instrument and whether hardware fuzzing needs pre-fork reset initialization; its reported comparison favors DUT-only instrumentation.

C. Interfacing Software Fuzzers with Hardware

  • Coverage instrumentation should focus on the DUT, even though the fuzzer must use the testbench and simulation engine to manipulate it.The stated aim is to avoid spending fuzzing cycles on coverage in the testbench or simulation engine.Source: C. Interfacing Software Fuzzers with… · p. 8
  • The section raises reset as an integration concern: traditional testbenches reset the DUT for each execution, prompting the question of whether pre-fork initialization is required.Repeated resets may occur hundreds or thousands of times per second; requiring fuzzer-specific initialization could complicate design-agnostic integration.Source: C. Interfacing Software Fuzzers with… · p. 8
  • The comparison used 16-, 32-, and 64-state locks with four-bit codes, 50 empty-seed runs per setup, and unlocking as approximate full FSM coverage.Approximate coverage reflects that the experiments did not excise the locks’ reset-state transitions.Source: C. Interfacing Software Fuzzers with… · p. 8
  • Instrumenting only the DUT improves fuzzing speed and never handicaps coverage convergence; all runtime improvements were statistically significant at the 0.05 level.The reported advantage was less pronounced as DUT size increased relative to the testbench and simulation engine.Source: Figure 8 · p. 9, C. Interfacing Software Fuzzers with… · p. 9

2) Hardware Resets vs. Fuzzer Performance: · D. Hardware Fuzzing vs. CRV

Hardware-reset overhead diminishes as DUT complexity grows, while Hardware Fuzzing achieves near-full FSM coverage over two orders of magnitude faster than CRV on medium-to-large locks, even from an empty seed.

2) Hardware Resets vs. Fuzzer Performance:

  • The reset experiment compared default fork-server initialization at main() with initialization after the DUT reset to assess repeated-reset simulation overhead.AFL’s fork server creates child processes from the initialized program state, allowing program-specific initialization to occur before fuzzing children are forked.Source: 2) Hardware Resets vs. Fuzzer… · p. 9
  • Only 8- and 16-state locks showed significant runtime differences between fork-server initialization points (p < 0.05), indicating reset overhead diminishes as DUT complexity grows.The analysis compared run times normalized to the median after-DUT-reset run time for each lock size.Source: 2) Hardware Resets vs. Fuzzer… · pp. 9–10, Figure 10 · p. 9
  • Even the largest studied digital lock had fewer software-model basic blocks than the smallest OpenTitan core, the RISC-V Timer.The paper notes this size comparison to contextualize the finding that reset overhead diminishes with DUT complexity.Source: 2) Hardware Resets vs. Fuzzer… · p. 9, Figure 9 · p. 9

D. Hardware Fuzzing vs. CRV

  • On medium-to-large locks, Hardware Fuzzing achieved ≈full FSM coverage over two orders of magnitude faster than CRV, even when seeded with an empty file.Run times were averaged across 20 trials; many CRV runs were stopped after five days.Source: D. Hardware Fuzzing vs. CRV · p. 10, Figure 11 · p. 10
  • Hardware Fuzzing’s advantage over CRV became apparent as lock complexity increased, while results were indistinguishable for extremely small designs.The experiments covered digital locks with 2–64 states and code widths of 1–8 bits, using an empty-file fuzzer seed to align its starting state with CRV.Source: D. Hardware Fuzzing vs. CRV · p. 10
  • Hardware Fuzzing is presented as a low-cost, low-overhead coverage-directed-guidance approach for hardware design verification.The comparison was against CRV, described as the current state-of-the-art hardware dynamic verification technique.Source: D. Hardware Fuzzing vs. CRV · p. 10

VI. EVALUATION - PART 2 … 3) KMAC:

The evaluation examines grammar format and real-world fuzzing on four OpenTitan IP cores, which share a bus protocol that enables a reusable harness. The core descriptions highlight their different functions and complexity.

VI. EVALUATION - PART 2

  • The evaluation asks how grammar format affects fuzzer learning and how Hardware Fuzzing performs on real hardware IP cores.The authors aim to avoid requiring DV engineers to tailor harnesses to individual designs, unlike existing CDG methods,,,, –.Source: §VI · p. 10

A. OpenTitan IP

  • The evaluation studies AES, HMAC, KMAC, and RISC-V Timer cores from OpenTitan [35], using their shared TL-UL memory-mapped interface to reuse a generic fuzzing harness.The harness executes fuzzer-generated instructions as TileLink operations and reports violated SVAs as crashes.Source: A. OpenTitan IP · p. 10, Figure 12 · p. 11

1) AES:

  • The AES core supports 128-, 192-, and 256-bit keys and ECB, CBC, CFB, OFB, and CTR modes, with 12-, 14-, and 16-cycle block latencies, respectively.It has a shared 128-bit datapath and is the second most complex studied core by hardware and software LOC.Source: 1) AES · pp. 10–11

2) HMAC:

  • The HMAC core supports SHA-256-only and HMAC modes, processes 512-bit message chunks, and takes 80 cycles to hash one block or 340 cycles to compute its HMAC.It supports little- or big-endian message input and digest storage, and is about half as complex as AES by hardware and software LOC.Source: 2) HMAC · p. 11

3) KMAC:

  • KMAC supports SHA3-224/256/384/512, SHAKE128/256, and cSHAKE128/256, with configurable hash or authentication operation and endianness; its 1600-bit Keccak-f takes 72 cycles.The core communicates configuration, messages, digests, keys, and commands through TileLink operations on memory-mapped registers.Source: 3) KMAC · p. 11
  • The KMAC software model contains almost 120k lines of C++, largely because Verilator maps dependencies between large registers and vectored signals into multidimensional arrays.Compilation optimizes away this artifact, reducing the basic-block count in the DUT portion of the harness.Source: 3) KMAC · p. 11

4) RV-Timer: … 2) Instruction Frame Formats:

This section describes the RV-Timer and evaluates grammar-decoding choices for a generic hardware-fuzzing harness; variable instruction frames are reported as best for greybox fuzzers that prioritize small test files.

4) RV-Timer:

  • The RV-Timer is a single 64-bit timer with 12-bit prescaler and 8-bit step configurations, activated and configured through TileLink writes to memory-mapped registers.It can also generate system interrupts when it reaches a pre-configured time value.Source: 4) RV-Timer · p. 11

B. Optimizing the Hardware Fuzzing Grammar

  • The generic testbench harness decodes a grammar into TL-UL bus transactions, raising questions about decoding opcodes and packing instruction frames.The harness is intended to exercise the device under test through corresponding bus transactions.Source: B. Optimizing the Hardware Fuzzing… · p. 11

1) Opcode Formats:

  • The grammar defines wait, read, and write actions using one-byte opcodes, leaving 253 of 256 values potentially useless depending on decoding.The paper empirically studies constant and mapped opcode-decoding choices.Source: 1) Opcode Formats · pp. 11–12
  • Software-domain coverage correlates with hardware-domain coverage, and variable instruction frames work best for greybox fuzzers prioritizing small test files.The comparison covers software line coverage, basic-block coverage, and HDL line coverage across four OpenTitan IP cores and grammar variations.Source: Figure 13 · p. 12
  • Constant decoding assigns one opcode value per action and ignores remaining values, whereas mapped decoding assigns equal-sized ranges to actions with no invalid values.Source: 1) Opcode Formats · p. 12

2) Instruction Frame Formats:

  • TL-UL reads require a 32-bit address and writes require 32-bit address and data fields; fixed frames may leave fields unused, while variable frames append them only when needed.Source: 2) Instruction Frame Formats · p. 12

3) Results: … 2) Additional Bus Protocols:

With one empty seed and one hour of fuzzing, Hardware Fuzzing achieves over 88% HDL line coverage in three of four studied OpenTitan designs and over 65% in the remaining design. It also converges on coverage more than two orders of magnitude faster than CRV, using crash-based bug detection and a TL-UL harness that can be extended to other bus protocols.

3) Results:

  • Across four OpenTitan IP blocks fuzzed for 24 hours, variable frames seem better early, opcode type makes little difference in most experiments, and RV-Timer reaches ≈85% HDL line coverage in under a minute.Experiments used all combinations of opcode and instruction-frame formats, with 8–12 binary Hardware Fuzzing seed files per core.Source: 3) Results · p. 12
  • Variable-frame instructions suit fuzzers that prioritize small inputs by enabling longer temporal test sequences, and increased software-domain coverage translates to hardware coverage.The paper attributes the deeper possible sequential-state exploration to longer test sequences.Source: 3) Results · p. 12

C. Hardware Fuzzing in Practice

  • After one hour of fuzzing each of four OpenTitan IP cores using a single empty seed file as starting input, over 88% HDL line coverage was achieved in three cores and over 65% in the remaining core.Source: C. Hardware Fuzzing in Practice · p. 13
  • Hardware Fuzzing achieves over two orders-of-magnitude faster coverage-convergence times than CRV.The paper presents this as a comparison with the most popular DV technique today.Source: C. Hardware Fuzzing in Practice · p. 13

1) Detecting Bugs During Fuzzing:

  • Incorrect hardware behavior is detected through invariant checks or gold-model mismatches, which trigger SIGABRT crashes that software fuzzers log.Invariant violations use SVAs to signal the HSB process; gold-model testbenches signal on model-result mismatches.Source: 1) Detecting Bugs During Fuzzing · p. 13

2) Additional Bus Protocols:

  • The design-agnostic harness decodes bus-specific grammar into TL-UL transactions, supports OpenTitan cores, and can be extended to Wishbone, AMBA, or Avalon with a new harness.The current generic harness conforms to TL-UL; users write a new harness for another bus protocol.Source: 2) Additional Bus Protocols · p. 13

3) Hardware without a Bus Interface: … IX. CONCLUSION

Hardware Fuzzing adapts software testing methods to hardware design verification through generic interfaces, while addressing key deployability challenges. The paper reports high code coverage and faster design coverage than standard dynamic verification, alongside limitations and distinctions from prior work.

3) Hardware without a Bus Interface:

  • For non-bus I/O, a generic harness maps each fuzz-generated file to a sequence of DUT inputs across spatial and temporal domains; structurally dependent inputs call for a grammar and corresponding testbench.The approach is demonstrated on digital locks (Fig. 7B).Source: 3) Hardware without a Bus Interface · p. 13

4) Limitations:

  • Hardware Fuzzing currently relies on designer-created invariants or gold models to identify crashing inputs and does not detect side-channel vulnerabilities involving analog leakage.The paper identifies hardware sanitizers as a future research area.Source: 4) Limitations · p. 13

VIII. RELATED WORK — 1) Design-Agnostic:

  • Prior coverage-directed-generation approaches are design-agnostic or design-specific; RFUZZ uses mux-toggle coverage, while RFUZZ and Gent et al. raise scalability concerns with direct RTL coverage tracing.RFUZZ requires FPGA acceleration, and its coverage metric’s relation to code and functional coverage is unclear.Source: 1) Design-Agnostic · p. 13, §VIII · p. 13

2) Design-Specific:

  • Coppelia applies symbolic execution to processor RTL models, while MicroGP and Bose et al. generate assembly programs; Hardware Fuzzing can combine static methods with fuzzing such as concolic execution.The assembly-generation approaches require DUT-specific grammars.Source: 2) Design-Specific · pp. 13–14

IX. CONCLUSION

  • Over 88% HDL code coverage was achieved in three of four designs, and design coverage was over two orders of magnitude faster than standard dynamic verification.The results were achieved in one hour with no knowledge of the DUT design or implementation.Source: §IX · p. 14
Loading 2102.02308v1…