un seul nœud codant l’instruction du processeur utilis´ee. Le compilateur standard du processeur extensible se base ensuite sur cette repr´esentation pour effectuer l’allocation des registres et l’ordon- nancement.
Cependant, l’algorithme d’ordonnancement du GPP hˆote ne tient g´en´eralement pas compte du parall´elisme entre l’extension et le GPP hˆote. Pour pallier cette insuffisance, il est possible d’utiliser un algorithme d’ordonnancement sp´ecifique g´en´er´e `a partir de la description de l’architecture et du jeu d’instructions du processeur [118,191,33] (dans un langage ADL15 comme LISA [89]) ou encore
de n’utiliser l’ordonnancement du compilateur que pour des zones de code o`u aucune instruction sp´ecialis´ee n’est utilis´ee. Dans ce cas, une nouvelle version du code de l’application est g´en´er´ee ou ´ecrite par le concepteur : pour chaque zone optimis´ee par des ISE, l’ordonnancement des instructions est d´ecrit explicitement par une s´equence d’instructions assembleur en ligne qui ne sera pas analys´ee par le compilateur.
1.2
Conception d’une extension mat´erielle
Concevoir un ASIP consiste, par d´efinition, `a analyser une ou plusieurs applications qui corres- pondront `a la cible logicielle du processeur. C’est cette analyse qui permettra d’explorer les multiples possibilit´es architecturales afin de r´epondre aux besoins de l’application ainsi qu’aux contraintes ma- t´erielles du produit. L’objectif de cette section est de pr´esenter l’int´erˆet et le principe d’un flot de conception ASIP reposant sur une exploration it´erative des nombreux param`etres `a ´evaluer.
1.2.1
Conception par exploration
Quels que soient l’architecture du processeur et le niveau de conception (i.e., compl`ete ou partielle) d’un ASIP, la compilation de l’application sur le processeur constitue le cœur de la probl´ematique. En effet, comme ´evoqu´e dans la sous-section1.1.2, c’est lors de la compilation que sont s´electionn´ees les instructions du processeur. C’est donc uniquement apr`es cette ´etape que l’architecture concr`ete du processeur pourra ˆetre d´efinie. Ces informations permettront alors au concepteur d’´evaluer la pertinence des instructions s´electionn´ees et leur ad´equation avec les diff´erentes contraintes applicatives et architecturales.
Il est aujourd’hui admis qu’un flot de conception ASIP ne peut pas ˆetre enti`erement automa- tis´e [92]. En effet, l’espace des possibilit´es architecturales est trop vaste et complexe pour ˆetre enti`e- rement mod´elis´e par des fonctions de coˆut qui sont pourtant les seuls moyens de quantifier la qualit´e de choix automatiques. Il s’agit plutˆot d’identifier un compromis acceptable, en fonction du contexte applicatif et mat´eriel, entre les crit`eres de performance et les coˆuts en surface et en consommation. Un tel choix ne peut raisonnablement reposer que sur l’expertise du concepteur et l’objectif des outils est alors d’automatiser la compilation tout en laissant au concepteur la possibilit´e de d´efinir un cadre architectural en ad´equation avec ses exigences et contraintes.
Pour r´epondre au mieux `a cette probl´ematique, les m´ethodologies de conception d’ASIP s’appuient sur un processus cyclique [77,99,47,74] qui assiste le concepteur `a atteindre un compromis satisfai- sant par une exploration it´erative de l’espace de conception. Les principales ´etapes de ce processus de
22 Chapitre 1. Contexte et ´etat de l’art sur l’extension de jeux d’instructions Compilation Analyse de l'application Exploration architecturale Génération de code Évaluation/ Simulation/ Synthèse Selection de code Ordonnancement Génération / Extension du jeu d'instruction Allocation registres Concepteur
Figure 1.8 – Conception assist´ee d’un ASIP par exploration.
conception peuvent ˆetre r´esum´ees par la figure1.8. Tout d’abord, le concepteur analyse l’application pour identifier les parties critiques et en d´eduire les mod`eles d’architecture et d’ex´ecution (e.g., SIMD, VLIW, etc.) qui lui semblent les plus adapt´es pour le futur processeur sp´ecialis´e. Les caract´eristiques issues de cette exploration architecturale sont alors utilis´ees par le compilateur ASIP qui s´electionne les instructions du processeur et produit un code assembleur exploitable par l’architecture. La des- cription mat´erielle de cette derni`ere peut ˆetre g´en´er´ee `a partir du mod`ele architectural retenu lors de l’´etape pr´ec´edente et des instructions s´electionn´ees. Les informations obtenues sur les performances de l’application (par simulation [47,74] ou par ´evaluation d’une fonction de coˆut) combin´ees `a celles issues de la synth`ese de la description mat´erielle du processeur permettront au concepteur d’´etablir si le compromis entre les performances de l’application et les contraintes mat´erielles est acceptable. Si ce n’est pas le cas, le processus de conception sera raffin´e par une nouvelle exploration. Une fois que le concepteur est satisfait des performances et de l’architecture, le processus est termin´e.
1.2.2
Couplage de l’extension mat´erielle au processeur
Dans le cas d’un processeur extensible, la premi`ere ´etape de l’exploration architecturale consiste `a choisir un couplage entre l’extension mat´erielle et le GPP hˆote :
• Couplage fort (e.g., OneChip [192] ou Chimaera [203]). L’extension mat´erielle est assimil´ee `a une nouvelle unit´e fonctionnelle connect´ee au chemin de donn´ees du GPP hˆote. Elle acc`ede directement `a sa file de registres pour lire les op´erandes et ´ecrire les r´esultats des ISE et le coˆut des communications entre le processeur et l’extension est n´egligeable.
1.2. Conception d’une extension mat´erielle 23 • Couplage lˆache (e.g., Microblaze [199,22] ou S6000 [174] ). L’extension mat´erielle peut ´egale- ment communiquer avec le processeur hˆote par l’interm´ediaire de m´emoires et ´eventuellement en utilisant un DMA16, les ISE sont g´en´eralement de taille plus importante que pour un cou- plage fort. Si une communication utilise une m´emoire, son coˆut n’est plus n´egligeable et d´epend de la technologie utilis´ee.
• Coprocesseur (e.g., GARP [86] ou ADRES [131]). L’ind´ependance de l’extension mat´erielle est ´elev´ee : elle dispose g´en´eralement de sa propre file de registres ainsi que de m´emoires internes qui lui permettent d’ex´ecuter des zones de code pouvant aller jusqu’`a des fonctions enti`eres. Ainsi, un coprocesseur peut avoir son propre flot de contrˆole et communique tr`es peu avec le processeur hˆote.
La liste des architectures cit´ees est loin d’ˆetre exhaustive et, pour une ´etude plus compl`ete, le lecteur est invit´e `a consulter les articles [63,84,187] qui r´ef´erencent et pr´esentent les plus r´epandues.
1.2.3
Granularit´e de la sp´ecialisation
La granularit´e des instructions sp´ecialis´ees est li´ee au couplage entre l’extension mat´erielle et le processeur hˆote. Ainsi, des ISE de petite taille sont g´en´eralement utilis´ees dans des extensions mat´erielles fortement coupl´ees. D’autre part, il est ´evident que la granularit´e des ISE joue sur la flexibilit´e de l’extension : des motifs de taille r´eduite auront plus de probabilit´e d’ˆetre pr´esents dans de multiples applications en comparaison avec des motifs contenant plus de nœuds et donc plus sp´ecifiques. R´eciproquement, des instructions sp´ecialis´ees dont la taille est importante offrent souvent, mais pas syst´ematiquement (cf.section 1.1.2.3, page20), plus d’opportunit´es d’acc´el´eration mat´erielle.
! " #! #" $! $" %! %" &! &" "! ! #!! $!! %!! &!! "!! '!! (!! )*+,-./01 /)02-3/45/6537.*87405 ) *+ ,- ./ 0 1/ 65 37 .* 87 40 53
(a) Distribution of size of extension instructions.
! "!! #!! $!! %!! &!! '!! (!! " "! "!! "!!! "!!!! )*+,-./01 /)02-3/45/67348/6908: ) *+ ,- ./ 0 1/ 6 7 34 8/ 6 90 8: 3
(b) Distribution of size of basic blocks (logarithmic scale). Figure 2: The distribution of the number of nodes in the graphs used for graph-subgraph isomorphism.
1.3 Overview
The remainder of this paper is structured as follows. In section 2 we introduce extensible processors and the existing approaches to automated instruction set extension. This is followed in section 3 by a presentation of our novel code generation methodology for AISEgenerated instruction patterns. We demonstrate the effective- ness of our approach through experimental evaluation in section 4 before we discuss related work in section 5. Finally, in section 6 we summarize our results, conclude and provide an outlook to future work.
2. BACKGROUND
This section provides a short overview of the technologies relevant to the work of this paper.
2.1 Extensible Processors
Extensible processors are based on the premise that processor per- formance, die area, and power consumption can be improved if the architecture of the processor is extended to include some fea- tures that are application-specific. This approach requires an abil- ity to extend the architecture and its implementation, as well as the compiler and associated binary utilities, to support the application- specific extensions.
Architecture extensions begin with the capability to add custom instructions to a baseline instruction set. In their simplest form these may be predefined packs of add-on instructions, such as the ARMDSP-enhanced extensions included in the ARM9E[3], the various flavors of MIPSApplication Specific Extensions [17], or SYNOPSYS’ floating-point extensions to the ARCOMPACTinstruc- tion set [2].
These are domain-specific extensions, they can be used across many related tasks. Application-specific instruction set extensions are not predefined by the processor vendor but are instead identified by the system integrator through analysis of the application. To allow such instructions to be incorporated into a pre-existing pro- cessor pipeline, there must be a well-defined extension interface. From a high-level architecture perspective this interface will al- low the extension to operate as a “black-box” functional unit at
the execute (Ex) stage of a standard RISCpipeline. This is an over- simplification though, standard RISCinstructions are two-input and one-output. Effective extension instructions require this constraint to be relaxed as extensions exploit the parallelism available in large instructions. This, therefore, generally requires an extended or ad- ditional register file, hence the need for an extension interface. Practical extensible processors for the embedded computing mar- ket, such as those from SYNOPSYSand TENSILICA, normally have single-issue in-order pipelines of 5-7 stages. This permits operat- ing frequencies in the range 400-700MHz at the 90nm technology node. Extension instructions may be constrained to fit within a single clock cycle, or may be pipelined to operate across multiple cycles.
The representation of instruction set extensions varies from one vendor to another, but essentially describes the encoding and se- mantics of each extension instruction in ways that can be under- stood by both a processor generator tool and all of the software tools (e.g. compilers, assemblers and simulators). There follows a process of translating the abstract representation of the extension instructions to structural form using a Hardware Description Lan- guage (HDL) such as VERILOGor VHDL. This is then incorporated into the overall HDLdefinition of the processor, that is then synthe- sized to the target silicon technology or perhaps to an FPGA.
2.2 Automated Instruction Set Extension
Many algorithms for AISEhave been described in the literature, [11] provides a comprehensive survey of the topic. The algorithm used for the generation of ISEs in following sections of this paper, however, is ISEGEN[5].
The most basic constraints on extension instructions are:
1. The template is convex (i.e. there is no dataflow path between two operations in the template that includes an operation that is not in the template), so that it may be scheduled. 2. Input and output port constraints are met (i.e. the number of
register input and output ports are sufficient), so that it may
Figure 1.9 – Tailles des ISE identifi´ees par ISEGEN [23] dans les blocs de base de 179 bench- marks [137].
D´efinir la taille des instructions sp´ecialis´ees constitue donc un autre param`etre suppl´ementaire de l’espace d’exploration d’un flot de conception ASIP. Lors d’une ´etude r´ecente, la r´epartition des ISE en fonction de leurs tailles a ´et´e mesur´ee pour 179 benchmarks (t´el´ecommunications, multim´edia et
24 Chapitre 1. Contexte et ´etat de l’art sur l’extension de jeux d’instructions
cryptographie) en utilisant ISEGEN [23], un algorithme glouton qui identifie `a chaque it´eration une ISE qui maximise le profit d’une fonction de m´erite. Les r´esultats de ces exp´erimentations ont ´et´e obtenus pour la repr´esentation interm´ediaire de GCC (options de compilation-O2) et sont r´esum´es par la figure1.9. Il y apparaˆıt clairement que le nombre d’ISE de plus de dix nœuds est tr`es faible et que la taille des blocs de bases ne d´epasse que rarement 200 nœuds.
1.2.4
Espace d’exploration des architectures de l’extension
Les caract´eristiques de l’architecture conditionneront les performances de l’application ex´ecut´ee sur le processeur sp´ecialis´e et de nombreux param`etres sont donc `a ´evaluer par le concepteur lors du processus d’exploration.
• Parall´elisme spatial des op´erations. Les op´erations d’une repr´esentation interm´ediaire de type DAG peuvent ˆetre ex´ecut´ees en parall`ele si elles ne sont pas li´ees par des chemins de d´ependances de donn´ees. L’extension comportera alors de multiples ressources mat´erielles qui occuperont d’autant plus de surface.
• Mod`ele d’ex´ecution VLIW. Un mod`ele d’ex´ecution VLIW pour les ISE utilisera simul- tan´ement plusieurs unit´es fonctionnelles reconfigurables de l’extension mat´erielle. Ainsi, le parall´elisme spatial est exploit´e tout en augmentant le degr´e de r´eutilisation du mat´eriel. • Mod`ele d’ex´ecution SIMD. Le mat´eriel de l’extension est dupliqu´e pour ex´ecuter simul-
tan´ement plusieurs instances du comportement d’une ISE pour des donn´ees diff´erentes. Ce comportement peut ˆetre fait `a granularit´e fine (subword-parallelism) ou encore entre plusieurs it´erations d’un mˆeme corps de boucle. On parle ´egalement de vectorisation.
• Mod`ele d’ex´ecution pipelin´ee. Des ISE multicycles peuvent ˆetre pipelin´ees afin d’augmen- ter le d´ebit de l’extension mat´erielle ou encore de r´eduire l’impact des contraintes issues de son nombre restreint d’entr´ees et de sorties [150].
• Approximation des flottants. Le traitement des flottants peut ˆetre simplifi´e en utilisant une approximation par virgule fixe dont la pr´ecision acceptable est d´ependante de l’application. • Arithm´etique des op´erations. Le choix de l’arithm´etique utilis´ee pour mettre en œuvre les
op´erations de l’application peut augmenter les performances des calculs (par des op´erateurs mat´eriels plus efficaces) ou encore am´eliorer la s´ecurit´e du mat´eriel [181].
• M´emorisation sur l’extension. L’utilisation de ressources m´emoires embarqu´ees sur l’ex- tension r´eduit la pression sur le processeur hˆote en limitant le nombre de communications n´ecessaires. Ainsi, une donn´ee interm´ediaire produite sur l’extension restera sur l’extension si elle n’est pas utilis´ee par le processeur.
• Alimentation de l’extension. Les techniques de clock-gating et de power-gating peuvent ´egalement ˆetre envisag´ees pour r´eduire la consommation dynamique et statique de l’extension mat´erielle si celle-ci n’est pas utilis´ee lors de l’ex´ecution d’un programme.
• R´eseau d’interconnexions. La capacit´e d’un ´el´ement de calcul `a communiquer avec d’autres ressources de calculs ou de m´emorisation conditionne les performances de l’architecture. Ainsi, un r´eseau de communication tr`es permissif (e.g., full-crossbar ) facilitera l’allocation des res- sources au prix d’une surface mat´erielle ´elev´ee.