Pith. sign in

REVIEW 3 major objections 4 minor 39 references

HLSTester: Efficient Testing of Behavioral Discrepancies with LLMs for High-Level Synthesis

T0 review · 3 major / 4 minor · reviewed 2026-08-16 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read An LLM-guided framework detects HLS behavioral mismatches up to 2.71x faster while raising testbench pass rates by about 20.67%.

desk verdict A sensible integration of LLM-based HLS testbench adaptation, backward slicing, and mutation for discrepancy testing, but the headline speedups rest on an unproven redundancy-filter assumption. read the letter →

arxiv 2504.14641 v3 pith:KDO3O6PW submitted 2025-04-20 cs.SE cs.SYeess.SY

Kangwei Xu , Bing Li , Grace Li Zhang , Ulf Schlichtmann This is my paper · ORCID
classification cs.SEcs.SYeess.SY
keywords high-levelsynthesisbehavioraldiscrepancytestingLLM-aidedverificationtestbenchgenerationruntimespectradynamicmutationredundancy-awarefilteringFPGA
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

HLSTester is a testing workflow that uses a large language model to adapt existing C/C++ testbenches into HLS-compatible versions, instruments key variables selected by backward slicing, records their runtime spectra, generates new test inputs through dynamic mutation steered by an LLM reasoning chain, and skips hardware simulations it deems redundant. The paper claims this pipeline detects behavioral discrepancies between original C programs and FPGA circuits produced by high-level synthesis faster and more reliably than both direct LLM use and traditional fuzz testing. Concretely, it reports an average 2.71x total speedup, an average 20.67 percentage-point gain in testbench simulation pass rate, and more detected discrepancies within the same time budget across ten benchmark tasks. A sympathetic reader should care because this is the part of the HLS flow that currently demands manual hardware-software expertise, and the paper is arguing that it can be largely automated.

What carries the argument

The load-bearing object is the runtime spectrum of key variables, defined as the tuple of variable value range, array access offsets, loop iteration counts, static stack usage, and FIFO queue sizes recorded from instrumented code. Backward slicing from a mismatched output identifies which variables to instrument; the monitored spectra feed two loops: a dynamic-mutation loop that increases the activation probability of mutation types that produce new spectral extremes, and a redundancy filter that skips hardware simulation when a new input's value range and data size stay within recorded bounds. An LLM progressive reasoning chain splits analysis into code, statement, and directive levels to generate targeted inputs. Together these mechanisms convert a one-shot testbench-writing task into a feedback loop in which each hardware simulation is expected to expand the observed behavior space.

What would settle it

Take a benchmark program with a division or array access, run HLSTester until it records a min/max range and size for some input, then feed it a permutation of that same input that preserves the global min, max, and size but places a large value immediately before the divisor or at a boundary index. If the C and RTL spectra differ for the permuted input while the filter would have skipped its hardware simulation, the redundancy assumption is refuted.

Watch

Extended reading notes

Core claim

The central claim is that behavioral discrepancy testing for HLS can be made fast enough for routine use by combining an LLM with program-analysis feedback rather than relying on either alone. On its own terms, HLSTester states that its RAG-guided testbench modification raises the HLS simulation pass rate by an average of 20.67% over asking an LLM directly; that its instrumentation pass rates improve by 25.33% for HLS code and 18.67% for C/C++ code; that LLM-guided reasoning gives a 1.81x speedup in detecting all discrepancies, dynamic mutation raises that to 2.28x, and redundancy-aware filtering adds a further 15.73% acceleration; and that the full pipeline finishes the ten benchmark tasks in 27.88% to 72.23% less total time than baselines, with an average 2.71x speedup.

Load-bearing premise

The paper's time savings depend on the assumption that a test input whose value range and data size stay within previously recorded bounds cannot trigger a new behavioral discrepancy; this is not proven, since inputs with the same global min/max and size can differ in ordering or intermediate values and could still overflow, divide by zero, or access out of bounds.

Editorial extensions

If this is right

  • Testbench conversion for HLS can be treated as an LLM task grounded in retrieved synthesis rules, with pass rates of roughly 80-100% on the ten benchmarks versus lower rates for direct LLM generation.
  • Behavioral discrepancies such as custom-bit-width overflow, out-of-bounds static-array access, and pipeline-induced ordering differences can be detected in a few minutes to about two hours per benchmark instead of several hours.
  • Mutation types that expand monitored spectra extremes become more likely to fire, so test-input generation adapts to the program under test without manual tuning.
  • Skipping hardware simulations for inputs whose range and size are already covered is claimed to be safe and to contribute a 15.73% workflow acceleration on top of the mutation and reasoning speedups.
  • With the same time budget, HLSTester reports detecting roughly 5-9 discrepancies across the ten tasks, compared with 1-2 for traditional fuzz testing.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The redundancy filter's skip decisions are testable: permuting a recorded input while preserving its global min, max, and size and checking whether C and RTL spectra still match would reveal whether inputs with identical bounds can still trigger new discrepancies.
  • The probability update only rewards mutations that expand spectral extremes, so mutations that expose a discrepancy without expanding a range would never be reinforced; the reported speedups may therefore depend on how well discrepancy-triggering inputs correlate with extreme-value expansion.
  • Because all ten benchmarks share the same HLS tool and one LLM, the 20.67% pass-rate gain and 2.71x speedup are not yet evidence about portability to other synthesis tools, directive sets, or LLMs; re-running the workflow on another toolchain would test that.
  • The framework's pass rate measures simulation success of generated testbenches and instrumented code, not the rate of finding real bugs; a next step would be to measure precision of the reported discrepancy symptoms against known injected defects.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 4 minor

Summary. The paper proposes HLSTester, an LLM-aided framework for testing behavioral discrepancies between original C/C++ programs and circuits produced by high-level synthesis (HLS). The framework has five stages: modifying C/C++ testbenches into HLS-compatible form using an LLM with retrieval-augmented guidance; instrumenting key variables selected by backward slicing; monitoring runtime spectra in both C and RTL simulation; generating test inputs through dynamically prioritized mutation combined with LLM-guided reasoning; and skipping supposedly redundant hardware simulations via a filter based on recorded input value ranges and data sizes. The evaluation uses ten benchmark tasks with the GPT-4o model and Vitis HLS, repeating each experiment 15 times. The paper reports average improvements of 20.67 percentage points in testbench pass rate, higher instrumentation pass rates, more detected discrepancies within a fixed time budget, and an average 2.71x total speedup, of which 15.73% is attributed to redundancy-aware filtering.

Significance. If the reported results hold, HLSTester would be a useful practical contribution to HLS verification: it addresses a real pain point, namely the human effort and long simulation times involved in checking behavioral equivalence between software and synthesized hardware. The evaluation has genuine strengths: pass-rate results are based on actual HLS compilation and simulation outcomes, the experiments use an external industrial tool (Vitis HLS), the benchmark set spans several hardware-directive categories, and ablation variants are used to isolate components. The paper's central weakness is that the speedup claims rest on the redundancy filter's monotonicity assumption, which is neither proved nor empirically validated, so the headline acceleration figures are not yet trustworthy.

major comments (3)
  1. [Section III-D, Fig. 7, Fig. 9, Fig. 13] The redundancy-aware filter assumes that a test input whose value range and data size lie within previously recorded bounds 'will not trigger new discrepancies' and can therefore skip hardware simulation. This monotonicity assumption is not established, and the paper itself lists mechanisms that violate it: Table II includes Order Mutation (T4), which rearranges elements while preserving range and size, and Table I includes pipeline and dataflow discrepancies in which execution order, alignment, and intermediate values matter. For example, [1,3,5] and [5,1,3] have the same min, max, and size, but an accumulator or feedback-path variable can behave differently on the two inputs. Because skipped inputs may be exactly the ones that reveal new discrepancies, the reported 15.73% filtering speedup and the overall 2.71x speedup are not yet validated, and the cumulative discrepancy curves in Fig. 9 may be undercounted. The authors should either prove the monotonicity property for the discrepancy classes under test or empirically validate it by running the full simulation on all generated inputs and reporting how many filtered inputs would have triggered a new discrepancy.
  2. [Section IV, Table III, Figs. 10-13] All headline comparisons are reported as point estimates from n=15 runs with no confidence intervals, standard deviations, or significance tests. Several pass-rate improvements are only 13.33 or 20 percentage points, which with n=15 is not convincingly significant: for instance, a 13.33-point improvement could arise from two or three additional successful instances. The total-time speedups in Table III and Fig. 13 are likewise reported without variance, so the 2.71x average has no stated uncertainty. The authors should report per-instance data or at least confidence intervals for pass rates and times, and perform a statistical test (e.g., a paired test across the 15 runs) for the key comparisons. This is required for the 'significantly accelerates' claim to be supported by the evidence.
  3. [Section III-C, Eq. (4), Fig. 9] The dynamic mutation mechanism depends on the update factor alpha=0.04, the 30% ratio of LLM-guided inputs, and the five LLM correction queries per instance, but no sensitivity analysis is reported. The speedups attributed to dynamic mutation (1.81x and 2.28x) and the comparison curves in Fig. 9 are conditional on these specific values. A small ablation or sensitivity study over alpha and the LLM-input ratio would show whether the reported acceleration is robust or tuned to the chosen parameters.
minor comments (4)
  1. [Table II and Section III-C.1] The text says 'mutation type T7 is activated, producing a new test input (ID3: [1, 4, 7, 8])', but Table II lists ID3 as mutation T1 with input [9,1,4,7,8] and ID2 as T7 with input [1,4,7,8]; the text and table should be aligned.
  2. [Table III, columns 8-10] The heading 'Base. Fuzz Prop.' is ambiguous; it should clearly state that the three columns are the GPT baseline, the traditional fuzz method, and the proposed method.
  3. [Section IV, general] The description of the 15 repeated instances is terse: it is not stated whether these are independent reruns with different random seeds, whether the same five LLM queries are reused, or whether the pass rates are aggregated over reruns or over benchmark tasks. Clarifying this would help readers interpret the reported averages.
  4. [Section III-D, running example] In the filtering example, the text states that the recorded input range (2,5) is updated to (1,5) after seeing [1,4,5], but it does not specify how the data-size bound is updated in the same example; a consistent example including size would make the filter rule easier to follow.

Circularity Check

1 steps flagged · score 3.0 of 10

Redundancy-aware filter defines 'will not trigger new discrepancies' by its own range/size criterion, making part of the reported speedup self-referential.

  1. self definitional [Section III-D, 'Redundancy Filtering of Test Inputs for Efficient Testing']
    "If the test input remains within the previously recorded range, it implies that the test input will not trigger new discrepancies, and simulation is skipped."

    The filter defines the predicate 'will not trigger new discrepancies' as equivalent to 'value range and data size stay within the recorded bounds.' Thus, by construction, any input satisfying that containment condition is classed as redundant, and the time saved by skipping it is counted as acceleration. The soundness of that equivalence—that global min/max and size alone determine whether new HLS behavioral discrepancies can appear—is assumed, not tested. The paper itself lists order mutation and pipeline/dataflow discrepancies where ordering and intermediate values matter, so inputs such as [1,3,5] and [5,1,3] can be classified as equivalent even though they may exercise different feedback paths.

full rationale

Most of HLSTester's reported results are externally grounded: testbench simulation pass rates, instrumented-code pass rates, and detected discrepancy counts come from actual HLS tool compilation and simulation, compared against GPT and fuzz baselines. The backward-slicing instrumentation, RAG-based testbench repair, and spectra-guided mutation are standard or empirically evaluated mechanisms, not predictions that reduce to their own definitions by construction. The self-citations in the reference list appear as benchmark and prior-work context, not as load-bearing uniqueness or derivation steps. The one genuinely self-referential element is the redundancy-aware filter: it defines 'redundant' as 'within the recorded value range and data size' and then uses that same definition to justify skipping simulations and to claim acceleration. This makes the filter's speedup contribution partially circular because the key premise—that no new discrepancy can arise without a change in global min/max or size—is assumed by the filter itself and not independently demonstrated. The paper's own Table I includes pipeline and dataflow discrepancies where order and intermediate states matter, so the assumption is not merely a minor technicality. Therefore the overall circularity score is moderate: the central pass-rate and discrepancy-detection comparisons are independent, but a portion of the headline speedup rests on a self-defined skip rule.

Assumptions & free parameters 3 free parameters · 4 assumptions · 0 invented entities

The paper introduces no new physical or mathematical entities. The framework's behavior rests on a handful of software engineering choices: the mutation probability update factor, the fraction of LLM-generated inputs, and the redundancy filter's monotonicity assumption, the last of which is load-bearing for the speedup claims. The evaluation also assumes that the benchmarks have known, countable discrepancy sets from prior work and that spectra extremes correlate with discrepancy-triggering behavior.

free parameters (3)
  • mutation probability update factor alpha = 0.04
    Set by hand in Section III-C1; controls how quickly successful mutation types are reinforced, no sensitivity analysis is provided.
  • LLM-guided test input ratio = 30%
    In Section III-C, '30% of test inputs are generated by the LLM'; chosen by hand without ablation across ratios.
  • number of LLM correction queries per instance = 5
    Experimental setup in Section IV; arbitrary and not varied in the evaluation.
assumptions (4)
  • ad hoc to paper Redundancy filtering monotonicity: test inputs with value range and data size within previously recorded bounds will not trigger new discrepancies.
    Assumed in Section III-D and load-bearing for the speedup claims.
  • domain assumption Spectra extremes correlate with behavioral discrepancies.
    The dynamic mutation and filtering rely on monitoring spectra extremes as the signal for discrepancy-triggering inputs (Sections III-B and III-C).
  • domain assumption Benchmark discrepancies are known and countable.
    The evaluation reports time to detect 'all discrepancies' per benchmark, implying a ground truth from prior work [31] to [34] that is not enumerated in this paper.
  • domain assumption GPT-4o outputs are stable enough for repeated measurements.
    All results use n=15 repeated instances of a non-deterministic API, with no account of variance.

how reviews work

0 comments
Cite this review

Pith. "Pith review of HLSTester: Efficient Testing of Behavioral Discrepancies with LLMs for High-Level Synthesis." pith.science (2026). https://pith.science/paper/KDO3O6PW

@misc{pith2026250414641,
  author       = {Pith},
  title        = {Pith review of: HLSTester: Efficient Testing of Behavioral Discrepancies with LLMs for High-Level Synthesis},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/KDO3O6PW}},
  note         = {Machine review of arXiv:2504.14641}
}
read the original abstract

In high-level synthesis (HLS), C/C++ programs with synthesis directives are used to generate circuits for FPGA implementations. However, hardware-specific and platform-dependent characteristics in these implementations can introduce behavioral discrepancies between the original C/C++ programs and the circuits after high-level synthesis. Existing methods for testing behavioral discrepancies in HLS are still immature, and the testing workflow requires significant human efforts. To address this challenge, we propose HLSTester, a large language model (LLM) aided testing framework that efficiently detects behavioral discrepancies in HLS. To mitigate hallucinations in LLMs and enhance prompt quality, the testbenches for original C/C++ programs are leveraged to guide LLMs in generating HLS-compatible testbenches, effectively eliminating certain traditional C/C++ constructs that are incompatible with HLS tools. Key variables are pinpointed through a backward slicing technique in both C/C++ and HLS programs to monitor their runtime spectra, enabling an in-depth analysis of the discrepancy symptoms. To reduce test time, a testing input generation mechanism is introduced to integrate dynamic mutation with insights from an LLM-based progressive reasoning chain. In addition, repetitive hardware testing is skipped by a redundancy-aware filtering technique for the generated test inputs. Experimental results demonstrate that the proposed LLM-aided testing framework significantly accelerates the testing workflow while achieving higher testbench simulation pass rates compared with the traditional method and the direct use of LLMs on the same HLS programs.

Figures

Figures reproduced from arXiv: 2504.14641 by the authors.

Figure 1
Figure 1. Traditional workflow for testing behavioral discrepancies in HLS. [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 3
Figure 3. Testing Workflow of the proposed HLSTester. [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗
Figure 5
Figure 5. Using backward slicing to pinpoint key variables in the HLS program. [PITH_FULL_IMAGE:figures/full_fig_p004_5.png] view at source ↗
Figures from the paper (6 more)
Figure 7
Figure 7. Figure 7: Multi-dimensional test input generation and redundancy-aware filtering. [PITH_FULL_IMAGE:figures/full_fig_p005_7.png]
Figure 8
Figure 8. Figure 8: LLM-aided reasoning chain for progressive behavioral discrepancy [PITH_FULL_IMAGE:figures/full_fig_p006_8.png]
Figure 9
Figure 9. Figure 9: Comparison of the number of behavioral discrepancies detected within the same time budget across ten tasks, as shown on the x-axes of the figures. [PITH_FULL_IMAGE:figures/full_fig_p007_9.png]
Figure 10
Figure 10. Figure 10: Comparison of the simulation pass rate of the modified HLS testbench [PITH_FULL_IMAGE:figures/full_fig_p007_10.png]
Figure 11
Figure 11. Figure 11: Comparison of the simulation pass rate of the instrumented HLS code [PITH_FULL_IMAGE:figures/full_fig_p008_11.png]
Figure 12
Figure 12. Figure 12: Comparison of the pass rate for instrumented C++ code between the [PITH_FULL_IMAGE:figures/full_fig_p008_12.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

39 extracted references · 35 canonical work pages

  1. [1]

    Machine Learning in Advanced IC Design: A Methodological Survey,

    Tinghuan Chen, Grace Li Zhang, Bei Yu, Bing Li, Ulf Schlichtmann, “Machine Learning in Advanced IC Design: A Methodological Survey,” IEEE Design & Test, 2023

    2023

  2. [2]

    High-Level Synthesis for FPGAs: From Prototyping to Deployment,

    Jason Cong, Bin Liu, Stephen Neuendorffer, Juanjo Noguera, Kees Vissers, Zhiru Zhang, “High-Level Synthesis for FPGAs: From Prototyping to Deployment,” IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems (TCAD), 2011

    work page 2011

  3. [3]

    CPU-FPGA Coscheduling for Big Data Applications,

    Jason Cong, Zhenman Fang, Di Wu,et al., “CPU-FPGA Coscheduling for Big Data Applications,” IEEE Design & Test, 2017

    work page 2017

  4. [4]

    FPGA/DNN Co-Design: An Efficient Design Methodology for IoT Intelligence on the Edge,

    Cong Callie Hao, Xiaofan Zhang, Yuhong Li, Sitao Huang, Jinjun Xiong, Kyle Rupnow, Wen-mei Hwu, Deming Chen, “FPGA/DNN Co-Design: An Efficient Design Methodology for IoT Intelligence on the Edge,” IEEE/ACM Design Automation Conference (DAC), 2019

    work page 2019

  5. [5]

    Correlated Multi-objective Multi-fidelity Optimization for HLS Directives Design,

    Qi Sun, Tinghuan Chen, Siting Liu, Jianli Chen, Hao Yu, and Bei Yu, “Correlated Multi-objective Multi-fidelity Optimization for HLS Directives Design,” ACM Transactions on Design Automation of Electronic Systems (TODAES), 2022

    work page 2022

  6. [6]

    RapidStream: Parallel Physical Implementation of FPGA HLS Designs,

    Licheng Guo, Pongstorn Maidee, Yun Zhou, Chris Lavin, Jie Wang, Yuze Chi, Weikang Qiao, Alireza Kaviani, Zhiru Zhang, Jason Cong, “RapidStream: Parallel Physical Implementation of FPGA HLS Designs,” ACM International Symposium on Field-Programmable Gate Arrays, 2022

    work page 2022

  7. [7]

    Refactoring for Heterogeneous Computing with FPGA,

    Jason Lau, Aishwarya Sivaraman, Qian Zhang, Muhammad Ali Gulzar, Jason Cong, Miryung Kim, “Refactoring for Heterogeneous Computing with FPGA,” International Conference on Software Engineering, 2020

    work page 2020

  8. [8]

    Vitis High-Level Synthesis User Guide,

    “Vitis High-Level Synthesis User Guide,” Accessed: 2024. [Online]. Avail- able: https://docs.amd.com/r/2024.2-English/ug1399-vitis-hls/

    work page 2024

Show all 39 references
  1. [9]

    Border Control: Sandboxing Accelerators,

    Lena E. Olson, Jason Power, Mark D. Hill, and David A. Wood, “Border Control: Sandboxing Accelerators,” IEEE/ACM MICRO, 2015

    2015

  2. [10]

    Mu-grind: A Framework for Dynamically Instrumenting HLS- Generated RTL,

    Parmida Vahdatniya, Amirali Sharifian, Reza Hojabr, Arrvindh Shri- raman, “Mu-grind: A Framework for Dynamically Instrumenting HLS- Generated RTL,” ACM International Conference on Parallel Architectures and Compilation Techniques, 2022

    2022

  3. [11]

    American Fuzzy Lop (AFL),

    Michal Zalewski, “American Fuzzy Lop (AFL),” Accessed: 2024. [On- line]. Available: https://lcamtuf.coredump.cx/afl/

    2024

  4. [12]

    The Art, Science, and Engi- neering of Fuzzing,

    Valentin Manes, HyungSeok Han, Choongwoo Han, sang cha, Manuel Egele, Edward Schwartz, Maverick Woo, “The Art, Science, and Engi- neering of Fuzzing,” IEEE Transactions on Software Engineering, 2019

    2019

  5. [13]

    HAsim: FPGA-based high-detail multicore simulation using time-division multiplexing,

    Michael Pellauer, Michael Adler, Michel Kinsy, Angshuman Parashar, Joel Emer, “HAsim: FPGA-based high-detail multicore simulation using time-division multiplexing,” IEEE/ACM International Symposium on High Performance Computer Architecture (HPCA), 2011

    2011

  6. [14]

    New solutions on LLM acceleration, optimization, and application,

    Yingbing Huang, Lily Jiaxin Wan, Hanchen Ye, Manvi Jha, Jinghua Wang, Yuhong Li, Xiaofan Zhang, Deming Chen, “New solutions on LLM acceleration, optimization, and application,” IEEE/ACM Design Automation Conference (DAC), 2024

    2024

  7. [15]

    GPT4AIGChip: Towards Next- Generation AI Accelerator Design Automation via Large Language Mod- els,

    Yonggan Fu, Yingyan Lin,et al., “GPT4AIGChip: Towards Next- Generation AI Accelerator Design Automation via Large Language Mod- els,” International Conference on Computer Aided Design, 2023

    2023

  8. [16]

    A Survey of Circuit Foundation Model: Foundation AI Models for VLSI Circuit Design and EDA,

    Wenji Fang, Jing Wang, Yao Lu, Shang Liu, Yuchao Wu, Yuzhe Ma, Zhiyao Xie, “A Survey of Circuit Foundation Model: Foundation AI Models for VLSI Circuit Design and EDA,” arXiv: 2504.03711, 2025

    2025 arXiv

  9. [17]

    Large Language Models for Verification, Testing, and Design,

    Chandan Kumar Jha, Muhammad Hassan, Khushboo Qayyum, Sallar Ahmadi-Pour, Kangwei Xu, Ruidi Qiu, Jason Blocklove, Luca Collini, Andre Nakkab, Ulf Schlichtmann, Grace Li Zhang, Ramesh Karri, Bing Li, Siddharth Garg, Rolf Drechsler, “Large Language Models for Verification, Testin...

    2025

  10. [18]

    VRank: Enhancing Verilog Code Generation from Large Language Models via Self-Consistency,

    Zhuorui Zhao, Ruidi Qiu, Ing-Chao Lin, Grace Li Zhang, Bing Li, Ulf Schlichtmann, “VRank: Enhancing Verilog Code Generation from Large Language Models via Self-Consistency,” ACM/IEEE International Symposium on Quality Electronic Design (ISQED), 2025

    2025

  11. [19]

    LLM-Aided Efficient Hardware Design Automation,

    Kangwei Xu, Ruidi Qiu, Zhuorui Zhao, Grace Li Zhang, Ulf Schlicht- mann, Bing Li, “LLM-Aided Efficient Hardware Design Automation,” arXiv preprint: 2410.18582, 2024

    2024 arXiv

  12. [20]

    Basis Sharing: Cross-Layer Parameter Sharing for Large Language Model Compression,

    Jingcun Wang, Yu-Guang Chen, Ing-Chao Lin, Bing Li, Grace Li Zhang, “Basis Sharing: Cross-Layer Parameter Sharing for Large Language Model Compression,” International Conference on Learning Representa- tions (ICLR), 2025

    2025

  13. [21]

    AutoBench: Automatic Testbench Generation and Evaluation Using LLMs for HDL Design,

    Ruidi Qiu, Grace Li Zhang, Rolf Drechsler, Ulf Schlichtmann, Bing Li, “AutoBench: Automatic Testbench Generation and Evaluation Using LLMs for HDL Design,” ACM/IEEE International Symposium on Machine Learning for Computer-Aided Design (MLCAD), 2024

    2024

  14. [22]

    Paradigm-Based Automatic HDL Code Generation Using LLMs,

    Wenhao Sun, Bing Li, Grace Li Zhang, Xunzhao Yin, Cheng Zhuo, Ulf Schlichtmann, “Paradigm-Based Automatic HDL Code Generation Using LLMs,” International Symposium on Quality Electronic Design, 2025

    2025

  15. [23]

    CITYW ALK: Enhancing LLM- Based C++ Unit Test Generation via Project-Dependency Awareness and Language-Specific Knowledge,

    Yuwei Zhang, Qingyuan Lu, Kai Liu, Wensheng Dou, Jiaxin Zhu, Li Qian, Chunxi Zhang, Zheng Lin, Jun Wei, “CITYW ALK: Enhancing LLM- Based C++ Unit Test Generation via Project-Dependency Awareness and Language-Specific Knowledge,” arXiv preprint: 2501.16155, 2025

    2025 arXiv

  16. [24]

    CorrectBench: Automatic Testbench Generation with Functional Self- Correction using LLMs for HDL Design,

    Ruidi Qiu, Grace Li Zhang, Rolf Drechsler, Ulf Schlichtmann, Bing Li, “CorrectBench: Automatic Testbench Generation with Functional Self- Correction using LLMs for HDL Design,” IEEE/ACM Design, Automation & Test in Europe Conference & Exhibition (DATE), 2025

    2025

  17. [25]

    HTransformations of High-Level Synthesis Codes for High-Performance Computing,

    Johannes de Fine Licht, Torsten Hoefler,et al., “HTransformations of High-Level Synthesis Codes for High-Performance Computing,” IEEE Transactions on Parallel and Distributed Systems (TPDS), 2021

    2021

  18. [26]

    Synthesisable recursion for C++ HLS tools,

    David B. Thomas, “Synthesisable recursion for C++ HLS tools,” IEEE International Conference on Application-specific Systems, Architectures and Processors (ASAP), 2016

    2016

  19. [27]

    Finding and Understanding Bugs in FPGA Synthesis Tools,

    Yann Herklotz and John Wickerson, “Finding and Understanding Bugs in FPGA Synthesis Tools,” IEEE/ACM International Symposium on Field- Programmable Gate Arrays (FPGA), 2020

    2020

  20. [28]

    RFUZZ: Coverage-Directed Fuzz Testing of RTL on FPGAs,

    Kevin Laeufer, Jack Koenig, Donggyu Kim, Jonathan Bachrach and Koushik Sen, “RFUZZ: Coverage-Directed Fuzz Testing of RTL on FPGAs,” International Conference on Computer-Aided Design, 2018

    2018

  21. [29]

    Fault Testing and Diagnosis Techniques for Carbon Nanotube-Based FPGAs,

    Kangwei Xu, Yuanqing Cheng, “Fault Testing and Diagnosis Techniques for Carbon Nanotube-Based FPGAs,” ACM/IEEE Asia and South Pacific Design Automation Conference (ASP-DAC), 2022

    2022

  22. [30]

    Testing and Fault Tolerance Techniques for Carbon Nanotube-Based FPGAs,

    Siyuan Lu, Kangwei Xu, Peng Xie, Rui Wang, Yuanqing Cheng, “Testing and Fault Tolerance Techniques for Carbon Nanotube-Based FPGAs,” Elsevier Integration, VLSI Journal, 2025

    2025

  23. [31]

    Automated C/C++ Program Repair for High-Level Syn- thesis via Large Language Models,

    Kangwei Xu, Grace Li Zhang, Xunzhao Yin, Cheng Zhuo, Ulf Schlicht- mann, Bing Li, “Automated C/C++ Program Repair for High-Level Syn- thesis via Large Language Models,” IEEE/ACM International Symposium on Machine Learning for CAD (MLCAD), 2024

    2024

  24. [32]

    HLSRewriter: Efficient Refactoring and Optimization of C/C++ Code with LLMs for HLS,

    Kangwei Xu, Grace Li Zhang, Xunzhao Yin, Cheng Zhuo, Ulf Schlicht- mann, Bing Li, “HLSRewriter: Efficient Refactoring and Optimization of C/C++ Code with LLMs for HLS,” ACM Transactions on Design Automation of Electronic Systems (TODAES), 2025

    2025

  25. [33]

    Open Source Computer Vision (OpenCV),

    “Open Source Computer Vision (OpenCV),” Accessed: 2024. [Online]. Available: https://docs.opencv.org/

    2024

  26. [34]

    Leetcode Problem Set,

    “Leetcode Problem Set,” Accessed: 2023. [Online]. Available: https://leetcode.com/problemset/

    2023

  27. [35]

    GPT through OpenAI API,

    “GPT through OpenAI API,” Accessed: 2024. [Online]. Available: https://platform.openai.com/

    2024

  28. [36]

    A Survey on Software Fault Localization,

    W. Eric Wong, Franz Wotawa,et al., “A Survey on Software Fault Localization,” IEEE Transactions on Software Engineering, 2016

    2016

  29. [37]

    An Em- pirical Examination of Fuzzer Mutator Performance,

    James Kukucka, Lu ´ıs Pina, Paul Ammann, and Jonathan Bell, “An Em- pirical Examination of Fuzzer Mutator Performance,” ACM International Symposium on Software Testing and Analysis (ISSTA), 2024

    2024

  30. [38]

    Logic Design of Neural Networks for High-Throughput and Low-Power Applications,

    Kangwei Xu, Grace Li Zhang, Ulf Schlichtmann, Bing Li, “Logic Design of Neural Networks for High-Throughput and Low-Power Applications,” IEEE/ACM Asia and South Pacific Design Automation Conference (ASP- DAC), 2024

    2024

  31. [39]

    Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks,

    Nils Reimers, Iryna Gurevych, “Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks,” ACL Empirical Methods in Natural Language Processing (EMNLP), 2019. 9

    2019

Pith tools

Reviewed August 16, 2026 · model on record in the stance chip above.