FlexiBench: Sustainable Benchmark for FlexICs

• FlexiBench is a domain-specific workload suite for sustainable item-level intelligence that benchmarks flexible electronics under extreme constraints such as kHz clock rates and minimal memory footprints.
• It encompasses 11 diverse workloads spanning single-use to 20-year deployments, integrating both operational and embodied carbon metrics for comprehensive system evaluation.
• The benchmark aids in architecture selection by comparing RISC-V cores (SERV, QERV, HERV), demonstrating speedups up to 4.93× and significant energy-per-execution improvements tied to lifetime considerations.

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 (Prakash et al., 9 Sep 2025).

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 (Prakash et al., 9 Sep 2025).

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 (Prakash et al., 9 Sep 2025).

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 (Prakash et al., 9 Sep 2025).

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 (Prakash et al., 9 Sep 2025).

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 (Prakash et al., 9 Sep 2025).

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 (Prakash et al., 9 Sep 2025).

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

$1000\times$0

and the embodied-carbon equation as

$1000\times$1

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 (Prakash et al., 9 Sep 2025).

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 $1000\times$2. 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 $1000\times$3 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 (Prakash et al., 9 Sep 2025).

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 (Fursin et al., 14 Sep 2025). The paper “FLEX: A Benchmark for Evaluating Robustness of Fairness in LLMs” introduces FLEX, not FlexiBench (Jung et al., 25 Mar 2025). The paper “FLBench: A Benchmark Suite for Federated Learning” uses FLBench only and explicitly does not mention “FlexiBench” (Liang et al., 2020).

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 (Prakash et al., 9 Sep 2025).

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.