---
title: 'FlexiBits: Low-Power RISC-V for Flexible Electronics'
url: https://www.emergentmind.com/topics/flexibits
type: topic
---

# FlexiBits: Low-Power RISC-V for Flexible Electronics

FlexiBits is a family of **area-optimized RISC-V cores with 1-bit, 4-bit, and 8-bit datapaths** introduced as part of the **FlexiFlow** framework for **item-level intelligence (ILI)** in **flexible electronics**. It targets deployments in disposable or low-cost products such as food packaging, medical patches, and smart textiles, where computing must operate under **kHz-scale clocks**, **several thousands of gates**, and deployment scales of **trillions of items per year**. In that setting, FlexiBits is not a generic term for arbitrary low-precision computing; it denotes a specific architectural family—**SERV**, **QERV**, and **HERV**—used to trade off embodied carbon, operational carbon, area, and execution energy across application lifetimes that vary by roughly **1000×**, from **days to years** [2509.08193].

## 1. Role within FlexiFlow and item-level intelligence

Within FlexiFlow, FlexiBits is the architectural component that supplies a small processor design space for lifetime-aware optimization. The broader framework combines three elements: **FlexiBench**, a workload suite for sustainability-oriented ILI applications; **FlexiBits**, the processor family; and a **carbon-aware model** that selects the optimal architecture for a given workload, execution frequency, and deployment lifetime [2509.08193].

The motivation is specific to flexible integrated circuits. The paper states that flexible electronics offer significantly lower cost than silicon, but are limited to **kHz rather than GHz**, **several thousand gates / tens of thousands of transistors**, and **sub-KB to KB-scale memory**. These constraints make conventional microprocessor assumptions inappropriate. FlexiBits therefore treats narrow datapaths not as a minor implementation choice, but as the primary mechanism for making a programmable processor viable in this substrate [2509.08193].

A central misconception is that the **1-bit, 4-bit, and 8-bit** labels describe the architectural ISA width. They do not. All three variants execute a **32-bit word ISA**, while varying only the **microarchitectural datapath slice width**. In other words, FlexiBits preserves programmability while serializing or partially serializing execution to reduce hardware cost [2509.08193].

## 2. Processor family and microarchitecture

FlexiBits generalizes the **SERV** architecture into a three-point family:

| Variant | Datapath | Reported core metrics |
|---|---:|---|
| SERV | 1-bit | 2546 NAND2 eq; 2.93 mm²; 17.75 mW |
| QERV | 4-bit | 3198 NAND2 eq; 3.68 mm²; 21.07 mW |
| HERV | 8-bit | 3903 NAND2 eq; 4.50 mm²; 24.99 mW |

The family is based on **RISC-V** and is evaluated with software targeting **RV32E**. The implementations omit hardware **multiply/divide** and **floating point**, and the paper explicitly excludes performance-oriented features such as **prefetching** and **memory bypassing**, noting that even modest additions of this sort would require **at least 32 D flip-flops**, which is substantial at these budgets [2509.08193].

The microarchitecture is organized around a common template with **width-independent control logic** and **width-dependent datapath logic**. The control plane is largely fixed across SERV, QERV, and HERV, while the arithmetic slice changes from a **1-bit adder** to **4-bit** and **8-bit** versions. This keeps widening overhead moderate and localizes most scaling cost in the datapath rather than in decode and state machinery [2509.08193].

Execution is **serial, multi-cycle, and in-order**. The paper distinguishes **one-stage instructions**—including **R-type** and most **I-type**—from **two-stage instructions** such as **loads**, **stores**, **jumps**, **branches**, **shifts**, and **set-less-than**. On SERV, one-stage instructions take roughly **32 cycles plus some fetch overhead**, while two-stage instructions take about **64 cycles**, or roughly **70 cycles from initial fetch to retirement**. This structure helps explain why FlexiBits can reuse very small arithmetic hardware while still remaining ISA-compatible [2509.08193].

Memory is modeled as **on-chip single-cycle access**, using **LPROM** for instructions and **SRAM** for volatile data. The paper notes that the register file is excluded from some area/power comparisons because it is implemented with **SRAM for area considerations**. It also emphasizes that memory remains a major bottleneck in flexible electronics: SRAM is less mature, volatile capacity is very limited, and some workloads exceed feasible memory budgets even when the processor core is small enough [2509.08193].

Relative to SERV, **QERV** and **HERV** deliver geometric-mean speedups of **3.15×** and **4.93×**, respectively, while achieving **2.65×** and **3.50×** better energy efficiency per workload execution. Because the underlying process uses **resistive n-type logic**, **static power dominates**, so wider datapaths can consume more instantaneous power but still reduce energy per task by finishing sooner [2509.08193].

## 3. Lifetime-aware selection and carbon model

The paper’s main interpretive move is to treat FlexiBits not as a single “best” processor, but as a family whose optimal member depends on deployment conditions. FlexiFlow models total carbon as the sum of operational and embodied components. The operational term is

$$
\text{C\textsubscript{Operational} (kg CO\textsubscript{2}e)} =
\text{Power} \times \text{Runtime} \times \text{Prog. Frequency}
\times \text{Lifetime} \times \text{Carbon Intensity},
$$

while the embodied term is

$$
\text{C\textsubscript{Embodied} (kg CO\textsubscript{2}e)} =
\frac{\text{Die Area}}{\text{Active Wafer Area} \times \text{Wafer Yield}}
\times \text{kg CO\textsubscript{2}e/wafer}.
$$

This model formalizes the intuition that **short-lived, infrequently executed devices** should favor smaller processors, whereas **long-lived or frequently executed devices** may justify larger datapaths if they reduce accumulated runtime energy [2509.08193].

The resulting crossover behavior is central to the meaning of FlexiBits. **SERV** is favored when **embodied carbon** dominates; **QERV** and **HERV** become preferable when **operational carbon** dominates. The paper gives **Cardiotocography Monitoring** as a concrete example: at **one week**, **SERV** minimizes carbon, but at the actual deployment lifetime of **nine months**, **HERV** becomes optimal. Choosing SERV instead of HERV in that setting would increase carbon footprint by **1.62×** [2509.08193].

The framework also shows that algorithm choice can dominate microarchitectural choice. In **Food Spoilage Detection**, a **KNN-Large** model reaches **98.9%** accuracy, while **LR** reaches **98.2%**, yet KNN-Large incurs **14.5×** more carbon over a **1-year** deployment. This is why the paper states that **algorithmic decisions can reduce carbon footprint by 14.5×**, while **lifetime-aware microarchitectural design can reduce carbon footprint by 1.62×** [2509.08193].

## 4. Workloads, feasibility, and selection behavior

FlexiBits is evaluated using **FlexiBench**, an **11-workload** suite targeting sustainability applications across **10 UN SDGs**. The suite spans workloads such as **Water Quality Monitoring**, **Food Spoilage Detection**, **Arrhythmia Detection**, **Package Tracking**, **Smart Irrigation Control**, **Cardiotocography**, **Gesture Recognition**, **Malodor Classification**, **Air Pollution Monitoring**, **Tree Tracking**, and **HVAC Control** [2509.08193].

These workloads vary strongly along the dimensions that matter for FlexiBits. The paper reports **7+ orders of magnitude variation** in dynamic instruction count, **1000× variation** in memory footprint, and **1000× variation** in operational lifetime. Memory requirements range from **0.31 KB** non-volatile memory for **Water Quality Monitoring** to approximately **240 KB** total memory for the largest workloads. Lifetimes range from **single use** or **1 week** to **20 years** [2509.08193].

At **10 kHz**, all three FlexiBits cores enable **8 of the 11** workloads. The three that remain infeasible are **Gesture Recognition**, **Arrhythmia Detection**, and **Tree Tracking**, which the paper describes as “orders of magnitude away” from feasibility and therefore better suited to algorithmic simplification or custom ASIC treatment [2509.08193].

The workload analysis also explains why different variants occupy different niches. **Malodor Classification**, a small decision-tree-like task with a **4-year** deployment, tends to favor **SERV** because its computational demand is low and embodied cost dominates. **Package Tracking**, which uses an MLP over IMU-derived features with a **3-week** lifetime, gives more room for QERV or HERV when execution energy becomes meaningful. **Cardiotocography**, with a **9-month** deployment, is one of the clearest cases where widening the datapath becomes beneficial [2509.08193].

## 5. Physical implementation and validation

FlexiBits was not left at the modeling stage. The paper reports a physical implementation flow based on **Pragmatic Semiconductor’s 0.6 µm resistive n-type logic-based FlexIC PDK**. For architectural characterization, the work used **Cadence Genus**. For open-source implementation, it integrated **OpenROAD** with the Pragmatic PDK and describes the resulting chip as the **first successful tape-out using open-source tools with a non-silicon PDK** [2509.08193].

The taped-out design was a **full SERV-based SoC**. The implementation targeted **10 kHz** but achieved **30.9 kHz** operation, while the tested fabricated dies operated reliably up to **33.0 kHz**. The **30.9 kHz** value is the figure highlighted in the abstract and summarizes the practical viability of the approach [2509.08193].

This validation matters because FlexiBits is meant for a substrate in which many assumptions from standard CMOS design do not hold. The tape-out therefore serves less as a benchmark contest and more as evidence that the architecture family, tool flow, and lifetime-aware methodology are physically realizable in flexible electronics [2509.08193].

## 6. Terminology, scope, and relation to adjacent “flexible-bit” research

FlexiBits is a specific term within **FlexiFlow**, not a universal label for all flexible-precision systems. Closely named work in the literature refers to distinct ideas. **“FlexiBit: Fully Flexible Precision Bit-parallel Accelerator Architecture for Arbitrary Mixed Precision AI”** denotes a cloud- and edge-oriented accelerator for arbitrary FP/INT mixed precision, centered on bit-parallel arithmetic and emerging formats such as FP6 and FP5 [2411.18065]. **“Bit-Mixer”** addresses runtime layer-wise bit-width selection in neural networks through a meta-quantized model with **Transitional Batch-Norms** [2103.17267]. **“FlexQuant”** targets LLM inference by dynamically switching layer precision during token generation using **perplexity entropy** and **KL divergence** [2506.12024]. **“BitNet Text Embeddings”** trains a single text embedder to support **1-, 2-, 4-, 8-, and 16-bit** output embeddings from one checkpoint [2606.25674]. A much earlier and conceptually different strand appears in **“Customizable Precision of Floating-Point Arithmetic with Bitslice Vector Types,”** which implements arbitrary low-precision floating-point formats in software through bitslice representations and bitwise instructions [1602.04716].

This comparison clarifies the scope of FlexiBits. Unlike those systems, FlexiBits is neither a generic quantization framework nor a runtime precision-switching mechanism. Its defining feature is the use of **1-bit, 4-bit, and 8-bit datapaths as pre-synthesis architectural options** for **flexible-electronics RISC-V processors**, selected according to workload lifetime, execution rate, and carbon trade-offs. In that sense, its contribution lies less in low-bit arithmetic per se than in making bitwidth a lifetime-aware architectural variable for the **Extreme Edge** [2509.08193].

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