A Chisel Framework for Flexible Design Space Exploration through a Functional Approach

TL;DR

This paper introduces a flexible, functional approach to design space exploration using Chisel, enabling customizable strategies that improve hardware design efficiency and reduce development time.

Contribution

It proposes a novel methodology leveraging functional programming in Chisel for adaptable design space exploration, with a proof-of-concept framework and strategy library.

Findings

Demonstrated flexible exploration strategies with multiple use cases

Showed how metrics can guide exploration processes

Validated the approach's effectiveness in reducing design time

Abstract

As the need for efficient digital circuits is ever growing in the industry, the design of such systems remains daunting, requiring both expertise and time. In an attempt to close the gap between software development and hardware design, powerful features such as functional and object-oriented programming have been used to define new languages, known as Hardware Construction Languages. In this article, we investigate the usage of such languages - more precisely, of Chisel - in the context of Design Space Exploration, and propose a novel design methodology to build custom and adaptable design flows. We apply a functional approach to define flexible strategies for design space exploration, based on combinations of basic exploration steps, and provide a proof-of-concept framework along with a library of basic strategies. We demonstrate our methodology through several use cases, illustrating how various metrics of interest can be considered to build exploration processes - in particular, we provide a quality of service-driven exploration example. The methodology presented in this work makes use of designers' expertise to reduce the time required for hardware design, in particular for Design Space Exploration, and its application should ease digital design and enhance hardware developpers' productivity.

Full text

The methodology presented in this work makes use of designers’ expertise to reduce the time required for hardware design, in particular for Design Space Exploration, and its application should ease digital design and enhance hardware developpers’ productivity.

Chisel, design space exploration, FPGA, design methodology, functional programming

††ccs: Hardware Hardware description languages and compilation††ccs: Hardware Hardware accelerators

1. Introduction

Over the past few decades, software developers have benefited from emerging techniques and semantics, such as oriented programming, functional programming and incremental development. In the meantime, the development processes for digital designs have not evolved much, with most still relying on well-known processes based on Hardware Description Languages (HDL). To address this problem, and increase design productivity, initiatives have emerged such as Domain Specific Languages (DSL) or High Level Synthesis (HLS).

The first of these, DSLs, allow users to describe hardware circuits by composing specific operators for a given domain, such as audio, video, or network processing. Consequently, this approach offers users some optimized primitives, and the tools implicitly compose those primitives to build the resulting circuit. Although this approach is well-suited for users that are less familiar with the task of hardware design, it cannot be adapted for a general use case, as DSL are, by design, restricted to a specific applicative domain. Moreover, their use is also constrained by the available primitives (or IPs, for Intellectual Property), as they are often provided by an external vendor.

In contrast, HLS approaches allow users to define digital designs from a high-level entry point, using languages such as C to algorithmically define how the circuit should behave. This type of approach facilitates the design of hardware circuits in most cases, as the implementation details are abstracted from the designers, making it possible for them to focus on functional aspects instead. Due to these advantages, in the past decade, HLS tools have grown matured, and they are now widely adopted as an alternative to HDL-based design methodology in the industry. However, HLS approaches are less suitable for some cases, in particular where performance needs are tightly constrained, as the expressivity of the input description — *i.e. *an imperative description — is too high-level to specify most of the implementation details. Effectively, making those details abstractions can lead to suboptimal designs, especially for domain-specific problems with particular hardware needs, involving for example IP and memory interfacing, tight scheduling or target specific implementations (bruant_towards_2021). Moreover, HLS tools can lack expressivity, as users need to instrument the code to guide the tool toward an acceptable solution, for example by specifying unrolling factors for loops, or data structure partitioning. Indeed, as the change of programming paradigm in the flow is a complex problem, it requires complex tool chains, making this instrumentation both tool- and version-dependent. As a consequence, adapting a HLS design to a new target (or for other performance needs) can be tedious, with a corresponding impact on the potential for evolution, adaptability and reusability of such solutions. In addition, HLS tools have yet to be perfected to fully benefit from state-of-the-art compilation optimizations that could be adapted to the particular context of digital design, including accurate performance models to guide comparisons between implementation candidates (faber_challenges_2022).

Based on these concerns, an alternative to both DSL and HLS approaches would appear interesting, to propose a more generic design methodology. Such methodology could provide developers with performance, expressivity and reusability, without restriction to a particular applicative domain. As an initiative in this direction, Hardware Construction Languages (HCL) have been proposed, which can be used to describe parametrized hardware generators in high-level languages. Examples of languages that can be used as HCLs include python, with projects such as MyHDL or PyRTL (jaic2015enhancing; lockhart_pymtl_2014); Haskell, with C$\lambda$ash (baaij_clash_2010); and Scala, with SpinalHDL (papon2017spinalhdl) and Chisel (bachrach_chisel_2012).

Although these initiatives can effectively be used to add expressivity and reusability to standard design flows, some aspects of the designer’s job still need to be considered to propose efficient and generic design methodologies using HCLs. Among these aspects, we specifically consider in this work the problem of Design Space Exploration (DSE), which is a key feature in hardware design. It consists in selecting, among a (potentially very large) design space composed of functionally equivalent implementations, the implementation which best fits the use case, *i.e. *which has the “best” properties (operating frequency, resource usage, latency, etc.) for a particular problem.

In this work, we propose to consider the use of the HCL paradigm for DSE, to help developers to build and compare equivalent implementations in order to select the best one(s) for a particular use case. We chose to work with Chisel, a promising HCL which has imposed itself both in academic and industrial fields, but which does not yet support Design Space Exploration features, as far as we know. We start by proposing a new design methodology — meta design — which leverages Chisel’s features to build circuit generators based on meaningful generation parameters. We then use the functional features of the language to propose an alternative to DSE tools. We call this process meta exploration. It is based on an innovative philosophy: giving more credit to user expertise in guiding the exploration tools, rather than relying on generic heuristics which might not be appropriate for a particular use case. This approach allows us to propose a solution that leverages Chisel not only during the design phase, but also to build efficient, expertise-based strategies to explore the possible variations of an architecture. We hence propose a dual-methodology for design and exploration, with a particular focus on how a functional approach of the DSE problem can help build concise yet effective design processes.

In this paper, Section 2 presents an analysis of the Design Space Exploration problem in the literature, while Section 3 introduces the meta exploration methodology. Section 4 introduces the meta design methodology, the first stage in meta exploration, while Section LABEL:sec.dse introduces the second stage in the proposed methodology, providing a formalization of the DSE problem and how it can be solved through a functional approach. Section LABEL:sec.qece introduces QECE (Quick Exploration using Chisel Estimators), the framework that was developed as a proof-of-concept for the meta exploration methodology. Finally, Section LABEL:sec.expe demonstrates the usability of the proposed methodology through various experiments, and Section LABEL:sec.conclusion discusses the contributions of this paper, before considering the prospects of the proposed approach.

2. Background and Related Works

The process of building a digital circuit to solve a particular use case is central to the role of hardware developers. Describing the circuit’s micro architecture in a language that can be fed into the design flow is generally relatively easy, but this is only the visible part of a complex process. The whole process relies on an in-depth analysis of both the algorithm to be implemented and the targeted technology, guiding the developer’s decisions, based on their expertise in digital design to identify the best fit for each use case.

In this context, the developer is often faced with the task of Design Space Exploration (DSE), which is about comparing and selecting the best implementations for a given use case. The implementations compared are selected from among almost equivalent candidates, meaning that the developer needs to generate and compare implementations in a meaningful way. However, the problem of exploring this design space is quite broad, and consequently initiatives are being proposed to offer a better comprehension of the problem as a whole. As a first approach, Schafer et al. (schafer_high-level_2020) presented the DSE problem as a Multi Objective Optimization Problem (MOOP), with standard objectives to be optimized by the DSE tool. They propose an interesting 4-class taxonomy to classify the possible heuristics of exploration: meta heuristics, such as Genetic Algorithms (manuel_model-based_2020; paletti_dovado_2021) or Bayesian optimization (lo_multi-fidelity_2018), dedicated heuristics (awais_ldax_2021), supervised learning algorithms (nardi_practical_2019; geng_high-speed_2021), and graph-based analysis (zhao_performance_2020). This taxonomy highlights the fact that no generic DSE strategy is suitable for every use case, and therefore, to perform efficient DSE, we need generic and parametrizable exploration tools that could be fine-tuned by developers, based on their expertise.

As the aim of this paper is to propose an alternative to the existing DSE approaches, it is important to define some of the key features that a DSE tool should offer. In this context — and based on the considerations from (schafer_high-level_2020) — we hence list the characteristics of an ideal DSE tool. First of all, it should be programmable, allowing users to parametrize at least two aspects of the exploration: the metrics of interest and the exploration strategies. The metrics of interests — *i.e. *metrics that the tool should consider during the exploration process — are key concerns when it comes to exploration, as the user may want to consider standard features of the circuit targeted (*e.g. *resource usage, operating frequency, latency, or power consumption), or more specific features, such as security aspects or quality of service provided. The exploration strategies — *i.e. *the algorithm that the tool uses to scan the design space — can be used to avoid exhaustive exploration of the design space or suboptimal convergence of the exploration process, for example. Furthermore, any such tool should also focus on the performance of the resulting circuits, in order to provide users with exploitable designs. A similar focus should also be applied to the controllability of the circuits generated, as the users may want to exploit their expertise to specify some implementation details (*e.g. *memory interface, IP usage or control flow) to guide the tool toward better solutions. Last but not least, the DSE tool should be integrable in any development flow, especially in emerging agile approaches, meaning that its results should be readily reusable, portable and adaptable to new use cases (*e.g. *a new technology target, new performance needs, a new functioning environment or even a new tool chain), and should be compatible with most development frameworks.

As the principle of HLS itself is tightly linked to the problem of exploring design spaces, HLS tools are imposing themselves as turnkey solutions for DSE, with tools produced by both academic (canis2011legup) and industrial stakeholders (zhang_autopilot_2008; singh2011implementing). However, those approaches are limited by design, as inferences from the tool to generate archictecture variations affect both the reusability and the controllability of designs. Indeed, HLS tools act on implicit parameters — known as exploration knobs (schafer_high-level_2020) — to generate several hardware implementations of the same algorithm. Exploration knobs — such as memory partitioning, or the level of unrolling of imperative loops — can be directly manually tuned by users in the imperative description, but such tuning is highly dependent on the tool and its version, hence influencing the portability of the approach. Moreover, it then requires considerable effort to adapt a description to a new use case, as it is not always straightforward to infer how knob will affect the optimization objective(s) during the exploration process. Finally, the available tools are generally based on standard metrics and exploration strategies, that cannot be parametrized by users in a programmatic way. Nevertheless, among the DSE initiatives described in the literature, some leverage multiple approaches by combining them for efficient exploration (dong_liu_efficient_2016; bai_boomexplorer_2021), displaying a need for flexibility in the process of building an exploration strategy.

Simultaneously, more controllable solutions have emerged, based on hardware-targeting languages rather than higher-level descriptions. Among them, Paletti et al. (paletti_dovado_2021) introduced Dovado, an RTL based DSE framework that leveraged HDL parameters for design space exposition. With Dovado, users can explore a more meaningful design space, and the descriptions can be reused and adapted to new use cases, as they are written in a HDL. However, the users have no control on the metrics to be optimized during the exploration process, or on the exploration strategies — *e.g. *they can use Genetic Algorithm based strategies (based on (shokri_algorithm_2013)), but cannot fine-tune them, or develop and integrate new strategies. In addition, the authors claim that they should support a more powerful entry language — such as Chisel — as Verilog features are in fact limited for this type of use.

In this work, to respond to these various needs, we propose a novel approach for a Chisel-based DSE tool focused on user experience, by providing a framework to build flexible, user-defined exploration strategies, based on three main notions. First of all, we consider the process of exposing the design space to be explored as a key concern to build efficient exploration strategies — in contrast to implicit approaches such as HLS where the tools infer the different implementations to be compared, we propose to allow users to define the design spaces themselves, hence relying on their expertise to expose the relevant candidates for exploration. Through this method, users can extensively control both the implementation and the design spaces explored by the tool. The second notion relates to the comparison of implementation candidates: users should be able to define the metrics to be optimized — *i.e. *the Objectives of the Multi Objective Optimization Problem (schafer_high-level_2020). Finally, we consider that users should be able to define custom exploration strategies — *i.e. *user-defined algorithms to scan the design spaces and compare the different implementations — that could be composed to provide use-case-adapted DSE processes based on the users’ knowledge.

3. Overview of the Proposed Methodology

The methodology proposed in this paper has two main goals: to build reusable and adaptable hardware generators, and to use those generators to develop Design Space Exploration (DSE) features, making it possible to build flexible design processes.

3.1. A Novel Approach to Design Space Exploration

To begin with, we consider the DSE problem from a new perspective, based on the considerations introduced in the previous section — *i.e. *providing an efficient, programmable and reusable framework for DSE. To do, we consider three complementary aspects that can be used to describe an exploration approach:

1. (1)

design space exposition, which is used to define the architecture variations to be considered in an exploration process.

In most standard tools, this is usually done through a combination of implicit parameters — such as the level of loop unrolling in a HLS kernel – and explicit user guidance — which can add some hints (usually using pragmas) to select the best parameters, in order to help the exploration tools to build a meaningful design space. 2. (2)

metric definition, which defines the metrics that must be considered to efficiently compare the various implementations.

Such metrics can be the resource usage — *e.g. *for developers who want to constrain the area — the latency of the resulting kernels, or any other metric that makes sense for the specific use case. 3. (3)

exploration strategy, which specifies how the exploration tool scans the design space to qualify the different implementations, and how it compares them to identify one or multiple best fit(s).

As stated by Schafer *et al. * (schafer_high-level_2020), standard DSE methodologies rely on pre-existing, more or less generic heuristics to propose exploration strategies. Such tools do not usually allow users to add a new strategy, or to fine-tune the proposed heuristics for a particular use case.

This novel approach to the DSE problem there makes it possible to analyze the existing literature in a new light, as the three aspects are usually considered as a whole. In this paper, we leverage this new approach to build a flexible and modular methodology for design space exploration.

3.2. Meta Exploration Methodology

Based on the considerations set out in Section 3.1, we introduce a novel exploration methodology. As Hardware Construction Languages (HCL) can be used to build hardware generators, and hence expose interesting design spaces to explore, we based this approach on this emerging paradigm. This methodology — that we call meta exploration methodology — is introduced in a simplified schematic in Figure 1, which highlights the process by which the design space for a particular architecture is explored.

Meta exploration involves on two complementary steps, which we will detailed below:

1. (1)

exposure of a design space that would be interesting to explore, with respect to the algorithm being implemented (Section 4).

The developer of a module is responsible for providing a parametrized generator along with meaningful parameters, so as to define a design space that only includes meaningful variations of architectures. 2. (2)

leverage of a functional approach to describe an exploration strategy as a composition of basic steps (Section LABEL:sec.dse).

The developer must then define the different steps in the exploration strategy, using a flexible approach to guide and control the exploration process.

Meta exploration is proposed as a novel methodology which relies on high level features to address the challenges of Design Space Exploration. The specific goal of this methodology is to allow users to take advantage of their own expertise and knowledge to develop and control the various steps in the design process, rather than relying on more or less configurable steps and inferences.

4. Design Space Exposition

The first step in our novel meta exploration methodology is to explicitly define the design space to be explored. To perform design space exposition, we propose to rely on the developer of the module itself to expose a meaningful design spaces to be explored, by drawing on their experience with respect to the target algorithm, the architectural choices and the target device.

We introduce a sub methodology called meta design in Figure 2, which aims to build highly parametrized hardware generators based on prior analysis of the algorithm and the functioning environment of the resulting circuit.

The meta design methodology is comparable to standard hardware design processes — that can be summarized as analysis, implementation and validation (Figure 2) — as the designer must adequately analyze the target ecosystem before implementing a particular algorithm. However, particular emphasis is placed on defining and exposing high-level parameters for the generators built, in order to propose architectures variations that can be directly integrated into the generator description. Through this approach, it becomes possible to reuse and adapt the circuits and modules produced, hence increasing the designers’s productivity.

This approach mainly makes it possible to perform meaningful design space exposition for each module developed, as the parameters are defined by the developers themselves. Although this means that the developer must take on a new task — as exposing relevant parameters can require more reflection and planning than standard RTL design processes — it also means that any exploration process relying on this methodology will only consider implementations that were selected by the developer of the module(s).