ChatHLS: Towards Systematic Design Automation and Optimization for
High-Level Synthesis
Runkai Li1,2 , Jia Xiong1,2 , Xiuyuan He1 , Jiaqi Lv2 , Jieru Zhao3 , Xi Wang1,2
arXiv:2507.00642v2 [cs.AR] 12 Aug 2025
1
National Center of Technology Innovation for EDA, Nanjing, China
2
Southeast University, Nanjing, China
3
Shanghai Jiao Tong University, Shanghai, China
xi.wang@seu.edu.cn
Abstract
The increasing complexity of computational demands has
spurred the adoption of domain-specific accelerators, yet traditional hardware design methodologies remain constrained
by prolonged development and verification cycles. HighLevel Synthesis (HLS) bridges the software-hardware gap by
enabling hardware design from high-level languages. However, its widespread adoption is hindered by strict coding constraints and intricate hardware-specific optimizations. To address these challenges, we introduce ChatHLS, an agile HLS
design automation workflow that leverages fine-tuned LLMs
integrated within a multi-agent framework for HLS-specific
error correction and design optimization. Through navigating
LLM training with a novel verification-oriented data augmentation paradigm, ChatHLS achieves an average repair pass
rate of 82.7% over 612 error cases. Furthermore, by enabling
optimization reasoning within practical computational budgets, ChatHLS delivers performance improvements ranging
from 1.9× to 14.8× on resource-constrained kernels, attaining a 3.6× average speedup compared to SOTA approaches.
These results underscore the potential of ChatHLS in substantially expediting hardware development cycles while upholding rigorous standards of design reliability and quality.
Introduction
The exponential growth in computational requirements has
catalyzed the development of domain-specific accelerators
(DSAs) (Kinzer et al. 2021). However, traditional IC design
and verification processes are lengthy and extremely reliant
on manual effort, rendering them incapable of meeting the
agile development needs for DSA chips. High-Level Synthesis (HLS) emerges as a pivotal technology that bridges the
software-hardware gap through C/C++-like behavioral descriptions and substantially accelerates the traditional hardware development process (Cong et al. 2022). However,
to effectively transform software algorithms into hardware
implementations, HLS tools impose specific constraints on
the programming paradigm, inducing redundant portability overhead. Consequently, developers must navigate strict
coding restrictions for HLS-compatible C code (HLS-C)
while managing delicate hardware-specific optimizations.
This learning curve results in a minimally automated and
time-consuming process that poses hurdles for software engineers seeking to leverage HLS for hardware acceleration.
Traditional HLS Development Workflow
(a) Tuning 20+ Commonly Used Directives
Lat. QoR
Util. Feedback
Cloud
...
Robotics
Genome
Sequencing
</>
</>
Cpp
HLS-C
(b)
HLS Tool
C-Sim
Co-Sim
C-Synth
QoR
Report
Satisfy?
</>
RTL
Log
Pass?
Error
Message
Debugging Involving Several Person-month
Figure 1: Bottlenecks in HLS development: (a) HLS design
optimzation trade-off and (b) HLS-specific error diagnosis.
Developing HLS designs requires substantial hardware
expertise, as depicted in Figure 1, and ensuring consistency
between software code and synthesized register-transfer
level (RTL) code remains time-consuming and error-prone.
Furthermore, examining the compatibility and quality of
HLS design constitutes a trial-and-error process (Zhang
et al. 2022). Current approaches to address HLS challenges
remain limited. Domain-specific languages (DSLs), while
simplifying hardware description, trade expressivity for simplicity and introduce extra learning costs (Chen et al. 2024;
Nigam et al. 2020; Lai et al. 2019). Alternatively, automated
code transformation tools attempt to directly refactor C code
for HLS compatibility (Lau et al. 2020; Zhang et al. 2022).
However, their effectiveness is often hampered by a reliance
on predefined templates and suboptimal convergence.
Recent advancements in Large Language Models (LLMs)
have demonstrated remarkable capabilities in the comprehension of mainstream programming languages (Tian et al.
2024; Hou et al. 2024), with applications in RTL code generation and error correction (Wang et al. 2024; Xu et al.
2024a). While LLMs demonstrate potential in streamlining
hardware design and enabling design optimization, particularly in HLS development, their effectiveness is limited by
the scarcity of high-quality datasets (Fu et al. 2023). Current
approaches primarily leverage retrieval-augmented generation (RAG) to provide domain-specific context for LLMs to
aid HLS-C generation and debugging (Xiong et al. 2024; Xu
et al. 2024b). However, RAG may yield inconsistent and unexpected results due to imprecise context retrieval and the
inherent limitations of the available datasets.
Despite these challenges with RAG-based approaches, the
characteristics of HLS present unique opportunities for LLM
integration. HLS abstracts hardware design into behavioral
descriptions, enabling LLMs with established proficiency in
mainstream programming languages to be effectively utilized in hardware development. Building on this insight, we
propose ChatHLS, an automated end-to-end workflow designed to streamline HLS design. We develop a novel data
augmentation method for training LLMs to enhance their debugging capabilities in HLS-specific errors. Furthermore, by
learning from design quality feedback, ChatHLS is able to
navigate the complex design space, effectively striking a balance between performance and resource consumption.
We summarize the contributions of this paper as follows:
• We introduce ChatHLS, a novel fine-tuned multi-agent
system for agile HLS design. By integrating LLMs with
HLS tools through specialized agents, ChatHLS enables
efficient design optimization while ensuring correctness.
• We propose VODA, an adaptive verification dataset construction paradigm. VODA automates the capture and increment of error cases detected in HLS-C generation, pioneering a new method for few-shot learning in HLS.
• We develop HLSFixer, which aligns LLMs with expert
debugging patterns through a hierarchical and collaborative approach to rectify HLS-specific errors, achieving an
82.7% accuracy on 612 test cases in error diagnosis.
• We propose HLSTuner, which prompts LLMs to navigate exquisite trade-offs from design quality feedback
through an iterative refinement loop. HLSTuner achieves
a 3.6× average speedup over SOTA methods.
Related Work
Traditional Alignment to HLS Design
Unlike C/C++ programming, HLS-C development demands
careful consideration of compiler limitations and quality of
results (QoR). Developers must refactor source codes to
align with HLS programming paradigms and strategically
apply hardware-specific directives. However, the Cartesian
product of diverse directives constitutes an overwhelming
design space (Schafer and Wang 2020). Traditional design
space exploration methods rely on heuristics (Sohrabizadeh
et al. 2022) or prediction models (Kuang et al. 2023; Li et al.
2025). Nevertheless, heuristic-based approaches require numerous iterations to converge. Learning-based approaches
have limited generalization beyond the training distribution.
Domain-specific languages (DSLs) abstract the semantics
of algorithmic representations and hardware optimization in
HLS (Ye et al. 2022; Chen et al. 2024). While DSLs mitigate certain coding pitfalls, they introduce additional learning curves and exhibit limited expressivity, restricting applicability to nuanced use cases. HeteroRefactor automates the
refactoring of C to HLS-C through dynamic invariant analysis (Lau et al. 2020). HeteroGen advances this approach with
fuzzing tests for automated test input generation and exception handling (Zhang et al. 2022). However, both solutions
still require iterative validation and manual oversight to ensure code synthesizability in HLS tool, and fail to handle
functional errors in static operating modes.
20 40
60 80
Claude 3.5 Sonnet
GPT-4o
Llama3.1-8B
DeepSeek-Coder-6.7B
HLS Designs
Figure 2: Pass rates of existing LLMs in repairing HLSspecific errors across various HLS designs.
LLM-Aided HLS Design
Scaling laws indicate that the effectiveness of LLMs in
domain-specific tasks like hardware design is limited by the
availability of comprehensive, specialized datasets (Chang
et al. 2024). While initial applications in hardware description languages (HDL) demonstrated capabilities of LLMs
in RTL code generation and debugging through various approaches (Tsai, Liu, and Ren 2024; Thakur et al. 2024; Wang
et al. 2024; Xu et al. 2024a), they still struggled with syntax
correctness and hardware optimization.
The limitations in HDL applications have catalyzed research interest in HLS. Previous work has incorporated
retrieval-augmented generation (RAG) to provide domainspecific expertise related to HLS, with the aim of fixing errors caused by C algorithms incompatible with vendor HLS
tools and design optimization (Xu et al. 2024b; Xiong et al.
2024; Xu, Hu, and Huang 2024). However, RAG struggles
to provide accurate and comprehensive search results, which
may impair the reasoning capabilities of LLMs due to partially matched contexts (Tang et al. 2025; Xia et al. 2025).
Prior efforts have demonstrated that fine-tuning LLMs can
improve the accuracy of generating HLS designs from specifications (Gai et al. 2025). While these approaches support
syntax and function error correction, they lack a comprehensive analysis of HLS compatibility issues.
Despite recent advances in LLM-driven HLS development, two critical challenges continue to impede progress:
• Limited HLS-C generation and debugging capabilities. Current LLMs exhibit significant limitations in understanding HLS-C programming constraints and optimization principles, as shown in Figure 2, leading to unreliable code generation. Meanwhile, the acquisition of
HLS-C is constrained by specialized development environments and the need for hardware design expertise.
• Complexity of HLS design optimization. Optimizing
HLS design involves exploring an immense design space.
The vast combination of directives, along with their nonlinear QoR impacts, requires extensive optimization experience. These limitations result in suboptimal selection and placement of directives, ultimately compromising the quality of hardware implementations.
A: ChatHLS Workflow
Phase 1: HLS-C Generation
Phase 2: HLS-C Debugging
Fail
Augmented
CoT
LLM ④ :
Bug Fixing
</>
LLM ① :
HLS GEN
Cpp
LLM ② :
HLSTuner
HLS
Tool
PASS?
Training
Training
</>
#pragma
Insertion
Source
Code
Labeling
</>
HLS-C
Optimized
z
Code
LLM ⑧: Bug
Insertion
HLS-C
HLS
Tool
LLM⑦: Opt
Reasoning
Opt
CoT
Opt
Dataset
Loop/Array
z
i Information
QoR Pass </>
Check
HLS-C
Output
User
Requirement
C: Debugging Dataset Construction
</>
z
QoR
</>
HLS-C
LLM Group ⑤:
HLSFixer
HLSFixer
... Bug Analysis
Type)
RAG
HLS-C
CoT Candidates
LLM③ :
Bug Analysis (Unknown
Yes
B: Optimization Dataset Construction
HLS Dataset
Collection
z
CoT (Known Type)
Testing
Input
LLM⑥:
Scoring
No
</>
Buggy
z
Code
HLS-C
HLS
Tool
Bug
Type
BugRAG
Bug
Case
LLM⑨: Debug
Reasoning
Debug
CoT
Error
Message
Debugging
Dataset
z
Figure 3: ChatHLS workflow and dataset construction.
Bug Insertion Workflow
Design & Philosophy
</>
ChatHLS Architecture & Workflow
Based on the aforementioned challenges, we propose the
ChatHLS workflow to optimize HLS designs while incorporating robust code error correction capability. As illustrated in Figure 3.A, the architecture comprises two primary
phases: HLS-C generation and HLS-C debugging.
In the HLS-C generation phase, LLM 1 performs targeted code transformations on the input C algorithm, leveraging retrieved HLS-related context. A fine-tuned LLM 2
then conducts optimization on the generated HLS design,
providing reasonable directive allocation strategies based on
comprehensive analysis and scheduling. However, the inherent hallucinations of LLMs and their misalignment with
HLS specifications may introduce errors during optimization, such as pragma conflicts and type confusion during directive selection and embedding.
The HLS-C debugging phase is designed to ensure the
correctness of the generated HLS-C within ChatHLS workflow. Initially, the generated code is tested by the HLS tool.
Upon detection of errors during C simulation and synthesis,
we parse the compilation report and pair it with the erroneous code for a fine-tuned LLM 3 specifically tailored for
error diagnosis. This LLM formulates modification suggestions with analytical explanations, which are then passed to
LLM 4 . Operating under strict instruction adherence, this
agent integrates the suggestions to implement fixing.
For errors that are beyond the training distribution, we forward the error message to LLM Group 5 for multifaceted
assessment. Subsequently, LLM 6 evaluates the proposed
solutions and selects the most appropriate one to repair
the code. Furthermore, the errors encountered at this stage
are collected into datasets, thereby continuously enhancing
the capability of our debugging agent. The efficiency and
robustness of ChatHLS is ensured by semantic alignment
among multi-agents and parsable output formats.
HLS-C
Bug
Info
Source
Code
Verification
Error
Message
LLM ⑧：Bug
Insertion
</>
HLS-C
Buggy
Code
Retrieval
Type: [PUC (Pipline and Unroll Conflict)]
Description:
BugRAG
#pragma HLS pipeline & #pragma HLS unroll are applied to
the same loop or nested loops.
Error Example:
LLM⑩：
Bug Type
Analysis
for (i = 0; i < m; i++) {
#pragma HLS pipeline II=1
#pragma HLS unroll ... ...
}
Synthesis Error Message:
New Bug
Type?
Yes
'C-SYNTH Failure Reason':Source synthesis failed
'C-SYNTH Failure Details':"ERROR:[HLS 214-274]
Error Analysis: [Conflict Explanation]
Verification-Oriented Data Augmentation
Figure 4: Verification dataset construction workflow.
Verification-Oriented Data Augmentation
The complexity of HLS, encompassing hardware specification and optimization, extends beyond the knowledge
scope of general LLMs, hindering their application in hardware design automation. To address this deficiency, we propose a Verification-Oriented Data Augmentation (VODA)
paradigm. The philosophy of VODA is to construct and progressively expand a high-quality dataset of buggy code with
HLS-specific errors for fine-tuning LLMs to improve their
error correction capabilities in HLS.
We design BugRAG that dynamically collects and expands the range of HLS-specific error types. Drawing on a
comprehensive analysis of AMD forum inquiries, prior research (Zhang et al. 2022; Xu et al. 2024b; Wan et al. 2024),
and error cases incrementally expanded through VODA, we
categorize error cases encountered during HLS-C generation
and optimization phases, as representative cases shown in
Table 1. These cases are structured into modular error slices
within the BugRAG, incorporating mnemonic identifiers to
improve retrieval accuracy (Wan et al. 2024).
Category
Error Type
Error Message
Debugging Instruction
Dynamic Array Error: In function A: Undefined Cause: Dynamic memory allocation is not synthesizable. ⇒ Diagnosis: Replace
dynamic allocation malloc() with fixed-size static array A[].
Allocation (DAA) function malloc
HLS-C
Loop Index Out of Error: C TB testing failed, stop
Incompatible
Bounds (OOB) generating test vectors
Errors
Pointer Access Error: @E Simulation failed:
Error (PTR)
SIGSEGV
Cause: Out-of-bounds access creates faulty hardware, failing HLS co-simulation.
⇒ Diagnosis: Analyze array access patterns and correct loop boundary <= to <.
Cause:Unconstrained pointers are not synthesizable. ⇒ Diagnosis: Replace unsafe
pointer *p with explicit static array p[] to produce determined hardware.
Dataflow-Pipeline Error: PIPELINE and DATAFLOW Cause: Apply conflict directives at same scope. ⇒ Diagnosis: Resolve producerconsumer dependency by removing DATAFLOW from logically interdependent loop.
Conflict (DPC) are incompatible
HLS-C
Semantic
Errors
Error: Forced nested loop full
UNROLL cause synth time-out
Cause: PIPELINE on deep nested or large footprint loops cause resource explosion.
⇒ Diagnosis: Analyze loop structure and restrict PIPELINE to critical inner loops.
Array Partition Warning: PARTITION failed:
Invalid Dim (AID) size mismatch or dim too deep
Cause: PARTITION exceeds declared dimensions. ⇒ Diagnosis: Correct dim parameter to match array declaration and intended memory access pattern.
Multi-Layer
Pipeline (MLP)
Table 1: Examples of BugRAG entries and representative HLS-specific error types.
VODA Architecture. VODA operates in two stages. The
first stage is the continuous expansion of error cases to populate the error repository, as illustrated in Figure 4. When
an HLS design fails verification, an analysis agent (LLM
10 ) examines the erroneous code and error messages parsed
from the HLS tool test results. It then generates an error slice
containing descriptions, examples, and analysis of a specific
HLS error type and queries BugRAG to check for existing
entries. If unmatched, the analysis agent identifies a new error type and integrates the slice into the error repository.
In the second stage, we generate a verification dataset
through a controlled bug injection process. This process is
facilitated by an insertion agent (LLM 8 ), which synthesizes buggy code by integrating retrieved error slices from
BugRAG as context. The agent assesses the contextual applicability of potential bugs, reducing the probability that the
LLM forcibly generates trivial results.
HLSFixer
VODA reveals that the incorporation of verification phase
can mitigate the limitations of LLMs in HLS design generation capabilities. Building upon this insight, we develop
HLSFixer, a hierarchical code repair framework designed
to improve the accuracy of HLS-C error correction. As depicted in Figure 5, the debugging process identifies and addresses issues in HLS-C by first detecting errors from the
parsed error message. LLM 3 then examines the causes of
these errors and provides debugging instructions. After applying targeted modifications to the HLS-C based on this
analysis, HLSFixer retests the corrected HLS design against
the golden results to ensure semantic consistency between
the design intent before and after the modification.
When LLM 3 fails to correct errors in one attempt, we
implement a multifaceted evaluation strategy to refine the
debugging instructions. We provide the modified code and
test results to LLM Group 5 . Debugging instructions from
various LLMs are then compiled and evaluated by the scoring agent 6 , which selects the optimal suggestion to improve the quality of debugging instruction feedback.
Training Strategy. To train the analysis agent, as shown
in Figure 3.C, we decouple expert debugging patterns into
learnable multi-stage reasoning templates to hierarchically
perform error localization, diagnosis, and repair. For subtle
errors, we compose testbench with golden results to generate error messages from the HLS tool. Their messages help
LLM to pinpoint the error location and suggest fine-grained
modifications, rather than rewriting the code from scratch.
We apply LLM 9 to integrate accurate debugging instructions derived from reviewing golden HLS-C into chain-ofthought (CoT), pairing buggy code with corresponding error messages. We constructed a dataset comprising buggy
code, associated error messages, and accurate debugging instructions. This versatile dataset is suitable for fine-tuning
various pre-trained LLMs by translating complex code correction workflows into natural language descriptions aligned
with the diagnostic patterns of experienced engineers.
We further employ direct preference optimization (DPO)
(Rafailov et al. 2024) in HLSFixer, which learns implicit reward functions from a preference dataset composed of contrastive CoT and non-CoT pairs. CoT helps bridge the gap
between ambiguous error messages and HLS-specific errors.
This method enables the alignment of the fine-tuned LLM
3 with expert debugging preferences while mitigating policy collapse risks inherent in conventional RLHF reward
modeling. The integration of DPO with our multi-LLM verification system effectively reinforces the hierarchical reasoning capabilities of HLSFixer.
HLSTuner
Given the overwhelming design space of HLS-C, we propose HLSTuner, an HLS design optimization framework,
to automate the directive allocation and embedding. As depicted in Figure 5, the optimization workflow initiates with
the construction of input pairs containing directive specifications, target design metadata (e.g., array dimensions and
loop trip counts), and structure features. HLSTuner progressively processes these inputs to select appropriate directives and coarsely estimates their impact on the resource
consumption, ultimately culminating optimization strategies
with better trade-offs.
1
Kernel HLS-C
2
void kernel_mvt(...){
...
for(i=0;i<n;i++){
for(j=0;j<n;j++)
x1[i]=x1[i]+A[i][j]*y_1[j];
}
...
}
5
Buggy Optimized HLS-C 6
L1: for(i=0;i<n;i++){
L2:
#pragma HLS PIPELINE
#pragma HLS UNROLL
for(j=0;j<n;j++) ... } }
Error Log
Passed C-synth: false,
ERROR:In 'L2', pragma conflict
happens on 'UNROLL' and 'PIPELINE'
Labeled HLS-C
3
Debug Prompt
Your task is to debug the buggy code,
using the error log to guide you...
1.Debug the Code:
(Identify Errors; Analyze Reasons; Propose Fixes)
2.Construct a Chain of Thought:
(Sequential Reasoning; Hypothesis Formation;
Testing and Verification; Reflection)
3.Output:
(Bug Analysis; Error Correction Strategies ...)
Optimization Strategies:
Unoptimized Code Segment: "L2: for(...)",
Optimization: "add #pragma HLS unroll",
Reason: "Unrolling was added to ...",
Impact on QoR: "Improved by ...,at the cost of ..."
Input:
HLS-C Code; QoR Report; Loop/Array Info
L2 Loop,40
7
8
Debug CoT
Debugging Process:
1. Identifying Errors 2. Analyzing Reasons
3. Reasoning
4. Hypothesis Formation
5. Testing and Verification 6. Reflection
Bug Analysis:
erroneous_code_line: (mvt.cpp:20:9),
reason: "Complete unroll negates the
purpose of pipeline...",
modification_actions: "Remove ..."
Optimization CoT
Detailed Reasoning:
1. Design Space Analysis 2. Understand Pragma
3. Optimization Strategy 4. Assess Impact
You may use the following pragma types:
- Loop Pipeline
- Loop Unroll
- Array Partition
Loop/Array Info
L1 Loop,40
4
DSE PromptPrompt
Optimization
Your task is to optimize the following
HLS design by inserting `#pragma ` ...
void kernel_mvt(...){...
L1: for(i=0;i<n;i++){...}
L2:
for(j=0;j<n;j++){...} }
Optimized Bug-free HLS-C
void kernel_mvt(...){
...
L1: for(i=0;i<n;i++){
#pragma HLS UNROLL
L2:
for(j=0;j<n;j++)
#pragma HLS PIPELINE
...
}
}
Figure 5: An example of HLS-C optimization and error diagnosis in ChatHLS workflow.
LLMs struggle to accurately capture the interplay between performance optimization and resource consumption.
To address this challenge, HLSTuner continuously collects
QoR from the optimization trajectory to balance optimization against hardware consumption when mapping HLS
designs. When synthesized implementations fail to meet
the specified metrics, HLSTuner activates an iterative refinement cycle that incorporates both the current configuration and QoR. Through dynamic tuning of directives,
HLSTuner progressively aligns optimization objectives with
target hardware constraints, striking a balance between performance gains and resource efficiency.
Training Strategy. The optimization of loop and memory access parallelism constitutes a critical bottleneck in
HLS design, as these structure features predominantly determine the performance of the synthesized hardware. Specifically, for loops, HLSTuner supports the pragma PIPELINE
and UNROLL. The PIPELINE pragma allows overlapping execution of loop iterations to improve throughput, while the
UNROLL pragma replicates loop bodies to exploit parallelism.
For arrays, HLSTuner supports ARRAY PARTITION, which
divides arrays into smaller memories to enable parallel access and reduce memory bottlenecks. Our goal is to train
general LLMs to dominate these three types of directives.
As shown in Figure 3.B, we employed heuristic-based
tools to generate raw samples (Ferikoglou et al. 2024). These
curated samples, along with their metadata and QoR, are
used by LLM 7 to generate optimization CoT to reason about directive combinations, insertion positions, and
their potential QoR impacts. Specifically, the reasoning of
HLSTuner begins with identifying data dependencies in
nested loop structures, proceeding with exploring the parallelism of loop execution layer by layer, and determining
the optimal loop unrolling granularity by evaluating hardware resource utilization. To address memory access bottlenecks in parallel execution, HLSTuner analyzes access
patterns and implements array partitioning optimizations
aligned with the derived unrolling factors. We construct a
specialized dataset tailored for fine-tuning the LLM 2 on
directive semantic understanding and QoR perception.
Kernel
Lat. (Cycles)
DSP (Util.)
FF (Util.)
LUT (Util.)
Loop & Array
# Directives
Atax
1702
14.6%
1.6%
3.6%
4/4
20
Bicg
1658
13.2%
1.6%
3.3%
3/5
21
Gemm
15661
10.5%
0.4%
2.1%
4/3
17
Gesummv
470
10.8%
0.8%
2.4%
2/5
19
Mvt
1629
13.9%
1.7%
3.8%
4/5
23
Table 2: QoR metrics and design structure of representative
baseline computation kernels in linear algebra.
Evaluations
Dataset Construction & LLM Training
Through the proposed verification-oriented data augmentation (VODA) paradigm, we constructed comprehensive
datasets to fine-tune the LLM for HLS-specific error correction. Specifically, we compiled 12,352 samples of buggy
code covering 25 different types of HLS designs, and ended
up with 34 types of error through data augmentation. Using
this comprehensive dataset, we trained LLM 3 through supervised fine-tuning (SFT) method to enhance its ability to
handle HLS-specific errors. Furthermore, we constructed a
preference dataset containing 3,489 preference pairs to induce LLM 3 to explicitly perform debugging reasoning,
further improving error diagnosis accuracy. We collected
4,804 optimized samples across 20 HLS designs to form a
dataset for training LLM 2 to perform directive allocation
and embedding for HLS design optimization.
We trained LLM 2 and LLM 3 , both based on Llama38B, using the LoRA (Low-Rank Adaptation) method. The
training was conducted on a server equipped with 8×
NVIDIA A800-80G GPUs. We employed the model with
AdamW optimizer, bfloat16 precision, batch size of 2 and
implemented a cosine learning rate scheduler. During the
training phase, we trained the models for 11 epochs with
a peak learning rate of 1e-4. For the reinforcement learning
phase, we trained 3 epochs with a peak learning rate of 5e-6.
DeepSeek-Coder-6.7B
HLSFixer
GPT-4o
Claude 3.5 Sonnet
Llama3.1-8B
Pass Rate (%)
100
80
60
40
20
0
FIN
MCS
ICT
UDM
UCS
MUE
CDE
DAA
OOB
PTR
TFF
UDT
MLP
SHT
ILS
PUC
(a) Errors types in transformation phase
Pass Rate (%)
100
80
60
40
20
0
UDO
DPC
AID
IGK
UUI
MLL
UCP
TMB
(b) Errors types in optimization phase
Figure 6: Comparison of code repair pass rates on different HLS-specific errors.
Claude 3.5 Sonnet
GPT-4o
60
40
20
0
Kernel
Vitis
Manual
Benchmarks & Metrics
To evaluate the performance of HLSFixer, we tested it with
612 cases derived from 33 HLS designs, encompassing 34
distinct error types. We categorized our test cases into 3
types: Kernel (90 cases from 8 kernels in (Pouchet and Yuki
2016)), Vitis (215 cases from 10 examples in (Xilinx Inc.
2024)), and Manual (307 cases from 15 manually crafted
designs). For each test case ωi , we define Pass Rate as the
ratio of successful debugging cases ωi∗ to the total number
of test cases N to quantify the debugging ability.
|{ωi∗ }|
× 100%
N
Fixing+Analysis+DPO
HLSFixer
(1)
We evaluated HLSTuner on five PolyBench kernels that
represent computational patterns and data dependency challenges (Pouchet and Yuki 2016). Since HLSTuner focuses
on analyzing the impact of directives on design structure,
these results are sufficient to indicate strong generalization
potential. We perform synthesis with Vitis HLS 2022.1 targeting the Xilinx ZCU106 MPSoC platform for evaluation.
For the baseline, we synthesize kernels in the auto optimization mode of Vitis HLS to obtain QoR. These reports include
execution latency, utilization of digital signal processors
(DSP), flip-flops (FF) and look-up tables (LUT), shown in
Table 2. We evaluated the optimal speedup achieved through
19.0%
80
60
40
Overall
Figure 7: Comparison of debugging capability between
HLSFixer and general-purpose LLMs.
Pass Rate =
Fixing+Analysis
100
63.0%
80
Fixing
HLSFixer
Pass Rate (%)
Pass Rate (%)
100
Llama3.1-8B
DeepSeek-Coder-6.7B
Kernel
Vitis
Manual
Overall
Figure 8: Ablation study of HLSFixer design.
fewer than five attempts to verify the feasibility of generating effective solutions. We establish a proxy metric for hardware design Energy Efficiency by defining the relationship
between latency Lat(l) and resource utilization U til(ur ):
−1
Energy Efficiency = (Lat(l) · U til(ur ))
!−1
=
(1 − e
−γ·l
)·
X
2
1
1−ur
(2)
r
where Lat(l) is modeled as an activation function to prioritize optimal performance, with l denoting execution latency
and γ serving as a sensitivity coefficient. For each resource
r ∈ {DSP, F F, LU T }, we define U til(ur ) to penalize excessive resource consumption, with ur representing the utilization of specific resource used in the target hardware. All
experiments were excluded from the training distribution to
ensure generalization of our method.
HLSFixer Capability Analysis
Comparison with General LLM. Figure 6 compares
pass rates of HLSFixer and other models across 24 error
types, comprising 12 tasks from HLS-C transformations
and 12 tasks from optimization. These results demonstrate
that HLSFixer outperforms existing general LLMs in HLSspecific error correction tasks. Specifically, for the error
types in the transformation and optimization phase, HLSFixer achieved pass rates of 80.8% and 86.5%, respectively.
Llama3.1-8B
GPT-4o
RALAD
8.7×
6.9×
5.4×
2.8×
1.9×
1
0.0
Dahlia
HLSTuner
14.8×
Atax
Bicg
Gemm
Gesummv
Mvt
Speedup Ratio
Speedup Ratio
Baseline
15
10
5
HeteroCL
12.9×
Atax
Abaltion Study. We conducted ablation experiments
shown in Figure 8. After fine-tuning LLM 3 , HLSFixer
exhibited improved error correction performance. We compared HLSFixer with (1) fixing only with GPT-4o, (2) fixing
combined with analysis agent using the fine-tuned LLM 3 ,
and (3) fixing and analysis agent augmented with DPO. The
fine-tuned analysis agent, trained to learn error correction
reasoning patterns for HLS-specific errors, demonstrates an
8.7% improvement in code repair pass rate compared to direct error correction using a single fixing agent. Augmenting
LLM 3 with DPO further increased the overall pass rate
by 1.8%. For errors unresolved in a single attempt, we performed iterative multifaceted evaluations with up to five iterations, which led to an additional 8.5% improvement. Various debugging instructions are provided by different SOTA
general LLMs from different sources. A general LLM then
scores these instructions based on the clarity and soundness,
the extent to which they indicate code modifications. These
results validate that the hierarchical design of HLSFixer reinforces its ability to diagnose HLS-specific errors.
HLSTuner Capability Analysis
Comparison with General LLMs. Figure 9 compares
kernel performance optimization between HLSTuner, GPT4o, Llama3.1-8B and RALAD (Xu, Hu, and Huang 2024).
Current general-purpose LLMs typically require multiple
optimization attempts (up to five after debugging), as single attempt frequently produces suboptimal results including
excessive resource utilization or even synthesis failures. In
contrast, HLSTuner, driven by a fine-tuned agent with specialized hardware optimization knowledge, achieves comparable speedups through one-shot optimization.
In tests conducted on five kernels that were beyond the
training set, HLSTuner achieved an average speedup of 5.4×
compared to the original designs, 3.8× over the optimized
21.1×
17.7×
Allo
11.9×
HLSTuner
23.5×
16.7×
Bicg
Gemm
Gesummv
Mvt
Geo Mean
Figure 10: Latency speedup of DSL-based (Dahlia, HeteroCL, Allo), learning-based (HGBO-DSE) methods.
Energy Efficiency
Vitis HLS
Llama3.1-8B
This performance demonstrates the effectiveness of HLSFixer within the ChatHLS workflow. Figure 7 illustrates that
across the comprehensive test cases, HLSFixer achieved a
repair pass rate of 82.7% on average, outperforming GPT4o and Llama3-8B by 19.1% and 63.0%, respectively. This
significant performance gap highlights the specialized debugging capabilities of HLSFixer in HLS designs. HLSFixer
enables focused correction reasoning of LLMs while improving design-agnostic adaptability and generalization by
minimizing irrelevant contextual semantics.
HGBO-DSE
1
0.0
Geo Mean
Figure 9: Comparison of optimization capability between
Vitis HLS auto optimization (Baseline), general LLMs,
retrieval-augmented method (RALAD) and HLSTuner.
40
20
10
5
GPT-4o
RALAD
Dahlia
Heterocl
HGBO-DSE
HLSTuner(Ours)
Allo
8.9×
4
2
1
0.5
11.2×
9.0×
6.6×
6.2×
1.9×
0.2
0.1
Atax
Bicg
Gemm
Gesummv
Mvt
Geo Mean
Figure 11: Energy efficiency comparison on various kernels.
designs from GPT-4o and 2.5× over the retrieval-augmented
method RALAD, while maintaining resource utilization under 25% on target hardware. HLSTuner reached a peak
speedup of 14.8× in the Bicg with minimal additional hardware overhead, confirming its ability to produce reliable design optimizations that outperform existing general LLMs.
Comparison with DSL-based and learning-based methods. Figure 10 compares HLSTuner against DSL-based
(Nigam et al. 2020; Lai et al. 2019; Chen et al. 2024)
and learning-based (Kuang et al. 2023) methods. HLSTuner
achieved a geometric mean speedup of 16.7× over Dahlia,
3.5× over HeteroCL, 2.0× over Allo and 1.4× over HGBODSE, while maintaining acceptable resource utilization
across all benchmarks. Figure 11 presents a comparison of
the energy efficiency of HLS designs generated by different methods. HLSTuner effectively condenses complicated
design optimization with only a few minutes of overhead.
Furthermore, HLSTuner maintains the expressivity of HLS
designs by eliminating the need for source code modifications. It alleviates the effort of developer by allowing simple
natural language specifications of optimization targets and
automating the directive embedding.
Conclusion
In this paper, we present ChatHLS, an automated HLS-C
generation and optimization workflow while ensuring code
correctness. We introduce the verification-oriented data augmentation paradigm to construct HLS verification datasets
by dynamically incrementing error cases. Experiments show
that ChatHLS achieves a code repair accuracy of 82.7%
on a comprehensive test set. Additionally, it attains a geometric mean speedup of 3.6× compared to DSL-based and
learning-based methods, all with acceptable target hardware
resource utilization. These improvements pave the way for a
more efficient and reliable hardware design process.
References
Chang, K.; Wang, K.; Yang, N.; Wang, Y.; Jin, D.; Zhu, W.;
Chen, Z.; Li, C.; Yan, H.; Zhou, Y.; Zhao, Z.; Cheng, Y.;
Pan, Y.; Liu, Y.; Wang, M.; Liang, S.; Han, Y.; Li, H.; and
Li, X. 2024. Data is all you need: Finetuning LLMs for Chip
Design via an Automated design-data augmentation framework. In 61st ACM/IEEE Design Automation Conference.
Chen, H.; Zhang, N.; Xiang, S.; Zeng, Z.; Dai, M.; and
Zhang, Z. 2024. Allo: A Programming Model for Composable Accelerator Design. Proc. ACM Program. Lang., 8.
Cong, J.; Lau, J.; Liu, G.; Neuendorffer, S.; Pan, P.; Vissers, K.; and Zhang, Z. 2022. FPGA HLS Today: Successes,
Challenges, and Opportunities. ACM Trans. Reconfigurable
Technol. Syst., 15(4).
Ferikoglou, A.; Kakolyris, A.; Masouros, D.; Soudris, D.;
and Xydis, S. 2024. CollectiveHLS: A Collaborative Approach to High-Level Synthesis Design Optimization. ACM
Trans. Reconfigurable Technol. Syst.
Fu, Y.; Zhang, Y.; Yu, Z.; Li, S.; Ye, Z.; Li, C.; Wan,
C.; and Lin, Y. C. 2023. GPT4AIGChip: Towards NextGeneration AI Accelerator Design Automation via Large
Language Models. In 2023 IEEE/ACM International Conference on Computer Aided Design (ICCAD), 1–9.
Gai, J.; Chen, H.; Wang, Z.; Zhou, H.; Zhao, W.; Lane,
N.; and Fan, H. 2025. 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), 988–994.
Hou, X.; Zhao, Y.; Liu, Y.; Yang, Z.; Wang, K.; Li, L.; Luo,
X.; Lo, D.; Grundy, J.; and Wang, H. 2024. Large Language
Models for Software Engineering: A Systematic Literature
Review. ACM Trans. Softw. Eng. Methodol.
Kinzer, S.; Kim, J. K.; Ghodrati, S.; Yatham, B.; Althoff,
A.; Mahajan, D.; Lerner, S.; and Esmaeilzadeh, H. 2021.
A Computational Stack for Cross-Domain Acceleration. In
2021 IEEE International Symposium on High-Performance
Computer Architecture (HPCA), 54–70.
Kuang, H.; Cao, X.; Li, J.; and Wang, L. 2023. Hgbo-dse:
Hierarchical gnn and bayesian optimization based hls design space exploration. In 2023 International Conference
on Field Programmable Technology (ICFPT), 106–114.
Lai, Y.-H.; Chi, Y.; Hu, Y.; Wang, J.; Yu, C. H.; Zhou, Y.;
Cong, J.; and Zhang, Z. 2019. HeteroCL: A Multi-Paradigm
Programming Infrastructure for Software-Defined Reconfigurable Computing. In Proceedings of the 2019 ACM/SIGDA
International Symposium on Field-Programmable Gate Arrays, 242–251.
Lau, J.; Sivaraman, A.; Zhang, Q.; Gulzar, M. A.; Cong,
J.; and Kim, M. 2020. HeteroRefactor: refactoring for heterogeneous computing with FPGA. In Proceedings of the
ACM/IEEE 42nd International Conference on Software Engineering, 493–505. ISBN 9781450371216.
Li, W.; Wang, D.; Ding, Z.; Sohrabizadeh, A.; Qin, Z.; Cong,
J.; and Sun, Y. 2025. Hierarchical mixture of experts: Generalizable learning for high-level synthesis. In Proceedings of
the AAAI Conference on Artificial Intelligence, volume 39,
18476–18484.
Nigam, R.; Atapattu, S.; Thomas, S.; Li, Z.; Bauer, T.; Ye,
Y.; Koti, A.; Sampson, A.; and Zhang, Z. 2020. Predictable
accelerator design with time-sensitive affine types. In Proceedings of the 41st ACM SIGPLAN Conference on Programming Language Design and Implementation, 393–407.
Pouchet, L.-N.; and Yuki, T. 2016. PolyBench/C 4.2.
Rafailov, R.; Sharma, A.; Mitchell, E.; Ermon, S.; Manning,
C. D.; and Finn, C. 2024. Direct preference optimization:
your language model is secretly a reward model. In Proceedings of the 37th International Conference on Neural Information Processing Systems.
Schafer, B. C.; and Wang, Z. 2020. High-Level Synthesis
Design Space Exploration: Past, Present, and Future. IEEE
Transactions on Computer-Aided Design of Integrated Circuits and Systems, 39(10): 2628–2639.
Sohrabizadeh, A.; Yu, C. H.; Gao, M.; and Cong, J. 2022.
AutoDSE: Enabling Software Programmers to Design Efficient FPGA Accelerators. ACM Trans. Des. Autom. Electron. Syst.
Tang, Z.; Zhu, B.; Hao, Y.; Ngo, C.-W.; and Hong, R.
2025. RAGG: Retrieval-Augmented Grasp Generation
Model. Proceedings of the AAAI Conference on Artificial
Intelligence, 39(7): 7311–7319.
Thakur, S.; Ahmad, B.; Pearce, H.; Tan, B.; Dolan-Gavitt,
B.; Karri, R.; and Garg, S. 2024. VeriGen: A Large Language Model for Verilog Code Generation. ACM Trans. Des.
Autom. Electron. Syst., 29(3).
Tian, R.; Ye, Y.; Qin, Y.; Cong, X.; Lin, Y.; Pan, Y.; Wu, Y.;
Hui, H.; Liu, W.; Liu, Z.; and Sun, M. 2024. DebugBench:
Evaluating Debugging Capability of Large Language Models. arXiv preprint arXiv:2401.04621.
Tsai, Y.; Liu, M.; and Ren, H. 2024. RTLFixer: Automatically Fixing RTL Syntax Errors with Large Language
Model. In 61st ACM/IEEE Design Automation Conference.
Wan, L. J.; Huang, Y.; Li, Y.; Ye, H.; Wang, J.; Zhang,
X.; and Chen, D. 2024. Software/Hardware Co-design for
LLM and Its Application for Design Verification. In 2024
29th Asia and South Pacific Design Automation Conference
(ASP-DAC), 435–441.
Wang, X.; Wan, G.-W.; Wong, S.-Z.; Zhang, L.; Liu, T.;
Tian, Q.; and Ye, J. 2024. ChatCPU: An Agile CPU Design & Verification Platform with LLM. In 61st ACM/IEEE
Design Automation Conference.
Xia, Y.; Zhou, J.; Shi, Z.; Chen, J.; and Huang, H. 2025. Improving Retrieval Augmented Language Model with SelfReasoning. Proceedings of the AAAI Conference on Artificial Intelligence, 39(24): 25534–25542.
Xilinx Inc. 2024. Vitis-HLS-Introductory-Examples.
Xiong, C.; Liu, C.; Li, H.; and Li, X. 2024. HLSPilot: LLMbased High-Level Synthesis. In 2024 IEEE/ACM International Conference on Computer Aided Design (ICCAD).
Xu, H.; Hu, H.; and Huang, S. 2024. Optimizing HighLevel Synthesis Designs with Retrieval-Augmented Large
Language Models. In 2024 IEEE LLM Aided Design Workshop (LAD), 1–5.
Xu, K.; Sun, J.; Hu, Y.; Fang, X.; Shan, W.; Wang, X.; and
Jiang, Z. 2024a. MEIC: Re-thinking RTL Debug Automation using LLMs. In 2024 IEEE/ACM International Conference on Computer Aided Design (ICCAD).
Xu, K.; Zhang, G. L.; Yin, X.; Zhuo, C.; Schlichtmann, U.;
and Li, B. 2024b. Automated C/C++ Program Repair for
High-Level Synthesis via Large Language Models. In Proceedings of the 2024 ACM/IEEE International Symposium
on Machine Learning for CAD, 1–9.
Ye, H.; Hao, C.; Cheng, J.; Jeong, H.; Huang, J.; Neuendorffer, S.; and Chen, D. 2022. ScaleHLS: A New Scalable
High-Level Synthesis Framework on Multi-Level Intermediate Representation. In 2022 IEEE International Symposium on High-Performance Computer Architecture (HPCA),
741–755.
Zhang, Q.; Wang, J.; Xu, G. H.; and Kim, M. 2022. HeteroGen: transpiling C to heterogeneous HLS code with automated test generation and program repair. In Proceedings
of the 27th ACM International Conference on Architectural
Support for Programming Languages and Operating Systems, 1017–1029.