White Paper · RPU Microelectronics · October 2026 edition

Reflexive Processing Unit (RPU):
An Adaptive Rate-of-Change Comparator
with Memory

A hardware primitive that decides when a sensor signal has really changed, two clock cycles after each sample, with no CPU in the decision path, and that lets shells be built around it without touching the core.

Author: Özcan Demirkıran — Founder & Principal Architect, RPU Microelectronics, Kocaeli, Turkey
IP status: Patent pending · PCT/IB2026/053070 (filed 27 March 2026) · priority TR 2025/012696 (4 September 2025)
Evidence levels: board (FPGA) · RTL simulation · bit-exact model · synthesis tool estimate
Contact: ceo@rpu-micro.com · rpu-micro.com · Design & Reuse: RPU-REFLEX 01
Abstract

Every always-on system first decides whether a sample is worth acting on. That decision is made today by a memoryless level comparator, which cannot follow drift or a moving noise floor, or by firmware, which needs an awake processor to run it. The Reflexive Processing Unit (RPU) makes it in hardware. It keeps the last N samples, compares the means of the newer and older halves of that window, and adapts its threshold to the noise floor; the decision arrives two clock cycles after each sample with zero jitter. An event shell, a separate state machine that never writes the core's metric or threshold, adds interrupt control and sensor-health reporting. The block occupies 2,960 standard cells in TSMC 65nm and meets a 1.6 ns (625 MHz) timing target in synthesis. In an Ibex RISC-V system on an FPGA board, board counters matched full-system simulation in 101 of 101 runs. Tuned once and frozen, it caught every event across a σ 25 → 400 noise sweep and, at the highest noise, woke the CPU 483 times against 936 for a comparator tuned the same way; on real earthquake records it matched STA/LTA (213 vs 210 of 300), on par at every false-alarm budget from 2 to 20 per hour, with equal or shorter latency. As noise rises, a frozen comparator floods the CPU; the RPU's threshold rises with the noise.

The first decision

Every always-on system, whether a seismic node, a wearable, a vibration monitor or a battery pack, spends most of its life watching a signal that has not meaningfully changed. Before any useful work, it must answer one question: is this sample worth waking for?

The cheapest 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: temperature, ageing and load move the baseline, and a fixed reference either fires on the drift or must be set so high that real events pass unseen. It cannot follow a moving noise floor: when wind, traffic or machinery raise the noise it floods the CPU with interrupts, and when they fall, a reference set for the noisy hours misses small events.

So a comparator never works alone. Around it sits firmware that re-centres the baseline, retunes the reference, filters spikes and handles faults, and a processor that must stay awake often enough to run it. A processor has to be awake to decide that it may sleep.

CPUs execute, GPUs parallelise and NPUs infer. Each makes computation faster or cheaper once it has started. None of them decides whether a computation should start at all. The RPU moves that first decision out of the instruction stream and into the signal itself.

The algorithm alone is not the point: it can be written in software, and a C version exists. What software cannot change is where the decision is made. A software version can only decide while the processor is awake, so it spends the energy it is trying to save.

Architecture

The RPU implements one rule in hardware: keep local state, measure how it changes over time, and act when the change crosses a threshold. With a window of N = 2H samples, the metric m, the alarm a and the threshold θ are:

m[n]   = | (1/H)·Σ x[n−i], i = 0…H−1  −  (1/H)·Σ x[n−i], i = H…2H−1 |
a[n]   = 1  if ready[n] and m[n] > θ[n],  otherwise 0
θ[n+1] = clip( P(θ[n], m[n]), L, U )

The chain has four stages, each replaceable without redesigning the others:

StageDelivered todayDesigned alternatives
StateRing buffer of the last N samples (N = 8 to 128, a power of two), split into an older and a newer halfRunning integrator. Multi-scale windows on one buffer and a time-shared multi-channel core are built and board-tested
Temporal metricAbsolute difference of the half-window means, kept by two running sums: the same few additions per sample at any window size, no multiplier or dividerVariance, slope, multi-metric family on the same buffer
PolicyFixed threshold, or adaptive: steps up in noise and down in quiet, clamped to bounds, with a runtime-writable ceiling. Option: proportional setpointsBounds learned from the metric statistics
ActionDecision two clock cycles after the sample, zero jitter; registered wake/interrupt one cycle later; clock-gate enablePower gating, staged wake-up, multi-bit action vector

Because the metric compares two window averages, a constant offset cancels, slow drift gives a small metric and a step or burst a large one. The block is a side-band peripheral: it reads the sample stream, has no bus-master or memory-write path, and removing its wake line returns the system to its previous behaviour.

Figure 1 · Decision chain and event shell

Sensor / ADC 12-bit samples · in_data, in_valid RPU core 1 · State ring buffer of the last N = 2H samples 2 · Temporal metric m = | mean(new half) − mean(old half) | 3 · Policy adaptive threshold θ within bounds L … U 4 · Decision a = m > θ · 2 clocks, zero jitter a[n] Event shell coalescing · hardware ACK holdoff · wake budget held-alarm delivery stream & heartbeat timeouts frozen-value check low-sensitivity flag back-dated onset reads a[n] and ack only CPU sleeps in WFI until woken (lowRISC Ibex RISC-V on the board) wake_en fault ack configuration registers, out of band: the decision path never waits for software
The core produces one decision per sample. The shell reads only the decision stream and the CPU's acknowledgements, and never writes the metric or the threshold.

The event shell

The shell is a second state machine s that decides which decisions become interrupts e:

e[n] = G( s[n−1], a[n] )
s[n] = U( s[n−1], a[n], ack[n] )

Because it never writes m or θ, shell functions can be added, removed or corrected without touching the core mathematics or its verification. The frozen-value check with its report-once fault interrupt, the low-sensitivity flag, the back-dated onset and a selectable input conditioner (raw by default) were all added this way, with the delivered core left byte-for-byte unchanged. New behaviour inside the core enters as parameters instead: with the options switched off, the extended core was proven equivalent to the delivered one by induction in Yosys for four parameter sets.

Memory is the difference

A comparator is memoryless. The RPU keeps the last N samples, two running sums and the history of its own threshold, and each capability below follows from that memory: immunity to drift (it compares the signal with its own past), immunity to spikes (an isolated spike is spread over the window and attenuated H-fold), adaptation to the environment (the threshold history is a learned noise floor), silence as information (recognising a frozen value needs a history), the shape of a change (step, ramp and spike leave different metric trajectories), knowing when it is blind (a threshold pinned at its ceiling), and a pre-event record (at every trigger the buffer holds the N samples before the event).

More than one "when" question

Changing what feeds the chain changes the question it answers, with the same circuit. Sensor samples ask whether a change has started; measured minus expected values ask whether a system is leaving its expected behaviour; measurements after a command ask whether it took effect in time; the time between events asks whether the event rate is changing. The output need not be a wake-up either: with a suitable policy the same core can signal inspect, wait, measure (the signal has settled), test, record, recompute or retune.

Predictable by design

Because the metric is a fixed arithmetic operation, the RPU's response to common signal shapes can be calculated before deployment. The relations below were confirmed on the bit-exact model of the RTL with H = 32.

InputRPU responseWhat it means
Single spike of size BMetric rises only to B/H, for 2H samples (900 gives 28)Glitches attenuated H-fold; spikes below H·θ never trigger alone
Step of size AMetric climbs linearly to A over H samples, returns to zero after 2HDetection delay ≈ H·θ/A samples, known in advance
Ramp of slope sMetric settles at s·HThe threshold is a slope limit θ/H, specifiable in physical units
Periodic interference, period divides HMetric stays at zeroMains hum or rotation cancelled by choice of sample rate and window; a window of half the period does the opposite and is avoided
White noise, std. dev. σApproximately half-normal, spread σ·√(2/H)False-alarm probability follows from the threshold in closed form

Every configuration can therefore ship with a statement of what it will and will not detect: a step of a given size within a known delay, and isolated spikes below a known size never. That is the kind of evidence safety certification asks for, and a trained classifier cannot give.

Evidence

All system tests use the same Ibex firmware with the CPU sleeping in WFI; the only difference between arms is the detector. The comparator is an EWMA-baseline comparator tuned on the same data. Detection is always reported next to wake-ups, because a low wake count can also mean a blind detector.

Robustness with settings frozen

TestResultLevel
Unseen recordings U1–U3Events: RPU 10/12 with 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 caughtBoard
Proportional setpoints, 4 held-out foldsHeld-out total 57/61 events and 120 false alarms, against 45/61 and 122 for the delivered setpoints; the chosen setting matched simulation on the board 8/8Model + board
Noise sweep, σ 25 → 400Both tuned once at σ 200, then frozen. 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 rightsWake-ups: comparator 517, RPU 483, RPU with S1 gate 373; all 4/4 eventsRTL simulation
S1 shape gate (core option), held-out dataUnmatched alarms −54%, interrupts −33%, CPU active cycles −30%; no detected event lost; +59 LUT, +29 FFBoard, 20/20

Real sensor data

DatasetResultLevel
STEAD, earthquake P-wave arrivalsOn par with STA/LTA at every false-alarm budget from 2 to 20 per hour (e.g. RPU 213/300, STA/LTA 210/300 at up to 20 per hour); median latency equal or shorterBit-exact model
CWRU, bearing faultsOne RPU with a rectifier front end: 25/27 with 0 false alarms; comparator and STA/LTA alone 27/27 at 1.5–6 false alarms per minute. In a pre-registered hybrid test, two RPU cells (raw OR envelope) reached 27/27 with 0 false alarms, as did a STA/LTA-plus-derivative hybridBit-exact model

At the real sample rate, and across channels

TestResultLevel
STEAD segment at 100 Hz, RC5.2 against RC5.3CPU wake-ups 798 → 315 with the same 133 events delivered; 137 with a freeze profile calibrated for the sensor. Testing at the real rate showed that in RC5.2 every alarm suppressed by the wake budget raised its own fault interrupt; RC5.3 reports a suppression once per windowBoard, equal to simulation
Multi-channel extensions in the Ibex system3-channel array with 2-of-3 voting, multi-scale core on one shared buffer, time-shared core for 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. Voting did not reduce false alarms on seismic data; the gain is shared hardwareBoard; FPGA synthesis

Sensor health

Fault injection on the board: a stopped stream and a lost heartbeat raise faults as specified. A persistent fault raises a single 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, which raised false freeze faults on real seismic data and are therefore set per sensor; the fault paths ran 10/10 on a fault-injection test build on the board, matching full-system simulation. The check does not detect a recorded signal being replayed.

Implementation

2,960
standard cells, 0.018 mm², TSMC 65nm GP
625 MHz
timing target met, 65nm synthesis, stand-alone core (Cadence Genus)
101/101
board runs matching full-system simulation
2 clk
decision latency, zero jitter

A power sweep of the RPU block in TSMC 65nm GP at the worst-case corner (activity-based, from a gate-level VCD of the system running a real stimulus) gives 3.98 mW at 490 MHz, 0.852 mW at 100 MHz, 0.129 mW at 10 MHz and 56.6 µW at 1 MHz. SkyWater SKY130: timing met at 100 MHz, about 0.047 mm², 3.876 mW with 0.014 mW leakage. The system kit runs on a Nexys A7-100T with a lowRISC Ibex core; a clean copy of the delivery package passed its own acceptance run (11/11 board runs, firmware rebuilt byte for byte). The block has not been taped out, and power has not been measured on silicon.

When it saves energy

CPU active cycles and signal transitions are activity measures; they drive dynamic power but are not a battery-life measurement. Whether the RPU saves energy in a given system follows from one inequality:

S  >  P_RPU / (P_gated − P_idle)

S, the temporal sparsity, is the share of time the data is quiet; P_RPU is the block's own power; P_gated and P_idle are the active and idle power of what it lets sleep. For analog sensors the ADC must stay on to feed the RPU, so system power should be quoted with the ADC included. The RPU can work with an analog front end rather than against it: an analog wake-up stage keeps the ADC off until something happens and the RPU confirms the change and checks sensor health before the CPU wakes; or the ADC samples slowly while the scene is quiet and the RPU raises it to full rate when a change starts. The two-clock latency is counted from the accepted sample, so system latency then also includes the ADC's wake-up and settling time and a window refill. Both are designed options; neither has been built or measured yet.

Energy is often not the main reason. Deterministic, netlist-analysable timing; a trigger that keeps working if firmware hangs; sensor-fault reporting; and capacity freed on the processor matter in mains-powered and certified systems too. If a feature goes unused, the cost is its area: about 340 LUTs and 230 flip-flops on the FPGA and well under 1% of a real SoC.

Where it fits, and where it does not

The RPU fits where a system must watch continuously, the data is quiet most of the time, and the noise floor moves with weather, load or temperature: seismic and perimeter sensing, structural health, battery thermal-runaway watch, grid protection on the rate of change of frequency, predictive maintenance, wearables and implanted sensing, certified automotive, avionics and medical systems, edge-AI front ends, energy-harvesting nodes, smart meters and trackers, and sensor-health supervision. Placed inside a sensor interface chip, directly after the ADC, it turns an ordinary sensor into an event-detecting one.

It is not a fit for streams that change on every sample, such as video or scrambled serial links; for events below the noise floor that need matched filtering first; or for subtle anomalies that need a classifier. For safety uses, rate of change is paired with a simple level guard, the way fire detectors pair a fixed-temperature limit with a rate-of-rise trigger. The RPU avoids unnecessary computation; it does not make necessary computation faster.

Integration

The core taps the sample stream and drives a standard interrupt. Illustrative instantiation of the reference core:

// Reference core rpu_ultimate_final.sv (GitHub); the evaluation kits carry the delivered core.
rpu_ultimate_final #(.DATA_WIDTH(12), .DEPTH(32), .USE_DYNAMIC_TH(1'b1)
  /* MIN_TH_P, MAX_TH_P, STEP_UP_P, STEP_DN_P, HI_DELTA_P, LO_DELTA_P: size from your signal */) u_rpu (
  .clk      (sys_clk),
  .rst_n    (sys_rst_n),
  .in_data  (sensor_data),     // read-only tap
  .in_valid (data_valid),
  .wake_en  (irq_external_i)   // RISC-V; or any NVIC line on Arm Cortex-M
  /* observation outputs left open on first integration */
);

Window depth, threshold bounds and adaptation steps are synthesis or register parameters. The RPU is one RTL source tuned per application: signal scale, sample rate, the shape and duration of the target event, and the relative cost of false alarms and misses all matter. Our calibration tool, which matches the RTL bit for bit, selects a profile on part of a partner's recordings, freezes it, and reports detection, false alarms and CPU activity on the rest, next to a comparator tuned on the same data.

Related approaches

Software DVFS and power-management units act through a software layer on load, not on data change. Conventional clock gating follows an enable generated elsewhere. Firmware triggers such as STA/LTA adapt well but need an awake processor. Accelerometers with built-in wake logic show that buyers pay for this function, but we have not found an equivalent licensable block for geophones, strain gauges, hydrophones, current shunts or pressure probes.

Research on neuromorphic and memristor-based perception explores adaptive, change-driven sensing with new devices and network-level control. The search report for our Turkish priority application cites Wang et al. (Nature Communications, 2024) and HP US8450711B2 in category Y, and IBM US11144718B2 and University of Michigan US9111613B2 in category A. The RPU takes a narrower route: one decision rule, in standard CMOS, inside the block.

Status and availability

ItemStatus
Core evaluation kitSystemVerilog RTL, testbenches, assertions, Nexys A7 build; board acceptance runs passed
System evaluation kitIbex RISC-V SoC with the RPU and event shell; 101/101 board runs matched simulation; clean-copy acceptance passed
ASICSynthesized in TSMC 65nm and SKY130, timing met; tape-out partner sought
IPPatent pending: PCT/IB2026/053070, priority TR 2025/012696. No patent granted yet
NextPilots on customer sensor data, field tests with a live ADC, a tape-out partner

Evaluation is free for 30 days under NDA. Research and academic use of the reference RTL is free; commercial use requires a written licence. We invite evaluators to try to break the RPU rather than take our word for it: tune once and change the noise floor; stop the stream or freeze the value; try to silence the trigger from firmware; measure the decision latency under load.

Özcan Demirkıran — Founder & Principal Architect
RPU Microelectronics · Kocaeli, Turkey
ceo@rpu-micro.com · +90 536 636 10 72
rpu-micro.com · Design & Reuse listing ↗

"The cheapest computation is the one that never occurs."