Pith. sign in

REVIEW 3 major objections 5 minor 31 references

HLSmith: An Expert-Guided Agentic Framework for C/C++-to-HLS Translation

T0 review · 3 major / 5 minor · reviewed 2026-08-15 · deepseek-v4-flash

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

Pith's one-line read HLSmith claims that guiding LLM agents with guarded, ordered HLS optimization recipes and staged compiler feedback converts plain C/C++ into valid, faster FPGA accelerators, completing all 14 evaluated kernels versus 57% for the leading…

desk verdict The guarded-recipe idea is real and the within-model ablations are well done, but the headline ChatHLS numbers rest on evidence that can't be replayed, and the paper never says the gold HLS reference is kept out of the model's prompts. read the letter →

arxiv 2608.06791 v1 pith:RHCCOUQX submitted 2026-08-07 cs.AR cs.AI

Yuebo Luo , Ahmad Sedigh Baroughi , Philip Stachura , Le Chen , Venkatram Vishwanath , Zhenman Fang , Caiwen Ding This is my paper · ORCID
classification cs.ARcs.AI
keywords high-levelsynthesisLLMagentsFPGAacceleratorsC-to-HLStranslationguardedoptimizationrecipesfeedbackmodelfine-tuningPolyBench
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

This paper argues that LLMs fail to translate plain C/C++ into high-performance FPGA hardware not because they cannot code, but because they lack the hardware architect's procedural know-how: which transformation to apply, in what order, and under what preconditions. To supply that know-how, it builds HLSmith, a framework whose core is a library of guarded recipes, each keyed to a diagnosed bottleneck, listing structural prerequisites, ordered code changes, unsafe cases to avoid, and expected outcomes. An orchestrator runs a staged loop: synthesize the baseline, read the tool's report, diagnose the bottleneck, route a matching recipe, validate the edit by simulation and synthesis, and keep the best valid design. On a fixed 28-kernel polyhedral benchmark suite, the paper reports that HLSmith beats the prior agent-orchestration baseline on every common kernel, with 14 of 14 RTL-valid designs against 8 of 14, and geometric-mean speedups of 6.91x over the eight common passes (4.24x on a seven-kernel sensitivity set). The reason to care: if the recipe-plus-feedback mechanism holds up, LLM-based hardware design shifts from hoping the model has hardware intuition to engineering that intuition as reusable, checkable procedure.

What carries the argument

The load-bearing object is the guarded recipe tuple $s = \langle b, p, a, q, g, e \rangle$, along with the orchestration loop that only applies a recipe when its bottleneck matches the tool's diagnosis and its preconditions hold in the current code. The tuple is the interface between distilled HLS expertise and the LLM agents: it turns 'know how to optimize HLS' into a routable, checkable procedure, and the staged loop—baseline synthesis, diagnosis, recipe application, validation, keep-or-restore—enforces transformation order and prevents the model from wandering. A second mechanism is the early setup router, which ranks workflow-depth and expertise-policy combinations from the plain source and initial report, and cuts the search space from ten setups to five while staying within 5% of the exhaustive optimum on 18 of 19 kernels.

What would settle it

Re-run the 14-kernel comparison with identical tool version, device, and CPU-golden outputs, replaying RTL co-simulation for every candidate and comparing executed cycle counts from the logs; if HLSmith's valid count drops below 14, or the geometric-mean RTL speedup over the baseline differs materially from 6.91x (4.24x on the sensitivity set), the paper's central claim is refuted.

Watch

Extended reading notes

Core claim

The central discovery is that C/C++-to-HLS optimization can be decomposed into bottleneck-conditioned, guarded transformation recipes and driven by a staged, compiler-feedback loop, and that this decomposition is what lets LLM agents produce functionally correct, faster accelerators. Each recipe is a tuple $s = \langle b, p, a, q, g, e \rangle$: a bottleneck $b$ found in the synthesis report, structural prerequisites $p$, the architectural action $a$, an ordered checklist $q$, unsafe conditions $g$ to avoid, and expected results $e$. The Action Router admits a recipe only when $b$ matches the current diagnosis, $p$ holds in the current code, and no guard $g$ is triggered; the Optimizer applies the ordered steps; the HLS tool's reports are checked against $e$; and the orchestrator keeps the best valid design, reverting on failure. The paper's evidence is the comparison against the leading prior agent-orchestration framework on the polyhedral benchmark suite: HLSmith produces RTL-valid designs on all 14 kernels it attempts, versus 8 for the baseline, and its designs use fewer executed RTL cycles on every one of the eight common passes, with a geometric-mean ratio of 6.91x (4.24x excluding one influential kernel). The same workflow, when used to record trajectories from commercial frontier models, fine-tunes open-weight models down to 7B parameters, with reported peak per-kernel synthesis gains of 3.61x.

Load-bearing premise

The headline numbers rest on RTL cycle counts and co-simulation pass/fail results that the authors supply without releasing generated RTL or output traces for independent value replay, so the core comparison assumes those reported measurements are accurate and comparable to the baseline's.

Editorial extensions

If this is right

  • If the claims hold, LLM-based HLS optimization no longer depends on the model's implicit hardware intuition: explicit guarded recipes plus synthesis feedback can steer agents to valid, faster designs, which is a reusable recipe for other hardware-generation tasks.
  • The 14/14 RTL-valid rate versus 8/14 implies the staged recipe flow improves correctness and performance together, not one at the cost of the other, in this evaluation.
  • The 5-of-10 setup router implies roughly half the workflow configurations can be pruned up front on the basis of source code and the initial HLS report while staying within 5% of the exhaustive best on most kernels, lowering compute cost.
  • The fine-tuning results imply open-weight models as small as 7B can absorb validated optimization behavior from commercial teacher trajectories, lowering the cost and privacy barrier of using front-tier API models for HLS.
  • The up-to-252x speedups, if representative, imply that the gap between 'compiles and simulates' and 'actually fast' in HLS is bridgeable by structured architectural restructuring rather than pragma tuning alone.

Reading between the lines

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

  • We infer that the guarded-recipe representation could be made even stronger by machine-checking the preconditions and guards with a static analyzer, so that LLM judgment is only needed for the final code edit, not for deciding applicability.
  • We infer that the recipe tuple is a form of searchable expert knowledge that could bootstrap itself: successful trajectories from one set of kernels could be mined into new library entries, growing coverage beyond the initial expert-derived recipes.
  • The paper's own inspection notes that the fine-tuned 7B model's improvements come from simpler transformations such as loop fission, pipelining, and unrolling, and not from tiling, double buffering, or dataflow; we infer that reward tuning currently under-exploits the architectural restructuring the library encodes, so combining GRPO with explicit recipe supervision may yield further gains.
  • Because the RTL traces and output values are not released, we infer that an independent reproducibility check is the first test the community should run before relying on the speedup ratios.
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 / 5 minor

Summary. The paper presents HLSmith, an agentic framework that translates plain C/C++ programs into optimized HLS designs. It combines a library of guarded transformation recipes distilled from expert HLS code, a staged and feedback-driven orchestration flow (flash vs. multi-step), and a tool-grounded model-adaptation pipeline using SFT and GRPO. The authors evaluate HLSmith on HLSFactory-28 PolyBench kernels, comparing against ChatHLS and reporting a 14/14 RTL-valid design rate versus ChatHLS's 8/14, with geometric-mean speedups of 6.91x over eight common passes (4.24x on a seven-kernel sensitivity set). Additional experiments measure the effect of expertise policies, a setup router, and fine-tuned open-weight models.

Significance. If the central comparison is valid, this is a potentially significant advance: it separates reusable, guarded HLS expertise from workflow control and shows that structured, prerequisite-aware optimization can outperform a prior state-of-the-art agentic framework. The paper has several genuine strengths: matched within-model comparisons, explicit disclosure of which evidence rows include golden-output or RTL checks, and exclusion of evaluation kernels from model-adaptation training data. However, the two largest claims—14/14 validity and 6.91x speedup over ChatHLS—currently rest on (a) an unspecified role for the gold reference HLS implementation in the agentic loop, and (b) self-supplied RTL cycle counts with no independent output replay. These issues are load-bearing for the headline result and must be resolved before the contribution can be fully assessed.

major comments (3)
  1. [Section III-A; Section V-B; Figure 8] The manuscript lists 'a corresponding reference HLS implementation used as the gold reference' as an input to HLSmith (Section III-A) but never states that this reference is withheld from the LLM agents. Because the ChatHLS comparison in Section V-B and Figure 8 is the basis for the 14/14 validity and 6.91x geometric-mean speedup claims, the possibility that the reference HLS code appears in Translator/Optimizer prompts, few-shot context, or validation feedback would make the comparison trivially explainable and would invalidate the guarded-recipe/staged-flow attribution. Please state explicitly whether the reference HLS implementation is visible to any agent during translation or optimization; if it is visible, repeat the ChatHLS comparison with the reference withheld.
  2. [Table IV; Figure 8 caption] The RTL-cycle and output-validity evidence for the ChatHLS comparison is self-reported: Table IV labels the additional RTL rows 'Supplied RTL cycles; no independent output replay,' and the Figure 8 caption states that 'The CSVs omit generated RTL and output traces, preventing independent value replay.' The headline numbers (14/14 versus 8/14 validity, 6.91x speedup) therefore rest entirely on numbers supplied by the authors. This is a load-bearing reproducibility gap; please release the generated RTL, co-simulation logs, and output traces, or run an independent replay of the comparison.
  3. [Table IV; Table V; Figure 6] The teacher-sweep rows in Table IV are labeled 'no golden-output or RTL check,' yet Table V and Figure 6(a-c) present large benchmark-baseline speedups (17.46x, 14.51x, 11.39x) from these same sweeps. These numbers are HLS synthesis-cycle estimates without independent output verification. The paper should clearly separate claims that are backed by CPU-golden C simulation and RTL co-simulation from claims that are only synthesis estimates, so that the abstract's 'functionally correct designs' statement is not implicitly attributed to unverified synthesis results.
minor comments (5)
  1. [Abstract; Section VI] The abstract reports 'a geometric mean speedup of 4.24x over ChatHLS,' but Section VI reports 6.91x over the eight common passes and 4.24x on the seven-kernel sensitivity set. Please reconcile or qualify the headline number so the abstract matches the detailed results.
  2. [Section IV-B] There is a 'Table??' placeholder in the text describing the expertise tuple in Eq. (2). Please insert the intended table or reference.
  3. [Section V-B] Several sentences are garbled, e.g., 'excluding it gives 4.24×on the other The 6 HLSmith-only passes improve recorded solve rate' and 'and and beating expertise off cases.' Please proofread and rewrite these passages.
  4. [Figure 4 caption] The caption contains the typo 'HLS-Factgory'; it should be 'HLSFactory.'
  5. [Section V-D] The manuscript itself notes that 'The reported 2.02× median ratio compares different C-simulation-passing subsets and is neither paired nor a geometric mean.' Given this disclosure, the later conclusion that small models 'achieve decent optimization' should not lean on this unpaired result; consider removing it or clearly marking it as preliminary.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the central claims are benchmarked against external baselines and held-out kernels, and no equation reduces the reported speedups to the framework's own inputs.

full rationale

HLSmith's derivations are not circular. The expertise library is distilled from Rodinia-HLS, an external benchmark family distinct from the HLSFactory-28 evaluation set, and the paper explicitly states that 'Kernels used for evaluation are excluded from the model-adaptation training data' (Section IV-D). The headline comparison is against ChatHLS, an external baseline, and the selection rule in Eq. (1) is an arg-min over candidates that independently pass C simulation, synthesis, timing, fit, and CPU-golden checks; it does not encode the predicted speedup. The GRPO reward in Eq. (5) uses hand-set constants and a speedup ratio relative to the initial baseline, and the evaluation is performed on held-out tasks, so the reward is not fitted to the evaluation outcome. The setup-router evaluation in Eq. (3) is reported on 19 group-held-out development kernels, and the paper states that 'Neither branch sees optimized-candidate outcomes at prediction time' (Section IV-E). The manuscript's own limitations, such as 'The CSVs omit generated RTL and output traces, preventing independent value replay' (Fig. 8) and 'Supplied RTL cycles; no independent output replay' (Table IV), are reproducibility weaknesses rather than circular reductions. The only self-citation, CUDAHercules [14], is for figure layout inspiration and is not load-bearing. No fitted parameter, equation, or self-citation chain reduces the reported 4.24x/6.91x speedups to the framework's inputs by construction.

Assumptions & free parameters 6 free parameters · 5 assumptions · 0 invented entities

The central claims rest on software design choices and domain assumptions rather than on new physical or mathematical entities. The main unsupported inputs are the hand-authored expertise library, the choice of reference baselines, and the hand-set training rewards.

free parameters (6)
  • GRPO reward base b = 0.2
    Eq. (5); hand-set constant giving the correctness-ladder tier reward. Chosen by authors, affects adapted model behavior.
  • GRPO latency weight alpha = 0.6
    Eq. (5); weights the speedup ratio in the reward. Hand-set constant.
  • GRPO resource penalty beta = 0.5
    Eq. (5); penalizes resource overshoot beyond the target FPGA budget.
  • GRPO speedup cap h(z) = min(2,z)
    Eq. (5); caps latency credit at a 2x speedup to stabilize policy optimization.
  • Resource budget factor for Bd = 50% of U280 capacity
    Section V.A; authors chose half the FPGA capacity as the feasibility bound for GRPO rollouts.
  • Multi-step attempt cap = 5
    Section IV.A; default cap of five optimization attempts per kernel before final selection.
assumptions (5)
  • domain assumption Expertise distilled from Rodinia-HLS transfers to HLSFactory-28 PolyBench kernels
    Section IV.B uses Rodinia-HLS as the source of optimization patterns and HLSFactory-28 as evaluation; there is no formal or empirical proof that the guarded recipes cover all kernels in the test set.
  • domain assumption Vitis HLS synthesis latency estimates are a reliable proxy for RTL performance when selecting designs
    Eq. (1) selects the minimum worst-case HLS-synthesis latency, and teacher-sweep speedups are reported on these estimates without RTL verification (Table IV).
  • domain assumption The supplied HLSFactory reference implementations are a meaningful performance baseline
    All speedup ratios divide by supplied upstream HLS implementation cycles; the paper acknowledges these are not expert frontier baselines, so absolute speedups may overstate practical gains.
  • domain assumption LLM agents in the loop follow the routed ordered transformation checklists with adequate reliability
    The mechanism assumes the Optimizer agent implements the ordered action checklist q from Eq. (2); failures to follow instructions are only detected after synthesis.
  • domain assumption Commercial frontier model trajectories, filtered by Vitis tool feedback, provide valid supervision for fine-tuning open-weight models
    Section IV.F builds SFT data from teacher artifacts that pass C simulation and synthesis but, for the teacher sweep, not golden-output or RTL checks.

how reviews work

0 comments
Cite this review

Pith. "Pith review of HLSmith: An Expert-Guided Agentic Framework for C/C++-to-HLS Translation." pith.science (2026). https://pith.science/paper/RHCCOUQX

@misc{pith2026260806791,
  author       = {Pith},
  title        = {Pith review of: HLSmith: An Expert-Guided Agentic Framework for C/C++-to-HLS Translation},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/RHCCOUQX}},
  note         = {Machine review of arXiv:2608.06791}
}
read the original abstract

Application-specific FPGA accelerators offer substantial performance and energy-efficiency gains across many application domains, but developing them is costly, often requiring months of specialized effort. Even with high-level synthesis (HLS), designers still need extensive hardware expertise to build high-performance accelerators. Although large language models (LLMs) have demonstrated strong software-generation capabilities, even frontier models lack the hardware intuition and procedural knowledge needed to reliably translate baseline C/C++ programs into high-performance HLS designs: they struggle to identify effective architectures, follow the optimization processes used by HLS experts, and apply hardware transformations consistently across diverse kernels. We present HLSmith, an expert-guided framework for translating C/C++ programs into optimized HLS accelerators. HLSmith combines three components: an HLS optimization expertise library that encodes guarded transformation recipes, their applicability and prerequisite conditions, and unsafe cases to avoid; a staged, feedback-driven orchestration flow modeled on expert HLS development practice that guides agents through synthesis, bottleneck analysis, and optimization; and a tool-grounded model-adaptation pipeline that converts optimization trajectories from commercial frontier models into training data for fine-tuning open-weight LLMs. We evaluate HLSmith on PolyBench against ChatHLS, a leading prior agent-orchestration framework for HLS accelerator development. HLSmith achieves a geometric mean speedup of 4.24x over ChatHLS while producing functionally correct designs, in both software and RTL simulation, for every benchmark, compared with ChatHLS's 57% valid-design rate. It further reaches speedups of up to 252x and 138x with commercial frontier models and open-weight models, respectively.

Figures

Figures reproduced from arXiv: 2608.06791 by the authors.

Figure 1
Figure 1. From functional HLS-C to architecture-aware optimization. The top row isolates one-shot generation, feedback without explicit HLS expertise, and [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. End-to-end HLSmith workflow. The numbered path translates plain C, evaluates the HLS-C design, diagnoses its bottleneck, routes the guarded recipe [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Prerequisite-aware HLS optimization. Tiling creates local reuse, banking supplies ports for parallel lanes, and stage separation enables double-buffered [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (6 more)
Figure 4
Figure 4. Figure 4: HLS-Factgory’s TRMM optimization process with HLSmith (base model Claude Sonnet 4.6). Each intermediate design synthesizes and lowers Vitis’s [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]
Figure 5
Figure 5. Figure 5: Hybrid setup routing. A structured rank committee and an independent [PITH_FULL_IMAGE:figures/full_fig_p006_5.png]
Figure 6
Figure 6. Figure 6: Per-kernel benchmark-baseline speedup. Bars show [PITH_FULL_IMAGE:figures/full_fig_p009_6.png]
Figure 7
Figure 7. Figure 7: Open-weight expertise sweep. Within each mode, bars show the best qualified speedup over the upstream reference across five policies; diamonds [PITH_FULL_IMAGE:figures/full_fig_p010_7.png]
Figure 8
Figure 8. Figure 8: RTL outcomes for 14 attempts. Labels show ChatHLS/HLSmith [PITH_FULL_IMAGE:figures/full_fig_p010_8.png]
Figure 9
Figure 9. Figure 9: Five-kernel open-model pilot. Bars show geometric-mean HLS [PITH_FULL_IMAGE:figures/full_fig_p011_9.png]

Review history (2 revisions) →

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

31 extracted references · 16 canonical work pages

  1. [1]

    HLS-Eval: A benchmark and framework for evaluating LLMs on high-level synthesis design tasks,

    S. Abi-Karam and C. Hao, “HLS-Eval: A benchmark and framework for evaluating LLMs on high-level synthesis design tasks,” in Proceedings of the 2025 IEEE International Conference on LLM- Aided Design (ICLAD), 2025, pp. 219–226. [Online]. Available: https://doi.org/10.1109/ICLAD65226.2025.00021

    arXiv 2025

  2. [2]

    HLSFactory: A framework empowering high-level synthesis datasets for machine learning and beyond,

    S. Abi-Karam, R. Sarkar, A. Seigler, S. Lowe, Z. Wei, H. Chen, N. Rao, L. John, A. Arora, and C. Hao, “HLSFactory: A framework empowering high-level synthesis datasets for machine learning and beyond,” in Proceedings of the 2024 ACM/IEEE International Symposium on Machine Learning for CAD (MLCAD), 2024, pp. 1–9. [Online]. Available: https://doi.org/10.114...

    arXiv 2024

  3. [3]

    Agent factories for high level synthesis: How far can general-purpose coding agents go in hardware optimization?

    A. Bhandwaldar, M. Choudhury, R. Puri, and A. Srivastava, “Agent factories for high level synthesis: How far can general-purpose coding agents go in hardware optimization?” 2026. [Online]. Available: https://arxiv.org/abs/2603.25719

    arXiv 2026

  4. [4]

    C2HLSC: Leveraging large language models to bridge the software-to-hardware design gap,

    L. Collini, S. Garg, and R. Karri, “C2HLSC: Leveraging large language models to bridge the software-to-hardware design gap,”ACM Trans. Des. Autom. Electron. Syst., vol. 30, no. 6, Oct. 2025. [Online]. Available: https://doi.org/10.1145/3734524

    doi:10.1145/3734524 2025

  5. [5]

    Best-effort FPGA programming: A few steps can go a long way,

    J. Cong, Z. Fang, Y . Hao, P. Wei, C. H. Yu, C. Zhang, and P. Zhou, “Best-effort FPGA programming: A few steps can go a long way,”

    work page

  6. [6]

    Understanding performance differences of FPGAs and GPUs,

    J. Cong, Z. Fang, M. Lo, H. Wang, J. Xu, and S. Zhang, “Understanding performance differences of FPGAs and GPUs,” inProceedings of the IEEE International Symposium on Field-Programmable Custom Com- puting Machines, 2018, pp. 93–96

    work page 2018

  7. [7]

    High-level synthesis for FPGAs: From prototyping to deployment,

    J. Cong, B. Liu, S. Neuendorffer, J. Noguera, K. Vissers, and Z. Zhang, “High-level synthesis for FPGAs: From prototyping to deployment,” IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol. 30, no. 4, pp. 473–491, 2011

    2011

  8. [8]

    An introduction to high-level synthesis,

    P. Coussy, D. D. Gajski, M. Meredith, and A. Takach, “An introduction to high-level synthesis,”IEEE Design & Test of Computers, vol. 26, no. 4, pp. 8–17, 2009

    2009

Show all 31 references
  1. [9]

    QLoRA: Efficient finetuning of quantized LLMs,

    T. Dettmers, A. Pagnoni, A. Holtzman, and L. Zettlemoyer, “QLoRA: Efficient finetuning of quantized LLMs,”arXiv preprint arXiv:2305.14314, 2023. [Online]. Available: https://arxiv.org/abs/2305. 14314

    2023 arXiv

  2. [10]

    Benchmarking optimization software with performance profiles,

    E. D. Dolan and J. J. Mor ´e, “Benchmarking optimization software with performance profiles,”Mathematical Programming, vol. 91, no. 2, pp. 201–213, 2002

    2002

  3. [11]

    Efron and R

    B. Efron and R. J. Tibshirani,An Introduction to the Bootstrap. New York, NY: Chapman & Hall/CRC, 1994

    1994

  4. [12]

    Exploring code language models for automated HLS-based hardware generation: Benchmark, infrastructure and analysis,

    J. Gai, H. M. Chen, Z. Wang, H. Zhou, W. Zhao, N. D. Lane, and H. Fan, “Exploring code language models for automated HLS-based hardware generation: Benchmark, infrastructure and analysis,” in Proceedings of the 30th Asia and South Pacific Design Automation Conference (ASP-DAC)...

    2025

  5. [13]

    ChatHLS: Towards systematic design automation and optimization for high-level synthesis,

    R. Li, J. Xiong, X. He, J. Zhao, J. Lv, H. Fang, L. Qi, and X. Wang, “ChatHLS: Towards systematic design automation and optimization for high-level synthesis,” inProceedings of the 64th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers). Sa...

    2026

  6. [14]

    CUDAHercules: Benchmarking hardware-aware expert- level CUDA optimization for LLMs,

    S. Li, Z. Zhang, G. Sun, Y . Luo, W. Chen, Y . Wang, M. Hong, and C. Ding, “CUDAHercules: Benchmarking hardware-aware expert- level CUDA optimization for LLMs,” 2026. [Online]. Available: https://arxiv.org/abs/2605.08467

    2026 arXiv

  7. [15]

    TimelyHLS: LLM- based timing-aware and architecture-specific FPGA HLS optimization,

    N. Mashnoor, M. Akyash, H. Kamali, and K. Azar, “TimelyHLS: LLM- based timing-aware and architecture-specific FPGA HLS optimization,” in2025 IEEE International Conference on Omni-layer Intelligent Sys- tems (COINS), 2025, pp. 1–6

    2025

  8. [16]

    LAAFD: LLM-based agents for accelerated FPGA design,

    M. Moraru, K. Kamalakkannan, J. Dominguez-Trujillo, P. Diehl, A. Barai, J. Loiseau, Z. K. Baker, H. Pritchard, and G. M. Shipman, “LAAFD: LLM-based agents for accelerated FPGA design,” 2026. [Online]. Available: https://arxiv.org/abs/2602.06085

    2026 arXiv

  9. [17]

    PolyBench/C: The polyhedral benchmark suite,

    L.-N. Pouchet and T. Yuki, “PolyBench/C: The polyhedral benchmark suite,” https://web.cse.ohio-state.edu/ ∼pouchet.2/software/polybench/, 2012, accessed July 2026

    2012

  10. [18]

    A unified framework for automated code transformation and pragma insertion,

    S. Pouget, L.-N. Pouchet, and J. Cong, “A unified framework for automated code transformation and pragma insertion,” inProceedings of the ACM/SIGDA International Symposium on Field Programmable Gate Arrays, 2025, pp. 187–198

    2025

  11. [19]

    LIFT: LLM-based pragma insertion for HLS via GNN supervised fine-tuning,

    N. Prakriya, Z. Ding, Y . Sun, and J. Cong, “LIFT: LLM-based pragma insertion for HLS via GNN supervised fine-tuning,” 2025. [Online]. Available: https://arxiv.org/abs/2504.21187

    2025 arXiv

  12. [20]

    Qwen3.6-27B: Flagship-level coding in a 27B dense model,

    Qwen Team, “Qwen3.6-27B: Flagship-level coding in a 27B dense model,” April 2026. [Online]. Available: https://qwen.ai/blog?id=qwen3. 6-27b

    2026

  13. [21]

    DeepSeekMath: Pushing the limits of mathematical reasoning in open language models,

    Z. Shao, P. Wang, Q. Zhu, R. Xu, J. Song, X. Bi, H. Zhang, M. Zhang, Y . K. Li, Y . Wu, and D. Guo, “DeepSeekMath: Pushing the limits of mathematical reasoning in open language models,”arXiv preprint arXiv:2402.03300, 2024. [Online]. Available: https://arxiv.org/abs/2402.03300

    2024 arXiv

  14. [22]

    Autodse: Enabling software programmers to design efficient fpga accelerators,

    A. Sohrabizadeh, C. H. Yu, M. Gao, and J. Cong, “Autodse: Enabling software programmers to design efficient fpga accelerators,”ACM Trans. Des. Autom. Electron. Syst., vol. 27, no. 4, Feb. 2022. [Online]. Available: https://doi.org/10.1145/3494534

    2022 doi

  15. [23]

    Gemma 4 technical report,

    G. Team, S. E. Abd, V . Aggarwal, R. Algayres, A. Andreev, O. Bachem, I. Ballantyne, C. Brick, V . C ˘arbune, M. Casbon, M. Chaturvedi, A. Chawla, V . Cotruta, A. Coucke, P. Culliton, R. Dadashi, L. Dixon, M. Elhawaty, U. Evci, C. Farabet, J. Ferret, F. Galgani, S. Girgin, J.-...

    2026 arXiv

  16. [24]

    HLSPilot: LLM-based high-level synthesis,

    C. Xiong, C. Liu, H. Li, and X. Li, “HLSPilot: LLM-based high-level synthesis,” 2024. [Online]. Available: https://arxiv.org/abs/2408.06810

    2024 arXiv

  17. [25]

    Deepseek-v4: Towards highly efficient million- token context intelligence,

    A. Xu, B. Lin, B. Xue, B. Wang, B. Xu, B. Wu, B. Zhang, C. Lin, C. Dong, C. Linget al., “Deepseek-v4: Towards highly efficient million- token context intelligence,”arXiv preprint arXiv:2606.19348, 2026

    2026

  18. [26]

    Optimizing High-Level Synthesis Designs with Retrieval-Augmented Large Language Models,

    H. Xu, H. Hu, and S. Huang, “Optimizing High-Level Synthesis Designs with Retrieval-Augmented Large Language Models,” in2024 IEEE LLM AIDED DESIGN WORKSHOP , LAD 2024, 2024

    2024

  19. [27]

    HLSRewriter: Efficient refactoring and optimization of C/C++ code with LLMs for high-level synthesis,

    K. Xu, G. L. Zhang, X. Yin, C. Zhuo, U. Schlichtmann, and B. Li, “HLSRewriter: Efficient refactoring and optimization of C/C++ code with LLMs for high-level synthesis,”ACM Transactions on Design Automation of Electronic Systems, vol. 31, no. 4, 2026

    2026

  20. [28]

    ScaleHLS: A new scalable high-level synthesis framework on multi-level intermediate representation,

    H. Ye, C. Hao, J. Cheng, H. Jeong, J. Huang, S. Neuendorffer, and D. Chen, “ScaleHLS: A new scalable high-level synthesis framework on multi-level intermediate representation,” 2021. [Online]. Available: https://arxiv.org/abs/2107.11673

    2021 arXiv

  21. [29]

    HLS- Seek: QoR-aware code generation for high-level synthesis via proxy comparative reward reinforcement learning,

    Q. Zou, F. Yu, H. Tan, Y . Chen, B. He, and W. Wong, “HLS- Seek: QoR-aware code generation for high-level synthesis via proxy comparative reward reinforcement learning,” 2026. [Online]. Available: https://arxiv.org/abs/2605.13536

    2026 arXiv

  22. [30]

    AgRefactor: Self-evolving agentic workflow for HLS compatibility and performance,

    Y . Zou, Z. Ding, Y . Sun, and J. Cong, “AgRefactor: Self-evolving agentic workflow for HLS compatibility and performance,” 2026. [Online]. Available: https://arxiv.org/abs/2606.30949 APPENDIXA AI USE OpenAI Codex materially assisted this paper by reviewing the implementation ...

    2026 arXiv

  23. [2018]

    Available: https://arxiv.org/abs/1807.01340

    [Online]. Available: https://arxiv.org/abs/1807.01340

    arXiv

Pith tools

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