DB4HLS

DB4HLS is a database of High-Level Synthesis (HLS) Design Space Explorations (DSEs) comprising more than 100000 design points. In the database are reported outcomes of exhaustive explorations performed on 39 designs from the MachSuite benchmark suite.

DB4HLS aims to provide standardized synthesis data sets that will allow easier comparisons among DSE strategies, enabling fairer evaluations of the strengths and weaknesses of each approach. It will also facilitate the development and assessment of future design exploration frameworks.

DB4HLS provides a rich set of DSEs by targeting the benchmarks of the MachSuite collection of designs. We have performed DSEs for 39 out of 50 functions in the benchmark suite, discarding those with variable latency due to input-dependent control flows and those with very small design spaces. The considered functions present on average 40 lines of code, with the biggest having 308 lines of code.

For each design, we performed an extensive DSE across their configuration spaces to generate the set of all possible implementations defined by the user. The data collection required more than 4 years of single-core machine time. We aim at constantly expanding the database in order to add DSEs targeting different benchmark suites.

For an overview of the contributions included in DB4HLS, you can refer to:

2020 DB4HLS: A Database of High-Level SynthesisDesign Space Explorations
L. Ferretti, J. Kwon, G. Ansaloni, G. Di Guglielmo, L. Carloni, and L. Pozzi. DB4HLS: A Database of High-Level SynthesisDesign Space Explorations.

DB4HLS structure

The DB4HLS infrastructure offes:

A database of DSEs

The database structure, implemented in MySQL, comprises a description of the designs targeted for exploration and the explored HLS optimizations applied to each design. Finally, it reports the resource and performance results obtained by synthesis. The database tables and the relationships among the entities are depicted in the picture below.

A detailed description of the database tables and their contents is available at DB4HLS documentation.

A domain-specific language for DSEs

Generating the different configurations associated with a DSE is a tedious and error-prone process when performed by hand. Therefore, we developed a Domain-Specific Language (DSL) to automatically and concisely define configuration spaces by employing Configuration Space Descriptors (CSDs).

Below is an example of CSD for the last_step_scan function included in DB4HLS, describing 1600 different configurations:

resource;last_step_scan;bucket;{RAM_2P_BRAM} resource;last_step_scan;sum;{RAM_2P_BRAM} array_partition;last_step_scan;bucket;1;{cyclic,block};{1->512,pow_2} array_partition;last_step_scan;sum;1;{cyclic,block};{1->128,pow_2}@bind_a unroll;last_step_scan;last_1;{1->128,pow_2}@bind_a unroll;last_step_scan;last_2;{1,2,4,8,16} clock;{10}

Each line of a descriptor encodes a knob, which comprises a directive type, a label corresponding to its location in the design C/C++ code, and one or multiple sets of values. The number of sets is equal to the number of parameters required by the directive type. Values can be numerical when expressing optimizations such as loop unrolling or array partitioning factors, or categorical when determining the type of employed FPGA resources such as BRAM types. A shorthand is provided for expressing regular value series (e.g., a succession of power-of-two values). Finally, we provide a @bind decorator, which constraints the values associated with different directives.

A detailed description of the DSL created to describe the configuration space is available at DSL documentation.

A framework parallelizing synthesis runs

To automate DSE and commit their outcomes in DB4HLS, we have created a framework to parallelize new explorations and further enrich the database. Starting from a user-provided design and Configuration Space Descriptor (CSD), configuration files are automatically generated and stored in the database. Then, using GNU Parallel, a tunable number of instances of an employed HLS tool (we use Vivado HLS for the data collection, but it can be interfaced to other synthesis tools) are concurrently and independently executed, one for each configuration. As synthesis runs terminate, the retrieved performance and resource information are also stored in DB4HLS, and new HLS processes are launched until all configurations have been explored.

The figure above shows an overview of the parallelized exploration process.

MySQL statements can then be used to retrieve data from the tables in the database and to access the design's implementations and the associated performance and resources results.

A tutorial on how to interact with the database and retrieve data from it is avaliable at the DB4HLS tutorial page.

Author

Lorenzo Ferretti, Ph.D., currently PostDoc at Università della Svizzera italiana (USI).
You can find more information about my work here and for any question you can contact me at lorenzo.ferretti@usi.ch.