What does “field programmable array” refer to?
The full term is Field Programmable Gate Array (FPGA). An FPGA implements configurable digital logic; an NPU accelerates supported neural-network operations. The choice depends on the actual signal path. FPGA signal processing can be useful for parallel interfaces or timing-sensitive acquisition, while an NPU may simplify a supported inference workload.
From an FPGA development board to a custom product
An FPGA board proves only part of the system. A custom design also needs power sequencing, clocking, memory interfaces, thermal design and a repeatable test method. Compare FPGA design effort and verification with an MPU or system-on-chip FPGA architecture. FPGA cost includes engineering, tools, board complexity and production test as well as the chip itself.
What is an AI MPU?
An AI-capable MPU platform combines an application microprocessor with the software and acceleration resources needed for a machine-learning workload. Start by identifying which tasks belong on the CPU and which benefit from a supported accelerator.
An MPU, or application microprocessor, is usually the software center of an embedded Linux system. An “AI MPU” is not a separate processor category so much as an MPU platform that includes, or works closely with, acceleration resources such as an NPU, GPU, DSP or FPGA. The MPU hosts Linux, networking, storage, security services, application logic and the runtime that coordinates AI workloads.
For MPU machine learning, the practical question is not only CPU speed. Memory bandwidth, accelerator support, camera and high-speed I/O, Linux BSP quality, long-term availability, thermal design and model-toolchain maturity often matter more than a headline TOPS value.
What makes an MPU a good artificial-intelligence platform?
The best MPU for artificial intelligence is workload-specific. A vision gateway may prioritize MIPI CSI, hardware video pipelines and an NPU. A rugged mission computer may need PCIe, multiple Ethernet ports, deterministic companion cores and stronger security features. An industrial platform may value long product life, TSN, CAN-FD and a stable Linux ecosystem.
Benchmark the actual model and complete preprocessing chain. A platform with a lower advertised accelerator figure can win if it avoids memory copies, supports the required operators and keeps the sensor-to-result path efficient.
NPU: efficient neural inference at the edge
An edge NPU accelerates neural-network operators such as convolutions, matrix operations and common activation functions. It is usually the most efficient place for supported detection, classification, segmentation and feature-extraction models when power and sustained inference throughput matter.
NPU performance depends on compilation and operator coverage. Unsupported layers may fall back to CPU or another accelerator. Quantization requirements, tensor layouts, input resolution and memory movement can also change real-world performance dramatically. Always benchmark the production graph rather than relying on theoretical TOPS alone.
FPGA: deterministic pipelines and AI inference where flexibility matters
An FPGA excels at deterministic data movement, custom interfaces and massively parallel pipelines. In edge systems it can deserialize sensors, align timestamps, filter data, generate regions of interest, perform image preprocessing and feed an accelerator with predictable latency. FPGA AI inference is also possible when a model maps well to the available DSP, memory and vendor acceleration stack.
The trade-off is engineering effort. RTL or HLS design, simulation, timing closure, verification and update strategy must be planned. An FPGA should be selected because deterministic behavior or custom parallelism creates system value—not simply because it can run arithmetic.
NPU vs FPGA for edge AI
The NPU vs FPGA decision is often a false binary. An NPU is generally the easier choice for supported neural networks and strong performance per watt. An FPGA is stronger when the system needs custom sensor interfaces, deterministic preprocessing, unusual data formats or a tightly controlled pipeline before and after inference.
A common architecture uses both: FPGA for sensor ingest and preprocessing, NPU for the neural network, and MPU for Linux orchestration. This reduces the amount of irregular work forced onto any one processor.
| Resource | Best-fit workloads | Main constraints |
|---|---|---|
| FPGA | Deterministic pipelines, custom I/O, timestamping, preprocessing, specialized acceleration | RTL/HLS effort, verification, device resources |
| NPU | Supported neural inference with good performance per watt | Operator support, compiler/runtime, quantization and memory movement |
| MPU | Linux applications, networking, storage, cybersecurity, orchestration | Less deterministic execution; general-purpose overhead |
| MCU / RT core | Control loops, safety supervision, power sequencing, deterministic I/O | Limited memory and high-level compute |
A practical way to partition an edge AI architecture
- Start with deadlines: identify which signals have hard timing requirements and the maximum sensor-to-action delay.
- Map data rates: calculate sensor throughput, intermediate tensor sizes and worst-case memory traffic.
- Keep deterministic ingest close to the interface: FPGA, DMA engines or real-time cores are often appropriate.
- Place supported neural models on the NPU: validate operator coverage and actual compiled performance.
- Use the MPU for the system: networking, storage, updates, logging, APIs and application policy belong naturally in Linux.
- Reserve real-time control: an MCU or deterministic core should supervise time-critical actuation and platform health where required.
Memory bandwidth is often the hidden bottleneck
Many edge AI designs focus on compute peaks and discover later that copies, color conversion, tensor reformatting or shared DDR dominate latency. Zero-copy or low-copy paths, DMA topology, cache behavior and accelerator memory access should be evaluated early. Thermal throttling can also turn a strong benchmark into weak sustained performance.
This is especially important when multiple cameras, radar, event sensors or high-speed Ethernet streams share the same memory subsystem.
Reference architecture examples
Vision / event-sensor pipeline
Sensor → FPGA ingest and timestamping → NPU inference → MPU decision services → CAN-FD or Ethernet output. This is a strong pattern for low-latency perception and connects directly to our .
Embedded AI computer
High-speed I/O → DMA / accelerator path → NPU or GPU inference → Linux application services → storage and network APIs. Our embedded compute module and rugged edge computer product classes are built around this type of partitioning.
Industrial deterministic gateway
CAN-FD / serial / Ethernet interfaces → FPGA or MCU timestamping and protocol handling → MPU services → optional NPU analytics. Here deterministic I/O and long-term software maintainability can be more important than maximum AI throughput.
How to choose between FPGA, NPU and MPU
Choose from the complete workload, not the processor label. If the dominant problem is neural inference, start from NPU compatibility. If custom I/O and deterministic preprocessing dominate, evaluate FPGA resources. If Linux services, networking and application software dominate, start with MPU capability. Most high-performance edge platforms will combine at least two of these resources.
Before committing hardware, run representative streams through the intended software stack and measure end-to-end latency, power, memory bandwidth and thermals. That evidence is more valuable than generic accelerator rankings.
Worked example: four cameras and a shared memory budget
Consider a planning example with four 1280 × 720 streams at 30 frames per second, represented as RGB with one byte per channel after image conversion. Their combined logical image payload is 4 × 1280 × 720 × 30 × 3 = 331,776,000 bytes per second, approximately 332 MB/s in decimal units. This is not the camera-link bitrate or measured performance of an ALVEXIS product.
One additional full-frame copy reads and writes that payload, adding approximately 664 MB/s of memory traffic before considering cache behaviour or other operations. Model tensors, colour conversion, logging and concurrent services add their own traffic. This explains why a design can be constrained by data movement even when its headline accelerator rating appears sufficient.
| Work to place | Starting point | Evidence before committing |
|---|---|---|
| Camera ingest and synchronisation | Supported SoC interfaces, with FPGA or a companion device where required | Simultaneous stream capture, timestamp behaviour and loss under load |
| Neural inference | NPU when the chosen graph and precision are supported | Conversion accuracy and sustained on-device application measurements |
| Linux services and recording | MPU resources and an explicitly budgeted storage path | CPU, memory and I/O behaviour while inference is active |
| Time-critical external control | A suitable real-time controller or validated deterministic implementation | Response-time evidence under the relevant worst-case workload |
The purpose of partitioning is to make each timing and resource requirement explicit. It does not imply that every design needs four different processors. Begin with the simplest architecture that meets the requirements, then add resources where measurements or interface constraints justify them.
A validation plan for choosing the processor mix
- Freeze the input contract: sensors, data formats, model, resolution and operating conditions.
- Verify model support and output quality before comparing accelerator throughput.
- Measure acquisition, preprocessing, inference and delivery separately, then measure the complete path.
- Repeat under sustained thermal load with recording, networking and all intended sensors active.
- Record queue age, lost inputs and tail latency, so a high average rate does not hide intermittent delays.
Keep the board revision, software image, toolchain versions and test inputs with the results. For a Rockchip implementation, the RK3588 model deployment guide develops this workflow. For event-camera data, use the software integration guide to define timestamps and representations before choosing the inference path.
After the workload is characterised, compare the SoM and SBC integration options. That decision connects the compute architecture to connectors, power, enclosure and production work.
From processor selection to a buildable product
A processor shortlist is only useful when it fits the complete product. Before ordering a custom board, turn the workload into a short engineering brief:
- Inputs: sensor count, interfaces, sample rates and synchronisation requirements.
- AI workload: the actual model, supported precision and acceptable output quality.
- Physical constraints: dimensions, power source, cooling and operating environment.
- Delivery: prototype quantity, production volume, software ownership and acceptance tests.
For an inspection station, connect the camera pipeline to the line trigger, part identifier and result interface. Our industrial machine vision and quality control solution explains how those requirements become a pilot.
MPU, NPU and FPGA edge AI FAQ
What is MPU AI?
MPU AI describes artificial-intelligence workloads deployed on an embedded microprocessor platform, usually with Linux and often with integrated or companion acceleration such as an NPU, GPU or FPGA. The MPU commonly manages applications, networking, storage, security and orchestration around the inference pipeline.
Can an MPU run machine learning?
Yes. MPU machine-learning workloads can run on CPU cores or use integrated accelerators. For production systems, model support, memory bandwidth, sustained thermals and end-to-end latency matter more than headline TOPS alone.
NPU vs FPGA: which is better for edge AI?
An NPU is usually the simpler choice for supported neural-network inference with strong performance per watt. An FPGA is preferable when custom sensor interfaces, deterministic preprocessing, unusual data formats or specialized pipelines are central to the design. Many systems use both.
Can you run an NPU workload on an FPGA?
An FPGA can implement neural-network accelerators or inference pipelines, but it is not automatically equivalent to a dedicated NPU. The trade involves programmable logic resources, memory, toolchain maturity, model support, verification effort and power.
When does FPGA AI inference make sense?
FPGA AI inference is attractive when inference must be tightly coupled to deterministic preprocessing, custom interfaces or specialized data movement. It is especially useful when a standard NPU runtime does not fit the sensor path or latency constraints.
Where TinyML fits within edge computing
Edge computing describes processing near the source of data; edge AI applies machine-learning inference there. TinyML addresses a more constrained class of deployment, often on microcontrollers with limited memory and power. A small vibration classifier and a multi-camera perception pipeline therefore need very different hardware budgets even though both can be edge AI.
For a microcontroller target, check model size, runtime memory, supported operators and acquisition overhead. For an NPU or FPGA-based design, also evaluate memory movement and the partition between accelerated and non-accelerated work. Choose the smallest architecture that satisfies the measured task and recovery requirements, rather than selecting a technology from its acronym alone.
Technical references
- Rockchip: RKNN software components and deployment tools
- Rockchip: model conversion and inference examples
- Gallego et al.: Event-based Vision — A Survey
- TensorFlow Lite Micro: inference on memory-constrained devices
The bandwidth example is an explicit calculation, not a product benchmark. Validate the selected architecture on the intended workload.
Partition your real edge AI workload.
Describe your sensors, AI model or algorithm, latency target and power limit. We can scope the compute architecture, custom electronics, embedded software and enclosure around your application. Use the project brief to share what you know; early requirements are welcome.