---
title: 'FlexiBench: Sustainable Benchmark for FlexICs'
url: https://www.emergentmind.com/topics/flexibench
type: topic
---

# FlexiBench: Sustainable Benchmark for FlexICs

FlexiBench is the workload suite within **FlexiFlow**, a lifetime-aware design framework for **item-level intelligence (ILI)** in which computation is integrated directly into disposable or semi-disposable products such as food packaging and medical patches. In the paper “Lifetime-Aware Design of Item-Level Intelligence,” FlexiBench is presented as a benchmark suite for **flexible electronics**, specifically for **natively flexible integrated circuits (FlexICs)** operating under severe constraints such as **kHz** clock rates, **thousands of gates / tens of thousands of transistors**, **very small memories**, and deployment at **trillion-item scale**. Its defining feature is that it treats **application lifetime** and **task frequency** as benchmark dimensions alongside workload behavior, so that architecture evaluation is tied not only to energy per execution but also to embodied and operational carbon over deployments ranging from days to years [2509.08193].

## 1. Position within item-level intelligence

FlexiBench is not a generic embedded benchmark. It is the application and workload layer inside a three-part framework: **FlexiBench** provides workloads, **FlexiBits** provides candidate microarchitectures, and **FlexiFlow** uses benchmark-derived performance, power, area, lifetime, and carbon models to choose the carbon-optimal design. The benchmark was introduced because existing embedded suites are described as poor matches for ILI on flexible electronics: they are silicon-centric, emphasize conventional performance and energy metrics, and do not reflect the combination of **kHz** operation, **thousands of gates**, **KB-scale memories**, ultra-low-cost constraints, and deployment lifetimes that can vary by roughly **\(1000\times\)** between applications [2509.08193].

This design choice makes lifetime a first-class benchmark variable. In the paper’s framing, **short-lived devices** are dominated by **embodied carbon**, whereas **long-lived or frequently executed devices** accumulate more **operational carbon**. A plausible implication is that FlexiBench is intended less as a leaderboard suite than as a workload basis for architecture selection under lifecycle constraints.

## 2. Benchmark dimensions and system assumptions

FlexiBench characterizes workloads implemented for **RISC-V RV32E**, specifically **without** the **M extension** and **F/D extensions**. The workloads are described as **bare-metal embedded programs** in C, and arithmetic-heavy cases may therefore rely on **software-emulated multiplication using shifts and adds**. This ISA choice is directly tied to the area regime of flexible electronics, where a conventional 32-bit feature-rich core is too expensive [2509.08193].

The benchmark exposes several axes of heterogeneity. First, it spans **11 workloads** and **10 UN SDGs**. Second, it covers deployment lifetimes from **single use** to **20 years**. Third, it spans a **\(1000\times\)** range in memory requirements, from roughly **0.3 KB** to **240 KB**. Fourth, it spans a **seven orders-of-magnitude range** in dynamic instructions per execution. The paper also identifies two broad instruction-mix classes: **threshold-like workloads**, dominated by comparisons and branches, and **arithmetic-heavy workloads**, exemplified by **Cardiotocography**, whose MLP spends **over 60% of cycles on arithmetic operations**. **Arrhythmia Detection** is described as an outlier with a more even mix of I-type, R-type, loads, and shifts [2509.08193].

This benchmark structure is unusually explicit about memory type. **NVM** stores code, constants, and persistent data; **VM** stores stack, temporaries, and inputs. The paper stresses that **SRAM dominates memory power** and that VM-heavy workloads can therefore change the carbon-optimal core earlier than compute-only reasoning would suggest.

## 3. Workload inventory

The suite groups its 11 workloads into **short-lived deployments (days–weeks)**, **medium-term deployments (months)**, and **long-term deployments (years)**. The workloads, lifetimes, and core algorithms are as follows.

| Workload | Lifetime | Core algorithm |
|---|---:|---|
| Water Quality Monitoring (WQ) | single use | threshold checks |
| Food Spoilage Detection (FS) | 1 week | logistic regression |
| Arrhythmia Detection (AD) | 2 weeks | Bloom filter-based predictor |
| Package Tracking (PT) | 3 weeks | neural network |
| Smart Irrigation Control (SI) | 6 months | k-nearest neighbors |
| Cardiotocography (CT) | 9 months | neural network |
| Gesture Recognition (GR) | 2 years | cosine similarity |
| Malodor Classification (MC) | 4 years | decision tree |
| Air Pollution Monitoring (AP) | 4 years | XGBoost |
| Tree Tracking (TT) | 10 years | discrete Fourier transform |
| HVAC Control (HC) | 20 years | random forest |

The workload descriptions are application-specific rather than synthetic. **Water Quality Monitoring** performs threshold checks on water metrics such as **pH**, **dissolved oxygen**, and **total dissolved solids**. **Food Spoilage Detection** uses temperature, humidity, and VOC/gas-sensor measurements to classify spoilage level. **Arrhythmia Detection** processes ECG streams using **Approximate Pair Presence Tracking**. **Package Tracking** classifies package handling from **20-second IMU windows**. **Smart Irrigation Control** uses soil temperature and moisture. **Cardiotocography** classifies fetal state from **21 preprocessed features**. **Malodor Classification** uses a **4-sensor e-nose array** with explicitly mentioned **5-bit** sensor values. **HVAC Control** predicts occupancy from temperature, humidity, light, and CO\(_2\) using **100 decision trees**. Memory footprints range from **WQ = 0.31 KB NVM and 0.01 KB VM** to **GR = 200.46 KB NVM and 40.00 KB VM** [2509.08193].

The benchmark therefore mixes thresholding, decision trees, forests, KNN, logistic regression, MLPs, cosine similarity, Bloom-filter analytics, DFT, and XGBoost. This suggests that FlexiBench is designed to stress not only datapath width and control flow, but also memory footprint, execution periodicity, and deployment horizon.

## 4. Use in FlexiBits evaluation

FlexiBench is the workload basis for evaluating three area-optimized RISC-V-compatible cores: **SERV** with a **1-bit** datapath, **QERV** with a **4-bit** datapath, and **HERV** with an **8-bit** datapath. The reported methodology uses the **RISC-V GNU toolchain**, **Spike** for instruction-level simulation, **Icarus Verilog** for cycle-accurate simulation, an assumed clock frequency of **10 kHz**, and **on-chip, single-cycle** memory access. **Tree Tracking** is modeled analytically because task compute time is extremely high [2509.08193].

Across FlexiBench, wider datapaths reduce runtime enough that energy per execution improves despite modestly higher instantaneous power. The paper reports **QERV** with a **\(3.15\times\)** geometric-mean speedup over SERV and **HERV** with a **\(4.93\times\)** geometric-mean speedup. Microprocessor-only area and power are reported as **SERV: 2.93 mm\(^2\), 17.75 mW; QERV: 3.68 mm\(^2\), 21.07 mW; HERV: 4.50 mm\(^2\), 24.99 mW**. In energy terms, **QERV consumes \(2.65\times\) lower energy per program execution than SERV**, and **HERV consumes \(3.50\times\) lower energy per program execution than SERV** [2509.08193].

The paper is careful, however, not to equate speedup with application enablement. One section states that all FlexiBits cores enable **8 of the 11** FlexiBench workloads, whereas appendix text and table indicate **7 workloads** are currently deployable and identify **Gesture Recognition**, **Arrhythmia Detection**, and **Tree Tracking** as not feasible today. This is an internal inconsistency in the paper, but the named infeasible workloads are explicit. The broader conclusion remains that FlexiBench is intended to reveal that faster cores do not automatically matter if the workload already meets timing needs at **10 kHz**.

## 5. Carbon-aware interpretation and algorithm choice

FlexiBench is coupled directly to FlexiFlow’s lifecycle model. The paper gives the operational-carbon equation as

$$
\text{C}_{\text{Operational}} = \text{Power} \times \text{Runtime} \times \text{Prog. Frequency} \times \text{Lifetime} \times \text{Carbon Intensity},
$$

and the embodied-carbon equation as

$$
\text{C}_{\text{Embodied}} =
\frac{\text{Die Area}}{\text{Active Wafer Area} \times \text{Wafer Yield}}
\times \text{kg CO}_2\text{e/wafer}.
$$

The benchmark provides the workload-dependent inputs to these terms: runtime, memory footprint, task frequency, and expected deployment lifetime. The paper then uses FlexiBench to derive architecture-selection regions over **deployment lifetime** and **program execution frequency** [2509.08193].

Two concrete results illustrate the role of the benchmark. First, for **Cardiotocography**, the paper states that **SERV** minimizes total carbon at **1 week**, whereas at the realistic **9-month** lifetime **HERV** becomes optimal; using SERV instead of HERV in that 9-month scenario would increase carbon footprint by **\(1.62\times\)**. Second, the **Food Spoilage Detection** workload is used to compare alternative algorithms from prior work. **KNN-Large** and **logistic regression** achieve similar accuracy, **98.9% vs. 98.2%**, but **KNN-Large consumes \(14.5\times\) more carbon over a 1-year deployment**. The paper therefore attributes a larger carbon effect to algorithm selection than to microarchitectural selection in that case [2509.08193].

This suggests that FlexiBench functions simultaneously as a hardware benchmark and as a software-algorithm benchmark. Its intended unit of comparison is not merely “instructions per second,” but application-level carbon-optimal deployment under extreme-edge constraints.

## 6. Naming, adjacent systems, and limitations

The exact term **“FlexiBench”** appears in the item-level-intelligence framework described above. It should be distinguished from several similarly named systems. The paper “Framing AI System Benchmarking as a Learning Task: FlexBench and the Open MLPerf Dataset” uses **“FlexBench”**, not “FlexiBench,” for a modular MLPerf-derived inference benchmark [2509.11413]. The paper “FLEX: A Benchmark for Evaluating Robustness of Fairness in Large Language Models” introduces **FLEX**, not FlexiBench [2503.19540]. The paper “FLBench: A Benchmark Suite for Federated Learning” uses **FLBench** only and explicitly does not mention “FlexiBench” [2008.07257].

The FlexiBench description also contains several limits and caveats. The paper states that **memory technology is a bottleneck**, that **not all workloads are currently feasible on today’s FlexICs**, and that fixed-point or quantization details are often implicit rather than fully formalized. It also narrows the system boundary: the carbon model excludes **sensors, analog front ends, communication, packaging, and batteries** when comparing architectures. In addition, one inconsistency lists **Gesture Recognition** with **2 years** in the main table but **3 years** in the appendix description, and another inconsistency appears in the count of currently deployable workloads [2509.08193].

Taken as a benchmark artifact, FlexiBench is therefore best understood as a **domain-specific workload suite for sustainable item-level intelligence on flexible electronics**, rather than as a general embedded benchmark. Its distinctive contribution is the explicit coupling of workload behavior, memory footprint, execution periodicity, and deployment lifetime to architecture and carbon selection at the **Extreme Edge**.

Source: https://www.emergentmind.com/topics/flexibench