HAL Id: tel-00665104
https://tel.archives-ouvertes.fr/tel-00665104
Submitted on 1 Feb 2012
HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci- entific research documents, whether they are pub- lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.
l’exploration architecturale de systèmes numériques
Tomasz Toczek
To cite this version:
Tomasz Toczek. Une approche fonctionnelle pour la conception et l’exploration architecturale de systèmes numériques. Autre. Université de Grenoble, 2011. Français. �NNT : 2011GRENT036�.
�tel-00665104�
Pour obtenir le grade de
DOCTEUR DE L’UNIVERSITÉ DE GRENOBLE
Spécialité : Micro et Nano Électronique
Arrêté ministériel : 7 août 2006
Présentée par
Tomasz TOCZEK
Thèse dirigée par Dominique HOUZET et codirigée par Stéphane MANCINI
préparée au sein du Laboratoire Gipsa-lab dans l'École Doctorale E.E.A.T.S.
Une approche fonctionnelle pour la conception et
l'exploration architecturale de systèmes numériques
Thèse soutenue publiquement le 15 juin 2011, devant le jury composé de :
Pr. Jocelyn SEROT
Professeur à l'université Blaise Pascal (Clermont-Ferrand), Rapporteur et Président du jury
Pr. Marc POUZET
Professeur à l 'université Pierre et Marie Curie (Paris), Rapporteur Pr. Dominique HOUZET
Professeur à Grenoble INP, Membre du jury Dr. Stéphane MANCINI
Maître de conférences à Grenoble INP, Membre du jury M. Laurent HILI
Ingénieur à l'ESTEC (Pays-Bas), Membre du jury
le d´ eveloppement des syst` emes num´ eriques modernes, tels que leurs tailles importantes ou la grande vari´ et´ e des blocs les constituant. Nous proposons un ensemble de m´ ecanismes permettant de m´ elanger au sein d’un mˆ eme design plusieurs formalismes de description distincts (
mod` eles de calcul
) se situant potentiellement ` a des niveaux d’abstraction diff´ erents. De plus, nous offrons au concepteur la possibilit´ e d’expliciter directement les param` etres explorables de chaque sous-partie du design, puis d’en d´ eterminer des valeurs acceptables via une ´ etape d’exploration partiellement ou totalement automatis´ ee r´ ealis´ ee ` a l’´ echelle du syst` eme. Les gains qu’apportent ces strat´ egies nouvelles sont illustr´ es sur plusieurs exemples.
Mots cl´ es : Conception au niveau syst` eme, Exploration architecturale, Mod` eles de calcul, Pro- grammation fonctionnelle, Monades, Haskell
Abstract: This work presents a novel system-level design method based on typed functional programming and aiming at mitigating some of the issues making the development of modern digital systems complex, such as their increasing sizes and the variety of their subcomponents.
We propose a range of mechanisms allowing to mix within a single design several description formalisms (“models of computation”), possibly at different abstraction levels. Moreover, the designer is provided with means to directly express the explorable parameters of each part of their design, and to find acceptable values for them through a partially or totally automatic system-wide architectural exploration step. The advantages brought by those new strategies are illustrated on several examples.
Keywords: System-Level Design, Design Space Exploration, Models of Computation, Func- tional Programming, Monads, Haskell
Th` ese r´ ealis´ ee au laboratoire Gipsa-lab 961 rue de la Houille Blanche
BP 46
F - 38402 GRENOBLE Cedex
Avant de poursuivre, je tenais ` a remercier tout particuli` erement mes directeurs de th` ese, Do-
minique Houzet et St´ ephane Mancini, pour leurs ´ eclairages pr´ ecieux et la libert´ e qu’ils m’ont
laiss´ ee dans la r´ ealisation de mes travaux de recherche. Je remercie ´ egalement les professeurs Joce-
lyn Serot et Marc Pouzet en leur qualit´ e de rapporteurs, et M. Laurent Hili pour sa participation
au jury. Enfin, je voudrais t´ emoigner de ma reconnaissance ` a ma famille pour m’avoir soutenu
au cours de ces quelques derni` eres ann´ ees, ainsi qu’` a l’int´ egralit´ e des personnels de Gipsa-lab, de
Grenoble INP et de l’´ ecole doctorale EEATS.
Introduction 13
1 Etat de l’art ´ 15
1.1 Challenges pour le design niveau syst` eme . . . . 15
1.2 Instanciation de composants . . . . 17
1.2.1 Composants g´ en´ eriques . . . . 17
1.2.2 Fichiers annexes, annotations du source, g´ en´ eration . . . . 21
1.3 Description de mat´ eriel et programmation fonctionnelle . . . . 22
1.3.1 Description de mat´ eriel . . . . 23
1.3.1.1 Bluespec SystemVerilog . . . . 23
1.3.1.2 Lava . . . . 23
1.3.1.3 ForSyDe . . . . 24
1.3.1.4 SML-Sys . . . . 24
1.3.1.5 CλaSH . . . . 24
1.3.2 V´ erification formelle . . . . 24
1.3.2.1 M´ ethodes classiques . . . . 24
1.3.2.2 M´ ethodes bas´ ees sur le syst` eme de types . . . . 25
1.4 Exploration architecturale . . . . 25
2 M´ ethodologie propos´ ee 27 2.1 Objectifs . . . . 27
2.1.1 Instanciation et explorabilit´ e . . . . 27
2.1.2 Multiplicit´ e des niveaux d’abstraction . . . . 28
2.1.3 Utilisation d’un seul langage . . . . 28
2.1.4 Facilit´ e d’emploi . . . . 29
2.2 Dichotomie MoC/Moteur . . . . 29
2.2.1 Monade d’´ etat explorable . . . . 30
2.2.2 Mod` eles de Calcul . . . . 34
2.2.3 Moteurs . . . . 35
2.2.4 R` egles d’impl´ ementation . . . . 36
2.3 Expression des m´ ethodes d’exploration . . . . 36
2.3.1 M´ ethodes simples . . . . 36
2.3.1.1 Choix par d´ efaut . . . . 36
2.3.1.2 Parcours al´ eatoire . . . . 37
2.3.2 M´ ethodes avanc´ ees . . . . 38
2.3.2.1 Types de donn´ ees . . . . 38
2.3.2.2 Recuit simul´ e . . . . 40
2.3.2.3 Programmation g´ en´ etique . . . . 42
2.3.2.4 Evaluation du score dans un contexte monadique . . . . ´ 45
2.4 Exemple et comparaison . . . . 46
2.4.1 Description et pertinence . . . . 46
2.4.2 Impl´ ementation . . . . 46
2.4.3 Vitesses de convergence . . . . 49
2.5 Conclusion . . . . 52
3 Mod´ elisations sans horloge et niveau RTL 53 3.1 Mod´ elisation sans horloge . . . . 53
3.1.1 Objectifs . . . . 53
3.1.2 Mod` ele de calcul . . . . 53
3.1.3 Moteur . . . . 55
3.1.4 Mod` eles de caches . . . . 57
3.1.4.1 Cache unidimensionnel . . . . 57
3.1.4.2 Cache multidimensionnel . . . . 59
3.1.5 Design . . . . 60
3.1.6 R´ esultats . . . . 62
3.1.7 Conclusions . . . . 64
3.2 Mod´ elisation au niveau RTL . . . . 64
3.2.1 Objectifs . . . . 64
3.2.2 Mod` ele de calcul . . . . 65
3.2.2.1 Transfert . . . . 65
3.2.2.2 Hi´ erarchie de classes . . . . 67
3.2.3 Moteur . . . . 70
3.2.3.1 Netlist . . . . 70
3.2.3.2 Simulation . . . . 73
3.2.3.3 Evaluation de la complexit´ ´ e . . . . 74
3.2.4 Mod` eles de caches . . . . 74
3.2.4.1 Interface m´ emoire . . . . 74
3.2.4.2 Cache unidimensionnel . . . . 75
3.2.4.3 Cache multidimensionnel . . . . 77
3.2.5 Design . . . . 78
3.2.6 R´ esultats . . . . 80
3.2.7 Conclusions . . . . 83
4 R´ esolution de divers probl` emes architecturaux 85 4.1 D´ ecoupage des pipelines en ´ etages . . . . 85
4.1.1 Contexte et principe . . . . 85
4.1.2 Extensions au mod` ele de calcul . . . . 85
4.1.2.1 D´ ecoupage automatique d´ eterministe . . . . 85
4.1.2.2 D´ ecoupage automatique probabiliste . . . . 87
4.1.3 Etude de cas : pipeline de ray casting dans des grilles hi´ ´ erarchiques . . . . . 87
4.1.3.1 Grilles hi´ erarchiques . . . . 87
4.1.3.2 Principe de la travers´ ee . . . . 88
4.1.3.3 Organisation mat´ erielle . . . . 89
4.1.3.4 R´ esultats . . . . 89
4.2 Allocation de ressources sur GPU . . . . 93
4.2.1 Programmation sur GPU . . . . 93
4.2.1.1 Historique . . . . 93
4.2.1.2 Architecture . . . . 95
4.2.1.3 Probl` emes . . . . 97
4.2.2 Mod` eles de calcul appropri´ es . . . . 98
4.2.2.1 Direct . . . . 98
4.2.2.2 Avec ordonnanceur . . . 100
4.2.3 Gains apport´ es . . . 102
4.3 Instanciation de r´ eseaux d’interconnexions . . . 103
4.4 Conclusion . . . 105
Conclusion g´ en´ erale 107
A Syntaxe de Haskell 109
A.1 Bases . . . 109
A.2 Filtrage par motif . . . 110
A.3 Polymorphisme . . . 112
A.4 Monades . . . 113
A.5 Pr´ elude . . . 114
A.5.1 Arithm´ etique . . . 114
A.5.2 Listes et chaˆınes de caract` eres . . . 114
A.5.3 Monades . . . 116
A.5.4 Divers . . . 117
B Reconstruction tomographique 119 B.1 Principe de la reconstruction tomographique . . . 119
B.2 R´ etroprojection en tomographie PET . . . 119
C Coprocesseur pour la travers´ ee de grilles hi´ erarchiques 121 C.1 Original (VHDL) . . . 121
C.2 MoC RTL, calqu´ e sur la version VHDL . . . 133
C.3 MoC RTL avec d´ ecoupage automatique du pipeline . . . 143
1.1 Quantit´ e pr´ evisionnelle de logique pr´ esente dans les SoCs . . . . 16
1.2 Quantit´ e pr´ evisionnelle de logique r´ eutilis´ ee dans les SoCs . . . . 16
1.3 Productivit´ e pr´ evisionnelle des concepteurs de SoCs . . . . 16
1.4 my noc.vhd . . . . 18
1.5 switch.vhd . . . . 18
1.6 my noc.vh . . . . 19
1.7 priorities.v . . . . 19
1.8 switch.v . . . . 19
2.1 Comportement de pickTwo . . . . 44
2.2 Exemple de parcours al´ eatoire de l’espace de design . . . . 50
2.3 Exemple de recuit simul´ e . . . . 50
2.4 Exemple d’exploration par programmation g´ en´ etique . . . . 51
2.5 Comparaison de exemples pr´ ec´ edents . . . . 51
3.1 Comparaison des politiques d’adressage impl´ ement´ ees . . . . 60
3.2 Allure typique des acc` es m´ emoire pour le calcul d’un voisinage de voxels . . . . 63
3.3 Hi´ erarchie de classes d´ efinissant les MoCs RTL et imp´ eratifs (listing) . . . . 68
3.4 Hi´ erarchie de classes d´ efinissant les MoCs RTL et imp´ eratifs (graphe) . . . . 69
3.5 Repr´ esentation d’une netlist . . . . 71
3.6 Mod` ele RTL de m´ emoire ` a latence ´ elev´ ee . . . . 76
3.7 Adressage de tableaux multidimensionnels . . . . 79
3.8 Sch´ ema global du r´ eseau d’unit´ es de reconstruction tomographique . . . . 80
3.9 Unit´ e de reconstruction tomographique mod´ elis´ ee au niveau RTL . . . . 81
3.10 R´ eseau d’unit´ es de reconstruction tomographiques mod´ elis´ e au niveau RTL . . . . 82
3.11 Nombre moyen d’´ el´ ements lus par cycle en fonction de l’it´ eration . . . . 83
4.1 Exemple de grille hi´ erarchique 4 × 4 × 4 . . . . 88
4.2 Exemple de travers´ ee de grille uniforme 2D via l’algorithme DDA . . . . 88
4.3 Variables caract´ erisant un rayon ` a un moment de la travers´ ee . . . . 90
4.4 Algorithme de d´ etermination de la prochaine cellule . . . . 90
4.5 Sch´ ema d’ensemble du SoPC de rendu par lancer de rayons . . . . 91
4.6 Organisation de l’unit´ e de travers´ ee . . . . 91
4.7 Organisation de l’unit´ e de recherche de voisins . . . . 92
4.8 Comparaison entre trois impl´ ementations de l’unit´ e de recherche de voisins (en terme de code source) . . . . 92
4.9 Sch´ ema architectural d’un GPU de nVidia (figure emprunt´ ee ` a [69]) . . . . 95
4.10 Grilles et blocs de threads sous CUDA (figure emprunt´ ee ` a [69]) . . . . 96
4.11 MoC PTX . . . . 99
4.12 Programme exprim´ e dans le MoC PTX . . . 100
4.13 Mod` eles de calcul pour la programmation imp´ erative sur GPU . . . 101
4.14 Exemple de programme dans ce mod` ele de calcul . . . 101
4.15 Mod` ele de calcul pour la programmation sur GPU avec primitives de communication
entre grilles et ordonnancement . . . 102
4.16 Recuit simul´ e d’un programme sur GPU . . . 104
4.17 Organisation possible de classes pour la mod´ elisation de NoCs . . . 104
A.1 Hi´ erarchie des classes d´ edi´ ees ` a l’arithm´ etique et leurs instances . . . 115
Le design niveau syst` eme est un domaine difficile pour un grand nombre de raisons. Les syst` emes ` a concevoir sont de plus en plus complexes, et comportent des blocs h´ et´ erog` enes aux fonctionnalit´ es et comportements extrˆ emement vari´ es qui pourtant doivent communiquer efficace- ment. La r´ eutilisation de composants devient une n´ ecessit´ e, et il est de plus en plus ardu pour le concepteur de connaˆıtre le design dans son int´ egralit´ e et donc de comprendre les motifs qui en dictent les performances. De cet ´ etat de fait r´ esulte la n´ ecessit´ e croissante d’automatiser les choix architecturaux, ou tout du moins de guider de concepteur dans leur r´ ealisation. Parall` element, la taille mˆ eme des designs actuels et les besoins en terme de r´ eutilisation appellent ` a une flexibilit´ e toujours plus grande dans les m´ ecanismes d’instanciation des composants individuels.
Nous proposons dans ce manuscrit une approche bas´ ee sur la programmation fonctionnelle typ´ ee pour le design niveau syst` eme. L’int´ erˆ et de l’utilisation de langages fonctionnels est multi- ple. D’ores et d´ ej` a, l’expressivit´ e de ces langages permet de rem´ edier ` a une partie significative des probl` emes que le designer peut rencontrer dans l’organisation de son syst` eme. L’utilisation de fonc- tions d’ordre sup´ erieur et du polymorphisme peut favorablement remplacer des m´ ecaniques telles que la programmation g´ en´ erique et constitue une excellente voie pour favoriser la r´ eutilisation de code source. Par ailleurs, les paradigmes fonctionnels trouvent leur applications dans des domaines appel´ es ` a prendre une importance croissante ` a l’avenir, tels que v´ erification formelle ou l’extraction de parall´ elisme. On peut mˆ eme affirmer qu’attaquer ces deux probl` emes requiert in´ evitablement une analyse fonctionnelle du programme ` a un moment ou ` a un autre.
Un des aspects centraux de la m´ ethode propos´ ee est de permettre au concepteur de sp´ ecifier les diff´ erentes parties de son design via diff´ erents jeux de primitives que nous appelons mod` eles de calcul. Proc´ eder ainsi permet ` a chaque ´ el´ ement du design d’ˆ etre d´ ecrit dans le paradigme le plus adapt´ e ` a son niveau d’abstraction et ` a ses autres propri´ et´ es intrins` eques. Chaque mod` ele de calcul constitue ce que l’on qualifie souvent de langage embarqu´ e sp´ ecifique ` a un domaine : il s’agit techniquement d’une biblioth` eque de constructions qu’il est possible d’agencer de sorte ` a d´ egager des ´ el´ ements syntaxiques et s´ emantiques non-pr´ esents dans le langage hˆ ote. Nous proposons un ensemble de r` egles ` a suivre dans la construction de mod` eles de calcul, leur permettant de commu- niquer entre eux, et garantissant la possibilit´ e d’explorer architecturalement les designs exprim´ es par leur biais. Il est int´ eressant de noter que cantonner les diff´ erents ´ el´ ements d’un design ` a des mod` eles de calcul pr´ ecis est en soi d´ esirable dans la mesure o` u cela permet de b´ en´ eficier des in- variants propres ` a chacun. Par contraste, l’utilisation d’un langage ` a usage plus g´ en´ eral ne permet pas de tirer parti aussi facilement et syst´ ematiquement des propri´ et´ es r´ esultant (´ eventuellement) de la discipline d’impl´ ementation utilis´ ee. Le parall´ elisme en est un exemple : difficile ` a d´ eduire dans le contexte d’un langage ` a usage g´ en´ eral, il peut n´ eanmoins ˆ etre extrait naturellement dans le cadre de toute une vari´ et´ e de mod` eles de calcul qui s’y prˆ etent.
La suite de ce manuscrit comporte en tout quatre chapitre et trois annexes.
Le premier chapitre fait office d’introduction ´ etendue et recense quelques approches compa-
rables ` a celle que nous proposons. Plus sp´ ecifiquement, on y trouve quelques pr´ evisions sur la
productivit´ e dans le domaine de la conception ´ electronique au cours des prochaines ann´ ees, ainsi
qu’une discussion des limitations des approches classiques pour le design niveau syst` eme. La fin du
chapitre ´ enum` ere des m´ ethodes plus modernes permettant de palier ` a ces limitations. Elles sont
divis´ ees en trois cat´ egories : les approches niveau syst` eme utilisant des annotations ou des fichiers
annexes en conjonction des m´ ethodes classiques, les approches fonctionnelles, et enfin celles se
focalisant sur l’exploration architecturale.
Le second chapitre pr´ esente les objectifs que nous nous sommes fix´ es et les principes de base de la m´ ethode que nous proposons pour les atteindre. On y voit en d´ etail les m´ ecanismes d’exploration architecturale et leur fondements fonctionnels. Le chapitre donne et commente les impl´ ementations de trois algorithmes d’exploration stochastiques : le parcours al´ eatoire, le recuit simul´ e et une m´ ethode bas´ ee sur la programmation g´ en´ etique. On discute ´ egalement les moyens ` a mettre en œuvre pour permettre l’utilisation d’entr´ ees/sorties durant l’´ etape d’exploration tout en restant dans un contexte fonctionnel pur. Enfin, les trois algorithmes propos´ es sont compar´ es sur un exemple tr` es simple mais avec une taille d’espace de design volontairement tr` es importante.
Le troisi` eme chapitre constitue une ´ etude de cas permettant de se faire une id´ ee des apports de la m´ ethodologie propos´ ee dans un contexte plus concret. L’application cible choisie rel` eve de l’imagerie m´ edicale, et plus sp´ ecifiquement de la tomographie ` a ´ emission de positrons. On pro- pose deux impl´ ementations mat´ erielles distinctes d’unit´ es de r´ etroprojection tomographique. La r´ etroprojection est une ´ etape de la reconstruction tomographique coˆ uteuse ` a la fois en calcul et en acc` es m´ emoire, et les choix li´ es aux d´ etails algorithmiques et architecturaux sont particuli` erement importants. Il s’agit donc d’un bon moyen d’´ evaluer les possibilit´ es en mati` ere d’exploration au- tomatis´ ee de l’espace de design sur un exemple r´ ealiste. Chaque impl´ ementation pr´ esente et utilise un mod` ele de calcul diff´ erent : mod´ elisation sans horloge pour la premi` ere, et niveau RTL pour la seconde.
Le quatri` eme chapitre pr´ esente plusieurs aspects difficiles du design niveau syst` eme ou orient´ e plateforme, et donne des pistes permettant de les r´ esoudre se basant sur les propositions ´ elabor´ ees au second chapitre. On y privil´ egie les probl` emes qu’il est ardu d’attaquer sans l’aide d’outils suppl´ ementaires dans les approches conventionnellement utilis´ ees en conception. On y abordera le d´ ecoupage automatis´ e en pipelines de chemins combinatoires, la programmation et l’alloca- tion de ressources sur processeurs graphiques programmables, ainsi que l’instanciation de r´ eseaux d’interconnexions.
La premi` ere annexe est une introduction ` a Haskell. Les chapitres deux ` a quatre contenant
de nombreux extraits de code dans ce langage, il est recommand´ e que le lecteur ne connaissant
pas encore ce langage commence par cette annexe. La seconde annexe regroupe les portions de
code trop longues pour ˆ etre int´ egr´ es ` a l’endroit du manuscrit o` u elles sont discut´ ees. La troisi` eme
pr´ esente tr` es succinctement les ´ equations relatives ` a l’´ etape de r´ etroprojection en topographie PET
qui a ´ et´ e prise comme exemple au chapitre 3.
Etat de l’art ´
1.1 Challenges pour le design niveau syst` eme
L’´ evolution des technologies dans le domaine de la micro-´ electronique a toujours ´ et´ e source d’une forte activit´ e de recherche dans le domaine de la conception assist´ ee par ordinateur
´
electronique (EDA). Gordon Moore est consid´ er´ e comme le premier ` a avoir clairement mis en
´
evidence le caract` ere empiriquement exponentiel de l’´ evolution de la complexit´ e des circuits num´ eriques int´ egr´ e avec le temps [64]. Sa pr´ ediction de 1975, stipulant que le nombre de transistors par die doublerait tous les deux ans [63], s’est av´ er´ ee remarquablement exacte jusqu’` a aujourd’hui, et devrait le rester pendant au moins les 5 prochaines ann´ ees [4]. Cette croissance rapide implique que le designer augmente r´ eguli` erement sa productivit´ e s’il veut ˆ etre capable de concevoir des cir- cuits aussi complexes que la technologie lui permet (voir figures 1.1, 1.2 et 1.3). Historiquement, de cette n´ ecessit´ e d´ ej` a a d´ ecoul´ e un certain nombre de r´ evolutions dans la conception ´ electronique.
La plus significative a sans doute ´ et´ e celle de l’arriv´ ee des langages de mod´ elisation et design de mat´ eriel, pour remplacer, l` a o` u c’´ etait possible, le design niveau porte. Bien qu’ayant augment´ e consid´ erablement l’efficacit´ e du designer, la conception de puces enti` eres au niveau RTL par le biais de ces langages est depuis d´ ej` a plusieurs ann´ ees devenue tr` es difficile ` a un coˆ ut raisonnable.
L’av` enement des Systems on Chip (SoCs), cons´ equence de l’explosion de la complexit´ e des circuits, a ` a la fois permis de mitiger le fardeau du designer en se basant davantage sur la r´ eutilisation de microprocesseurs, d’architectures d’interconnexions et d’autres blocs mat´ eriels (IP), mais aussi apport´ e son lot de challenges sp´ ecifiques :
1. probl` emes de partitionnement logiciel/mat´ eriel : la th´ eorie veut que les tˆ aches de haut niveau soient faites en soft, avec des coprocesseurs hardware dans le rˆ ole d’acc´ el´ erateurs de traite- ments r´ ep´ etitifs de plus bas niveau ; h´ elas, dans les cas non triviaux, le choix entre mat´ eriel et logiciel pour une partie d’un traitement donn´ ee est ` a la fois difficile et crucial du point de vue des performances obtenues apr` es optimisation
2. probl` emes de co-design logiciel/mat´ eriel : une fois le partitionnement effectu´ e, le fait qu’un traitement donn´ e comporte ` a la fois une partie soft et une partie hard le rend moins trivial
`
a impl´ ementer et ` a mettre au point
3. probl` emes d’interconnexions : de nombreux composants vont devoir communiquer entre eux, ce qui va se traduire par des motifs de trafic dans les interconnexions souvent complexes et difficiles ` a anticiper ; dans beaucoup de cas, le nombre d’IP est trop grand pour qu’un bus unique suffise — les hi´ erarchies de bus et les Networks-on-Chip (NoCs) permettent d’y rem´ edier mais am` enent leur propre lot de param` etres ` a configurer : position est blocs IP, tailles des buffers des switchs/bridges, probl` emes de contention/deadlocks, de d´ elais variables dans la transmission des messages, etc.
4. probl` emes d’organisation des hi´ erarchies m´ emoire : pour faire face ` a la latance importante
des DRAMs off-chip, une surface de plus en plus importante du die est consacr´ ee aux buffers
0 5 10 15 20 25 30 35 40 45
2008 2010 2012 2014 2016 2018 2020 2022 2024 3 3 3 3 3 3 3 3
3 3 3 3
3 3
3 3
Figure 1.1 – Quantit´ e de logique pr´ esente dans un SoC utilis´ e dans un appareil ´ electronique grand public dans les ann´ ees qui viennent, normalis´ ee par rapport ` a 2009 (pr´ evisions de l’ITRS)
0 20 40 60 80 100
2008 2010 2012 2014 2016 2018 2020 2022 2024 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3
Figure 1.2 – Quantit´ e de logique r´ eutilis´ ee dans un tel SoC, en pour cent (pr´ evisions de l’ITRS)
0 10 20 30 40 50 60
2008 2010 2012 2014 2016 2018 2020 2022 2024 nouveaux designs
3 3 3 3 3 3 3 3 3 3 3 3 3 3
3 3 designs r´eutilis´es 3
+ + + + + + + + + +
+ +
+ +
+ + +
Figure 1.3 – Productivit´ e par designer n´ ecessaire pour la conception d’un tel SoC, normalis´ ee
par rapport ` a la productivit´ e pour de nouveaux designs en 2009 (pr´ evisions de l’ITRS)
on-chip ; il s’agit de caches ou de scratchpads dont il va falloir g´ erer le partage des donn´ ees, la coh´ erence mutuelle et le write-back, les garanties de temps de r´ eponse, etc.
5. v´ erification et profiling : la simulation d’un circuit niveau porte a un coˆ ut prohibitif ; l’util- isation d’´ emulateurs de jeux d’instructions permet de le r´ eduire dans une certaine mesure (souvent insuffisante), tandis que la simulation ` a des niveaux d’abstraction plus ´ elev´ es est nettement plus rapide, au d´ etriment de la pr´ ecision des r´ esultats ; le prototypage sur FPGA offre d’excellentes performances, mais peut s’av´ erer compliqu´ e pour les tr` es gros designs 6. mise au point : un bug non descell´ e avant que la totalit´ e du syst` eme ne soit en place va
souvent ˆ etre difficile ` a trouver et ` a r´ esoudre
7. lorsque l’on s’int´ eresse aux syst` emes embarqu´ es, des contraintes suppl´ ementaires li´ ees ` a l’en- vironment dans lequel le syst` eme se trouve (ex : consommation) viennent encore noircir le tableau
8. multiplicit´ e des outils et mod` eles : le caract` ere disparate des logiciels permettant de con- tribuer ` a r´ esoudre certains de ces probl` emes rend la gestion de projet difficile ; le flot de conception peut devenir tr` es compliqu´ e du fait des d´ ependances et/ou incompatibilit´ es entre les outils utilis´ es
La pr´ esente th` ese propose une m´ ethodologie qui se veut flexible et adapt´ ee pour attaquer les challenges ´ evoqu´ es plus haut. En particulier, elle permet l’utilisation de diverses m´ ethodes d’exploration de l’espace de design, tout en laissant le designer maˆıtre de la taille de l’espace de design ` a explorer, et du niveau d’abstraction dans lequel les diff´ erentes parties de son design seront exprim´ ees. Elle se veut unificatrice : il doit ˆ etre possible d’incorporer au sein d’un mˆ eme design divers mod` eles de calcul (MoCs), mod` eles de performances, traitements heuristiques, etc. de fa¸ con aussi simple et ´ el´ egante que possible.
1.2 Instanciation de composants
La conception de SoCs demande au designer de m´ elanger un grand nombre de blocs IP au sein d’un mˆ eme design. Il s’agit d’une tˆ ache pour laquelle les langages de description de mat´ eriel classiques et encore largement utilis´ es, tels que le VHDL [41] ou Verilog [42], commencent ` a montrer leurs limites. En effet, bien que ces langages int` egrent la possibilit´ e de d´ efinir des composants et de les instancier hi´ erarchiquement, souvent le cˆ ablage des interfaces est assez fastidieux et verbeux. Similairement, les m´ ecanismes de g´ en´ ericit´ e qu’offrent les HDL bas niveau, bien que tr` es efficaces pour certains param` etres tels que les tailles des entr´ ees et des sorties, peuvent s’av´ erer maladroits, comme nous le verrons, lorsqu’ils concernent des aspects plus subtiles du comportement du bloc mat´ eriel. Pour toutes ces raisons, un nombre cons´ equent de techniques plus adapt´ ees ` a l’instanciation massive de blocs mat´ eriels param´ etrables ont ´ et´ e d´ evelopp´ ees.
Dans les sections qui suivent, les plus significatives d’entre elles seront analys´ ees un peu plus en d´ etail, exemples ` a l’appui lorsque ce sera possible.
1.2.1 Composants g´ en´ eriques
Avant de d´ etailler les techniques alternatives, il convient de faire la lumi` ere sur ce qu’il est possible et n’est pas possible de faire avec du VHDL ou du Verilog standard. Il s’agit en effet des langages qui dominent l’industrie, et qui ont une longue histoire durant laquelle ils ont fait l’objet d’attention de la part d’un grand nombre d’acteurs du march´ e. On peut donc les consid´ erer comme matures. Les outils d’EDA impl´ ementent ces deux langages de fa¸ cons souvent assez robuste, malgr´ e des diff´ erences sur la s´ emantique exacte de certaines constructions, notamment en synth` ese
`
a partir du VHDL [96].
Nous avons choisi un exemple de bloc IP pour illustrer les probl´ ematiques souvent rencontr´ ees au niveau de l’instanciation. Il s’agit d’un switch tel qu’on peut en trouver dans les NoCs matriciels.
Notre cahier des charges est le suivant :
1. le switch comporte quatre ports
1 package my noc i s
2 type p r i o r i t y p o l i c y t i s
3 ( p r i o r i t y p o l i c y a l p h a , p r i o r i t y p o l i c y b e t a , p r i o r i t y p o l i c y g a m m a ) ; 4 type s w i t c h i n t e r f a c e t i s
5 ( s w i t c h i n t e r f a c e a , s w i t c h i n t e r f a c e b ) ; 6
7 type p a c k e t h e a d e r t i s record −− . . .
8 end record;
9 type p a c k e t h e a d e r a r r a y t i s array( n a t u r a l range<>) o f p a c k e t h e a d e r t ; 10
11 function c o m p u t e p r i o r i t y a l p h a ( h d r s : p a c k e t h e a d e r a r r a y t ) return n a t u r a l ; 12 function c o m p u t e p r i o r i t y b a t a ( h d r s : p a c k e t h e a d e r a r r a y t ) return n a t u r a l ; 13 function c o m p u t e p r i o r i t y g a m m a ( h d r s : p a c k e t h e a d e r a r r a y t ) return n a t u r a l ; 14 function c o m p u t e p r i o r i t y (
15 p o l i c y : p r i o r i t y p o l i c y t ; 16 h d r s : p a c k e t h e a d e r a r r a y t 17 ) return n a t u r a l ;
18
19 type s w i t c h i n a t i s record −− . . .
20 end record;
21 type s w i t c h o u t a t i s record −− . . .
22 end record;
23 type s w i t c h i n b t i s record −− . . .
24 end record;
25 type s w i t c h o u t b t i s record −− . . .
26 end record;
27 end package; −− my noc 28
29 package body my noc i s
30 function c o m p u t e p r i o r i t y (
31 p o l i c y : p r i o r i t y p o l i c y t ; 32 h d r s : p a c k e t h e a d e r a r r a y t 33 ) return n a t u r a l i s
34 begin
35 case p o l i c y i s
36 when p r i o r i t y p o l i c y a l p h a => return c o m p u t e p r i o r i t y a l p h a ( h d r s ) ; 37 when p r i o r i t y p o l i c y b e t a => return c o m p u t e p r i o r i t y b e t a ( h d r s ) ; 38 when p r i o r i t y p o l i c y g a m m a => return c o m p u t e p r i o r i t y g a m m a ( h d r s ) ;
39 end case;
40 end;
41 −− . . .
42 end package body; −− my noc
Figure 1.4 – my noc.vhd
1 e n t i t y s w i t c h i s
2 generic( b u f f e r s i z e : n a t u r a l := 8 ;
3 p r i o r i t y p o l i c y : p r i o r i t y p o l i c y t := p r i o r i t y p o l i c y a l p h a ; 4 s w i t c h i n t e r f a c e s : array ( 3 downto 0 ) o f s w i t c h i n t e r f a c e t ;
5 ) ;
6 port( c l k : in s t d u l o g i c ;
7 r e s e t : in s t d u l o g i c ;
8 s w i t c h i n s a : in array( 3 downto 0 ) o f s w i t c h i n a t ; 9 s w i t c h o u t s a : out array ( 3 downto 0 ) o f s w i t c h o u t a t ; 10 s w i t c h i n s b : in array ( 3 downto 0 ) o f s w i t c h i n b t ; 11 s w i t c h o u t s b : out array ( 3 downto 0 ) o f s w i t c h o u t b t ;
12 ) ;
13 end e n t i t y; −− s w i t c h 14
15 a r c h i t e c t u r e r t l o f s w i t c h i s −− . . . 16 begin −− . . .
17 end; −−a r c h i t e c t u r e r t l o f s w i t c h
Figure 1.5 – switch.vhd
1 ‘ i f n d e f MY NOC VH 2 ‘ d e f i n e MY NOC VH 3
4 ‘ d e f i n e SWITCH INTERFACE A 0 5 ‘ d e f i n e SWITCH INTERFACE B 1 6
7 ‘ d e f i n e SWITCH INTERFACE A IN LENGTH 48 // e x a m p l e 8 ‘ d e f i n e SWITCH INTERFACE A OUT LENGTH 33 // e x a m p l e 9 ‘ d e f i n e SWITCH INTERFACE B IN LENGTH 36 // e x a m p l e 10 ‘ d e f i n e SWITCH INTERFACE B OUT LENGTH 33 // e x a m p l e 11
12 ‘ e n d i f // !MY NOC VH
Figure 1.6 – my noc.vh
1 module p r i o r i t i e s ( ) ; 2
3 function c o m p u t e p r i o r i t y a l p h a ; // . . . 4 endfunction;
5
6 function c o m p u t e p r i o r i t y b e t a ; // . . . 7 endfunction;
8
9 function c o m p u t e p r o i r i t y g a m m a ; // . . . 10 endfunction;
11
12 end module;
Figure 1.7 – priorities.v
1 ‘ i n c l u d e ” my noc . vh ” 2
3 module s w i t c h (
4 input c l k ,
5 input r e s e t ,
6 input [ 4∗‘SWITCH INTERFACE A IN LENGTH−1 : 0 ] s w i t c h i n s a , 7 output [ 4∗‘SWITCH INTERFACE A OUT LENGTH−1 : 0 ] s w i t c h o u t s a , 8 input [ 4∗‘SWITCH INTERFACE B IN LENGTH−1 : 0 ] s w i t c h i n s b , 9 output [ 4∗‘SWITCH INTERFACE B OUT LENGTH−1 : 0 ] s w i t c h o u t s b 10 ) ;
11
12 parameter INTERFACE1 = SWITCH INTERFACE A ; 13 parameter INTERFACE2 = SWITCH INTERFACE A ; 14 parameter INTERFACE3 = SWITCH INTERFACE A ; 15 parameter INTERFACE4 = SWITCH INTERFACE A ; 16 parameter BUFFER SIZE = 8 ;
17
18 ‘ i f n d e f COMPUTE PRIORITY 19 ‘ i n c l u d e ” p r i o r i t i e s . v ”
20 ‘ d e f i n e COMPUTE PRIORITY c o m p u t e p r i o r i t y a l p h a 21 ‘ e n d i f
22
23 // . . . 24
25 ‘ u n d e f COMPUTE PRIORITY 26 endmodule
Figure 1.8 – switch.v
2. chaque port doit pouvoir ˆ etre cˆ abl´ e de deux fa¸ cons
1, et il doit ˆ etre possible de choisir individuellement le cˆ ablage de chaque port, ind´ ependamment des autres
3. on souhaite pouvoir sp´ ecifier une politique de priorit´ e des paquets, id´ ealement via une fonc- tion d´ efinie par le designer qui instancie le bloc
4. enfin, la taille du buffer stockant les paquets en attente d’ˆ etre trait´ es doit pouvoir ˆ etre sp´ ecifi´ ee
Les listings des figures 1.4 et 1.5 permettent de se faire une id´ ee de ce que demande l’impl´ ementation d’un tel bloc en VHDL. Le caract` ere fortement typ´ e du VHDL se traduit par une certaine verbosit´ e, souvent rentabilis´ ee par un gain en clart´ e. Il y a essentiellement deux fa¸ cons de proc´ eder pour g´ erer les politiques de priorit´ es :
– La premi` ere est de se limiter ` a un ensemble de politiques, et de sp´ ecifier celle utilis´ ee en passant un param` etre g´ en´ erique. C’est ce cas qui a ´ et´ e illustr´ e sur les figures 1.4 et 1.5.
On d´ efinit deux types ´ enum´ er´ es permettant le param´ etrage de la politique de priorit´ e et des interfaces du switch, un type correspondant ` a l’information contenue dans un en-tˆ ete de paquet, et trois fonctions correspondant ` a trois politiques de priorit´ es pr´ ed´ efinies. La fonction compute priority, qui est celle qui sera utilis´ ee dans le code du switch, appellera de fa¸ con ad´ equate l’une de ces fonctions suivant le param` etre g´ en´ erique que l’utilisateur aura pass´ e ` a l’instanciation du bloc. En cons´ equence, la gestion de multiples politiques de priorit´ es ne pose pas de probl` eme, ` a condition de se cantonner ` a celles pr´ evues par le designer du switch. En effet, en VHDL’00, il n’est pas possible de passer une fonction ou un composant en argument g´ en´ erique lors de l’instanciation d’un bloc.
– Dans les cas o` u il est imp´ eratif que l’utilisateur puisse sp´ ecifier un comportement non pr´ ed´ efini, on aurait tendance ` a laisser le designer cr´ eer un bloc s´ epar´ e effectuant le calcul en question, puis ` a le raccorder au bloc ` a param´ etrer par des ports d´ edi´ es, ou bien utiliser un sous-composant ordinaire et laisser l’utilisateur en d´ efinir une nouvelle architecture, puis choisir celle-ci par le biais d’une configuration. Ces approches posent n´ eanmoins souvent probl` eme. Si on utilise un bloc s´ epar´ e, alors le bloc ` a param´ etrer ne choisit plus combien de blocs auxiliaires instancier, et les m´ ecanismes d’optimisation de l’outil de synth` ese sont potentiellement moins efficaces. De plus, la complexit´ e induite par ce nouveau cˆ ablage peut ˆ
etre significative, et constitue ´ eventuellement une source d’erreur suppl´ ementaire pour le designer. Si on utilise la m´ ethode bas´ ee sur les configurations, on s’expose potentiellement
`
a des lourdeurs si le bloc ` a param´ etrer est complexe. L’utilisateur peut en effet alors devoir sp´ ecifier la configuration pour toute la hi´ erarchie de composants sous-jacents, ce qui encore une fois peut ˆ etre source d’erreur, en plus d’exposer des d´ etails d’impl´ ementation qu’il au- rait ´ et´ e pr´ ef´ erable de cacher. De plus, le param´ etrage est s´ epar´ e de l’instanciation dans le code source, ce qui n’est pas particuli` erement logique ; cela a pour effet que l’utilisateur peut penser que le param´ etrage n’est pas possible s’il se contente de regarder les ports et les param` etres g´ en´ eriques du composant plutˆ ot que de se r´ ef´ erer ` a sa documentation (si tant est qu’elle existe).
Les interfaces entre le switch et ses voisins sont d´ efinies par le biais d’enregistrements. Il s’agit d’un motif de conception fr´ equent dans les mod` eles VHDL, dont l’utilit´ e principale est de r´ eduire la verbosit´ e de l’instanciation d’un composant. ´ Etant donn´ e le caract` ere g´ en´ eral du langage, l’impl´ ementation d’un bloc synth´ etisable implique de se borner ` a un sous-ensemble du VHDL.
G´ en´ eralement, on utilise pour cela deux processus, l’un dit synchrone sensible aux fronts d’horloge, et l’autre dit combinatoire sensible aux sorties des bascules [26]. Alternativement, certains outils de synth` ese [75] acceptent en entr´ ee un design contenant des processus parsem´ es d’instructions du type wait until rising edge(clk), la cr´ eation de registres correspondant aux variables et la construction des machines ` a ´ etat sous-jacentes aux diff´ erents processus devenant implicites. Dans tous les cas, il est important (et souvent non trivial) de savoir o` u commence et o` u s’arrˆ ete le
1. on peut par exemple supposer que l’on souhaite pouvoir connecter les switchs en point-`a-point, mais ´egalement les relier `a un bus standard tel que AMBA [1] ; si les interfaces sont suffisamment diff´erentes, il n’est effectivement pas rentable du point de vue des performances d’utiliser un simple bloc convertisseur, comme on le fait souvent pour justement ´eviter les probl`emes d’instanciation li´es aux composants aux interfaces param´etrables
sous-ensemble synth´ etisable par l’outil. Malgr´ e l’omnipr´ esence du VHDL dans le monde de l’EDA, un certain nombre de pratiques sous-optimales sont courantes, comme l’usage des types r´ esolus ou du reset asynchrone [46].
Les listings des figures 1.6 ` a 1.8 illustrent le mˆ eme bloc mais cette fois mod´ elis´ e en Verilog.
Contrairement ` a VHDL,Verilog a ´ et´ e en premier lieu pens´ e comme un langage de simulation plutˆ ot que de formalisation de cahiers des charges. En cons´ equence, il est plus concis et emprunte beaucoup aux langages d’ing´ enierie logicielle tels que le C. Le syst` eme de typage est par contre minimaliste pour ne pas dire pauvre, puisqu’il se limite ` a de la logique 4-´ etats, sans possibilit´ e pour l’utilisateur de d´ efinir de nouveaux types ou sous-types de donn´ ees.
Comme on peut le voir ` a la figure 1.8, en l’absence d’enregistrements, on passe de longues chaˆınes de bits qu’on va
d´ es´ erialiser
` a l’int´ erieur du bloc pour limiter le nombre de ports.
Verilog est dot´ e d’un m´ ecanisme de param` etres qu’il est possible de surcharger, fonctionnant comme l’´ equivalent des param` etres g´ en´ eriques avec valeur par d´ efaut du VHDL. Comme il n’est pas non-plus possible de passer de tˆ ache, fonction ou module en param` etre par cette voie l` a, nous allons avoir recours au pr´ eprocesseur. Verilog ne pr´ evoit aucun m´ ecanisme de compilation s´ epar´ ee ; le moyen adopt´ e pour r´ eutiliser du code est justement son inclusion via des directives du pr´ eprocesseur. Ce pr´ eprocesseur est tr` es similaire ` a celui du C ANSI, en un peu plus rudimentaire (de par la non-possibilit´ e de d´ efinir des macros acceptant des arguments, ou l’absence de certaines directives telles que #warning ou #error). Les pratiques recommand´ ees dans son utilisation [90]
empruntent partiellement au C, ` a ceci pr` es que l’inclusion en milieu de fichier est nettement plus courante. Dans notre exemple, nous avons utilis´ e une technique inspir´ ee des x-macros du C (parfois appel´ ees supermacros [14]) pour param´ etrer de facto notre bloc par une politique de priorit´ es. Avant d’inclure le fichier
switch.v
, l’utilisateur a la possibilit´ e de sp´ ecifier sa propre fonction de priorit´ e en associant son nom ` a la macro COMPUTE PRIORITY. Si cette macro n’est pas d´ efinie ` a l’inclusion de
switch.v
, elle prend comme valeur par d´ efaut l’une des fonction de priorit´ e pr´ ed´ efinies.
Mentionnons au passage l’existence de System Verilog [6], qui dispose d’une syntaxe proche de celle de Verilog mais offre la possibilit´ e de d´ efinir des types ´ enum´ er´ es et des enregistrements, dispose d’un syst` eme de classes, et d’un assez grand nombre d’autres ajouts, principalement destin´ es ` a la simulation. Si nous avions voulu impl´ ementer notre switch en System Verilog, la fa¸ con la plus propre de faire aurait ´ et´ e de d´ efinir les politiques de priorit´ e comme descendantes d’une classe abstraite. Le design r´ esultant n’aurait n´ eanmoins pas ´ et´ e synth´ etisable.
Enfin, le lecteur attentif aura remarqu´ e que les standards VHDL et Verilog cit´ es plus haut sont ceux de 2000 et 2001, respectivement. Ce choix est dˆ u au fait que l’essentiel du code ´ ecrit de nos jours dans ces langages se conforme ` a ces versions des standards. Cela dit, certaines des faiblesses mentionn´ ees dans cette section ont ´ et´ es corrig´ ees en totalit´ e ou en partie dans les versions subs´ equentes [43, 44], qui ne sont h´ elas pas encore support´ ees par la vaste majorit´ e des outils d’EDA r´ epandus. Notablement, VHDL’08 autorise le passage de fonctions et de types par le biais de param` etres g´ en´ eriques. Ces ´ evolutions semblent s’inscrire dans une tendance plus g´ en´ erale ` a l’ajout d’´ el´ ements fonctionnels dans les versions r´ ecentes ou ` a venir des langages de programmation, illustr´ ee par exemple par l’incorporation d’inf´ erence de types ou de lambda expressions dans les langages Java [30] et C++ [15, 47].
1.2.2 Fichiers annexes, annotations du source, g´ en´ eration
Une fa¸ con de faciliter le travail d’instanciation de quantit´ es significatives de composants est
d’avoir recours ` a des informations fournies par le designer sous une forme alternative ou addi-
tionnelle plus appropri´ ee que celle des HDL classiques. Cela peut se faire soit par l’utilisation de
fichiers annexes (souvent dans des formats dont l’analyse syntaxique est simple et capables d’or-
ganiser les donn´ ees sous forme de hi´ erarchies ou des graphes, comme par exemple XML ou UML ;
MARTE [9, 22] est un exemple particuli` erement notable de telle approche pour la mod´ elisation
niveau syst` eme), soit par le biais d’annotations ins´ er´ ees dans le code source par le biais de direc-
tives (par exemple, #pragma en C) ou de commentaires sp´ ecialement format´ es. Ces informations
seront ensuite utilis´ ees pour produire des netlists, du code HDL interm´ ediaire, etc.
Un exemple tr` es caract´ eristique d’une telle approche est Xilinx Platform Studio (XPS) et les outils associ´ es. Les composants constituant le syst` eme que le designer d´ ecrit sont encapsul´ es puis instanci´ es via un fichier MHS (Microprocessor Hardware Specification) qui sera ensuite utilis´ e par Platgen (le g´ en´ erateur de plateformes) au cours de la cr´ eation du bitstream. Il est possible de param´ etrer de cette fa¸ con chaque bloc instanci´ e, y compris dans la fa¸ con dont il est connect´ e au reste du monde. Il en r´ esulte une sp´ ecification des composants instanci´ es plus concise et plus sˆ ure (un cˆ ablage incoh´ erent pouvant ˆ etre d´ etect´ e par l’outil). Platgen permet ´ egalement de g´ erer de fa¸ con coh´ erente ` a l’´ echelle du syst` eme l’espace d’adressage tel qu’il sera vu par les microprocesseurs (et donc les drivers). En revanche, il est toujours impossible de param´ etrer un bloc par une fonction, un autre bloc, etc.
La g´ en´ eration de code interm´ ediaire ` a partir d’information sur la topologie des interconnexions est ´ egalement particuli` erement utilis´ ee dans le cas des NoCs. C’est par exemple le cas du NoC Arteris. Le terme Arteris d´ esigne un tout comportant ` a la fois la biblioth` eque de composants permettant de construire le r´ eseau sur puce ` a proprement parler, le protocole que ces composants vont utiliser pour communiquer, et l’outil permettant l’instanciation du r´ eseau sur puce. ` A partir de la liste des composants ` a interconnecter et de leurs interfaces (potentiellement h´ et´ erog` enes), cet outil produit une repr´ esentation du NoC sous forme de fichiers IP-XACT [45, 57], un format de description de design bas´ e sur l’XML et destin´ e ` a ˆ etre utilis´ e directement par les outils d’EDA.
Il ne faut ´ egalement pas n´ egliger les approches qui
d´ etournent
de leur usage des langages de programmation logicielle pour d´ ecrire du mat´ eriel. Il y a dans ces cas deux fa¸ cons possibles de proc´ eder : ´ ecrire puis utiliser un compilateur capable de traduire le langage en question sous une forme exploitable (par exemple, VHDL interm´ ediaire) ou faire en sorte d’obtenir le r´ esultat souhait´ e directement en ex´ ecutant le programme compil´ e via un compilateur classique. Dans la premi` ere cat´ egorie, on peut notablement citer un certain nombre d’outils dont l’optique est d’u- tiliser le C comme un HDL : ImpulseC de Impulse Accelerated Technologies, PICO de Synfora, ou encore Catapult C de Mentor Graphics en sont trois exemples. L’utilisation du C dans le domaine de l’EDA est motiv´ ee par son caract` ere relativement bas niveau d’une part et l’omnipr´ esence de ce langage dans l’ing´ enierie logicielle d’autre part. Ultimement, si un mˆ eme langage peut ˆ etre utilis´ e pour d´ ecrire le mat´ eriel comme le logiciel, on peut ´ egalement esp´ erer automatiser le partition- nement mat´ eriel/logiciel, puisque le mˆ eme code pourra ˆ etre utilis´ e pour d´ ecrire les deux. Il existe
´
egalement des exemples d’outils prenant en entr´ ee d’autres langages, tels que Matlab.
Parmi les m´ ethodes ne n´ ecessitant pas de compilateur particulier, en dehors de celles bas´ ees sur les langages fonctionnels et qui seront d´ etaill´ ees dans la section suivante, on citera (sans ˆ etre exhaustif) SystemC et Ptolemy II. SystemC [5] est un cas un peu particulier, puisqu’il existe des outils de synth` ese analysant lexicallement et syntaxiquement du code SystemC en vue de produire une netlist ou des binaires utilisables par un simulateur. Cependant, l’un des buts premiers du SystemC a ´ et´ e d’offrir un environnement de simulation sous forme de biblioth` eque et runtime C++
classique, de sorte ` a ce que les mod` eles comportementaux de composants puissent incorporer du code C++ ordinaire ou faire appel ` a du code objet existant. En termes de niveau d’abstraction, SystemC laisse dans une certaine mesure le choix au designer qui peut opter pour des mod` eles clock´ es, du TLM, etc. Des approches cherchant ` a doter SystemC de MoCs aux propri´ et´ es plus sp´ ecifiques peuvent ´ egalement ˆ etre d´ enombr´ ees [37, 74]. Ptolemy II [84] est, quant ` a lui, bas´ e sur Java. Il se compose d’une riche biblioth` eque de classes correspondant entre autres ` a un jeu de composants se comportant comme de boites noires, et ` a un ensemble diversifi´ e de mod` eles de calcul. Le programmeur peut utiliser Java pour sp´ ecifier son design, en raccordant les composants entre eux, voire en en d´ efinissant de nouveaux si n´ ecessaire. Il est ´ egalement possible de d´ efinir le design par le biais d’un front-end graphique, ainsi que du langage MoML, bas´ e sur XML et propre
`
a Ptolemy II, ce qui le rapproche un peu des m´ ethodes ´ evoqu´ ees dans les paragraphes pr´ ec´ edents.
1.3 Description de mat´ eriel et programmation fonctionnelle
Dans cette section, nous allons passer en revue quelques unes des diff´ erentes approches ex-
istantes pour la sp´ ecification et la v´ erification de mat´ eriel utilisant dans langages fonction-
nels. Si nous insistons plus particuli` erement sur cette classe de m´ ethodes, c’est parce que notre m´ ethodologie, qui sera expos´ ee dans les chapitres subs´ equents de ce manuscrit, s’inscrit dedans (comme nous le verrons un peu plus loin).
D’une fa¸con g´ en´ erale, outre leur ad´ equation pour la description de constructions parall` eles, l’int´ erˆ et de l’utilisation de langages fonctionnels typ´ es pour la description de mat´ eriel [61, 88, 89]
r´ eside dans leur ad´ equation pour manipuler le genre de repr´ esentations de donn´ ees successible d’apparaˆıtre dans ce domaine. Le pattern matching rend l’expression de transformations de graphes ais´ ee, et le lambda-calcul permet la construction de biblioth` eques de combinateurs efficaces et flexibles. De plus, les techniques telles que la compilation dynamique, la construction de langages embarqu´ es et la quasi-quotation (qui permet ` a l’utilisateur de d´ efinir sa propre syntaxe pour certaines parties du programme) trouvent leur utilisation naturellement dans la description de mat´ eriel ou dans les domaines connexes tels que la simulation. Enfin, la possibilit´ e de construire facilement des langages embarqu´ es autorise ´ egalement le programmeur ` a se d´ efinir ses propres boˆıtes ` a outils adapt´ ees ` a la r´ esolution de certaines classes de probl` emes.
1.3.1 Description de mat´ eriel
1.3.1.1 Bluespec SystemVerilog
Bluespec SystemVerilog (BSV) [2,10] est un langage de description de mat´ eriel fonctionnel tr` es proche de Haskell, mais dot´ e de constructions et mots cl´ es propres ` a la repr´ esentation de circuits sous forme RTL. Il s’agit probablement de l’approche fonctionnelle la plus connue dans le domaine de l’EDA. Le compilateur Bluespec est un outil commercial, et accepte en entr´ ee SystemVerilog en plus du langage BSV. Il est important de noter que, malgr´ e son nom, le langage BSV ne partage avec SystemVerilog qu’une similarit´ e syntaxique superficielle, et n’est absolument pas compatible avec lui au niveau du code source (il est cependant possible de m´ elanger des unit´ es de compilation BSV et SystemVerilog dans un mˆ eme design).
BSV constitue un bon exemple permettant de comprendre l’int´ erˆ et de l’utilisation de combina- teurs dans le domaine du design mat´ eriel. G´ en´ eralement, les descriptions BSV sont plus concises et moins propices aux erreurs que leurs ´ equivalents dans les approches imp´ eratives ou d´ eclaratives classiques. Cela est dˆ u ` a un ensemble de facteurs. Le comportement de circuits est d´ etermin´ e par un ensemble de r` egles (rang´ ees par modules) qu’il est possible de composer et de traiter ais´ ement.
BSV est accompagn´ e d’une biblioth` eque de types/composants utilisant judicieusement les possi- bilit´ es du langage et aidant ` a r´ eduire au maximum la quantit´ e de logique de contrˆ ole exprim´ ee par l’utilisateur, lui permettant de se focaliser sur la fonctionnalit´ e du circuit. Notons en outre que BSV est apte ` a r´ epondre au cahier des charges que nous nous sommes fix´ es pour le design du switch de la section 1.2.1. En particulier, la politique de gestion des priorit´ es peut ˆ etre pass´ e directement ` a l’instanciation du switch soit par le biais du type Action, soit par le biais du type Rules, tous deux d´ efinis par le langage et utilisables au mˆ eme titre que les plus classiques Bit#(n), Int#(n), etc.
1.3.1.2 Lava
Lava [17] est une autre approche fonctionnelle au niveau RTL. Il s’agit cette fois d’une simple biblioth` eque Haskell d´ efinissant des types ad´ equats pour la repr´ esentation de portes logiques et des fonctions permettant leur manipulation. Il est ainsi possible de simuler, de v´ erifier et de g´ en´ erer du code interm´ ediaire ` a partir des designs. Comme Lava peut ˆ etre pr´ esent´ e comme un langage dans un langage, on parle d’EDSL (Embedded Domain Specific Language). La sp´ ecification des designs eux mˆ emes se fait via l’utilisation d’un petit nombre de blocs ´ el´ ementaires type portes logiques (and2, or2, inv, etc.) raccord´ es par le biais d’op´ erateurs ou de fonctions (souvent appel´ ees de fa¸ con infixe en pratique), tels que >->, permettant de s´ erialiser deux blocs, ou par2, les mettant en parall` ele.
Ce genre de description niveau
porte
peut sembler excessivement proche du mat´ eriel, mais une
utilisation judicieuse de fonctions d’ordre sup´ erieur, aussi bien celles offertes par Lava que celles
du pr´ elude Haskell (c.f. section A.5) ou celles d´ efinies par l’utilisateur, lui enl` eve beaucoup de
sa lourdeur. Le fait de passer des blocs (ou des fonctions retournant des blocs) en arguments ` a d’autres est un des aspects centraux et idiomatiques de la philosophie du langage (donc, l` a aussi, nous n’aurions pas eu de probl` emes pour instancier notre switch).
Parmi les variantes de Lava existantes, certaines, dont celle de Xilinx, font usage du polymor- phisme via le syst` eme de classes de types de Haskell afin d’interpr´ eter diff´ eremment chaque design en fonction de la tˆ ache ` a r´ ealiser. Les primitives (portes, fonction se s´ erialisation, etc.) sont d´ efinies dans des classes dont les instances vont correspondre aux types de donn´ ees n´ ecessaires pour simuler, v´ erifier, ou g´ en´ erer du code interm´ ediaire ` a partir du design. Ces classes sont monadiques
2, no- tamment parce que les monades sont un excellent moyen d’abstraire les d´ etails de fonctionnement interne d’un langage embarqu´ e dont les constructions peuvent pr´ esenter des effets de bord [97].
1.3.1.3 ForSyDe
ForSyDe (Formal System Design) [82] est, tout comme Lava, un EDSL bas´ e sur Haskell. Con- trairement aux deux approches pr´ ec´ edentes, ForSyDe offre plusieurs mod` eles de calcul d´ efinissant les modalit´ es et contraintes de communication entre processus. On d´ enombre ainsi un MoC syn- chrone, un MoC sans horloge, et un MoC d´ edi´ e aux signaux continus (par opposition aux signaux binaires). Il est possible de simuler ou de g´ en´ erer du code VHDL ` a partir des designs.
La particularit´ e de ForSyDe est de reposer sur un certain nombre d’extensions de Haskell support´ ees par le compilateur GHC (Glasgow Haskell Compiler), ` a savoir les classes de types
`
a arit´ e sup´ erieure ` a un, la surcharge d’instances, mais aussi et surtout Template Haskell (TH).
Les deux premi` eres sont de facto accept´ ees au sein de la communaut´ e de Haskell (elles sont en particulier impl´ ement´ ees par Hugs, l’autre compilateur Haskell majeur) ; la derni` ere, TH, est sp´ ecifique ` a GHC version 6 et subs´ equentes, et permet la r´ eflexion et la compilation dynamique. Le design sp´ ecifi´ e par l’utilisateur n’est pas ´ evalu´ e, comme en Lava, mais est imm´ ediatement converti en arbre syntaxique abstrait qui va ensuite ˆ etre transform´ e vers ce que l’on cherche ` a en obtenir : soit une fonction de simulation compil´ ee dynamiquement, soit du code VHDL interm´ ediaire.
1.3.1.4 SML-Sys
SML-Sys [61] est une approche orient´ ee vers la simulation et impl´ ement´ ee dans le langage Standard ML, un langage fonctionnel impur [62]. Contrairement aux approches pr´ ec´ edentes, il n’est pas possible de g´ en´ erer du code ` a partir de designs exprim´ es via SML-Sys. L’atout majeur de l’approche r´ eside dans sa capacit´ e ` a g´ erer des designs sp´ ecifi´ es dans une grande vari´ et´ e de mod` eles de calcul pouvant communiquer entre eux. L’int´ erˆ et du paradigme fonctionnel dans ce contexte r´ eside essentiellement dans la tr` es claire s´ eparation entre la partie communication et calcul du design.
1.3.1.5 CλaSH
CλaSH [13] est une m´ ethode de conception de circuits synchrones bas´ ee sur le langage Haskell.
Contrairement ` a Lava ou ` a ForSyDe, qui sont des langages embarqu´ es ayant vocation ` a ˆ etre utilis´ es en conjonction avec des compilateurs ou interpr´ eteurs classiques tels que GHC ou Hugs, CλaSH utilise un compilateur s´ epar´ e sp´ ecifique. Cela lui permet de synth´ etiser les
structures de contrˆ ole
natives de Haskell telles que les clauses if-then-else ou le pattern matching. Le r´ esultat est un code tr` es concis et peu propice aux erreurs.
1.3.2 V´ erification formelle
1.3.2.1 M´ ethodes classiques
D’ores et d´ ej` a, il convient de mentionner l’existence ou la possibilit´ e d’utiliser des proc´ ed´ es de v´ erification formelle
classiques
dans les paradigmes fonctionnels. C’est en particulier le cas dans Lava, qui permet la v´ erification de propri´ et´ es de circuits combinatoires en testant toutes
2. Le principe des monades est rappel´e section A.4.
les combinaisons d’entr´ ees possibles. Ce genre de proc´ ed´ e exhaustif est bien sˆ ur limit´ e aux cir- cuits de faibles tailles. Il existe d’autres algorithmes permettant d’effectuer de la v´ erification ou du test d’´ equivalence au niveau netlist et capables de prendre en compte l’existence d’´ el´ ements m´ emorisants (par exemple, [49]) qui pourraient ˆ etre ais´ ement mis en œuvre dans le contexte de la programmation fonctionnelle. Par ailleurs, les outils d’EDA existants peuvent ˆ etre utilis´ es si une approche fonctionnelle donn´ ee est capable de produire du code interm´ ediaire.
1.3.2.2 M´ ethodes bas´ ees sur le syst` eme de types
La correspondance de Curry-Howard est le constat qu’en lambda-calcul typ´ e, un type et une fonction s’y conformant se comportent exactement comme une formule et sa preuve [39]. Il en r´ esulte qu’un syst` eme de types suffisamment expressif peut servir ` a d´ efinir et ` a prouver toutes les propri´ et´ es exprimables dans une large vari´ et´ e de syst` emes logiques.
Ce constat a motiv´ e le d´ eveloppement de langages sensiblement plus richement typ´ es que ceux auxquels on est habitu´ es. Une raison pour laquelle les langages conventionnels se cantonnent aux types alg´ ebriques et ` a leurs variantes est que les algorithmes de v´ erification de types s’ex´ ecutent alors en temps born´ es (et terminent forc´ ement). De plus, les algorithmes d’inf´ erence de types, tels que celui de Hindley-Minler (tr` es proche de celui utilis´ e par Haskell), ne fonctionnent que sur des types alg´ ebriques ou certaines de leurs g´ en´ eralisations qui restent simples. Les langages construits autour de types plus complexes partent du postulat que les gains offerts par ces types exc` edent les d´ esavantages pr´ ec´ edemment mentionn´ es.
Il existe des langages fonctionnels sp´ ecialis´ es dans la preuve de th´ eor` emes, tels que Agda [68]
ou encore Coq [94]. Ces langages sont dot´ es de biblioth` eques standards dont l’utilit´ e premi` ere est d’aider ` a la r´ edaction de preuves. On peut conjecturer que des biblioth` eques de ce genre de constructions pourraient ˆ etre impl´ ement´ ees dans tous les langages disposant d’un syst` eme de types suffisamment riche.
Cayenne [12] est un exemple de langage de programmation ` a usage g´ en´ eral permettant le typage d´ ependant (c.-` a-d. autorisant le param´ etrage des types par des valeurs, et non plus seulement par d’autres types). Sa syntaxe emprunte des ´ el´ ements aux langages fonctionnels les plus r´ epandus (Haskell, ou dans une moindre mesure Standard ML) comme aux langages imp´ eratifs et objets (C/C++, Java). Les types d´ ependants accroissent consid´ erablement l’expressivit´ e d’un syst` eme de types dans la mesure o` u ils ´ equivalent ` a l’usage de propositions quantifi´ ees dans les formules que les types expriment, mais aussi se traduisent plus simplement par une plus grande libert´ e offerte au programmeur dans l’organisation de son code tout en lui garantissant une s´ ecurit´ e de typage maximale, un avantage qu’il ne faut pas n´ egliger.
Enfin, citons Ωmega [86], un exemple de langage fonctionnel richement typ´ e qui peut ˆ etre utilis´ e pour la description de mat´ eriel [85,87]. Ωmega permet de d´ efinir des fonctions dans l’espace des types comme dans celui des donn´ ees. Bien qu’il ne s’agisse pas techniquement de typage d´ ependant, les possibilit´ es de Ωmega en sont quasi-identiques dans la mesure o` u il suffit de traiter les types comme des valeurs pour arriver ` a des fins similaires. La cat´ egorisation est hi´ erarchique (autrement dit, il est possible de d´ efinir des
types de types
, par exemple). Une grande partie de la syntaxe du langage lui mˆ eme et nombre de ses caract´ eristiques proviennent de Haskell. En particulier, Ωmega dispose des mˆ emes raccourcis syntaxiques que Haskell pour faciliter l’´ ecriture de monades, et d’une syntaxe de m´ etaprogrammation calqu´ ee sur celle de Template Haskell. En plus de prouver la correction des diff´ erentes parties du design, les types dans Ωmega peuvent en plus servir ` a garantir d’autres propri´ et´ es, telles que la conformit´ e du design ` a des contraintes de taille ou de consommation, par exemple.
1.4 Exploration architecturale
La recherche en exploration architecturale va essentiellement dans deux directions distinctes
mais compl´ ementaires : le parcours de l’espace de design et l’´ evaluation des performances. L’espace
de design peut ˆ etre parcouru manuellement, automatiquement ou suivant une approche mˆ elant
les deux. L’´ evaluation de performances doit ˆ etre aussi rapide et pr´ ecise que possible. Elle peut ˆ
etre r´ ealis´ ee en simulant ou en ´ emulant le design (auquel cas les performances mesur´ ees sont exactes), ou bien extraite ` a partir d’un mod` ele simplifi´ e. Il est important de noter que, pour une efficacit´ e maximale, l’exploration architecturale doit concerner aussi bien la composante mat´ erielle que logicielle d’un syst` eme, si tant est qu’on puisse influer sur les deux [78].
Le parcours de l’espace de design, lorsqu’il est automatis´ e, peut ˆ etre exhaustif ou localement exhaustif dans les cas o` u le temps n´ ecessaire pour ´ evaluer les performances est suffisamment court.
Un exemple de telle approche est [79], pr´ esentant une m´ ethode de recherche de topologie optimale de r´ eseau sur puce qui teste toutes les combinaisons possibles et utilise un mod` ele d’´ evaluation des performances tr` es agressif permettant de passer ` a peine quelques secondes sur une configuration donn´ ee. [27], quant ` a lui, pr´ esente une approche pour configurer les SoCs param´ etr´ es, en les partitionnant ` a l’aide d’un graphe de d´ ependances pr´ ealablement construit puis en effectuant une recherche exhaustive sur chaque partie.
Lorsqu’un parcours exhaustif est trop coˆ uteux, ou lorsque l’on souhaite tout simplement r´ eduire la dur´ ee de l’exploration, on a tendance ` a avoir recours ` a des m´ ethodes stochastiques. Les algo- rithmes g´ en´ etiques semblent ˆ etre le plus fr´ equemment utilis´ es dans ces cas l` a. On pourra notam- ment citer [11] pour la configuration de SoCs, [93] pour celle des hi´ erarchies m´ emoires, [18] qui concerne plus particuli` erement la synth` ese des DSP, etc. Les algorithmes g´ en´ etiques (tout comme d’autres m´ ethodes stochastiques telles que le recuit simul´ e) interviennent aussi au moment du map- ping sur la technologie cible ; [53] r´ esume certaines de ces techniques dans le contexte des FPGA.
Enfin, il est int´ eressant de noter que ce genre de m´ ethodes peut ´ egalement servir ` a d´ eterminer les param` etres et options optimales des outils de synth` ese et des compilateurs utilis´ es, en fonction des crit` eres recherch´ es.
En terme d’´ evaluation des performances, en plus des simulations ` a l’´ echelle du syst` eme, on peut
´
enum´ erer des approches aussi diverses que l’extraction des param` etres des composants individuels (processeurs, bus, etc.) via simulation cycle accurate dans le but d’en extraire des mod` eles plus simples, ensuite utilis´ es pour simuler le SoC entier [27], ou bien celles permettant de mapper un design de taille importante sur un ou plusieurs FPGAs [98].
Pour pouvoir mener l’exploration ` a son terme, il faut avoir un id´ ee des aspects que l’on souhaite
optimiser. ` A chaque design correspond un compromis entre fonctionnalit´ e, quantit´ e de logique
n´ ecessaire, puissance consomm´ ee, etc. Ce compromis peut ˆ etre trouv´ e en informant l’outil des
contraintes de place, de consommation, etc., ou bien en faisant en sorte que l’outil se contente de
g´ en´ erer de logs permettant au designer de r´ ealiser lui-mˆ eme les choix architecturaux.
M´ ethodologie propos´ ee
2.1 Objectifs
Afin de r´ epondre aux besoins sp´ ecifiques qu’impose la conception de SoCs complexes, nous proposons une m´ ethodologie de design originale. Nous nous sommes pour cela fix´ es un certain nombre d’objectifs ` a atteindre. ` A notre connaissance, aucune des m´ ethodes de design actuelles ne satisfait simultan´ ement et de fa¸ con acceptable ` a tous ces objectifs.
2.1.1 Instanciation et explorabilit´ e
Un des probl` emes majeurs du design d’un SoC, comme nous l’avons vu au chapitre pr´ ec´ edant, est le param´ etrage des blocs mat´ eriels h´ et´ erog` enes qu’il comporte. Nous partons du principe qu’il est de moins en moins acceptable de demander au concepteur de comprendre l’implication qu’aura le param´ etrage d’un bloc en particulier sur le reste du syst` eme. Face ` a ce constat, nous avons pris le parti de :
– int´ egrer la possibilit´ e pour le designer d’exprimer les diff´ erentes impl´ ementations alternatives d’un bloc IP via des primitives pr´ evues ` a cet effet
– fournir ` a l’utilisateur un certain nombre de m´ ethodes d’exploration architecturale afin de parcourir l’espace de design ainsi obtenu
Les m´ ethodes d’exploration en question peuvent ˆ etre automatiques ou manuelles, comme on le verra plus loin. Afin d’acc´ el´ erer l’´ etape d’exploration de l’espace de design, le designer pourra pond´ erer les alternatives en fonction de la probabilit´ e qu’il estime que chacune d’entre elle a d’ˆ etre le choix optimal. Il s’agit d’une mesure heuristique qu’il peut s’il le d´ esire ignorer, en affectant un poids identique ` a toutes.
Un corollaire de tout cela est que l’utilisateur peut utiliser des blocs mat´ eriels comme des boˆıtes noires et esp´ erer que l’algorithme d’exploration stochastique qu’il aura choisi d’utiliser les param` etre correctement. Un autre corollaire, et non des moindres, est qu’il sera facile de faire en sorte que la topologie des interconnexions soit explor´ ee en mˆ eme temps que les IPs sont param´ etr´ ees, de sorte ` a ce qu’elle soit adapt´ ee au trafic que vont g´ en´ erer les blocs une fois configur´ es. C’est un ´ el´ ement fondamental permettant une v´ eritable int´ egration des communica- tions au sein de la conception syst` eme. Proc´ eder autrement a tendance ` a produire des goulots d’´ etranglement r´ eduisant s´ ev` erement les performances globales du syst` eme.
L’utilisation d’algorithmes d’exploration automatique implique bien sˆ ur que l’utilisateur four- nisse une fonction de coˆ ut ` a maximiser
1.
1. On pourrait aussi envisager une optimisation multiobjectif produisant un ensemble de param´etrages appar- tenant `a la fronti`ere de Pareto (ce que nous ne ferons pas pour rester dans des cas simples) ; en tout cas, il faut que l’utilisateur donne un moyen `a l’algorithme pour ´evaluer un param´etrage donn´e.
