Port du micro-kernel DNA sur plateforme Zynq - Thomas Hiscock Encadrant : Olivier Muller
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
Ensimag, 2ème année Fevrier - Mai 2013
Module d’introduction à la recherche en laboratoire
Port du micro-kernel DNA sur
plateforme Zynq
Thomas Hiscock
Encadrant : Olivier Muller
1
Table des matières
1 Introduction 3
2 Etat de l’art 4
2.1 Les solutions existantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Comparaisons des méthodes . . . . . . . . . . . . . . . . . . . . . . . . . 6
3 Solution d’intégration envisagée 7
3.1 Présentation de DNA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Déploiement d’une tâche . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 Gestion des communications, synchronisation . . . . . . . . . . . . . . . . 8
4 Réalisations et suite du projet 10
4.1 Driver d’UART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5 Conclusion 11
21 Introduction
L’Ensimag propose au second semestre un module d’introduction à la recherche en
laboratoire. Au sein d’un laboratoire, une demi-journée par semaine nous étudions un
problème de recherche. J’ai choisi d’aller au Laboratoire TIMA travailler sur le port d’un
OS léger sur une plateforme SoC (System On Chip) , la carte Zynq de Xilinx (Figure1).
TIMA est un laboratoire du CNRS, de Grenoble INP et de l’UJF dans le domaine
des systèmes intégrés. Dans l’équipe System level synthetis (SLS) où j’ai effectué mon
IRL, Les principaux thèmes abordés sont l’étude des futurs systèmes sur puce, les sys-
tèmes multiprocesseurs ainsi que la modélisation, la simulation et le déboguage de tels
systèmes. L’exploitation des architectures reconfigurables est également un sujet abordé.
Figure 1: La carte Zynq
En effet, les SoCs composés d’un CPU et d’un ou plusieurs FPGA(s) sont de plus
en plus fréquents. Ils permettent d’envisager des améliorations significatives des perfor-
mances et de consommation énergétique en combinant efficacement ces deux composants.
La plateforme Zynq figure 1 produit par Xilinx est un exemple de tel SoC. Elle est com-
posée d’un processeur ARM cortex-A9, et d’un FPGA. De nombreux OS ont été portés
sur cette plateforme, Linux, Android, FreeRTOS et bien d’autres. Nous nous proposons
dans cet IRL de porter le micronoyau DNA (développé à TIMA) sur cette plateforme.
C’est-à-dire porter le noyau sur le sous-système ARM cortex-A9 puis dans un second
temps intégrer le FPGA.
Cette deuxième étape n’est pas aisée et est sujet à beaucoup de recherche aujourd’hui,
car la mise en place d’une application mixte hardware, software nécessite des méca-
nismes complexes. Admettons que l’on veuille créer une telle application, il faut d’une
part développer la partie logicielle (dans un langage comme le C), développer la partie
matérielle (en langage VHDL par exemple), établir la communication (via les bus sys-
tèmes) et une synchronisation entre les deux, synthétiser le circuit, le placer, le router
et enfin déployer l’application. C’est pourquoi nous cherchons à exploiter le CPU de
la Zynq muni d’un OS en vue de simplifier la mise en place d’une application mixte
CPU/FPGA. Pour cela, nous allons étudier les méthodes d’intégrations existantes dans
la littérature, les comparer, puis essayer de dégager une solution pertinente par rapport
à notre plateforme.
32 Etat de l’art
Nous cherchons une méthode d’intégration qui soit légère mais aussi qui simplifie le
développement matériel, mais sans trop compliquer la partie logiciel de l’application. De
plus en plus de calculateurs sont maintenant équipés de cellules de calcul contenant des
FPGA. Même si notre plateforme d’étude est la Zynq, nous recherchons une intégration
qui permette d’envisager un système multi-tâches à la fois matérielles et logicielles.
L’intégration d’un FPGA se décompose en plusieurs sous-parties. Tout d’abord le
déploiment, comment peut-on programmer le FPGA depuis le CPU, les politiques de
partage du matériel. Ensuite la communication et la syncronisation dans le système. En
effet un système mixte FPGA/CPU est complètement asynchrone l’ensemble des tâches
doît pouvoir communiquer et se synchroniser, c’est en grandes partie le choix de ces
mécanismes qui vont conditionner les performances, la simplicité et la legerté du modèle
d’intégration.
On ne pourraît penser l’intégration des FPGA sans l’existence de la reconfiguration
partielle. Elle permet de reconfigurer seulement une partie du FPGA au cours de l’exe-
cution. Becker [6] présente un sytème multi-tâches hardware, on voit pour se faire qu’il
découpe le FPGA en modules, chaque module contient une zone statique qui gère entre
autre la communication, et une zone dynamique reconfigurée pour executée la tâche
souhaitée.
2.1 Les solutions existantes
Intégration derrière une mémoire virtuelle
Vuletid[10] propose d’interfacer une tâche matérielle derrière une mémoire virtuelle.
Les tâches sont déployées puis exécutées depuis un thread logiciel, grâce à une fonction
FPGA_execute().
Cette mémoire virtuelle offre une abstraction confortable pour le programmeur qui
peut alors effectuer des opérations sur des variables communes avec la partie logicielle.
Ainsi on peut accélérer efficacement une partie des calculs d’une application. De plus,
elle semble assez simple à mettre en place.
Mais une telle intégration pose plusieurs problèmes. Tout d’abord cela nécessite une
mémoire virtuelle pour le FPGA, ce qui n’est déjà pas envisageable pour tous les sys-
tèmes embarqués (coût en place et réduction des performances). De plus, le CPU va
souvent être utilisé (car c’est lui qui va gérer tous les accès mémoires depuis le matériel).
Ensuite, dans le cas d’un système multi-tâches, il faut gérer soigneusement les accès
mémoires depuis le matériel. C’est pour cela que le déploiement de la tâche matérielle
est fait depuis un thread. Ainsi avec cette méthode, la logique reconfigurable est utilisée
4comme un coprocesseur, le parallélisme de la plateforme n’est pas complètement exploité.
Les hardware threads
L’idée proposée par Andrews[5] en 2008, est de définir une version hardware des
threads tel que présenté figure 2. La partie utilisateur est encapsulée dans une par-
tie statique permettant même à la tâche de faire des appels systèmes, et également au
système de bloquer le thread.
Cette intégration possède l’avantage d’être assez simple, de permettre une synchroni-
sation des tâche et est compatible avec le modèle très connu et maîtrisé de la program-
mation par threads.
Cependant, la partie statique est très lourde et coûteuse en place sur une zone logique
programmable. Ajoutons à cela qu’il est dur d’envisager la relocation d’un thread hard-
ware.
Figure 2: Un hardware thread
OpenCL
OpenCL[1] est une API utilisée pour développer des programmes sur des systèmes
parallèles hétérogènes composés de GPUs et CPUs. Le système considéré par OpenCL
est composé d’un hôte qui commande plusieurs unités de calculs. OpenCL comprend
un langage permettant de décrire un kernel (un programme exécutable par une unité
de calcul). Au moment de la compilation de l’application, ce kernel est compilé en une
représentation intermédiaire. À l’exécution, cette représentation est compilée pour la
plateforme de calcul qui va le lancer. Dans un tel système les communications sont
toutes effectuées par des mémoires de différents niveaux. Aggarwal présente d’ailleurs
une gestion mémoire similaire pour un système multi FPGA [3].
5Dans notre cas nous travaillons sur un système mixte FPGAs/CPUs, mais nous pou-
vons nous inspirer du fonctionnement de OpenCL.
Un tel choix d’intégration a l’avantage d’abstraire complètement les unités de calcul
(grâce à la notion de kernel), ce qui permet de tirer pleinement parti du parallélisme
offert par la plateforme de calcul.
Cependant, tout d’abord l’utilisation d’une telle API complique beaucoup la partie
logicielle d’une application (initialisation des unités de calculs, déploiement, ect...). En-
suite pour tirer parti pleinement du FPGA, on ne peut pas utiliser le même langage de
programmation que pour du software (à moins d’avoir un compilateur très performant,
ce qui n’est pas le cas à ce jour). Ce qui fait la force d’OpenCL c’est qu’un kernel peut
tourner sur une unité de calcul quelconque, ce qui n’est pas réellement envisageable sur
un système hétérogène.
Notion d’acteur, réseau de tâche
Pour faciliter la programmation d’applications mixtes matérielles, logicielles, il pour-
rait être intéressant d’abstraire cette hétérogénéité, comme le fait openCL en définissant
une unité de calcul. Dans [4], on trouve une comparaison des principaux modèles de
programmation existants. Le modèle SDF (Synchronous data flow) est très utilisé pour
décrire des systèmes de type DSP. L’idée est de définir une application comme un en-
semble de tâches communicants et se synchronisant avec des FIFOs (exemple d’une
addition vectorielle figure 3) . Ainsi en définissant une application à partir des acteurs,
on masque au développeur l’hétérogénéité de la plateforme.
Gantel [7] présente une intégration d’une application décrite dans un tel modèle.
Une fois les acteurs définis, ils sont séparés entre matériel ou logiciel. Les acteurs ma-
tériels sont implantés comme des threads hardware (figure 2) décrit précédemment, et
des acteurs logiciels tournent sur des CPUs. On trouve plusieurs autres frameworks[2]
permettant de simplifier au maximum le développement d’une telle application. S’ils
peuvent être utiles dans des applications très complexes et sur des systèmes fortement
distribués. Dans le cas de la Zynq ils seront peu utiles
Ce type d’intégration a l’avantage de tirer parti complètement de l’hétérogénéité de
la plateforme. Mais le coût matériel de l’implantation choisie par Gantel n’est pas envi-
sageable dans notre cas.
2.2 Comparaisons des méthodes
Comparons maintenant ces différentes méthodes. La mémoire virtuelle et les hthreads
simplifient tous deux bien le développement coté matériel et logiciel mais leurs surcouts
matériels pèche. Une API type openCL complique grandement le développement coté
6Appli_Vect_1 Appli_Vect_2
Add_Vecteur
Figure 3: Réseau effectuant une addition vectorielle
logiciel. Enfin un réseau de tâche satisfait tous nos critères, mis à part le coût de l’im-
plantation. Mais plusieurs choix d’implantation d’un tel modèle peuvent être fait.
Méthode simplicité hardware simplicité software coût mise en place
Aucune -- -- --
Mémoire virtuelle + + --
Hthread + + -
OpenCL ++ - -
Réseau de tâche ++ ++ X
Ainsi la solution qui apparaît la plus adaptée par rapport à nos critères pourrait être
une solution à base d’un réseau de tâche. Maintenant comment peut-on implanter de
manière efficace une telle intégration dans notre système Zynq, DNA OS ?
3 Solution d’intégration envisagée
3.1 Présentation de DNA
Le micronoyau DNA est développé au sein de TIMA. Cet OS a la particularité d’être
très léger. L’OS est décrit par un ensemble de composants. Chaque composant est décrit
à l’aide d’un fichier .xml, on y spécifie les fonctions qu’il fournit, les variables globales
et les types qu’il peut définir. Une application est construite en joignant les composants
nécessaires. Ainsi cet OS présente l’avantage de séparer proprement le code de chaque
composants mais aussi de compiler seulement ce qui est nécessaire. Cet OS semble donc
pertinent par rapport à notre souhait d’avoir une intégration légère.
La figure 4 représente de découpage en composant choisit pour cette intégration et
les liens entre eux. Les principaux composants sont le ZynqPlatformDriver, qui est l’en-
semble des pilotes de la Zynq (liaison série, bus). Le composant ARMCortexA9 permet
de d’utiliser le CPU de la Zynq, pour faire tourner DNA OS. Deux autres composants
viennent s’ajouter, l’allocateur, et le MPI que nous décrivont un peu plus bas. Enfin une
application définie par un utilisateur pourra se servir des composants OS, Allocateur et
MPI.
73.2 Déploiement d’une tâche
Dans la littérature, se trouvent pleins d’exemples [8] [9] de drivers permettant de
programmer le FPGA depuis un OS. Dans notre cas le composant ZynqPlatformDri-
ver(figure 4), contient ce driver, qui permet d’envoyer une configuration de FPGA (le
bitstream). Il y a un problème que nous n’avons pas encore évoqué, pour un système à
plusieurs FPGA ou si un FPGA est découpé en plusieurs zones d’exécutions. Une tâche
utilisateur doit pouvoir être lancée dans toutes ces zones. Ceci implique où de manipu-
ler le bitstream pour déplacer la tâche, où de générer les bitstreams correspondants à
chaques modules.
La solution HCM[11] est très intéressante elle permet d’abstraire complètement la
disponibilité matérielle. Notre solution se basera donc sur une architecture similaire au
HCM. Le déploiement sera ainsi geré par un composant Allocateur (figure 4). Il permet
depuis un programme de faire des demandes d’allocations, et d’obtenir un équivalent du
pid, qui identifie la tâche matérielle. Un fid qui nous sera utile pour la gestion des
communications.
ZynqPlatformDriver
UserApp ArmCortexA9
DnaCore
Allocateur
MPI
Figure 4: Découpage en composant proposé
3.3 Gestion des communications, synchronisation
Nous voulons mettre en place un système de communication entre les tâches. Ces
communications sont modélisées par des FIFOs. En vue de minimiser le coût maté-
riel, la gestion des communications sera seulement effectuée par le CPU. Nous allons
donc ajouter un composant supplémentaire MPI dans DNA pour gérer toutes les com-
8Figure 5: Architecture proposée pour la communication
munications. Ceci permet de garder une souplesse et d’abstraire plus à l’utilisateur ces
communications. Ce composant fournit une fonction create_channel(). Cette fonction
est cruciale, elle permet de créer un canal de communication entre 2 tâches (matérielle-
logicielle, matérielle-matérielle ou encore logicielle-logicielle). On peut ensuite faire appel
aux fonctions send() et receive(). Pour effectuer les écritures et les lectures dans un
canal. Ce composant communique impérativement avec l’Allocateur, pour router correc-
tement les messages, si une tâche n’est pas actuellement sur le matériel par exemple.
Pour qu’une tâche matérielle puisse interagir avec ce composant MPI. Nous définis-
sons une partie statique (figure 5) sur le FPGA qui permet de faire l’interface avec
le bus et le composant MPI. Chaque tâche possède des canaux numérotés, la fonction
create_channel() permet d’attribuer ces numéros de canaux. Pour effectuer une com-
munication on spécifie le numéro de canal, la donnée, send/receive pour un envoie ou
une réception. Le signal wait géré par la partie statique du FPGA doit être en mesure
de bloquer la tâche (canal vide ou plein par exemple).
Cette numérotation des canaux, simplifie la gestion des communications. En effet elle
évite d’avoir à passer des paramètres à la tâche matérielle, une opération qui risque de
complexifier notre intégration. De plus cette numérotation peut être complètement au-
tomatisée grâce à des frameworks, comme le SCF[2] par exemple, dans lequel on définit
dans un langage de description les liens intertâches.
Voici un exemple de code pour une telle intégration, pour réaliser l’addition de deux
vecteurs sur le FPGA (graphe figure 3) :
void proc_1 () {
// Chargement descripteur de tache depuis un fichier
fpga_task_t tache1 = create_task ( " path ... " ) ;
// Allocation des ressources materielles
int fid1 = fpga_alloc ( tache1 ) ;
// Creation des canaux la tache1 et le processus courant
9create_channel ( fid1 , my_pid () ,0) ;
create_channel ( fid1 , my_pid () ,1) ;
// Execution sur le fpga
fpga_compute ( fid1 ) ;
// Envoie du premier vecteur canal 0 de la tache 1
fpga_send ( fid1 , val1_x ,0) ;
fpga_send ( fid1 , val1_y ,0) ;
// Envoie du deuxieme vecteur canal 1 de la tache 1
fpga_send ( fid2 , val2_x ,1) ;
fpga_send ( fid2 , val2_y ,1) ;
// Reception du resultat canal 9 de la tache 1
fpga_receive ( fid1 , & mess ,0) ;
fpga_close ( fid1 ) ;
}
4 Réalisations et suite du projet
4.1 Driver d’UART
Pour mettre en place cette solution d’intégration une des premières étape est l’écri-
ture des drivers de la plateforme, j’ai donc travaillé sur le développement du composant
ZynqPlateformeDriver (figure 4). Entre autre par la réalisation du driver de l’UART
(Universal Asynchronous Receiver Transmitter) de la Zynq. L’UART permet l’envoie de
message série et est donc impératif pour pouvoir obtenir un minimum d’information de
la Zynq. Ce driver a été testé à l’aide d’un programme standalone (en dehors de tout OS)
sur l’émulateur qemu. Il a fallu également que je prenne en main U-Boot qui est utilisé
comme bootloader de DNA. J’ai par la suite intégré ce driver au composant Zynqpla-
teformDriver. Malheureusement des problèmes de linkage ont empêchés l’aboutissement
du test dans DNA et sur la carte Zynq.
Le composant ArmCortexA9 (figure 4) est presque déjà existant. En effet DNA OS a
déjà été porté sur plusieurs plateformes Arm. De même le composant DnaCore existe.
Reste donc à développer le driver de plateforme, l’allocateur et le MPI.
105 Conclusion
Ainsi beaucoup des méthodes d’intégrations trouvées dans la littérature sont inté-
ressantes. Mais peu sont réellement adaptées à nos critères et notre plateforme. Nous
avons retenu une intégration basée sur un modèle de réseau de tâches. Car elle permet
d’abstraire complètement l’hétérogénéité de notre plateforme, et permet de définir de
manière assez simple une application. Pour mettre en place une intégration basée sur
un tel modèle sur la Zynq, nous avons essayés d’utiliser des mécanismes de gestion assez
simples, pour permettre à la fois de la souplesse et des coûts moins lourds en termes de
matériel. Avec plus de temps, il serait intéressant de mettre en place complètement cette
intégration, et d’étudier les performances du système.
Cet IRL fût pour moi une expérience très riche, j’ai appris beaucoup de choses, à
la fois sur le plan technique comme l’utilisation de qemu, U-Boot, le déboguage. Mais
c’était aussi l’occasion d’apprendre des méthodes, d’analyses et de synthèses nécessaire
au travail bibliographique. Enfin j’ai découvert tout le domaine de l’exploitation des
FPGA qui m’a beaucoup plus. Plus généralement cet IRL m’a motivé à m’orienter vers
le domaine du calcul embarqué pour ma future carrière.
Je remercie Olivier Muller de m’avoir accueilli au sein de TIMA et accordé du temps
pour cet IRL.
11Références
[1] Opencl overview, http ://www.khronos.org/assets/uploads/developers/library/overview/opencl-
overview.pdf, 2011.
[2] V Aggarwal, R Garcia, G Stitt, A George, and H Lam. Scf : A device-and language-
independent task coordination framework for reconfigurable, heterogeneous sys-
tems. In Proceedings of the Third International Workshop on High-Performance
Reconfigurable Computing Technology and Applications, pages 19–28. ACM, 2009.
[3] Vikas Aggarwal, Alan D George, Changil Yoon, Kishore Yalamanchili, and Herman
Lam. Shmem+ : A multilevel-pgas programming model for reconfigurable supercom-
puting. ACM Transactions on Reconfigurable Technology and Systems (TRETS),
4(3) :26, 2011.
[4] Gregory Eugene Allen. Computational process networks : a model and framework
for high-throughput signal processing. pages 21–33, 2011.
[5] David Andrews, Ron Sass, Erik Anderson, Jason Agron, Wesley Peck, Jim Ste-
vens, Fabrice Baijot, and Ed Komp. Achieving programming model abstractions
for reconfigurable computing. Very Large Scale Integration (VLSI) Systems, IEEE
Transactions on, 16(1) :34–44, 2008.
[6] Jürgen Becker, Michael Hubner, Gerhard Hettich, Rainer Constapel, Joachim Ei-
senmann, and Jurgen Luka. Dynamic and partial fpga exploitation. Proceedings of
the IEEE, 95(2) :438–452, 2007.
[7] Laurent Gantel, Amel Khiar, Benoit Miramond, Mohamed El Amine Benkhelifa,
Lounis Kessal, Fabrice Lemonnier, and Jimmy Le Rhun. Enhancing reconfigurable
platforms programmability for synchronous data-flow applications. ACM Transac-
tions on Reconfigurable Technology and Systems (TRETS), 5(3) :14, 2012.
[8] Vincent Nollet, Paul Coene, Diederik Verkest, Serge Vernalde, and Rudy Lauwe-
reins. Designing an operating system for a heterogeneous reconfigurable soc. In
Parallel and Distributed Processing Symposium, 2003. Proceedings. International,
pages 7–pp. IEEE, 2003.
[9] Vincenzo Rana, Marco Santambrogio, Donatella Sciuto, Boris Kettelhoit, Markus
Koester, Mario Porrmann, and Ulrich Ruckert. Partial dynamic reconfiguration
in a multi-fpga clustered architecture based on linux. In Parallel and Distributed
Processing Symposium, 2007. IPDPS 2007. IEEE International, pages 1–8. IEEE,
2007.
[10] M Vuletid, Laura Pozzi, and Paolo Ienne. Seamless hardware-software integration in
reconfigurable computing systems. Design & Test of Computers, IEEE, 22(2) :102–
113, 2005.
[11] Yan Xu, Olivier Muller, Pierre-Henri Horrein, and Frédéric Pétrot. Hcm : An
abstraction layer for seamless programming of dpr fpga. In Field Programmable
Logic and Applications (FPL), 2012 22nd International Conference on, pages 583–
586. IEEE, 2012.
12Vous pouvez aussi lire
