Lifetime-Aware Design for Item-Level Intelligence at the Extreme Edge

Shvetank Prakash, Andrew Cheng, Olof Kindgren, Ashiq Ahamed, Graham Knight, Jedrzej Kufel and 10 others

Putting a tiny computer into every disposable item — food packaging that senses spoilage, a medical patch that watches vitals — means using cheap flexible electronics that run at only kilohertz speeds with a few thousand gates, and manufacturing trillions of them, so their carbon cost matters enormously; this paper (Harvard and Pragmatic Semiconductor — Shvetank Prakash, Vijay Janapa Reddi, Emre Ozer, and colleagues) shows these items differ 1000-fold in how long they live, which flips the right chip design — a short-lived item is dominated by the carbon of making it, a long-lived one by the carbon of running it — and builds FlexiFlow, a lifetime-aware framework with a benchmark suite, area-tuned 1/4/8-bit RISC-V cores, and a carbon model, validated by the first fully open-source flexible-chip tape-out at 30.9 kHz.

The argument in one glance

Problem

Putting a computer in every disposable item breaks the usual rules of chip design

The next frontier of ubiquitous computing is item-level intelligence: embedding a tiny computer directly into everyday disposable products, so food packaging can detect spoilage, a medical patch can monitor vitals, and a textile can sense odor. But this pushes computing to an extreme the usual playbook was not written for. The scale is trillions of units a year, not the millions of a phone model, and the products are low-margin, so a silicon microcontroller costing tens of cents to dollars is simply too expensive to put in each one. The power budget is microwatts to milliwatts, the speeds are kilohertz, and — unlike a phone or a server that lives for years — these items live anywhere from days to years. On top of all that, manufacturing and running trillions of chips is a serious environmental question. The economics, the physics, and the sustainability all point the same way: the conventional way of designing chips does not fit here.
What people did

Use cheap flexible electronics and a standard small processor design

The enabling technology is flexible electronics — circuits fabricated on bendable substrates rather than silicon — which are dramatically cheaper per unit, cheap enough to integrate into disposable goods, though limited to kilohertz clock speeds and only a few thousand logic gates. The natural next step is to drop a conventional small processor design onto this substrate and treat every deployment the same way, as chip design usually does.
Why it fell short

One design cannot be right when lifetimes vary a thousandfold

The flaw is treating all deployments alike. These applications vary enormously in how long they operate: a spoilage sensor runs for days, an infrastructure monitor for years — a thousandfold spread. That matters because the carbon cost of a chip has two parts, the embodied carbon of manufacturing it and the operational carbon of powering it over its life, and which one dominates depends entirely on lifetime. For a short-lived item, the carbon of making it dwarfs the carbon of running it, so you want the smallest, cheapest-to-make chip even if it is slow; for a long-lived item, operation dominates, so a slightly larger but far more energy-efficient chip pays for its manufacturing carbon over time. A single one-size-fits-all design is wrong for most of the trillion items, and at that scale being wrong is an environmental problem, not just an efficiency one.
This paper's idea

Make lifetime a first-class design parameter and optimize for carbon

FlexiFlow is a lifetime-aware design framework for item-level intelligence on flexible electronics. Its core insight is that operational lifetime, which conventional design ignores, is a first-class parameter that flips the optimal architecture, so it explicitly models the trade-off between embodied and operational carbon based on each application's lifetime. It has three parts: FlexiBench, the first benchmark suite of sustainability workloads from spoilage detection to health monitoring; FlexiBits, a family of area-optimized RISC-V cores with 1-, 4-, and 8-bit datapaths that let a designer trade area against energy per task; and a carbon-aware model that picks the right core for a given deployment. Choosing the microarchitecture by lifetime cuts carbon by 1.62 times, and choosing the algorithm cuts it by 14.5 times. The authors validate the whole flow with the first tape-out of a flexible chip using fully open-source tools, running at 30.9 kilohertz.

Why this problem is worth solving

The whole regime is so far outside conventional computing that its constraints have to be rethought from scratch.

Item-level intelligence sits at what the authors call the Extreme Edge, and on every axis it is orders of magnitude away from the computing we design for today. Where a phone ships in the millions and a server serves for years, item-level intelligence targets trillions of units a year embedded in disposable products that may live only days. Where a phone runs at gigahertz with gigabytes and a watt or more of power, these devices run at kilohertz with a few kilobytes and microwatts to milliwatts. And the cost ceiling is brutal: a silicon microcontroller at tens of cents to dollars is unaffordable when the product it goes into is low-margin and thrown away, so silicon is largely out. This combination — extreme scale, extreme cheapness, extreme constraints, and disposability — means the design considerations that matter are not the ones that matter for a datacenter or a phone. It also raises a sustainability question that scale makes unavoidable: manufacturing and operating trillions of tiny computers has a real environmental cost, and Jevons’ paradox warns that making each one more efficient can, by enabling far more of them, increase total harm. So getting the design principles right is not an optimization nicety; it is what decides whether item-level intelligence is a net benefit, and that is why the domain needs its own methodology.

The hinge that reorganizes the whole design is a variable conventional computing barely notices: how long the thing runs.

Every chip carries two kinds of carbon cost. Embodied carbon is emitted once, when the chip is manufactured. Operational carbon is emitted continuously, from generating the power the chip consumes over its working life. For most conventional computing the operational side dominates, because devices run for years, so designers optimize for energy efficiency in use. Item-level intelligence breaks this, because its lifetimes range over a thousandfold — from a spoilage sensor that operates for days to an infrastructure monitor that runs for years. That range straddles the crossover point between the two carbon costs. For a very short-lived item, the chip barely runs, so its operational carbon is tiny and the carbon of manufacturing it dominates the total; the right move is to make the chip as small and cheap to fabricate as possible, even if it is slow and does more energy per task, because the manufacturing footprint is what you are minimizing. For a long-lived item, the chip runs so much that operational carbon dominates, so a somewhat larger chip that finishes each task with far less energy wins, its extra manufacturing carbon amortized over years of savings. So the optimal architecture literally inverts as lifetime crosses that threshold. A design methodology that ignores lifetime will pick the wrong chip for most of the trillion items, which is why FlexiFlow makes lifetime a first-class parameter and centers everything on the embodied-versus-operational carbon trade-off.

What people did before, and where it broke

Silicon microcontrollers for edge devices. Use conventional low-power silicon chips, as in IoT and wearables. Where it broke. At tens of cents to dollars per unit they are far too expensive for trillions of low-margin disposable items, so silicon cannot reach item-level intelligence scale.
Flexible electronics with off-the-shelf core designs. Adopt the cheap flexible substrate but drop in a standard processor design uniformly. Where it broke. A single design ignores the thousandfold lifetime variation, so it is carbon-suboptimal for most deployments — too large for short-lived items where manufacturing carbon dominates, too small and inefficient for long-lived ones where operational carbon dominates.
Optimizing purely for energy efficiency in operation. Follow the conventional instinct that operational energy is what matters and minimize it. Where it broke. For the many short-lived item-level applications, embodied (manufacturing) carbon dominates, so chasing operational efficiency with a larger chip actively increases total carbon.
Conventional 32-bit datapaths. Use a standard word-width core. Where it broke. At the extreme area and cost limits of flexible chips, which have only a few thousand gates, a 32-bit datapath is prohibitively large and expensive, leaving no room to tune area against energy for different lifetimes.
The gap. No framework treated deployment lifetime as a first-class design parameter, modeled the embodied-versus-operational carbon trade-off for item-level applications, and offered a family of area-tunable cores plus a benchmark suite so the right chip could be chosen per deployment at trillion-item scale.

How FlexiFlow works

Choosing the carbon-optimal flexible chip by an application's lifetime

↓ →
new
↓ →
new
↓ →
new
↓ →
new
↓ →
new

The idea

Elevate lifetime to a first-class design parameter, because it decides which carbon cost matters. The intellectual core of FlexiFlow is noticing that a variable conventional computing treats as incidental — how long a device operates — is, for item-level intelligence, the parameter that reorganizes the entire design. Because these items span a thousandfold in lifetime, they straddle the crossover between embodied and operational carbon: below it, the one-time carbon of manufacturing dominates and you want the smallest possible chip; above it, the ongoing carbon of operation dominates and you want the most energy-efficient chip even if it is bigger. So the optimal design is not a fixed target but a function of lifetime, and FlexiFlow makes that explicit by modeling the embodied-versus-operational trade-off per application. Building the whole methodology around a first-order model of a device’s total carbon, split into what its manufacture costs and what its operation costs, is the same principled accounting the first-order carbon-model work for processor sustainability covered elsewhere on this site is built on, making the two components of carbon the quantities a design is actually optimized against rather than a rough afterthought. FlexiFlow’s contribution is to add lifetime as the axis along which that trade-off tips, and to show it tips far enough to change the answer.

Give the designer an area-versus-energy dial by making the datapath width tunable. A lifetime-aware model is only useful if there are meaningfully different chips to choose between, so FlexiFlow builds a family. It observes that a conventional 32-bit datapath is prohibitively large for flexible chips with only a few thousand gates, and instead offers narrow bit-serial RISC-V cores at 1, 4, and 8 bits — SERV at one bit, and the new QERV and HERV at four and eight. The elegant part is that they share the same width-independent control logic and differ only in the datapath, so a wider core costs area purely for computation, not for extra control complexity, and each finishes a task in fewer cycles: the 4- and 8-bit cores use 2.65 and 3.50 times less energy per program execution than the 1-bit core despite drawing more power, because they run so much faster. That gives a clean dial: narrow means small area but more energy per task (favoring short lifetimes), wide means more area but far less energy per task (favoring long lifetimes). Squeezing capable computation into a device with almost no gates by carefully trading numeric width against cost is the same extreme-constraint engineering the deep-learning-on-microcontrollers work covered elsewhere on this site pursues, fitting real workloads into hardware whose resources are counted in kilobytes rather than gigabytes. FlexiFlow turns that trade-off into a spectrum a carbon model can select from.

Make it a whole framework, and remember the algorithm matters even more than the hardware. FlexiFlow is deliberately holistic: it pairs the cores with a benchmark suite of real sustainability workloads and a carbon model, so the design space can be explored end to end rather than one chip at a time, and it is released open source and validated by an actual fabricated chip. That breadth surfaces a striking result: while choosing the microarchitecture by lifetime cuts carbon by 1.62 times, choosing the algorithm cuts it by 14.5 times — the software decision has an order of magnitude more leverage than the hardware one. A framework that only tuned cores would have missed this, because it takes a full-stack view to compare a hardware knob against an algorithm knob on the same carbon yardstick. Assembling benchmarks, hardware, and a carbon model into one framework so that decisions across the stack can be weighed together against carbon is the same holistic stance the carbon-aware datacenter-design framework covered elsewhere on this site takes, insisting that sustainability is a system-level optimization spanning many coupled choices rather than a single component’s problem. FlexiFlow brings that systems view to the Extreme Edge and finds the biggest lever is not where hardware designers usually look.

Following an application through FlexiFlow

Picking the carbon-optimal chip for a short-lived versus a long-lived item

A trace, drawn from the paper's framework, of how FlexiFlow selects a design based on an application's lifetime and workload.

Step 1 of 5

Characterize the application and its lifetime

A designer starts from a FlexiBench workload — say, spoilage detection that runs for days, or infrastructure monitoring that runs for years — with its computation per run and its deployment lifetime. Lifetime is treated as a primary input, not an afterthought.

The thousandfold lifetime spread across applications is exactly what makes a single default design wrong for most of them.

Why it works

Lifetime determines which carbon cost dominates, so it must drive the design. Embodied carbon is fixed and operational carbon scales with runtime → but item lifetimes span a thousandfold, straddling the crossover between them → so the optimal chip inverts with lifetime, and a lifetime-aware choice cuts carbon by 1.62 times over one design.
A shared control plane makes wider datapaths pay only for compute. Adding datapath width usually adds control complexity too → but FlexiBits keeps control logic identical across 1-, 4-, and 8-bit cores → so extra area buys only computation, giving a clean area-versus-energy dial to match against lifetime.
Faster wider cores use less energy per task despite more power. A wider datapath draws more power per cycle → but it finishes each task in far fewer cycles → so the 4- and 8-bit cores use 2.65 and 3.50 times less energy per execution, making them the right choice for long lifetimes.
A benchmark and carbon model turn intuition into selection. Knowing the trade-off exists is not enough to design → but FlexiBench workloads plus a carbon model quantify embodied and operational carbon per design → so the framework can pick the minimum-carbon core rather than guess.
A full-stack view exposes the bigger lever. Optimizing hardware alone hides where the gains really are → but comparing microarchitecture and algorithm on one carbon yardstick → so the framework reveals algorithmic choices cut carbon 14.5 times, far more than the 1.62 times from microarchitecture.

What it costs (trade-offs and scope)

The technology is genuinely slow and tiny. Flexible electronics run at kilohertz, not gigahertz, with only a few thousand gates and kilobytes of memory, so item-level intelligence can only do very small workloads; the fabricated chip runs at 30.9 kilohertz. This is a different class of computing, not a cheaper version of a microcontroller, and only lightweight sensing and inference fit.
The carbon conclusions rest on modeling assumptions. The embodied-versus-operational trade-off depends on estimates of manufacturing carbon, power-generation emissions, and workload run frequency; the paper notes it must conservatively estimate some values (for example, life-cycle data for flexible gas sensors) where real data is scarce, so the exact crossover points and carbon ratios carry that uncertainty.
The best design is deployment-specific, which adds design burden. Because the optimal core depends on lifetime and workload, there is no single chip to reuse across products; realizing the benefit means running the framework per application and potentially fabricating different designs, trading manufacturing simplicity for carbon optimality.
Algorithm dominance shifts where effort should go. The finding that algorithmic choices cut carbon 14.5 times versus 1.62 times for microarchitecture means much of the leverage is in software; the hardware family is valuable but is not where most of the carbon savings live, so the framework’s value is as much in guiding algorithm selection as core selection.
It is an early, first-of-its-kind demonstration. This is the first tape-out of a flexible chip with fully open-source tools and the first such benchmark suite and carbon framework; it establishes feasibility and methodology at trillion-item scale in analysis, but real trillion-item deployment, yield, and integration into products remain future work.

The evaluation

Designing a flexible chip for a disposable intelligent item

Property	One-size-fits-all core	Optimize operational energy only	FlexiFlow (lifetime-aware)
Treats lifetime as a design input
Models embodied vs operational carbon
Datapath choice
Right for short-lived items
Reported carbon reduction

A comparison drawn from the paper. FlexiFlow's FlexiBits cores (SERV, QERV, HERV at 1/4/8 bits) and carbon-aware model are evaluated on the FlexiBench sustainability workloads; the 1.62-times and 14.5-times figures are the paper's reported carbon reductions from lifetime-aware microarchitecture and algorithm choices, validated by the first fully open-source flexible-chip tape-out at 30.9 kilohertz.Underlined values explain themselves when clicked.

Where this stops working

What to keep in mind

The full paper text was available (the authors’ arXiv version, 2509.08193), so this account of the mechanism — item-level intelligence on flexible electronics, the thousandfold lifetime variation and why it flips the optimal design through the embodied-versus-operational carbon trade-off, the three FlexiFlow components (FlexiBench workloads, FlexiBits 1/4/8-bit bit-serial RISC-V cores with shared control logic, and the carbon-aware model), and the tape-out — follows the paper’s own description. The headline numbers are the paper’s reported results: the 4- and 8-bit cores (QERV, HERV) use 2.65 and 3.50 times less energy per execution than the 1-bit core (SERV); lifetime-aware microarchitectural design cuts carbon by 1.62 times and algorithmic choices by 14.5 times; and the first tape-out of a flexible chip with fully open-source tools runs at 30.9 kilohertz. Several carbon estimates rely on conservative assumptions where life-cycle data is scarce, so the exact ratios carry modeling uncertainty, and the domain is genuinely kilohertz-scale, few-thousand-gate computing. Exact per-workload numbers, the carbon model details, and the tape-out specifics should be read from the paper itself. FlexiFlow is open source (github.com/harvard-edge/FlexiFlow).

Background

Why embodied carbon changes the sustainability calculus

It is worth understanding why manufacturing carbon, long a footnote, becomes central here. For most of computing’s history, sustainability discussions focused on operational energy — the electricity a device draws while running — because devices ran for years and their manufacturing footprint was amortized to insignificance. But two trends have made embodied carbon, the emissions from fabricating a chip, increasingly important: chips are made in ever more energy-intensive processes, and devices are replaced ever faster. Item-level intelligence takes this to an extreme, because its whole premise is disposable computing — a chip that lives days and is thrown away has almost no operational footprint but the full manufacturing footprint, so embodied carbon is essentially the entire cost. Multiply by trillions of units and by Jevons’ paradox, in which cheaper, more efficient computing simply gets deployed far more widely, and the embodied carbon of item-level intelligence could dominate its environmental impact. This is why FlexiFlow refuses to optimize operation alone and insists on the manufacturing side of the ledger. That recognition that reducing the carbon of making hardware, not just running it, is where large sustainability gains hide is the same premise the work on repurposing discarded devices to minimize embodied carbon covered elsewhere on this site is built on, treating avoided manufacturing as a first-order environmental benefit. FlexiFlow’s twist is that when a device is disposable by design, you cannot avoid manufacturing it, so you must make manufacturing it as light as its short life demands.

If you remember only three things

1. Item-level intelligence embeds tiny computers into trillions of disposable products (spoilage-sensing packaging, health patches), which requires flexible electronics — far cheaper than silicon but limited to kilohertz speeds and a few thousand gates — and at that scale the carbon of manufacturing and operating the chips is a first-order concern. The key insight is that these applications vary a thousandfold in operational lifetime (days to years), which straddles the crossover between embodied carbon (one-time, from manufacturing) and operational carbon (ongoing, from power), so the carbon-optimal chip inverts with lifetime and no single design fits, yet prior methodology ignored lifetime.
2. FlexiFlow is a lifetime-aware framework with three parts: FlexiBench, the first suite of sustainability workloads; FlexiBits, area-optimized bit-serial RISC-V cores at 1, 4, and 8 bits (SERV, QERV, HERV) that share identical width-independent control logic so wider datapaths cost area only for computation, giving an area-versus-energy dial (the 4- and 8-bit cores use 2.65 and 3.50 times less energy per task than the 1-bit core because they finish faster); and a carbon-aware model that sums embodied and operational carbon per application and picks the smallest core for short-lived items (embodied dominates) or a wider one for long-lived items (operational dominates).
3. Choosing the microarchitecture by lifetime cuts carbon by 1.62 times over a one-size-fits-all design, and choosing the algorithm cuts it by 14.5 times — showing the software decision has an order of magnitude more leverage than the hardware one. The authors validate the framework with the first tape-out of a flexible chip using fully open-source tools, running at 30.9 kilohertz, and release it open source. The domain is genuinely kilohertz-scale, few-thousand-gate computing, several carbon estimates rest on conservative assumptions, and the best design is deployment-specific.

Check yourself

Check your understanding

1. Why does item-level intelligence require rethinking conventional chip design?
2. Why does an application's operational lifetime change which chip design is carbon-optimal?
3. How does the FlexiBits core family provide a useful area-versus-energy trade-off?
4. What are FlexiFlow's main results, and what surprising finding did its full-stack view surface?

Sources

The paper is “Lifetime-Aware Design for Item-Level Intelligence at the Extreme Edge” by Shvetank Prakash, Andrew Cheng, Arya Tschand, David Kong, Mariam Elgamal, Jerry Huang, Emma Chen, Gage Hills, and Vijay Janapa Reddi (Harvard University), Ashiq Ahamed, Graham Knight, Jedrzej Kufel, Francisco Rodriguez, Richard Price, and Emre Ozer (Pragmatic Semiconductor), and Olof Kindgren (Qamcom Research and Technology), published at ASPLOS 2026, DOI 10.1145/3779212.3790182. It is licensed CC BY.

This explainer is based on the paper’s full text, obtained from the authors’ arXiv preprint (arXiv:2509.08193). The account of the mechanism — item-level intelligence embedding computation into trillions of disposable products; flexible electronics as a cheap alternative to silicon limited to kilohertz speeds and a few thousand gates; the thousandfold operational-lifetime variation and why it makes lifetime a first-class parameter by determining whether embodied (manufacturing) or operational (power) carbon dominates; the FlexiFlow framework’s three components (FlexiBench sustainability workloads, FlexiBits bit-serial RISC-V cores at 1/4/8 bits — SERV, QERV, and HERV — with shared width-independent control logic and width-scaling datapaths, and the carbon-aware model); and the validation by tape-out — follows the paper’s own description. The reported results cited here are the paper’s own: the 4- and 8-bit cores use 2.65 and 3.50 times less energy per program execution than the 1-bit core (with roughly 4.93 times geomean speedup for the 8-bit core); lifetime-aware microarchitectural design reduces carbon footprint by 1.62 times while algorithmic decisions reduce it by 14.5 times; and the first tape-out of a flexible chip using fully open-source tools achieves 30.9 kilohertz operation. Some life-cycle-assessment values are conservatively estimated where data is scarce. FlexiFlow is available at github.com/harvard-edge/FlexiFlow. Exact per-workload numbers, the carbon model details, and the tape-out specifics should be read from the paper itself.