Initiation à la modélisation et co-simulation comportementale
publicité
MIGREST Initiation à la modélisation et co-simulation comportementale C-VHDL d’un réseau de communication sur Puce (Network on Chip) C. Tanougast1, S. Jovanovic2, F. Monteiro1, C. Diou1, A. Dandache1 1 Laboratoire des Interfaces Capteurs et Microélectronique (L.I.C.M.) Université Paul Verlaine de Metz, LICM-ISEA, 7 rue Marconi, 57070 Metz Technopole 2 Université Henri Poincaré – Nancy Université, BP 239, 54506 Vandœuvre-Les-Nancy Email : [email protected] 1. INTRODUCTION ET CONTEXTE Cet article présente un projet pédagogique d’initiation à la modélisation et simulation comportementale d’un réseau de communication sur puce (NoC - Network on Chip) [1], mené avec les étudiants de master 2 parcours RSEE (Radiocommunication et Systèmes Electronique Embarqués) de l’Université Paul Verlaine de Metz. Etant donné l’évolution rapide et de plus en plus complexe des systèmes sur puce (SoC - System On Chip) vers des systèmes sur puce multi-processeurs (MPSoC - Multiprocessors SoC), l’interconnexion de communication des modules ou cœurs (IP - Intellectual Property) constituant ces systèmes, a subit une évolution topologique et structurelle. Cette dernière répond à des contraintes de performance et de coût liées à la complexité et à l’augmentation croissante des modules ou IPs interconnectés. Actuellement cette évolution s’oriente vers l’intégration d’un réseau de communication sur puce, mettant en œuvre la transmission des données par paquets vers les nœuds interconnectés au réseau et correspondant aux modules ou IPs (processeurs, mémoires, contrôleurs de périphériques reliés, etc.) (Figure 1). Cette transmission est réalisée à travers des routeurs constituant le réseau et mettant en œuvre des règles d’aiguillage et de routage des paquets à travers le réseau [1]. C’est dans ce contexte que nous proposons aux étudiants de RSEE un projet d’initiation à la modélisation et à la co-simulation C-VHDL comportementale d’un NoC à l’aide de l’outil Modelsim de MentorGraphics [2]. Connexions P2P 1990 Bus partagé 1995 Bus partagé hiérarchique Bus Matrice (Bus Crossbar) Network on Chip 2000 2005 2010 ? Temps Figure 1. Evolution des interconnectes dans les Systèmes sur Puce. 2. MODELISATION ET DESCRIPTION D’UN NoC ET DE SON ENVIRONNEMENT 2. 1. Etude de cas : Modélisation d’un NoC de type MESH avec routage X-Y. Nous proposons aux étudiants de modéliser un NoC par aiguillage de paquets de données constituant un message (switching packets), de topologie Mesh et de taille paramétrable (3x3, 6x6 et 10x10) avec des règles d’aiguillage de type Wormhole (Wormhole switching) et selon l’algorithme de routage standard X-Y [1]. La figure 2 illustre le type de réseau proposé aux étudiants. Il s’agit d’une matrice de routeurs intégrés associés chacun à un noeud de calcul modélisé par un processeur PE (Processor Element). Chaque couple PE –routeur possède une adresse spécifique et peut émettre des messages. Ces messages sont partitionnés en paquets de données de taille fixe. Chaque paquet est constitué de flits (flow control units) correspondant à des mots de données de taille fixe. On définit également la notion de Phits (physical units) correspondant à l’unité d’information pouvant être émis à travers les canaux physiques du réseau en un seul cycle. A. Modélisation VHDL Comportementale d’un Routeur Les étudiants sont amenés à modéliser, à l’aide d’une description VDHL comportementale, un routeur NoC de paquets de données constitué de 5 flits. La taille d’un phit correspondant à la taille des canaux et entrées des P5 MIGREST buffers d’un routeur est égale à la taille d’un flit. Les spécifications d’un routeur sont alors décrites de la façon suivante : - Routeur de paquets de données de 5 flits de taille 9 bits (5x 9 bits). - Canaux de données de taille 9 bits (taille d’un phit). - Un buffer à chaque entrée de direction de profondeur 2 flits (2 x 9 bits). - Cellule interne d’aiguillage du routeur (Switch) de type Crossbar. - Quatre directions de transfert de données (Est, Ouest, Sud et Nord). - Algorithme de routage déterministe de type X_Y. - Règle d’aiguillage de type Wormhole : la connexion entre une entrée et une sortie de direction d’un routeur est maintenu jusqu’à ce que tous les données élémentaires (flits) d’un paquet de message sont envoyés. X N N N N Y R R 00 N R R R N0 R N R N1 2N 22 N N R R 21 N N R 20 1N 12 N N R R 11 N N R 10 0N 02 N N R R 01 R R N2 NN Routeur d’adresse i, j ij N Nœud = module (processeur, IPs, mémoire, etc.) Figure 2. Structure du NoCs de type Mesh NxN. La figure 3 donne une description de la spécification d’un routeur NoC. La modélisation globale du réseau s’effectue ensuite par une description structurelle VHDL réalisée par des instanciations du module routeur en vue d’élaborer un réseau NoC de taille paramétrable 3x3, 6x 6 et 10x 10 (figure 2). B. Algorithme de routage L’algorithme proposé aux étudiants est un algorithme de routage statique de type X_Y signifiant que les paquets de données sont dirigés vers le PE destinateur à travers les routeurs du réseau selon d’abord l’axe des abscisses X du réseau, puis selon son axe des ordonnées Y. La modélisation de l’algorithme de routage X_Y est réalisée en VHDL selon l’algorithme suivant : - If X_routeur < X_destination, direction paquets = Direction_Est - If X_routeur > X_destination, direction paquets = Direction_Ouest - If X_routeur = X_destination et Y_router > Y_ destination, direction paquets = Direction_Sud - If If X_routeur = X_destination et Y_router < Y_ destination, direction paquets = Direction_Nord - If If X_routeur = X_destination et Y_router = Y_ destination, direction paquets = Local_PE P5 MIGREST PE Direction_Nord Pe_out Pe_in Buffers Buffers Direction_Ouest Direction_Est Switch - Crossbar Buffers Buffers Routage Arbitre Direction_Sud Figure 3. Illustration du model structurel d’un Routeur NoC. La figure 4 illustre l’algorithme de routage X_Y d’un paquet entre les PE_00 et PE_22. Une mauvaise description de cet algorithme peut faire apparaître au cours de la simulation du NoC des interblocages (Deadlock) ou des bouclages (Livelock) de paquets [1]. PE Add_00 Add_10 Add_20 Add_01 Add_02 Add_11 Add_12 Add_21 Add_03 Add_13 Add_22 Add_23 PE Add_30 Add_31 Add_32 Add_33 Figure 4. Illustration de l’algorithme X_Y. C. Police d’arbitrage L’élaboration des règles d’arbitrage de priorité de l’ordre de traitement des paquets entrant dans un routeur et routés selon les sorties de direction, est laissée à l’initiative des étudiants. Ces règles doivent être associées à l’algorithme de routage, au nombre de flits constituant les paquets et aux règles d’aiguillage Wormhole. L’objectif est d’amener les étudiants à une description itérative progressive du module de routage et d’arbitrage au fur et à mesure des phases de modélisation – simulation mettant en évidence les phénomènes de blocage temporaire, de verrouillage (starvation) et leurs impacts sur la notion de latence de transfert de paquets de données. 2. 2. Co-Simulation sous environnement ModelSim A partir d’une description en langage C modélisant l’envoi et la réception de paquets de données par l’ensemble des PEs associés à chaque routeur du NoC, les étudiants réalisent une modélisation comportementale VHDL détaillée d’un NoC (routeurs, contrôleurs de flux données, etc.) et une validation par co-simulation C-VHDL P5 MIGREST grâce à l’interfaçage VHDL FLI (Foreign Language Interface) de ModelSim [3]. La modélisation et la simulation du réseau NoC développé par les étudiants sont assurées par la description structurelle VHDL du réseau associée à une modélisation en langage C/C++ de l’ensemble des PEs du réseau assurant les émissions et les réceptions des paquets de données. La figure 5 illustre l’interfaçage et l’association d’une co-simulation sous environnement ModelSim. A partir des fichiers contenant les paquets de données à transmettre par des PE émetteurs vers PEs destinataires, un interfaçage entre la description VHDL du NoC et le model C/C++ des fonctionnalités d’émission et de réception de paquets par chaque PE est exécuté sous ModelSim. Réception de paquets de données par PEs Emission de paquets de données par PEs PEoo PE01 Add_00 Add_0j Add_i0 Add_ij PE0i PE10 PEij PEs.C PEs.vhd Testbench.vhd NoC.vhd ModelSim Figure 5. Illustration de la co-simulation C-VHDL sous ModelSim. En pratique, le model abstrait des PEs est mis en œuvre à travers une compilation DLL de la modélisation C/C++ des PEs. Cette dernière est ensuite définie comme la partie « architecture» de la description VHDL des PEs du NoC sous ModelSim. La figure 6 montre l’intégration de fonctionnalité abstrait C/C++ dans la partie « architecture » de la description VHDL des PEs du NoC. Figure 6. Attribution FLI d’un model abstrait par DLL dans une description VHDL. La figure 7 présente le contenu d’un fichier associé à un PE et contenant les paquets (constitués de 5 flits) à transmettre. Le premier flit correspond à l’adresse du PE émetteur, le second flit à l’adresse du PE destinataire suivi ensuite des flits de données à transmettre. Figure 7. Exemple de paquets de données à transmettre par le PE d’adresse 00. P5 MIGREST Au cours des phases de co-simulation, les étudiants sont sensibilisés aux risques d’interblocage (Deadlock), de bouclage (Livelock) et de verrouillage (Starvation) des paquets de données dans un NoC [1]. Ces risques sont principalement dus au partage de ressources limitées et aux règles d’accès à ces ressources. Ils sont couramment étudiés et analysés dans le développement d’un NoC adapté pour la conception d’un MPSoC spécifique. Les Figures 8 et 9 donnent respectivement des exemples de résultat de co-simulation sous ModelSim. La figure 8 présente un aiguillage Wormhole d’un paquet de données selon le routage X_Y. La figure 9 montre la réception d’un paquet de données par un PE du NoC. Figure 8. Exemple de résultat de simulation de l’aiguillage Wormhole d’un paquet selon X_Y. Figure 9. Exemple de simulation de réception d’un paquet données par le PE_54. Cette co-simulation permet une validation accélérée comportementale du NoC tout en mettant en évidence sa caractérisation à travers les notions de latence et de débit de données. La figure 10 montre un exemple des P5 MIGREST résultats de temps de latence en nombre de cycle des paquets transmis dans le NoC par un PE émetteur vers des PE_destinataires. Figure 10. Latences simulées en nombre de cycle d’horloge des paquets transmis par le PE_00. 3. CONCLUSION Cet enseignement propose de modéliser, de simuler et d’évaluer l’architecture d’un réseau de communication sur puce à l’aide d’une co-simulation C-VHDL avec l’outil Modelsim. Il permet de sensibiliser les étudiants au rôle fondamental des interconnectes sur les performances attendues d’un MPSoC lors de sa conception. La modélisation des transactions des paquets de données est réalisée en C/C++ ce qui permet une simulation rapide nécessaire pour vérifier les fonctionnalités et les performances d’un réseau de communication sur puce pour des systèmes intégrés complexes tandis que les modules du NoC à réaliser sont décrits en VHDL en vue d’une description synthétisable sur une technologie donnée. L’objectif de cet enseignement est d’une part de sensibiliser les étudiants sur les phases de développement et de conception microélectronique de l’interconnecte, constituant l’élément clé des performances d’un MPSoC. D’autre part, de montrer l’intérêt d’utiliser des outils tel que ModelSim permettant une co-simulation dans le but de simuler et de valider une architecture dans son contexte environnemental de fonctionnement. Cet enseignement est complémentaire à l’enseignement de modélisation de système haut niveau à partir d’un langage tel que SystemC. En effet, il compléter l’enseignement de la conception microélectronique en présentant des outils permettant d’accélérer les phases de développement de systèmes qui deviennent de plus en plus complexes par l’intégration à la fois de parties matérielles et logicielles. BIBLIOGRAPHIE [1] G. De Micheli et L. Benini, « Networks on Chips, Technology and tools », Morgan Kaufmann publishers, 2006. [2] Mentor Graphics, « Modelsim SE User’s Manuel, Sofware, Version 6. 4 », 2008. http://www.mentor.com/. [3] Mentor Graphic, « ModelSim, Foreign Language Interface, version 5.6d », August 2002. P5
