L’analyse fonctionnelle à l’échelle du système permet d’optimiser les SoC manycore et de les mettre sur le marché dans le délai imparti.
Les besoins en matière de traitement de données des applications d’intelligence artificielle (IA) et d’apprentissage automatique (ML) ont entraîné un développement important du calcul massivement parallèle et une explosion de la complexité des circuits silicium. Cette complexité se retrouve dans des circuits tels que le Cerebras Wafer-Scale Engine (figure 1), un processeur manycore géant composé d’une mosaïque de puces de silicium et comportant 2,6 billions de transistors et 850 000 cœurs de calcul
Le marché des SoC d’IA continue de croître et est très concurrentiel. Chaque fabricant de semi-conducteurs y trouve son créneau en fonction des performances, du coût et de la flexibilité de ses produits. En développant des produits favorisant chacun un paramètre différent parmi ces trois, les fondeurs ont fait exploser le nombre de nouvelles architectures manycore . Les architectes système testent de nombreuses approches, mais les conceptions sont très complexes et les fabricants de puces veulent tous maîtriser cette complexité pour acquérir un avantage concurrentiel.
Parmi toutes les sources de complexité, il en est une en particulier qu’il est très important de prendre en compte lors de la conception de SoC d’IA multicœurs : lorsque de nombreuses unités d’exécution ( thread ) travaillent en parallèle sur des données partagées, des erreurs fonctionnelles et une dégradation des performances se produisent. Auparavant, les concepteurs pouvaient utiliser la méthode classique du contrôle de l’exécution de l’UC pour déboguer ce problème, mais cette méthode ne fonctionne pas avec les architectures manycore . Compte tenu du temps de propagation aller et retour, du nombre de cœurs, du parallélisme des contrôles et des données, des multiples niveaux de hiérarchie et des processus interdépendants, les concepteurs ont peu de chances de réussir à déterminer la cause première des problèmes logiciels.
En outre, ils doivent tenir compte de la co-optimisation du matériel et du logiciel, ce qui nécessite une analyse fonctionnelle approfondie. Pour mettre en œuvre des applications d’IA sur un SoC, les concepteurs doivent compiler le code source de manière à tirer parti de l’architecture manycore . Cela nécessite souvent une chaîne d’outils sur mesure prenant parfaitement en charge cette architecture. Le processus implique un cycle d’optimisation et de test du matériel et du logiciel, qui commence par une émulation du SoC et se poursuit par sa première version silicium et par ses générations suivantes, comme le montre la figure 2.
Ce cycle d’analyse fonctionnelle permet aux équipes de développement de déterminer :
- l’efficacité avec laquelle les données sont partagées,
- si le réseau sur puce (NoC) est sursouscrit ou déséquilibré,
- comment mesurer les performances de l’application sans affecter l’exécution du code,
- comment optimiser le profil du contrôleur de mémoire pour maximiser le débit de données,
- comment corréler les événements survenant dans l’ensemble du SoC.
Pour en arriver là, il faut adopter une nouvelle approche de l’optimisation des SoC d’IA et des logiciels qu’ils exécutent. Pour pouvoir mettre sur le marché, dans le délai imparti, des SoC d’IA de haute qualité dont les performances restent optimales après le déploiement, il faut procéder à une analyse fonctionnelle à l’échelle du système. Cette analyse permet notamment :
- d’obtenir des informations détaillées sur n’importe quel sous-système ou composant,
- d’avoir une image précise et cohérente de l’ensemble du système dès le démarrage,
- de surveiller les interconnexions en tenant compte des transactions et de générer des statistiques,
- de procéder à un contrôle classique de l’exécution du processeur avec traçage,
- de prendre en charge tous les protocoles d’interconnexion et architectures ISA courants,
- de sélectionner à tout moment les sous-systèmes importants,
- de disposer d’outils flexibles et puissants pour générer des informations sur les données.
Une infrastructure à base d’IP, de logiciels de surveillance et d’analyse intégrée sur la puce offre tous ces avantages, de la simulation au déploiement. La figure 3 illustre une architecture typique de surveillance et d’analyse fonctionnelle d’un SoC.
Prenons un exemple, illustré à la figure 4. Ce schéma fonctionnel est celui d’une puce manycore intégrant un moniteur de NoC (réseau sur puce) qui trace toutes les transactions NoC dans une mémoire tampon circulaire. Comme ce moniteur tient compte des transactions, il peut être configuré pour détecter certains état du bus ; par exemple, un blocage qui fait que la durée de la transaction dépasse un certain seuil (exprimé en nombre de cycles). Lorsque ce seuil est dépassé, le moniteur peut fournir les informations concernant la transaction bloquée et celles qui la précèdent immédiatement, ce qui permet de diagnostiquer le problème. Tout cela ne nécessite aucune intervention de l’hôte de débogage lors de l’exécution.
Le même moniteur de NoC peut être configuré pour déclencher un traçage ailleurs dans le système lors de la détection de ce même état de blocage – par exemple, via un moniteur d’état traçant le comportement d’un accélérateur matériel –, en utilisant la fonctionnalité de déclenchement croisé de l’infrastructure de messagerie d’Embedded Analytics.
Pour pouvoir réussir à produire des SoC manycore , il est indispensable de comprendre les problèmes liés à la mise en œuvre d’un environnement efficace de validation et d’optimisation du système. C’est l’une des principales raisons pour lesquelles il est capital de travailler avec un fournisseur possédant des compétences approfondies dans ce domaine.
