JuliaHLS Toolchain for Hardware Integration

• JuliaHLS toolchain is a compilation framework that converts Julia code into hardware descriptions (VHDL and SystemVerilog) using MLIR and CIRCT infrastructures.
• It employs both dynamic handshake and static FSM-based scheduling to optimize throughput, resource usage, and latency in hardware synthesis.
• The toolchain bridges high-level scientific programming with vendor-agnostic RTL generation, eliminating the traditional two-language problem in hardware development.

The JuliaHLS toolchain encompasses a series of compiler and synthesis flows that translate Julia source code into hardware descriptions suitable for FPGA and ASIC implementation, notably VHDL and SystemVerilog, with a particular emphasis on leveraging advanced compiler infrastructures such as MLIR and CIRCT. Associated research has focused on unifying hardware/software development, eliminating the "two-language problem," and bridging high-level scientific programming in Julia with vendor-agnostic RTL code generation for efficient accelerator deployment.

1. Core Architecture and Compilation Pipeline

JuliaHLS systems comprise multi-stage compiler toolchains built to process idiomatic Julia code and emit hardware descriptions. Initial prototypes are constructed natively in Julia, utilizing the language's reflective compiler and IR pipeline (Biggs et al., 2022), while more recent instantiations leverage the MLIR and CIRCT ecosystems for higher extensibility and formalism (Short et al., 12 Mar 2025, Short et al., 17 Dec 2025). The pipeline proceeds as follows:

1. Front-end (Parsing, Type Inference):
   • Julia code is parsed and converted to an Abstract Syntax Tree (AST) with user annotatable macros (e.g., @hls) for HLS kernel demarcation.
   • The Julia compiler’s lowering phase generates typed SSA IR, ensuring every variable and operation receives a statically known bit-width and datatype.
   • Type inference and method specialization are enforced so IR is monomorphic, with dispatch resolved at compile time.
2. Intermediate Representation (IR) and Lowering:
   • The Julia IR is systematically lowered to MLIR dialects, starting with a custom "julia" dialect, progressing through standard (std), control flow (scf), MemRef, and optionally Affine dialects (Short et al., 12 Mar 2025, Short et al., 17 Dec 2025).
   • Control structures (loops, branches) are mapped to region-based operations (e.g., scf.for, scf.if) and then raised to affine or dataflow-friendly representations if static analysis is feasible.
3. Hardware-Oriented Passes:
   • IR is further optimized (dead code elimination, constant folding, loop normalization, bufferization). Functions returning arrays are transformed for pass-by-reference, enabling generation of load-store queues (LSQs).
   • Control-Data Flow Graphs (CDFG) are constructed, where IR nodes become hardware "actors" communicating via handshake protocols (Biggs et al., 2022).
4. Scheduling and Resource Mapping:
   • Two principal scheduling regimes are supported:
     • Dynamic Scheduling: MLIR's handshake dialect captures actors firing upon input readiness, with handshake-driven communication enforcing back-pressure and correctness across pipelines. Each operation may instantiate a dedicated hardware resource (one actor per operation) in baseline prototypes.
     • Static Scheduling: The Calyx dialect encodes control as FSMs, supporting initiation interval (II) minimization, pipelining, and time-multiplexing (resource sharing) (Short et al., 17 Dec 2025).
   • Scheduling parameters are formalized:
     • $$II = \max_{(u \rightarrow v)\in D}\left\lceil\frac{\text{delay}(u \rightarrow v)}{\text{dist}(u \rightarrow v)}\right\rceil$$
     • $$\text{Latency} = \sum_{\ell=1}^{N_{\text{stages}}}\text{delay}_\ell$$
5. RTL Generation:
   • Backend passes convert the scheduled IR to target-specific VHDL or SystemVerilog. CIRCT’s SV dialect encapsulates constructs such as modules, always_ff/always_comb blocks, and FSMs, supporting both dynamic (dataflow) and static (FSM) RTL.
   • Vendor neutrality is achieved by avoiding proprietary macros and using parameterizable module interfaces.

2. Language Mapping and Hardware Abstraction

The toolchain capitalizes on Julia's semantics for expressive, hardware-conscious code mapping:

• Type System Translation: Julia integer and floating-point types, booleans, structs, and fixed-shape arrays are injected as bit-vector or bundle types, with array shapes mapped to MemRef descriptors. For example, $M(\mathrm{Int}\{k\}) = \mathrm{bv}\langle k\rangle$ and $$M(\mathrm{Array}\{T,N\}) \rightarrow \mathrm{MemRef}<\ldots, M(T)>$$ (Short et al., 12 Mar 2025).
• Multiple Dispatch and Overloading: Julia's dispatch permits seamless replacement of standard functions and operators with hardware-specialized implementations (e.g., "+" replaced by adder actors under hardware targets). Hardware approximations for mathematical functions are made possible by dispatching to in-Julia definitions or IP cores such as FloPoCo (Biggs et al., 2022).
• Metaprogramming: Macros (e.g., @hls_loop_unroll) manipulate the AST, inject pipeline pragmas, or rewrite high-level Julia constructs (e.g., comprehensions) into pipelined hardware actor chains.

3. Scheduling, Optimization, and Memory Integration

The scheduling layer is central to balancing throughput, resource utilization, and latency:

• Dynamic (Handshake) Scheduling: Each IR operator is an actor firing asynchronously upon input readiness; back-pressure and memory dependencies are managed by handshake channels and load-store queues. This enables overlap of computation and memory latency, crucial for streaming applications with variable downstream availability (Short et al., 17 Dec 2025).
• Static (Calyx) Scheduling: Loops and control flow are compiled into FSMs with fixed II and latency, permitting resource sharing via time-multiplexing. Resource usage models and cost equations are formalized, e.g., $$U_\mathrm{total} = \sum_{t \in \mathrm{Types}} c_t \cdot N_t$$.

AXI4-Stream memory integration is achieved by generating adapters that translate LSQ accesses to standard AXI4-Stream interfaces. Both on-chip RAM (BRAM inference) and off-chip DRAM are supported, with tvalid/tready signals ensuring correct back-pressure propagation and deadlock-free pipeline stalling (Short et al., 17 Dec 2025).

4. Code-to-RTL Example and RTL Characteristics

A canonical transformation from Julia to RTL involves treating idiomatic Julia functions directly, without user-facing pragmas or hardware-specific annotations:

Example Function:

function implicit_else(A, B) result = 0 if A < B result = A + B elseif A > B result = A - B end return result end

The resulting SystemVerilog module comprises states for each control path, comparator and arithmetic actors, and valid/ready logic for handshake and data movement. In static scheduling, the control logic is encoded as an FSM; in dynamic scheduling, ready/valid handshakes are inserted at each actor boundary to implement back-pressure (Short et al., 17 Dec 2025).

This paradigm extends to more complex kernels (e.g., Newton–Raphson, CORDIC, FIR filters), where Julia loops and high-level library calls are mapped to pipelined pipelines or time-multiplexed hardware, parameterized by the targeted FPGA's resource constraints.

5. Performance Metrics and Comparative Evaluation

Resource utilization, throughput, and synthesis results have been reported for both initial and MLIR-based toolchains. Key metrics are summarized as follows (Biggs et al., 2022, Short et al., 12 Mar 2025, Short et al., 17 Dec 2025):

Kernel	LUTs (JuliaHLS)	FFs (JuliaHLS)	DSPs (JuliaHLS)	Throughput (%) vs. Baseline
if_else	511–LUT, 595–FF	6	82.6%
power	555–LUT, 671–FF	3
newton_raphson	4006–LUT, 3456–FF	18
CORDIC (static)	4791–LUT, 5155–FF	9	59.8%

Throughput is commonly 59%–83% that of state-of-the-art C/C++ HLS tools, attributed primarily to lack of full resource sharing and the overhead from lifting high-level constructs without vendor-specific optimizations. Static scheduling and MLIR canonicalization passes significantly reduce memory and arithmetic operation counts in dense kernels such as conv2d_im2col, enabling them to fit on modest FPGAs (Short et al., 17 Dec 2025).

6. Current Limitations and Prospective Enhancements

Prototype implementations exhibit the following constraints:

• No support for dynamic dispatch or unbounded dynamic arrays without full type specialization.
• Memory interfaces are limited in early versions; no integrated block RAM or DRAM support in initial Julia-native implementations (Biggs et al., 2022).
• Recursion and higher-order Julia constructs are currently not synthesizable.
• Floating-point operations are limited by the hardware support of underlying Julia definitions or external IP integration; fixed-point support requires further extension.
• Static scheduling, resource sharing, and automation of memory bufferization are ongoing areas of enhancement. Planned features include tighter polyhedral analysis, integration of Yosys for open-source backends, automated static/dynamic island partitioning, and formal correctness verification via SMT-based frameworks (Short et al., 12 Mar 2025, Short et al., 17 Dec 2025).

A plausible implication is that, as MLIR/CIRCT infrastructure in Julia matures, JuliaHLS flows will provide seamless, high-productivity accelerator generation for scientific and data-driven systems, ultimately collapsing the software/hardware language divide.

7. Significance and Context

The JuliaHLS toolchain exemplifies a major step toward unifying high-level algorithm specification and hardware realization, leveraging advanced compiler structuring, semantic mapping, and modern IR frameworks. By enabling direct, idiomatic translation from Julia to hardware description languages without the need for directives, manual buffer management, or vendor lock-in, it addresses core productivity bottlenecks faced by domain experts in scientific computing and signal processing. These approaches position JuliaHLS as a blueprint for future HLS flows that are both researcher-friendly and extensible to evolving accelerator architectures (Biggs et al., 2022, Short et al., 12 Mar 2025, Short et al., 17 Dec 2025).