# ADAM: ADAptive microcontroller platform for edge AI systems

Felipe Paiva Alencar, Aymen Romdhane, Bruno Lovison-Franco, Yann Guilhot, Jonathan Miquel, Theo Soriano, David Novo, Pascal Benoit

## ► To cite this version:

Felipe Paiva Alencar, Aymen Romdhane, Bruno Lovison-Franco, Yann Guilhot, Jonathan Miquel, et al.. ADAM: ADAptive microcontroller platform for edge AI systems. RSP 2025 - 36th International Symposium on Rapid System Prototyping, Sep 2025, Taipei, Taiwan. hal-05390255

HAL Id: hal-05390255

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

Submitted on 1 Dec 2025

HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published 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
# ADAM: ADAptive Microcontroller Platform for Edge AI Systems

Felipe Paiva Alencar¹ Aymen Romdhane¹² Bruno Lovison Franco¹ Yann Guilhot¹
Jonathan Miquel² Théo Soriano¹ David Novo¹ Pascal Benoit¹

¹LIRMM, Univ. Montpellier, CNRS   ²Univ. Grenoble Alpes, CEA, CNRS, Grenoble INP, SPINTEC

## Abstract

Modern edge computing systems must balance performance and energy efficiency under constrained power budgets. We present ADAM (ADAptive Microcontroller), an open-source and parametric RISC-V platform designed to explore architectural and software-level mechanisms for energy-aware embedded computing. ADAM supports heterogeneous cores organized into separate low-power and high-performance domains, enabling partitioned execution across a range of workload intensities. The platform introduces the Activity Pause Protocol, a software-driven interface for coordinating clock and power gating transitions, and includes a hybrid evaluation flow that combines FPGA execution with post-synthesis RTL simulation using execution context snapshotting. We demonstrate ADAM's capabilities with a keyword spotting use case, highlighting how domain separation and programmable power management reduce energy consumption by up to 38% in intermittent workloads.

## CCS Concepts

* Computer systems organization → Embedded systems; Heterogeneous (hybrid) systems; Embedded systems; Hardware → Power estimation and optimization; Reconfigurable logic and FPGAs.

## Keywords

Edge Computing, RISC-V, TinyML

## ACM Reference Format:

Felipe Paiva Alencar, Aymen Romdhane, Bruno Lovison Franco, Yann Guilhot, Jonathan Miquel, Théo Soriano, David Novo, and Pascal Benoit. 2025. ADAM: ADAptive Microcontroller Platform for Edge AI Systems. In *36th International Workshop on Rapid System Prototyping (RSP '25), September 28-October 3 2025*, Taipei, Taiwan. ACM, New York, NY, USA, 7 pages. https://doi.org/10.1145/3768617.3770731

## 1 Introduction

The Internet of Things (IoT) has transformed how we interact with technology. Everyday objects are now connected, enabling data collection, analysis, and automation. This connectivity benefits a wide range of applications, from smart homes to industrial systems and smart cities, enhancing efficiency and quality of life.

With the growing number of IoT devices, traditional cloud-based architectures struggle to handle rising data volumes, causing network bottlenecks and security concerns. Edge computing addresses this by decentralizing processing, shifting part of the workload from the cloud to the edge, closer to where data is generated.

In this work, we introduce ADAM (ADAptive Microcontroller), a parametric and extensible open-source RTL platform designed for IoT and Edge Computing. Its parametric design enables extensive customization, allowing users to configure the number and type of RISC-V cores, memory blocks, and peripherals. Its extensibility further supports the integration of additional RISC-V core implementations, making it adaptable to a wide range of application needs. The architecture can be divided into separate domains: one optimized for high performance and the other for low power. This partitioning coupled with a custom hardware protocol for fine-grained, software-controlled power management makes ADAM particularly well-suited for exploring intermittent computing scenarios.

We validate ADAM on a representative keyword spotting application, where an energy-efficient core continuously monitors audio input, while a high-performance core is activated only for compute-intensive tasks (e.g., TinyML inference). Our results show that domain-level partitioning and software-driven power gating reduce energy consumption by up to 38%.

In summary, this work makes the following contributions:

* We present ADAM, a parametric and open-source microcontroller platform based on heterogeneous RISC-V cores, designed for energy-efficient intermittent computing.

* We introduce the Activity Pause Protocol, a lightweight and software-controlled interface for managing clock and power gating in a predictable and portable way.

* We propose a hybrid evaluation methodology that enables snapshot-based migration from FPGA execution to RTL simulation, bridging real-time testing with detailed energy analysis.

* We present an experimental validation on a realistic keyword spotting pipeline. We demonstrate how ADAM enables partitioned execution and fine-grained power management in a TinyML use case, achieving up to 38% energy savings.

* We open-source ADAM [1] to facilitate and encourage open research and agile implementation of new ideas in edge computing.

## 2 Hardware Architecture

This section outlines the ADAM hardware architecture, which is implemented in SystemVerilog and organized into two separate domains: a high-speed domain (HSD) for performance tasks and a low-power domain (LPD) for energy-efficient operation. We describe their main components, the core-agnostic integration interface, the interconnect fabric, and the Activity Pause Protocol (APP), which enables software-controlled power management.

<footnote>Publication rights licensed to ACM. ACM acknowledges that this contribution was authored or co-authored by an employee, contractor or affiliate of a national government. As such, the Government retains a nonexclusive, royalty-free right to publish or reproduce this article, or to allow others to do so, for Government purposes only. Request permissions from owner/author(s).

**RSP '25, Taipei, Taiwan**

© 2025 Copyright held by the owner/author(s). Publication rights licensed to ACM.

ACM ISBN 979-8-4007-2224-0/2025/09

https://doi.org/10.1145/3768617.3770731</footnote>
<figure><img src="image_2.png" /><figcaption>Figure 1: ADAM block diagram.</figcaption></figure>

## 2.1 ADAM Overview

Figure 1 illustrates the main architectural components of ADAM, organized in two distinct domains. The HSD is designed for the rapid execution of moderately high-performance tasks and comprises the following components: (1) An arbitrary number of RISC-V cores, customizable to the application's performance requirements; (2) a shared debug module providing debug support for all cores in this domain; and (3) an arbitrary number of general-purpose memory banks, usable for storing instructions and data.

In contrast, the LPD is designed for low power consumption and targets the execution of continuous, low-performance tasks. It comprises the following components: (1) A low-power RISC-V core, where the specific implementation can be selected by the user to best suit the energy efficiency requirements; (2) a dedicated memory bank enabling the low-power core to operate independently of the high-speed domain; (3) various peripherals for interfacing with external devices and sensors; and (4) the System Configuration (SYSCFG) peripheral, which allows software control over architectural configuration parameters, such as boot addresses and power state management.

Communication between these components is handled by an interconnect fabric (detailed in Section 2.3), consisting of crossbars and buses, as depicted in the figure.

## 2.2 Core-Agnostic Design

A key feature of ADAM is its core-agnostic architecture, which is not tied to any specific RISC-V core implementation. This design choice allows users to integrate different open-source cores depending on their needs, whether to achieve better performance, improve energy efficiency, or support specific RISC-V extensions. It also enables fair evaluation of different cores within the same system, under identical conditions.

To provide this flexibility, ADAM defines a standard core wrapper interface that new cores must conform to. The interface is designed to accommodate most RISC-V cores available in the open-source community. Listing 1 shows a code snippet of the required wrapper module, which defines the following interface: (1) Two AXI4-Lite master interfaces (one for instruction access and one for data); (2) a single interrupt line (with plans to extend this to full PLIC support in future work); (3) debug request and debug unavailable signals for integration with ADAM's debug infrastructure; (4) clock

<caption>Listing 1: Wrapper to include arbitrary cores in ADAM</caption>

```c
module adam_core.wrapper #(
    `ADAM_CFG_PARAMS
) (
    ADAM_SEQ.Slave seq,
    ADAM_pause.Slave pause,

    input ADDR_T boot_addr,
    input DATA_T hart_id,

    AXI_LITE axil_inst,
    AXI_LITE的一部分 axil_data,

    input logic irq,

    input logic debug_req,
    output logic debug_unavail
);
```

and reset signals from the sequential interface (seq); (5) support for the Activity Pause Protocol (pause), enabling external power management of the core (see Section 2.4); and (6) hart_id input to uniquely identify the hardware thread at runtime.

To simplify the integration process, ADAM provides reusable components for common scenarios. For example, many open-source RISC-V cores expose memory ports using the OBI (Open Bus Interface) protocol. ADAM includes the OBI-to-AXI4-Lite bridge module to simplify connecting such cores.

Cores successfully integrated with this approach include Ibex [8] and CV32E40P [11]. The wrapper also supports cores with tightly coupled accelerators, such as vector units, by bundling the accelerator alongside the RISC-V core, allowing ADAM to interact with the ensemble as a standard core instance.

## 2.3 Energy-Efficient Interconnect Fabric

The ADAM interconnect fabric mainly uses the AXI4-Lite protocol, a simplified AXI version designed for simple, low-throughput peripheral access. It removes features like out-of-order completion and burst transfers, reducing complexity while maintaining sufficient performance for edge applications. For peripheral buses, we use the APB protocol. Though non-pipelined and lower in performance, APB is more compact and suitable for connecting many low-throughput peripherals.

A key characteristic of the ADAM interconnect fabric is that it is split across two domains as shown in Figure 1. The purpose of this split is to better support intermittent computing. By partitioning the fabric, we can power down not only the high-speed core but also the interconnect and memories associated with the HSD, thereby reducing static power consumption during idle phases.

This partitioning also brings benefits in terms of area efficiency. Since crossbars have quadratic area complexity (proportional to the number of initiators times the number of targets), splitting the fabric helps reduce the overall size. Similarly, we use two peripheral buses: one that can be powered down along with most peripherals during idle periods, and another dedicated to essential peripherals that must remain active.

Finally, all elements of the fabric implement the Activity Pause Protocol (detailed in Section 2.4), enabling fine-grained power state control that is accessible to software.
## 2.4 Power Management Protocol

To reduce energy consumption in modern compute systems, it is essential to minimize power usage during idle periods. One of the most effective strategies for achieving this is the use of clock and power gating, which disable unused logic blocks to save energy when they are idle or not in use. The main challenge is applying these techniques safely in our architecture. We aim for software-controlled power management that avoids invalid states, for example, turning off a module that still has in-flight memory transactions.

To address this, we introduce the Activity Pause Protocol (APP), a standardized way to safely apply clock and power gating. The protocol defines two roles: an initiator and a target. The initiator requests transitions between power states, which the target must acknowledge and act upon. To this end, the protocol defines four signals: the initiator controls *clk* (clock), *rst* (reset), and *req* (request), while the target controls *ack* (acknowledge). The protocol also defines three power states:

* **Active:** The normal state where internal logic is active and updates every clock cycle. The target enters this state when either *req* or *ack* is deasserted (0) and *rst* is also deasserted (0).

* **Pause:** Safe state for clock gating. Internal logic is held stable. The target is in this state when both *req* and *ack* are asserted (1). The *rst* signal remains deasserted (0).

* **Stop:** Safe state for clock and power gating where the internal state can be lost. The target is in this state when *req*, *ack*, and *rst* are all asserted (1).

The protocol is designed for hierarchical use. For example, a peripheral with transmitter and receiver modules might have each module implement the protocol independently. The top-level entity forwards requests and relays acknowledgments, but it can also independently manage power for submodules when they are idle, enabling fine-grained power control across the design.

Transitions to a different power state can be controlled by software through a dedicated system configuration peripheral (SYSCFG in Figure 1). This peripheral provides software-accessible registers that allow the user to request transitions for each core, peripheral, or broader power domain (such as the entire high-speed domain), including parts of the interconnect. This setup enables flexible and programmable power management throughout the system.

The protocol defines abstract states only. The actual clock and power gating implementations are left to the designer at synthesis time. This flexibility means that if adding gates at the module level introduces too much overhead, the design can remain unchanged. Typically, only the top-level module incurs physical overhead for power saving, and the required control signals can be derived from *req*, *ack*, *clk*, and *rst* using simple logic.

Figure 2 provides an example of how clock and power gating can be implemented for a module to follow the Activity Pause Protocol. Importantly, this is a generic implementation sketch that does not require custom logic specific to any given module. This design could either be inserted at the RTL level via code transformations or inferred automatically by the logic synthesis tool.

## 3 Build System and Tooling

ADAM is designed to support both FPGA prototyping and ASIC synthesis, requiring flexible yet consistent management of hardware

<figure><img src="image_3.png" /><figcaption>**Figure 2: Clock and power gating physical implementation sketch. APP signals can drive generic clock-gating logic and power switches without custom module-specific design.**</figcaption></figure>

configurations across a wide range of experimental setups. Varying the number and type of RISC-V cores, peripherals, or memory mappings is often needed for different applications or deployment scenarios. Managing these architectural variants consistently across simulation, synthesis, and software flows is key for reproducibility and efficient iteration.

To address this, ADAM employs a unified build system centered around a configuration file, *adam.yml*, which specifies architectural hyperparameters and defines a set of build targets—each corresponding to a distinct ADAM instance. This centralization guarantees consistency across all stages of the hardware-software toolchain. A companion script, *adam.py*, parses the configuration and orchestrates the necessary workflows, including RTL simulation, FPGA bitstream generation, and software compilation.

Hardware source files are organized into modular file sets, each corresponding to a self-contained component such as a specific RISC-V core or a third-party IP block. These modules explicitly declare their dependencies, allowing the build system to automatically compose the correct subset of SystemVerilog files for a given configuration. This modular structure simplifies architectural exploration and avoids code duplication.

ADAM achieves flexibility through the extensive use of SystemVerilog parameters and reusable, generic building blocks. This design approach enables rapid prototyping of diverse architectural configurations with minimal manual intervention, while preserving transparency and maintainability in the hardware design flow.

To ensure reproducibility and minimize environment-specific issues, we provide a Dockerized development environment. The container includes the open-source RISC-V GNU toolchain, OpenOCD for debugging, and all Python dependencies used by the build system. Proprietary tools such as QuestaSim and Vivado are mounted from the host machine into the container, preserving licensing constraints while maintaining portability. A helper script detects host environment variables (e.g., license servers, X11 display) and generates the appropriate Docker command, enabling features like graphical waveform viewing with X11 pass-through. The ADAM toolchain integrates the following key components:

* **RISC-V GNU Toolchain:** Used to compile software targeting the RISC-V cores instantiated in ADAM platforms.
* **QuestaSim**: Enables cycle-accurate RTL simulation and waveform-based debugging.

* **Vivado**: Used for logic synthesis, implementation, and bitstream generation for AMD/Xilinx FPGAs.

* **OpenOCD & GDB**: Used for on-chip debugging and software bring-up on ADAM platforms.

* **Synopsis Design Compiler / PrimePower**: Used for ASIC synthesis and post-synthesis power analysis, respectively.

We also supply installation scripts that automatically clone sub-modules, apply required patches, and build the documentation. The documentation includes step-by-step tutorials on common work-flows such as environment setup, simulation, bitstream generation, and debugging, helping users adopt and extend the ADAM platform.

## 4 Software

While ADAM's hardware is designed for configurability, supporting diverse architectural variants at the software level presents its own set of challenges. In particular, software must avoid hard-coded assumptions and remain portable across a variety of ADAM instances—each potentially featuring different cores, peripherals, or memory layouts. To address this, we implement two software abstraction layers: the Register Abstraction Layer (RAL) and the Hardware Abstraction Layer (HAL).

The RAL is an auto-generated C header that defines packed C structures matching the exact memory layout of ADAM peripherals. It also defines an additional structure for the memory map, containing pointers to these peripheral structures, which allows easy and flexible access without hard-coded addresses. Bit-fields expose single-bit flags directly, eliminating the need for manual bit-wise operations. Thanks to unions, both word-level and flag-level access are supported. Listing 2 shows an example using the RAL abstraction to transmit a character via UART 0.

The HAL is a C library built on top of the RAL, designed to make ADAM easier to use by application developers by abstracting hardware details behind an API. Listing 3 shows a simple example that initializes a UART and sends a message using the HAL. The HAL also provides libgloss bindings for newlib, enabling standard C functions such as printf, and provides utilities to save/restore processor state during power gating and managing the boot sequence.

<caption>**Listing 2: RAL definition, mapping, and usage example**</caption>

```c
1 typedef struct {
2     ral_data_t DR;
3     union {
4         ral_data_t CR;
5         struct {
6             ral_data_t PE : 1; // Peripheral Enable
7             ...
8         };
9     };
10 } ral_utf_t;
11 ral_t RAL = {
12     .LSPA.UART = { (ral_utf_t *) 0x00010800 }
13 };
14 int main() {
15     // Other UART0 configuration
16     RAL.LSPA.UART[0]->PE = 1; // Enable UART0
17     RAL.LSPA.UART[0]->DR = 'A'; // Transmit 'A'
18     return 0;
19 }
```

<caption>**Listing 3: Example use of HAL**</caption>

```c
1 hal_utf_t utf = {
2     .baudrate = 115200,
3     .instance = RAL.LSPA.UART[0]
4 };
5 hal_utf_init(&utf);
6 hal_utf_write(&utf, "Hello World!
", 13);
```

## 5 FPGA Deployment

ADAM is primarily designed for ASIC deployment, with native support for clock and power gating, enabling detailed Power, Performance, and Area (PPA) characterization through post-synthesis simulation. While such simulations are essential for accurate energy estimation, they are extremely time-consuming. For example, simulating just 1 millisecond of execution at 50 MHz takes approximately 30 minutes, rendering full-application simulations impractical. RTL simulation is also prohibitively slow for debugging complex software, further motivating the need for faster alternatives during development. To address these limitations, ADAM also supports prototyping on FPGAs.

### 5.1 FPGA Support for Software Development

The ADAM prototype is implemented on a Digilent Nexys Video board [6], with the full setup shown in Figure 3. The system includes a PMOD microphone module for input, USB connections for UART and JTAG communication, a JTAG-HS2 probe for debugging [5], and an external power supply. In this FPGA model, the JTAG interface used to load the bitstream is not accessible to the user RTL, requiring a second JTAG interface for runtime debugging.

The system includes peripheral modules such as GPIO, UART, SPI, and a TIMER, enabling ADAM to communicate with external devices. These interfaces make it possible to connect ADAM to a wide range of sensors and communication modules. For example, they would allow integration with a board featuring a camera and a LoRa radio, as used in the platform described by Soriano et al. [13], supporting scenarios such as visual sensing and long-range wireless communication for edge applications.

<figure><img src="image_4.png" /><figcaption>**Figure 3: FPGA prototype of ADAM on the Digilent Nexys Video board.**</figcaption></figure>
Debugging on FPGA is often limited due to reduced internal
signal visibility and the impracticality of using simulation for long-
running applications. To address this, ADAM includes a JTAG debug
interface located in the high-speed domain, enabling runtime in-
spection and control using GDB. This feature is implemented with
the open-source riscv-dbg module from the PULP platform [12].

## 5.2 FPGA Support for Fast Energy Estimation

Although FPGA execution enables fast functional validation and performance measurement, power estimation still requires RTL simulation. A common workaround is to simulate short applications that approximate segments of a larger workload. However, even these minimal applications often incur substantial initialization overhead, reducing efficiency. Moreover, manually partitioning complex applications risks introducing inaccuracies in control flow or memory layout.

To overcome this, we developed a snapshotting mechanism that captures the complete architectural state during FPGA execution, allowing the same state to be restored in RTL simulation. This enables targeted RTL simulation of specific execution segments, bypassing initialization phases. Resuming from a snapshot requires only 15 microseconds of simulated time (~30 seconds) to restore the full execution context.

The snapshot process involves saving all relevant state, including general-purpose registers and control and status registers, in memory. A dedicated routine stores this state on the stack, after which the contents of each memory bank are dumped into files. These memory dumps are loaded into the RTL simulation, where the system detects the saved context and resumes execution accordingly. While the current implementation supports multi-core configurations, restoring execution requires manual adjustments to the restore script for proper coordination across cores and peripherals. Making this process more automated and general remains an area for future improvement.

# 6 Experimental Results

To evaluate ADAM in realistic deployment scenarios, we assess its performance and energy behavior using a representative edge computing workload. Our evaluation combines hardware execution on an FPGA for functional validation and performance measurement, with RTL-level simulation for cycle-accurate power estimation.

## 6.1 Edge Use Case: Keyword Spotting

Keyword spotting (KWS) serves as a representative workload for intermittent computing, as it naturally follows an event-driven paradigm under strict energy constraints. In this use case, the system remains in a low-power idle state while continuously monitoring incoming audio. It passively listens for relevant acoustic events—typically spoken keywords—and only activates compute-intensive processing when such an event is detected.

Our implementation is based on the Micro Speech Example [14] from the TensorFlow Lite for Microcontrollers (TFLM) framework [4] and follows the general processing pipeline shown in Figure 4. Audio is sampled at 16 kHz via an SPI-connected microphone, with

each recording window spanning 980 ms to accommodate overlapping temporal windows and improve temporal resolution. Following the structure proposed in [15], the pipeline consists of two main stages:

<figure><img src="image_5.png" /><figcaption>Figure 4: Overview of the KWS processing pipeline.</figcaption></figure>

* **Feature Extraction:** The recorded audio is processed to compute Mel-Frequency Cepstral Coefficients (MFCCs), which provide a compact and perceptually relevant representation of the signal's spectral characteristics. This stage is implemented entirely with integer arithmetic to ensure compatibility with resource-constrained embedded systems.

* **Inference:** The resulting MFCC features are fed into a Depthwise Separable Convolutional Neural Network (DS-CNN), which factorizes standard convolutions into depthwise and pointwise operations to reduce both compute and memory complexity. The model is statically quantized to 8-bit integers (INT8) across all weights and activations, with the exception of the input audio recording, which remains in 16-bit format.

To avoid unnecessary energy consumption on silent or irrelevant input, we introduce a lightweight signal-power check prior to feature extraction. This component operates in real time on the 16-bit audio stream, continuously estimating signal energy using a simple accumulation of squared sample amplitudes over a sliding window. If the energy falls below a predefined threshold, the system remains in its idle state, bypassing the compute-intensive stages of the pipeline. This pre-filtering mechanism significantly reduces the number of inference activations and, consequently, the overall energy consumption. Importantly, it introduces minimal computational overhead and fits naturally within the constraints of low-power embedded cores.

## 6.2 Experimental Setup

To leverage the event-driven nature of the KWS application, we configure ADAM as a heterogeneous dual domain architecture:

* **High-speed domain (HSD):** One CV32E40P, which is 32-bit, in-order RISC-V core featuring a 4-stage pipeline that implements the rv32imc ISA.

* **Low-power domain (LPD):** One Ibex, which is 32-bit, in-order RISC-V core featuring a 2-stage pipeline that implements the rv32imc ISA.
* **Memory:** two memory banks of 512 KiB each in HSD (separate instruction and data), and one 4 KiB memory bank in LPD (shared instruction and data).

* **Peripherals:** GPIO, UART, SPI, two TIMERs, and a debug module.

The design leverages the complementary strengths of the two cores. The Ibex core, with its simplified pipeline and minimal memory footprint, is well-suited for lightweight, always-on tasks such as audio acquisition and power-level detection. In contrast, the CV32E40P is employed for the compute-intensive MFCC extraction and DS-CNN inference, benefiting from its higher performance. This functional partitioning aims to reduce overall energy consumption without compromising responsiveness, a claim supported with detailed profiling in the next section.

The SPI connects to the microphone, while GPIO and UART handle debugging and data visualization. Two hardware timers are used: one for 16 kHz audio sampling interrupts, the other for independent performance monitoring.

The application is deployed on an FPGA for real-time execution, as described in Section 5. The debug module enables a snapshotting mechanism that allows execution to run on hardware up to a defined point, at which the full system state is saved. From that point, execution resumes in post-synthesis simulation using QuestaSim and Synopsys PrimePower, enabling detailed power estimation.

The design used in RTL simulation is synthesized with Synopsys Design Compiler targeting GlobalFoundries 22FDX technology. This hybrid flow preserves realistic runtime behavior observed in hardware, while enabling cycle-accurate power analysis on selected execution segments.

## 6.3 Execution Profiling and Power Analysis

To evaluate the behavior and energy efficiency of the system, we break down the KWS application into four key execution phases:

(1) **TFLM Initialization:** Sets up the TensorFlow Lite Micro (TFLM) environment, including model and operator initialization.

(2) **Recording:** Captures raw audio from the microphone and computes signal power level to detect silence.

(3) **Preprocessing:** Extracts Mel-frequency Cepstral Coefficients (MFCCs) from the recorded audio.

(4) **Inference:** Runs the DS-CNN model on the MFCC features to produce a prediction.

To highlight the advantages of ADAM's support for intermittent computing, we compare two application mappings:

(1) **Baseline:** All application phases run on the CV32E40P core in the high-speed domain (HSD).

<table><caption>**Table 1:** Cycle count, time, average power, and energy consumption for each application phase.</caption><thead><tr><th>Execution Phase</th><th>Domain</th><th>Cycles</th><th>Time</th><th>Power</th><th>Energy</th></tr></thead><tbody><tr><td>TFLM Init.</td><td>HSD</td><td>7.91 M</td><td>0.16 s</td><td>1.88 mW</td><td>296.9 μJ</td></tr><tr><td>Recording</td><td>HSD</td><td>49.5 M</td><td>0.99 s</td><td>1.58 mW</td><td>1568.7 μJ</td></tr><tr><td>Preprocessing</td><td>HSD</td><td>17.5 M</td><td>0.35 s</td><td>1.69 mW</td><td>591.8 μJ</td></tr><tr><td>Inference</td><td>HSD</td><td>57.5 M</td><td>1.15 s</td><td>1.69 mW</td><td>1943.1 μJ</td></tr><tr><td>Recording</td><td>LPD</td><td>49.5 M</td><td>0.99 s</td><td>0.97 mW</td><td>964.6 μJ</td></tr></tbody></table>

<figure><img src="image_6.png" /><figcaption>**Figure 5:** Power profile during the recording phase on the CV32E40P. Peaks correspond to 16 kHz timer events.</figcaption></figure>

<figure><img src="image_7.png" /><figcaption>**Figure 6:** Partitioned execution schedule.</figcaption></figure>

(2) **Partitioned:** The Ibex core in the low-power domain (LPD) handles recording and energy detection, waking the CV32E40P only for preprocessing and inference.

For each execution phase mapping, we measure cycle count, execution time, average power, and total energy consumption. Results are summarized in Table 1. In our experiment, power-state transitions account for under 0.01% of cycles and energy. The impact is negligible overall yet may become relevant with frequent switching.

The power profile for the CV32E40P during the recording phase is shown in Figure 5. Power peaks correspond to 16 kHz timer events, during which an audio sample is captured and processed. Between interrupts, the core enters the wait-for-interrupt (WFI) state and power consumption drops.

Although the recording phase takes the same number of cycles in both mappings—since the duration is fixed by the 980 ms audio window sampled at 16 kHz—its power behavior differs. The CV32E40P processes the samples faster and spends more time in the wait-for-interrupt (WFI) state, but it consumes more power during active processing. Overall, the energy consumption in the partitioned mapping is 38.5% lower than in the baseline mapping.

We estimated energy consumption by numerically integrating power traces over the execution period, with start and end times derived from cycle counts at a 50 MHz clock. Figure 6 shows the power profile of the partitioned mapping. Initialization occurs only once, while the recording phase may repeat until a non-silent segment is encountered. In the partitioned version, this loop is handled by the Ibex; in the baseline, all phases run on the CV32E40P. The structure of the schedule remains identical, but the active core changes.
<figure><img src="image_8.png" /><figcaption>**Figure 7: Energy savings achieved by partitioned mapping relative to baseline, as a function of accumulated silent audio duration before inference.**</figcaption></figure>

The energy-efficiency gain of partitioned mapping depends on the silence duration between inferences. As shown in Figure 7, a 60-second interval already yields over 37.5% improvement, with gains increasing and approaching the maximum savings when inference occurs only once across multiple recordings. These results illustrate the types of experiments enabled by ADAM rather than fully optimized configurations. More aggressive power-mode use and alternative task mappings could further improve efficiency, which we leave for future work.

## 7 Related Work

Several open-source RTL platforms have been developed around the RISC-V ecosystem. To our knowledge, ADAM is the first RISC-V microcontroller platform to integrate domain-level heterogeneity, software-controlled power management, and a hybrid FPGA/RTL flow for accurate energy analysis in intermittent computing.

Previous efforts such as ICOBS [13] address intermittent execution with state preservation but rely on a monolithic architecture and do not support runtime-configurable power domains. PULP [3] offers a rich multi-core microcontroller platform with diverse IP components, yet it targets high-performance IoT applications by coupling a microcontroller with a multi-core compute cluster. Similarly, modular SoC platforms like X-HEEP [9] and ESP [10] enable rapid prototyping and IP reuse but offer limited or no support for dynamic power gating or domain-level isolation. In contrast, ADAM is explicitly designed for energy-constrained, intermittent edge computing, providing software-visible control over power domains to enable fine-grained, application-aware energy management.

From a methodology perspective, Strober [7] interleaves FPGA and RTL simulation to estimate power via regression models trained on sampled activity. While scalable, it prioritizes coverage over accuracy. ADAM adopts a snapshot-based flow, migrating execution from FPGA to post-synthesis simulation to obtain precise gate-level power estimates without statistical modeling.

Finally, ADAM introduces the Activity Pause Protocol, a software-accessible interface that extends existing standards like AXI/ACE Low Power Interface [2] by explicitly supporting power-off states with internal state loss, enabling flexible runtime energy management beyond clock gating.

## 8 Conclusions

We presented ADAM, an open-source, parametric microcontroller platform for flexible and energy-efficient intermittent edge computing. ADAM features heterogeneous RISC-V cores in distinct power/performance domains, with software-controlled power management using the Activity Pause Protocol for fine-grained clock and power gating. ADAM provides a unified build system, auto-generated software layers, and a hybrid evaluation flow. Its snapshotting mechanism enables seamless transfer of application state between FPGA and simulation, bridging functional validation and power analysis.

On a keyword-spotting application, ADAM improves energy efficiency by up to 38% through partitioned execution across heterogeneous cores and programmable power states. The complete platform, including RTL, tooling, and documentation, is open source [1]. Its versatility and extensibility aim to support the research community in exploring new edge architectures and mappings.

## 9 Acknowledgments

This work was partially supported by the French National Research Agency (ANR) through the France 2030 government PEPR Electronic grants EMCOM (ANR-22-PEEL-0009) and CHOOSE (ANR-22-PEEL-0013).

## References

[1] ADAC Research Group. ADAM GitHub repository. URL https://github.com/ADAC-LIRMM/adam. Accessed: 2025-09.

[2] Arm Ltd. AMBA AXI and ACE protocol specification. URL https://developer.arm.com/documentation/ihi0022/latest. Accessed: 2025-09.

[3] F. Conti, D. Rossi, A. Pullini, I. Loi, and L. Benini. PULP: A ultra-low power parallel accelerator for energy-efficient and flexible embedded vision. *Journal of Signal Processing Systems*, 2016.

[4] R. David, J. Duke, A. Jain, V. Janapa Reddi, N. Jeffries, J. Li, N. Kreeger, I. Nappier, M. Natraj, T. Wang, et al. Tensorflow lite micro: Embedded machine learning for tinyml systems. *Proceedings of machine learning and systems*, 2021.

[5] Digilent. JTAG-HS2 programming cable reference manual. URL https://digilent.com/reference/programmers/jtag-hs2/reference-manual. Accessed: 2025-09.

[6] Digilent. Nexys Video FPGA board reference manual. URL https://digilent.com/reference/programmable-logic/nexys-video/reference-manual. Accessed: 2025-09.

[7] D. Kim, A. Izraelevitz, C. Celio, H. Kim, B. Zimmer, Y. Lee, J. Bachrach, and K. Asanović. Strober: Fast and accurate sample-based energy simulation for arbitrary RTL. In *Proceedings of the annual international symposium on Computer architecture (ISCA)*, 2016.

[8] lowRISC. Iben RISC-V Core. URL https://github.com/lowRISC/ibex. Accessed: 2025-09.

[9] S. Machetti, P. D. Schiavone, T. C. Müller, M. Peón-Quirós, and D. Atienza. X-heep: An open-source, configurable and extendible risc-v microcontroller for the exploration of ultra-low-power edge accelerators. *arXiv preprint arXiv:2401.05548*, 2024.

[10] P. Mantovani, D. Giri, G. Di Guglielmo, L. Piccolboni, J. Zuckerman, E. G. Cota, M. Petracca, C. Pilato, and L. P. Carloni. Agile soc development with open ESP. In *Proceedings of the 39th International Conference on Computer-Aided Design*, 2020.

[11] OpenHW Group. OpenHW Group CORE-V CV32E40P. URL https://github.com/openhwgroup/cv32e40p. Accessed: 2025-09.

[12] PULP Platform. riscv-dbg: RISC-V Debug Module. URL https://github.com/pulp-platform/riscv-dbg. Accessed: 2025-09.

[13] T. Soriano, D. Novo, and P. Benoit. An FPGA-based Emulation Platform for Edge Computing Node Design Exploration. In *RSP 2021 - 32nd International Workshop on Rapid System Prototyping*, pages 8-14, Virtual event, France, Oct. 2021. doi: 10.1109/RSP53691.2021.9806230. URL https://hal.umontpellier.fr/hal-03596105.

[14] TensorFlow Lite Micro contributors. Micro speech example. URL https://github.com/tensorflow/tlite-micro/tree/main/tensorflow/lite/micro/examples/micro_speech. Accessed: 2025-09.

[15] Y. Zhang, N. Suda, L. Lai, and V. Chandra. Hello edge: Keyword spotting on microcontrollers, 2017.