FPGA vs Microcontroller: Which Runs Your Smart Home Hub
Every shipping smart home hub in 2026 runs on a microcontroller or a small application processor. None run on an FPGA. The gap is not an oversight. The workload of a smart home hub is I/O-bound protocol translation and event-driven state management. That is the exact task an interrupt-driven MCU handles efficiently and an FPGA overbuilds for.
This article walks through why the market converged on MCUs for hub duties, what the BOM numbers actually look like once you include NRE, and the specific conditions where an FPGA still earns its keep in a camera-adjacent or video-processing build.
The Real Workload of a Smart Home Hub
A hub spends 99.9% of its time waiting. Commands arrive at irregular intervals: a Zigbee light switch press, a Thread motion sensor notification, a Wi-Fi message from a cloud-linked appliance. Each event generates a small packet (typically 20-80 bytes), a short lookup in a device state table, and a translation to one or more outbound packets on different radios.
Zigbee 3.0 runs on the 802.15.4 PHY at 250 kbps. Thread adds IPv6 on the same radio layer. Wi-Fi operates on its own stack with different timing requirements. BLE sits on yet another stack. A hub with all four radios is juggling four different packet formats and four different retry strategies, but only one of them is active at any given moment. The CPU-bound work is trivial. The hard part is waking fast, routing correctly, and going back to sleep without missing the next event.
That description matches what MCUs do natively. An ARM Cortex-M4 or a RISC-V core with a small RTOS wakes from a low-power state on an interrupt, services the event in microseconds, and returns to sleep. FPGAs can match the latency but not the energy cost per event, and the event rate is the metric that matters over a year of uptime.
The Power Budget Gap
The lowest-power FPGA family shipping in 2026 is Lattice iCE40 UltraPlus, which lists 75 μW standby. That sounds low until you compare to MCUs designed for the same task. An ESP32-C6 in light sleep with RAM retained sits at 15-68 μW depending on which peripherals stay armed. That is a 2-5x gap in standby, and standby dominates the annual energy budget.
Active draw tells the same story. The MCU wakes the specific peripheral needed for the event, processes the packet, and re-sleeps. FPGA implementations often keep larger portions of the fabric active to maintain timing closure across clock domains. Unused LUTs still leak current. Configuration memory still draws power. The architectural advantage runs the wrong direction for this workload.
On battery-backed hubs or solar-powered outdoor bridges, the gap compounds. Every extra 100 μW shortens runtime. Every extra milliwatt in active duty doubles the thermal load at the enclosure. For hubs that sit inside wall plates or weatherproof boxes, thermal headroom decides whether the device survives a summer heatwave.
BOM Cost at Volume
MCU silicon lands between $1 and $5 at 10k+ volumes for capable parts. An ESP32-C6 costs roughly $3 with integrated Wi-Fi 6, BLE 5.3, and 802.15.4 radios for Zigbee and Thread. An STM32F4 runs $2-4 depending on flash size. A Nordic nRF5340 with dual ARM cores and Thread/BLE comes in around $4.
FPGAs capable of implementing useful protocol logic start at $5 for the smallest Lattice parts and climb rapidly. iCE40 HX1K is the entry point at roughly $3 but lacks the LUT count for meaningful protocol stacks. Realistic FPGA silicon for hub-class work sits at $10-40 per unit. That alone doubles or triples the silicon line on the BOM.
Non-recurring engineering widens the gap further. MCU firmware with a mature RTOS and vendor-supplied protocol stacks costs $5K-20K to productize for a competent team. FPGA designs require HDL expertise, Vivado or Quartus licenses, multi-week timing closure cycles, and a verification strategy that covers every corner case. $50K-200K of NRE before the first production unit ships is the realistic range. Consumer and smart-home applications represent under 8% of global FPGA revenue for this exact reason. The economics do not work.
| Metric | ESP32-C6 / STM32 MCU | Lattice iCE40-class FPGA |
|---|---|---|
| Standby power | 15-68 μW | 75 μW+ |
| Silicon cost (10k vol) | $1-5 | $5-40 |
| NRE | $5K-20K | $50K-200K |
| Native Matter/Thread | Yes (radio + stack) | No (custom HDL required) |
| Firmware update path | OTA standard | Bitstream + verification |
Interrupt Latency and Why It Rarely Matters
The one place FPGAs genuinely win is deterministic sub-microsecond latency for fixed functions. An FPGA can service an event in tens of nanoseconds because the logic is gates, not instructions. An MCU with FreeRTOS hits roughly 3 μs worst-case interrupt latency with typical 2-5 μs context switches. That is a real ordering-of-magnitude gap.
It just does not matter for home automation. A Zigbee mesh hop adds 10-30 ms of latency. A Thread routing decision adds similar. A Wi-Fi command traveling from a phone to a hub and out to a device is lucky to complete in 50 ms on a clean network. The millisecond range is the domain of user-perceived responsiveness. Microseconds do not change the experience.
The workloads where sub-microsecond determinism earns its keep are motor control loops at 10 kHz+, industrial PID systems with fast sensors, and dedicated DSP pipelines running continuous signal processing. A smart home hub is none of those things.
Development Ecosystem
FreeRTOS runs on roughly 40% of embedded MCUs that use an RTOS. It is free, well-documented, and ships with vendor-supplied ports for every common chip. Zephyr gains traction under the Linux Foundation's stewardship and supports 450+ boards. Both let developers focus on application logic in C or Rust instead of timing closure in Verilog.
FPGA toolchains carry their own costs. Vivado and Quartus licenses price in the thousands annually for the capabilities needed for real protocol work. Timing closure across multiple clock domains takes weeks on novel designs. Debugging is slower because internal signals are harder to observe. You cannot just drop a printf statement in gates.
Firmware updates matter for any device that sits on the network for five years. MCU firmware ships as a binary, flashes in seconds, and rolls back cleanly through a bootloader. FPGA bitstream updates involve larger files and more complex validation steps. Secure boot for MCUs is a solved problem with reference implementations from every major vendor. Secure boot for FPGAs exists but requires more engineering.
Why Every Commercial Hub Picks the Same Architecture
Teardowns of the Amazon Echo, Google Nest Hub, Apple HomePod, and Samsung SmartThings hub all reveal ARM-based application processors or MCUs. No FPGA appears in the main control path. MediaTek, NXP i.MX, and Amlogic SoCs dominate the market. STMicroelectronics shipped over 5 billion STM32 MCUs cumulatively through 2024. RISC-V parts crossed 10 billion cumulative shipments in 2025.
ESP32-C6, Nordic nRF5340, and Silicon Labs MG24 all offer native Matter and Thread support with radios on-die. Development boards sell for $4-8. Matter-certified device count reached 2,800+ in early 2025 and continues to climb. The ecosystem economics favor MCUs to the point that the question "should we use an FPGA" is no longer asked by anyone shipping to consumer volume.
When an FPGA Still Makes Sense
The edge cases where FPGAs earn their place are real but narrow.
Early prototyping of novel radio protocols. If you are building hardware for a standard that does not yet have silicon support, an FPGA lets you implement the PHY before a chip exists. This matters to standards-track researchers and early implementers, not to product teams shipping consumer hubs.
Video pipelines with custom ISP logic. Some high-end security cameras use FPGAs as an ISP co-processor to handle specific sensor-to-encoder paths that off-the-shelf SoCs do not cover. ESP32-P4 absorbed much of this workload in 2024-2025 with hardware H.264 encoding and up to 25 GOPS of AI acceleration at $4-6 per chip. Dedicated SoCs keep eating FPGA territory here.
Industrial or automotive signal processing where deterministic timing under sub-microsecond windows is a hard requirement. Smart home hubs live outside this domain.
High-bandwidth Layer 2 switching or packet inspection at multi-gigabit rates. Enterprise network gear uses FPGAs. Home hubs do not.
The Practical Recommendation
Use an ESP32-C6 or equivalent 32-bit MCU with native Matter support for any new hub project. Prototype on an $8 development board with FreeRTOS or Zephyr. Spend engineering effort on reliable OTA firmware updates, proper interrupt priorities, and mesh commissioning flows rather than on reconfigurable logic.
The microcontroller won the hub market years ago on energy, cost, and time-to-market. New protocol standards, native Thread radios at $3, and hardware accelerators for the parts that used to justify custom logic have only widened the gap. Build accordingly.
Related: From Microcontrollers to Smart Thermostats: The Tech Inside Your HVAC | Raspberry Pi Home Automation: A Practical Setup Guide
