---
title: HLStrans Dataset Overview
url: https://www.emergentmind.com/topics/hlstrans-dataset
type: topic
---

# HLStrans Dataset Overview

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 [2507.04315]. 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 [2507.04315]. 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 [2507.04315].

## 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 [2507.04315]. 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 [2507.04315].

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 [2507.04315]. 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 [2507.04315]. 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 [2507.04315].

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 [2507.04315]. 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 [2507.04315].

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 [2507.04315]. Code pairs are stored as complete sources rather than diffs, allowing models to learn full-program edits and directive placement in context [2507.04315]. 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 [2507.04315].

## 3. Transformation taxonomy

A central feature of HLStrans is its explicit coverage of five transformation categories, each tied to HLS constraints and optimization mechanisms [2507.04315].

| 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 [2507.04315]. 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 [2507.04315]. 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 [2507.04315]. The main experimental flow uses a 200 MHz clock constraint, while some augmentation and evaluation runs use 300 MHz to demonstrate runtime improvements [2507.04315]. 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 [2507.04315].

Validation is testbench-driven. Every optimized design passes a self-contained testbench that checks functional equivalence to the original specification [2507.04315]. 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 [2507.04315].

The evaluation protocol uses HLS-tool-reported QoR and success labels. The principal metrics are %Function Correct, %Synthesis Correct, Acceleration, and %Optimization Rate [2507.04315]. Acceleration is defined as
$$
\mathrm{accel} = \frac{o}{n},
$$
where \(o\) is the latency in cycles of the baseline or reference and \(n\) is the latency in cycles of the new variant [2507.04315]. Minimum, average, and maximum acceleration are reported for functionally and syntactically correct cases, while %Optimization Rate records the share of test programs with \(\mathrm{Acceleration} > 1\) and maintained functional correctness [2507.04315].

Standard HLS metrics available in the synthesis reports include latency in cycles, initiation interval \(II\) for pipelined loops, achieved frequency \(f\), and resource utilization in LUTs, FFs, DSPs, and BRAM [2507.04315]. For throughput-oriented analysis, the conventional relation
$$
\mathrm{Throughput} = \frac{f}{II}
$$
is noted, although the dataset aggregates acceleration using reported latency cycles in practice [2507.04315].

## 5. Benchmarking large language models

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 [2507.04315]. 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 [2507.04315].

Three prompting strategies are evaluated: zero-shot prompting, chain-of-thought prompting, and retrieval-augmented prompting [2507.04315]. 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 [2507.04315]. Candidate selection is evaluated with Best@1 and Best@5, where \(k\) candidates are generated per input and the fastest correct one is selected [2507.04315].

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 [2507.04315]. Deepseek-R1 and GPT-4o perform best overall [2507.04315]. 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% [2507.04315]. 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% [2507.04315].

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 [2507.04315]. 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 [2507.04315]. The setup uses 2× NVIDIA H100 \(80\,\mathrm{GB}\), CUDA 12.2, and cuDNN 9.1 [2507.04315]. 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 [2507.04315]. The interpretation given is improved hardware-aware behavior learned from HLStrans [2507.04315].

The experimental split uses 17 applications for testing, including repair and optimization tasks, while the remaining 120 applications are divided into training \(90\%\) and validation \(10\%\) [2507.04315]. The paper notes that researchers can replicate or customize splits for their own studies [2507.04315].

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 \(\rightarrow\) unroll \(\rightarrow\) partition \(\rightarrow\) dataflow, and finally adapting types and functions such as `ap_fixed`, `ap_int`, `hls::stream`, and `hls::sqrt` [2507.04315]. Retrieval augmentation is recommended as a way to guide safe pragma placement and common streaming and pipelining idioms [2507.04315]. The paper also recommends an automated loop of testbench execution, synthesis, and metric collection, tracking %Function Correct, %Synthesis Correct, latency, \(II\), \(f\), LUT/FF/DSP/BRAM utilization, acceleration, %Optimization Rate, and failure or warning logs [2507.04315].

The listed pitfalls are concrete and domain-specific: misplaced pipeline or unroll pragmas can increase \(II\) 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 [2507.04315].

## 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 [2507.04315]. The baseline latency is 2,097,324 cycles, the optimized latency is 508,479 cycles, and the resulting speedup is
$$
S = \frac{L_{\text{base}}}{L_{\text{variant}}} = \frac{2{,}097{,}324}{508{,}479} \approx 4.12\times
$$
[2507.04315]. 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 [2507.04315]. 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 [2507.04315]. These examples are used to illustrate how a single base program can yield multiple HLS variants with distinct latency, \(II\), 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 [2507.04315]. 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 [2507.04315]. 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 [2507.04315].

Source: https://www.emergentmind.com/topics/hlstrans-dataset