HLSClaw: Bringing Vibe Coding to High-Level Synthesis through Skill-Based Agentic Harness

HLSClaw: Bringing Vibe Coding to High-Level Synthesis through Skill-Based Agentic Harness Jinming Ge∗

The Hong Kong University of Science and Technology Hong Kong, Hong Kong jgeab@connect.ust.hk

arXiv:2611.02784v1 [cs.LG] 2 Nov 2026

Shangkun Li

The Hong Kong University of Science and Technology Hong Kong, Hong Kong shangkun.li@connect.ust.hk

Shang Liu

The Hong Kong University of Science and Technology Hong Kong, Hong Kong sliudx@connect.ust.hk

Afzal Ahmad

The Hong Kong University of Science and Technology Hong Kong, Hong Kong afzal.ahmad@connect.ust.hk

Linfeng Du†

The Hong Kong University of Science and Technology Hong Kong, Hong Kong linfeng.du@connect.ust.hk

Jiawei Liang

The Hong Kong University of Science and Technology Hong Kong, Hong Kong jliangbr@connect.ust.hk

Jiang Xu

The Hong Kong University of Science and Technology (Guangzhou) Guangzhou, China jiang.xu@hkust-gz.edu.cn

Wei Zhang‡

Dept of Electronic & Computer Engineering The Hong Kong University of Science and Technology Hong Kong, Hong Kong wei.zhang@ust.hk

Abstract

CCS Concepts

LLM agents are rapidly shifting software development toward intent-driven vibe coding, yet their effectiveness drops sharply in high-level synthesis (HLS), where code optimization must jointly consider design structure, directive search, and downstream hardware constraints. Existing HLS optimization approaches, including both heuristic-based methods and recent LLM-assisted pipelines, typically operate at fixed abstraction levels or in weakly coupled stages, limiting their ability to leverage the strong interplay between source code restructuring and directive search outcomes. Our key insight is that HLS optimization can be reframed from a fixed, hardwired transformation pipeline into a skill-based agentic control problem: an LLM agent equipped with modular, executable optimization skills and a feedback-driven orchestrator can autonomously navigate the coupled space of code restructuring and directive search. This motivates the design of HLSClaw1 , the first HLS-specific, skill-based agentic harness for holistic HLS optimization. On real-world HLS benchmarks, HLSClaw achieves a 39.12× geometric-mean latency speedup, outperforming the compiler baseline ScaleHLS by 1.98×, and surpassing the commercial coding agents Claude Code and Codex by 1.86× and 1.70×, respectively, while maintaining strong timing robustness.

• Hardware → High-level and register-transfer level synthesis; • Computing methodologies → Intelligent agents.

∗ Corresponding author: Jinming Ge (jgeab@connect.ust.hk)

† Corresponding author: Linfeng Du (linfeng.du@connect.ust.hk) ‡ Corresponding author: Wei Zhang (wei.zhang@ust.hk)

1 HLSClaw is open-sourced at https://github.com/gjskywalker/HLSClaw

Conference’17, Washington, DC, USA 2026. ACM ISBN 978-x-xxxx-xxxx-x/YYYY/MM https://doi.org/10.1145/nnnnnnn.nnnnnnn

Keywords Autonomous LLM, Harness Engineering, High-Level Synthesis, Source-to-Source Transformation

1

Introduction

Software development is undergoing a paradigm shift from laborintensive manual coding toward AI-assisted vibe coding, in which developers express high-level intent to LLM-powered agents. This paradigm succeeds in mainstream software since modern software compilers are mature enough to accommodate structural variations in source code without materially affecting runtime correctness or performance [3]. General-purpose agentic tools such as OpenAI Codex [19] and Claude Code [2] capitalize on this robustness, delivering remarkable proficiency in mainstream software tasks with minimal human intervention. However, this paradigm breaks down in high-level synthesis (HLS), the dominant agile design flow for specialized hardware accelerators [7, 10, 28]. Unlike software compilation, HLS design quality is highly sensitive to both source-level computational structure and applied hardware directives. Their interaction shapes the resulting hardware architecture and quality of results (QoR), giving rise to a multidimensional and tightly coupled optimization space. Consequently, closing the vibe coding quality gap for HLS demands domain-specific harnesses—structured wrappers that equip an LLM agent with executable tools, feedback parsers, and correctness

Conference’17, July 2017, Washington, DC, USA

Input HLS Design

User Goal

HLSClaw Workflow Analysis& Plan

Feedback-Driven Rewrite

Code Restructure

Differential C-Sim

Directive Search

LLM Agent

Skills

Profiling

Ge et al.

Rewrite

KG-RAG

Fuzzing

2.1 DSE Eng.

Figure 1: Overview of HLSClaw: an LLM agent coordinates optimization skills in a feedback-driven workflow. checks—to perform high-quality source-to-source transformations, the decisive factor for final hardware QoR. Despite sustained efforts from both academia and industry [6, 9, 11, 12, 22, 24–27], high-quality HLS source-to-source transformation remains an open challenge. Existing approaches either isolate code restructuring from HLS directive search or couple them in a fixed order, where early structural transformations constrain the space for downstream directive optimization. Recent LLM-based methods [8, 18, 25, 26] alleviate this rigidity by leveraging LLMs’ natural capacity for flexible source-level reasoning. However, they still organize optimization as either a linear pipeline or a human-scripted iteration, lacking a closed-loop architecture in which structural decisions can be revised based on later synthesis outcomes. These gaps cannot be addressed by simply prompting the LLM to “try again” with raw feedback: without structured feedback parsing, the agent cannot diagnose bottlenecks; without tool-driven validation, it silently introduces bugs; and without optimization memory, it repeats failed transformations. Our key insight is that HLS experts navigate this tightly coupled optimization problem not by following a fixed recipe, but by iteratively diagnosing bottlenecks from synthesis feedback, selecting matched strategies, validating functional consistency, and revising upon deficiency—precisely the closed-loop capabilities that current LLM-based methods lack. Our work, as shown in Fig. 1, encodes this expert workflow by reframing HLS source-to-source transformation from hardwired rule design to dynamic skill orchestration— packaging expert HLS knowledge into modular skills that an LLM agent selects and composes according to the current design state and vendor-tool feedback. The main contributions are as follows: • We present HLSClaw, the first HLS-specific, skill-based agentic harness that brings vibe coding to HLS through feedback-driven orchestration of code restructuring and directive search. • We equip HLSClaw with modular, composable skills whose complementary benefits for optimization quality and efficiency are demonstrated through ablation studies. • Across 12 HLS benchmarks, we achieve a 39.12× geometricmean latency speedup, outperforming Claude Code by 1.86× and Codex by 1.70×, with only modest resource overhead.

2

synthesis results target the AMD U250 FPGA at a 5 ns clock period (200 MHz) using Vitis HLS 2025.2.

Motivation

We present two representative design snippets to illustrate the fundamental limitations of current HLS optimization: the inability of HLS compilers to compensate for suboptimal source structure, and the necessity of bidirectional coupling between code restructuring and directive search for high-quality optimization. For clarity, Fig. 2 only retains the key computational structure of each kernel. All

When Directives Are Not Enough

Fig. 2 (top) presents the CRS kernel, a sparse reduction-andbroadcast pattern that commonly appears in ML workloads. The original design uses the aggressive directive #pragma HLS PIPELINE II=1 ( 1 ). This setting yields a latency of 1,990 cycles. However, it ignores a loop-carried RAW dependency on total: the requested II=1 is unachievable in practice due to the FP accumulation latency, and the resulting design faces severe timing pressure with the Vivado post-synthesis clock stretched to 9.35 ns. The indirect memory access vec[cols[j]] further complicates scheduling since memory partitioning cannot guarantee conflict-free bank access. As a result, although the transformed code appears to reduce cycle count, the generated hardware is timing-infeasible and yields worse QoR. By contrast, HLSClaw identifies the loop-carried RAW dependency as the key bottleneck and applies a coordinated restructuring ( 1 ): it stages external arrays into BRAM, decomposes the accumulator into UNROLL FACTOR=4 independent partial sums with the inner loop fully unrolled, and relaxes the pipeline target to II=4 so each partial_sum[k] is updated once every four iterations. A final tree reduction merges the partial results, breaking the RAW hazard and producing a more efficient hardware pipeline. Although this rewrite results in a higher latency of 3,506 cycles, it achieves a much shorter clock of 3.19 ns, leading to a lower execution time.

2.2

When One Strategy Does Not Fit All

The 3 × 3 convolution over a 32 × 32 input shown in Fig. 2 (bottom) exposes a limitation of task-level dataflow decomposition [1, 4, 21, 27]. After applying dataflow decomposition with pipeline directives at II = 1, the resulting latency remains far from optimal despite significant engineering effort. The computational structure exposes the underlying cause: nine input values are loaded independently for every output pixel, yet adjacent windows overlap by six elements ( 2 ). The true bottleneck is spatial data reuse, and factoring the code into producer–consumer stages does nothing to exploit it. HLSClaw addresses this bottleneck by reorganizing the entire loop nest around a line-buffer and sliding-window architecture ( 2 ). A single pipelined loop at II = 1 brings in one new pixel per cycle, shifts a 𝐾 × 𝐾 window of registers, and refills one column from the line buffer, with the MAC fully unrolled. The resulting latency of 1,147 cycles (−74.5% vs. original) demonstrates the payoff of matching the transformation to the kernel-specific bottleneck. Crucially, this improvement stems from directive search outcomes feeding back into restructuring decisions: when the dataflow-decomposed code proved unresponsive to further directive tuning, HLSClaw recognized diminishing returns and selected a fundamentally different restructuring strategy—something forward-only pipelines cannot do, as they lack feedback between stages.

2.3

From Compiler Limitations to LLM Opportunities

These two cases expose two fundamental challenges in existing HLS optimization methods. Challenge 1: structure-constrained

HLSClaw: Bringing Vibe Coding to High-Level Synthesis through Skill-Based Agentic Harness

Original Design

Conference’17, July 2017, Washington, DC, USA

HLSClaw Results

Computational Structure

01: #define N 494 01: for (int j = 0; j < N * 3; j += 4) { CRS 02: spmv_sum: 02: #pragma HLS PIPELINE II=4 03: for (int j = 0; j < N * 3; ++j) { Clock: 9.35ns 03: for (int k = 0; k < 4; k++) { Clock: 3.19ns 04: #pragma HLS PIPELINE II=1 04: int idx = j + k; Latency: 3,506 Latency: 1,990 05: 05: total += val[j] * vec[cols[j]];} if (idx < N * 3) { 1 06: broadcast: 06: partial_sum[k] += val_buf[idx] * -40.0% 07: for (int i = 0; i < N; ++i) { 07: 1 vec_buf[cols_buf[idx]]; } } } 08: #pragma HLS PIPELINE II=1 08:TYPE sum0 = partial_sum[0] + partial_sum[1]; 09: out[i] = total; 09:TYPE sum1 = partial_sum[2] + partial_sum[3]; 10: } 10:TYPE sum = sum0 + sum1; 01: static void load_windows(...) { 01: void dut(...) { Conv2D 02: for (int r = 0; r < OUT_H; ++r) { 02: for (int r = 0; r < IN_H; ++r){ 03: for (int c = 0; c < OUT_W; ++c) { 07: for (int c = 0; c < IN_W; ++c) { Clock: 5ns Clock: 5ns 04: #pragma HLS PIPELINE II=1 08: #pragma HLS PIPELINE II=1 Latency: 1,147 Latency: 4,502 05: for (int kr = 0; kr < K; ++kr) { 09: float pixel = input[r][c]; 06: for (int kc = 0; kc < K; ++kc) { 10: for (int wr = 0; wr < K; ++wr) { 07: packet.data[kr][kc] = input[r + kr][c + kc];}} 11: for (int wc = 0; wc < K - 1; ++wc) { 08: window_stream.write(packet);}}} 12: window[wr][wc] = window[wr][wc + 1];} } -74.5%13: for (int wr = 0; wr < K - 1; ++wr) { 13: static void compute_outputs(...) { 14: for (int r = 0; r < OUT_H; ++r) { 14: window[wr][K - 1] = linebuf[wr][c]; } 15: for (int c = 0; c < OUT_W; ++c) { 15: window[K - 1][K - 1] = pixel; 2 16: #pragma HLS PIPELINE II=1 16: for (int lb = 0; lb < K - 2; ++lb) { 17: WindowPacket packet = window_stream.read(); 2 17: linebuf[lb][c] = linebuf[lb + 1][c]; } 18: output[r][c] = convolve_window(packet,kernel);}}} 18: linebuf[K - 2][c] = pixel; 19: void dut(...) {#pragma HLS DATAFLOW 19: if (r >= K - 1 && c >= K - 1) { 20: load_windows(input, window_stream); 20: output[r - (K - 1)][c - (K - 1)] = \ 21: compute_outputs(window_stream, kernel, output);} 21: convolve_window(window, kernel);} } } }

Target:PIPELINE II=1 Actual Schedule 1 RAW FP Add Iter j Load Load FP Mul. Load Load FP Mul. FP Add Iter j+1 Limited by FP add latency Partial-sum decomposition --- Break the RAW

Tree 1 Reduction Iter j FP Mul.*4 Iter j+4

FP Add *4 FP Mul.*4

r=0 r=1 r=2 r=3 r=4 c=0

c=1

FP Add *4

HLSClaw Result

r=0 r=1 r=2 r=3 r=4 c=0

c=1

2

c=2

c=2

c=3

c=3

c=4

c=4

Load Store Load Store

load_ windows FIFO: window_stream window_stream.read()

2

Window Register Line Buffer Pixel HLSClaw Result

MAC Store compute_ MAC Store outputs

Figure 2: Motivation examples demonstrating the limitations of existing HLS compilers and the opportunity for LLMs. The green arrows show execution time reductions. Circle and pentagon markers highlight the bottlenecks and modified regions. directive exploration. CRS shows that restrictive computational dependencies fundamentally limit directive search, often trapping it in locally optimal designs. Challenge 2: missing architecturelevel reorganization. Conv2D shows that even after dataflow decomposition and pipelining, existing compilers may fail to identify transformations such as line-buffer-based spatial reuse that eliminate the dominant memory-access bottleneck. Both challenges arise because the required restructurings are high-level, domain-aware optimizations that are difficult to encode as deterministic compiler transformations, motivating the use of LLM-based reasoning. However, existing LLM-assisted HLS methods typically lack a feedback connection between code restructuring and downstream DSE, preventing synthesis outcomes from revising earlier structural decisions. HLSClaw addresses this limitation by grounding the agent with domain-specific skills, coordinating them in a feedback-driven loop, and using context engineering to preserve diagnoses, tool evidence, and design history across iterations. This design harnesses the flexibility of LLMs to enable a tool-grounded, correctness-aware, and iterative process tailored to the tightly coupled nature of HLS optimization.

Context Engineering 3.5 Top States

Input HLS Design

Artifacts Analysis& Plan Reports

User Goal

ScratchPad

Memory 3.3

HLSClaw Workflow 3.1

Directive Search

Opt. Plan Bottleneck Diag.

Code Restructure

Orig. Rewritten Best Design Candidate Candidate Rewritten Candidate Differential Bottleneck Diag. C-Sim

Skills Profiling 3.2

Rewrite 3.3

KG-RAG 3.2

Fuzzing 3.3 DSE Eng. 3.4

Figure 3: Overview of HLSClaw with five optimization skills, a feedback-driven workflow, and context engineering. through HLS synthesis. After directive search, the resulting QoR reports are fed back to the analysis stage. If the best candidate violates the user-specified constraints or the reports indicate further optimization opportunities, the agent updates its bottleneck diagnosis and initiates another restructuring iteration. This feedback-driven process continues until no candidate provides a meaningful QoR improvement or the optimization budget is exhausted.

3 Methodology 3.1 Framework Overview

3.2

Fig. 3 presents the architecture of HLSClaw. Given an HLS design and a user-specified optimization goal, the agent first invokes the Profiling and KG-RAG skills to analyze synthesis feedback, diagnose the bottleneck, and formulate an optimization plan. Guided by this plan, the agent invokes the Rewrite skill to generate source-level design variants that target the identified bottleneck. The rewritten candidate is then compared with the original design through differential C simulation using the Fuzzing skill. Candidates that fail the functional-consistency check are rejected and returned to the agent for further revision, whereas valid candidates proceed to directive exploration. The agent then invokes the DSE Engine skill to explore directive configurations for the current design and evaluates them

A key enabler of HLSClaw’s agentic behavior is its ability to plan before acting. Before applying any optimization, the agent invokes the Profiling skill, which runs HLS synthesis and performs static analysis of the resulting QoR reports to derive higher-level bottleneck diagnoses. Crucially, profiling is not limited to the initial design: after major rewrites or DSE rounds, the agent re-invokes the profiling skill to reassess the updated design. This ensures that subsequent decisions are grounded in the current design state and forms a central component of HLSClaw’s closed-loop optimization. After obtaining the QoR report, the agent invokes the KG-RAG skill to ground its bottleneck diagnosis in domain-specific HLS knowledge. As shown in Fig. 4, the knowledge library is constructed

Profiling & Knowledge-Guided Planning

Conference’17, July 2017, Washington, DC, USA

Ge et al.

offline by parsing vendor documentation with a multimodal document parser [14], encoding the extracted text, images, tables, and equations, and organizing them into a knowledge-graph-based RAG store. At query time, the agent formulates a bottleneck-aware query, and the RAG library returns prioritized optimization strategies with supporting rationale. Unlike Flat-RAG, which retrieves semantically similar passages independently, the graph-structured RAG explicitly models relationships among bottlenecks, root causes, optimization techniques, and vendor constraints. This structure supports multi-hop reasoning, composition of compatible strategies, and vendor-specific grounding. Database

Parser (MinerU)

pdf web … ...

Content List Text Table

Embedding (Multimodal Emb.)

Knowledge-Graph RAG

Text

Multimodal Emb.

Multimodal

Image Equa.

Figure 4: Offline construction of the KG-RAG library from multimodal documents for HLS knowledge retrieval.

3.3

Code Restructuring & Differential C-Sim

The Rewrite skill provides a library of more than 100 curated code templates collected from publicly available repositories and programming platforms. Additionally, we classify them according to common HLS bottlenecks, including redundant computation, loopcarried dependencies, inefficient memory access, limited data reuse, irregular control flow, and imbalanced dataflow organization. For each bottleneck category, the library records representative code templates together with their applicable conditions, enabling the agent to retrieve structurally relevant examples when implementing an optimization plan. The template library is further complemented by a self-updating memory. When the agent encounters a bottleneck that is not adequately covered by existing templates, it derives a new rewrite pattern from the successful optimization attempt and stores the validated pattern, its triggering bottleneck, and the observed synthesis outcome for reuse in subsequent runs. Since LLM-generated rewrites may introduce functional errors, HLSClaw invokes the Fuzzing skill before each rewritten candidate enters HLS evaluation. The skill constructs a self-checking differential testbench that executes the original design and the rewritten candidate on identical fixed-seed, fuzz-generated inputs through AMD Vitis C simulation. Their outputs are compared element-wise using exact matching for integer and fixed-point computations and a predefined numerical tolerance for floating-point outputs. A candidate is rejected if it produces an output mismatch, runtime failure, assertion violation, or incompatible top-level interface. The failing input and first divergent output are summarized as feedback for the next rewrite attempt. Candidates that pass this test-based functional-consistency check proceed to HLS synthesis and directive search. This lightweight gate prevents incorrect rewrites from consuming expensive HLS evaluations.

3.4

Directive Search & DSE Engine

The directive-search stage consists of two steps. First, the agent leverages the structural analysis from the rewrite stage to identify high-impact directive sites and construct a focused candidate set

Top States System Prompt

You are an expert HLS designer, you can follow the provided optimization pipeline or design a tailored one … …

Compact History

<history>turn 1</history> <history>turn 2</history> … ...

Skills Info

<available_skills>fuzzing</available_skills> <available_skills>profiling</available_skills> <available_skills>rewrite</available_skills> … ...

User Spec.

<target>latency</target> <board>U250</board> <frequency>200MHz</frequency>

ScratchPad

Artifacts

Analysis

References

Report

pdf

web

syn.rpt

<analysis>bottleneck lies in … </analysis>

Designs

Script

<command>source run.sh</command>

Orig.

fuzzing.py

Opt. v1

run.sh

Command

Artifact Path <path>skills/fuzzing/fuzzing.py</path>

Figure 5: Context engineering with Top States, ScratchPad, and Artifacts for orchestration, memory, and outputs. from the full set of AMD Vitis HLS directives. The agent then invokes the DSE Engine skill to evaluate these candidates through an algorithmic search engine, progressively adding or updating one directive site at each iteration. For candidate selection, HLSClaw adopts a constraint-first, goalaware ranking scheme. Let C denote the set of user-specified constraints, where each constraint is expressed as 𝑔𝑐 (𝑥) ≤ 𝑏𝑐 for candidate 𝑥. These constraints may include the target clock period and resource budgets. We quantify the maximum normalized constraint violation as   𝑔𝑐 (𝑥) − 𝑏𝑐 𝑉 (𝑥) = max , [𝑧] + = max(𝑧, 0). (1) 𝑐∈C 𝑏𝑐 + A candidate is feasible if and only if 𝑉 (𝑥) = 0. Candidates are first ranked by normalized constraint violation and then by the user-selected optimization objective. Let 𝑞𝑔 (𝑥) denote the QoR cost of candidate 𝑥 under goal 𝑔. We normalize this objective against the current rewritten baseline 𝑥 0 : 𝐽𝑔 (𝑥) =

𝑞𝑔 (𝑥) . 𝑞𝑔 (𝑥 0 )

(2)

A lower value of 𝐽𝑔 (𝑥) indicates a better design under the selected optimization goal. Candidates are ordered lexicographically by
Φ𝑔 (𝑥) = 𝑉 (𝑥), 𝐽𝑔 (𝑥) . (3) Each feasible candidate is preferred over an infeasible one; feasible candidates are then ranked solely by the selected QoR objective. The DSE Engine explores hardware directives in three stages. It first synthesizes the rewritten baseline and evaluates all singlesite directive candidates in parallel. For each site, the best option that improves upon the baseline under the lexicographic ranking Φ𝑔 = (𝑉 , 𝐽𝑔 ) is retained. These options are then progressively combined through beam expansion. At each round, the engine ranks the evaluated configurations using Φ𝑔 and applies rank-based Boltzmann sampling to preserve promising alternatives while avoiding early commitment to a local optimum. As the search progresses, the selection gradually favors higher-ranked candidates. Finally, the remaining evaluation budget is used to explore unseen, conflict-free multi-site combinations, and the lexicographically best configuration is returned.

HLSPilot

ScaleHLS

HLSRewriter

Codex

Claude Code

HLSClaw 17.3x 19.7x 14.1x 23.0x 21.0x 39.1x

10000 1000 100 10 1

Conference’17, July 2017, Washington, DC, USA

Atax

BNN

CNN

CRS HLSPilot

100x

GEMM GetTanGhramSchmidt Matrixmult ScaleHLS

HLSRewriter

Codex

Stencil SubstrinegcNormTrans V

Claude Code

Viterbi Geomean

HLSClaw 14.5x 13.4x 11.3x 11.3x 12.5x 15.2x

Normalized Resource Score

Normalized Latency Speedup

HLSClaw: Bringing Vibe Coding to High-Level Synthesis through Skill-Based Agentic Harness

10x 1x

Viterbi Geomean Stencil SubstrinegcNormTrans V Figure 6: Performance and resource comparison across 12 HLS benchmarks. Top: normalized latency speedup, where higher is better. Bottom: normalized resource score relative to the original design, where lower is better.

3.5

Atax

BNN

CNN

CRS

GEMM GetTanGhramSchmidt Matrixmult

Context Engineering

Long-horizon agentic runs accumulate heterogeneous context, including user constraints, intermediate analyses, code variants, tool outputs, and empirical takeaways. As illustrated in Fig. 5, HLSClaw partitions this context into three layers. Top States maintains stable orchestration information such as the system prompt, skill descriptions, execution history, and user specifications. ScratchPad stores transient reasoning state, including bottleneck diagnoses, commands, and artifact paths, while Artifacts preserves concrete outputs such as designs, synthesis reports, and scripts. This separation keeps control signals explicit, allows reasoning to persist across skill invocations, and preserves inspectable evidence throughout long-horizon optimization. This partitioning yields three benefits. First, robustness: the agent can resume, reroute, or terminate using explicit state rather than fragile conversational reconstruction. Second, reasoning quality: separating working memory from orchestration metadata reduces interference across skill invocations. Third, auditability: tool outputs persist as artifacts rather than free-form summaries. Context engineering therefore provides a reliable basis for multi-skill orchestration by separating control logic, evolving reasoning state, and verifiable optimization evidence.

Table 1: Execution time = latency × achieved clock period; For all four metrics, higher is better. Metric GM ETS EWS Perf/HW Gain

Experiments

We implement HLSClaw using LangGraph 1.0.10 [16], a productiongrade framework for building agentic systems in industry [5, 17], comprising over 12,000 lines of Python code, and evaluate it on a suite of 12 representative HLS kernels drawn from four classical benchmark suites [15, 20, 23, 30] spanning dense linear algebra (GEMM, Matrixmult, Atax, GramSchmidt), neural-networkstyle computation (BNN, CNN, GetTanh), stencil and convolution patterns (Stencil, CRS), and control-heavy or irregular workloads (Viterbi, Substring, VecNormTrans). All designs are synthesized using Vitis HLS 2025.2 targeting the AMD U250 at a 5 ns clock period (200 MHz), with latency as the primary optimization objective. For DSE, we set the beam width to 𝐵 = 5, limit each search to at most 𝑀 = 13 HLS evaluations per rewritten design, and use an initial Boltzmann temperature of 𝑇0 = 50.0 with a geometric cooling factor of 𝛾 = 0.85. Hardware QoR is measured from synthesis reports in terms of latency (cycles), timing slack (ns), and resource utilization. We quantify overall hardware cost using a weighted normalized resource metric, denoted as ResourceScore:

ScaleHLS

HLS Rewriter

Codex

Claude Code

HLSClaw

11.89 3.44 4.41 0.82

18.29 6.35 4.46 1.36

14.16 5.35 4.99 1.25

13.34 4.13 4.42 1.18

14.68 5.26 4.68 1.17

30.59 7.48 5.70 2.01

GM: geometric mean of execution-time speedups. ETS/EWS: equal-time and equal-work harmonic-mean speedups, respectively [13]. Perf/HW gain: geometric mean of per-benchmark execution-time speedup divided by normalized ResourceScore overhead.

ResourceScore = 0.30𝑢 LUT + 0.10𝑢 FF + 0.30𝑢 DSP + 0.30𝑢 BRAM . This formulation assigns larger weights to LUT, DSP, and BRAM because they are typically more constraining in HLS designs, while FF receives a smaller weight due to its lower practical pressure. We compare against five baselines representing three optimization paradigms: (1) compiler-based: ScaleHLS [27]; (2) LLM-based: HLSPilot [25] and HLSRewriter [26]; (3) general-purpose coding agents: OpenAI Codex [19] and Claude Code [2]. To ensure fair comparison across LLM-based methods, HLSClaw, HLSPilot [25], and HLSRewriter [26] all use GPT-5.5 as the base model.

4.1 4

HLSPilot

Comparison with SOTA HLS Opt. Methods

Fig. 6 compares end-to-end speedup and resource usage across 12 benchmarks for six methods. HLSClaw achieves the highest geometric-mean latency speedup of 39.1×, outperforming Codex (23.0×) and Claude Code (21.0×) by 1.70× and 1.86×, respectively. Although the coding agents report higher nominal speedups on several benchmarks, four of these designs suffer severe timing violations, as indicated by the red dashed boxes. In contrast, HLSClaw maintains timing-feasible performance across the benchmark suite while remaining competitive in resource usage, with a geometricmean normalized resource score of 15.2×. For LLM-based methods and general-purpose coding agents, the overall runtime is dominated by repeated Vitis HLS evaluations. HLSClaw reduces this cost through differential C simulation, which rejects incorrect rewrites before they enter synthesis and avoids unnecessary tool invocations. Compiler-based methods such as ScaleHLS instead use analytical QoR models during DSE, trading synthesis-level evaluation fidelity for lower exploration runtime. To account for timing infeasibility and enable a fair comparison of performance and resource efficiency, we further evaluate all

No-RAG

Flat-RAG

KG-RAG

1.0

Atax

CNN

BNN

Original (1x)

No-RAG

g Substrin Flat-RAG

100x 10x 1x

Normalized latency

3.8x 10.4x 21.5x

Original (1x) 100x 30.0x 10.0x 3.00x 1.00x 0.30x

Ge et al.

an

Geome

KG-RAG 5.71x 14.0x 15.4x

Normalized Resource Score

Normalized Latency Speedup

Conference’17, July 2017, Washington, DC, USA

Atax BNN CNN Substring Geomean Figure 7: KG-RAG ablation on four kernels: (top) normalized latency speedup; (bottom) normalized resource score.

Resource-constrained (res 0.67, lat 1.00)

HLSRewriter ScaleHLS

0.8 0.6

HLSPilot HLSClaw

0.4 0.2 0.0

0

2

4

6 8 ResourceScore

Explored candidates HLSClaw Pareto frontier (goal sweep)

10

12

HLSClaw Other methods

Figure 8: Latency–resource trade-off on CNN. The red curve shows the Pareto frontier obtained by sweeping 𝜆. Table 2: Impact of differential C simulation on validation and optimization wall-clock time. C-sim time (s)

HLS evals

Invalid evals executed

Without C-sim gate With differential C-sim

0 94.10

80 65

15 0

966.50 295.71

Change Relative saving

+94.10 −15 – 18.8%

−15 100%

−670.79 69.40%

Configuration

Table 3: Contribution of eval-1, eval-2, eval-3, and eval-4. Benchmark

eval-1 cycles

eval-1 gain

eval-2 cycles

eval-2 gain

eval-3 cycles

eval-3 gain

966.50 389.81

Substring

24,607

10.65 ×

42,762

6.13 ×

4,122†

63.59 × †

VecNormTrans 30,729

1.46 ×

6,199

7.26 ×

4,814

9.35 ×

3,127 14.39 ×

−576.69 59.70%

CNN

8,115

4.61 ×

14,278

2.62 ×

8,115

4.61 ×

4,105

9.11 ×

Atax

1,259

26.62 ×

977

34.30 ×

1,072†

31.26 × †

532

63.00 ×

HLS wall Total wall time (s) time (s)

eval-4 cycles

eval-4 gain

4,121

63.61 ×

† Timing-infeasible design.

methods using four execution-time-based metrics, as summarized in Table 1. Execution time is computed as latency multiplied by the achieved clock period, thereby penalizing designs with poor timing closure. HLSClaw consistently achieves the best results across all four metrics, attaining a GM speedup of 30.59×, ETS and EWS speedups of 7.48× and 5.70×, respectively, and the highest Perf/HW gain of 2.01.

4.2.3 Feedback-driven Rewrite. Table 3 compares directive search only (eval-1), code restructuring only (eval-2), fixed-order restructuring followed by DSE (eval-3), and the full feedback-driven workflow (eval-4). The isolated stages favor different kernels, while eval-3 cannot revise restructuring decisions using downstream synthesis feedback and produces timing-infeasible designs. In contrast, eval-4 achieves the lowest latency on all four benchmarks while maintaining timing feasibility.

4.3 4.2

Skill Ablation Study

To isolate the contributions of key components of HLSClaw, we conduct three ablation studies: KG-RAG versus Flat-RAG and NoRAG; differential C simulation for early rejection of incorrect rewrites; and isolated, one-shot, and feedback-driven coordination of code restructuring and directive search. 4.2.1 KG-RAG. We evaluate No-RAG, Flat-RAG, and KG-RAG within HLSClaw, as shown in Fig. 7. KG-RAG achieves the highest geometric-mean latency speedup and Perf/HW gain, with 21.5/15.4 ≈ 1.40×, compared with 10.4/14.0 ≈ 0.74× for Flat-RAG and 3.8/5.71 ≈ 0.67× for No-RAG. The small gain of Flat-RAG over No-RAG suggests that isolated passage retrieval provides limited benefit, whereas graph-structured retrieval better captures relationships among bottlenecks, optimization strategies, and hardware constraints. 4.2.2 Differential C-Sim. Table 2 evaluates differential C simulation on four benchmarks using four rewrites each. Without early validation, the 16 candidates require 16 × 5 = 80 HLS evaluations. Eight fixed-seed fuzzing trials reject three incorrect rewrites before DSE, avoiding 15 HLS evaluations. Including 94.10 s of C-sim overhead, total wall-clock time decreases from 966.50 s to 389.81 s.

Case Study: Multi-Objective Pareto Front

Although this work mainly focuses on latency optimization, HLSClaw is not restricted to a single optimization objective. After filtering infeasible candidates, the agent can rank feasible designs using a user-defined latency–resource objective: 𝐽𝜆 (𝑥) = 𝜆

𝜌 (𝑥) 𝐿(𝑥) + (1 − 𝜆) , 𝐿(𝑥 0 ) 𝜌 (𝑥 0 )

0 ≤ 𝜆 ≤ 1,

(4)

where 𝐿(𝑥) and 𝜌 (𝑥) denote the latency and resource score of candidate 𝑥, respectively, and 𝑥 0 is the current rewritten baseline. We sweep 𝜆 on CNN to study the latency–resource trade-off. As shown in Fig. 8, HLSClaw explores a broad design space and traces a Pareto frontier from resource-efficient to latency-oriented solutions, demonstrating its ability to adapt to different user objectives rather than returning only the fastest design.

4.4

Open-Source Model Study

To investigate the feasibility of deploying open-source LLMs for agentic HLS optimization, we establish a local inference environment on an Ascend server equipped with eight Ascend 910B NPUs, each providing 64 GiB of HBM, and a 192-core Kunpeng 920 CPU. The software stack includes CANN 8.5.2, PyTorch 2.7.1, TorchNPU 2.7.1.post2, and Hugging Face Transformers 4.53.3. All evaluated models are executed in BF16 precision.

HLSClaw: Bringing Vibe Coding to High-Level Synthesis through Skill-Based Agentic Harness

Table 4: Inference results of open-source LLMs on Huawei Ascend 910B1 NPUs. Model

NPUs

Tokens

Time (s)

Tokens/s

1 1 4

93 92 128

4.57 7.18 32.22

20.35 12.81 3.97

Qwen2.5-0.5B openPangu-7B Qwen2.5-32B

Qwen-7B

Pangu-7B

10x 3x

2.34x

30x 1.51x

Normalized Latency Speedup

Original (1x)

1x 0.3x

Atax

BNN

anh

GetT

tring

Subs

M

GEM

budgets and parallelism settings. Therefore, these results demonstrate the feasibility of using open-source LLMs for HLS optimization, rather than a strictly controlled comparison of model capabilities.

5

100x

ean Geom

Figure 9: Cycle-based latency speedup of HLSClaw using openPangu-7B and Qwen2.5-7B-Instruct on five benchmarks.

We evaluate Qwen2.5 and openPangu models to validate inference across different model sizes and NPU configurations. For integration with HLSClaw, we deploy openPangu-Embedded-7B on a single NPU and expose it through a lightweight FastAPI server implementing OpenAI-compatible model discovery and chat completion endpoints. HLSClaw communicates with the remote inference server through an SSH tunnel using its existing custom LLM provider, without modifying the agent workflow. The serving configuration uses deterministic decoding (temperature = 0), a maximum generation length of 4096 tokens, and a request timeout of 600 seconds. 4.4.1 NPU Inference Performance. We first evaluate the inference capability of the Ascend platform using three open-source LLM configurations. Table 4 reports the execution time and generation throughput from our initial inference tests. Qwen2.5-0.5B and openPangu-Embedded-7B are executed on a single NPU, whereas Qwen2.5-32B is distributed across four NPUs using layer-wise model sharding. Specifically, its 64 Transformer layers are evenly partitioned across the four devices. All three configurations successfully complete autoregressive generation on the Ascend platform. The 32B experiment further demonstrates the feasibility of distributing a large model across multiple NPUs. Since the measurements involve different model sizes and generation workloads, they serve as functional deployment results rather than a controlled comparison of inference efficiency. 4.4.2 Open-Source Model Comparison. Figure 9 compares the HLS optimization performance of openPangu-7B and Qwen2.57B-Instruct on five selected benchmarks. Speedup is calculated using worst-case latency in cycles, with unsuccessful runs assigned 1×. Pangu achieves a geometric-mean speedup of 2.34×, compared with 1.51× for Qwen, primarily driven by its 46.35× speedup on Atax versus Qwen’s 7.77×. However, Pangu’s Atax result has a negative timing slack of −0.30 ns, and the two models were evaluated under different search

Conference’17, July 2017, Washington, DC, USA

Related Work

HLS Optimization. Existing HLS optimization methods mainly explore hardware directives or apply compiler-based transformations. Directive-search approaches, including AutoDSE [24], COMBA [29], and FADO [11, 12], use heuristic search, analytical models, or learned predictors to identify promising configurations. ScaleHLS [27], SEER [6], and more recent holistic frameworks [21, 22] further optimize source code or intermediate representations and, in some cases, combine code transformations with directive insertion. Nevertheless, these methods generally operate within predefined transformation spaces or fixed optimization orders, limiting their ability to revisit source-level decisions using downstream feedback. LLM-Assisted HLS. Recent studies use LLMs for HLS code generation and optimization. HLSPilot [25] generates and refines synthesizable designs, while HLSRewriter [26] focuses on source-code refactoring. C2HLSC [8] and ChatHLS [18] further demonstrate LLM-based translation, analysis, and optimization for HLS. However, these approaches typically rely on one-shot, fixed-stage, or externally scripted workflows, with limited support for revising earlier restructuring decisions or maintaining structured state across repeated synthesis and rewriting iterations.

6

Conclusion

This paper presents HLSClaw, a skill-based agentic harness for HLS optimization that coordinates code restructuring, directive search, and synthesis feedback. HLSClaw achieves a 39.12× geometricmean latency speedup with strong timing robustness, outperforming ScaleHLS, Claude Code, and Codex, while also supporting userdefined latency–resource trade-offs through goal-aware DSE.

Conference’17, July 2017, Washington, DC, USA

References [1] Stefan Abi-Karam, Rishov Sarkar, Suhail Basalama, Jason Cong, and Callie Hao. 2026. FIFOAdvisor: a DSE framework for automated FIFO sizing of high-level synthesis designs. In 2026 31st Asia and South Pacific Design Automation Conference (ASP-DAC). IEEE, 489–495. [2] Anthropic. 2025. Claude Code: Agentic Coding Tool. https://www.anthropic. com/product/claude-code. Accessed: 2026-04-04. [3] Amir H Ashouri, William Killian, John Cavazos, Gianluca Palermo, and Cristina Silvano. 2018. A survey on compiler autotuning using machine learning. ACM Computing Surveys (CSUR) 51, 5 (2018), 1–42. [4] Suhail Basalama and Jason Cong. 2025. Stream-HLS: towards automatic dataflow acceleration. In Proceedings of the 2025 ACM/SIGDA International Symposium on Field Programmable Gate Arrays. 103–114. [5] ByteDance. 2025. DeerFlow: A Multi-Agent Framework for Deep Research Automation. https://github.com/bytedance/deer-flow. Accessed: 2026-04-13. [6] Jianyi Cheng, Samuel Coward, Lorenzo Chelini, Rafael Barbalho, and Theo Drane. 2024. Seer: Super-optimization explorer for high-level synthesis using e-graph rewriting. In Proceedings of the 29th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 2. 1029–1044. [7] Yuze Chi, Weikang Qiao, Atefeh Sohrabizadeh, Jie Wang, and Jason Cong. 2022. Democratizing domain-specific computing. Commun. ACM 66, 1 (2022), 74–85. [8] Luca Collini, Siddharth Garg, and Ramesh Karri. 2025. C2hlsc: Leveraging large language models to bridge the software-to-hardware design gap. ACM Transactions on Design Automation of Electronic Systems 30, 6 (2025), 1–24. [9] Jason Cong, Muhuan Huang, Peichen Pan, Yuxin Wang, and Peng Zhang. 2016. Source-to-source optimization for HLS. In FPGAs for Software Programmers. Springer, 137–163. [10] Jason Cong, Jason Lau, Gai Liu, Stephen Neuendorffer, Peichen Pan, Kees Vissers, and Zhiru Zhang. 2022. FPGA HLS today: successes, challenges, and opportunities. ACM Transactions on Reconfigurable Technology and Systems (TRETS) 15, 4 (2022), 1–42. [11] Linfeng Du, Tingyuan Liang, Sharad Sinha, Zhiyao Xie, and Wei Zhang. 2023. FADO: Floorplan-aware directive optimization for high-level synthesis designs on multi-die FPGAs. In Proceedings of the 2023 ACM/SIGDA International Symposium on Field Programmable Gate Arrays. 15–25. [12] Linfeng Du, Tingyuan Liang, Xiaofeng Zhou, Jinming Ge, Shangkun Li, Sharad Sinha, Jieru Zhao, Zhiyao Xie, and Wei Zhang. 2024. FADO: Floorplan-aware directive optimization based on synthesis and analytical models for high-level synthesis designs on multi-die FPGAs. ACM Transactions on Reconfigurable Technology and Systems 17, 3 (2024), 1–33. [13] Lieven Eeckhout. 2024. R.I.P. Geomean Speedup Use Equal-Work (or Equal-Time) Harmonic Mean Speedup Instead. IEEE Computer Architecture Letters 23, 1 (2024), 78–82. doi:10.1109/LCA.2024.3361925 [14] Zirui Guo, Xubin Ren, Lingrui Xu, Jiahao Zhang, and Chao Huang. 2025. Raganything: All-in-one rag framework. arXiv preprint arXiv:2510.12323 (2025). [15] Yuko Hara, Hiroyuki Tomiyama, Shinya Honda, Hiroaki Takada, and Katsuya Ishii. 2008. Chstone: A benchmark program suite for practical c-based high-level synthesis. In 2008 IEEE International Symposium on Circuits and Systems (ISCAS). IEEE, 1192–1195. [16] LangChain Inc. 2024. LangGraph: A Library for Building Stateful, Multi-Actor Applications with LLMs. https://github.com/langchain-ai/langgraph. Accessed:

Ge et al.

2026-04-13. [17] LangChain Inc. 2024. Top 5 LangGraph Agents in Production 2024. https: //blog.langchain.com/top-5-langgraph-agents-in-production-2024/. Features LinkedIn, Elastic, Replit, and AppFolio. Accessed: 2026-04-13. [18] Runkai Li, Jia Xiong, Xiuyuan He, Jiaqi Lv, Jieru Zhao, and Xi Wang. 2025. ChatHLS: Towards Systematic Design Automation and Optimization for HighLevel Synthesis. arXiv preprint arXiv:2507.00642 (2025). [19] OpenAI. 2025. Introducing Codex. https://openai.com/index/introducing-codex/. Accessed: 2026-04-04. [20] Louis-Noël Pouchet et al. 2012. PolyBench: The Polyhedral Benchmark Suite. https://www.cs.colostate.edu/~pouchet/software/polybench/ Accessed: 2026-0719. [21] Stéphane Pouget, Michael Lo, Louis-Noël Pouchet, and Jason Cong. 2025. Holistic Optimization Framework for FPGA Accelerators. ACM Transactions on Design Automation of Electronic Systems 31, 1 (2025), 1–37. [22] Stéphane Pouget, Louis-Noël Pouchet, and Jason Cong. 2025. A unified framework for automated code transformation and pragma insertion. In Proceedings of the 2025 ACM/SIGDA International Symposium on Field Programmable Gate Arrays. 187–198. [23] Brandon Reagen, Robert Adolf, Yakun Sophia Shao, Gu-Yeon Wei, and David Brooks. 2014. MachSuite: Benchmarks for Accelerator Design and Customized Architectures. In Proceedings of the IEEE International Symposium on Workload Characterization. Raleigh, North Carolina. [24] Atefeh Sohrabizadeh, Cody Hao Yu, Min Gao, and Jason Cong. 2022. AutoDSE: Enabling software programmers to design efficient FPGA accelerators. ACM Transactions on Design Automation of Electronic Systems (TODAES) 27, 4 (2022), 1–27. [25] Chenwei Xiong, Cheng Liu, Huawei Li, and Xiaowei Li. 2024. HLSPilot: LLMbased high-level synthesis. In Proceedings of the 43rd IEEE/ACM International Conference on Computer-Aided Design. 1–9. [26] Kangwei Xu, Grace Li Zhang, Xunzhao Yin, Cheng Zhuo, Ulf Schlichtmann, and Bing Li. 2025. HLSRewriter: Efficient Refactoring and Optimization of C/C++ Code with LLMs for High-Level Synthesis. ACM Transactions on Design Automation of Electronic Systems (2025). [27] Hanchen Ye, Cong Hao, Jianyi Cheng, Hyunmin Jeong, Jack Huang, Stephen Neuendorffer, and Deming Chen. 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). IEEE, 741–755. [28] Wei Zhang. 2025. Streamlining FPGA Development: Challenges and Opportunities of Agile Design Flows. Keynote at the International Conference on Field-Programmable Technology (FPT). [29] Jieru Zhao, Liang Feng, Sharad Sinha, Wei Zhang, Yun Liang, and Bingsheng He. 2017. COMBA: A comprehensive model-based analysis framework for high level synthesis of real applications. In 2017 IEEE/ACM International Conference on Computer-Aided Design (ICCAD). IEEE, 430–437. [30] Yuan Zhou, Udit Gupta, Steve Dai, Ritchie Zhao, Nitish Srivastava, Hanchen Jin, Joseph Featherston, Yi-Hsiang Lai, Gai Liu, Gustavo Angarita Velasquez, et al. 2018. Rosetta: A realistic high-level synthesis benchmark suite for software programmable FPGAs. In Proceedings of the 2018 ACM/SIGDA International Symposium on Field-Programmable Gate Arrays. 269–278.

Related documents

• Agent Factories for High Level Synthesis: How Far Can General-Purpose Coding Agents Go in Hardware Optimization?#1233806
• Agentic Hardware Design as Repository-Level Code Evolution#319700
• CodeDevX/Vibe-Coding-Instruct#786836
• Case Studies and Reflections on Agentic Software Engineering for Rapid Development of Digital Music Instruments#217809
• Case Studies and Reflections on Agentic Software Engineering for Rapid Development of Digital Music Instruments#187385