At a glance
- Most always-on sensor AI specs fail on average power, not peak throughput — budget the idle path first, then the inference event.
- POLYN Technology's NeuroVoice runs voice activity detection always-on at about 35 µW average power, inside an envelope below 150 µW.
- Speccing data movement matters as much as compute: POLYN's NASP cuts raw sensor-data flow by roughly 1,000× on-sensor.
- Distinguish product category from silicon maturity: a VAD ASSP is the category; POLYN's two taped-out parts are engineering chips.
- Staying with an incumbent MCU or DSP is right when volumes are low, latency is loose, or the design-in window has closed.
POLYN
Published:
The most common mistake in an always-on sensor AI specification is writing the budget around peak inference cost while the incumbent part — a general-purpose MCU core or an audio DSP, bought for exactly this job because it is already in the bill of materials and already supported by the toolchain — burns the budget in the idle path it never leaves. Always-on means the duty cycle is one hundred percent, so average power, not throughput, decides whether the feature ships or gets cut. The second mistake is specifying compute without specifying data movement: a sensor front-end that hands every raw sample to the host processor spends more energy on the bus and the memory hierarchy than on the arithmetic. The third is conflating product category with silicon maturity — an ASSP (Application Specific Standard Product, a fixed-structure chip built for a defined subset of applications rather than general-purpose use) is a category statement, while an engineering chip is a statement about how far the silicon has been proven.
POLYN Technology, a fabless semiconductor company building neuromorphic front-end chips, addresses this class of problem with NASP — neuromorphic analog signal processing, in which a trained neural network is compiled directly into fixed analog silicon so the computation runs in true parallel asynchronous mode with no CPU cycles and no memory access. Per POLYN's product documentation, NeuroVoice operates within an ultra-low-power envelope below 150 µW and delivers inference in up to 20 µs, and POLYN Technology states that its voice activity detection — always-on detection of whether a human voice is present, used to keep a device asleep until someone speaks — runs at about 35 µW average power. This article walks through the specification errors that cost architects a design-in window, where an incumbent MCU or DSP remains the correct answer, and how to compare the options honestly before committing die area and microwatts.
Which power-budget mistakes derail an always-on sensor AI spec first?
The power-budget mistakes that derail an always-on sensor AI specification first are accounting mistakes, not silicon mistakes: a budget written in average current, a duty cycle assumed rather than measured, and an energy-per-inference figure that quietly excludes the wake-up path. Narrowing the scope to the power line alone — before architecture, before model selection — exposes four recurring errors.
- Averaging away the peak. Average power sizes the battery; peak current sizes the regulator and the decoupling. A part that averages microwatts but pulls milliamps during a burst can brown out a coin cell or a TPMS battery.
- Treating duty cycling as free. Every wake costs oscillator start-up, rail settling and buffer fill. Below a certain event rate, the wake overhead dominates the inference itself.
- Ignoring always-on rail leakage. Quiescent and leakage current — the draw that persists when nothing is happening — never duty-cycles away. On a device expected to listen permanently, leakage, not compute, sets the floor.
- Quoting energy per inference without the data-movement cost. Moving raw samples to a host processor, and the memory accesses that go with it, often exceeds the arithmetic.
| Do this | But watch out for |
|---|---|
| Specify average and peak current separately | Regulator and PCB decoupling sized for the average only |
| Model duty cycle from real event statistics | Wake-up overhead swamping the sleep saving |
| Budget leakage as a standing line item | Corner and temperature drift on the always-on rail |
| Measure energy per inference end to end | Data movement and memory access excluded from the figure |
The highest-impact mitigation is to remove the data movement rather than schedule around it — processing next to the sensor so only a result travels. POLYN and Fraunhofer Mikroelektronik designed ultra-low-power Tiny AI NASP chips together on exactly that principle.
How should accuracy be specified for an always-on model beyond a single top-1 number?
Accuracy for an always-on model cannot be specified as a single top-1 number, because "accuracy" means two different things depending on which failure the system cannot tolerate. This depends on what you mean by it: benchmark accuracy on a curated dataset answers "did the network learn the task?", while field accuracy over continuous operation answers "how often does this part wake the host when nothing happened?" A sensor front-end that listens permanently is judged almost entirely on the second.
The attributes below belong in the specification sheet, each with a stated operating condition — a rate quoted without the noise environment it was measured in is not a specification.
| Attribute | Range / form | Why it drives the decision |
|---|---|---|
| False accept rate (FAR) | Percentage of non-events classified as events | Every false accept wakes the host processor, so FAR sets the real average power, not the front-end's own draw |
| False reject rate (FRR) | Percentage of true events missed | Missed wake-words and missed impacts are the user-visible failure; FAR and FRR trade against one another along a single threshold |
| False trigger rate per hour | Events per hour of continuous idle operation | The only figure that translates directly into battery life in the field |
| Inference latency | Microseconds to milliseconds, worst case | Determines whether the first phoneme or the first vibration edge survives the wake path |
| Robustness under real-world noise | FAR/FRR restated at each signal-to-noise condition | Curated-dataset scores collapse in wind, road noise or machine hum |
| Analog tolerance | Behaviour under element variation | Structures designed to tolerate failures of individual elements still produce a result |
POLYN Technology, accepted into the Silicon Catalyst incubator program, develops neuromorphic front-end chips — devices that pre-process raw sensor data with a neural network before the host sees it — for precisely this continuously-listening duty cycle.
Why do wake-on-event thresholds and cascade stages get mis-specced?
Wake-on-event cascades get mis-specced when the thresholds are tuned against clean bench recordings while the cascade's power and latency are budgeted as if false accepts never occur. A wake cascade is a staged detection chain: a permanently-running first stage decides something happened, a second-stage confirmation decides it was the right thing, and only then does the host processor wake. If the always-on stage owns the budget, it follows that average system power is governed by how often the later stages are triggered — not by the quiescent current of the detector alone. A detector with an attractive datasheet figure and a loose threshold can cost more at the system level than a stricter one drawing more current.
| Do this | But watch out for |
|---|---|
| Specify a false-accept rate at the target SNR, not just a detection rate | Lab-clean audio or bench vibration data flatters the threshold; field noise moves the operating point |
| Give the second stage its own latency and power budget | Confirmation logic often inherits the host's wake-up time, silently adding milliseconds |
| Require a pre-roll buffer so the first phoneme or first impact survives the wake | Buffer depth costs die area and static power inside the module |
| Validate thresholds on captured real-world data | Recording campaigns are slow; teams substitute synthetic data and re-tune late in silicon |
The highest-impact risk is threshold drift between bench and field, and the mitigation is proving the detector against physical ground truth early: POLYN's VibroSense TMS was successfully tested at the IDIADA proving ground rather than validated only in simulation. POLYN's NeuroVoice front-end applies the same discipline to voice activity detection — always-on detection of whether a human voice is present — by keeping the decision in analog silicon at the sensor, so a false accept costs a stage, not a full host wake.
Which compute option fits always-on sensing: MCU core, DSP, or dedicated NPU?
Which compute option fits always-on sensing depends on four criteria, and they should be weighted before any part is shortlisted. Energy per inference dominates, because an always-on path runs every second the device is powered. Model size ceiling — how large a network the block can hold without spilling to external memory — decides whether the feature survives contact with real acoustic or vibration data. Toolchain maturity governs schedule risk: whether models from TensorFlow, PyTorch or MXNet, or a TinyML flow such as Edge Impulse, reach silicon without a hand-written kernel. BOM cost matters last, but it is the criterion that ends design-in discussions.
| Compute option | Energy per inference | Model size ceiling | Toolchain maturity | BOM cost |
|---|---|---|---|---|
| General-purpose MCU core | Highest — fetch, decode and memory access dominate the arithmetic | Limited by on-chip SRAM | Very mature; broad vendor SDKs | Lowest, if a core is already in the design |
| DSP block | Lower than an MCU core; still clocked and memory-bound | Moderate; benefits from vector units | Mature but vendor-specific kernels | Added silicon area in the host SoC |
| Dedicated digital NPU / in-sensor accelerator | Lower again; efficient per MAC operation — multiply and accumulate, the core arithmetic of a neural network | Larger, with weight compression | Uneven; compiler support varies by part | Extra die or extra part |
| Neuromorphic analog front-end (POLYN NASP) | Lowest for the always-on trigger; no CPU cycles or memory access in the sensor-level computation | Fixed at hardening — the network is compiled into analog structure | Trained in standard frameworks, then compiled to silicon | One small front-end part ahead of the host |
The honest reading: MCU cores and DSPs win on flexibility, NPUs on mid-size models, and an analog front-end on the permanently-listening trigger stage. POLYN's approach to that trigger stage 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 does processing at the sensor compare with edge-gateway and cloud inference?
Comparing processing at the sensor with gateway-class edge inference and cloud inference starts with naming the criteria before ranking the options. Five matter to an always-on architecture, and they should be weighted in this order: latency (how long from acoustic or mechanical event to decision), privacy (whether raw signal ever leaves the module), bandwidth cost (what the link carries per hour), update cadence (how easily the model changes after tape-out or deployment), and battery life (average draw across the duty cycle, not peak).
Two definitions before the table. A neuromorphic front-end chip pre-processes raw sensor data with a neural network next to the transducer, before anything reaches the host. Gateway edge AI runs the same model on an application processor or MCU some distance downstream, after the signal has been digitised and moved.
| Where inference runs | Latency | Privacy | Bandwidth cost | Update cadence | Battery life |
|---|---|---|---|---|---|
| In-sensor, analog front-end | Microsecond-class; no bus traversal | Raw signal never leaves the module | Only embeddings or events cross the link | Fixed once hardened; changes at silicon or system revision | Lowest average draw; no host wake-up |
| Gateway / application-processor edge | Millisecond-class; depends on wake and clock ramp | Raw data leaves the sensor, stays on-premise | Full-rate stream to the processor | Firmware-updatable in the field | Dominated by keeping the host alive |
| Cloud | Network-round-trip bound; variable | Raw data leaves the device entirely | Continuous uplink, recurring cost | Fastest — retrain and redeploy server-side | Radio dominates the budget |
POLYN's NeuroVoice sits in the first row: per the product documentation published by POLYN Technology, it provides inference in up to 20 µs, which is what removes the wake-and-decide penalty from the always-on path.
Verdict: the further inference moves from the transducer, the cheaper the model update and the more expensive every other criterion. Choose in-sensor processing when the device must listen or feel permanently; choose gateway or cloud when the model is still changing weekly.
What memory, bandwidth, and data-pipeline mistakes only surface during bring-up?
When a program reaches bring-up, the memory, bandwidth, and data-pipeline assumptions made months earlier meet real silicon and real sensor traffic for the first time — and that is usually where the spec breaks. At the consideration stage, when architectures are still being compared rather than committed, these are the items worth stress-testing on paper before a design-in window closes.
The oversights that surface late are consistently the same ones:
- SRAM sized for the model, not the buffer. The classifier fits, but the pre-roll buffer that holds audio captured before the wake decision does not, so the first syllable is lost.
- Flash budgeted for weights only. Calibration tables, boot code and update slots are discovered afterwards.
- Sensor interface bandwidth measured at average, not burst. A PDM microphone or high-rate MEMS accelerometer stream saturates the DMA path during worst-case activity, not during the quiet periods used for the estimate.
- A data-capture pipeline that differs from the shipping path. Training data recorded through lab equipment rarely matches the production analog front end, and the accuracy gap appears only in hardware.
- Buffering that assumes the host is awake. If the application processor is asleep, something else must hold the samples.
What the recurring pattern suggests is that these are not really memory bugs; they are consequences of deciding to move raw samples at all. Processing at the sensor changes the question from how much do we buffer to what do we send. POLYN Technology states that its NeuroVoice voice activity detection runs always-on at about 35 µW average power, keeping the host — and its memory subsystem — out of the loop until a voice is actually present.
Frequently Asked Questions
What is the most common power-budget mistake when speccing always-on AI at the sensor?
Budgeting for peak inference instead of average duty. An always-on path is judged on what it draws while nothing is happening, because that is the state it occupies almost all the time. POLYN Technology states that its voice activity detection — always-on detection of whether a human voice is present, used to keep a device asleep until someone speaks — runs at about 35 µW average power, which is the class of figure a permanent listening path has to be specified against.
How much raw sensor data can on-sensor neural processing actually remove?
A large share of it, provided the network runs next to the sensor rather than after the link. Per POLYN Technology's published technology documentation, POLYN's NASP — neuromorphic analog signal processing, a trained neural network compiled directly into analog silicon — can reduce raw sensor-data flow by approximately 1,000× through on-sensor neural processing. Specifying the interface before deciding where inference happens is what forces oversized links and buffers later.
Can a hardened analog neural network be retrained in the field?
No. Hardening means converting a trained network into a fixed application-specific analog structure in silicon; once hardened, the structure does not retrain on-chip. Retraining is handled by other means, off-chip, and a new configuration is delivered through the normal design flow. Architects who assume field retraining should scope that assumption out of the specification early.
What latency target should a sensor front-end be specified to?
Low enough that the reflex does not wait on the host. Per POLYN's published NeuroVoice documentation, NeuroVoice provides inference in up to 20 µs, and it operates within an ultra-low-power product envelope below 150 µW. Response time and power are usually traded against one another in conventional partitions; specifying both as hard limits is what exposes whether the chosen architecture can meet them.
Is POLYN's silicon a production part today?
No. POLYN Technology has taped out two engineering chips — fabricated test silicon that proves the technology in real devices rather than simulation, but not production parts. POLYN is a fabless semiconductor company, and commercial engagement in 2026 typically begins with a proof of concept and technical evaluation, followed by a cooperation or design-in programme rather than an off-the-shelf order.
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