At a glance
- An MCU wake filter answers "was there energy?"; an inference chip answers "was it a voice?" — different accuracy, different power.
- POLYN's voice activity detection runs always-on at about 35 µW average power, keeping the host processor asleep until speech is present.
- NeuroVoice provides inference in up to 20 µs, per POLYN's published product documentation, well inside a below-150 µW envelope.
- NASP compiles a trained neural network directly into analog silicon, removing CPU cycles and memory access from sensor-level computation.
- Decide with a prerequisites check, a measured baseline, and staged evaluation steps before committing to a design-in window.
POLYN
Published:
If your always-on path only has to notice that something happened — a threshold crossing, a loud transient, a step change in RMS energy — an MCU wake filter is enough, and adding an inference part will not pay for itself. If the path has to decide what happened before waking the host — that this sound is human speech and not a slamming door, that this vibration signature is a bearing defect and not road noise — you need a real inference chip, because a threshold detector has no way to represent the distinction and will pay for the difference in false wakes. The decision is arithmetic, not preference: measure the false-wake rate your comparator produces in the real acoustic or mechanical environment, multiply by the host's wake energy and wake latency, and compare that total against the standing cost of continuous inference. POLYN's voice activity detection — always-on detection of whether a human voice is present, so the device stays asleep until someone speaks — runs at about 35 µW average power per an independent lab measurement, and NeuroVoice provides inference in up to 20 µs according to POLYN's published product page, which is the order of magnitude a wake filter's spurious activations have to beat. This guide walks the evaluation as a procedure: what to have in hand, what to measure, in what order, and where the comparison usually goes wrong in 2026 design reviews.
What is an MCU wake filter versus a real inference chip?
The phrase "wake filter" on an MCU and "inference chip" describe different signal path positions, not maturity grades. This section addresses the always-on stage between raw sensor stream and sleeping host processor. Two readings yield different silicon.
Reading one — the MCU wake filter. An always-on gating model runs as firmware on a microcontroller core or sensor hub: energy threshold, band-limited envelope detector, or small quantized classifier. The MCU digitizes continuously, keeping ADC, clock tree and memory accesses alive even when idle. Typical case: RMS-energy gate on MEMS microphone waking the application processor when ambient level crosses threshold — cheap but false-trigger prone.
Reading two — the dedicated inference chip. An NPU or edge AI accelerator: fixed-function digital datapath executing trained network MAC operations — multiply-and-accumulate, the core arithmetic of neural layers. It decides rather than gates, but remains a clocked machine fetching weights from memory.
A third architecture answers differently. In neuromorphic analog signal processing (NASP), the trained network hardens into fixed analog structure: Ohm's law performs multiply, summing resistors perform accumulate — no instruction fetch, no weight memory. POLYN and Fraunhofer Mikroelektronik designed ultra-low-power Tiny AI NASP chips together. Separately, POLYN reports two engineering chips taped out — engineering parts, not production silicon — so the architecture has been exercised in fabricated form rather than in simulation alone.
| Attribute | MCU wake filter | Digital inference chip (NPU) | Neuromorphic analog front end |
|---|---|---|---|
| What it computes | Threshold or gating heuristic | Quantized neural network | Network hardened into analog structure |
| Memory access | Continuous | Weight fetch per inference | None at sensor-level computation |
| Position | Sensor hub / MCU core | Between hub and host | Directly beside the sensor |
Most architects mean reading one — the real question is whether that gate is accurate enough to justify keeping it awake.
Which always-on workloads can a wake filter actually handle on its own?
An always-on wake filter — a small model running continuously on a general-purpose microcontroller and raising an interrupt when something interesting appears — handles a narrow but real set of workloads. The dependable ones are binary gates: a yes/no decision on a low-bandwidth stream, where a false positive costs only an unnecessary host wake-up.
| Workload | Sensor modality | Model class | Footprint on a Cortex-M-class part | Accuracy characteristic |
|---|---|---|---|---|
| Keyword spotting (fixed wake word) | MEMS microphone | Small CNN or DS-CNN on MFCC features | Fits on-chip SRAM | Good in quiet, degrades sharply in noise |
| Voice activity detection (VAD) — is a human speaking? | MEMS microphone | Energy/spectral gate or tiny classifier | Smallest of the five | Usable, but tuned conservatively to avoid missed speech |
| Motion gating | Accelerometer, IMU | Threshold plus decision tree | Negligible | Robust; the physics is simple |
| Person-present detection | Low-resolution thermal or ToF | Quantised binary classifier | Largest; often needs frame buffering | Adequate at short range only |
| Vibration anomaly trigger | Accelerometer, piezo | Autoencoder or statistical baseline | Model fits; the sample buffer does not | Flags deviation, cannot classify fault type |
The attributes that decide feasibility are sampling rate, feature-extraction cost, model memory, and tolerable false-positive rate. The limiting attribute is rarely model size — it is the duty cycle needed to catch a short event.
Any workload requiring continuous extraction rather than a gate — separating one voice from background noise, or characterising a signal through every rotation — is not a wake problem and will not fit this envelope. That boundary is where neuromorphic front-end silicon applies; POLYN, a fabless developer of such parts, was accepted into the Silicon Catalyst incubator program.
When does a wake filter break down and force you to add a dedicated NPU?
A wake filter can break in two distinct ways, and the fix differs depending on which one you are seeing. A wake filter here means a fixed-function gate on the MCU — an energy threshold, a band-pass stage, or a small always-on classifier — that decides whether to rouse the main processor. The first is a statistical failure: the gate still runs inside budget, but no longer separates the target event from the background. The second is a budget failure: accuracy is reachable, but only at a duty cycle, clock rate or memory footprint the always-on rail cannot fund. An NPU — a neural processing unit, a digital block dedicated to running inference — answers the second case more readily than the first.
| Failure signal | Do this | But watch out for |
|---|---|---|
| False accepts wake the host on noise; false rejects clip the first phoneme | Move discrimination into a trained model, not a hand-tuned threshold | A larger model raises the always-on power floor the gate was meant to protect |
| Response time misses the reflex window at the required sample rate | Shorten the path — infer next to the sensor, not after the bus | Digital pipelines buy latency with clock frequency, which costs power |
| RAM and flash exhausted by weights and feature buffers | Re-scope the front end to detection only, deferring classification | Splitting the model adds an interface and synchronisation cost |
| Multi-class audio, vibration or contact-sensing workloads | Add a dedicated inference stage, such as a POLYN NASP neuromorphic front-end chip | Fixed analog structures are hardened at tape-out; retraining happens off-chip |
| Frequent model update cadence | Keep updatable layers on reprogrammable silicon | Update flexibility competes directly with power |
Mitigate the highest-impact risk — the rising always-on floor — by validating the front end against real physical data early. It is also worth checking whether a candidate NASP front end exists as fabricated silicon rather than only as a simulation result: POLYN reports two engineering chips taped out, and is explicit that these are engineering parts rather than production silicon.
How do MCU wake filters and inference chips compare on power, latency, memory, and BOM cost?
Compare an MCU wake filter against a dedicated inference chip only after criteria and weights are fixed — otherwise comparison collapses into unit price. A wake filter is a threshold or fixed-coefficient filter on the host MCU or DSP deciding when to wake the main processor; an inference chip runs a trained neural network in dedicated silicon next to the sensor.
Weight criteria in this order for always-on paths:
- Idle / always-on power — the dominant term, because that branch never stops drawing current.
- Inference latency — decides whether the system reacts before the host wakes.
- Model size ceiling — governs false-accept rate; a filter cannot learn what it was never given coefficients for.
- Toolchain effort and unit cost — decide whether the part clears the design-in window, but should never outrank the first two.
| Approach | Active power | Always-on power | Latency | Model ceiling | Toolchain effort | Unit cost | Typical use case |
|---|---|---|---|---|---|---|---|
| MCU/DSP wake filter | Moderate | Highest of the three | Bounded by clock and software stack | Threshold logic, small fixed filters | Lowest — firmware only | Lowest, reuses existing silicon | Coarse energy-threshold wake with generous battery |
| Hybrid two-tier | Moderate on tier two | Reduced, but tier one still clocked | Two-stage, additive | Small model in tier one, larger on wake | Highest — partitioning plus two build flows | Adds a part to BOM | Retrofits where host stack cannot change |
| Dedicated inference chip | Confined to front end | Lowest — network itself is always-on stage | Front-end decision, no host round trip | Full trained network hardened into silicon | Model training plus compilation, no firmware loop | New part, amortised across volume | Permanent listening, in-tire sensing |
POLYN's sensor-edge neuromorphic work has been covered by EE Times Europe, Planet Analog, All About Circuits, EE Journal, Embedded Computing Design, New Electronics, eeNews Embedded and Hackster, and presented in a tinyML Talks session.
How do you decide which tier your product needs?
Deciding which tier a product needs is a consideration-stage exercise: you are proving which class of part your power and latency budgets can carry. Work through it in order.
- Define the trigger event first. State exactly what must wake the system — a voice onset, an impact, a vibration signature — and the acceptable false-accept and false-reject behaviour. Expected outcome: a one-paragraph trigger specification your team agrees on before any silicon is discussed.
- Budget the duty cycle and the energy per inference. Duty cycle is the fraction of time the detection path is active; energy per inference is the charge consumed each time it runs. Weigh both against your battery or harvesting envelope. Expected outcome: a hard ceiling that any candidate must sit under.
- Benchmark the candidate model on target hardware, not on a datasheet. Measure wake-to-decision latency and average current on the actual MCU, DSP or front-end device, with the sensor attached. Getting a neuromorphic candidate onto the bench works differently from ordering a catalogue part: POLYN, for one, does not sell off the shelf — engagement runs as a proof of concept or a cooperation agreement, so plan that lead time into the evaluation. Expected outcome: measured numbers you can defend in a design review.
- Choose the tier against those two ceilings. A wake filter suits coarse triggers with generous latency; a two-tier cascade suits mixed workloads; a dedicated always-on inference device — a NASP front end such as POLYN's NeuroVoice family, which sits directly beside the microphone — suits paths where the decision must be both continuous and effectively instantaneous at the sensor.
The tier question is routinely filed as an accuracy problem when the binding constraint is usually what the rest of the system is doing while it waits for confirmation. Settle that, and the tier chooses itself.
Frequently Asked Questions
What is the difference between an MCU wake filter and a real inference chip?
An MCU wake filter is a lightweight screen — typically an energy, amplitude or threshold test running on the host microcontroller — that decides only whether something happened. A real inference chip runs a trained neural network on the raw sensor signal and returns a classified decision, such as voice activity detection (VAD): always-on detection of whether a human voice is present, used to keep a device asleep until someone actually speaks. The practical distinction is false wakes. A threshold filter cannot separate speech from a slammed door; a trained network can, which is why a wake filter that keeps the application processor booting all day can cost more system energy than the inference stage it was meant to replace.
How much power does always-on voice activity detection actually consume?
POLYN's voice activity detection runs always-on at about 35 µW average power, per an independent lab measurement. For a device expected to listen permanently, that envelope is the whole argument: the always-on path is what sets the battery budget, and a detection stage that draws that little on average does not need to be duty-cycled, gated behind a button, or pushed to a host processor that must wake to evaluate every candidate event.
Why does an analog neural network cost less energy than the same network on an MCU?
Because the arithmetic is free. The fundamental operation of a neural network is the MAC — multiply and accumulate. In analog silicon, Ohm's law performs the multiply (V = I × R) and summing resistors into a single amplifier performs the accumulate. POLYN's NASP (Neuromorphic Analog Signal Processing) compiles a trained network directly into that analog structure, so the computation runs in true parallel asynchronous mode. There are no instruction fetches and no weight loads from memory: NASP removes CPU and memory-access overhead from the sensor-level neural-network computation entirely, which is where most of the energy goes in a digital implementation.
How fast can a sensor-side inference decision be returned?
POLYN reports that NeuroVoice provides inference in up to 20 µs. That figure matters wherever response time, rather than average power, is the binding constraint — a robotic hand that must react before the event reaches central compute needs something closer to a biological reflex arc, the fast neural path that acts before the brain has processed the event. POLYN's NeuroSense work targets exactly that sensor-level reflex layer for robotics and physical AI, but it remains in research phase under a joint project; there is no product to specify against today.
Can a hardened NASP network be retrained on the chip?
No. Hardening means converting a trained neural network into a fixed application-specific analog structure in silicon, and once hardened the network cannot be retrained on-chip. Retraining is achieved by other means, off the part. Two consequences follow for an architect evaluating the approach. First, the model must be settled before tape-out, so the training and validation loop belongs entirely in the design phase. Second, the analog structure is designed to tolerate failures of individual elements while still producing a result — a graceful-degradation property that a fixed digital datapath does not offer.
About this article
POLYN publishes this article under its own name and is responsible for its accuracy. Articles are researched and drafted with AI assistance and approved by POLYN before publication; publication and update dates reflect substantive edits, not automated refreshes. Last updated: 2026-08-30