# Circadia: Checkpointing for Intermittent Computing in AI Driven Applications

Matthieu Rodet, Jean-Luc Béchennec, Mikaël Briday, Sébastien Faucou, Isabelle Puaut, Erven Rohou

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

## To cite this version:

Matthieu Rodet, Jean-Luc Béchennec, Mikaël Briday, Sébastien Faucou, Isabelle Puaut, et al. Circadia: Checkpointing for Intermittent Computing in AI Driven Applications. DSD 2025 - 28th Euromicro Conference on Digital System Design, Sep 2025, Salerno, Italy. pp.1-10, 10.1109/DSD67783.2025.00091. hal-05340384

HAL Id: hal-05340384

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

Submitted on 31 Oct 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_2.png" /></figure>
# Circadia: Checkpointing for Intermittent Computing
in AI Driven Applications

Matthieu Rodet

PACAP

Univ Rennes, Inria, CNRS, IRISA
Rennes, France

0009-0009-8382-5318

Jean-Luc Béchennec

STR

Nantes Université, École Centrale Nantes,
CNRS, LS2N

Nantes, France
0000-0002-3763-8417

Mikaël Briday

STR

Nantes Université, École Centrale Nantes,
CNRS, LS2N

Nantes, France
0000-0001-7251-6688

Sébastien Faucou

STR

Nantes Université, École Centrale Nantes,
CNRS, LS2N

Nantes, France
0000-0002-1514-3579

Isabelle Puaut

PACAP

Univ Rennes, Inria, CNRS, IRISA
Rennes, France

0000-0001-9310-9651

Erven Rohou

PACAP

Univ Rennes, Inria, CNRS, IRISA
Rennes, France

0000-0002-8060-8360

**Abstract**—Battery-less embedded systems powered by energy harvesting eliminate the need for battery maintenance and enable their deployment in remote environments. However, their intermittent execution, disrupted by unpredictable power failures, complicates data processing. Solutions for intermittency management gravitate around one key technique: checkpointing volatile data before power failures, and retrieving data at system reboot. Moreover, since data transmission is a major source of energy consumption, performing computations directly on-device is essential. Initially used for simple tasks such as goods identifications, battery-less systems are now being applied to more energy-intensive tasks such as image recognition leveraging machine learning algorithms such as Convolutional Neural Networks (CNNs).

In this paper, we introduce Circadia, a checkpointing strategy dedicated to CNN inference in battery-less systems. By leveraging the structured dataflow and control flow of CNNs, Circadia strategically places checkpoints within the CNN code to ensure task termination, data consistency, and low energy consumption. By design, Circadia has a linear complexity relative to model size, a significant improvement over the closest state-of-the-art checkpointing method, which has cubic complexity. This enables Circadia to handle much larger CNNs. Experimental results, on both generated and state-of-the-art embedded CNNs, show that its checkpoint placement time is several orders of magnitude lower than existing approaches, while its energy consumption at runtime remains nearly identical.

***Index Terms***—Intermittent Computing, Static Checkpointing, Energy efficiency, Code Generation, CNN/ConvNet

## I. INTRODUCTION

Recent advances in ambient energy harvesting technologies and ultra-low-power processors have made it possible to develop battery-less devices that use only a *capacitor* or

a *super-capacitor* as an energy buffer. The objective is to operate effectively despite low energy availability by creating embedded systems that only operate when energy is available, and pauses the execution otherwise, a paradigm known as *intermittent computing* [1]. The challenge lies in ensuring that energy shortages, along with the unpredictable shutdowns they cause, do not prevent the system from eventually completing its assigned tasks. These devices harvest energy from ambient sources such as wind, solar radiation, or electromagnetic waves [2]–[5]. During energy depletion, they enter a low-power mode and resume execution once sufficient energy has been harvested. This capability enables battery-less devices to operate in hard-to-reach areas with minimal maintenance, unlocking new opportunities in various fields, including healthcare [6], space exploration [7], wild life monitoring [8], and civil engineering [9].

Intermittent systems present numerous scientific challenges [10]. To ensure the reliable execution of tasks, it is critical to enforce both *task termination* and *data consistency* [10] despite these interruptions, all while considering resource limitations specific to embedded systems (low-power technologies, reduced-size memory, limited bandwidth). Current solutions gravitate around one main technique: saving the volatile data to non-volatile memory at key moments, and retrieving the last saved data at system restart after a power failure. This concept is known as *checkpointing*.

Checkpointing techniques are split into *static* techniques, where checkpoint placement is determined at compile time, and *dynamic* techniques, which decide checkpoint placement at runtime – for example, when available energy is running low. To ensure task termination, static checkpointing must guarantee that the energy consumed between two successive checkpoints does not exceed the system’s energy buffer

The authors acknowledge the ANR – FRANCE (French National Research Agency) for its financial support of the OWL project n°ANR-23-IAS3-0003-02.
capacity. Additionally, a memory-efficient (and thus energy-efficient) static strategy should checkpoint only *live* data – i.e., data that will be reused in the future.

As research advances and new solutions emerge, it is becoming increasingly feasible to adapt intermittent systems to more complex algorithms beyond their original use cases. Initially, intermittent computing was designed for devices performing minimal tasks, such as uniquely identifying goods or individuals via Radio Frequency Identification (RFID) technology [3], [11]. Today, intermittent systems are being applied to more energy-intensive tasks, including image recognition, data processing, and classification, leveraging machine learning (ML) algorithms [12]. A key advantage of executing these algorithms directly on embedded systems rather than relying on computing clusters, is the reduction of energy-consuming data transfers required to send raw data to external servers [13]. Additionally, processing data at the source enhances privacy by limiting exposure during transmission, thereby reducing security risks while also lowering latency between data acquisition and decision-making.

Supporting Convolutional Neural Networks (CNNs), in the presence of power shortages, creates new opportunities for designing efficient checkpointing strategies. CNNs have a simple and well-defined code structure, enabling extremely fast yet energy-efficient static checkpoint placement, as their control flow consists of a fixed sequence of operations. Moreover, the data flow within a CNN (data exchanged between its layers) is both static and explicitly defined. This allows for precise knowledge of data lifetimes, thereby minimizing checkpoint size. Compared to general-purpose checkpointing strategies, this approach eliminates the need for complex and potentially overly conservative data lifetime analyses.

In this paper, we introduce CIRCADIA, *Checkpointing for Intermittent Computing in AI Driven Applications*, a static checkpointing technique specifically designed for CNNs. Unlike application-agnostic intermittent checkpointing methods, CIRCADIA takes advantage of CNN-specific properties – namely, their static control and data flow – when placing checkpoints. The static knowledge of the control flow enables extremely fast checkpoint placement, while the static knowledge of the data flow ensures that only live data is saved at each checkpoint, eliminating the need for additional static analysis. CIRCADIA guarantees both task termination and data consistency despite unpredictable energy shortages. A side product of CIRCADIA is a compilation toolchain that transforms CNN models into C code, automating the insertion of checkpointing code. This toolchain also enables the integration of alternative static checkpointing strategies, allowing their performance evaluation. An artefact containing our work (CIRCADIA, compilation toolchain, evaluation) can be found at https://gitlab.inria.fr/mrodet/circadia-artefact.

This paper presents two main contributions:

* **CIRCADIA**, an energy-aware static checkpoint placement technique specifically designed for CNNs. Leveraging complete knowledge of the control and data flow of CNNs, it enables fast checkpoint placement, ensuring task termination and data consistency despite unpredictable energy shutdowns. An **evaluation**, on both generated and state-of-the-art embedded CNNs, shows that CIRCADIA achieves a checkpoint overhead comparable to the CNN-specific technique JULIENNING [12], while offering a significantly faster checkpoint placement algorithm, and a 35% reduction in energy consumption compared to the general-purpose static checkpointing strategy SCHEMATIC [14].

* **A compilation toolchain** that transforms CNNs into ready-to-use C code, automating checkpoint insertion without requiring modifications at the binary code level. It also allows the integration of different checkpoint placement algorithms to evaluate their performance.

**Roadmap:** This paper is organized as follows: Section II summarizes the context surrounding CIRCADIA and defines the problem we address. Section III presents the CIRCADIA's checkpoint placement algorithm. Section IV describes the compilation chain developed with CIRCADIA. Section V evaluates CIRCADIA's performance in comparison to state-of-the-art techniques. Section VI reviews related work on checkpointing for intermittent computing and embedded neural network models. Finally, Section VII summarizes our work.

## II. CONTEXT AND PROBLEM STATEMENT

### A. Neural Network Model Properties

This study focuses on feed-forward convolutional neural networks (CNNs) [15]. We assume that CNN training has already been completed, and focus on how CNNs can be made suitable to the constraints of intermittent execution.

1) **CNNs: Neural Networks** can be viewed as a series of layers, each applying a specific operation to an input to produce an output. Inputs and outputs are represented as sets of 2D matrices, where each matrix corresponds to a *channel* of the input/output. *Convolutional Neural Networks (CNNs)* restrict layer types to the following:

* **Convolutional.** These layers consist of a set of filters, where each filter contains a small matrix called a *kernel* for each input channel and a bias term. The filter is applied to the input, producing a single output channel by summing the convolution of each input channel with its corresponding kernel, followed by an element-wise addition of the bias. The initial steps of this process are illustrated and further detailed in Section III-A. Finally, an *activation function* (see the role of activation functions below) is applied.

* **2D Max-Pooling.** These layers compute the local maximum of a sliding window applied to each input channel, generating the corresponding output channel.

* **Dense.** These layers perform a matrix multiplication between the input vector and a weight matrix. The result is then added to a bias vector, followed by an activation function.

*Activation functions* play a crucial role in CNNs, by introducing non-linearity. Without them, a sequence of convolutional layers would only result in a linear transformation of the input, preventing the CNN from learning complex patterns. Among activation functions, the most commonly used are ReLU, Sigmoid and Softmax. Sigmoid and Softmax are
<figure><img src="image_3.png" /><figcaption>Fig. 1. CNN illustration.</figcaption></figure>

particularly well-suited for probabilistic interpretation, making them common choices for the final layer of a CNN. In contrast, ReLU is widely used after each convolutional layer to enhance feature extraction and improve model convergence.

Typical CNN architectures consist of a series of convolutional layers interspersed with max-pooling layers, followed by one or more dense layers at the end [16], [17].

The restriction to CNNs only applies to CIRCADIA's compilation chain, as CIRCADIA's checkpointing algorithm can be adapted to any ordered sequence of tasks with static dataflow.

2) Feed-forward: CIRCADIA assumes feed-forward networks in which each layer exclusively uses the data produced by the preceding layer, as illustrated in Figure 1.

## B. System Description

1) Memory: CIRCADIA targets dual memory architectures, that integrate both volatile (VM) and non-volatile (NVM) memories. The key property leveraged in our approach is that VM offers lower energy access costs (up to 2.47× compared to FRAM [18]), while NVM provides persistence across system shutdowns. We make the following assumptions:

* Sufficient VM memory is available for execution. Specifically, the VM must be large enough to store both the input and output of each layer in the model.

* Sufficient NVM memory is available to store the code, model weights and checkpoints.

* The Worst-Case Energy Consumption (WCEC) of each code snippet is available.

* Both code and model weights reside in NVM.

2) Energy Management: Intermittent systems operate without batteries, relying solely on a capacitor for energy storage. We assume the capacitor's total capacity is known and fixed over time. In the following, we refer to it as CAPA.

3) Execution Scheme: Due to the intermittent nature of execution, data must be regularly saved in NVM to ensure it can be retrieved upon system resume. The points at which data is saved are referred to as checkpoints. Checkpoint placement is static, meaning that it is determined at compilation time.

We also assume that our system halts execution at each checkpoint, transitioning into a deep sleep state. Entering this deep sleep state causes the loss of the volatile state of the system (content of VM, CPU registers). Ambient energy is harvested until the capacitor is fully replenished. Therefore, execution after a power failure re-starts with a full energy buffer. Additionally, we assume that the input data for any inference initially resides in NVM, requiring it to be loaded into

<table><caption>TABLE I

EXECUTION COSTS REPARTITION AMONG LAYERS FOR AN INFERENCE.
THE INPUT IS COMPOSED OF 3 CHANNELS OF SIZE 32 × 32. THE MODEL HAS 5 LAYERS: CONVOLUTIONAL (8 FILTERS), MAX-POOLING, CONVOLUTIONAL (16 FILTERS), MAX-POOLING, AND DENSE.
CONVOLUTIONAL'S KERNELS SHAPE IS 3 × 3 AND MAX-POOLING POOLS SHAPE IS 2 × 2. THE OUTPUT IS A VECTOR OF SIZE 10.</caption><thead><tr><th rowspan="2">Layer Type</th><th colspan="2">Execution cost</th></tr><tr><th>in clock cycles</th><th>in % of total</th></tr></thead><tbody><tr><td>Convolutional</td><td>26,068,084</td><td>49.00</td></tr><tr><td>Max-pool</td><td>615,267</td><td>1.16</td></tr><tr><td>Convolutional</td><td>25,811,820</td><td>48.52</td></tr><tr><td>Max-pool</td><td>199,035</td><td>0.37</td></tr><tr><td>Dense</td><td>509,432</td><td>0.96</td></tr></tbody></table>

VM before computation begins. Likewise, once the inference is completed, the result is stored back into NVM.

## C. Problem Statement

We address the following problem:

Given a trained CNN, the system's CAPA, and the Worst-Case Energy Consumption of (WCEC) of code snippets, generate code capable of performing inference despite intermittent execution. The generated code includes static checkpoint placement that ensures task termination and data consistency.

## III. CIRCADIA

CIRCADIA utilizes its high-level understanding of the CNN dataflow to precisely identify which VM data needs to be checkpointed into NVM. This enables CIRCADIA to save only the *live* data of the VM. The following sections detail the possible locations for checkpoints (Section III-A), the linear-complexity algorithm proposed for checkpoint placement (Section III-B) and the properties it guarantees (Section III-C).

### A. Checkpoint Granularity

CIRCADIA constrains the possible locations where checkpoints can be placed (*checkpoint granularity*). We define an *elementary operation* as the smallest unit of execution that is performed atomically, meaning checkpointing can only occur between elementary operations.

We selected a granularity specifically targeting convolutional layers, which usually account for the majority of computation as shown in Table I. Figure 2 illustrates the principle of a convolutional layer. It consists of filters and a set of input channels. Each filter is associated with a kernel – a small matrix – for each input channel. A convolution, depicted as a * in the figure, is the standard convolution operation on matrices, where a small matrix, the kernel, slides over a larger matrix and performs element-wise multiplication followed by summation at each position. The output of a filter is computed as the sum of the convolutions of each input channel with its corresponding kernel in the filter. The final output of the convolutional layer is the collection of all filter outputs, with each filter contributing one output channel.

The understanding of convolutional layers made us select as elementary operation the matrix convolutions, as shown in
red cross-hatching in Figure 2. To achieve this, a result matrix is allocated for each filter and initialized with the respective filter bias. The result of each elementary operation is then accumulated to the corresponding filter's result matrix. In the same manner, we propose to divide max-pooling layers into sequences of matrix local maximum operations.

The reason why we chose matrix convolution as our elementary operation unit is twofold. Firstly, this operation is widely used and optimized by many hardware accelerators, such as the *Low Energy Accelerator* (LEA) [19] of the MSP430 series of micro-controllers, commonly deployed in intermittent computing. Secondly, the kernel's liveness corresponds to the duration of matrix convolution, making matrix convolution a natural granularity for checkpoint placement.

When converting each layer into elementary operations, an additional setup elementary operation is placed at the beginning to initialize the layer's input and output matrices. The total number of elementary operations generated for each type of layer is as follows:

* **Convolutional layer.** With $N$ input channels and $M$ filters, the layer consists of $N \times M$ matrix convolutions, followed by an activation function. Including one elementary operation for the setup, this results in $N \times M + 2$ elementary operations.

* **Max-pooling layer.** With $N$ input channels, the layer consists of $N$ matrix-local maximum operations. Including one elementary operation for the setup, this results in $N + 1$ elementary operations.

* **Dense layer.** This layer consists of a matrix multiplication followed by an activation function. Including one elementary operation for the setup, this results in 3 elementary operations.

While the execution order of layers is dictated by the model architecture, there is flexibility in the order of elementary operations within the same layer. Currently, our approach processes convolutional layers *filter by filter*, generating one output channel at a time, as illustrated in green circles in Figure 2. Elementary operations of Max-pooling layers are processed in the channels order.

## B. Checkpoint Placement Algorithm

The CIRCADIA checkpoint placement strategy, detailed in Algorithm 1, employs a greedy algorithm. The algorithm operates by sequentially processing elementary operations (OP) while decrementing an energy quota, which is initially set to CAPA (main loop starting line 6 in the algorithm). When the remaining quota is insufficient to execute both the next elementary operation and the following checkpoint, a checkpoint is placed at the current position (line 8 in the algorithm), as shown in red in the example. Subsequently, the same process is applied with a starting energy quantity that is adjusted by subtracting from CAPA the restoration cost of the previous checkpoint. By design, CIRCADIA has a **linear complexity** relative to the number of elementary operations.

The assumption presented in Algorithm 1 ensures that placing a checkpoint at every possible location always constitutes a valid solution. Thus, a valid solution (at worst the one with

<figure><img src="image_4.png" /><figcaption>Fig. 2. Convolutional layer example.</figcaption></figure>

## Algorithm 1 CIRCADIA checkpoint placement algorithm

**Require:** OP: Energy cost of each elementary operations (in execution order)

CP: Energy cost of each possible checkpoint (in execution order)

CAPA: System energy buffer size

**Assume:** $\forall i \in [1, |OP|-1], CP_{i-1} + OP_i + CP_i \le CAPA$

1: **function** CIRCADIA(OP, CP, CAPA)

2:     ▷ Indexes of selected checkpoints

3:     Placement ← ∅

4:     ▷ Account for data retrieving and first operation

5:     quota ← CAPA - CP[0] - OP[0]

6:     **for** i = 1 **to** |OP| - 1 **do**

7:         **if** quota < OP[i] + CP[i+1] **then**

8:             Placement.add(i)

9:             quota = CAPA - CP[i]

10:          quota ← quota - OP[i]

11:      **return** Placement

a checkpoint at each possible location) is always found by CIRCADIA.

Among checkpoint costs, two hold special significance: the *first and last checkpoints*. The first checkpoint fetches data in VM when starting an inference, whereas the last one copies back the final result to NVM.

## C. Enforced properties

CIRCADIA enforces the following properties:

* **Forward Progress.** By design of the algorithm, when starting from any checkpoint and with a fully charged capacitor,
<figure><img src="image_5.png" /><figcaption>Fig. 3. Compilation chain summary of every steps.</figcaption></figure>

the execution reaches the next checkpoint without power failure. This is equivalent to ensuring that, for any two successive checkpoints i, j in a checkpoint placement:

$$CP[i] + \sum_{k=i}^{j} OP[k] + CP[j] \leq CAPA$$

The existence of at least one valid checkpoint placement is guaranteed by the second assumption of Algorithm 1.

* **Data Consistency.** Since execution halts at each checkpoint and resumes only after the energy buffer is replenished through harvesting, the *Forward Progress* property guarantees that unexpected crashes cannot occur during execution. As a result, power loss is only possible at checkpoints, where the system is in a safe state, ensuring data consistency.

* **Semantics preservation.** CIRCADIA's checkpoint placement does not alter elementary operations nor their execution order. Consequently, it naturally preserves the semantics of the checkpointed CNN: the inference result is the same whether the CNN is checkpointed or not.

## IV. COMPILATION CHAIN

CIRCADIA is complemented by an end-to-end compilation chain that transforms a trained CNN model into C code, ready for further instrumentation and/or compilation to the desired target. Figure 3 summarizes the steps of the compilation chain, that are described in the following Sections.

### A. Model Description

The compilation chain starts by generating a *Model Description* from a high-level CNN model given as input. Any CNN representation is valid, as long as it contains the following information. This description consists of a descriptor for each layer, specifying the layer type and its input/output shapes. Our approach currently supports three types of layers: *convolutional*, *max-pool*, and *dense*. Depending on the layer type, the following data is stored:

* **Convolutional.** Kernels shape, weights and biases, and activation function name.

* **Max-pooling.** Pooling shape used in the local maximum.

* **Dense.** Weights, biases, and activation function name.

Converting a CNN model into our model description is straightforward since it closely resembles those used in standard machine learning toolkits, but excludes unnecessary information, such as training parameters.

### B. Layer Division into elementary operations

Model division into elementary operations is achieved through sequential processing of the layers, dividing each of them into elementary operations. During this process, the WCEC of each operation is determined (input OP in Algorithm 1), as well as the WCEC of checkpoint operations (input CP in Algorithm 1).

The precise WCEC of a checkpoint depends on the checkpoint placement, as it involves saving data produced by previous elementary operations and restoring data needed by following elementary operations. Therefore, at this stage, it is not possible to precisely evaluate the WCEC of a checkpoint. Instead, we estimate an upper bound of the WCEC, by assuming that all produced data from every elementary operation prior to the checkpoint must be saved, and that all required data from every elementary operation after the checkpoint must be loaded. This over approximation is equivalent to saving the partially produced layer output and loading the still-alive layer input at the time of the checkpoint. In practice, a layer is likely to have multiple checkpoints placed inside, making each cost lower than the upper bound.

A checkpoint typically consists of two costs: saving data before entering deep sleep and restoring data after wake-up. At this point, we assume that both costs are equal, meaning that a checkpoint restores the same data that was previously saved. This assumption is a necessary approximation, as a more precise dataflow analysis would require knowledge of the exact checkpoint placement. In reality, the data restored may be a subset of saved data, depending on subsequent execution dependencies.

### C. Checkpoint Placement

The checkpointing strategy is applied, using the WCECs of elementary operations and checkpointing operations generated in the previous step. The compilation chain is designed to support seamless integration of alternative static strategies, provided they adhere to the specifications outlined in Algorithm 1.

Since the dataflow is static, our compilation chain can layout the memory so that data items that need to be saved together are *contiguous* in memory. This allows to merge multiple calls to the checkpointing function into a single one, and further allows to implement fast and energy-efficient data transfers through the use of a Direct Memory Access (DMA) if one is available.

### D. C Code Generation

The C code generation process begins with a predefined C template that includes generic data types, checkpoint operations, and functions corresponding to each elementary
<table><caption>TABLE II
GENERATED MODEL ARCHITECTURE DEPENDING ON A SIZE *N* AND NUMBER OF ELEMENTARY OPERATIONS (|OP|) AFTER DIVISION.</caption><thead><tr><th>Type</th><th>Input</th><th>#Filters</th><th>Output</th><th>|OP|</th></tr></thead><tbody><tr><td>Conv</td><td>32 × 32 × 3</td><td>N</td><td>30 × 30 × N</td><td>3N + 2</td></tr><tr><td>MP</td><td>30 × 30 × N</td><td></td><td>15 × 15 × N</td><td>N + 1</td></tr><tr><td>Conv</td><td>15 × 15 × N</td><td>N</td><td>13 × 13 × N</td><td>N<sup>2</sup> + 2</td></tr><tr><td>MP</td><td>13 × 13 × N</td><td></td><td>7 × 7 × N</td><td>N + 1</td></tr><tr><td>Dense</td><td>49N</td><td></td><td>10</td><td>3</td></tr></tbody></table>

operation. The template contains *placeholders* that will be filled by the C code generator to fit a particular CNN model. Placeholders exist for:

* Global variables defining the model weights;

* Reservation of a buffer in NVM, that is big enough to store any of the checkpoints placed;

* Code in the main function, to insert calls to the C functions that implement the elementary operations, and calls to the checkpointing functions.

The generated C code can then be directly compiled or further instrumented by any required tools. The toolchain currently allows the comparison of different static checkpoint placement strategies. For now, code optimizations are postponed to the C compiler.

## V. EXPERIMENTS

### A. Experimental Setup

1) **CNNs Architectures and Benchmarks:** We chose to use the Keras representation, from the TensorFlow Python library as a high-level CNN model representation. To conduct our experiments, we require a diverse set of CNNs with a known number of elementary operations. We opted to generate parametric CNN models that follow a common architecture used in various applications [16], [17]. They feature five layers: two convolutional layers, each followed by a max-pooling layer, to extract features while mitigating dataflow explosion, and a final dense layer for inference. Each model has a fixed input size of 32 × 32 with 3 channels and a final output size of 10 classes. The only varying parameter is the number of filters in the convolutional layers, named *N*. Table II gives the precise architecture of generated models, where *N* represents the configurable size parameter.

The number of elementary operations resulting from the model division is given by the formula deduced from Section III-A: $|OP| = 9 + 5 \times N + N^2$. Our experiments cover $N \in [1, 21]$, generating models with elementary operations counts ranging from 15 to 1059.

In this work, we assume that energy consumption does not depend on data values. As inference control flow is also independent of data values, model weights become irrelevant. Thus, in our evaluations, models are defined solely by their architecture, with randomly generated weights and inputs.

Additionally, we validate our observations on two real-world CNN architectures. The smallest one is designed for Human

Activity Recognition (HAR) [20] and consists of three convolutional, three max-pooling, and one dense layer, reaching 3,540 elementary operations by processing it using our compilation chain. Another architecture, inspired by SqueezeNet [21], a well-established CNN for image recognition, contains eleven convolutional and two max-pooling layers [22], resulting in 22,307 elementary operations.

2) **Baselines:** CIRCADIA is compared with two state-of-the-art static checkpoint placement algorithms: SCHEMATIC [14] and JULIENNING [12].

* **SCHEMATIC** [14] is a static general-purpose solution that can handle any type of programs, including programs with dynamic control and data flows. It determines checkpoint placement based on the WCEC of code snippets and maximum capacity of the energy buffer. Additionally, it performs memory allocation for variables, placing them in VM or NVM to minimize energy consumption. To determine checkpoint placement, SCHEMATIC utilizes the Control Flow Graph (CFG) to construct a Reachable Checkpoint Graph (RCG). The RCG models, for each checkpoint, which subsequent checkpoints are reachable given the available energy. By leveraging this approach, SCHEMATIC ensures the forward-progress property while maximizing the distance between checkpoints to reduce their frequency. Unlike solutions designed specifically for CNNs, SCHEMATIC does not impose any checkpoint granularity, as it does not leverage high-level model-specific information.

* **JULIENNING** [12] is a static specialized solution designed for programs that are divided into sequences of operations with static control and data flows, making it well-suited for CNNs. Each task's WCEC, is known in advance. JULIENNING uses the RCG, as described in SCHEMATIC, to determine the shortest path from the start to the end of execution. The energy cost between two checkpoints depends on the computational cost of the operations and on the overhead of loading the necessary data before execution and saving the generated data afterward. By leveraging the explicit dataflow and the RCG, JULIENNING can compute the exact WCEC between two checkpoints. By finding the shortest path in this graph, JULIENNING's checkpoint placement ensures optimal energy overhead.

3) **Tools and Implementation:** To ensure a fair comparison between the checkpoint placement policies of SCHEMATIC, CIRCADIA and JULIENNING, we use the same experimental environment for the three techniques: C Code is generated using CIRCADIA's toolchain; after a power failure, execution restarts only once the capacitor is fully replenished; the same execution environment (SCHEPTIC emulator) is used with the same WCEC. The compilation of the generated C code is done using the `clang` compiler with the flags required by SCHEPTIC, `-emit-llvm -S -g`.

The SCHEPTIC emulator [23] executes programs at the LLVM Intermediate Representation (LLVM-IR) level [24] under an intermittent power supply. We chose to use SCHEPTIC, already used in the evaluation of SCHEMATIC, as it provides detailed insights into key execution metrics such as
energy consumption and checkpointing overhead. To account for power failures in a controlled and reproducible manner, SCEPTIC employs a periodic power failure model, through the introduction of a *time between power failures* (TBPF), which specifies the interval, measured in CPU cycles, between consecutive power failures. Additionally, the SCEPTIC emulator continuously monitors various metrics at the IR level and provides mappings to machine-specific metrics, particularly the energy consumption of the target system. This ensures that the results remain relevant for real-world embedded systems.

SCHEMATIC operates at the LLVM-IR level. We start by generating C code without applying any checkpointing technique. Loop bounds, required by SCHEMATIC, are extracted from the model description. The C code annotated with loop bounds is then compiled into LLVM-IR for application of SCHEMATIC's checkpoint placement.

JULIENNING operates after the model has been divided into elementary operations. We implemented JULIENNING's checkpointing algorithm as accurately as possible based on its description [12]. Our implementation integrates all optimizations of load and store operations, that avoid the multiple checkpointing of the same data. The authors of JULIENNING analyzed the checkpoint placement complexity as $O(n^3)$, where *n* is the number of tasks – analogous to elementary operations in our experimentation – and our implementation adheres to this complexity.

4) *Target System and Energy Model:* The energy model used to evaluate the WCEC and employed in SCEPTIC to emulate executions is the same as that used by SCHEMATIC, specifically targeting the MSP430FR5969 microcontroller [25]. This ultra-low-power platform is widely used in the intermittent computing field as it features 2 KB of SRAM VM and 64 KB of FRAM, a highly efficient NVM [26]. The simulator SCEPTIC requires that the TBPF, which corresponds to our definition of CAPA, to be expressed in CPU cycles. We adopt the same convention and set this value to 5,000,000 cycles, which corresponds to a simulation of about 0.3 s. This low value was chosen to ensure that even small models are subject to intermittency and thus the need for checkpoints.

## B. Metrics

Three metrics are used in the experimental evaluation:

* **Total Energy Spent per Inference.** This metric evaluates the overall energy cost for performing one inference. The inference cost itself being identical across solutions, differences between solutions reflect variations in the energy cost of their checkpoint operations. Checkpoint placement strategies aim to lower as much as possible this metric.

* **Checkpoint Energy Proportion.** This metric represents the proportion of total energy spent on checkpoints relative to the overall energy cost of an inference, expressed in percentage. Checkpoint placement strategies aim to lower as much as possible this metric. It is expected to correlate with the previous one and provides a direct measure of how energy-efficient each solution is.

* **Checkpoint Placement Time.** This metric quantifies the time required to determine checkpoint placement, excluding code generation. Contrary to other metrics that reflects the runtime efficiency of the generated code, this metrics relates to the scalability of the offline checkpoint placement strategy. Since all checkpoint placement strategies are implemented in the same programming language (here, Python), the measured checkpoint placement times are directly comparable. Checkpoint placement strategies aim to lower as much as possible this metric.

## C. Runtime Energy Efficiency

The runtime energy efficiency of the general-purpose static checkpoint placement strategy SCHEMATIC is first compared against the CNN-dedicated solutions CIRCADIA and JULIENNING. Next, we conduct a direct comparison between CIRCADIA and JULIENNING, using the same evaluation metrics.

1) *General-purpose vs. CNN-dedicated solutions:* Experiments, as highlighted in Figure 4, show that CNN-dedicated solutions such as CIRCADIA and JULIENNING reduce the total energy consumption of an inference by an average of 35% compared to general-purpose solutions like SCHEMATIC.

The proportion of energy spent on checkpointing, shown in Figure 5, reveals an interesting yet surprising insight: SCHEMATIC spends less than 0.01% of its total energy on checkpointing, whereas CNN-specific solutions allocate between 2% and 2.5% of their total energy to this process. This indicates that SCHEMATIC's inefficiency is not due to excessive checkpointing but rather from a fundamental limitation. A key shortcoming of SCHEMATIC is that it does not support point-to analysis, making it allocate all pointer-accessed data in NVM. In contrast, CNN-dedicated approaches fully leverage their complete knowledge of the generated code, allowing them to accurately distinguish between data that should reside in VM and data that must be stored in NVM. As a result, SCHEMATIC executes much more slowly and consumes more energy, despite performing smaller checkpoints. In contrast, CIRCADIA and JULIENNING make a better use of VM to reduce the overall energy cost of inference.

In our application, the use of pointers is hard to avoid, as the matrices have to be transferred between layers. CNN-dedicated solutions leverage their complete understanding of the dataflow, effectively bypassing the need for complex pointer analysis required by general-purpose approaches. This further highlights the importance of developing domain-specific solutions tailored for CNN.

2) *CNN-dedicated checkpoint overhead:* CIRCADIA exhibits a total energy spent per inference that is, on average, 0.13 percentage point higher than that of JULIENNING, as shown in Figure 4. This difference drops to 0.03 percentage point for models larger than 500 elementary operations. As previously mentioned, the only difference between CIRCADIA and JULIENNING lies in their checkpoint placement strategies. Consequently, this difference in total energy translates directly into the proportion of energy spent on checkpointing, as illustrated in Figure 5. As CIRCADIA uses a greedy heuristic,
<figure><img src="image_6.png" /><figcaption>Fig. 4. Total energy spent per inference depending on model size. The energy consumption of Juliennin and Circadia is almost identical (curves overlap).</figcaption></figure>

<figure><img src="image_7.png" /><figcaption>Fig. 5. Checkpoint energy proportion depending on model size.</figcaption></figure>

the ratio of energy consumed for checkpointing operations in the generated code is systematically higher than that of the optimal solution computed by JULIENNING. Nevertheless, the maximum increase of checkpoint energy proportion is small (at most 0.4 percentage point), with an average increase of only 0.13 percentage point. We conclude that CIRCADIA incurs a checkpoint energy overhead nearly identical to JULIENNING, achieving close to optimal total energy overhead.

## D. Compile-time Checkpoint Placement Duration

We evaluate CIRCADIA and JULIENNING based on time required to compute a checkpoint placement, for both generated and real-world CNN architectures, and maximum model size computable within a given timeout value.

For a small generated model of size 15, JULIENNING determines a checkpoint placement in approximately 3.2 ms, whereas CIRCADIA computes it in about 0.015 ms, achieving a 206× speedup. For a larger generated model of 1059 elementary operations, JULIENNING requires approximately 1888 s, whereas CIRCADIA performs the computation in around 0.23 ms, which represents a 6 orders of magnitude acceleration. Additional results are provided in Figure 6, showcasing graphs that align with the cubic and linear complexities of JULIENNING and CIRCADIA, respectively. Not only is CIRCADIA consistently faster than JULIENNING across all scenarios, but its linear complexity also makes it significantly more scalable as model size increases.

To further evaluate the scalability of CIRCADIA, we analyzed two real-world CNN architectures, HAR and SqueezeNet,

<figure><img src="image_8.png" /><figcaption>Fig. 6. Checkpoint placement time depending on model size. JULIENNING (top) and CIRCADIA (bottom) scales diverge by 6 orders of magnitudes.</figcaption></figure>

<table><caption>TABLE III
MAXIMUM NUMBER OF ELEMENTARY OPERATIONS (|OP|), ALLOWING CHECKPOINTS TO BE PLACED WITH A DEFINED COMPUTATIONAL TIME BUDGET. N IS THE SAME AS DEFINED IN SECTION V-A1.</caption><thead><tr><th rowspan="2">Timeout</th><th colspan="2">CIRCADIA</th><th colspan="2">JULIENNING</th></tr><tr><th>|OP|</th><th>N</th><th>|OP|</th><th>N</th></tr></thead><tbody><tr><td>0.5 s</td><td>696,393</td><td>832</td><td>75</td><td>6</td></tr><tr><td>1.0 s</td><td>1,342,125</td><td>1156</td><td>93</td><td>7</td></tr><tr><td>2.0 s</td><td>2,642,253</td><td>1623</td><td>113</td><td>8</td></tr><tr><td>3.0 s</td><td>3,902,603</td><td>1973</td><td>135</td><td>9</td></tr><tr><td>4.0 s</td><td>5,237,235</td><td>2286</td><td>159</td><td>10</td></tr><tr><td>5.0 s</td><td>6,368,055</td><td>2521</td><td>159</td><td>10</td></tr></tbody></table>

described in Section V-A1. By extrapolating the results from Figure 6, JULIENNING would approximately take one day and 289 days to compute the respective checkpoint placements of HAR and SqueezeNet, whereas, after experimentation, CIRCADIA takes 0.95 ms and 10.5 ms respectively. This further reinforces the importance of CIRCADIA’s scalability, as it enables checkpoint placement strategies that remain computationally feasible even for models used in practice.

As a complementary extension to previous metrics, we evaluate the scalability of CIRCADIA and JULIENNING with respect to model size. To this end, Table III presents the maximum model size (elementary operations count) that each method can handle within specific timeout values. Experimental results exhibit that, for a fixed amount of time, CIRCADIA can compute checkpoint placements for significantly larger models than JULIENNING, 9k × larger for a 0.5 s timeout and 40k × larger for a 5 s timeout. This difference stems from the linear complexity of CIRCADIA compared to the cubic complexity of JULIENNING, making CIRCADIA more scalable.

In summary, CIRCADIA offers a solution that performs a checkpoint energy overhead nearly identical to the optimal, while being faster to compute and more scalable. This significant speed advantage makes it suitable for large models.
Researchers in the field of intermittent computing have
developed effective strategies to mitigate unpredictable power
failures. While these strategies vary, they all center around
checkpointing critical data at key moments to ensure correct
execution.

**Task-based** approaches rely on the user to divide the program into tasks, which are small, atomically executed snippets of code, such as collecting, processing, or transmitting data. The first method to propose this approach was DINO [27], which allows users to define task boundaries where data consistency is ensured. While DINO continues to use checkpoints, other techniques, such as *Chain* [28] or *Alpaca* [29], aim to isolate tasks by providing each one with its own dedicated processing memory. Unlike CIRCADIA, task-based approaches implies an user intervention to divide its code into smaller atomic tasks, which is automatically done by CIRCADIA's toolchain.

**Static checkpointing** aims to abstract intermittent execution from the user. These techniques operate at compile time, performing static code analysis to automatically place checkpoints at strategic positions. Historically, Mementos [11] was the first approach to address checkpointing in intermittent systems, proposing to place checkpoints at the end of each loop and at every function return. Later strategies, such as RockClimb [30] and SCHEMATIC [14], leverage WCEC estimates of the target system to more accurately predict potential energy shortage points and determine checkpoint locations. CIRCADIA, as well as JULIENNING [12] are static checkpoint placement techniques that are CNN-dedicated.

**Dynamic checkpointing** determines the optimal moments to checkpoint during execution, ensuring that it is only done when necessary. For instance, *Hibernus* [31] and *QuickRecall* [32] monitor the supply voltage, initiating a checkpoint when it falls below a critical threshold. Another approach, *So Far So Good* [33], traces the execution path until a power failure happens and places a checkpoint slightly before, adapting over time. Dynamic checkpointing techniques, in contrast to static ones, incur a run-time overhead to monitor available energy, and do not enforce forward progress.

More recently, complex projects including ML applications are now being adapted for intermittent execution [13]. Several approaches have been proposed to effectively embed CNNs in energy-constrained environments. Most modern embedded systems now integrate specialized hardware accelerators [19], [34], [35] to optimize computation efficiency. Some systems further leverage Processing-In-Memory technologies [36]–[38], enabling direct computations on NVM to reduce data movement and energy overhead. Research has also been conducted on how to reduce the energy and memory consumption of CNN models [39], often trading off some degree of accuracy, using techniques such as *Pruning* [40], *Quantization* [41], or *Multi-version computing* [35]. This research makes increasingly possible the use of ML applications in intermittent systems and motivates research like CIRCADIA.

This paper introduces CIRCADIA, an energy-efficient and fast static checkpoint placement method for CNN-based intermittent systems, enforcing forward progress and data consistency. Alongside CIRCADIA, we present a compilation toolchain that converts a CNN model into a ready-to-use C code including checkpoint placement. Experimental results demonstrate that CIRCADIA reduces energy consumption by 35% compared to state-of-the-art general-purpose techniques such as SCHEMATIC, while matching the energy efficiency of specialized techniques like JULIENNING. Compared to JULIENNING, CIRCADIA distinguishes itself through its significantly faster and more scalable checkpoint placement strategy, an observation realized through both generated and real-life models. This enables its application to larger models, thereby expanding its usability and impact.

*Discussion and Future Work:* In our work, we made a key design choice regarding checkpoint granularity. Our choice is mainly motivated by the existence of hardware accelerators that execute matrix convolutions atomically with low energy consumption (e.g., 17.8× lower with the LEA accelerator on the MSP430FR5994 [19]). Reducing the granularity further would increase the number of possible checkpoint positions, offering more flexibility in checkpoint placement. However, this would also reduce the efficient utilization of hardware accelerators, as checkpointing at a finer level might interrupt their optimized execution. Additionally, increasing the search space for checkpoint placement could significantly increase computation time. This finer granularity is left for future work.

Our application domains include remote and inaccessible environments, such as space missions or building foundations, where replacing failing system components is nearly impossible. Among these components, capacitors are particularly prone to energy capacity degradation over time, influenced by stress factors such as temperature, voltage, and humidity [42]. This degradation poses a significant threat to the Forward Progress property, as the available energy may fall below expected levels, potentially leading to critical system failures. However, since CIRCADIA is a static solution with fast computation time, it is feasible to generate and transmit an updated checkpoint placement adapted to the capacitor degradation.

Previous work [43] has highlighted that operating at higher voltages increases energy consumption for the same computations and that charge efficiency declines as the capacitor approaches full capacity. This suggests that operating at lower voltages not only improves energy efficiency but also reduces charging time. Additionally, in long-term deployment scenarios, capacitor degradation could prevent the system from reaching full charge, further highlighting the need for adaptive energy management strategies. A promising direction for future work is to address these two issues, by developing a checkpoint placement strategy that accounts for energy loss due to high-voltage execution, ultimately improving both execution efficiency and system longevity in intermittent computing environments.
REFERENCES

[1] M. Surbatovich, B. Lucia, and L. Jia, "Towards a formal foundation of intermittent computing," *Proc. ACM Program. Lang.*, 2020.

[2] B. Malik, V. Doychinov, A. Hayajneh, S. A. R. Zaidi, I. Robertson, and N. Somjit, "Wireless power transfer system for battery-less sensor nodes," *IEEE Access*, 2020.

[3] I. Zalbide, E. D'Entremont, A. Jiménez, H. Solar, A. Beriain, and R. Berenguer, "Battery-free wireless sensors for industrial applications based on UHF RFID technology," in *SENSORS*, 2014.

[4] L. Wang, Y. Yang, D. K. Noh, H. K. Le, J. Liu, T. F. Abdelzaher, and M. Ward, "AdaptSens: An adaptive data collection and storage service for solar-powered sensor networks," in *30th IEEE Real-Time Systems Symposium*, 2009.

[5] S. Priya and D. Inman, *Energy harvesting technologies*. Springer US, 2009.

[6] A. Curtiss, B. Rothrock, A. Bakar, N. Arora, J. Huang, Z. Englhardt, A.-P. Empedrado, C. Wang, S. Ahmed, Y. Zhang, N. Alshurafa, and J. Hester, "FaceBit: Smart face masks platform," *Proc. ACM Interact. Mob. Wearable Ubiquitous Technol.*, 2022.

[7] B. Denby and B. Lucia, "Orbital edge computing: Nanosatellite constellations as a new class of computer system," in *Twenty-Fifth International Conference on Architectural Support for Programming Languages and Operating Systems*, 2020.

[8] V. Lostanlen, A. Bernabeu, J.-L. Béchennec, M. Briday, S. Faucou, and M. Lagrange, "Energy efficiency is not enough: Towards a batteryless internet of sounds," in *Proceedings of the 16th International Audio Mostly Conference*, 2021.

[9] M. Afanasov, N. A. Bhatti, D. Campagna, G. Caslini, F. M. Centonze, K. Dolui, A. Maioli, E. Barone, M. H. Alizai, J. H. Siddiqui, and L. Mottola, "Battery-less zero-maintenance embedded sensing at the Mithræum of Circus Maximus," in *18th Conference on Embedded Networked Sensor Systems*, New York, NY, USA, 2020.

[10] B. Lucia, V. Balaji, A. Colin, K. Maeng, and E. Ruppel, "Intermittent computing: Challenges and opportunities." 2nd Summit on Advances in Programming Languages, 2017.

[11] B. Ransford, J. Sorber, and K. Fu, "Mementos: System support for long-running computation on RFID-scale devices," *SIGARCH Comput. Archit. News*, 2011.

[12] A. Gomez, A. Tretter, P. A. Hager, P. Sanmugarajah, L. Benini, and L. Thiele, "Dataflow driven partitioning of machine learning applications for optimal energy use in batteryless systems," *ACM Trans. Embed. Comput. Syst.*, 2022.

[13] M. G. S. Murshed, C. Murphy, D. Hou, N. Khan, G. Ananthanarayan an, and F. Hussain, "Machine learning at the network edge: A survey," *ACM Computing Survey*, 2021.

[14] H. Reymond, J.-L. Béchennec, M. Briday, S. Faucou, I. Puaut, and E. Rohou, "Schematic: Compile-time checkpoint placement and memory allocation for intermittent systems," *IEEE/ACM International Symposium on Code Generation and Optimization*, 2023.

[15] K. Fukushima, "Visual feature extraction by a multilayered network of analog threshold elements," *IEEE Transactions on Systems Science and Cybernetics*, 1969.

[16] D. Reiman, A. A. Metwally, J. Sun, and Y. Dai, "Popphy-cnn: A phylogenetic tree embedded architecture for convolutional neural networks to predict host phenotype from metagenomic data," *IEEE Journal of Biomedical and Health Informatics*, 2020.

[17] Y. Lecun, L. Bottou, Y. Bengio, and P. Haffner, "Gradient-based learning applied to document recognition," *Proceedings of the IEEE*, 1998.

[18] *MSP430FR58xx, MSP430FR59xx, and MSP430FR6xx Family User's Guide*, 2012. [Online]. Available: https://www.ti.com/lit/ug/slau367p/slau367p.pdf

[19] *Benchmarking the Signal Processing Capabilities of the Low-Energy Accelerator on MSP430™ MCUs*, 2016. [Online]. Available: www.ti.com/lit/an/slaa698b/slaa698b.pdf

[20] B. Himmetoglu, *CNN Model for Human Activity Recognition*, 2017. [Online]. Available: https://github.com/healthDataScience/deep-learning-HAR

[21] F. N. Iandola, S. Han, M. W. Moskewicz, K. Ashraf, W. J. Dally, and K. Keutzer, "Squeezenet: AlexNet-level accuracy with 50x fewer parameters and <0.5 MB model size," 2016.

[22] C.-H. Yen, H. R. Mendis, T.-W. Kuo, and P.-C. Hsiu, "Keep in balance: Runtime-reconfigurable intermittent deep inference," *ACM Trans. Embed. Comput. Syst.*, 2023.

[23] A. Maioli, L. Mottola, M. H. Alizai, and J. H. Siddiqui, "Discovering the hidden anomalies of intermittent computing," in *Proceedings of the 2021 International Conference on Embedded Wireless Systems and Networks*, ser. EWSN 2021, 2021.

[24] C. Lattner and V. Adve, "LLVM: a compilation framework for lifelong program analysis & transformation," in *International Symposium on Code Generation and Optimization*, 2004.

[25] *MSP430FR596x, MSP430FR594x Mixed-Signal Microcontrollers*, 2012. [Online]. Available: https://www.ti.com/lit/ds/symlink/msp430fr5969.pdf

[26] A. Sheikholeslami and P. Gulak, "A survey of circuit innovations in ferroelectric random-access memories," *Proceedings of the IEEE*, 2000.

[27] B. Lucia and B. Ransford, "A simpler, safer programming and execution model for intermittent systems," *SIGPLAN Not.*, 2015.

[28] A. Colin and B. Lucia, "Chain: tasks and channels for reliable intermittent programs," *ACM International Conference on Object-Oriented Programming, Systems, Languages, and Applications*, 2016.

[29] K. Maeng, A. Colin, and B. Lucia, "Alpaca: Intermittent execution without checkpoints," *Proc. ACM Program. Lang.*, 2017.

[30] J. Choi, L. Kittinger, Q. Liu, and C. Jung, "Compiler-directed high-performance intermittent computation with power failure immunity," in *IEEE 28th Real-Time and Embedded Technology and Applications Symposium*, 2022.

[31] D. Balsamo, A. S. Weddell, G. V. Merrett, B. M. Al-Hashimi, D. Brunelli, and L. Benini, "Hibernus: Sustaining computation during intermittent supply for energy-harvesting systems," *IEEE Embedded Systems Letters*, 2015.

[32] H. Jayakumar, A. Raha, and V. Raghunathan, "QuickRecall: A low overhead HW/SW approach for enabling computations across power cycles in transiently powered computers," in *27th International Conference on VLSI Design and 13th International Conference on Embedded Systems*, 2014.

[33] B. Yarahmadi and E. Rohou, "So far so good: Self-adaptive dynamic checkpointing for intermittent computation based on self-modifying code," in *Proceedings of the 24th International Workshop on Software and Compilers for Embedded Systems*, 2021.

[34] H. Desai and B. Lucia, "A power-aware heterogeneous architecture scaling model for energy-harvesting computers," *IEEE Computer Architecture Letters*, 2020.

[35] A. Bakar, R. Goel, J. de Winkel, J. Huang, S. Ahmed, B. Islam, P. Pawelczak, K. S. Yıldırım, and J. Hester, "Protein: An energy-efficient and heterogeneous platform for adaptive and hardware-accelerated battery-free computing," in *20th Conference on Embedded Networked Sensor Systems*, 2023.

[36] Z. Chowdhury, J. D. Harms, S. K. Khatamifard, M. Zabihi, Y. Lv, A. P. Lyle, S. S. Sapatnekar, U. R. Karpuzcu, and J.-P. Wang, "Efficient in-memory processing using spintronics," *IEEE Computer Architecture Letters*, 2018.

[37] S. Resch, S. K. Khatamifard, Z. I. Chowdhury, M. Zabihi, Z. Zhao, H. Cilasun, J.-P. Wang, S. S. Sapatnekar, and U. R. Karpuzcu, "Mouse: Inference in non-volatile memory for energy harvesting applications," in *53rd Annual IEEE/ACM International Symposium on Microarchitecture*, 2020.

[38] K. Akhunov and K. S. Yildirim, "LUTIC: A cram-based architecture for power failure resilient in-memory computing," in *26th International Symposium on Design and Diagnostics of Electronic Circuits and Systems*, 2023.

[39] G. Gobieski, B. Lucia, and N. Beckmann, "Intelligence beyond the edge: Inference on intermittent embedded systems," in *the 24th International Conference on Architectural Support for Programming Languages and Operating Systems*, 2019.

[40] R. Reed, "Pruning algorithms-a survey," *IEEE Transactions on Neural Networks*, 1993.

[41] S. Zhuo, H. Chen, R. K. Ramakrishnan, T. Chen, C. Feng, Y. Lin, P. Zhang, and L. Shen, "An empirical study of low precision quantization for TinyML," in *tinyML Research Symposium'22*, 2022.

[42] D. DeVoto, J. Major, A. Gupta, and O. Yadav, "A review of degradation behavior and modeling of capacitors," in *ASME International Technical Conference and Exhibition on Packaging and Integration of Electronic and Photonic Microsystems*, 2018.

[43] H. Reymond, J.-L. Béchennec, M. Briday, S. Faucou, I. Puaut, and E. Rohou, "EarlyBird: Energy belongs to those who wake up early," in *Proceedings of the 30th IEEE International Conference on Embedded and Real-Time Computing Systems and Applications*, 2024.