Ht Pour Tsar V0.6

ECOLE POLYTECHNIQUE PROMOTION 2006 LE GRAND Etienne

RAPPORT DE STAGE DE RECHERCHE

Traitement des entrées sorties dans l’architecture extensible du processeur multi-cœur TSAR Hypertransport pour TSAR v0.6, juillet 2009

NON CONFIDENTIEL

Option : Physique - Informatique Champ de l'option : Semi-conducteurs et composants Directeur de l'option : Yvan Bonnassieux Directeur de stage : Alain Greiner Dates du stage : 06/04/2009 – 31/07/2009 Adresse de l'organisme : UNIVERSITE PIERRE ET MARIE CURIE Laboratoire d’Informatique de Paris 6 Section System On Chip Maison de la pédagogie, 4 place Jussieu 75005 PARIS, FRANCE

Hypertransport pour TSAR, v0.6

2

Rapport de stage de recherche

Etienne Le Grand

Résumé Alors que les performances des processeurs mono-cœurs semblent plafonner, les fabricants de processeurs grand public s’engagent dans la voie des multi-cœurs. Le projet européen de processeur massivement multi-cœur scalable TSAR vise à profiter du bouleversement du marché de l’électronique pour y faire une place aux industries européennes. Pour ce faire, le processeur TSAR doit être compatible PC, et idéalement être utilisable dans les cartes mères présentes dans le commerce. Le problème se pose donc de la communication du processeur avec les périphériques extérieurs. Après avoir étudié les architectures PC actuelles, nous choisissons de recourir au protocole ouvert Hypertransport Gen1 pour profiter des composants existants. Nous déterminons alors les modifications à apporter à l’architecture TSAR pour y intégrer un module de communication entrées/sorties. Celui-ci effectue la traduction entre le protocole interne et le protocole externe à TSAR et gère le lien physique transportant les informations au format Hypertransport. Un bridge VCI-Hypertransport assurant la traduction de protocole est conçu et implémenté dans le langage de prototypage virtuel SystemC. Il est adapté aux composants internes à TSAR. Son fonctionnement est démontré dans plusieurs environnements synthétiques. Son code synthétisable reste à écrire et ne pourra être testé correctement qu’en interaction avec une carte mère.

Abstract While performances of mono-core processors seem to level, large scale processors manufacturers step into multi-core designs. The European project of scalable massively multicore processor TSAR aims at taking advantage of the changing market to give European industries a role to play. To that end, the processor TSAR has to be IBM PC compatible (Wintel) and ideally pluggable into the released motherboards. That brings the problem of the communication between the processor and the external peripherals. After studying the state of the art PC architectures, we choose to have recourse to the open Gen1 Hypertransport protocol in order to take the most of the existing devices. We determine then how to modify TSAR’s architecture to integrate to it an input/output communication module. This one deals with the protocol translation between the inside and the outside of TSAR and manages the physical link that transports the Hypertransport packets. A VCI-Hypertransport bridge that handles the protocol translation is designed and implemented in SystemC virtual prototyping language. It is adjusted to fit to the internal components of TSAR. Its behaviour is demonstrated in a set of synthetic testing environments. Its synthesizable code is yet to be written and could not be correctly tested unless in interaction with a motherboard.

3

Hypertransport pour TSAR, v0.6

Sommaire 1

PROJET TSAR........................................................................................... 10 1.1 1.1.1

La course a la puissance de calcul : des mono-cœurs aux multi-cœurs........................................ 10

1.1.2

Outils développés .......................................................................................................................... 10

1.1.3

Marché bientôt énorme, un futur des FPGA et ASIC .................................................................... 10

1.1.4

Projets multi-cœurs existants ........................................................................................................ 11

1.1.5

Se positionner pour le futur........................................................................................................... 11

1.2

Mer de cœurs de processeurs ........................................................................................................ 11

1.2.2

Interconnect, architecture NUMA GALS ...................................................................................... 11

1.2.3

Mécanismes de cohérence............................................................................................................. 12

Projet............................................................................................................................................. 13

1.3.2

Disponibilité du design.................................................................................................................. 13

1.3.3

Utilisation du standard VCI .......................................................................................................... 13

ETAPES DU PROJET .................................................................................................. 14

1.4.1

Modélisation SystemC : Prototypage virtuel................................................................................. 14

1.4.2

Synthese VHDL pour FPGA : Prototypage physique.................................................................... 14

1.4.3

Architecture finale......................................................................................................................... 15

TSAR COMPATIBLE PC......................................................................... 15 2.1

CAHIER DES CHARGES ............................................................................................. 15

2.1.1

Besoin de traitement des entrés/sorties ......................................................................................... 15

2.1.2

Travail demandé............................................................................................................................ 15

2.2

SOLUTIONS EXISTANTES .......................................................................................... 16

2.2.1

Architecture I/O traditionnelle...................................................................................................... 16

2.2.2

Architecture adoptée par AMD® pour ses multi-cœurs................................................................. 17

2.3

SOLUTION ADOPTEE................................................................................................. 18

2.3.1

Utilisation des composants existants............................................................................................. 18

2.3.2

Architecture adoptée ..................................................................................................................... 18

PROTOCOLE HYPERTRANSPORT..................................................... 19 3.1

4

SOCLIB ..................................................................................................................... 13

1.3.1

1.4

3

ARCHITECTURE SCALABLE CLUSTERISEE............................................................... 11

1.2.1

1.3

2

CONTEXTE TECHNOLOGIQUE DU PROJET ............................................................... 10

GENERATIONS, PARAMETRES ET PERFORMANCES ................................................. 19

Rapport de stage de recherche 3.1.1

Différentes générations ................................................................................................................. 19

3.1.2

Choix de la génération .................................................................................................................. 19

3.1.3

Largeur du lien.............................................................................................................................. 19

3.2

Signaux de support........................................................................................................................ 20

3.2.2

Signaux de lien .............................................................................................................................. 20

PAQUETS .................................................................................................................. 21

3.3.1

Headers information ..................................................................................................................... 21

3.3.2

Headers commande ....................................................................................................................... 22

3.3.3

Headers réponse............................................................................................................................ 23

3.3.4

Données......................................................................................................................................... 23

3.4

CANAUX VIRTUELS................................................................................................... 24

3.5

RESEAUX HYPERTRANSPORT .................................................................................. 24

3.5.1

Chaines.......................................................................................................................................... 24

3.5.2

Interfaces....................................................................................................................................... 24

3.5.3

Transactions.................................................................................................................................. 25

CLUSTER HYPERTRANSPORT ........................................................... 26 4.1

COMPOSITION DU CLUSTER ..................................................................................... 26

4.1.1

Interface hôte Hypertransport....................................................................................................... 26

4.1.2

Bridge Hypertransport .................................................................................................................. 27

4.1.3

Input Output Memory Management Unit (IO MMU).................................................................... 27

4.1.4

Gestionnaire de Bridge ................................................................................................................. 28

4.2

5

SIGNAUX ................................................................................................................... 20

3.2.1

3.3

4

Etienne Le Grand

ADRESSAGE DU CLUSTER HYPERTRANSPORT ......................................................... 28

4.2.1

Correspondance Cluster-Espace mémoire.................................................................................... 28

4.2.2

Besoins particuliers du cluster Hypertransport ............................................................................ 28

4.2.3

Nouvelle règle de routage ............................................................................................................. 29

BRIDGE HYPERTRANSPORT .............................................................. 30 5.1

STRUCTURE ET INTERFACES .................................................................................... 30

5.2

COMMAND OUT RESPONSE IN (CORI)................................................................... 31

5.2.1

Transactions sortantes .................................................................................................................. 31

5.2.2

Command Out (CO) ...................................................................................................................... 31

5.2.3

Response In (RI)............................................................................................................................ 34

5.3

COMMAND IN RESPONSE OUT (CIRO)................................................................... 35

5.3.1

Transactions entrantes .................................................................................................................. 35

5.3.2

Command In (CI) .......................................................................................................................... 36

5

Hypertransport pour TSAR, v0.6 5.3.3

6

DISPOSITIFS DE TEST ........................................................................... 38 6.1

TEST PAR REBOUCLAGE VCI-HT->HT-VCI ......................................................... 39

6.1.1

Principe......................................................................................................................................... 39

6.1.2

Plateforme simple processeur-RAM.............................................................................................. 39

6.1.3

Plateforme TSAR V0...................................................................................................................... 40

6.2

UTILISATION D’INITIATEURS VCI ET HT SYNTHETIQUES ..................................... 40

6.2.1

Besoin............................................................................................................................................ 40

6.2.2

Fichier de commandes .................................................................................................................. 41

6.2.3

Automatisation des tests et résultats ............................................................................................. 41

6.3

6

Response Out (RO)........................................................................................................................ 37

TESTS SUR FPGA..................................................................................................... 42

6.3.1

Ecriture du code VHDL................................................................................................................. 42

6.3.2

Test sans interface Hypertransport ............................................................................................... 42

6.3.3

Connexion à l’interface hôte conçue par l’université de Heidelberg............................................ 42

Rapport de stage de recherche

Etienne Le Grand

Liste des figures Figure 1 Architecture scalable clustérisée................................................................................ 12 Figure 2 Interface VCI ............................................................................................................. 14 Figure 3 FPGA Altera® Stratix III sur plateforme de prototypage DE3 .................................. 15 Figure 4 Architecture traditionnelle ......................................................................................... 16 Figure 5 Architecture AMD ..................................................................................................... 17 Figure 6 Architecture adoptée .................................................................................................. 18 Figure 7 Largeur et fréquence possibles .................................................................................. 19 Figure 8 Signaux de lien (supérieurs) et de support................................................................. 20 Figure 9 Headers et données formant les paquets .................................................................... 21 Figure 10 Multiplexage des 3 canaux virtuels sur le lien physique ......................................... 24 Figure 11 Composants Hypertransport et leurs interfaces ....................................................... 25 Figure 12 Les trois types de transactions Hypertransport ........................................................ 25 Figure 13 Cluster Hypertransport au sein du processeur TSAR .............................................. 26 Figure 14 Interface Hypertransport (Modèle de l'Université de Heidelberg) .......................... 27 Figure 15 Sémantique des adresses TSAR............................................................................... 28 Figure 16 Sémantique des adresses entrées/sortie.................................................................... 29 Figure 17 Routage vers les clusters Hypertransport (oranges) ................................................ 29 Figure 18 Structure et interfaces du bridge Hypertransport (fifos de contrôles et de données regroupées) ............................................................................................................................... 30 Figure 19 Champs des paquets VCI (paramètres utilisés dans TSAR) et HT.......................... 30 Figure 20 Traduction des transactions sortantes ...................................................................... 31 Figure 21 Communications internes au bloc CO ..................................................................... 32 Figure 22 Segments importants de l'espace adressable Hypertransport................................... 32 Figure 23 Mécanisme de traduction d'adresse VCI vers Hypertransport................................. 33 Figure 24 Communications internes au bloc RI....................................................................... 34 Figure 25 Traduction transactions entrantes ............................................................................ 35 Figure 26 Communications internes au bloc CI...................................................................... 36 Figure 27 Format des identifiants VCI pour un cluster XY et un cluster IO ........................... 36 Figure 28 Communications internes au bloc RO .................................................................... 37 Figure 29 Plateforme de test par rebouclage VCI-HT -> HT-VCI .......................................... 39 Figure 30 Plateforme simple de test et résultat ........................................................................ 39 Figure 31 Plateforme de test multi-initiateur multi-cible pour le bloc CORI .......................... 40 7

Hypertransport pour TSAR, v0.6

8

Rapport de stage de recherche

Etienne Le Grand

Remerciements Je souhaite remercier l’équipe TSAR du LIP6 pour son accueil et son soutien tout au long de mon stage. Je remercie avec une attention toute particulière mon tuteur de stage, le professeur Alain Greiner pour avoir été si présent et disponible. Merci également à Manuel Bouyer, Nicolas Poullion, Ghassan Almaless, Franck Wajsbürt, Abdelmalek Si-Merabet et Eric Guthmuller pour leurs contributions aux discussions concernant l’intégration d’Hypertransport à TSAR. Ce stage n’aurait pas été réalisable en 4 mois sans les réponses rapides qu’ils ont été capables d’apporter à mes interrogations.

Introduction De début avril à fin juillet 2009, j’effectue un stage de recherche à l’Université Pierre et Marie Curie. Je travaille au sein de l’équipe TSAR, section du département de System on Chip du Laboratoire d’Informatique de Paris 6 (LIP6). Ce stage a une grande envergure puisqu’il m’a amené à découvrir en détail une architecture de processeur multi-cœur ainsi que l’état de l’art de l’architecture des ordinateurs, puis à confronter ces deux technologies afin de les faire concorder. Cette confrontation m’a d’ailleurs amené à remettre en cause certains choix stratégiques de l’architecture du processeur multi-cœur. Ce rapport de stage est élaboré dans le but d’être accessible aux personnes ne disposant pas d’expertise dans le domaine de l’Hypertransport ou des processeurs multi-cœurs scalables, tout en introduisant les détails nécessaires à la compréhension du fonctionnement du composant conçu : un bridge VCIHypertransport. Il expose les problématiques traitées durant le stage et constitue un bon point de départ pour celui qui poursuivra le développement du module entrées/sorties du processeur TSAR.

9

Hypertransport pour TSAR, v0.6

1 Projet TSAR 1.1 Contexte technologique du projet 1.1.1 La course a la puissance de calcul : des mono-cœurs aux multicœurs L’informatique a permis des progrès technologiques et scientifiques considérables grâce à la puissance de calcul qu’elle a apporté. Les processeurs sont au cœur de tous les ordinateurs personnels, stations de travail ou serveurs. Ils sont les acteurs principaux de cette révolution, et ont eux-mêmes suivi une évolution impressionnante, suivant la célèbre loi de Moore. Depuis l’invention du microprocesseur, cette course à la puissance de calcul a grandement reposé sur l’amélioration des techniques de fonderie des circuits intégrés, en particulier la diminution de la taille des transistors. Cette miniaturisation a permis d’augmenter la fréquence de fonctionnement des circuits ainsi que leur complexité avec l’invention des processeurs super-scalaires capables d’exécuter plusieurs opérations élémentaires à la fois. Aujourd’hui, la physique nous indique que l’on atteint les limites de ces méthodes. Il ne sera bientôt plus possible d’augmenter la cadence des circuits électroniques, du moins pas avec les technologies actuelles. Pour ne pas cesser la course à la puissance et pour continuer à suivre la loi de Moore, les constructeurs développent des processeurs multi-cœurs. Comme il ne sera rapidement plus envisageable d’augmenter sensiblement la puissance des cœurs de calcul, c’est l’augmentation de leur nombre qui compensera la stagnation des fréquences.

1.1.2 Outils développés La programmation parallèle était jusqu’à récemment réservée aux applications scientifiques ayant un tel besoin de puissance de calcul qu’elles nécessitaient la mise en parallèle de plusieurs processeurs. Il s’agissait d’un mode de programmation lourd avec relativement peu d’outils de développement en comparaison à la gamme d’outils utilisés dans les communautés traditionnelles de développeurs. Pour profiter de la puissance de calcul parallèle des processeurs multi-cœurs maintenant présents dans les PC, les habitudes de programmation changent, et les outils de développement avec. Tout laisse à penser que la programmation parallèle va s’imposer comme une norme dans le futur, non seulement pour les applications nécessitant une grande quantité de calcul, mais aussi sur les plateformes PC.

1.1.3 Marché bientôt énorme, un futur des FPGA et ASIC Le marché des processeurs multi-cœurs englobera bientôt celui des ordinateurs personnels, des stations de travail et des serveurs. Ce marché s’agrandira peut être même bien au-delà du monde du PC. Etant donné le prix des jeux de masques nécessaires à la mise sur silicium des circuits intégrés, le coût de mise sur le marché des circuits intégrés spécialisés (ASIC, pour application specific integrated circuits) est énorme. Les circuits programmables de prototypage FPGA connaissent un grand succès car ils répondent au besoin de flexibilité, d’efficacité et d’accessibilité que les concepteurs de circuits électroniques éprouvent. Les architectures multi-cœurs scalables pourront peut être elles aussi répondre à ces besoins et s’emparer d’une bonne part de marché.

10

Rapport de stage de recherche

Etienne Le Grand

1.1.4 Projets multi-cœurs existants Il existe de nombreux projets d’architectures massivement scalables. Pour n’en citer que deux, Tilera® a développé un processeur 64 cœurs et le commercialise sous le nom de Tile64™. Intel® a quant à lui testé un prototype de processeur à 80 cœurs, fournissant une puissance supérieure au TeraFLOPS. En plus de la grande capacité de calcul qu’offrent ces architectures, leurs concepteurs vantent leur faible consommation, conséquence de la simplification des cœurs utilisés ou de la mise en veille des cœurs lorsque ceux-ci n’ont pas d’instructions à exécuter.

1.1.5 Se positionner pour le futur Le projet TSAR et ses successeurs offrent à l’Europe une opportunité de profiter de la révolution en marche pour se positionner sur le marché de l’électronique sous la nouvelle forme qu’il revêtira après son évolution.

1.2 Architecture scalable clustérisée 1.2.1 Mer de cœurs de processeurs TSAR est une architecture de processeur multi-cœur scalable clustérisée, que l’on peut décrire comme une mer de cœurs de processeurs. La puce finale doit posséder 4096 cœurs regroupés en 32x32 clusters de 4 cœurs. Afin d’augmenter la flexibilité du design, l’architecture est conçue de manière à pouvoir associer différents types de cœurs de processeurs. Ainsi, quels que soient les besoins de calcul ou de traitement de signal d’une application, celle-là pourra s’exécuter sur la plateforme en utilisant les cœurs de processeurs répondant à ses besoins. Le but étant de couvrir la plus large gamme d’applications électroniques nécessitant normalement la conception d’un ASIC ou le recours à un FPGA. Cette diversification des capacités de calcul permet une utilisation efficace des ressources, donc une faible consommation. Cette importante puissance de calcul à faible consommation est chère aux systèmes embarqués. Le processeur de référence du projet est le MIPS32, mais des PPC405, SPARC V8 ou ARM7 peuvent tout aussi bien être utilisés sur la plateforme presque sans y apporter de modifications.

1.2.2 Interconnect, architecture NUMA GALS 1.2.2.1 Besoin de débit Dans une application classique, les lectures mémoire représentent 20% des instructions exécutées et les écritures 10%. Avec 4096 cœurs de processeur, on s’attend donc à un débit de l’ordre de 100 écritures par cycle. Une connexion des processeurs à la mémoire par un bus, comme c’est le cas dans la majorité des processeurs multi-cœurs du commerce n’est donc pas envisageable. A la place, on utilise un réseau embarqué DSPIN reliant selon une topologie de grille 2D les 1024 clusters de 4 cœurs de processeur. La bande passante totale de ce type de réseau augmente proportionnellement au nombre de nœuds du réseau (1024 dans notre cas). Cette propriété rend l’architecture scalable en supprimant le goulot d’étranglement que représente le bus.

11

Hypertransport pour TSAR, v0.6

Figure 1 Architecture scalable clustérisée

1.2.2.2 Distribution de la mémoire, Non Uniform Memory Access TSAR est une architecture 40bit, ce qui signifie que les adresses physiques y sont codées sur 40 bit. L’espace adressable est donc de 240octets = 1To et contient les registres des composants internes à TSAR, les registres des périphériques externes et la mémoire externe RAM. L’espace physique est distribué sur le réseau en 1024 blocs de 1Go. Les bits de poids fort désignent les coordonnées du cluster auquel une adresse est attribuée, ce qui simplifie beaucoup le routage ainsi que le placement des processus sur les différents processeurs par le système d’exploitation. La mémoire étant distribuée, le temps d’accès à une case de la mémoire dépend de la position de l’initiateur de la demande et de la position du banc mémoire visé. Le temps d’accès à la mémoire n’est pas uniforme, TSAR est donc une architecture NUMA (Non Uniform Memory Access) 1.2.2.3 Architecture Globally Asynchronous, Locally Synchronous DSPIN étant un réseau asynchrone, chaque cluster possède sa propre horloge dont la fréquence peut être ajustée en fonction des besoins. L’architecture est dite Globalement Asynchrone, Localement Synchrone (GALS). Cela permet d’adapter localement la fréquence d’horloge pour diminuer la consommation. Cette séparation claire en différentes zones synchrones facilite également la visualisation des chaines longues dans les communications entre composants.

1.2.3 Mécanismes de cohérence Chaque cœur de processeur possède deux caches L1, un pour les instructions et un pour les données. Les données ou instructions utilisées récemment par chaque cœur sont recopiées dans ses caches et peuvent y être modifiées lors d’écritures mémoires. Par conséquent, sans mécanisme de cohérence, chaque cœur a une image différente de la mémoire. Or, pour profiter des outils de développement parallèle pour PC, tout doit être fait pour que les processus s’exécutant sur le processeur n’aient pas conscience de cette duplication de la mémoire. Dans les processeurs actuels possédant 2, 4, 8 ou 16 cœurs, la cohérence est généralement assurée par un mécanisme d’espionnage de bus. Les caches espionnent sur l’unique bus système les écritures mémoires. Ce mécanisme n’est pas utilisable dans notre cas, car les 12

Rapport de stage de recherche

Etienne Le Grand

écritures ne passent pas par un bus mais par un réseau 2D. En revanche, l’importante bande passante de ce réseau permet d’assurer la cohérence de la mémoire par un protocole de cohérence distribuée hybride. Il repose sur la présence dans chaque cluster d’un memorycache responsable de la tranche de mémoire RAM allouée au cluster. Chaque accès à la RAM passe par un des memorycache qui reporte les modifications aux caches des processeurs possédant la ligne de cache concernée. C’est ce mécanisme qui permet d’assurer la cohérence tout en gardant l’architecture scalable.

1.3 Soclib 1.3.1 Projet Le Laboratoire d’Informatique de Paris 6 est membre du projet SocLib qui regroupe 6 laboratoires académiques et 11 industriels. Ce projet vise à développer une librairie de prototypage virtuel codé en langage SystemC et dont les composants utilisent le protocole de communication Virtual Component Interface (VCI). Le langage SystemC permet de simuler sur ordinateur le comportement de composants électroniques et de plateformes comprenant plusieurs composants.

1.3.2 Disponibilité du design Le modèle SystemC de TSAR est disponible pendant sa phase de conception dans la librairie en ligne SocLib. Chacun de ses composants peut donc être utilisé au sein de plateformes autres que TSAR. La présence du modèle de TSAR dans cette librairie libre de droits permettra également aux développeurs intéressés par les possibilités qu’offre TSAR de simuler directement sur ordinateur l’exécution de leurs applications sur TSAR. Une communauté pourra donc facilement se créer autour du développement pour architecture TSAR. Ses membres viendront probablement dans un premier temps du monde de la programmation parallèle pour PC. Ils voudront donc profiter des outils développés dans leur domaine : les outils de programmation parallèle pour PC.

1.3.3 Utilisation du standard VCI Tous les composants internes de TSAR ainsi que tous les composants de la librairie SocLib utilisent le protocole de communication VCI. Ce choix permet la réutilisation des composants dans différents contextes. Ce protocole d’échange de paquets distingue les paquets commandes des paquets réponses. Il définit des interfaces initiateurs et cibles. Une transaction VCI débute par l’émission d’un paquet commande par l’initiateur. Ce paquet contient une adresse destinataire dont les bits de poids le plus fort définissent la cible et sont utilisés pour router le paquet jusqu’à elle. Il contient d’autres informations, dont l’identifiant de l’initiateur. Lorsque la cible reçoit le paquet commande, elle le traite en autant de temps que nécessaire et renvoie un paquet réponse en y recopiant l’identifiant de l’initiateur qui sera utilisé pour router la réponse jusqu’à l’initiateur. L’interface entre les composants est semblable à une interface FIFO : les paquets sont transférés lorsque des signaux « prêt à lire, prêt à écrire » sont positionnés de chaque côté du lien VCI. Les paquets commande et réponse sont acheminés de manière atomique via des canaux physiquement distincts afin d’éviter les inter-blocages. Un initiateur peut émettre plusieurs commandes à la fois. Dans ce cas, les réponses peuvent lui revenir dans le désordre. 13

Hypertransport pour TSAR, v0.6 Le protocole VCI utilisé dans TSAR définit 4 commandes : Read, Write, et deux demiopérations atomiques : Linked Load et Store Conditional.

Figure 2 Interface VCI

1.4 Etapes du projet 1.4.1 Modélisation SystemC : Prototypage virtuel La première étape du projet consiste à modéliser TSAR à l’aide du langage de prototypage virtuel SystemC. Il s’agit en fait de programmation C++ faisant usage d’une librairie SystemC, qui fournit des notions propres au hardware : styles de communication, temps, concurrence (opération en parallèle), réactivité à un stimulus et types de données. Le code SystemC écrit est exécutable ordinateur au sein d’un noyau de simulation. La modélisation permet donc de tester l’ensemble de la plateforme en la simulant sur ordinateur, tout en disposant d’importants moyens de débogage. Un tel modèle est appelé spécification exécutable. Lorsque l’on a recours au prototypage virtuel, il est facile d’utiliser des opérations impossibles à réaliser en électronique. Afin de s’assurer que le prototype virtuel simule bien le comportement d’un composant électronique réel, on adopte la convention d’écriture Cycle Accurate Bit Accurate(CABA). On décrit un composant par ses entrées, ses sorties et ses registres internes. On décrit ensuite chacun des automates qui caractérisent son comportement en écrivant leur fonction de transition et leur fonction de génération (de Moore ou de Mealy). En s’interdisant de changer plus d’une fois la valeur d’un registre dans ces fonctions, on s’assure qu’il sera possible d’écrire une description synthétisable du composant modélisé.

1.4.2 Synthese VHDL pour FPGA : Prototypage physique La seconde étape du projet consiste à utiliser un FPGA comme prototype physique de TSAR. Pour cela, on écrit le code VHDL des composants à partir de leur modèle SystemC. Ce code synthétisable permet de programmer le FPGA. On utilise les FPGA Altera® Stratix III, sur lesquels on souhaite dans un premier temps faire fonctionner à 50Mhz ou 100Mhz 4 clusters de 2 à 4 processeurs chacun. Les cartes de prototypage utilisées étant interconnectables, on 14

Rapport de stage de recherche

Etienne Le Grand

peut imaginer de futurs prototypes virtuels constitués de plusieurs FPGA comportant chacun quelques clusters, et dialoguant entre eux selon un protocole à établir. Les processeurs utilisés sur cette plateforme de démonstration seront des MIPS32.

Figure 3 FPGA Altera® Stratix III sur plateforme de prototypage DE3

1.4.3 Architecture finale L’étape finale du projet consiste à concevoir le circuit intégré TSAR en lui-même : l’architecture à fondre sur silicium. Elle comportera les 1024 clusters de 4 processeurs chacun. La puce aura la taille d’un processeur PC classique, et sera idéalement utilisable dans certains PC existants.

2 TSAR Compatible PC 2.1 Cahier des charges 2.1.1 Besoin de traitement des entrés/sorties Pour profiter des logiciels de développement parallèle pour PC, la puce TSAR doit être compatible PC. Elle doit donc communiquer avec les périphériques classiques d’un ordinateur, que ce soit via les cartes mères actuelles ou via une carte mère conçue pour l’occasion. La tâche est gigantesque de par le nombre de protocoles et le nombre de périphériques à gérer. C’est pourquoi nous n’avons pas la prétention de concevoir les interfaces vers chaque type de périphérique. On s’adaptera plutôt aux solutions déjà existantes en utilisant les composants du marché.

2.1.2 Travail demandé La première étape pour rendre TSAR compatible PC est d’étudier les solutions existantes d’architecture I/O. J’ai conduit ces recherches pendant la première partie de mon stage. Mon 15

Hypertransport pour TSAR, v0.6 travail a ensuite consisté à définir les modifications à apporter à l’architecture TSAR pour l’adapter à la solution choisie : le traitement des entrées/sorties par protocole Hypertransport.

2.2 Solutions existantes 2.2.1 Architecture I/O traditionnelle Les processeurs des PC traditionnels sont utilisés sur carte mère et dialoguent avec les périphériques externes et la mémoire via des composants de traduction de protocole : le northbridge et le southbridge. Dans cette situation, le processeur est connecté par le front side bus au northbridge, qui fait l’intermédiaire avec les entrées/sorties nécessitant un gros débit : la mémoire système, le ou les contrôleurs graphiques, et les périphériques PCIe®.

Figure 4 Architecture traditionnelle

Pour accéder aux périphériques nécessitant un débit plus modéré, les requêtes du processeur doivent passer par le northbridge puis le southbridge. Ce circuit implique des conversions de protocole qui augmentent la latence et réduisent le débit des transferts. De plus, dans le cas d’un système multi-cœur, des goulots d’étranglement se forment. Les requêtes des différents coeurs vers la mémoire ou les périphériques doivent toutes passer par le même front side bus, dont la bande passante devient critique. Que l’on ait un ou quatre cœurs de processeur, le débit du front side bus reste le même, ce qui a un impacte sur les performances du système.

16

Rapport de stage de recherche

Etienne Le Grand

2.2.2 Architecture adoptée par AMD® pour ses multi-cœurs 2.2.2.1 Réponse aux problèmes de scalabilité Pour parer aux problèmes de goulot d’étranglement et de haute latence, AMD® a adopté une nouvelle architecture pour ses serveurs multiprocesseurs. Ce fabricant fait le pari d’un protocole unique entre les processeurs et le chipset. Ainsi, il supprime le northbridge. Il n’y a plus de goulot d’étranglement, et comme il n’y a plus de conversions de protocole entre la puce processeur et l‘extérieur, la latence est diminuée. De plus, la mémoire est connectée directement aux processeurs, laissant plus de bande passante pour les périphériques d’un côté, et la mémoire de l’autre.

Figure 5 Architecture AMD

2.2.2.2 Protocole ouvert et soutenu Le protocole unique utilisé est l’Hypertransport, qui fut créé pour l’occasion et qui a le grand atout d’être bien documenté. Effectivement, comme AMD® a pour but de vendre ses processeurs, la firme souhaite que ceux-ci soient compatibles avec une large gamme de composants et de cartes mères. Elle a donc initié la création d’un consortium qui soutient le protocole Hypertransport : l’Hypertransport Consortium (HTC). Son rôle est de documenter la norme Hypertransport et de promouvoir son utilisation de manière à ce que les constructeurs de composants de carte mère développent rapidement des southbridges compatibles avec les nouveaux processeurs AMD®. En conséquence, la spécification du protocole Hypertransport est ouverte et détaillée. Des membres du consortium ont également publié des ouvrages pour aider les développeurs de composants électroniques à intégrer Hypertransport dans leurs produits.

17

Hypertransport pour TSAR, v0.6

2.3 Solution adoptée 2.3.1 Utilisation des composants existants La conception des southbridges demande un travail gigantesque que l’on ne peut pas se permettre de réaliser. Nous souhaitons au contraire profiter de la population de composants et de cartes mères compatibles avec le protocole Hypertransport. Pour ce faire, il faudra intégrer un module de communication Hypertransport à l’intérieur de TSAR. Ainsi, le processeur pourra s’intégrer dans une architecture Hypertransport.

2.3.2 Architecture adoptée TSAR sera connecté directement à la mémoire et communiquera avec les périphériques via un southbridge à l’aide du protocole Hypertransport. L’industriel Broadcom® fourni par exemple les composants HT1000™ et HT2000™, qui mis en parallèle, forment un southbridge complet. Ce southbridge assure la conversion entre Hypertransport et une grande partie des protocoles utilisés par les périphériques récents. Dans cette situation, il n’y a pas de conversion de protocole intermédiaire entre Hypertransport et les protocoles des périphériques externes.

Figure 6 Architecture adoptée

On retrouve ce schéma dans la situation où on insère TSAR à la place des processeurs présents dans les cartes mères conçues pour AMD®. On peut imaginer utiliser TSAR directement dans ces cartes mères. Si on le souhaite, le processeur peut également être connecté à un slot dit HTX®, sur lequel on peut insérer une carte HTX® de la même manière qu’on insère une carte PCI® dans un slot PCI®. Ces slots utilisent le protocole Hypertransport qui offre un débit énorme, suffisant par exemple pour qu’une carte HTX® possède un ou plusieurs coprocesseurs. On ne s’intéresse pas ici à cette possibilité. 18

Rapport de stage de recherche

Etienne Le Grand

3 Protocole Hypertransport Le consortium Hypertransport définit la spécification du protocole Hypertransport. Pour chaque génération du protocole, tous les points sont détaillés, tels que les signaux constituant les liens, les paquets transportant l’information, et les interfaces à partir desquelles les réseaux Hypertransport sont construits. Nous présentons ici brièvement le protocole Hypertransport, et invitons le lecteur à se reporter à la spécification officielle pour une description plus détaillée. Les éditions MindShare publient également un excellent ouvrage dont certaines illustrations sont utilisées pour cette présentation.

3.1 Générations, paramètres et performances 3.1.1 Différentes générations Il existe 3 générations d’ Hypertransport, croissantes en performances et en complexité. La 1ère génération (Gen1) accepte des débits allant de 200Mhz à 800Mhz. Elle intègre déjà un mécanisme de détection d’erreur par CRC. La 2ème génération (Gen2) accepte des débits allant de 200Mhz à 1400Mhz. Elle améliore entre autres la compatibilité avec le bus PCIe, mais est encore assez proche de la génération 1. La 3ème génération (Gen3) accepte des débits allant de 1200Mhz à 3200Mhz. Parmi d’autres évolutions, elle introduit le scrambling et la récupération d’horloge afin d’atteindre des débits plus élevés, permet le HotPlug et renforce la vérification d’intégrité des signaux par CRC.

3.1.2 Choix de la génération Le choix de la génération 1 pour notre application est principalement du à la complexité des autres générations. Le débit offert est déjà suffisant. Sur FPGA, la limitation de fréquence ne vient pas du lien Hypertransport mais de la fréquence d’utilisation du FPGA (on utiliserait une fréquence de 200Mhz pour Hypertransport). Sur silicium, Hypertransport ne sera toujours pas limitant si la fréquence du lien Hypertransport est égale à celle du réseau DSPIN.

3.1.3 Largeur du lien Une fois la génération choisie, il est possible d’adapter les performances du lien à nos besoins en modifiant sa largeur. Hypertransport supporte des liens d’une largeur de 2, 4, 8, 16 ou 32bit. Tous les liens de largeur d’au moins 8bit fonctionnent de la même manière, la différence entre ces liens n’apparaissant que dans l’étape de sérialisation/désérialisation.

Figure 7 Largeur et fréquence possibles

19

Hypertransport pour TSAR, v0.6

3.2 Signaux Hypertransport est un protocole de connexion point à point contrairement aux bus dont l’accès est partagé par plus de deux composants. Un lien Hypertransport est composé de deux groupes de signaux : les signaux de support et les signaux de lien.

Figure 8 Signaux de lien (supérieurs) et de support

3.2.1 Signaux de support Les signaux de support sont communs à tous les composants Hypertransport du réseau. Ils véhiculent des informations qui concernent tous les composants : présence de tension, fonctionnement ou mise en veille du réseau Hypertransport, reset. Il y a un signal par information, les informations ne sont donc pas multiplexées temporellement. Les signaux de support fonctionnent à faible fréquence.

3.2.2 Signaux de lien Les signaux de lien connectent directement deux composants Hypertransport et transportent les paquets. Il peut s’agir de paquets envoyé d’un composant à l’autre tout aussi bien que de paquets devant transiter par ce lien pour atteindre leur cible ailleurs dans le réseau. Chacun de ces signaux de lien est constitué d’une paire différentielle à faible voltage (LVDS). Cette technologie nécessite deux fils pour chaque signal, mais permet d’atteindre des débits de l’ordre de quelques gigahertz sur les distances nécessaires à relier des composants sur une carte mère. Il y a deux transferts par cycle d’horloge (technologie DDR) Tous les liens Hypertransport sont bidirectionnels et possèdent pour chaque direction : •

des signaux d’horloge (CLK, un seul dans la génération 1)

•

un signal de contrôles et données (CAD), le nombre de bit du signal CAD définit la largeur du lien

•

des signaux de sélection contrôle/données (CTL, un seul dans la génération 1) qui informent pour chaque envoi si l’information présente sur le signal CAD sont de nature contrôle ou données

Le nombre de broches d’une interface Hypertransport est bien supérieur à la largeur du lien. A titre d’exemple, un lien bidirectionnel Hypertransport de largeur 8bit nécessite 57 fils. 20

Rapport de stage de recherche

Etienne Le Grand

3.3 Paquets Hypertransport est un protocole d’échange de paquets dit en split transaction : une ou plusieurs commandes sont envoyées, les composants cibles de ces commandes effectuent les opérations demandées et peuvent répondre après un certain temps. Ainsi, il n’y a pas de blocage du lien entre la commande et la réponse. Un paquet est composé d’un header de contrôle suivi optionnellement de données. On distingue trois types de header de contrôle : les headers information, headers commande et headers réponse.

Figure 9 Headers et données formant les paquets

3.3.1 Headers information Il existe trois headers d’information : NOP, Synchronisation/Error, Extended Flow Control. Ils permettent des échanges d’informations de gestion de lien au niveau interfaces Hypertransport, qui sont les seules à les utiliser. •

Au niveau des liens, la gestion des flux de paquets Hypertransport est basée sur un système de crédits. L’interface émettrice ne peut envoyer un nouveau paquet que si elle dispose des crédits suffisants. Elle consomme des crédits lors de l’envoi d’un paquet et en regagne lorsqu’elle reçoit des paquets NOP que l’interface réceptrice lui envoie en signifiant quelle place s’est libérée dans ses buffers d’entrée. Les paquets NOP portent ce nom car lorsqu’aucun paquet n’est dans le buffer d’envoi d’une interface, celle-ci envoie des paquets NOP.

•

Lorsqu’une erreur de lien Hypertransport est détectée, ou lorsqu’une synchronisation est nécessaire, la séquence de synchronisation est initiée par l’envoi d’un paquet Synchronisation/Error, qui a la particularité d’être recevable même lorsque le lien est désynchronisé et que les autres paquets ne peuvent plus passer.

•

Dans certaines configurations d’Hypertransport, des paquets de contrôle de flux étendus peuvent être utilisés (Extended Flow Control). Nous ne nous y intéressons pas

21

Hypertransport pour TSAR, v0.6

3.3.2 Headers commande Un paquet requête Hypertransport débute toujours par un header commande qui contient les informations sur l’opération que la cible doit effectuer ainsi que des informations sur la manière de router le paquet. 3.3.2.1 Sized Read Il s’agit de la commande de lecture. On distingue les lectures en Byte ou en Dword. •

Les lectures en Byte permettent de lire une combinaison quelconque d’octets au sein d’un mot de 32bit. On appellera cette lecture une lecture masquée, puisqu’un masque est appliqué pour définir quels octets sont à lire.

•

Les lectures en Dword permettent de lire une série de mots de 32 bits. Une telle lecture ne peut pas être à cheval sur deux blocs de 64 octets alignés, sa longueur maximale est donc 16 mots, ce qui correspond à la lecture d’un bloc aligné de 64 octets.

Les lectures requièrent toujours une réponse 3.3.2.2 Read Modify Write Hypertransport supporte deux types d’opérations atomiques (Read Modify Write) •

Fetch & Add prend un argument. Cette commande renvoie la valeur présente à l’adresse indiquée puis l’incrémente de la quantité présente en argument et écrase l’ancienne valeur.

•

Compare & Swap prend deux arguments. Cette commande lit la valeur présente à l’adresse indiquée et la compare au premier argument. Si les deux valeurs sont égales elle écrit le deuxième argument à la place de la première valeur.

Les opérations atomiques requièrent toujours une réponse. 3.3.2.3 Non Posted Sized Write et Posted Sized Write Il s’agit des commandes d’écriture. Comme pour les lectures, il existe des écritures en Byte ou en Dword •

Les écritures en Byte permettent d’écrire une combinaison quelconque d’octets au sein d’un bloc de 32 octets alignés. On dit qu’il s’agit d’écritures masquées. Le masque est envoyé avant les données dans un mot de 32 bits, chaque bit correspondant à un octet du bloc de 32bit alignés.

•

Les écritures en Dword ne sont pas masquées. Tout comme les lectures en Dword, leur longueur peut aller jusqu’à 16 mots et elles ne doivent pas être à cheval sur deux blocs de 64 octets alignés.

Contrairement à VCI où tout paquet commande génère une réponse, Hypertransport définit des paquets ne nécessitant pas de réponse. Ils sont dits postés. Ainsi, les écritures, qu’elles soient Byte ou Dword, peuvent être postées ou Non Postées. Suivant le cas, elles génèreront ou non une réponse.

22

Rapport de stage de recherche

Etienne Le Grand

3.3.2.4 Autres headers commande Flush est utilisé pour s’assurer que toutes les commandes postées sont bien arrivées à destination, ce qui est utile en particulier si des écritures postées ont été envoyées. Lorsque ce paquet arrive à destination, une réponse est renvoyée. Le paquet Broadcast permet de diffuser une information sur tout le réseau. Il ne requiert pas de réponse. Fence définit une barrière entre deux groupes de paquets, de manière à assurer que leur ordre ne change pas pendant leur acheminement jusqu’à destination. On peut associer une extension d’adresse (Address Extension) à un autre header commande pour véhiculer les bits 63..40 de l’adresse dans les implémentations 64bits d’Hypertransport. Nous n’utiliserons pas cette possibilité puisque notre architecture ne supporte pas les adresses 64bit.

3.3.3 Headers réponse Il n’existe que deux headers réponse : Le header Read Response est utilisé pour introduire un paquet répondant à une lecture ou une opération atomique, et le header Target Done est utilisé dans les autres cas.

3.3.4 Données Les headers peuvent être suivis de données. C’est le cas dans toutes les commandes d’écriture et de lecture atomique, ainsi que tous les paquets Read Response. L’unité élémentaire de données est un mot de 32bit. Le nombre de données suivant un header est toujours indiqué dans le header. 3.3.4.1 Données de Write Les données de Write suivent un header Non Posted Write ou Posted Write. S’il s’agit d’une écriture masquée, alors la première donnée est le masque. Les données suivantes sont les mots (de 1 à 8) à écrire à partir de l’adresse indiquée. S’il s’agit d’une écriture non masquée, alors les données sont les mots (de 1 à 16) à écrire à partir de l’adresse indiquée. 3.3.4.2 Données de Fetch & Add Chaque paquet de Fetch & Add est associé à un Qword (deux mots de 32bit) qui est envoyé en données. Il s’agit de la quantité à ajouter à la valeur Qword lue à l’adresse indiquée. 3.3.4.3 Données de Compare & Swap Chaque paquet de Compare & Swap est associé à deux Qword (deux mots de 32bit) qui sont envoyés en données. Le premier Qword est comparé à la valeur présente à l’adresse indiquée, et si la comparaison réussi le deuxième Qword est écrit à l’adresse indiquée. 3.3.4.4 Données de Read Response Lorsqu’un composant reçoit une lecture, masquée ou non, il renvoie un paquet Read Response composé du header Read Response et d’autant de données que de mots lus : 1 pour une lecture masquée, et de 1 à 16 pour une lecture non masquée.

23

Hypertransport pour TSAR, v0.6

3.4 Canaux virtuels Pour éviter les inter-blocages, les paquets commande et réponse sont acheminés par des canaux différents. Les canaux sont virtualisés au niveau du lien mais les buffers des différents canaux sont physiquement séparés. Hypertransport effectue une deuxième séparation entre les commandes postées et les commandes non postées. Cette séparation améliore la gestion du flux et augmente la bande passante finale. Par conséquent, les commandes postées et non postées ont la capacité de se doubler. On peut interdire à un paquet d’en dépasser un autre en l’indiquant dans son header. On peut aussi émettre un paquet Fence pour délimiter deux groupes de paquets et leur interdire de se doubler.

Figure 10 Multiplexage des 3 canaux virtuels sur le lien physique

3.5 Réseaux Hypertransport Nous avons jusque là décrit le protocole Hypertransport au niveau du lien composant à composant. Hypertransport dépasse ce seul champ et permet de définir des réseaux.

3.5.1 Chaines Un réseau Hypertransport est constitué de chaines de composants Hypertransport. Il existe quatre types de composants : bridge hôte (1 par réseau), bridge, tunnel et cave. Une chaine Hypertransport est une chaine de tunnels se finissant d’un côté par le bridge hôte ou un bridge, et de l’autre par une cave ou un bridge. Les chaines d’assemblent pour former des réseaux.

3.5.2 Interfaces Les composants se connectent au réseau Hypertransport par une ou plusieurs interfaces. Il existe deux types d’interfaces : Client P (Primaire) et Hôte S (Secondaire). Le bridge hôte possède une interface hôte. Les bridges possèdent une interface client et plusieurs interfaces hôte. Les tunnels et les caves possèdent une interface client. Chaque

24

Rapport de stage de recherche

Etienne Le Grand

chaine possède une interface hôte à une ou deux de ses extrémités. Les autres interfaces présentes sur la chaine sont des interfaces client.

Figure 11 Composants Hypertransport et leurs interfaces

3.5.3 Transactions Dans un système processeur-mémoire-périphériques, le bridge hôte est relié au processeur et à la mémoire, et communique en Hypertransport avec les périphériques. Le standard Hypertransport définit trois types de transactions : •

Les transactions DMA sont émises par les périphériques et visent la mémoire. Elles passent par le bridge hôte

•

Les transactions Programmed IO sont émises par le processeur en direction des périphériques. Elles passent par le bridge hôte

•

Les transactions Peer to Peer sont émises par un périphérique en direction d’un autre périphérique. Même si l’initiateur et la cible sont sur la même chaine Hypertransport, elles doivent aussi passer par le bridge hôte.

Figure 12 Les trois types de transactions Hypertransport

25

Hypertransport pour TSAR, v0.6 On remarque bien l’importance du bridge hôte, par lequel toutes les transactions doivent passer. C’est ce composant qui doit être intégré dans TSAR. Il est normalement intégré aux processeurs AMD®, et il n’existe pas de design d’un tel bridge qui soit libre de droits. Nous devons donc le concevoir.

4 Cluster Hypertransport Pour que TSAR puisse communiquer en Hypertransport, on introduit dans au moins un de ses clusters un ensemble de composants faisant la conversion VCI-Hypertransport. Chaque cluster comprenant ces composants possède un lien au format Hypertransport vers l’extérieur de la puce. Pour cette raison, il est appelé cluster Hypertransport. Même s’il est possible d’avoir plusieurs clusters Hypertransport au sein du même processeur TSAR, il est très probable que l’on n’en ait qu’un seul.

4.1 Composition du cluster Le cluster Hypertransport possède quatre composants dédiés à la communication avec les périphériques : l’interface hôte Hypertransport, le bridge Hypertransport, l’unité de gestion de mémoire entrées/sorties et le gestionnaire de bridge.

Figure 13 Cluster Hypertransport au sein du processeur TSAR

4.1.1 Interface hôte Hypertransport L’interface (ou cœur) Hypertransport gère le lien physique Hypertransport. Elle doit : •

contenir les buffers d’entrées/sorties

•

gérer le système de crédits régulant les flux Hypertransport

•

effectuer la vérification d’erreurs par CRC

•

sérialiser/désérialiser lors de l’envoi des paquets

•

initialiser le lien

•

resynchroniser le lien si nécessaire

26

Rapport de stage de recherche

Etienne Le Grand

Il s’agit d’un composant complexe, on cherche donc les solutions existantes de manière à pouvoir se concentrer sur le bridge plutôt que sur l’interface L’Université de Heidelberg (Allemagne) a conçu une interface Hypertransport client et a acquis une bonne expertise dans le domaine de l’Hypertransport. Nous sommes en négociation pour qu’ils ajoutent à leur interface les fonctionnalités nécessaires pour en faire une interface hôte. L’Université de Heidelberg sera peut être membre du projet successeur de TSAR.

Figure 14 Interface Hypertransport (Modèle de l'Université de Heidelberg)

4.1.2 Bridge Hypertransport Le bridge Hypertransport se charge de la traduction des transactions VCI en transactions Hypertransport(HT) et inversement. Il est connecté avec l’interface Hypertransport d’un côté, et le réseau interne à TSAR (au protocole VCI) de l’autre. La conception et le fonctionnement de ce composant sont décrits en détail plus loin.

4.1.3 Input Output Memory Management Unit (IO MMU) L’Input Output Memory Management Unit (IO MMU) se place entre le bridge Hypertransport et le réseau interne de TSAR. Elle traduit les adresses des commandes entrantes (venant des périphériques) pour offrir la flexibilité et la protection propre à l’usage d’une MMU. Il n’est pas certain que l’on utilisera effectivement une IO MMU. Etant donné que le protocole Hypertransport est conçu pour avoir le minimum de composants entre le southbridge et les processeurs, il est probable que l’IO MMU soit intégrée aux chipsets et qu’il soit inutile de l’implémenter à l’intérieur de TSAR. C’est pourquoi elle n’est pas intégrée au bridge, et pourra être rajoutée ou non à l’architecture TSAR au moment de l’étude des southbridges utilisés. 27

Hypertransport pour TSAR, v0.6

4.1.4 Gestionnaire de Bridge Pour être utilisable dans des environnements diverses et avec différents southbridges, le bridge Hypertransport doit être configurable. Entre autres, la traduction des adresses sortantes et les règles d’allocation des identifiants de paquets VCI et Hypertransport doivent être configurables par software. A l’initialisation, des commandes au format VCI sont envoyées au bridge, qui les traite au lieu de les traduire en Hypertransport. C’est le rôle du gestionnaire de bridge. Intégré au bridge, il est vu par les composants internes de TSAR comme un composant à part entière et les commandes de configuration de bridge lui sont adressées.

4.2 Adressage du cluster Hypertransport 4.2.1 Correspondance Cluster-Espace mémoire Dans l’architecture TSAR, il y a correspondance entre clusters et espace mémoire. En effet, chaque cluster dispose de sa tranche de l’espace mémoire physique, et l’ensemble de ces tranches forme l’espace mémoire physique total. Cette stratégie a l’avantage de rendre le routage trivial. Les bits de poids fort d’une adresse correspondent aux coordonnées XY du cluster propriétaire de cette adresse. Lorsqu’un routeur reçoit une commande, il lui suffit donc de comparer XY à ses propres coordonnées pour savoir de quel côté transférer la commande. Le même mécanisme existe pour le routage des réponses, à partir de l’identifiant du cluster initiateur. Cet identifiant correspond justement aux bits de poids fort de la tranche de mémoire allouée au cluster et contient donc les valeurs de XY.

Figure 15 Sémantique des adresses TSAR

Avec des adresses physiques de 40bit, si l’on a 210=1024 clusters, chacun d’entre eux dispose de 230octets=1Go. C’est largement suffisant pour les clusters standards puisqu’en réalité moins d’un dixième de cet espace correspond à de la mémoire RAM ou à des registres internes (le reste n’ayant pas de réalité physique). En revanche, ce n’est pas assez pour le cluster Hypertransport.

4.2.2 Besoins particuliers du cluster Hypertransport Le cluster Hypertransport contient le bridge Hypertransport, par lequel toutes les commandes visant les périphériques doivent transiter. Or, ces commandes peuvent concerner de grandes plages d’adresse. Avec tous les périphériques extérieurs présents, on risque de dépasser le Gigaoctet d’espace mémoire alloué au cluster. Pire, à l’intérieur des clusters, chaque composant dispose d’une fraction seulement de ce Gigaoctet. Dans cette situation, le bridge Hypertransport devrait se contenter de quelques méga-octets d’espace mémoire seulement. Pour palier à ce problème, on altère la correspondance cluster-mémoire de manière à attribuer plus d’espace mémoire au bridge tout en effectuant un minimum de changements dans la fonction de routage.

28

Rapport de stage de recherche

Etienne Le Grand

4.2.3 Nouvelle règle de routage Afin d’allouer plus d’espace mémoire au bridge Hypertransport, on introduit une nouvelle sémantique des adresses. Toutes les adresses physiques dont les deux bits de poids fort sont à 1 appartiennent au cluster Hypertransport.

Figure 16 Sémantique des adresses entrées/sortie

On peut comprendre cette sémantique de deux manières : •

Un quart des clusters de l’architecture est dédié aux périphériques. Autrement dit, un grand nombre de clusters connexes ne fait que transférer les paquets au cluster Hypertransport.

•

Le quart supérieur de l’espace adressable est alloué au cluster Hypertransport, et les routeurs doivent router commandes et réponses en conséquence. Cela nécessite l’introduction d’une nouvelle règle de routage, mais évite l’apparition de clusters vides dans l’architecture.

Figure 17 Routage vers les clusters Hypertransport (oranges)

Le changement de la fonction de routage est en fait minime. Les coordonnées du cluster Hypertransport sont enregistrées dans chaque routeur. Lorsque l’un d’entre eux reçoit un paquet, il vérifie les deux bits de poids fort de l’adresse. S’ils sont tous les deux à 1, le routeur utilise les XY du cluster Hypertransport, sinon il utilise les XY tirés de l’adresse. La suite du routage ne change pas. Si on souhaite avoir plusieurs liens avec les périphériques, donc utiliser plusieurs clusters Hypertransport, des bits de l’adresse peuvent être réservés pour indiquer vers quel bridge Hypertransport rediriger les requêtes (champ N). Dans ce cas, les coordonnées de chaque cluster Hypertransport sont enregistrées dans les routeurs. 29

Hypertransport pour TSAR, v0.6

5 Bridge Hypertransport 5.1 Structure et interfaces Le bridge Hypertransport rempli la fonction de traduction VCI->HT et HT->VCI. Il est séparé en deux parties indépendantes : CORI et CIRO. Du côté Hypertransport, il communique avec le réseau interne de TSAR par deux interfaces VCI et avec l’interface hôte par l’intermédiaire de 12 fifos : deux (contrôle et données) par canal virtuel et par direction.

Figure 18 Structure et interfaces du bridge Hypertransport (fifos de contrôles et de données regroupées)

Les paquets que le bridge reçoit de chaque côté contiennent des champs différents mais aux significations parfois proches. Les informations contenues dans les paquets commande doivent être conservés soit dans leur traduction, soit dans une table des transactions, de manière à disposer de ces informations lors de la traduction du paquet réponse.

Figure 19 Champs des paquets VCI (paramètres utilisés dans TSAR) et HT

30

Rapport de stage de recherche

Etienne Le Grand

5.2 Command Out Response In (CORI) 5.2.1 Transactions sortantes Le bloc Command Out Response In (CORI) est une cible VCI et un initiateur Hypertransport. Il traduit les commandes VCI sortantes (CO) en commandes Hypertransport, puis traduit les réponses Hypertransport entrantes (RI) en réponses VCI. Les commandes sortantes gérées sont les lectures d’au plus 16 mots, les écritures masquées d’au plus 8 mots et les écritures non masquées d’au plus 16 mots. Les opérations atomiques ne sont pas encore gérées mais peuvent être implémentées si le besoin apparait. Il en est de même pour les broadcasts, dont l’implémentation ne parait pas nécessaire. Le protocole VCI ne définit pas d’écritures postées. Toutes les commandes d’écriture attendent une réponse, et l’initiateur est en général gelé tant qu’il attend l’acquittement de l’écriture. Le temps de réponse des périphériques pouvant être grand, on se donne la possibilité de laisser le bridge acquitter lui-même certaines écritures. Pour cela, la valeur du champ TRDID des commandes d’écriture distingue les écritures normales (non postées) des écritures acquittables directement par le bridge (non postées).

Figure 20 Traduction des transactions sortantes

5.2.2 Command Out (CO) 5.2.2.1 Fonction et structure Le bloc CO traduit les commandes VCI en headers et données Hypertransport et les envoie dans les différents canaux virtuels. Les réponses aux écritures postées sont passées au bloc RI pour être renvoyées à l’initiateur VCI directement.

31

Hypertransport pour TSAR, v0.6

Figure 21 Communications internes au bloc CO

L’automate VciCO traduit un paquet VCI en header de contrôle, masque et données Hypertransport. Pour cela, il traduit l’adresse, alloue un identifiant Hypertransport au paquet et traduit le code commande. Des informations sont stockées dans la table des transactions. Elles seront utilisées par le bloc RI 5.2.2.2 Identifiants et table des transactions sortantes L’identifiant de paquet VCI n’est pas utilisable en Hypertransport. Il faut donc allouer un nouvel identifiant à la transaction. Cet identifiant est pris parmi les identifiants disponibles stockés dans la fifo HTIds. La table des transactions sortantes contient les informations nécessaires à la traduction des réponses entrantes : SRCID, TRDID, PKTID. Elle est indexée par les identifiants Hypertransport, elle a donc autant de cases qu’on utilise d’identifiants Hypertransport. C’est une RAM à double accès : le bloc CO peut y écrire au même cycle que le bloc RI y lit. 5.2.2.3 Traduction d’adresse Les adresses des commandes VCI ont une signification à l’intérieur de TSAR, mais n’en ont plus à l’extérieur. Pour accéder aux différents segments de l’espace adressable Hypertransport, l’adresse doit être traduite.

Figure 22 Segments importants de l'espace adressable Hypertransport

32

Rapport de stage de recherche

Etienne Le Grand

Le bloc de traduction d’adresse, utilisé par VciCO, est configurable par envoi d’une commande de configuration au gestionnaire de bridge. Celui-ci remplit une petite table de page. Avec 4 pages de 16Go, on est sûr de pouvoir s’adapter à l’environnement (principalement le southbridge).

Figure 23 Mécanisme de traduction d'adresse VCI vers Hypertransport

5.2.2.4 Store & Forward VCI et Hypertransport ont une politique différente concernant les écritures masquées : VCI ne différencie pas écritures masquée ou non masquées, et indique mot par mot le masque à appliquer. Au contraire, Hypertransport différencie les écritures masquées (Byte) et non masquées (Dword). Dans le cas des écritures masquées, il faut envoyer le masque entier avant les données à écrire. Pour effectuer la traduction, on concatène donc les masques des écritures VCI et on stocke les données. Lorsque la fin du paquet VCI arrive, on sait s’il s’agit d’une écriture masquée ou non (dans ce cas, tous les BE étaient à 0xF). Contrairement aux écritures, la différenciation entre lectures masquées et non masquées ne pose pas de problèmes. L’automate HTCO transmet les paquets Hypertransport une fois que ceux-ci sont prêts. Ils sont dirigés vers le canal de commandes postées (PCO) ou le canal de commandes non postées (NPCO) suivant les informations présentes dans le header de contrôle. Il utilise de manière optimale l’écriture dans les fifos de sortie : lorsque c’est possible, paquets de lectures et d’écritures sont envoyés en même temps. 5.2.2.5 Débit Si le dimensionnement des fifos est convenable, le bloc CO peut accepter les paquets en continue sur l’interface VCI. Il n’y a perte de débit que dans deux cas particuliers : •

si le bridge reçoit plus d’écritures masquées que d’autres commandes, le débit sera légèrement diminué car les envois des masques concaténés prennent chacun un cycle par écriture masquée.

•

si les périphériques Hypertransport sont trop lents à répondre, le bridge peut être à court d’identifiants Hypertransport, car on atteindra la limite de transactions Hypertransport simultanées possibles. Il attendra alors de recevoir des réponses pour libérer des identifiants et continuer les envois.

33

Hypertransport pour TSAR, v0.6 5.2.2.6 Registres internes •

vcico_dec[4] est un décompteur permettant de détecter la fin du paquet en cours de traduction.

•

masked[1] indique si l’écriture en cours de traduction est masquée ou non. Ce registre est mis à jour au fur et à mesure de la traduction en fonction des BE

•

mask[32] concatène les BE entrants en un mot de masque hypertransport. Il est rempli au fur et à mesure de la traduction.

•

htco_dec est un décompteur permettant de détecter la fin du paquet en cours de transfert.

•

ctrlCO[64] mémorise le header de contrôle de l’écriture en cours de transfert. Cette mémorisation permet de traiter les headers de lecture en même temps que les données des écritures.

5.2.2.7 Dimensionnement des fifos •

DataCO doit avoir une profondeur d’au moins 17 pour pouvoir stocker les données d’écriture de longueur 16.

•

HTIds étant rempli d’identifiants Hypertransport lors du reset, la profondeur de cette fifo correspond au nombre d’identifiants Hypertransport utilisables, donc le nombre de transactions simultanées possibles. Il faut dimensionner cette valeur en fonction de la fréquence des commandes sortantes et du temps de réponse des périphériques.

•

VciCO, CtrlCO, MaskCO, CtrlPCO, CtrlNPCO, DataPCO, DataNPCO, et CoToRi peuvent avoir une profondeur de 2. Avec une profondeur de 1, le débit sera divisé par deux.

5.2.3 Response In (RI) 5.2.3.1 Fonction et structure Le bloc RI envoie les réponses VCI générées par le bloc CO et les réponses traduites depuis l’Hypertransport. Il utilise les informations présentes dans la table des transactions sortantes pour reconstruire les paquets réponse VCI. Le bloc RI ne possède qu’un seul automate.

Figure 24 Communications internes au bloc RI

Au reset, l’automate VciRI se charge de remplir la fifo HTIds avec les identifiants Hypertransport alloués au bridge. 34

Rapport de stage de recherche

Etienne Le Grand

L’automate VciRI donne la priorité aux acquittements d’écritures postées. Ces réponses sont placées dans la fifo CoToRi par le bloc CO. Lorsque cette fifo est vide, l’automate traduit les réponses venant de l’Hypertransport et libère les identifiants Hypertransport des transactions en les insérant dans la fifo HTIds. L’état de la fifo CoToRi ne sera pas vérifié avant la fin de l’envoi de la réponse Hypertransport en cours de traitement. 5.2.3.2 Registres internes •

vciri_dec[4] est un décompteur permettant de détecter la fin de la réponse en cours de transfert.

•

reset_numid[8] est un compteur utilisé au reset pour remplir les fifos d’identifiants.

5.2.3.3 Débit et dimensionnement des fifos Si les fifos sont bien dimensionnées, le débit du bloc RI est limité par l’interface VCI. •

VciRI et CtrlRI doivent être de profondeur 2 pour permettre un bon débit

•

Mises bout à bout, DataRI et son vis-à-vis (dans l’interface Hypertransport) doivent avoir une profondeur suffisante pour stocker les données d’un paquet réponse entier (16 données)

5.3 Command In Response Out (CIRO) 5.3.1 Transactions entrantes Le bloc Command In Response Out (CIRO) est un initiateur VCI et une cible Hypertransport. Il traduit les commandes Hypertransport entrantes (CI) en commandes VCI, puis traduit les réponses VCI entrantes (RI) en réponses Hypertransport. Les commandes entrantes gérée sont les lectures masquées ou non, les opérations atomiques (pas dans la 1ère version du bridge) et les écritures postées et non postées, masquées et non masquées. Les interruptions (écritures non postées visant un segment particulier de l’espace d’adressage) seront traduites à l’intérieur du bridge dans une version ultérieure.

Figure 25 Traduction transactions entrantes

35

Hypertransport pour TSAR, v0.6

5.3.2 Command In (CI) 5.3.2.1 Fonction et structure Le bloc CI lit les commandes Hypertransport présentes dans les canaux virtuels des commandes postées (PCI) et non postées (NPCI). Ces commandes sont enregistrées dans la table des transactions entrantes et traduites en VCI à la volée. Le bloc CI comporte un unique automate.

Figure 26 Communications internes au bloc CI

L’automate HTCI traduit les commandes Hypertransport en VCI et les envoie. Les commandes venant du bloc RO sont prioritaires face aux commandes hypertransport. De la même manière que le bloc CO attribuait un identifiant Hypertransport aux commandes sortantes, un identifiant VCI est attribué aux commandes entrantes. Les headers Hypertransport sont recopiés dans la table des transactions entrantes. Les adresses ne sont pas traduites : c’est le rôle de l’IO MMU qui est placée en sortie de la fifo VciCI. On prévoit une fifo d’envoi de réponses Hypertransport en cas d’erreurs (commandes entrantes incorrectes). 5.3.2.2 Identifiants et table des transactions entrantes La fifo VciIds a la même fonction que la fifo HTIds du bloc CORI. Pour assurer le bon routage de la réponse vers le cluster Hypertransport, les identifiants VCI stockés dans cette fifo doivent bien correspondre au cluster Hypertransport. Les 4 bits de poids fort de l’identifiant sont donc fixés.

Figure 27 Format des identifiants VCI pour un cluster standard et un cluster IO

Les paquets réponse VCI comportent très peu de champs car ce protocole suppose que l’initiateur de la transaction est capable de reconnaitre une réponse à partir de l’identifiant de 36

Rapport de stage de recherche

Etienne Le Grand

la transaction. En Hypertransport, au contraire, de nombreux champs doivent être renseignés dans le header de la réponse. La table des transactions entrantes stocke les headers des commandes entrantes de manière à pouvoir renseigner les champs du paquet réponse. Le traitement des opérations atomiques nécessite d’enregistrer des données. Un tableau de données vient compléter la table des transactions entrantes pour les opérations atomiques. 5.3.2.3 Registres internes •

mask[32] : Lors de la réception d’écritures masquées, le masque est contenu dans le premier mot de donnée du paquet hypertransport. Cette information est stockée dans le registre mask, et envoyé par blocks de 4 bits dans les BE du paquet VCI

•

htci_dec[4] est un décompteur permettant de détecter la fin du paquet en cours de transfert.

•

addr[40] enregistre et incrémente l’adresse cible au fur et à mesure de l’envoi du paquet.

5.3.2.4 Débit et dimensionnement des fifos •

VciCI, CtrlPCI, CtrlPNCI et CiToRo doivent être de profondeur au moins 2

•

DataPCI et DataNPCI doivent être dimensionnés de même manière que la fifo DataRI du bloc RI.

•

RoToCi est utilisée rarement, mais toujours pour envoyer 2 paquets VCI à la fois. Il est conseillé de lui donner une profondeur de 2 ou 3.

5.3.3 Response Out (RO) 5.3.3.1 Fonction et structure Le bloc RO envoie les réponses Hypertransport générées par le bloc CI et les réponses traduites depuis VCI. Il utilise les informations présentes dans la table des transactions entrantes pour reconstruire les paquets réponse Hypertransport. Le bloc RO ne possède qu’un seul automate, mais en possèdera davantage pour traiter les opérations atomiques.

Figure 28 Communications internes au bloc RO

Au reset, l’automate HTRO se charge de remplir la fifo VciIds et AtIds avec les identifiants utilisables par le bridge. L’automate HTRO donne la priorité aux réponses de la fifo CiToRo, puis il lit les réponses VCI. Les réponses aux écritures postées sont jetées. Les réponses aux transactions atomiques 37

Hypertransport pour TSAR, v0.6 sont traitées en envoyant une nouvelle commande atomique VCI ou en délivrerant une réponse Hypertransport. Les réponses aux autres types de transactions sont traduites en Hypertransport à partir des informations contenues dans la table des transactions entrantes, puis envoyées à l’Hypertransport. 5.3.3.2 Opérations atomique Le bloc CIRO émule les commandes Hypertransport Fetch & Add et Compare & Swap par des commandes VCI Linked Load et Store Conditional. Dans la première version du bridge, ce bloc n’est pas implémenté, ce qui signifie que les opérations atomiques entrantes ne sont pas supportées. Pour s’assurer que le traitement des opérations atomique ne crée par d’inter-blocage, on doit découpler l’acceptation des réponses et l’envoi des commandes des transactions LL/SC. Pour cela, on limite le nombre de transactions atomiques simultanées en réservant un petit nombre d’identifiants de transaction aux transactions atomiques. Ces identifiants sont stockés dans la fifo AtIds. 5.3.3.3 Registres internes •

reset_numid[8] est un compteur utilisé au reset pour remplir les fifos d’identifiants.

•

attmpdata[32] fait tampon avant l’émission des SC. Les mots de données à envoyer en SC y sont stockés pendant un cycle.

•

sumoverflow[1] enregistre la retenue de l’addition du mot de poids faible lors de l’émulation d’un Fetch & Add.

5.3.3.4 Débit et dimensionnement des fifos •

VciRO et CtrlRO doivent être de profondeur 2 pour permettre un bon débit.

•

DataRO doit être dimensionnée de la même manière que la fifo DataRI du bloc RI

•

ROtoCI doit être assez profonde pour contenir les paquets commande de toutes les transactions atomiques simultanées. Ainsi, elle n’est jamais pleine, ce qui permet de découpler l’acceptation des réponses de l’émission des commandes.

6 Dispositifs de test Contrairement à de nombreux composants de TSAR, on ne peut pas tester le bridge Hypertransport en situation normale dans une plateforme SystemC de TSAR. En effet, nous ne disposons pas modèles de périphériques ou southbridges Hypertransport en SystemC. Les tests en situation artificielle sont donc les seuls dont nous disposerons pour nous assurer que le design du bridge Hypertransport ne comporte pas de défauts. Dans ces conditions, la batterie de test doit être aussi proche que possible de l’exhaustivité pour éviter de passer à côté d’une erreur de conception jusqu’au moment de fondre le composant.

38

Rapport de stage de recherche

Etienne Le Grand

6.1 Test par rebouclage VCI-HT->HT-VCI 6.1.1 Principe Pour tester le modèle SystemC du bridge Hypertransport, on connecte les blocs CORI et CIRO par leur interface Hypertransport. Le dispositif résultant doit se comporter comme une ligne à retard pour connexion VCI. On peut alors insérer cette ligne à retard entre deux composants VCI et vérifier qu’elle ne modifie pas le comportement global du système.

Figure 29 Plateforme de test par rebouclage VCI-HT -> HT-VCI

Pour que le test couvre une large gamme de transactions, on peut utiliser différents initiateurs et cibles VCI.

6.1.2 Plateforme simple processeur-RAM La ligne à retard peut être insérée à l’entrée d’une RAM VCI dans un système « cœur de processeur - cache L1 - RAM». Pour faciliter la visualisation du comportement du système, on préfère utiliser une plateforme utilisant en plus un réseau VCI virtuel (VGMN) et un terminal (TTY).

Figure 30 Plateforme simple de test et résultat

39

Hypertransport pour TSAR, v0.6 Le lien interconnect-ram est remplacé par la ligne à retard, et l’application s’exécute normalement, comme si la connexion interconnect-ram était toujours directe. Ce test est encourageant, mais lorsque l’on enregistre les transactions traduites par le bridge Hypertransport, on s’aperçoit à quel point le test est peu exhaustif : •

Il ne comporte que deux type de transactions

•

Le débit est très faible

•

On n’a jamais plusieurs transactions simultanées.

6.1.3 Plateforme TSAR V0 La faiblesse du test sur plateforme processeur-RAM est due au fait que le bridge ne doive traiter les transactions que d’un initiateur. Pour éviter cela, on teste le rebouclage sur la plateforme TSAR V0 qui contient 16 processeurs. Le rebouclage remplace la connexion entre l’interconnect et un memorycache qui reçoit les requêtes de tous les processeurs. Ainsi, on teste notre composant avec 16 initiateurs. Lors de la simulation, on s’aperçoit que la plateforme ne fonctionne plus avec cette modification car le protocole interne de TSAR n’est pas tout a fait standard VCI : il donne aux champs TRDID et PKTID une signification particulière. Or, la valeur de ces champ est perdue lors du passage au protocole Hypertransport. Il aurait été possible de modifier le bridge de manière à pour reconstruire la valeur de TRDID et SRCID lors de la traduction Hypertransport->VCI, mais cela n’est pas pertinent. En effet, le bridge n’est pas conçu pour être utilisé dans une telle situation. On arrive aux limites des tests par rebouclage.

6.2 Utilisation d’initiateurs VCI et HT synthétiques 6.2.1 Besoin Pour tester le bridge le plus exhaustivement possible, on a besoin d’une plateforme avec plusieurs initiateurs VCI, plusieurs initiateurs Hypertransport, plusieurs cibles VCI et plusieurs cibles Hypertransport. On peut tester individuellement la partie CORI et la partie CIRO du bridge, ce qui permet de se ramener à deux plateformes plus simples avec pour chacune plusieurs initiateurs et plusieurs cibles.

Figure 31 Plateforme de test multi-initiateur multi-cible pour le bloc CORI

Pour avoir à la fois plus de contrôle sur le test et une plateforme moins complexe, on utilise un initiateur synthétique capable d’émuler plusieurs initiateurs envoyant chacun des 40

Rapport de stage de recherche

Etienne Le Grand

commandes de tous les types possibles. Un tel composant serait complexe si l’on n’utilisait pas les possibilités qu’offre SystemC.

6.2.2 Fichier de commandes SystemC étant basé sur le langage C++, le modèle SystemC d’un composant peut utiliser les capacités de l’hôte de la simulation. Lors de la simulation, les initiateurs synthétiques ouvrent un fichier source contenant la liste des commandes à envoyer.

Si la syntaxe du fichier de commandes permet la description de toutes les commandes VCI, alors on peut fabriquer des jeux de fichiers de commandes qui testeront exhaustivement le bridge.

6.2.3 Automatisation des tests et résultats Pour l’instant, les tests sont écrits à la main et le bon fonctionnement du bridge est également vérifié manuellement : le code SystemC crée un fichier où il enregistre les traductions effectuées. On peut imaginer tester le bridge de manière exhaustive en automatisant l’écriture des fichiers de commande et la vérification de la bonne traduction de ces commandes et des réponses engendrées. Pour permettre cela, nous aurons besoin d’une cible synthétique capable d’émuler plusieurs cibles aux comportements distincts. Or, la description du comportement d’un tel composant nécessiterait un langage plus évolué que celui listant les commandes à envoyer par l’initiateur synthétique.

41

Hypertransport pour TSAR, v0.6

6.3 Tests sur FPGA 6.3.1 Ecriture du code VHDL Le bridge Hypertransport n’a pas pour but de rester un modèle SystemC. On écrira son code VHDL de manière à pouvoir le synthétiser et disposer du design du composant en lui-même. L’écriture du code VHDL se fait à partir du modèle SystemC, or les outils de débogage qu’offre le langage VHDL sont plus rudimentaires que ceux de SystemC. Il est donc important que le code SystemC du bridge soit bien testé et obéisse aux règles d’écriture CABA de manière à ce que la traduction de SystemC à VHDL se fasse en engendrant le minimum de nouvelles erreurs.

6.3.2 Test sans interface Hypertransport Pour détecter les erreurs introduites lors de la traduction de SystemC à VHDL, il sera impossible d’utiliser les initiateurs synthétiques lisant des fichiers de commandes pour vérifier le comportement du bridge synthétisé. Le test du code VHDL pourra être fait dans un premier temps par rebouclage comme pour le modèle SystemC, mais ces tests ne testeront donc qu’une petite partie du comportement du bridge.

6.3.3 Connexion à l’interface hôte conçue par l’université de Heidelberg Pour être complet, le cluster Hypertransport doit contenir une interface (ou cœur) Hypertransport. Nous avons déterminé qu’il serait possible d’utiliser sur nos FPGA le cœur développé par l’Université de Heidelberg. Celui-ci devra tout de même subir quelques modifications pour être utilisable comme interface hôte. Une fois l’interface hypertransport intégrée au cluster Hypertransport, il sera possible d’effectuer des tests en rebouclage, mais cette fois en passant par une nappe externe au FPGA. On pourra même connecter ainsi deux FPGA pour les faire dialoguer en Hypertransport. Enfin, le véritable test du module d’entrées/sorties de TSAR se fera lorsqu’il sera possible de connecter TSAR à un southbridge et vérifier l’interaction du processeur avec les périphériques.

42

Rapport de stage de recherche

Etienne Le Grand

Bibliographie [1]

TSAR Architecture Specification Version 0.4, Juin 2009, UPMC / LIP6

[2]

Virtual Component Interface Standard Version 2 (OCB 2 2.0), Mars 2001, VSI Alliance™

[3]

Stratix III Device Handbook, Février 2009, Altera Corporation

[4]

Terasic DE3 User Manual, Mars 2009, Altera Corporation

[5]

HT-1000 Product Brief, HT-1000-PB03-DR, Novembre 2007, Broadcom Corporation

[6]

HT-2000 Product Brief, HT-2000-PB03-DR, Novembre 2007, Broadcom Corporation

[7]

AMD-811 HyperTranspor I/O Hub Data Sheet 24674 Rev. 3.03, Juillet 2004, AMD Corporation

[8]

HyperTranspor I/O Link Specification Revision 3.10, HTC20051222-0046-0026, Juillet 2008, HyperTransport Technology Consortium

[9]

Hypertransport 3.1 Interconnect Technology, September 2008, Brian Holden, Jay Trodden, Don Anderton, Mindshare Press

[10]

HT Core User Manual Version 1.00, Août 2008, Computer Architecture Group of the University of Heidelberg.

[11]

HyperTransport MegaCore Function User Guide Version 9.0, Mars 2009, Altera Corporation

43