Les architectures multiprocesseurs

L'évolution très rapide des technologies de fabrication de circuits intégrés sur silicium permet aujourd'hui de réaliser des systèmes numériques complets intégrés sur une même puce et contenant un grand nombre de processeurs (MP-SOC) an d'atteindre les perfor-mances requises par l'application. La taille du marché des MP-SoC devient de plus en plus importante (plus que 1600 circuits pas an), ce qui rend de ces circuits la cible directe des plateformes de prototypage. Par conséquent, notre intérêt était de chercher des benchmarks ayant un comportement semblable à celui des circuits industriels. Notre première tenta-tive était de récupérer des circuits industriels auprès des grandes industries des systèmes sur puces. Mais pour des raisons de condentialité, cette tentative a échoué. Par la suite, nous avons essayé de récupérer les benchmarks "open source". Les circuits proposés dans [29, 30, 31] ne sont pas susamment grands pour être partitionnés sur des plateformes multi-FPGA. La taille des benchmarks générés par un programme GNL utilisant la for-mule de Rent [33] peut dépasser les millions de LUT, par contre, le comportement aléatoire de ces circuits n'obéit pas aux exigences du marché.

Pour toutes ces raisons, nous avons décidé de concevoir un générateur de benchmarks qui permet de générer des circuits multiprocesseurs ayant un comportement réel et des ca-ractéristiques semblables à celles des circuits industriels. En eet, ces benchmarks sont conçus à l'aide d'une base de données contenant un ensemble de composants virtuels dont la fonctionnalité pourra correspondre à un processeur, une mémoire ou même un réseau sur puce.

4.2.1 Caractéristiques des architectures multiprocesseurs

Les benchmarks générés doivent répondre à un certain nombre d'exigences an de valider l'ensemble des techniques développées dans le cadre du projet PPR.

4.2.1.1 Architectures hétérogènes

A part les composants processeurs, les benchmarks doivent contenir d'autres compo-sants répartis d'une manière asymétrique sur l'architecture. Ces compocompo-sants inclus des accélérateurs, des coprocesseurs, des mémoires et des périphériques. L'hétérogénéité et

4.2 Les architectures multiprocesseurs 55 l'asymétrie permettent d'évaluer "l'intelligence" de l'outil de partitionnement et sa capa-cité de créer des partitions qui respectent les contraintes de surface sur les diérents FPGA de la carte.

4.2.1.2 Horloges multi-domaines

Les circuits intégrés récents sont contrôlés par plusieurs horloges (multi-domaines). Le nombre d'horloges dépend de l'application logicielle. Lors des étapes de partitionnement et de routage, les outils CAO doivent gérer convenablement les diérentes horloges en y appliquant une attention considérable. Les benchmarks de test doivent être multi-domaines an de bien évaluer le comportement des outils de partitionnement et de routage envers ces horloges.

4.2.1.3 Architectures de grande taille

Les architectures générées doivent être assez grandes pour occuper toutes la surface logique d'une carte multi-FPGA. Ces architectures permettront d'évaluer la performance de l'outil de partitionnement, mais aussi celle des techniques de multiplexage proposées dans cette thèse. La plateforme matérielle fabriquée dans le cadre du projet PPR contient deux FPGAs Virtex 7, chacune de taille logique qui dépasse les 2 millions de LUT. Par conséquent, il est nécessaire de concevoir un outil de génération de benchmarks qui génère en un temps acceptable une telle taille.

4.2.2 Caractéristiques du générateur de benchmarks

Le générateur de benchmarks comportera un volet logiciel et un volet matériel. Le volet matériel consiste à développer une plateforme matérielle générique décrite dans un langage de description de matériel et synthétisable. Cette plateforme est construite par un générateur permettant d'obtenir un système multiprocesseur avec un nombre variable de processeurs. On peut également envisager de faire varier les caractéristiques des caches et les moyens de communication entre les processeurs. L'intérêt de cette plateforme géné-rique est de faire varier simplement la complexité du système à travers les paramètres du générateur. Ainsi, on obtient un démonstrateur permettant à la fois la mise au point des méthodes proposées que leur évaluation à travers une série d'expériences.

Le volet logiciel est basé sur le développement d'une ou de plusieurs applications. L'expéri-mentation consiste à compiler l'application et à enregistrer le code exécutable obtenu dans les mémoires du système multiprocesseur avant de demander au système d'exécuter l'appli-cation. Les applications doivent être écrites sous forme de plusieurs tâches communicantes (des threads). Cette écriture permet de distribuer facilement l'application sur la plateforme multiprocesseur. L'objectif est d'obtenir des applications comportant un nombre variable

de tâches qui s'exécutent sur une plateforme ayant elle-même un nombre variable de pro-cesseurs.

Une application qui répond à ces caractéristiques a été développée dans le laboratoire d'In-formatique de Paris 6 (LIP6). Cette application est basée sur l'outil DSX [73] qui permet la co-conception de plateformes matérielles-logicielles destinées au traitement de ux ba-sées sur des architectures multiprocesseurs sur puces. Cet outil génère des netlists décrites avec le langage de description SystemC. Ces netlists ne sont pas implémentables sur carte FPGA à moins de passer par une étape de traduction qui risque d'être impossible.

Nous proposons donc de mener des modications au environnement DSX_SystemC an de générer des netlists synthétisables et implémentables sur une plateforme de prototypage. Avant de présenter notre nouvel environnement, nous donnons d'abord une description des fonctions principales et de la chaine de compilation de l'environnement DSX_SystemC.

4.3 L'environnement DSX_SystemC

L'outil DSX (Design Space eXploration)[73] assiste la conception d'applications logi-cielles décrites de manière statique sous forme d'un graphe de taches et du matériel sous-jacent. Pour le concepteur d'un système intégré, il est impératif d'avoir un contrôle maxi-mum sur le système sur puce construit, tant au niveau de l'architecture, que du placement des objets physiques. Un objectif essentiel est de permettre au concepteur de l'application de contrôler de façon très ne, non seulement le placement des taches sur les processeurs, mais également le placement des diérents objets logiques (piles d'exécution des taches, canaux de communication, barrières de synchronisation, verrous,..) sur les bancs mémoire physiques.

4.3.1 Chaine de compilation de DSX_SystemC

La gure4.1 représente un schéma simplié des ux d'entrée et de sortie classiques de DSX.

Le développement d'un SoC est décomposé en trois étapes :

• La conception d'une application décrite sous forme d'un graphe de tâches communi-cantes par des canaux de communication spéciques appelés MWMR (Multi Writer Multi Reader). Chaque tâche doit être dénie au préalable. Cette dénition com-porte la façon dont la tache est intégrée dans le graphe (entrées, sorties, ressources) et encore l'ensemble de ses implémentations matérielles et logicielles. La description se fait à travers une API en python.

• La conception d'une plateforme matérielle pour héberger cette application : il s'agit d'une architecture conçue à l'aide des IP-core de la bibliothèque SoCLIB [36]. C'est une librairie ouverte conçue pour le prototypage virtuel des systèmes sur puce. Il s'agit d'un ensemble de modèles de simulation system C des composants matériels,

4.3 L'environnement DSX_SystemC 57

Figure 4.1  Schéma descriptif des ux d'entrée et de sortie de DSX_SystemC qui peuvent être utilisés lors de la description architecturale des systèmes intégrés, notamment sous DSX.

• Enn le déploiement de l'application logicielle sur la plateforme matérielle.

Les plateformes sont simulées soit au niveau CABA (cycle accurate bit accurate, cycle précis bit précis) soit au niveau transactionnel (TLM). Tous les composants sont intégrés sur une seule puce. L'architecture générique contient un nombre variable de processeurs RISC 32 bits programmables et de bancs mémoire embarqués. Elle contient du matériel pour l'achage et la gestion des verrous, et des coprocesseurs spéciques à l'application. Il y a deux types de composants : initiateurs (typiquement des processeurs et des coprocesseurs) et cibles (typiquement, les bancs memoire, terminaux..).

4.3.2 Bibliothèque SoCLib de composants

SoCLib est une plateforme ouverte, conçue pour le prototypage des systèmes multi-processeurs sur puces. Il s'agit d'une bibliothèque de modèles de simulation SystemC des composants matériels, qui peuvent être utilisés lors de la description architecturale de sys-tèmes intégrés, notamment DSX.

L'outil DSX_SystemC et SoCLib ont été conçus pour cibler la simulation comportemen-tale des ASICs comme une étape de vérication avant la fabrication eective du circuit intégrés. Pour proter des avantages du prototypage matériel, il a été nécessaire de cibler une autre plateforme matérielle (au lieu de la station de travail) qui n'est autre qu'une plateforme à base de circuits FPGA. Par conséquent, notre but c'était de modier l'outil DSX_SystemC pour générer, en plus du simulateur system C caba, une plateforme VHDL synthétisable et implémentable sur carte FPGA.