Syringe Pump Design Hardware

C2HLSC: Leveraging Large Language Models to Bridge the

Software-To-Hardware Design Gap

LUCA COLLINI, SIDDHARTH GARG, and RAMESH KARRI, NYU Tandon School of Engineering, USA High-Level Synthesis (HLS) tools offer rapid hardware design from C code, but their compatibility is limited by code constructs. This paper investigates Large Language Models (LLMs) for automatically refactoring C code into HLS-compatible formats. We present a case study using an LLM to rewrite C code for NIST 800-22 randomness tests, a QuickSort algorithm, and AES-128 into HLS-synthesizable C. The LLM iteratively transforms the C code guided by the system prompt and tool’s feedback, implementing functions like streaming data and hardware-specific signals. With the hindsight obtained from the case study, we implement a fully automated framework to refactor C code into HLS-compatible formats using LLMs. To tackle complex designs, we implement a preprocessing step that breaks down the hierarchy in order to approach the problem in a divide-and-conquer bottom-up way. We validated our framework on three ciphers, one hash function, five NIST 800-22 randomness tests, and a QuickSort algorithm. Our results show a high success rate on benchmarks that are orders of magnitude more complex than what has been achieved generating Verilog with LLMs.

CCS Concepts: • Hardware →Application specific integrated circuits; Hardware-software codesign; Hardware description languages and compilation; Software tools for EDA. Additional Key Words and Phrases: High-Level Synthesis, Large Language Models, Automatic Code Repair

Acm Reference Format:

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. 1, 1, Article 1 (January 2025), 24 pages. https://doi.org/10.1145/3734524

Introduction

The increased demand for custom hardware accelerators shines a light on High-Level Synthesis (HLS) tools, which allow the fast design of accelerators by converting C code into hardware description languages (HDLs) such as Verilog and VHDL. HLS tools convert a high-level specification (C, C++) into an register transfer level (RTL) description : (1) HLS uses state-of-the-art compilers (e.g., LLVM or GCC) to extract a high-level control data flow graph (CDFG). (2) They then assign operations to time (scheduling) and space (allocation and binding) to determine the micro-architecture.

HLS tools support pragmas and directives to explore architectural choices for a C specification. HLS, though, does not come without its shortcomings. In fact, it can work on a subset of C code and often requires reformatting code in specific ways that are easier to map into hardware. This is because software and hardware paradigms are different.

For instance, hardware does not support dynamic memory allocation and recursive constructs. Outputs can only communicate through parameters, array sizes need to be static, limited support for pointers, and multiple processes can be modeled through independent function instances mapped into hardware blocks. Designers manually refactor C code to remove these constructs and make it compatible with HLS tools. Such manual refactoring is time-consuming and School of Engineering, Brooklyn, New York 11201, USA.

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on © 2025 Copyright held by the owner/author(s). Publication rights licensed to ACM.

2

Collini et al. error-prone . We explore the use of Large Language Models (LLMs) to aid developers in porting generic C code into HLS synthesizable C code. LLMs can write Verilog code . Since the available Verilog code is very scarce, compared to software languages like C and Python, LLMs perform poorly on HDLs. By raising the level of abstraction, we propose to use LLMs to write HLS C and aid hardware design effectively. We build upon the work in , expanding the prototype flow into a complete flow. The main contributions are: • An automated flow for rewriting C code into synthesizable C code, which: – Supports hierarchical designs, automatically building unit tests from a top-level test; – Supports function rewriting for streaming functions; – Supports pragma generation to target either area or throughput objectives; – Uses in-context learning and smart model selection to reduce cost; • An experimental evaluation using real-world applications benchmarks, including crypto and NIST implementa- tions of TRNG tests.

The Paper Road-Map Is As Follows:

(1) Section 2 gives an overview of High-Level Synthesis tools and large language models. (2) Section 3 summarizes related works, highlighting the novelties of our approach. (3) Section 4 illustrates the case study of an engineer-in-the-loop approach, presenting the tasks, methodologies, and results motivating the development of a fully automated framework.

(4) Section 5 presents the fully automated C2HLSC tool, discussing capabilities and limitations. (5) Section 6 reports the experimental setup and analyzes and discusses the results. (6) Section 7 concludes the paper .

2.1

High-Level Synthesis: capabilities and limitations HLS methods automatically convert a high-level software specification into a corresponding RTL description . The resulting component is a specialized IP block tailored to execute the functionality. The HLS process is based on state-of- the-art compilers (e.g., LLVM or GCC), which extract a high-level representation of the functionality and assigns the corresponding operations to time (scheduling) and space (allocation and binding) to determine the micro-architecture.

Engineers can instruct the HLS tool to adopt different implementation strategies for different parts of the code by using pragmas or directives. Pragmas and directives formats are tool-specific, but most tools support the following

Optimizations:

• Loop unrolling: multiple iterations of a loop are executed simultaneously, reducing the number of loop iterations. In hardware, this increases parallelism by replicating hardware resources for each unrolled iteration. For example, instead of processing one element per clock cycle, an unrolled loop might handle multiple elements concurrently, improving throughput for additional area due to resource duplication.

• Loop/Function pipelining: overlaps the execution of consecutive loop iterations/function calls, much like instruction pipelining in processors. This allows new iterations to begin before the previous ones complete, improving latency and resource utilization. The pragma controls the initiation interval (II), which determines how often new loop iterations start. A smaller II leads to higher throughput but requires more resources.

• Array partitioning: is used to divide arrays into smaller, independent memory blocks, allowing parallel access. This alleviates memory access bottlenecks by enabling multiple elements to be read from or written to

Manuscript Submitted To Acm

C2HLSC: Leveraging Large Language Models to Bridge the Software-to-Hardware Design Gap

3

simultaneously. Different partitioning schemes, such as block or cyclic partitioning, can be applied depending on the access patterns in the code. This improves bandwidth and efficient memory usage. Although other pragmas exist for defining module interfaces and other architectural optimization, these are the most commonly used pragmas and the ones that we focus on in the optimization part of this framework.

HLS has its shortcomings. Software paradigms assume the code to be executed on a Von Neumann machine, capable of dynamic memory allocations, stack management for function calls, and often with an operating system that provides routines for executing multiple processes. All these language features cannot be mapped into a hardware digital circuit and, for this reason, are not supported by HLS tools. The following are the most common HLS limitations:

(1) Dynamic Memory Allocation:

• Description: Functions like malloc, calloc, realloc, and free are used for dynamic memory allocation in C. Hardware requires fixed memory allocation, making these functions incompatible.

}

This C code allocates memory X integers and assigns the address of the allocated memory to arr. To make this code compatible with HLS tools, the engineer should identify an upper bound for the number of integers needed and use a fixed-size array.

(2) Recursion:

• Description: Recursive functions require dynamic stack management, which is not present in hardware. HLS tools build a hardware module for each function. A module that contains itself is not feasible.

}

Every recursive function can be rewritten in an iterative version. For the general case, it is necessary to implement a stack, and the engineer should identify an upper bound for it. (3) Pointers: Pointers, especially those involving dynamic memory or complex pointer arithmetic, have limited support in hardware as there is no concept of addressable memory.

(4) Standard Library Functions Many standard C library functions, especially those related to I/O, file handling, and dynamic memory, are not supported. (5) Complex Data Structures: dynamic or nested elements can be challenging to map directly to hardware.

(6) Multiple Processes: Multiple processes or threads are not directly supported; instead, independent function instances are used to model parallelism.

Large Language Models (Llms)

LLMs are trained on vast amounts of text data, excelling in tasks such as code generation and translation, particularly in widely used programming languages like C, C++, and Python. However, they encounter challenges when applied to

4

Collini et al. HDLs like Verilog or VHDL, due to the comparatively limited amount of training data in these specialized languages . In light of this, the focus of this paper shifts from generating HDL code to leveraging LLMs for refactoring C code into a subset that is compatible with HLS tools. Rather than targeting Verilog or VHDL directly, this approach capitalizes on HLS, which enables the design of hardware systems from C code. However, HLS imposes strict requirements, only functioning with specific code constructs as in Section 2.1. LLMs, with their proven strengths in understanding and transforming general-purpose C code, can be used to refactor this code into an HLS-synthesizable form while maintaining its original functionality. We provide instructions and examples in the form of in-context learning (ICL) to instruct the LLM on the kind of transformations needed for HLS. This strategy allows for a streamlined hardware design process by using LLMs’ capabilities in code manipulation, bypassing their limitations in HDL generation.

Related Works

Previous work explored LLMs to design hardware. Verigen fine-tuned an LLM to improve its ability to produce Verilog . The fine-tuned LLM, though, performed marginally better than ChatGPT3.5-turbo with an accuracy ∼65%. ChipChat was the first to tapeout a design written by an AI model. However, the single-shot performance of the AI model was low and needed several iterations in order for the LLM to get to the correct result. In AutoChip , authors proposed the use of simulation-based feedback to automatically guide the LLM towards a correct design iteratively.

The approach resulted in success, but only on very simple benchmarks. By leveraging C code generation, we aim to validate our work on real-world applications. In Liu et al. showed that raising the level of abstraction to Chisel (a domain-specific language based on Scala) improved the LLM success rate by 30% with respect to Verilog generation. We target generating synthesizable C code as LLMs are more capable at C than at hardware languages . In , an LLM was used to write Amaranth HDL, a Python-based HDL that allows the modeling of synchronous logic at the RTL. For this reason, while it uses a high-level language, its semantics are close to Verilog and is targeted to hardware designers. While the LLM came up with parts of the design, it fell short in some tasks, like generating interfaces.

Software developers use HLS to design hardware, and as such, the code only provides the functionality1. The first LLM-based approach to generating accelerators leveraging HLS was GPT4AIGChip. The GPT4AIGChip framework is based on user-provided templates to generate C code and directives to build accelerators. The process is not fully automated as some limitations in the framework (interfaces and composing different functions) need to be overcome by hand. Liao et al. evaluated natural language to synthesizable C and C to Verilog using LLMs. Similarly, Swaroopa et al. explored natural language to synthesizable C generation, finding frequent problems in the correctness of the generated code. We focus on transforming generic C to synthesizable C using LLMs. Our gap is closer, and our inputs and outputs are of the same nature, making this approach more promising to succeed. At the same time, our approach is relevant because most new algorithms are first implemented in software (i.e., reference implementations of NIST standards) and then need to be accelerated in hardware. Moreover, we can leverage the existing testing infrastructure to verify the correctness of the LLM-generated code. Our approach leverages the existing software code bases to build their hardware accelerators. HLSPilot is a framework that focuses on kernel identification and optimization starting from C/C++ code. To the best of our knowledge, HLSPilot does not focus on code repairs for synthesizable code. In Xu et al. proposed a framework to automatically repair C code for HLS. They first use state-of-the-art techniques to repair simpler issues and then use an LLM to repair the remaining issues. Their results show that their approach struggles on bigger benchmarks (for example, the success rate on AES is 60%, compared to 80% in our work). We include 1Whereas the hardware architecture and interface specification are instructed using HLS pragmas and directives.

Manuscript Submitted To Acm

C2HLSC: Leveraging Large Language Models to Bridge the Software-to-Hardware Design Gap

5

a preprocessing step to break down the design hierarchy and tackle the design in a bottom-up divide-and-conquer fashion, tasking the LLM with more, but simpler tasks.

Fpga

Fig. 1. Flow used in the C2HLSC case-study. We performed a case study manually prompting Gemini LLM to refactor C code into synthesizable C suitable for HLS. The goal of this case study was to explore the potential and limitations of LLM in refactoring C code for HLS tools.

The evaluation consisted of two tasks. The first task involved rewriting reference C implementations of the Frequency test, Frequency Block test, Cumulative Sums, and Overlapping Template Matching tests from the NIST 800-22 suite into synthesizable C code. These tests are designed to assess the randomness of a sequence. A first challenge arose due to the inherent differences between software and hardware implementations. The reference C implementations operate on a pre-loaded random sequence stored in memory. Conversely, hardware implementations require on-the-fly analysis, processing the sequence bit-by-bit. This necessitates modifying the code to handle a streaming data input rather than a pre-loaded array. A second challenge stemmed from the p-value calculation. In the software context, the precise p-value is critical and computed on the fly. However, since the hardware implementations primarily focus on distinguishing random from non-random sequences, this process can be simplified by pre-computing certain values offline and reducing the computational burden during on-the-fly analysis. Both these challenges – adapting to streaming data and simplifying p-value calculations – are non-trivial for human developers and LLMs. The second task assesses the LLM’s ability to rewrite code constructs that are not supported by HLS tools. We used two algorithms: a QuickSort containing pointers and recursion , and the AES128 encrypt from the tinyAES library with six functions. The goal was for the LLM to generate code without pointers and recursion, making it suitable for (Catapult) HLS.

Methodology

Figure 1 illustrates our We broke down the process into small steps to allow the LLM to transform the original C into synthesizable C. For the first task, we followed the following steps for the three tests: (1) Present task to the LLM: "Hi, I have this code in C that I need to rewrite such that I can use it with an HLS tool to generate hardware.". (2) Ask to remove print statements. (3) Ask to rewrite the function as a streaming interface: "Now I need to rewrite the function such that it will get inferred as a streaming interface, to do so, I need to get rid of the epsilon array and have the function take a parameter to accept a bit at each function call." (4) Ask to remove math steps to be computed offline (in some cases, ask to write a script to run them). (5) Ask to add is_random and valid signals as parameters. (6) Ask to optimize

6

Collini et al. data types using arbitrary width integers and fixed point arithmetic using HLSLIBS . (7) Ask to write a main function to test the function passing random bits. (8) Ask to fix mistakes passing errors from the HLS tool.

For QuickSort, we followed these steps: (1) Present the task to the LLM: "Hi, I have this code in C that I need to rewrite such that I can use it with an HLS tool to generate hardware.". (2) Ask to remove print statements. (3) Ask to rewrite function without using pointers. (4) Ask to rewrite function without recursion. (5) Ask to fix array sizes in function parameters. (6) Ask to optimize data types using arbitrary width integers and fixed point arithmetic using HLSLIBS. (7) Ask to write a main function to test the function passing an array to sort. (8) Ask to fix mistakes by passing errors from the HLS tool.

For the AES 128 from tinyAES we followed the following steps asking to fix one function at a time: (1) Present the task to the LLM: "Hi, I have this code in C that I need to rewrite such that I can use it with an HLS tool to generate hardware.". (2) Ask to rewrite for loops with fixed bounds and no pointer usage. (3) Ask to rewrite the function parameters to use fixed-size arrays. (4) Ask to fix eventual mistakes passing errors from the HLS tool. When the LLM responds with sub-optimal answers, we check alternative answers. If none fully satisfy the request, we instruct the LLM with additional prompts, including more details pointing out where the problem was and, if not sufficient, hinting at possible solutions.

Case Study Results

This study aimed to evaluate how LLMs perform at rewriting C code so that it is HLS synthesizable. We run the code through Catapult HLS to check correctness after synthesis, but we do not focus on resource utilization, as it depends on the architectural decisions. We targeted the nangate45 library at 50 MHz with a synchronous active high reset for all the tests. The LLM was able to rewrite all C code to run on Catapult HLS. We performed simulations with Modelsim to check the equivalency of the result between the original C and the synthesized Verilog obtained from the LLM-generated C. We can classify the errors in the LLM-generated code into compile/functional errors and synthesis errors. The syntax and synthesis errors were easier to fix, instructing the LLM with the error message and the affected line. For functional errors caught by the failing tests, it was harder for the LLM to identify the cause and propose a fix.

Manual effort was needed to point out the sources of the issues so that the LLM could propose an effective fix. Typical functional issues were mistaken loop readjustments, widths, and arbitrary width types.

4.3.1

C2HLSC of NIST 800-22 Randomness Tests. The LLM performed well in most steps, especially in rewriting the function as a streaming interface, which is one of the more complex steps. Figure 2 shows the streaming interface rewriting for the Frequency Block test. For all three tests, this step was performed correctly at the first shot. However, the LLM did stumble on tasks that seemed more trivial. For example, when asked to remove the abs function in this line of code (abs(sum.to_int()) <= SUM_THRESHOLD); it came up with convoluted ways that did not work like (sum.to_int() <0) ? -sum.to_int() : sum.to_int()) <= SUM_THRESHOLD and it took many tries to eventually get the expected result (sum

4.3.2

C2HLSC of QuickSort. The original QuickSort used a function to swap elements in the arrays using pointers. Inlining the function and removing pointers was flawless, as reported in Figure 3. However, in the subsequent steps it reverted to using the function and needed re-prompting to inline. The LLM eliminated recursion in one shot, using a fixed-size stack to track the high and low values. However, the stack management logic was not correct. The problem

Manuscript Submitted To Acm

C2HLSC: Leveraging Large Language Models to Bridge the Software-to-Hardware Design Gap

4 Array And Have The Function Take A Parameter

5 to accept a bit at each function call.

20 }}

Fig. 2. Transforming into a streaming pipeline. On the left, in green, human prompt. On the right, in purple, LLM response was identified at the end when running the generated test, which caused a segmentation fault. The LLM fixed the problem in a few tries by feeding the errors from gdb and showing intermediate values of high and low.

*B = Temp;}

5 ...

9 Swap(&Arr[Low], &Arr[J]);

10 ... 1 ...

Return J;

13 ... Fig. 3. Removing pointers and inlining. On the left, in green, human prompt. On the right, in purple, LLM response.

4.3.3

C2HLSC of AES 128 Encrypt. We fed one function at a time to the LLM starting from the top function Cipher. We tested the generated C code and found errors. We prompted the LLM to correct the errors. The LLM made major changes in the MixColumn and ShiftRows functions, so we asked it to double-check that the new code was correct. The ShiftRow function was corrected in 2 iterations without extra context on the error. Results are in Figure 4. Fixing the MixColumn function took more iterations even though the error was simple.

8

Collini et al.

1 Llm Result After 2 Tries Telling The Llm That

2 the loop logic was wrong.

(*State) = Temp;}

22 ...

16 }}}

Fig. 4. Removing pointers. On the left, in green, human prompt. On the right, in purple, LLM response

Case Study Discussion

Using LLMs to refactor C code into HLS-compatible formats is a promising avenue in LLM-aided design. The LLM, in our case Google’s Gemini, refactored reference C implementations of NIST 800-22 randomness tests, QuickSort, and AES-128. The LLM’s ability to iteratively refactor the code based on user instructions significantly reduces manual effort in adapting code for HLS tools. This can streamline the hardware design process, especially for repetitive tasks.

The LLM effectively addressed challenges like converting code from memory-based data processing to streaming, from recursion to iteration and pointers. While the LLM achieved core functionalities, it occasionally struggled with minor details, requiring several iterations to guide it to the correct solution. In a practical scenario, a developer can rectify these minor errors. However, for an automated flow, a feedback loop is crucial, like that in .

Table 1. Resource Utilization and Latency Results. Typical operations include memory read and writes and basic mathematical operations (such as XOR, sum, subtraction). For Monobit the operations are memory reads/writes, sums and comparators. The different numbers of operations between manual and LLM Assisted depend on unrolling/pipelining directives.

18115.8

n.a.

67

n.a.

18

n.a.

38604.5

n.a.

1924

n.a.

160

n.a. Table 1 shows the area for the implemented designs. For NIST test implementation, we have reference designs that were implemented by a graduate student. We used the same directives for a fair comparison between the 2. Area scores

Manuscript Submitted To Acm

C2HLSC: Leveraging Large Language Models to Bridge the Software-to-Hardware Design Gap

9

from Catapult are close. The manual implementations took around 4 hours each, while C2HLSC took between 30 to 60 minutes each. Although the sample size is limited, this shows the potential of LLMs to speed up the process effectively and efficiently.

Fully Automated C2Hlsc Framework

With the experience of the engineer-in-the-loop case study, we implemented a fully automated C2HLSC prototype. An overview of the framework is provided in Figure 5. The first insight from the case study was that the LLM can handle single-function tasks but has difficulties when prompted to work on multiple functions simultaneously. For this reason, we implemented a pre-processing step to handle hierarchical designs. A second insight was the twofold nature of the errors that can occur in the generated C: functional/compile errors and synthesis errors. The former can be caught by the inner loop (G++ and running unit tests). The latter can be caught by running the HLS tool. For this reason, we set up a double feedback loop as shown in Figure 5. One checks that the generated code compiles and passes reference tests, and one checks that the code is synthesizable by Catapult HLS. Once the code is synthesizable, we enter a new step to apply pragmas to the code. This step is based on the same double-loop structure of the code refactoring step.

We selected OpenAI and Anthropic models as we did not have access to Gemini APIs. Our framework is built around a model, the model itself can be easily swapped as more powerful models get released. The flow is implemented in Python and is available at C2HLSC.

Fn

...

Tn

...

Hls.V

Fig. 5. Automated C2HLSC LLM-based prototype flow.

Hierarchical Preprocessing

From our engineer-in-the-loop case study, we learned that prompting the LLM to fix the whole code base at once was not effective for larger code bases. For this reason, we implemented a preprocessing step (illustrated in Figure 5 1 ) that

10

Collini et al. has the role of breaking down the design hierarchy so that the code refactoring step can be applied to one function at a time. We parse the input C code and identify the function hierarchy starting from the top function specified by the user. The code refactoring step requires a test to verify functional correctness. To ease the engineer, we only require a top-level test and automatically build unit tests for the child functions as part of the hierarchical preprocessing step. To identify the inputs to the child functions, we compile the code in debug mode and run it with gdb. We set a breakpoint for each function call and read out the parameters value. We then use these values to build unit tests for the child functions. In this way, we can test the inner functions with the same values they would be called with when testing the top-level function. The whole process is automated with a Python script.

Code Refactoring

The code refactoring step (illustrated in Figure 5 2 ) is the heart of the C2HLSC flow. This step works on a single function. Functions are provided from the hierarchical preprocessing step, starting from leaf functions and then going up the hierarchy; in this way, we can always compile and synthesize the current function to test it. We noticed that LLMs have the tendency to get "distracted" by the function calls. Very often, the LLM would respond by reimplementing a function or providing a new signature for the function (a function signature consists of the function’s name, its parameters and their data types, and its return type), and the provided code would not compile when integrated with the results from the child functions. Sometimes, this was also caused by the LLM changing the signature of the child functions, which would then not be compatible with the parent calls. For this reason, we provide in the prompt the signature of the child functions from the previous iterations and instruct the LLM to consider those as provided. The code refactoring step may begin with an optional prompt to refactor the code to obtain a streaming interface. If this is not needed, the input function is synthesized with the HLS tool to identify the first error to fix. We build a prompt starting from the HLS tool error. Our system and initial prompts are listed in Figure 6. For the most common errors, we provide in-context learning examples to fix the error in the prompt. Section A.1 reports the in-context learning examples that we provide in our prompts.

1 You are a C and High -Level Synthesis (HLS) expert.

2

Assist with coding tasks to produce synthesizable HLS code. 3 Your response should include a C code snippet that only modifies the specified functions , 4 while leaving the rest of the code unchanged.

Do Not Add Pragmas Or Directives ,

5 and ensure the code allows the HLS tool to infer the correct behavior. 1 Help me rewrite the function to be compatible with HLS:

4 ```

5 The following child functions and includes will be provided with the following signature , assume them

11

12 also include a main function that tests the code in the same way of the reference code:

15 ```

Fig. 6. System prompt (on top) and initial prompt (on bottom) for code refactoring.

Manuscript Submitted To Acm

C2HLSC: Leveraging Large Language Models to Bridge the Software-to-Hardware Design Gap

11

We implemented a double feedback loop to guide the LLM to refactor the original C code into synthesizable C code. The inner loop uses g++ to compile the code. If the compilation process fails, we build a prompt including the error message from g++, and we prompt the LLM with it. This inner loop allows us to catch syntax and functional errors very quickly, as g++ is orders of magnitude faster than running the HLS tool directly. When the code compiles and runs successfully, we synthesize it with the HLS tool. If the synthesis succeeds, we proceed with the pragma identification step; otherwise, we build a new prompt as described above and re-iterate the loop.

Pragma Identification

The pragma identification step (illustrated in Figure 5 3 ) has the same structure as the code refactoring step, but we changed the task for the LLM. In this step, we prompt the LLM to add pragmas to the code either to reduce the area or maximize throughput. We use in-context learning to provide the available pragmas and syntax of the HLS tool. We need the double feedback loop as sometimes the LLM will change the code even if the system prompt asks to only add pragmas. For this reason, we need to check that the code still behaves as expected before we synthesize it. As reflected by our system prompt listed in Figure 7, we ask the LLM to focus the optimizations around loop unrolling, pipelining, array partitioning, and function inlining. We found that using this strategy, the LLM is less prone to change the code, possibly entering loops of error fixing. This approach allows us to get a higher success rate while still using the most common optimization pragmas.

1 You are a C and High -Level Synthesis (HLS) expert. Assist in coding tasks aimed at

2

optimizing synthesizable HLS code. Your response must include a C code snippet that

3

modifies only the specified functions for optimization. Do not change functionality , 4 and only add pragmas without modifying the function logic.

5

Optimize the code for either area or latency as instructed.

7

Loop Unrolling: Use "# pragma hls_unroll X" to unroll loops with a factor of X.

8

Set X to yes to fully unroll the loop. Unrolling reduces latency

9

at the cost of area.

10

Pipelining: Use "# pragma hls_pipeline_init_interval X" with X as the initiation

11

interval to pipeline loops. 0 disables pipelining. Pipelining

12

can be applied to loops to increase throughput at cost of latency. 13 If no optimization is needed , simply rewrite the original function.

1

Update the function to optimize it for HLS targeting .

5 ```

6 The following child functions and includes will be provided with the following

11 ```

12 You should include a main function that tests the code in the same way of the

16 ```

Fig. 7. System prompt (on top) and initial prompt (on bottom) for code optimization.

12

Collini et al.

Experimental Evaluation

We implemented the C2HLSC framework in Python, using pycparser to parse the input C code and generate unit tests code in the hierarchical preprocessing step. Our framework is available at C2HLSC. We selected Catapult HLS as our high-level synthesis tool as it is an industry-level tool capable of targeting both ASIC and FPGA flows. We targeted nangate45 at 50MHz with synchronous active high reset for all runs. We selected models from OpemAI and Anthropic.

In particular, we employ an ensemble approach using ChatGPT 4o-mini and 4o . We begin our flow with the smaller and cheaper 4o-mini model, and we switch to the more advanced but more expensive 4o model after 3 failing iterations. In this way, if the problem at hand is simple, we can solve it efficiently with the smaller model and use the more complex one only for the more challenging tasks. In this way, we save both execution time and cost as the smaller model is cheaper and faster than the more complex one. We also use Claude Sonnet 3.5 from Anthropic for a comparison. We evaluated our framework on ten benchmarks targeting both area and latency optimizations; for each configuration, we ran each benchmark 10 times with each model. We used the recommended parameters from each LLM provider: Claude Sonnet 3.5 with temperature=0.2 and top_p=0.2, and ChatGPT-4o with temperature=0.25 and top_p=0.2.

Benchmark Characterization

Previous work for Verilog generation is usually evaluated on RTLLM and/or VerilogEval , which are composed of very simple, grad-school class exercise levels at most. High-level synthesis code generation studies like [14, 20, 24] also focus on small, exercise-like problems. For our evaluation, we picked 10 benchmarks, of which 9 consist of real-world case applications. We selected three ciphers: AES, DES, and Present. One hashing function, sha256. Five tests for randomness evaluation: monobit, monobit block, cumulative sums, runs, and overlapping input pattern. We selected the quicksort algorithm to showcase an example of a recursive application. The ciphers and hash functions allow us to test our approach on dataflow-intensive designs with multiple hierarchy levels. The randomness tests allow us to stress our framework with applications that require to be refactored with a streaming interface. Both scenarios have in common that the algorithms come from standards that publish reference implementations, that might be wanted to be accelerated in hardware using HLS but are not compatible out of the box. Table 2 reports the benchmarks with their original sources and summarizes their characteristics. Some benchmarks needed minor modifications to work with our framework; all input code for our evaluation, together with the raw results, is available at our repo: C2HLSC.

Table 2. Benchmarks characterization. Min. and Max. counts are reported by single functions.

Total

Min. Max.

Total

Min. Max.

Related Journal Articles & DOI Links

Selected peer-reviewed publications relevant to 12 Lead ECG Acquisition. Click the DOI to access the full paper (may require institutional access).

Why Choose Us?

Bangalore guidance for robotics, Spectre and autonomous systems projects.