Deploying a Quantized ONNX Controller onto a Tiny-TPU

I. Executive Synthesis: Feasibility and Strategic Overview

A. Assessment of Conceptual Viability

The objective of embedding an ONNX model trained within Unity3D’s ML-Agents framework onto a custom Tensor Processing Unit (TPU) architecture, specifically the open-source Tiny-TPU v2, defined by Chisel and synthesized on a low-cost Field-Programmable Gate Array (FPGA), is conceptually sound and technologically viable. This approach represents an advanced convergence of deep reinforcement learning (DRL) for critical systems, such as drone control, with the efficient, customized execution path offered by application-specific integrated circuit (ASIC) design principles implemented on an FPGA. The resulting system moves beyond traditional fixed-control laws like the Proportional-Integral-Derivative (PID) controller, leveraging the learned policies of the ONNX model for high-performance, deterministic control. Success hinges on mastering the intermediate open-source compiler toolchain.

B. High-Level Challenges and Mitigation Strategies

While feasible, the project presents three primary technical hurdles, each requiring targeted mitigation strategies rooted in advanced compiler and hardware-software co-design practices.

The first challenge is Numerical Conversion. Reinforcement Learning (RL) models are typically trained using 32-bit floating-point (FP32) precision and often employ complex, computationally expensive activation functions like hyperbolic tangent ($\text{Tanh}$) or $\text{Sigmoid}$.¹ The Tiny-TPU architecture, like most dedicated neural accelerators, is optimized for low-precision fixed-point arithmetic (e.g., INT8 or INT16).³ This transition requires mandatory Quantization-Aware Training (QAT) to ensure the control policy retains its efficacy after conversion. Furthermore, computational efficiency dictates replacing mathematically complex non-linear activations with simple, hardware-friendly alternatives, such as Leaky ReLU.⁴

The second major hurdle is the Toolchain Semantic Gap. Translating the high-level graph semantics of the ONNX representation into the structural, bit-accurate hardware constructs necessary for the Chisel/FIRRTL design flow demands sophisticated compilation infrastructure. Standard ONNX-to-MLIR conversion tools will produce generic tensor operations.⁶ However, for the deployment to realize the acceleration benefits of the Tiny-TPU, a highly customized MLIR lowering pipeline must be developed.⁸ This custom pipeline is required to perform fixed-point lowering and map these operations directly onto the specialized Matrix Multiply Unit (MXU) of the Tiny-TPU, recognizing its specific data types, tile sizes, and fixed-point representation. This necessitates the use of MLIR’s extensible framework, particularly via projects like CIRCT (Circuit IR Compilers and Tools), to manage the progressive transformation from high-level software abstraction to low-level hardware Intermediate Representation (IR).⁹

The final challenge involves Resource Constraint. The project requires ensuring that the substantial Tiny-TPU v2 core, which includes approximately 9,192 Look-Up Tables (LUTs) and 68 Digital Signal Processing (DSP) blocks ¹¹, fits comfortably onto the low-cost Lattice ECP5-25F FPGA found on the Colorlight 5A-75E board.¹² Detailed resource analysis confirms that the ECP5-25F offers approximately 24,000 LUTs and 156 DSP slices ¹⁴, making the core component fit highly feasible, provided optimization targets the dedicated DSP blocks. This validates the “low cost” feasibility criterion for the chosen hardware platform.

II. Deep Dive: ML Model Constraints and Optimization for Fixed-Point Hardware

A. Analysis of Unity ML-Agents Architectures (PPO/SAC)

Unity ML-Agents is an open-source toolkit leveraging PyTorch implementations of state-of-the-art DRL algorithms, enabling game and simulation environments to serve as training grounds for intelligent agents.¹⁵ For drone control, algorithms like Proximal Policy Optimization (PPO) or Soft Actor-Critic (SAC) are commonly used to learn stable flight and trajectory management, replacing traditional control systems.¹⁶

The exported policy model is packaged in the ONNX format, which is typically designed for generic inference engines like Unity’s Barracuda. The resulting network architecture often features dense layers corresponding to MatMul or Gemm operators, as well as necessary structural operations like Reshape, Flatten, and various activations.² A significant structural constraint arises if the policy utilizes recurrent logic, such as the LSTM operator. If present, the hardware implementation must handle complex sequential state management and associated memory access patterns.¹ The memory and logic required to manage the recurrent state variables would dramatically increase the utilization of logic blocks and embedded RAM (Block RAMs, or BRAMs) on the ECP5 FPGA, potentially complicating the attainment of the target 100 MHz operating frequency.¹¹

B. Mandatory Hardware Preparation: Model Quantization (INT16 Fixed-Point)

To ensure the deterministic, low-latency execution required for real-time drone control, the ML-Agents policy must be converted from its native FP32 domain to a low-bit fixed-point representation compatible with the Tiny-TPU MXU. Given the inherent instability risks associated with RL policies (e.g., drone stabilization policies are highly sensitive to numerical error ¹⁶), an INT16 precision is recommended over INT8.

The quantization process requires the calculation of per-layer scale and zero-point parameters.³ The scale defines the step size between quantized levels, mapping the floating-point range to integers, while the zero-point is an integer offset.¹⁷ The zero-point’s definition is crucial; it must ensure that the floating-point zero value is exactly representable in the quantized space, which is essential for preserving the integrity of zero padding used in matrix operations and convolutional layers.³ This calibration data must be extracted and subsequently utilized to guide the MLIR compilation process. The most robust implementation strategy involves performing Quantization-Aware Training (QAT) within the PyTorch-based ML-Agents framework. QAT adapts the policy weights during training to the numerical constraints of the target fixed-point system, thereby minimizing the policy performance degradation often observed when conversion is performed post-training.

The critical need for a low-latency control loop means the data path design must maximize speed by minimizing external memory latency. The Tiny-TPU v2 benchmark suggests utilizing 49 BRAMs.¹¹ These embedded memory resources must efficiently store the static quantized weights and manage the intermediate activation states—a particularly challenging task for sequential or recurrent policies. High-speed RL inference is fundamentally bandwidth-bound, meaning the Chisel/FIRRTL design must orchestrate data streaming to the MXU to minimize pipeline stalls and reliably achieve the expected 100 MHz frequency.¹¹

Furthermore, the scale and zero-point values, once determined through calibration ³, are static constants that define the fixed-point arithmetic (effectively shifts and offsets). The custom compiler passes developed in the MLIR flow must treat these parameters as constants embedded directly into the FIRRTL IR. If the compiler were to treat scales and zero-points as dynamic, runtime variables, they would necessitate the implementation of complex, general-purpose multiplication hardware. By embedding them as constants, the Yosys synthesis suite can significantly optimize these operations into efficient, fixed-shift and addition circuits, conserving valuable LUT resources on the ECP5 device.

C. Addressing Non-Linearities: Activation Function Adaptation

DRL policies commonly employ $\text{Tanh}$ or $\text{Sigmoid}$ activation functions.¹ Hardware implementation of these functions on an FPGA is resource-intensive, requiring complex circuits such as piecewise linear (PWL) approximations ¹⁸, polynomial expansions, or CORDIC (Coordinate Rotation Digital Computer) algorithms.⁵ Polynomial approximations, while accurate, consume many resources, including DSP slices.⁵ Since the dedicated DSP slices are already largely allocated to the Tiny-TPU MXU for matrix multiplication ¹¹, using these functions strains the ECP5 resource budget.

To meet the “low cost” constraint and ensure the design fits within the ECP5-25F resource envelope, the most practical solution is to retrain the policy using hardware-friendly activation functions such as Leaky ReLU or PReLU.⁴ These functions map to simple comparison and multiplexing logic in hardware, requiring minimal LUTs and virtually no dedicated DSP resources. This strategy maximizes the hardware resource availability for the high-performance Matrix Multiply Unit (MXU) core, which is the primary source of acceleration.

III. The Tiny-TPU v2 Architecture and Hardware Constraints

A. Overview of Tiny-TPU v2 Design Philosophy

The Tiny-TPU v2 is an open-source hardware accelerator design realized using Chisel, a Scala-based hardware construction language that compiles to the FIRRTL (Flexible Intermediate Representation for RTL) IR.²¹ Chisel is ideal for developing highly parameterized and scalable hardware designs. The architectural core of the Tiny-TPU is the Matrix Multiply Unit (MXU), explicitly designed for executing large volumes of parallel fixed-point multiply-accumulate (MAC) operations. This structure is perfectly suited to accelerate the dense matrix multiplication (MatMul/Gemm) operations that dominate the computational cost of the DRL policy network derived from ML-Agents.²

B. Detailed Resource Budget Analysis: Mapping Tiny-TPU Primitives to FPGA Fabric

The feasibility of the “home garage” approach relies on utilizing the Colorlight 5A-75E board, which incorporates the Lattice ECP5-25F. Analysis of the resource requirements for the Tiny-TPU v2 core against the capacity of this cost-effective FPGA confirms viability.

Table 1: Tiny-TPU v2 Resource Demand vs. Low-Cost ECP5 Capacity

Resource Metric	Tiny-TPU v2 Benchmark (Need)	Lattice ECP5-25F (Capacity)	Utilization	Viability Assessment
Logic Elements (LUTs)	9,192	$\sim$24,000	$\sim$38.3%	High Confidence Fit
Dedicated DSP Slices (18×18 equiv.)	68	$\sim$156	$\sim$43.6%	Highly Feasible
Embedded Block RAM (Blocks)	49	Sufficient (Max 3.7 Mbits family capacity)	Low	Feasible
Target Frequency	100 MHz	Achievable with Open-Source Flow	–	Must be verified post P&R

The resource analysis demonstrates that the core Tiny-TPU logic requires only about 38% of the available LUTs and 44% of the dedicated DSP blocks on the ECP5-25F.¹¹ This low utilization confirms ample remaining resources for the necessary I/O, control, and state machine logic, validating the viability of using this low-cost hardware platform.

A central requirement for achieving the performance indicated in the benchmarks (100 MHz target frequency ¹¹) is the efficient use of dedicated hardware. The ECP5 family includes specialized DSP slices optimized for 18×18 multiplication operations.¹⁴ The Chisel implementation, via the FIRRTL compiler, must be structured to explicitly infer and utilize these dedicated resources for the Tiny-TPU’s 68 DSPs.¹¹ If the compilation process fails to correctly map the MatMul operations to these blocks, the design would be synthesized purely from general-purpose LUTs, resulting in an overrun of the logic budget and an inability to achieve timing closure at the required operating frequency, rendering the accelerator unsuitable for real-time control.

C. I/O and Control Plane Integration on the ECP5-25F

The choice of the Colorlight 5A-75E board is strategically sound for a “home garage” project, providing a highly capable Lattice ECP5 FPGA (LFE5U-25F) at an extremely low cost (typically $13 to $25, based on current market availability).¹³ This commercial reuse of consumer hardware leverages economies of scale to drastically reduce the project’s hardware expense compared to dedicated development kits. The board is fully supported by the open-source Yosys/Nextpnr flow via Project Trellis.²²

The remaining 60% of the FPGA logic must be used to implement the Control Plane and I/O logic required for the drone system:

1. Drone Interface Logic: Implementing Pulse Width Modulation (PWM) generation circuits to control the electronic speed controllers (ESCs) for the drone motors, and potential interfaces (SPI or $\text{I}^2\text{C}$) for communication with external sensors such as Inertial Measurement Units (IMUs) or GPS modules.
2. Host Communication: Logic for JTAG/UART to enable configuration loading and debugging with a host PC.
3. Tiny-TPU Control Logic: This is the sophisticated state machine responsible for sequencing the layers of the ONNX computation graph. It manages the loading of weights from BRAMs, initiating the MXU operation, and writing the intermediate activation states back to memory iteratively.

IV. The Open-Source Compilation Toolchain: ONNX to RTL

A. Layer 1: Front-end Translation (ONNX to MLIR)

The compiler process begins by ingesting the quantized ONNX model. Tools such as iree-import-onnx ⁶ or ONNX-MLIR ⁷ translate the abstract computational graph into the Multi-Level Intermediate Representation (MLIR) framework. This initial step converts the model into high-level MLIR dialects, typically utilizing Tensor and Linalg dialects, which represent array and linear algebra operations.²⁴

MLIR’s hierarchical, multi-level structure is essential because it enables the progressive lowering of the high-level computational concepts toward the specific hardware target.²⁵ It systematically applies transformations based on constraints unique to the Tiny-TPU architecture, such as fixed-point precision, bit-width constraints, and the dimensions of the MXU tiling.

B. Layer 2: Custom Lowering and Hardware Semantics (Fixed-Point MLIR Passes)

The most complex phase of this project is the development of custom compiler passes within MLIR. Since standard MLIR dialects primarily handle floating-point types, an intermediate custom dialect is necessary to formally define and track the explicit fixed-point precision, including the scale and zero-point parameters, throughout the entire compilation flow.⁸

The custom MLIR pass pipeline must execute the following critical transformations:

1. Quantization Injection Pass: This pass reads the calibration data (scales and zero-points) generated during model optimization and injects these parameters as literal constants into the MLIR operations. This action ensures that the fixed-point arithmetic (defined by shift and offset) is fully resolved at compile time.
2. Tiny-TPU Tiling Pass: This optimization pass transforms large matrix multiplication operations (e.g., linalg.matmul or tensor.matmul) by tiling them to match the exact physical dimensions of the Tiny-TPU MXU (e.g., $N \times M$ matrix tiles). This optimization is vital for memory access pattern efficiency and parallel execution on the hardware.
3. Fixed-Point Lowering Pass: This critical pass replaces abstract fixed-point operations with explicit, bit-accurate arithmetic. It converts standard tensor operations into sequences of shift, add, and multiply operations using the custom fixed-point data types.
4. Hardware Primitive Mapping: Finally, the fully lowered, tiled, fixed-point operations are converted into calls to specialized external primitives that correspond directly to the input/output interfaces of the Chisel modules (e.g., a call to tpu.mxu_compute).

The ability of MLIR to rapidly apply various optimization strategies, such as different loop unrolling or tiling heuristics, provides significant value for this project. This flexibility facilitates rapid experimentation, dramatically accelerating the complex hardware-software co-design cycle, which is essential for projects undertaken in a resource-limited environment.²⁶

C. Layer 3: Hardware Generation (MLIR/CIRCT to FIRRTL/Chisel)

Once the MLIR graph has been fully lowered, transformed into fixed-point arithmetic, and mapped onto the Tiny-TPU architectural primitives, it enters the hardware generation phase. The CIRCT project provides the necessary MLIR dialect (circt::firrtl) to formally define hardware concepts and generate valid FIRRTL.¹⁰ CIRCT is designed to be a replacement for the older Scala FIRRTL Compiler (SFC).²¹

The MLIR graph is translated via CIRCT into the high-level FIRRTL IR. The Tiny-TPU v2 design, originally defined in Chisel, must be structured to integrate this generated FIRRTL as the core computation graph, defining the sequencing and data flow for the neural network. FIRRTL, which supports complex hardware types like !firrtl.class and !firrtl.uint<W> ²⁷, is then compiled into low-level Verilog RTL using either the Scala FIRRTL Compiler or the MLIR FIRRTL Compiler.²¹

D. Layer 4: Physical Implementation (Yosys, Nextpnr, and Open-Source FPGA Flow)

The final stage involves physical placement and routing of the custom RTL onto the target FPGA. The explicit support for Lattice ECP5 devices by the completely Free and Open Source Software (FOSS) toolchain—Yosys and Nextpnr, supported by Project Trellis—is the foundational enabler for the “low cost from home garage environment” requirement.²³ This established flow eliminates dependence on proprietary vendor CAD tools.

1. RTL Synthesis (Yosys): The generated Verilog RTL (containing the Tiny-TPU core and the drone I/O logic) is synthesized by the Yosys Open Synthesis Suite into a technology-mapped netlist.²³
2. Place and Route (Nextpnr): The nextpnr-ecp5 tool utilizes the device database from Project Trellis to perform timing-driven placement and routing, physically mapping the logic elements and interconnects onto the LFE5U-25F fabric.²³ The resource analysis confirms the physical mapping feasibility.
3. Deployment: The final configuration bitstream (.bit file) is then uploaded to the Colorlight 5A-75E board using the openFPGALoader utility.²⁸

V. Detailed Technical Roadmap and Best Practices (Implementation Guide)

The successful completion of this project requires adherence to a structured, multi-phase technical roadmap.

A. Phase 1: Model Optimization and Quantization Calibration

The initial step is to optimize the ML-Agents DRL policy specifically for fixed-point hardware:

• Tooling: Unity ML-Agents (PyTorch), ONNX Runtime, Custom Python QAT Scripts.
• Best Practice: Prioritize reliability and low resource consumption. Retrain the PPO or SAC policy using Leaky ReLU or PReLU activations instead of $\text{Tanh}/\text{Sigmoid}$ to maximize hardware efficiency. Perform Quantization-Aware Training (QAT) to the recommended asymmetric INT16 fixed-point format, utilizing an extensive dataset of drone flight samples for accurate calibration of the necessary scale and zero-point parameters.³

B. Phase 2: Compiler Flow Customization and Tiny-TPU IR Definition

This phase addresses the complex compiler gap. The design must be structured to explicitly leverage the dedicated hardware of the Tiny-TPU.

• Tooling: Chisel, Scala, LLVM/MLIR, CIRCT.
• Steps:
  • Define the Chisel interfaces for the Tiny-TPU MXU module, ensuring ports for input weights, activations, and configuration registers are clearly specified.
  • Develop the custom MLIR fixed-point dialect and the critical lowering passes. These passes must utilize the extracted INT16 scale and zero-point values, defining explicit bit-manipulation logic rather than abstract arithmetic.
  • Verify the MLIR lowering process through CIRCT, confirming that the generated FIRRTL IR correctly represents the fixed-point pipeline and preserves custom hardware types.²⁷

C. Phase 3: Integration and Verification

Prior to physical deployment, the functional correctness of the hardware description must be rigorously verified.

• Tooling: Verilator (RTL Simulation), C++/Python test harnesses.
• Procedure: A detailed, fixed-point test bench must be constructed. This test bench drives the generated Verilog RTL (which includes the Tiny-TPU core) with the same quantized input tensors used during the ML-Agents simulation. The output control signals (e.g., motor thrust commands) produced by the RTL simulation are then compared cycle-accurately against a reference fixed-point calculation, ensuring functional equivalence and detecting any numerical divergence introduced by the lowering process.

D. Phase 4: Physical Deployment and Timing Closure

The final phase involves mapping the optimized RTL to the ECP5 device.

• Tooling: Yosys, Nextpnr-ecp5, Project Trellis, openFPGALoader.
• Critical Step: The synthesis flow must be configured to prioritize the use of the ECP5’s dedicated DSP blocks for the Tiny-TPU’s MXU MAC operations. The design relies on the DSP blocks for high-speed computation, and if the synthesis fails to infer these blocks correctly, the device will fail timing analysis at the critical 100 MHz target frequency.¹¹
• Deployment: After successful Place and Route, the final .config file is generated by nextpnr-ecp5 ²⁹, and the resulting bitstream is written to the Colorlight 5A-75E using openFPGALoader.²⁸

VI. Conclusion and Strategic Recommendations

A. Final Assessment and Performance Outlook

The analysis confirms the technical viability of deploying a Unity ML-Agents ONNX drone control policy onto a Tiny-TPU v2 core synthesized on a low-cost ECP5 FPGA. By adopting a fully open-source hardware flow (Chisel, MLIR, CIRCT, Yosys, Nextpnr) and utilizing optimized hardware (Colorlight 5A-75E), this ambitious project can be achieved within the specified constraints.

The resultant system is projected to achieve high-speed inference, delivering control loop latency in the microsecond range. This deterministic, highly predictable latency is a significant advantage over typical CPU or GPU-based embedded inference platforms and is critical for stable, real-time drone control, surpassing the performance determinism of standard software-based PID or DRL controllers.

B. Recommendation for Hardware and Compiler Scalability

For projects requiring larger neural networks or the complexity introduced by Long Short-Term Memory ($\text{LSTM}$) units, two strategic considerations are necessary:

1. Scaling Hardware Capacity: While the ECP5-25F is suitable for many drone control policies, larger, more complex models may exceed its resource limit. The project should consider migrating to larger ECP5 variants, such as those offering up to 84,000 LUTs and 160 DSP slices.¹⁴ For future accelerator designs targeting massive LLMs or recommendation systems, advanced features like sparsity acceleration, which are present in proprietary cloud TPUs, would need to be incorporated into the custom accelerator architecture.³⁰
2. Standardizing I/O and Control Interfaces: The coupling of the Tiny-TPU core to the specific I/O pins of the Colorlight board introduces design fragility. Future work should focus on adopting standardized hardware definition principles. Utilizing concepts similar to the ONNX GO HW approach, which proposes an experimental domain within ONNX to define SoC primitives such as GPIO, DMA, ADC/DAC, and timers ³¹, would improve hardware portability and interoperability across different FPGA and embedded system platforms (e.g., Jetson or Zynq devices).
3. Community Contribution: Given the advanced nature of the required MLIR compiler work—specifically the fixed-point lowering and hardware primitive mapping—contributing these custom passes and accelerator definitions back to the open-source community, particularly to CIRCT, would ensure longevity, broader adoption, and continuous refinement of the tooling.⁹ This collaboration aligns with the spirit of the open-source tools that enable this low-cost hardware development.