Google releases complete Coral AI chip design and open-source compiler
The release pairs an open hardware design with tools for deploying familiar AI models. Its 10 mW inference figure remains a design target, not a finished-device battery rating.
Loading page…
The release pairs an open hardware design with tools for deploying familiar AI models. Its 10 mW inference figure remains a design target, not a finished-device battery rating.
Listen to this story
On October 20, 2026, Google paired a complete open Coral NPU design with compiler version 1.0, making the project a hardware-to-model toolchain rather than a chip specification alone. Its compiler schedules work across a host CPU and accelerator, with the aim of carrying models across device classes; that does not mean identical performance or hardware configurations. Synaptics’ board rollout offers commercial targets from microcontroller-class sensors to Linux robotics, while VeriSilicon and GlobalFoundries are involved in implementation and manufacturing preparation.
The new matrix engine reuses data in local registers and performs 256 multiply-accumulate operations per cycle.
Google lists configurations up to 1 TOPS and targets 10 milliwatts average inference power; this is not a finished-device battery-life rating.
Compiler 1.0 accepts models from JAX, PyTorch and TensorFlow through formats including StableHLO and TOSA, and maps work to scalar, vector and matrix units.
Google Research released the complete 32-bit Coral NPU chip design and version 1.0 of its open-source compiler on October 20, 2026. The paired release gives developers both hardware blueprints and software for targeting them, supporting Google’s effort to reduce the work of moving AI models between small, low-power devices.
Google’s stated problem is fragmentation: developers targeting different chips can end up rewriting low-level operations, changing model precision and debugging vendor-specific compilers. Its answer is to develop the accelerator and compiler together, rather than publish a hardware specification and leave software teams to make models fit afterward.
The final architectural milestone is a Matrix Execution Unit, released this month. It joins three earlier pieces: a RISC-V processor for control logic, a vector processor that handles multiple data elements together, and a closely connected memory system with floating-point support. Google has published the complete RTL—the code describing the hardware’s logic—on GitHub.
The distinction is how the hardware handles matrix multiplication, a central operation in vision models and transformer attention. Google says a vector engine repeatedly loads weights and intermediate data for this work. The new matrix engine instead reuses that data in local registers, performing 256 multiply-accumulate operations per cycle rather than repeatedly moving it through memory.
Google specifies configurations reaching one trillion operations per second, or 1 TOPS, and targets 10 milliwatts of average inference power. Inference means running a trained model. That power figure is a design target, not a battery-life rating for a finished wearable or robot. Google identifies continuous sensing and compact transformer models as intended uses.
The accompanying compiler translates models into instructions the hardware can execute. Built on the IREE and MLIR software projects, version 1.0 accepts models from JAX, PyTorch and TensorFlow through standard intermediate formats, including StableHLO and TOSA. Developers therefore do not need to start by writing custom assembly instructions.
Its job extends beyond translation. Google says the compiler divides workloads between the host CPU and Coral accelerator, combines operations, and breaks matrices into blocks that fit local memory. It then maps the work onto scalar, vector and matrix instructions. That division matters because Google says unsupported model layers falling back to a CPU can increase delay and battery drain.
Hardware teams also get an open-source MPACT simulator and a reference design for an FPGA, a reprogrammable chip. Google says those tools let teams benchmark models and adjust silicon configurations before committing a chip to fabrication, connecting software testing with hardware design choices.
Alongside Google’s release, Synaptics moved its Coralboard SL from a limited run to general availability through DigiKey on October 20. The partner announcement also introduced Coralboard SR, based on the newly launched Astra SR200 family. That family incorporates second-generation Coral NPU technology with RISC-V vector-core support.
Google presents the shared architecture and compiler foundation as a way to optimize a model once and deploy across these different power budgets. That is the portability proposition: a common development workflow spanning devices, rather than identical computing capacity or hardware configurations in every Coral-based product.
For companies turning the open design into commercial chips, Google is working with VeriSilicon on implementation and design verification. It is also working with GlobalFoundries on its 12LP+ manufacturing process, including evaluation of ultra-low-power libraries for the matrix unit. Those efforts address the production work beyond publishing the blueprints: implementing, checking and preparing a design for fabrication.
Loading discussion...
Join the conversation
Explain when access to the source would influence your choice.
Be the first to share a perspective or an experience.
Reader comments
Newest comments first. Replies stay oldest first.