TimelyHLS: LLM-Based Timing-Aware and Architecture-Specific FPGA HLS Optimization

Hadi Kamali; Kimia Azar; Mohammad Akyash; Nowfel Mashnoor

REVIEW 5 major objections 5 minor 32 references

TimelyHLS: LLM-Based Timing-Aware and Architecture-Specific FPGA HLS Optimization

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

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

Pith's one-line read TimelyHLS claims that an LLM grounded in FPGA architecture specs and iterated on commercial synthesis feedback can replace most manual pragma tuning and consistently achieve timing closure, with up to 4x kernel speedups.

desk verdict Plausible LLM+HLS framework, but the evaluation as written cannot support the headline speedups—Table III mixes latency with slack and the baseline is never defined. read the letter →

arxiv 2507.17962 v1 pith:JB62XTYN submitted 2025-07-23 cs.CR

Nowfel Mashnoor , Mohammad Akyash , Hadi Kamali , Kimia Azar This is my paper

classification cs.CR

keywords FPGAhigh-levelsynthesistimingclosureLLMcodegenerationretrieval-augmentedpragmaoptimizationfeedbackloop

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

TimelyHLS claims that the hard part of FPGA high-level synthesis—choosing the right pragmas and code structure so that a design meets its clock constraints—can be automated by an LLM that is told the target chip's resources and allowed to see the tool's own error and timing reports. The framework first prompts a model to write HLS code with pragmas for a given kernel and FPGA, then runs the code through commercial HLS and RTL synthesis, checks functional correctness with testbenches, and feeds failures and negative-slack reports back into the model until timing closure and correctness are reached. On ten benchmarks drawn from open-source HLS suites and ten FPGA families, the authors report up to 4x latency speedups, area reductions over 50% in some cases, and up to 70% less manual tuning. If true, this means a large share of expert HLS pragma tuning can be replaced by a grounded, feedback-driven LLM pipeline.

What carries the argument

The load-bearing mechanism is a two-stage closed-loop verification pipeline wrapped around an LLM with retrieval-augmented generation. A structured knowledge base of FPGA architectural specifications and pragma templates is queried during code generation; the first stage compiles and simulates the generated C/C++ in HLS tooling; the second stage exports RTL, synthesizes it for the target FPGA, checks worst and total negative slack, and runs RTL simulation. Each stage's logs are formatted back into the prompt for another LLM pass, repeating until HLS and RTL simulation pass, the RTL is synthesizable, and no negative slack remains.

What would settle it

Fix the base code for each of the ten kernels from a publicly versioned source, specify a timed expert-tuning protocol, and rerun TimelyHLS on identical hardware; if speedups vanish when the base code is already reasonably optimized, or if the timed manual baseline is not actually slower, the central claim fails. A simpler check is to run the same LLM-and-RAG flow without the RTL-stage timing feedback; if the timing-closure rate stays the same, the second feedback loop is not the cause of the reported gains.

Watch

Extended reading notes

Core claim

The paper's central claim is that timing-closed, high-performance FPGA implementations can be generated by a closed loop in which an LLM is the search engine: retrieval from a structured FPGA knowledge base supplies architecture-specific directives, the commercial toolchain supplies ground truth, and the LLM revises code in response to synthesis and timing logs. The paper demonstrates this on ten kernels and ten devices, with the strongest reported results being matrix multiplication latency reduced from 16,531 to 4,277 cycles and initiation interval from 16 to 1–2, bitonic sort fully pipelined at II=1, and Viterbi flip-flop and LUT reductions above 50%. The authors also report that the framework consistently achieves timing closure with no negative slack across the evaluated platforms.

Load-bearing premise

The central claim depends on the Base designs and manual-tuning effort being fair, well-defined comparators; the paper never states how the base code was generated, what protocol the manual tuning followed, or how the 70% reduction was measured, so if those baselines are arbitrary the speedup and labor-savings numbers do not support the conclusions.

Editorial extensions

If this is right

HLS pragma selection can be automated end-to-end by an LLM grounded in architecture specs and guided by synthesis logs, rather than by expert trial and error.
Designs that start with negative timing slack can be brought to closure across low-cost and high-end FPGA families without manual code rewrites.
The same two-stage feedback loop can target other objectives such as area or power, since the feedback channel is objective-agnostic and the prompts are configurable.
Reported speedups up to 4x and resource reductions over 50% imply that expert-level quality of results may be reachable with substantially less design effort.
Kernels with irregular memory access or feedback-heavy loops remain the hard cases: they succeed on high-end devices but can fail on resource-limited FPGAs.

Reading between the lines

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

A fair estimate of the 70% manual-tuning reduction would require a timed, specified protocol for expert tuning and a fixed base design; the paper does not report that protocol, so the labor-savings figure should be treated as preliminary.
Because the paper does not ablate the two feedback stages, the marginal contribution of RTL-stage timing feedback versus HLS-stage correction is unknown; a version of the loop that stops after the HLS stage would isolate where the gains come from.
A head-to-head against a heuristic design-space-exploration tool on identical kernels would separate gains from retrieval and feedback from gains already available through standard pragma recipes.
The framework's dependence on vendor-published datasheets and user guides suggests its knowledge base, not the LLM itself, may carry most of the architecture-specific value; rebuilding the knowledge base for another vendor would test that directly.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Desk Editor's Note

read the letter

Colleague,

The paper proposes TimelyHLS, an LLM-with-RAG system for FPGA HLS that generates code and then iterates on Vitis/Vivado feedback. The core idea is not new—HLSPilot already does RAG from vendor docs—but the two-stage feedback loop (HLS-level then RTL-level) is a reasonable extension, and the evaluation spans ten FPGA families, which is broader than most similar work. The code example in Fig. 3 shows real transformations, and the authors are upfront about area trade-offs.

The problems are in the evaluation. Table III is captioned as a latency comparison but contains negative nanosecond values, which are slack numbers, not latencies. That is not a minor formatting issue; it means the reported metric is ambiguous and likely inconsistent across rows. The baseline is never defined: the reader cannot tell whether 'Base' is the original CHStone/LegUp code, a naive LLM output, or a deliberately degraded version. The manual-tuning reduction of 70% appears in the abstract and Section V, but no protocol or timing measurement is given anywhere. No artifacts or logs are released, despite the paper claiming a dataset of logs was collected. These are load-bearing flaws because every headline number in the abstract is a ratio against that undefined base.

The novelty claim is also overstated. The paper cites HLSPilot and describes it as using RAG with vendor-specific rules, then calls TimelyHLS the first LLM+RAG for FPGA HLS. That contradiction is avoidable and weakens trust.

On the positive side, the system itself seems plausible, the authors engage with related work honestly, and the two-stage feedback idea is worth exploring. If the baselines were pinned down and artifacts released, the empirical claims could be checked. As written, the central numbers are not auditable.

This paper is for people working on LLM-based EDA and HLS pragma automation. I would not desk-reject it outright—the topic is relevant and the framework has merit—but I would send it to peer review with the strong expectation of heavy revision: a rewritten evaluation with a clearly defined baseline, a corrected Table III, a measured manual-tuning protocol, and artifact release. Without those, the claims should be scaled back to an experience report. If the authors can provide them, this could become a solid contribution.

I would engage with a revised version, but not with the current one as-is.

Referee Report

5 major / 5 minor

Summary. The manuscript proposes TimelyHLS, a framework that combines large language models (LLMs) with retrieval-augmented generation (RAG) and iterative synthesis feedback to generate HLS code with FPGA-specific pragmas. The workflow has two verification stages: Vitis HLS for C-level synthesis and functional simulation, and Vivado for RTL synthesis, timing analysis, and RTL simulation. The authors evaluate TimelyHLS on ten benchmark kernels across ten FPGA families and report up to 4x latency speedup, over 50% area savings in some cases, consistent timing closure, and up to 70% reduction in manual tuning. The paper includes a code example, resource utilization tables, and loop initiation interval results.

Significance. If the empirical claims were fully supported, the work would be a useful step toward automating HLS pragma selection, because it uses commercially measured synthesis feedback rather than fitted constants and addresses architecture-specific timing closure. The iterative two-stage feedback loop is a plausible and potentially valuable design. However, the current manuscript does not define the baselines used for the speedup and manual-tuning claims, and Table III is internally inconsistent, so the headline numbers cannot be verified as written. The absence of released artifacts, prompts, or logs further limits reproducibility.

major comments (5)

[Section V-A, Fig. 2] The speedup ratios (3.85x for Matrix Multiplication, 3.7x for Bitonic Sort, etc.) are computed relative to an undefined 'Base' design. Section III-A says kernels were selected from CHStone, LegUp, and MachSuite and that the authors 'developed corresponding HLS C++ source files,' but it is never stated whether Base is the original repository code, an LLM-generated naive implementation, or a deliberately degraded variant, nor what clock constraint was used. Without a precise baseline definition, the speedup claims are not reproducible.
[Table III, Section V-B] Table III is captioned 'Latency Comparison' but reports values in nanoseconds, including negative entries such as -0.08 and -0.54. These are WNS slack values, not latencies; for Matrix Multiplication the row 'Base (ns) -0.08' versus 'TimelyHLS (ns) 0.1' would imply negative latency if read literally. The accompanying text discusses slack, which suggests the table is mislabeled. Relabel it as a timing/slack comparison or report actual latency in cycles, and specify units consistently.
[Abstract, Section V] The claim of up to 70% reduction in manual tuning appears in the abstract and in the contributions, but Section V contains no measurement protocol, no definition of the manual-tuning baseline, and no timing of expert or designer effort. This claim is not backed by any experiment described in the manuscript and should either be removed or supported with a clearly specified protocol and measurement.
[Section IV-A] The statement that 'All designs were synthesized with constraints of achieving the maximum frequency' is not a well-defined timing constraint. Timing closure (WNS >= 0) depends on the chosen clock period, and 'maximum frequency' is an outcome, not a constraint. Specify the target clock period for each device or report the achieved Fmax so that the timing closure claim can be interpreted.
[Section III-A, reproducibility] The paper describes a dataset of source code, testbenches, synthesis reports, and timing summaries, but no artifacts, prompts, or logs are provided. Given that the evaluation rests on commercial tool outputs, releasing the generated HLS code, prompts, and synthesis logs (or stating clearly why they cannot be shared) is necessary for independent verification of the central claims.

minor comments (5)

[Section I, Section V-D] There are typos: 'oveheard' should be 'overhead' in Section I, and 'look initiation interval' should be 'loop initiation interval' in Section V-D.
[Section III-B vs. Section IV-B] Section III-B says the LLM is 'Code LLaMA or GPT-4,' but Section IV-B reports experiments using only GPT-4 and Claude-3.5-Sonnet. These statements should be aligned.
[Section I, contribution (i)] The contribution claim that TimelyHLS is 'the first framework to integrate an LLM with RAG for FPGA-specific HLS code generation' is contradicted by the paper's own related-work discussion of HLSPilot [7], which already uses RAG with vendor documentation. The novelty claim should be softened to avoid an internal inconsistency.
[Tables IV and V] The resource utilization tables report FF/LUT changes without giving the absolute baseline resource counts or the corresponding latencies at those operating points; adding the base values would make the latency-area trade-off discussion auditable.
[Fig. 4] Figure 4 presents pass rates across FPGA families without error bars or sample sizes; the text should state how many synthesis runs per family were performed and whether the pass rate is per benchmark or per generated candidate.

Circularity Check

0 steps flagged · score 0.0 of 10

No circular derivation: timing, latency, and correctness results are measured by external commercial tools; undefined baselines are auditability issues, not equation-level circularity.

full rationale

No circularity found. TimelyHLS's central claims are empirical measurements: generated HLS code is compiled with Xilinx Vitis HLS, exported to RTL, synthesized with Vivado, and checked against reference testbenches; timing closure is judged by post-synthesis WNS/TNS from the vendor toolchain. These outcomes are not derived from the knowledge base, from fitted constants, or from the LLM's own output by construction. The RAG knowledge base is built from vendor datasheets and user guides, not from the benchmark results, so the retrieval step does not smuggle the target results into the inputs. The only self-citations (references [27]-[29]) appear in related-work context about LLM use in RTL design and are not load-bearing for the paper's own claims. The paper does have significant auditability problems that belong under correctness risk rather than circularity: Section III-A says the authors 'developed corresponding HLS C++ source files' without stating whether the 'Base' comparator is the original repository code, and Section V-A never defines the manual-tuning protocol behind the 'up to 70%' reduction; Table III is labeled 'Latency Comparison' yet contains negative-slack values (e.g., '-0.08', '-0.54') alongside latency values, making the comparison internally inconsistent. These issues undermine reproducibility of the headline speedups, but they do not make the derivation circular: the timing and speedup numbers remain externally measured outputs of a commercial synthesis flow, not quantities forced by the paper's definitions or by self-citation. Accordingly, the circularity score is 0.

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

No fitted parameters or invented physical entities are present. The framework's results depend on practical assumptions about LLM behavior, tool feedback quality, and benchmark representativeness, as listed above.

assumptions (4)

domain assumption The LLM, prompted with RAG-retrieved FPGA data, will produce valid HLS C/C++ with appropriate pragmas.
Section III-B assumes one-shot and iterated generation converges to compilable, correct code; no formal guarantee or termination argument is given.
domain assumption The curated knowledge base from vendor datasheets and user guides is complete and accurate for each target FPGA.
Section III-B states the knowledge base is extracted from datasheets and manuals; errors or omissions would directly affect generated pragmas.
domain assumption Vitis and Vivado synthesis and timing logs are a faithful and sufficient feedback signal for the LLM to correct design flaws.
Section III-D feeds logs back verbatim; this assumes the LLM can interpret tool output and that the logs expose all relevant problems.
domain assumption The ten selected benchmarks from CHStone, LegUp, and MachSuite are representative of typical HLS optimization bottlenecks.
Section III-A selects 10 applications but gives no quantitative selection criteria; external validity depends on this choice.

how reviews work

0 comments

Cite this review

Pith. "Pith review of TimelyHLS: LLM-Based Timing-Aware and Architecture-Specific FPGA HLS Optimization." pith.science (2026). https://pith.science/paper/JB62XTYN

@misc{pith2026250717962,
  author       = {Pith},
  title        = {Pith review of: TimelyHLS: LLM-Based Timing-Aware and Architecture-Specific FPGA HLS Optimization},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/JB62XTYN}},
  note         = {Machine review of arXiv:2507.17962}
}

read the original abstract

Achieving timing closure and design-specific optimizations in FPGA-targeted High-Level Synthesis (HLS) remains a significant challenge due to the complex interaction between architectural constraints, resource utilization, and the absence of automated support for platform-specific pragmas. In this work, we propose TimelyHLS, a novel framework integrating Large Language Models (LLMs) with Retrieval-Augmented Generation (RAG) to automatically generate and iteratively refine HLS code optimized for FPGA-specific timing and performance requirements. TimelyHLS is driven by a structured architectural knowledge base containing FPGA-specific features, synthesis directives, and pragma templates. Given a kernel, TimelyHLS generates HLS code annotated with both timing-critical and design-specific pragmas. The synthesized RTL is then evaluated using commercial toolchains, and simulation correctness is verified against reference outputs via custom testbenches. TimelyHLS iteratively incorporates synthesis logs and performance reports into the LLM engine for refinement in the presence of functional discrepancies. Experimental results across 10 FPGA architectures and diverse benchmarks show that TimelyHLS reduces the need for manual tuning by up to 70%, while achieving up to 4x latency speedup (e.g., 3.85x for Matrix Multiplication, 3.7x for Bitonic Sort) and over 50% area savings in certain cases (e.g., 57% FF reduction in Viterbi). TimelyHLS consistently achieves timing closure and functional correctness across platforms, highlighting the effectiveness of LLM-driven, architecture-aware synthesis in automating FPGA design.

Figures

Figures reproduced from arXiv: 2507.17962 by the authors.

**Figure 1.** Overview of TimelyHLS Framework. III. OVERVIEW OF TIMELYHLS The TimelyHLS framework automates timing-aware HLS code generation through a combination of LLM, RAG, and iterative synthesis feedback [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗

**Figure 2.** Performance Speedup Ratios for Artix 7 [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗

**Figure 3.** TimelyHLS Code Example with Optimization. [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗

Figures from the paper (1 more)

**Figure 4.** Figure 4: Code Generation Success across FPGA Families. [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

32 extracted references · 29 canonical work pages

[1]

Improving classification accuracy of a machine learning approach for FPGA timing closure

Q. Yanghuaet al.,“Improving classification accuracy of a machine learning approach for FPGA timing closure”, in2016 IEEE 24th FCCM. IEEE, 2016, pp. 80–83

work page 2016
[2]

Conget al.,”FPGA HLS today: successes, challenges, and opportu- nities”,ACM TRETS, vol

J. Conget al.,”FPGA HLS today: successes, challenges, and opportu- nities”,ACM TRETS, vol. 15, no. 4, pp. 1–42, 2022

work page 2022
[3]

Towards Automatic High-Level Code Deployment on Reconfigurable Platforms: A Survey of High-Level Synthesis Tools and Toolchains

M. W. Numanet al.,“Towards Automatic High-Level Code Deployment on Reconfigurable Platforms: A Survey of High-Level Synthesis Tools and Toolchains”,IEEE Access, vol. 8, pp. 174692–174722, 2020

work page 2020
[4]

LAMDA: Learning-assisted multi-stage autotuning for FPGA design closure

E. Ustunet al.,“LAMDA: Learning-assisted multi-stage autotuning for FPGA design closure”, inFCCM. IEEE, 2019, pp. 74–77

work page 2019
[5]

Correlated multi-objective multi-fidelity optimization for HLS directives design

Q. Sunet al.,“Correlated multi-objective multi-fidelity optimization for HLS directives design”,ACM TODAES, vol. 27, no. 4, pp. 1–27, 2022

work page 2022
[6]

AMD Vitis HLS, High-Level Synthesis Tool,

AMD, “AMD Vitis HLS, High-Level Synthesis Tool,” https://www.amd.com/en/products/software/adaptive-socs-and- fpgas/vitis/vitis-hls.html

work page
[7]

HLSPilot: LLM-based high-level synthesis

C. Xionget al.,“HLSPilot: LLM-based high-level synthesis”, inProc. of 43rd IEEE/ACM ICCAD, 2024, pp. 1–9

work page 2024
[8]

Automatic hardware pragma insertion in high-level synthesis: A non-linear programming approach

S. Pougetet al.,“Automatic hardware pragma insertion in high-level synthesis: A non-linear programming approach”,ACM Tran. on Design Auto. of Elec. Sys., vol. 30, no. 2, pp. 1–44, 2025

work page 2025

Show all 32 references

[9]

Democratizing domain-specific computing

Y . Chiet al.,“Democratizing domain-specific computing”,Commun. of the ACM, vol. 66, no. 1, pp. 74–85, 2022

2022
[10]

Lahtiet al.,”High-level Synthesis for FPGAs—A Hardware Engi- neer’s Perspective”,IEEE Access, 2025

S. Lahtiet al.,”High-level Synthesis for FPGAs—A Hardware Engi- neer’s Perspective”,IEEE Access, 2025

2025
[11]

[Online]

AMD,#pragma HLS pipeline—Vitis HLS User Guide (UG1399), AMD Inc., Santa Clara, CA, USA. [Online]. Available: https://docs.amd.com/r/en-US/ug1399-vitis-hls/pragma-HLS-pipeline
[12]

Accelerating FPGA prototyping through predictive model- based HLS design space exploration

S. Liuet al.,“Accelerating FPGA prototyping through predictive model- based HLS design space exploration”, inDAC, 2019, pp. 1–6

2019
[13]

Lattice-Traversing Design Space Exploration for High Level Synthesis

L. Ferrettiet al.,“Lattice-Traversing Design Space Exploration for High Level Synthesis”, in2018 IEEE 36th ICCD, 2018, pp. 210–217

2018
[14]

AutoDSE: Enabling software programmers to design efficient FPGA accelerators

A. Sohrabizadehet al.,“AutoDSE: Enabling software programmers to design efficient FPGA accelerators”,ACM TODAES, vol. 27, no. 4, pp. 1–27, 2022

2022
[15]

Robust GNN-based representation learning for HLS

A.Sohrabizadehet al.,“Robust GNN-based representation learning for HLS”, in2023 IEEE/ACM ICCAD, IEEE, 2023, pp. 1–9

2023
[16]

Prakriyaet al.,”LIFT: LLM-based pragma insertion for HLS via GNN supervised fine-tuning”,arXiv, preprint arXiv:2504.21187, 2025

N. Prakriyaet al.,”LIFT: LLM-based pragma insertion for HLS via GNN supervised fine-tuning”,arXiv, preprint arXiv:2504.21187, 2025

2025 arXiv
[17]

Sherlock: A multi-objective design space exploration framework

Q. Gautieret al.,“Sherlock: A multi-objective design space exploration framework”,ACM TODAES, vol. 27, no. 4, pp. 1–20, 2022

2022
[18]

Check your facts and try again: Improving large language models with external knowledge and automated feedback

B. Penget al.,“Check your facts and try again: Improving large language models with external knowledge and automated feedback”, arXiv, preprint arXiv:2302.12813, 2023

2023 arXiv
[19]

Opentuner: An extensible framework for program autotuning

J. Anselet al.,“Opentuner: An extensible framework for program autotuning”, inProc. 23rd Int. Conf. on Par. arch. and comp., 2014, pp. 303–316

2014
[20]

Efficient task transfer for HLS DSE

Z. Dinget al.,“Efficient task transfer for HLS DSE”, inProc. 43rd IEEE/ACM ICCAD, 2024, pp. 1–9

2024
[21]

Exploiting loop-array dependencies to accelerate the design space exploration with high level synthesis

N. K. Phamet al.,“Exploiting loop-array dependencies to accelerate the design space exploration with high level synthesis”, in2015 IEEE DATE. IEEE, 2015, pp. 157–162

2015
[22]

Lin-analyzer: A high-level performance analysis tool for FPGA-based accelerators

G. Zhonget al.,“Lin-analyzer: A high-level performance analysis tool for FPGA-based accelerators”, inProc. 53rd DAC, 2016, pp. 1–6

2016
[23]

COMBA: A comprehensive model-based analysis frame- work for high level synthesis of real applications

J. Zhaoet al.,“COMBA: A comprehensive model-based analysis frame- work for high level synthesis of real applications”, in2017 IEEE/ACM ICCAD. IEEE, 2017, pp. 430–437

2017
[24]

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

H. Yeet al.,“ScaleHLS: A new scalable high-level synthesis framework on multi-level intermediate representation”, in2022 IEEE HPCA, IEEE, 2022, pp. 741–755

2022
[25]

Autoannotate: Reinforcement learning based code annotation for high level synthesis

H. Shahzadet al.,“Autoannotate: Reinforcement learning based code annotation for high level synthesis”, in2024 25th ISQED, IEEE, 2024, pp. 1–9

2024
[26]

AutoHLS: Learning to Accelerate Design Space Exploration for HLS Designs

M. R. Ahmedet al.,“AutoHLS: Learning to Accelerate Design Space Exploration for HLS Designs”, in2023 IEEE 66th MWSCAS, IEEE, 2023, pp. 491–495

2023
[27]

Evolutionary large language models for hardware security: A comparative survey

M. Akyashet al.,“Evolutionary large language models for hardware security: A comparative survey”, inProc. of the great lakes symposium on VLSI 2024, 2024, pp. 496–501

2024
[28]

LLM-IFT: LLM-Powered Information Flow Track- ing for Secure Hardware

N. Mashnooret al.,“LLM-IFT: LLM-Powered Information Flow Track- ing for Secure Hardware”, in2025 IEEE 43rd VTS. IEEE, 2025, pp. 1–5

2025
[29]

RTL++: Graph-enhanced LLM for RTL Code Generation

M. Akyashet al.,“RTL++: Graph-enhanced LLM for RTL Code Generation”,arXiv, preprint arXiv:2505.13479, 2025

2025 arXiv
[30]

CHStone: A benchmark program suite for practical C-based high-level synthesis

Y . Haraet al.,“CHStone: A benchmark program suite for practical C-based high-level synthesis”, in2008 IEEE ISCAS. IEEE, 2008, pp. 1192–1195

2008
[31]

LegUp: An open-source high-level synthesis tool for FPGA-based processor/accelerator systems

A. Caniset al.,“LegUp: An open-source high-level synthesis tool for FPGA-based processor/accelerator systems”,ACM TECS, vol. 13, no. 2, pp. 1–27, 2013

2013
[32]

MachSuite: Benchmarks for accelerator design and customized architectures

B. Reagenet al.,“MachSuite: Benchmarks for accelerator design and customized architectures”, in2014 IEEE IISWC. IEEE, 2014, pp. 110– 119

2014

Pith tools

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

[1] [1]

Improving classification accuracy of a machine learning approach for FPGA timing closure

Q. Yanghuaet al.,“Improving classification accuracy of a machine learning approach for FPGA timing closure”, in2016 IEEE 24th FCCM. IEEE, 2016, pp. 80–83

work page 2016

[2] [2]

Conget al.,”FPGA HLS today: successes, challenges, and opportu- nities”,ACM TRETS, vol

J. Conget al.,”FPGA HLS today: successes, challenges, and opportu- nities”,ACM TRETS, vol. 15, no. 4, pp. 1–42, 2022

work page 2022

[3] [3]

Towards Automatic High-Level Code Deployment on Reconfigurable Platforms: A Survey of High-Level Synthesis Tools and Toolchains

M. W. Numanet al.,“Towards Automatic High-Level Code Deployment on Reconfigurable Platforms: A Survey of High-Level Synthesis Tools and Toolchains”,IEEE Access, vol. 8, pp. 174692–174722, 2020

work page 2020

[4] [4]

LAMDA: Learning-assisted multi-stage autotuning for FPGA design closure

E. Ustunet al.,“LAMDA: Learning-assisted multi-stage autotuning for FPGA design closure”, inFCCM. IEEE, 2019, pp. 74–77

work page 2019

[5] [5]

Correlated multi-objective multi-fidelity optimization for HLS directives design

Q. Sunet al.,“Correlated multi-objective multi-fidelity optimization for HLS directives design”,ACM TODAES, vol. 27, no. 4, pp. 1–27, 2022

work page 2022

[6] [6]

AMD Vitis HLS, High-Level Synthesis Tool,

AMD, “AMD Vitis HLS, High-Level Synthesis Tool,” https://www.amd.com/en/products/software/adaptive-socs-and- fpgas/vitis/vitis-hls.html

work page

[7] [7]

HLSPilot: LLM-based high-level synthesis

C. Xionget al.,“HLSPilot: LLM-based high-level synthesis”, inProc. of 43rd IEEE/ACM ICCAD, 2024, pp. 1–9

work page 2024

[8] [8]

Automatic hardware pragma insertion in high-level synthesis: A non-linear programming approach

S. Pougetet al.,“Automatic hardware pragma insertion in high-level synthesis: A non-linear programming approach”,ACM Tran. on Design Auto. of Elec. Sys., vol. 30, no. 2, pp. 1–44, 2025

work page 2025