# A Disciplined Approach to Neural Network Framework Selection for On-board Critical Applications

Christophe Marabotto, Mariem Turki, Eric Jenn

► To cite this version:

Christophe Marabotto, Mariem Turki, Eric Jenn. A Disciplined Approach to Neural Network Framework Selection for On-board Critical Applications. 13th European Congress of Embedded Real Time Systems (ERTS), Feb 2026, Toulouse, France. 10.82331/ERTS.2026.49. hal-05513859

HAL Id: hal-05513859

https://hal.science/hal-05513859v1

Submitted on 16 Feb 2026

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
# A Disciplined Approach to Neural Network Framework Selection for On-board Critical Applications

Christophe Marabotto<fnref n="1" />, Mariem Turki², and Eric Jenn³

¹,²,³ IRT Saint Exupery, Toulouse, France

firstname.lastname@irt-saintexupery.com

## ABSTRACT

Transforming Artificial Neural Networks (ANNs) into efficient executables on resource-constrained embedded platforms is an essential step for AI model deployment. This process relies on deployment toolchains, whose growing number and features raise a significant challenge for developers. Differences among these toolchains can have critical impacts on final system performance and development cost. To address this, our work introduces a disciplined approach comprising key evaluation criteria for systematically assessing and comparing neural network deployment frameworks.

We illustrate our method through an extensive comparative analysis of leading toolchains targeting diverse hardware architectures, including FPGAs, GPUs, and CPUs / MCUs. The insights and practical guidelines derived from this study are intended to facilitate navigation in the complex toolchain landscape and help to take rational design and implementation decisions.

## 1. INTRODUCTION

Unlike traditional approaches where each function is handled by a specific algorithm often coded manually, a deep learning model is generally processed by a toolchain that produces its corresponding executable artifact. This artifact can be a section of source code to be compiled, a native binary to be executed on a CPU, GPU, TPU, etc., or a data structure to be interpreted, possibly using precompiled kernels.

This toolchain plays a role similar to a compiler in the sense that it transforms a model described according to some proprietary or standard format (e.g., ONNX<fnref n="1" />) into a lower representation ready to be executed or interpreted. However, unlike the choice of a compiler which generally boils down to choosing a variant of `gcc` or `llvm` fitted with the appropriate backend, the domain of ML is not yet consolidated and the set of ML toolchains is large and ever increasing. Additionally, the differences between these frameworks may have a significant impact on many aspects of the development process, and be difficult to estimate in advance. In one word, toolchains abound; making the right choice among them is a complex task.

Therefore, in this paper, we propose to facilitate and ratio-

nalize this choice thanks to (i) a set of relevant criteria based on our experience in the application of ML in the aerospace domain, (ii) a set of relevant, measurable attributes for each criterion, (iii) the evaluation of those criteria on a variety of tool chains used during the development of aerospace embedded systems, and (iv) insights gained from internal on-board AI projects, specifically addressing the technical constraints and trade-offs involved in choosing appropriate neural network frameworks.

## 2. RELATED WORK

The safety of AI models in mission-critical systems remains an open research challenge, drawing significant attention from both industry and academia. Regulatory frameworks, such as EASA [17] for AI applications in aeronautics, ECSS-E-HB-40-02A [15] for AI in space systems, and the AI Act [16] for high-risk AI systems, are progressively shaping the standards for the development, validation, and testing of these new software components. In addition, most of these systems face considerable challenges in terms of on-board computational capabilities, timeliness, energy consumption, heat dissipation, or tolerance to radiation effects.

Performance and efficiency of neural networks in on-board applications are heavily influenced by the underlying hardware. Leveraging hardware acceleration is often essential to meet the computational demands of deep learning models within the constraints of power consumption and real-time processing. Several types of hardware accelerators are commonly considered for on-board deployment, including Graphics Processing Units (GPUs), Field-Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), and Vision Processing Units (VPUs), as well as increasingly capable Central Processing Units (CPUs) and microcontrollers (MCUs).

**FPGA.** For space applications (and other domains requiring high reliability and low latency) leveraging FPGAs, tools such as Vivado/Vitis HLS [3], VHDL, FINN [50], and VTR (Vilog to Routing) [35] are frequently cited, although a majority of papers do not detail their deployment methods [5]. Other studies, like [7], have performed in-depth analyses of specific tools like hls4ml [18] and Vitis AI [27], comparing operator support, usability, and hardware implementation.

**GPUs and Single-Board Computers (SBCs).** Several packages have been specifically tailored for exporting models for SBC deployment, including: ExecuTorch (rebranded PyTorch

<footnote>Christophe Marabotto et al. This is an open-access article distributed under the terms of the Creative Commons Attribution 4.0 License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original author and source are credited.</footnote>

<footnote n="1">¹https://onnx.ai/</footnote>
Mobile) [41], OpenVINO [23], ONNX Runtime [11], Teno-
sorRT [37], and LiteRT (rebranded TensorFlow Lite) [21].
This review [24] provides a comparative analysis of these
AI frameworks for SBC deployment, focusing on compatibil-
ity, performance (latency, throughput), deployment ease, spe-
cific hardware optimization (e.g., leveraging CUDA or Neon
cores), and community and industry adoption. Benchmarks
such as MLPerf [33] are often used to evaluate model perfor-
mance across a variety of hardware platforms.

**CPUs and MCUs.** For highly resource-constrained devices like microcontrollers, ultra-lightweight frameworks, also known as TinyML frameworks, are necessary. TensorFlow Lite for Microcontrollers (TFLM) [10] is a predominant solution, but others like MicroTVM [8], STM32Cube.AI [46], u-Tensor [6], Edge Impulse [14], e-AI [44], HailoRT [22], and CMSIS-NN [29] are gaining attention. Studies [38] compare these frameworks based on criteria such as memory usage, arithmetic support, and learning curve.

**ASICs, VPUs, and Specialized Accelerators.** Deployment on ASICs (e.g., Google Edge TPU, Intel Movidius VPU) often also involves the use of vendor-specific toolchains and compilers (e.g., Edge TPU Compiler, OpenVINO [23] for Intel VPUs). While these tools are proprietary, higher-level frameworks like LiteRT [21] or ONNX Runtime [11] can serve as a common interface before target-specific compilation. Studies in this area often focus on the performance and power efficiency gains offered by these dedicated accelerators compared to more generic solutions.

Beyond platform-specific inventories, some research proposes more general frameworks to guide selection. In this study [13], authors propose a generic approach covering various factors like cost, schedule, and intellectual property, illustrated through several use cases. Another interesting work worth mentioning is [12] where the authors compare different TinyML deployment chains based on supported high-level frameworks, hardware matrix, and used weights data type. Other works focus on crucial aspects influencing framework choice like interoperability and model conversion [25] or optimization techniques [31]. DeepGreen, under the Eclipse AIDGE platform, is a notable framework that provides a set of open-source tools to reduce model computational complexity and memory consumption across all hardware families, facilitating the optimized deployment of deep neural networks onto constrained embedded systems [48].

Finally, none of these studies provide a definitive answer to the following question: How to select an appropriate AI framework for on-board deployment in critical systems considering the large spectrum of technical and operational constraints? The present paper aims to fill a gap by proposing an approach dedicated to the selection of AI deployment frameworks for critical applications. Our approach seeks to integrate domain and use-case-related constraints to provide engineers with a rigorous and reproducible decision-making process, extending beyond mere inventories or ad-hoc comparative analyses.

**3. DISCIPLINED APPROACH**

The selection of an implementation and deployment toolchain
for neural networks in on-board applications is a critical de-

cision, directly impacting performance, power efficiency, and
development timelines. It is also a *complex decision* due to the
large and ever-increasing number of those toolchains. In this
section, we propose a set of criteria to support this selection
process. Those criteria, introduced and evaluated on several
frameworks, targeting FPGAs, GPUs, and CPUs/MCUs hard-
ware platforms.

**3.1. Selection Procedure**

Evaluating a framework means first filtering out non-pertinent criteria and sorting the remaining ones according to their relative importance for the context and system at stake. In practice, the relative importance – or weight – of the criteria depends on the industrial constraints, system requirements, regulations, etc.

Each criteria calls for the evaluation of one or several attributes. Values of these attributes may be readily available (e.g., the fact that the toolchain is open source or not) or may require a specific measure (e.g., an end-to-end latency evaluation) and, consequently, a dedicated measurement environment. Ideally, criteria with identical weights must be sorted according to the increasing effort required to evaluate their respective attributes.

It is important to distinguish, prior to any evaluation, between end-to-end frameworks, which include multiple components enabling sparsity optimization, quantization, compilation, and full model deployment, and runtime-only frameworks, which are limited to executing a model on the target from an already optimized user-provided model. Our study primarily focuses on the comparison of end-to-end frameworks, for which the entire deployment chain can be evaluated, while also opening a discussion on the differences observed among various runtime-only frameworks, particularly in terms of flexibility, traceability, and robustness of deployment tools.

Thus, the proposed disciplined process for execution providers
or runtime selection extends upon the following steps:

1. Defining system requirements, including industrial con-
straints, that may directly or indirectly impacted by the
choice of a AI/ML framework

2. Selecting and weighting evaluation criteria according to (i) their impact on the satisfaction of the system requirements and (ii) the effort required to evaluate them. See Section 4 for concrete examples.

**3.2. Criteria Definition**

By definition, a relevant criterion is a quantity, or attribute,
pertaining to an AI/ML framework impacting positively or
negatively the overall cost of system development and main-
tenance. A strict and rigorous application of this definition
would require first cost models to be established (which are
highly company-specific) and refined down to the point it may
show, possibly in an analytical manner, some characteristics
of the AI/ML framework. This is out of the scope of the cur-
rent study, and we instead propose a selection of criteria for
which impact on cost can be assessed in a generic way.

Our evaluation criteria are organized in the following main
categories:
**Life-cycle and Sustainability.** Focused on the long-term viability and activity of the toolchain on Github. This includes:

* the interest and adoption by the developer community (measured by the number of stars),

* the size and diversity of the development community (measured by the number of contributors),

* maintainability (indicated by the number of commits in the last 12 months),

* freshness or abandon (measured by a recency score based on the date of the last push), and

* maturity / stability / structured development cycle (estimated by the number of official versions published).

**Functional Capabilities.** Features provided by the toolchain. This includes:

* the set of supported operators (based on ONNX OpSet)

* the number of tested AI models (model zoo size)

* the set of supported optimizations: Evaluated across three dimensions:

1. **Data-Dependent Optimizations:** We define three levels of data-dependent optimization, which focuses on reducing model complexity and redundancy based on learned parameters:

- **Level 0 (No Optimization):** The model is deployed using its full original redundancy. No parameter reduction or architectural modification based on weight significance is applied.

- **Level 1 (Pruning-only):** Optimization is limited to Pruning (e.g., magnitude-based or structured pruning), reducing the number of parameters/operations. This is typically done post-training and requires sparsity support in the runtime.

- **Level 2 (Pruning + Advanced Optimization):** Optimization combines Pruning with techniques that modify the model's knowledge or architecture during training, such as Knowledge Distillation (KD) or Neural Architecture Search (NAS).

2. **Quantization Strategies:** Three quantization levels are considered, representing the process of reducing the numerical precision of weights and activations to lower bit-widths (e.g., INT8):

- **Level 0 (No Quantization):** The model is deployed in its native floating-point precision (FP32 or FP16), without any reduction in bit-width for deployment efficiency.

- **Level 1 (Post-Training Quantization - PTQ):** Quantization is applied after training using a small calibration dataset to determine scaling factors and zero points. Accuracy loss is not actively mitigated during the training phase.

- **Level 2 (PTQ + Quantization-Aware Training - QAT):** Optimization includes PTQ combined with Quantization-Aware Training (QAT). QAT simulates the effects of low-precision arithmetic during the fine-tuning phase, allowing the model to recover accuracy lost due to quantization.

3. **Data-Independent Optimizations:** We define three graph optimization levels by evaluating the autonomy and depth of the compiler's internal transformation pipeline. This metric assesses the tool's ability to algorithmically restructure the computational graph through techniques such as operator fusion, memory layout rewriting, and hardware-aware instruction scheduling, independently of manual user tuning or pre-processing:

- **Level 0 (Basic Translation):** Minimal optimization. The compilation process mirrors the input graph (direct translation). Fully dependent on external model pre-optimization.

- **Level 1 (Structural/Memory Optimization):** Essential optimization. Includes standard operator fusion (e.g., Conv+BatchNorm) and critical memory optimizations such as buffer reuse. Does not perform complex architectural exploration or advanced loop tiling.

- **Level 2 (Advanced/Algorithmic Optimization):** State-of-the-art optimization. Includes aggressive operator fusion, memory layout rewriting, and hardware-aware scheduling (auto-tuning/tiling). Enables peak performance through algorithmic search of optimal configurations.

**Reliability and Development Assurance (DA).** The evaluation of reliability and Development Assurance includes:

1. **Verification Process:** assesses the development assurance of the toolchain's internal checks using a level from 0 to 4.

- **Level 0 (None):** Closed software lacking any publicly available unit tests for the compiler or runtime.

- **Level 1 (External Validation):** Tools provide user integration tests or validation scripts for the generated model, but no tests for the toolchain core.

- **Level 2 (Runtime / Libraries):** Compiler core is closed, but the Runtime or plugins/parsers are open-source and unit-tested.

- **Level 3 (Full Compiler):** Comprehensive public testing of the entire toolchain (parsing, optimization, code generation) via visible Continuous Integration and Continuous Deployment (CI/CD) pipelines.

- **Level 4 (Certification / Formal):** Level 3 verification augmented by the activities and evidence necessary to satisfy the certification objectives corresponding to the targeted assurance level (e.g., Tool Qualification Level 3 - TQL 3 - for Assurance Level 3, as defined in DO-330 [43]). In practice, reaching Level 4 implies that the code (including any libraries) used to implement the ML model comes with its own qualification package in accordance with the relevant certification standard (e.g., DO-178C [42]).

2. **Transparency:** evaluates auditability and traceability using an Auditability Scale from 0 to 4.

- **Level 0 (Black Box):** Compilation process is opaque, yielding an uninspectable binary with no information about its internal implementation.
tion on the model transformation and implemen-
tation process.

- **Level 1 (Static Report):** Generation of simple reports (SVG, HTML) showing the post-compilation graph without dynamic inspection capabilities.

- **Level 2 (Dynamic Introspection):** Tool provides APIs or dedicated tools to profile execution time, latency, and memory usage layer-by-layer on the target hardware.

- **Level 3 (Open & Modifiable IR):** User can access the **Intermediate Representation (IR)** in a textual or object format, enabling custom optimization passes.

- **Level 4 (White Box / Code Gen): Maximum Transparency.** Tool generates readable and auditable source code (C/C++, RTL), ensuring complete, line-of-code traceability back to the original model.

3. **Known Issues:** quantitative measure corresponding to the number of open issues (e.g., on GitHub) that may affect the overall stability, maturity, or reliability of the toolchain, with a lower count being indicative of higher quality.

**3.3. Criteria Evaluation**

Figure 1 illustrates the evaluation of each criteria for each hardware family (GPU, FPGA, CPU/MCU) and visualize the relative scores across all criteria.

**Life-cycle and Sustainability.** The evaluation of the *Life-cycle and Sustainability* criterion was fully automated using a Python script leveraging the GitHub API, and the resultant scores used for the radar diagrams are dynamic, with the last data update dated December 2025.

Across all hardware families, the evaluation highlights substantial disparities in long-term viability, development activity, and community engagement. For FPGA-oriented toolchains, the results reveal a heterogeneous ecosystem. Mature and community-driven projects such as hls4ml [18] and FINN [50] exhibit strong sustainability indicators, including high recency scores, active contribution patterns, and a steady release cadence. In contrast, Vitis-AI [27], despite a large user base, shows signs of limited recent development activity, with only a single commit in the last 12 months and a comparatively lower recency score. Frameworks like TVM cover all these aspects, as they are both regularly updated and supported by a strong community.

Considering GPU frameworks, openvino stands out as the most active among all evaluated toolchains, with very large contributor communities and stable release cycles. These indicators collectively emphasize the strategic and continuous investment from major industrial stakeholders in GPU-focused toolchains.

Finally, CPU/MCU-oriented frameworks display the broad-
est coverage of the evaluated spectrum, ranging from highly
mature ecosystems to lightweight and specialized toolchains.
At the high end, tvm and edgeai-tidl-tools exhibit strong
sustainability, with sustained contribution levels and rich
release histories. In contrast, MCU-focused toolchains
such as STM32AI naturally expose smaller communities

and more modest activity, yet maintain good recency and
stable release patterns.

This diversity is indicative of the long-standing maturity of embedded toolchains, whose development cycles tend to be slower but remain stable over longer periods.

**Functional Capabilities.**

The *Functional Capabilities* criterion exposes strong contrasts in feature richness, operator coverage, and optimization capabilities across hardware families. For FPGA toolchains, Vitis AI clearly dominates in terms of model-zoo breadth (103 tested models) and ONNX operator support (opset 18 in Vitis AI 3.5 [4]), while FINN and hls4ml provide more specialized/efficient capabilities with very limited model-zoo sizes.

Considering data-independent optimization, Vitis AI performs multiple optimizations, such as computation node fusion, for example, when the batch norm is fused into a preceding convolution, efficient instruction scheduling by exploiting inherent parallelism or exploiting data reuse [1], leading to a Level 2 classification.

The GPU family offers the most balanced and feature-
rich capabilities. TensorRT, LiteRT, and openvino all
support advanced optimization pipelines and robust op-
erator coverage. Notably, openvino exhibits a strikingly
large model zoo (911 models), far exceeding all other
toolchains across families. These disparities must be
highlighted, as they strongly influence generalizability
and benchmarking breadth. It is important to note that
documentation rarely provides explicit details about sup-
ported ONNX OpSets, and several ratings may therefore
underestimate operator coverage for toolchains where of-
ficial support information remains ambiguous.

The CPU/MCU family demonstrates the widest coverage across the entire spectrum of capabilities, reflecting both the maturity and diversity of toolchains targeting low-power devices. Tools such as edgeai-tidl-tools, tvm, and hailo provide strong operator coverage and advanced optimization maturity. Conversely, tflite-micro, and STM32AI intentionally adopt minimal or specialized capabilities, emphasizing small footprint deployment rather than feature completeness. Model-zoo sizes also vary dramatically, from highly curated collections (≈200 models for hailo and ≈130 for edgeai-tidl-tool) to toolchains offering none, thus increasing the development cost. This heterogeneity is consistent with the long-standing historical maturity of MCU-based execution flows and the diversity of deployment constraints.

A specific insight emerges regarding data-independent optimization maturity: toolchains such as TVM implement state-of-the-art compiler pipelines with layer fusion, data layout optimization, automated schedule optimization using an ML-based cost model, etc. [8]. Similarly, TensorRT implements layer fusion [36], kernel auto-tuning (to select the most efficient kernel implementation for the target GPU and layer dimensions), and dynamic tensor memory management (for memory reuse), which awards these two frameworks a level 2 score.

On the other hand, TFLite-micro performs structural
memory optimization (static buffer reuse to eliminate
memory copies) and relies on the upstream TFLite con-
verter for basic operator fusion (e.g., Conv + BN).
<figure><img src="image_2.png" /><figcaption>Figure 1. Multidimensional evaluation of selected AI frameworks, categorized by hardware target (FPGA: row 1; GPU: row 2; CPU/MCU: row 3).</figcaption></figure>

However, the TFLite-micro compiler pipeline itself does not perform complex architectural exploration, advanced loop tiling, memory layout rewriting, or ML-based auto-tuning. It delegates the deep kernel optimization to pre-optimized, non-search-based libraries like CMSIS-NN [47, 29] (Levels 1).

Similarly, frameworks like STM32AI and Hailo exhibit hardware-constrained optimization schemes (Level 1), focusing primarily on memory mapping, fixed-function NPU scheduling, or specialized code generation. These results illustrate the structural differences between general-purpose compiler stacks and hardware-specialized toolchains.

When evaluating the quantization techniques of the different frameworks, FINN relies on the Brevitas [20] tool, hls4ml leverages QKeras [9], while Vitis AI uses its own component, the Vitis AI Quantizer [2]. These three tools all support Quantization-Aware Training (QAT), earning them a score of 2 for this criterion. It is worth noting, however, that FINN uniquely allows for the deployment of partially quantized models, which is particularly attractive for making performance-accuracy trade-offs.

## Reliability and Development Assurance.

The Reliability and Development Assurance criterion reveals clear differences across hardware families in terms of verification process quality and transparency. Across all toolchains, none achieves the maximum Verification Process score (Level 4, formal or certified verification), highlighting an important limitation of current industrial AI compilers for safety-critical applications. Within the

FPGA family, FINN, hls4ml and tvm (VTA [34]) emerge as the strongest candidates, with Verification scores of 3 and Transparency scores of 4 thanks to their fully open, auditable code-generation pipelines capable of emitting HLS/VHDL or synthesizable RTL. In contrast, Vitis AI remains significantly more opaque (Transparency 2) and only partially verifiable (Level 2), as some main components like Vitis AI Compiler remain closed-source [51]. GPU toolchains offer generally strong verification maturity (Levels 2–3), but none provides white-box transparency. TensorRT, LiteRT, and openvino remain fundamentally opaque (Transparency levels 2–3), as their internal compilation flows, optimization passes, and code-generation mechanisms are not fully inspectable. This reflects the industrial focus on performance rather than auditable determinism, which limits their suitability for high-assurance certification contexts.

CPU/MCU frameworks demonstrate the largest variability. On one end, tvm and STM32AI achieve full transparency (Score 4) by generating human-readable C/C++ code or exposing an editable intermediate representation, greatly facilitating traceability and verification. On the other end, tools such as edgeai-tidl-tools or hailo remain considerably more opaque (Transparency 1–2), reflecting proprietary compilation flows targeting DSPs or NPUs. Verification maturity similarly varies from minimal (Level 1 for STM32AI, TIDL) to advanced (Level 3 for tvm and tflite-micro).

Finally, the number of open issues (in reversed order) provides an indicative measure of stability and unresolved bugs. Toolchains with large communities, most notably
openvino (554) and Vitis-AI (408), naturally accumulate higher issue counts, which decreases their raw score despite active maintenance. Conversely, smaller or highly specialized toolchains such as FINN, STM32AI, and openvino (for GPU category benchmarks) show substantially fewer unresolved issues, resulting in better scores under this criterion. While this indicator should not be over-interpreted, it helps contextualize the practical reliability risks associated with each framework.

## 4. APPLICATION

This section illustrates the approach on three representative case studies. Each project highlights the impact of the toolchain selection on the overall performance of a system and development effort.

For each use case, we first establish the use-case-related requirements (e.g., hardware target, model architecture, and operational constraints). Following this, we describe the experimental setup and provide lessons learned from our experience developing AI models.

**Domain-related requirements.** Aeronautical domain. The aeronautical domain is subject to strong certification constraints, including the need to demonstrate that:

1. Performance validation: on-board performance corresponds to the expected model performance.

2. Model output: On-board implementation strictly respects the model semantics (e.g., the embedded model forward pass produces exactly (bitwise) the results generated by a reference model).

3. Model design: The model implements well-defined operations and semantics format. One possible solution is to use the SONNX profile [49] (under development), which requires native support of the ONNX standard (or using a conversion tool, which then becomes part of the toolchain).

If the code produced by the toolchain cannot be verified, the toolchain must satisfy DO-330 [43] requirements. In this context, the toolchain produces code intended to be integrated into the system, and a failure could potentially lead to system failure. In the case of a collision-avoidance system, failure of the ML component could result in a catastrophic failure. In this context, applying DO-330 leads to assigning a TQL between 1 and 4 depending on the assurance level targeted (see DO-330 Appendix B). The aeronautical domain is subject to strong long-term maintainability constraints. Therefore, the toolchain must be maintainable. In addition, if toolchain is qualified (see above), it must be usable across a wide range of use cases. The hardware platform is generally defined before the application is developed and is no more a free variable. Therefore, the toolchain must support this target.

### 4.1. Use Case 1: “An evaluation bench for the exploration of machine learning deployment solutions on embedded platforms”

**Use-case-related requirements.**

In this study [26] from the Confiance.ai project, authors aim to deploy a neural network for collision avoidance (ACAS-Xu) on a Zynq Ultrascale+ MPSoC. Thus, hardware target and model are fully defined and specific to the use-case. This implies that the ability of the toolchain

to come with a well-populated model zoo is not critical. Furthermore, the model uses only a few operators (fully connected network). So there are no strong constraints on the supported ONNX OpSet. The system's safety relies on numerical analyses performed on the design model. Therefore, these verifications are only meaningful if the semantics of the model is strictly preserved, bitwise. The model is quantized. Hence, it is not necessary to implement quantization mechanisms. The quantized model is small; therefore, it is not essential to implement optimization methods.

Two frameworks were investigated: (i) Vitis AI and (ii) FINN.

**Setup and Lessons Learned.**

<table><caption>Table 2. Engineering metrics of both workflows.</caption><thead><tr><td>Framework</td><td>FINN</td><td>Vitis-AI</td></tr></thead><tbody><tr><td>Maturity</td><td>Low</td><td>High</td></tr><tr><td>Ease of Use</td><td>Low</td><td>Medium</td></tr><tr><td>Transparency</td><td>High</td><td>Low</td></tr><tr><td>Community Support</td><td>Low</td><td>High</td></tr></tbody></table>

(i) **Vitis AI.** Deployment of neural networks on AMD DPUs (general purpose AI accelerator) is made more efficient through the use of integer quantization to reduce the energy cost, memory footprint, and data path bandwidth required for inference. As the model supplied by their partner was quantized, it was necessary to carry out the quantization again with Vitis AI, as at that time the framework did not accept models that have already been quantized. Nevertheless, the authors succeeded in improving post-quantification performance by implementing a first stage of Post Training Quantization (PTQ) followed by a Quantitation-Aware Training (QAT) phase, all within the Vitis AI ecosystem.

As part of the compilation process, the weights are formatted as INT8, concatenated, and shuffled for efficient execution. Thus, it is not possible to review the weights post-compilation. Furthermore, the Vitis AI tool DPU instruction compiler is not provided as open source, and the instruction set for the DPUCZ is not publicly documented. When the model contains operations that the DPU cannot support, some subgraphs are created and mapped to the CPU. Supported operators are input framework dependent, meaning that if the input model is written in Tensorflow, the supported operators can differ from experiments made on Pytorch or Caffe model equivalent. Finally, Vitis AI offers constant resource consumption that is independent of the depth of the network. This property is particularly interesting in the context of real-time-critical embedded systems.

(ii) **FINN.** This framework exploits the parallel processing capabilities of FPGAs, allowing highly optimized latency and power efficiency. To perform model quantization, user can use Brevitas [39]. Given the current maturity of the FINN toolchain, authors were unable to complete the deployment flow for the selected model due to incompatibilities with certain operators.
<table><caption>Table 1. Case studies evaluating multiple framework on a given hardware platform.</caption><thead><tr><th>Workflow</th><th>Building Segmentation [40]</th><th>Building Segmentation [40]</th><th>Cloud [19]</th><th>Segmentation</th><th>ACAS-Xu [26]</th></tr></thead><tbody><tr><td>Model</td><td>U-Net</td><td>U-Net</td><td>FCN</td><td></td><td>MLP</td></tr><tr><td>Number of params</td><td>1.941 M</td><td>1.941 M</td><td>614</td><td></td><td>15855</td></tr><tr><td>Dataset</td><td>Inria Aerial Image Labeling Dataset [32]</td><td>Inria Aerial Image Labeling Dataset [32]</td><td>IRT Internal</td><td></td><td>ACAS-Xu (internal)</td></tr><tr><td>Hardware target</td><td>Zynq Ultrascale+ (FPGA)</td><td>Jetson AGX Xavier (GPU/CPU)</td><td>Cyclone V MitySOM-5CSx (FPGA)</td><td></td><td>Zynq Ultrascale+ (FPGA)</td></tr><tr><td>Toolchain</td><td>FINN, Vitis AI</td><td>TVM, cuDNN, Tf</td><td>VGT, VHDL</td><td></td><td>Vitis AI, FINN</td></tr></tbody></table>

## 4.2. Use Case 2: Real-time semantic segmentation of aerial images
Use-case-related requirements.

This use case, carried out in the SPOC project [40] focuses on earth observation, specifically using satellites and UAVs (drones). These tools are important for capturing high-resolution images of the Earth's surface, with detail levels ranging from 0.2 to 10 meters. SPOC project focuses on a semantic segmentation workflow that employs the U-Net model trained on the Inria Aerial Image Labeling Dataset [32]. To investigate the impact of different hardware-toolchain combinations, two deployment workflows were explored: one targeting the Zynq UltraScale+ FPGA, utilizing the TVM, FINN, and Vitis AI toolchains, and another targeting the Jetson AGX Xavier GPU, leveraging cuDNN and TensorFlow.

### Setup and Lessons Learned.

<table><caption>Table 3. Synthesis of the engineering metrics of the five workflows as described in SPOC project [40]. Metrics are quantified as high, medium, and low.</caption><thead><tr><th>Framework</th><th>TensorFlow</th><th>cuDNN</th><th>TVM</th><th>FINN</th><th>Vitis-AI</th></tr></thead><tbody><tr><td>Maturity</td><td>High</td><td>High</td><td>High</td><td>Low</td><td>High</td></tr><tr><td>Ease of Use</td><td>High</td><td>Low</td><td>High</td><td>Low</td><td>Medium</td></tr><tr><td>Transparency</td><td>High</td><td>High</td><td>High</td><td>High</td><td>Low</td></tr><tr><td>Community Support</td><td>High</td><td>Low</td><td>High</td><td>Low</td><td>High</td></tr></tbody></table>

### (A) Deployment on the Jetson AGX Xavier GPU/CPU

**(i) Tensorflow (Tf) 2.6.** The float32 model remains unchanged between the training and deployment stages which explains the consistency observed between the standard computing environment and the embedded deployment.

**(ii) Nvidia cuDNN 8.4.1 library.** The model remains in float32 format. The neural network must be manually implemented in C++ with calls to the cuDNN library to execute operations on the GPU. The neural network is then cross-compiled for an ARM target using g++ and NVCC (Nvidia CUDA Compiler), resulting in an executable that is deployed on the board. Only the down-sampling path and the middle convolution of the U-Net were implemented using cuDNN. The intermediate tensor outputs from the middle convolution produced by cuDNN are equivalent to those from TensorFlow. Thus, using cuDNN should not change the model's performance.

**(iii) TVM 0.8.** The trained Float32 model was deployed on an ARM processor using TVM 0.8 to export the model to Relay, quantization of the neural network is optional.

The model was compiled using an optimization level of 3 (which achieved the best trade-off between optimization and neural network accuracy). Subsequently, TVM's auto-scheduling was employed, conducting 10,000 trials to optimize the scheduling of the inference on the CPU. The model was then ready for deployment on the ARM-A53 target, operating under a Linux-based system with the TVM runtime installed. The TVM workflow, without quantization, preserved the quality of the neural network's output. In further experiments, every weight and activation function were quantized to eight bits, except for the first convolutional layer. These experiments revealed that post-training quantization with TVM had a negligible impact on the evaluation metrics, minimally affecting both IoU and accuracy.

### (B) Deployment on the Zynq UltraScale+ FPGA

**(i) FINN.** As FINN is incompatible with Keras or TensorFlow, the U-Net model was re-implemented using PyTorch 1.7.1 and Brevitas 0.6.1 which is a quantization library designed to facilitate Quantization Aware Training (QAT) with PyTorch and to support deployment through FINN. First, the Float32 version of the U-Net was trained using Keras and the weights were exported to the PyTorch/Brevitas version of the U-Net. Then a training of the quantized version of the U-Net was proceeded. After training, the model was exported to the ONNX format, which is compatible with FINN. At this stage, the model is transformed into a graph that contains only FINN HLS-compatible nodes. Subsequently, the folding configuration for each graph node is defined to set the parallelism. Then, synthesis and implementation were performed. Finally, the model was deployed on FPGA. Despite aggressive quantization, performance results showed a slight decrease.

**(ii) Vitis-AI.** The workflow process begins with training the Float32 model using Keras, followed by exporting it through the Vitis-AI toolkit. Deployment on the MPSOC involves four primary activities: configuring the DPU and generating the FPGA bitstream, compiling and quantizing the model to 8-bit using Vitis-AI, generating C++ application code using VART for model execution, and creating the BSP for the ZCU102 board. The quantized model maintains the same accuracy as the Float32 baseline and runs on three DPU cores. Resource usage is mainly limited by DSPs and BRAMs, while LUT-based logic remains available for further scaling. The Vitis-AI workflow is mature and flexible, supporting custom IP and a wide range of layers, though it can be complex and some
tools are not fully open source.

Table 4 summarizes the engineering metrics of the five workflows. TensorFlow and TVM rank highest thanks to their maturity, ease of use, strong documentation, large communities, and high transparency. cuDNN workflow is mainly intended for developers of deep learning frameworks like Pytorch or TensorFlow. As a result, it is difficult to use on its own and often requires advanced CUDA programming. FINN appears to be the least mature, with identified bugs, and it presents significant usability challenges. The need to develop custom transformations not available in the FINN library further complicates its usage. Although the community is active, it is relatively small compared to the others. Documentation and examples exist but are dispersed across various websites and GitHub repositories, which complicates the comprehension process. FINN's lack of support for certain operators necessitates modifying network architectures. Despite these limitations, FINN offers high transparency, as the quantized model is fully accessible, allowing users to inspect and verify the network implementation.

### 4.3. Use Case 3: OPS-SAT Cloud Segmentation Use-case-related requirements.

In CIAR project [28], authors deployed different neural networks for cloud semantic segmentation on OPS-SAT and a set of other hardware targets of interest. This feature is particularly useful when embedded on an Earth Observation (EO) satellite, as it allows only cloud-free images to be transmitted, reducing bandwidth usage by sending only relevant data to end users, and enabling acquisition replanning according to cloud cover (IRMA project<fnref n="2" />).

#### Setup and Lessons Learned.

To evaluate the influence of various hardware-toolchain configurations, the MitySOM-5CSx (Cyclone V FPGA) platform was employed in conjunction with the VGT deployment chains and the VHDL generic library implementation (see Table 1). The two approaches [19] revealed distinct trade-offs between resource utilization, quantization robustness, and development effort.

<table><caption>Table 4. Engineering metrics of both workflows.</caption><thead><tr><td>Framework</td><td>VGT</td><td>VHDL</td></tr></thead><tbody><tr><td>Maturity</td><td>Medium</td><td>High</td></tr><tr><td>Ease of Use</td><td>High</td><td>Low</td></tr><tr><td>Documentation / Examples</td><td>Medium</td><td>High</td></tr><tr><td>Community Support</td><td>Medium</td><td>High</td></tr></tbody></table>

#### (i) VGT.

This approach employed an FxP8.11 fixed-point quantization, mobilizing 80% of the ALM (Adaptive Logic Module) resources but utilizing 0% of the dedicated DSP blocks. This method relies on an ANN-to-HDL generator enabling rapid translation of trained models into pipelined hardware. However, it supports only a limited subset of layer types, requiring manual integration of unsupported operators and fixed-point arithmetic. This constrains network depth and layer dimensions so that the full model

fits into the FPGA.

Post-training quantization was applied, resulting in more than 50% of weights being rounded to zero in some models, impacting feature extraction and robustness to radiometric variations. Authors recommends to switch to Quantization-Aware Training to prevent underflow or overflow to occur.

#### (ii) VHDL generic library implementation.

Authors adopted an FxP11.13 precision and exploited DSP blocks up to 99% of their capacity and 90% of the ALM. Unlike the VGT workflow, this approach provides fine-grained control over signal processing and resource allocation, at the cost of significantly higher development effort. It enables RTL-level optimisation, including quantization-aware arithmetic handling, reducing sensitivity to descriptor variability. In terms of performance, the VHDL approach showed a slight advantage, achieving a latency of 121,241 µs for the inference of 5,037 image patches, compared to 125,875 µs for the VGT-based implementation.

Furthermore, deployment on the FPGA demonstrated a throughput 10 to 36 times higher than that of manufacturer ASIC targets (Google Coral, Intel Neural Compute Stick 2) at an equivalent power consumption of 2 W, while preserving the Float32-level accuracy (79% accuracy). These results highlight the efficiency of RTL-based deployment strategies for the Cyclone V architecture.

In summary, while VGT enables rapid prototyping and reduces initial deployment time, the VHDL generic approach offers superior optimisation capability, lower quantization sensitivity, and better suitability for long-term mission-critical embedded AI applications.

### 5. DISCUSSION

This study allows us to observe that, currently, the toolchains most frequently used for AI model development in aerospace systems generally fail to reach satisfactory levels (Score 4) regarding the Verification Process criterion, and rarely achieve high scores in Transparency. This clearly highlights a gap between standard industry practices in the ML domain and the stringent requirements of safety-critical embedded systems. Initiatives such as SONNX [49] or ACETONE [45] are moving in a relevant direction, ensuring the future availability of certified toolchains specifically designed for Neural Network deployment in critical contexts.

On the ACAS-Xu use-case, previous authors conducted an in-depth analysis of the Vitis AI toolchain, differentiating between "lossy" and "lossless" transformations. This analysis demonstrated that the Vitis AI Compiler operates opaque transformations that compromise auditability.

For instance, according to the Vitis AI documentation, the compiler performs several graph-level optimizations, including layer fusion based on pattern-matching algorithms, and splits the computational graph into multiple subgraphs depending on the operations supported by the target DPU. Crucially, as part of the compilation process, the model weights are formatted as INT8, concatenated, and shuffled for efficient execution, making it impossible to review the weights post-compilation. This high level of abstraction and modification within the toolchain is a significant obstacle to achieving the high transparency

<footnote n="2">²https://www.irt-saintexupery.com/fr/projet-irma-esa/</footnote>
(Level 4) required for critical embedded systems certification. While open-source alternatives like HLS-based implementations or the pure software Vitis Accelerated Libraries offer more visibility, the standard Vitis AI flow falls short of meeting the rigorous verification and auditability demands of critical contexts.

A key point of caution regarding Vitis AI's maturity relates to its advertised support. While Vitis AI claims support for a broad ONNX Opset (Opset 18), the actual DPU (Deep learning Processor Unit) on which the network runs has strong limitations on supported operations. Operations not supported by the DPU are offloaded and executed on the CPU. This discrepancy suggests that it would be more pertinent to assess the runtime limitations (e.g., AMD DPU Features) rather than the general Opset announced by general-purpose toolchains.

Concerning the FINN tool, it is important to state that our comparative technical analysis focuses on pure feature characteristics and does not include performance comparison on the presented use-cases, due to a lack of available results for FINN on these specific benchmarks. Nevertheless, FINN presents key advantages over Vitis AI for embedded deployment: (i) Highly Optimized Latency: Essential for real-time systems. (ii) High Power Efficiency and (iii) Flexibility in Mixed Precision: FINN allows for layer-by-layer quantization (mixed precision), a feature Vitis AI does not enable, offering a crucial degree of control for optimizing resource usage and performance in constrained hardware.

The ECSS-E-HB-40-02A [15] guidelines emphasize that, although exhaustive verification of all possible behaviors of an ML model is typically infeasible, it is strongly recommended to apply standard ECSS practices as extensively as possible and to introduce safety cage architectures together with appropriate risk mitigation strategies (monitoring, redundancy, sandboxing, and similar approaches) to compensate for the inherent impossibility of fully covering all cases. However, the handbook currently lacks specific guidance regarding the verification, testing, or qualification of the ML deployment toolchain itself, that is the conversion, optimization, compilation, or execution components (quantization toolchains, graph optimizers, inference runtimes, FPGA, GPU or CPU/MCU backends, and related elements). In contrast with other safety critical domains such as aeronautics, where DO-330 defines a systematic framework for tool qualification, ECSS-E-HB-40-02A introduces no comparable mechanism. As a result, each project remains responsible for defining its own internal procedures for establishing trust in the toolchain, for example non regression testing, golden model baselining, tool supported risk analyses, or cross backend validation.

Consequently, to target a formal or certification level assurance posture in a space project integrating ML, the developer must not only perform rigorous V&V but also demonstrate, through formal analyses, robust risk containment architectures, error margins, and fallback mechanisms, that the intrinsic limitations of ML are correctly handled within the project requirements. This must be complemented by an internal trust assessment process for the deployment toolchain, since no standardized ECSS

methodology currently exists to guarantee the conformity or robustness of modern ML toolchains. Establishing such processes is essential to support the reliable and widespread integration of AI within critical embedded systems.

It is also important to note that, although the applied optimizations may be complex, they do not alter the fundamental nature of the computations themselves. For example, a matrix multiplication remains a matrix multiplication after optimization and constitutes a functionally simple operation. As a consequence, it may be more effective (and significantly simpler) to verify the final artifact (i.e., the inference code) rather than the tool that produces it. This reasoning closely mirrors established practices in the field of compilation: with a notable exception such as CompCert [30], compilers are generally not qualified against standards like DO-330. Instead, verification efforts typically focus on the compilation output rather than on the compiler itself, even though the compiler is still expected to meet certain quality requirements and to be used within a well-defined and constrained context (e.g., restricted language constructs or optimization levels) for which its behavior is reasonably well understood.

The internal experiments conducted do not allow for the verification of all criteria evaluations since related case studies do not cover all available toolchains. Nevertheless, our evaluations provide a preliminary indicator that can guide our choices for future projects.

## 6. CONCLUSION

This work advances the understanding of the decision-making process in neural network deployment by highlighting the complex trade-offs engineers must navigate. Our criteria-based evaluation framework facilitates systematic assessment of toolchains, bridging the gap between theoretical capabilities and practical applicability. We think that, facing the ever increasing number of AI deployment frameworks and hardware target, practitioners in the embedded systems community really needs support to make appropriate choices. This could be achieved though a joint effort to define a set of metrics relevant to our constraints, create an maintain associated benchmarks, share results, experiences and guidelines. Our work is a first stage towards that goal.

Future work should focus on automating and extending the evaluation process to cover functional and safety-critical criteria not addressable through static analysis alone. A promising direction involves leveraging agen-tic Large Language Models (LLMs) trained to navigate repositories and documentation for data extraction and scoring. Beyond simple documentation review, LLM-based agents could be used to directly execute and evalu-ate frameworks on diverse hardware targets, enabling em-pirical verification of advanced functional metrics such as accuracy degradation, latency, and energy consumption, as well as certification-relevant criteria including seman-tic preservation and transparency. This automated, empir-ical approach not only accelerates evaluation but also en-ables exploration of high-dimensional problems in safety-critical embedded systems that would be prohibitively costly for human analysis.
REFERENCES

[1] AMD. Vitis AI User Guide (UG1414) — Compiling the Model, 2023. URL https://docs.amd.com/r/en-US/ug1414-vitis-ai/Compiling-the-Model. Release date: 2023-09-28.

[2] AMD. Vitis AI Quantizer (UG1414). Vitis AI User Guide, 2024. URL https://docs.amd.com/r/en-US/ug1414-vitis-ai/Vitis-AI-Quantizer.

[3] AMD. AMD Vitis HLS – High-Level Synthesis Tool for Adaptive SoCs and FPGAs. https://www.amd.com/fr/products/software/adaptive-socs-and-fpgas/vitis/vitis-hls.html, 2025.

[4] AMD and Xilinx. Release notes 3.5 — vitis™ ai 3.5 documentation. https://xilinx.github.io/Vitis-AI/3.5/html/docs/reference/release_notes.html, 2023. URL https://xilinx.github.io/Vitis-AI/3.5/html/docs/reference/release_notes.html. Accédé le 2 décembre 2025.

[5] Pedro Antunes and Artur Podobas. Fpga-based neural network accelerators for space applications: A survey. 2025.

[6] Michael Bartling, Neil Tan, Dboy Liao, Kazami Hsieh, and uTensor Team. uTensor: Tinyml ai inference library. https://github.com/uTensor/uTensor, 2025.

[7] Davide Carini. Comparing hls4ml and vitis ai for cnn synthesis and evaluation on fpga: a comprehensive study. 2022.

[8] Tianqi Chen, Thierry Moreau, Ziheng Jiang, Lianmin Zheng, Eddie Yan, Meghan Cowan, Haichen Shen, Leyuan Wang, Yuwei Hu, Luis Ceze, Carlos Guestrin, and Arvind Krishnamurthy. Tvm: An automated end-to-end optimizing compiler for deep learning, 2018.

[9] C. Coelho. QKeras. GitHub repository, 2019. URL https://github.com/google/qkeras.

[10] R David, J Duke, A Jain, VJ Reddi, N Jeffries, J Li, N Kreeger, I Nappier, M Natraj, S Regev, et al. Tensorflow lite micro: Embedded machine learning on tinyml systems. arxiv 2020. arXiv preprint arXiv:2010.08678, 2010.

[11] ONNX Runtime developers. Onnx runtime. https://onnxruntime.ai/, 2021.

[12] Pierpaolo Dini, Lorenzo Diana, Abdussalam Elhanashi, and Sergio Saponara. Overview of ai-models and tools in embedded iiot applications. Electronics, 2024.

[13] Rimma Dzhusupova, Jan Bosch, and Helena Holmström Olsson. The goldilocks framework: towards selecting the optimal approach to conducting ai projects. In Proceedings of the 1st International Conference on AI Engineering: Software Engineering for AI, 2022.

[14] Edge Impulse, Inc. Edge Impulse: The leading edge ai platform. https://edgeimpulse.com/, 2025.

[15] European Cooperation for Space Standardization (ECSS). ECSS-E-HB-40-02A DIR1: Space Engineering – Machine Learning Qualification Handbook. Technical report, European Space Agency, 2023. Version 1, Released in 2023.

[16] European Union. Regulation of the European Parliament and of the Council Laying Down Harmonised Rules on Artificial Intelligence (Artificial Intelligence Act) and Amending Certain Union Legislative Acts, 2021.

[17] European Union Aviation Safety Agency (EASA). EASA Artificial Intelligence (AI) Concept Paper Issue 2: Guidance for Level 1&2 Machine Learning Applications. Technical report, EASA, March 2024. Issue 2.

[18] Farah Fahim et al. hls4ml: An open-source codesign workflow to empower scientific low-power machine learning devices. arXiv preprint arXiv:2103.05579, 2021.

[19] Frédéric Férésin, Erwann Kervennic, Yves Bochichon, Edgar Lemaire, Nassim Abderrahmane, Gaétan Bahl, Ingrid Grenet, Matthieu Moretti, and Michael Benguigui. In space image processing using ai embedded on system module: example of ops-sat cloud segmentation. In 2nd European Workshop on On-Board Data Processing, 2021.

[20] Giuseppe Franco, Alessandro Pappalardo, and Nicholas J Fraser. Xilinx/brevitas, 2025. URL https://doi.org/10.5281/zenodo.3333552.

[21] Google. Litert overview, 2025. URL https://ai.google.dev/edge/litert.

[22] Hailo. An open source light-weight and high performance inference framework for hailo devices. https://github.com/hailo-ai/hailort, 2025.

[23] Intel Corporation. OpenVINO Toolkit, 2019.

[24] Umair Iqbal, Tim Davies, and Pascal Perez. A review of recent hardware and software advances in gpu-accelerated edge-computing single-board computers (sbcs) for computer vision. Sensors, 2024.

[25] Purvish Jajal et al. Interoperability in deep learning: A user survey and failure analysis of onnx model converters. In Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis, 2024.

[26] Eric Jenn et al. An evaluation bench for the exploration of machine learning deployment solutions on embedded platforms. In 12th European Congress Embedded Real Time Systems-ERTS 2024, 2024.

[27] Vinod Kathail. Xilinx vitis unified software platform. In Proceedings of the 2020 ACM/SIGDA International Symposium on Field-Programmable Gate Arrays, pages 173–174, 2020.

[28] Erwann Kervennic et al. Embedded cloud segmentation using ai: Back on years of experiments in orbit on ops-sat. In 2023 European Data Handling Data Processing Conference (EDHPC), 2023.
[29] Liangzhen Lai, Naveen Suda, and Vikas Chandra. Cmsis-nn: Efficient neural network kernels for arm cortex-m cpus. arXiv preprint arXiv:1801.06601, 2018.

[30] Xavier Leroy, Sandrine Blazy, Daniel Kästner, Bernhard Schommer, Markus Pister, and Christian Ferdinand. Compcert-a formally verified optimizing compiler. In *ERTS 2016: Embedded Real Time Software and Systems, 8th European Congress*, 2016.

[31] Tailin Liang et al. Pruning and quantization for deep neural network acceleration: A survey. *Neurocomputing*, 2021.

[32] Emmanuel Maggiori, Yuliya Tarabalka, Guillaume Charpiat, and Pierre Alliez. Can semantic labeling methods generalize to any city? the inria aerial image labeling benchmark. In *IEEE International Geoscience and Remote Sensing Symposium (IGARSS)*. IEEE, 2017.

[33] Peter Mattson et al. Mlperf training benchmark. *Proceedings of Machine Learning and Systems*, 2020.

[34] Thierry Moreau, Tianqi Chen, Ziheng Jiang, Luis Ceze, Carlos Guestrin, and Arvind Krishnamurthy. Vta: an open hardware-software stack for deep learning. arXiv preprint arXiv:1807.04188, 10, 2018.

[35] Kevin E. Murray et al. Vtr 8: High performance cad and customizable fpga architecture modelling. *ACM Trans. Reconfigurable Technol. Syst.*, 2020.

[36] NVIDIA Corporation. Best practices: Types of fusions, 2024. URL https://docs.nvidia.com/deeplearning/tensorrt/latest/performance/best-practices.html#types-of-fusions. Section de la documentation sur les meilleures pratiques de performance.

[37] NVIDIA TensorRT. Nvidia tensorrt. https://developer.nvidia.com/tensorrt/, 2024.

[38] Leandro Antonio Pazmiño Ortiz, Ivonne Fernanda Maldonado Soliz, and Vanessa Katherine Guevara Balarezo. Advancing tinyl in iot: A holistic system-level perspective for resource-constrained ai. 2025.

[39] A. Pappalardo. Brevitas, 2020. URL https://github.com/Xilinx/brevitas. Zenodo release.

[40] Julien Posso et al. Real-time semantic segmentation of aerial images using an embedded u-net: A comparison of cpu, gpu, and fpga workflows. 2025.

[41] PyTorch Team. Executor runtime overview. https://pytorch.org/executororch/stable/runtime-overview.html, 2024.

[42] Radio Technical Commission for Aeronautics. RTCA DO-178C. Software Considerations in Airborne Systems and Equipment Certification, 2011.

[43] Radio Technical Commission for Aeronautics (RTCA). DO-330: Software Tool Qualification Considerations. Standard, RTCA, Inc., 2011. RTCA DO-330.

[44] Renesas Electronics Corporation. e-AI Solution: Embedded ai development environment. https://www.renesas.com/en/key-technologies/artificial-intelligence/e-ai, 2025.

[45] Iryna De Albuquerque Silva, Thomas Carle, Adrien Gauffriau, and Claire Pagetti. Acetone: predictable programming framework for ml applications in safety-critical systems. In *24th European Conference on Real-Time Systems (ECRTS 2022)*, volume 8, 2022.

[46] STMicroelectronics. STM32Cube.AI. https://stm32ai.st.com/stm32-cube-ai/, 2025.

[47] TensorFlow Authors. Optimized kernel implementations, 2024. URL https://github.com/tensorflow/tflite-micro/blob/main/tensorflow/lite/micro/docs/optimized_kernel_implementations.md. Documentation du projet TensorFlow Lite for Microcontrollers.

[48] The DeepGreen Consortium. The "Eclipse AIDGE" open source platform. https://deepgreen.ai/, 2023.

[49] The DeepGreen Consortium. ONNX Safety-Related Profile. https://github.com/ericjenn/working-groups/tree/ericjenn-srpwg-wg1/safety-related-profile, 2025.

[50] Yaman Umuroglu et al. Finn: A framework for fast, scalable binarized neural network inference. In *Proceedings of the 2017 ACM/SIGDA international symposium on field-programmable gate arrays*, pages 65-74, 2017.

[51] Xilinx. Vitis-ai copyleft model zoo. GitHub repository, 2025. URL https://github.com/Xilinx/Vitis-AI-Copyleft-Model-Zoo. commit history consulted on 2025-12-02.