ODIN-Based CPU-GPU Architecture with Replay-Driven Simulation and Emulation

Ce papier présente une méthodologie de validation par rejouabilité pour l'intégration d'une architecture SoC ODIN combinant CPU et GPU, permettant de reproduire de manière fiable des charges de travail complexes et d'accélérer le débogage dans les systèmes à base de chiplets.

L'essentiel

🏗️ Le Grand Projet : Assembler le Cerveau et les Mains

Imaginez que vous construisez une ville futuriste (un processeur moderne). Cette ville a besoin de deux types de bâtiments principaux :

1. Le Cerveau (CPU) : C'est le maire. Il est très intelligent, prend des décisions rapides, gère les feux de circulation et gère les détails. Mais il ne peut pas faire beaucoup de choses en même temps.
2. Les Mains (GPU) : C'est une armée de milliers d'ouvriers. Ils sont moins bons pour prendre des décisions complexes, mais ils peuvent déplacer des montagnes de briques (traiter des données) tous en même temps, très vite.

Le défi de l'article est de coller ces deux bâtiments ensemble pour qu'ils travaillent comme une seule équipe. C'est ce qu'on appelle l'architecture "ODIN".

🚧 Le Problème : Le Chaos de la Construction

Avant de construire la vraie ville en béton (le vrai processeur en silicium), les ingénieurs doivent la simuler sur ordinateur. Mais c'est un cauchemar pour trois raisons :

• C'est trop grand : La ville est immense.
• C'est imprévisible : Parfois, les ouvriers (GPU) agissent de manière un peu aléatoire, ce qui rend difficile de savoir pourquoi un problème survient.
• Le langage est compliqué : Le Maire et les Ouvriers parlent des langages techniques très précis. Si l'un fait un faux pas, tout s'arrête.

Habituellement, pour tester cela, les ingénieurs devaient écrire des manuels d'instructions (des "modèles") pour dire au Maire comment parler aux Ouvriers. Mais écrire ces manuels prend des mois, et souvent, le manuel pour la simulation (le dessin) ne correspond pas exactement à celui pour l'émulation (le prototype rapide). C'est comme si vous essayiez de piloter un avion avec un manuel écrit pour un bateau : ça ne marche pas bien.

💡 La Solution Magique : La "Machine à Rembobiner" (Replay Engine)

Au lieu d'écrire de nouveaux manuels, les ingénieurs d'Intel ont eu une idée brillante : enregistrer la conversation.

Imaginez que vous filmez une répétition parfaite où le Maire et les Ouvriers travaillent ensemble sans erreur.

1. L'Enregistrement (Capture) : Ils regardent d'abord le "GPU" tout seul, enregistre chaque mouvement, chaque mot et chaque geste exact qu'il fait.
2. Le Rembobinage (Replay) : Ensuite, quand ils assemblent la grande ville (CPU + GPU), ils ne demandent pas aux ouvriers de réfléchir. Ils leur disent : "Regardez la vidéo de la répétition et faites exactement la même chose, au même moment."

C'est ce qu'ils appellent le "Replay Engine" (Moteur de Rejoue).

🎬 Comment ça marche en pratique ?

Voici les étapes, comparées à un tournage de film :

• La Répétition (Validation IP) : D'abord, on teste le GPU seul. On enregistre tout ce qui se passe sur les câbles qui le relient au reste du système. On transforme cette vidéo en une liste de codes (une "ROM") très précise.
• Le Tournage (Simulation & Émulation) :
  • En Simulation (Le Script) : On utilise cette liste de codes pour faire tourner le système lentement sur un ordinateur puissant. On peut tout voir en détail, comme un réalisateur qui regarde chaque plan au ralenti pour trouver une erreur.
  • En Émulation (Le Prototype) : On met ce même code sur des puces spéciales (FPGA) qui vont très vite. On peut faire tourner des scénarios réels (comme lancer un jeu vidéo ou de l'IA) en quelques secondes, ce qui prendrait des années en simulation lente.

L'avantage clé : Comme on utilise la même vidéo enregistrée pour les deux étapes, il n'y a pas de confusion. Si un bug apparaît dans le prototype rapide, on sait exactement où il est, car on peut le rejouer instantanément dans la simulation lente pour l'analyser.

🏆 Les Résultats : Une Ville construite en un trimestre

Grâce à cette méthode, l'équipe a réussi quelque chose d'extraordinaire :

• Ils ont fait démarrer le système et exécuter des tâches complexes en moins de trois mois (un trimestre).
• Ils ont évité des mois de travail à écrire des manuels d'instructions (BFM).
• Ils ont pu trouver et corriger les bugs beaucoup plus vite, car ils pouvaient rejouer le problème à l'infini sans que le système ne change d'humeur.

🎒 En résumé : Les Leçons à retenir

1. La répétition est reine : Mieux vaut enregistrer une performance parfaite et la rejouer que d'essayer de la recréer à chaque fois.
2. Un seul langage pour tous : En utilisant le même fichier d'enregistrement pour la simulation lente et le prototype rapide, on évite les malentendus.
3. La précision avant tout : Pour que la "vidéo" fonctionne, il faut que tout soit parfaitement synchronisé (pas de mouvements aléatoires).
4. Gain de temps : Cette méthode a permis de construire et de valider une partie de processeur très complexe beaucoup plus vite que les méthodes traditionnelles.

En gros, au lieu de demander à des ingénieurs de réinventer la roue à chaque fois qu'ils testent un nouveau système, ils ont simplement dit : "Regardez comment on l'a fait la dernière fois, et faites pareil !". C'est simple, efficace, et ça fonctionne.

Résumé technique

1. Problématique et Contexte

L'intégration de sous-systèmes CPU et GPU au sein d'une même puce (SoC) est devenue fondamentale pour les charges de travail modernes d'IA et de graphisme. Cependant, cette intégration dans une architecture basée sur des « chiplets » (puces modulaires), comme l'architecture ODIN d'Intel, pose des défis de validation pré-silicium considérables :

• Complexité de l'interaction : La combinaison de processus orientés contrôle (CPU) et de calcul massivement parallèle (GPU) crée des interactions de protocole complexes, notamment au niveau des interfaces du Network-on-Chip (NoC).
• Non-déterminisme et échelle : Les exécutions GPU sont souvent non déterministes et dépendent fortement de la hiérarchie mémoire. La validation traditionnelle par tests dirigés (directed testing) est insuffisante pour détecter des problèmes d'intégration qui n'apparaissent que sous des charges de travail réalistes.
• Fracture Simulation/Émulation : Les flux de validation classiques reposent souvent sur des modèles fonctionnels de bus (BFM) distincts pour la simulation et l'émulation. Cela entraîne la maintenance de bases de données séparées, une complexité accrue dans la configuration, et des difficultés à corréler les résultats de débogage entre les deux environnements.
• Coût du débogage : Identifier la racine d'une défaillance au niveau du système complet (SoC) et la remonter jusqu'au bloc IP spécifique (CPU, GPU ou NoC) est long et coûteux en ressources.

2. Méthodologie : Moteur de Replay (Replay Engine)

Pour surmonter ces obstacles, les auteurs proposent une méthodologie de validation pilotée par le rejeu (replay), reposant sur un moteur de capture et de rejeu déterministe.

• Concept Central : Au lieu de générer dynamiquement des stimuli via des BFM complexes au niveau du SoC, l'équipe capture les signaux d'interface exacts (données, contrôle, réponses) lors de la validation autonome du bloc IP GPU.
• Architecture du Moteur de Replay :
  • Capture : Des formes d'ondes temporellement précises sont capturées à la périphérie de l'IP GPU.
  • Conversion : Ces formes d'ondes sont traitées hors ligne pour extraire les signaux d'interface et les convertir en une représentation binaire ordonnée par cycle.
  • Initialisation ROM : Les données converties sont stockées dans des structures ROM au sein du moteur de replay.
  • Exécution : Lors de la simulation ou de l'émulation du SoC complet, le moteur lit ces ROM pour rejouer les requêtes et les réponses exactes observées précédemment, sans avoir besoin d'un agent de réponse actif (BFM) en temps réel.
• Avantage Clé : Cette approche permet d'utiliser une seule base de données de conception pour la simulation et l'émulation, éliminant la nécessité de maintenir des collatéraux de testbench différents pour chaque environnement.

3. Contributions Clés

• Unification Simulation/Émulation : La méthodologie permet d'exécuter les mêmes scénarios de charge de travail (démarrage du système, exécution de tâches GPU) avec un comportement déterministe identique sur les deux plateformes, en utilisant le même artefact de rejeu.
• Réduction de l'Overhead d'Intégration : En réutilisant les comportements de protocole validés lors de l'étape IP, l'équipe élimine le besoin de développer et de maintenir des modèles BFM complexes pour le niveau SoC, accélérant ainsi le « bring-up » du système.
• Débogage Déterministe : La capacité à rejouer exactement les mêmes séquences d'interface permet de reproduire systématiquement des échecs observés en émulation (où la visibilité interne est limitée) et de les analyser en détail en simulation.
• Validation de l'Architecture Chiplet : La méthode valide efficacement l'intégration du sous-système CPU Xeon, des cœurs GPU Xe et du NoC, en traitant les interfaces de chiplet comme des frontières de rejeu bien définies.

4. Résultats et Réalisations

• Accélération du Cycle de Validation : L'équipe a réussi à réaliser le démarrage complet du système (boot) et l'exécution de charges de travail GPU en un seul trimestre, un résultat significatif compte tenu de la complexité du design.
• Efficacité de l'Émulation : Le design complet (CPU-GPU-NoC) a été mappé avec succès sur la plateforme d'émulation EP1 (utilisant 16 cartes FPGA). Les ressources utilisées (LUT, RAM, REG) sont restées dans les limites de la capacité disponible, laissant une marge pour le débogage.
• Corrélation des Résultats : Les résultats de simulation et d'émulation ont été parfaitement corrélés, confirmant que le rejeu déterministe préserve la fidélité fonctionnelle tout en permettant une exécution à haute vitesse en émulation.
• Apprentissages Techniques :
  • La capture de formes d'ondes déterministes est cruciale pour la fiabilité du rejeu.
  • L'automatisation de l'injection de la logique de capture/rejeu a réduit les erreurs manuelles.
  • Des compromis ont été nécessaires, tels que la désactivation de la randomisation des bascules (flops) utilisée pour la validation de la métastabilité, afin d'assurer un comportement déterministe.

5. Signification et Impact

Cette étude démontre que la validation pilotée par le rejeu est une méthodologie évolutive et indispensable pour les architectures SoC hétérogènes complexes de nouvelle génération (type chiplet).

• Évolutivité : Elle offre un cadre de validation pratique qui s'adapte à la complexité croissante des systèmes, en permettant une vérification précise au niveau des interfaces de sous-systèmes et de chiplets.
• Confiance Intégration : En réduisant le temps de débogage et en éliminant les divergences entre simulation et émulation, cette approche augmente considérablement la confiance dans l'intégration pré-silicium.
• Modèle Reproductible : La capacité à capturer, convertir et rejouer des interactions de protocole complexes offre une solution robuste pour les défis de validation liés aux architectures CPU-GPU couplées, devenant un standard potentiel pour les futures générations de puces Intel et d'autres fondeurs.

En résumé, l'article présente une avancée méthodologique majeure qui transforme la validation des systèmes complexes en passant d'une approche basée sur la génération de stimuli dynamiques (souvent fragile et coûteuse) à une approche basée sur la reproduction déterministe de comportements validés, garantissant ainsi une intégration plus rapide et plus fiable.