arXiv CS open access

Rule-Guided and Trajectory-Aware Repair for LLM-Based HLS Generation

Xianjing Zhu et al. · arxiv_cs

arXiv CS · Papers

software-architecture software-engineering testing

Large language models (LLMs) offer a promising path for directly generating functionally correct and synthesizable HLS-C from natural-language specifications. However, existing approaches often struggle to turn multi-round tool feedback and reusable HLS knowledge into effective revisions, limiting e

Conceptio Open Archive

Analyze & explore related research in Conceptio

Connect this record directly into your research workflow or AI agent. Explore citations across open repositories, query full text, and export structured proof bundles.

Explore in Search →Connect via MCP / API ↗

Rule-Guided and Trajectory-Aware Repair for LLM-Based HLS Generation Xianjing Zhu1 , Wenqi Lou1,2 , Yuanbo Wen3 , Teng Wang1,2 , Lei Gong1 , Chao Wang1 , Xuehai Zhou1 1 University of Science and Technology of China, Hefei, China 2 Suzhou Institute for Advanced Research, University of Science and Technology of China, Suzhou, China 3 SKL of Processors, Institute of Computing Technology, CAS, Beijing, China

arXiv:2611.07324v1 [cs.AR] 5 Nov 2026

Abstract Large language models (LLMs) offer a promising path for directly generating functionally correct and synthesizable HLS-C from natural-language specifications. However, existing approaches often struggle to turn multi-round tool feedback and reusable HLS knowledge into effective revisions, limiting end-to-end generation success. We propose MementoHLS1 , an agentic HLS generation framework built around executable and falsifiable dual-memoryguided repair. MementoHLS combines an Executable Repair Contract Library (ERCL), which converts cross-task HLS knowledge into evidence-gated repair actions, with a Reviewer-Grounded Falsification Ledger (RFL), which converts task-local repair history into trajectory evidence to suppress ineffective routes and preserve validated progress. To ensure reliable outcome attribution, a Same-Candidate Reviewer binds Parse, Compile, Testbench (TB), and Synthesis (Synth) outcomes to the corresponding candidate, while a Single-Commit Arbiter commits at most one candidate per round. Evaluated on 94 HLS-Eval and 170 Bench4HLS tasks, MementoHLS improves same-candidate TB∧Synth pass@1/pass@5 from 41.7%/57.4% to 58.9%/68.1% on HLS-Eval, and from 15.5%/32.9% to 32.4%/50.6% on Bench4HLS, demonstrating substantial improvements in end-to-end HLS generation reliability.

Introduction

High-Level Synthesis (HLS) translates C/C++ descriptions into RTL, lowering the barrier for accelerator and FPGA design [2, 8, 16]. Recent advances in LLMs further enable AI-assisted HLS automation. As illustrated in Fig. 1, existing LLM-based HLS workflows can be broadly divided into two stages: generating a functionally correct and synthesizable HLS-C implementation, and optimizing valid designs for latency, throughput, or resource efficiency. Methods such as C2HLSC [3] and HLSRewriter [15] focus on C/C++-toHLS transformation and repair, while HLSPilot [13] and related approaches [7, 9] mainly target downstream QoR optimization. These two stages are complementary, as optimization relies on a correct and synthesizable HLS implementation. Early LLM-based HLS generation methods typically start from existing algorithmic C/C++ programs and transform them into HLS-compatible code. With improved LLM reasoning and code generation capabilities [18], recent studies [4, 6, 17, 19] directly generate HLS-C implementations from natural-language specifications. However, obtaining a functionally correct and synthesizable design still requires iterative feedback from Parse, Compile, Testbench (TB), and Synthesis (Synth) stages. Existing approaches improve HLS generation through prompting, retrieval, tool feedback, fine-tuning, or iterative refinement. 1 Code is available at: https://github.com/ZD-zhu/MementoHLS.

C/C++ Implementation

Functionally Correct & Synthesizable HLS-C

QoR-Optimized HLS-C

Input existing algorithmic impl.

</>void kernel1 (...) { for (i=0;..) {… for (Tk=0;Tk<…){ #pragma HLS PIPELINE II=1 c[i][j]+=a[i][k+Tk]*b[k+Tk][j] }}}} </>

Adjust/Insert HLS directives PIPELINE/UNROLL

Prior Works

</> 1. Often sequential loops ... 2. Software data structures ... 3. Dynamic memory / I/O ... </>

• • •

Parse / Compile /TB /Synth ✓

NL to Synth. HLS-C Prior works

Natural-Language Specification User Input:</> 1、“Implement a GEMM HLS kernel ...” 2、“Implement an AES encrypt. HLS kernel...” 3、“Give me a YUV-to-RGB ...” </>

C2HLSC HLSRewriter AgRefactor

Prior Works • • • •

ContractHIL-HLS Gai et al. SAGE-HLS(AST) HLS-Seek MementoHLS (Ours)

Optimize: Latency↓ or Throughput ↑ Or LUT / FF / BRAM / DSP↓

FPGA Accelerator Deployment u Reviwer & Arbiter

• • • • •

Perserve: ✓Parse ✓Compile ✓TB ✓Synth

ChatHLS HLSPilot RALAD LIFT

u Executable Repair Contract Library (ERCL) u Reviewer-Grounded Falsification Ledger (RFL)

Vitis

HLS-C (QoRoptimized)

Vitis / HLS toolchain

FPGA

• C synthesis Bitstream / • RTL generation accelerator • Implementation deployment & place-and-route

Figure 1: Overview of the Two-Stage LLM-Assisted HLS AuERCL 和RFL的描述与论文保持一致，移动到前两个。第三 tomation Workflow. 个写 Reviwer & Arbiter

However, during multi-round generation, simply returning tool logs, retrieved knowledge, and previous interactions to the LLM does not provide sufficient control over how repair knowledge should be applied or how previous repair outcomes should influence subsequent generation. We identify two key limitations in current tool-guided HLS generation: (1) a knowledge-to-action gap, (2) a history-to-evidence gap. First, reusable HLS knowledge does not directly translate into reliable repair actions. HLS-specific knowledge may describe synthesis restrictions, interface requirements, or numerical issues, but its applicability depends on the current candidate, task interface, data types, dimensions, tool feedback, and algorithmic constraints. Such a context-dependent applicability issue has also been observed in retrieval-augmented reasoning for hardware design specifications [12]. A reliable repair mechanism must explicitly encode applicability evidence, prohibited conditions, permissible edits, design invariants, and validation obligations. To address this challenge, we introduce the Executable Repair Contract Library (ERCL), which converts reusable cross-task HLS knowledge into evidence-gated and executable repair contracts. Second, raw interaction history does not provide reliable evidence about whether previous generation attempts have actually improved the design. Across multiple rounds, superficial changes in logs may correspond to the same failure, while apparently different repairs may regress previously satisfied validation stages or revisit ineffective routes. Simply storing previous tool logs or model interactions cannot distinguish genuine progress from repeated failures, regression, or oscillation [10]. Reliable iterative repair requires attributing each observed outcome to the repair route that produced it, normalizing unstable tool feedback, and using this evidence to suppress ineffective actions while preserving validated progress. To address this challenge, we introduce the ReviewerGrounded Falsification Ledger (RFL), which converts task-local generation history into normalized trajectory evidence and uses actual tool outcomes to assign repair credit, suppress ineffective

Xianjing Zhu, Wenqi Lou, Yuanbo Wen, Teng Wang, Lei Gong, Chao Wang, and Xuehai Zhou

routes, preserve validated progress, and trigger recovery under stagnation. We integrate ERCL and RFL into MementoHLS, an agentic framework for reliable LLM-based HLS generation. ERCL determines which reusable repair knowledge is applicable and authorized for the current generation failure, whereas RFL determines how the observed outcomes of previous repair attempts should constrain subsequent generation. For this dual-memory mechanism to operate reliably, however, every tool outcome must be unambiguously attributable to the exact candidate and repair action that produced it. We therefore introduce a Same-Candidate Reviewer to bind Parse, Compile, Testbench, and Synthesis outcomes to a unique candidate, together with a Single-Commit Arbiter that commits at most one candidate per round. These mechanisms provide reliable attribution for ERCL and RFL, forming a closed loop where reusable knowledge guides repair actions and trajectory evidence shapes subsequent generation. In summary, this work makes the following contributions: • We propose MementoHLS, an agentic framework for reliable LLM-based HLS generation that closes the loop among generation, tool feedback, and repair under a fixed LLM, while ensuring reliable outcome attribution through candidate-bound review and single-commit execution. • We introduce the ERCL, which transforms reusable crosstask HLS knowledge into evidence-gated, executable repair contracts with explicit applicability and validation constraints. • We introduce the RFL, which converts task-local multiround repair history into tool-grounded trajectory evidence for repair credit assignment and adaptive trajectory control. • We evaluate MementoHLS on HLS-Eval [1] and Bench4HLS [5], where it consistently achieves state-of-the-art samecandidate TB∧Synth success rates across multiple LLM backbones and model scales.

2 Related Work 2.1 Direct NL-to-HLS Generation Direct NL-to-HLS generation produces complete HLS C/C++ implementations from natural-language specifications without relying on an existing source program. Gai et al. [4] study the effects of fine-tuning, prompting, and feedback on HLS generation, while HLS-Eval [1] establishes compilation, functional verification, and synthesis as key evaluation stages. SAGE-HLS [6] incorporates synthesizable HLS data and serialized abstract syntax trees into structure-aware fine-tuning to improve the synthesizability and functional correctness of generated code. HLS-Seek [19] further exploits functional and QoR signals through post-training with proxy rewards and selective synthesis feedback. These methods improve direct HLS generation through model adaptation or feedback-driven refinement, but lack explicit mechanisms for executable knowledge reuse, trajectory-level repair evidence, and reliable outcome attribution. MementoHLS addresses these gaps at inference time through ERCL, RFL, and candidatebound execution.

2.2

C-to-HLS Transformation and Optimization

A complementary line of work starts from existing C/C++ or HLS implementations and applies LLMs to compatibility transformation and hardware optimization. HLSPilot [13] combines HLS optimization strategies with profiling and design-space exploration, while RALAD [14] retrieves HLS examples and optimization knowledge to guide existing designs. C2HLSC [3] progressively transforms conventional C programs into HLS-compatible implementations using hierarchical decomposition and tool feedback. HLSRewriter [15] further combines repair knowledge, retrieval, refactoring, and directive optimization for synthesis compatibility and hardware efficiency. ChatHLS [7] integrates generation, tool-based debugging, and QoR optimization in a multi-agent workflow. LIFT [9] focuses on structure-aware pragma generation, while AgRefactor [20] combines specialized agents, refactoring tools, and cross-task memory for software-to-HLS transformation and optimization. These approaches assume an existing implementation that provides substantial algorithmic and structural guidance, and mainly target HLS compatibility or QoR optimization. MementoHLS instead starts from a natural-language specification and focuses on reliably obtaining a functionally correct and synthesizable HLS implementation through multi-round generation. The two settings are therefore complementary: a design produced by MementoHLS can serve as the input to subsequent transformation or QoR-oriented optimization.

3 MementoHLS Framework 3.1 MementoHLS Overview This section presents MementoHLS, an evidence-driven repair framework deployed around a fixed LLM. MementoHLS integrates reusable repair knowledge from ERCL and task-local trajectory evidence from RFL to guide iterative HLS candidate repair. We represent an HLS task as 𝑥 = (𝑑, 𝐼, A, 𝛿), where 𝑑 denotes the natural-language design intent, 𝐼 denotes immutable interface artifacts, A denotes validation assets, and 𝛿 specifies the tool configuration. Given a dataset D, the projection 𝜋 D (𝑥) determines the content visible to the model. In contrast, the Reviewer retains the complete task 𝑥, while the reference implementation never enters the model context. A repair trajectory consists of uniquely identified candidates: 𝑐𝑡 = (id𝑡 , 𝑧𝑡 , code𝑡 , parent𝑡 , origin𝑡 )

(1)

where id𝑡 denotes the unique trajectory identifier and 𝑧𝑡 the full generated payload. Upon successful parsing, code𝑡 is the extracted source code; otherwise, code𝑡 = ⊥. parent𝑡 identifies the repair source for credit comparison and origin𝑡 records the generation route. The complete artifact is stored in trajectory history H , while RFL maintains compressed trajectory states. As shown in Fig. 2, given an NL-to-HLS task, MementoHLS first generates an initial candidate using the fixed LLM. In each subsequent round, the Reviewer evaluates the committed candidate through Parse, Compile, TB, and Synth, and identifies the earliest valid failure. Based on candidate-bound evidence, ERCL retrieves applicable repair knowledge, while RFL provides trajectory evidence including previous outcomes, local vetoes, and candidate states. The Diagnoser generates a structured repair hypothesis,

Rule-Guided and Trajectory-Aware Repair for LLM-Based HLS Generation

Initial Candidate Candidate <OUTPUT_CODE filename="top.cpp"> void top_fn(...) { // model-generated HLS C++ } </OUTPUT_CODE> candidate_id

Fixed LLM Generator Generation Rule

1. Immutable prompt only 2. One wrapped C++ candidate 3. Fixed model, seed, and sampling 4. No reference kernel in context 5. Shared Round 0 across modes

MementoHLS Repair

Evidence Retrieval

stage-aware Reviewer 2.C-sim Compile→TB 1 Parse

Eligibility evidence failure stage + tool logs code features + task facts interface invariants

4.TB &Synth JOINT SUCCESS

3.Synth

Deterministic policy

same candidate_id

negative evidence excludes RFL local veto applies ranked top-1 contract or abstain

earliest failed stage + sanitized evidence

Structured Diagnoser Evidence

source code stage log ERCL matches

Dual Memory ERCL ELigibility & decision policy positive / negative / historical evidence priority + confidence -> top-1 or abstain ......

Executable contract schema permissions Uq+ /Uq− + invariants Iq operator((op, Pre, Post) + full review Vq ......

Repair State

Hypothesis

Constraints

root cause action family target objects

permitted edits forbidden edits predicted result

Round state

Control

anchor review failed stage

local vetoes stagnation best archive

RFL Trajectory credit supported / contradicted / unresolved

Immutable HLS Task intent + top signature + I/O header + TB/data + tool setup interface, dimensions, and assets fixed

Repair Routes contract operator Pre_q-> one edit Post_q + invariants

Single-Commit Arbiter Clean-room

Local LLM repair

authorized once no failed-code lineage

evidence + contracts compact RFL state

select exactly one route one candidate c_(t+1) / round

Control & archive local veto + best candidate | stagnation + one clean-room

Figure 2: The framework of MementoHLS. and the Single-Commit Arbiter selects one repair route to produce the next candidate. The new candidate is evaluated by the same tool chain, and the outcome is returned to RFL for trajectory-level credit assignment. In this process, ERCL governs what repair can be attempted, while RFL governs how previous repair outcomes should influence subsequent generation. Candidatebound validation and single-commit execution provide reliable outcome attribution for both mechanisms.

3.2

Candidate-Bound Review and Repair Execution

ERCL and RFL rely on reliable evidence attribution. Therefore, MementoHLS uses candidate-bound review and single-commit execution as the execution substrate for closed-loop repair. For each candidate 𝑐𝑡 , the Reviewer returns a complete review record: R (𝑐𝑡 ) = (v𝑡 , e𝑡 ),

v𝑡 = (𝑃𝑡 , 𝐶𝑡 ,𝑇𝑡 , 𝑆𝑡 )

(2)

where the four states indicate whether the candidate passes Parse (𝑃𝑡 ), Compile (𝐶𝑡 ), TB (𝑇𝑡 ), and Synth (𝑆𝑡 ). The evidence e𝑡 is bound to the same candidate_id and contains tool outcomes and diagnostic information. The Reviewer identifies the first failing stage in the standard HLS kernel development flow, i.e., Parse → Compile → TB → Synth. This ordering defines the repair target and does not terminate tool execution. We define joint success as 𝐽𝑡 = 𝑇𝑡 ∧ 𝑆𝑡 , where 𝑇𝑡 and 𝑆𝑡 indicate TB and Synth success, respectively. For each repair round, the Diagnoser generates a structured hypothesis based on the candidate, failure evidence, ERCL contracts, and RFL state. It produces a root-cause hypothesis, action family, target objects, and permitted or prohibited modifications. The diagnosis is treated only as a repair hypothesis rather than a confirmed cause; repair effectiveness is determined solely by subsequent tool outcomes. The Single-Commit Arbiter selects at most one route among deterministic contract execution, authorized clean-room generation, and local LLM repair. This guarantees that each observed outcome can be uniquely attributed to the repair route that produced the candidate. Together, candidate-bound review and

single-commit execution provide the auditable evidence substrate required by ERCL and RFL.

3.3

Executable Repair Contract Library

ERCL converts reusable cross-task HLS knowledge from passive textual guidance into executable repair contracts. Instead of directly injecting retrieved knowledge into the LLM prompt, ERCL represents repair knowledge with explicit applicability boundaries, execution constraints, and validation obligations. Each contract is represented as: 𝑞 = id𝑞 , 𝜙𝑞 , E𝑞 , U𝑞 , I𝑞 , O𝑞 , V𝑞 , 𝜔𝑞 , 𝜅𝑞

(3)

where 𝜙𝑞 denotes the target failure stage; E𝑞 = (E𝑞+, E𝑞− , E𝑞ℎ ) denotes positive, negative, and historical applicability evidence; U𝑞 = (U𝑞+, U𝑞− ) defines permitted and prohibited modifications; I𝑞 specifies preserved design invariants; O𝑞 = (op𝑞 , Pre𝑞 , Post𝑞 ) describes an optional deterministic operator and its preconditions and postconditions; and V𝑞 denotes the required Reviewer validation obligation. Different from workflow memories that reuse previous procedures from task trajectories [11], ERCL provides explicit repair authority through applicability evidence, modification constraints, invariants, and validation requirements. At runtime, ERCL determines contract eligibility using tool feedback, candidate code, task facts, and trajectory history. It filters contracts with matched negative evidence, conflicting invariants, insufficient support, or RFL local vetoes. Immutable interface constraints, precise diagnostics, and concrete code features take precedence over textual similarity. Therefore, a retrieved match does not itself grant repair authority. Only contracts with sufficient evidence enter the eligible set 𝑄𝑡ret ; otherwise, ERCL returns ⊥ and abstains from contract-driven repair. For an eligible contract, ERCL authorizes only the predefined transformation: Pre𝑞 → op𝑞 → Post𝑞

(4)

Xianjing Zhu, Wenqi Lou, Yuanbo Wen, Teng Wang, Lei Gong, Chao Wang, and Xuehai Zhou

ERCL Contract Example id =SYNTH_REMOVE_HOST_IO

Normalize. For a failed candidate 𝑐𝑡 , the RFL removes unstable fields from tool feedback, including paths, source locations, timestamps, and run names, and constructs the failure signature:

1 Retrieve only when the contract is applicable

Diagnosis: standalone diagnostic formatting/print call in synthesizable source.

𝜎𝑡 = Hash (𝑓 (𝑐𝑡 ), Norm(e𝑡 [𝑓 (𝑐𝑡 )]))

ℰ+ � trigger code contains printf|fprintf|sprintf

ℰℎ� support this rule/operator is not task-locally vetoed

Qtret : ordered rules + provenance;

⊥ if empty (match≠ authority)

2 Authorize and execute the predefined transformation �+ �

allow

Iq invariant

Oq = (Opq, Preq, Postq)

�− � forbid

interface / type / shape / algorithm constraints remain valid

Preq runtime authorization

• standalone printf or fprintf(stdout/stderr) • return/formatted output does not affect algorithmic state

Postq runtime check

• only diagnostic output is removed • sprintf-like memory writes remain • file/data/system calls are untouched • code changed; invariants hold

Failed checks / exception / invariant violation / no change ⇒ Abstain

3 Discharge Vq on the same changed candidate

Vq discharged: the complete Reviewer passed on the locked candidate

Figure 3: An example executable repair contract in ERCL. The Executor verifies Pre𝑞 , applies op𝑞 , and checks Post𝑞 . Any failed precondition, execution exception, invariant violation, or no-change result causes the contract to abstain, preventing unconstrained LLM modifications. After execution, the modified candidate must satisfy the complete validation obligation: V𝑞 = Parse + Compile + TB + Synth

(5)

The validation result is obtained through the same CandidateBound Reviewer, ensuring that contract effectiveness is determined by actual tool outcomes. Therefore, ERCL follows the procedure: retrieve → authorize → execute → validate Fig. 3 illustrates this contract semantics using the synthesis-stage contract SYNTH_REMOVE_HOST_IO, showing how ERCL combines applicability evidence, execution constraints, and validation obligations to enable safe and auditable repair.

3.4

Reviewer-Grounded Falsification Ledger and Closed-Loop Control

The Reviewer-Grounded Falsification Ledger (RFL) is a task-local trajectory memory that converts multi-round repair history into normalized evidence for guiding subsequent HLS generation and repair. Unlike raw tool logs or interaction histories, RFL evaluates repair routes according to actual Reviewer outcomes, assigns credit to executed actions, and constrains future repair decisions. The RFL is isolated by (task, sample, seed, mode) and does not update the global ERCL. Here, falsification refers to locally testing whether a repair hypothesis is supported by actual tool outcomes. The RFL maintains repair trajectories through four stages: normalize, evaluate, constrain, and recover.

(6)

where e𝑡 [𝑓 (𝑐𝑡 )] denotes the evidence of the earliest failed stage. The RFL further constructs an action fingerprint from the normalized action family, contract/operator identifier, and target object to identify repeated failures and ineffective repair routes. Evaluate. The RFL compares the repaired candidate with its actual parent candidate and assigns credit to the actual submitted repair route, rather than the natural-language diagnosis. A route is labeled supported if it improves the validation frontier without regression or invariant violation, and contradicted if it preserves the same failure, degrades previous progress, or violates constraints; otherwise, it remains unresolved. Constrain. When a repair contract, action family, or route is falsified with an identifiable target, the RFL records it into a trajectorylocal negative ledger indexed by failure stage and failure signature. These local vetoes constrain subsequent ERCL retrieval and LLM repair decisions, while the global ERCL remains unchanged. The effective repair space is therefore jointly determined by cross-task knowledge and trajectory evidence: A𝑡 = Eligible𝐸𝑅𝐶𝐿 (𝑐𝑡 , e𝑡 ) − Veto𝑅𝐹 𝐿 (H𝑡 )

(7)

Recover. The RFL detects stagnation from repeated failure signatures, repeated repair routes, A–B–A oscillation, conflicting diagnoses, or missing progress. When stagnation occurs, RFL supports candidate recovery or controlled clean-room generation. The recovered candidate follows the same single-commit and Reviewer validation process, and its outcome is incorporated into the trajectory evidence. Together, ERCL and RFL form a closed-loop repair process: ERCL provides reusable repair opportunities according to current candidate evidence, while RFL continuously updates their trajectorylocal validity based on actual execution outcomes. Thus, subsequent repair decisions are jointly constrained by cross-task repair knowledge and task-local trajectory evidence.

Experiments

In this section, we evaluate MementoHLS from three perspectives: overall effectiveness against representative NL-to-HLS methods, individual and combined contributions of ERCL and RFL, and the benefits-cost trade-off of multi-round repair. Specifically, we investigate the following research questions: RQ1: Is MementoHLS consistently effective across model families, parameter scales, and domain-adaptation states, and how does it compare with existing direct NL-to-HLS methods? RQ2: What contributions do ERCL and RFL make to MementoHLS individually, and how do they perform when used together? RQ3: How much cumulative and marginal benefit can multi-round repair provide, and what are the corresponding costs in terms of repair rounds, LLM calls, and HLS tool executions?

4.1

Implementation and Settings

MementoHLS is implemented in Python and deployed through vLLM on an Ubuntu 22.04 server equipped with an NVIDIA A100

Rule-Guided and Trajectory-Aware Repair for LLM-Based HLS Generation

Table 1: Comparison of HLS code generation performance on HLS-Eval, reporting pass@1 (p@1) and pass@5 (p@5) success rates (%) across parsing, compilation, testbench (TB), synthesis, and joint TB&Synth evaluation. HLS-Eval [1] (%) Type

Model

Size

Parse

Compile

Synth

TB&Synth

p@1

p@5

p@1

p@5

p@1

p@5

p@1

p@5

p@1

p@5

Base Model

Llama-3

99.8

100.0

64.3

80.9

45.3

59.6

59.1

76.6

41.7

57.4

Code Models

Qwen2.5-Coder Qwen2.5-Coder

32B 7B

99.1 99.1

100.0 100.0

88.6 78.7

94.3 89.4

59.1 55.5

65.9 67.0

82.3 74.9

93.2 88.3

56.4 53.8

64.8 65.9

SAGE-HLS [6]

Llama-3 + FT† Qwen2.5-Coder + FT†

8B 7B

95.3 100.0

100.0 100.0

60.6 75.1

80.9 94.7

46.6 53.6

61.7 69.1

53.4 67.2

79.8 93.6

40.9 46.8

59.6 67.0

ContractHIL-HLS [17]

DeepSeek V3

671B

96.8

87.4

70.4

76.6

94.7

Gai et al. [4]

CodeLlama

6.3

48.8

1.4

27.9

HLS-Seek [19]

HLS-Seek (SFT) HLS-Seek (GRPO)

7B 7B

77.5 84.7

88.4 95.3

50.7 68.9

60.5 81.4

MementoHLS

Qwen2.5-Coder Qwen2.5-Coder + FT† Qwen2.5-Coder Llama-3 Llama-3 + FT†

7B 7B 32B 8B 8B

100.0 100.0 100.0 100.0 100.0

90.4 92.5 96.8 81.5 77.4

94.6 97.8 98.9 91.5 94.6

66.6 67.4 77.2 59.4 55.5

74.4 79.7 81.9 69.1 68.0

89.7 86.8 94.4 80.2 70.4

96.8 97.9 98.9 92.6 95.7

65.7 63.1 75.5 58.9 50.6

74.4 78.7 81.9 68.1 65.9

† FT denotes LoRA fine-tuning on the training corpus released by SAGE-HLS [6]. “–” denotes unreported settings, which we do not reproduce because the implementation is not publicly available.

Table 2: Comparison of HLS code generation capabilities on Bench4HLS. Bench4HLS [5] (%) Type

Model

Size

Synth

TB&Synth

p@1 p@5 p@1 p@5 p@1 p@5 Foundational Models

Llama-3

15.8

32.9

58.9

95.3

15.5

32.9

Code Models

Qwen2.5-Coder Qwen2.5-Coder

32B 7B

49.8 26.7

60.0 51.1

85.9 52.1

97.6 91.8

48.6 26.4

59.4 50.6

SAGE-HLS [6]

Llama-3 + FT† Qwen2.5-Coder + FT†

8B 7B

28.9 32.2

42.9 51.1

80.4 80.3

96.5 98.8

28.9 31.4

42.3 48.8

Qwen2.5-Coder 7B 43.6 Qwen2.5-Coder + FT† 7B 45.1 MementoHLS Qwen2.5-Coder 32B 61.7 Llama-3 8B 32.5 Llama-3 + FT† 8B 35.6

58.2 54.7 68.2 50.6 49.4

86.1 97.2 96.9 79.2 93.7

98.2 98.8 98.8 98.2 98.8

42.3 44.1 61.0 32.4 35.2

57.0 52.9 66.4 50.6 48.8

4.2

4.3 80 GB GPU. The maximum context length is set to 8192 and the sampling temperature for generation and repair is 0.7. For each task, we use five independent random seeds to generate five trajectories, with iterative repair limited to five rounds and early stopping when the same candidate passes both TB and Synth. The primary ERCL bank contains 71 contract entries, comprising 6 Parse, 23 Compile, 27 TB, and 15 Synth-stage entries. The ERCL was frozen before any experiments on HLS-Eval and Bench4HLS, and no benchmark failure cases, reference implementations, or evaluation outcomes were used during contract construction or refinement. HLS validation is performed using Vitis HLS 2024.2 and the Vivado flow on the Xilinx xczu9eg-ffvb1156-2-e device with a 5 ns clock constraint.

Benchmarks and Metrics

We select HLS-Eval [1] and Bench4HLS [5] as the primary evaluation benchmarks. HLS-Eval contains 94 manually verified HLS designs spanning diverse workloads and application domains, enabling evaluation of generation reliability across various HLS tasks. In contrast, Bench4HLS provides 170 manually curated and validated designs with greater emphasis on larger and structurally complex workloads, together with compilation, functional simulation, and synthesis evaluation. Therefore, HLS-Eval emphasizes workload diversity and coverage, while Bench4HLS provides complementary evaluation on design complexity and engineering-oriented validation. Together, these benchmarks enable a comprehensive assessment of MementoHLS across different task scales and complexity regimes. Following prior work, we adopt Pass@1 and Pass@5 as the primary metrics. Pass@1 evaluates the success rate of a single trajectory, while Pass@5 measures whether at least one of five independent trajectories satisfies the target condition.

Comparison with Baselines

To answer RQ1, we evaluate MementoHLS across different model families, parameter scales, domain-adapted backbones, and representative NL-to-HLS methods. We consider Llama-3-8B, Qwen2.5Coder-7B, Qwen2.5-Coder-32B, and LoRA-adapted variants based on the HLS-specific training corpus released by SAGE-HLS. As shown in Table 1 and Table 2, MementoHLS consistently improves same-candidate TB∧Synth pass@1 and pass@5 across both benchmarks and all evaluated backbones, with gains of up to 19.1 and 17.7 percentage points, respectively. These improvements persist from 7/8B models to the stronger 32B backbone, indicating that MementoHLS improves end-to-end generation reliability rather than merely compensating for limited model capability.

Xianjing Zhu, Wenqi Lou, Yuanbo Wen, Teng Wang, Lei Gong, Chao Wang, and Xuehai Zhou

Cumulative success (%)

Zero-shot a

RFL

ERCL 52

Zero-shot

MementoHLS

Feedback

Bench4HLS Repair rounds

Bench4HLS — TB&Synth p@5

RFL

Bench4HLS Logical LLM calls

ERCL

MementoHLS

Bench4HLS Total tokens

Bench4HLS Vitis tool time

Zero-shot

Feedback

RFL ERCL

MementoHLS

20 36

Rounds / trajectory 15 1

60 c

HLS-Eval — TB&Synth p@1

HLS-Eval Repair rounds

HLS-Eval — TB&Synth p@5

k tokens / trajectory

100

200

Seconds / trajectory

HLS-Eval Logical LLM calls

HLS-Eval Total tokens

HLS-Eval Vitis tool time

Zero-shot

Feedback

RFL

ERCL

MementoHLS

45 40

Calls / trajectory

32 0

Cumulative success (%)

Feedback

Bench4HLS — TB&Synth p@1

Rounds / trajectory 0

Repair round

0.0

2.5

5.0

7.5

10.0

Calls / trajectory

k tokens / trajectory

100

150

200

Seconds / trajectory

Figure 5: Per-trajectory cost of MementoHLS repair strategies.

Figure 4: Round-cumulative TB∧Synth success. The results on domain-adapted backbones further demonstrate the complementarity between MementoHLS and offline HLS adaptation. While LoRA fine-tuning injects HLS-specific knowledge into model parameters, MementoHLS leverages candidate-level Parse, Compile, TB, and Synth feedback to perform inference-time repair. Furthermore, comparisons with representative NL-to-HLS methods, including Gai et al., ContractHIL-HLS, and HLS-Seek, show that MementoHLS improves same-candidate TB∧Synth success under unified evaluation, demonstrating enhanced end-to-end reliability across the complete HLS generation and validation pipeline.

4.4

Impact of Different Components

To isolate the contribution of each component, we fix Llama-3-8B as the backbone for all RQ2 experiments. All configurations share the same Round-0 candidates and repair budget. We compare four iterative settings: Feedback without memory, RFL only, ERCL only, and the complete MementoHLS with both components enabled. These configurations form a 2 × 2 factorial design over ERCL and RFL, while Zero-shot serves only as the backbone reference. As shown in Table 3, ERCL and RFL improve different aspects of the repair process. RFL primarily stabilizes repair trajectories by preserving validated progress and suppressing ineffective or regressive repair routes. In contrast, ERCL more directly improves end-to-end correctness by applying evidence-gated executable repair knowledge to the current failure. Each component provides consistent benefits independently, while their combination achieves the strongest TB∧Synth performance on both benchmarks. These results demonstrate that ERCL and RFL play complementary roles in MementoHLS. ERCL determines which reusable repair knowledge is applicable to the current failure, whereas RFL evaluates previous repair outcomes based on actual tool feedback and constrains subsequent repair decisions. By jointly leveraging cross-task repair knowledge and task-local trajectory evidence, MementoHLS achieves more reliable multi-round HLS repair.

4.5

Benefits and Costs of Multi-Round Repair

Round-wise Repair Gains. Fig. 4 show that most gains are obtained in the early repair rounds. On Bench4HLS, the first three rounds

account for 74.1% and 83.3% of the final pass@1 and pass@5 improvements, respectively; the corresponding ratios on HLS-Eval are 74.1% and 70.0%. Although the marginal gains gradually decrease, they remain positive through Round 5, which still contributes 1.8/0.6 percentage points on Bench4HLS and 1.5/2.1 points on HLS-Eval. Moreover, the complete MementoHLS continues to make progress in later rounds, whereas the single-component variants tend to plateau earlier. These results indicate that most failures can be repaired within the first few rounds, while the complete system retains the ability to recover additional difficult cases in later rounds. Repair Efficiency. Figure 5 further shows that these gains do not result from simply increasing the number of retry opportunities. Under the same five-round repair budget, MementoHLS requires an average of only 3.84 repair rounds and 8.62 logical LLM calls per trajectory on Bench4HLS, and 2.48 rounds and 5.89 calls on HLS-Eval, the lowest averages among all iterative configurations. Despite using fewer repair attempts, MementoHLS improves TB∧Synth correctness by 10.7–17.7 percentage points over Zero-shot. These results indicate that its advantage primarily stems from more effective repair decisions rather than brute-force resampling. Latency Preservation. The correctness gains of MementoHLS are achieved without introducing a systematic latency penalty. As shown in Table 4, the fraction of generated designs that are not slower than the benchmark reference increases from 66.56% to 75.68% on HLS-Eval and from 86.99% to 87.18% on Bench4HLS. Therefore, MementoHLS improves end-to-end correctness while preserving the latency characteristics of the generated designs, maintaining their suitability as starting points for subsequent latency, resource, and PPA optimization.

Conclusion and Future Work

We introduced MementoHLS, an inference-time repair framework for reliable LLM-driven HLS generation. MementoHLS establishes an evidence-driven closed loop around a fixed LLM, where ERCL transforms reusable HLS knowledge into executable repair contracts and RFL converts multi-round repair history into trajectorylevel evidence for guiding subsequent decisions. With a fixed model and a maximum of five repair rounds, MementoHLS improves TB∧Synth pass@1/pass@5 by 17.2/10.7 percentage points on HLSEval and by 16.9/17.7 percentage points on Bench4HLS, while

Rule-Guided and Trajectory-Aware Repair for LLM-Based HLS Generation

Table 3: Component ablation of MementoHLS with the Llama-3-8B backbone on HLS-Eval and Bench4HLS. HLS-Eval [1] (%) Variant

Parse

Compile

Bench4HLS [5] (%) Synth

TB∧Synth

Parse

Compile

Synth

TB∧Synth

p@1 p@5 p@1 p@5 p@1 p@5 p@1 p@5 p@1 p@5 p@1 p@5 p@1 p@5 p@1 p@5 p@1 p@5 p@1 p@5 Zero-shot∗ Feedback RFL ERCL MementoHLS

99.8 100.0 100.0 100.0 100.0 100.0 100.0 100.0 100.0 100.0

64.3 72.1 78.5 78.3 81.5

80.9 86.2 90.4 92.6 91.5

45.3 54.9 55.7 55.7 59.4

59.6 63.8 67.0 68.1 69.1

59.1 69.1 76.0 77.2 80.2

76.6 85.1 90.4 92.6 92.6

41.7 53.6 54.5 55.7 58.9

57.4 63.8 67.0 68.1 68.1

99.9 100.0 100.0 100.0 100.0 100.0 100.0 100.0 100.0 100.0

58.4 95.3 15.8 60.0 95.3 21.4 66.1 95.9 21.8 73.3 100.0 26.8 79.8 99.4 32.5

32.9 40.0 40.6 46.5 50.6

58.9 60.6 66.8 73.5 79.2

95.3 95.9 96.5 98.8 98.2

15.5 21.4 21.5 26.7 32.4

32.9 40.0 40.6 46.5 50.6

∗ Zero-shot denotes direct Round-0 generation without iterative feedback or repair.

Table 4: Latency preservation of Llama-3-8B relative to the optimized benchmark references. All values are percentages. Not∗ Slower ↑

Faster ↑

Slower ↓

Avg. Red. ↑

Avg. Inc. ↓

HLS-Eval [1] Zero-shot MementoHLS

66.56 75.68

46.98 47.30

33.44 24.32

68.26 75.02

1.01e3 7.23e2

Bench4HLS [5] Zero-shot MementoHLS

86.99 87.18

2.08 3.21

13.01 12.82

91.44 94.87

2.49e8 4.50e3

Setting

* Not Slower denotes designs with latency less than or equal to the reference. Avg. Red./Inc. denotes the average latency reduction/increase among designs faster/slower than the reference, respectively.

achieving complementary benefits from ERCL and RFL. Future work will explore additional HLS toolchains, unseen algorithm families, and stronger correctness and QoR-aware repair under controlled resource budgets.

References [1] Stefan Abi-Karam and Cong Hao. 2025. HLS-Eval: A Benchmark and Framework for Evaluating LLMs on High-Level Synthesis Design Tasks. In Proc. ICLAD. 219–226. [2] Hongzheng Chen, Niansong Zhang, Shaojie Xiang, et al. 2024. Allo: A Programming Model for Composable Accelerator Design. Proc. ACM Program. Lang. 8, PLDI (2024), 593–620. [3] Luca Collini, Siddharth Garg, and Ramesh Karri. 2025. C2HLSC: Leveraging Large Language Models to Bridge the Software-to-Hardware Design Gap. ACM Trans. Des. Autom. Electron. Syst. 30, 6 (2025), 96:1–96:24. [4] Jiahao Gai, Hao Chen, Zhican Wang, et al. 2025. Exploring Code Language Models for Automated HLS-Based Hardware Generation: Benchmark, Infrastructure and Analysis. In Proc. ASP-DAC. 988–994. [5] M. Zafir Sadik Khan, Kimia Zamiri Azar, and Hadi Kamali. 2026. Bench4HLS: End-to-End Evaluation of LLMs in High-Level Synthesis Code Generation. In Proc. DATE. 1–7. [6] M. Zafir Sadik Khan, Nowfel Mashnoor, Mohammad Akyash, et al. 2025. SAGEHLS: Syntax-Aware AST-Guided LLM for High-Level Synthesis Code Generation. In Proc. ICCD. 574–581. [7] Runkai Li, Jia Xiong, Xiuyuan He, et al. 2026. ChatHLS: Towards Systematic Design Automation and Optimization for High-Level Synthesis. In Proc. ACL. 20996–21015. [8] Wenqi Lou, Lei Gong, Chao Wang, et al. 2021. OctCNN: A high throughput FPGA accelerator for CNNs using octave convolution algorithm. IEEE Trans. Comput. 71, 8 (2021), 1847–1859. [9] Neha Prakriya, Zijian Ding, Yizhou Sun, et al. 2025. LIFT: LLM-Based Pragma Insertion for HLS via GNN Supervised Fine-Tuning. arXiv:2504.21187 (2025). [10] Noah Shinn, Federico Cassano, Ashwin Gopinath, et al. 2023. Reflexion: Language Agents with Verbal Reinforcement Learning. In Proc. NeurIPS, Vol. 36. 8634–8652. [11] Zora Zhiruo Wang, Jiayuan Mao, Daniel Fried, et al. 2025. Agent Workflow Memory. In Proc. ICML, Vol. 267. 63897–63911. [12] Changwen Xing, SamZaak Wong, Xinlai Wan, et al. 2026. ChipMind: RetrievalAugmented Reasoning for Long-Context Circuit Design Specifications. In Proc. AAAI, Vol. 40. 1337–1345.

[13] Chenwei Xiong, Cheng Liu, Huawei Li, et al. 2024. HLSPilot: LLM-Based HighLevel Synthesis. In Proc. ICCAD. 1–9. [14] Haocheng Xu, Haotian Hu, and Sitao Huang. 2024. Optimizing High-Level Synthesis Designs with Retrieval-Augmented Large Language Models. In Proc. LAD. 1–5. [15] Kangwei Xu, Grace Li Zhang, Xunzhao Yin, et al. 2026. HLSRewriter: Efficient Refactoring and Optimization of C/C++ Code with LLMs for High-Level Synthesis. ACM Trans. Des. Autom. Electron. Syst. 31, 4 (2026), 61:1–61:21. [16] Hanchen Ye, Hyegang Jun, and Deming Chen. 2024. HIDA: A Hierarchical Dataflow Compiler for High-Level Synthesis. In Proc. ASPLOS. 215–230. [17] Jingbo Zhang, Haoxiang Sun, Wenbo Wang, et al. 2026. ContractHIL-HLS: Contract-Aligned Multi-Agent Workflow with Hardware-in-the-Loop Feedback for HLS Design. arXiv:2607.25283 (2026). [18] Qirui Zhou, Yuanbo Wen, Ruizhi Chen, et al. 2025. Qimeng-gemm: Automatically generating high-performance matrix multiplication code by exploiting large language models. In Proc. AAAI, Vol. 39. 22982–22990. [19] Qingyun Zou, Feng Yu, Hongshi Tan, et al. 2026. HLS-Seek: QoR-Aware Code Generation for High-Level Synthesis via Proxy Comparative Reward Reinforcement Learning. arXiv:2605.13536 (2026). [20] Yang Zou, Zijian Ding, Yizhou Sun, et al. 2026. AgRefactor: Self-Evolving Agentic Workflow for HLS Compatibility and Performance. arXiv:2606.30949 (2026).

Xianjing Zhu, Wenqi Lou, Yuanbo Wen, Teng Wang, Lei Gong, Chao Wang, and Xuehai Zhou

Quality of Results on Nontrivial Kernels

Selected Llama-3-8B case studies show resource savings on a 1024term fixed-point dot product and a 1024-bit, 256-way selector. A multi-cycle image stencil shows lower latency with a small LUT trade-off. M denotes MementoHLS; FT denotes the existing LoRA model. Measurement scope. All reports use Vitis HLS 2024.2, xczu9egffvb1156-2-e, and a 5 ns target clock. Reference is the benchmark kernel, not the testbench driver, and is synthesized once. Cycles are top-level worst-case HLS estimates; 𝑇est is the estimated clock period in ns, not end-to-end time. Resource counts and latency always refer to the same implementation. Table A.1: HLS-Eval: lower resource use for a 1024-term arithmetic reduction without increased cycle latency. LUT

DSP

𝑇est (ns)

1024-term fixed-point dot product Reference 37 1,809 Base 1,028 299 Base + M 1,028 156 FT 516 2,468 FT + M 516 2,468

2,675 175 145 807 807

64 2 2 4 4

3.420 3.420 3.420 3.613 3.613

Method

Cycles

All numeric rows pass TB and synthesis. Reference is deterministic. 𝑇est is in ns. LUT, FF and DSP are absolute counts; BRAM and URAM are zero. Bold identifies M configurations, not statistical significance.

Table A.2: Bench4HLS: a multi-cycle image stencil with lower latency and a small LUT trade-off. LUT

DSP

𝑇est (ns)

5×5 image-window sum (Prob156) Reference 77 5,545 Base 939 2,484 Base + M 872 2,575 FT 304 3,643 FT + M 304 3,643

5,298 689 603 3,053 3,053

0 0 0 0 0

3.529 3.633 3.242 3.607 3.607

Method

All rows pass TB and synthesis. 𝑇est is in ns. BRAM and URAM are zero. The Base-path LUT increase is 91 (3.7%); this is not an all-metric non-regression example.

Multi-cycle image stencil. The Prob156 kernel computes all 64 output pixels of an 8×8 image, each with a bounded 5×5 neighborhood and zero-padding boundary semantics. Base + M reduces cycle latency from 939 to 872 (7.1%) and FF from 689 to 603 (12.5%); 𝑇est decreases from 3.633 to 3.242 ns. LUT increases from 2,484 to 2,575: 91 LUT, or 3.7%. This is explicitly a latency improvement with a small LUT trade-off, not an all-metric non-regression example. The FT path is unchanged at 304 cycles. The selected Base + M implementation is from Round 2. Table A.3: Bench4HLS: resource savings in a wide selection datapath. Method

Arithmetic reduction. The dot product retains all 1024 products and their accumulation, using the benchmark’s 32-bit fixed-point parameter/result type and 16-bit fixed-point feature type. Base + M uses 156 rather than 299 LUT (47.8% fewer) and 145 rather than 175 FF (17.1% fewer), while retaining 1,028 cycles, two DSP blocks, and a 3.420 ns estimated clock period. Its selected candidate is from repair Round 3. The FT path remains unchanged at 516 cycles and four DSP blocks. Thus, the benefit on this case is a smaller Base-path footprint, not fewer execution cycles. The reference uses explicit 32-way array partitioning/parallelism and 64 DSP blocks; these different architectures must not be interpreted as evidence that M is faster than the reference.

Cycles

LUT

1024-bit, 256-to-1 four-bit selector (Prob021) Reference 0 273 Base – – Base + M 0 2,171 FT 0 2,171 FT + M 0 273

DSP

𝑇est (ns)

0 – 0 0 0

1.362 – 1.887 1.887 1.362

All numeric rows pass TB and synthesis. 𝑇est is in ns. A dash denotes no eligible candidate, not zero. No Base-path PPA comparison is claimed. BRAM and URAM are zero. Zero cycles do not mean zero physical delay.

Wide-datapath selection. Prob021 selects one of 256 four-bit fields from a 1024-bit input. FT + M reduces LUT from 2,171 to 273 (87.4%) and 𝑇est from 1.887 to 1.362 ns (27.8%), matching the reference resource and clock estimates. FF and DSP remain zero, and the reported cycle latency stays zero. The selected FT implementation uses a wide shift followed by masking; FT + M, selected at Round 1, uses a variable four-bit slice. Both preserve the selectorto-bit-field relation. The result is a wide combinational datapath area/timing benefit, not multi-cycle acceleration. Interface pragmas can differ, so the counts describe complete HLS implementations rather than an isolated fixed-interface datapath rewrite. Interpretation. The positive evidence is confined to these bestobserved implementations: resource savings with preserved cycle latency, plus the explicitly qualified latency–LUT trade-off for the image stencil.

Rule-Guided and Trajectory-Aware Repair for LLM-Based HLS Generation

Additional Multi-Round Repair Results

Figure B.1 provides a per-round view of the existing repair-budget evaluation. For each 𝑘 ∈ {1, 5}, the marginal gain at round 𝑡 is the cumulative TB&Synth pass@𝑘 at 𝑡 minus that at 𝑡 − 1, expressed in percentage points. The five methods use the same evaluation setting as the main-text repair-budget experiment. Zero-shot has no repair-stage gain. This view complements the main-text cumulative and cost plots; it introduces neither an additional experiment nor a new candidate-selection policy.

Marginal gain (pp)

Zero-shot 6 a

Feedback

RFL

Bench4HLS — TB&Synth p@1

MementoHLS

Bench4HLS — TB&Synth p@5 8.2

5.9 4.2

4 2.6

2.4

3.6 2.9

1.8

2.4

2 0.6

0 1

Marginal gain (pp)

ERCL

6 c 4.7

HLS-Eval — TB&Synth p@1

HLS-Eval — TB&Synth p@5

4.3

5.7

3.2

2.9 2.4

2.1

1.5

2 1.1 0.0

0 1

Repair round

Figure B.1: Per-round marginal TB&Synth gains on Bench4HLS and HLS-Eval. Each panel reports changes in pass@1 or pass@5 over rounds 1–5. Values are percentage-point increments, not relative percentage improvements.

Rule-Guided and Trajectory-Aware Repair for LLM-Based HLS Generation

Analyze & explore related research in Conceptio

Related documents