STM32N6: Neural ART Accelerator on STM32
Deep dive into STM32N6's Neural ART NPU: architecture, toolchain flow, and a worked MobileNet-v2 throughput estimate for embedded vision.
Contents & prerequisites
Running a MobileNet-v2 or YOLO-Nano model on a typical Cortex-M7 at 400 MHz means squeezing every MAC through CMSIS-NN kernels on a scalar/SIMD core — a few hundred MFLOPS to a couple of GOPS if you're lucky with DSP extensions on that class of core. That ceiling has been the real barrier to on-device vision at useful frame rates. STM32N6 breaks it by adding a dedicated NPU — "Neural ART" — that ST rates at up to 600 GOPS (int8). By comparison, the STM32N6's own Cortex-M55 running CMSIS-NN/Helium kernels tops out on the order of a few GOPS for int8 conv workloads, so offloading to Neural ART is roughly two orders of magnitude faster than staying on that same chip's CPU. Understanding how the accelerator is architected, how a model gets mapped onto it, and where its real limits sit is the difference between hitting 30 fps person detection and finding your 1.2M-parameter model swapping in and out of a 4.2 MB SRAM budget.
Silicon Overview
STM32N6 pairs a Cortex-M55 (Armv8.1-M with Helium/MVE) running up to ~800 MHz with Neural ART, a separate hardwired NPU block, plus a 2D GPU (GPU2D/Chrom-ART successor) and camera/display interfaces (MIPI CSI-2, DCMIPP, DSI). The M55 handles control flow, RTOS, sensor fusion and any custom pre/post-processing; Neural ART handles the bulk tensor math of the network itself. This split matters: the M55 is not the bottleneck for inference throughput once a graph is fully mapped to the NPU — it's the DMA/memory subsystem feeding the accelerator that usually is.
Key resources on-chip:
| Resource | Typical figure | Role |
|---|---|---|
| Neural ART NPU | up to 600 GOPS @ int8 | convolution/FC/pooling engine |
| Cortex-M55 | up to ~800 MHz, Helium | control, pre/post-proc, fallback ops |
| Internal AXI SRAM | ~4.2 MB | weights/activations, tightly coupled |
| External memory | HyperRAM/OctoSPI PSRAM/flash | model overflow, frame buffers |
| Camera/display | MIPI CSI-2, DCMIPP, DSI | sensor ingest, output |
Neural ART Architecture
Neural ART is built around a systolic-style MAC array plus dedicated units for the operations that dominate CNN/DS-CNN workloads:
- Convolution engine — a grid of int8 (and some int16) MAC units performing multiply-accumulate for standard, depthwise, and pointwise convolutions in a streaming fashion, avoiding full im2col expansion in SRAM.
- Activation/pooling unit — ReLU/ReLU6, and average/max pooling fused inline after accumulation, so intermediate tensors don't round-trip to memory just for a nonlinearity.
- DMA-driven weight/activation streaming — the accelerator has its own DMA paths into the internal SRAM and external memory so that while one layer's output is being written, the next layer's weights can be prefetched. This is what keeps utilization above the "load-stall" cliff that plagues NPUs fed only by a shared system bus.
- Op-level scheduler — a small hardware/firmware scheduler that walks a precompiled graph description (produced offline) and issues layer configurations without CPU intervention per-layer; the M55 only kicks off the graph and gets an interrupt/completion flag.
This is architecturally similar in spirit to Arm's Ethos-U (also int8 MAC arrays with a microcode-driven command stream), but Neural ART is ST's own design, tuned specifically for the STM32N6's memory hierarchy and integrated directly with the ST Edge AI toolchain rather than being a licensed Arm block.
Compute Budget: A Worked Estimate
Take a MobileNet-v2 (α=0.5, 96×96 input) style model: roughly 45M MACs per inference (a realistic figure for this width/resolution combination used in many embedded person-detection deployments).
MACs per inference ≈ 45 × 10⁶
Neural ART peak (int8) ≈ 600 GOPS (1 MAC ≈ 2 OPS → 300 GMAC/s)
Ideal inference time = 45e6 / 300e9 ≈ 150 µs
Real utilization on depthwise-heavy networks rarely exceeds 30–50% of peak because depthwise convolutions have low arithmetic intensity (few MACs per weight/activation byte moved) and stall the MAC array waiting on memory. Applying a conservative 35% utilization:
Effective throughput ≈ 300 GMAC/s × 0.35 ≈ 105 GMAC/s
Realistic inference time ≈ 45e6 / 105e9 ≈ 430 µs → ~2300 fps ceiling
Even at this derated figure, the NPU has enormous headroom over the ~30 fps most camera pipelines need — the actual system frame rate will be capped by DCMIPP ingest, resize/crop preprocessing, and CSI-2 bandwidth, not by Neural ART's raw compute. That's a genuinely different bottleneck profile than a CMSIS-NN-on-M7 design, where the CPU convolution loop is the bottleneck.
Check: 45M MACs at a naive Cortex-M55/Helium software rate of, say, 1.5 GMAC/s would take ~30 ms — a 70× gap versus the derated NPU figure of 430 µs. That's lower than the ~100× headline uplift ST advertises; the discrepancy is expected, since the derated 430 µs figure already assumes only 35% NPU utilization, while the ~100× marketing number compares peak NPU throughput against a lighter-loaded CPU baseline. Against the ideal 150 µs NPU figure the gap widens to ~200×, so 70–200× is the realistic envelope depending on both sides' assumed utilization, and ~100× is a reasonable midpoint rather than a precise, reproducible ratio.
Toolchain: Model to Neural ART Binary
- Train in TensorFlow/Keras or PyTorch as normal (fp32).
- Quantize to int8 — post-training quantization or QAT, same principles as any other int8 MCU deployment. Neural ART is int8-native; fp32 layers fall back to the M55.
- ST Edge AI Core / ST Edge AI Developer Cloud compiles the quantized ONNX/TFLite graph into a Neural ART-mapped binary: it partitions ops that Neural ART supports (conv, depthwise conv, FC, pooling, common activations) from ops it doesn't (custom layers, some reshape/transpose patterns), assigning the latter to the M55.
- Memory placement — the compiler decides which tensors live in internal SRAM vs. external PSRAM/flash based on the ~4.2 MB budget; oversized models spill to external memory with a latency penalty on every access that crosses the bus.
- Deploy — the resulting artifact is linked into the firmware image; at runtime the M55 issues a single call to trigger the precompiled graph on Neural ART and waits on completion (interrupt or polling), then continues with post-processing (NMS for object detection, softmax, etc.) on the CPU.
This "compile the whole graph once, offline" model is the key practical difference from CMSIS-NN, where you're calling per-layer kernel functions from your own C code — Neural ART is closer to a fixed-function accelerator than a programmable kernel library, which is faster but means graph changes require a recompile through ST's toolchain rather than editing kernel calls.
Design Implications
- Partitioning awareness matters. An architecture with unsupported ops (unusual activation functions, certain custom preprocessing fused into the graph) will silently fall back those layers to the M55, which can dominate latency even if 95% of MACs run on the NPU — profile per-layer, not just aggregate MAC count.
- Depthwise-heavy models underutilize the array. If your target is Neural ART, favor architectures with a healthy mix of standard/pointwise convolutions (or explicitly benchmark on ST's Developer Cloud) rather than assuming any MobileNet variant maps equally well.
- Memory budget drives model choice as much as compute does. A model that fits entirely in the ~4.2 MB internal SRAM avoids external-memory latency; check compiled model + activation footprint against this before committing to input resolution or channel width.
- Pipeline bottleneck shifts upstream. With NPU compute no longer the constraint, camera ingest (DCMIPP/CSI-2), resize/crop, and color conversion become the frame-rate-limiting stages — budget them explicitly rather than assuming "NPU is fast, so we're fine."
- Power envelope. Neural ART's efficiency (reported in the few-TOPS/W range for int8) is what makes always-on vision at battery-relevant power feasible — but only if the M55 and peripherals are also duty-cycled; leaving the CPU spinning between NPU calls erodes the advantage.
Key Takeaways
- STM32N6 adds Neural ART, a dedicated int8 NPU (~600 GOPS peak) alongside a Cortex-M55, shifting CNN inference bottlenecks from CPU compute to memory/pipeline bandwidth.
- The accelerator streams weights/activations via its own DMA and fuses activation/pooling inline, keeping utilization high on standard convolutions but lower (~30–50%) on depthwise-heavy layers.
- Deployment is a compile-once workflow through ST Edge AI Core: quantize to int8, compile the graph to a Neural ART binary, and let unsupported ops fall back to the M55.
- A worked MobileNet-v2-class estimate (45M MACs) shows ~150 µs ideal / ~430 µs realistic inference time — far below camera pipeline frame budgets, meaning DCMIPP/CSI-2 ingest and preprocessing, not the NPU, set the achievable frame rate.
- Model architecture choices (depthwise ratio, input resolution, memory footprint vs. the ~4.2 MB internal SRAM) matter more for realized performance on Neural ART than raw MAC count alone.
Learning
Sign in to track your progress.
Evidence
Public projects engineers linked to STM32N6: Neural ART Accelerator on STM32.
No engineer has linked a project to this topic yet. Built something that proves it? Add the project and tag it with embedded-systems-stm32n6-neural-art-accelerator-on-stm32 — it then shows here and on your public profile.
