Démystifier les extensions personnalisées dans la conception SoC RISC-V

La discussion sur la configuration d'un processeur de base ou l'ajout d'extensions personnalisées pour résoudre les compromis conception matériel-logiciel dans un system-on-chip (SoC) a longtemps été une pierre angulaire de la proposition de valeur de la communauté RISC-V. Des articles récents – comme Un guide pour accélérer les applications avec des instructions personnalisées RISC-V justes – soulignent les bénéfices tangibles de l'extension de l'ISA open-source.

Les SoC IA et machine learning d'aujourd'hui sont contraints par la puissance, la performance et la surface de puce, faisant des extensions ISA un levier puissant mais souvent négligé pour répondre à ces exigences.

Un récent webinaire Quantum Leap Solutions, intitulé Flexibilité RISC-V – La puissance des extensions personnalisées, visait à démystifier comment l'ISA RISC-V peut être adapté pour la conception SoC moderne. La session a attiré plus de 100 participants et mettait en vedette un panel d'experts de l'industrie.

La discussion s'est concentrée sur comment un ISA modifié peut accélérer les applications émergentes et comment les concepteurs évaluent les extensions pour l'architecture RISC-V.

Modéré par Mike Ingster, fondateur et président de Quantum Leap Solutions, les panelistes étaient :

• John Min, Directeur FAE chez Andes Technology
• Larry Lapides, Vice-Président Ventes chez Imperas Software
• Taek Nam, Ingénieur Application Senior chez Mentor

Mike Ingster : Pourquoi RISC-V est-il une meilleure option pour les applications d'apprentissage IA et ML que d'autres architectures CPU ?

John Min : RISC-V a été conçu alors que l'IA devenait mainstream, et son jeu d'instructions vectoriel a été conçu avec les charges de travail IA et VR à l'esprit.

Larry Lapides : Dans un système IA avec un array multiplexé de processeurs hétérogènes – une architecture qu'on a vue implémentée à plusieurs reprises – un concepteur peut combiner cœurs scalaires et vectoriels. RISC-V vous permet d'éliminer les fonctionnalités inutiles tout en gardant les instructions vectorielles, délivrant un PPA (prix-performance-surface) supérieur.

Ingster : Les cœurs RISC-V avec extensions vectorielles peuvent-ils aussi être étendus avec des instructions personnalisées ?

Min : Oui. Un exemple typique est un cœur vectoriel qui incorpore des extensions clients pour ajouter des tampons supplémentaires, prévenant les arrêts dus à la famine de données.

Lapides : Imperas et Andes ont tous deux des clients qui ont implémenté de telles fonctions personnalisées pour améliorer la performance.

Ingster : Dans un array multiprocesseur, tous les CPUs ont-ils besoin de la même configuration, ou peuvent-ils avoir des instructions personnalisées différentes ?

Lapides : Les processeurs hétérogènes sont courants. Les instructions personnalisées peuvent varier d'un cœur à l'autre, et même le jeu d'instructions de base peut différer – un cœur peut supporter les instructions vectorielles tandis qu'un autre reste scalaire, permettant une exécution entrelacée.

Min : Dans un array multiplexé, CPUs et simulateurs peuvent être hétérogènes, permettant une simulation multicœur efficace.

Ingster : Voyez-vous un processeur RISC-V de classe serveur sur le marché ?

Min : La trajectoire est claire : fréquence plus élevée, pipelines plus larges, exécution out-of-order, et multicœurs massivement parallèles. Ces éléments apparaissent déjà dans les cœurs RISC-V de prochaine génération pour charges de travail IA entreprise.

Lapides : Historiquement, RISC-V a commencé avec des SoCs preuve de concept 32 et 64 bits. Il y a environ deux ans, on a vu une surge de SoCs IoT et axés sécurité. Aujourd'hui, on voit des processeurs de classe application – cœurs RISC-V 64 bits tournant de vrais RTOS et premiers pipelines out-of-order. Les premières puces de classe serveur sont attendues dans les deux à trois prochaines années.

Ingster : Les extensions personnalisées peuvent-elles fournir la sécurité du dispositif et la gestion du cycle de vie ?

Min : Absolument. Une instruction personnalisée peut effectuer des vérifications à l'exécution pour forcer la compatibilité logicielle, ou un port mémoire dédié peut isoler des données critiques, améliorant la sécurité et le contrôle du cycle de vie.

Taek Nam : Les concepteurs peuvent aussi tirer parti de l'IP d'analytique embarquée Tessent pour intégrer la sécurité et la gestion du cycle de vie directement dans les SoCs avec extensions personnalisées.

Ingster : Pourquoi l'approche RISC-V aux instructions personnalisées diffère-t-elle d'autres vendeurs comme ARC ou Tensilica ?

Min : Le mécanisme d'extension formel de RISC-V permet aux instructions personnalisées d'être formellement incorporées dans le standard, fournissant un chemin clair vers une adoption plus large.

Ingster : Comment un développeur peut-il partager des instructions personnalisées avec clients ou partenaires ?

Min : Trois options existent : la garder propriétaire, la soumettre à RISC-V International pour inclusion (ex. extensions DSP d'Andes devenues P-extensions), ou partager les intrinsèques et fichiers d'en-tête tout en protégeant l'implémentation sous NDA.

Lapides : Un modèle d'extension personnalisée peut être offert comme open-source ou binaire, ou comme modèle de processeur instruction-accurate, facilitant le développement logiciel pré-silicium.

Ingster : Les extensions personnalisées mèneront-elles à des problèmes de compatibilité dans la communauté RISC-V ?

Min : Les extensions propriétaires restent isolées ; si une extension gagne une utilisation répandue, elle peut être proposée pour inclusion dans l'ISA de base, prévenant la fragmentation.

Ingster : Le processeur vectoriel est-il supporté par un compilateur dans sa version actuelle ?

Min : Les extensions vectorielles RISC-V 0.8 sont stables et supportées par GCC et LLVM. Le support compilateur final suivra la finalisation de la spécification officielle.

Ingster : Comment les extensions personnalisées sont-elles supportées dans la chaîne d'outils logicielle ?

Lapides : Les concepteurs intègrent les extensions dans leurs modèles RISC-V, générant des simulateurs de jeu d'instructions pour le développement logiciel. GCC et LLVM peuvent être étendus pour supporter de nouvelles instructions, et les concepteurs peuvent fournir des implémentations macro.

Ingster : Comment le compilateur est-il informé d'une instruction personnalisée nouvellement créée ?

Lapides : L'équipe logicielle doit implémenter l'instruction dans le backend du compilateur.

Min : Alternativement, traiter l'instruction comme une bibliothèque : fournir un fichier d'en-tête et une implémentation propriétaire optionnelle, minimisant l'effort de développement tout en gagnant en performance.

Ingster : Quels OS sont supportés sur RISC-V, et y a-t-il un support pour Android ?

Lapides : Linux, Zephyr RTOS, et d'autres systèmes d'exploitation temps-réel sont les cibles principales. Android n'a pas été officiellement vérifié sur RISC-V, mais des efforts de portage sont en cours. Le site RISC-V International liste tous les OS supportés.

Ingster : Comment les extensions personnalisées sont-elles vérifiées ?

Lapides : La vérification implique d'ajouter les extensions au RTL et au modèle de processeur. Les simulateurs de jeu d'instructions permettent une validation logicielle précoce.

Taek : Un client récent a utilisé notre IP d'analytique embarquée pour tracer et quantifier les gains de performance des instructions personnalisées, confirmant les bénéfices par une validation pilotée par les données.

Ingster : Quelle surface est requise pour ajouter l'IP d'analytique embarquée ?

Taek : Typiquement autour de 1 % de la puce, selon la configuration. Chaque design est évalué pour optimiser la surface tout en délivrant la valeur maximale.

Ces points forts sont tirés de la discussion complète du panel, hébergée par Quantum Leap Solutions.