An open design, not a finished consumer gadget

Google announced the completion of its 32-bit Coral NPU architecture on 20 October, alongside version 1.0 of an open compiler toolchain. An NPU is a processor specialised for neural-network calculations; the compiler translates a model into operations the hardware can execute.

The release adds a matrix-processing component to the design and connects it to the IREE/MLIR software stack. Its stated goal is to reduce the work of adapting a model for different small devices.

This is an architecture and developer-tool announcement. It is not the launch of a finished smartwatch, a pair of smart glasses or a general-purpose AI assistant running independently of a phone.

What is available to build with

Synaptics separately announced that the Coralboard SL was moving from a limited-edition run to general availability through DigiKey on 20 October. The company identifies its processor as the Astra SL2619, with a Torq/Coral NPU subsystem rated at 1 TOPS, or a trillion operations per second. That is a stated compute rating, not the speed of every model.

The company also introduced Coralboard SR, based on its Astra SR200 family. Synaptics says the SL and SR boards share a compiler and runtime intended to make development more consistent. The announcement of SR should not be read as proof that its retail availability is identical to SL’s. SIGNAL has not confirmed stock, delivery times or pricing for individual countries.

The open Coral NPU repository provides a separate starting point for developers examining the accelerator itself. A published design and an orderable board serve different needs: one can support hardware development, while the other lets a team begin experimenting without designing its own chip.

Why the software matters as much as the chip

A small device has to fit useful work into limited memory, power and physical space. Imagine a hypothetical camera that recognises a specific event locally, rather than sending every frame elsewhere for analysis. The interesting result is not a large number on a processor specification. It is whether the whole device can recognise the event reliably, respond quickly and keep operating within its energy budget.

Synaptics’ architecture explanation describes a processor family that combines different computing resources and moves between low-power monitoring and more demanding inference. That makes the integration question important: the model, its compiler, memory and surrounding application have to work together.

A shared development path could reduce repeated integration work. It does not mean every model will run unchanged on every board, or that a model that fits a development kit will fit a much smaller finished product. Developers must still validate the specific configuration they intend to ship.

The numbers need their conditions

Google describes the completed architecture as configurable up to 1 TOPS and gives an average inference-power target of 10 milliwatts. It separately lists the SR200 implementation at 400 GOPS, or 400 billion operations per second. These descriptions concern different configurations and should not be combined into a promise about one shipping device.

Nor does processing information locally automatically make an entire product private or offline. The application can still store data, connect to a service or send information elsewhere. The real question is which data moves, under whose control, and for what purpose.

SIGNAL has not benchmarked these releases or measured their power consumption. The reporting here is based on Google’s and Synaptics’ own material, with no independent performance result claimed. Useful next evidence would show representative models, accuracy after optimisation, memory requirements and energy measured across the complete application—not just the accelerator. That is what would turn a promising developer platform into a convincing product foundation.

Original sources

Sources checked 21 October 2026. Send a correction.