Dynamatic: Dynamic HLS Compiler

• Dynamatic is an open-source high-level synthesis tool that transforms C programs into dynamically scheduled, elastic dataflow circuits using handshake protocols.
• It employs a multi-stage pipeline—from Clang and LLVM through MLIR dialects (ControlFlow and handshake) to RTL—to optimize hardware performance for irregular control flows.
• The tool enhances performance by enabling operations to fire based on local data availability, achieving up to 2.5× improved execution time and 4× throughput over static scheduling.

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 (Xu et al., 20 Mar 2026). 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 (Rajagopal et al., 2023). 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 (Xu et al., 20 Mar 2026).

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 (Rajagopal et al., 2023). 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 (Xu et al., 20 Mar 2026).

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 (Xu et al., 20 Mar 2026). 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 (Rajagopal et al., 2023).

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 (Xu et al., 20 Mar 2026). 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 (Rajagopal et al., 2023). 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 (Xu et al., 20 Mar 2026). The reported pipeline begins with Clang, which parses C and produces LLVM IR; LLVM passes then perform standard optimizations (Xu et al., 20 Mar 2026). 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 (Xu et al., 20 Mar 2026).

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 (Xu et al., 20 Mar 2026). 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 (Xu et al., 20 Mar 2026). 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 (Xu et al., 20 Mar 2026).

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 (Rajagopal et al., 2023). 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 (Xu et al., 20 Mar 2026). This is the basis for the claim that the tool has a performance advantage whenever the control flow or memory access pattern is unpredictable (Xu et al., 20 Mar 2026). 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 (Rajagopal et al., 2023).

The trade-off is also explicit. Dynamatically scheduled circuits trade off area utilisation for increased dynamism and throughput (Rajagopal et al., 2023). 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 (Xu et al., 20 Mar 2026). 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 (Xu et al., 20 Mar 2026). 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 (Xu et al., 20 Mar 2026). 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 (Xu et al., 20 Mar 2026). For HLS, this representation must be converted into multiplexers and control structures in the circuit (Xu et al., 20 Mar 2026).

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 (Xu et al., 20 Mar 2026). Dynamatic therefore performs this conversion at the function level, analyzing entire control-flow regions rather than relying purely on local rewrite rules (Xu et al., 20 Mar 2026). The authors explicitly acknowledge that this solution is “not ideal” because the rewrite must operate on the entire function (Xu et al., 20 Mar 2026). 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 (Xu et al., 20 Mar 2026). The broader discussion attributes this dependence analysis to alias analysis and polyhedral analysis at LLVM and/or MLIR level (Xu et al., 20 Mar 2026). 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]]> (Xu et al., 20 Mar 2026).

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 (Xu et al., 20 Mar 2026). This is characterized as awkward and fragile, since transformations must preserve operation names and attribute invariants to keep dependencies consistent (Xu et al., 20 Mar 2026). 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 (Xu et al., 20 Mar 2026).

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 (Rajagopal et al., 2023). 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 (Rajagopal et al., 2023).

In that account, Dynamatic generates pure dataflow circuits within basic blocks, but requires basic blocks to start sequentially (Rajagopal et al., 2023). 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 (Rajagopal et al., 2023). 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 (Rajagopal et al., 2023). 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 (Rajagopal et al., 2023). The paper defines software and hardware semantics for these primitives and maps them to handshake-compatible hardware components (Rajagopal et al., 2023).

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 $2.5\times$0, not on basic-block “start” events (Rajagopal et al., 2023). By comparison, Dynamatic’s CDFG-based approach remains partly control-centric between basic blocks (Rajagopal et al., 2023). 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 (Rajagopal et al., 2023). 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 (Rajagopal et al., 2023).

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 (Rajagopal et al., 2023). 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 (Rajagopal et al., 2023).

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 (Rajagopal et al., 2023). 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 (Rajagopal et al., 2023). 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 (Rajagopal et al., 2023). 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 (Rajagopal et al., 2023).

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 (Rajagopal et al., 2023). 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 (Rajagopal et al., 2023).

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 (Xu et al., 20 Mar 2026). 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 (Xu et al., 20 Mar 2026). 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 (Xu et al., 20 Mar 2026).

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 (Xu et al., 20 Mar 2026). 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 (Xu et al., 20 Mar 2026).

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 (Xu et al., 20 Mar 2026). The authors argue that these limitations force fragile workarounds and reintroduce some of the very LLVM rigidity that MLIR was intended to alleviate (Xu et al., 20 Mar 2026).

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 (Rajagopal et al., 2023). Another aims to improve the compiler substrate and engineering architecture of MLIR-based HLS itself (Xu et al., 20 Mar 2026). 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.