TUD – PICEA: Programming and Compiler Environment for MYRTUS Accelerators
| ID: R23 | Licence: GPLv3 |
Owner: TUD |
Contacts: jiahong.bi@tu-dresden.de j.gallegor@upm.es mohammad.cheshfar@unica.it |
| Short Description | An MLIR-based compilation framework that integrates the tools of the Node-Level Optimization and Deployment step of the MYRTUS DPE into a single flow, from machine learning models and DSP kernels down to FPGA, CGRA, RISC-V and CPU targets. |
| Key features | – Interconnects different MLIR dialects and frameworks (filter, base2, dfg, emithls, cgra) in a single compiler. – Automatic optimization on the execution dataflow graph, without user-provided pragmas or templates. – Various outputs for different hardware deployments, generating several implementation variants of the same kernel. – A single command-line entry point (resin) for the complete flow of each backend. |
| Require | – MLIR (Multi-Level Intermediate Representation). – AMD Vitis HLS and Vivado™ Design Suite, for the FPGA paths. – Gurobi ILP Solver. |
| Provide | An MLIR-based compiler that compiles the same kernel to different hardware platforms. |
| Input | – Machine learning models (e.g., PyTorch, TensorFlow, ONNX), imported into the MLIR linalg dialect through the IREE importer. – DSP kernels written through the Python bindings of the DSP front end (filter and base2 dialects). – The deployment specification (TOSCA) from the upper steps of the DPE, indicating which kernels to compile. |
| Output | – FPGA: HLS C++ code with Vitis/Vivado scripts (LAKSA flow), or the network descriptions and actors for MDC runtime-reconfigurable accelerators. – CGRA: configurations for the CGRA and the C driver for the host RISC-V core, through the CGRA compiler. – CPU and RISC-V: executables through LLVM. – A YAML description of the application for design space exploration with Mocasin. |
| User | Developers. |
| Benefits for the user | Automatic optimizations and deployment. |
| Download | Coming soon |
| Position in the MYRTUS DPE | Step 3 – Node-Level Optimization and Deployment. |
| TRL@M0 | 2-3 |
| TRL@M36 | 5-6 |
General description
At the baseline, MLIR did not provide the abstractions required by the DPE. Upstream dialects such as linalg are mature, but they are target-agnostic and sit at a high level of abstraction. They carry no dataflow semantics, no hardware-specific data representations, and nothing that would drive an HLS tool flow. The tool chains for the individual targets, for instance the standard FPGA tool chains and the CGRA compiler tool chains, are standalone tools outside MLIR and cannot be reached from a common IR at all. Both the dialects and the lowering paths from a high-level description down to each of the targeted platforms had to be built, since separate components alone do not make an integrated flow.
Role in the MYRTUS DPE
PICEA is the compilation framework behind the DPE Node-Level Optimization and Deployment step. It takes machine learning models imported into linalg, as well as DSP applications written through the Python bindings, and compiles them down to the hardware platforms in the continuum: FPGA-based accelerators, the RISC-V+CGRA edge node and CPUs. The dataflow graph representation sits at the centre of the framework, and the optimizations applied on it are what carry a high-level description into an efficient implementation on each target. The implementation variants generated for the different targets are provided to the MIRTO Cognitive Engine, which decides at runtime which one to deploy.
MYRTUS Extension/Contribution
This is a new result, consistent with the seamless integration of node-level tools. PICEA builds on the common MLIR framework started in the EVEREST project [2] and integrates the node-level tools of MYRTUS into a single framework. The dfg dialect, originally created in EVEREST (dfg-mlir [1]), has been reimplemented and extended here to the needs of code generation through different backends, for example to operate on tensors and support operations such as convolutions, and it serves as the common dataflow representation from which the individual target paths branch off. Further dialects complete the picture: filter describes DSP filters at a high level, base2, reimplemented from earlier work, provides the fixed-point data types needed on FPGAs and CGRAs, emithls generates HLS C++ with compiler directives, and cgra prepares the code for CGRA deployment.
On the FPGA path, emithls connects the flow from MLIR to Vitis HLS for both the LAKSA and MDC toolchains. For MDC, PICEA can also merge several dataflow networks into one before hardware generation. On the CGRA path, the CGRA compiler toolchain takes over, while the code that is not offloaded is lowered through LLVM to the RISC-V core. Moreover, PICEA exports the dataflow representation as a YAML description for Mocasin, which explores the mapping of the application onto the target node.
Each level of abstraction keeps its own representation, and each target keeps its own tool flow, but they are now connected through well-defined lowering and translation steps instead of being used separately. The interoperability layer removes the manual effort at those boundaries and enables a programming and exploration flow.
Technology Benefits and Innovations
PICEA is built on the idea that the information needed to map a workload onto reconfigurable hardware is already in the IR, and does not have to come from the user. Its dialects each capture one aspect of the problem, and lowering carries the description from the level a domain expert works at down to the level a target toolchain can consume. This addresses a concrete gap. Most MLIR-based HLS frameworks expect their input at the level of affine loops, leaving to the user the effort of lowering the application to that level, while PICEA accepts higher-level linalg descriptions. Existing high-level frameworks either depend on predefined templates, which restricts them to operators somebody has already written a template for, or they hand the optimization decisions back to the user as pragmas and directives, which calls for hardware expertise the domain expert may not have. PICEA derives those decisions by analysis instead, and because each target keeps its own tool flow behind a well-defined lowering step, a new target can be added without disturbing the rest of the framework.
PICEA additionally supports MLIR-level composition of multiple dataflow networks, identifying compatible actor instances for hardware sharing and inserting configuration-controlled switching boxes. Through integration with MDC, this enables multiple functions to execute on a shared FPGA architecture, with configuration-based mode selection within a single bitstream, potentially reducing resource usage compared with separate implementations.
Users
The expected users are application developers working with the DPE who need their workloads to run on the supported reconfigurable hardware platforms, but who are domain experts rather than hardware experts and should not have to optimize the code themselves or know the details of the target platform.
Application Domains
PICEA is not tied to a particular application domain. What it requires of a workload is that the computation can be expressed as a dataflow graph of statically analyzable kernels, and the current implementation covers DSP applications and CNN inference pipelines, the two classes of workloads addressed in the MYRTUS project. Extending it further is a matter of adding dialects and the corresponding transformations, which is exactly what MLIR is designed for. Image processing, scientific kernels and other compute-intensive workloads are therefore within reach without touching what is already in place.
References
- [1] dfg-mlir: github.com/Feliix42/dfg-mlir
- [2] K. F. Friebel, J. A. Ohlmann, J. Castrillon, “Demonstrating a Future for MLIR-native DSL Compilers on a NumPy-like Example”, arXiv:2604.19906, 2026.