---
title: 'Dynamatic: Dynamic HLS Compiler'
url: https://www.emergentmind.com/topics/dynamatic
type: topic
---

# Dynamatic: Dynamic HLS Compiler

Searching arXiv for the specified Dynamatic papers and closely related entries.
Dynamatic is an open-source, research-driven High-Level Synthesis (HLS) compiler that generates dynamically scheduled dataflow hardware from software programs. It compiles C into RTL implementations of dataflow circuits whose operations execute whenever their inputs are valid, using instruction-granularity dataflow graphs, dataflow units connected via handshake channels, and tokens that carry data over these channels [2603.19856]. Within the contemporary HLS landscape, Dynamatic is positioned as a state-of-the-art dynamic-scheduling HLS tool that lowers LLVM IR, in control-dataflow graph (CDFG) form, directly to latency-insensitive elastic dataflow circuits built around the handshake model of computation [2308.11048]. The resulting execution model differs from statically scheduled HLS by making operation firing depend on local data availability and handshake protocols rather than on a statically precomputed global schedule [2603.19856].

## 1. Definition and computational model

Dynamatic produces dynamically scheduled circuits in which operations are wrapped in handshake components and interconnected by channels that obey a handshake protocol. Data moves through the circuit when ready, so execution is driven by data availability rather than a statically fixed cycle schedule [2308.11048]. In the formulation summarized by the MLIR experience report, the generated hardware consists of instruction-granularity dataflow graphs, dataflow units connected via handshake channels, and token exchange across those channels; operations execute whenever their inputs are valid [2603.19856].

This model places Dynamatic within the paradigm of dataflow circuits and elastic circuits. The circuits are described as elastic, with local handshakes and buffering, and they can absorb variable latency, stalls, and reordering within correctness constraints [2603.19856]. A plausible implication is that Dynamatic’s hardware semantics is intentionally latency-insensitive in the sense emphasized by the GSA-to-HDL work, where throughput and latency are determined by data dependencies and backpressure rather than by a compile-time schedule [2308.11048].

The principal problem Dynamatic addresses is the construction of high-performance hardware for programs with unpredictable control flow or memory access patterns, where static scheduling and static control/dataflow models perform poorly [2603.19856]. The associated comparison class is conventional statically scheduled HLS, exemplified in the source material by Vivado HLS and Catapult, which must pessimistically assume worst-case latencies on irregular control-flow kernels [2308.11048]. In this sense, Dynamatic’s defining characteristic is not merely that it lowers software to hardware, but that it does so using a runtime, data-driven schedule.

## 2. Compilation flow and intermediate representations

Dynamatic currently takes C and produces RTL for dynamically scheduled dataflow hardware [2603.19856]. The reported pipeline begins with Clang, which parses C and produces LLVM IR; LLVM passes then perform standard optimizations [2603.19856]. A custom LLVM pass performs memory-dependence analysis, after which LLVM IR is converted to the MLIR ControlFlow dialect, then translated to Dynamatic’s handshake dialect, and finally lowered to RTL [2603.19856].

The following table summarizes the pipeline elements that are explicitly described.

| Stage | Representation or tool | Reported role |
|---|---|---|
| Front end | C, Clang | Parse C and produce LLVM IR |
| Mid-level optimization | LLVM IR, LLVM passes | Standard optimizations |
| Dependence analysis | Custom LLVM pass | Identify dependencies between memory accesses |
| MLIR import | ControlFlow dialect | Bring sequential control flow into MLIR |
| Circuit IR | Handshake dialect | Model dataflow circuits |
| Backend | RTL | Emit hardware description |

The ControlFlow dialect models structured control flow using basic blocks and branches such as `cf.br` and `cf.cond_br` [2603.19856]. In this representation, block arguments play the role of SSA $\phi$ inputs. The handshake dialect is Dynamatic’s custom dialect for dataflow circuits, where units are modeled as operations and channels as values [2603.19856]. It also defines custom attributes including `handshake.name` and `handshake.deps`, the latter being used to encode memory-dependency information in node attributes because MLIR does not permit attributes on values or edges [2603.19856].

The 2023 GSA-to-HDL paper describes Dynamatic somewhat differently, but compatibly, as a tool that takes LLVM IR in CDFG form and lowers it directly to latency-insensitive elastic dataflow circuits [2308.11048]. Read together, the two accounts suggest a toolchain whose conceptual hardware-facing representation is a control-dataflow graph or handshake graph, while its current implementation uses MLIR dialect boundaries to structure the lowering flow.

## 3. Dynamic scheduling, elasticity, and performance rationale

Dynamatic’s scheduling is dynamic in the specific sense that operation firing is controlled by local data and handshake protocols rather than by a statically precomputed global schedule [2603.19856]. This is the basis for the claim that the tool has a performance advantage whenever the control flow or memory access pattern is unpredictable [2603.19856]. The GSA-to-HDL paper frames the same point by observing that traditional statically scheduled HLS tools must pessimistically assume worst-case latencies, whereas Dynamatic’s circuits naturally tolerate variable or unknown latencies [2308.11048].

The trade-off is also explicit. Dynamatically scheduled circuits trade off area utilisation for increased dynamism and throughput [2308.11048]. The practical summary in the MLIR experience report states that Dynamatic has demonstrated benefits on irregular control-flow kernels, including up to $2.5\times$ improvement in execution time and $4\times$ throughput versus static HLS, at up to $5\times$ resource cost [2603.19856]. These figures are presented there as strengths of the tool rather than as results rederived in that paper.

A recurring feature of the design is elasticity. Buffering and local handshakes allow the circuit to absorb stalls and variable latencies, and Dynamatic applies buffer insertion to regulate the critical path and optimize circuit throughput [2603.19856]. In the handshake dialect, buffers are explicit operations placed on handshake channels, and MLIR’s pass infrastructure is used to walk the handshake graph, compute critical paths and slack, and insert buffer operations along values connecting handshake operations [2603.19856]. This suggests that throughput optimization in Dynamatic is not only a matter of high-level scheduling policy but also of explicit microarchitectural regulation of channelized dataflow.

## 4. Control flow, SSA, and memory dependencies

A central transformation in Dynamatic is the conversion of software-style control flow to handshake-style dataflow graphs. In MLIR, SSA $\phi$ semantics are represented through block arguments rather than explicit $\phi$ operations, and successor branches pass actual values to the target block’s arguments [2603.19856]. For HLS, this representation must be converted into multiplexers and control structures in the circuit [2603.19856].

The source material emphasizes that this conversion is not straightforward in MLIR. Block arguments are values with no producer, and branches collect outgoing values that are disconnected from successor blocks; because pattern rewriting typically matches operations as roots, block arguments cannot be used as pattern roots [2603.19856]. Dynamatic therefore performs this conversion at the function level, analyzing entire control-flow regions rather than relying purely on local rewrite rules [2603.19856]. The authors explicitly acknowledge that this solution is “not ideal” because the rewrite must operate on the entire function [2603.19856]. A common misconception is that MLIR’s higher-level SSA structure automatically simplifies control-to-circuit lowering; the Dynamatic experience instead presents block-argument SSA as a source of transformation complexity for hardware generation.

Memory dependence handling is similarly central. Dynamatic uses a custom LLVM pass to identify dependencies between memory accesses, and the resulting information is used later to instantiate memory controllers ensuring program-order constraints [2603.19856]. The broader discussion attributes this dependence analysis to alias analysis and polyhedral analysis at LLVM and/or MLIR level [2603.19856]. Because MLIR does not support edge annotations, Dynamatic assigns each operation a unique `handshake.name` and stores dependency information in attributes such as `handshake.deps = #handshake<deps[["load2", 1]]>` [2603.19856].

The example given for a histogram kernel makes the representational issue concrete: conceptually, a RAW dependency is an edge `store3 -> load2` with distance `1`, but MLIR forces that dependence to be encoded as an operation attribute on `store3` referring to the string name of `load2` [2603.19856]. This is characterized as awkward and fragile, since transformations must preserve operation names and attribute invariants to keep dependencies consistent [2603.19856]. The same lack of edge annotation affects profiling-driven optimization, where control-flow edge information is stored in an external CSV file rather than directly in the IR [2603.19856].

## 5. Relation to h-GSA and critiques of the lowering model

The paper “GSA to HDL: Towards principled generation of dynamically scheduled circuits” situates itself explicitly in the context of Dynamatic and similar dynamic-scheduling HLS tools [2308.11048]. Its critique targets the existing Dynamatic-style lowering flow and identifies three limitations: basic-block-centric control restricts parallelism; the lowering must perform significant static analysis to prevent artificial control-flow dependencies; and the flow lacks a formally specified IR and transformation semantics [2308.11048].

In that account, Dynamatic generates pure dataflow circuits within basic blocks, but requires basic blocks to start sequentially [2308.11048]. This can impose unnecessary sequencing constraints even though the hardware is dynamically scheduled. The paper argues that lowering from a control-centric CDFG requires conservative assumptions, and that not all artificial dependencies can be eliminated safely [2308.11048]. A plausible implication is that some observed limits of Dynamatic are not inherent to handshake-based execution itself, but to the structure of the IR through which dynamic hardware is derived.

The proposed alternative is h-GSA, a hardware-oriented extension of Gated Static Single Assignment (GSA), with a lowering flow from SSA to GSA, then to h-GSA, and finally to dynamically scheduled hardware [2308.11048]. GSA introduces $\mu$ instructions at loop headers, $\gamma$ instructions at conditional exits, and $\eta$ instructions at loop exits, thereby refining classic SSA $\phi$-functions into gates that encapsulate loop and conditional value flow [2308.11048]. The paper defines software and hardware semantics for these primitives and maps them to handshake-compatible hardware components [2308.11048].

The contrast with Dynamatic is explicit. h-GSA is described as a purely dataflow-centric IR with no basic blocks; the schedule depends only on data dependencies gated via $\mu/\gamma/\eta$, not on basic-block “start” events [2308.11048]. By comparison, Dynamatic’s CDFG-based approach remains partly control-centric between basic blocks [2308.11048]. The authors present this as a more principled and formally grounded route to dynamic circuit generation, built on CompCertGSA’s mechanized SSA-to-GSA transformation [2308.11048]. They do not present a complete end-to-end proof of correctness, but they argue that the approach narrows the gap toward a verified translation from software to hardware [2308.11048].

## 6. Scheduling example and implications for parallelism

The most detailed comparison between Dynamatic and h-GSA in the available material is a motivating loop example involving three loops `L0`, `L1`, and `L2` over variables `a` and `b` [2308.11048]. In the example, there is a dependency chain on `a` between `L0` and `L1`, but there is no data dependence between `L0` and the inner loop `L2`, which updates `b` [2308.11048].

According to the paper, Dynamatic’s schedule reflects its basic-block-based lowering discipline: loop bodies must start sequentially, `L2` is nested within `L1` in the control-flow graph, and `L1` is ordered after `L0` [2308.11048]. As a consequence, `L2` starts only after `L1` starts, and `L1` starts only after `L0` has started, in fact after `L0` finishes because of the dependence on `a`; the displayed schedule shows that the second iteration of `L1` starts at cycle 8 [2308.11048]. The paper interprets this as underutilization of potential parallelism.

Under h-GSA, by contrast, there are no basic blocks. The write-after-write dependence on `a` is represented by gating nodes, so `L1` still waits for `L0` to complete as required, but `L2`, having no dependency on `a`, is free to start as soon as its own inputs are ready [2308.11048]. The reported schedule allows `L0` and `L2` to start at cycle 0, while `L1` remains ordered after `L0`; the figure is described as optimal for this example [2308.11048].

This example is qualitative rather than benchmark-oriented. The same paper states that efficient handling of memory and automatic buffering are still to be addressed in the h-GSA prototype and notes that these are features Dynamatic already supports, which would be needed for a fair performance comparison [2308.11048]. The comparison therefore should not be read as a complete empirical refutation of Dynamatic’s effectiveness. Rather, it isolates a specific structural limitation in the current lowering model and uses a schedule construction to illustrate the potential performance improvement from a different abstraction [2308.11048].

## 7. MLIR-based implementation, ecosystem role, and open issues

Dynamatic is developed primarily at EPFL and ETH Zurich and has evolved from a research prototype into a substantial academic tool with an active development and publication ecosystem [2603.19856]. The tool is described as open-source, available at `github.com/EPFL-LAP/dynamatic`, and actively developed, with approximately 30 pull requests per month, a CI/CD pipeline, and a code review process for less experienced developers [2603.19856]. It forms the basis for numerous publications, and many research results on memory systems, buffering, loop transformations, and control-flow optimization have been merged back into the main HLS flow [2603.19856].

The 2026 experience report gives a nuanced assessment of MLIR as the implementation substrate for Dynamatic. MLIR is said to improve over LLVM for HLS by allowing custom dialects with domain-specific operations and types, providing generated support for parsing, printing, verification, and transformations, and enabling multiple abstraction levels within a single infrastructure [2603.19856]. For Dynamatic, this means that a low-level hardware dialect with circuit semantics—the handshake dialect—can coexist with software-oriented dialects such as ControlFlow [2603.19856].

At the same time, the paper identifies persistent problems. Edge annotations are not supported; block-argument SSA complicates control-flow-to-circuit conversion; fragmentation across MLIR repositories makes cross-project interoperation fragile; and the absence of a strong C-to-MLIR frontend means that Dynamatic still relies on LLVM IR for front-end optimizations [2603.19856]. The authors argue that these limitations force fragile workarounds and reintroduce some of the very LLVM rigidity that MLIR was intended to alleviate [2603.19856].

Taken together with the 2023 GSA-to-HDL critique, these issues define the current research frontier around Dynamatic. One trajectory aims to improve the IR and semantics used for dynamic hardware generation, as in h-GSA [2308.11048]. Another aims to improve the compiler substrate and engineering architecture of MLIR-based HLS itself [2603.19856]. The available evidence therefore presents Dynamatic both as a mature implementation of dynamically scheduled handshake-based HLS and as an active locus of methodological debate over how such systems should represent control, dependencies, and correctness.

Source: https://www.emergentmind.com/topics/dynamatic