A Dynamic Memory Allocation Library for High-Level Synthesis

One impediment to the uptake of high-level synthesis (HLS) design methodologies is their lack of support for constructs frequently employed by software engineers - a primary example being dynamic memory allocation routines. No commercial HLS tool supports these constructs, forcing designers to rewrite programs to remove any dynamic memory allocation function calls (e.g.malloc(), free()), replacing them with statically allocated data. This shortcoming limits the portability of C/C++ descriptions, may introduce software bugs, and forces users to overestimate memory requirements, consuming precious on-chip BRAM resources. We address these problems by extending the capabilities of modern HLS tools through introduction of a tool-independent, HLS-friendly C library of five dynamic memory allocation schemes. Additionally, we developed a benchmark suite to evaluate and compare all five allocation schemes for their performance, area and memory trade-offs. We use the high-level synthesis tool, LegUp, to conduct our experiments. Our results indicate that each allocator in our library is best-suited for certain applications, in terms of performance, area and memory usage. We provide usage guidelines to assist HLS developers in selecting an appropriate allocation scheme.

I. Introduction

High-level synthesis (HLS) tools have allowed individuals to design digital circuits using high-level languages such as C/C++, with a few caveats. Many commercial and research HLS tools do not support dynamic memory allocation requests, function pointers and recursive function calls [1], [2], [3], [4]. This lack of coverage of the C/C++ language hinders HLS adoption. Programs that employ these unsupported programming constructs must be re-written before being input to an HLS flow. If dynamic memory allocation functions exist in the program, designers must re-write the code to use statically-allocated data. However, identifying the required static size of a dynamic memory request is challenging and causes HLS designers to overestimate memory requirements. Additionally, it is not always clear how one can translate dynamic memory constructs into statically allocated data. This problem is intensified if the program has a large number of unique dynamic memory requests, potentially causing the corresponding hardware circuit to consume a majority of on-chip memory. An HLS design modified to replace dynamic memory constructs may not fit on the device of choice. If the design does fit, synthesis tools may incur difficulty during place and route if a majority of memory resources are consumed, leading to lower . Additionally, requiring program modifications is undesirable as it may introduce bugs, requiring extra debugging time to ensure correct operation of the program/design [5].