HLStrans Dataset Overview

• HLStrans is a dataset that provides paired naïve C/C++ sources and optimized, synthesizable HLS C/C++ implementations with integrated testbenches and synthesis reports.
• It encompasses 137 diverse applications and over 23,000 design variants generated through Monte Carlo tree search and genetic algorithms, covering five transformation categories.
• Benchmarking with LLMs shows improved synthesis success and acceleration, making HLStrans a key resource for hardware-aware code generation and LLM fine-tuning.

HLStrans is a dataset for LLM-driven C-to-HLS hardware code synthesis that targets the conversion of naive or non-synthesizable C/C++ into synthesizable, optimized HLS C/C++ suitable for FPGA-oriented flows (Zou et al., 6 Jul 2025). It was introduced to address a gap in open resources for end-to-end HLS generation: synthesizable HLS differs substantially from general-purpose C/C++ because it disallows dynamic allocation and recursion, expects static bounds and fixed data sizes, and depends on directive insertion and specialized libraries such as ap_int, ap_fixed, and hls::stream to expose parallelism and map algorithm structure to hardware (Zou et al., 6 Jul 2025). HLStrans combines paired code exemplars, self-contained testbenches, synthesis-derived labels, transformation metadata, and a benchmark spanning repair, pragma insertion, and optimization, with 137 distinct applications and over 23,000 labeled design variants (Zou et al., 6 Jul 2025).

1. Definition and scope

HLStrans is organized around paired C-to-HLS exemplars. Each example starts from an original C/C++ source $x$, described as a naive or non-synthesizable implementation of a target kernel, and provides an HLS-optimized source $y$, described as a synthesizable HLS C/C++ implementation featuring a top function, any needed sub-functions or types, inserted directives, and an HLS-friendly coding style (Zou et al., 6 Jul 2025). Each entry also includes a self-contained C++ testbench $tb$, Vitis HLS synthesis reports, synthesis and compilation success or failure signals, warnings, and transformation metadata, including proven transformation sequences and explanatory reasoning integrated alongside optimized outputs (Zou et al., 6 Jul 2025).

The dataset’s stated purpose is not merely QoR prediction. Prior corpora cited in the paper—HLSdataset, HLSsyn, MLSBench, Spector, and Dai et al.—are characterized as focusing on QoR estimation or including only log files, with limited program sources, fewer transformations, and no paired C-to-HLS samples with testbenches (Zou et al., 6 Jul 2025). HLStrans instead targets end-to-end generation and evaluation of functionally correct, synthesizable, and optimized HLS code.

This design makes the dataset relevant to several adjacent research problems: supervised program transformation, retrieval-augmented code generation, optimization-conditioned fine-tuning, and hardware-aware design-space exploration. A plausible implication is that HLStrans is intended not only as a benchmark but also as a training substrate for models that must jointly reason about functional semantics, synthesizability constraints, and hardware cost trade-offs.

2. Corpus composition and data organization

The corpus contains 137 distinct applications curated from Polybench, Rodinia, MachSuite, Rosetta, C2HLS, PP4FPGA, ForgeBench, HLSFactory, and additional GitHub sources, with an average program size of approximately 93 lines of code (Zou et al., 6 Jul 2025). Over 23,000 synthesized and annotated HLS design variants are produced through augmentation using Monte Carlo tree search and genetic algorithms for design-space exploration, combined with LLM-guided edits (Zou et al., 6 Jul 2025).

The application mix is deliberately heterogeneous. The kernels include linear algebra and dense compute from Polybench, image processing and vision from Rodinia, DSP-like and data analytics workloads from MachSuite, signal processing and other FPGA-oriented tasks from PP4FPGA and Rosetta, and real-world GitHub kernels (Zou et al., 6 Jul 2025). Complexity ranges from small loop-based kernels to multi-function pipelines requiring dataflow and streaming, and spans memory access patterns such as coalescing, tiling, and ping-pong buffers, as well as control structures including nested loops and producer-consumer organization (Zou et al., 6 Jul 2025).

The file layout follows a simple paired structure in which code files $x$ and $y$ are accompanied by the testbench and corresponding Vitis HLS synthesis reports (Zou et al., 6 Jul 2025). Code pairs are stored as complete sources rather than diffs, allowing models to learn full-program edits and directive placement in context (Zou et al., 6 Jul 2025). Performance and resource tags are included as discrete 1–10 labels ranking each variant by latency and area, with 10/10 assigned respectively to the top 10% performers by lowest latency and the lowest 10% resource users (Zou et al., 6 Jul 2025).

3. Transformation taxonomy

A central feature of HLStrans is its explicit coverage of five transformation categories, each tied to HLS constraints and optimization mechanisms (Zou et al., 6 Jul 2025).

Category	Representative contents
Code restructuring	Loop tiling, local tiling, memory coalescing, ping-pong buffering, dataflow partitioning, control flow simplification
Directive insertion	#pragma HLS PIPELINE, UNROLL, ARRAY_PARTITION, DATAFLOW, INLINE, RESOURCE, DEPENDENCE, STREAM, loop-merge and related loop-level pragmas
Data-type adaptation	ap_int<W>, ap_uint<W>, ap_fixed<TOTAL,INT>, ap_ufixed<TOTAL,INT>, precise-width structs/bitfields, pointer/array to hls::stream<T>
Function-level transformation	hls::sqrt, hls::exp, hls::log, hls::sin/cos, synthesizable division and modulo such as hls::div, hls::mod
HLS-compliant code repair	Removal of dynamic memory, recursion, function pointers, unrestricted pointer arithmetic; enforcement of static loop bounds and fixed-size arrays

These categories are directly aligned with the synthesis requirements of HLS. Synthesizability depends on static bounds and analyzable control and data dependencies; hardware mapping depends on appropriate memory structures, buffering, streaming, and stage formation; optimization depends on pragma-guided scheduling and resource allocation (Zou et al., 6 Jul 2025). The taxonomy therefore serves a dual role: it defines the label space of transformations represented in the dataset and provides a decomposition of the end-to-end C-to-HLS task into repair, restructuring, and performance tuning.

An important technical point is that HLStrans extends beyond pragma-only optimization. The paper emphasizes code restructuring, data-type adaptation, function substitution, and HLS-compliant repair in addition to pragmas (Zou et al., 6 Jul 2025). This matters because many C-to-HLS failures cannot be solved by inserting directives alone; they require semantic edits to remove unsupported constructs or to expose a more hardware-compatible computation structure.

4. Toolchain, validation, and metrics

HLStrans is built around AMD Vitis HLS in the Xilinx flow, with the Xilinx Alveo U55C data center card as the FPGA target (Zou et al., 6 Jul 2025). The main experimental flow uses a 200 MHz clock constraint, while some augmentation and evaluation runs use 300 MHz to demonstrate runtime improvements (Zou et al., 6 Jul 2025). The dataset uses HLS-specific types such as ap_int, ap_fixed, and ap_uint, and hls::stream for FIFO-based streaming, together with extensive use of pipeline, unroll, partition, and dataflow pragmas (Zou et al., 6 Jul 2025).

Validation is testbench-driven. Every optimized design passes a self-contained testbench that checks functional equivalence to the original specification (Zou et al., 6 Jul 2025). Synthesis success and warnings are tracked, and the optimization requirement is conditional: if the original $x$ is synthesizable, the optimized $y$ must reduce cycles; if $x$ is not synthesizable, $y$ must become synthesizable (Zou et al., 6 Jul 2025).

The evaluation protocol uses HLS-tool-reported QoR and success labels. The principal metrics are %Function Correct, %Synthesis Correct, Acceleration, and %Optimization Rate (Zou et al., 6 Jul 2025). Acceleration is defined as

$\mathrm{accel} = \frac{o}{n},$

where $y$0 is the latency in cycles of the baseline or reference and $y$1 is the latency in cycles of the new variant (Zou et al., 6 Jul 2025). Minimum, average, and maximum acceleration are reported for functionally and syntactically correct cases, while %Optimization Rate records the share of test programs with $y$2 and maintained functional correctness (Zou et al., 6 Jul 2025).

Standard HLS metrics available in the synthesis reports include latency in cycles, initiation interval $y$3 for pipelined loops, achieved frequency $y$4, and resource utilization in LUTs, FFs, DSPs, and BRAM (Zou et al., 6 Jul 2025). For throughput-oriented analysis, the conventional relation

$y$5

is noted, although the dataset aggregates acceleration using reported latency cycles in practice (Zou et al., 6 Jul 2025).

5. Benchmarking LLMs

HLStrans includes a benchmark spanning closed-source and open-source LLMs. The models named in the paper are GPT-4o and Deepseek-R1 on the closed-source side, and Qwen2.5-Coder-32B-Instruct, Qwen2.5-Coder-7B-Instruct, and Qwen2.5-Coder-3B-Instruct on the open-source side (Zou et al., 6 Jul 2025). The benchmark tasks are code repair, directive insertion and code transformation for latency and throughput optimization, and overall generation of functionally correct, synthesizable HLS code (Zou et al., 6 Jul 2025).

Three prompting strategies are evaluated: zero-shot prompting, chain-of-thought prompting, and retrieval-augmented prompting (Zou et al., 6 Jul 2025). The retrieval pipeline uses CodeBERT embeddings and FAISS KNN to retrieve the top-1 similar exemplar from HLStrans; that exemplar is then fed to the LLM to guide edits toward synthesizable, high-performance patterns (Zou et al., 6 Jul 2025). Candidate selection is evaluated with Best@1 and Best@5, where $y$6 candidates are generated per input and the fastest correct one is selected (Zou et al., 6 Jul 2025).

The key findings emphasize the value of exemplars. Retrieval-augmented prompting consistently yields the highest synthesis success without hurting functional correctness, and CoT helps all models, although retrieval delivers the largest gains (Zou et al., 6 Jul 2025). Deepseek-R1 and GPT-4o perform best overall (Zou et al., 6 Jul 2025). Representative results reported for Best@1 with retrieval are: Deepseek-R1 achieves Opt 41.2%, Avg accel 7.2×, and Max accel 57.0×; GPT-4o achieves Opt 41.2%, Avg accel 4.7×, and Max accel 24.6×; synthesis correctness reaches up to 47.1% (Zou et al., 6 Jul 2025). For Best@5 with retrieval, Deepseek-R1 achieves Opt 47.2%, Avg accel 9.4×, and Max accel 83.2×; GPT-4o achieves Opt 41.2%, Avg accel 5.9×, and Max accel 37.3×; function correctness reaches up to 64.7%, and synthesis correctness up to 58.8% (Zou et al., 6 Jul 2025).

The failure analysis is also technically significant. Over-aggressive pragmas can degrade performance or break synthesis, LLM edits may introduce loop-carried dependencies that prevent pipelining, and misplaced dataflow or insufficient FIFO depth can stall concurrency (Zou et al., 6 Jul 2025). These are not generic code-generation errors; they are HLS-specific failure modes in which syntax and even functional correctness can coexist with poor or invalid hardware schedules.

6. Fine-tuning, usage patterns, and experimental splits

The paper reports optimization-conditioned fine-tuning in which performance and resource tags from 1 to 10 are used to encourage a model to prefer code patterns associated with low latency and low area (Zou et al., 6 Jul 2025). The setup uses 2× NVIDIA H100 $y$7, CUDA 12.2, and cuDNN 9.1 (Zou et al., 6 Jul 2025). Fine-tuned Qwen2.5-Coder-7B and Qwen2.5-Coder-3B exhibit higher optimization rates, larger average accelerations, and better synthesis success; one reported point is Best@5 for Qwen-7B, with Opt 29.4%, Avg accel 3.1×, and Max accel 21.4×, accompanied by a small drop in function correctness (Zou et al., 6 Jul 2025). The interpretation given is improved hardware-aware behavior learned from HLStrans (Zou et al., 6 Jul 2025).

The experimental split uses 17 applications for testing, including repair and optimization tasks, while the remaining 120 applications are divided into training $y$8 and validation $y$9 (Zou et al., 6 Jul 2025). The paper notes that researchers can replicate or customize splits for their own studies (Zou et al., 6 Jul 2025).

Practical usage guidance in the paper is unusually explicit. Researchers are advised to structure prompts around the five transformation families, typically repairing for synthesizability first, then staging optimizations in the order pipeline $tb$0 unroll $tb$1 partition $tb$2 dataflow, and finally adapting types and functions such as ap_fixed, ap_int, hls::stream, and hls::sqrt (Zou et al., 6 Jul 2025). Retrieval augmentation is recommended as a way to guide safe pragma placement and common streaming and pipelining idioms (Zou et al., 6 Jul 2025). The paper also recommends an automated loop of testbench execution, synthesis, and metric collection, tracking %Function Correct, %Synthesis Correct, latency, $tb$3, $tb$4, LUT/FF/DSP/BRAM utilization, acceleration, %Optimization Rate, and failure or warning logs (Zou et al., 6 Jul 2025).

The listed pitfalls are concrete and domain-specific: misplaced pipeline or unroll pragmas can increase $tb$5 or fail because of loop-carried dependencies; over-partitioning arrays can exceed BRAM or LUTRAM budgets; naive dataflow regions without adequate streaming depth can deadlock; and floating point in tight loops can inflate DSP usage, motivating conversion to ap_fixed with justified bit-widths (Zou et al., 6 Jul 2025).

7. Exemplars, limitations, and significance

A concrete example in the paper is a K-Nearest Neighbors kernel transformed using pipelining, loop unrolling, array partitioning, and hls::stream-based buffering (Zou et al., 6 Jul 2025). The baseline latency is 2,097,324 cycles, the optimized latency is 508,479 cycles, and the resulting speedup is

$tb$6

(Zou et al., 6 Jul 2025). The optimized design increases resource use—specifically more DSPs, LUTs, and FFs—to enable deeper pipelines and parallel compute lanes, while remaining within platform budgets (Zou et al., 6 Jul 2025). The paper also reports that for Rodinia kernels such as kmeans, runtime drops from 2243.2 ms in the baseline to 15.7 ms under the Deepseek-R1 + HLStrans framework (Zou et al., 6 Jul 2025). These examples are used to illustrate how a single base program can yield multiple HLS variants with distinct latency, $tb$7, and resource trade-offs.

The limitations are clear. Current evaluations rely on synthesis reports rather than on-board measurements, and the dataset targets the AMD/Xilinx flow; planned expansions include real FPGA execution-time measurement, Intel FPGA platforms, Catapult HLS, larger program sizes, and broader real-world kernel coverage (Zou et al., 6 Jul 2025). This suggests that present metrics should be interpreted as synthesis-level proxies for deployed hardware behavior rather than as final silicon- or board-level performance claims.

HLStrans is publicly available under the MG0-2.0 license at https://huggingface.co/datasets/qingyun777yes/HLStrans, and each entry includes paired C/HLS sources, testbenches, synthesis-derived labels, and explanatory reasoning (Zou et al., 6 Jul 2025). Its significance lies in combining paired full-source supervision, validated testbenches, transformation metadata, and synthesis-derived optimization signals in a single benchmarkable corpus. Within the landscape described by the paper, that combination is what makes it suitable for immediate training and evaluation of LLMs for C-to-HLS hardware code synthesis (Zou et al., 6 Jul 2025).