Coral NPU veröffentlicht 32-Bit-Design und Compiler

Published · AI Daily — AI-assisted deep research, methodology & disclosure

Der Coral NPU-Beitrag von Google vom 20. Oktober verknüpft ein vollständiges 32-Bit-RTL-Design und den IREE/MLIR-Compiler-Stack v1.0 mit der Hardware von Synaptics-Partnern. Die Matrixeinheit ist bis zu 1 TOPS mit einem durchschnittlichen Inferenzleistungsziel von 10 mW konfigurierbar. Hierbei handelt es sich um Design- und Herstellerversprechen, nicht um eine messbare Garantie für jedes eingesetzte Edge-Gerät.

Coral NPU veröffentlicht mehr vom Edge-Stack

Der Entwicklerbeitrag von Google vom 20. Oktober beschreibt eine offene 32-Bit-Coral-NPU-Architektur, eine v1.0-Compiler-Grundlage und Partnerhardware. Das ursprüngliche Datum ist wichtig: Es handelt sich um eine technische Ankündigung vom 20. Oktober, die für die Ausgabe vom 25. Oktober ausgewählt wurde, und nicht um eine Neuveröffentlichung am Sonntag. Laut Google sind die Meilensteine ​​eins bis vier der Architektur jetzt verfügbar, darunter eine Matrix Execution Unit, die bis zu 1 TOPS konfigurierbar ist und auf eine durchschnittliche Inferenzleistung von etwa 10 mW abzielt. Diese Zahlen beschreiben ein Konfigurations- und Designziel und keinen unabhängig verifizierten Benchmark für jedes Board oder jede Arbeitslast. Die vollständige 32-Bit-RTL wird aus dem Projekt-Repository verlinkt, wodurch die Implementierung besser überprüfbar ist als ein Diagramm allein.

Warum ein offenes Design immer noch einen Compiler benötigt

Ein Beschleunigerbefehlssatz ist nur ein Teil der nutzbaren Kanteninferenz. Ein Entwickler beginnt mit einem Modell in JAX, PyTorch oder TensorFlow und benötigt dann einen Exportpfad, unterstützte Operatoren, Partitionierung zwischen CPU und NPU, Speicherlayout, Quantisierung und wiederholbare Leistungsmessungen. Als Software-Brücke präsentiert Google den auf IREE und MLIR basierenden Coral Compiler v1.0. Es heißt, dass der Stack Standarddarstellungen einschließlich StableHLO und TOSA akzeptiert, Operationen fusioniert, Matrizen für den lokalen Speicher in Kacheln aufteilt und das Ziel simulieren kann. Das Compiler-Repository ist eine primäre Quelle für verfügbaren Code. Eine erfolgreiche Kompilierung beweist nicht die numerische Genauigkeit oder Energieeffizienz für ein bestimmtes Sensorprodukt; Diese erfordern eine Platine und einen Messaufbau.

Die Architektur kombiniert ein C-programmierbares RISC-V-Skalar-Frontend, eine RVV 1.0-Vektoreinheit und die neue Matrixeinheit. Die Matrixeinheit verwendet eine spezielle Außenprodukt-Multiplikations-Akkumulations-Engine, die mit der RISC-V-VME-Richtung verbunden ist. Diese Arbeitsteilung spiegelt gängige Edge-Modelle wider: Kontrollfluss und Vorverarbeitung sehen nicht wie eine große Matrixmultiplikation aus, während Aufmerksamkeits- und Visionsschichten dies häufig tun. Ein gemeinsam entwickelter Software-Stack kann entscheiden, wo jeder Vorgang hingehört. Der Nutzen muss auf der gesamten Anwendungsebene gemessen werden, einschließlich Sensorerfassung, CPU-Fallback und Speicherverschiebung. Ein hoher TOPS-Spitzenwert kann mit einer schlechten Anwendungslatenz einhergehen, wenn nicht unterstützte Vorgänge wiederholt Daten zwischen Prozessoren verschieben.

Hardware-Ansprüche beziehen sich auf verschiedene Produkte

Derselbe Beitrag identifiziert Synaptics Astra SR200-Mikrocontroller-Chips mit 400 GOPS und stellt ein Coralboard SR-Entwicklungskit vor. Es heißt auch, dass Coralboard SL, das als 1-TOPS-Board beschrieben wird, nach einer früheren Vorschau über DigiKey allgemein verfügbar wurde. Hierbei handelt es sich nicht um austauschbare Messungen: Eine beschreibt eine Mikrocontroller-Serie der zweiten Generation, eine andere ein Board, und das konfigurierbare Architekturziel ist eine separate Aussage. Der Artikel berichtet über die Ankündigungen der Anbieter; Es wurden weder Stromverbrauch, Preis noch Verfügbarkeit in jeder Region gemessen. Teams, die ein Produkt bewerten, sollten vor der Auswahl eines Modells die genaue Siliziumversion, die Speicherkapazität, den unterstützten Compiler-Build und den tatsächlichen Kaufstatus bestätigen.

Open RTL kann eine Barriere senken und andere offenlegen

Durch die Veröffentlichung von RTL und einem Compiler erhalten Silizium- und Toolchain-Teams eine konkrete Grundlage für Inspektionen und Experimente. Dadurch wird die Herstellung eines fertigen Chips nicht kostenlos, und es ist auch nicht garantiert, dass jeder Operator eines vorhandenen Modells unterstützt wird. Hardware-Integratoren benötigen weiterhin Verifizierung, Timing-Abschluss, Softwaretreiber und Sicherheitsqualifikation. Anwendungsentwickler benötigen Daten, um zu sehen, ob eine Edge-Bereitstellung nach Komprimierung oder Operator-Ersetzung korrekt bleibt. Die kommerziellen Beispiele des Beitrags zeigen einen Weg von der Architektur zu Produkten, es handelt sich jedoch eher um von Anbietern bereitgestellte Beispiele als um eine allgemeine Zählung der Branchenakzeptanz.

Der Quelle zufolge umfasst die nächste Roadmap-Phase eine 64-Bit-Architektur und CHERI-Unterstützung. Dabei handelt es sich um Pläne, nicht um Funktionen der 32-Bit-Version. Ein Projekt mit aktuellem 32-Bit-Anforderungen sollte die veröffentlichte RTL und den Compiler überprüfen, anstatt einen zukünftigen Zweig zu planen. Sicherheitsempfindliche Geräte sollten auch die Ambitionen hinsichtlich der Speichersicherheit von den Isolationseigenschaften heutiger Hardware und Firmware unterscheiden. Die gleiche Vorsicht gilt für das 10-mW-Ziel: Ein durchschnittliches Ziel für die Inferenzleistung ist nicht die volle Akkulaufzeit des Geräts. Radio, Sensor, CPU und Standby-Strom können ein ständig aktives Produkt dominieren.

Eine reproduzierbare Kantenauswertung

Wählen Sie ein kompaktes Modell und veröffentlichen Sie das genaue Diagramm, die Eingabeform, die numerische Toleranz und die Auswertungsdaten, die in einem Versuch verwendet wurden. Führen Sie zuerst den Coral-Compiler und -Simulator aus, um nicht unterstützte Operatoren und CPU-Fallbacks zu identifizieren, und messen Sie dann dasselbe Modell auf einer benannten Platine mit stabiler Uhr, Leistungsinstrument und Umgebungsbedingungen. Zeichnen Sie End-to-End-Latenz, Durchsatz, Modellqualität, Speichernutzung und Gesamtsystemenergie pro Inferenz auf. Vergleichen Sie es mit einer reinen CPU-Basis oder einer anderen Beschleuniger-Baseline mit derselben Arbeitslast. Wenn ein Modell eine neu geschriebene Ebene erfordert, melden Sie diese Neuschreibung als Teil des Ergebnisses. Dieses vorgeschlagene Protokoll hält eine Behauptung über offene Werkzeuge getrennt von der gemessenen Produktleistung.

Die wichtige Entwicklung ist die Verfügbarkeit von Architektur- und Compiler-Artefakten, die Ingenieure zusammen mit konkreter Partnerhardware prüfen und anpassen können. Google hat primäre Code-Links und Produktansprüche bereitgestellt, die Quelle liefert jedoch keinen unabhängigen geräteübergreifenden Benchmark für jeden Edge-Anwendungsfall. Für Leser aus den Bereichen Robotik, Wearables und lokale Inferenz besteht der nützliche nächste Schritt darin, ihr eigenes Modell zu testen, anstatt einen TOPS oder eine Potenzzahl zu extrapolieren. Das Veröffentlichungsdatum 25. Oktober ist redaktionell; Die Upstream-Ankündigung und die darin zitierte Synaptics-Veranstaltung sind auf den 20. Oktober datiert.

Sources

FAQ

Was hat Google am 20. Oktober für Coral NPU veröffentlicht?

Google verknüpft die komplette 32-Bit-Coral-NPU-RTL, einschließlich einer Matrixeinheit, und eine v1.0-Compiler-Grundlage basierend auf IREE und MLIR. Außerdem werden Chips und Entwicklungsboards von Synaptics-Partnern beschrieben. Die Architektur kann besichtigt werden, die Ankündigung bewertet jedoch nicht jedes Modell, jede Platine oder jeden Leistungszustand einzeln.

Wie sollte ein Entwickler einen TOPS und 10 mW interpretieren?

Der Beitrag beschreibt eine konfigurierbare Matrixeinheit mit bis zu einem TOPS und einem Ziel von etwa 10 mW durchschnittlicher Inferenzleistung. Bei diesen Zahlen handelt es sich um begrenzte Designansprüche, nicht um die Akkulaufzeit des gesamten Geräts oder den garantierten Anwendungsdurchsatz. Sensorerfassung, CPU-Fallback, Speicherbewegung und tatsächliche Modelloperatoren müssen auf benannter Hardware gemessen werden.

Was ist ein nützlicher Test für den offenen Coral-Stack?

Kompilieren Sie ein angeheftetes Modell, zeichnen Sie nicht unterstützte Operatoren und CPU-Fallbacks auf und führen Sie es dann auf einem benannten Board mit festen Eingabeformen und numerischer Toleranz aus. Messen Sie die End-to-End-Latenz, Genauigkeit und Systemenergie und vergleichen Sie eine CPU-Basislinie mit denselben Daten. Dieser vorgeschlagene Test unterscheidet sich von den angegebenen Produkt- und Architekturansprüchen von Google.