FPGAs in IoT and Embedded Systems: Use Cases, Architecture Patterns, and the 2026 Landscape

Choosing the Right Architecture for Edge Devices with Limited Resources

 

FPGAs occupy a specific and defensible position in the embedded systems design space — one that general-purpose processors and fixed-function ASICs cannot fully displace. Where MCUs and SoCs execute sequential instructions and are constrained by the interfaces and peripherals their silicon designers anticipated, FPGAs implement logic in hardware fabric that the product engineer defines. This means FPGAs can implement protocols that don't exist in standard silicon, execute control loops with deterministic sub-microsecond timing, process data across multiple parallel channels simultaneously, and be reconfigured in the field as requirements evolve.

The global FPGA market reached $8.9 billion in 2026 and is projected to grow at 7.6% CAGR to $18.5 billion by 2036. Growth is driven by edge AI, 5G infrastructure, industrial automation, and automotive ADAS — precisely the domains where FPGAs deliver capabilities that alternative silicon cannot match. Low-end FPGAs are the fastest-growing segment, reflecting adoption in cost-sensitive embedded and IoT applications where FPGA's interface flexibility and determinism justify the premium over MCU-class silicon.

This article covers the specific use cases where FPGAs deliver genuine advantage in IoT and embedded applications, the architecture patterns that combine FPGAs with other silicon, the current state of FPGA AI toolchains, and the practical design considerations for production deployment.

When FPGAs Are the Right Choice

The decision to use an FPGA in an IoT or embedded design is not primarily a performance decision — modern SoCs with NPUs deliver substantial AI inference throughput at lower cost. It is a requirements decision driven by the specific capabilities that FPGA hardware fabric provides and that software execution on sequential processors cannot replicate.

FPGA is the correct choice when any of the following conditions apply:

Hard real-time deadlines under 10 microseconds. Software execution on any operating system — Linux, RTOS, or bare-metal MCU — is subject to interrupt latency, pipeline stalls, and exception handling overhead that prevent deterministic sub-10µs response times. FPGA logic responding to an interrupt or sensor event does so in hardware clock cycles, with timing that is independent of software stack behavior. Motor control loops, industrial safety shutdowns, and high-frequency data acquisition applications with tight timing constraints require FPGA execution.

Custom sensor interfaces or proprietary protocols with no standard silicon support. Industrial environments use hundreds of distinct sensor interfaces, fieldbus protocols, and legacy communication standards. EtherCAT, Modbus RTU, PROFIBUS, and proprietary high-speed parallel sensor buses may not be available as peripheral IP in any standard SoC. FPGA fabric implements any digital interface the protocol specification defines, with timing controlled at the hardware level.

Massive signal processing parallelism. Processing data from hundreds of input channels simultaneously — ADC samples across multiple sensors, multi-channel audio, or high-speed vision data — exceeds what sequential CPU execution can accomplish at the required throughput. FPGA implements parallel processing elements that execute simultaneously across all channels.

Post-deployment hardware reconfigurability. Products with long field lifespans, where hardware requirements may evolve after deployment, can receive OTA bitstream updates that change the FPGA's implemented logic. This is functionally equivalent to a hardware revision without a board change, providing a level of field adaptability that fixed-silicon products cannot offer.

Core IoT Use Cases for FPGAs

Industrial Control and Motor Drive

Industrial IoT applications with precise motion control — servo drives, CNC controllers, robotic actuators — require control loop execution at rates between 10kHz and 100kHz with deterministic timing. At 100kHz, the control loop must complete within 10µs. An RTOS running on a 400MHz Cortex-A processor can achieve this in theory, but interrupt latency from Linux or even RTOS scheduling can cause jitter that translates to position or velocity error in the controlled system.

FPGA-implemented control loops execute in fixed hardware latency — typically a handful of clock cycles at the FPGA's operating frequency — with zero jitter from software scheduling. The control law (PID, FOC, or custom algorithm) is implemented as combinational or pipelined logic that receives sensor inputs and produces actuator outputs within a fixed, deterministic cycle.

FPGAs natively support industrial communication protocols required for factory connectivity: Time-Sensitive Networking (TSN) for deterministic Ethernet-based control, EtherCAT for servo drives, and PROFINET for Siemens-ecosystem integration. These protocols require precise timing implementation that FPGA hardware provides. Standard SoC peripherals do not implement TSN's time-aware shaper or EtherCAT's distributed clock mechanism with the precision that industrial networks require.

Edge AI Acceleration

FPGAs are increasingly used as AI accelerators in edge deployments where GPU-class solutions are too power-hungry or too expensive, but pure CPU inference is too slow. FPGA fabric implements neural network inference as pipelined hardware — matrix multiplication, activation functions, and pooling operations execute in parallel across the fabric rather than sequentially in a processor.

AMD's Xilinx Kria K26 SoM, combining Zynq UltraScale+ ARM processor cores with programmable FPGA fabric, represents the production deployment pattern for FPGA-based edge AI. AMD provides pre-built vision AI applications through the Kria Vision AI Starter Kit — object detection, classification, and tracking — that run on the FPGA fabric with the ARM processors handling the application logic. Vitis AI provides the toolchain for deploying custom PyTorch or TensorFlow models to the FPGA fabric through quantization and hardware-aware compilation.

Altera, now independent from Intel following the Silver Lake acquisition in September 2025, is expanding its FPGA focus beyond data centers toward edge AI applications. The Agilex series targets high-performance edge applications with tensor block architecture designed specifically for neural network workloads. Altera's FPGA AI toolchain accepts TensorFlow, Caffe, and PyTorch model inputs, reducing the RTL expertise required to deploy AI models to FPGA fabric.

The FPGA AI accelerator advantage over GPU solutions at the edge is power efficiency: FPGAs implementing specific inference workloads can deliver comparable throughput to GPU-class devices at significantly lower power, because unused logic blocks can be powered down and the implemented architecture matches the specific model topology without the overhead of a general-purpose GPU's fixed architecture.

Protocol Bridging and Multi-Protocol Gateways

IoT gateways connecting heterogeneous field devices, sensors, and industrial equipment to IP-based networks frequently require protocol conversion between incompatible physical and logical interfaces. A gateway connecting legacy Modbus RS-485 sensors, CAN FD devices, a PROFIBUS field network, and a TSN Ethernet backbone must implement four distinct protocol stacks, each with different timing requirements and electrical interfaces.

FPGA fabric implements all of these protocol stacks simultaneously, with each protocol running in dedicated hardware logic at the required timing precision. Where an MCU-based gateway must time-multiplex a single processor across multiple protocol handlers — introducing latency and reducing determinism — the FPGA handles all channels concurrently. The SoC co-processor on a hybrid platform manages the application logic (protocol translation, data routing, device management) while the FPGA handles the real-time protocol handling that the SoC cannot execute with sufficient determinism.

High-Speed Vision and Video Processing

Industrial machine vision applications — quality inspection, dimensional measurement, barcode reading — require processing high-resolution image data at line-rate speeds. An FPGA receiving image data from a 10GigE camera can process each pixel through a vision pipeline — Bayer demosaicing, geometric correction, feature extraction — before the pixel leaves the line buffer, achieving true streaming processing at camera speed.

The AMD Spartan UltraScale+ FPGA family, launched in March 2024 and targeting cost-optimized I/O-intensive edge applications, offers up to 30% lower total power than the previous generation with high I/O count for camera and sensor interfaces. This positions Spartan UltraScale+ as the appropriate FPGA tier for industrial vision applications that require a cost-optimized FPGA rather than the higher-cost Zynq or Virtex families.

Secure Cryptographic Offload

IoT devices handling sensitive data — industrial controllers on secure networks, medical devices storing patient data, connected vehicles with privacy-sensitive payloads — require cryptographic operations that must not be performed in software where they are vulnerable to timing side-channel attacks. FPGA-implemented cryptographic accelerators execute AES, SHA-3, and ECC in hardware with constant-time behavior that eliminates the timing side channels that software implementations expose. Physical Unclonable Functions (PUFs) implemented in FPGA fabric provide device-unique cryptographic identities derived from manufacturing process variation — a hardware root of trust that is intrinsic to the device rather than stored in programmable memory.

FPGA Architecture Patterns in IoT Products

Standalone FPGA

A standalone FPGA serves as the primary system controller when the application is fundamentally a hardware problem: a single-function industrial sensor with a proprietary output interface, a protocol bridge with no application-level processing, or a cryptographic accelerator with a fixed function. Standalone FPGAs are typically low-end or mid-range devices (Lattice iCE40, AMD Artix, Efinix Trion) chosen for power efficiency and small form factor. Efinix's Trion family targets edge IoT and sensor applications directly; the larger Titanium family targets edge servers and co-processor architectures.

SoC + FPGA (Discrete)

The most common FPGA pattern in IoT products uses a separate FPGA alongside an application processor SoC. The SoC runs Linux or RTOS for application logic, networking, and user interface. The FPGA handles real-time interfaces, custom protocols, and signal processing that the SoC cannot execute with sufficient determinism. Communication between the two typically uses PCIe, AXI, or high-speed SPI, with the SoC acting as the master and the FPGA as a coprocessor. This architecture is straightforward to implement and allows independent development of the software stack (SoC side) and hardware logic (FPGA side).

SoC FPGA (Integrated: AMD Zynq / Intel Cyclone SoC)

AMD Zynq UltraScale+ MPSoC and Intel/Altera Cyclone SoC integrate ARM application processor cores alongside FPGA fabric on a single device. The ARM cores communicate with the FPGA fabric through high-bandwidth AXI interconnect within the same chip, eliminating the PCIe or SPI communication overhead of discrete implementations. This architecture is well-suited for applications where the boundary between software and hardware is dynamic — where different partitioning of functionality between processors and FPGA fabric may be explored during development, or where tight coupling between real-time hardware and application software is required.

Embedded FPGA (eFPGA) in Custom SoCs

Embedded FPGA IP cores integrated into custom SoCs allow the programmable logic fabric to be incorporated directly into a domain-specific chip. This approach is growing in IoT chipsets where the product volume justifies custom silicon but the interface flexibility and post-production reconfigurability of FPGA fabric adds value. SRAM-based eFPGA holds 32.2% of the embedded FPGA market segment due to its flexibility and ease of repeated configuration changes.

 

FPGAs in IoT


FPGA architecture comparison

Architecture

Development complexity

BOM impact

Best for

Standalone low-end FPGA

Medium

$2–8 added

Single-function I/O intensive designs

SoC + discrete FPGA

High

$8–20 added

Multi-protocol gateways, vision systems

Zynq/SoC FPGA

High

Similar to SoC

Tight hardware-software coupling

eFPGA in custom SoC

Very high

Amortized in SoC

High-volume domain-specific products

FPGA AI Toolchains — Closing the Expertise Gap

The historical barrier to FPGA adoption has been the expertise requirement: FPGA design requires RTL programming in VHDL or Verilog, a discipline distinct from both embedded software development and machine learning engineering. In 2026, FPGA vendors are actively closing this gap through AI-aware toolchains that accept standard ML frameworks as input.

AMD Vitis AI accepts PyTorch and TensorFlow models and compiles them for deployment on Xilinx/AMD FPGA fabric and Zynq platforms. The toolchain handles quantization, architecture mapping to FPGA DSP blocks and BRAM, and performance optimization. AMD provides pre-validated model zoo entries for common vision architectures that deploy directly to Kria hardware.

Altera's FPGA AI toolchain for the Agilex series accepts TensorFlow, Caffe, and PyTorch model inputs, abstracting the RTL layer from ML engineers. Altera states the Agilex tensor block architecture achieves twice the clock rate of competitors, enabling the same neural network to run in half the logic area — reducing cost and static power consumption.

Efinix's Efinity IDE includes RISC-V SoC integration, enabling the combination of programmable logic with a soft RISC-V processor core without external SoC silicon. This architecture is relevant for IoT products requiring both programmable interfaces and a software-programmable controller on a single low-power FPGA device.

The practical implication for IoT product teams is that FPGA AI deployment no longer requires RTL engineering expertise for standard model architectures. Teams proficient in PyTorch model development can deploy to FPGA hardware using vendor toolchains without writing HDL. The expertise barrier remains for custom protocol implementation and non-standard hardware interfaces, which continue to require RTL engineering skills.

Design Considerations for FPGA-Based IoT Products

Power budget for FPGA logic: FPGA static power — the power consumed regardless of logic activity — is the primary power consideration for IoT applications with low duty cycles. Lattice iCE40 Ultra series targets sub-100µW static power for always-on IoT applications. Mid-range FPGAs may draw tens of milliwatts of static power, which is incompatible with multi-year battery operation. The correct FPGA tier selection accounts for static power against the operating duty cycle.

Bitstream security: FPGA configuration files (bitstreams) contain the full hardware design and represent significant intellectual property. SRAM-based FPGAs lose configuration on power-down and reload from external flash on startup — this boot process is a point of attack if the bitstream is unencrypted. All major FPGA families support encrypted bitstreams using AES-256. Production designs should always use encrypted bitstreams to prevent design extraction through flash readout.

OTA bitstream updates: FPGA-based IoT products that require field updates must implement both bitstream loading infrastructure (loading a new bitstream into configuration flash without physical access) and safe fallback (returning to the known-good configuration if the new bitstream fails to load or produces errors). This is analogous to dual-bank firmware updates in MCU products.

Security certification: Products subject to EU Cyber Resilience Act enforcement from 2027 must document their hardware security architecture. FPGA-based designs must cover bitstream encryption, secure boot implementation, and any cryptographic accelerators in the documented security architecture. PUF-based device authentication should be incorporated at design time if device-unique identity is required.

Tool and license management: AMD Vivado and Intel/Altera Quartus require licenses for synthesis and implementation of non-trivial designs. License cost and management is a practical consideration for development teams that are not FPGA-specialist organizations. Lattice Semiconductor's Lattice Radiant and Efinix's Efinity toolchains use perpetual or lower-cost license models that reduce the tooling barrier for teams with occasional FPGA development needs.

Quick Overview

Key Applications: industrial motor control and servo drives with hard real-time loops, protocol bridges for multi-fieldbus IoT gateways, FPGA-accelerated edge AI for smart cameras and industrial vision, high-speed data acquisition and signal processing, post-deployment reconfigurable IoT hardware for long-lifecycle products

Benefits: sub-microsecond hardware timing determinism unavailable from any software execution platform; implementation of any digital interface without external silicon; parallel processing across all data channels simultaneously; post-deployment hardware reconfigurability through OTA bitstream updates; AI toolchains (Vitis AI, Altera AI) enabling PyTorch/TensorFlow model deployment without RTL expertise

Challenges: BOM cost premium of $8–20 over equivalent SoC for most applications; RTL expertise still required for custom protocols and non-standard architectures; FPGA static power incompatible with multi-year battery operation in most mid-range families; bitstream security requires AES encryption implementation; tooling and license management overhead for non-FPGA-specialist teams

Outlook: global FPGA market growing at 15.2% CAGR to $41.6 billion by 2033; Altera independent from Intel and expanding edge AI focus with Agilex tensor block architecture; eFPGA integration into custom IoT SoCs growing; AMD Spartan UltraScale+ lowering cost of I/O-intensive edge FPGA designs; EU Cyber Resilience Act 2027 requiring bitstream security documentation for connected products

Related Terms: FPGA, eFPGA, HDL, VHDL, Verilog, RTL, Xilinx Kria, AMD Zynq UltraScale+, Altera Agilex, Lattice iCE40, Efinix Trion, AMD Spartan UltraScale+, Vitis AI, TSN, EtherCAT, PROFIBUS, Modbus, PUF, bitstream encryption, SoC FPGA, RISC-V soft processor, industrial IoT, edge AI accelerator, deterministic latency, parallel processing

 

Contact us

 

 

Our Case Studies

 

FAQ

When should I use an FPGA instead of an MCU or SoC for an IoT device?

 

Use an FPGA when the application has requirements that software execution cannot meet: hard real-time deadlines under 10 microseconds, custom sensor interfaces or proprietary protocols not available in standard silicon, parallel processing of many data channels simultaneously, or post-deployment hardware reconfigurability requirements. For applications that do not have these requirements, MCU or SoC is almost always a better choice, with lower BOM cost, a simpler development toolchain, and a broader firmware ecosystem. The key diagnostic question is whether the core challenge is a hardware parallelism or determinism problem, or a software complexity or AI inference problem. Hardware problems favor FPGA, while software and AI problems favor SoC.
 

What are embedded FPGAs (eFPGAs) and when are they relevant for IoT?

 

An embedded FPGA integrates programmable logic fabric IP directly into a custom SoC design, rather than using a discrete FPGA chip. This approach allows a purpose-built IoT chip to include reconfigurable logic alongside fixed-function CPU, DSP, and connectivity blocks. eFPGA is relevant when product volume justifies custom silicon development, and the product requires post-production flexibility that a fixed-function ASIC cannot provide, for example, an industrial IoT chip that must support multiple proprietary sensor protocols across different customer configurations, implemented as different FPGA bitstreams on the same hardware. SRAM-based eFPGA has 32.2% of the embedded FPGA market segment, reflecting its widespread use in products where repeated in-field reconfiguration is a value proposition.
 

How do FPGA AI toolchains work and how much RTL expertise is required?

 

FPGA AI toolchains accept trained models from standard ML frameworks, such as PyTorch and TensorFlow, apply quantization to INT8 precision, and compile the quantized model to FPGA hardware description. AMD Vitis AI, Altera's AI toolchain, and Lattice sensAI all provide this path. The toolchain automates mapping of neural network operations, including convolutions, matrix multiplications, and activations, to the FPGA's DSP blocks and distributed RAM. For standard architectures, such as CNNs and object detectors based on YOLO variants, RTL expertise is not required because the toolchain handles the hardware implementation. RTL expertise is still required for custom pre- or postprocessing logic, unusual model architectures not supported by the toolchain, and custom hardware interfaces. Teams combining ML and RTL expertise can implement fully custom AI inference pipelines, while teams with only ML expertise can use vendor-provided IP cores for standard architectures.
 

What FPGA families are appropriate for low-power IoT edge devices?

 

Low-end FPGAs targeting power-sensitive IoT applications include Lattice iCE40 Ultra with sub-100µW standby power and a 5 mm × 5 mm form factor, Efinix Trion family devices targeting IoT, sensor, and machine vision with competitive power and cost, AMD Spartan UltraScale+ for I/O-intensive edge applications with lower power than the previous generation, and Microchip PolarFire family devices emphasizing low static power and security features. The correct selection depends on the required logic capacity, including LUTs and DSP blocks, I/O count and interface requirements, static power budget, and development toolchain preference. Mid-range and high-end FPGAs, such as Xilinx Zynq and Altera Agilex, provide significantly more capability but draw more static power and cost more. They are appropriate for edge appliances and gateways where the power budget allows, but not for battery-powered IoT nodes.