Paper deep dive
HLSmith: An Expert-Guided Agentic Framework for C/C++-to-HLS Translation
Yuebo Luo, Ahmad Sedigh Baroughi, Philip Stachura, Le Chen, Venkatram Vishwanath, Zhenman Fang, Caiwen Ding
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 92%
Last extracted: 8/10/2026, 3:19:01 AM
Summary
The paper introduces HLSmith, an expert-guided agentic framework designed to translate baseline C/C++ programs into high-performance High-Level Synthesis (HLS) accelerators. It addresses limitations of existing Large Language Model (LLM) approaches by incorporating a structured HLS optimization expertise library, a staged feedback-driven orchestration flow, and a tool-grounded model adaptation pipeline. Evaluated on PolyBench benchmarks, HLSmith achieves a geometric mean speedup of 4.24x over the ChatHLS framework, producing functionally correct designs for all benchmarks, with speedups up to 252x using commercial frontier models.
Entities (8)
Relation Signals (6)
HLSmith → generates → HLS accelerators
confidence 95% · HLSmith, an expert-guided framework for translating C/C++ programs into optimized HLS accelerators.
HLSmith → outperforms → ChatHLS
confidence 95% · HLSmith achieves a geometric mean speedup of 4.24x over ChatHLS while producing functionally correct designs
HLSmith → evaluatedon → PolyBench
confidence 92% · We evaluate HLSmith on PolyBench against ChatHLS
LLM → struggleswith → hardware intuition
confidence 90% · even frontier models lack the hardware intuition and procedural knowledge needed to reliably translate baseline C/C++ programs
HLSmith → uses → HLS optimization expertise library
confidence 90% · HLSmith combines three components: an HLS optimization expertise library that encodes guarded transformation recipes...
Rodinia-HLS → provides → optimization behaviors
confidence 85% · Rodinia-HLS [6] supplies abundant and staged human HLS optimization behaviors.
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Application-specific FPGA accelerators offer substantial performance and energy-efficiency gains across many application domains, but developing them is costly, often requiring months of specialized effort. Even with high-level synthesis (HLS), designers still need extensive hardware expertise to build high-performance accelerators. Although large language models (LLMs) have demonstrated strong software-generation capabilities, even frontier models lack the hardware intuition and procedural knowledge needed to reliably translate baseline C/C++ programs into high-performance HLS designs: they struggle to identify effective architectures, follow the optimization processes used by HLS experts, and apply hardware transformations consistently across diverse kernels. We present HLSmith, an expert-guided framework for translating C/C++ programs into optimized HLS accelerators. HLSmith combines three components: an HLS optimization expertise library that encodes guarded transformation recipes, their applicability and prerequisite conditions, and unsafe cases to avoid; a staged, feedback-driven orchestration flow modeled on expert HLS development practice that guides agents through synthesis, bottleneck analysis, and optimization; and a tool-grounded model-adaptation pipeline that converts optimization trajectories from commercial frontier models into training data for fine-tuning open-weight LLMs. We evaluate HLSmith on PolyBench against ChatHLS, a leading prior agent-orchestration framework for HLS accelerator development. HLSmith achieves a geometric mean speedup of 4.24x over ChatHLS while producing functionally correct designs, in both software and RTL simulation, for every benchmark, compared with ChatHLS's 57% valid-design rate. It further reaches speedups of up to 252x and 138x with commercial frontier models and open-weight models, respectively.
Tags
Links
- Source: https://arxiv.org/abs/2608.06791v1
- Canonical: https://arxiv.org/abs/2608.06791v1
Trouble viewing inline? Open PDF directly →
Full Text
66,169 characters extracted from source content.
Expand or collapse full text
HLSmith: An Expert-Guided Agentic Framework for C/C++-to-HLS Translation Yuebo Luo ∗ , Ahmad Sedigh Baroughi † , Philip Stachura ∗† , Le Chen ‡ , Venkatram Vishwanath ‡ , Zhenman Fang ∗† , and Caiwen Ding ∗ ∗ University of Minnesota Twin Cities † Simon Fraser University ‡ Argonne National Laboratory ∗ luo00466@umn.edu, zhenman@umn.edu, dingc@umn.edu † asa582@sfu.ca, pstachur@sfu.ca ‡ lechen@anl.gov, venkat@anl.gov Abstract—Application-specific FPGA accelerators can provide substantial improvements in performance and energy efficiency across a range of application domains. However, developing FPGA designs is costly and often requires months of work due to the complexity and specialized expertise involved. Even with higher-level abstraction tools such as high-level synthesis (HLS), designers still require extensive hardware knowledge to develop high-performance accelerators. Although large language models (LLMs) have demonstrated strong software-generation capabilities, even frontier models lack the hardware intuition and procedural knowledge needed to re- liably translate baseline C/C++ programs into high-performance HLS designs. They struggle to identify effective architectures, follow the optimization process used by HLS experts, and apply hardware transformations consistently across diverse kernels. We present HLSmith, an expert-guided framework for trans- lating C/C++ programs into optimized HLS accelerators. HL- Smith combines three components: an HLS optimization exper- tise library that encodes guarded transformation recipes, their applicability and prerequisite conditions, and unsafe cases to avoid; a staged, feedback-driven orchestration flow modeled on expert HLS development practice, which guides agents through synthesis, bottleneck analysis, and optimization; and a tool- grounded model-adaptation pipeline that converts optimization trajectories produced by commercial frontier models into training data for fine-tuning open-weight LLMs. We evaluate HLSmith on PolyBench and compare against ChatHLS, a leading prior agent-orchestration framework for HLS accelerator development. HLSmith achieves a geometric mean speedup of 4.24x over ChatHLS while producing func- tionally correct designs, in both software and RTL simulation, for every benchmark compared with a 57% valid-design rate of ChatHLS. And a speedup of up to 252x and 138x on PolyBench with commercial frontier models and open weight models, respectively. I. INTRODUCTION Application-specific FPGA accelerators can provide sub- stantial improvements in performance and energy efficiency by customizing the compute datapath, memory hierarchy, and parallelism to the requirements of an application [7], [8]. However, these benefits come at the cost of long development cycles and substantial hardware-design expertise. A designer must translate the algorithm into an effective hardware ar- chitecture, making coupled decisions about parallelism, data movement, memory organization, and pipelining under re- source and timing constraints. This makes FPGA accelerator development difficult even for experienced designers. High-level synthesis (HLS) raises the design abstraction by compiling C/C++ programs into register-transfer level (RTL) hardware. HLS removes much of the burden of explicitly describing cycle-level control and datapaths, but it does not remove the need for hardware architecture design. Ordinary algorithmic C/C++ primarily specifies what to compute; it rarely provides the source structure needed to express how the computation should be implemented efficiently on an FPGA. A high-performance HLS design commonly requires coordi- nated transformations such as creating tiled on-chip buffers, reorganizing loops for pipelining, partitioning memories to feed unrolled compute lanes, separating load, compute, and store stages, overlapping these stages with double buffering, and coalescing external-memory transfers [5], [18], [22]. This is not limited to simply applying a pragmas to an existing C/C++ implementation but often requires restructuring of the code to develop a properly architected and optimized design. Consequently, translating baseline C/C++ into optimized HLS requires the same fundamental hardware reasoning and it- erative development process that limits conventional FPGA design. Recent work has explored large language models (LLMs) for automating HLS code generation, compatibility repair, pragma selection, and optimization with synthesis feed- back [1], [3], [4], [12], [13], [15], [16], [19], [24], [26], [27], [29], [30]. These systems demonstrate that LLMs can often produce code that compiles, passes C simulation, and synthesizes. However, a functionally valid HLS program is not necessarily a high-performance accelerator. It may repeat- edly access external memory, serialize computation through a poorly selected loop, require more concurrent accesses than the available local-memory ports, or lack the architectural stages needed to overlap communication and computation. ChatHLS, the most versatile prior framework, specializes models for HLS-C generation, error repair, directive plan- ning, and validation, but its optimization flow focuses on directive tuning and does not perform algorithm-level C/C++ refactoring [13]. Other agentic systems, including LAAFD, Agent Factories, and AgRefactor, improve HLS optimization through iterative feedback, larger agent searches, or knowledge accumulated across tasks [3], [16], [30]. However, they do not explicitly encode or systematically evaluate the hardware- architecture expertise and multistep development process that experienced HLS designers use to progressively restructure arXiv:2608.06791v1 [cs.AR] 7 Aug 2026 Fig. 1.From functional HLS-C to architecture-aware optimization. The top row isolates one-shot generation, feedback without explicit HLS expertise, and broad unordered guidance; these are control mechanisms rather than full characterizations of the cited systems. The bottom row shows HLSmith’s bottleneck- conditioned, prerequisite-aware, validated workflow. Baseline exemplars are HLS-Eval, Agent Factories, C2HLSC, and LAAFD [1], [3], [4], [16]; layout inspired by CUDAHercules [14]. baseline C/C++ into a high-performance accelerator. We identify three limitations that prevent existing LLM- based approaches from consistently translating baseline C/C++ into expert-quality HLS accelerators, shown in Figure 1. (1) General-purposeLLMshaveweakhardware- architecture intuition. They are effective at preserving soft- ware functionality but often fail to reason about the spatial architecture of the source code, including locality, banking, pipeline initiation interval, resource replication, and commu- nication bandwidth. (2) LLMs lack procedural knowledge of the HLS devel- opment process. Experienced HLS designers do not treat C-to-HLS conversion as a single code-generation task. They follow a staged development process: first establishing a cor- rect and synthesizable baseline, then diagnosing architectural bottlenecks, and finally refining the design through successive optimization stages that build on earlier transformations. (3) LLMs struggle to apply optimization strategies consis- tently across diverse kernels. HLS transformations often de- pend on program structure and prerequisite changes: unrolling requires sufficient memory banking to feed replicated lanes, while double buffering requires separable load, compute, and store stages. A broad, unordered list does not tell the model which optimization is applicable or how to apply it safely. In this paper, we present HLSmith, an expert-guided frame- work for translating baseline C/C++ programs into optimized HLS accelerators. HLSmith encodes HLS optimization ex- pertise through a structured library of guarded transforma- tion recipes and avoidance rules. Each library entry asso- ciates a bottleneck with structural preconditions, ordered code changes, and safety guards. These recipes and rules guide a staged, feedback-driven orchestration flow that first establishes a correct and synthesizable HLS baseline, then uses HLS tool reports to diagnose performance bottlenecks and apply suc- cessive optimizations when their preconditions are met. The same tool-grounded workflow records optimization trajectories produced by commercial frontier models and converts them into training data for fine-tuning open-weight LLMs. Together, these components capture both reusable HLS optimization expertise and the staged development process required to produce high-performance accelerators. We evaluate HLSmith on HLSFactory-28, a fixed set of 28 PolyBench kernels. Compared with ChatHLS, HLSmith achieves an average speedup of 4.2× while producing func- tionally correct designs in both software and RTL simulation, compared with a 57% valid-design rate for ChatHLS. Fine- tuning further improves performance by up to 3.61× for a single kernel and 70% overall improvement with GRPO applied to models as small as 7B, and with commercial models achieves up to 252× speedup over the reference HLS kernel. In summary, this paper makes the following contributions: 1) A structured HLS optimization-expertise library compris- ing guarded transformation recipes and avoidance rules that encode bottleneck and applicability conditions, rele- TABLE I METHODOLOGICAL SCOPE AND PUBLIC-SOURCE AVAILABILITY OF REPRESENTATIVE LLM-BASED HLS SYSTEMS. Comparable end-to-end workflow scopeOptimization mechanism and availability System HLS-C generation Tool-grounded repair QoR-feedback optimization C/RTL verification Architecture restructuring HLS-specific model adaptation Guarded, ordered optimization recipes Open source HLS-Eval (One-shot) [1] ✓ —◦— ✓ C2HLSC [4] ✓ ◦— ✓ HLSRewriter [27] ✓ ◦ ✓ —◦ ✗ Agent Factories [3]◦ ✓ ◦ ✓ — ✗ LAAFD [16] ✓ ✓ — ✗ AgRefactor [30] ✓ ◦ ✓ —◦ ✓ ChatHLS [13] ✓ — ✓ — ✓ HLSmith (this work) ✓ Pending ◦: partial; —: absent. vant structural requirements, ordered transformation steps, and safety guards. 2) A staged, feedback-driven orchestration framework mod- eled on expert HLS development practice, which sepa- rates baseline synthesis, tool-guided bottleneck analysis, and successive optimization into distinct phases, greatly improving LLM actors’ performance from zero-shot at- tempts. 3) A tool-grounded model-adaptation methodology that con- verts commercial frontier-model optimization trajectories, evaluated using correctness and HLS-tool feedback, into training data for fine-tuning and reinforcement learning on open-weight LLMs to perform HLS optimization across diverse kernels. I. RELATED WORK Traditional compiler- and DSE-based approaches automate HLS optimization through synthesis-guided search, multi-level transformations, and joint optimization of code and direc- tives [18], [22], [28]; however, they do not investigate reusable optimization expertise as an explicit inference-time component of an LLM workflow. LLM-based HLS generation, evaluation, and optimiza- tion. Recent work has established HLS as a distinct target for language models. HLS-Eval [1] provides a benchmark and evaluation framework for two core tasks: generating HLS code from natural-language descriptions and editing HLS code for optimization, while Gai et al. [12] study benchmark con- struction, fine-tuned HLS generation, and prompting effects such as chain-of-thought and feedback loops. HLSPilot [24] reduces the gap between sequential C/C++ and HLS by sup- plying pattern-specific C-to-HLS strategies through in-context learning, then relying on profiling and downstream DSE for pragma tuning. RALAD [26] provides an existing, non-HLS- specialized LLM with retrieved HLS code examples and explanations to guide pragma insertion. LIFT [19] trains an LLM to infer predefined pragma configurations, whereas HLS- Seek [29] trains an HLS code generator with QoR rewards and selective synthesis feedback. LLM-based refactoring and repair for HLS. A second line of work focuses on transforming software-oriented C/C++ into synthesizable or better-optimized HLS-C. C2HLSC [4] iteratively refactors generic C into HLS-compatible C using hierarchical preprocessing and feedback from compilation and HLS, then performs a separate pragma-identification stage. HLSRewriter [27] starts from regular C/C++ and combines step-wise compatibility analysis, a RAG-based repair-template library extracted from HLS manuals, pipeline-aware loop decomposition, bit-width adjustment, and subsequent pragma- based PPA optimization. TimelyHLS [15] uses a structured, architecture-specific knowledge base and iteratively refines generated HLS code using HLS and RTL synthesis logs, timing reports, and functional-correctness feedback. These systems show that LLMs can assist with compatibility repair, code restructuring, and architecture-aware refinement, but they do not isolate the effect of explicitly represented, reusable HLS optimization expertise combined with guarded and ordered application of transformations. Agenticandfeedback-drivenHLSworkflows. ChatHLS [13] is the most directly comparable reproducible baseline for our study. It provides a multi-agent workflow spanningHLS-Cgeneration,tool-groundeddebugging, verification, and iterative QoR-aware directive tuning. Its optimization component, HLSTuner, models the directive- to-hardware-to-QoR relationship and selects, configures, and inserts directives such as PIPELINE, UNROLL, and ARRAY PARTITION,withoutperformingsource-level architectural restructuring. LAAFD [16] uses iterative synthesis feedback within an agentic workflow for latency-oriented HLS kernel generation and optimization. Agent Factories [3] explores inference-time agent scaling through sub-kernel decomposition, ILP-based composition, and design-wide refinement. AgRefactor [30] combines cross-task memory with automated refactoring tools to ensure HLS compatibility and optimize performance. In par- ticular, it integrates HeteroRefactor, a profile-guided, source- to-source refactoring and optimization tool for FPGA HLS, rather than a complete compiler or HLS backend. Although these systems employ tool feedback, multiple agents, source transformations, or reusable memory, they do not explicitly isolate the effect of guarded, ordered HLS optimization recipes across successive transformations. Comparison scope and artifact availability. Table I compares methodological scope and public-source availability rather than reported QoR, since the systems use different Plain C input Translator Agent Read Benchmark Add Pragmas Algorithm focused Compile C input Benchmark spec Vitis HLS C-Simluation C-Synthesis RTL-Simulation Translated Baseline QoR Check Error log Synth Report Initiate Repair Expertise Library Sourced expert code Distilled expert intent Professional instruct Rodinia-HLS Bench Multi-step Expertise Expert Reference code Learn & Distill Best-of-N Selection Check Bottlenecks Search Usable Expertise Apply Expertise Orchestrator Coordinate agents Select Optimize Act Action Router Rank bottlenecks Match applicable expertise Selected Expertise Synth Report Feedback Flash Mode---One Step in All Optmization Plain C input All-in Edit with Expertise Buffer Pipeline Unroll Candidates QoR Best Valid Multi-step Mode---Expert Instinct Enforced by-step Optmization DiagnoseRoute Expertise Expert Step Validate Keep/ RestoreNext Step Plain C input Workflow Target Optmized HLS Plain C inputSys Workflow Workflow Metric 1 2 3 4 Action Request Router Response 5 6 7 Return Decision Select expertise Retain best valid design Action Complete Bottleneck Initial r esult Action Decision Optimizer Agent Lower CyclesFunctionality Correctness Fig. 2. End-to-end HLSmith workflow. The numbered path translates plain C, evaluates the HLS-C design, diagnoses its bottleneck, routes the guarded recipe in Eq. (2), and validates the resulting edit. The upper paths contrast independent single-step candidates with repeated multi-step feedback; the Orchestrator coordinates both and preserves the best eligible design. benchmarks, hardware targets, optimization objectives, and execution overhead. In the table, tool-grounded repair means that an HLS-tool failure conditions a subsequent code edit, while QoR-feedback optimization means that measured la- tency or resource results condition a subsequent optimization. Architecture restructuring denotes source-level changes to loop organization, memory access, buffering, or dataflow structure beyond directive insertion. HLS-specific model adaptation de- notes fine-tuning or other changes to model parameters using HLS-specific data. Guarded, ordered optimization steps are reusable representations that encode applicability conditions, guards, and an ordered sequence of transformation steps. Positioning of HLSmith. HLSmith studies a mechanism not explored by prior LLM-based HLS systems. Rather than asking only whether retrieval helps, whether general-purpose agents can scale, or whether iterative feedback improves optimization, we study whether HLS optimization expertise can be represented as reusable, guarded procedures and applied through a staged controller that accounts for transformation order and applicability. HLSmith represents this expertise as a library of guarded transformation recipes and avoidance rules. Each entry encodes a bottleneck context, applicability conditions, relevant structural requirements, safety guards, and ordered transformation steps. This representation separates three mechanisms that are often conflated in prior work: selecting relevant HLS knowledge, applying a source-level ar- chitectural transformation, and determining which subsequent optimization is applicable after the current structural changes have been established. We further compare a single-turn Flash flow with a structured multi-step flow under matched controls, evaluate candidates using the HLS tool, and retain the best valid candidate design. I. C-TO-HLS TASK AND OBJECTIVE A. Input, Output, and Evaluation Setup For each kernel, HLSmith receives an algorithmic C im- plementation without HLS pragmas, a corresponding refer- ence HLS implementation used as the gold reference, the public header and top-level function interface, test inputs, independently computed CPU reference outputs, and the target hardware configuration and resource constraints. HLSmith then produces an optimized C/C++ implementation for Vitis HLS. The generated implementation may restructure loops and arrays, introduce local buffers, add explicit processing stages, reorganize memory accesses to enable burst transfers, and insert HLS pragmas for interfaces, pipelining, loop unrolling, array partitioning, dataflow, and AXI memory configuration. B. Candidate Eligibility, Selection, and Validation For a method m, let C m be the candidates generated within its resource budget. The eligible set E m ⊆ C m contains only candidates that pass C simulation with verified functional correctness, complete C synthesis, fit every target-device re- source limit, and meet the target clock period. The orchestrator (Section IV.A) selects based on Equation (1) as follows: c ⋆ m = arg min c∈E m b L(c),(1) where b L(c) is the worst-case HLS-synthesis latency. If E m is empty, the method fails on the task. Only selected candidates c ⋆ m undergoes RTL co-simulation. IV. METHODOLOGY A. Agent Workflow and Compiler Feedback HLSmith assigns distinct roles to translation, tool-grounded evaluation, bottleneck diagnosis, and optimization. The agents are execution mechanisms. Translator. At step 1 ⃝ in Fig. 2, the Translator converts algorithmic C into an initial HLS-C implementation. Toolchain evaluator. Vitis C simulation and synthesis es- tablish functionality, synthesizability, latency, timing, and used hardware resources. QoR Check. The Feedback role converts tool output into a concise diagnosis: compile or correctness faults, performance Fig. 3. Prerequisite-aware HLS optimization. Tiling creates local reuse, banking supplies ports for parallel lanes, and stage separation enables double-buffered overlap. Each step instantiates the contract in Eq. (2). bottlenecks involving latency, initiation interval, timing, re- source pressure, dependencies, scheduling, and memory ports. This diagnosis identifies the triggering bottleneck b used by the expertise in Eq. (2). Optimizer. The Optimizer receives the diagnosis profile and selects useful expertise from the expertise library. Execute the candidate HLS kernel rewrite following expertise guidance. A multi-step run repeats this loop up to a default cap of five attempts. Final selection uses Eq. (1), and only the selected winner proceeds to the reported RTL check. Orchestrator. The Orchestrator sequences the aforemen- tioned roles, maintains the current and best eligible designs, and routes the best configuration combination set by flash mode/multi-step mode execution and expertise policies. It asks the Action Router for expertise that matches the current bottleneck diagnosis, evaluates the resulting candidate, and either advances the search or restores the previous best state. HLSmith supports two search depths. In flash mode, in- dependent candidates receive the same initial report, and each attempts one expertise-guided code generation. In multi- step mode, every accepted candidate is evaluated again, and the new evidence conditions the next recipe. This separates one-turn guidance from prerequisite-aware sequencing and repeated feedback. Fig. 2 shows an overview of the system framework. The path in the middle illustrates how the system generally translates ( 1 ⃝), profiles the initial version ( 2 ⃝, 3 ⃝ and 4 ⃝), then optimizes HLS candidates with sourced expertise from the library ( 5 ⃝ and 6 ⃝) until the final candidate wins ( 7 ⃝); the lower path shows the Orchestrator and Action Router controlling the loop. The top left and right panels contrast all-in-one flash mode with expertise-enforced multi-step optimization mode. B. From Rodinia-HLS Patterns to Optimization Expertise Rodinia-HLS [6] supplies abundant and staged human HLS optimization behaviors. It provides examples of step-by-step architectural changes including tiling intermediate variables, pipelining legal loops, matching compute lanes to mem- ory banks, overlapping separable stages, and coalescing data transfer. A specific HLS kernel design can integrate several optimization techniques, so HLSmith learns and distills the fundamental optimization principles rather than the individual changes of specific HLS kernels in the benchmark. 1) Implementation of Per-step Expertise: Each set of opti- mization techniques applied is represented as: s =⟨b,p,a,q,g,e⟩,(2) where b is a bottleneck found in the current HLS kernel diagnosis profile, p the HLS code structural prerequisites, a the architectural action such as rewrite and edit, q an ordered action checklist, g unsafe conditions that the actions should avoid, and e the expected results from the actions. Table ?? shows examples of these fields: its triggering-evidence of the bottleneck column gives b; the related architecture concept gives a; and the guarded implementation combines p, q, g, and e. Equation (2) is the interface between expert knowledge and the agentic workflow. At turn t, the QoR Check produces bottleneck b t . The Action Router admits a recipe of actions to optimize only when its b matches b t , its prerequisites p hold in the current design, and no guard g is needed to apply. The Optimizer receives the list of optimization actions a and checklist q; The Vitis report generated from the optimized candidate is compared with e. The last best design would be restored if the optimized candidate fails. If the optimization loop advances, Eq. (1) chooses the final eligible candidate. Fig. 3 exemplifies the prerequisite relation in Eq. (2). Tiling creates reusable local data; banking supplies enough ports Translated HLS TRMM Kernel Repeated global accesses est. cycles: 22,598,401 Mem Banking Local matrix row + acc Cyclic Factor 8 est. cycles: 469,321 Double Buffer Local row buffers Load/Comp Overlap est. cycles: 181,621 Pipeline Full-B staging Pipeline legal loops est. cycles: 159,267 Tiling Reuse Full-B staging Pipeline legal loops est. cycles: 97,914 Match Lanes+banks Actor-8 banking +unroll Parallel Accumulators est. cycles: 26,233 Profile Re-Pr ofile Period Down Reuse Up Expose Lanes 123456 Fig. 4. HLS-Factgory’s TRMM optimization process with HLSmith (base model Claude Sonnet 4.6). Each intermediate design synthesizes and lowers Vitis’s cycle estimate, with the CO-SIM measurement of the final design. This illustrates the multi-step mechanism that builds up an overall improvement. (a) Hybrid setup-predictor architecture Input x k : plain C,initial HLS report, ten setups 易 Structured / Embedding Committee ET log-regret, within-5%, pairwise + frozen source retrieval Prompted Qwen3-0.6B 45 A/B setup comparisons from token-logit margins Normalized-Rank Consensus Keep Top-4 Semantic Setup Ranking Keep first unique Top-1 R(x k ): Five Setups ● ● ● ● ● ⚙ Run Each Workflow → golden, CSim, CSYN, timing, and fit gates → lowest-cycle valid design 1: 2: 3: 烙 4: ☷ 5: ☆ 6: 7: ↻ for each s ∈ R do 8: ⚙ 9: if AllGatesPass(c) and 10: 11: ⇥ return (b, R, candidate evidence) The predictor reduces ten mode-expertise combinations to five. The action router then chooses optimization steps inside each retained workflow. Fig. 5. Hybrid setup routing. A structured rank committee and an independent semantic comparator rank workflow configurations before candidate genera- tion; fusion retains complementary choices for execution. before unrolling creates parallel lanes; and separating load, compute, and store stages enables double-buffered overlap to hide latency. These steps are ordered, performed flexibly and dynamically, as outlined in the QoR report. C. Expertise-Guided Optimization and Best-Design Recovery The Action Router maps each diagnosed bottleneck to one of five source-level optimization families: local tiling, pipelin- ing, unrolling with memory banking, double-buffered stage overlap, and memory-access coalescing. At each optimization step, the router ranks applicable library entries and provides the selected entry’s applicability pattern, strategy, ordered transformation steps, and safety guards to the Optimizer Agent. In multi-step execution, each new synthesis report triggers another diagnosis and routing step, allowing subse- quent transformations to reflect the current implementation and its remaining bottlenecks. Under the selected-expertise, the Optimizer receives only the routed entries, whereas the all-expertise provides all library entries and therefore evaluates targeted selection against broad exposure to expertise. Each generated candidate is first compared with the inde- pendent functional reference for functional correctness checks. Candidates that pass these checks undergo synthesis to de- termine latency, timing, and resource feasibility. A failed, unchanged, or lower-quality candidate does not replace the best eligible design that the Orchestrator retains. When op- timization terminates, the internal scores used to manage intermediate steps are discarded, and Eq. (1) selects the eligible candidate with the lowest HLS-estimated latency. Only Algorithm 1 Vitis-grounded GRPO adaptation Require: Tasks D = (x k ,L 0 k ), resource limits B, policy π θ , group size G, stabilizer ε A 1: for each policy update do 2:for each task context x k in the batch do 3:Sample a k,1 ,...,a k,G ∼ π θ old (·| x k ) 4:for i = 1,...,G in parallel do 5:(z k,i ,Q k,i )← VITISCSIMCSYNTH(a k,i ,k) 6:r k,i ← HLSREWARD(z k,i ,Q k,i ,L 0 k , B) 7:end for 8:A k ← (r k − mean(r k ))/(std(r k ) + ε A ) 9:end for 10:Apply a completion-token-masked clipped GRPO update 11: end for 12: return adapted Translator this selected design undergoes RTL co-simulation; a run is considered valid, and RTL cycles are reported, only if co- simulation completes successfully and its outputs match the same independent reference. D. Example: Multi-Step Optimization of HLSFactory TRMM Using expertise from Rodinia-HLS to the HLS-Factory benchmark’s TRMMkernel, the plain C code updates each row of a dense matrix from later rows and one strided column of a triangular matrix. Its direct loop nest repeatedly moves the same data and exposes neither sufficient reuse nor independent memory-fed arithmetic lanes. Fig. 4 shows how the HLSmith translates and optimizes the TRMM kernel with base model Claude Sonnet 4.6. The baseline kernel starts from a 22,598,401-cycle HLS estimate; after the HLSmith applies local staging and cyclic banking, it reduces the estimate to 469,321 cycles. On top of that, a double-buffered candidate that stems from the previous step reaches 181,621 cycles but misses the 3.33-ns clock period target, so the next report changes the direction of optimization. Full-matrix local staging and a pipeline rewrite is then applied to reach 159,267 cycles; then, the tiling is applied to the last best candidate and reaches 97,914 cycles. Finally, factor-eight banking and unrolling match memory ports to arithmetic lanes are implemented on the last step’s work and reach 26,233 cycles at 2.494 ns. All five intermediate designs synthesize and improve the preceding cycle estimate. The selected design reports 50,040 executed co-simulation cycles, and all 4,800 output values match the independent CPU result. For prompt-time expertise comparisons, we hold the model weights fixed and vary only the expertise provided to the TABLE I ROUTER AND POST-TRAINING CONFIGURATIONS. ComponentModel / dataKey settings Early setup routerQwen3-0.6B; 19/4/4/1 (train/validate/test/excluded) split; 874/191/186 (train/validate/test) historical and 190/40/40 complete rows ExtraTrees: latency ratio, within-5%, and pairwise order; embedding retrieval; 45 pairwise prompts; structured top four + unique semantic top one (five of ten setups) Supervised fine-tuningSonnet 4.6 → Qwen3.6-27B; 165 actions; 22 training/five held-out kernels; Translator, Synthesis, and Orchestrator 4-bit NF4 QLoRA [9]; rank 16; one epoch Group-relative policy optimizationQwen2.5-Coder-7B; 14 Rodinia/ML4Accel training tasks; PolyBench evaluation Group size 8; LoRA rank 32; clip 0.2; zero KL coefficient; temperature 1.0; 1,536-token cap; 100 updates; learning rate 10 −5 TABLE I ROUTER SEARCH SPACE: TWO WORKFLOWS× FIVE EXPERTISE POLICIES. Expertise PolicyLibrary view Candidates flash / multi NoneDisabledEmpty1 / 1 per step SelectedMatchedUp to three deterministic matches1 / 1 per step Best-fitZero to three evidence-ranked entries1 / 1 per step Exhaustive One candidate per eligible entry (up to five) ≤ 5 / ≤ 5 per step AllFull42 positive entries, applicability-gated1 / 1 per step model. For model-adaptation comparisons, we hold the work- flow and expertise policy fixed and vary only the model weights. Kernels used for evaluation are excluded from the model-adaptation training data. E. Hybrid Early-Prediction Setup Routing We define a workflow setup as a complete HLSmith con- figuration. Throughout the HLSmith, the inner Action Router in Fig. 2 selects an optimization action list within a single workflow run. A second, outer early-prediction setup router decides which workflow configurations are worth proceeding. The setup router observes only the plain C source and its initial HLS report, then ranks workflow-depth and expertise-policy combinations before the design is generated. Section V-A specifies the evaluated setup space and execution overhead in terms of time and tokens. Fig. 5 shows the two complementary ranking branches. The structured branch combines latency prediction, near-optimal classification, pairwise ordering, and preference transfer from similar kernels. Rank consensus merges these features. The semantic branch, supported by Qwen-0.6B, compares config- uration descriptions in the context of the source and initial HLS report, then contributes a non-duplicate recommendation; this prioritizes agreement among measured predictors while reserving an independent semantic judgment. The concrete predictors, shortlist size, and data split can be found in Section V-A. Let S denote the available setups, R(x k ) ⊂ S the subset retained for kernel context x k , and L k (s) =∞ when setup s does not produce a valid, timing- and resource-feasible design. We quantify the cost of pruning by the latency ratio as follows: Γ k (R) = min s∈R(x k ) L k (s) min s∈S L k (s) ≥ 1.(3) After routing, Eq. (1) chooses the valid candidate with the fewest cycles. Neither branch sees optimized-candidate out- comes at prediction time. F. Post-Training of Open Model In addition, we study two complementary forms of post- training for open models that serve as the base model of HL- Smith. (1) Offline supervised fine-tuning (SFT) distills feasible actions from a stronger teacher, whereas (2) reinforcement learning directly favors programs that obtain higher measured HLS quality of results (QoR). 1) Offline SFT from Validated Agent Actions: We build supervision from expertise-guided teacher artifacts. Each ex- ample joins a model-call context x—agent role, HLS kernel, feedback, and indexed expertise—with the response y and the corresponding candidate’s Vitis evaluation. An example enters the positive setD + only if the response contains code and the derived candidate completes C simulation and HLS synthesis while meeting the target period and device constraints. The target model’s chat template renders each conversation, and a completion mask M x,y,t equals one only for the com- plete assistant target and excludes the prompt and framework context. With frozen base-model parameters θ and trainable adapter parameters φ, the objective is as follows: L SFT (φ) =− P (x,y)∈D + P t M x,y,t logp θ,φ (y t | x,y <t ) P (x,y)∈D + P t M x,y,t . (4) Because each supervised completion token receives the same cross-entropy weight and latency, neither weights nor se- lects examples, SFT imitates validated, expertise-conditioned teacher actions without directly optimizing latency, neither invoking Vitis nor an external LLM. The teacher, target roles, corpus split, and adapter settings appear in Section V-A. 2) Vitis-Grounded Group-Relative Policy Optimization: To optimize QoR directly, we formulate Translator adaptation as a single-step contextual bandit rather than reinforcement learning over the multi-step agentic workflow. The context is the plain source, header, and top-level function; an action is one complete generated HLS kernel. QoR from Vitis C simulation and synthesis are mapped to a scalar reward. The TABLE IV EVALUATION MATRIX. HLS CYCLES ARE SYNTHESIS ESTIMATES; RTL CYCLES COME FROM CO-SIMULATION. StudyModels / workloadCompared configurationsEvidence Teacher sweepSonnet 4.6, Opus 4.8, GPT-5.5; 26 PolyBench kernels Zero-shot; flash/multi-step × no, selected, or all expertise C simulation, HLS synthesis, timing, and fit; no golden-output or RTL check Open-model sweepGemma-4-31B [23], Qwen3.6-27B [20]; 27 PolyBench kernels flash/multi-step × five expertise policiesCPU-golden output, C simulation, HLS synthesis, timing, and fit Setup routerSonnet 4.6; 19 group-held-out kernelsPredicted five versus exhaustive ten setupsGroup-held-out ranking; valid-candidate HLS cycles Supervised fine-tuningQwen3.6-27B; five held-out kernelsZero-shot; flash/multi-step × expertise off/onAgentic: CPU golden through timing/fit; Zero-shot: print-only C simulation and synthesis; no RTL Policy optimizationQwen2.5-Coder-7B; 14 training and 24 evaluation tasks Base versus supervised versus reward-tunedTraining: C-simulation-gated QoR reward; evaluation: reported RTL Additional RTLDeepSeek-v4 Flash [25], Grok, HLSmith/ChatHLS Expertise sensitivity and cross-system comparison Supplied RTL cycles; no independent output replay adapted Translator can subsequently be used inside the full HLSmith workflow. We use group-relative policy optimization (GRPO) [21], summarized in Algorithm 1. a k,i , z k,i is its terminal tool outcome and Q k,i contains latency L k,i and resource use U k,i,d . The reward separates a correctness ladder from latency benefit and resource pressure: er k,i (h) = b + αh L 0 k L k,i − β X d max 0, U k,i,d B d − 1 . (5) Here d ranges over FPGA resource classes and B d is the corresponding hardware resource scoped by the target FPGA. Equation (5) gives latency credit only after the tool outcome reaches the valid-design tier; lower tiers receive terminal scores. Among valid candidates, h rewards speedup relative to the baseline, while the final term penalizes only resource- budget excess defined by the target FPGA. Concrete reward constants, rollout settings, adapter parameters, and training data appear in Section V-A. Table I gives the router’s complete configuration space. Matched-positive, best-fit, and exhaustive are sub-policies of Select expertise; each exposes a kernel-dependent subset of the expertise library. V. EVALUATION A. Experimental Setup Table IV provides an overview of HLSmith experiment setup for evaluation. The teacher-model sweep crosses flash and multi-step execution with no, selected, or all architectural expertise. Zero-shot generation is a separate arm. Within a study, comparisons fix the model, input, initial design and report, prompt, and candidate hardware resource budget. Flash mode candidates independently start from the same state; multi-step runs condition each action one by one on the newly accepted tool result. Exhaustive best-of-setup values are search ceilings. The learned router is evaluated separately through Eq. (3). Motivated by the three major challenges identified in Section I—limited architectural reasoning in general-purpose LLMs, insufficient procedural knowledge of HLS develop- ment, and difficulty selecting kernel-appropriate optimization techniques—we evaluate the effectiveness of expertise and workflow design, early setup/configuration routing, and open models with and without post-training using HLS synthe- sis, correctness checks, and, ultimately, RTL co-simulation profiles. The router validation split selects benchmarks by the architecture characteristics, performance and resources thresholds, and the complexity of the benchmark. In the valida- tion split, selected kernels are durbin, floyd_warshall, gemm, and trmm. For the GRPO experiment, we set that b = 0.2, α = 0.6, β = 0.5, h(z) = min(2,z), B d to 50% of U280 capacity (to help encourage feasible designs), and ε A = 10 −4 in Eq. (5). Valid rewards are clipped to [−0.4, 2]; Abnormal cases such as empty or simulation-dependent out- put, tool failure or timeout, and mismatch or near-empty circuits receive −1.0, −0.8, and −0.6, respectively. The C simulation serves as the gate for rollouts; target timing and RTL correctness remain downstream evaluations. HLSFactory, serving as our major benchmark, supplies the construction flow for 28 PolyBench HLS kernels [2], [17]. On top of that, output value checks are added to ensure correctness signals perform normally. This becomes ”CPU-golden” as golden references. As a result of our added measures, table IV establishes independent numerical agreement. Unless the table states otherwise, a candidate is eligible only after C simulation, synthesis, target-timing, and device-resource checks. Through- out the experiment, we report valid-design counts and speedup ratios, with all failures and exclusions [10]. A common valid denominator is used to produce Geometric means of the overall speedup against golden references; paired confidence intervals use bootstrap resampling [11]. Vitis HLS 2023.2 targets AMD Alveo U280 FPGA (device: xcu280-fsvh2892- 2L-e) at 300 MHz throughout the matched local studies. B. Architectural Expertise and Multi-Step Optimization For kernel k, let B k , S k , and O k be the benchmark-baseline, selected-design, and selected expertise-off cycles. Table V reports geometric means of B k /S k and O k /S k on a common cohort; values above one favor S k . The agentic framework 1/64 × 1/8 × 1 × 8 × 64 × 512 × N/RN/R (a) Claude Sonnet 4.6 88.6 139 7.4 5.8 33.7 20.8 133 2.8 † 4.8 2.2 10.6 18.0 3.3 7.1 1.2 4.1 77.9 16.3 5.2 8.5 20.9 90.9 117 117 10.4 62.2 1/64 × 1/8 × 1 × 8 × 64 × 512 × N/RN/R (b) Claude Opus 4.8 88.6 145 5.1 7.1 19.2 11.2 5.6 3.1 5.3 3.6 6.6 23.1 5.6 5.2 4.5 3.9 18.9 20.7 9.7 8.5 41.1 13.1 117 117 10.3 252 1/64 × 1/8 × 1 × 8 × 64 × 512 × N/RN/R (c) GPT-5.5 52.7 74.0 † 5.0 5.2 11.2 2.9 31.6 3.7 2.7 3.7 6.5 † 5.5 2.9 † 3.7 9.1 8.3 5.4 47.3 5.2 8.2 42.7 13.1 98.9 117 6.8 51.5 1/64 × 1/8 × 1 × 8 × 64 × 512 × EO N/R E N/R (d) DeepSeek V4 Flash 87.8 138 6.9 4.8 1.07 3.5 1.5 1.2 1.9 1.6 1.1 1.3 3.1 1.07 8.5 1.4 1.4 3.8 5.2 2m3m atax bicg cholesky correlation covariance doitgen durbin fdtd-2d floyd-warshall gemm gemver gesummv gramschmidt heat-3d jacobi-1djacobi-2d lu ludcmp mvt nussinov seidel-2d symm syr2k syrk trisolv trmm HLSFactory kernel (numeric/alphabetic order) 1/64 × 1/8 × 1 × 8 × 64 × 512 × N/RN/R (e) Grok 4.5 87.7 7.5 3.2 4.8 5.1 10.0 4.3 6.1 2.0 6.8 6.4 2.6 4.6 1.7 2.9 2.3 1.8 3.9 1.3 15.0 13.5 3.3 3.8 71.0 Speedup over benchmark baseline Solid/hatched: single-/multi-step; ×E/×O: expertise-on/off failure; N/R: unavailable comparison; cross-hatch: excluded Grok repeat; † : partial grid Expertise off (bar/diamond)Selected expertiseAll expertise Fig. 6. Per-kernel benchmark-baseline speedup. Bars show B k /S k and diamonds B k /O k . Rows (a–c) use HLS synthesis; rows (d–e) use RTL co-simulation. Crosses denote failures, daggers incomplete grids, N/R a missing baseline, and cross-hatch unmatched Grok reruns. TABLE V COMMON-COHORT SUMMARY OF FIG. 6. COVERAGE IS ELIGIBLE KERNELS/26; TEACHER ROWS REQUIRE ALL SIX SETUPS, WHEREAS RTL ROWS REQUIRE AN EXECUTED BASELINE AND BOTH FLASH ARMS. FIVE UNMATCHED GROK RERUNS ARE EXCLUDED. ModelEvidenceCompared setupsCoverage Benchmark-baseline speedup Expertise-off speedup Expertise wins/losses Claude Sonnet 4.6HLS synthesisExhaustive setup selection25/2617.46×2.88×22/3 Claude Opus 4.8HLS synthesisExhaustive setup selection26/2614.51×2.63×23/3 GPT-5.5HLS synthesisExhaustive setup selection23/2611.39×2.30×17/6 DeepSeek V4 Flash RTL co-simulation Flash mode22/262.58×2.55×17/5 Grok 4.5RTL co-simulation Flash mode21/264.47×1.87×17/4 using teacher (Claude Sonnet 4.6) and other models (Claude Opus 4.8, Grok 4.5, and DeepSeek v4-flash) is tested against six agentic setups, with all three sub-categories of the select- expertise policy merged into a single class for notational simplicity, while RTL co-simulation rows use a single all- expertise mode setup. Table V and Fig. 6(a–c) summarize three sweeps. Sonnet 4.6 completes 180/182 requested cells: all 26 zero-shot and 154/ 156 agentic cells; two multi-step doitgen cells are absent. All 154 completed agentic cells meet timing and resource limits, versus 18/26 zero-shot designs. On 25 completed tasks, B k /S k is 17.46× versus B k /O k =6.07×; thus expertise adds 2.88× and wins 22/25 kernels against expertise off. In comparison, Opus 4.8 advances 15/26 cases in zero- shot and 25/26 agentic designs meet timing and resource limits. With expertise selection policy applied, an overall speedup of B k /S k =14.51× and O k /S k =2.63×; are reached, and and beating expertise off cases in 23/26 benchmarks; expertise selection policy yields 1.03×/ 1.30× cycle reduction 2.12×/ 1.58× for all expertise policy applied (flash/multi- step). Selected expertise benefits more from rerouting, whereas all expertise helps more in one step. In addition, GPT-5.5 executes 153/156 agentic cells; 152 synthesize and 150 also meet timing and resource limits. On 23 complete grids, B k /S k is 11.39×, O k /S k is 2.30×, and expertise wins 17 kernels against expertise-off. In short, the expertise-related framework configurations win most completed tasks for every API-called model, while the Opus mode results show that its best exposure 1/256 × 1/16 × 1 × 16 × 256 × not run Single-step: 3.33× reference, 3.05× over no expertise; multi-step: 5.78× reference, 4.71× over no expertise Gemma-4-31B 2.3× 8.2× 3.6× 21.9× 23.2× 23.7× 1.3× 22.9× 3.1× 3.0× 48.3× 49.5× 3.9× 57.2× 1.3× 2.3× 3.6× 1.6× 7.5× 6.7× 3.1× 1.5× 2.5× 1.3× 7.1×7.1× 0.18× 0.20× 12.1× 12.1× 0.51× 4.9× 0.60× 9.7× 2.0× 6.8× 1.4× 1.4× 10.5× 1.3× 3.7× 6.6× 1.0× 1.6× 1.3× 1.9× 9.7× 9.3× 11.2× 35.2× 3.4× 8.9× 12.9× 14.5× 2m3m atax bicg cholesky correlation covariance doitgen durbin fdtd-2d floyd-warshall gemm gemver gesummv gramschmidt heat-3d jacobi-1djacobi-2d lu ludcmp mvt nussinov seidel-2d symm syr2k syrk trisolv trmm HLSFactory kernel (numeric/alphabetic order) 1/256 × 1/16 × 1 × 16 × 256 × not run Single-step: 4.14× reference, 18.77× over no expertise; multi-step: 2.98× reference, 11.39× over no expertise Qwen3.6-27B 114× 1.7× 119× 23.7× 2.1× 2.1× 2.3× 1.3× 8.3× 8.4× 4.4× 4.5× 6.2× 6.2× 2.3× 3.5× 0.95× 0.96× 0.95× 1.0× 10.7× 3.8× 2.2× 2.2× 3.4× 3.6× 0.10× 1.00× 6.5× 2.1× 0.51× 3.5× 0.88× 9.7× 6.6× 18.2× 4.0× 1.0× 0.91× 6.0× 11.7× 1.00× 106× 2.6× 3.0× 0.99× 2.2× 1.5× 66.5× 5.4× 2.5× 6.3× 2.0× 2.1× Upstream HLS reference / selected synthesis cycles Paired bars: solid = single-step, hatched = multi-step; hollow diamond = that mode's no-expertise setup; Doitgen = not run No expertiseMatched expertiseFocused routingBroad routingAll positive expertise Fig. 7. Open-weight expertise sweep. Within each mode, bars show the best qualified speedup over the upstream reference across five policies; diamonds show expertise off. Solid/hatched bars denote flash/multi-step execution. The 27 kernels pass CPU-golden, simulation, synthesis, timing, and resource checks. TABLE VI FIVE-OF-TEN SETUP ROUTING ON 19 GROUP-HELD-OUT DEVELOPMENT KERNELS. COUNTS SHOW INCLUSION OF THE EXHAUSTIVE OPTIMUM OR A WORKFLOW WITHIN 5%. Router Exhaustive optimum Within 5% of optimum Latency ratio geometric mean / 95th percentile Shallow multilayer perceptron15/1916/191.142× / 2.413× Pairwise ranking network11/1913/191.180× / 2.206× Qwen embedding nearest neighbor16/1916/191.081× / 1.642× Extremely randomized trees (pairwise)17/1917/191.056× / 1.362× Prompted Qwen3-0.6B14/1918/191.103× / 1.526× Fine-tuned Qwen3-0.6B8/199/191.887× / 12.703× HLSmith hybrid router (ours) † 17/1918/191.026× / 1.087× depends on workflow depth. These results support explicit, kernel-dependent expertise rather than a universally best setup. In Figure 6, with exhaustive router applied, rows (a–c) present the routed best per-benchmark configuration speedup over the benchmark reference HLS code across all six major agentic setups. Except for a few ties against the expertise-off cases in speedup ratios (e.g., 5 ties out of 26 benchmarks for HLSmith with Claude Sonnet 4.6), our framework can adaptively select the optimal configurations across various tasks, with the obvious improvement in expertise adopted. Even with flash mode implemented only, rows (d–e) DeepSeek and Grok reach 2.58× and 4.47× over the bench- mark baseline on 22 and 21 kernels, respectively. On the 18 common enabled-arm kernels, Grok uses 1.66× fewer cycles. The within-model expertise effect is distinct: it reduces cycles by 2.55× for DeepSeek and 1.87× for Grok. Grok is faster, whereas DeepSeek responds more to expertise. Requiring only both generated arms to pass leaves 23 DeepSeek pairs and 23 Grok pairs; expertise reduces cycles atax bicg covariance gemm gemm-blocked gemm-ncubed gesummv 2m3m symm syr2k syrk matmul mvt 1K 10K 100K 1M 10M Executed RTL cycles (lower is better) failfailfailfailfailfail 1.77× 2.06× 11.9× 2.77K 40.9× 13K 3.35× 2.7× 16.4K 1.71M 210× 26.4K 3.31K 1.55× HLSmithChatHLSChatHLS failure Fig. 8.RTL outcomes for 14 attempts. Labels show ChatHLS/HLSmith speedup on paired passes. Crosses mark 6 ChatHLS failures; blue labels give HLSmith cycles. Outputs are not replayed. by 3.22× and 1.55×, with wins/losses of 18/5 DeepSeek pairs and 18/5 Grok pairs. For five Grok kernels, only the expertise- enabled arm receives an additional attempt; cross-hatching marks these excluded reruns. The CSVs omit generated RTL and output traces, preventing independent value replay. Fig- ure 7 shows that all 540 outputs also pass C simulation, synthesis, timing, and resource gates; 177 retains the translated baseline after unsuccessful edits. For Gemma, it reaches 3.33×/ 5.78× relative to the up- stream HLS reference and 3.05×/ 4.71× relative to the no- expertise arm (flash/multi-step). Qwen3.6-27B [20] reaches 4.14×/ 2.98× and 18.77×/ 11.39×. Expertise-enabled policies supply the minimum on 16/27 and 20/ 27 Gemma cases, and 23/27 and 25/ 27 Qwen cases. These are post-hoc setup ceil- ings; every reference speedup divides the supplied upstream HLS implementation’s cycles by generated-design cycles, not by an expert frontier. We use ChatHLS as the quantitative comparison because it most closely matches HLSmith’s end-to-end scope, in- cluding HLS-C generation, tool-grounded repair, QoR-driven optimization, C/RTL verification, and HLS-specific model Single-step expertise off Single-step all expertise Multi-step expertise off Multi-step all expertise 0.5M 1M 2M 4M Geometric-mean synthesis cycles Gemma-4-31BQwen active-roleQwen Orchestrator Fig. 9.Five-kernel open-model pilot. Bars show geometric-mean HLS synthesis cycles (lower is better) across workflow–expertise settings; color and hatch identify the model. All outputs pass CPU, timing, and resource checks. adaptation (Table I). The comparison between ChatHLS and our HLSmith covers 14 kernels attempted by both systems. Overall, our HLSmith reports 14 RTL co-simulation passes and ChatHLS 8. On 8 common passes, every speedup ratio favors our HLSmith and GM(L ChatHLS /L HLSmith ) = 6.91×. The large benchmark, syr2k, whose speedup ratio is influen- tial: excluding it gives 4.24× on the other The 6 HLSmith-only passes improve recorded solve rate. C. Pruning Workflow Configurations with the Early Router Kernel-dependent winners motivate the outer router with early prediction functionality (Section IV-E), which can retain five of the ten setups per benchmark in Table I and 19 group-held-out development kernels. During the training and evaluation, t sees only source structure and the initial HLS report; Sonnet 4.6 generates candidates. Equation (3) measures quality relative to exhaustive selection, independently of the per-turn Action Router. Table VI shows that four structured choices plus one semantic choice preserve ExtraTrees’ 17/19 exact-optimum coverage, increase within-5% coverage from 17/19 to 18/19, and reduce the 95th-percentile latency ratio from 1.362× to 1.087× while pruning 50.0% of setups. Pairwise fine-tuning improves token classification but worsens synthesized latency. D. Transferring Optimization Behavior to Open Models Local open-model configurations. Figure 9 compares Gemma-4-31B base with two rank-16 Qwen3.6-27B adapters on five kernels. All 60 agentic outputs pass CPU-golden, C simulation, synthesis, timing, and resource gates. With all expertise enabled, Gemma achieves 0.50× /1.02× speedup over the recorded gold reference in Flash/multi-step mode, respectively; the corresponding results are 0.65× /1.38× for active-role fine-tuning and 1.13×/2.24× for Orchestrator fine- tuning; expertise is therefore not uniformly beneficial. The modes use two/five model calls. Direct zero-shot C simulation and synthesis pass 22/27 Gemma-base, 21/27 Qwen-base, and 5/5 adapter kernels. Matched Translator adaptation diagnostic. A four-kernel A/B changes only the Qwen3.6-27B [20] Translator; all other roles, flash execution, expertise-off policy, temperature, seed, candidate count, and Vitis setup remain fixed. Fine-tuning reduces geometric-mean synthesis and RTL-simulation cycles by 1.70× and 1.60×, improving two kernels and tying two; timing passes change from 3/4 to 4/4. The four-pair RTL-ratio TABLE VII MATCHED QWEN3.6-27B TRANSLATOR FINE-TUNING DIAGNOSTIC. GAINS DIVIDE BASE BY FINE-TUNED WORST-CASE CYCLES.† MARKS A BASE TARGET-CLOCK MISS. Kernel HLS-estimate gain Executed RTL gain Fine-tuned selection durbin1.00×1.00×baseline retained floyd-warshall1.00×1.00×baseline retained gemm † 3.61×2.91×generated edit trmm2.34×2.26×generated edit Geometric mean1.70×1.60×— bootstrap interval, [1.00×, 2.56×], includes one. Table VII gives per-kernel results. In short, with proper GRPO configu- ration, small models with as few as 7B parameters can achieve decent optimization within our agentic framework. Common-task 7B comparison. Algorithm 1 adapts Qwen2.5- Coder-7B using the earlier linear, 2×-capped reward (Sec- tion IV-F). SFT and GRPO use different training corpora but share 24 evaluation tasks. RTL-output passes rise from 10 for the base model to 13 after group-relative policy optimization; SFT reaches 8. The reported 2.02× median ratio compares different C-simulation-passing subsets and is neither paired nor a geometric mean. Post-training behavior. Across 26 base/reward-tuned tasks, 7 change from broken to RTL-correct, 4 pass in both cases and improve, and 3 regress. Inspection finds loop fission, outward pipelining, reduction unrolling, and feeding-array partitioning, but no dataflow, double buffering, tiling, or AXI- burst restructuring. On gesummv, cycles fall from the 64,835- cycle reference estimate to 4,987 (13.00×). VI. CONCLUSION HLSmith frames C/C++-to-HLS optimization as hardware- architecture design rather than code generation alone. It distills multi-stage optimization practices from expert HLS imple- mentations into reusable architectural expertise and applies them through compiler-guided single- and multi-step work- flows. Across four commercial teacher models, expertise- enabled configurations produce the best synthesized design for most kernels and achieve up to 252× speedup over the supplied HLS baselines. In executed RTL comparisons, HLSmith completes all 14 kernels, versus 57% for ChatHLS, and delivers a 6.9× geometric-mean speedup over the eight common passes (4.2× on the seven-kernel sensitivity set). The hybrid router evaluates five of ten configurations while retaining a result within 5% of exhaustive selection on 18 of 19 development kernels. Teacher-derived fine-tuning improves geometric-mean synthesis and RTL performance by 1.70× and 1.60×, respectively, with a peak per-kernel synthesis gain of 3.61×. These results demonstrate that explicit architectural expertise, compiler feedback, and targeted model adaptation enable agents to translate plain C/C++ into efficient HLS accelerators. REFERENCES [1] S. Abi-Karam and C. Hao, “HLS-Eval: A benchmark and framework for evaluating LLMs on high-level synthesis design tasks,” in Proceedings of the 2025 IEEE International Conference on LLM- Aided Design (ICLAD), 2025, p. 219–226. [Online]. Available: https://doi.org/10.1109/ICLAD65226.2025.00021 [2] S. Abi-Karam, R. Sarkar, A. Seigler, S. Lowe, Z. Wei, H. Chen, N. Rao, L. John, A. Arora, and C. Hao, “HLSFactory: A framework empowering high-level synthesis datasets for machine learning and beyond,” in Proceedings of the 2024 ACM/IEEE International Symposium on Machine Learning for CAD (MLCAD), 2024, p. 1–9. [Online]. Available: https://doi.org/10.1145/3670474.3685961 [3] A. Bhandwaldar, M. Choudhury, R. Puri, and A. Srivastava, “Agent factories for high level synthesis: How far can general-purpose coding agents go in hardware optimization?” 2026. [Online]. Available: https://arxiv.org/abs/2603.25719 [4] L. Collini, S. Garg, and R. Karri, “C2HLSC: Leveraging large language models to bridge the software-to-hardware design gap,” ACM Trans. Des. Autom. Electron. Syst., vol. 30, no. 6, Oct. 2025. [Online]. Available: https://doi.org/10.1145/3734524 [5] J. Cong, Z. Fang, Y. Hao, P. Wei, C. H. Yu, C. Zhang, and P. Zhou, “Best-effort FPGA programming: A few steps can go a long way,” 2018. [Online]. Available: https://arxiv.org/abs/1807.01340 [6] J. Cong, Z. Fang, M. Lo, H. Wang, J. Xu, and S. Zhang, “Understanding performance differences of FPGAs and GPUs,” in Proceedings of the IEEE International Symposium on Field-Programmable Custom Com- puting Machines, 2018, p. 93–96. [7] J. Cong, B. Liu, S. Neuendorffer, J. Noguera, K. Vissers, and Z. Zhang, “High-level synthesis for FPGAs: From prototyping to deployment,” IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol. 30, no. 4, p. 473–491, 2011. [8] P. Coussy, D. D. Gajski, M. Meredith, and A. Takach, “An introduction to high-level synthesis,” IEEE Design & Test of Computers, vol. 26, no. 4, p. 8–17, 2009. [9] T. Dettmers, A. Pagnoni, A. Holtzman, and L. Zettlemoyer, “QLoRA: Efficient finetuning of quantized LLMs,” arXiv preprint arXiv:2305.14314, 2023. [Online]. Available: https://arxiv.org/abs/2305. 14314 [10] E. D. Dolan and J. J. Mor ́ e, “Benchmarking optimization software with performance profiles,” Mathematical Programming, vol. 91, no. 2, p. 201–213, 2002. [11] B. Efron and R. J. Tibshirani, An Introduction to the Bootstrap.New York, NY: Chapman & Hall/CRC, 1994. [12] J. Gai, H. M. Chen, Z. Wang, H. Zhou, W. Zhao, N. D. Lane, and H. Fan, “Exploring code language models for automated HLS-based hardware generation: Benchmark, infrastructure and analysis,” in Proceedings of the 30th Asia and South Pacific Design Automation Conference (ASP-DAC), 2025, p. 988–994. [Online]. Available: https://doi.org/10.1145/3658617.3697616 [13] R. Li, J. Xiong, X. He, J. Zhao, J. Lv, H. Fang, L. Qi, and X. Wang, “ChatHLS: Towards systematic design automation and optimization for high-level synthesis,” in Proceedings of the 64th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers).San Diego, California, USA: Association for Computational Linguistics, 2026, p. 20 996–21 015. [Online]. Available: https://aclanthology.org/2026.acl-long.962/ [14] S. Li, Z. Zhang, G. Sun, Y. Luo, W. Chen, Y. Wang, M. Hong, and C. Ding, “CUDAHercules: Benchmarking hardware-aware expert- level CUDA optimization for LLMs,” 2026. [Online]. Available: https://arxiv.org/abs/2605.08467 [15] N. Mashnoor, M. Akyash, H. Kamali, and K. Azar, “TimelyHLS: LLM- based timing-aware and architecture-specific FPGA HLS optimization,” in 2025 IEEE International Conference on Omni-layer Intelligent Sys- tems (COINS), 2025, p. 1–6. [16] M. Moraru, K. Kamalakkannan, J. Dominguez-Trujillo, P. Diehl, A. Barai, J. Loiseau, Z. K. Baker, H. Pritchard, and G. M. Shipman, “LAAFD: LLM-based agents for accelerated FPGA design,” 2026. [Online]. Available: https://arxiv.org/abs/2602.06085 [17] L.-N. Pouchet and T. Yuki, “PolyBench/C: The polyhedral benchmark suite,”https://web.cse.ohio-state.edu/ ∼ pouchet.2/software/polybench/, 2012, accessed July 2026. [18] S. Pouget, L.-N. Pouchet, and J. Cong, “A unified framework for automated code transformation and pragma insertion,” in Proceedings of the ACM/SIGDA International Symposium on Field Programmable Gate Arrays, 2025, p. 187–198. [19] N. Prakriya, Z. Ding, Y. Sun, and J. Cong, “LIFT: LLM-based pragma insertion for HLS via GNN supervised fine-tuning,” 2025. [Online]. Available: https://arxiv.org/abs/2504.21187 [20] Qwen Team, “Qwen3.6-27B: Flagship-level coding in a 27B dense model,” April 2026. [Online]. Available: https://qwen.ai/blog?id=qwen3. 6-27b [21] Z. Shao, P. Wang, Q. Zhu, R. Xu, J. Song, X. Bi, H. Zhang, M. Zhang, Y. K. Li, Y. Wu, and D. Guo, “DeepSeekMath: Pushing the limits of mathematical reasoning in open language models,” arXiv preprint arXiv:2402.03300, 2024. [Online]. Available: https://arxiv.org/abs/2402.03300 [22] A. Sohrabizadeh, C. H. Yu, M. Gao, and J. Cong, “Autodse: Enabling software programmers to design efficient fpga accelerators,” ACM Trans. Des. Autom. Electron. Syst., vol. 27, no. 4, Feb. 2022. [Online]. Available: https://doi.org/10.1145/3494534 [23] G. Team, S. E. Abd, V. Aggarwal, R. Algayres, A. Andreev, O. Bachem, I. Ballantyne, C. Brick, V. C ̆ arbune, M. Casbon, M. Chaturvedi, A. Chawla, V. Cotruta, A. Coucke, P. Culliton, R. Dadashi, L. Dixon, M. Elhawaty, U. Evci, C. Farabet, J. Ferret, F. Galgani, S. Girgin, J.-B. Grill, M. Grootendorst, J. Guo, C. Hardin, Y. He, S. M. Hernandez, O. Homburger, L. Hussenot, J. Ji, A. Joulin, A. Kamath, P. Kassraie, O. Lacombe, P. Lahoti, G. Liu, G. Martins, L. Martins, T. Matejovicova, R. Merhej, N. Momchev, S. Mondal, R. Mullins, S. R. Panyam, S. Pathak, S. Perrin, A. S. Pinto, E. Pot, A. Pouget, A. Ram ́ e, S. Ramos, D. Reid, D. Rim, M. Rivi ` ere, K. Roth, L. Rouillard, O. Sanseviero, P. G. Sessa, S. Settle, D. Sinopalnikov, S. Smoot, P. Stanczyk, A. Steiner, L. Stewart, I. Tolstikhin, M. Tschannen, A. Tsitsulin, N. Vieillard, R. Wu, P. Xu, H. Yang, E. Yvinec, B. Zhang, L. Zhang, J. Zou, N. Aagnes, A. Abdelhamed, J. Adamek, S. Agrawal, S. Agrawal, I. Alabdulmohsin, J. B. Alayrac, U. Alon, C. Amarnath, A. Anand, C. Anastasiou, S. Ariafar, F.-X. Aubet, K. Axiotis, F. Barbero, J. Barral, A. Bendebury, U. Bergmann, S. Bileschi, K. Black, M. Blondel, S. Borgeaud, A. Bra ˇ zinskas, R. Burnell, R. Busa-Fekete, M. Cai, D. Calandriello, G. Cameron, C. Caucheteux, R. Chaabouni, G. Chadha, J. Chan, B. J. Chen, J. Chen, L. Chen, X. Chen, D. Cheng, T. hsiang Chien, N. Chinaev, Y. Chou, Z. Chu, B. Coleman, P. Consul, S. Conway-Rahman, S. Crowell, D. Cutler, V. Dani, S. Daruki, A. Das, D. Deutsch, N. Dikkala, L. Ding, Q. Ding, S. Dodhia, K. Donhauser, T. Doshi, A. Dragan, A. Druinsky, S. Dua, Z. Egyed, D. Eisenbud, D. Eppens, C. Fan, B. Fatemi, Y. Fathullah, V. Feinberg, M. Ferev, S. Flennerhag, T. Fujimoto, J. G. Oliveira, I. Galatzer-Levy, J. Gante, S. Geisler, S. Ghosal, A. M. Girgis, T. von Glehn, A. Go, A. Gokhale, A. Grills, Y. Gu, M. Gupta, P. Gupta, G. Guruganesh, R. Hadsell, H. Harkous, J. Harlalka, D. Hassabis, A. Hauth, J. Heyward, A. Hosseini, C.-Y. Hsia, I.-H. Hsu, X. Huang, Y. Huang, K. Hui, A. Hutter, T. I, F. Iliopoulos, A. Jain, G. Jawahar, Z. Ji, Q. Jin, M. Johnson, K. Joshi, A. Kandoor, W.-C. Kang, K. Kavukcuoglu, M. Kazemi, K. Kenealy, A. Khalifa, P. Kirk, I. Korotkov, S. Kothawade, V. Kovalev, N. Kovelamudi, A. Kraft, R. Kumar, V. Kumar, H. Kuppam, J. Lannin, C.-Y. Lee, S. Lee, D. Lepikhin, A. Levkovitch, D. Li, Q. Li, V. Li ́ evin, E. Lin, Z. Lin, C. Liu, T. Liu, T. Liu, X. Liu, I. Lobov, M. Lunayach, M. Ma, G. Madan, A. Maksai, E. Malmi, M. Matuszak, D. McDuff, G. Menghani, M. Mikuła, D. Mirylenka, K. Misiunas, V. Misra, A. Mitran, K. Mohamed, M. Mukha, E. Noland, J. O’Donnell, B. O’Donoghue, K. Olszewska, B. Orlando, W. Pan, R. Panigrahy, U. Parekh, N. Perez-Nieves, C. Park, E. Paskie, L. Peng, B. Petrini, S. Petrov, J. Pfeiffer, B. Piot, M. Plomecka, S. Poder, O. Ponce, A. Pramanik, D. Racz, A. Rajan, M. Ramanovich, A. Rao, M. Ritter, V. Rodrigues, E. Rosen, M. Rybi ́ nski, N. Sachdeva, M. E. Sander, R. Sathyanarayana, S. Savla, S. Schmidgall, T. Schuster, G. Scrivener, B. Seguin, A. Sellergren, A. Severyn, I. Shafran, D. Shah, B. Shahriari, Y. Shangguan, A. Shenoy, P. Shenoy, R. Shivanna, P. Sho, L. Spangher, W. Stokowiec, T. Strother, Y. Su, Y. Sun, M. Sundararajan, A. Tacchetti, M. H. Taege, P. Tafti, J. Tarbouriech, C. Tekur, S. Thakoor, R. Thapa, M. Traverse, L. Treven, T. Tu, C. T. Tung, C ̧ a ̆ glar ̈ Unl ̈ u, P. Veli ˇ ckovi ́ c, M. P. Venkat, S. G. Venkatesh, V. Venkiteswaran, F. Visin, A. Vitvitskyi, K. Vodrahalli, W. Wang, X. Wang, T. Warkentin, J. Wassenberg, J. Wieting, C. Wu, L. Xiao, H. Xu, Y. Xu, F. Xue, A. Yadav, J. Yan, A. Yang, L. Yang, M.-H. Yang, Z. Ying, J. H. Yoo, M. Zadimoghaddam, S. Zafar, F. Zhang, J. Zhang, J. Zhang, X. Zhang, C. Zhao, D. Zhou, and C. Zou, “Gemma 4 technical report,” 2026. [Online]. Available: https://arxiv.org/abs/2607.02770 [24] C. Xiong, C. Liu, H. Li, and X. Li, “HLSPilot: LLM-based high-level synthesis,” 2024. [Online]. Available: https://arxiv.org/abs/2408.06810 [25] A. Xu, B. Lin, B. Xue, B. Wang, B. Xu, B. Wu, B. Zhang, C. Lin, C. Dong, C. Ling et al., “Deepseek-v4: Towards highly efficient million- token context intelligence,” arXiv preprint arXiv:2606.19348, 2026. [26] H. Xu, H. Hu, and S. Huang, “Optimizing High-Level Synthesis Designs with Retrieval-Augmented Large Language Models,” in 2024 IEEE LLM AIDED DESIGN WORKSHOP, LAD 2024, 2024. [27] K. Xu, G. L. Zhang, X. Yin, C. Zhuo, U. Schlichtmann, and B. Li, “HLSRewriter: Efficient refactoring and optimization of C/C++ code with LLMs for high-level synthesis,” ACM Transactions on Design Automation of Electronic Systems, vol. 31, no. 4, 2026. [28] H. Ye, C. Hao, J. Cheng, H. Jeong, J. Huang, S. Neuendorffer, and D. Chen, “ScaleHLS: A new scalable high-level synthesis framework on multi-level intermediate representation,” 2021. [Online]. Available: https://arxiv.org/abs/2107.11673 [29] Q. Zou, F. Yu, H. Tan, Y. Chen, B. He, and W. Wong, “HLS- Seek: QoR-aware code generation for high-level synthesis via proxy comparative reward reinforcement learning,” 2026. [Online]. Available: https://arxiv.org/abs/2605.13536 [30] Y. Zou, Z. Ding, Y. Sun, and J. Cong, “AgRefactor: Self-evolving agentic workflow for HLS compatibility and performance,” 2026. [Online]. Available: https://arxiv.org/abs/2606.30949 APPENDIX A AI USE OpenAI Codex materially assisted this paper by reviewing the implementation and experimental results, identifying con- founds, drafting and revising the dark-gray text, and helping generate tables and figures from recorded measurements. It also assisted with consistency, citation, build, anonymity, and evidence-boundary checks. Codex did not create experimental measurements; results with incomplete controls or correctness evidence remain labeled as preliminary. Hosted models used to generate HLS programs or training examples are identified in the methodology and are treated as experimental subjects. The human authors define the re- search questions, design the system and evaluation, verify the measurements and technical claims, approve the final text and figures, and retain responsibility for the submission. Dark gray marks Codex-authored text during collaborative review and is removed after human approval.