Coral NPU completes 10 mW RISC-V architecture and gets compiler that skips assembly

Running AI inference outside the cloud has always run into a practical problem: every edge chip maker has its own architecture, its own compiler, and its own quantization limitations. The result, in the words of the Google Developers Blog, is a "fragmentation tax": the ML team rewrites kernels, requantizes the model, and debugs a proprietary compiler for every new hardware target.

It was to tackle this that Google Research introduced, last year, the Coral NPU: an open hardware standard (a RISC-V architecture geared toward ML) paired with an open-source toolchain. On October 20, 2026, coinciding with Synaptics Tech Day, the project reached three milestones that shift the standard's status from experiment to something already running in commercial silicon.

The 32-bit architecture is complete

The Coral NPU is built in four blocks ("milestones"). The first three, released over the past year, covered a C-programmable RISC-V scalar frontend for flow control, an RVV v1.0 vector coprocessor for SIMD operations, and a memory subsystem with floating-point support. The fourth and final block, announced now, is the Matrix Execution Unit (MXU).

The MXU exists because modern ML workloads, from vision encoders to transformer attention layers, spend most of their time on matrix multiplication (GEMM/GEMV). Running 2D math on a 1D vector engine forces the chip to repeatedly reload weights and activations from memory, which burns more energy moving data than doing the math. The MXU uses an outer-product MAC engine based on the RISC-V VME specification (Zvt family), capable of computing a full 2D tile per cycle, 256 MACs per cycle, reusing weights and activations in local registers.

The practical result: throughput scales quadratically, configurable up to 1 TOPS, with a target of 10 mW average power for inference. That number is what separates, according to Google, devices that only do keyword spotting or simple motion detection from devices capable of running continuous multimodal models, such as compact versions of Gemma, real-time voice translation on wearables, and low-latency visual perception on robots, all on a small battery.

The complete RTL for the 32-bit architecture is available on GitHub, and Google says it is working with VeriSilicon on design implementation and verification to get it ready for tape-out, in addition to a partnership with GlobalFoundries on the 12LP+ FinFET process, which sped up core timing by 70% and reduced standard-cell area by up to 15% between RTL iterations.

From PyTorch to silicon without writing assembly

The second piece is the Coral Compiler v1.0, built on top of IREE/MLIR. It takes models written in JAX, PyTorch, or TensorFlow and carries them through standardized representations like StableHLO and TOSA down to the Coral NPU hardware. Along the way, the compiler partitions the work between the host CPU and the NPU core, performs operator fusion, tiles the matrices to fit into local SRAM and matrix accumulators, and progressively lowers everything into the Coral NPU's scalar, vector (RVV v1.0), and matrix (VME) instructions.

This is what eliminates the need to write vendor-specific assembly: the entire flow, from ML framework to silicon instruction, runs through a single pipeline. Alongside the compiler, Google is releasing the MPACT simulator and an FPGA reference design, which makes it possible to benchmark a model and tune silicon configuration before the chip even goes into fabrication, something relevant for anyone designing their own SoC who can't wait for a tape-out to discover a model doesn't run.

Real hardware: two Coralboards, one workflow

The third milestone is where the promise becomes a product. At Synaptics Tech Day, Synaptics launched three items built on the Coral NPU:

The Coralboard SL, which had a limited presale at Google I/O, is now in general worldwide availability through DigiKey, with SDK and documentation on Synaptics' developer page. Since both product families share the same architecture and the same compiler, the ML team optimizes a model once and ships the same binary to both a milliwatt-class wearable (Coralboard SR) and a 1 TOPS board (Coralboard SL), using the same compilation workflow.

What this changes for those who build here

For those developing IoT, robotics, or wearables in Brazil, the central point isn't TOPS, it's lock-in. Today, migrating a model trained in PyTorch from one MCU to another usually means switching SDKs, quantization formats, and, in many cases, the entire inference framework (TensorFlow Lite Micro on one chip, a proprietary SDK on another). With the Coral NPU, the promise is to compile once and run on any SoC that implements the standard, from MCU-class to 1 TOPS-class, without rewriting the inference pipeline.

In practice, this opens the door to edge-sensing prototypes, for example in agribusiness or industrial monitoring applications, which today rely on simple keyword spotting because the power budget didn't allow for anything more sophisticated. With a dedicated matrix subsystem under 10 mW, it becomes feasible to consider heavier vision or audio models running continuously on a small battery, without depending on a round trip to the cloud for every inference.

It's worth remembering that this gain is theoretical until someone measures it on real hardware: Google speaks of a design target ("targeting 10mW"), not a published end-application benchmark. Anyone evaluating the Coralboard SR or SL via DigiKey should treat that number as a starting point for their own validation, not as a production guarantee.

Where the standard hasn't arrived yet

The Coral NPU is RISC-V, and that cuts both ways. On one hand, it means not depending on a single IP vendor; on the other, it means a tooling, debugger, and commercial support ecosystem that's still much thinner than established architectures like Cortex-M with TensorFlow Lite Micro, which today dominates much of embedded IoT in Brazil. For now, the only commercial silicon announced comes from a single partner, Synaptics; there isn't yet a second source of manufacturers for those who want to avoid single-vendor dependency again, ironically the very problem the open standard sets out to solve at the architecture level.

Google's roadmap already points to a 64-bit architecture and CHERI support (hardware-level memory safety) as next steps, which signals that the platform is still taking shape. For anyone who needs something in production tomorrow, the safer path is to treat the Coralboard SL as an evaluation kit first: order the board through DigiKey, run the v1.0 compiler against a real model from your domain, and measure power consumption and latency before committing an entire hardware project to the bet.