Coral NPU publie sa conception 32 bits et son compilateur

Coral NPU publie davantage de pile de périphérie

Le message des développeurs de Google du 20 octobre décrit une architecture ouverte Coral NPU 32 bits, une base de compilateur v1.0 et du matériel partenaire. La date originale compte : il s'agit d'une annonce technique du 20 octobre sélectionnée pour le numéro du 25 octobre, et non d'un nouveau lancement dimanche. Google affirme que les étapes un à quatre de l'architecture sont désormais disponibles, y compris une unité d'exécution matricielle configurable jusqu'à 1 TOPS et ciblant une puissance d'inférence moyenne d'environ 10 mW. Ces chiffres décrivent un objectif de configuration et de conception, et non une référence vérifiée de manière indépendante pour chaque carte ou charge de travail. Le RTL 32 bits complet est lié à partir du référentiel du projet, ce qui rend l'implémentation plus inspectable qu'un diagramme seul.

Pourquoi une conception ouverte a toujours besoin d'un compilateur

Un jeu d’instructions d’accélérateur n’est qu’un élément d’inférence de bord utilisable. Un développeur commence avec un modèle dans JAX, PyTorch ou TensorFlow, puis a besoin d'un chemin d'exportation, d'opérateurs pris en charge, d'un partitionnement entre CPU et NPU, d'une disposition de la mémoire, d'une quantification et de mesures de performances répétables. Google présente Coral Compiler v1.0, construit sur IREE et MLIR, comme pont logiciel. Il indique que la pile accepte les représentations standard, notamment StableHLO et TOSA, fusionne les opérations, les matrices de tuiles pour la mémoire locale et peut simuler la cible. Le référentiel du compilateur est une source principale de code disponible. Une compilation réussie ne prouve pas la précision numérique ou l’efficacité énergétique d’un capteur particulier ; ceux-ci nécessitent une carte et une configuration de mesure.

L'architecture combine un frontal scalaire RISC-V programmable en C, une unité vectorielle RVV 1.0 et la nouvelle unité matricielle. L'unité matricielle utilise un moteur de multiplication-accumulation de produits externes dédié associé à la direction RISC-V VME. Cette division du travail reflète des modèles courants déployés en périphérie : le flux de contrôle et le prétraitement ne ressemblent pas à une multiplication matricielle à grande échelle, contrairement aux couches d'attention et de vision. Une pile logicielle co-conçue peut décider de la place de chaque opération. Le bénéfice doit être mesuré sur l'application entière, y compris la capture des capteurs, le repli sur le CPU et les transferts mémoire. Si des opérations non prises en charge entraînent des transferts répétés entre processeurs, un pic élevé en TOPS peut coexister avec une forte latence de l'application.

Les réclamations concernant le matériel appartiennent à différents produits

Le même article identifie les puces du microcontrôleur Synaptics Astra SR200 à 400 GOPS et présente un kit de développement Coralboard SR. Il indique également que Coralboard SL, décrite comme une carte 1 TOPS, a atteint la disponibilité générale via DigiKey après un aperçu antérieur. Ce ne sont pas des mesures interchangeables : l'une décrit une série de microcontrôleurs de deuxième génération, l'autre une carte, et l'architecture cible configurable est une déclaration distincte. L'article rapporte ce que les vendeurs ont annoncé ; il n’a pas mesuré la consommation d’électricité, le prix ou la disponibilité dans chaque région. Les équipes évaluant un produit doivent confirmer la révision exacte du silicium, la capacité de mémoire, la version du compilateur prise en charge et le statut d'achat réel avant de choisir un modèle.

Open RTL peut abaisser une barrière et en exposer d'autres

La publication de RTL et d'un compilateur donne aux équipes silicium et chaîne d'outils une base concrète pour l'inspection et les expériences. Cela ne rend pas la fabrication d'une puce finie gratuite et ne garantit pas non plus que chaque opérateur d'un modèle existant est pris en charge. Les intégrateurs de matériel ont encore besoin de vérification, de fermeture de synchronisation, de pilotes logiciels et de qualifications en matière de sécurité. Les développeurs d'applications ont besoin de données pour voir si un déploiement périphérique reste précis après compression ou substitution d'opérateur. Les exemples commerciaux de l'article montrent un cheminement depuis l'architecture jusqu'aux produits, mais il s'agit d'exemples fournis par les fournisseurs plutôt que d'un décompte général d'adoption par l'industrie.

La source indique que la prochaine phase de la feuille de route comprend une architecture 64 bits et la prise en charge de CHERI. Ce sont des plans, pas des capacités de la version 32 bits. Un projet avec un besoin actuel de 32 bits devrait revoir le RTL et le compilateur publiés plutôt que de planifier une future branche. Les appareils sensibles à la sécurité doivent également distinguer les ambitions en matière de sécurité de la mémoire des propriétés d'isolation du matériel et des micrologiciels actuels. La même prudence s'applique à l'objectif de 10 mW : un objectif de puissance d'inférence moyenne n'est pas une durée de vie complète de la batterie de l'appareil. La radio, le capteur, le processeur et l'alimentation en veille peuvent dominer un produit toujours actif.

Une évaluation des bords reproductible

Choisissez un modèle compact et publiez le graphique exact, la forme d'entrée, la tolérance numérique et les données d'évaluation utilisées dans un essai. Exécutez d'abord le compilateur et le simulateur Coral pour identifier les opérateurs non pris en charge et le repli du processeur, puis mesurez le même modèle sur une carte nommée avec une horloge, un instrument d'alimentation et des conditions ambiantes stables. Enregistrez la latence de bout en bout, le débit, la qualité du modèle, l'utilisation de la mémoire et l'énergie totale du système par inférence. Comparez avec une référence de CPU uniquement ou une autre référence d'accélérateur utilisant la même charge de travail. Si un modèle nécessite une couche réécrite, signalez cette réécriture dans le cadre du résultat. Le protocole proposé sépare les affirmations sur les outils ouverts des performances mesurées du produit.

Le développement important réside dans la disponibilité d’artefacts d’architecture et de compilateur que les ingénieurs peuvent inspecter et adapter, accompagnés de matériel partenaire concret. Google a fourni des liens vers les codes principaux et des revendications de produits, mais la source ne fournit pas de référence indépendante multi-appareils pour chaque cas d'utilisation Edge. Pour les lecteurs en robotique, en wearables et en inférence locale, la prochaine étape utile consiste à tester leur propre modèle plutôt que d’extrapoler un TOPS ou un seul nombre de puissance. La date de publication du 25 octobre est éditoriale ; l'annonce en amont et l'événement Synaptics qui y est cité sont datés du 20 octobre.