The RPU is a hardware primitive that sits behind a sensor ADC and decides when something has changed. It measures how fast the signal is changing rather than its level, moves its own threshold with the noise floor, and decides two clock cycles after each sample, with no CPU instruction in the path. About 3,000 standard cells. Board-tested today with a RISC-V system.
A level comparator is memoryless. The RPU is a rate-of-change comparator with memory: it adapts to its environment, and shells can be built around it without touching the core. Tuned once, it keeps working as conditions change.
TSMC 65nm and SKY130 synthesis · timing met at 625 MHz (65nm) · board-tested in a RISC-V system
Free technical evaluation on your own sensor data. You license only if it earns its place.
Listed on Design & Reuse · Product of the Week
RPU Microelectronics · Patent pending: PCT/IB2026/053070 · Priority TR 2025/012696 · Kocaeli, Turkey
Is this sample worth waking up for? Your system asks it thousands of times a second. Most of the time the answer is no: the signal has not meaningfully changed. You have seen it in power profiles and idle-time graphs on every always-on product you have shipped.
The cheapest way to answer is a level comparator: a few dozen gates that fire when a signal crosses a fixed reference. On its own it fails in two predictable ways. It cannot tell a slow drift from a sudden event, and it cannot follow a noise floor that moves with wind, load or temperature. So in practice a comparator never works alone. Around it sits firmware that re-centres the baseline, retunes the reference and filters spikes, and a processor that must stay awake often enough to run it.
The question is not whether that first decision is needed. It is where it should be made.
A processor has to be awake to decide that it may sleep. The RPU moves that first decision out of the instruction stream and into the signal itself, before any computation starts. The rest of this page shows what it does, what we have measured, and where it does not help.
The RPU keeps a short memory of the signal: the last N samples, split into an older and a newer half. Its metric is the difference between the two half-window averages, kept with two running sums, so each sample costs the same few additions at any window size, with no multiplier or divider. A constant offset cancels out, slow drift gives a small metric and a real step or burst gives a large one.
Its threshold is not fixed. It steps up when the signal gets noisier and down when it gets quieter, inside bounds you set. The hardest part of a comparator system, adapting to the environment, is done in hardware. Whatever can be built around a comparator can be built around the RPU in the same way, as shells, without touching the core.
A comparator can only ask whether the present sample is above a reference. Memory is what lets a detector understand context, and every capability below follows from it.
| Capability | Why a memoryless comparator cannot do it | Status |
|---|---|---|
| Immunity to drift | The RPU compares the signal with its own recent past; a comparator has no past to compare with | Board-tested |
| Immunity to spikes | An isolated spike is spread over the window and attenuated H-fold; a comparator fires on any single sample above its reference | Board-tested |
| Adapting to the environment | The threshold history is a learned noise floor, short-term learning without training; a comparator's reference stays where it was set | Board-tested |
| Silence as information | Recognising that a value has frozen while the stream keeps running needs a history of the signal | Board-tested |
| Shape of the change | The metric's course over time tells a step, a ramp and a spike apart; the S1 shape gate, a core option, is the first use of this | Board-tested |
| Knowing when it is blind | A threshold pinned at its ceiling means the detector has lost sensitivity, and the RPU can report it; a comparator can never know it is blind | System kit option |
| Back-dated onset | The change began about H samples before the trigger, which gives a sharper timestamp for locating events with several sensors | System kit option |
| Pre-event record | At every trigger the buffer already holds the N samples before the event, the pre-event memory that seismic recorders need | Data present · readout designed |
Fed and configured differently, the same chain answers other "when" questions. This is why we call the RPU a primitive rather than a wake-up block.
At its heart, yes, and that is the point. We benchmark the RPU against a comparator because both are building blocks of the same kind: small, standalone and placed in front of a processor. The comparison places the RPU among such basic blocks, as a drop-in primitive rather than a processor or a classifier, and measures what its built-in memory and adaptation are worth.
The difference is what happens after tuning. A comparator is only as good as its last retune. Tuned once at σ 200 and frozen, the RPU and a comparator both caught every event across a σ 25 → 400 noise sweep, but at the highest noise the RPU woke the CPU 483 times against 936. On real earthquake records it matched STA/LTA, the seismic standard, at every false-alarm budget, with equal or shorter latency. That is the job the firmware around a comparator does today, done in about 3,000 cells.
WFI with interrupts is the right mechanism, and the RPU uses it. The question is what raises the interrupt. A raw sensor interrupt fires on noise and drift; a firmware trigger needs the CPU awake to run. The RPU puts a rate-of-change decision with an adaptive threshold in front of the interrupt line, so the CPU sleeps through noise and drift and is woken when the signal really changes.
The decision itself arrives a fixed two clock cycles after the sample, with zero jitter, whatever the CPU is doing; the registered wake output follows one cycle later. How quickly your CPU then runs its first instruction depends on the CPU. The RPU fixes the part that software cannot: when the decision is made.
A DSP can do far more, but it is a processor: it has to wake and run code to decide that nothing changed. A DMA engine moves data without looking at it. An interrupt controller routes interrupts; it does not decide whether one should exist. That decision is made today by a comparator or by software, and that is the gap the RPU fills. It does not compete with WFI either: it gives WFI a wake source worth waiting for.
Some accelerometers ship with built-in wake logic, which shows that sensor buyers pay for it. Most sensors do not: geophones, strain gauges, hydrophones, current shunts, pressure probes. The RPU is that wake logic as a licensable block for any 12-bit stream, placed next to the processor or inside the sensor interface chip, directly after the ADC.
Our evaluation kits are set up for four challenge tests. Run them on the board, with your own data if you like.
Send us recordings from your sensor. We tune a profile on part of them, freeze it, and report detection, false alarms and CPU activity on the rest, against a comparator tuned on the same data. If it does not earn its place in your system, you owe nothing.
Every result below carries its evidence level: Board measured on the FPGA board, RTL-sim full-system simulation of the RTL, Model a Python model that matches the RTL bit for bit, Tool estimate from synthesis and power tools. Detection is always reported next to wake-ups, because a low wake count can also mean a blind detector.
The video shows our first hardware demonstration on a Nexys A7 board. One light sensor feeds two circuits at once. The LED of the always-on threshold circuit stays lit for the whole recording; the RPU's LED lights only when real light reaches the sensor and goes dark when it stops, while the conversation in the room never triggers it. It is a demonstration of behaviour, not a benchmark: the measured results follow below.
| Test | Comparison | Result | Level |
|---|---|---|---|
| Unseen recordings U1–U3 drift with correlated noise; changing noise with ±400 spikes; periodic interference with rising noise | RPU vs comparator, settings frozen, then run on new data | Events: RPU 10/12 with the delivered settings, 12/12 with the proportional or two-speed option; comparator at its fixed campaign setting 8/12. The RPU never missed an event the comparator caught | Board |
| Proportional setpoints, 8 recordings four rotating held-out folds | Proportional vs delivered fixed setpoints, both with the S1 gate | On data the setting had never seen: 57/61 events and 120 false alarms, against 45/61 and 122 for fixed setpoints. On real seismic data fixed setpoints did better, so the setting is chosen per application | Model + Board 8/8 |
| Noise sweep, σ 25 → 400 | Both tuned once at σ 200, then left unchanged | Both caught 4/4 at every level. At σ 400 the RPU woke 483 times against 936 for the comparator (373 with the S1 gate). | Model |
| Noisy stream, equal tuning rights | Settings chosen on a separate recording, measured once | Wake-ups: comparator 517, RPU 483, RPU with S1 gate 373: 28% fewer, with all 4/4 events caught | RTL-sim |
| S1 shape gate (core option), held-out data | RPU with vs without the gate | Unmatched alarms −54%, interrupts −33%, CPU active cycles −30%; no detected event lost. Cost: +59 LUT, +29 FF | Board 20/20 |
| Sensor faults | Stream stop, heartbeat loss, persistent fault, frozen value | All reported as specified on the board on a fault-injection test build, 10/10; a stopped stream or a lost heartbeat raises exactly one interrupt (an earlier test build: CPU active cycles 43,617 → 442). In RTL simulation a digital freeze is flagged within 31 samples and an analog freeze within 287 with the default limits; on real seismic data those limits raised false freeze faults, so they are set per sensor | Board + RTL-sim |
| Real sample rate, seismic segment STEAD at 100 Hz, 2,000 s per run | System kit RC5.2 against RC5.3, same data, same settings | CPU wake-ups 798 → 315 with the same 133 events delivered; 137 with a freeze profile calibrated for the sensor. Testing at the real rate exposed a flaw of our own: in RC5.2 every alarm suppressed by the wake budget raised its own fault interrupt. RC5.3 reports a suppression once per window | Board = sim |
| Several channels inside the Ibex system | 3-channel array with 2-of-3 voting; multi-scale core on one shared buffer; time-shared core serving 3 or 8 channels | 12/12 board runs equal to simulation. At 64 channels the time-shared core needs about 7 times fewer LUTs than separate cores. With one channel or one scale, each is proven equivalent to the delivered core on its decision outputs. Voting did not reduce false alarms on seismic data: the gain is shared hardware, not better detection | Board + Tool estimate |
| Dataset | Result | Reading | Level |
|---|---|---|---|
| STEAD · real earthquake P-wave arrivals | On par with STA/LTA at every budget from 2 to 20 false alarms per hour, e.g. RPU 213/300 · STA/LTA 210/300 at ≤ 20 per hour | Both tuned on a separate set for at most 20 false triggers per hour, then measured once on a 10-hour test set: no difference was statistically significant; median latency equal or shorter (0.06–0.12 s vs 0.12–0.18 s), without a CPU running it | Model |
| CWRU · bearing faults | One RPU with a rectifier front end: 25/27, 0 false alarms. Two RPU cells, raw OR envelope: 27/27, 0 false alarms | A comparator and STA/LTA alone caught 27/27, but at 1.5 to 6 false alarms per minute: a flood of interrupts the RPU does not raise. The two-cell result comes from a pre-registered hybrid test, where a STA/LTA-plus-derivative hybrid also reached 27/27 with no false alarms | Model |
Cadence Genus: 2,960 standard cells, 0.018 mm², a 1.6 ns timing target met for the stand-alone core at its RTL default parameters. Power of the RPU block in a gate-level system power sweep (worst-case corner, activity-based): 0.852 mW at 100 MHz, 0.129 mW at 10 MHz, 56.6 µW at 1 MHz. Synthesis results; tape-out is the next step.
Timing met at 100 MHz, about 0.047 mm². Older processes, common in sensor interface chips, make the block larger; the window memory sets most of the area, so window depth is chosen per sensor. Its value does not come from speed or density, so mature and open processes serve it. Because the window's two read addresses always fall in opposite halves, the buffer maps onto two single-port SRAM banks without adding latency (analysis, not yet built).
Current system kit (RC5.3): 101 of 101 board runs on 14 bitstreams matched simulation field by field. A clean copy of the delivery package passed its own acceptance run: 11/11 board runs, firmware rebuilt from source byte for byte.
Core options enter as parameters. With them switched off, the extended core was proven equivalent to the delivered one by induction in Yosys, for four parameter sets. SystemVerilog assertions ship with the RTL.
| Input | RPU response | What it means |
|---|---|---|
| Single spike of size B | Metric rises only to B/H | Glitches are attenuated H-fold; spikes below H·θ never trigger alone |
| Step of size A | Metric climbs to A over H samples | Detection delay ≈ H·θ/A samples, known in advance |
| Ramp of slope s | Metric settles at s·H | The threshold is a slope limit θ/H, specifiable in physical units |
| Interference whose period divides H | Metric stays at zero | Mains hum or rotation can be cancelled by choice of sample rate and window |
| White noise, std. dev. σ | Spread ≈ σ·√(2/H) | False-alarm probability follows from the threshold in closed form |
The RPU fits when three things are true: the system must watch continuously, the data is quiet most of the time, and the noise floor moves with weather, load or temperature. It does not need to know what the signal means. Each engagement starts with a calibration on the partner's own recordings; none of the scenarios below has been field-tested yet.
Threshold rides the wind and traffic noise; CPU and radio sleep until a real step.
Details →Daily thermal drift stays below threshold; impacts and cracks trigger.
Details →Keep processing off until the signal changes; in implants the limit is heat.
Details →Wake analysis only on change; the threshold history tracks wear.
Details →Rate of change warns earlier than a level: thermal runaway, RoCoF protection.
Details →Side-band hardware with fixed timing, leaving certified firmware untouched.
Details →Run inference only when the input changes; watch on-chip monitors for sudden drift.
Details →Spend harvested energy, radio time and flash writes only on change.
Details →The core taps the sample stream (in_data, in_valid) and drives a wake line to any level-triggered interrupt input. It is plain synthesizable SystemVerilog with no custom tooling, proprietary bus or licensed compiler; we have built it with Vivado, Cadence Genus, Yosys and Icarus. The system kit adds the event shell, a register interface and a fault line.
S, the temporal sparsity, is the share of time the data is quiet. PRPU is the block's own power; Pgated and Pidle are the active and idle power of what it lets sleep. Any integrator can evaluate it for their own system. For analog sensors the ADC must stay on to feed the RPU, so quote system power with the ADC included. The RPU can work with an analog front end rather than against it: an analog wake-up stage can keep the ADC off until something happens, with the RPU confirming the change and checking sensor health before the CPU wakes; or the ADC can sample slowly while the scene is quiet, raised to full rate by the RPU when a change starts. Both are designed options, not yet built; system latency then also includes the ADC's wake-up and settling time and a window refill.
Energy is often not the main reason to use it. Fixed timing, sensor-health reporting and a trigger that runs without the CPU matter even in mains-powered systems.
Evaluate on FPGA. The system kit runs on a Nexys A7 board with a lowRISC Ibex RISC-V core, with bitstreams, firmware and acceptance scripts. Or prove the math in software first: a C version of the decision logic (rpu.c / rpu.h) is available on request. It must run on an awake CPU, so it saves the heavy work downstream (FFT, inference, radio), not the wake-up itself. The hardware moves the decision to where software cannot: before the CPU wakes.
in_data and in_valid from your sensor or ADC output. These are read-only taps: no change to your signal routing or bus.
wake_en to an interrupt input: irq_external_i on RISC-V, an NVIC line on Arm Cortex-M, or any level-triggered input. The CPU sees a standard external interrupt and acknowledges it.
This panel answers common questions from our current documents: architecture, parameters, evidence, power and integration. For anything deeper, write to us and you will get an engineer, not a script.
Start with the executive summary if you decide, and with the white paper or the ASIC PPA report if you design. The October 2026 Technical Brief and the evaluation kits, with their board logs, acceptance scripts and challenge tests, are sent on request.
An evaluation is meant to let your team reproduce our results and then run your own. Every kit ships with its own acceptance script, file hashes and the board logs it was accepted with.
We answer within 48 hours, agree an NDA, and send the kits by secure transfer.
The evaluation runs for 30 days at no cost, with direct engineering support by email and video call. At the end you choose: license, extend, or close with no further obligation.
There are good, established ways to save power and detect events: DVFS, clock gating, comparators, firmware triggers such as STA/LTA, and research architectures. The RPU does not replace them. It fills one specific gap: a first decision that adapts to its environment and is made in hardware, before any computation starts.
| Question | Level comparator | Firmware trigger (e.g. STA/LTA) | DVFS / PMU | RPU |
|---|---|---|---|---|
| Decides from how the signal changes? | No, from its level | Yes | No, from load | Yes |
| CPU needed to decide? | No | Yes, every sample | Yes | No |
| Adapts to a moving noise floor? | No | Yes | n/a | Yes, in hardware |
| Memory of the signal? | None | In software | n/a | N samples + threshold history |
| Decision timing | Fixed | Depends on software | µs to ms | Fixed, 2 clocks |
| Sensor-health reporting | No | If written | No | Stop, heartbeat, freeze |
| Cost | Tens of gates | An awake CPU | OS + PMU | ~3,000 cells |
The RTL, the FPGA system and two evaluation kits are complete, with multi-channel extensions board-tested in the same system. The block has been synthesized in two processes with timing met, and validated on real seismic and bearing data with a model that matches the RTL bit for bit. The next steps are pilots on customer data and a tape-out partner.
Read the evidence tables and the closed-form behaviour, then the ASIC PPA report for timing, area and power estimates in 65nm and SKY130.
Clone the reference RTL and run its testbench, then request the system kit and run the four challenge tests on a Nexys A7.
Read the executive summary, share it internally, then book a 30-minute call with our founder.
Send us recordings from your sensor. We tune a profile on part of them, freeze it, and report detection, false alarms and CPU activity on the rest, next to a comparator tuned on the same data.
If the RPU does not earn its place in your system, you owe nothing.