# UpGate: Low-Power and Secure Over-the-Air Hardware Reconfiguration for Deployed FPGAs

Alexandre Abadie, Alfonso Cortes-Neira, Thomas Watteyne, Filip Maksimovic

► To cite this version:

Alexandre Abadie, Alfonso Cortes-Neira, Thomas Watteyne, Filip Maksimovic. UpGate: Low-Power and Secure Over-the-Air Hardware Reconfiguration for Deployed FPGAs. ICIN 2025 - 28th Conference on Innovation in Clouds, Internet and Networks, Mar 2025, Paris, France. pp.28-35, 10.1109/ICIN64016.2025.10942953. hal-05024604

HAL Id: hal-05024604

https://inria.hal.science/hal-05024604v1

Submitted on 8 Apr 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
# UpGate: Low-Power and Secure Over-the-Air Hardware
Reconfiguration for Deployed FPGAs

Alexandre Abadie*, Alfonso Cortes-Neira*, Thomas Watteyne*, Filip Maksimovic*

* Inria, France

e-mail: first.last@{inria.fr*}

**Abstract**—Attaching field-programmable gate arrays to micro-
controllers deployed in the field can increase their potential ap-
plications. Making these systems reconfigurable post-deployment
effectively makes them future-proof, allowing maintenance and
updating of firmware in distributed computing applications. This
paper presents UpGate, an embedded software that can securely
perform an over-the-air update of an FPGA's function with
minimal communication overhead, enabling complete flexibility
of the device's functionality. Several benchmarks are performed
using simple to complex hardware designs for in-depth analysis
of memory footprint, timing, and power consumption. The results
show that regular lossless compression techniques, such as GZip
and LZ4, with 80% compression rate in the worst case, are
reducing the global binary update duration by at least 4 times.
This represents 15 times less 128 B packets transmitted, and
approximately 40 s to transfer a RISC-V core bitstream of
579 kB. Surprisingly, what takes the most time and energy is
writing to flash.

<figure><img src="image_2.png" /><figcaption>Fig. 1. The UpGate user experience</figcaption></figure>

I. INTRODUCTION

Modern Field-Programmable Gate Array (FPGA) chips
offer a powerful, cheap and versatile solution to extend low-
power, constrained microcontroller-based deployments. Such
deployments usually have limited embedded resources in
terms of CPU frequency, RAM, Flash size, and connectivity
bandwidth [1]. They are also designed to consume as little as
possible energy to be able to run on battery for years. As a
result, they typically only target very basic applications: sensor
data measures and/or actuator controls, with communications
channels to transmit and/or receive information.

Attaching an FPGA to a microcontroller allows new classes
of applications to be used in such situations: machine learning
models to process input data and make decisions, enhanced
security with dedicated cryptographic accelerators, complete
low-level radio modulation, etc. An FPGA can also be con-
figured as a complete, standalone, RISC-V co-processor, thus
providing virtually unlimited new capabilities to any deployed
device.

However, once initially configured from the developer's
computer and physically deployed in the field, the FPGA can-
not be easily reconfigured remotely and/or wirelessly, mostly
because of the limited capacity of the microcontroller itself,
the very low bandwidth or the lossy connectivity. The solution
so far has been to get physical access to the device, connect
a computer over USB and run the FPGA reconfiguration
manually. Doing so takes time and hence comes with a high
cost as it requires an operator to reach all deployed devices in
person to perform the update operation. Moreover, depending

on the type of deployment, physical access could either be
impossible or dangerous for an operator.

Consequently, despite its reconfigurable nature, the FPGA
may loose its usefulness when the hardware design needs to be
updated, e.g. after a design flaw or a vulnerability is uncovered,
or when new hardware features must be deployed. Having the
possibility to reconfigure an FPGA after it has been deployed
provides a way to apply hardware-level updates throughout
the lifetime of the device, thereby increasing the usefulness
of the deployed application and reducing the physical device
obsoleteness.

In this paper, we propose UpGate, a portable and open-
source solution to perform over-the-air reconfiguration of an
FPGA attached to a low-power microcontroller based de-
vice. Thanks to UpGate, continuous hardware updates can be
performed, remotely, securely, and with low communication
overhead, on already deployed devices.

UpGate uses security features such as hash computation
of the new bitstream and signature verification to guarantee
the trustworthiness of the new FPGA configuration. To save
precious connectivity resource and time, UpGate compresses
the bitstream during transfer and decompresses it before
configuring the FPGA. Compressing the bitstream divides the
reconfiguration duration by at least 4 times, and reduces the
number of packets exchanged during the update by a factor
of 15. This reduced duration corresponds to a similar reduction
in energy consumption.

The remainder of this paper is organized as follows. Section
II surveys related work. Section III introduces the architecture of UpGate and how it works. Section IV describes our experimental setup and evaluation methodology. Section V presents the results. Finally, Section VI concludes the paper.

## II. RELATED WORK

The majority of previous work on portable and efficient solutions to wireless FPGA configuration is limited to software-based approaches that require either use pre-compiled FPGA logic or target-specific firmware. To our knowledge, only TinySDR [2] proposes both hardware and software solutions to this problem. Unfortunately, the TinySDR software implementation only supports Texas Instruments MSP430 based microcontrollers; the over-the-air update protocol is not described.

Other similar live reconfigurations of FPGAs do exist, such as by Zuo et al. [3], which uses a high-speed FC-AE-1553 protocol aimed at high-performance satellite deployments, not resource-constrained IoT devices. The works by Braeken et al. [4] and Vliegen et al. [5] address security concerns with an on-FPGA implementation of a cryptographic core to ensure bitstream validity at the cost of dedicated FPGA resources. Finally, Mesquita et al. [6] do a brief survey of FPGA reprogramming strategies and show the challenges of partial reconstruction that can arise from reusing existing logic due to rerouting and reallocation during synthesis.

All four of the prior approaches use the on-FPGA Microblaze running precompiled firmware that performs the FPGA reprogramming. The Microblaze processor still requires an external radio for wireless remote reprogramming, and limits all four approaches to Xilinx FPGAs. The Microblaze is also a preconfigured soft-core processor that will use some of the resources of the FPGA. Although the results from UpGate are all written for a Xilinx target, it is portable and will work on any FPGA that is capable of booting from flash.

The work by Aziz et al. [7] uses an external radio-based approach (XBee). It does not use either a soft-core or an external processor. However, it uses a small amount of dedicated logic on the FPGA for reconfiguration. The wireless protocol that they use is also not secure, making it susceptible to attackers and errors in the transferred binary, especially since a compromised firmware without their dedicated logic could render over-the-air booting unusable. Encryption and authentication are both addressed in UpGate.

To implement and design the UpGate protocol used to perform a complete FPGA configuration, we take inspiration from the SUIT secure firmware update standard protocol [8]. Zandberg et al. [9] provide an open-source implementation for microcontrollers based on the RIOT operating system. Abadie et al. [10] apply SUIT concepts to update microcontroller firmware on a swarm of robots. In particular, to guarantee authenticity and integrity, they implement Ed25519 signature verification of the update notification and SHA-256 firmware image hash verification. The use of the ARM Crypto-Cell peripheral available on some microcontrollers accelerates the signature verification phase. For instance, on a Nordic nRF52840, it takes less than 20 ms with the cryptographic

accelerator instead of over 2 s for the equivalent software based implementations. Although the SUIT solution does not fully apply to our FPGA reconfiguration use case, we take inspiration from its focus on trustworthiness and bitstream integrity in UpGate.

Another strategy used in UpGate is the use of bitstream compression to reduce over-the-air latency of reprogramming. The work by Gia et al. [11] compares multiple different lossless compression techniques to reduce data in IoT networks. They identify LZO, LZ4, and Zstandard as potential algorithms for IoT data compression. However, their compression/decompression algorithms are run on relatively high-performance processors, the slowest running on a 1.4 GHz ARM A53 Raspberry Pi. In addition, although it is a thorough survey of various algorithms, it does not discuss the details of computations that result in higher or lower latency. To the best of our knowledge, there is no benchmarked analysis of lossless compression algorithms on embedded microcontrollers in prior literature.

## III. UPGATE

<figure><img src="image_3.png" /><figcaption>Fig. 2. Interconnection between a microcontroller and an FPGA in a typical UpGate hardware setup. The UpGate embedded server can receive bitstream data either from UART or the 2.4GHz radio. The bitstream data is sent to the FPGA flash memory over SPI.</figcaption></figure>

### A. Overview

Fig. 1 illustrates the UpGate user experience, which consists of (1) an **update controller** running on the computer, and (2) an **embedded server** running on the microcontroller.

The main UpGate workflow steps are the following:

1) The hardware designer first describes the circuit design using a hardware description language (HDL), then synthesizes the design to a netlist, and finally generates the bitstream that has to be loaded on the FPGA.

2) The update controller transfers the bitstream over-the-air to the embedded server.
<figure><img src="image_4.png" /><figcaption>Fig. 3. Sequence diagram of the UpGate protocol.</figcaption></figure>

3) The embedded server writes the received bitstream into the FPGA flash memory.

4) Finally, the embedded server triggers the FPGA reconfiguration and notifies the update controller of the update completion.

Fig. 2 shows how UpGate interconnects the microcontroller with the FPGA. UpGate is portable and can run on any microcontroller that has GPIOs, an SPI interface and a radio. The SPI interface provides connection to the flash memory, where the FPGA configuration is stored. The GPIOs are used (1) to trigger the reboot of the FPGA once the update process has completed, and (2) to provide physical, direct interfaces between the microcontroller and the FPGA, depending on the application running on the FPGA.

UpGate is designed to work with widely used SRAM-based FPGAs. This makes it usable with any type of FPGA that can be reconfigured from a flash memory. With such FPGA architectures, the FPGA programmer usually writes the configuration bitstream to an external flash memory and triggers the FPGA configuration loader, which in the end loads the configuration to SRAM cells. In its current implementation, UpGate automatizes and allows this process to be performed wirelessly using microcontroller radio.

Implementations for cryptography and compression are used in UpGate to secure and speed up the update process.

## B. Protocol

Usually, FPGA configuration bitstreams are quite large in size, from hundreds of kB to a few MB, and do not fit in the small amount of RAM available on a microcontroller, which is typically on the order of 100s of kB. As a result, the entire bitstream cannot be stored in the microcontroller RAM before being written to the FPGA flash memory. The bitstream therefore has to be split into chunks that are sent consecutively to the UpGate server running on the microcontroller. A signal-

<table><caption>Fig. 4. UpGate notification packet.</caption><thead><tr><td>Type</td><td>Version</td><td>Bitstream len.</td><td>Bitstream hash</td><td>Notification signature</td></tr></thead><tbody><tr><td>1B</td><td>4B</td><td>4B</td><td>32B</td><td>64B</td></tr></tbody></table>

<table><caption>Fig. 5. UpGate chunk packet.</caption><thead><tr><td>Type</td><td>Packet token</td><td>Chunk index</td><td>Chunk size</td><td>Index</td><td>Count</td><td>Size</td><td>Packet data</td></tr></thead><tbody><tr><td>1B</td><td>4B</td><td>4B</td><td>2B</td><td>1B</td><td>1B</td><td>1B</td><td>&lt;= 128B</td></tr></tbody></table>

ing protocol is defined to ensure that each chunk is correctly received and written before a new one comes in.

The UpGate protocol takes inspiration from RobOTAP [10], designed for microcontroller firmware updates. Fig. 3 describes the UpGate protocol. It can be summarized as follows:

* The update controller initializes the update process by sending an update notification message to the UpGate embedded server. This notification message contains bit-stream metadata such as its size, the version and a SHA-256 hash. To ensure trust between the update controller and the embedded server, the notification message is signed using Ed25519 [12].

* Upon reception of the notification message, the embedded server verifies the signature to make sure the message is trustable.

* Flash memory is organized in pages; in order to write data on a flash page, the page first needs to be erased. Once it has verified the notification message, UpGate erases the corresponding number of pages required to store the bitstream, then acknowledges the update.

* Once the update acknowledgement is received, the update controller cuts the bitstream in 8 kB chunks. Each 8 kB chunk is compressed, then split in 128 B slices. These compressed slices are encapsulated in independent update messages sent over-the-air to the embedded server. The $N^{th}$ message is only sent once the $(N - 1)^{th}$ message has been acknowledged.

* Upon reception, the embedded server reconstructs the compressed chunk from the 128 B slices, decompresses it to get back an 8 kB original chunk.

* Each 8 kB chunk is written in 256 B page-size steps to flash memory. 256 B corresponds to the page size of the flash memory used by the FPGA and is configurable in UpGate to cope with different page sizes from other flash memory models.

* Once all chunks have been written to the FPGA flash and acknowledged, the embedded server triggers the FPGA reconfiguration and notifies the completeness of the update process to the update controller.

Packets exchanged between the update controller and the embedded server are described in Fig. 4 and Fig. 5. The update notification packet contains the bitstream version as a 4 B unsigned integer. This field is used to ensure that the same version is not unnecessarily flashed a second time, as this could be used as an attack vector by malicious external code to deploy an old, flawed version. The packet data unit (PDU) size
<figure><img src="image_5.png" /><figcaption>Fig. 6. UpGate compression/decompression flow between the update controller and the embedded server.</figcaption></figure>

limit cannot exceed 255 B, to fit in the BLE maximum payload size. Also, the update message consists of the bytes of a slice as well as 14 B of metadata used by the embedded server to reconstruct and decompress the 8 kB chunk it belongs to. Exchanged bitstream slices are therefore at most 128 B long, so the total update message size, which is at most 136 B, remains below the BLE PDU size limit.

To avoid ending up in an undetermined state, the bitstream is first stored in a temporary location in flash. Once the complete bitstream is received and the global SHA-256 is verified, it is copied from the temporary flash location to the final location where it replaces the previous configuration. This mitigates the risk of triggering a configuration reload from an incomplete bitstream if a power cycle occurs while the bitstream transfer is in progress.

### C. Security

UpGate includes security measures equivalent to those defined by the SUIT standard [8].

The update notification message, shown in Fig. 4, is first signed by the update controller using the Ed25519 digital signature algorithm [12]. To be able to sign, a public/private key pair is generated and provided to the update controller by a trusted developer or maintainer. The private key is kept secret on the update controller. The private and public keys are used to sign the update notification message. The public key is compiled within the firmware running on the microcontroller and is used by the embedded server to verify the signature.

The bitstream integrity is verified using SHA-256 [13]. The bitstream SHA-256 hash is computed by the update controller and stored in the update notification during the initialization of the update. The embedded server feeds the SHA-256 hash

computation with each 8 kB chunk received, and, once all chunks have been received, compares the resulting hash with the one initially contained in the update notification message.

If any of the security checks performed by the embedded server fails – Ed25519 signature or SHA-256 comparison – the update process is canceled.

### D. Compression

Still because of the little amount of RAM available on microcontrollers, it is again not possible to decompress a full bitstream in one go in RAM. To circumvent this limitation, the update controller compresses the input bitstream by 8 kB chunks, as shown in Fig. 6. Each chunk is compressed, therefore taking less than 8 kB and is sent in 128 B increments over the radio. Upon reception, each 128 B packet is written in a temporary buffer, which is itself decompressed back to its 8 kB size. Finally, the 8 kB decompressed buffer is split into 256 B blocks, each written to the flash memory attached to the FPGA.

UpGate provides three compression strategies: no compression, LZ4 [14] and Gzip [15]. Gzip uses dictionary-based compression from LZ77 [16] with Huffman coding [17]. LZ4 is also derived from LZ77 dictionary compression, but with a focus on decompression speed, at the cost of a lower compression rate than Gzip.

## IV. EXPERIMENTAL SETUP

This section details our experimental hardware setup, our software implementation and the different use cases considered to evaluate UpGate.

### A. Overview

UpGate relies on a microcontroller that is wired to I/Os and to the flash memory attached to an FPGA, as depicted in Fig. 2. We use Digilent Arty-A7 development kits based on Xilinx Artix-A7 35T and 100T FPGAs [18].

Many external GPIOs can be connected between the microcontroller and the FPGA. One GPIO is used to trigger the reconfiguration of the FPGA; another is initialized as input to verify that the FPGA is ready. Further GPIOs are wired directly to the FPGA depending on the application requirements. For example, these GPIOs can be used for secondary serial bus connections, such as SPI, UART, I2C, or to notify the microcontroller of an event on the FPGA.

The bitstreams are compressed and sent from a Python script that serves as the update controller and that is running on the user computer. The computer is connected via UART to a Nordic nRF52840-DK board that acts as a wireless gateway to transmit the bitstream over-the-air to the device under test.

### B. Software implementation

The implementation of UpGate is published under the BSD 3-clause license, part of the DotBot project<fnref n="1" />, and well documented<fnref n="2" />. UpGate uses existing compression implementations

<footnote n="1">¹ As an online additional to this paper, all source code used is available under a BSD open-source license at https://github.com/dotbots/DotBot-firmware.</footnote>

<footnote n="2">² Full document of UpGate at https://dotbot-firmware.readthedocs.io/en/latest/upgate.html</footnote>
<table><caption>TABLE I
FPGA USE CASES STATISTICS</caption><thead><tr><th>Use case</th><th>IOs</th><th>LUTs</th><th>Flip-Flops</th></tr></thead><tbody><tr><td>Button switch</td><td>12 (5.71%)</td><td>4 (0.02%)</td><td>0 (0.00%)</td></tr><tr><td>Blinky + UART</td><td>7 (3.33%)</td><td>23 (0.11%)</td><td>47 (0.11%)</td></tr><tr><td>RISC-V core</td><td>12 (5.71%)</td><td>1994 (9.59%)</td><td>1314 (3.16%)</td></tr><tr><td>SDR</td><td>18 (8.57%)</td><td>16384 (78.77%)</td><td>16 (0.04%)</td></tr></tbody></table>

for Gzip [19] and LZ4 [20].

### C. Hardware Setup

We evaluate UpGate on the Nordic nRF52840 microcontroller which features an ARM Cortex-M4 core and an integrated 2.4 GHz radio. The nRF52840 runs at 64 MHz, with 256 kB of RAM and 1 MB of flash. The radio has support for three 2.4 GHz modulation technologies: IEEE 802.15.4, BLE and Nordic's proprietary Enhanced ShockBurst (ESB). The radio implements both short-range BLE modes – 2 Mbps and 1 Mbps – and long range modes (500 kbps, 125 kbps). The nRF52840 also comes with several commonly used peripherals, targeting a wide range of potential IoT applications. To interface with the FPGA flash memory, UpGate implementation uses an SPI bus, clocked at 8 MHz.

The ARM CryptoCell accelerator performs cryptographic operations orders of magnitude faster than a pure software implementation. For instance, the Ed25519 signature verification takes 18 ms instead of more than 2s for equivalent software implementations [10].

### D. Measurement setup

In our experiments, all timing measurements are performed using a logic analyzer with sub-microsecond precision. To measure the power consumption of the microcontroller, we use the Nordic Power Profile Kit during a complete UpGate process. When the CPU is idle and the radio is not running, the microcontroller draws ~0.8mA. When enabled, the radio draws 10 mA in RX and up to 15 mA in TX. The power consumption of the FPGA is not profiled. When active, depending on the bitstream that is running on the FPGA, the power consumption is many 10s of mW and is much higher than the microcontroller consumption. However, the microcontroller can turn the FPGA off if it needs to save energy.

### E. Use Cases

We evaluate UpGate on different FPGA application use cases. First, we load simple FPGA bitstreams which interact with button and blink an LED. Second, we load an implementation of a RISC-V core. Third, we load an implementation of a software-defined radio (SDR). These use cases cover a wide range of circuit design complexities, from the most simple to a much more complex one, as summarized in Table I. These use cases also cover interesting design redundancy aspects, especially in the SDR case that has great potential for compression. In the following subsections, we describe the

<table><caption>TABLE II
MEMORY FOOTPRINT ON THE NORDIC NF52840</caption><thead><tr><th></th><th>RAM</th><th>Flash</th></tr></thead><tbody><tr><td>Security</td><td>256 B</td><td>11631 B</td></tr><tr><td>Gzip</td><td>0 B</td><td>2511 B</td></tr><tr><td>LZ4</td><td>0 B</td><td>2032 B</td></tr><tr><td>UpGate</td><td>18496 B</td><td>2358 B</td></tr><tr><td>Total</td><td>18752 B</td><td>18532 B</td></tr></tbody></table>

circuit design of the RISC-V core and the SDR. HDL files are published under the BSD 3-clause license<fnref n="3" />.

1) RISC-V core: We use an existing open-source RISC-V core called NeoRV32 [21]. This processor is synthesizable to near 100 MHz clock speed on the Artix-A7 FPGA. This makes it a viable alternative to a low-power, low-performance processor in networked distributed computing applications. The processor itself can interface with the wireless microcontroller over either UART or SPI as a child peripheral, as both interfaces are part of the RISC-V implementation.

2) SDR: One of the intended applications of attaching an FPGA to an existing wireless microcontroller is to perform ad-hoc reconfiguration of its wireless capabilities. For instance, usual 2.4 GHz radio have hardware specifications well-suited to a number of existing modulations in addition to BLE, such as 802.11a or 802.15.4. As a result, a simple way of using an FPGA in this context is to implement the radio demodulation directly on the FPGA. In fact, one of the major benefits of using FPGAs is the preconfigured signal processing IP, such as Fast Fourier Transforms (FFTs) and filters built into digital signal processing (DSP) blocks. We are implementing a generic frequency shift-key demodulator as well as an FFT on the FPGA.

## V. UPGATE PERFORMANCE EVALUATION

To evaluate the performance of UpGate, we consider four different benchmarking metrics: (1) the memory footprint of UpGate in the firmware running on the microcontroller, (2) the impact of the three compression strategies (no compression, LZ4, and Gzip) on the amount of data transferred and on the update time, (3) the energy consumption of a whole bitstream update, and (4) the time needed to perform each step of a complete FPGA reconfiguration.

### A. Footprint

The memory footprint of UpGate is measured from the data map of the firmware generated by the firmware build toolchain. On the Nordic nRF52840 microcontroller, the security primitives call the ARM CryptoCell cryptographic accelerator. Although the RAM footprint remains low, at 256 B, the flash usage is above 11 kB, which is quite high. This is because there is no open-source driver implementation of the ARM CryptoCell peripheral. As a result, developers have to link the firmware against a proprietary blob, which contains additional

<footnote n="3">³ https://github.com/DotBots/upgrade-use-cases.</footnote>
<table><caption>TABLE III
BITSTREAM SIZES AND COMPRESSION RATES</caption><thead><tr><th rowspan="2">Use cases</th><th rowspan="2">Size (B)</th><th rowspan="2">Entropy**</th><th rowspan="2">% of zeros</th><th colspan="4">Compressed size/compression ratio</th></tr><tr><th>LZ4 (B)</th><th>LZ4 Ratio (%)</th><th>Gzip (B)</th><th>Gzip Ratio (%)</th></tr></thead><tbody><tr><td>LED switch</td><td><b>2192012</b></td><td>0.008653</td><td>99.9462</td><td>12945</td><td><b>99.41</b></td><td>12915</td><td><b>99.41</b></td></tr><tr><td>LED sw. small*</td><td>229476</td><td>1.713064</td><td>75.9535</td><td>29574</td><td>87.11</td><td>15200</td><td><b>93.38</b></td></tr><tr><td>Blinky + UART</td><td><b>2192012</b></td><td>0.015755</td><td>99.9048</td><td>14401</td><td>99.34</td><td>14277</td><td><b>99.35</b></td></tr><tr><td>Blinky + UART small*</td><td>264184</td><td>1.552450</td><td>79.0937</td><td>31044</td><td>88.25</td><td>16770</td><td><b>93.65</b></td></tr><tr><td>RISC-V core</td><td><b>2192012</b></td><td>0.374780</td><td>97.0513</td><td>99733</td><td>95.45</td><td>81731</td><td><b>96.27</b></td></tr><tr><td>RISC-V core small*</td><td>579308</td><td>1.811004</td><td>79.9682</td><td>114624</td><td>80.21</td><td>84813</td><td><b>85.36</b></td></tr><tr><td>SDR</td><td><b>2192012</b></td><td>0.154940</td><td>98.6927</td><td>49129</td><td>97.76</td><td>40483</td><td><b>98.15</b></td></tr><tr><td>SDR small*</td><td>867244</td><td>0.787598</td><td>91.4262</td><td>66986</td><td>92.28</td><td>46639</td><td><b>94.62</b></td></tr></tbody></table>

<figure><img src="image_6.png" /><figcaption>Fig. 7. Durations of the transfer phase, decompression phase, and of the full update (transfer/decompression/storage/move).</figcaption></figure>

cryptographic features that are not needed by UpGate, but
cannot be excluded.

The compression algorithms have a low flash usage, around 2 kB, which shows that the implementations are lightweight enough to fit in a microcontroller's memory. The large RAM usage of UpGate comes from the implementation choice made by the LZ4 and uzlib compression libraries: the UpGate embedded server has to allocate two 8 kB buffers in RAM used by (1) the compression libraries to store the decompressed data, (2) by internal logic to ensure the chunk written to flash and the decompressed data are the same.

## B. Compression

Xilinx FPGA bitstreams contain significant byte-wise redundancy because of their 32-bit data representation[23]. Consequently, large sequences of 0x00 bytes exists in the bitstream. Also, these bitstreams use the redundant 0xAA995566 synchronization word, placed before each configuration packets. All of these observations point towards a simple avenue to compress synthesized bitstreams and to reduce the overhead of transmitting and receiving them.

FPGA tools, such as Xilinx Vivado, provide their own compression which compresses at the design level, but not at the byte level of the bitstream. One of the benefits of Xilinx compression is that the FPGA configuration loader has specific built-in hardware that decompresses it as the binary arrives before storing into local SRAM.

The Xilinx Vivado compressed bitstream size is directly related to the FPGA gates utilization needed by a hardware design. This is shown in Tables I and III: the default bitstream size is always ~2.2 MB, regardless of the gates usage, while the Xilinx Vivado compressed version is 3x to 10x smaller,

depending on the design complexity. So the default bitstream contains the configuration of all gates available in the FPGAs, regardless they are used in the design or not. As stated in the Digilent Arty-A7 reference manual [18], the compression ratios can achieve 10x, which is quite low given the binary redundancy.

Table III contains the entropy of several bitstreams and percentages of 0x00 bytes. Well-known lossless compression techniques offer very high compression rates in this context [24], as shown in Table III. Also, Gzip outperforms LZ4 compression rates, especially when compressing a Xilinx Vivado compressed bitstream (85% instead of 80% in the RISC-V core use case). For both Gzip and LZ4, the compression reduces the transferred data significantly with both Vivado compressed and non-compressed bitstreams.

This also applies to other types of FPGA bitstream, such as Lattice. We generated equivalent bitstreams for the Orange-Crab target and noticed similar compression rates.

The following results only consider lossless compression techniques applied to Vivado compressed bitstreams. Although it compresses better, a 2 MB bitstream is in too consuming too much time to erase and write on the Flash memory.

## C. Energy Consumption

Fig. 8 displays the total energy consumed during the entire bitstream update, showing that the “no compression” case is the most energy-hungry. This is because the radio (drawing 10 mA) is always on during the bitstream transfer phase so the more time it takes to transfer, the more it consumes. When looking at instantaneous power consumption, it appears that decompression, which is computationally intensive, draws 5 mA on average. LZ4 compresses slightly less than GZip for

<footnote>* The small version corresponds to the bitstream compressed with Xilinx Vivado compression method.</footnote>

<footnote>** Entropy is computed using ent [22] on the Vivado small bitstream version.</footnote>
<figure><img src="image_7.png" /><figcaption>Fig. 8. Energy consumption during a full bitstream update.</figcaption></figure>

<figure><img src="image_8.png" /><figcaption>Fig. 9. Number of packets sent during a bitstream update.</figcaption></figure>

the binaries in our experiments. Even though it is a faster decompression than GZip, the reduced over-the-air time from higher compression rates results in lower energy consumption with GZip than with LZ4.

## D. Timings

The bitstream update durations are displayed in Fig. 7. The initial signature verification consistently takes 18 ms [10], and is negligible overhead when compared to the FPGA update procedure.

Notably, Fig. 7 shows that, in all cases, the compression reduces total reconfiguration time. The bitstream compression rate is so high that transmission over low bandwidth transport media and write to flash are sped up by at least 4x. This is made even clearer when looking at the number of 128 B packets (the amount of data exchanged during the update), in Fig. 9: using LZ4 or Gzip to compress the bitstream results in 15 times fewer packets. Sending fewer packets results in faster over-the-air transfer.

Another key aspect is the duration of decompression on the microcontroller. LZ4 is 20 times faster on average than Gzip. The total reprogramming duration remains similar, indicating that sending fewer packets over-the-air is important for reducing total time.

Fig. 10 shows where time is spent in the SDR use case. Without compression, 85% of the time is spent transferring data over-the-air and writing on flash memory. With LZ4 compression, that is reduced to 55% but it is still the most time-consuming portion of the update processes. With Gzip compression, the transfer and write to flash steps duration falls down to ~40% and is equivalent as the relocation step time, which is performed at the end of whole process. This step also impacts significantly the duration of the reconfiguration.

Finally, Fig. 10 shows that Gzip decompression takes much longer than LZ4 decompression - 10% instead of 0.5% of the total duration - but the total update process remains faster.

## E. Discussion

Our results show that most of the time is spent transferring and writing the bitstream to the flash memory. Depending on the model of flash memory and the communication media bandwidth, this time can be reduced significantly.

<figure><img src="image_9.png" /><figcaption>Fig. 10. Break-down of the time spent by UpGate.</figcaption></figure>

Different models of flash memory can have a 2x writing speed increase compared to others, depending on a number of factors including technology used and memory size. Concerning wireless communication, the BLE radio can be configured with a datarate between 125 kbps and 2 Mbps. Using a higher data rate lowers the duration, albeit with a marginal time compared to flash operations when using compression.

UpGate timing could be further improved if using direct JTAG access to the FPGA and thereby configure the SRAM cells directly. This would significantly speed up the reconfiguration process, but would only be active until the next power cycle. An hybrid approach with both flash and JTAG programming of RAM could be an interesting solution where reconfiguration is fast, and remains active across power cycles.

The choice of compression algorithm should take into account the limited computational capability of a microcontroller. Our results show that LZ4 is better as decompression is much faster, even though it has a lower compression rates than Gzip.

# VI. CONCLUSION & FUTURE WORK

The UpGate protocol provides a flexible and portable method to do live updates of FPGA implementations with the assistance of a wireless microcontroller. This has implications for a combination of applications, including reconfigurable testbeds, enhanced computational capability of deployments of sensor networks, and potentially live updates of systems in which FPGAs are used, such as in automobile and aeronautic applications.

For the purposes of benchmarking in this paper, UpGate is implemented on a selection of devices, the protocol itself is intentionally designed to be as hardware-agnostic as possible.
Every FPGA that we are aware of has the ability to boot itself from flash on reset. In addition, the application programming interface is written in such a way that it is also irrelevant how the binary is delivered to the microcontroller.

Potential future work includes further benchmarking of in-FPGA accelerators, and improvements of the experimental hardware: a custom-designed circuit board that would serve as a self-contained module. This custom board could then be seamlessly integrated into a wireless testbed for further research in computational acceleration in edge computing applications or research in new physical-layer protocols.

One major observed performance benefit of UpGate is the use of lossless compression methods. Even in fairly resource-heavy designs, the compression ratio using either LZ4 or GZip is extremely high and greatly reduces the amount of data transferred. One potential future work would be to implement an LZ4 or GZip compression in FPGA hardware logic as part of its power-on-reset procedure. This way, the heavily compressed binary can be stored directly into the flash and, during the boot procedure, the configuration can be read and decompressed on-the-fly from the memory as it is transferred into the FPGA's on-chip SRAM cells. Unfortunately, because the FPGA space is still relatively closed-off (the boot ROM is typically inaccessible to users), this would likely need cooperation from FPGA manufacturers.

An additional potential future work is further investigation of the electrical interface between the microcontroller and the FPGA. In the RISC-V we used in this paper, the processor uses a wishbone bus to communicate with its on-chip (or in this case, on-FPGA) accelerators, co-processors, or peripherals. This same wishbone bus could be exposed to an UpGate microcontroller interface, but would require a software API on the wireless microcontroller. Another potential interface that could be useful for large and slow data transfer is directly through shared memory. One downside is that, if the FPGA is ever reset or loses power, it also loses the binary and needs to be reconfigured.

## ACKNOWLEDGMENT

This document is issued within the frame and for the purpose of the OpenSwarm project. This project has received funding from the European Union's Horizon Europe Framework Programme under Grant Agreement No. 101093046. Views and opinions expressed are however those of the author(s) only and the European Commission is not responsible for any use that may be made of the information it contains.

## REFERENCES

[1] C. Bormann, M. Ersue, and A. Keränen, "Terminology for Constrained-Node Networks," RFC 7228, 2014.

[2] M. Hessar, A. Najafi, V. Iyer, and S. Gollakota, "TinySDR: Low-Power SDR Platform for Over-the-Air Programmable IoT Testbeds," in *Symposium on Networked Systems Design and Implementation (NSDI)*, 2020.

[3] J. Zuo, J. He, Y. Ma, X. Chang, and S. Cao, "FPGA Remote Reconfiguration Technology for Space Applications in Embedded Systems," in *2024 IEEE 6th Advanced Information Management, Communicates, Electronic and Automation Control Conference (IMCEC)*, 2024.

[4] A. Braeken, J. Genoe, S. Kubera, N. Mentens, A. Touhafi, I. Verbauwhede, Y. Verbelen, J. Vliegen, and K. Wouters, "Secure remote reconfiguration of an FPGA-based embedded system," in *6th International Workshop on Reconfigurable Communication-Centric Systems-on-Chip (ReCoSoC)*, 2011.

[5] J. Vliegen, N. Mentens, and I. Verbauwhede, "Secure, remote, dynamic reconfiguration of FPGAs," *ACM Transactions on Reconfigurable Technology and Systems (TRETS)*, 2014.

[6] D. Mesquita, F. Moraes, J. Palma, L. Moller, and N. Calazans, "Remote and Partial Reconfiguration of FPGAs: tools and trends," in *Proceedings International Parallel and Distributed Processing Symposium*, 2003.

[7] S. M. Aziz, D. H. Hoskin, D. M. Pham, and J. Kamruzzaman, "Remote reconfiguration of fpga-based wireless sensor nodes for flexible internet of things," *Computers and Electrical Engineering*, vol. 100, p. 107935, 2022.

[8] B. Moran, H. Tschofenig, D. Brown, and M. Meriac, "A Firmware Update Architecture for Internet of Things," RFC 9019, 2021.

[9] K. Zandberg, K. Schleiser, F. Acosta, H. Tschofenig, and E. Baccelli, "Secure Firmware Updates for Constrained IoT Devices Using Open Standards: A Reality Check," *IEEE Access*, 2019.

[10] A. Abadie, S. Alvarado-Marin, F. Maksimovic, M. Vučinić, and T. Wateyne, "RobOTAP: Over-the-Air Programming of Robotic Swarms," in *Workshop on Crystal-Free/Less Radio and System-based Research for IoT (CrystalFreeIoT)*, *Cyber-Physical Systems and Internet-of-Things Week (CPS-IoT Week)*, 2024.

[11] T. N. Gia, L. Qingqing, J. P. Queralta, H. Tenhunen, Z. Zou, and T. Westerlund, "Lossless Compression Techniques in Edge Computing for Mission-Critical Applications in the IoT," 2019.

[12] S. Josefsson and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)," RFC 8032, 2017.

[13] T. Hansen and D. E. Eastlake, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)," RFC 6234, 2011.

[14] Y. Collet, "LZ4 Frame Format Description," 2023. [Online]. Available: https://github.com/lz4/lz4/blob/dev/doc/lz4iederFrame_format.md

[15] L. P. Deutsch, "DEFLATE Compressed Data Format Specification version 1.3," RFC 1951, 1996.

[16] J. Ziv and A. Lempel, "A Universal Algorithm for Sequential Data Compression," *IEEE Transactions on Information Theory*, 1977.

[17] D. A. Huffman, "A Method for the Construction of Minimum-Redundancy Codes," *Proceedings of the IRE*, 1952.

[18] Digilent, "Arty A7 Reference Manual," 2023. [Online]. Available: https://digilent.com/reference/programmable-logic/arty-a7/reference-manual

[19] J. Ibsen, "uzlib GitHub Repository," 2021. [Online]. Available: https://github.com/pfalcon/uzlib

[20] Y. Collet, "LZ4 GitHub Repository," 2024. [Online]. Available: https://github.com/lz4/lz4

[21] S. L. Harris, D. Chaver, L. Piñuel, J. Gomez-Perez, M. H. Liaqat, Z. L. Kakakhel, O. Kindgren, and R. Owen, "Rvfpga: Using a RISC-V Core Targeted to an FPGA in Computer Architecture Education," in *Conference on Field-Programmable Logic and Applications (FPL)*, 2021.

[22] J. Walker, "ENT - A Pseudorandom Number Sequence Test Program," 1992. [Online]. Available: https://www.fourmilab.ch/random/README

[23] F4PGA Authors, "Project X-Ray Documentation," 2022. [Online]. Available: https://f4pga.readthedocs.io/projects/prjxray/en/latest/

[24] K. J. Balakrishnan and N. A. Touba, "Relationship between Entropy and Test Data Compression," *IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems*, 2007.