TinyEngine NPU: TI MSPM0G5187 and AM13Ex for Edge AI

For a decade, “AI on a microcontroller” meant squeezing a quantized network through a Cortex-M CPU and accepting whatever latency and battery drain came out. Texas Instruments is now betting that the answer for the cheap end of the market is not a faster CPU but a small, fixed-function accelerator sitting beside a very ordinary core. The TinyEngine NPU is that accelerator, and in March 2026 TI put it into a sub-dollar Cortex-M0+ part (the MSPM0G5187) and a 200 MHz Cortex-M33 motor-control family (the AM13Ex).

The interesting question is not whether 2.56 giga-operations per second sounds impressive. It does not, next to a 600 GOPS STM32N6. The interesting question is what class of problem becomes cheap enough to solve locally when the accelerator costs a few cents of die area, and what breaks when you try to use it for something bigger.

What this covers: what TI actually announced and what is verified versus vendor claim, how the NPU is organized and fed with data, the toolchain from training to firmware, a worked latency and energy model, a comparison with Arm Ethos-U55, NXP eIQ Neutron and ST Neural-ART parts, failure modes, and a practical decision checklist.

Context and Background

The microcontroller AI market split into two tiers between 2020 and 2025. The high tier adopted Arm’s Cortex-M55 or M85 with an Ethos-U55 microNPU: Arm describes the U55 as configurable from 32 to 256 multiply-accumulate (MAC) units, handling 8-bit and 16-bit integer data, with the M55/U55 pairing claimed at up to 480x uplift in ML performance over earlier Cortex-M processors (Arm developer blog). Renesas’ RA8P1, for example, pairs a 1 GHz Cortex-M85 with an Ethos-U55 quoted at 256 GOPS at 500 MHz (Renesas RA8P1). ST went its own way with the in-house Neural-ART accelerator in the STM32N6, quoted at 600 GOPS and 3 TOPS/W alongside an 800 MHz Cortex-M55 (ST blog). NXP’s MCX N line integrates the eIQ Neutron NPU and claims up to 42x faster inference than the CPU cores alone (NXP MCX N fact sheet).

The low tier, where most of the world’s microcontrollers actually live, was left to software. A Cortex-M0+ has no DSP extension, no SIMD, and no helium vector unit. Running even a small convolutional network there is possible, but every multiply-accumulate is several instructions, and the core stays awake while it grinds. That is the gap TI is addressing.

TI is not new to this. The TinyEngine NPU first appeared in the C2000 family: the TMS320F28P55x, launched in late 2024, targeted arc-fault detection and motor-bearing fault detection, and the EE Times coverage of the AM13E230x describes it as the third TI MCU family to gain the block (EE Times). TI’s own product overview lists the F28P55x, AM13E230x and MSPM0G5187 as the current TinyEngine families (TI TinyEngine overview, SPRT822). The March 10, 2026 announcement widened it from real-time control into general-purpose, ultra-low-power parts (TI press release).

If you are choosing a runtime rather than silicon, our comparison of ONNX, TFLite, ExecuTorch and CoreML covers the model-format side, and the RTOS question for these parts is treated in Zephyr vs FreeRTOS vs NuttX. This post concentrates on the silicon and toolchain.

What TI Announced: The Verified Facts

Separating datasheet facts from marketing claims matters here, because the headline numbers are all vendor-relative. The table below lists what TI’s datasheet and secondary sources agree on.

Attribute	MSPM0G5187	AM13E23019 (first AM13Ex part)
CPU	Arm Cortex-M0+ with MPU, up to 80 MHz	Arm Cortex-M33 with FPU, MPU, DSP, up to 200 MHz
Flash	Up to 128 KB, ECC, dual bank	Up to 512 KB (2 x 256 KB), ECC
SRAM	Up to 32 KB, ECC/parity	128 KB, ECC
NPU	TinyEngine, 2.56 GOPS at 80 MHz	TinyEngine (same 2.56 GOPS class reported)
ADC	One 12-bit 1.6 Msps, up to 26 channels	Three 12-bit SAR, up to 6.67 Msps each
Notable I/O	USB 2.0 FS, I2S/TDM, 12-channel DMA	CAN-FD, motor PWM, eCAP/eQEP
Temperature	-40 to 125 C	Not confirmed in sources reviewed
Price (1k units)	Under $1 (one source lists $0.97)	$2.45, preproduction
Status	In production	Preproduction; more variants by end of 2026

Sources: MSPM0G5187 datasheet, CNX Software, LinuxGizmos.

Two points deserve care. First, the 2.56 GOPS figure is a peak number quoted at the MSPM0G5187’s 80 MHz maximum clock; the AM13Ex runs its CPU at 200 MHz, and whether the NPU clock tracks the CPU clock is not stated in the material I could verify, so I do not claim a higher AM13Ex NPU throughput. Second, TI’s headline claims of “up to 90x lower latency and more than 120x lower energy per inference” are comparisons against software inference on MCUs without the accelerator. They are plausible for convolution-heavy models on a core with no SIMD, but they are best-case ratios, and TI publishes them without a full model-by-model table in the announcement.

Other verified details: the MSPM0G5187 lists 1.5 microamps in STANDBY and 88 nanoamps in SHUTDOWN with wake capability, and 103 microamps per MHz in RUN, with a 1.62 to 3.6 V supply. The LP-MSPM0G5187 LaunchPad is priced at $22, and the SDK supports FreeRTOS and Zephyr.

Anatomy of the TinyEngine NPU

The TinyEngine NPU is a fixed-function convolution engine that runs alongside the CPU and reads the same on-chip memory. It executes layers independently, so the CPU can sleep, sample sensors, or run control code while a network is evaluated. TI’s overview states it supports generic, depthwise, pointwise and transposed convolutions, fully connected layers, and average and max pooling with batch normalization, at 8-, 4- and 2-bit weight precision with mixed-precision configurations.

Direct answer for the snippet: the TinyEngine NPU is a small TI-designed neural accelerator integrated into MSPM0, AM13Ex and C2000 microcontrollers. It offloads quantized convolutional networks from the CPU at up to 2.56 GOPS, cutting latency and energy for tasks like arc-fault detection, motor-fault detection, keyword spotting and gesture recognition.

Figure 1: Where the TinyEngine NPU sits inside an MSPM0G5187 class device, with the CPU, DMA, ADC and shared SRAM.

The figure shows the data path that matters. Sensors feed the ADC or I2S peripheral, DMA writes samples into SRAM without waking the core, and the NPU reads inputs and weights from memory and writes activations back. The CPU’s job shrinks to orchestration and to the parts of the pipeline that are not neural, such as windowing, feature extraction and thresholds. The important architectural consequence is that the NPU shares memory with the CPU, so model size, activation buffers and application state all compete for the same 32 KB of SRAM on the MSPM0G5187.

What 2.56 GOPS means in practice

A useful sanity check is to convert throughput into operations per cycle. At 80 MHz, 2.56 GOPS is 32 operations per clock. Counting a MAC as two operations (one multiply, one add), that is 16 MACs per cycle. This is my arithmetic from the published peak, not a TI-disclosed microarchitecture detail, and the true structure (a 16-wide array, or a smaller array with sub-byte packing) is not public in the documents I reviewed.

Compare that with the Ethos-U55 numbers: 256 GOPS at 500 MHz is 512 operations per cycle, or 256 MACs per cycle, which matches Arm’s top 256-MAC configuration. The TinyEngine is therefore roughly sixteen times narrower per cycle than the largest U55 and about a hundred times lower in absolute peak, and that ratio is the whole design philosophy: it targets models measured in tens of kilobytes, not megabytes.

The low-bit modes are the second lever. With 2-bit and 4-bit weights, a model shrinks 2x to 4x against int8 in flash and memory bandwidth. On a part with 128 KB of flash, that is the difference between carrying one model and carrying several. It also means quantization-aware training is not optional; post-training quantization to 2-bit weights on an unmodified network generally destroys accuracy.

Why a shared-memory design suits the low end

Dedicated NPU SRAM, as used in larger parts, costs die area and adds a copy step. Sharing SRAM keeps the cost down, and for a 1D convolutional network over a sensor window the working set is small. A typical time-series classifier for arc-fault detection might take a window of a few hundred to a few thousand samples, apply a handful of small convolutions, and output a class. The peak activation tensor is the binding constraint, which the compiler must fit alongside the application’s own buffers.

The cost of the design shows up in two places: contention when DMA, CPU and NPU all touch SRAM, and the lack of headroom for image-scale models. A 96 by 96 grayscale frame alone is 9,216 bytes as int8, and the first feature-map expansion after a stride-1 convolution with 16 channels would be roughly 147 KB, far beyond 32 KB. The MSPM0G5187 is a sensor, audio and time-series part, not a camera part, and TI’s stated use cases (wake word, gesture, arc fault, motor fault) reflect that.

From Training to Firmware: The TI Edge AI Toolchain

A hardware accelerator is only as usable as its compiler. TI’s flow has three layers, and understanding them explains most of the practical constraints you will hit.

At the top is CCStudio Edge AI Studio, which TI describes as a free environment for model selection, training and deployment with more than 60 pre-built models and application examples, plus PyTorch and ONNX support (TI press release). Underneath it is the open-source TinyML Tensorlab on GitHub, whose ModelMaker package trains models, ModelOptimization handles post-training and quantization-aware quantization, and ModelZoo ships reference models. Its task list covers time-series classification and regression, forecasting, anomaly detection and image classification, and version 1.4.0 (June 2026) lists support for 40 MCU devices and adds agent skills for natural-language workflows (tinyml-tensorlab).

At the bottom is the TI Neural Network Compiler for MCUs, which produces an inference library (.h and .a files) that you link into a Code Composer Studio project. It offers two compilation targets: hardware-accelerated inference on the NPU, or software-only inference on the CPU. Its manual devotes sections to which layer patterns and configurations the NPU supports and to quantization-aware training in PyTorch (TI NN Compiler guide).

Figure 2: The TinyEngine NPU toolchain, from labelled sensor data to a linked inference library and on-device validation.

Figure 2 lays out the loop. The second half, compile and validate, is where projects stall, because the compiler either maps a layer pattern to the NPU or falls back to the CPU, and a single unsupported operator in the middle of a graph can split execution into slow and fast segments. The lesson from every NPU toolchain applies here: design the network for the accelerator’s supported patterns from the first epoch, rather than compiling a generic architecture and hoping.

Model design rules that follow from the hardware

From the supported-operator list and the memory limits, a handful of design rules are defensible without inventing compiler specifics. Prefer stacks of depthwise-separable convolutions, which use few weights and map onto the depthwise and pointwise support. Use small kernels and aggressive early down-sampling to keep the peak activation tensor low. Avoid recurrent layers, attention, and exotic activations unless the compiler guide confirms they are mapped; the published NPU op list names convolutions, fully connected and pooling only. Keep the classifier head small, and do feature extraction (FFT, mel filterbank, RMS windows) on the CPU or dedicated peripherals.

Because the operator list is convolution-centric, the sweet spot is one-dimensional signals treated as short images: vibration, current, voltage, audio spectrograms, IMU windows. That matches TI’s marketed examples, and it is also where tiny models reach production accuracy with modest data. It does not match small language models or transformers, which the TinyEngine does not target.

A worked latency and energy model (illustrative)

The following numbers are my own back-of-envelope model, not TI benchmarks, so treat them as a method rather than a measurement. Suppose an arc-fault classifier has 150,000 MACs per inference, run once per 10 ms window.

On the NPU at the 16 MACs per cycle implied by the peak rating, the ideal compute time is 150,000 / 16 = 9,375 cycles, or about 117 microseconds at 80 MHz. Real utilization on small layers is well under 100 percent because of memory reads, layer setup and pooling, so a planning figure of 30 to 50 percent utilization gives roughly 230 to 390 microseconds. The NPU is busy 2 to 4 percent of each 10 ms window.

On a Cortex-M0+ with no SIMD, an int8 MAC needs two loads, a sign extension, a multiply and an accumulate. A reasonable planning range is 8 to 15 cycles per MAC, so 1.2 to 2.25 million cycles, or 15 to 28 milliseconds at 80 MHz. That is more than the 10 ms window, so the software path cannot keep up at all. This is the mechanism behind TI’s 90x style claims: the ratio between a dozen cycles per MAC in software and a fraction of a cycle per MAC in hardware is in the tens, and the exact multiple depends on the model.

Energy follows time. At the datasheet’s 103 microamps per MHz, active current at 80 MHz is about 8.2 mA, and the NPU adds its own draw that TI has not broken out in the sources I reviewed. Even ignoring that, the software path holds the CPU in RUN for the whole 15 to 28 ms every window, which is a duty cycle above 100 percent and a battery killer. The NPU path keeps the system in the 1.5 microamp STANDBY state for roughly 95 percent of each window. Averaged, that is the mechanism behind a 100x energy claim: it comes mostly from letting the system sleep, not from the accelerator being magically efficient per MAC.

AM13Ex: When the NPU Sits Inside a Motor Controller

The AM13Ex line is a different product with the same accelerator. It is a real-time control MCU: a 200 MHz Cortex-M33 with FPU and DSP instructions, up to 512 KB of flash, 128 KB of SRAM, three 12-bit ADCs at up to 6.67 Msps, CAN-FD, motor PWM and quadrature encoder inputs. TI says it can run real-time control for up to four motors at once, cites a bill-of-materials reduction of up to 30 percent versus multi-chip solutions, and describes a trigonometric math accelerator that is 10x faster than CORDIC implementations (TI press release). These are vendor claims and depend on the baseline architecture being compared.

The pitch is that field-oriented control (FOC) loops keep running deterministically on the CPU and peripherals while the NPU watches for anomalies in the same current and voltage data: bearing wear, rotor faults, arc events. EE Times reports TI’s framing that fault detection latency can drop from around half a second to four milliseconds, enabling shutdown before a hazard develops (EE Times). Again, that is TI’s example, not an independent benchmark.

Figure 3: An AM13Ex style control architecture, where the deterministic FOC loop and the NPU anomaly path share sampled phase currents but not timing budget.

Why AI beside the control loop, not inside it

A neural network is a poor replacement for the inner current loop. FOC runs at 10 to 40 kHz with tight jitter budgets, wants provable worst-case timing, and is well served by a PI controller and a few trigonometric operations. The NPU’s value is in the slow path: classification over windows of hundreds of milliseconds, predictive maintenance signatures, and adaptive tuning of gains. Put another way, use the CPU for what has a closed-form solution and the NPU for what needs a learned decision boundary.

The design consequence is priority and isolation. The ADC-triggered control interrupt must always preempt, the NPU inference runs on a lower-rate schedule, and both read from the same sample buffers via DMA. If your safety case requires deterministic behavior, the NPU path should only ever raise a flag that a deterministic supervisor evaluates, never directly command a power stage.

Plan for the sourcing reality too. The AM13E23019 was listed as preproduction at $2.45 per 1,000 units when announced, with additional variants promised by the end of 2026. Preproduction silicon is not automotive or industrial qualification, and TI’s AM13Ex release does not, in the material reviewed, claim a functional-safety certification. If IEC 61508 or ISO 13849 evidence is in your scope, confirm with TI what is documented for the specific part number and revision.

How the TinyEngine NPU Compares With Ethos-U, Neutron and Neural-ART

Comparing NPUs by peak GOPS alone is misleading, because the real constraint at this end of the market is the whole system: memory, toolchain, price and power state. The right way to place the TinyEngine is by workload class.

Figure 4: A decision map for MCU with NPU selection by model size and workload, from sensor time series to vision.

The table uses only figures that vendors publish, and blank or approximate entries are marked as such.

Device class	CPU	Accelerator	Published peak	Best fit
TI MSPM0G5187	Cortex-M0+, 80 MHz	TinyEngine	2.56 GOPS at 80 MHz	Wake word, gesture, arc and motor fault, sub-dollar sensing
TI AM13E23019	Cortex-M33, 200 MHz	TinyEngine	2.56 GOPS class (reported)	Motor control with local fault detection
Renesas RA8P1	Cortex-M85, up to 1 GHz	Ethos-U55	256 GOPS at 500 MHz	Audio and vision on a high-end MCU
ST STM32N6	Cortex-M55, 800 MHz	Neural-ART	600 GOPS, 3 TOPS/W	Camera-based vision, up to 4.2 MB on-chip RAM
NXP MCX N94x	Dual Cortex-M33	eIQ Neutron	Up to 42x versus CPU alone (GOPS not stated in fact sheet)	Balanced secure IoT with moderate ML

Sources: TI datasheet, Renesas, ST, NXP.

What the numbers do and do not say

Dividing the peak figures shows the spread. The STM32N6’s 600 GOPS is about 234 times the TinyEngine’s 2.56 GOPS, and the RA8P1’s 256 GOPS is 100 times higher. Those are peak ratios, not price or power ratios: the MSPM0G5187 costs under a dollar, and the parts it is compared against are priced in a different class (I did not find verified list prices for them, so I make no per-dollar claim).

The comparison that matters is standby behavior. A 1 GHz Cortex-M85 part is engineered for performance in a system that can afford to be powered; the MSPM0G5187 is engineered around a 1.5 microamp STANDBY state and wake-on-event. A coin-cell wake-word device wants the second. A camera-based people counter wants the first. There is little overlap, which is why the honest recommendation is often not “which is best” but “which tier is your workload in”.

The Ethos-U ecosystem advantage

Arm’s ecosystem gives Ethos-U a strong argument that is not about silicon: models compile through common flows (Vela compiler, TFLite Micro, and increasingly ExecuTorch), and the same binary logic ports across Alif, Renesas, NXP and others. A TinyEngine model is tied to TI’s compiler and quantization flow, and a network trained for the TinyEngine’s 2-bit mixed precision will not be portable to an Ethos-U part without retraining. If your product roadmap involves multiple silicon vendors, that lock-in has a real cost. Our comparison of ONNX, TFLite, ExecuTorch and CoreML shows where the portable formats stop, and the same portability argument reappears higher up the stack in Jetson Thor vs Hailo-10H vs Coral and Hailo-10H vs Jetson Orin Nano, where the accelerator class is two orders of magnitude bigger again.

TI counters with breadth: the same TinyEngine and toolchain span C2000 real-time parts, the AM13Ex, and MSPM0, so a team that already builds on TI silicon can reuse data pipelines and models across product lines. That is a genuine engineering-cost argument, different from a raw benchmark argument.

A decision matrix by use case

Use case	Recommended tier	Why
Battery keyword or wake-word detection	MSPM0G5187 class	Sub-2 microamp standby, I2S/TDM input, small model
Arc-fault or motor-bearing anomaly detection	TinyEngine on AM13Ex or F28P55x	Shares ADC data with control loop, TI reference models exist
Gesture from an IMU or radar	MSPM0G5187 class	Small 1D or 2D features, low duty cycle
Person detection from a camera	STM32N6 or Ethos-U class	Frame buffers need megabytes and hundreds of GOPS
Multi-vendor product with portable models	Ethos-U based parts	Common compiler and model formats
Small language model or transformer	Not an MCU NPU workload	Move up to a Jetson or Hailo class accelerator

Trade-offs, Gotchas, and What Goes Wrong

The failure modes with this class of part are consistent, and most are about scope rather than defects.

Memory is the first wall. 32 KB of SRAM is shared by your stack, RTOS, sensor buffers, feature-extraction scratch space and the network’s activations. A model that fits in flash may still fail at runtime because the peak activation tensor does not fit. Budget SRAM explicitly and inspect the compiler’s memory report before you write application code.

Unsupported operators silently reduce the win. When the compiler cannot map a layer pattern to the NPU, it falls back to CPU execution. The 90x figure applies to layers on the accelerator; a network that spends half its MACs on the CPU is bounded by Amdahl’s law. Verify the fraction of MACs on the NPU and measure end-to-end latency on hardware.

Low-bit quantization needs quantization-aware training. Pushing weights to 4-bit or 2-bit saves memory and bandwidth but degrades accuracy on small models, which have little redundancy to absorb error. Budget training time for QAT, and hold out data from different machines, sensors, temperatures and operators to confirm the model generalizes. Arc-fault detection in particular has a safety cost when it misses and a nuisance-trip cost when it false-alarms.

Vendor-relative claims are not a benchmark. TI’s 90x and 120x figures compare against unaccelerated MCUs. They say nothing about how the part performs against an Ethos-U55 microNPU, and no independent MLPerf Tiny submission for the MSPM0G5187 or AM13Ex was found in my search. Run your model, on your board, with your power monitor.

Preproduction is not production. The AM13E23019 is preproduction. Errata, SDK maturity, safety documentation and long-term availability all lag production parts. The MSPM0G5187 is in production and inexpensive, which makes it the lower-risk entry point.

Lock-in and skills. TinyEngine models compile through TI’s flow only. Teams need to be comfortable with PyTorch QAT and TI’s layer-support rules. If your staff are used to TFLite Micro, expect a learning curve.

Security and update paths. The MSPM0G5187 lists an AES accelerator, secure key storage and firewalls, and a dual-bank flash for over-the-air updates. A model shipped in flash is an asset worth protecting and versioning. Plan for model updates separately from firmware updates, because retraining will happen more often than a code change.

Practical Recommendations

Start by classifying the workload rather than the chip. If the input is a one-dimensional signal or a small spectrogram, the model is under roughly 50 KB, the device must idle at microamps and the unit cost must stay near a dollar, the MSPM0G5187 with its TinyEngine NPU is a sensible first candidate. If the workload is motor control with anomaly detection, look at the AM13Ex or the C2000 F28P55x, and treat the NPU as an advisory path next to a deterministic control loop.

If the input is an image larger than a thumbnail, or the model needs tens of megabytes of weights, do not force it. Choose an Ethos-U55 or Neural-ART class part, or an edge module, and accept the cost.

Prototype cheaply. The LP-MSPM0G5187 LaunchPad at $22 is enough to validate the toolchain and the accuracy, and TI’s Edge AI Studio includes more than 60 models and examples to start from. Measure, do not assume.

A short checklist before committing:

Write down the model’s parameter count, MACs, peak activation size and inference rate, then compare to 32 KB of SRAM and the implied 16 MACs per cycle budget.
Confirm every layer pattern is in the compiler’s supported-on-NPU list, and record the fraction of MACs on the NPU.
Train with quantization-aware training at the target precision and test on held-out devices and conditions.
Measure current on a power profiler across a full duty cycle, including wake-up and sensor time.
Decide the model update path (dual-bank flash, signed images) before the first field unit ships.
For AM13Ex, ask TI for safety documentation and errata status for the exact device revision.
Compare against one Ethos-U or Neutron part on the same model to confirm the low-cost tier is enough.

Frequently Asked Questions

What is the TinyEngine NPU?

The TinyEngine NPU is a small neural processing unit designed by Texas Instruments and integrated into its C2000 F28P55x, Arm Cortex-M33 AM13E230x and Cortex-M0+ MSPM0G5187 microcontrollers. It executes quantized convolutional, fully connected and pooling layers in parallel with the CPU, at up to 2.56 GOPS. TI says it delivers up to 90x lower latency and over 120x lower energy per inference than comparable MCUs without an accelerator.

How fast is the MSPM0G5187 NPU compared with an Ethos-U55?

The MSPM0G5187’s TinyEngine is rated at 2.56 GOPS at 80 MHz. Arm’s Ethos-U55 scales from 32 to 256 MACs, and in Renesas’ RA8P1 it is quoted at 256 GOPS at 500 MHz, about 100 times higher peak. The two target different tiers: TinyEngine for sub-dollar sensor and audio models, Ethos-U for larger audio and vision workloads with more memory and higher power.

How much does the MSPM0G5187 cost and when is it available?

TI states the MSPM0G5187 is priced under $1 in 1,000-unit quantities, and one secondary source lists $0.97. It is in production as of the March 2026 announcement. The LP-MSPM0G5187 LaunchPad development kit costs $22. The AM13E23019 is separate: $2.45 per 1,000 units in preproduction, with more AM13Ex variants planned by the end of 2026.

Can the TinyEngine NPU run speech or vision models?

It can run small keyword-spotting and gesture models, which TI cites as target uses, thanks to the MSPM0G5187’s I2S/TDM audio interface. Vision is limited: 32 KB of SRAM cannot hold the activation maps of even a small camera network. Large language models and transformers are out of scope, since the documented operators are convolutional, fully connected and pooling layers.

What tools do I use to deploy models on the TinyEngine NPU?

TI provides CCStudio Edge AI Studio, the open-source TinyML Tensorlab (ModelMaker, ModelOptimization and ModelZoo), and the TI Neural Network Compiler for MCUs, which outputs an inference library for Code Composer Studio. Training happens in PyTorch, with quantization-aware training recommended for the 8-, 4- and 2-bit modes. The SDKs support FreeRTOS and Zephyr on the MSPM0G5187.

Should I choose TinyEngine or a Cortex-M55 with Ethos-U?

Choose the TinyEngine when the model is small, the device must sleep at microamps, cost is a hard limit and you already build on TI silicon. Choose a Cortex-M55 or M85 with Ethos-U when you need vision, larger models, portable toolchains across vendors, or a higher performance headroom. If unsure, benchmark your model on both, because vendor claims are relative to their own baselines.

TI MSPM0G5187 and AM13Ex: TinyEngine NPU Edge AI Microcontrollers