# PYXIS: A highly predictable toolchain for FPGA circuit production of advanced GNC algorithm

Inès Winandy, Arnaud Dion, Pierre-Loïc Garoche, Florent Manni

► To cite this version:

Inès Winandy, Arnaud Dion, Pierre-Loïc Garoche, Florent Manni. PYXIS: A highly predictable toolchain for FPGA circuit production of advanced GNC algorithm. SMC-IT/SCC 2025, Jul 2025, Los Angeles, United States. hal-05080319

HAL Id: hal-05080319

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

Submitted on 22 May 2025

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 Attribution 4.0 International License
# PYXIS: A highly predictable toolchain for FPGA circuit production of advanced GNC algorithm

Inès Winandy*, Arnaud Dion†, Pierre-Loïc Garoche*

Fédération ENAC ISAE-SUPAERO ONERA
Université de Toulouse, Toulouse, France

* first.last@enac.fr, †first.last@isae-supaero.fr

Florent Manni

CNES - Centre national d'études spatiales
Toulouse, France

florent.manni@cnes.fr

**Abstract**—The configuration of Field-Programmable Gate Arrays (FPGAs) within the context of command law implementation for aerospace systems is a complex process. In a previous work, we proposed the use of dataflow programming languages as the input for the synthesis process and as an alternative to traditional hardware programming languages. The proposed translation flow has been demonstrated to be faster than current state-of-the-art tools while simultaneously offering greater predictability in the inferred hardware component of the design. This paper extends this previous work, addressing identified challenges. A first one is related to the use of a generated circuit to perform Guidance, Navigation and Control (GNC) functions: the generated netlist requires synchronization to be used within a closed-loop system. A second one concerns the generation of circuits for custom datatypes: target descriptions must be automatically generated to facilitate technology mapping. As a consequence, a novel toolchain is proposed, providing the capability to generate synchronised circuits with arbitrary precision for computation.

**Index Terms**—Field programmable gate arrays (FPGA), High Level Synthesis (HLS), Embedded systems, Guidance, Navigation and Control (GNC), Dataflow Programming, Computer-aided Design (CAD), Retiming, Sketch-driven synthesis

## I. INTRODUCTION

FPGAs combine the advantages of ASICs and CPUs with high computing speed, precise execution time, and reconfigurability. Consequently, these systems have become a subject of considerable interest within the aerospace industry [7], [13]. FPGAs are specific devices that require a certain level of expertise for configuration. They are composed of multiple slices containing primitives that are placed on an interconnection matrix. These slices typically contain programmable look-up tables (LUTs), flip-flops, and carry logic. The latest FPGAs also incorporate digital signal processors (DSPs) and random-access memory (RAMs) [2].

Configuring an FPGA implies configuring these primitives and connecting them through the utilization of Hardware Description Language (HDL), like VHDL and Verilog, at Register Transfer Level (RTL). Thus, the configuration of these devices requires expertise that is more closely related to hardware design than to software programming. This process is iterative and comprises several stages:

1. The HDL code production.

2. Synthesis: the translation of HDL code into a list of components called netlist.

3. Implementation: the placement and routing of the netlist on the targeted FPGA family.

At each stage, Behavioral and timing simulations can be run to verify the circuit. In the case where a requirement is not met, the corresponding stage must be repeated.

High-level synthesis (HLS) has been proposed as a solution to facilitate the development of FPGA-based systems. The goal of HLS is to raise the abstraction level of FPGA programming [10] to facilitate circuit implementation. This objective can be accomplished through the compilation of programming languages such as C into hardware description languages, such as HDL coders enables the usage of dataflow programming languages as input for HLS [5]. These languages are commonly employed in real-time applications in the aerospace field.

The high-level synthesis of dataflow synchronous programming language has been identified as a potentially fruitful approach for the development of FPGA-based designs for aerospace applications. Nevertheless, it should be noted that this process may result in a loss of the inherent parallelism aspect of dataflow programming languages, and it is also characterized by a significant degree of slowness.

Based on these observations, we have suggested using dataflow programming for a direct translation into netlist [12]. As traceability is a mandatory feature in critical aerospace systems, this approach supported the generation of a readable netlist. The synthesis process was faster than those conducted with traditional tools [12]. The produced circuit was functionally correct, but the toolchain was incomplete. The netlist associated with each construct was manually coded, a time-consuming process prone to errors. Moreover, the resultant netlist was not synchronized. To obtain a real-time circuit, synchronization had to be performed manually.

The current paper addresses these concerns. It focuses on the automated production of the target description files that were hand-written and the synchronization of the netlists produced with the mentioned toolchain.

We made the following contributions:

* An update of the toolchain that enables the automated technology mapping of the generated netlist and the synchronization of the resulting circuit.

* A sketch-driven approach for the automated generation of target description language code.
<figure><img src="image_2.png" /><figcaption>Fig. 1: Lus2ir toolchain</figcaption></figure>

1. node add (a: int, b: int) returns (c: int);

2. let

3. c = 0 -> a + b + (pre c);

4. tel

Listing 1: Lustre program

* The synchronization system is designed to guarantee two properties. First, it ensures the correct operation of the generated circuit. Second, it ensures the execution time of the circuit.

This paper is structured as follows: Section II recalls some Lus2IR components from [12], section III explains how netlists are synchronized, section IV shows the technology mapping process, section V illustrates the application of our toolchain PYXIS to a representative use case, section VI the related work, and finally, section VII brings a conclusion on the updated PYXIS toolchain.

## II. BACKGROUND

Synchronous dataflow programming languages have certain similarities with register transfer level descriptions; and a novel approach has been proposed, where synchronous dataflow programming languages are considered as an alternative input for the synthesis process. This approach has been developed within the framework of a toolchain, the illustration of which is provided in Figure 1. We recall the components of this toolchain and their respective functions.

**Lustre language:** Lustre is a dataflow synchronous programming language developed for real-time systems [3]. This language was used as the basis for the SCADE language, which is used for the development of critical systems in the aerospace industry [4]. A Lustre program is built with nodes that handle input signals and return output signals. Nodes contain instructions that are executed in parallel. These instructions can be arithmetic, boolean or control instructions. A subset of the Lustre grammar is shown in Figure 2.

In a first stage of the compilation process, Lustre programs are compiled into a normalized form, relying on a minimal set of constructs. Normalized Lustre contains new variables to encode automaton states and transitions with a subset of the Lustre language [1]. To illustrate this process, a lustre program is given in Listing 1 and its normalization in Listing 2.

**Reticle:** Reticle is a language proposed as a potential intermediate representation (IR) for structural Verilog pro-

bt ::= real | bool | int

d ::= node f (p) returns (p); vars p let D tel

p ::= x : bt; ...; x : bt

D ::= pat = e; D | pat = e;

pat ::= x | (pat, ... , pat)

e ::= v | x | (e,...,e) | e → e | op(e,...,e) | pre e | if e then e else e

v ::= i::int | r::real | true::bool | false::bool

<caption>Fig. 2: subset of Lustre grammar</caption>

1. node add (X: int) returns (S: int);

2. let

3. t0 = 0 -> pre c;

4. t1 = b + t0;

5. c = a + t1;

6. tel

Listing 2: Normalized Lustre program

duction from higher-level representations [11]. The Reticle Compiler employs pattern-matching techniques to identify patterns within the intermediate representation and substitutes them with a predetermined hardware implementation. To perform pattern matching, the Reticle Compiler requires target description files. These are typically manually written. Listing 3 shows an example of target description.

**Direct compilation of Lustre into Reticle IR:** Lus2IR is a code generator performing the direct translation between each normalized Lustre statement and Reticle statement as shown in Listing 4. The translation process produces the intermediate representation required by the Reticle compiler.

Last, the output of this toolchain is a readable netlist in the shape of structural Verilog, which can be interpreted by other tools for the purposes of simulation, implementation, and FPGA configuration.

1. pat lut_and_bool(a: bool, b: bool) -> (y: bool){

2. y:bool = and(a, b) @lut;

3. }

4. }

5. imp lut_and_bool[1,1](a: bool, b: bool) -> (y: bool){

6. y: bool = lut2[0x8](a, b) @a6(x, y);

7. }

Listing 3: Reticle's target description

1. def main(a: i32, b: i32, en: bool) -> (c: i32) {

2. t0:i32 = reg[0](c, en);

3. t1:i32 = add(b, t0);

4. c:i32 = add(a, t1);

5. }

Listing 4: Reticle's Intermediate Representation
<figure><img src="image_3.png" /><figcaption>Fig. 3: PI controller dependency graph</figcaption></figure>

### III. SYNCHRONIZATION

The fundamental principle of dataflow programming is the assumption that the scheduling and real-time execution of program nodes is managed by a real-time operating system (RTOS). It is important to note that the toolchain's output should not be interpreted as a program to be run on a computer with an operating system. It is a physical computational unit in itself. In order to obtain functional circuits, the toolchain must provide a method for synchronizing the inputs and outputs (IO) signals.

#### A. Issue: running a dynamical control system at a specific frequency

A controller can be modeled with a time function where the gains are set according to the targeted system frequency

$$U(k) = k_i * \epsilon(k) + k_p * \epsilon(k) - k_p * \epsilon(k-1) + U(k-1) \quad (1)$$

Equation (1) models a PI controller with:

* $U(k)$: The control signal at the present iteration

* $U(k-1)$: The control signal in the previous iteration

* $\epsilon(k)$: The error at the present iteration

* $\epsilon(k-1)$: The error at the previous iteration

* $k_i$: The constant integral gain

* $k_p$: The constant proportional gain

The program that executes this function can be modeled as a Direct Acyclic Graph (DAG). An illustration of a covering tree of this DAG is given in Figure 3. The hardware translation of the PI controller, illustrated by Figure 4, exhibits synchronization issues arising from inputs instability. In this particular example, `mul_0`, `mul_1`, `reg_0` and `reg_1` receive their respective inputs at the time, `t_0`, and produce a valid output at `t_1`. Following this, `add_2` receives synchronized inputs at `t_2` and generates a valid output at `t_3`. In contrast, `mul_2` and `add_1` receive unsynchronised inputs, resulting in erroneous outputs. As these erroneous signals propagate throughout the graph, it can be deduced that all subsequent outputs will be incorrect. Figure 4 illustrates the described issue.

<figure><img src="image_4.png" /><figcaption>Fig. 4: Signal propagation into the PI circuit. The previous value of a variable is obtained using a register.</figcaption></figure>

#### B. Solution: a wrapper to control the execution of the dynamical system

D Flip-flops store their inputs at each rising or falling edge of the clock cycle, which introduces a latency in the signal propagation. Using register properties in an FPGA to manage circuit timing is referred to as retiming.

A common solution to synchronize the circuit would be to use pipelining. This solution requires the exploration of the DAG to equilibrate data paths with the introduction of new registers as illustrated in Figure 5a. This approach permits the computation of valid outputs at each clock cycle. However, this output is delayed according to the depth of the graph.

The depth of a DAG is defined as the longest path between an input and an output, as illustrated in red in Figure 3. Assuming that the inputs and the registers storing the previous value remain stable for a duration equivalent to the depth of the graph, the outputs can be considered valid after this duration. As the gains of the controller are set according to a pre-defined frequency, the system IOs must be updated at this frequency.

The storage of a new signal using D flip-flop registers can be initiated using a clock-enable signal. This property can be used to lock inputs, outputs, and previous values until the propagation of valid signals all along the graph. To take advantage of these properties, the circuit is wrapped in the synchronization system illustrated in Figure 6.

This synchronization system relies on a counter that computes the number of clock rising edges. The counter initiates the transmission of an enable signal when the number of rising edges reaches a threshold determined by the depth of the graph. This signal activates the update of the circuit IO and PREV registers.

This solution provides a high reliability on signal stability. Furthermore, the number of inferred registers is equal to the number of input and output ports, which is more predictable than inferring those registers among a covering tree, like in the pipelining solution. The tree is only explored in depth, which requires less effort than trying to re-equilibrate data paths. The
<figure><img src="image_5.png" /></figure>

<figure><img src="image_6.png" /><figcaption>Fig. 5: Retiming solutions</figcaption></figure>

<figure><img src="image_7.png" /><figcaption>Fig. 6: Wrapped system</figcaption></figure>

selection of this method was driven by the predictability in the primitive inference of this synchronization system.

### C. Frequency constraint

In control systems, the generation of valid outputs must occur at a specific, predefined frequency. The synchronization mechanism described earlier ensures that outputs are produced in alignment with the frequency of the enabling signal.

To guarantee correct timing, we must manually account for the latency introduced by signal propagation through the

dataflow graph. This latency is determined by the depth of the graph, which corresponds to the longest path from input to output. If we denote this depth as *Lcycle*, then the system must wait at least *Lcycle* clock cycles before producing valid outputs.

Let:

* $T'$ be the clock period of the FPGA

* $T$ be the desired output period, i.e., the period of the enabling signal

* $F'$ be the clock frequency of the circuit

* $F$ be the target output frequency (inverse of $T'$)

We can relate the clock and output frequencies using the following equations:

$$T = T' \times Lcycle \quad (2)$$

$$F' = F \times Lcycle \quad (3)$$

These equations indicate that, to achieve an output frequency $F$, the system clock must operate at a frequency $F'$ that is *Lcycle* times higher.

However, this is subject to a physical constraint: the maximum achievable clock frequency $Fmax$ of the synthesized FPGA design, which is determined by timing analysis during the place-and-route phase. The clock frequency must therefore satisfy:

$$F' \leq F_{max} \quad (4)$$

In other words, to maintain synchronization and ensure that valid outputs are produced at the desired frequency $F$, the system must be clocked fast enough to accommodate the graph depth, but not exceed the FPGA's maximum timing capabilities. This constraint is crucial for ensuring the temporal correctness of the circuit and preventing timing violations during hardware execution.

## IV. AUTOMATED TDL GENERATION

Custom bit-width operations are a fundamental aspect of FPGA design. Reducing operand widths can significantly lower hardware resource usage and power consumption while improving computational speed. However, supporting arbitrary precision within the toolchain introduced in Section II requires generating a large number of target descriptions—one for each bit-width and operation type. Creating these manually is time-consuming and error-prone. This section introduces an automated method for generating target description files.

### A. Technology mapping

The Reticle compiler performs technology mapping by relying on target descriptions, which associate patterns in the intermediate representation (IR) with specific hardware implementations. The Target Description Language (TDL) defines pairs of entries: a pattern (PAT) that matches a code fragment in the IR, and its corresponding implementation (IMPL) as a hardware construct.
1 pat dsp_add_i_n(a: i_n, b: i_n) -> (y: i_n){
2 y:i_n = add(a, b) @dsp;
3 }
4
5 imp dsp_add_i16[1,1](a: i_n, b: i_n) -> (y: i_n){
6 y: i_n = add(a,b) @alu(??,??);
7 }
}

<caption>Listing 5: DSP sketch example</caption>

As shown in Listing 3, a basic example of this mechanism is the pattern and implementation pair for a Boolean AND operation. When Reticle detects this pattern—an AND between two Boolean values—it maps it to a 2-input lookup table (LUT2) configured with the hexadecimal value 0x8, which implements the logical AND.

This matching process allows for efficient hardware synthesis from a higher-level IR but requires extensive target descriptions to support diverse operations and bit-widths.

## B. Sketch guided TDL production

We propose using a sketch-driven approach to automate TDL production. Each operation in the IR is associated with a predefined hardware primitive based on its function. The mapping between operations and hardware resources is summarized in Table I.

<table><caption>TABLE I: Operator mapping to primitive</caption><thead><tr><td>Primitive</td><td>Type</td><td>Operation</td></tr></thead><tbody><tr><td>DSP</td><td>Arithmetic</td><td>add, sub, mul</td></tr><tr><td>LUT</td><td>Bitwise<br>Comparison<br>Control</td><td>not, and, or, xor<br>eql, neql, lt, gt, le, ge<br>Mux</td></tr><tr><td>FDRE</td><td>Memory</td><td>reg</td></tr></tbody></table>

Each primitive is linked to a sketch—an abstract template in pseudocode—that guides the generation of both the pattern and the implementation.

1) **Arithmetic Primitives (DSP):** Digital Signal Processors (DSPs) are ideal for high-speed arithmetic operations such as addition and multiplication. As shown in Listing 5, sketches for DSP-based operations describe how the IR operation (e.g., add) maps to a DSP block. The DSP location is left unspecified using `@alu(??, ??)` to allow for flexible placement during synthesis. The number of DSP blocks required depends on operand bit-widths, and since DSPs are inherently synchronous, no additional synchronization components (e.g., flip-flops) are needed.

2) **Logical and Control Primitives (LUTs):** Operations such as bitwise logic, comparisons, and multiplexers are implemented using Look-Up Tables (LUTs). These primitives execute logic equations bit-by-bit. As LUTs are asynchronous, each output must be connected to a flip-flop to resynchronize the data. The bits are then reassembled using concatenation.

For example, the multiplexer circuit illustrated in Figure 7 is described in Listing 6, where each input bit is processed independently and synchronized before forming the complete result. The corresponding logic equation is:

<figure><img src="image_8.png" /><figcaption>Fig. 7: Multiplexer circuit</figcaption></figure>

1 pat lut_mutex_i_j sel: bool, a: i_n, b: i_n) -> (y: i_n) {
2 y:i_n = mux sel, a, b) @lut;
3 }
4
5 imp lut_mutex_i_n[1,1](a: i_n, b: i_n, sel:bool) ->
6 (y: i_n) {
7 v0 :bool = vcc();
8 a_n: bool = ext[n](a);
9 b_n: bool = ext[n](b);
10 l_n: bool = lut3[0xac](a_n, b_n, sel) @a6(??, ??);
11 r_n: bool = fdre[0](l_n, v0) @a(??, ??);
12 y: i_n = cat(a_0, a_1, ..., a_n);
}
}

<caption>Listing 6: Mux sketch example</caption>

$$O_i = A_i \cdot \bar{S} + B_i \cdot S \quad (5)$$

3) **Memory Elements (Registers):** The only memory elements currently required are FDREs (flip-flops with reset and enable). In register operations, each bit is passed through an individual FDRE, as illustrated in Listing 7. These bits are then concatenated to reconstruct the output data of the desired type and size.

When the code generator encounters a Lustre statement with a new bit-width, it uses the associated sketch to automatically generate the corresponding IR pattern and hardware implementation. This enables seamless support for arbitrary precision arithmetic and reduces the need for manual intervention during technology mapping.

1 pat lut_reg_0_i16(a: i_n, en: bool) -> (y:i_n) {
2 y:i_n = reg[0](a, en) @lut;
3 }
4
5 imp lut_reg_0_i_n[1, 2](a: i_n, en: bool) -> (y: i_n) {
6 a_n:bool = ext[n](a);
7
8 d_n:bool = fdre(a_n, en) @a(??, ??);
9
10 y:i_n = cat(d0, ..., d_n);
11
12 }

<caption>Listing 7: Reg sketch example</caption>
# V. EXPERIMENTATION

This section presents an empirical evaluation designed to validate the effectiveness of the proposed synchronization mechanism within the PYXIS toolchain.

## A. Test method

To verify the correct behavior of the generated synchronized circuit, we implemented a benchmark using the full toolchain. The chosen test case is a Lead-Lag controller applied to a spring-mass system—a representative closed-loop control application.

The verification strategy involves two simulations:

1. A software-based simulation of the Lustre model using the **Lustre C compiler**.

2. A hardware simulation of the synthesized Verilog netlist using the **FPGA vendor's simulation tool**.

These simulations are executed in parallel and compared to evaluate functional equivalence.

The benchmark is executed in a closed-loop configuration where both the controller and the plant (i.e., the spring-mass system) evolve concurrently. The objective is not to ensure the physical convergence of the system but to validate that the hardware simulation yields the same numerical behavior as the software simulation. Controller gains are selected randomly from a uniform distribution within the range [0, 1], and all computations are performed using 16-bit precision.

## B. Results

The results of the simulation are presented in Figure 8. Until the 24th iteration, the outputs of both the software and hardware simulations match precisely, confirming the correctness of the synchronization logic and the generated circuit.

However, beyond this point, a divergence in output values is observed. This discrepancy occurs because the computed numerical values exceed the dynamic range representable by the fixed 16-bit encoding. Consequently, saturation or overflow errors appear in the hardware simulation, whereas the software model—executed with floating-point arithmetic—continues without such limitations.

These results validate two key aspects:

* The **synchronization mechanism** operates correctly and produces functionally equivalent behavior across simulation environments.

* The **limitations of fixed-point encoding** must be taken into account when designing systems for real-world deployment, particularly in high-dynamic-range applications.

This experiment provides a practical demonstration of the efficacy of the synchronization strategy and highlights the importance of precision-aware design in FPGA-based control systems.

<figure><img src="image_9.png" /><figcaption>Fig. 8: Simulation result</figcaption></figure>

# VI. RELATED WORKS

The retiming technique amounts to rely on registers blocs to address the timing requirements of an FPGA design [8]. This technique is frequently employed to support synchronization of sequential circuits. It amounts to balance the data paths before the relevant component. In our particular context, registers need to be positioned within the tree while an output is produced at each clock cycle. In contrast to this approach, our work proposes to integrate registers as external interfaces with other components. As a result, valid signals propagate in the design during a fixed amount of time before the outputs are updated.

Technology mapping is an integral component of synthesis tools, facilitating the configuration of specific hardware components according to the RTL code. Conventional technology mapping methodologies entails the modelling of the netlist as a directed acyclic graph (DAG), where each node corresponds to a logic gate or a register [6]. The graph is then reduced thanks to multiple input lookup tables that execute the same logic function. However, with the emergence of more advanced primitives such as DSP, the mapping problem has evolved, and most synthesizers fail to map logic functions effectively with those primitives.

The concept of a sketch-driven synthesis for FPGA technology mapping has been proposed for the first time by the Lakeroad framework [9]. This framework has succeeded in generating designs that make efficient use of modern FPGA resources. The Lakeroad technique involves the extraction of semantic elements from the input programs to instantiate primitives from implementation schemas. The primary distinction between the existing work and the present one is related to the nature of the input language. Indeed, the objective of the Lakeroad framework is to generate optimised netlists from conventional HDL programs. In contrast, the present work produces those netlists from a synchronous dataflow programming language targeting specifically FPGA configuration by aerospace engineers.
<figure><img src="image_10.png" /><figcaption>Fig. 9: The PYXIS toolchain</figcaption></figure>

## VII. CONCLUSION

The original goal of the toolchain described in [12] was to generate a readable netlist that preserved the structural semantics of the source model, while significantly reducing synthesis time. Although this objective was achieved, the initial version lacked support for synchronization mechanisms, rendering it unsuitable for real-time or closed-loop control systems. This paper addressed these limitations by introducing a novel synchronization method designed to ensure deterministic and correct circuit behavior in such contexts.

We presented PYXIS, an enhanced toolchain that introduces two major improvements. First, it incorporates a lightweight and predictable synchronization mechanism that guarantees both signal stability and timing accuracy. This mechanism infers a known and bounded number of registers-equal to the number of input and output ports-making it more predictable and easier to implement than traditional pipelining techniques that require complex data-path balancing. Second, the toolchain includes automated support for the generation of target description files used in technology mapping. This automation addresses the previously manual and error-prone process, especially when dealing with arbitrary precision arithmetic.

Although pattern-matching techniques, as implemented in Reticle, offer high predictability for circuit generation, the need to manually define hardware implementations for each operation and bit width limited their practical use. Our approach introduces a sketch-driven synthesis method that automatically generates technology mapping descriptions from dataflow synchronous models. This contribution not only improves usability and reduces engineering effort but also aligns with modern FPGA design methodologies that rely on customizable and resource-efficient primitives.

The resulting PYXIS toolchain, illustrated in Figure 9, has been evaluated through a closed-loop simulation of a Lead-Lag controller. The results confirm the correctness of the synchronized design and validate its practical applicability.

As future work, we plan to incorporate optimization passes within the synthesis flow and deploy the toolchain in physical testbeds, such as nanosatellite platforms. These developments aim to further enhance the performance and deployment readiness of dataflow-based FPGA implementations in aerospace and embedded control applications.

## REFERENCES

[1] Hamza Bourbouh, Pierre-Loïc Garoche, Christophe Garion, and Xavier Thirioux. From Lustre to Simulink: Reverse Compilation for Embedded Systems Applications. ACM Transactions on Cyber-Physical Systems, 5(3):1-20, July 2021.

[2] Andrew Boutros and Vaughn Betz. FPGA Architecture: Principles and Progression. IEEE Circuits and Systems Magazine, 21(2):4-29, 2021. Conference Name: IEEE Circuits and Systems Magazine.

[3] P Caspi, D Pilaud, N Halbwachs, and J A Plaice. LUSTRE: A declarative language for programming synchronous systems.

[4] Jean-Louis Colaço, Bruno Pagano, and Marc Pouzet. SCADE 6: A formal language for embedded critical software development (invited paper). In 2017 International Symposium on Theoretical Aspects of Software Engineering (TASE), pages 1-11, September 2017.

[5] Serena Curzel, Michele Fiorito, Patricia Lopez Cueva, Tiago Jorge, Thanassis Tsiodras, and Fabrizio Ferrandi. Exploration of Synthesis Methods from Simulink Models to FPGA for Aerospace Applications. In Proceedings of the 20th ACM International Conference on Computing Frontiers, pages 243-249, Bologna Italy, May 2023. ACM.

[6] Umer Farooq. Tree-Based Heterogeneous FPGA Architectures: Application Specific Exploration and Optimization. Springer New York, New York, NY, 1st ed edition, 2012.

[7] Shubham Gandhare and B. Karthikeyan. Survey on FPGA Architecture and Recent Applications. In 2019 International Conference on Vision Towards Emerging Trends in Communication and Networking (ViTE-CoN), pages 1-4, March 2019.

[8] Guillaume Huard. Retiming et parallélisation automatique. report, Laboratoire de l'informatique du parallélisme, 1998. Pages: 2+36p.

[9] Gus Henry Smith, Ben Kushigian, Vishal Canumalla, Andrew Cheung, Steven Lyubomirsky, Sorawee Porncharoenwase, René Just, Gilbert Louis Bernstein, and Zachary Tatlock. FPGA Technology Mapping Using Sketch-Guided Program Synthesis. In Proceedings of the 29th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 2, pages 416-432, April 2024. arXiv:2401.16526 [cs].

[10] Emanuele Del Sozzo, Davide Conficconi, Alberto Zeni, Mirko Salaris, Donatella Sciuto, and Marco D. Santambrogio. Pushing the Level of Abstraction of Digital System Design: A Survey on How to Program FPGAs. ACM Computing Surveys, 55(5):1-48, May 2023.

[11] Luis Vega, Joseph McMahan, Adrian Sampson, Dan Grossman, and Luis Ceze. Reticle: a virtual machine for programming modern FPGAs. In Proceedings of the 42nd ACM SIGPLAN International Conference on Programming Language Design and Implementation, pages 756-771, Virtual Canada, June 2021. ACM.

[12] Inès Winandy, Arnaud Dion, Pierre-Loïc Garoche, and Florent Manni. A Reactive System-Specific Compilation Chain from Synchronous Dataflow Models to FPGA Netlist. In 2024 IEEE 10th International Conference on Space Mission Challenges for Information Technology (SMC-IT), pages 11-21, July 2024. ISSN: 2836-4171.

[13] Michael Wirthlin. High-Reliability FPGA-Based Systems: Space, High-Energy Physics, and Beyond. Proceedings of the IEEE, 103(3):379-389, March 2015.