Pith. sign in

REVIEW 3 major objections 5 minor 39 references

ChipFuzzer shows that LLMs can reason about RTL control flow and historical bug patterns to generate RISC-V tests that lift condition coverage and bug detection beyond mutation-based hardware fuzzers.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

T0 review · grok-4.5

2026-07-14 12:29 UTC pith:ELQTNH2Z

load-bearing objection Solid dual-stage LLM fuzzer for RTL with real coverage and efficiency gains; the 21.1 pp Encarsia bug lift is real but partly prior-driven, so treat it as family-tuned rather than pure semantic magic. the 3 major comments →

arxiv 2607.10340 v1 pith:ELQTNH2Z submitted 2026-07-11 cs.AR

When Fuzzing Meets Understanding: LLM-Driven Semantic Test Generation for RTL Verification

classification cs.AR
keywords hardware fuzzingRTL verificationlarge language modelscoverage-guided testingbug-guided testingRISC-V CPUsemantic test generationcontrol-flow similarity
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

Hardware fuzzing usually mutates seeds with little understanding of what a design must do to reach a hard branch. ChipFuzzer instead asks a large language model to read uncovered RTL paths, pull the most similar prior test, and fill the missing conditions, then later steers generation toward modules and signals that have failed before. On RocketCore, BOOM, and CVA6 it raises average condition coverage by 5.8 points and Encarsia bug-detection rate by 21.1 points over the strongest prior fuzzer, and it reaches the same coverage thresholds with many fewer tests. The paper argues that semantic, history-aware test generation can push past the coverage plateaus of purely heuristic fuzzing while remaining complementary to fast early-stage mutation.

Core claim

The authors establish that a dual-stage LLM pipeline—coverage-guided generation driven by control-flow similarity and five-rule discrepancy analysis, followed by bug-guided targeting of historical bug-prone regions and semantic seed fusion—produces more effective RTL verification tests than heuristic hardware fuzzers, delivering measurable gains in condition coverage and injected-bug detection on three open-source CPUs.

What carries the argument

The dual-stage ChipFuzzer workflow: path-similarity retrieval of a seed template, structured discrepancy analysis that names the first divergence, missing branch, state preparation, trigger event, and legality constraints for the LLM, plus three historical-bug priors (instances, recurrent modules, signal confusions) fused with coverage seeds into one compilable program.

Load-bearing premise

That an LLM, given RTL or Chisel context, a similar seed, a fixed discrepancy checklist, and a 128-PR bug history, will consistently invent legal RISC-V programs that actually reach the intended hard states and that those bug priors transfer cleanly to the designs under test.

What would settle it

Run the same 24-hour budget and Encarsia 90-bug corpus on the three CPUs with a strong non-LLM baseline and with ChipFuzzer; if condition-coverage or bug-detection gains disappear, or if most LLM outputs still fail to cover the named target after five correction rounds, the central claim fails.

Watch this falsifier. Get emailed when new claim-graph text bears on it.

If this is right

  • Coverage-guided and bug-guided LLM stages can be sequenced after fast mutation fuzzers once easy states are exhausted.
  • Historical bug modules and signal patterns become reusable priors for directing new test generation.
  • Fewer, path-targeted tests can reach the same coverage thresholds that mutation-based methods reach only with thousands of seeds.
  • Syntax and semantic correctors that feed compiler and simulation feedback back to the LLM become part of a closed verification loop.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The same discrepancy-plus-prior pattern could be tried on non-CPU RTL blocks (interconnects, accelerators) once suitable seed and bug corpora exist.
  • If bug priors transfer poorly across microarchitectures, the method’s bug stage may need design-family fine-tuning rather than a single shared corpus.
  • Hybrid systems that hand hard-to-cover residual paths from a conventional fuzzer to ChipFuzzer could amortize LLM latency while keeping early throughput high.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. ChipFuzzer is an LLM-driven RTL fuzzing framework with a dual-stage workflow: a Coverage-Guided stage that retrieves control-flow-similar seed templates, applies a five-rule discrepancy analysis, and prompts an LLM to generate RISC-V testcases toward uncovered regions (with syntax/semantic correctors), and a Bug-Guided stage that uses a 128-PR historical bug corpus to prioritize bug-prone modules/signals and fuses coverage- and bug-guided seeds. On RocketCore, BOOM, and CVA6 under a 24-hour budget, the authors report average condition-coverage gains of 5.8 pp and Encarsia bug-detection gains of 21.1 pp over TheHuzz/Cascade/BMCFuzz, with supporting efficiency tables, multi-model comparison, and LO/CG/BG/CBG ablations.

Significance. If the results hold under tighter controls, the paper is a solid systems contribution to hardware verification: it moves beyond mutation heuristics by making control-flow discrepancy and historical bug priors first-class inputs to LLM test generation, and it ships a public code link plus multi-metric 24h curves, testcase-efficiency numbers (e.g., 645 vs 4k–17k tests to 75% on Rocket), multi-model comparison, and a four-way ablation. Coverage gains and the CG ablation are the most transferable evidence; the bug-finding claim is more contingent on how design-family priors interact with Encarsia. The work is of clear interest to the hardware-fuzzing and LLM-for-EDA communities even if the bug margin is partly corpus-aligned.

major comments (3)
  1. §5.1 and §5.3 / Fig. 8: The central 21.1 pp Encarsia bug-detection claim rests on historical priors from 128 open-source RISC-V PRs. The paper only asserts no bug-instance overlap with Encarsia, not independence of module/signal priors (cache/coherence/bus, valid/ready/privilege/exception). Ablations show BG alone ~38.9% vs CG alone ~5.6%, so most of the lift is attributed to those priors on the same design family Encarsia injects into. Please quantify transfer (e.g., leave-one-design-out priors, or a no-module-prior control) so the margin is not overstated as pure semantic-fuzzing advance.
  2. §4.2.3–4.2.4 and §5.2: Path-reaching success of LLM generation is load-bearing for both coverage and bug claims, yet the paper reports only final coverage/bug rates. Please report intermediate rates: fraction of LLM outputs that compile, fraction that cover the selected target after ≤5 syntax/semantic corrections, and residual failure modes (illegal CSR/privilege, wrong PLRU setup, etc.). Without these, it is hard to separate semantic reasoning from correction-loop and seed-database effects.
  3. §5.1 transition rule and free parameters: Stage I→II switches when cumulative condition-coverage gain over 100 consecutive validated tests falls below 0.1%; max correction iterations is fixed at five; S_similarity = N_common/N_target. Sensitivity of the 5.8 pp / 21.1 pp claims to these thresholds is not shown. A short sensitivity table (or fixed-budget Stage-I-only vs dual-stage) is needed to establish that the dual-stage design, not a particular cutoff, drives the reported gains.
minor comments (5)
  1. Fig. 5: Early-stage slower growth is attributed to LLM latency; please state approximate testcases/hour or wall-clock per generation so throughput vs quality is comparable to mutation baselines.
  2. §5.1: ChatFuzz is excluded for lack of public code; a short qualitative comparison of method (seed generator vs dual-stage semantic guidance) would still help position the contribution.
  3. Fig. 4 prompt and §4.2.1: Clarify how much Chisel vs Verilog is fed for Chisel designs and whether prompt length is truncated for large modules.
  4. Typos/consistency: 'CV A6' spacing, 'Difuz-zRTL' line break, and arXiv date formatting in the header.
  5. §6 limitations correctly note RISC-V CPU focus; a sentence on whether bug priors are expected to transfer to non-CPU RTL would strengthen the discussion.

Circularity Check

0 steps flagged

No significant circularity: coverage and bug rates are external measurements, not identities of fitted inputs or self-citation chains.

full rationale

ChipFuzzer is an empirical systems paper. Its load-bearing claims (5.8 pp average condition-coverage gain; 21.1 pp Encarsia bug-detection gain over BMCFuzz/Cascade/TheHuzz) are outcomes of running generated RISC-V programs on external simulators (Verilator RTL, Spike ISA) and on the external Encarsia injected-bug corpus, not algebraic rearrangements of parameters fitted to those same targets. Control-flow similarity (S_similarity = N_common / N_target), the five-rule discrepancy schema, syntax/semantic correctors, and the Stage I→II transition rule (<0.1% condition-coverage gain over 100 consecutive validated tests) are generation heuristics; success is still scored by independent coverage reports and differential RTL/ISA mismatch, so the reported numbers are not forced by construction. Historical bug priors (128 open-source RISC-V PRs; instance/module/signal strategies) are inputs that bias target selection, but Section 5.1 states the Encarsia evaluation set has no bug-instance overlap with that corpus, and detection is still counted by whether injected bugs fire under simulation—not by matching the prior labels. Ablations (LO/CG/BG/CBG) further measure each stage against the same external oracles. There is no self-definitional loop, no fitted parameter renamed as a prediction, no load-bearing uniqueness theorem imported from overlapping authors, and no ansatz smuggled in via self-citation that collapses the central claim. Concerns that design-family module/signal priors may align with Encarsia injection hotspots are validity/generalization issues, not circularity under the stated criteria. Score 0; steps empty.

Axiom & Free-Parameter Ledger

3 free parameters · 4 axioms · 3 invented entities

Central claims rest on empirical engineering assumptions (LLM RTL reasoning, transfer of historical bug patterns, coverage metrics as proxies) and a few hand-chosen control knobs (stage transition, correction budget, similarity formula), not on free physical constants or new particles. Invented entities are system modules, not ontological posits.

free parameters (3)
  • Stage I→II transition threshold = 0.1% over 100 testcases
    Hand-chosen rule: switch when cumulative condition-coverage gain over 100 consecutive validated testcases falls below 0.1%; directly controls when bug-guided stage and fusion begin.
  • Max syntax/semantic correction iterations = 5
    Cap of five repair loops per testcase; affects success rate and wall-clock budget of LLM generation.
  • Path similarity score S = N_common / N_target = node-overlap ratio
    Ad hoc path-overlap metric used to pick templates; ties broken by preferring lower-coverage seeds. Choice of metric shapes which templates the LLM rewrites.
axioms (4)
  • domain assumption Coverage metrics (condition, register-toggle, mux-toggle) and differential RTL vs ISA simulation are adequate proxies for verification progress and bug exposure.
    Standard hardware-fuzzing evaluation premise used throughout §5; does not prove functional correctness of the DUT.
  • domain assumption Foundation LLMs can infer missing architectural state and legal RISC-V sequences from RTL/Chisel snippets plus structured discrepancy rules.
    Load-bearing capability assumption in §3.3 Motivation I and §4.2 generation/correction pipeline; paper notes hallucination risk in Discussion.
  • domain assumption Historical bug-related PRs from open-source RISC-V CPUs provide transferable priors for bug-prone modules and signals on the evaluated designs.
    Underpins Stage II (§4.3.1); corpus of 128 PRs with ~20% cache-related and 85/128 signal-level mistakes is observational, not proven universal.
  • ad hoc to paper Encarsia evaluation bugs do not overlap the 128-PR historical corpus used for priors.
    Stated in §5.1 to avoid train/test contamination of bug-guided stage; correctness of the claim is author-asserted.
invented entities (3)
  • ChipFuzzer dual-stage workflow (Coverage-Guided + Bug-Guided) no independent evidence
    purpose: Organize LLM test generation first for uncovered paths, then for historically bug-prone regions with seed fusion.
    Core system architecture of the paper; evaluated empirically, not an independent physical entity.
  • Five-rule discrepancy analysis (path-alignment, branch-condition, state-preparation, event-trigger, legality) no independent evidence
    purpose: Structure what the LLM must add relative to a similar seed path to reach a target code segment.
    Author-defined prompt scaffolding in §4.2.3; success is measured only via resulting coverage.
  • Semantic-aware seed fusion of coverage-guided and bug-guided seeds no independent evidence
    purpose: Combine state-setup patterns with bug-oriented triggers into one compilable testcase.
    Introduced in §4.3.2; contribution is methodological.

pith-pipeline@v1.1.0-grok45 · 19361 in / 3538 out tokens · 38002 ms · 2026-07-14T12:29:45.331800+00:00 · methodology

0 comments
read the original abstract

The growing complexity of modern chips poses significant challenges to hardware verification. In recent years, coverage-guided fuzzing has emerged as a promising approach for improving verification efficiency. However, existing hardware fuzzers still struggle to achieve high coverage and expose corner-case bugs, as they predominantly rely on heuristic strategies with limited ability to reason about the internal logic and semantic behavior of the design under test (DUT). In this work, we propose ChipFuzzer, a hardware fuzzing framework that leverages the semantic reasoning capabilities of large language models (LLMs) to improve fuzzing effectiveness. ChipFuzzer adopts a dual-stage workflow comprising a Coverage-Guided stage and a Bug-Guided stage. In the Coverage-Guided stage, ChipFuzzer employs control-flow similarity and discrepancy analysis to guide LLM-driven testcase generation, thereby improving coverage. In the Bug-Guided stage, ChipFuzzer leverages historical bug data to identify bug-prone code regions and prioritize testcase generation for those regions, thus enhancing bug discovery efficiency. Experimental results on three open-source CPU designs show that ChipFuzzer improves average condition coverage by 5.8 percentage points and bug detection rate by 21.1 percentage points over the strongest baseline.

Figures

Figures reproduced from arXiv: 2607.10340 by Cangyuan Li, Kaiyan Chang, Kun Wang, Siyang Cai, Ying Wang, Yinhe Han.

Figure 1
Figure 1. Figure 1: Typical hardware fuzzer flow. 3.2 Large Language Models LLMs have achieved remarkable success in natural language pro￾cessing (NLP). Their applications have rapidly expanded into the field of Electronic Design Automation (EDA), demonstrating great potential in hardware code generation and verification. In the do￾main of LLM-based hardware verification, existing research pri￾marily focuses on two directions… view at source ↗
Figure 2
Figure 2. Figure 2: LLM-guided reasoning for generating testcases tar [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Overview. ChipFuzzer uses a small set of simple testcases to bootstrap the seed database. These testcases are first executed on the DUT to ob￾tain their exercised control-flow paths and initial coverage reports, and each testcase is then stored together with its control-flow path as an initial seed entry. Coverage reports collected from RTL simu￾lation are used to identify uncovered code lines in the DUT. … view at source ↗
Figure 4
Figure 4. Figure 4: Prompt template for testcase generation. [PITH_FULL_IMAGE:figures/full_fig_p004_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Coverage growth of ChipFuzzer and baseline methods under register-toggle, condition, and multiplexer-toggle cov [PITH_FULL_IMAGE:figures/full_fig_p008_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: Condition coverage comparison of different foun [PITH_FULL_IMAGE:figures/full_fig_p008_6.png] view at source ↗
Figure 8
Figure 8. Figure 8: Bugs detected by baseline fuzzers, ChipFuzzer [PITH_FULL_IMAGE:figures/full_fig_p009_8.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

39 extracted references · 2 linked inside Pith

  1. [1]

    Patterson, Brian Richards, Colin Schmidt, Stephen Twigg, Huy Vo, and Andrew Waterman

    Krste Asanović, Rimas Avizienis, Jonathan Bachrach, Scott Beamer, David Bian- colin, Christopher Celio, Henry Cook, Daniel Dabbelt, John Hauser, Adam Izraelevitz, Sagar Karandikar, Ben Keller, Donggyu Kim, John Koenig, Yunsup Lee, Eric Love, Martin Maas, Albert Magyar, Howard Mao, Miquel Moreto, Al- bert Ou, David A. Patterson, Brian Richards, Colin Schmi...

  2. [2]

    Jonathan Bachrach, Huy Vo, Brian Richards, Yunsup Lee, Andrew Waterman, Rimas Avižienis, John Wawrzynek, and Krste Asanović. 2012. Chisel: construct- ing hardware in a scala embedded language. In Proceedings of the 49th annual design automation conference. 1216–1225

  3. [3]

    Matej Bölcskei, Flavien Solt, Katharina Ceesay-Seitz, and Kaveh Razavi. 2025. Encarsia: Evaluating cpu fuzzers via automatic bug injection. In 34th USENIX Security

  4. [4]

    Patterson, and Krste Asanović

    Christopher Celio, David A. Patterson, and Krste Asanović. 2015. The Berke- ley Out-of-Order Machine (BOOM): An Industry-Competitive, Synthesizable, Pa- rameterized RISC-V Processor . Technical Report UCB/EECS-2015-167. http: //www2.eecs.berkeley.edu/Pubs/TechRpts/2015/EECS-2015-167.html

  5. [5]

    Chen Chen, Vasudev Gohil, Rahul Kande, Ahmad-Reza Sadeghi, and Jeyavijayan Rajendran. 2023. PSOFuzz: Fuzzing processors with particle swarm optimiza- tion. In 2023 IEEE/ACM International Conference on Computer Aided Design (IC- CAD). IEEE, 1–9

  6. [6]

    Chen Chen, Rahul Kande, Nathan Nguyen, Flemming Andersen, Aakash Tyagi, Ahmad-Reza Sadeghi, and Jeyavijayan Rajendran. 2023. {HyPFuzz}:{Formal- Assisted} processor fuzzing. In 32nd USENIX Security Symposium (USENIX Se- curity 23). 1361–1378

  7. [7]

    Edmund M Clarke, Thomas A Henzinger, Helmut Veith, Roderick Bloem, et al

  8. [8]

    Handbook of model checking . Vol. 10. Springer

  9. [9]

    David Cyrluk, Sreeranga Rajan, Natarajan Shankar, and Mandayam K Srivas

  10. [10]

    In International Con- ference on Theorem Provers in Circuit Design

    Effective theorem proving for hardware verification. In International Con- ference on Theorem Provers in Circuit Design . Springer, 203–222

  11. [11]

    Yinlin Deng, Chunqiu Steven Xia, Chenyuan Yang, Shizhuo Dylan Zhang, Shujing Yang, and Lingming Zhang. 2023. Large language models are edge- case fuzzers: Testing deep learning libraries via fuzzgpt. arXiv preprint arXiv:2304.02014 (2023)

  12. [12]

    Farimah Farahmandi, Yuanwen Huang, and Prabhat Mishra. 2020. System-on- chip security. Cham, Switzerland: Springer (2020)

  13. [13]

    Vasudev Gohil, Rahul Kande, Chen Chen, Ahmad-Reza Sadeghi, and Jeyavijayan Rajendran. 2024. MABFuzz: Multi-armed bandit algorithms for fuzzing proces- sors. In 2024 Design, Automation & Test in Europe Conference & Exhibition (DATE). IEEE, 1–6

  14. [14]

    Christian Holler, Kim Herzig, and Andreas Zeller. 2012. Fuzzing with code frag- ments. In 21st USENIX Security Symposium (USENIX Security 12) . 445–458

  15. [15]

    Wei Hu, Armaiti Ardeshiricham, and Ryan Kastner. 2021. Hardware information flow tracking. ACM Computing Surveys (CSUR) 54, 4 (2021), 1–39

  16. [16]

    Jaewon Hur, Suhwan Song, Dongup Kwon, Eunjin Baek, Jangwoo Kim, and By- oungyoung Lee. 2021. Difuzzrtl: Differential fuzz testing to find cpu bugs. In 2021 IEEE Symposium on Security and Privacy (SP) . IEEE, 1286–1303

  17. [17]

    Rahul Kande, Addison Crump, Garrett Persyn, Patrick Jauernig, Ahmad-Reza Sadeghi, Aakash Tyagi, and Jeyavijayan Rajendran. 2022. {TheHuzz}: In- struction fuzzing of processors using {Golden-Reference} models for find- ing {Software-Exploitable} vulnerabilities. In 31st USENIX Security Symposium (USENIX Security 22) . 3219–3236

  18. [18]

    Minwoo Kang, Mingjie Liu, Ghaith Bany Hamad, Syed M Suhaib, and Haoxing Ren. 2025. Fveval: Understanding language model capabilities in formal verifica- tion of digital hardware. In 2025 Design, Automation & Test in Europe Conference (DATE). IEEE, 1–6

  19. [19]

    Kevin Laeufer, Jack Koenig, Donggyu Kim, Jonathan Bachrach, and Koushik Sen. 2018. RFUZZ: Coverage-directed fuzz testing of RTL on FPGAs. In 2018 IEEE/ACM International Conference on Computer-Aided Design (ICCAD) . IEEE, 1–8

  20. [20]

    Ruiyang Ma, Yuxin Yang, Ziqian Liu, Jiaxi Zhang, Min Li, Junhua Huang, and Guojie Luo. 2024. Verilogreader: Llm-aided hardware test generation. In 2024 IEEE LLM Aided Design Workshop (LAD) . IEEE, 1–5

  21. [21]

    Yehuda Naveh, Michal Rimon, Itai Jaeger, Yoav Katz, Michael Vinov, Eitan s Marcu, and Gil Shurek. 2007. Constraint-based random stimuli generation for hardware verification. AI magazine 28, 3 (2007), 13–13

  22. [22]

    Soyeon Park, Wen Xu, Insu Yun, Daehee Jang, and Taesoo Kim. 2020. Fuzzing javascript engines with aspect-preserving mutation. In 2020 IEEE Symposium on Security and Privacy (SP) . IEEE, 1629–1642

  23. [23]

    Ruidi Qiu, Grace Li Zhang, Rolf Drechsler, Ulf Schlichtmann, and Bing Li. 2024. Autobench: Automatic testbench generation and evaluation using llms for hdl design. In Proceedings of the 2024 ACM/IEEE International Symposium on Ma- chine Learning for CAD . 1–10

  24. [24]

    Ruidi Qiu, Grace Li Zhang, Rolf Drechsler, Ulf Schlichtmann, and Bing Li. 2025. Correctbench: Automatic testbench generation with functional self-correction using llms for hdl design. In 2025 Design, Automation & Test in Europe Conference (DATE). IEEE, 1–7

  25. [25]

    Riscv-Software-Src. 2025. Riscv-isa-sim: Spike, a risc-v isa simulator. https: //github.com/riscv-software-src/riscv-isa-sim. Accessed: 2025-11-14

  26. [26]

    Mohamadreza Rostami, Marco Chilese, Shaza Zeitouni, Rahul Kande, Jeyavi- jayan Rajendran, and Ahmad-Reza Sadeghi. 2024. Beyond random inputs: A novel ML-based hardware fuzzing. In 2024 Design, Automation & Test in Europe Conference & Exhibition (DATE). IEEE, 1–6

  27. [27]

    Raghul Saravanan and Sai Manoj Pudukotai Dinakarrao. 2024. The emer- gence of hardware fuzzing: A critical review of its significance. arXiv preprint arXiv:2403.12812 (2024)

  28. [28]

    Shidong Shen, Jinyu Liu, Weizhi Feng, Fu Song, and Zhilin Wu. 2025. BMCFuzz: Hybrid Verification of Processors by Synergistic Integration of Bound Model Checking and Fuzzing. In 2025 IEEE/ACM International Conference On Computer Aided Design (ICCAD). IEEE, 1–9

  29. [29]

    Wilson Snyder. 2025. Verilator. https://github.com/verilator/verilator.git Ac- cessed: 2025-11-14

  30. [30]

    Flavien Solt, Katharina Ceesay-Seitz, and Kaveh Razavi. 2024. Cascade: {CPU} fuzzing via intricate program generation. In 33rd USENIX Security Symposium (USENIX Security 24) . 5341–5358

  31. [31]

    Shinya Takamaeda-Yamazaki. 2015. Pyverilog: A python-based hardware de- sign processing toolkit for verilog hdl. In Applied Reconfigurable Computing: 11th International Symposium, ARC 2015, Bochum, Germany, April 13-17, 2015, Proceedings 11. Springer, 451–460

  32. [32]

    Timothy Trippel, Kang G Shin, Alex Chernyakhovsky, Garret Kelly, Dominic Rizzo, and Matthew Hicks. 2022. Fuzzing hardware like software. In31st USENIX Security Symposium (USENIX Security 22) . 3237–3254

  33. [33]

    Yonghao Wang, Jiaxin Zhou, Hongqin Lyu, Zhiteng Chao, Tiancheng Wang, and Huawei Li. 2025. DeepAssert: An LLM-Aided Verification Framework with Wang et al. Fine-Grained Assertion Generation for Modules with Extracted Module Specifi- cations. arXiv preprint arXiv:2509.14668 (2025)

  34. [34]

    Yinan Xu, Sa Wang, Dan Tang, Ninghui Sun, and Yungang Bao. 2024. Pathfuzz: Broadening fuzzing horizons with footprint memory for CPUs. In Proceedings of the 61st ACM/IEEE Design Automation Conference . 1–6

  35. [35]

    Zhiyuan Yan, Wenji Fang, Mengming Li, Min Li, Shang Liu, Zhiyao Xie, and Hongce Zhang. 2025. Assertllm: Generating hardware verification assertions from design specifications via multi-llms. In Proceedings of the 30th Asia and South Pacific Design Automation Conference . 614–621

  36. [36]

    Florian Zaruba and Luca Benini. 2019. The cost of application-class processing: Energy and performance analysis of a Linux-ready 1.7-GHz 64-bit RISC-V core in 22-nm FDSOI technology. IEEE Transactions on Very Large Scale Integration (VLSI) Systems 27, 11 (2019), 2629–2640

  37. [37]

    Zixi Zhang, Balint Szekely, Pedro Gimenes, Greg Chadwick, Hugo McNally, Jianyi Cheng, Robert Mullins, and Yiren Zhao. 2025. Llm4dv: Using large lan- guage models for hardware test stimuli generation. In 2025 IEEE 33rd Annual International Symposium on Field-Programmable Custom Computing Machines (FCCM). IEEE, 133–137

  38. [38]

    Yujie Zhao, Zhijing Wu, Hejia Zhang, Zhongming Yu, Wentao Ni, Chia-Tung Ho, Haoxing Ren, and Jishen Zhao. 2025. PRO-V: An Efficient Program Gen- eration Multi-Agent System for Automatic RTL Verification. arXiv preprint arXiv:2506.12200 (2025)

  39. [39]

    Hao Zhong. 2022. Enriching compiler testing with real program from bug re- port. In Proceedings of the 37th IEEE/ACM International conference on automated software engineering. 1–12