TimelyHLS: LLM-Based FPGA HLS Optimization

• TimelyHLS is an FPGA-oriented optimization framework that uses LLM and retrieval-augmented generation to tailor HLS code with timing-aware, architecture-specific directives.
• It implements a closed-loop feedback system by integrating synthesis logs, simulation results, and tool feedback from Vitis HLS and Vivado to ensure functional correctness and timing closure.
• The framework significantly reduces manual tuning with up to 70% less effort, achieving up to 4x latency speedup and notable resource savings across diverse FPGA targets.

TimelyHLS is an FPGA-oriented High-Level Synthesis optimization framework that combines a LLM with Retrieval-Augmented Generation to generate and iteratively refine HLS code under timing-closure and architecture-specific constraints. Introduced in “TimelyHLS: LLM-Based Timing-Aware and Architecture-Specific FPGA HLS Optimization” (Mashnoor et al., 23 Jul 2025), it is designed to take a kernel plus target-platform metadata, insert timing-critical and design-specific pragmas, verify correctness through HLS- and RTL-level flows, and repeatedly revise the design using synthesis logs, timing reports, and simulation results until the implementation is functionally correct, synthesizable, and free of negative slack.

1. Problem formulation and positioning

TimelyHLS is motivated by the persistent difficulty of timing closure in FPGA HLS. In the setting described by the paper, timing closure remains hard even when design entry is raised from RTL to C/C++, because the final result depends on the interaction among algorithm structure, HLS scheduling and binding, pragma selection, architecture-specific resources, and downstream effects such as routing delay and congestion. The paper identifies high target clock rates, large interconnected logic structures, deep logic pipelines, complex routing effects, and critical paths that are hard to predict from source code as recurring causes of failure. It also emphasizes that modern HLS tools still depend heavily on manual directives such as loop pipelining, loop unrolling, memory and array partitioning, interface directives, and dataflow organization, and that these directives interact combinatorially and differ across toolchains and FPGA families (Mashnoor et al., 23 Jul 2025).

Within that framing, TimelyHLS is presented as a response to a “closure gap”: current tools still require substantial manual intervention to meet strict timing and platform-specific optimization requirements. The framework is explicitly aimed at producing designs that are functionally correct, synthesizable, architecture-specific, and timing-closure-friendly. The paper situates it against heuristic and DSE-based autotuning, analytical or model-based methods, learning-based methods, and prior LLM-for-HLS approaches, and argues that the missing combination is timing awareness, architecture-specific grounding, tool-feedback-driven iterative refinement, and structured retrieval from a curated FPGA knowledge base. A common misconception is that TimelyHLS is simply a prompt-based code generator; the paper instead describes a closed-loop optimization system whose defining feature is repeated interaction with commercial synthesis and implementation tools.

2. Knowledge base, prompting, and code generation

The central generative mechanism is an LLM coupled to a structured architectural knowledge base through Retrieval-Augmented Generation. The knowledge base is built from official FPGA datasheets, vendor HLS user guides, architectural reference manuals, and vendor tool documentation. It stores FPGA-specific features, synthesis directives, pragma templates, and optimization heuristics. The examples given in the paper include device family and part metadata, counts and capacities of DSPs, BRAMs, and LUTs, timing constraints, supported or recommended HLS directives, pragma forms for pipelining, unrolling, and array partitioning, architecture-aware coding patterns, and platform-aware interface styles such as AXI interfaces (Mashnoor et al., 23 Jul 2025).

Prompt formation combines a task-specific kernel description with performance goals, loop behavior or memory-access constraints, target FPGA metadata, and retrieved platform constraints and optimization guidance. The LLM is then asked to generate HLS-compliant C/C++ annotated with directives. The paper conceptually mentions Code LLaMA or GPT-4 in the description, and the evaluated models are OpenAI GPT-4 and Anthropic Claude-3.5-Sonnet, both run with default temperature 0.7. TimelyHLS is described as inserting both timing-critical pragmas and design-specific pragmas. Named examples include #pragma HLS pipeline, unroll, array_partition, memory partitioning, AXI interfaces, and structural changes such as sparsemux insertion in Bitonic Sort. The paper also presents itself as “the first framework to integrate an LLM with RAG for FPGA-specific HLS code generation” (Mashnoor et al., 23 Jul 2025).

3. Closed-loop verification and refinement

The operational core of TimelyHLS is a two-stage verification-and-refinement pipeline. At the HLS level, generated code is compiled and simulated in Xilinx Vitis HLS 2024.2. The framework checks whether the candidate is syntactically valid, HLS-synthesizable, and functionally correct at the C/HLS level. If it fails, TimelyHLS extracts syntax errors, resource binding issues, pipeline depth violations, and simulation mismatches from Vitis logs and feeds them back into the LLM as an augmented prompt. This loop continues until the design passes HLS synthesis and HLS functional simulation (Mashnoor et al., 23 Jul 2025).

After HLS-level success, TimelyHLS exports RTL and proceeds to Xilinx Vivado 2024.2. This stage evaluates RTL synthesizability, timing closure, resource utilization, and behavioral equivalence at RTL simulation. The paper states that post-synthesis reports are inspected for Worst Negative Slack, Total Negative Slack, resource utilization, and validity or synthesizability of the generated RTL, and that RTL testbenches are generated to validate equivalence against expected outputs or HLS outputs. If this stage fails, the framework extracts synthesis errors, critical path reports, and functional mismatches and again feeds them to the LLM. The iterative loop terminates only when three pass conditions are met: functional simulation succeeds at both HLS and RTL levels, Vivado can synthesize the design for the target FPGA architecture, and timing closure is achieved with no negative slack. The paper does not provide formal pseudocode, retrieval scoring equations, loss functions, or update rules; it describes TimelyHLS operationally as a closed-loop heuristic optimizer rather than mathematically (Mashnoor et al., 23 Jul 2025).

4. Architecture awareness and target coverage

A defining claim of TimelyHLS is architecture-specific adaptation. The prompt includes target metadata such as device family, number of DSPs, BRAMs, LUTs, and timing constraints, and the retrieval layer supplies platform-aware directive and coding guidance. Although the experiments are run through Xilinx Vitis HLS and Vivado, the paper states that prompts and scripts are configurable and parameterized so as to be reusable for different vendors. In practice, the reported evaluation covers ten Xilinx targets spanning embedded, mid-range, and high-end devices (Mashnoor et al., 23 Jul 2025).

FPGA family	Device
Zynq	xc7z020-clg484-1
Zynq UltraScale+	xczu3eg-sbva484-1-e
Artix-7	xc7a200tfbg676-2
Kintex-7	xc7k325tffg676-2
Spartan-7	xc7s50-ftgb196-2
Virtex UltraScale+	xcvu9p-flgb2104-2-e
Virtex UltraScale+	xcvu11p-flga2577-1-e
Virtex UltraScale+	xcvu9p-flgb2104-1-e
Kintex UltraScale+	xck26-sfvc784-2LV-c
Versal AI Edge	xave2602-nsvh1369-1LJ-i-L

The paper makes clear that TimelyHLS reasons about timing constraints, critical-path behavior, memory hierarchy and memory-access bottlenecks, DSP/BRAM/LUT/FF tradeoffs, routing congestion, initiation interval, loop unrolling, pipelining, array partitioning, dataflow, and interface pragmas. Its behavior is described as heuristic and prompt-driven rather than cost-model-driven. On resource-constrained devices it may favor compact and efficient structures; on larger devices it may employ more advanced interface structures; when timing pressure is high it may increase parallelism and logic duplication; and when latency is already close to optimal it may instead favor area reduction. The paper’s examples include loop hierarchy restructuring plus pipelining, unrolling, and array partitioning for Matrix Multiplication; loop pipelining and sparsemux support for Bitonic Sort; timing repair through heavy DSP usage in Vector Dot Product; and area reduction in Viterbi.

5. Experimental methodology and quantitative behavior

The evaluation uses ten representative HLS applications drawn from CHStone, LegUp benchmarks, and MachSuite: Matrix Multiplication, Convolution, Vector Dot Product, Vector Addition, Bitonic Sort, Viterbi Decoder, Adaptive FIR Filter (LMS), CORDIC Algorithm, Matrix-Vector Multiplication, and Needleman–Wunsch. The paper also names the dominant optimization difficulty for several of them, such as long critical paths from nested loops and pipelining inefficiencies in Matrix Multiplication, timing issues from memory access and computation overlap in Convolution, deep pipelines and routing congestion in Bitonic Sort, feedback-loop latency in LMS, and irregular memory access patterns causing critical-path delay and low throughput in Needleman–Wunsch. Experiments were run on Ubuntu 24.04.2 LTS using Xilinx Vitis HLS 2024.2 and Vivado 2024.2, on a machine with a 13th Gen Intel Core i7-13700 and 32 GB RAM. The main baseline is the original “Base” implementation; the paper discusses AutoDSE, HARP, LIFT, and HLSPilot in related work, but does not report direct quantitative head-to-head comparisons with those systems (Mashnoor et al., 23 Jul 2025).

The headline results are a reduction in manual tuning by up to 70%, up to 4x latency speedup, and over 50% area savings in some cases. The abstract gives 3.85x latency speedup for Matrix Multiplication, 3.7x for Bitonic Sort, and 57% FF reduction in Viterbi. The paper also states that TimelyHLS consistently achieves timing closure and functional correctness across platforms. Timing repair is shown explicitly in slack figures for at least two kernels: Matrix Multiplication improves from -0.08 ns to 0.1 ns, and Vector Dot Product from -0.54 ns to 0.54 ns. Loop-level structural changes are also reported: Matrix Multiplication II is reduced from 16 to 1–2, Bitonic Sort changes from Non-pip. to All II = 1, Matrix-Vector Multiplication from Not pip. to Pip. (II=1), Vector Addition from 1–2 to 1, and CORDIC from 2 to Unrolled (Mashnoor et al., 23 Jul 2025).

The results are not uniformly monotone across all metrics, which is important for interpreting the system correctly. Matrix Multiplication latency is reduced from 16,531 cycles to 4,277 cycles, aligning with the approximately 3.85x speedup claim. Bitonic Sort is reported at 3.6x speedup in the body and 3.7x in the abstract. By contrast, Vector Dot Product is an explicit mixed tradeoff: latency increases from 519 cycles to 640 cycles while DSP usage rises from 5 to 160, and the paper uses this example to show that timing closure can require aggressive operator duplication. Resource changes are similarly context-dependent. Viterbi shows the clearest area-saving case, with 57.34% FF reduction and about 48% LUT reduction on Artix-7 and Spartan-7, while several other kernels spend additional LUTs or FFs to gain throughput or repair timing. These results support an interpretation of TimelyHLS as an architecture- and constraint-sensitive optimizer rather than a uniformly dominant one.

6. Limitations, reproducibility, and significance

The paper leaves several elements underspecified. It provides no explicit objective functions, retrieval formulas, loss functions, scoring functions, or iterative update equations. It also lacks a formal ablation isolating the effects of RAG, the structured knowledge base, iterative synthesis feedback, or the choice of LLM. Reproducibility is partial: the paper reports the operating system, toolchain versions, CPU, RAM, LLMs, temperature, knowledge-base sources, and benchmark sources, but does not provide exact prompt templates, the retrieval or indexing implementation, the embedding model, document chunking strategy, retrieval ranking scheme, stopping criteria beyond the high-level pass conditions, a code release link, a benchmark repository, exact iteration counts per benchmark, or an artifact release (Mashnoor et al., 23 Jul 2025).

The evaluation also imposes boundary conditions on broader claims. Although the framework is described as configurable for different vendors, the reported experiments are entirely on Xilinx Vitis HLS, Vivado, and Xilinx families. Failures are said to be concentrated in complex designs, irregular memory-access kernels, feedback-heavy loops, and resource-constrained FPGAs. The framework depends heavily on the quality and informativeness of tool feedback and on the coverage of the documentation-derived knowledge base. It also anticipates ordinary LLM failure modes—syntax errors, invalid or unsupported pragmas, resource binding issues, pipeline violations, functionally incorrect code, and RTL-level mismatches—which is precisely why the iterative correction loops are necessary. For these reasons, TimelyHLS should not be understood as a lightweight single-prompt workflow; the paper presents it as a tool-integrated optimization system (Mashnoor et al., 23 Jul 2025).

Its broader significance lies in the way it reframes HLS automation. TimelyHLS does not replace synthesis, implementation, or testbench-driven verification; it wraps them in a feedback loop grounded in architecture-specific documentation and optimization templates. This suggests a model of LLM-assisted FPGA development in which the LLM is not treated as a stand-alone code generator, but as an overview-aware rewriting engine whose outputs are constrained by platform metadata, directive semantics, and implementation reports. In that sense, TimelyHLS is best understood as a practical attempt to close the distance between generative code production and the physical-design realities of FPGA timing closure.