Vient Et Part Vient Et Part

THSE
Pour obtenir le grade de

DOCTEUR DE LUNIVERSIT DE GRENOBLE
Spcialit : Informatique
Arrt ministriel : 7 aot 2006
Prsente par
Pierre-Henri Horrein
Thse dirige par Frdric Ptrot
et encadre par Christine Hennebert
prpare au sein du CEA/LETI et du TIMA
et de lcole Doctorale Mathmatiques, Sciences et Techniques de
lIngnieur, Informatique
Architectures logicielles pour la
radio exible : intgration dunits
de calcul htrognes
Thse soutenue publiquement le 10 janvier 2012,
devant le jury compos de :
M. Olivier Sentieys
Professeur des Universits, ENSSAT, Prsident
M. Tanguy Risset
Professeur des Universits, INSA Lyon, Rapporteur
M. Christophe Moy
Professeur, Suplec Rennes, Rapporteur
M. Jean-Luc Danger
Directeur dtudes, Tlcom ParisTech, Examinateur
M. Franck Rousseau
Matre de Confrences, Grenoble INP, Examinateur
M. Frdric Ptrot
Professeur des Universits, Grenoble INP, Directeur de thse
Mme Christine Hennebert
Docteur, CEA, Encadrante
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
Remerciements
La thse est un travail personnel, mais beaucoup de monde y participe. Jaimerais citer dans
ces remerciements toutes les personnes qui ont rendu ce travail possible. Cependant, elles sont
nombreuses, et je demande pardon par avance ceux que je ne pourrai pas citer. Jaimerais tout
dabord remercier mes deux rapporteurs, Tanguy Risset et Christophe Moy davoir accept de
sacquitter de cette tche consommatrice en temps. Leurs remarques judicieuses sur mon travail
avant et pendant la soutenance mont forc creuser et largir mon champ de vision. Je remercie
galement les membres du jury, Olivier Sentieys, Franck Rousseau, et Jean-Luc Danger davoir
fait le dplacement jusqu Grenoble pour ceux qui ny taient pas, et davoir pris le temps de
sintresser mon travail.
Jai eu la chance dtre soutenu avant et durant cette thse par mon directeur de thse,
Frdric Ptrot. Mme si la thse est un objectif depuis longtemps, il ma montr ce qutait
la recherche et ma remotiv (sans le savoir) lors de mon premier stage avec lui en 2007. Je lai
parfois trop sollicit, mais il a toujours rpondu prsent, mme quand le temps lui manquait. De
mme, Christine Hennebert ma encadr au CEA durant cette thse, et je len remercie. Elle a
su juguler ma tendance papillonner, et ma permis de rester sur des rails plus ou moins droits
malgr les dicults, et a na pas t vident.
Jai pu mappuyer sur deux laboratoires durant ma thse. Du ct du CEA, lquipe LASP,
mon quipe de rsidence devenue ANP au cours de ma thse, ma chaleureusement accueilli ds
mon arrive. Certaines personnes ont cependant eu plus dinuence que dautres. Dimitri Kt-
nas, bien quextrieur lquipe ma oert la possibilit de travailler sur son simulateur et ma
permis davancer dans la direction que javais prise lpoque. Xavier Popon ma consacr du
temps pour le support sur la carte Magnet. Dominique Noguet ma soutenu dans mes dmarches
administratives et ma judicieusement conseill sur les directions prendre tout au long de ma
prsence au CEA. Manuel Pezzin, par ses conseils, ses avis, et sa bonne humeur ma grandement
aid surmonter mes moments de petite forme. Florian Pebay-Peyroula ma accueilli dans son
bureau. Jai beaucoup apprci nos discussions, quelles soient scientiques ou non, et jespre
pouvoir continuer travailler avec lui. Pour nos discussions (pas forcment professionnelles) tard
le soir, je remercie galement Roselin. Finalement, une bonne ambiance au travail est primor-
diale pour avancer et lquipe Ptit-Dj a fortement contribu cette ambiance. Je remercie donc
Alexandre, Yanis, Ccile, Mathilde, Jessie, Philippe, et Stphanie (et Manuel et Florian, une fois
de plus !), ainsi que Claire, arrive aprs le Ptit-Dj. Ces remerciements dpassent bien sr le
cadre strictement professionnel.
Mme si dans les faits, je ntais pas rellement dans le laboratoire TIMA, je me suis toujours
senti bienvenu dans lquipe SLS, pour les quelques runions de groupe auxquelles jai particip,
ou juste pour un th. Les personnes du groupe que jaimerais remercier individuellement, en plus
de mon directeur de thse, sont plus des amis que des collgues. Donc, au TIMA et pas seulement,
je remercie tout particulirement Olivier Muller. Son soutien scientique, son oreille attentive, ses
conseils aviss (sans oublier son chat !) mont t dun grand secours. Merci galement de mavoir
donn lopportunit de participer au projet C. Cette exprience, bien qupuisante, aura t bn-
que. Nicolas Fournel et Damien Hedde mont support la maison durant ces dernires annes
(et il faut du courage !). Nos soires (nuits/week-ends) Vorbis, nos discussions vidoludiques, nos
randonnes, et nalement les conseils de Nicolas et le paralllisme temporel de la thse de Damien
et de la mienne ont t un soutien bienvenu.
Finalement, mme sans aucun lien avec le travail, certaines personnes ont particip au bon
iii
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
REMERCIEMENTS REMERCIEMENTS
droulement de cette thse. Pour cela, je remercie Catherine, qui ma support et soutenu du-
rant toute cette dernire anne de thse, malgr les dicults de sa propre thse. Cline, pour
son soutien inconditionnel et les preuves traverses ensemble, sera toujours importante. Merci
nalement Guillaume et Juliette qui restent proches mme sils sont loins, et Sylvain, moins
loin et aussi proche.
Et bien entendu, pour mavoir permis den arriver l et mavoir soutenu et entour quels que
soient mes choix, ne les oublions pas : je naurais pas pu y arriver sans le soutien permanent de
mes parents, de mes frres, et de ma famille. Je nai malheureusement pas la place de tous les
citer, mais je tiens les remercier chaleureusement.
iv
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
Table des matires
1 Introduction 1
2 Problmatique 5
2.1 Contexte de la thse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1 Modle rseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2 Chane de communication . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Rseaux exibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1 Radio classique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.2 Radio recongurable . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2.1 Vision gnrale . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2.2 Software Radio . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2.3 Software-Dened Radio . . . . . . . . . . . . . . . . . . . . 9
2.2.3 Radio exible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.4 Radio cognitive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.4.1 Terminal de radio cognitive . . . . . . . . . . . . . . . . . . . 10
2.2.4.2 Radio opportuniste . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.5 Interactions radio exible/radio cognitive . . . . . . . . . . . . . . . . . 11
2.2.5.1 Dirences de terminologie . . . . . . . . . . . . . . . . . . 11
2.2.5.2 Architecture dun terminal radio . . . . . . . . . . . . . . . . 11
2.2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Radio exible : de multiples possibilits . . . . . . . . . . . . . . . . . . . . . . 12
2.3.1 Scnarios de reconguration . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.1.1 Adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.1.2 volution des normes . . . . . . . . . . . . . . . . . . . . . . 13
2.3.1.3 Multimode . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.2 De multiples cibles de reconguration . . . . . . . . . . . . . . . . . . 13
2.3.2.1 Cibles logicielles . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.2.2 Matriel recongurable . . . . . . . . . . . . . . . . . . . . . 14
2.3.3 Conclusion sur la radio exible . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Choix de limplantation : volution . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.1 Performance de la radio logicielle . . . . . . . . . . . . . . . . . . . . . 15
2.4.2 Essor du GPGPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.3 Problmes du GPGPU pour la radio logicielle . . . . . . . . . . . . . . 16
2.5 Environnement de reconguration unique . . . . . . . . . . . . . . . . . . . . . 16
2.5.1 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5.2 Gestion de la recongurabilit . . . . . . . . . . . . . . . . . . . . . . . 17
2.5.3 Intgration de la radio exible . . . . . . . . . . . . . . . . . . . . . . . 18
2.5.4 Gestion de la reconguration . . . . . . . . . . . . . . . . . . . . . . . 18
2.5.5 Conclusion : besoins dun environnement exible . . . . . . . . . . . . 19
2.6 Conclusion gnrale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
v
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
TABLE DES MATIRES TABLE DES MATIRES
3 tat de lart 21
3.1 Reprsentation dune application radio . . . . . . . . . . . . . . . . . . . . . . 22
3.1.1 Reconguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1.1.1 Dnition gnrale . . . . . . . . . . . . . . . . . . . . . . . 22
3.1.1.2 Cas de la radio logicielle . . . . . . . . . . . . . . . . . . . . 22
3.1.2 Reprsentation des applications . . . . . . . . . . . . . . . . . . . . . . 22
3.2 Plateformes de radio logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.1 Solutions base de processeurs . . . . . . . . . . . . . . . . . . . . . . 23
3.2.2 Intgration des GPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.3 Utilisation de FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.4 Solutions hybrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.5 Matriel recongurable et adaptabilit . . . . . . . . . . . . . . . . . . 25
3.2.5.1 Paramtrisation et oprateurs communs . . . . . . . . . . . . 25
3.2.5.2 ASIC et SOC . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.6 Conclusion sur les plateformes . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Environnements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.1 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.2 Excution htrogne . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.2.1 Acclrateurs matriels . . . . . . . . . . . . . . . . . . . . . 27
3.3.2.2 Intgration des FPGA . . . . . . . . . . . . . . . . . . . . . . 27
3.3.2.3 Excution htrogne GPP/DSP . . . . . . . . . . . . . . . . 27
3.3.3 Environnements complets . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.3.1 SCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.3.2 RMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.3.3 GNURadio . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.3.4 P-HAL/Aloe . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.3.5 MVR : Machine Virtuelle Radio . . . . . . . . . . . . . . . . 31
3.3.3.6 Surfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4 Conclusion du chapitre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4 Intgration du GPU dans la radio logicielle 35
4.1 Introduction : le GPGPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.1.1 Origine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.1.2 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.1.2.1 Architecture dune plateforme OpenCL . . . . . . . . . . . . 36
4.1.2.2 Format dune application . . . . . . . . . . . . . . . . . . . . 37
4.1.3 Contraintes et objectif . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2 Utilisation optimise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.1 Oprations basiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.2 Oprations complexes : premire approche . . . . . . . . . . . . . . . . 40
4.2.3 Proposition : maximisation de lutilisation . . . . . . . . . . . . . . . . 41
4.2.3.1 Paralllisation grain n . . . . . . . . . . . . . . . . . . . . 41
4.2.3.2 Paralllisation gros grain . . . . . . . . . . . . . . . . . . . 42
4.2.3.3 Comparaison . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3 Ordonnancement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3.1 Ecacit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3.2 Latence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3.3 Mmoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.4 Intgration distribue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
vi
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
4.4.1 Prsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.4.2 Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.4.2.1 Intgration transparente . . . . . . . . . . . . . . . . . . . . . 46
4.4.2.2 Buer OpenCL . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.5 Intgration centralise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.5.1 Prsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.5.2 Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.5.3 En pratique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.6 Rsultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.6.1 Synthse des contributions . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.6.2 Oprations implantes . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.6.2.1 FFT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.6.2.2 Demapping . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.6.2.3 IIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.6.3 Protocole dexprimentation . . . . . . . . . . . . . . . . . . . . . . . . 52
4.6.4 Rsultats des oprations unitaires . . . . . . . . . . . . . . . . . . . . . 53
4.6.4.1 Inuence du seuil . . . . . . . . . . . . . . . . . . . . . . . . 53
4.6.4.2 Inuence de la taille des vecteurs . . . . . . . . . . . . . . . . 55
4.6.5 Rsultats pour des applications multitches . . . . . . . . . . . . . . . . 56
4.7 Perspectives et conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.7.1 Discussion : portabilit vers lembarqu . . . . . . . . . . . . . . . . . . 57
4.7.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5 Dnition dun environnement pour la radio exible 61
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.1.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.1.2 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.1.2.1 Support des units dexcution . . . . . . . . . . . . . . . . . 63
5.1.2.2 Application, adaptabilit et recongurabilit . . . . . . . . . . 63
5.2 Architecture gnrale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.2.1 Prsentation gnrale de lenvironnement . . . . . . . . . . . . . . . . . 64
5.2.2 R-HAL et traducteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.2.2.1 Reprsentation et contrle de la plateforme . . . . . . . . . . 65
5.2.2.2 Traduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.2.2.3 Gestion des applications . . . . . . . . . . . . . . . . . . . . 66
5.2.3 Couche protocolaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.3 Gestion des applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.3.1 Prsentation : ot de dveloppement dune application avec FRK . . . . 67
5.3.2 Reprsentation dune application . . . . . . . . . . . . . . . . . . . . . 68
5.3.2.1 Waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.3.2.2 Conguration Instance . . . . . . . . . . . . . . . . . . . . . 68
5.3.3 Traduction et implantation de lapplication . . . . . . . . . . . . . . . . 68
5.3.3.1 Oprations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.3.3.2 Transferts de donnes . . . . . . . . . . . . . . . . . . . . . . 70
5.3.3.3 Chargement dune application . . . . . . . . . . . . . . . . . 71
5.3.4 Gestion de lexcution . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.3.4.1 Ordonnancement . . . . . . . . . . . . . . . . . . . . . . . . 71
5.3.4.2 Adaptabilit : modication dynamique de la CI . . . . . . . . 72
5.4 Implantation des cibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.4.1 TaME et extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
vii
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
5.4.1.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.4.1.2 Interface : API principale . . . . . . . . . . . . . . . . . . . . 73
5.4.2 Cible logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.4.2.1 Dnition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.4.2.3 Ordonnancement . . . . . . . . . . . . . . . . . . . . . . . . 74
5.5 Intgration des coprocesseurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.5.1 Dnition et postulat . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.5.2 Reprsentations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.5.2.1 Coprocesseur . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.5.2.2 Oprations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.5.3 Fonctionnement de la cible coprocesseur . . . . . . . . . . . . . . . . . 77
5.5.3.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.5.3.2 Cong Switch . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.5.3.3 Ordonnancement . . . . . . . . . . . . . . . . . . . . . . . . 78
5.5.3.5 Exemple : le codeur . . . . . . . . . . . . . . . . . . . . . . . 79
5.6 FRK en pratique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.6.1 tat de FRK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.6.2 Implantation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.6.2.1 Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.6.2.2 RTEMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.6.3 Exemple du codeur convolutif . . . . . . . . . . . . . . . . . . . . . . . 81
5.6.3.1 Prsentation du programme . . . . . . . . . . . . . . . . . . . 81
5.6.3.2 Excution logicielle . . . . . . . . . . . . . . . . . . . . . . . 82
5.6.3.3 Excution matrielle : une seule application . . . . . . . . . . 83
5.6.3.4 Excution matrielle : deux applications . . . . . . . . . . . . 84
5.6.4 Exemple complet : IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . 87
5.6.4.1 Prsentation du programme et de la plateforme . . . . . . . . 87
5.6.4.2 Fonctionnement BPSK . . . . . . . . . . . . . . . . . . . . . 88
5.6.4.3 Demande dadaptation . . . . . . . . . . . . . . . . . . . . . 88
5.6.5 Quelques chires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6 Conclusion 91
A Rsultats complets pour le GPU 95
B Paralllisation dun ltre IIR 99
B.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
B.2 Dmonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
B.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
C Prsentation gnrale de linterface de FRK 103
C.1 OPM et communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
C.1.1 Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
C.1.1.1 Opration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
C.1.1.2 Waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
C.1.1.3 CI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
C.1.2 Fonctions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
C.1.2.1 Oprations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
viii
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
C.1.2.2 Cration de la waveform . . . . . . . . . . . . . . . . . . . . 105
C.1.2.3 Traduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
C.2 Interface R-HAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
C.2.1 Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
C.2.1.1 Transferts de donnes . . . . . . . . . . . . . . . . . . . . . . 106
C.2.1.2 Oprations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
C.2.2 Fonctions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
C.3 TaME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
C.3.1 Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
C.3.1.1 Structure dun TaME . . . . . . . . . . . . . . . . . . . . . . 108
C.3.1.2 Oprations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
C.3.2 Fonctions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
C.3.2.1 CI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
C.3.2.2 Oprations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
C.4 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
C.5 Rsum et conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
D Intgration de matriel ddi dans FRK 113
D.1 Utilisation de MAGNET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
D.1.1 Plateforme MAGNET . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
D.1.2 Reprsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
D.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Publications 117
Bibliographie 119
ix
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
x
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
Table des gures
2.1 Modle OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Exemple de chane de communication type pour un rseau sans l . . . . . . . . 7
2.3 Reprsentation dun rcepteur superhtrodyne . . . . . . . . . . . . . . . . . . 8
2.4 Reprsentation dun rcepteur idal de radio logicielle . . . . . . . . . . . . . . 9
2.5 Reprsentation dun rcepteur ralisable de SDR . . . . . . . . . . . . . . . . . 10
2.6 Cycle simpli dun terminal intelligent [MM99] . . . . . . . . . . . . . . . . . 10
2.7 Interactions entre radio exible et radio cognitive . . . . . . . . . . . . . . . . . 12
2.8 Reprsentation du rapport exibilit/performance de direntes solutions dim-
plantation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.9 Architecture de plateforme exible gnrique . . . . . . . . . . . . . . . . . . . 17
3.1 Reprsentation et reconguration hirarchique [DMLP05] . . . . . . . . . . . . 23
3.2 Architecture de lenvironnement SCA . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 Architecture gnrale de GNURadio . . . . . . . . . . . . . . . . . . . . . . . . 30
3.4 Architecture gnrale de P-HAL/Aloe . . . . . . . . . . . . . . . . . . . . . . . 31
4.1 Reprsentation dune plateforme OpenCL . . . . . . . . . . . . . . . . . . . . . 37
4.2 Architecture dune application OpenCL . . . . . . . . . . . . . . . . . . . . . . 38
4.3 Opration de radio logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.4 Opration de radio logicielle sur GPU : approche classique . . . . . . . . . . . . 40
4.5 Opration de radio logicielle sur GPU : approche propose . . . . . . . . . . . . 42
4.6 Dbit chantillons en MS/s pour des FFT de 128 points pour dirents seuils . . 44
4.7 Implantation distribue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.8 Utilisation de buers spciques pour les GPU . . . . . . . . . . . . . . . . . . 47
4.9 Implantation centralise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.10 Protocole dexprimentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.11 Dbit chantillons en MS/s pour la FFT pour dirents seuils, taille de vecteur
xe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.12 Dbit chantillons en MS/s pour le demapping pour dirents seuils, taille de
vecteur xe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.13 Dbit chantillons en MS/s pour lIIR pour dirents seuils, taille de vecteur xe 55
4.14 Dbit chantillons en MS/s en fonction de N, pour un seuil optimal calcul expri-
mentalement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.15 Rsultats pour une squence doprations, pour un seuil optimal calcul expri-
mentalement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.1 Architecture de plateforme exible gnrique . . . . . . . . . . . . . . . . . . . 62
5.2 Intgration de Flexible Radio Kernel (FRK) dans une architecture logicielle classique 64
5.3 Intgration de FRK dans une architecture logicielle classique . . . . . . . . . . . 65
5.4 Architecture de la PL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.5 tapes de chargement dune application FRK . . . . . . . . . . . . . . . . . . . 67
5.6 Traduction dune opration en utilisant lOPM . . . . . . . . . . . . . . . . . . . 69
5.7 Architecture gnral dun contrleur de cibles . . . . . . . . . . . . . . . . . . . 73
5.8 Reprsentation dune tche pour la cible logicielle . . . . . . . . . . . . . . . . . 75
5.9 Codeur convolutif matriel paramtrable . . . . . . . . . . . . . . . . . . . . . . 76
xi
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
TABLE DES FIGURES TABLE DES FIGURES
5.10 Instance pour le codeur convolutif . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.11 Implantation de la cible pour le codeur . . . . . . . . . . . . . . . . . . . . . . . 77
5.12 Automate de slection dune conguration pour le TaME coprocesseur . . . . . . 79
5.13 Plateforme MagNET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.14 Application traduite pour une cible logicielle . . . . . . . . . . . . . . . . . . . 83
5.15 FRK avec deux codeurs, cibles mixtes . . . . . . . . . . . . . . . . . . . . . . . 84
5.16 FRK avec deux codeurs en matriel . . . . . . . . . . . . . . . . . . . . . . . . 85
5.17 Reprsentation de ltat du systme . . . . . . . . . . . . . . . . . . . . . . . . 86
5.18 Application IEEE 802.11 simplie utilise . . . . . . . . . . . . . . . . . . . . 87
5.19 Plateforme matrielle pour lapplication IEEE 802.11 . . . . . . . . . . . . . . . 87
A.1 Rsultats complets pour la FFT . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
A.2 Rsultats complets pour le demapping . . . . . . . . . . . . . . . . . . . . . . . 96
A.3 Rsultats complets pour la IIR . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
C.1 Diagramme de classe des structures de FRK . . . . . . . . . . . . . . . . . . . . 112
xii
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
Liste des acronymes
API Application Programming Interface
ASIC Application Specic Integrated Circuit
ASIP Application Specic Integrated Processor
BSP Board Support Package
CI Conguration Instance
CORBA Common Object Request Broker Architecture
CPU Central Processing Unit
DSP Digital Signal Processor
DVB Digital Video Broadcasting
FFT Fast Fourier Transform
FIFO First In First Out
FIR Finite Impulse Response
FRK Flexible Radio Kernel
FPGA Field-Programmable Gate Array
GPGPU General Purpose computing on Graphics Processing Unit
GPP General Purpose Processor
GPU Graphics Processing Unit
GSM Global System for Mobile communications
HAL Harware Abstraction Layer
KPN Kahn Process Network
LDPC Low Density Parity Check
MAC Medium Access Control
NoC Network on Chip
OFDM Orthogonal Frequency Division Multiplexing
OPM Operation to Platform Mapping
OSI Open Systems Interconnection
OpenCL Open Computing Language
PHY couche PHYsique
PL Protocol Layer
POSIX Portable Operating System Interface for Unix
QAM Quadrature Amplitude Modulation
QPSK Quadrature Phase Shift Keying
R-HAL Radio Hardware Abstraction Layer
RTEMS Real-Time Executive for Multiprocessor Systems
RVM Radio Virtual Machine
xiii
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
LISTE DES ACRONYMES LISTE DES ACRONYMES
SCA Software Communications Architecture
SIMD Single Instruction Multiple Data
TaME TArget Management Element
UMTS Universal Mobile Telecommunication System
WCDMA Wideband Code Division Multiple Access
xiv
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
Chapitre 1
Introduction
L
informatique daujourdhui est connecte tous les niveaux. Les applications sont de plus en
plus externalises, et il devient dicile de trouver des programmes informatiques nutilisant
pas les rseaux.
Allant de paire avec les applications, la conception mme des plateformes matrielles intgre
les rseaux. Que ce soit les serveurs, les stations de travail, les ordinateurs portables, les tl-
phones, . . . La plupart des systmes utilisent aujourdhui plusieurs mthodes daccs aux rseaux.
Lvolution des tlphones portables est reprsentative de cette connectivit accrue. Ils permettent
de se connecter au rseau tlphonique
1
, peuvent utiliser le Bluetooth pour se connecter des p-
riphriques ou un ordinateur, et ont galement souvent accs un rseau WiFi. Tous ces rseaux
sont des rseaux sans l, qui utilisent les ondes lectromagntiques comme support. Ils voluent
rgulirement, de nouveaux voient le jour, certains ne sutilisent plus.
Contexte : la radio logicielle
Intgrer une norme rseau dans une plateforme matrielle requiert lintgration de plusieurs
lments :
une antenne adapte londe utilise pour la norme ;
un systme de modulation et de dmodulation, qui permet de moduler le signal en bande
de base sur la porteuse lmission, et deectuer lopration inverse pour la rception. Ce
systme est gnralement en partie analogique et en partie numrique ;
une chaine doprations, appele couche PHYsique (PHY), qui transforme lmission la
suite de bits envoyer en un signal en bande de base selon des caractristiques propres la
norme. A la rception, une chaine doprations duale eectue le traitement inverse an de
restituer la squence de bits mise ;
un protocole, appel couche Medium Access Control (MAC), qui dnit quelle suite de bits
sera envoye quel moment sur quel canal. La couche MAC reoit les donnes du rseau et
les transfre la couche physique.
Les Application Specic Integrated Circuit (ASIC) sont communment utiliss pour supporter
une norme de communication dans un terminal radio. Un terminal radio contient autant de p-
riphriques matriels quil y a de rseaux auxquels il est susceptible de se connecter. Lutilisation
de priphriques matriels permet actuellement datteindre les performances requises en termes
de taille, de consommation et de dbit.
Alors que la multiplication des normes supportes par un simple systme gnre une aug-
mentation de la surface de silicium requis par les ASIC, que de nouvelles normes arrivent sur le
march rgulirement, que toutes ces normes sont sujettes de nombreuses volutions et mises
jour, la notion de exibilit sinvite dans la rexion concernant la conception des futurs sys-
tmes communicants. On ne veut pas seulement implanter des rseaux de manire performante,
et en limitant la consommation dnergie. On veut pouvoir faire voluer ces rseaux, et les im-
planter de manire intelligente. Cette exibilit peut sappuyer sur dirents types de circuits :
1. ce qui reste tout de mme leur fonction premire
1
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
CHAPITRE 1. INTRODUCTION
logiciel sur processeurs (gnralistes ou non), matriel paramtrable, Field-Programmable Gate
Array (FPGA), . . .
La notion de exibilit recouvre plusieurs aspects. Elle permet de grer la coexistence, voire
la coopration entre units de calcul htrognes. Mais, au-del de cette possibilit oerte aux
futurs systmes, elle permet aussi dorir aux systmes une forme dintelligence dans leurs capac-
its dadaptation leur environnement. Ces capacits dadaptation peuvent servir pour dirents
objectifs :
changer les paramtres intrinsques dun codeur pour sadapter aux dfaillances du canal et
rduire les erreurs ;
changer de norme en fonction de la distance lmetteur, du dbit requis ;
teindre des lments qui ne servent pas et les r-allumer ds que ncessaire ;
utiliser une puce unique pour excuter direntes normes, potentiellement en concurrence
(multimode).
Cette liste nest pas exhaustive.
Si lutilisateur peut souhaiter mettre jour certaines caractristiques de son systme en fonc-
tion de ses besoins, il ne veut pas que sa communication soit coupe parce que le codeur change
de paramtres ou que le systme a dtect quil peut communiquer avec une norme plus conome
en nergie. La capacit du systme sadapter doit donc tre intgre tout en conservant la qualit
du service oerte lutilisateur. La notion de exibilit prend lallure dun d pour les systmes
venir.
Problmatique gnrale et contributions
La exibilit ultime en informatique reste le logiciel. Cependant, la radio logicielle reste ex-
primentale, utilisable uniquement avec des processeurs puissants, des plateformes ddies, ou
des normes requrant peu de calculs. On peut galement se demander si cest vraiment un objectif
atteindre. La recherche ne seectue plus rellement au niveau de la radio logicielle mais du
dveloppement des processeurs, puisquon peut dicilement rduire le nombre minimal dopra-
tions requises pour une norme. En attendant lmergence de processeurs susament puissants qui
narriveront peut tre pas, dautres solutions peuvent tre utilises qui permettent dj une certaine
exibilit. Elles se basent sur lutilisation dunits de calcul htrognes. On peut par exemple
envisager lutilisation de processeurs spcialiss, que ce soit des Application Specic Integrated
Processor (ASIP) ou des Digital Signal Processor (DSP). Nous tudions dans cette thse une unit
assez rcente pour ce type de calculs, le Graphics Processing Unit (GPU). Ces units proposent
une puissance de calcul norme (de lordre du TFlop/s pour les plus puissants !), mais sont bases
sur une architecture complique exploiter. Nous verrons comment on peut en bncier.
Mais des units matrielles sont galement utilisables. Ces units sont conues pour raliser
une opration donne, mais sont paramtrables pour pouvoir modier leur fonctionnement. Cer-
tains coprocesseurs Fast Fourier Transform (FFT), par exemple, peuvent calculer des transformes
pour dirents nombres de points. On peut aussi dnir des encodeurs ou des dcodeurs canal pro-
grammables. De plus en plus darchitectures matrielles voient le jour qui permettent une certaine
exiblit. Ces architectures sont htrognes, cest--dire quelles utilisent des units direntes.
Elles ne permettent pas de tout faire, mais sont tout de mmes capables de balayer des ensembles
assez large de possibilits, en utilisant le plus possible les acclrateurs, et en compensant en logi-
ciel les lments non ralisables en matriel. Le problme des plateformes htrognes rsident
dans la dicult les utiliser. Une plateforme logicielle est dans un sens simple programmer,
mme si le systme qui permet de la contrler est complexe. On fournit du code, et quelle que soit
la plateforme qui lexcutera, on pourra conserver le mme code. Les possibilits de plateformes
htrognes sont beaucoup plus nombreuses, parce quon peut mettre les acclrateurs que lon
veut, pour les oprations que lon veut. Il y a une innit de possibilits. Nous nous intressons
2
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
ces plateformes htrognes dans cette thse, en proposant un environnement capable dabstraire
nimporte quelle unit, et en proposant une mthode originale de gestion des units matrielles
paramtrables.
Plan de la thse
Cette thse est ordonne en 6 chapitres. Le premier chapitre est cette introduction.
Le chapitre 2 prsente la problmatique de la radio exible et de cette thse en gnral et les
points particuliers sur lesquels portent nos travaux.
Le chapitre 3 est ddi ltat de lart. Nous prsentons plusieurs travaux raliss dans le do-
maine de la radio exible, qui ont aliment notre rexion. Nous nous attardons sur les plateformes
radio htrognes tudies par dautres quipes de recherche.
Le chapitre 4 est consacr lutilisation du GPGPU pour la radio exible. La conception dune
application radio base de GPU et son intgration dans une chaine de communication logicielle
sont tudies thoriquement. Des exprimentations sont menes et les rsultats sont prsents et
analyss.
Le chapitre 5 dtaille un nouvel environnement de radio exible ralis pendant cette thse.
Lenvironnement et ses enjeux sont prsents avant daborder des aspects prcis comme la gestion
des units dexcution htrognes, lintgration dunits matrielles ou limpact du contrle sur
les applications. Des cas pratiques dutilisation de lenvironnement sont ensuite proposs.
Finalement, les conclusions gnrales de cette thse sont donnes dans le dernier chapitre.
Celui-ci souvre sur des perspectives de complments, damliorations ou dvolution des travaux
eectus, et du domaine en gnral.
Quatre chapitres dannexe sont galement joints. Lannexe A contient les rsultats numriques
complets pour lutilisation du GPU dans la radio exible.
On donne la dmonstration dans lannexe B de la correction dune implantation parallle dun
ltre rcursif.
Lannexe C prsente de manire plus dtaille linterface de lenvironnement dni dans le
chapitre 5.
Finalement, lannexe D donne des dtails dimplantation de FRK pour lutilisation avec du
matriel ddi.
3
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
4
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
Chapitre 2
Problmatique
D
ans ce chapitre, nous abordons dirents problmes lis la radio exible. Comme nous
avons pu le voir dans lintroduction, la notion de exibilit est prendre en compte lors de
la conception dun terminal radio. Cette exibilit nest cependant pas exempte dinconvnients,
en particulier au niveau de lintgration. Nous donnons ici une dnition plus prcise de la radio
exible, et nous discutons ensuite les axes adresss dans ces travaux de thse.
2.1 Contexte de la thse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1 Modle rseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2 Chane de communication . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Rseaux exibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1 Radio classique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.2 Radio recongurable . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.3 Radio exible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.4 Radio cognitive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.5 Interactions radio exible/radio cognitive . . . . . . . . . . . . . . . . 11
2.2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Radio exible : de multiples possibilits . . . . . . . . . . . . . . . . . . . . 12
2.3.1 Scnarios de reconguration . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.2 De multiples cibles de reconguration . . . . . . . . . . . . . . . . . 13
2.3.3 Conclusion sur la radio exible . . . . . . . . . . . . . . . . . . . . . 15
2.4 Choix de limplantation : volution . . . . . . . . . . . . . . . . . . . . . . 15
2.4.1 Performance de la radio logicielle . . . . . . . . . . . . . . . . . . . . 15
2.4.2 Essor du GPGPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.3 Problmes du GPGPU pour la radio logicielle . . . . . . . . . . . . . 16
2.5 Environnement de reconguration unique . . . . . . . . . . . . . . . . . . 16
2.5.1 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5.2 Gestion de la recongurabilit . . . . . . . . . . . . . . . . . . . . . . 17
2.5.3 Intgration de la radio exible . . . . . . . . . . . . . . . . . . . . . . 18
2.5.4 Gestion de la reconguration . . . . . . . . . . . . . . . . . . . . . . 18
2.5.5 Conclusion : besoins dun environnement exible . . . . . . . . . . . 19
2.6 Conclusion gnrale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
2.1. CONTEXTE DE LA THSE CHAPITRE 2. PROBLMATIQUE
2.1 Contexte de la thse : les rseaux sans l
Les travaux raliss durant cette thse se situent la frontire entre les rseaux et larchitecture
des systmes. An de pouvoir prsenter la problmatique que nous adressons, il convient de dnir
correctement larchitecture gnrale dun terminal radio.
2.1.1 Modle rseau
Tout dabord, les normes rseaux actuelles sont divises selon un modle en couche, le modle
Open Systems Interconnection (OSI).
Le modle OSI, prsent dans la gure 2.1, est un modle bas sur 7 couches distinctes, cha-
cune des couches tant spcie pour remplir un objectif bien prcis. Dans un terminal rseau,
chacun de ces niveaux est capable de dialoguer avec son quivalent dans un autre terminal. Un
niveau donn reoit des requtes de la couche directement au dessus, et met des requtes vers la
couche directement en dessous.
Figure 2.1 Modle OSI
On sintresse principalement aux deux premires couches du rseau, la couche physique (ap-
pele PHY), et la couche de liaison de donnes (data link layer). La premire couche est en con-
tact direct avec le medium utilis pour la transmission des donnes. Dans le cadre de la radio, ce
medium est le domaine des ondes lectromagntiques.
La seconde couche est conue pour permettre le transfert entre deux terminaux du rseau.
Elle se divise en deux sous-couches, la couche Medium Access Control (MAC), qui permet de
grer eectivement laccs au milieu, surtout dans le cas daccs multiples, et la couche Logical
Link Controller (LLC), qui gre normalement le contrle derreur en plus dautres attributions. On
regroupera par abus de langage sous la mme appellation "MAC" lensemble des lments de la
couche 2.
2.1.2 Chane de communication
La partie physique dun rseau est gnralement reprsente comme une chane de communi-
cation, permettant de transposer linformation du domaine numrique au domaine analogique en
utilisant des techniques de modulation. Cette chane de communication correspond ce que nous
appellerons dans ce mmoire une application radio. Une chane type extrmement simplie est
prsente dans la gure 2.2.
La chane de communication est donc idalement reprsente sous la forme dun graphe.
Chaque nud reprsente une tche et les artes qui relient les nuds reprsentent les commu-
nications (donnes) entre les tches. Ce graphe peut-tre assimil un pipeline. On peut utiliser
6
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
CHAPITRE 2. PROBLMATIQUE 2.2. RSEAUX FLEXIBLES
Figure 2.2 Exemple de chane de communication type pour un rseau sans l
le modle de programmation Synchronous Data Flow pour reprsenter cette application, les ratios
entre les entres consommes et les sorties produites pour chaque tche tant connus.
2.2 Vers des rseaux de plus en plus exible
La exibilit devient une notion incontournable des rseaux sans l [Tut02]. Le terme de
exibilit est utilis, dans ce contexte, pour caractriser un lment du rseau qui nest pas g
dans un mode de fonctionnement. Cet lment peut tre le rseau lui-mme, ou bien un terminal
rseau, ou encore un lment de ce terminal. Depuis la formalisation de la radio logicielle en
1992 [Mit92], la notion de exibilit dans la radio a pris de lampleur et est maintenant devenue
un des principaux domaines de recherche associs aux liaisons sans l.
Cependant, cette notion de exibilit est oue. Une multitude de termes se rapportent plus
ou moins la radio exible, il est par consquent dicile den donner une dnition prcise.
Nous recensons dans cette partie les termes les plus utiliss, an de clarier la rexion autour
des travaux raliss dans le cadre de cette thse. Nous employons la terminologie utilise dans
[DZD
+
05].
2.2.1 Radio classique
On dnit un terminal radio comme un appareil capable dmettre et de recevoir des don-
nes modules sur des ondes lectromagntiques du domaine radio-frquentiel (RF). On dnit
une chane de communication radio comme la squence dactions eectuer pour transmettre ou
recevoir les donnes. La chane de transmission prend donc en entre un ux de donnes trans-
mettre, et fournit en sortie une onde lectromagntique. La chane de rception prend en entre
londe lectromagntique, et fournit en sortie un ux de donnes, qui correspond aux donnes
transmises par lmetteur.
Les domaines frquentiels et dimplantation pour un rcepteur superhtrodyne usuel sont
prsents en gure 2.3. Le domaine RF est la sortie directe de lantenne. Le rcepteur eectue
couramment un ltrage et une amplication, qui sont plus simplement raliss en analogique.
Les rcepteurs superhtrodynes utilisent une frquence intermdiaire (FI), qui sobtient en
mlangeant le signal RF un signal issu dun oscillateur local. Ce signal intermdiaire est gale-
ment ltr, puis dmodul an dobtenir le signal en bande de base (BB). Ces oprations sont
couramment ralises en analogique galement. Le signal bande de base est ensuite chantillonn,
an de raliser les oprations suivantes en numriques (synchronisation, demapping, dsentrelace-
ment, correction derreur, . . . ).
Dans une implantation traditionnelle dune chane de communication, tous les lments de
la chane sont implants laide de matriel ddi sur ASIC. Cette solution prsente le meilleur
rapport consommation/performance/surface. Elle limite galement la dicult dintgration dans
une plateforme complte, puisque les communications ne sont pas la seule fonctionnalit attendue
dun systme informatique moderne. Il ny a en eet pas besoin de rajouter de connaissance de la
7
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
2.2. RSEAUX FLEXIBLES CHAPITRE 2. PROBLMATIQUE
Figure 2.3 Reprsentation dun rcepteur superhtrodyne : implantation et frquences
chane de communication dans le systme, uniquement de grer un priphrique.
La multiplication des normes rseaux remet en cause la pertinence de cette approche classique
car la conception de terminaux "multistandards", cest--dire qui supportent plusieurs normes de
communication, imposerait la multiplication dimplantations ddies. Il y a donc une limite rapi-
dement atteinte quant au cot de la multiplication des implantations matrielles ddies.
2.2.2 Radio recongurable
2.2.2.1 Vision gnrale
Un terminal radio recongurable est un terminal qui utilise le mme matriel pour excuter
plusieurs chanes de communication direntes (les applications radio). On distingue ici deux
proprits :
ladaptabilit [DZD
+
05][GC97][KH00], qui sapplique plutt la chane de communica-
tion, et qui lui permet de sadapter lenvironnement ambiant en faisant varier un ensemble
de valeurs connues, comme par exemple le taux de codage ou la constellation de la modu-
lation ;
la recongurabilit [DZD
+
05][KMR00], qui est une proprit du terminal, et qui dnit
sa capacit modier en profondeur la structure de lapplication ou des lments qui la
composent.
Ces deux proprits sont bien sr non exclusives. Lorsquon parle de radio recongurable, on
sintresse donc des implantations de terminaux radio qui permettent une modication profonde
de la chane de communication.
2.2.2.2 Software Radio
La radio logicielle ("software radio" en anglais) est une mise en uvre de la radio recongu-
rable, dans laquelle les lments qui composent une chane de communication sont implants en
logiciel, et sont donc excuts par des processeurs gnriques [Mit92][Jon05][Tut02].
La radio logicielle reprsente la vision idale de la radio recongurable. Lantenne est directe-
ment relie un chantillonneur (convertisseur analogique numrique), qui peut fonctionner une
frquence susante pour respecter le critre de Shannon-Nyquist, cest--dire
f
s
2 f
c
avec f
c
la frquence de londe porteuse, et f
s
la frquence dchantillonnage. Les modications de
domaines par rapport la radio classique sont prsents sur la gure 2.4. Il ny a plus de frquence
intermdiaire, toutes les oprations sont ralises directement en numrique, et sur un processeur
gnrique (General Purpose Processor (GPP)).
8
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
Figure 2.4 Reprsentation dun rcepteur idal de radio logicielle
Cependant, dans des systmes radio, on travaille sur des frquences dont lordre de grandeur
varie entre la dizaine de mgahertz (10
7
Hz), et la dizaine de gigahertz (10
10
Hz). Ltat de la
technique sur les chantillonneurs commerciaux permet actuellement datteindre, un prix lev,
des frquences de lordre de 3 Gch/s. titre dexemple, les convertisseurs de National Semicon-
ductor, sur 8 bits, 3 Gch/s (rfrence : ADC083000CIYB-ND), se vendent aux alentours de 800
dollars lunit (en juin 2011). La cible nest donc pas llectronique grand public.
Au-del du problme de lchantillonnage, si on prend la norme WiFi qui opre 2.4 GHz,
traiter 4.8 10
9
chantillons par seconde avec des oprations de traitement du signal complexe
est un d intressant mais dicile relever avec les capacits de traitement actuelles. Daprs
une tude des normes Global System for Mobile communications (GSM) et Universal Mobile
Telecommunication System (UMTS), [Alh10] estime les besoins en calcul pour le GSM (porteuse
autour de 900 MHz) 10 GIPS, et pour lUMTS (mme porteuse) 100 GIPS. On notera que les
tudes divergent quant cette complexit. Ainsi, [TR08] estime 100 MIPS le GSM, et 6 GIPS
le Wideband Code Division Multiple Access (WCDMA) (comparable lUMTS).
LUMTS nest donc mme pas thoriquement ralisable sur un processeur Intel Xeon actuel,
malgr ses 4 curs et 8 threads potentiels. Raliser une plateforme de radio logicielle requiert la
conception dune architecture multiprocesseur intgre trs haute performance. Ceci est ralis-
able, mais pose des problmes de cots, de consommation, de surface, et galement de contrle
logiciel.
2.2.2.3 Software-Dened Radio
La radio logicielle est donc un concept, qui est atteignable en utilisant une plateforme ddie,
mais qui dans la pratique soure de problmes de consommation et dencombrement qui limitent
son dveloppement commercial.
An de pallier ce problme de performance requise, le concept de Software-Dened Radio
[Jon05] (radio logicielle restreinte [Alh10] en franais) fait intervenir un traitement prliminaire
de londe, an de rduire la frquence en entre du systme logiciel. La partie logicielle ne sap-
plique donc qu un sous-ensemble du terminal radio complet. Il y a galement une gnralisation
du terme logiciel, qui ne dsigne plus simplement lexcution sur un processeur gnralis, mais
lutilisation dune architecture qui permet la reconguration (GPP, DSP, FPGA, ou autres fonc-
tions ddies recongurables).
On prsente sur la gure 2.5 les domaines correspondants la SDR. La partie RF est gre
par une entit matrielle, qui se charge dappliquer les ltres et de slectionner uniquement la
bande de frquence souhaite. La translation de frquence vers une frquence intermdiaire est
galement eectue par ce front-end RF. Le signal analogique rsultant est ensuite numris, puis
transmis au logiciel SDR, qui est donc en charge du traitement numrique du signal. Ce logiciel
peut sexcuter sur un FPGA, sur un DSP, ou encore sur un processeur classique.
9
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
2.2. RSEAUX FLEXIBLES CHAPITRE 2. PROBLMATIQUE
Figure 2.5 Reprsentation dun rcepteur ralisable de SDR
2.2.3 Radio exible
La radio exible est un concept distinct de la radio recongurable, daprs [DZD
+
05]. Cest
galement un concept extrmement ou. [DZD
+
05] dnit la notion de exibilit comme un en-
semble de proprits qui permettent une implantation volutive de la radio, comme par exemple
la recongurabilit, ladaptabilit, la modularit, lextensibilit,. . . Daprs [PRR
+
03], un terminal
prsentant une seule de ces caractristiques peut tre considr comme un terminal exible. On
peut galement trouver le terme de radio logicielle tendue.
La exibilit englobe de nombreux domaines. On sintresse principalement ici la exibi-
lit de la couche physique, ainsi qu la mise disposition de cette exibilit dans les couches
suprieures. Ainsi, un protocole de routage "exible" sort du domaine abord, alors que la prise
en compte dans la couche MAC de la possibilit de changer la modulation, par exemple, en fait
partie.
2.2.4 Radio cognitive
2.2.4.1 Terminal de radio cognitive
Finalement, la dernire notion lie la radio exible est la radio intelligente (cognitive ra-
dio) [MM99][Jon05]. Un terminal de radio cognitive est capable danalyser son environnement
et de ragir aux potentiels changements. Dans un monde idal, un terminal de radio intelligente
est un terminal capable de communiquer avec nimporte quelle autre entit, intelligente ou non,
en sadaptant aux modes de communications des autres entits. Il est galement capable doprer
dans des conditions de transmission diciles, ou encore de sintgrer dans des "trous" de com-
munication dautres entits (radio opportuniste). Il se base sur les capacits de la radio exible, et
permet doptimiser lutilisation du spectre.
Figure 2.6 Cycle simpli dun terminal intelligent [MM99]
Un terminal de radio cognitive peut tre dcrit de faon simplie comme sur la gure 2.6
[MM99]. Le terminal surveille en permanence son environnement. Cet environnement peut tre
10
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
dni de direntes manires, selon lapplication. En fonction du rsultat de cette surveillance,
le terminal dcide quelle sera sa conguration, et transmet lunit de reconguration les modi-
cations eectuer. Tout ce cycle sorganise autour dun apprentissage. La radio cognitive peut
tre utilise dans direntes applications. Par exemple, elle peut permettre de crer un terminal
radio qui peut se connecter nimporte quelle norme radio porte, an de communiquer avec
nimporte quel terminal. Mais lune des utilisations principales du concept de radio cognitive est
actuellement laccs dynamique au spectre radio (Dynamic Spectrum Access, DSA).
2.2.4.2 Radio opportuniste
La radio opportuniste est un eort pour optimiser lutilisation des bandes de frquence, sous
licence ou non. Un rseau opportuniste est un rseau secondaire, qui communique en prsence
dautres rseaux (le rseau primaire tant le rseau ociel) de manire invisible pour ces autres
rseaux.
La radio opportuniste temporelle sattache combler les trous dans une bande de frquence
donne. Le projet Oracle [ora] est un exemple de ce type dapplication. Il vise crer un rseau
secondaire permettant lchange dinformations alors quun rseau primaire de type WiFi, utilisant
le CSMA/CA, est prsent.
La radio opportuniste frquentielle ou spatiale cherche utiliser les frquences sous licences,
mais non utilises dans une zone donne du fait de la rpartition en cellules du rseau. Lexemple
typique de cette application est lutilisation des TV White Space (TVWS)[qos][cog]. La diusion
de la tlvision se fait sur des bandes de frquences sous licence. Cependant, an dviter les
interfrences, le rseau de diusion est divis en cellules. Deux metteurs adjacents ne se verront
pas allouer la mme bande de frquence. Il existe donc des trous dans lutilisation du spectre
frquentiel. Le passage au tout numrique pour la tlvision est galement une opportunit pour
cet axe de recherche, avec la libration des bandes de frquence prcdemment utilises par la
tlvision analogique.
2.2.5 Interactions radio exible/radio cognitive
2.2.5.1 Dirences de terminologie
Selon les tudes sur le sujet, on peut trouver direntes terminologie pour les dirents do-
maines abords prcdemment. Ainsi, la radio exible dans notre cas reprsente une implantation
exible dune application radio, alors que dans dautres tudes, elle peut reprsenter le domaine
gnral de la radio volutive, et donc inclure la radio cognitive. De mme la radio logicielle peut
galement se dcliner en radio logicielle tendue, et inclure ce que nous appelons la radio exible.
2.2.5.2 Architecture dun terminal radio
Un terminal radio volutif peut donc tre compos de deux lments :
la partie cognitive, qui se concentre sur la prise de dcision, et sur la rponse apporter aux
modications denvironnement ;
une implantation exible, qui excute les applications radio, et ore la possibilit de modi-
er son fonctionnement.
Cette dcoupe en deux couches de limplantation cohabite avec la dcoupe en couche du mo-
dle OSI. On prsente sur la gure 2.7 une architecture conceptuelle dun terminal radio.
Le sondage eectu par la radio cognitive correspond en fait un retour dinformation fait
par limplantation de lapplication radio. Cette implantation correspond au domaine de la radio
exible. Toutes les couches du modle OSI peuvent tre concernes. De mme, la phase daction
du cycle de la radio cognitive correspond nalement une modication de limplantation, elle
11
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
2.2. RADIO FLEXIBLE CHAPITRE 2. PROBLMATIQUE
Decider
Agir Sonder
Radio cognitive Radio Ilexible

Application
Presentation
Session
Transport
Reseau
Liaison
Physique
Figure 2.7 Interactions entre radio exible et radio cognitive
correspond donc des ordres donns la partie radio exible du terminal. On entrevoit dj ici la
ncessit de faciliter ces ordres et lutilisation de la radio exible.
2.2.6 Conclusion
Il existe donc plusieurs manires daborder la radio exible. On approfondira dans cette tude
les notions de recongurabilit et dadaptabilit, et plus particulirement leur intgration dans le
contexte de la radio exible et cognitive.
Lun des avantages majeurs de la radio exible (et cognitive) rside dans le moment de la
prise de dcision. Alors que dans un systme classique, la prise de dcision se fait en amont de la
spcication du rseau, dans la radio exible, cette prise de dcision est distribue, la fois dans le
temps et entre les dirents acteurs, de la spcication lexcution. Le systme est ainsi capable
de changer dynamiquement son fonctionnement pour sadapter son environnement.
Cependant, lajout de la exibilit un terminal ne se fait pas sans heurts. Un terminal de
radio classique est simple en termes dintgration et de contrle. Il prend en entre des donnes
transmettre, quelques paramtres pour le contrle, et fonctionne en bote noire. Plus un terminal
devient exible, plus ce contrle et cette intgration se compliquent.
2.3 Radio exible : de multiples possibilits
2.3.1 Scnarios de reconguration
Dans la radio exible, la reconguration peut suivre dirents scnarios [KM02][MBGS03]
selon lobjectif recherch. Chaque scnario prsente sa propre problmatique.
2.3.1.1 Adaptation
Tout dabord, ladaptabilit permet de modier le fonctionnement de la radio dans le but de
ladapter au rseau. Dans un tel scnario, un terminal, ou le rseau lui-mme, intgre des algo-
rithmes de prise de dcision qui lui permettent, selon son environnement, de modier son fonc-
tionnement.
La complexit rside dans les critres et les algorithmes permettant de prendre les dcisions
dadaptation. Le champ de la modication est gnralement connu, et la transformation du ter-
minal reste limite une gamme de fonctionnement nie et matrise, contrlable par un jeu de
paramtres numriques (cf. 2.2.2.1).
12
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
CHAPITRE 2. PROBLMATIQUE 2.3. RADIO FLEXIBLE
2.3.1.2 volution des normes
Un deuxime scnario possible est le scnario de la mise jour de la radio. La prise de dcision
nest pas intgre la radio, mais est eectue par des acteurs externes au systme. En rgle
gnrale, ces acteurs sont les lments responsables de la maintenance du systme.
Il existe de nombreuses illustrations de ce cas de gure. Par exemple, dans le domaine de la
tlphonie, ce scnario peut tre utilis pour toutes les volutions mineures des normes, comme
par exemple le passage de lUMTS lHSPA, sans avoir modier toute linfrastructure (et donc
changer les stations de base, lments coteux du rseau). Dans ce cas, la dcision de mise jour
est prise par loprateur responsable de linfrastructure faire voluer.
Ce scnario fait appel la notion de recongurabilit, mais dans un cadre statique. Dans le
cadre dune mise jour, on peut se permettre dteindre temporairement un systme. La dcision
de reconguration est externe au systme, et les algorithmes de prise de dcision du systme sont
donc inexistants.
Par contre, le besoin de recongurabilit est plus large que pour ladaptation. Dans le cadre de
ladaptation, seule une partie du systme est modie, dans le respect de la spcication initiale
des lments le constituant. Cela peut tre fait en cours de fonctionnement. Dans le cadre de la
mise jour, une nouvelle version des lments, rpondant de nouvelles spcications, peut tre
charge, venant potentiellement modier lintgralit de la chane de communication.
2.3.1.3 Multimode
Le cas du multimode est le plus complexe et le plus dlicat. Dans un scnario multimode, la
reconguration a lieu an de permettre lutilisation de plusieurs rseaux dirents en utilisant le
mme matriel.
Lexemple du smartphone est une bonne illustration du scnario. Ces appareils sont gnrale-
ment quips de plusieurs mthodes de connexion sans l, les plus courantes tant la tlphonie
(GSM, GPRS, EDGE, UMTS, HSPA), les rseaux locaux (WiFi) et les rseaux personnels (Blue-
tooth). La coexistence de ces dirents rseaux se fait gnralement par la coexistence de plusieurs
ASIC gs, chacun tant spci pour excuter une norme.
An dviter cette multiplication des ASIC, il est envisageable de mettre en place un com-
posant gnrique, capable dexcuter toutes ces normes, et de se recongurer selon les besoins de
manire dynamique. Ce scnario fait appel la recongurabilit, mais galement des algorithmes
de prises de dcision. La reconguration est temporellement beaucoup plus contrainte que dans
le cas dune volution, et doit tre faite dynamiquement et de faon transparente pour lutilisateur
(ou le systme qui utilise les direntes chanes de communication).
2.3.2 De multiples cibles de reconguration
La recongurabilit dune plateforme peut satteindre de direntes manires, selon les be-
soins lis au scnario envisag. Le problme du choix de la solution est intimement li au com-
promis classique performance/exibilit, comme prsent sur la gure 2.8 [Kha02][MGT01]. On
parle ici de performance nergtique, cest dire du rapport entre la performance (en termes de
capacit de calcul) et lnergie dpense pour atteindre cette performance.
2.3.2.1 Cibles logicielles
La cible logicielle est la plus exible des possibilits, dans ltat actuel des connaissances.
En eet, si on ne considre pas la performance et les dicults pratiques de mise en place de
la radio logicielle, un processeur est virtuellement capable dexcuter nimporte quelle opration,
tant quon lui fournit le programme qui la dcrit.
13
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
2.3. RADIO FLEXIBLE CHAPITRE 2. PROBLMATIQUE
Figure 2.8 Reprsentation du rapport exibilit/performance de direntes solutions dimplan-
tation
En pratique, il est dicile dignorer les aspects de performances et de consommation. Dans un
systme embarqu, la consommation dun processeur est nettement suprieure celle dun ASIC.
Les implantations utilisant des ASIC sont certes ges, mais extrmement performant avec une
consommation rduite. Les aspects de consommation mis part, la question de la performance
peut tre aborde dun autre point de vue : la sparation entre lapplication elle-mme et lex-
cutant de cette application. Dans la radio traditionnelle, le concepteur de lapplication conoit le
circuit qui permettra dimplanter une norme. Dans ce but, il recherche un compromis visant
raliser un circuit de petite taille rpondant aux exigences de dbit imposes par lapplication tout
en tenant compte de la technologie du circuit et de lergonomie nale du produit. Dans la radio
logicielle, le concepteur dploie lapplication sur une cible dont la puissance de calcul est limite
et indique par le fondeur du processeur.
Cette limite externe de performance est compense par la mise en place darchitectures base
de multiples processeurs htrognes (DSP), qui augmentent dautant la complexit de mise en
uvre. En eet, le surcot li la gestion de ces architectures, qui sajoute la complexit de
la gestion de la radio logicielle elle-mme (chemins de donnes, contrle, interactions avec les
couches hautes, reconguration, . . . ), rendent ces implantations extrmement lourdes. La com-
plexit de la radio logicielle nest pas lie limplantation dalgorithmes de traitement du signal
qui sont dj connus, mais lintgration de ces algorithmes et la gestion dynamique de leur
excution. Ceci rejoint des problmatiques darchitecture des systmes intgrs.
2.3.2.2 Matriel recongurable
La dnition dacclrateurs matriels recongurables permet de rpondre en partie au prob-
lme de performance de la radio logicielle. Cependant, la perte de gnricit lie lutilisation de
matriel est sensible.
An de dnir du matriel recongurable ecace, cest--dire permettant datteindre des per-
formances susantes en gardant la place requise sous contrle, il est ncessaire de trouver un
compromis entre gnricit et performance. Alors que les approches logicielles font le choix de la
gnricit "absolue", les solutions de matriels recongurables se basent sur des lments ayant
une fonctionnalit bien dnie (par exemple, un oprateur FFT), mais qui peuvent modier leur
fonctionnement (par exemple, changer le nombre de points de la FFT).
la dirence des techniques logicielles (ou apparentes), on dnit ici du matriel ddi, qui
restera en place. Dans les solutions logicielles, on charge une fonction logicielle sur un processeur
gnrique, qui va excuter cette fonction. La reconguration est simplement un changement de
fonction. Dans une solution base de matriel recongurable, lexcutant de la fonction, cest
dire lacclrateur matriel, est confondu avec la fonction, et la reconguration est donc limite
14
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
CHAPITRE 2. PROBLMATIQUE 2.4. CHOIX DE LIMPLANTATION : VOLUTION
sa gamme dexcution.
Ces approches font apparatre de nouveaux problmes, en particulier des problmes de con-
trle du matriel. Il nest pas envisageable, dans un cadre exible, de supprimer compltement
le logiciel. Linteraction entre le contrle logiciel et le matriel est un point crucial des environ-
nements base de matriel recongurable. De plus le nombre de possibilits pour rpondre un
besoin donn est tel quil ny a pas duniformisation et quil est ncessaire de fonctionner au cas
par cas pour le contrle.
Finalement, il pourrait tre envisageable de mettre en place des solutions mixtes base de
matriel recongurable et de logiciel. De telles mthodes combinent les avantages du logiciel et
du matriel : tant que lapplication reste dans le cadre du matriel dni, il est possible dutiliser
ce matriel. Mais si un besoin ponctuel non gr par le matriel apparat, il est possible dabsorber
cet cart en utilisant le logiciel. Ces approches sont cependant diciles mettre en place, cause
des transferts de donnes requis, et de la synchronisation.
2.3.3 Conclusion sur la radio exible
Les possibilits dutilisation et dimplantation de la radio exible sont donc trs vastes. Lob-
jectif est dobtenir des terminaux capables de sadapter leur environnement. Ceci passe en partie
par la possibilit de recongurer le terminal. Les techniques de radio exible taient pressenties,
au dbut des annes 2000, comme les solutions miracles, qui seraient adoptes trs largement
dans un dlai de 10 ans [Tut02]. Mme si des progrs ont t faits, ces solutions restent encore
majoritairement exprimentales.
Dans le domaine de la radio recongurable, les recherches se concentrent gnralement sur
la dnition de composants permettant une reconguration et sur des architectures intgrant ces
composants. Le problme rside dans le peu dinteroprabilit entre les direntes implantations.
La dcision dutiliser la radio exible pour une implantation commerciale impose le choix dune
solution. Ce choix est dterminant car le dveloppement qui sera ralis sur cette solution ne
pourra pas tre utilis pour une autre mthode.
Au del de ce problme du choix de larchitecture recongurable, se pose le problme de
lintgration de cette architecture avec les algorithmes de radio exible ou cognitive. Il y a un
besoin de faire cooprer les lments qui grent ces algorithmes (gnralement, des lments
logiciels rattachs la couche MAC), aux lments qui vont eectivement rpercuter les dcisions
(la partie recongurable). La multiplication des possibilits posent galement un souci dans ce
cadre, puisque pour chaque mthode de recongurabilit, il faut revoir lintgration.
2.4 Choix de limplantation : volution
La radio logicielle utilise donc des processeurs pour implanter la chane de communication de
la radio. Cependant, cette solution dimplantation se heurte de nombreux problmes, en particu-
lier des problmes de performance et de gestion des direntes tches.
2.4.1 Performance de la radio logicielle
Les chanes de communication radio sont gnralement implantes en matriel, dans un envi-
ronnement non exible. En eet, elles utilisent un modle de pipeline de tches particulirement
adapt une implantation matrielle, et les oprations trs coteuses utilises dans les normes sans
l rendent loptimisation ncessaire pour atteindre les dbits requis.
Alors que la radio logicielle est une solution optimale en termes de exibilit, la performance
nest pas vraiment au rendez-vous. En eet, le modle pipeline qui est utilis ne se prte pas
15
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
2.5. ENVIRONNEMENT DE RECONFIGURATION UNIQUE CHAPITRE 2. PROBLMATIQUE
vraiment aux processeurs, qui ne peuvent excuter quune opration la fois, et qui doivent donc
rendre les calculs squentiels.
Ceci dtriore considrablement les performances en terme de dbit atteignable des solutions
de radio logicielle. Lutilisation de plateformes multiprocesseurs est une solution aux problmes
dadquation application/architecture, puisque limplantation dun pipeline devient possible, mais
ne rsout pas les problmes doptimisation.
Les processeurs simple cur ne se trouvent plus que dans les systmes embarqus pour
lesquels lnergie consomme est un lment cl du systme. Cette squentialisation du pipeline
nest donc que partielle. De plus, la forte progression de la puissance de calcul des processeurs
actuels permet galement datteindre des dbits intressants. Cependant, dautres solutions peu-
vent tre envisages, qui permettraient de librer les processeurs pour son usage de base, tout en
orant potentiellement un meilleur dbit accessible.
2.4.2 Essor du GPGPU
Le calcul gnral sur processeur graphique (General Purpose computing on Graphics Pro-
cessing Unit (GPGPU)) est un domaine de recherche assez rcent, li lvolution des Application
Programming Interface (API) graphiques. Alors que les oprations taient trs cibles au dpart,
le besoin en gnricit pour certains calculs est devenu de plus en plus important, ce qui a men
une utilisabilit du GPU pour des calculs autres que des calculs purement graphique.
Un GPU est une architecture base dune multitude de curs de calculs dgnrs. Ces curs
sont uniquement capable dexcuter des oprations, mais pas de grer toutes les tches annexes
dun processeur habituel, cest dire la gestion dun programme, les branch, et autres oprations
non calculatoires.
La gestion de ces oprations annexes est dlgue une entit spare, qui contrle les curs.
Cest donc une architecture de type Single Instruction Multiple Data (SIMD) (ou SPMD selon les
cas), capable dexcuter une seule instruction ou programme sur une multitude de donnes.
Les GPU tant lorigine ddis au traitement de limage, de nombreuses oprations de type
traitement du signal sont proposes et optimises.
2.4.3 Problmes du GPGPU pour la radio logicielle
Il peut paratre intressant dutiliser le GPU pour augmenter encore le dbit atteignable par
des applications de radio logicielle. Cependant, le problme dadquation application/architecture
est encore plus prsent dans ce cas. Alors que la paralllisation des processeurs permet dexcuter
plusieurs tages du pipeline en parallle, la paralllisation interne du GPU, de type SIMD, ne
permet pas cette amlioration.
Si on prend lexemple de la radio logicielle sur un ordinateur standard, avec deux processeurs
4 curs, cette architecture permet en thorie dexcuter en concurrence 8 tages du pipeline.
An davoir un intrt en termes de performances pures utiliser un GPU, il faudrait que celui-ci
excute ces 8 tages squentiellement plus rapidement, ce qui implique un gain moyen par tage
suprieur 8, ce qui est trs lev.
Lintgration dapplications de radio logicielle sur un GPU nest donc pas intuitive, et il nest
pas garanti quun gain soit observable.
2.5 Environnement de reconguration unique
2.5.1 Objectifs
Le dveloppement de la radio cognitive et la multiplication des plateformes cibles pour la radio
logicielle crent de nouveaux besoins. An de permettre lexcution ecace de la radio cognitive,
16
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
CHAPITRE 2. PROBLMATIQUE 2.5. ENVIRONNEMENT DE RECONFIGURATION UNIQUE
et lutilisation optimale des plateformes, il est ncessaire dintgrer les direntes techniques de
radio exible (matriel recongurable, logiciel sur GPP, DSP ou GPU, . . . ) dans un mme envi-
ronnement. Il est galement ncessaire de faire collaborer ces solutions avec des algorithmes de
prise de dcision qui permettent de bncier au mieux de la recongurabilit pour le protocole.
Cette collaboration pose le problme plus gnral de lintgration des dirents domaines de la
radio exible.
Lintelligence de la radio exible est gnralement implante en logiciel, alors quil existe
direntes manires dimplanter la partie oprative. Cette intgration peut ds lors tre envisage
comme un simple programme logiciel, qui utilise les units fonctionnelles matrielles ou logi-
cielles en ayant une connaissance complte de ce quils font. Si on prend lexemple du H-ARQ,
la partie protocolaire, qui prend la dcision de choisir une certaine conguration du composant,
rpercuterait cette dcision directement sur la partie PHY. Cependant, le moindre changement
dans la plateforme, que ce soit sur lenvironnement logiciel, ou sur la partie PHY de lH-ARQ,
impose dimplanter nouveau le protocole.
Dans cette section, on sintresse aux dirents problmes rsoudre an dobtenir un envi-
ronnement uni et ecace pour la radio exible. On utilise, cette n, la plateforme reprsente
dans la gure 2.9. On y trouve des lments matriels recongurables, des lments dexcution
logicielle (processeurs, spcialiss ou non), des lments de mmorisation, et des entres/sorties
(E/S) classiques dun systme de ce type.
Figure 2.9 Architecture de plateforme exible gnrique
On envisage donc de mettre en place un environnement pour la radio exible capable de sex-
cuter sur cette plateforme gnrique, et de sadapter aux modications de la plateforme.
2.5.2 Gestion de la recongurabilit
La recongurabilit est une proprit lie limplantation [KMR00]. Lorsquun systme pos-
sde cette proprit, son fonctionnement est susceptible dtre modi.
Cette proprit de recongurabilit sobtient de direntes manires, comme voqu en
section 2.2. La multiplication des implantations recongurables, quelles soient logicielles ou
matrielles ou les deux, est le premier point grer lors de lintgration des dirents lments de
la radio exible dans un environnement unique.
17
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
2.5. ENVIRONNEMENT DE RECONFIGURATION UNIQUE CHAPITRE 2. PROBLMATIQUE
La mise en place de solutions recongurables passe souvent par une phase de slection du type
de recongurabilit souhait, en fonction des avantages des direntes mthodes. Une fois ce type
choisi, on intgre les lments de recongurabilit soit au niveau du systme dexploitation (pour
les lments matriels), soit directement au niveau de lapplication (pour les lments logiciels et
matriels).
Ce manque dabstraction nuit la exibilit, car il empche dintgrer des solutions qui pour-
raient tre avantageuses en termes de recongurabilit, et limite galement le dveloppement al-
gorithmique et protocolaire, puisquil faut chaque fois adapter limplantation de lalgorithme
la plateforme que lon utilise. De manire gnrale, la partie protocolaire du rseau na pas be-
soin de connatre les dtails du fonctionnement des lments recongurables. Que ceux-ci soient
logiciels ou matriels, le seul objectif pour le protocole est dtre capable de signaler le mode de
fonctionnement qui convient, quel que soit la mthode utilise pour limplanter.
La gestion de la recongurabilit au niveau de lenvironnement est donc un point cl dun
environnement uni. Cette gestion soulve plusieurs interrogations. Tout dabord, les couches
hautes ont besoin dune abstraction des oprateurs ncessaires la radio, quil convient de dnir.
Ensuite, les mcanismes de rpercussion de modications depuis la couche haute jusqu llment
permettant eectivement de raliser lopration ne sont pas immdiats. Finalement, en plus de la
gestion de la recongurabilit au niveau de la fonctionnalit, il faut aussi se poser la question de
la recongurabilit des connexions entre les dirents lments.
2.5.3 Intgration de la radio exible
Les environnements existant actuellement sont principalement des environnements de recon-
guration spciquement conus pour une solution. Cependant, an de permettre lutilisation de la
radio exible dans les meilleures conditions possibles, il est intressant de se pencher sur loppor-
tunit dtendre ces environnements recongurables des environnements exibles, cest--dire
intgrant les algorithmes de prise de dcision propres la radio exible (ou par extension la radio
cognitive).
Les algorithmes dits "cross-layer" qui tendent augmenter la coopration entre les couches
traditionnelles du rseau, sont mettre sur le mme plan que les algorithmes exibles. Ils soulvent
un problme plus large, puisquil peut galement tre ncessaire de modier le fonctionnement de
la couche MAC.
Cette intgration nest donc ni vidente ni immdiate. Il faut, pour la rendre eective, rsoudre
le problme de la place des algorithmes propres la radio exible dans le rseau, cest--dire de
leurs interactions avec les couches MAC et PHY, du rseau.
2.5.4 Gestion de la reconguration
La reconguration se gre dirents niveaux [KM02], en fonction de la granularit souhaite,
et des connaissances du niveau considr. Au niveau de la gestion dun composant matriel unique,
la reconguration est un processus purement systme, alors quau niveau dun terminal radio com-
plet, la reconguration impose la connaissance des normes rseaux, et de lenvironnement.
La gestion de la reconguration couvre plusieurs points :
une reprsentation de ltat dun systme pour les couches de haut niveau. Ce point est
primordial an de permettre lintgration des couches hautes voque prcdemment. Les
algorithmes de prise de dcision, qui vont dcider de lopportunit et de la teneur dune
reconguration, ont besoin dune reprsentation de ltat dun systme uniformis, et in-
dpendante de la plateforme ;
un mcanisme de traduction de cette reprsentation en une reprsentation comprhensible
pour une plateforme donne. Celui-ci sapparente une compilation dune conguration sur
une plateforme donne.
18
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
CHAPITRE 2. PROBLMATIQUE 2.6. CONCLUSION GNRALE
une gestion des tats possibles, qui inclut un mcanisme de changement dtat. Ces m-
canismes sont mis en uvre lexcution, et peuvent avoir supporter des contraintes
temporelles fortes.
2.5.5 Conclusion : besoins dun environnement exible
La radio exible est une technique dimplantation de terminaux radio qui permet denvisager
une meilleure coopration des lments du rseau, et donc datteindre une meilleure utilisation des
ressources. Cependant, elle englobe plusieurs solutions, base de logiciel ou de matriel recon-
gurable, qui peuvent sexcuter sur direntes cibles.
Il devient donc ncessaire dunier ces solutions dans un mme environnement, an de per-
mettre un vrai dveloppement de la radio exible. Un tel environnement permettrait en eet de
rassembler de manire homogne les dirents domaines impliqus dans la exibilit, en les
isolant les uns par rapport aux autres et donc en leur masquant les dicults et spcicits des
autres domaines.
An de concevoir cet environnement, il faut se pencher sur les dirents lments qui com-
posent la radio exible, et sur les interactions entre ces lments.
Des bauches denvironnement existent actuellement, mais qui ne permettent pas dintgrer
nimporte quelle solution, et surtout qui nintgrent pas des lments des couches hautes, pourtant
indissociables de la radio exible.
2.6 Conclusion gnrale : objectifs des travaux
En rsum, ces travaux se placent dans le contexte de la radio exible. Deux axes princi-
paux sont tudis, lun portant sur lutilisation du GPU dans un contexte de radio logicielle, an
damliorer les performances, et lautre axe traitant de lunication des dirents domaines et des
diverses solutions de la radio exible. Ces deux axes se rejoignent en un seul objectif, permettre
lintgration dunits htrognes pour une application de radio exible.
Plus prcisment, nous tenterons de rpondre aux questions suivantes :
Comment utiliser de manire ecace le GPGPU pour la radio logicielle ? Les GPU pro-
posent une architecture assez peu adapte aux application de radio logicielle, cependant leur
puissance potentielle de calcul est norme, et pouvoir les utiliser ecacement permettrait
denvisager des dbits qui sont pour linstant une utopie ;
Comment intgrer les oprations sur GPU dans une application radio ? Au del de lutilisa-
tion ecace thorique, il est important de pouvoir intgrer ecacement ces oprations dans
une vraie application, qui devra probablement faire appel dautres units ;
Quelle solution adopter pour utiliser les acclrateurs matriels dans une application de
radio exible ? Ces acclrateurs peuvent orir un certain niveau de exibilit tout en per-
mettant datteindre un meilleur dbit quune solution logicielle, avec un cot nergtique
moindre. Intgrer ces acclrateurs peut donc permettre denvisager des plateformes exi-
bles embarques ;
Au del de ces considrations dintgration dunits spciques, le nombre de possibilits
pour implanter un terminal radio a considrablement augment ces dernires annes. La
structure en couches dune norme rseau impose cependant aux couches de haut niveau de
connatre les couches de bas niveau disponibles. La multiplication du nombre de solutions
dimplantation est donc un frein la recherche. Ds lors, le problme de lintgration de
ces direntes solutions devient primordiale. Deux problmes se posent alors, en plus des
questions voques prcdemment :
quelle architecture dnir pour permettre lexcution dune application sur ces architec-
tures htrognes ?
19
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
2.6. CONCLUSION GNRALE CHAPITRE 2. PROBLMATIQUE
comment dcrire et traduire une application radio, an de permettre une certaine gnri-
cit dans la description, et de sadapter nimporte quelle plateforme qui lexcutera ?
20
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
Chapitre 3
tat de lart
D
ans ce chapitre, nous prsentons un ensemble non exhaustif de solutions lies la radio
exible, et plus particulirement la radio recongurable.
tant donne lactivit intensive de recherche autour des problmatiques de radio cognitive,
la littrature sur ce sujet est abondante. Elle aborde le domaine sous plusieurs angles, qui vont
des algorithmes de prise de dcision propres la radio exible et cognitive, des implantations
recongurables dlments bien prcis. Nous avons fait le choix de prsenter particulirement
deux aspects de la radio exible, qui ont fait lobjet de nos recherches durant cette thse.
Dans un premier temps, nous prsentons des techniques dexcution de la radio logicielle. Ces
techniques concernent en particulier des plateformes et direntes approches de la recongurabi-
lit dans la radio logicielle, et sont abordes dans la section 3.2. Dans un second temps, nous nous
intressons au contrle de lexcution et de la reconguration de ces plateformes, principalement
dun point de vue systme.
3.1 Reprsentation dune application radio . . . . . . . . . . . . . . . . . . . . 22
3.1.1 Reconguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1.2 Reprsentation des applications . . . . . . . . . . . . . . . . . . . . . 22
3.2 Plateformes de radio logicielle . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.1 Solutions base de processeurs . . . . . . . . . . . . . . . . . . . . . 23
3.2.2 Intgration des GPU . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.3 Utilisation de FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.4 Solutions hybrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.5 Matriel recongurable et adaptabilit . . . . . . . . . . . . . . . . . 25
3.2.6 Conclusion sur les plateformes . . . . . . . . . . . . . . . . . . . . . 26
3.3 Environnements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.1 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.2 Excution htrogne . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.3 Environnements complets . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4 Conclusion du chapitre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
21
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
3.1. REPRSENTATION DUNE APPLICATION RADIO CHAPITRE 3. TAT DE LART
3.1 Reprsentation dune application radio
3.1.1 Reconguration
3.1.1.1 Dnition gnrale
On dnit la reconguration comme un ensemble de 3 lments [KM02] :
une conguration initiale, avant la reconguration ;
une conguration nale, aprs la modication ;
un mcanisme de changement dtat, qui joue le rle de protocole de reconguration.
On appelle conguration ltat dans lequel se trouve le systme considr. Cette conguration
a une reprsentation, qui permet denregistrer ltat. Le mcanisme de changement dtat dpend
de la cible considre.
Prenons par exemple un noyau de systme dexploitation, le processeur tant la cible de la
reconguration, alors la conguration du systme est la valeur de ses registres, la reprsentation
est un tableau de registres, comportant les valeurs correspondantes au programme en cours, et le
mcanisme est la commutation de contexte. Si la cible de la reconguration est le couple pro-
cesseur/mmoire, alors la conguration est reprsente par ltat de la mmoire et par les registres
du processeur, un changement de conguration pouvant faire intervenir un chargement de pro-
gramme dans la mmoire.
3.1.1.2 Cas de la radio logicielle
Dans le cas spcique de la radio logicielle, ou de la radio recongurable en gnral, la recon-
guration est un processus hirarchique [DMLP05]. En eet, la cible de la reconguration peut se
situer dirents niveaux dabstractions.
Le premier niveau de reconguration est le plus haut niveau. Cest la partie cognitive de la
radio, qui se situe au niveau de la spcication de la norme. On ne sintresse pas lexcution de
la norme, ni aux spcicits de limplantation, mais uniquement ses fonctionnalits. Ce niveau
utilise donc une reprsentation abstraite des oprations possibles. Par exemple, une opration de
ltrage Finite Impulse Response (FIR), ou une opration de transforme FFT, mais sans connais-
sance du mode dimplantation de lopration.
Ces oprations sont fournies par le second niveau, que nous appelons niveau fonctionnel. Ce
niveau ore au niveau suprieur un ensemble doprations, et permet dassocier une implantation
sur la plateforme courante. Il possde donc une connaissance des spcicits du systme sur lequel
sexcute la norme.
Le dernier niveau sintresse aux lments recongurables. Il ny a plus de notion de fonction-
nalits dans ce cadre, uniquement des lments qui sont congurer de manire sadapter aux
ordres du second niveau. Un lment fonctionnel du second niveau peut avoir plusieurs implanta-
tion dans le dernier niveau. Par exemple, on peut implanter la mme fonctionnalit sur un DSP et
sur un GPP.
Cette hirarchisation, issue de [DMLP05], est prsente dans la gure 3.1. Nous distin-
guons dans cette tude la reconguration et la reprsentation. Les deux sont trs fortement lis.
[DMLP05] ne dtaille que la reprsentation.
3.1.2 Reprsentation des applications
Les applications radio sont appeles waveform. Celles-ci sont couramment reprsentes en
utilisant un graphe, dans lequel les nuds reprsentent les oprations, et les artes les transferts de
donnes [DDL10]. Cette vision en graphe de lapplication se prte bien lutilisation du modle
de programmation composant. Chaque bloc est dcrit en fonction de ses entres/sorties, et de
22
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
CHAPITRE 3. TAT DE LART 3.2. PLATEFORMES DE RADIO LOGICIELLE
Figure 3.1 Reprsentation et reconguration hirarchique [DMLP05]
lopration qui sera excute dans ce bloc. On peut ensuite connecter les direntes oprations en
utilisant des FIFO.
On trouve direntes philosophies dimplantation des waveforms. On distingue principale-
ment les implantations directes, comme celle de GNURadio [gnub], et les implantations indirectes
comme Software Communications Architecture (SCA) [sca01]. Dans les implantations directes, la
waveform est directement excutable telle quelle. GNURadio utilise du C++ ou du Python pour
crire ses waveforms, qui sont donc directement excute. Au contraire, SCA utilise un langage
de description pour dcrire ses waveforms, qui sont ensuite utilises par lenvironnement pour tre
excutes.
3.2 Plateformes de radio logicielle
La radio exible est clairement dpendante de capacit dun systme modier son mode de
fonctionnement.
Daprs la dnition donne en 2.2.2.1, la recongurabilit est une proprit qui dnit la
capacit dun systme modier son fonctionnement au-del dun simple changement de valeur
numrique. La recongurabilit est inclure dans le processus de conception dun terminal radio
[KMR00].
Cette section sattache prsenter certaines plateformes et approches permettant la recongu-
rabilit, dun point de vue architecture. On ne cherche pas dnir quelles techniques sont les plus
ecaces, uniquement balayer le plus largement possible les possibilits, ceci an de pouvoir les
intgrer dans un environnement uni, comme expliqu dans le chapitre prcdent.
3.2.1 Solutions base de processeurs
La recongurabilit dans le logiciel est intrinsque [KMR00]. En eet, il est trs simple dim-
planter plusieurs applications radio, et de passer de lune lautre en dchargeant et rechargeant
les codes compils correspondant. La dicult des approches logicielles rside dans le contrle
de ces chargements et dchargements, et dans la performance limite des processeurs compare
des solutions matrielles ddies.
On dnit gnralement comme logiciel, dans la radio exible, tout lment dont lexcutant
est spar de la fonction qui va tre excute. Ainsi, on peut dployer lapplication sur une cible
23
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
3.2. PLATEFORMES DE RADIO LOGICIELLE CHAPITRE 3. TAT DE LART
comme un GPP, un processeur ddi comme un DSP ou un GPU, ou un FPGA, les trois cibles
principales de la radio logicielle. Le choix de la cible est gnralement dict par le type dapplica-
tion et le contexte dexcution. Ainsi, les normes rseau qui requirent beaucoup de calculs auront
probablement besoin soit de nombreux processeurs gnriques, soit dutiliser des DSP. Dans un
contexte embarqu, on prfrera gnralement les DSP ou les FPGA, qui orent un meilleur rap-
port performance/nergie que les GPP.
La radio logicielle peut facilement tre dveloppe pour des plateformes qui ne sont pas
spciquement ddies cet usage. Par exemple, le projet GNURadio [gnub] peut tre d-
ploy sur des architectures PC classiques, ou sur des architectures embarques comme par ex-
emple la BeagleBoard [bea10][gnua]. On trouve galement beaucoup darchitectures dvelop-
pes spciquement pour excuter des applications de radio logicielle. Ces plateformes peu-
vent tre bases sur des DSP [Ram07][CAL] (avec laide dacclrateurs matriels), des FPGA
[HHP
+
09][MSA06][ASM
+
07]ou bien un mlange des deux [DMLP05]. Les plateformes base
de FPGA sont abordes dans la section suivante.
Dun point de vue applicatif, lutilisation de GPP pour lapplication transforme celle-ci en
application usuelle, mme si elle utilise un modle particulier. Elle est compile puis excute,
et la reconguration de la chane de communication se fait en lanant un nouveau processus.
Lintgration des DSP est plus complexe, mais reste dans le domaine du dveloppement logiciel.
3.2.2 Intgration des GPU
Avec le dveloppement de lusage du GPU pour le calcul scientique (GPGPU), la ques-
tion de lutilisation des GPU pour excuter des applications de radio logicielle a t le sujet de
plusieurs tudes. Dun point de vue architectural, les plateformes GPU peuvent aller de la carte
graphique dun ordinateur de bureau classique des architectures plus fouilles. Par exemple,
ltude [KHC10] propose une architecture matrielle et logicielle qui permet de bncier de la
puissance de calcul du GPU. Elle propose galement une implantation complte du protocole
WiMAX en utilisant le GPU.
Dun point de vue applicatif, ltude de lutilisation du GPU peut se faire avec deux objectifs
distincts :
concevoir une application spcique ;
utiliser le GPU dans le cadre dun environnement.
Dans le premier cas, on se place dans un cadre doptimisation classique. Il ny pas de spa-
ration entre lapplication et lenvironnement. On trouve une ralisation dun ltre polyphase dans
[HSM
+
08], dun rcepteur FM dans [SH09], dun dtecteur MIMO dans [WSGC11] et [WEL11],
de dcodeurs Turbo Code [WSC10] ou encore Low Density Parity Check (LDPC) [JCS11].
Dans le second cas, le problme est un peu dirent puisquon sintresse lintgration
doprations dans un systme.. On dnit des oprations primaires, qui pourront ensuite tre util-
ises pour dnir une application radio. Les oprations sont donc potentiellement plus petites, et
surtout, la gestion de la communication entre les direntes oprations pose problme. Les dif-
frentes tudes ralises sur GNURadio avec lenvironnement CUDA [NVI11] semblent donner
des rsultats limits [arc11]. Lintgration sous SCA [Mil10] semble plus ecace, cependant, les
tailles de vecteurs abordes sont trs grandes, ce qui ne correspond pas un cas pratique dutili-
sation de la radio logicielle. Une reprsentation des applications ainsi quune tude thorique de
lutilisation des GPU est propose dans [PZB
+
11]. Lutilisation des GPU est donc une question
ouverte, gnralement considre comme peu adapte aux applications radio.
3.2.3 Utilisation de FPGA
Les FPGA sont la cible de choix pour les applications de radio logicielle. Ils orent en eet
un bon mlange entre exibilit (utilisation dun langage de description) et ecacit (proche de
24
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
CHAPITRE 3. TAT DE LART 3.2. PLATEFORMES DE RADIO LOGICIELLE
celle dun ASIC).
Dans un cadre de reconguration statique, cest--dire quand la radio peut tre mise
hors ligne durant la reconguration, la ralisation dune application de radio logicielle
[MSA06][ASM
+
07][HHP
+
09] se penche principalement sur la dnition des briques de base
matrielles et sur la structure de lapplication.
Cependant, le manque de dynamisme des solutions FPGA ne permet pas de raliser ecace-
ment des terminaux multimodes. Le dveloppement des technologies de reconguration partielles
[Xil10] permet en partie de rsoudre ce problme [DPML07][HCS11], mais le temps de recong-
uration limite encore grandement lecacit de cette technologie.
3.2.4 Solutions hybrides
Finalement, lutilisation des 3 technologies (GPP, DSP/GPU, FPGA) prsente des avantages
et des inconvnients. Lune des solutions envisages pour compenser les inconvnients et lutil-
isation de plateforme hybride, utilisant les trois technologies. Une tude dune telle plateforme
est propose dans [TR08]. Elle prsente une architecture matrielle mixte GPP/DSP/FPGA, ainsi
quun environnement pour dvelopper sur une telle architecture. Cette tude reste supercielle,
il ny a pas dautomatisation du calcul, juste une rpartition et un interfaage entre le DSP et le
FPGA, et un OS temps-rel qui sexcute sur le GPP.
Dautres tudes sur des fonctionnement hybrides existent. On citera en particulier [DMLP05],
qui sintresse une architecture de calcul hybride DSP/FPGA.
3.2.5 Matriel recongurable et adaptabilit
Alors que les implantations de la radio logicielle sur des cibles telles que les GPP ou les FPGA
utilisent une dissociation entre la fonction implanter et llment recongurable qui permettra
de limplanter, il est galement possible dutiliser une approche ne ralisant pas cette dissociation.
Dans ce cas, le matriel utilis est indissociable de la fonction implante, ce qui sous-entend
gnralement une implantation ge.
Si on se concentre sur ladaptabilit, qui est lun des critres retenus dans [DZD
+
05] pour
dnir la radio exible, il nest pas ncessaire dutiliser une cible logicielle pour avoir cette pro-
prit. Un oprateur FFT, par exemple, peut tre adaptable en ajoutant la possibilit de changer le
nombre de points. Un modulateur peut tre adaptable si la constellation nest pas ge.
3.2.5.1 Paramtrisation et oprateurs communs
La paramtrisation est une approche dimplantation des terminaux de radio logicielles
1
qui
consiste utiliser un jeu de paramtres pour dnir le systme [Jon02]. Une application, cest-
-dire une norme rseau, peut ds lors tre reprsente comme un ensemble de paramtres, et
recongurer le systme consiste en un changement de paramtres actifs.
La technique des oprateurs communs [APR
+
11] est un driv de cette technique. Elle vise
extraire de direntes normes potentiellement excutable sur une plateforme des oprateurs "in-
divisibles", qui reprsentent les oprations de base dune norme radio. Ces oprateurs communs
peuvent ensuite tre implants sur nimporte quelle cible, logicielle ou matrielle (ASIC). Cest la
mise en commun de ces oprateurs qui dnit quelle sera la fonctionnalit rellement implante.
3.2.5.2 ASIC et SOC
Lutilisation dASIC adaptables pour implanter un terminal recongurable est galement une
mathode qui a t envisage. LeoCore [LNT
+
09] est un processeur bande de base conu partir
1. cette approche est beaucoup plus gnrale, mais nous nous concentrons ici sur la radio logicielle
25
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
3.3. ENVIRONNEMENTS CHAPITRE 3. TAT DE LART
dun NoC, qui embarque tous les lments dun systme de transmission radio usuel, et qui utilise
une modication des chemins entre ces lments pour se recongurer.
Il existe un autre systme base de NoC, Magali [NKM
+
09]. Ce systme utilise un coeur GPP
et des coeurs DSP pour la partie exible ainsi que des acclrateurs matriels gs pour certaines
oprations comme lH-ARQ, le codage, ou encore la modulation. La proprit dadaptabilit est
susante pour permettre lutilisation des ces oprateurs dans plusieurs normes, des DSP sont
disponibles pour les cas o le matriel ne sut pas.
3.2.6 Conclusion sur les plateformes
Lintrt croissant pour la recherche sur les techniques de radio cognitive (et donc exible) a
conduit la multiplication des techniques employes pour permettre lexcution des normes, ou
la reconguration.
Concernant les plateformes pour lexcution de la radio recongurable, le nombre de possibil-
its est presque inni. On trouve des plateformes base de GPP uniquement (ordinateurs de bu-
reau), ou de DSP, ou encore de FPGA. On trouve galement des mlanges de toutes ces solutions.
Des approches pour le GPU commencent galement voir le jour dans le cadre dapplications
spciques.
Dautres approches base de NoC existent. Ces techniques permettent dutiliser des ASIC
adaptables, plus ecaces que les solutions logicielles comme les DSP ou les FPGA, et de con-
necter ces ASIC laide dun NoC. Ceci permet de modier les squences dactions eectuer.
On se retrouve donc face une multitude de techniques possibles, avec pour chacune, une
mthode de gestion dirente. Cette multiplication des solutions appelle donc une unication du
contrle, qui peut tre fournie des environnements de reconguration.
3.3 Environnements
3.3.1 Objectifs
Limplantation dune norme de radio exible est donc actuellement ralisable sur de nom-
breuses plateformes. Cependant, ces plateformes ne servent qu excuter lapplication qui est
dploye. Le contrle de lexcution de cette application, ainsi que sa reconguration, doivent
galement tre prises en compte.
Les environnements de radio logicielle sont dvelopps pour satisfaire ces contraintes. Ils ser-
vent dinterface entre la reprsentation de lapplication et son excution relle, et prennent donc
en compte les spcicits de la plateforme. Ils orent galement une interface de reconguration
aux couches suprieures.
Nous prsentons ici plusieurs environnements de radio logicielle, avec chacun leurs spci-
cits.
3.3.2 Excution htrogne
Au-del de la radio logicielle, beaucoup dtudes se sont penchs sur les possibilits dex-
cution utilisant des lments htrognes. On sintresse ici ces possibilits, qui peuvent tre
utilises dans le cadre de la radio logicielle. Lorsquon intgre des lments de calcul dans un
systme, deux points sont prendre en compte :
le contrle de llment, qui permet de dnir ce quil va faire, de le synchroniser, et de
modier son fonctionnement le cas chant ;
les communications qui permettent damener llment les donnes sur lequel il va devoir
travailler.
26
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
CHAPITRE 3. TAT DE LART 3.3. ENVIRONNEMENTS
3.3.2.1 Acclrateurs matriels
Dans le cas des acclrateurs matriels ou des coprocesseurs, le contrle dpend du type dac-
clrateurs. Si celui-ci est intgr au processeur, comme dans le cas des coprocesseurs du MIPS
[MIP92] ou du ARM [ARM05], alors le contrle se fait en utilisant des instructions spciques
dans un programme.
Si on utilise un acclrateur matriel connect un bus, avec des registres, on utilise gnrale-
ment une interface priphrique telle que dnie dans la norme Portable Operating System Inter-
face for Unix (POSIX) [fIT03].
Le transfert de donnes entre le monde logiciel (mmoire vive) et les coprocesseurs est un
problme plus complexe [HPA01]. Lutilisation de FIFO est la mthode classique, quelles soient
logicielles ou matrielles.
3.3.2.2 Intgration des FPGA
On distingue ici deux types dutilisation du FPGA. Dans un premier cas, le FPGA est utilis
comme un ASIC, mais peut tre modi si besoin est. Cest le cas classique dutilisation, dans
lequel le fait que ce soit un FPGAqui est utilis est secondaire. Une fois lapplication termine, elle
nest jamais modie. Dans ce cas, le contrle sapparente un contrle dacclrateur matriel.
Dans le second cas, le FPGA peut tre recongur partiellement durant lexcution. Lintgra-
tion des lments potentiellement recongurables est alors problmatique. On se heurte en fait
un problme majeur dordonnancement, qui peut se rsumer ainsi : quand et quoi doit-on recon-
gurer ?
Une solution possible est de voir le FPGA comme un processeur [ANJ
+
04]. Dans ce contexte,
les lments recongurer deviennent lquivalent des programmes logiciels. Ils sont dcrits avec
un langage (VHDL, SystemC, . . . ) puis synthtiss et placs/routs pour la cible (au lieu dtre
compil pour un processeur). Il convient ds lors de les intgrer comme des tches part en-
tire dans le systme, avec une partie xe qui remplace les structures de processus des systmes
dexploitation classiques. On trouve dans [ANJ
+
04] les extensions ncessaires du systme dex-
ploitation. Cette approche est reprise dans [MHV
+
09][LP08][WCW
+
09].
3.3.2.3 Excution htrogne GPP/DSP
Lintgration des DSP dans un systme utilise le domaine plus gnral des systmes
htrognes. Utiliser des processeurs dirents dans une mme plateforme peut se rvler utile,
puisque chaque processeur a ses inconvnients qui peuvent tre contrebalancs par les avantages
des autres. Cependant, le dveloppement dune application devient rapidement complexe. Si on
passe sur les dicults dans le choix du processeur utiliser pour chaque tche, il reste grer
lintgration de processeurs ayant chacun leur propre interface daccs la mmoire, leur propre
jeu dinstruction, ou pire encore, leur propre "boutisme" (endianness).
On distingue alors deux approches pour grer cette intgration. Il est possible dutiliser une
approche distribue, base sur un systme dexploitation (OS) global [Gue10], qui intgre une
reprsentation de la plateforme, et qui dnit les mthodes utiliser pour chaque type de pro-
cesseur. Lapproche propose dans [Gue10] sappuie sur un ot de gnration.
Il est galement possible dutiliser une approche centralise, dans laquelle un GPP est uti-
lis comme contrleur, et donne les ordres et les donnes aux autres processeurs. La spcication
OpenCL [ope10] est un exemple de cette approche. Lenvironnement OpenCL dnit une archi-
tecture base sur un hte qui excute toutes les oprations de contrle, et sur des lments de
calcul qui sont commands par lhte. Les changes entre lhte et les lments sont bass sur
des FIFO. La dnition dune tche implique lcriture dun noyau (kernel) qui dnit le calcul.
Lapplication OpenCL cre des contextes dexcution lors de son initialisation. Ces contextes sont
27
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
en fait des associations entre des queues de contrle, et un ou plusieurs lments de calcul. Il y a
ensuite une compilation des kernel pour les contextes sur lesquels ils seront excuts. Ainsi, si un
kernel peut sexcuter sur un DSP et sur un GPP, il sera compil pour ces deux entits. Lors de
lexcution, le programme compil associ au contexte est employ.
Larchitecture OpenCL peut galement tre utilise pour les calculs sur GPU. En revanche,
cause des spcicits du processeur graphique, il est dicile de mettre en oeuvre lapproche
distribue.
3.3.3 Environnements complets
3.3.3.1 SCA
Le premier (et principal) environnement complet de radio logicielle est la norme propose par
le Joint Tactical Radio System (JTRS) Joint Program Oce (JPO). Cette norme baptise SCA
[sca01][SMM05][JXJQ09] est issue du domaine militaire. Elle est maintenant maintenue par le
Wireless Innovation Forum. La norme spcie une interface pour dnir une waveform (cf.3.1.2).
Limplantation eective de cette waveform est ensuite libre. On notera que SCA nest pas un
environnement proprement parler, mais plutt une spcication. Il y a donc une certaine libert
dans limplantation, et donc une variation possible entre direntes implantations.
Figure 3.2 Architecture de lenvironnement SCA
Larchitecture de SCAest prsente sur la gure 3.2. Tout sarticule autour du Core Framework
(CF), lenvironnement central, reprsent en gris clair. Le CF dnit toutes les interfaces pour
les dirents lments de SCA. La norme utilise une approche oriente objet, et donne donc les
dnitions dirents niveaux. Ainsi, par exemple, llment Resource est une interface pour la
conguration des composants logiciels. Cet lment sert en fait de base une multitude dautres
lments, comme par exemple les NetworkResource, qui gre des entits rseaux. Dautres types
peuvent galement hrite de cet lment.
Les dirents types de matriels sont supports par llment Device. Cet lment se dcline
en plusieurs sous-types, selon le type de matriel considr. On trouve principalement le type
LoadableDevice qui reprsente un priphrique sur lequel on peut charger ou dcharger du logi-
ciel. Les FPGA et les DSP rentrent dans cette catgorie de Device. Tout lment matriel doit tre
encapsul dans un lment logiciel de type Device.
28
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
Toute la norme SCA sarticule autour de la norme Common Object Request Broker Architec-
ture (CORBA) [OMG08], ceci an de permettre la communication entre les dirents composants.
Il existe une implantation libre de SCA, baptise OSSIE [Tec], base sur limplantation OmniORB
de CORBA.
Lenvironnement repose sur un systme dexploitation existant, qui doit respecter la norme
POSIX. Ce systme est reprsent en gris fonc sur la gure. Il est possible davoir deux plate-
formes direntes, grce lutilisation du bus logiciel CORBA.
De notre point de vue, SCA et ses implantations sourent de deux problmes principaux :
le manque de dynamisme de la reconguration [GMSG08]. La norme a t conue pour
permettre une conguration ecace, et pour abstraire les spcicits du matriel. Cepen-
dant, elle ne permet que dicilement le passage dynamiquement dune application SCA
une autre. Diverses tudes sattachent rsoudre ce problme. Dans [CDPR10], plusieurs
approches sont exprimentes, bases sur un aiguilleur de donnes [Cor08]. Les rsultats
montrent que la solution fonctionne bien, mais elle reste une rustine pour ajouter une fonc-
tionnalit absente de la conception.
la forte connotation logicielle de la norme. Il nest que peu question dutiliser des acclra-
teurs matriels ou autres matriels ddis dans la norme SCA. Une tude de lintgration de
matriel spcialis dans SCA est propose dans [KB05].
La littrature montre galement que SCA est largement adopt dans le domaine. On trouve par
example [DBRC05] ou [BZZ08], qui prsente des exemples dutilisation de la norme.
3.3.3.2 RMA
Reconguration Management Architecture (RMA) [MGT01] est une architecture de gestion
de la reconguration qui sattaque principalement au problme de la topologie dun rseau qui
intgre des terminaux recongurables. Cest le plus haut niveau de la hirarchie de reconguration
prsente en 3.1.1.2.
RMA est une architecture scinde en deux parties. La premire partie, Conguration Control
Part (CCP), est ancre dans le rseau. Elle gre lauthentication du terminal, la connexion un
dpt de logiciel (qui enregistre les congurations), et les interactions avec le reste du monde.
Cette partie gre entre autres la rcupration du logiciel, la virtualisation de la conguration, et le
monitoring.
La seconde partie est centre sur le terminal. On distingue la partie conguration de la partie
radio. La partie conguration (Conguration Management Part, CMP), sert dinterface avec la
CCP, et implmente le gestionnaire principal de conguration, qui interagit avec tous les autres
lments. Linterface entre la CMP, et la partie radio (Radio Module Part, RMP) se fait au travers
des contrleurs de reconguration (Reconguration Module Controller, RMC). La conguration
du terminal est reprsente dans RMA par un tag-le, qui est un chier XML.
RMA est une proposition relativement ancienne, qui est aujourdhui supplante par les autres
solutions, en particulier par SCA.
3.3.3.3 GNURadio
GNURadio [gnub] est un environnement de radio logicielle dni an de permettre lexcution
et la conguration dune application radio couche basse sur un GPP. Il est bas sur une vision
"bloc" de la waveform, avec une modlisation Synchronous Data Flow de lapplication. Cest un
environnement abouti, encore en dveloppement, et trs actif.
La gure 3.3 est une reprsentation de larchitecture gnrale de GNURadio. Il y a une spara-
tion claire entre la partie calculatoire de lapplication et la partie contrle. GNURadio dnit trois
grands types dobjets :
les blocs, qui servent reprsenter les oprations ;
29
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
Figure 3.3 Architecture gnrale de GNURadio
les buers qui permettent dassurer les communications entre les dirents blocs ;
lordonnanceur (scheduler) qui spcie comment vont sexcuter les blocs.
GNURadio soure des mmes problmes que SCA : le projet est conu pour une application
logicielle sur GPP uniquement, et il soure dun manque de dynamisme dans la reconguration.
Cependant, il ne sappuie pas sur CORBA, et limite donc le surcot de communication, et les
dpendances avec le logiciel. GNURadio est un framework plus quun environnement de recon-
guration : il permet dcrire rapidement une application radio en utilisant des blocs dj connus,
mais la gestion de la reconguration est supercielle. Laccent est mis sur lexcution dune ap-
plication.
3.3.3.4 P-HAL/Aloe
P-HAL [RGMF05] et son successeur Aloe [GMSG08] sont deux environnements similaires
qui proposent une interface dabstraction de la plateforme, an de permettre une application de
sexcuter sur plusieurs plateformes utilisant P-HAL.
P-HAL est bas sur une architecture qui se dcoupe en 3 lments, comme reprsent sur la
gure 3.4 :
une reprsentation de lapplication (du type waveform) et une traduction de cette reprsen-
tation en tches comprhensibles par le systme ;
une couche d"intergiciel", qui sert dinterface entre lapplication et les excutants ;
les lments dexcution, qui se sparent en une couche logicielle, et une couche matrielle.
Lobjectif de P-HAL est comparable celui de SCA. Cependant, il ny a pas dutilisation de
CORBA, ce qui rduit les dpendances de lapplication. Il devient envisageable de dployer P-
HAL sur une architecture ne supportant pas CORBA. Le bus logiciel est ainsi remplac par la
couche de middleware qui permet de masquer les spcicits du matriel. Chaque plateforme est
ainsi vue comme une plateforme virtuelle P-HAL. La couche dintergiciel permet dajouter encore
labstraction an de transformer les plateformes multiples en une plateforme unique virtuelle.
Aloe [GMSG08][GMBG10][alo] est une volution de P-HAL. Cette volution est conue pour
permettre la radio cognitive, et ajoute en particulier une gestion temps rel des ressources de calcul,
qui passe par un monitoring prcis et ecace du systme. Cet ajout est ralis en conservant
les dveloppements prcdents de P-HAL, mais en ajoutant des services de contrle du systme
[GMSG08].
linverse de GNURadio, P-HAL/Aloe est un gestionnaire de reconguration, laccent est
30
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
Figure 3.4 Architecture gnrale de P-HAL/Aloe
mis sur le contrle de la plateforme, et sur linterface oerte aux autres lments dun systme de
communication.
3.3.3.5 MVR : Machine Virtuelle Radio
Une autre approche, propose en 2000 par Gudaitis et Mitola (daprs [Abd10], le document
ntant pas disponible) se base sur lutilisation dune machine virtuelle radio. Lobjectif de cette
mthode, baptise Radio Virtual Machine (RVM) est de dnir une machine virtuelle du mme
type que celle de Java, cest--dire en utilisant une approche composants et en se basant sur du
bytecode excutable par toute plateforme supportant la machine virtuelle.
Une utilisation de cette approche est propose dans [ARFD09] et [ARFM10]. Une implanta-
tion dune RVM base sur Lua est propose, ainsi quun cas pratique dutilisation sur la plateforme
Magali.
Cette approche base sur une machine virtuelle prsente de nombreux avantages. Elle permet
en particulier une vraie abstraction de lapplication radio. Elle permet galement une recongura-
tion simplie dun terminal, puisquil sut de transfrer le bytecode correspondant une norme
puis lexcuter. Cependant, malgr le rel intrt que prsente cette approche pour la exibilit,
certains points ne sont pas compltement satisfaisants, en particulier le surcot associ la ma-
chine virtuelle, et la dicult de gestion dun composant matriel. Ces travaux restent malgr tout
les plus proches de ce que nous proposons dans cette thse.
3.3.3.6 Surfer
Le dernier environnement prsent ici est Surfer [DDL10][DLD11]. Cest un environnement
relativement rcent, prsent pour la premire fois en 2010. Son architecture est classique.
Lobjectif principal de Surfer est de minimiser au maximum le surcot li au contrle de
lexcution des blocs, tout en optimisant au maximum le calcul des donnes. Il utilise pour cela
un schma dordonnancement distribu bas sur des seuils dans les buers dentre/sortie. Les
surcots, qui sont gnralement centraliss dans une tche de contrle, sont ainsi rpartis entre
les dirents blocs. Un autre objectif principal de Surfer rside dans le peu de dpendances avec
dautres lments. Lenvironnement est bas sur une couche dinterface avec le systme dex-
ploitation, qui doit tre adapte en cas de changement de systme. On note ici la dirence avec
SCA, qui requiert lutilisation dun systme POSIX. Cest la mme approche que dans P-HAL. La
31
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
3.4. CONCLUSION DU CHAPITRE CHAPITRE 3. TAT DE LART
collecte de statistiques en interne de chaque bloc (dans le cadre de la distribution du contrle) fait
galement partie des objectifs.
A partir de cet environnement, une approche de la reconguration dynamique est propose
dans [DLD11]. Lobjectif est ici de permettre le dlestage des processeurs an dorir une qualit
de service donne certaines communications. An dy parvenir, plusieurs implantations de la
mme fonctionnalit sont proposes dans Surfer. Un superviseur est implant, qui se sert des
capacits de collecte de statistiques des blocs an de dtecter sil y a besoin de changer de moyen
de calcul. Par exemple, une application sexcute sur une plateforme qui contient un GPP et un
GPU. Le GPP tant susant pour excuter cette application, il ny a pas de raisons de lancer
deux priphriques. Cependant, si une application externe est lance sur ce GPP, il risque de ne
plus sure. Le superviseur dlestera alors le GPP en lanant le calcul sur le GPU. Lapplication
reviendra sur le GPP une fois celui-ci allg. Sans prendre en compte le superviseur, la mthode
de reconguration dynamique est assez proche de [CDPR10] sur SCA.
3.3.4 Conclusion
Il existe beaucoup dtudes sur des environnements de radio logicielle. Les quatre principaux
prsents ici, SCA, GNURadio, P-HAL/Aloe et Surfer prsentent tous des intrts dirents. SCA
est principalement intressant parce quil est normatif, et extrmement rpandu. Cependant, il
dnit le framework, sans spcier lenvironnement dexcution proprement dit. De plus, lutili-
sation de CORBA est pnalisante, les problmes de latence dans les interfaces tant connus. Cette
dpendance a dailleurs t supprime de la dernire version de la norme [SCA11], de mme que
la dpendance POSIX. Elle reste cependant prsente dans les implantations. Par contre, SCA
fournit un bon support des matriels htrognes. GNURadio, bien quintressant dans sa con-
ception, et extrmement riche en termes de dveloppement, dvolutions, et dans sa bibliothque
dlments de calcul, est exclusivement dvelopp pour GPP. Le support dautres lments dex-
cution nest pas prvu, hormis les DSP (BeagleBoard). Il est galement dicile prendre en
main. La ralisation dune application simple est aise, mais la moindre modication demande de
connatre tous les dtails, et la marche franchir est haute. Finalement, la reconguration nest
pas rellement aborde dans lenvironnement, ce qui le rend insusant pour nos besoins. Il reste
cependant un environnement intressant en particulier pour le prototypage et la recherche.
P-HAL/Aloe est actuellement lenvironnement le plus proche de nos attentes. Il est conu
pour unier des plateformes htrognes sous une mme architecture. La possibilit de collecter
dynamiquement des statistiques orent des perspectives intressantes. Il est galement disponible
sous licence libre. Cependant, la reconguration des waveforms nest pas dynamique, et le support
des waveforms multiples nest pas disponible.
Surfer semble intressant, cependant, il nest pas disponible sous licence libre (et ne le sera
pas prochainement daprs le concepteur principal), et malgr lintrt quil prsente, il en reste
ses dbuts.
Finalement, tous ces environnements sourent de deux dfauts majeurs :
la gestion de ladaptabilit nest pas tudie ;
le support du matriel spcique nest pas abord.
Malgr leur intrt certain, ils ne rpondent pas compltement la problmatique de cette
thse.
3.4 Conclusion du chapitre
La radio exible est un domaine trs large. Il englobe toutes les techniques dimplantation de
terminaux radios qui ne sont pas ges, en particulier des solutions adaptables par modication de
32
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
CHAPITRE 3. TAT DE LART 3.4. CONCLUSION DU CHAPITRE
paramtres numriques, et des solutions recongurables par changement de la structure mme de
lapplication.
Plusieurs mthodes existent pour apporter des lments de rponse cette problmatique. La
radio logicielle utilise des cibles gnriques, comme les processeurs (GPP, DSP) ou les FPGA.
Lutilisation des GPU a galement t envisage, mais les rsultats ne sont pas la hauteur des at-
tentes. Certaines mthodes utilisent une conception particulire des lments matriels ddis, qui
peuvent excuter direntes oprations selon lagencement utilis. Finalement, il est galement
possible de multiplier les composants ddis, autant quil y a de normes implanter (mthode
"Velcro" [Alh10]).
La multiplication des implantations nuit au dveloppement des algorithmes qui tirent parti de
la exibilit. La ncessit de prendre en compte toutes les implantations possibles est un frein
leur dploiement. Lutilisation des environnements de radio exible permet de contrebalancer en
partie ce problme, en orant une interface gnrique aux couches suprieures. Cependant, les
environnements actuels prsentent des lacunes qui empchent datteindre ce but dabstraction de
la mthode utilise pour la exibilit :
les environnements sont dvelopps la plupart du temps pour une solution prcise, et non
pour prendre en compte toutes les implantations matrielles ;
les environnements existants ne prennent pas systmatiquement en compte la recongura-
tion dynamique de la chane de communication ;
lintgration des couches hautes, et donc des algorithmes de la radio exible et cognitive,
nest pas faite dans lenvironnement ;
la gestion du matriel ddie nest quasiment pas aborde.
33
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
3.4. CONCLUSION DU CHAPITRE CHAPITRE 3. TAT DE LART
34
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
Chapitre 4
Intgration du GPU dans la radio
logicielle
N
ous abordons dans ce chapitre lutilisation du GPU dans le cadre de la radio logicielle.
Comme voqu dans le chapitre 2, le GPGPU est un domaine qui permet dobtenir une
puissance de calcul norme avec un cot nancier limit. Cependant, appliqu au domaine de la
radio logicielle, les tudes prcdentes montrent des rsultats dcevants. Nous cherchons donc
rpondre la question suivante dans ce chapitre : comment peut-on tirer prot du GPGPU dans
le cadre dun environnement de radio logicielle ? On sintresse dans cette tude aux trois points
suivants :
la conception dune opration SDR sur le GPU;
lordonnancement ;
les transferts de donnes entre les oprations.
4.1 Introduction : le GPGPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.1.1 Origine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.1.2 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.1.3 Contraintes et objectif . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2 Utilisation optimise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.1 Oprations basiques . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.2 Oprations complexes : premire approche . . . . . . . . . . . . . . . 40
4.2.3 Proposition : maximisation de lutilisation . . . . . . . . . . . . . . . 41
4.3 Ordonnancement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3.1 Ecacit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3.2 Latence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3.3 Mmoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.4 Intgration distribue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.4.1 Prsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.4.2 Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.5 Intgration centralise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.5.1 Prsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.5.2 Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.5.3 En pratique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.6 Rsultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.6.1 Synthse des contributions . . . . . . . . . . . . . . . . . . . . . . . . 49
4.6.2 Oprations implantes . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.6.3 Protocole dexprimentation . . . . . . . . . . . . . . . . . . . . . . . 52
4.6.4 Rsultats des oprations unitaires . . . . . . . . . . . . . . . . . . . . 53
4.6.5 Rsultats pour des applications multitches . . . . . . . . . . . . . . . 56
4.7 Perspectives et conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.7.1 Discussion : portabilit vers lembarqu . . . . . . . . . . . . . . . . . 57
4.7.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
35
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
4.1. INTRODUCTION : LE GPGPU CHAPITRE 4. INTGRATION GPU
4.1 Introduction : le GPGPU
4.1.1 Origine
Les volutions successives des API graphiques, de DirectX en particulier, ont pouss vers une
gnricit de plus en plus grande des processeurs graphiques (GPU). Dunits extrmement sp-
cialises, ces processeurs sont devenus de plus en plus gnriques an de satisfaire les contraintes
de plus en plus larges des oprations de traitement graphique. Logiquement, ce gain en gnri-
cit a permis une ouverture de larchitecture traditionnellement limite aux API graphiques. Cette
ouverture a permis lmergence du GPGPU.
Le GPGPU permet dutiliser le processeur graphique pour eectuer des calculs "classiques",
en utilisant un environnement adapt. Le GPU ne peut pas tre utilis dans toutes les applications
du fait de son architecture SIMD qui ne permet aucun contrle dpendant des donnes dans un
programme. Cependant, bon nombre de traitement de donnes sont compatibles avec cette archi-
tecture. Le GPU permet alors un gain en performance non ngligeable.
Ces environnements tant extrmement dpendants du matriel utilis, chaque constructeur
fournit son propre framework (CUDA pour NVidia, Stream pour ATI). An dunier ces environ-
nements, et de les largir dautres architectures que les GPU, le Khronos Group
1
, qui avait dj
normalis lOpenGL, propose lenvironnement de programmation Open Computing Language,
OpenCL [ope10]. Cet environnement permet dutiliser des units de calcul htrognes, gres
par un hte. Mme si on sintressera principalement lOpenCL pour les GPU, la norme prvoit
la possibilit dutiliser des DSP ou des GPP, en conservant le mme modle de programmation.
Bien que les spcications soient dj disponibles, il nexiste pas encore notre connaissance
dimplantation complte dOpenCL. Chaque constructeur propose sa propre implantation, qui se
trouve tre une surcouche de lenvironnement propritaire. Ceci nuit lobjectif nal dOpenCL,
dans le sens o il nest pas possible dutiliser rellement des lments htrognes. Un systme
avec un GPU ATI et un GPU NVidia ne pourra pas utiliser ces deux GPU dans une mme appli-
cation.
4.1.2 Principe
An de bien poser le cadre de ltude, nous prsentons succinctement OpenCL, en particu-
lier larchitecture dune plateforme OpenCL et sa signication sur un GPU, et le format dune
application OpenCL.
4.1.2.1 Architecture dune plateforme OpenCL
Une plateforme OpenCL est une plateforme gnrique utilise pour reprsenter tous les types
dunits de calcul utilisables avec la norme. La gure 4.1 est une reprsentation de cette plate-
forme. Les traits pleins reprsentent les donnes, les pointills montrent le contrle.
Larchitecture est divise en deux parties, lhte et les computing devices. Lhte est un GPP,
qui est utilis pour le contrle de lapplication. Il se charge :
de linitialisation de lenvironnement OpenCL, avec lallocation des structures ;
de lallocation des zones mmoires requises pour lapplication, sur la mmoire hte et sur
la mmoire des devices ;
du lancement des direntes applications sur les devices.
Un device est un "priphrique de calcul" asservi lhte. Il peut tre un GPP, un DSP, ou
encore un GPU. Un device est subdivis en computing units (units de calculs), qui sont elles
mme spares en processing elements (lment de traitement).
1. On trouve parmi les membres du Khronos Group les principaux acteurs du domaine : AMD/ATI, NVidia, Intel,
ARM, Texas Instruments et STMicroelectronics en particulier
36
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
CHAPITRE 4. INTGRATION GPU 4.1. INTRODUCTION : LE GPGPU
Figure 4.1 Reprsentation dune plateforme OpenCL
Dans notre tude, nous nous intressons uniquement au GPU, et plus particulirement aux
GPU NVidia, qui ont servi pour nos exprimentations. Un GPU NVidia est bas sur la mme
architecture. Les PE sont appels cores, les CU sont appels MultiProcessors, et les devices sont
les GPU complets. Les PE sont des coeurs de calculs dgnrs, dans lesquels tous les lments
de contrle de lapplication ont t enlevs. Un PE ne peut pas grer son propre programme. Un
programme sexcute au niveau de lunit, qui contrle elle-mme linstruction qui sera excute.
Tous les PE excutent donc la mme instruction au mme moment, mais sur plusieurs donnes
direntes (SIMD). Les GPUs sont particulirement bien adapts pour le calcul vectoriel.
4.1.2.2 Format dune application
Lcriture dune application OpenCL passe par deux tapes : lcriture du kernel, qui spcie
le calcul qui sera ralis, et lcriture de lapplication hte, qui permet dutiliser lenvironnement
OpenCL.
La gure 4.2 reprsente larchitecture gnrale dune application hte OpenCL. On eectue un
calcul sur un vecteur. Un kernel reprsente lapplication unitaire qui sapplique sur chaque lment
du vecteur. Il peut tre fourni par lutilisateur, ou se baser sur une bibliothque. Les cl_devices ser-
vent reprsenter le priphrique physique. Les pilotes qui seront utiliss pour ces priphriques
sont masqus lutilisateur, seul lenvironnement dexcution (runtime) dOpenCL a connaissance
de ces spcicits.
Le contexte est llment dexcution de base pour lutilisateur. Il regroupe un ou plusieurs p-
riphriques sous une mme structure, ainsi quune FIFO de contrle. Les communications entre le
37
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
4.1. INTRODUCTION : LE GPGPU CHAPITRE 4. INTGRATION GPU
Runtime OpenCL
kernel
appli.
hte
Code utilisateur
Device Hte
Extensions
C99
API
OpenCL
Exec.
Compilation (hte)
clprogram
clkernel
clcontext
HW
device
HW
device
HW
device
HW
device
....
cldevice cldevice ...
c
o
m
p
i
l
e
e
x
e
c
u
t
e
Represente
Est utilise par
Materiel
Logiciel
Objets OpenCL
Figure 4.2 Architecture dune application OpenCL
programme OpenCL et lenvironnement ont lieu exclusivement en utilisant ces FIFO. Les kernels
sont compils en programmes durant linitialisation. Une compilation a lieu pour chaque contexte
sur lequel le programme sexcutera. Ces kernels sont ensuite excuts pour chaque lment du
vecteur par les PE, chaque instance du kernel est appele thread.
4.1.3 Contraintes et objectif
Lobjectif de ce chapitre est dtudier les direntes possibilits dimplantation de la radio
logicielle pour un processeur graphique. La radio logicielle a un haut niveau de gnricit. Lu-
tilisation du GPU pour ce type dapplication est donc plus complexe que pour une application
spcique. Une application spcique peut se concevoir en fonction du GPU pour avoir une ex-
cution optimise. Dans le cas de la radio logicielle, loptimisation devient plus complexe.
Une application de radio logicielle est une succession doprations applique des chantil-
lons. Ces chantillons proviennent du convertisseur analogique numrique branch sur la sortie
de lantenne. Les chantillons sont gnralement organiss en trame. Par exemple, lutilisation
de lOFDM comme technique de modulation impose lutilisation de vecteurs dchantillons. Les
oprations sont appliques sur ces vecteurs, lexemple typique restant la transforme de Fourier.
Il est toujours possible dextraire une unit de base sur laquelle sapplique lopration, cette unit
pouvant aller de lchantillon unique (une valeur) un paquet complet en sortie de la chane de
communication.
On utilisera dans ce chapitre GNURadio comme environnement de radio logicielle, mais l-
tude est facilement transposable dautres environnements.
38
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
CHAPITRE 4. INTGRATION GPU 4.2. UTILISATION OPTIMISE
4.2 Mthode pour une utilisation optimise
Dans cette section, nous prsentons trois mthodes pour utiliser le GPUdans un environnement
de radio logicielle.
4.2.1 Oprations basiques
On parle ici doprations basiques pour dnir les oprations qui sont eectues chantillon
par chantillon, sans notion de bloc. Ce sont des oprations gnralement simples, utiliss pour
les transmissions non organises, cest--dire sans sparation en blocs ou en trames. Le passage
dune opration une autre est gr, de manire conceptuelle, en utilisant des FIFO [gnub]. Une
opration, dans ce contexte, est donc un bloc logiciel qui lit une FIFO en entre, eectue son
opration sur les donnes lues, puis crit le rsultat sur une FIFO en sortie. Cette FIFO sera elle-
mme lue par lopration suivante de lapplication de radio logicielle. Ceci est reprsent sur la
gure 4.3.
Figure 4.3 Opration de radio logicielle
Lamplication est un bon exemple dopration basique, dont limplantation est prsente dans
lalgorithme 1. Lobjectif de lamplication est de multiplier lchantillon par un facteur amp
connu. On remarque que mme si la transmission nest pas organise en bloc, lopration seectue
sur un tableau, et utilise donc une boucle. Ceci est d au fonctionnement des environnements de
radio logicielle qui ne transfrent pas les donnes chantillon par chantillon pour des raisons
videntes de performance. SCA utilise une taille dchantillon, et travaille donc sur des tailles
constantes, GNURadio utilise des FIFO, et travaille donc sur les donnes disponibles.
Algorithm 1 Opration damplication
for all sample in input do
output[sample] input[sample] * amp
end for
Utiliser le GPU pour la radio logicielle dans ces conditions est relativement simple. On trouve
dans [Mil10] une tude complte de lintgration du GPU dans SCA, pour 5 oprations basiques
dans le cas dun traitement non organis : une dmodulation AM, une dmodulation FM, un am-
plicateur, une dcimation et une interpolation. Lapproche utilise est alors logique. On dnit
comme kernel pour le GPU le corps de la boucle. Le CPU nest plus utilis pour le calcul, mais
uniquement pour transfrer les donnes au GPU et lancer le kernel sur lensemble des chantillons
lentre. La gure 4.4 reprsente la modication dans lopration. Le code correspondant pour
lamplication, sans les initialisations, est donn dans lalgorithme 2.
Lapproche classique [Mil10] donne de bons rsultats dans une transmission non organise,
condition de travailler sur susamment dchantillons en mme temps pour maximiser lutilisa-
tion du GPU. Daprs [Mil10], le nombre dchantillons minimum pour observer un gain en temps
de calcul pour le GPU par rapport au CPU est de 1024.
39
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
4.2. UTILISATION OPTIMISE CHAPITRE 4. INTGRATION GPU
Figure 4.4 Opration de radio logicielle sur GPU : approche classique
Algorithm 2 Opration damplication sur le GPU
procedure execute Code hte
Copier N chantillons vers le GPU
Dnir les arguments in, out, amp
Excuter amplification_kernel(in, out, amp) sur les N chantillons
Copier les N chantillons rsultats depuis le GPU
end procedure
procedure amplification_kernel(input, output, amp) Code GPU
id id du thread
output[id] = input[id] * amp ;
end procedure
4.2.2 Oprations complexes : premire approche
On appelle oprations complexes les oprations pour lesquelles le traitement chantillon par
chantillon ne fonctionne pas. Ces oprations seectuent donc sur des vecteurs dchantillons.
Un bon exemple dopration complexe est la FFT qui est utilise entre autres pour la modulation
OFDM. Une FFT prend en entre un vecteur et renvoie un vecteur de mme taille. La FFT se
calcule selon la fonction suivante, avec X le vecteur de sortie, x le vecteur dentre, et N la taille
du vecteur :
X
k
=
N1
n=0
x
n
e
2jk
n
N
, k = 0 . . . N 1
Pour eectuer ecacement une opration complexe sur le GPU, il convient de chercher une
implantation SIMD. Si on reprend lexemple de la FFT, en utilisant lalgorithme radix-2, on ob-
tient une implantation ecace sur GPU [bea]. Le kernel est alors relativement simple, puisquil
implante un papillon de FFT entre deux lments. On lance le kernel log
2
(N) fois, sur
N
2
lments.
Lapproche utilise ici ressemble donc celle utilise pour les oprations basiques, mme si
lunit de base nest plus rellement les chantillons. Cependant, cette approche prsente deux
inconvnients majeurs. Tout dabord, daprs [bea] et nos propres exprimentations, on nobserve
un gain en temps de calcul pour le GPU par rapport au CPU que pour N trs grand (N > 2
18
daprs [bea], N > 2
15
daprs nos exprimentations). Il est trs peu probable davoir besoin dune
telle taille de vecteurs dans une application radio, ce qui rend lutilisation du GPU avec une telle
approche inutile.
Lorsque lopration est ralise sur un "petit" vecteur, le CPU est ecace et le GPU napporte
donc pas de gain. Lutilisation de lenvironnement gnre un surcot, et les curs de calcul du
GPU sont moins ecaces que le CPU. Ceci explique en partie la grande taille de vecteur nces-
saire. De plus, le cot de transfert des donnes vers le GPU impose quil y ait un vrai gain sur le
40
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
CHAPITRE 4. INTGRATION GPU 4.2. UTILISATION OPTIMISE
calcul proprement dit. La bande passante entre le CPU et le GPU tourne autour de 8 Go/s thorique
(GPU connect sur un bus PCI-Express) sans cache. Les transferts seectuent en parallle du cal-
cul sur le CPU, alors quils doivent tre squentialiss sur le GPU.
4.2.3 Proposition : maximisation de lutilisation
Les applications radio ont une particularit qui nest pas exploite dans les implantations
actuelles sur GPU : elles traitent des donnes en permanence. Si on utilise le GPU pour une
application de calcul scientique comme par exemple MatLab, on ne sait pas par avance combien
on aura dchantillons traiter. Loptimisation se fait donc sur une opration unique : on cherche
coller du mieux possible au modle SIMD, et minimiser le nombre doprations. Cependant,
dans une application radio, on connat le nombre dchantillons : cest une application de stream-
ing (ux), ce qui implique quil y a virtuellement un nombre inni dchantillons traiter. Tant
que le rseau est actif, il y a des donnes.
Cette proprit peut tre utilise pour adapter la stratgie prcdente de deux manires dif-
frentes.
4.2.3.1 Paralllisation grain n
La premire mthode permettant de maximiser lutilisation du GPU est une extension de la
mthode prcdente. La maximisation de lutilisation sobtient en lanant plusieurs oprations
ensemble, augmentant ainsi le nombre de threads excuter. Ces threads permettent toujours
deectuer une sous-partie de lopration, mais plusieurs oprations sont lances en mme temps.
On joue ici sur lordonnancement. Au lieu dexcuter les donnes une par une, ou quand elles
sont disponibles, on force une tche attendre jusqu ce quun certain nombre dchantillons
soit disponible. On prsente le code correspondant pour le CPU dans lalgorithme 3. it
max
est la
dernire itration pour lalgorithme de FFT utilis. Les vecteurs sont de taille N.
Algorithm 3 Paralllisation grain n
Calculer it
max
Calculer T
opt
Attendre les T
opt
vecteurs
Copier N T
opt
chantillons vers le GPU
while it < it
max
do
Dnir les arguments in, out, it
Excuter fft_r2_kernel(in, out, it) sur les T
opt
vecteurs
it it 2
end while
Copier les N T
opt
chantillons rsultats depuis le GPU
end procedure
procedure fft_r2_kernel(input, output, itration) Code GPU
papillon_radix2(input, output, itration)
end procedure
Tout rside donc dans le calcul de T
opt
, qui reprsente le seuil dexcution, cest--dire le
nombre doprations lances en parallle, et donc le nombre de vecteurs qui seront traits par une
excution. On prcise ce paramtre dans la section 4.3. Cette mthode est une extension de la
mthode classique.
41
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
4.2. UTILISATION OPTIMISE CHAPITRE 4. INTGRATION GPU
4.2.3.2 Paralllisation gros grain
Dans cette tude, nous proposons une nouvelle mthode qui modie lunit de base pour le
calcul. Un thread traite intgralement une opration, et non plus une sous-partie. Llment de
base trait par un kernel OpenCL nest donc plus lchantillon, ou une sous-partie de vecteur,
cest la trame complte de lapplication radio. Ceci est reprsent sur la gure 4.5, et dcrit par
lalgorithme 4
Figure 4.5 Opration de radio logicielle sur GPU : approche propose
Algorithm 4 Paralllisation gros grain
Calculer T
opt
Attendre les T
opt
vecteurs
Copier T
opt
vecteurs vers le GPU
Dnir les arguments in, out
Excuter fft_kernel(in, out) sur les T
opt
vecteurs
Copier les T
opt
vecteurs rsultats depuis le GPU
end procedure
procedure fft_kernel(input, output) Code GPU
output fft(input)
end procedure
Les deux mthodes de maximisation de lutilisation ont le mme objectif et utilisent toutes les
deux un calcul fait sur plusieurs vecteurs en mme temps. Cependant, mme si elles permettent
toutes les deux un gain consquent par rapport au CPU, mme pour des vecteurs de petite taille,
les avantages et inconvnients ne sont pas les mmes.
4.2.3.3 Comparaison
La premire mthode est plus complique dployer, et utilise de petits noyaux. Il est en eet
ncessaire de trouver un algorithme qui se prte une dcomposition, avec des petits lments
indpendants. Ceci nest pas toujours possible, comme par exemple pour un ltre IIR. Lutilisation
des petits noyaux est ncessaire pour bien utiliser le GPU sur des calculs uniques an de pouvoir
utiliser tous les curs de calcul. Cependant, elle pnalise les performances, en augmentant le
42
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
CHAPITRE 4. INTGRATION GPU 4.3. ORDONNANCEMENT
surcot li au contrle des threads. De plus, si on reprend la FFT comme exemple, le calcul se
fait en plusieurs itrations, lhte est donc beaucoup sollicit. Par contre, cette mthode est plus
modulaire, comme on le verra dans la section sur lordonnancement, et permet donc une rduction
de la mmoire ncessaire. On peut galement sattendre ce quelle soit plus ecace pour des
seuils plus petits.
La mthode gros grains est plus simple dployer. Comme le kernel reprsente lopration
complte, il nest pas ncessaire de trouver une implantation adapte. De mme, il est possible
dutiliser cette mthode pour des oprations ne permettant pas une adaptation au modle SIMD,
comme pour le ltre IIR. Tant que ces oprations sont appliques sur les blocs, sans transfert de
donnes dun bloc lautre (IIR par bloc indpendant), il est possible dutiliser le GPU ecace-
ment, ce qui nest pas le cas avec lautre mthode. Les noyaux sont galement plus gros, ce qui
limite le surcot de contrle et permet de soulager lhte. Cependant, le besoin en mmoire est
important, et la mthode est trs peu modulaire, comme le montrent les exprimentations et la
section sur lordonnancement. Elle requiert galement des seuils levs (pour tre ecace, il faut
lancer au minimum un calcul par PE).
4.3 Ordonnancement
Les deux mthodes proposes sont toutes les deux bases sur un seuil, qui permet de dnir
combien de vecteurs vont tre traits par le GPU en mme temps. Ce seuil inue sur dirents
paramtres.
4.3.1 Ecacit
Le premier paramtre est lecacit de lopration. On parle ici decacit en termes de per-
formances brutes. An de relativiser leet du surcot de contrle du GPU, il faut utiliser le GPU
au maximum. Logiquement, augmenter le seuil permettrait donc damliorer les performances du
GPU. Cependant, il faut nuancer cette armation. An dtudier linuence du facteur T
opt
sur
la performance globale du systme, nous avons mis en place un test sur la FFT pour les deux
approches prcdentes. Il sagit de calculer un nombre donn de FFT en faisant varier T
opt
, et de
regarder le temps ncessaire. Pour des raisons doccupation mmoire, T
opt
reste infrieur 1024.
Le GPU utilis pour le test est constitu de 4 devices, chacun utilisant 32 PE, ce qui donne 128
PE. La valeur optimale de T
opt
est dpendante du GPU. Les tests suivants sont raliss en utilisant
le GPU entier.
La gure 4.6 prsente les rsultats de ce test. On a donc le dbit de traitement en million
dchantillons par seconde en fonction du seuil utilis. Ce dbit prend en compte le transfert des
donnes vers le GPU. La courbe sans les transferts est similaire, mme si les valeurs sont plus
petites (facteur 10). Dans les deux cas, on distingue une forte augmentation du dbit au dbut, puis
une augmentation moins marque avant une certaine stagnation. Il ne sert donc rien daugmenter
indniment le seuil. Lexistence dun seuil optimal est clairement visible sur ces rsultats, do
le nom T
opt
.
Le seuil optimal de lapproche grain n, visible sur la gure 4.6(a), est plus faible que celui
de lapproche gros grain, sur la gure 4.6(b). Cependant, lapproche gros grain permet davoir
un temps dexcution plus court.
4.3.2 Latence
Le seuil inuence aussi la latence. Lutilisation des approches proposes gnre une plus
forte latence que dans le cas dune excution "normale", du fait de laccumulation des vecteurs
avant lexcution. Cette latence peut se rvler problmatique dans certains cas. Par exemple, en
43
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
4.3. ORDONNANCEMENT CHAPITRE 4. INTGRATION GPU
0
20
40
60
80
100
200 400 600 800 1000
D
e
b
i
t

e
c
h
a
n
t
i
l
l
o
n

(
M
S
p
s
)
t
opt
FFT 128
(a) Approche grain n
0
20
40
60
80
100
200 400 600 800 1000
D
e
b
i
t

e
c
h
a
n
t
i
l
l
o
n

(
M
S
p
s
)
t
opt
FFT 128
(b) Approche gros grain
Figure 4.6 Dbit chantillons en MS/s pour des FFT de 128 points pour dirents seuils
prsence dun protocole de retransmission des paquets errons, il faut connatre rapidement le
rsultat de la rception an de pouvoir faire la demande de retransmission (ou transmettre lac-
quittement lmetteur). Il y a donc une contrainte temporelle sur le dcodage de la transmission.
Une latence trop importante pour le traitement de certains chantillons peut gnrer une pertur-
bation de la transmission. loppos, la latence ne pose pas rellement de problmes pour une
application de streaming vido par exemple, tant que le dbit est support.
Il est assez ais de calculer la latence induite par lutilisation du seuil dans le cadre dune
application radio. Elle dpend en eet de la frquence dchantillonnage et du seuil. Si on doit
attendre davoir T
opt
vecteurs de taille N pour lancer un calcul, et que les chantillons arrivent
avec une frquence f
s
, on obtient la formule suivante pour la latence L.
L =
T
opt
N
f
s
La latence L ainsi obtenue est le temps ncessaire pour obtenir le nombre de paquets requis. Pour
obtenir la latence globale du systme, il faut ajouter le temps requis par chaque opration.
Notons tout de mme quaugmenter la frquence dchantillonnage pour diminuer la latence
ne fonctionne pas. f
s
reprsente bien ici la frquence des chantillons traiter en entre de la
chane. Cette chane est dimensionne pour prendre en compte la frquence dchantillonnage,
donc si on augmente la frquence dchantillonnage, N augmentera galement. De mme, si on
dcide de travailler sur des vecteurs plus petits, pour que le temps de calcul ne devienne pas
prpondrant, il faudra augmenter T
opt
, ce nest donc pas non plus une solution viable.
An de limiter limpact des deux approches sur la latence, on dtaille deux solutions possibles.
Ces deux solutions prsupposent une connaissance de la structure de la transmission. Le principe
de base est de tabler sur la rpartition en paquets, et sur la structure du calcul GPU, qui permet de
calculer en parallle les paquets. Ainsi la multiplication du nombre de paquets calculer naug-
mentent pas le temps dune instance du calcul. An de diminuer la latence, il peut tre ncessaire
de diminuer le seuil, ce qui diminuerait lecacit.
La premire solution utilise une connaissance des chantillons prioritaires. Ainsi, si on sait
que durant la rception, il y a un paquet prioritaire intervalle rgulier comme un beacon par
exemple, il est envisageable de xer le moment du calcul en fonction de cet intervalle. Si le reste
de la transmission est non prioritaire, il est envisageable de tout accumuler dans des les, en at-
tendant que les lments prioritaires arrivent dans cette le. Larrive de ces lments dclenchent
automatiquement le calcul, an de garantir une latence minimale pour ceux-ci.
La seconde solution utilise la sparation en paquets de la transmission. Ainsi, si on connait le
temps de transmission dun paquet, on peut caler T
opt
sur le nombre dchantillons correspondants.
44
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
CHAPITRE 4. INTGRATION GPU 4.4. INTGRATION DISTRIBUE
Ainsi, les donnes qui une fois traites auraient dues tre mises en attente en attendant la n du
paquet sont toutes traites en mme temps, ce qui garantit une latence minimale pour le paquet.
Dans le cas o la transmission nest pas structure, par exemple dans les priodes dattente de
paquet (corrlation/synchronisation), il ny a pas de solution lgante. Il convient de dnir une
latence acceptable pour nimporte quel chantillon, et de calculer T
opt
en consquence, partir du
dbit dchantillon en entre du rcepteur.
4.3.3 Mmoire
Finalement, il y a un lien entre T
opt
et lespace mmoire requis par lapplication. Ainsi, plus
on augmente le seuil, plus la mmoire ncessaire pour excuter les direntes oprations sera im-
portante. Il faut ds lors adapter T
opt
aux caractristiques du systme. La mmoire nest cependant
prdominante dans le choix de T
opt
que dans certains cas bien particuliers comme le streaming ou
lembarqu, la latence acceptable tant gnralement plus limitante.
4.4 Intgration distribue
Deux implantations de lordonnanceur ont t envisages, lune distribue et lautre centrali-
se. Limplantation distribue a t mise en place dans lenvironnement de radio logicielle GNU-
Radio, son fonctionnement se prtant bien ce type dimplantation. Limplantation centralise,
plus complexe mettre en place, mais plus prometteuse, est galement dtaille. Elle a galement
t mise en place dans GNURadio, mme si une intgration complte de cette mthode est dicile
dans cet environnement. Les approches proposes de rduction de latence nont pas t implan-
tes, lenvironnement GNURadio ntant pas adapt. Lintgration centralise est prsente dans
la section suivante (4.5).
4.4.1 Prsentation
Limplantation distribue utilise une approche "opration par opration", similaire celle uti-
lise dans GNURadio. Cest limplantation la plus simple mettre en uvre.
Lenvironnement OpenCL est instanci et gr dans une classe spcique, qui contient les
dirents contextes, et qui permet de mettre en place les direntes queues de commande requises.
Chaque opration qui doit tre implante ncessite un bloc GNURadio pour linterface avec le
reste de lapplication et un kernel correspondant lapplication.
Lordonnanceur est implant de manire distribue, dans chacun des blocs GNURadio. Cest
une implantation pseudo-statique. Il est possible de faire voluer lordonnancement dans le temps,
mais de manire simpliste, cause de labsence dinformation sur le reste de lapplication. Le
paramtre T
opt
est dni dans le bloc lors de son instanciation.
Cette implantation permet de mlanger dirents modes dexcution entre GPU et CPU. Elle
peut utiliser indiremment les direntes mthodes de communication dnies prcdemment.
Dans la pratique, cette approche est assez simple mettre en uvre. Chacune des oprations
implanter prend la forme dun nouveau bloc GNURadio dans lAPI. Ce bloc a la mme interface
quun bloc classique, avec en plus comme attribut la classe spcique lOpenCL, qui contient
toutes les structures propres. Ces structures doivent pour la plupart tre uniques pour lapplication,
cette classe est donc instancie une seule fois. Lutilisateur qui veut utiliser des blocs GPU peut
utiliser tous les blocs dnis, de la mme manire quil utiliserait des blocs classiques.
4.4.2 Communications
Les applications SDRen gnral, et GNURadio en particulier, sont bases sur une communica-
tion entre blocs de type FIFO. Dans le cas dune implantation sur CPU, ces FIFO sont logicielles,
45
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
4.4. INTGRATION DISTRIBUE CHAPITRE 4. INTGRATION GPU
Figure 4.7 Implantation distribue
implantes en utilisant un buer tournant, et des indices. Dans cette tude, lutilisation du GPU
modie le problme. Il devient ncessaire de faire transiter les donnes entre les deux domaines,
et la mthode utilise est dirente. Les performances sont galement prendre en compte, les
transferts de donnes vers et depuis le CPU tant un goulot dtranglement de lutilisation du
GPU. Deux approches pour eectuer ces transferts sont tudies.
4.4.2.1 Intgration transparente
La premire solution est la plus vidente. Elle est utilise dans [Mil10]. Elle permet de rendre
lutilisation du bloc GPU transparente pour le reste du systme, en grant le transfert dans le bloc.
Cest lapproche reprsente sur les gures 4.4 et 4.7. Lintgration du bloc dans le domaine CPU
est forte, les donnes transitant dans les FIFO logicielles du CPU.
Cette mthode permet dalterner des blocs CPU et GPU facilement tant donne que les don-
nes rsident dans le CPU. En laissant au bloc la responsabilit de grer sa mmoire GPU, elle
permet de diminuer lempreinte sur la mmoire du GPU, la mmoire tant alloue au plus proche
de ce qui est requis. Du point de vue du dveloppeur, lapproche est aise implanter, puisquelle
ne ncessite pas de modications de la structure de GNURadio. Du point de vue de lutilisateur,
les blocs sont interchangeables et il est donc possible dutiliser lun ou lautre domaine indirem-
ment
2
.
Cependant, cest galement lintgration qui est potentiellement la moins ecace. Utiliser
des alternances de GPU et de CPU pour bncier des implantations les plus ecaces nest pas
forcment optimal. Les cots de transfert dun domaine lautre sont tels, compars aux cots de
lexcution, quil peut tre prfrable de nutiliser quun seul domaine. Linconvnient majeur dans
cette approche est que mme si deux oprations successives ont lieu sur le GPU, les donnes vont
devoir repasser par le CPU entre ces deux oprations. La perte de performance est dicilement
acceptable.
4.4.2.2 Buer OpenCL
An dviter cette perte de performance, il faut dnir un nouveau type de buer, adapt
lutilisation du GPU.
La premire ide pour raliser un tel buer est dutiliser une fonctionnalit spcie dans lAPI
OpenCL : lutilisation dune zone dans la mmoire de lhte comme base pour un buer OpenCL.
Les donnes sont ensuite transfres selon les besoins dans la mmoire du GPU de manire trans-
parente pour lutilisateur. Cependant, cette solution ore des rsultats plus que dcevants, et fait
toujours transiter les donnes par le CPU. De plus, le runtime OpenCL est pour linstant une bote
noire, et il nest donc pas possible de savoir exactement comment cette fonctionnalit est gre.
Nos exprimentations montrent des variations importantes de lecacit de la mthode. Une autre
fonction dOpenCL, qui permet de mapper un buer GPU dans le plan dadressage mmoire du
CPU, a galement d tre abandonne, cause de rsultats alatoires.
2. du point de vue de la communication au moins. Linterface du bloc peut tre modie par des paramtres propres
limplantation OpenCL
46
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
CHAPITRE 4. INTGRATION GPU 4.5. INTGRATION CENTRALISE
On en revient donc la dnition complte dun buer OpenCL. Le GPU est une entit de
calcul et non de contrle. De plus, le CPU reste responsable du contrle de lapplication radio
complte, il a donc besoin dinformations sur ce quil se passe dans cette application, et les trans-
ferts entre GPU et CPU sont diciles. Limplantation du contrle dun buer tournant dans le
GPU est donc exclue.
Par contre, nous pouvons utiliser une conception qui utilise les deux domaines, avec le contrle
dans lhte (le CPU), et les donnes physiques dans le GPU. Des blocs de transferts explicites des
donnes entre les deux domaines sont proposs. Cette approche est prsente dans la gure 4.8.
Le contrle est reprsent en pointills, les donnes relles en trait plein.
Figure 4.8 Utilisation de buers spciques pour les GPU
On utilise en fait une FIFO "fantme" qui rside dans le CPU, et qui permet de reter ce quil
se passe dans le GPU. Cette FIFO de contrle est une FIFO dindices. Lors de linitialisation, la
FIFO est remplie avec ses indices, et la mmoire est alloue dans le GPU. Lors de lutilisation de
ces FIFO, le bloc GNURadio lit la FIFO de contrle et en dduit lindice correspondant dans la
FIFO OpenCL. Cet indice est transmis en tant que paramtre du kernel. Une fois le calcul eectu,
le bloc retourne le nombre de valeurs produites, ce qui dans GNURadio permet de maintenir les
FIFO jour. Il ny a par contre aucune donnes rellement crites dans la mmoire de lhte. Les
blocs de transferts permettent de faire linterface entre ces deux types de FIFO. Les donnes sont
rellement lues en entre, puis transfres vers le GPU. En sortie, la FIFO de contrle est mise
jour en consquence. Les oprations inverses sont eectues dans lautre sens du transfert.
Cette approche a un inconvnient majeur : elle consomme de la ressource mmoire "inutile",
puisque ne contenant pas rellement de donnes. De manire gnrale, limplantation de FIFO
consomme galement plus de mmoire que limplantation de simple buers temporaires comme
pour lapproche prcdente. Cependant, elle permet dviter les transferts inutiles, tout en con-
servant une vision de ltat des FIFO pour lordonnanceur de GNURadio. Les performances sont
donc amliores.
4.5 Intgration centralise
4.5.1 Prsentation
Limplantation centralise est plus proche de larchitecture OpenCL. Le contrle du GPU tant
centralis sur lhte, il parat prfrable dutiliser une implantation centralise pour intgrer le
GPU dans GNURadio.
Le principe de cette approche est de regrouper dans un seul et mme bloc GNURadio toute
une squence doprations ralises sur GPU. Ce bloc est responsable dordonnancer les kernels
et de grer les communications entre les direntes oprations, comme prsent sur la gure 4.9.
Cette approche a trois grands avantages :
elle limite le besoin en mmoire. Puisquun seul bloc gre toute une squence doprations
GPU, il nest plus forcment ncessaire davoir des FIFO entre ces oprations. Les seules
FIFO seront en entre et en sortie de ce bloc. On nutilisera donc que la mmoire requise en
fonction du T
opt
maximal ;
47
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
4.5. INTGRATION CENTRALISE CHAPITRE 4. INTGRATION GPU
Figure 4.9 Implantation centralise
elle permet damliorer encore lutilisation du GPU. La plupart des GPU rcents sont bass
sur des units indpendants (les multiprocessors de NVidia en sont lexemple type). Pour
atteindre lutilisation maximale, on a remarqu dans la section 4.3.1 que T
opt
pouvait tre
trs grand. Centraliser le contrle peut permettre de lancer en parallle direntes tches,
qui seront donc excutes de manire concurrente. Le GPU peut donc potentiellement tre
utilis correctement mme avec un seuil plus petit. Cet avantage nest pertinent que pour
les GPU rcents, qui permettent lutilisation compltement indpendante des units (cf. le
compute capability de NVidia, [NVI10]) ;
plus gnralement, elle permet dutiliser des ordonnancements plus souples, puisquil y a
une connaissance de ltat de toutes les oprations dans le bloc quil ny avait pas avec
lapproche distribue.
Cette approche est cependant moins transparente pour lutilisateur que lapproche distribue,
tant donn quelle se distingue de lapproche GNURadio. En ltat actuel de limplantation, lu-
tilisateur doit spcier quelles oprations seront eectues dans le bloc GNURadio. Il est envis-
ageable dautomatiser cette rpartition. Cette approche na galement dintrt que si beaucoup
doprations sont ralises en squence. Cependant, cette limitation est un faux problme, puisque
le cot dun transfert mmoire limite les passages dun domaine lautre.
4.5.2 Communications
Les communications de lintgration centralise sont assures par des FIFO logicielles clas-
siques de GNURadio en entre et en sortie du bloc complet, et par des buers entre les direntes
oprations GPU. La taille des blocs peut tre calcule au plus juste. On connait en eet le ratio
entres/sorties, et le seuil de calcul qui sera utilis, cest--dire le nombre dlments qui seront
traits par une occurrence de lopration.
Lapproche centralise permet donc de supprimer le problme des communications, mme si
le calcul des tailles nest pas forcment vident.
4.5.3 En pratique
Dans la pratique, limplantation centralise consiste en une ralisation dun bloc GNURadio
qui ralisera plusieurs oprations, et qui sintgrera normalement dans une application. Ce bloc sert
dinterface avec le GPU. Il contient ses direntes structures, et une reprsentation de lapplication
GPU, cest dire de lensemble des oprations qui seront eectues, ainsi que des connexions
entre ces oprations. La fonction qui sera excute lors de lappel de ce bloc dans lapplication
sera en fait lordonnanceur, qui va lire les donnes en entre, soccuper du transfert vers le GPU,
puis excuter son application interne, avant de transfrer nouveau le rsultat vers le CPU pour
lcrire en sortie.
Implanter lapproche centralise revient ajouter la possibilit de crer un bloc partir
doprations GPU. Les mcanismes utiliss ressemblent fortement aux mcanismes qui perme-
ttent de crer une application dans GNURadio. Une opration GPU est reprsente laide des
48
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
CHAPITRE 4. INTGRATION GPU 4.6. RSULTATS
paramtres suivants :
un kernel qui reprsente lopration eectuer par le GPU;
une fonction pour dnir les arguments de lopration et pour lancer une excution du ker-
nel ;
un ratio entres/sorties qui dnit le rapport entre le nombre dentres et le nombre de
sorties ;
un seuil optimal T
opt
.
Dans la gestion centralise, on calcule dans la phase dinitialisation un ordonnancement, avec
les tailles de buers requises entre les direntes oprations GPU, et le nombre dexcution. Cet
ordonnancement est ensuite utilis durant lexcution pour lancer les noyaux. On propose un al-
gorithme permettant dinitialiser lordonnancement. Lobjectif de lordonnanceur est de dnir :
le seuil pour chacune des oprations considres ;
la taille des buers entre les blocs ;
la squence de kernels excuter.
Dans la premire version prsente dans lalgorithme tout le GPU est utilis pour raliser une
opration. En prsence dun GPU compatible avec le multitche, il est possible dappliquer une
autre modication, qui permet potentiellement de rduire lempreinte mmoire et la latence sans
diminuer le dbit. Si le GPU est constitu de units indpendants, on peut lancer plusieurs opra-
tions en parallle sur le GPU. Cette approche a plusieurs avantages. Les units tant plus petits, ils
ont besoin dun seuil moins lev pour tre utilis de manire optimale. Le temps dexcution est
videmment plus long, mais comme les tches sont excutes en parallle, on peut esprer garder
le mme dbit, mais en diminuant la latence et la mmoire requise.
4.6 Rsultats
4.6.1 Synthse des contributions
Avant dexaminer le rsultat des direntes mthodes proposes, rsumons lensemble des
propositions. Lobjectif principal est dtudier les possibilits dutilisation du GPU pour la radio
logicielle. On sintresse pour linstant une excution sans limitation de consommation lec-
trique, et sur des plateformes qui peuvent tre puissantes. Concrtement, on naborde pas dans nos
exprimentations le cas des systmes embarqus.
Les propositions de cette tude tournent autour de trois axes :
une conception dune opration SDR sur GPU. Ltude dans [Mil10] proposait une solution
pour des oprations basiques. Nous nous intressons dans cette tude des oprations plus
complexes, et nous proposons une approche qui utilise lopration complte comme kernel,
au lieu de dnir un algorithme optimis pour le GPU;
la dnition de lordonnancement des blocs GPU, qui dire de celui des blocs CPU cause
du besoin de charger au maximum le GPU. Cet ordonnancement se base sur un seuil, et peut
tre utilis pour toutes les approches ;
deux stratgies dintgration de ces blocs dans une application, cest--dire de la communi-
cation entre les lments, et de limplantation de lordonnancement dans un environnement
rel, en loccurrence GNURadio.
Les exprimentations visent valuer la dirence de performance entre une implantation
CPU, et les direntes approches proposes dans ce travail ou dans dautres.
4.6.2 Oprations implantes
An dtudier les rsultats des direntes solutions proposes, trois oprations direntes ont
t slectionnes et implantes. On prsente ici les dtails de limplantation.
49
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
4.6. RSULTATS CHAPITRE 4. INTGRATION GPU
4.6.2.1 FFT
La transforme de Fourier rapide est une opration classique de traitement du signal permettant
de passer du domaine frquentiel au domaine temporel et inversement. La formule a t donne
prcdemment. An dimplanter de manire ecace la FFT, on utilise ltude [bea] qui sintresse
aux implantations optimales de la FFT sur GPU. Lalgorithme utilis est un algorithme base de
papillons radix-2, prsent dans lalgorithme 5 pour une FFT de N points.
Algorithm 5 Algorithme FFT Radix-2
input vector Contient lentre de litration courante
it
max
log
2
(N)
for it [0, it
max
[ do
for i [0,
N
2
[ do
butterfly(i, i +
N
2
, i it, (i + 1) it)
end for
end for
Limplantation de lopration FFT sert dexemple dans les sections prcdentes, on ne revient
donc pas dessus. La premire approche utilise comme kernel la fonction butterfly, qui est un
papillon de FFT. Au contraire, lapproche gros grain utilise toute la fonction prsente dans lal-
gorithme comme kernel. Lintrt de la FFT dans cette tude rside dans lexistence dalgorithmes
optimiss pour le GPU.
4.6.2.2 Demapping
Le demapping est une fonction simple qui permet de traduire les chantillons du domaine com-
plexe en information binaire. On sintresse ici une modulation PSK, qui utilise une variation
de phase pour coder linformation. Plus prcisment, dans les exprimentations eectues, la con-
stellation est une constellation QPSK avec les phases

4
,
3
4
,
4
et
3
4
. La constellation est assez
simple dcoder, puisquil sut de regarder dans quel cadran se trouve lchantillon en cours de
traitement, alors quune constellation plus complexe requiert plusieurs calculs de distance. Lalgo-
rithme 6 est utilis, dans lequel I et Q reprsente les parties relles et imaginaires de lchantillon
complexe (reprsentation classique en traitement du signal).
Algorithm 6 Demapping dune constellation PSK
if I > 0 et Q > 0 then

4
else if I < 0 et Q > 0 then

3
4
else if I < 0 et Q < 0 then

3
4
else if I > 0 et Q < 0 then

4
end if
traduire()
Dans lapproche grain n, on dnit la taille du kernel en fonction de llment de sortie.
Dans le cas dun QPSK, un chantillon code 2 bits. Le kernel traitera donc 4 chantillons, an
davoir un nombre de bits entier en sortie. Dans le deuxime cas, le kernel traite tout un bloc. Par
exemple, si une trame est transforme laide dune FFT (modulation OFDM), le kernel travaillera
sur tout le rsultat de la FFT.
50
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
4.6.2.3 IIR
Finalement, nous nous intressons limplantation dun ltre IIR, opration pour laquelle
lextraction dun algorithme SIMD est plus complique. On peut citer comme tude [Kut08] qui
se base sur une extraction des parties rcursives et non rcursives. Cette approche sapplique bien
dans le cas dun processeur SIMD pas trop large, mais beaucoup plus dicilement dans le cas
dun processeur SIMD trs large comme le GPU. On propose donc ici une nouvelle approche qui
utilise la paralllisation gros grain, base sur des modications similaires, mais adaptes pour le
GPU.
Le ltre IIR est un ltre linaire :
IIR(n) =
F
i=0
b
i
x(n i)
B
j=1
a
j
IIR(n j)
Si on sintresse un calcul de ce ltre sur des blocs, sans rpercussion du rsultat du bloc
prcdent sur le premier lment dun bloc (il y a indpendance complte entre les blocs), on
obtient une implantation paralllisable sur GPU en utilisant lapproche gros grain. Le kernel est
alors le calcul complet dun IIR bloc. La formule de ce ltre est :
IIR
t
(n) =
F
i=0
b
i
x(tN + n i)
min(n,B)
j=1
a
j
IIR
t
(n j), n {0 . . . N 1}
En utilisant une correction des coecients, on peut calculer le ltre complet. La correction
permet de corriger lensemble des lments dun bloc t, en utilisant les lments corrigs du bloc
t 1, et des coecients constants c
j
:
_
_
IIR(tN + n) = IIR
t
(n)
B
j=1
c
j
(n)IIR(tN j)
c
j
(0) = a
j
c
j
(n) = a
j+n

n
k=1
a
k
c
j
(n k)
n {0 . . . N 1}, t N
La dmonstration de la correction de cette formule se fait par rcurrence. Elle est prsente
dans lannexe B. Dans cette formule, le calcul de chaque lment n du bloc est indpendant des
autres lments. On peut donc appliquer bloc par bloc un modle SIMD.
On en dduit lalgorithme 7 pour le calcul dun ltre IIR en utilisant le GPU. La procdure
iir_block permet de calculer une IIR
t
pour un bloc donn. Ce calcul est facilement paralllisable
sur un GPU, puisquil ny a pas de dpendances entre les dirents lments dun bloc. Une fois
que plusieurs blocs ont t calculs, on peut appliquer la correction. Le calcul de lIIR corrig
ne dpend que des IIR
t
, obtenus lors de la phase prcdente, on peut donc utiliser un algorithme
SIMD. Cest la fonction correction qui est utilise dans ce cas.
On notera que lutilisation de cette approche cote cher linitialisation (O(N B
2
) multipli-
cations/accumulations). Il y a galement un surcot durant lexcution, de B multiplications/accu-
mulations par lments. Ce surcot est similaire lapproche de [Kut08]. Lalgorithme ncessite
galement N B emplacements mmoires an denregistrer les coecients c
j
. En le comparant
lalgorithme de [Kut08], la mthode est similaire. Cependant, certaines dirences existent qui
permettent de rendre notre approche plus ecace et plus adapte la radio logicielle :
nous utilisons une approche en bloc et non pas une approche en ux, ce qui permet de
maximiser lutilisation du GPU, et dtre plus ecace ;
la taille de bloc utilise est suprieure N, qui est le cas problmatique de lapproche dans
[Kut08].
51
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
Algorithm 7 Implantation dun ltre IIR
procedure iir_bloc(B, F, N)
for n [0, N[ do
IIRt[i] 0
for i [n F, n] do boucle sur lentre
IIRt[n]IIRt[n]+a[i]x[i]
end for
for j [1,min(n,B)] do boucle rcursion
IIRt[n]IIRt[n]b[ j]IIRt[n j]
end for
end for
end procedure
procedure correction(c, B, N)
for n [0, N[ do
for j [1, B] do
IIR[n] IIRt[n] - c[ j][n] IIRt[n j]
end for
end for
end procedure
Utiliser le corps de la boucle comme kernel nest pas envisageable cause de la dpendance
des donnes. Lapproche grain n nest donc pas adapte. On pourrait concevoir une solution
qui mlangerait les deux approches, avec un ordonnancement qui se baserait sur lapproche gros
grain, mais suite nos exprimentations, le GPU narrive pas extraire lindpendance, et excute
tous les noyaux un par un. On ntudiera donc pas cette solution. De mme, comme attendu, nos
essais sur dautres implmentations indpendantes de lIIR nont pas t concluant. Lapproche
grain n ne peut donc pas implanter ecacement lIIR.
La nouvelle approche gros grain que nous avons introduite permet en revanche de dnir
un nouvel algorithme pour lIIR, qui exploite ecacement le GPU. En eet, le calcul de lIIR
bloc par bloc est compatible avec larchitecture SIMD du GPU, puisque le calcul sur un bloc ne
dpend pas du calcul sur le bloc prcdent. Lopration de correction la n, si on a besoin de la
dpendance dun bloc lautre, est galement paralllisable (bloc par bloc). Cette approche permet
donc dimplanter des oprations qui ne seraient pas implantables autrement.
4.6.3 Protocole dexprimentation
An de tester les direntes solutions proposes pour permettre lutilisation du GPU dans la
radio logicielle, on utilise des donnes gnres alatoirement dans un chier, et on applique les
calculs qui nous intressent. Le rsultat est ensuite crit dans un chier, puis compar au rsultat
dune excution CPU avec un GNURadio non modi (et donc suppos exact). Le protocole est
reprsent sur la gure 4.10. On calcule le temps requis pour eectuer cette opration (hors ini-
tialisation). Ce temps est ensuite utilis pour calculer le dbit chantillon de lapplication, cest
dire le nombre dchantillons traits par seconde.
Le matriel utilis pour lexcution est un ordinateur de bureau bas sur
un CPU Intel Core i5 760 (Quad Core, 2.80 GHz, 2Mo de cache) ;
8 Go de mmoire DDR3 ;
une carte graphique ASUS connecte sur le bus PCI-Express 16x (8 Go/s) base sur :
un GPUNVidia GTS 450 de 4 multiprocessors de 32 cores chacun, cadencs 1566 MHz,
soit un total de 128 cores ;
52
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
Lecture
Fichier
Ecriture
Fichier
Elements testes
CPU
GPU
Figure 4.10 Protocole dexprimentation
1 Go de mmoire DDR5, avec une bande passante de 60 Go/s en interne.
Les oprations sont excutes sur le GPU lui-mme. NVidia fournit, dans ses pilotes propri-
taires, lensemble de lenvironnement OpenCL, ainsi que le compilateur des kernels. Les opra-
tions sont donc implantes en utilisant la spcication normalise dOpenCL, puis en faisant ldi-
tion de lien avec la librairie OpenCL fournit par NVidia, qui donne limplantation des direntes
fonctions de la spcication. Il y a donc beaucoup dlments inaccessibles dans limplantation.
Les conclusions que lon tires des rsultats suivants sont vraies pour le GPU utilis. Pour des
raisons de moyens, il na pas t possible denvisager dautres GPU, on peut cependant faire
quelques suppositions qui seront prsentes au fur et mesure.
4.6.4 Rsultats des oprations unitaires
Ltude des oprations unitaires permet davoir une premire vision de lecacit des dif-
frentes mthodes considres. On tudie ici les dbits dchantillons pour 10 000 oprations.
Deux facteurs entrent en jeu pour tudier les performances : le seuil minimal pour lancer lexcu-
tion, et la taille du vecteur. Ces deux paramtres permettent en eet de dnir quel point le GPU
est utilis.
4.6.4.1 Inuence du seuil
Ltude de linuence du seuil permet de dterminer un seuil optimal utiliser pour chacune
des oprations et pour chacune des tailles de vecteur, an de permettre une excution optimale.
La gure 4.11 montre le dbit chantillon lors dune excution de 10 000 FFT pour direntes
valeurs du seuil de dclenchement. On tudie trois implantations : une implantation classique sur
CPU, une implantation grain n et une implantation gros grain. On peut remarquer deux choses
sur les courbes :
limplantation grain n donne de meilleurs rsultats que limplantation gros grain pour
des petites valeurs de seuil ;
limplantation gros grain est plus stable dans ses performances que limplantation grain
n, et permet datteindre un dbit minimal plus grand.
Limplantation grain n nest clairement pas adapte ce type dapplications. Le point de
stabilisation que lon remarque sur la courbe pour N = 1024 correspond une valeur de seuil
de 512. Le GPU utilis pour les tests utilise 128 curs, ce seuil correspond donc 4 fois le
nombre de curs. Cest le nombre minimal requis pour obtenir un ordonnancement optimal de
manire dterministe, tant donne la taille du kernel. On peut supposer que plus le nombre de
cores augmente, plus le seuil augmentera, ce qui aura donc pour eet daugmenter la latence. A
loppos, moins on a de cores, et plus le seuil diminue. Ceci signie quun GPU avec peu de PE
sera probablement utilis de manire optimal avec un nombre de vecteurs faible. Cependant, les
dbits atteignables seront probablement plus faibles aussi.
53
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
On constate galement que limplantation grain n est plus ecace pour N = 1024 que pour
N = 128. Ceci tait attendu, du fait de ltude de performance ralise en [bea].
0
20
40
60
80
100
200 400 600 800 1000
D
e
b
i
t

e
c
h
a
n
t
i
l
l
o
n

(
M
S
p
s
)
t
opt
CPU
Gros Grain
Grain Fin
(a) FFT 128 points
0
20
40
60
80
100
200 400 600 800 1000
D
e
b
i
t

e
c
h
a
n
t
i
l
l
o
n

(
M
S
p
s
)
t
opt
CPU
Gros Grain
Grain Fin
(b) FFT 1024 points
Figure 4.11 Dbit chantillons en MS/s pour la FFT pour dirents seuils, taille de vecteur
xe
Le gain pour lopration de demapping est beaucoup plus perceptible, comme on peut le voir
sur la gure 4.12. Lapproche gros grain est galement meilleure que lapproche grain n en
termes de performance. Cependant, cette dernire permet ici daugmenter le dbit de traitement
par rapport au CPU, ce qui ntait pas le cas pour la FFT. Ceci sexplique par la simplicit du
calcul compar par exemple lopration FFT.
0
50
100
150
200
200 400 600 800 1000
D
e
b
i
t

e
c
h
a
n
t
i
l
l
o
n

(
M
S
p
s
)
t
opt
CPU
Gros Grain
Grain Fin
(a) demap 128 points
0
50
100
150
200
250
200 400 600 800 1000
D
e
b
i
t

e
c
h
a
n
t
i
l
l
o
n

(
M
S
p
s
)
t
opt
CPU
Gros Grain
Grain Fin
(b) demap 1024 points
Figure 4.12 Dbit chantillons en MS/s pour le demapping pour dirents seuils, taille de
vecteur xe
Pour lopration IIR, il ny a pas dimplantation grain n. On donne les rsultats avec la
correction pour la rcursion bloc bloc, et sans cette correction. Lutilisation de la correction im-
pose un bloc de grande taille galement. Dans la deuxime phase, le kernel sapplique en eet sur
un vecteur de la taille du bloc, et pour maximiser lutilisation, il faut donc avoir un bloc de taille
consquente. Ceci se remarque sur la gure 4.13. Le ltre IIR utilise ici F = 1 et B = 1 comme
paramtre. Pour N = 128, la version en bloc de lalgorithme, sans la correction, est ecace, com-
parable lexcution CPU. Au contraire, la version avec la correction est peu ecace compare
au CPU. Par contre, pour N = 1024, les courbes se rapprochent. Le GPU prend lavantage partir
de N = 8192, comme on le voit sur la gure 4.13(c). Il y a quivalence en termes de dbit pour
N = 4096.
Lopration IIR tant la base une opration linaire et non pas en bloc, on peut donc arbi-
trairement augmenter la taille du bloc N en diminuant le seuil pour obtenir de bonnes performances
54
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
sur GPU, sans augmenter la mmoire. Comme le seuil utiliser diminue quand N augmente (on
a quasiment N T
opt
constant), augmenter N ne change pas la taille requise. Ceci est vrai pour le
ltre corrig. La taille du bloc a son importance pour le ltre non corrig.
0
5
10
15
20
25
30
35
40
200 400 600 800 1000
D
e
b
i
t

e
c
h
a
n
t
i
l
l
o
n

(
M
S
p
s
)
t
opt
CPU
Gros Grain
Corrige
(a) IIR 128 points
0
20
40
60
80
100
200 400 600 800 1000
D
e
b
i
t

e
c
h
a
n
t
i
l
l
o
n

(
M
S
p
s
)
t
opt
CPU
Gros Grain
Corrige
(b) IIR 1024 points
0
20
40
60
80
100
200 400 600 800 1000
D
e
b
i
t

e
c
h
a
n
t
i
l
l
o
n

(
M
S
p
s
)
t
opt
CPU
Corrige
(c) IIR 8192 points
Figure 4.13 Dbit chantillons en MS/s pour lIIR pour dirents seuils, taille de vecteur xe
Plusieurs remarques sont faire sur ces rsultats. Tout dabord, le ltre IIR utilis est un ltre
avec une seule rcursion. Le calcul est donc trs simple pour le CPU. Laugmentation du nombre
de rcursions complexierait le calcul, et rendrait donc le GPU plus attractif.
On remarque galement le comportement trange de la courbe pour la version corrige. Deux
raisons expliquent cet aplatissement soudain de la courbe autour de la valeur du CPU. La pre-
mire raison est la taille limite de la FIFO dentre, qui empche datteindre le seuil optimal. Les
valeurs au del du seuil indiqu ne sont donc pas signicatives. On remarque cette limitation sur
les rsultats en fonction de la taille des vecteurs dans la section 4.6.4.2. La deuxime raison est une
erreur de la version du driver utilise au moment des exprimentations. Alors que dans les expri-
mentations prcdentes, le GPU russissait extraire le paralllisme du kernel de la correction,
la version actuelle ny parvient pas. Les rsultats des exprimentations prcdentes ne sont par
contre pas complets. Nous esprons obtenir nouveau des rsultats intressants avec des versions
ultrieures.
4.6.4.2 Inuence de la taille des vecteurs
La taille des vecteurs inuence principalement le seuil requis pour tre ecace. On montre sur
la gure 4.14 les rsultats pour direntes tailles de vecteur, avec un seuil optimal pour chacun des
vecteurs. On remarque que dans tous les cas sauf lIIR avec la correction, lapproche gros grain
permet dobtenir un gain par rapport au CPU pour les oprations considres, alors que lapproche
classique grain n donne de plus mauvais rsultats que limplantation CPU.
55
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
0
20
40
60
80
100
7 8 9 10 11 12
D
e
b
i
t

e
c
h
a
n
t
i
l
l
o
n

(
M
S
p
s
)
log
2
(N)
CPU
Gros Grain
Grain Fin
(a) FFT
0
50
100
150
200
250
7 8 9 10 11 12
D
e
b
i
t

e
c
h
a
n
t
i
l
l
o
n

(
M
S
p
s
)
log
2
(N)
CPU
Gros Grain
Grain Fin
(b) Demapping
0
20
40
60
80
100
7 8 9 10 11 12
D
e
b
i
t

e
c
h
a
n
t
i
l
l
o
n

(
M
S
p
s
)
log
2
(N)
CPU
Gros Grain
Corrige
(c) IIR, F = 1
Figure 4.14 Dbit chantillons en MS/s en fonction de N, pour un seuil optimal calcul expri-
mentalement
On remarque galement, ce qui est nouveau, que pour une taille de bloc susante, utiliser un
GPU peut amliorer (ou au moins ne pas dtriorer) lexcution dun ltre IIR par rapport au CPU.
4.6.5 Rsultats pour des applications multitches
An dtudier lecacit du GPU dans le cadre dune application avec plusieurs oprations,
on utilise les trois oprations en squences (IIR, FFT, demapping). Cette application ne corres-
pond pas une application relle, mais permet de voir lvolution des performances dans le cas
du multitche. Deux lments ont t tudis qui peuvent inuer sur le multitche : le type din-
tgration (centralise ou distribue) et les communications entre les oprations. Il parait vident
que lutilisation du buer OpenCL permet dobtenir des performances plus intressantes. On ne
sintressera ici qu la dirence entre lexcution centralise et distribue, et sur leet de lutil-
isation des units indpendantes.
Les rsultats sont prsents dans la gure 4.15. Lapproche implante utilise lintgralit du
GPU pour chaque opration. Nous avions dj discut de la possibilit de rduire le seuil en
utilisant les capacit de paralllisme de tches des nouveaux GPU. Cette possibilit est en cours
dtude. Les rsultats montrent un rel intrt pour lapproche centralise, et un vrai gain dun
facteur allant jusqu 4 pour un dcoupage en blocs de 512 chantillons. La "dgradation" des
performances observes pour N > 512 sexplique par une taille de FIFO non adapte, les seuils
optimaux ne pouvant plus tre atteints. Lvolution propose prcdemment devrait permettre de
corriger ce problme. Une augmentation de la taille des FIFO est galement possible.
Ces rsultats sont extrmement dpendants du GPU utilis. Dans les conditions utilises pour
les rsultat de la gure 4.15, cest--dire avec lintgralit du GPU pour chacune des oprations, le
56
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
CHAPITRE 4. INTGRATION GPU 4.7. PERSPECTIVES ET CONCLUSION
0
20
40
60
80
100
120
140
7 8 9 10 11 12
D
e
b
i
t

e
c
h
a
n
t
i
l
l
o
n

(
M
S
p
s
)
log
2
(N)
CPU
Distribue
Centralise
Figure 4.15 Rsultats pour une squence doprations, pour un seuil optimal calcul exprimen-
talement
nombre de curs inue sur les rsultats par opration, et donc sur les rsultats globaux. Certains
GPU rcents orent la possibilit dutiliser les direntes computing units de manire indpen-
dante. Il devient donc possible de sparer lexcution dune squence doprations en crant un
pipeline doprations (comme expliqu en 4.5.3. Cette sparation nest pas encore implmente.
Cette solution permet galement denvisager des optimisations sur la localisation des donnes, en
utilisant de la mmoire locale des CU.
Dans ce cas de gure, la taille et le nombre des CU deviennent des paramtres importants du
GPU. Le GPU utilis a 4 CU de 32 curs chacun.
4.7 Perspectives et conclusion
4.7.1 Discussion : portabilit vers lembarqu
Lutilisation de la radio logicielle dans les systmes embarqus fait lobjet de plus en plus
dtudes. Lutilisation du multimode sur les terminaux mobiles serait un gros avantage pour la
tlphonie sans l, les smartphones pourraient suivre les volutions des normes, et mieux encore,
utiliser nimporte quelle norme sans avoir besoin de matriel ddi.
Paralllement, des GPU pour les applications embarques commencent voir le jour, dont
certains comme le Mali T604 de ARM supportent lOpenCL. Les plateformes ION de NVidia
pour les ultra-portables sont un autre exemple.
Les rsultats prsents dans cette tude sont prometteurs. Cependant, on utilise ici un pro-
cesseur relativement puissant, qui sut pour excuter la plupart des applications radio. Dans le
cadre des applications embarques, le processeur est beaucoup moins puissant et ne permet pas
denvisager une excution logicielle. Les DSP sont une solution possible, mais lutilisation dun
GPU embarqu pourrait permettre dexcuter plus dapplications.
Il ny a pas encore au moment de la rdaction de ce mmoire de GPU compatible OpenCL (ou
environnement quivalent) conu pour lembarqu. Le Mali T604 [arm], annonc en 2010 [mal],
nest pas encore fondu. Il est donc dicile de savoir si ltude ralise durant cette thse sera
portable sur ce GPU. On peut cependant mettre certaines hypothses.
Les contraintes de lembarqu pourraient faire diminuer le nombre de cores. Les spcications
accessibles du Mali parlent dune architecture base sur un nombre variable de curs, entre 1 et
4. La notion de curs est oue. Si le cur est un core NVidia, alors entre 1 et 4 curs indiquent
un trs petit GPU. Si on table sur quatre cores, au vu de leet du multitche qui diminuait le
nombre de cores accessibles par opration, on peut estimer que lapproche gros grain permettrait
toujours un gain par rapport au CPU, surtout que ce dernier est moins ecace. Si le cur est un
57
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
4.7. PERSPECTIVES ET CONCLUSION CHAPITRE 4. INTGRATION GPU
unit OpenCL, ce qui parait plus plausible, alors ltude ralise dans ce chapitre reste galement
valable.
La place limite, et la limite de consommation dnergie, risquent galement de pousser vers
une diminution des frquences, et surtout une absence de mmoire ddie au GPU. On peut sup-
poser que lintgration du GPU avec le CPU sera trs forte, avec une mmoire partage et des
caches (comme pour le Mali 400). Ceci pousse vers une limitation de la mmoire utilise, qui
imposerait alors de diminuer les seuils ayant pour consquence une forte dtrioration des perfor-
mances.
Dans lensemble, il est assez dicile de savoir quel sera le rsultat sur un GPU embarqu.
Mais au vu des performances dplorables de la radio logicielle sur un CPU embarqu, il y a lieu
de penser que lutilisation du GPU pourrait amliorer ces performances. La question laquelle il
faudra rpondre sera : ces performances seront-elles susantes pour implanter un vrai terminal ?
4.7.2 Conclusion
Nous nous sommes intresss dans ce chapitre la possibilit dutiliser le GPU pour excuter
des applications de radio logicielle, et plus particulirement des applications GNURadio. An
dtudier les ventuels avantages et inconvnients du GPU, trois points ont t abords.
Dans un premier temps, nous nous sommes intresss la conception dune opration excute
par le GPU. Larchitecture particulire dun GPU et de ses applications impose une implantation
dirente par rapport un CPU. La solution couramment utilise, par exemple dans [Mil10],
sapplique principalement sur des oprations basiques. Nous avons propos deux solutions pour
des oprations plus complexes. Lune, baptise approche grain n, se base sur des optimisations
des oprations pour le GPU, avec des kernels petits. Elle est une extension de la mthode classique.
Lautre est une mthode originale base sur lutilisation de gros kernels qui reprsentent toute
lopration. Cette approche dite gros grain permet denvisager une paralllisation mme pour
des oprations avec une dpendance de donnes.
Dans un second temps, nous nous sommes intresss lordonnancement, ou plus prcisment
au choix du moment de dclenchement de lopration sur le GPU. La maximisation de lutilisation
ncessite en eet que beaucoup doprations soient lances en parallle. Lutilisation dun seuil de
dclenchement, qui dnit combien dchantillons doivent tre prts tre traits avant lexcution
par le GPU, permet de contrler lecacit. Leet de ce seuil sur la latence et la mmoire a t
discut, ainsi que des solutions possibles pour diminuer cet eet. Cet ordonnancement a ensuite t
appliqu deux intgrations possibles des oprations GPU, lintgration distribue et centralise.
La deuxime option, qui dnit un bloc dans lequel toutes les oprations GPU seront ralises, est
une contribution de cette thse. Elle permet en particulier de grer le multitche ecacement, de
diminuer lempreinte mmoire, et dutiliser au mieux les direntes solutions dordonnancement
proposes.
Finalement, une tude des communications entre les blocs GPU a t faite. Dans le cas dune
intgration centralise, ces communications sont simples. Un buer conu pour les oprations
OpenCL a t dni dans le cas dune intgration distribue, qui vite les transferts inutiles de
GPU CPU. Ceux-ci sont en eet coteux.
Ltude des rsultats exprimentaux montre que lapproche gros grain propose permet
dobtenir une lgre amlioration de performance dans le cas des oprations unitaires. Pour les
applications multitches, lutilisation du buer OpenCL propose permet une amlioration plus
marque dans le cas dune intgration distribue, alors que lintgration centralise permet une
utilisation trs ecace du GPU, avec une empreinte mmoire et une latence minimises. Lutili-
sation de la nouvelle approche permet galement une amlioration de limplantation du ltre IIR,
contribution intressante de ce travail. On notera que ces rsultats sont vrais pour le GPU utilis.
Il serait intressant de regarder lvolution des rsultats sur dautres GPU, plus ou moins perfor-
58
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
CHAPITRE 4. INTGRATION GPU 4.7. PERSPECTIVES ET CONCLUSION
mant, an de se faire une ide plus prcise de linuence des paramtres du GPU (nombre de
curs, frquence, taille dune unit...) sur les rsultats obtenus.
Lintrt du GPU sur la plateforme utilise nest toutefois pas dmontr ici, et ce pour deux
raisons principales. Tout dabord, le gain en performance nest pas spectaculaire, mme si la carte
utilise pour les exprimentations est ici une carte graphique de faible puissance, alors que le CPU
est relativement performant (la consommation lectrique est la mme, daprs les spcications).
Un gain dun facteur 4 reste cependant intressant, mme si au vu des 128 curs du GPU, on
aurait pu esprer mieux. La libration du CPU est un atout, mais la complexit dune application
base de GPU limite son intrt. Cependant, le GPU peut tre envisag comme une cible de
secours, quil nest pas ncessaire dajouter dans une plateforme pour la radio exible, mais quil
est dommage de ne pas utiliser si elle est disponible.
Le second point noir de lutilisation du GPU est la latence. Dans cette tude, nous nous
sommes intresss principalement la puissance de calcul atteignable. Cependant, pour attein-
dre un dbit symbole plus intressant quavec un CPU, les latences envisages sont inacceptables
pour la plupart des normes rseaux. Si dans les protocoles de la couche MAC, une rponse est
requise (un acquittement, par exemple) dans un temps contraint, il est fort probable que ce temps
sera dpass en utilisant le GPU. Cependant, ce dernier conserve un intrt dans le cas dappli-
cations de type Digital Video Broadcasting (DVB), qui sont des applications de diusion, sans
retour possible de la part du rcepteur. Lutilisation de GPU dans le contexte embarqu pourrait
galement changer la donne, en diminuant le nombre de curs et donc la latence.
59
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
4.7. PERSPECTIVES ET CONCLUSION CHAPITRE 4. INTGRATION GPU
60
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
Chapitre 5
Dnition dun environnement pour la
radio exible
C
omme nous lavons voqu au chapitre 2, les multiples possibilits dimplantation de la radio
exible sont un frein au dveloppement dalgorithmes utilisant cette exibilit. Dans ce
chapitre, nous prsentons un environnement conu pour abstraire ces multiples implantations an
dorir une interface unique aux utilisateurs de la radio exible.
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.1.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.1.2 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.2 Architecture gnrale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.2.1 Prsentation gnrale de lenvironnement . . . . . . . . . . . . . . . . 64
5.2.2 R-HAL et traducteur . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.2.3 Couche protocolaire . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.3 Gestion des applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.3.1 Prsentation : ot de dveloppement dune application avec FRK . . . 67
5.3.2 Reprsentation dune application . . . . . . . . . . . . . . . . . . . . 68
5.3.3 Traduction et implantation de lapplication . . . . . . . . . . . . . . . 68
5.3.4 Gestion de lexcution . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.4 Implantation des cibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.4.1 TaME et extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.4.2 Cible logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.5 Intgration des coprocesseurs . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.5.1 Dnition et postulat . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.5.2 Reprsentations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.5.3 Fonctionnement de la cible coprocesseur . . . . . . . . . . . . . . . . 77
5.6 FRK en pratique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.6.1 tat de FRK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.6.2 Implantation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.6.3 Exemple du codeur convolutif . . . . . . . . . . . . . . . . . . . . . . 81
5.6.4 Exemple complet : IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . 87
5.6.5 Quelques chires . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
61
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
5.1. INTRODUCTION CHAPITRE 5. ENVIRONNEMENT FLEXIBLE
5.1 Introduction
5.1.1 Contexte
La radio exible telle quelle a t dnie dans [DZD
+
05] regroupe toute implantation volu-
tive dun terminal radio. On retient gnralement deux proprits : ladaptabilit qui concerne des
changements de paramtres numriques, et la reconguration qui concerne des changements dans
la structure mme de lapplication. Ces proprits peuvent sobtenir de direntes manires, par
exemple :
en utilisant une implantation logicielle de lapplication, qui sexcutera donc sur un ou des
processeurs, spcialiss ou non ;
en utilisant des acclrateurs matriels paramtrables ;
en utilisant des FPGA, qui permettent de modier larchitecture de la plateforme dexcu-
tion an de ladapter lune ou lautre des applications.
Les dirents lments matriels sont relis en utilisant une mthode dinterconnexion, clas-
siquement un bus matriel, ou un Network on Chip (NoC) comme pour les plateformes Mag-
ali [NKM
+
09] et Leocore [LNT
+
09]. Dans ce chapitre, on sintresse une plateforme gnrique
prsente dans le chapitre 2, que lon prsente nouveau dans la gure 5.1 pour simplier la
lecture.
Figure 5.1 Architecture de plateforme exible gnrique
On donnera des cas concrets dutilisation de cette plateforme dans la section 5.6.
5.1.2 Objectifs
Ce chapitre a pour objectif de prsenter un environnement permettant de rsoudre les prob-
lmes lis lunication des plateformes. Le but principal est donc de permettre un utilisateur de
dnir et dutiliser une application sans se soucier de la plateforme qui lexcutera ce qui regroupe
deux aspects :
le support de la plateforme, qui est ncessaire son abstraction ;
la spcication dune application.
62
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
CHAPITRE 5. ENVIRONNEMENT FLEXIBLE 5.1. INTRODUCTION
5.1.2.1 Support des units dexcution
Tout dabord, comme nous lavons voqu dans ltat de lart dans le chapitre 3, la plupart des
environnements de radio exible actuels sont en fait des environnements de radio logicielle, qui ne
proposent pas de support pour les coprocesseurs ddis. Lintgration de ces coprocesseurs, quand
elle est disponible, se fait en utilisant une encapsulation logicielle. Cette encapsulation permet de
prsenter lenvironnement une interface logicielle classique, mais qui grera en fait la congu-
ration dun lment matriel ralisant le calcul. Les communications avec le composant matriel
sont galement gres en utilisant la surcouche logicielle. Cette mthode est fonctionnelle, mais
pas compltement satisfaisante, principalement pour des raisons de performance.
En eet, le surcot gnr est important, et lutilisation du coprocesseur nest pas optimale.
Lutilisation de linterface priphrique (device) dun noyau POSIX par exemple force lutilisation
dappels systmes, qui dtriorent les performances et sont de plus non dterministes. En se pas-
sant de systme dexploitation, si on conserve une interface logicielle, on limite les performances
du coprocesseur, puisque celui-ci est tributaire du logiciel.
5.1.2.2 Application, adaptabilit et recongurabilit
Un deuxime point important dun environnement de radio exible concerne la gestion des ap-
plications radio. Mme si les applications sont gres dans les environnements existants, certaines
amliorations peuvent tre apportes.
Une application radio est de manire gnrale donne sous forme de graphe, avec chaque
nud reprsentant une opration eectuer, et les arrtes reprsentant les communications entre
les oprations. Lors de lcriture dune application pour un environnement, on dnit ce graphe
avec les oprations implantes en utilisant lAPI spcique de lenvironnement. Dans le cas de
SCA, par exemple, les oprations sont des composants avec des interfaces CORBA, qui utilisent
ou tendent des objets dnis dans lenvironnement. Dans le cas de GNURadio, les oprations
sont des classes C++, quil faut instancier et connecter pour former le graphe.
Dans ce chapitre, trois points principaux de la gestion des applications sont tudis. Tout
dabord, la dnition dune application sur une plateforme htrogne pose le problme de sa
reprsentation. Il faut en eet pouvoir reprsenter lapplication indpendamment de la plateforme,
et pouvoir la traduire pour quelle soit comprhensible et excutable par la plateforme.
Lorsquune application est crite et charge en utilisant un environnement prcis, il faut pou-
voir modier son fonctionnement an de supporter la exibilit. Dans les environnements actuels,
ceci se fait en rechargeant une nouvelle application et en dchargeant lancienne. Cependant, dans
le cas o la modication est une modication mineure, pour adapter par exemple le dbit aux
conditions du canal, recongurer compltement une application est excessif. Lun des objectifs
de ce chapitre est de dnir une mthode permettant une modication mineure de lapplication
sans ncessairement modier toute lapplication. Cette modication doit pouvoir sappliquer de
manire gnrique sans connaissance de la plateforme, pour respecter lobjectif dunication.
Lautre point important de la gestion des applications est la possibilit de crer un terminal
multimode. Ce type de terminal permet dexcuter en concurrence plusieurs applications radio en
utilisant la mme plateforme. Le multimode soulve tout dabord un problme de performance
qui se partage entre la dnition de la plateforme capable de supporter plusieurs applications,
et la possibilit pour lenvironnement de savoir sil pourra excuter une application donne ou
pas. Le premier point nest pas abord, le deuxime est voqu dans cette tude. Mais permettre
lexcution concurrente des applications radio impose galement de les grer correctement, an
de les faire cohabiter et dutiliser au mieux la plateforme disponible.
63
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
5.2. ARCHITECTURE GNRALE CHAPITRE 5. ENVIRONNEMENT FLEXIBLE
5.2 Architecture gnrale
An de rpondre aux objectifs que nous nous sommes xs, nous prsentons ici un nouvel
environnement de radio exible baptis FRK.
5.2.1 Prsentation gnrale de lenvironnement
FRK est un environnement de radio exible bas sur une architecture classique en couches,
chaque couche permettant de gagner un niveau dabstraction. Au contraire des environnements
actuels, il est conu pour tre un environnement de radio exible au sens large, et non un envi-
ronnement de radio logicielle. Il permet en eet de grer des implantations matrielles, quelles
soient bases sur des FPGA ou sur des ASIC. FRK est construit comme un ensemble de librairies,
au mme titre quun noyau. Le choix de faire appel FRK pour les direntes tches est donc
laiss au dveloppeur.
Son intgration avec le systme dexploitation est plus forte que pour les autres environ-
nements. Contrairement SCA, qui se construit en surcouche dun noyau POSIX, ou GNURadio,
qui nest quune application sexcutant dans un systme GNU/Linux, il ajoute des lments qui
pourraient sintgrer dans le noyau, ce en quoi il sapparente Aloe.
FRK est construit autour dune partie lie lexcution (que lon appelle le runtime
1
), et dune
partie permettant de grer tous les calculs seectuant en dehors de lexcution (oine).
Figure 5.2 Intgration de FRK dans une architecture logicielle classique
Lintgration du runtime dans le noyau est prsent dans la gure 5.2. Dans le runtime, on
distingue deux couches, qui correspondent grossirement aux couches du modle OSI :
la Protocol Layer (PL) est la couche de plus haut niveau. Elle permet dimplanter les pro-
tocoles daccs au medium, gnralement concentrs dans la couche MAC. Cette couche
nest que rapidement aborde dans ce document ;
la couche permettant lexcution des applications radio, appele Radio Hardware Abstrac-
tion Layer (R-HAL), qui fait linterface avec la couche protocolaire, et qui gre le charge-
ment et le dchargement des applications. Elle correspond la couche PHY du modle
OSI. Elle sintgre dans le noyau au niveau de la Harware Abstraction Layer (HAL), an
de fournir le support pour les coprocesseurs, et au niveau de la gestion des tches, an de
permettre lexcution logicielle.
1. par abus de langage, FRK tant construit comme une librairie
64
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
CHAPITRE 5. ENVIRONNEMENT FLEXIBLE 5.2. ARCHITECTURE GNRALE
La partie oine permet principalement de traduire une application pour la plateforme sur
laquelle on va lexcuter.
5.2.2 R-HAL et traducteur
La R-HAL permet de grer lexcution et la conguration de la plateforme an de permettre le
dploiement des applications radio. La gure 5.3 donne une reprsentation des dirents lments
composant la R-HAL. On distingue donc trois rles principaux pour cette couche.
Target Management (TaME)
OPM
Communication
WaveIorm Translator (WT)
Extension HAL
Accelerateurs
DRL
InterIace R-HAL
OIIline Runtime
Protocol Layer (PL)
CI
Noyau
Figure 5.3 Intgration de FRK dans une architecture logicielle classique
5.2.2.1 Reprsentation et contrle de la plateforme
La R-HAL permet de reprsenter la plateforme. La particularit de FRK, qui est la base de
sa conception et de laquelle dcoule son architecture, est sa gestion originale des direntes units
dexcution. Une plateforme excutant FRK est reprsente sous la forme de cibles (targets).
Une cible est un ensemble dunits dexcution pour lesquelles limplantation est similaire. Par
exemple, toute plateforme excutant FRK supporte la cible GPP. De mme, on peut dnir une
cible Open Computing Language (OpenCL), qui englobe les GPU, les GPP et les DSP avec un
support OpenCL. Finalement, on peut dnir comme cible les coprocesseurs matriels tels quils
seront prsents dans la section 5.5.
Les cibles sont gres dans la partie basse de la R-HAL. Cette gestion est ralise par le
TArget Management Element (TaME). On peut aussi avoir besoin de dnir des extensions de la
HAL qui sont propres FRK. Elles permettent de reprsenter les cibles non-gres par le systme
dexploitation, et galement de sinterfacer avec celui-ci. On revient plus loin sur les spcicits
de ces dirents lments et de la gestion de certaines cibles. Le but est de permettre dutiliser et
de congurer les direntes units dexcution prsentes sur la plateforme.
5.2.2.2 Traduction
Le Waveform Translator (WT) permet la traduction dune application dnie de manire
gnrique pour quelle soit excutable sur la plateforme. Bien que ne faisant pas rellement partie
de la R-HAL, elle y est rattache indirectement puisquelle doit sexcuter de manire cohrente
avec le runtime de FRK.
65
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
5.2. ARCHITECTURE GNRALE CHAPITRE 5. ENVIRONNEMENT FLEXIBLE
Le WT est la partie oine de FRK. Cette partie est base sur deux librairies permettant le
portage de lenvironnement sur la plateforme. La premire librairie est lOperation to Platform
Mapping (OPM), qui traduit une liste doprations prdnies en congurations pour la plate-
forme. Ce mcanisme est expliqu plus prcisment dans la section 5.3.
La deuxime librairie concerne les changes de donnes entre les oprations. La librairie im-
plante des canaux de transferts pour les direntes cibles prsentes sur la plateforme. Ainsi, par
exemple, on trouvera un canal de communication logiciel pour les communications entre tches
logicielles. De mme, un canal de type DMA pourra tre implant pour communiquer avec les
acclrateurs matriels. Le canal de communication OpenCL dni dans le chapitre 4 est un autre
exemple dimplantation.
La partie oine interagit en fait avec les couches basses de la R-HAL. Le port de FRK sur
une nouvelle plateforme passe par la dnition dune R-HAL supportant cette plateforme, et par
lcriture des librairies (OPM et communications) pour chaque cible de la plateforme.
5.2.2.3 Gestion des applications
La gestion des applications est galement ralise dans la R-HAL, et implique deux types
dactions.
La premire est le rle dordonnancement et dinterface, et est pris en charge par la partie
dinterface visible sur la gure 5.3. Lobjectif est de permettre le chargement et le dchargement
dapplications traduites pour la plateforme, et dassurer leur bon fonctionnement. Cette partie est
galement responsable de faire remonter aux dirents appelants les problmes ventuels ren-
contrs lors de lexcution de la plateforme. Lordonnancement entre les direntes applications
permet dassurer que toutes les applications actives sexcutent correctement.
Le second objectif est de permettre la modication dynamique de lapplication. Plus prcis-
ment, on veut pouvoir rpercuter des changements eectus sur lapplication haut niveau. Ceci est
eectu par la Dynamic Reconguration Layer (DRL), qui fonctionne en lien avec la partie oine
de FRK.
5.2.3 Couche protocolaire
La couche protocolaire (PL) a pour objectif de faciliter limplantation de protocoles de type
MAC. Elle nest actuellement pas encore compltement dnie. La gure 5.4 donne larchitecture
actuellement envisage.
Figure 5.4 Architecture de la PL
Le MAC manager (MM) est llment dans laquelle les couches MAC sexcutent. Pour
chaque norme qui va sexcuter dans lenvironnement, des couches MAC sont dnies. Ces
couches MAC sont implantes sous la forme de tches logicielles. Chacune des tches est as-
socie une application de la R-HAL, qui permet la communication. Il est galement envisag
que la PL ait une vision des cibles (TaME). Les protocoles MAC peuvent en eet tre implants
en matriel, certains protocoles tant normaliss. Lexemple du CSMA/CA, utilis dans les normes
66
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
CHAPITRE 5. ENVIRONNEMENT FLEXIBLE 5.3. GESTION DES APPLICATIONS
IEEE 802.11 et IEEE 802.15.4, en est une illustration. Cependant, intgrer ces lments peut se
rvler problmatique, surtout pour les appels la R-HAL. Ce problme nest pas encore rsolu
et fait partie des perspectives de ce travail.
Les couches MAC sont gres par le Conguration Scheduler (CS), cest--dire lordon-
nanceur des congurations. Cest llment central de la PL. Cet ordonnanceur est lordonnanceur
de plus haut niveau de FRK, qui active ou dsactive les normes dployes dans lenvironnement.
Cette (ds)activation se fait sur la base des lments sexcutant dans le contrleur MAC (MAC
controller, MC). Le MC est lentit dans laquelle les dirents algorithmes faisant usage de la
radio exible sexcutent. Il rcupre des informations de la R-HAL et des couches MAC en cours
dexcution, et prend ses dcisions sur lactivation ou la dsactivation des direntes normes, ou
sur la ncessit de recongurer ou de sadapter. Une implantation dalgorithmes propres la radio
cognitive pourrait se faire dans le MC.
5.3 Gestion des applications
5.3.1 Prsentation : ot de dveloppement dune application avec FRK
Les applications dans FRK scrivent en utilisant lAPI oerte par la librairie OPM. LAPI
gnrale de FRK est donne dans lannexe C. Lcriture de lapplication se fait selon la vision
classique de type graphe. On notera lexistence dune vision dirente, appele algbrique par son
auteur, dans laquelle on ne donne pas la squence doprations avec les transferts de donnes
eectuer, mais la fonction de transformation appliquer aux chantillons reus [Dic]. Le ot de
dveloppement pour FRK est prsent dans la gure 5.5.
Figure 5.5 tapes de chargement dune application FRK
Lapplication est dabord crite en utilisant une des mthodes disponibles (pour linstant, en
crivant un code dinitialisation). Cette application de haut-niveau que lon appellera waveform
par analogie avec lapplication SCA est ensuite traduite pour la machine sur laquelle elle va sex-
cuter. Cette traduction se fait en utilisant la partie oine de FRK. Bien quelle ait lieu en dehors
du runtime, la traduction a tout de mme lieu juste avant le chargement, et se fait au moment de
lexcution de la waveform. Le processus de traduction est prsent dans la section 5.3.3. Une
fois la waveform traduite, on obtient une Conguration Instance (CI), qui est en fait lapplication
que lon peut charger dans la R-HAL. La waveform sera utilise dans la PL ou dans les couches
suprieures, an de contrler lapplication. La CI sera conserve dans la PL, mais utilise dans la
R-HAL. Une fois la CI obtenue, ltape suivante est le chargement de lapplication sur la plate-
forme.
67
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
5.3. GESTION DES APPLICATIONS CHAPITRE 5. ENVIRONNEMENT FLEXIBLE
Quand la CI est charge, elle doit tre gre par la R-HAL qui est responsable de lordonnance-
ment des direntes CI et des oprations de la CI. Elle peut galement tre modie (adapte), ac-
tive ou dsactive. Cette modication se fait au niveau de la waveform, et est ensuite rpercute
sur la CI. Ces dirents mcanismes de gestion des applications sont prsentes dans les parties
suivantes.
5.3.2 Reprsentation dune application
On distingue dans FRK deux niveaux de reprsentation de lapplication. Le premier niveau
est la waveform, portable sur toutes les plateformes pour lesquelles FRK est disponible, et utilise
dans la PL. Le second niveau est lapplication traduite (la CI), spcique pour une plateforme.
5.3.2.1 Waveform
La reprsentation en graphe des applications permet denvisager plusieurs modes de
dveloppement. Elle se prte plutt bien lutilisation dune interface graphique, mais peut gale-
ment tre mise en place simplement laide de chiers contenant du code ou une reprsentation
du graphe laide dun langage de description. Dans ltat actuel de FRK, cest lapproche de
GNURadio qui est utilise. La reprsentation se fait avec un chier contenant du code. Les blocs
correspondant aux oprations sont instancis, puis connects explicitement laide dune fonc-
tion. Lapplication est donc crite en utilisant un programme, qui permet de gnrer la waveform
proprement dite.
LOPM ore aux utilisateurs un ensemble doprations prdnies. Ces oprations peuvent
avoir direntes granularits. On peut ainsi avoir des oprations simplistes, du type addition ou
multiplication. On peut galement avoir des oprations plus complexes, comme par exemple des
dmodulations damplitude ou de frquence. Finalement, on peut aussi avoir des oprations sur
des vecteurs comme la transforme de Fourier, ou encore un dcodeur Viterbi.
Une opration est dnie avec ses paramtres. On distingue deux types de paramtres :
les paramtres lis FRK, qui sont obligatoires. Ces paramtres sont lidentiant de lopra-
tion, le nombre de canaux en entres et le nombre de canaux en sorties, ainsi que les blocs
avec lesquels il y a connexion. Le dbit symbole requis pour lopration fait galement
partie des paramtres, mme sil nest pas encore utilis ;
les paramtres lis lopration, qui peuvent varier. Dans le cas dune opration dampli-
cation, par exemple, on a besoin de connatre la constante damplication. Pour la FFT, on
peut utiliser le nombre de points comme paramtre.
La waveform est une structure qui contient les direntes oprations de lapplication.
5.3.2.2 Conguration Instance
La CI est lapplication traduite pour la plateforme. Elle contient deux types dinformation.
Tout dabord, des informations dtat, en particulier le chargement et lactivation. Elle contient
aussi une rfrence vers la waveform dont elle est issue. Mais la CI contient galement les in-
formations sur les oprations instancies. Pour chaque cible de la plateforme, lensemble des
instances doprations excuter sur cette cible est donn. On marque galement les entres et
sorties de lapplication, qui sont utiliss pour des oprations spciques comme la dsactivation.
Les communications entre les oprations sont aussi disponibles.
5.3.3 Traduction et implantation de lapplication
La traduction de limplantation, comme prcis dans lexplication du ot de dveloppement
de FRK, se fait en deux phases : dabord les oprations puis les communications.
68
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
5.3.3.1 Oprations
La premire tape permet de rcuprer les direntes oprations qui sont utilises dans lap-
plication. Les oprations sont ensuite traduites pour tre excutables par la plateforme considre
laide de lOPM.
Chacune des oprations peut avoir direntes implantations en fonction des capacits de la
plateforme. De mme, en fonction des paramtres, une mme opration peut ne pas tre implan-
te de la mme manire. Prenons une nouvelle fois lexemple de la FFT. Sur une plateforme
comportant un GPU, un GPP, et un coprocesseur matriel FFT, on peut thoriquement avoir trois
implantations dune mme fonction. Cependant, le coprocesseur matriel nest pas ncessairement
capable de calculer une FFT quelque soit le nombre de points. De mme, pour limplantation logi-
cielle, un algorithme de type radix-4 sera plus ecace quun algorithme de type radix-2, mais ne
sappliquera que quand le nombre de points est un multiple de 4.
Lorsquon traduit une opration, les paramtres initiaux de cette opration sont xs. Lobjectif
de la traduction est de pouvoir extraire, pour un jeu de paramtre donn, les implantations pour les
direntes cibles existantes.
Figure 5.6 Traduction dune opration en utilisant lOPM
Le processus de traduction dune opration est reprsent dans la gure 5.6. On donne gale-
ment les types de donnes pour chaque tape, ces types tant dcrits dans lannexe C. Lors de
linitialisation de la plateforme, le nombre et le type de cibles sont connus, ainsi quun ordre
de priorit pour ces cibles. Chaque opration a un identiant unique (ID). Pour chaque cible,
on dnit les oprations qui seront excutables ainsi que limplantation qui correspond. Pour
les cibles gnriques indpendantes de la plateforme, comme par exemple les GPP ou la cible
OpenCL, limplantation est faite une seule fois. Pour les cibles dpendantes de la plateforme,
cest--dire les acclrateurs matriels, il faut faire limplantation pour chaque plateforme. Cette
implantation fait partie du portage de FRK sur la plateforme. Lors de la traduction, pour chaque
opration, on rcupre lID correspondant. Puis, on cherche toutes les implantations pour toutes
les cibles de la plateforme. On slectionne ensuite limplantation pour la cible ayant la priorit la
plus leve. Les implantations se prsentent sous la forme dun tableau dimplantations et dune
fonction select_config. Cette fonction permet de slectionner limplantation correspondant au
jeu de paramtres souhait pour la cible.
69
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
5.3.3.2 Transferts de donnes
La deuxime tape de la traduction de lapplication est la gnration des canaux de transfert de
donnes. Limplantation des communications dpend de lordonnancement que lon veut adopter.
Dans FRK, limplantation des communications se fait au moyen de FIFO implantes pour chaque
cible. Lutilisation de tampons de taille xe a t envisage au dbut de la conception de FRK,
comme pour limplantation centralise du GPU. Cependant, cette approche na pas encore aboutie
dans FRK, du fait de sa complexit au niveau de lordonnancement, et de sa faible volutivit. Lu-
tilisation des FIFO gnre un surcot li au contrle, principalement en logiciel, mais permet une
plus grande exibilit dans lordonnancement, et autorise certaines liberts sur lexcution ou non
dune opration. Si on tarde excuter une certaine opration pour laisser la priorit une autre,
les donnes ne sont pas perdues. Les FIFO rendent galement les oprations interchangeables
facilement.
On dnit deux types de FIFO, les FIFO ddies et les FIFO gnriques. Dans une FIFO
gnrique, les donnes sont localises dans la mmoire centrale du GPP principal. La FIFO
gnrique est implante au niveau de la R-HAL, et la mmoire ncessaire est donc localise
ce niveau l. Pour chaque cible, on dnit des oprations de synchronisation, qui permettent ef-
fectivement deectuer le transfert dans la cible. Les oprations de contrle, comme la purge ou
la vrication de ltat, sont communes au niveau de la R-HAL. Cette implantation a lavantage
de permettre une modication facilite de la cible de lopration. Lordonnanceur des applica-
tions, que lon dcrit plus prcisment dans la section 5.3.4, permet en eet de passer dune cible
une autre en fonction de la charge de la cible, comme dans lenvironnement Surfer [DLD11].
Elle permet aussi denvisager dutiliser une implantation double, pour les goulots dtranglement
de lapplication. Cette implantation double a t exprimente sur FRK, mais reste pour linstant
complique mettre en place. Par contre, lutilisation de FIFO gnriques nest pas toujours opti-
male. Si on reprend lexemple de la cible OpenCL, ltude du chapitre 4 montre que faire transiter
les donnes par la mmoire centrale est proscrire.
Les FIFO ddies de FRK sont principalement utilises pour faire transiter les donnes au sein
dune mme cible. la dirence des FIFOgnriques, une FIFOddie laisse libre la localisation
des donnes. Elle permet de diminuer le nombre de transferts, qui sont souvent coteux. Une FIFO
ddie peut ne pas avoir dimplantation logicielle et tre gre automatiquement par le matriel.
De mme, les donnes ne sont pas ncessairement accessibles par lenvironnement.
Dans les deux cas, chacune des cibles implante les interfaces de communication dont elle a
besoin. Linterface est xe et prsente en annexe C. On dnit galement une relation dordre
entre les direntes cibles pour dnir quelle sera linterface utilise. Ainsi, si on prend le cas
de la cible des acclrateurs matriels, en cas de connexion avec une cible logicielle, on utilise
les FIFO des acclrateurs matriels. De manire gnrale, les FIFO logicielles sont toujours les
moins prioritaires. Lors de la traduction, le WT va instancier toutes les FIFO requises une par
une. Ces FIFO sont slectionnes en faisant appel la fonction select_fifo de la cible prioritaire
qui, comme pour select_config, slectionnera la meilleure FIFO pour lopration en fonction
des cibles impliques. Lorsquune FIFO est instancie, les fonctions de lecture et dcriture sont
donnes au niveau de la CI, pour permettre aux oprations de savoir comment accder ses FIFO.
Si on reprend lapplication "FFT/demap" propose dans la gure 5.6, avec la cible 2 prioritaire,
le traducteur utilisera limplantation FFT0 de la cible 2 pour la FFT, et loprateur "Demap" de
la cible 1. Au moment de gnrer les FIFO, si on considre que la cible 2 est encore prioritaire,
lappel select_fifo slectionnera une implantation compatible pour une connexion avec une
autre cible, et renseignera dans la structure de limplantation FFT0 et demap les fonctions de
lecture et dcriture associe cette FIFO.
70
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
5.3.3.3 Chargement dune application
Une fois la waveform traduite, on obtient donc une CI, qui peut tre charge sur la plateforme.
Le chargement se fait cible par cible, opration par opration, en utilisant la R-HAL. Pour chaque
opration, on regarde la cible, et on appelle la fonction de chargement associe cette cible. Les
transferts de donnes sont grs au niveau des cibles.
5.3.4 Gestion de lexcution
La gestion de lexcution dune CI implique deux tapes :
lordonnancement, qui gre comment la CI va sexcuter sur la plateforme ;
la modication de la CI, qui permet ladaptabilit.
5.3.4.1 Ordonnancement
Lordonnancement des applications radio dans FRK se fait plusieurs niveaux :
lactivation/dsactivation des applications en fonction des normes requises est gre au
niveau de la PL;
le partage de la plateforme entre toutes les applications actives est gr au niveau de linter-
face R-HAL;
le partage dlments spciques de la plateforme est lune des tches de la partie basse de
la R-HAL qui gre les cibles.
Cette hirarchie de lordonnancement, qui correspond la hirarchie gnrale de FRK, se
rapproche de la vision hirarchique de la reconguration voque dans le chapitre 3 et dans
[DMLP05]. On se place ici au deuxime niveau de la hirarchie. Le niveau 1 (le plus haut) est
gr dans la PL, et fait intervenir des mcanismes plus proche de la radio cognitive, que lon
naborde pas dans cette tude. Le niveau 3 est gr spciquement en fonction des direntes
cibles et sera abord au cas par cas dans les sections suivantes.
Lordonnanceur des CI implant dans la R-HAL gre direntes actions. Tout dabord, il
rpond aux ordres dactivation et de dsactivation mis par la PL. Ces actions seectuent sur des
CI charges dans le systme. La dsactivation est dirente du dchargement : la CI sera toujours
prsente dans le systme, mais ne traitera plus dchantillons. An deectuer la dsactivation,
on utilise lalgorithme 8. La dsactivation des entres permet de stopper les chantillons entrant
dans le systme. Le fait de marquer les oprations comme inactives va permettre, au niveau de
la gestion des cibles, de forcer leur mise lcart lors du prochain traitement de cette opration
par lordonnanceur de la cible. Cette action est faite en appelant la fonction de dsactivation des
CI deactivate_ci. On marque ensuite la CI comme inactive (mme si les oprations ne sont pas
forcment inactives), pour information, et on sort la CI de la le des CI actives. Tout ceci se fait
videmment sous la protection des verrous associs, pour garantir latomicit.
Algorithm 8 Dsactivation dune CI
procedure D esactivation(CI)
Dsactiver les entres
Marquer toutes les oprations comme inactives
Marquer la CI comme inactive
Mettre la CI dans la le correspondante
end procedure
Lactivation suit la marche inverse. Les oprations sont marques comme actives et remises
immdiatement dans la le des oprations actives. Les sources sont actives en dernier, quand
toute la CI est prte, an dviter daccumuler trop dchantillons.
71
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
Lordonnancement entre les CI se fait selon un mode de priorit tabli par la PL. On distingue
deux modes de fonctionnement dans lordonnanceur : le mode dmon et le mode prioritaire. Une
CI en mode dmon traite des donnes en permanence en fonction de leur disponibilit. Elle na pas
de contraintes de temps pour traiter ces donnes, seulement une contrainte de stabilit, cest--dire
que toutes les donnes doivent tre traites. Une CI en mode prioritaire est traite immdiate-
ment au dtriment de toutes les autres. Ce mode prioritaire est mis en place au niveau des cibles.
Quand une CI passe en mode prioritaire, toutes les oprations associes deviennent prioritaires
sur les cibles. Ds que ces oprations ont susamment de donnes traiter, elles sont excutes,
quel que soit ltat des oprations des autres CI sexcutant sur cette cible. Le mode prioritaire
peut perturber le systme, et doit donc tre utilis avec parcimonie. Il est destin tre utilis
ponctuellement, par exemple pour une transmission, ou pour le traitement de canaux de contrle
dont on sait quand la rception est prvue. Il ny a pas actuellement de mode temps-rel dans
FRK. Il est encore en cours dtude, et devrait prendre la forme dun ordonnancement bas sur les
deadlines au niveau des cibles.
La gestion des calculs proprement dits de la CI se fait au niveau des oprations. Toutes les
oprations dune CI ne sont pas ncessairement actives au mme moment, an de maximiser
lutilisation de la plateforme. Si deux CI sont actives au mme moment, il est en eet sous-optimal
dordonnancer CI par CI, celles-ci nutilisant pas ncessairement les mmes cibles. Ordonnancer
opration par opration permet de grer la concurrence uniquement o il y en a. Chaque TaME
implante donc son propre ordonnanceur.
5.3.4.2 Adaptabilit : modication dynamique de la CI
Une CI charge nest pas ge. Deux raisons principales peuvent pousser une modication de
la CI : un ordre de la PL ou un manque de ressource. Lordre de la PL signie une modication de
la waveform. On parle ici dadaptabilit : la modication doit toucher un paramtre dune opra-
tion existante, mais ne peut pas modier la structure de la waveform, cest dire quelle ne peut
pas changer dopration, ni changer son interface. Le WT implante deux fonctions, translate et
update. translate est utilise pour traduire une waveform complte et gnrer une CI. La fonc-
tion update permet de retraduire uniquement une opration, sans modier les canaux de transferts
ni les autres oprations. On gnre donc une nouvelle conguration pour lopration, qui est rem-
place dans la CI initiale. Lancienne conguration vide la FIFO dentre et est supprime de la
liste des oprations pour lancienne cible. La nouvelle est insre dans la liste des oprations pour
la nouvelle cible.
Le manque de ressource est plus complexe grer. Dans la version actuelle de FRK, on parle
de manque de ressource quand un canal de transferts atteint son seuil critique. Cette dnition
nest pas optimale, mais on cherche juste mettre en place le mcanisme permettant de traiter ce
manque de ressources. En cas de dtection, la DRL est appele pour fournir une implantation de
remplacement pour lopration concerne. Si elle en trouve une, le mme mcanisme que pour une
adaptation a lieu, sauf que la FIFO dentre nest pas vide. Si elle nen trouve pas, la DRL tente de
trouver une autre implantation pour les autres oprations sexcutant sur la cible sature et modie
la CI concerne. Dans une prochaine version de FRK, il est envisag dimplanter un systme de
priorit dynamique pour les oprations. Dans ce mode dynamique, larrive saturation dune
cible diminue sa priorit lors de la traduction.
72
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
CHAPITRE 5. ENVIRONNEMENT FLEXIBLE 5.4. IMPLANTATION DES CIBLES
5.4 Units htrognes : implantation des cibles
5.4.1 TaME et extensions
5.4.1.1 Structure
Implanter une cible dans FRK revient implanter le support pour un type dunit dexcution.
Limplantation de ce support passe ncessairement par deux phases :
une description de la cible, qui se fait au niveau des extensions de la HAL;
une mise en place du contrle de lunit, qui comprend entre autres les fonctions de charge-
ment et de dchargement ainsi que lordonnanceur spcique de la cible, qui se fait au
niveau du TaME.
Figure 5.7 Architecture gnral dun contrleur de cibles
Larchitecture gnrale dune cible est prsente dans la gure 5.7. Les couches basses de la
R-HAL sont constitues dun ou plusieurs TaME sappuyant sur la HAL, qui peut tre dnie dans
le noyau ou dans les extensions.
5.4.1.2 Interface : API principale
An dtre utilisable, un TaME doit implanter une API prcise, qui permettra linterface de
la R-HAL de fonctionner quelque soit la cible. LAPI est assez limite, les lments de FRK tant
trs cloisonns.
On distingue deux types de fonctions :
les fonctions de modication doprations ;
les fonctions de recherche dinformations.
Les fonctions de modication permettent le chargement, lactivation, la dsactivation ou le
dchargement des oprations. Les fonctions de recherche dinformations permettent de rcuprer
des informations sur ltat de la cible, sur les erreurs ventuelles, sur le volume de donnes trait,
sur sa saturation ventuelle. La fonction de contrle est couple une fonction oerte par linter-
face de la R-HAL au TaME, qui permet de signaler quune cible est sature ou que de linformation
a t perdue. On prsente en annexe C les structures principales et les fonctions de FRK.
On prsente dans la suite de cette section limplantation de la cible logicielle, cest--dire
les mcanismes mis en place pour pouvoir excuter les oprations de manire logicielle. On se
concentre sur la cible GPP, et une rexion sur la cible OpenCL est donne dans la n de cette
section. Limplantation pour les coprocesseurs matriels est aborde dans la section 5.5
73
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
5.4. IMPLANTATION DES CIBLES CHAPITRE 5. ENVIRONNEMENT FLEXIBLE
5.4.2 Cible logicielle
5.4.2.1 Dnition
La cible logicielle nest pas implante directement au-dessus du GPP, elle utilise le noyau
comme HAL. Lorsque lon parle de GPP, on ne parle donc pas du processeur en lui-mme, mais
du noyau. Linterface avec le noyau se fait en utilisant les tches dnies par le noyau.
Nous pouvons remarquer une premire chose avant de dtailler lutilisation du noyau et lim-
plantation de la cible logicielle. La cible GPP, mme si elle se reprsente de la mme manire au
niveau de lOPM, dpend du noyau qui sera utilis. Dans la version actuelle de FRK, deux noy-
aux sont supports, Linux (ou nimporte quel noyau POSIX puisque seuls les appels POSIX sont
utiliss) et RTEMS (pas dans sa version POSIX, bien sr).
Lunit logicielle est donc reprsente par le noyau du systme dexploitation. Implanter une
opration pour lunit logicielle se fait en donnant la fonction qui devra tre excute. Cette fonc-
tion process doit avoir une interface simple, avec comme argument lopration sous sa forme
gnrique, an de connatre les dirents paramtres, ainsi quune zone mmoire en entre et en
sortie. An de permettre lexcution de cette fonction, la cible utilise une mthode base sur une
tche par opration. Cette mthode nest pas la plus ecace en termes de performance, cause du
surcot important li lordonnancement des tches au niveau du noyau.
Les transferts de donnes de la cible logicielle sont eectues avec des FIFO logicielles blo-
quantes
2
. Les donnes sont physiquement localises dans la mmoire centrale du processeur. On
dnit des fonctions read et write qui sont bloquantes en cas de manque de ressources. Ainsi, si
une requte de lecture est faite alors quil ny a pas susamment de donnes disponibles, le pro-
cessus appelant se met en attente dcritures sur la FIFO. De mme, si une requte dcriture est
faite sans espace mmoire disponible, la tche qui tente lcriture se met en attente tant quil ny
a pas eu de lectures. Les FIFO utilisent la granularit minimale pour la taille de donnes. Ainsi,
si une opration se fait sur un vecteur, llment de base de la FIFO ne sera pas le vecteur mais
un lment du vecteur. Cest la tche logicielle associe qui gre la prsence dun vecteur complet
avant dexcuter lopration.
Lordonnanceur de la cible logicielle est rparti entre la HAL (ou dans ce cas prcis, le noyau),
et le TaME. Au niveau du noyau, les tches sont rparties entre les dirents GPP existants. Elles
sont galement slectionnes pour excution selon la politique propre au noyau. Lordonnanceur
du TaME nest nalement responsable que de lactivation et de la dsactivation des direntes
tches. Dans le cas dun ordonnancement priorit, il peut galement modier les priorits des
direntes tches.
En ltat actuel de lenvironnement, les oprations sont implantes comme prsent dans la
gure 5.8. La fonction process, qui dnit laction eectue par lopration, est intgre dans une
tche, qui va grer la rcupration des donnes et lexcution du calcul. Le bloc gris correspond
cette fonction. Les autres blocs sont gnriques (et ne dpendent dailleurs pas du noyau employ).
Le bloc dinterface en entre et en sortie instancie pour chaque entre (et sortie) de lopration une
structure reprsentant la FIFO associ. En particulier, cette structure rhal_channel_t permet de
renseigner les fonctions de lecture et dcriture associes aux FIFO entourant le bloc.
Lordonnancement au niveau du TaME se fait en utilisant deux verrous, lun associ une
CI, lautre associ la cible elle-mme. Ces verrous permettent dinuencer lordonnanceur du
2. du mme type que pour la Kahn Process Network (KPN)
74
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
CHAPITRE 5. ENVIRONNEMENT FLEXIBLE 5.4. COPROCESSEURS
Figure 5.8 Reprsentation dune tche pour la cible logicielle
noyau, en forant une tche se mettre en attente. Chacune des tches tente de prendre un verrou
priodiquement, plus prcisment, chaque appel de la fonction process. Elle le libre immdi-
atement aprs. An de limiter limpact de lenvironnement, il est possible daugmenter la priode.
Si le verrou est dj pris, la tche ne peut pas sexcuter et est mise en attente. Les tches vrient
toujours leurs deux verrous (celui de la CI et celui de la cible). Une tche prioritaire ne vrie que
celui de la CI. La prise des verrous est faite par la PL ou par lapplication utilisant la CI. Si le
verrou de la CI est pris, alors la CI est dsactive, et les tches associes sont mises en attente. Le
verrou de la cible est utilis pour les tches prioritaires. Quand une CI est transforme en CI pri-
oritaire (ou quand elle redevient dmon), le verrou de la cible est pris ou relch en consquence,
an de forcer les tches non prioritaires se mettre en attente.
Lordonnanceur est galement protg, cest--dire que tout accs lordonnanceur ne peut se
faire que sous la protection dun verrou propre cet ordonnanceur. Cependant, ce verrou nentre
pas en jeu dans la gestion des oprations.
5.5 Intgration des coprocesseurs
5.5.1 Dnition et postulat
On prsente dans cette section les dtails de la cible des coprocesseurs matriels. On dnit
les coprocesseurs ou acclrateurs matriels comme des units de calculs paramtrables mais non
programmables. On sintresse ici des acclrateurs pouvant tre paramtrs en utilisant des
registres. Pour plus de simplicit, on considre galement que ces registres sont accessibles en
lecture et en criture, en utilisant le plan dadresses. Cependant, ce nest pas une obligation, la
mthode daccs au priphrique tant dpendante de la mthode dinterconnexion utilise. Ceci
est vrai galement pour les transferts de donnes. Lutilisation des interruptions est possible et doit
donc tre prise en compte. Limplantation du coprocesseur en lui-mme est laisse libre, il peut
par exemple tre dploy sur un FPGA ou dni comme un ASIC.
75
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
5.5. COPROCESSEURS CHAPITRE 5. ENVIRONNEMENT FLEXIBLE
5.5.2 Reprsentations
5.5.2.1 Coprocesseur
Dans FRK, les coprocesseurs sont reprsents en utilisant les registres. On distingue deux
types de registres. Certains registres du coprocesseur sont constants, et ne seront donc pas modis
durant lexcution par le coprocesseur. Ces registres sont gnralement les registres de congu-
ration. Les registres qui peuvent tre modis par le coprocesseur sont des registres volatiles. Ils
reprsentent gnralement ltat du coprocesseur.
Pour reprsenter un coprocesseur dans FRK, on donne les adresses auxquelles sont accessibles
les registres des deux types. Mme si ces adresses ne sont pas dans le plan dadresses gnral, il
est possible de dnir une adresse "locale" pour ce coprocesseur.
Pour illustrer la reprsentation des coprocesseurs, prenons lexemple (hypothtique) dun
codeur convolutif 3 additionneurs avec une mmoire de 3 lments, prsent sur la gure 5.9.
Dans ce codeur, on peut congurer le polynme du code en donnant, pour chaque additionneur,
les lments mmoires qui seront utiliss ou non. Comme le code a trois lments mmoire, les
additionneurs ont 4 entres possibles pour les bits mmoriss et le bit en entre. On peut galement
poinonner le code obtenu pour augmenter son rendement. Pour les registres volatiles, ltat des
lments mmoires est accessible dans un registre, et peut tre charg.
Figure 5.9 Codeur convolutif matriel paramtrable
On se retrouve donc avec une reprsentation du coprocesseur en 5 registres, dont 1 volatile :
trois registres pour activer les direntes oprandes de chaque additionneur (masque pour
les entres) ;
un registre pour donner le schma de poinonnage en sortie du codeur ;
un registre volatile pour ltat des bascules dans le codeur.
5.5.2.2 Oprations
Une opration excute par un coprocesseur est dnie en donnant lensemble des valeurs
pour les registres constants et volatiles du coprocesseur. Reprenons lexemple du codeur con-
volutif dans lequel on veut implanter le code reprsent en gure 5.10. Pour implanter ce code
sur lacclrateur matriel dni prcdemment, il faut donc donner 5 valeurs de registre, une
pour chaque registre existant. Les polynmes pour chaque additionneur (1000, 1011, 1110) sont
dabord donnes, puis la valeur de poinonnage (ici, pas de poinonnage, cest donc une matrice
de 1). Finalement, on initialise la valeur des mmoires 000.
Dans la version actuelle de FRK, il faut avoir une correspondance exacte entre une opration
et son implantation. Cela signie que le traducteur nest pas encore capable de grer les copro-
cesseurs implantant les squences doprations. Le codeur convolutif prsent ici implante en
ralit deux oprations distinctes, lencodage et le poinonnage. Il faut donc dnir une opration
qui intgre les deux actions. Le seul cas o il ny a pas ncessairement de correspondance exacte
76
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
Figure 5.10 Instance pour le codeur convolutif
est le cas o une opration est implante en utilisant plusieurs implantations de la mme cible. Par
exemple, un couple codeur/poinonneur dni comme une seule opration pourrait tre implant
sur deux coprocesseurs, lun pour lencodage, lun pour le poinonnage. Cette opration ne peut
pas encore tre rpartie entre plusieurs cibles.
5.5.3 Fonctionnement de la cible coprocesseur
5.5.3.1 Structure
Ces reprsentations de lunit dexcution et de lopration excuter sont utilises dans lar-
chitecture prsente dans la gure 5.11. On la dcrit ici pour un seul coprocesseur, le codeur dni
prcdemment.
Figure 5.11 Implantation de la cible pour le codeur
Le TaME pour les coprocesseurs regroupe lensemble des coprocesseurs dune plateforme
pour lesquels la mthode de contrle est la mme. Ceci permet de limiter le surcot gnr par
le TaME, et dviter lexplosion du nombre de TaME. En eet, si plusieurs coprocesseurs sont
disponibles et utiliss, il faudrait rajouter une cible par coprocesseur, ce qui pourrait entraner un
nombre de cibles important. On dnit donc une seule cible, la cible coprocesseur, qui grera
lensemble des coprocesseurs. En interne du TaME, cependant, tout est gr coprocesseur par
coprocesseur, sauf au niveau de linterface avec les couches suprieures.
5.5.3.2 Cong Switch
La conguration du coprocesseur est gre par un mcanisme dit de conguration switch qui
sapparente la commutation de contexte implante pour les GPP. On dispose donc dune con-
guration active sur le coprocesseur. Celle-ci est actuellement charge. Lorsque lordonnanceur
prend la dcision de changer de conguration active, il slectionne une nouvelle conguration.
77
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
5.5. COPROCESSEURS CHAPITRE 5. ENVIRONNEMENT FLEXIBLE
Le principe de la commutation de conguration est simple. On arrte le coprocesseur, soit
en bloquant sa FIFO dentre, soit en le dsactivant si laction est possible. On sauvegarde en-
suite dans la conguration actuelle (cest--dire dans sa reprsentation) les registres volatiles du
coprocesseur. La conguration est ensuite remise dans la le des congurations. La nouvelle con-
guration, quant elle, est active. Lensemble des registres est charg dans le coprocesseur, qui
est alors congur pour la nouvelle opration. On active ensuite les transferts de donnes vers le
coprocesseur.
Lordonnanceur du TaME des coprocesseurs est un ordonnanceur distribu, qui sapplique
pour chaque coprocesseur gr dans la cible. Chaque coprocesseur a une liste dinstances ex-
cuter, et une instance en cours dexcution. La fonction dordonnancement peut tre appele dans
trois cas :
soit sur interruption du coprocesseur dans le cas o celles-ci sont gres ;
soit, comme dcrit dans la suite, dans le cas o lune des FIFO dentres passe un seuil (soit
le dpasse, soit repasse en dessous) ;
soit quand lune des FIFO de sortie de linstance courante est pleine, auquel cas cette in-
stance ne peut plus sexcuter puisquelle na plus de place pour enregistrer le rsultat.
Lobjectif de cette fonction est de slectionner la conguration du coprocesseur.
La cible coprocesseur utilise un ordonnanceur bas sur ltat des canaux de communication en
entre, du mme type que celui propos dans [DDL10]. Le principe est assez simple. On dnit
pour chaque implantation un seuil minimal et un seuil maximal. Le seuil minimal est le seuil en
de duquel on nexcute pas lopration. Le seuil maximal est le seuil au del duquel lopration
doit tre excute si possible. Ltat dune conguration est vri aprs chaque criture et lecture
dans une des FIFO dentres. La fonction dcriture marque les oprations comme candidates
(seuil maximal dpass) ou excutables (seuil minimal dpass). La fonction de lecture ne marque
pas les oprations, pour ne pas avoir protger le marquage (accs exclusif). Lordonnanceur met
lui-mme jour la fonction courante. Finalement, si lcriture entrane un dpassement du seuil
maximal, ou la lecture du seuil minimal, lordonnanceur est appel.
Le choix de lopration excuter se fait en fonction des seuils, selon lautomate prsent dans
la gure 5.12. Lordonnancement se fait en deux parties : la slection dune opration selected,
et la dcision de reconguration. Lordonnanceur commence par vrier si des oprations ont at-
teint le seuil maximal (opration candidate). Si cest le cas, il slectionne la premire opration
candidate et sarrte. Si ce nest pas le cas, il cherche une opration ayant dpass le seuil min-
imal (opration excutable). Aprs la slection, il vrie ltat de lopration courante et dcide
sil faut recongurer ou non. Si lopration courante nest pas excutable, et quune opration a
t slectionne, il y a reconguration. De mme, si lopration slectionne est candidate, alors
que lopration courante nest quexcutable, on recongure. An de limiter les changements de
conguration, le choix par dfaut est de ne rien faire.
Lalgorithme 5.12 est donn pour une seule le. Pour implanter le mode prioritaire et le mode
dmon, lordonnanceur dispose de deux les, qui correspondent chacune un des modes. Si une
opration fait partie dune CI prioritaire, elle est range dans la le approprie. La le prioritaire
est toujours traite en priorit. Si elle nest pas vide, aucune conguration de la le dmon ne peut
sexcuter. La le des oprations en attente nest bien videmment pas traite.
Les transferts de donnes dans la cible des acclrateurs matriels sont implants selon les
deux mthodes dnies prcdemment, la mthode gnrique et la mthode ddie. La mthode
la plus simple est la mthode ddie. Comme dcrit prcdemment, la localisation des donnes
78
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
Figure 5.12 Automate de slection dune conguration pour le TaME coprocesseur
nest pas dnie pour cette mthode. Elle simplante quelque soit la mthode de transfert utilise
pour le coprocesseur, directement au niveau de la cible. Les appels aux fonctions write et read
permettent dcrire ou de lire directement les donnes. Lappel peut tre bloquant si la synchro-
nisation est longue, ou si lacclrateur ne peut plus accepter ou fournir des donnes, ou encore
si la conguration correspondant lopration est dsactive et quil ny a pas de tampon avec la
FIFO.
Au contraire, la FIFO gnrique simplante dans la R-HAL. La cible fournit donc uniquement
une fonction de synchronisation en lecture ou en criture. Cette approche a deux avantages. Elle
permet dimplanter une FIFO quand lacclrateur nen implante pas en matriel. Elle permet
galement de ne pas bloquer les oprations au bout des canaux de transferts, quand lacclrateur
est bloqu ou que la mthode dinterconnexion est lente. Cependant, elle gnre des copies de
donnes supplmentaires qui peuvent tre longues.
5.5.3.5 Exemple : le codeur
Pour illustrer le fonctionnement du TaME, reprenons lexemple prcdent du codeur convolu-
tif.
Imaginons deux applications bases chacune sur un code de rendement
1
3
, les applications A
et B. Lors du chargement des applications A et B, les oprations de codage sont toutes les deux
ranges dans le TaME. Comme lapplication A se charge avant lapplication B, cest le code A
qui est actif sur le coprocesseur. On considre pour lexemple que les deux applications sont en
mode dmon (ce qui est peu probable pour une tche dmission). Chacune des applications ses
propres FIFO logiques, lapplication active travaille sur la FIFO matrielle si elle est disponible,
alors que lapplication en attente a une FIFO logicielle.
Lorsque la FIFO dentre du code B dpasse le seuil x, lordonnanceur impose une com-
mutation de conguration. Il slectionne le code B comme nouvelle conguration, dsactive les
transferts de donnes vers le coprocesseur, et sauvegarde la conguration actuelle. Une fois ces
79
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
5.6. FRK EN PRATIQUE CHAPITRE 5. ENVIRONNEMENT FLEXIBLE
oprations eectues, il charge la nouvelle conguration, modie la source des donnes pour le
transfert, puis relance les transferts de donnes.
5.6 FRK en pratique
Nous donnons dans cette section certains dtails dimplantation de FRK, ainsi que des exem-
ples dutilisation. La jeunesse de FRK na pas permis de raliser de comparaisons concluantes
sur le cot de lenvironnement. Cependant, les exemples prsents ici ont t implants et sont
fonctionnels. Nous avons utiliss GNURadio comme environnement de comparaison pour vrier
la correction du rsultat.
5.6.1 tat de FRK
FRK a t implant en utilisant le langage C. Nous avons longuement hsit entre ce langage
et un langage objet comme le C++ qui aurait permis de raliser plus simplement certaines ac-
tions. Cependant, le C++ ore beaucoup plus de fonctionnalits que lhritage utilis dans FRK.
Ces fonctionnalits, que nous nutiliserons pas dans limplantation, cotent cher en termes de
performance et despace mmoire requis, comme nous avons pu nous en rendre compte sur une
plateforme embarque lors de nos premiers essais. Il nous a donc sembl prfrable dutiliser le
langage C, moins gourmand.
Figure 5.13 Plateforme MagNET
FRK a t port sur deux plateformes distinctes. Tout dabord, une plateforme classique x86 a
permis de valider la cible logicielle. La deuxime plateforme est base sur un Atmel AT91RM9200
coupl un FPGA. Elle a permis dexprimenter sur la cible des acclrateurs matriels. On donne
un schma de cette plateforme, utilise pour le projet europen MagNET, dans la gure 5.13. Un
noyau Linux 2.6.23 avait dj t port sur cette plateforme. Nous avons ralis le port du noyau
Real-Time Executive for Multiprocessor Systems (RTEMS) 4.10.
Au moment de la rdaction de cette thse, lenvironnement est dans ltat suivant :
la cible logicielle est implante pour les deux noyaux ;
la cible des coprocesseurs matriels est implante pour certains types dacclrateurs. Un
port sur la plateforme Magali a t envisage mais na pas pu tre ralis.
linterface R-HAL est compltement fonctionnelle du point de vue du contrle des applica-
tions ;
un mcanisme de monitoring a t dni et est partiellement implant (cf. annexe C) ;
80
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
CHAPITRE 5. ENVIRONNEMENT FLEXIBLE 5.6. FRK EN PRATIQUE
lOPM est galement crit et valid ;
linterface OpenCL est partiellement supporte. Cependant, certains lments posent prob-
lme. La traduction de lapplication en prsence dOpenCL en est un. La gestion de la sur-
charge est galement dicile, cause de lunication requise des oprations. Ces problmes
sont en cours de rsolution.
Les algorithmes utiliss actuellement pour tous les lments sont encore basiques, laccent
ayant t mis sur le fonctionnement des lments entre eux.
5.6.2 Implantation
Limplantation relle du TaME des acclrateurs nest pas aise. On donne ici quelques infor-
mations sur les techniques employes pour les deux noyaux que nous avons expriments.
5.6.2.1 Linux
Le premier noyau expriment est un sytme Linux, en loccurence un systme Linux embar-
qu. Deux approches ont t suivies dans le cas du Linux, lune sexcutant dans le noyau, lautre
non.
La plus grosse dicult vient en fait de la gestion des interruptions. Le nombre dinterrup-
tions possibles est norme, et elles peuvent virtuellement tre dclenches pour nimporte quelle
raison, selon lacclrateur tudi. Dans un premier temps, nous nous sommes donc intresss
des acclrateurs sans interruption. Lutilisation de tels acclrateurs peut se faire dans lespace
utilisateur. La seule contrainte est de mapper les adresses sur lesquelles nous allons travailler pour
la conguration dans le plan dadressage virtuel impos par Linux. Ceci se fait aisment, par lin-
termdiaire de la fonction POSIX mmap, condition de pouvoir travailler sur la mmoire comme
sur un chier. Une fois ceci fait, congurer le composant revient crire une adresse connue, et
il est possible dexcuter le TaME en mode utilisateur.
Cependant, si les interruptions sont ncessaires, il faudra au minimum une partie en mode
noyau. Cest limplantation actuelle dans FRK. Les extensions HAL sont implantes comme un
module du noyau, et ont donc accs toutes les fonctionnalits de celui-ci. Au dessus de ce mo-
dule, les fonctions du TaME proprement dites, comme lordonnanceur ou la commutation sont
mises en place en mode utilisateur, par des appels systme.
Limplantation de la cible logicielle utilise les threads POSIX. Les verrous sont ralises en
utilisant des mutex et des conditions.
5.6.2.2 RTEMS
Limplantation dans RTEMS suit la mme logique. Chacun des lments est ajout normale-
ment dans le Board Support Package (BSP), ainsi que les traitants dinterruption. Le TaME est
ensuite implant normalement comme pour lespace utilisateur de Linux, comme une librairie qui
implante les direntes fonctions requises.
La cible logicielle peut tre implante soit en utilisant linterface POSIX du noyau, soit en
utilisant les rtems_task spciques. Les verrous sont implants en utilisant des spinlock, solution
qui doit pouvoir tre amliore.
5.6.3 Exemple du codeur convolutif
5.6.3.1 Prsentation du programme
Le codeur convolutif a dj t prsent dans ce chapitre. On se base sur une application
similaire lapplication de test pour les exprimentations du GPU au chapitre 4. Les sources
et puits de lapplication sont des chiers. Il ny a pas de notions de dbit tenir dans ce cas. Le
81
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
programme est simple crire. On cre les trois lments constituant lopration, savoir la source
et le puits de lapplication qui sont tous les deux des chiers, et lopration de codage.
Deux applications avec deux codeurs sont cres, on donne ici le code pour lapplication du
codeur A.
int coderA_waveform(frk_wf_t *waveform)
{
frk_filesource_t source;
frk_filesink_t sink;
frk_convcoder_t coder;
init_filesource(&source);
init_filesink(&sink);
init_convcoder(&coder);
// Ouverture des fichiers concernes
FILE *source_file = fopen(sourcefilename , ...);
FILE *sink_file = fopen(sinkfilename , ...);
// Mise a jour source
source.file = source_file;
// Mise a jour puits
sink.file = sink_file;
// Reglage codeur
coder.num_adder = 3;
coder.num_mem = 3;
// Definition des entrees actives des additionneurs
coder.adder_mask[0] = 0x8; // 1000
coder.adder_mask[1] = 0xb; // 1011
coder.adder_mask[2] = 0xe; // 1110
// Definition du schema de poinconnage
coder.puncturing = 0xFFFFFFFF; // Pas de poinconnage
connect(source,0,coder ,0); // source ---> codeur
connect(coder,0,sink,0); // codeur ---> puits
init_waveform(waveform ,3); // waveform avec 3 elements
add_op(source,waveform);
add_op(coder,waveform);
add_op(sink,waveform);
}
On va ensuite appeler la fonction translate, qui permet la traduction dune waveform en une
CI. On gnre galement une autre waveform avec des polynmes dirents pour le codeur B.
Cette CI dpendra de la plateforme en cours.
5.6.3.2 Excution logicielle
Sur la plateforme x86, la traduction de cette waveform gnre une CI avec trois oprations et
2 canaux de communications FIFO. Ces oprations, pour lexcution logicielle, sont reprsentes
sous la forme de trois fonctions, une pour chaque opration. On reprsente sur la gure 5.14 la CI
correspondant au codeur A. Seul le TaME Linux est disponible sur la plateforme x86. La structure
servant reprsenter la CI, ainsi que les types annexes sont donns dans lannexe C. Il y a une liste
82
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
doprations par cible, ainsi quune liste des FIFO utilises. Dans FRK, les listes sont en ralit
implantes comme des tableaux de pointeur sur les lments concerns. Pour ces FIFO, on donne
la reprsentation gnrique au niveau de la R-HAL. Cette reprsentation utilise limplantation au
niveau du TaME.
Les ches sur la gure servent reprsenter les relations entre les dirents lments utiliss
pour dnir une CI. Ainsi, le champ outputs de lopration source_config est en fait un pointeur
sur la FIFOchannel_0. Les oprations sont reprsentes au niveau du TaME par une tche associe
dans le noyau, et une fonction process (non reprsente ici) qui est fournie lors de la traduction
par le TaME. Pour simplier la gure dj trs charge, les entres/sorties des congurations
pointent sur les FIFO du TaME. Dans limplantation relle, ces entres/sorties pointent sur les
FIFO du R-HAL. Une simplication de cette interface est en cours, qui supprimera un niveau en
fusionnant les deux. De mme, pour allger la gure, les pointeurs sur les producteurs prod et les
consommateurs cons des FIFO ne sont pas reprsents, ainsi que les pointeurs sur la CI.
La concurrence pour sexcuter sur la GPP est gre au niveau du noyau, les pthread_t tant
intgrs dans la le des lments excutables de celui-ci.
Figure 5.14 Application traduite pour une cible logicielle
5.6.3.3 Excution matrielle : une seule application
On commence par synthtiser sur le FPGA un codeur convolutif g ne permettant que lex-
cution du codeur A. Lors de la traduction, lappel la fonction de slection pour cette cible dtecte
que le codeur A peut tre implant en utilisant le codeur matriel. La traduction de lapplication
pour le codeur Bdtecte quil ny a pas dimplantation matrielle pour ce codeur. Une implantation
logicielle est donc mise en place.
83
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
On se retrouve donc avec une CI purement logicielle pour le codeur B, et une CI mixte pour le
codeur A, les sources et puits des applications tant ncessairement logiciels. Le codeur convolutif
a t intgr dans le TaME des acclrateurs. Il nest pas congurable. On utilise dans cet exemple
une FIFO ddie dans laquelle le processeur est charg de raliser la copie une adresse prcise.
Cette adresse est le point dentre dune FIFO matrielle de taille 1024 octets. La sortie fonctionne
de la mme manire. Une implantation possible des FIFO dans ce cas est prsente dans lannexe
D.
On montre dans la gure 5.15 la CI correspondant au codeur A, sexcutant de manire mixte.
Une fois de plus, seule la cible logicielle doit grer la concurrence.
Figure 5.15 FRK avec deux codeurs, cibles mixtes
Le processeur doit donc grer cinq tches, la dernire tant ralise par lacclrateur. Notons
que ce type dacclrateur non congurable nest pas encore gr correctement dans FRK. En eet,
si une deuxime application se base sur le mme codeur A, elle ne pourra pas utiliser le codeur
matriel. Il faudrait pour cela rendre accessible la mmoire du codeur, pour pouvoir remettre le
codeur dans un tat puis dans lautre. An de grer correctement ce cas, une dynamisation de
lOPM est en cours, qui permettra terme de rendre lOPM conscient des disponibilits de la
plateforme au moment de la traduction. Ceci sera coupl une requte base sur le dbit requis,
an de slectionner limplantation la mieux adapte entre logiciel et matriel selon les besoins de
chaque application. Un retour devra galement tre possible, si lapplication utilisant le codeur est
dcharge, an de permettre une modication dynamique de la cible dans ce cas.
5.6.3.4 Excution matrielle : deux applications
Finalement, on synthtise un codeur congurable permettant dexcuter les deux codes A et B.
Ce codeur est dsactivable, cest dire quun registre de conguration
3
est disponible avec un ag
pour activer ou dsactiver lencodage. La CI correspondante est prsente sur la gure 5.16. La
reprsentation des deux applications complexient encore la gure. Pour lallger, les ches ont
t quasiment toutes retires. Elles restent similaires aux gures 5.14 et 5.15. Les FIFO dindices
2 et 3 sont rattaches au codeur B.
3. utilis par le TaME et non par les applications, celles-ci utilisant les registres de paramtrisation
84
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
Figure 5.16 FRK avec deux codeurs en matriel
On remarque que contrairement aux deux cas prcdents, il y a galement de la concurrence
pour un accs au coprocesseur matriel. Pour grer cette concurrence, on utilise donc la commu-
tation de conguration prsent dans la section 5.5. On prsente dans la gure 5.17(a) ltat du
systme durant lexcution juste avant lappel lordonnanceur, avec le codeur A actif et charg
sur lencodeur matriel. Les ches reprsentent le buer utilis par les FIFO. Les canaux rat-
tachs la conguration active utilisent directement les FIFO matrielles en entre du codeur. Les
canaux rattachs une conguration en attente utilisent les tampons logiciels.
Le chier contient lalphabet, et est lu en boucle. Le codeur A encode lalphabet en minuscule,
alors que le codeur B encode lalphabet en majuscule. Dans cet tat, la source du codeur B est
active, le tampon de la FIFO2 se remplit donc. Le codeur A est actif, le tampon des FIFO 0
et 1 nest donc pas utilis. Par contre, les FIFO matrielles en entre du codeur sont utilises,
et lopration sinkA a dj lu un lment pour le copier dans son chier de sortie. Lopration
sinkB est en attente de donnes et nest donc pas dans la liste des threads excutables du noyau.
Lencodeur ayant fonctionn, ltat du registre volatile (le dernier de la liste) nest plus ltat initial,
do le dcalage entre la conguration dans le TaME, et la valeur dans lencodeur matriel.
Lorsque la FIFO dentre du codeur B, alimente par la tche source sourceB, atteint son seuil
de dclenchement, lordonnanceur est appel. Comme lencodeur est plus rapide que le taux de
remplissage de la FIFO par la tche sourceA, la FIFO dentre du codeur A nest pas remplie
jusquau seuil
4
. Lors de lappel lordonnanceur, la conguration coderB est slectionne, et une
commutation de conguration a lieu. Le systme se retrouve alors dans ltat reprsent sur la
gure 5.17(b), juste avant la ractivation de lencodeur.
Ce cas est un exemple. Dans la ralit, lordonnanceur est plus souvent appel parce que la
FIFO atteint son seuil minimal (vide). Les FIFO sont ici un mlange de FIFO matrielle et logi-
4. dans le systme rel, la FIFO est en fait quasiment toujours vide, le codeur traitant ses donnes trs rapidement
85
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
(a) Avant lordonnancement
(b) Aprs lordonnancement
Figure 5.17 Reprsentation de ltat du systme
86
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
cielle comme dans lannexe D. Elles utilisent un buer pour crire les donnes quand la con-
guration nest pas charge, et transfrent les donnes ds que la FIFO se charge pour raliser la
synchronisation. Les donnes sont ensuite crites directement dans le matriel.
5.6.4 Exemple complet : IEEE 802.11
5.6.4.1 Prsentation du programme et de la plateforme
An dessayer FRK avec une application plus complte, nous avons implant la norme IEEE
802.11 (la premire version, sortie en 1997). On donne dans la gure 5.18 une reprsentation
de la waveform de lmission et de la rception de la norme. On implante la transmission et la
rception sur la mme plateforme. La waveform de transmission envoie des donnes la waveform
de rception. La chane de transmission est fonctionnelle, les donnes dcodes la rception sont
celles avant la transmission. Cependant, il ny a pas de notions de temps rel, puisquil nest
pas pris en compte dans FRK dans ltat actuel. Il ny a pas non plus eu de validation avec un
priphrique 802.11 rel.
Scramble Spreader
(DSSS)
Demapper
(PSK)
Polynme Sequence Constellation
Demapper
(PSK)
Mapper
(PSK)
Constellation
Detection
Trame
Despreader
(DSSS)
Demapper
(PSK)
Valeur SFD Sequence Constellation
Demapper
(PSK)
Demapper
(PSK)
Constellation
Demapper
(PSK)
Demapper
(PSK)
Descramble
Figure 5.18 Application IEEE 802.11 simplie utilise
On utilise pour cette excution la plateforme reprsente en gure 5.19. Cette plateforme four-
nit un corrlateur utilisable pour raliser la corrlation avec le code de Barker utilis dans la norme.
Ce corrlateur travaille sur des phases. Elle fournit galement un modulateur DPSK utilisable pour
le BPSK et le QPSK, ainsi quun dmodulateur matriel pour le QPSK mais pas pour le BPSK.
Un mlangeur et un dmlangeur ont galement t implants en matriel. On cherche donc
utiliser les waveforms pour envoyer de linformation, puis pour recevoir cette mme information.
Ces acclrateurs sont accessibles sur le bus ddi au FPGA dans larchitecture.
ARM920T
Core
I/Os
SRAM
PIO
APB EBI
PIO
PIO
SDRAM
32M
Atmel AT91RM9200
Traducteur Adresses
Contrle
Scrambler Descramble
Mapper
B/QPSK
Demapper
QPSK
Correl.
Figure 5.19 Plateforme matrielle pour lapplication IEEE 802.11
87
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
5.6.4.2 Fonctionnement BPSK
On commence par excuter la norme avec la modulation BPSK. La CI utilise alors le pro-
cesseur pour la dmodulation. Linterface du dmodulateur PSK fourni dans FRK est la suivante :
struct frk_demap_psk_s {
frk_op_t param;
unsigned int symbol_size;
unsigned char gray_coded; // 1 : TRUE, 0 : FALSE
unsigned char differential;//1 : TRUE, 0 : FALSE
float first_symb;
}
Lattribut symbol_size permet de donner le nombre de bits contenus dans un symbole, et
par consquent le nombre de symboles possibles. Les symboles en sortie du dmodulateur sont
des phases reprsentes en ottant. Lattribut gray_coded est un boolen, qui permet de dnir
si la modulation utilise un code Gray pour donner lordre des symboles. De mme, lattribut
differential permet de dnir si la modulation est direntielle ou non. Finalement, first_symb
permet de donner la phase pour le premier symbole de la liste, an de reconstruire la constellation.
La conguration de lopration pour le cas BPSK avec est donc :
demap.symbol_size = 1;
demap.gray_coded = 1; // inutile
demap.differential = 1;
dempa.first_symb = 0.0f;
Cette conguration, tudie par la fonction select_config de lopration pour la cible
matrielle, renvoie une conguration nulle, aucun dmodulateur matriel ne permettant une d-
modulation avec une taille de symbole de 1. Limplantation du dmodulateur est donc logicielle.
5.6.4.3 Demande dadaptation
La fonction suivante est implante pour contrler lapplication.
// waveform est lapplication de reception IEEE 802.11
// i est lindice de loperation de demodulation dans la waveform
int set_qpsk_modulation(frk_wf_t *waveform , int i)
{
// op_list est la liste des operations de la waveform
waveform ->op_list[i].symbol_size = 2;
waveform ->op_list[i].gray_coded = 1;
waveform ->op_list[i].first_symb = 0.0f;
// repercussion de la modification dans la ci
update(waveform, (frk_op_t *)&(waveform->op_list[i]));
}
Cette fonction donne les paramtres de la dmodulation pour quils correspondent une mo-
dulation QPSK, utilisant un code Gray, et dont le premier symbole (00) se code avec une phase
nulle. Lappel update permet de mettre jour lopration de modulation. La R-HAL appelle la
DRL qui utilise lOPM, et vrie limplantation sur les direntes cibles. Au contraire du BPSK,
la cible des acclrateurs matriels permet dexcuter cette dmodulation. Comme on utilise des
FIFO ddies, la FIFO dentre est dabord vide, puis la tche est supprime de la liste des tches
88
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
CHAPITRE 5. ENVIRONNEMENT FLEXIBLE 5.7. CONCLUSION
dans la cible logicielle. La nouvelle opration est ajoute dans la cible matrielle, et les informa-
tions pour lcriture et la lecture dans les oprations prcdentes et suivantes sont mises jour.
Ladaptation est ainsi ralise pour la chane de rception.
Dans le cas de la transmission, la cible est la mme avant et aprs la modication. Rien nest
supprim, on dsactive lopration, on attend que la FIFO soit vide, puis on met jour la con-
guration du coprocesseur pour cette opration. On ractive ensuite lopration.
On remarquera que, mis part le temps dattente li au besoin de vider la FIFO, le temps
dadaptation est court. La vidange des FIFO nempche dailleurs pas les autres oprations de se
faire, sauf pour les oprations qui prcdent directement lopration en cours de modication.
5.6.5 Quelques chires
Il est actuellement dicile de donner des rsultats chirs sur lenvironnement FRK. En eet,
celui-ci est trs rcent, et nexiste actuellement qu ltat de preuve de concept. On peut tout de
mme donner les quelques rsultats disponibles titre dindications. Ces rsultats sont susceptibles
de varier grandement au fur et mesure de lvolution de lenvironnement.
Les premiers chires concernant lenvironnement sont la taille du projet. Lenvironnement est
actuellement gr en utilisant le gestionnaire de version Git. Le projet fait une taille denviron
4500 lignes de codes, dont 4000 sont ddies lenvironnement lui-mme, et 500 sont prsentes
pour les congurations (les fonctions de la cible logicielle et de la cible OpenCL partielle, et les
congurations de la cible matrielle).
Une fois lapplication compile, on peut estimer lempreinte mmoire de cette application. Il
est par contre dicile de dissocier lespace occup par lenvironnement de lespace occup par
les congurations elles-mmes. Pour lapplication 802.11, prsente dans la suite, le binaire pour
la plateforme x86 a une empreinte statique denviron 156 kio, avec autour de 5 Mo dallocations
dynamiques (les FIFO logicielles sont congures pour tre grandes). Pour la plateforme ARM, le
binaire fait environ 172 kio pour la cible Linux (laugmentation est lie la prsence dune cible
matrielle), et 320 kio pour la cible RTEMS (le noyau se lie en statique lapplication, do le
binaire plus grand).
Les chires concernant le surcot en temps dexcution de lenvironnement ne sont pas relle-
ment reprsentatifs des possibilits de lenvironnement. Pour la cible Linux, la proportion du
temps dexcution consacre lenvironnement est denviron 10% pour la cible logicielle unique-
ment, 12% quand on mlange la cible logicielle et la cible matrielle. Pour la cible RTEMS, le
manque doutils de prolage na pas permis dextraire ces valeurs.
5.7 Conclusion
Dans ce chapitre, nous avons abord lenvironnement de radio exible FRK. Cet environ-
nement a t conu pour rpondre deux objectifs majeurs :
permettre une intgration de nimporte quelle unit dexcution ;
unier lcriture dune application quelque soit les units dexcution utilises.
FRK est conu comme une librairie utiliser pour constuire et grer des applications radio.
Il se base sur des cibles, qui reprsentent les direntes units. Chacune des cibles doit implanter
une API commune, mais reste libre de grer ses oprations. Ces direntes cibles sont relies
une librairie de traduction dun jeu doprations basiques. Cette librairie, lOPM, permet de
dnir quelle sera la cible de prdilection pour une opration traduite donne. Elle est utilise
pour permettre lunication de la dniton des applications.
Cet environnement a t implant et port pour deux architectures direntes, et pour deux
noyaux dirents. Dirents cas pratiques ont t prsents, an de montrer les mcanismes rgis-
89
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
5.7. CONCLUSION CHAPITRE 5. ENVIRONNEMENT FLEXIBLE
sant lenvironnement. Mme sil reste exprimental, et largement amliorable, FRK remplit les
objectifs xs.
90
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
Chapitre 6
Conclusion
C
inq questions ont guid notre rexion dans le but de permettre lintgration dunits dex-
cution htrognes pour des applications de radio exible. Elles ont donn lieu des travaux
innovants, dont nous dressons le bilan dans cette conclusion. Ces travaux pousss ltat de pro-
totypes valident la pertinence de la radio exible et laissent entrevoir dlgantes solutions pour la
exibilit des terminaux mobiles de demain.
Rponse la problmatique
Lutilisation du GPGPU pour la radio logicielle a t tudie dans le chapitre 4. Les travaux
raliss au cours de cette thse montrent que le GPGPU peut prsenter un intrt pour des applica-
tions radio fort dbit, et que les futurs processeurs graphiques ddis au domaine de lembarqu
devront faire lobjet dune attention toute particulire.
Comment utiliser de manire ecace le GPGPU pour la radio logicielle ?
Pour rendre attrayante lutilisation du GPGPU, le d relever consiste compenser les pertes
de temps occasionnes par le transfert des donnes et le contrle de larchitecture SIMD par lem-
ploi de toute la puissance oerte par les units de calcul. Nous avons donc concentr notre tude
sur les techniques de paralllisation des traitements de donnes, la fois pour des oprations sap-
pliquant des lments unitaires et pour des oprations sappliquant des vecteurs ou des don-
nes interdpendantes. La conception dune opration a t envisage selon deux mthodes. Une
premire mthode, dite grain n et rsultant dune adaptation de travaux prcdents, consiste
optimiser les implantations pour le GPU avec un dcoupage en petits kernels. Nous lavons mise
en uvre et les rsultats obtenus sont dcevants et en de des capacits dun GPP. Une seconde
mthode, dite gros grain, a t introduite dans cette thse. Elle consiste utiliser comme kernels
lopration optimise complte. Bien quinduisant une plus grande latence, les rsultats obtenus
avec cette approche sont encourageants, avec un gain observable pour des oprations unitaires.
An de permettre le contrle des oprations, nous avons dni un paramtre, nomm seuil dex-
cution, qui dnit le nombre doprations devant tre excutes en parallle. Nous avons pressenti
lexistence dun seuil optimal et nous avons montr sa valeur exprimentalement.
Comment intgrer les oprations sur GPU dans une application radio ?
Une application radio consiste en une suite doprations sur les donnes. Plusieurs techniques
de contrle ont donc t testes pour enchaner les oprations excutes par le GPU. Nous nous
sommes attards sur deux dentre elles que nous appelons respectivement intgration distribue et
intgration centralise. Dans lintgration distribue, des FIFO assurent le transfert des donnes
dune opration une autre. An de rendre cette approche plus performante, une FIFO spcique
lenvironnement t dveloppe. Bien que le dbit de calcul prsente un gain par rapport une
implantation CPU, cette intgration reste peu ecace car inadapte larchitecture de contrle
centralise du GPU. La mise en uvre de lintgration centralise sest avre plus prometteuse.
91
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
CHAPITRE 6. CONCLUSION
Elle utilise des tampons de taille xe entre les oprations. Lors de linitialisation, le seuil opti-
mal est utilis pour dnir la squence dappel des oprations permettant dexcuter lapplication
voulue. Les dbits atteints avec cette technique dintgration se sont rvls 4 fois suprieurs
ceux obtenus avec un CPU, prouvant ainsi lintrt du GPU pour excuter une application radio.
Quelle solution adopter pour utiliser les acclrateurs matriels dans une applica-
tion de radio exible ?
Le GPU nest pas la seule unit dexcution qui peut tre utiliser pour la radio exible. Lutil-
isation de coprocesseurs matriels peut galement conduire diminuer les temps dexcution des
applications radio. Le chapitre 5 propose une solution pour utiliser ces coprocesseurs. Plutt que
de les encapsuler dans des oprations logicielles, nous avons prfr les considrer comme des
processeurs extrmement spcialiss. La gestion de ces coprocesseurs passe donc par la gestion
dune liste de tches ddies ces acclrateurs. La liste contient lensemble des oprations de-
vant tre excutes, et les tches reprsentent la conguration dun acclrateur pour une opration
donne. An de permettre la concurrence des tches sur ces coprocesseurs, nous avons introduit
la notion de commutation de conguration, dont le but est denregistrer ltat dun coprocesseur
et de charger une nouvelle conguration.
Quelle architecture dnir pour permettre lexcution dune application sur des
architectures htrognes ?
Ces direntes units dexcution possibles peuvent coexister sur une platforme. Nous avons
donc propos dans le chapitre 5 une approche pour permettre la coopration de ces units. FRK
est un environnement form dun ensemble de librairies qui permettent la gestion dunits dex-
cution htrognes dans le cadre de la radio exible. Lenvironnement repose sur la dnition de
cibles dexcution. Chaque cible est dnie pour chaque type dunit dexcution utilise sur la
plateforme et permet dimplanter les direntes techniques de contrle et de transfert de donnes.
Trois cibles ont t considres au cours de la thse :
la cible logicielle gnrale (cible des GPP) ;
la cible OpenCL qui a t rapidement prsente, mais nest pas encore fonctionnelle, mme
si ltude du chapitre 4 permet denvisager une intgration rapide ;
la cible des acclrateurs matriels.
Comment dcrire et traduire une application radio ?
Lutilisation de FRK permet dapporter une solution lgante au problme de gnricit de
lapplication soulev par lutilisation de plateformes htrognes. Pour cela, FRK sappuie sur
deux caractristiques. Une librairie doprations gnriques communment employes par les ap-
plications radio est propose au dveloppeur. Associe avec la sparation en cibles dexcution,
FRK permet dutiliser la plateforme haut niveau, sans connatre le dtail de chacune des archi-
tectures supportes. Un dveloppeur voulant dcrire une application radio utilise les oprations
gnriques oertes par la librairie et cre une application gnrique appele waveform. Cette
waveform est automatiquement traduite en une application excutable sur la plateforme par-
tir des implantations disponibles sur les cibles prsentes. Lapplication gnrique et lapplication
excutable sont intimement lies, et toute modication sur lune peut tre rpercute sur lautre
pour orir une adaptabilit sans reconguration.
92
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
Perspectives
A la lecture de ces travaux, plusieurs chemins se dessinent, tant du point de vue des dveloppe-
ments futurs que des axes de recherche venir. Tout dabord, les travaux prsents sur le GPU
seront poursuivis. Nous souhaitons mettre en uvre lapproche multitche pour diminuer le nom-
bre de blocs requis pour atteindre les gains optimaux, ceci an de rduire loccupation mmoire.
Ensuite, il nous parait essentiel de terminer lintgration de la cible OpenCL dans lenvironnement
FRK, puis de tester son ecacit. Notre premier objectif tait de prouver la fonctionnalit de len-
vironnement. Dans un deuxime temps, nous pourrons travailler sur le surcot li la prsence de
cet environnement sur la plateforme. On dnit dans notre cas le surcot comme la part du temps
dexcution due lenvironnement. Actuellement, FRK prsente un surcot infrieur celui de
GNURadio ou SCA, mais plus important quAloe, autour de 10%. Ce surcot est calcul sur
les direntes applications implantes en utilisant un outil de proling, pour la cible logicielle.
Outre, loptimisation de FRK en termes de cot, la prise en compte du temps rel est un objectif
court terme. Une dnition du temps est dj en cours dans lenvironnement, qui sera le point de
dpart de cette prise en compte. En eet, la notion de moment dune reconguration nest pas triv-
iale, mais ncessaire pour permettre lutilisation de lenvironnement dans une application relle.
Lintgration de nouvelles cibles, comme le FPGA (et plus particulirement, la reconguration dy-
namique partielle de celui-ci) est galement envisage. ou lintgration de nouvelles cibles comme
les FPGA pourront tre envisages.
Lvolution de lenvironnement FRK et les choix qui seront poser dans le futur ouvrent sur de
nouvelles questions. Notamment, la correspondance opration/implantation savre tre une tche
complexe quil peut tre intressant danalyser en dtail. Prenons lexemple du codeur convolutif.
Dun point de vue applicatif, il nous a paru naturel dassocier au codeur convolutif un poinonneur.
Le poinonnage est une opration simple et dnir un acclrateur ddi cette opration,
quil faudra par la suite intgrer dans la chane de communication, semble sous-optimal cause du
surcot important. Cependant, lopration poinonnage doit malgr tout gurer dans la librairie
et tre propose aux dveloppeurs. Il apparait alors comme impratif de mettre en place le support
des acclrateurs matriels implantant une squence doprations. Des premiers pas ont t faits
dans cette direction au niveau des TaME. En particulier, la possibilit demployer des FIFOddies
une cible et inaccessibles des autres cibles dcoule de cette problmatique. Par contre, le support
au niveau du traducteur et pour ladaptabilit est plus complexe mettre en uvre et est encore
en projet. La question va plus loin que le simple support des acclrateurs. Plus les oprations
sont petites, plus leur dnition est exible, mais plus le surcot devient important. Quelle que
soit la cible nale, il est peut-tre plus intressant de dnir de petites oprations gnriques qui
se traduisent en grosses oprations excuter.
La radio exible soure aujourdhui de son manque dunication et de clart. Il est dicile
de discerner, dans le foisonnement de possibilits et dobjectifs une tendance bien dnie. Mal-
gr tout, certains points paraissent acquis. Tout dabord, la radio logicielle sur GPP ne sera pas
utilise pour lexploitation relle de la radio avant trs longtemps, et ce nest pas ncessairement
un but poursuivre. Ceci ne veut pas dire quelle est impossible : en multipliant les processeurs,
en complexiant un peu larchitecture, il sera toujours possible dobtenir susament de puissance
de calcul pour excuter nimporte quelle norme, mme les plus diciles. Cependant, sans mme
considrer lencombrement et la consommation lectrique qui ne permettront ce genre de plate-
forme que pour certains cas bien dnis, le cot logiciel deviendra tellement important, quil serait
plus simple et moins cher dutiliser un ASIC, et de le changer pour le faire voluer. Qui plus est, il
faudra toujours une partie matrielle pour la radio logicielle, et cette partie matrielle sera toujours
plus complique quune simple antenne. La dicult lie la dnition dune antenne ayant un
gain satisfaisant sur une gamme de frquence de plusieurs gigahertz fait quune solution utilisant
plusieurs antennes est prfrable. Lchantillonnage est galement limitant, comme nous lavons
93
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
dit dans le chapitre 2. Mme une plateforme de radio logicielle est donc htrogne. Une plate-
forme comme la plateforme Magali (ou le processeur Leocore) est donc un excellent compromis,
permettant une excution logicielle pour certaines oprations, mais orant un support matriel
pour les oprations communes. La dnition dlments matriels permettant une reconguration
va galement dans le bon sens.
Avec FRK, nous disposons maintenant dune interface unie qui peut sutiliser quelle que
soit la plateforme. Nous esprons videmment que cet environnement sera utilis lavenir, sa
mise disposition tant prvue dans un avenir proche. Lunication nous semble une notion in-
contournable dans les travaux futurs et ne concerne pas seulement la couche PHY de la radio. La
PL de FRK est un premier pas vers lunication de la couche MAC, qui ouvre sur une plus grande
coopration entre les direntes normes existantes et qui ne pourra quamliorer leur ecacit.
94
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
Annexe A
Rsultats complets pour le GPU
C
ette partie est ddie la prsentation des rsultats pour lintgration du GPU dans lenviron-
nement GNURadio. Ces rsultats sont donnes de manire brute, sans explication tendue,
pour le lecteur intress. Ltude approfondie dune partie de ces rsultats est disponible dans le
chapitre 4.
0
20
40
60
80
100
200 400 600 800 1000
D
e
b
i
t

e
c
h
a
n
t
i
l
l
o
n

(
M
S
p
s
)
t
opt
CPU
Gros Grain
Grain Fin
(a) 128 points
0
20
40
60
80
100
200 400 600 800 1000
D
e
b
i
t

e
c
h
a
n
t
i
l
l
o
n

(
M
S
p
s
)
t
opt
CPU
Gros Grain
Grain Fin
(b) 256 points
0
20
40
60
80
100
200 400 600 800 1000
D
e
b
i
t

e
c
h
a
n
t
i
l
l
o
n

(
M
S
p
s
)
t
opt
CPU
Gros Grain
Grain Fin
(c) 512 points
0
20
40
60
80
100
200 400 600 800 1000
D
e
b
i
t

e
c
h
a
n
t
i
l
l
o
n

(
M
S
p
s
)
t
opt
CPU
Gros Grain
Grain Fin
(d) 1024 points
0
20
40
60
80
100
200 400 600 800 1000
D
e
b
i
t

e
c
h
a
n
t
i
l
l
o
n

(
M
S
p
s
)
t
opt
CPU
Gros Grain
Grain Fin
(e) 2048 points
0
20
40
60
80
100
200 400 600 800 1000
D
e
b
i
t

e
c
h
a
n
t
i
l
l
o
n

(
M
S
p
s
)
t
opt
CPU
Gros Grain
Grain Fin
(f) 4096 points
Figure A.1 Rsultats complets pour la FFT
95
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
ANNEXE A. RSULTATS COMPLETS POUR LE GPU
0
50
100
150
200
200 400 600 800 1000
D
e
b
i
t

e
c
h
a
n
t
i
l
l
o
n

(
M
S
p
s
)
t
opt
CPU
Gros Grain
Grain Fin
(a) 128 points
0
50
100
150
200
200 400 600 800 1000
D
e
b
i
t

e
c
h
a
n
t
i
l
l
o
n

(
M
S
p
s
)
t
opt
CPU
Gros Grain
Grain Fin
(b) 256 points
0
50
100
150
200
200 400 600 800 1000
D
e
b
i
t

e
c
h
a
n
t
i
l
l
o
n

(
M
S
p
s
)
t
opt
CPU
Gros Grain
Grain Fin
(c) 512 points
0
50
100
150
200
250
200 400 600 800 1000
D
e
b
i
t

e
c
h
a
n
t
i
l
l
o
n

(
M
S
p
s
)
t
opt
CPU
Gros Grain
Grain Fin
(d) 1024 points
0
50
100
150
200
200 400 600 800 1000
D
e
b
i
t

e
c
h
a
n
t
i
l
l
o
n

(
M
S
p
s
)
t
opt
CPU
Gros Grain
Grain Fin
(e) 2048 points
0
50
100
150
200
200 400 600 800 1000
D
e
b
i
t

e
c
h
a
n
t
i
l
l
o
n

(
M
S
p
s
)
t
opt
CPU
Gros Grain
Grain Fin
(f) 4096 points
Figure A.2 Rsultats complets pour le demapping
96
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
0
5
10
15
20
25
30
35
40
200 400 600 800 1000
D
e
b
i
t

e
c
h
a
n
t
i
l
l
o
n

(
M
S
p
s
)
t
opt
CPU
Gros Grain
Corrige
(a) 128 points
0
20
40
60
80
100
200 400 600 800 1000
D
e
b
i
t

e
c
h
a
n
t
i
l
l
o
n

(
M
S
p
s
)
t
opt
CPU
Gros Grain
Corrige
(b) 256 points
0
20
40
60
80
100
200 400 600 800 1000
D
e
b
i
t

e
c
h
a
n
t
i
l
l
o
n

(
M
S
p
s
)
t
opt
CPU
Gros Grain
Corrige
(c) 512 points
0
20
40
60
80
100
200 400 600 800 1000
D
e
b
i
t

e
c
h
a
n
t
i
l
l
o
n

(
M
S
p
s
)
t
opt
CPU
Gros Grain
Corrige
(d) 1024 points
0
20
40
60
80
100
200 400 600 800 1000
D
e
b
i
t

e
c
h
a
n
t
i
l
l
o
n

(
M
S
p
s
)
t
opt
CPU
Gros Grain
Corrige
(e) 2048 points
0
20
40
60
80
100
200 400 600 800 1000
D
e
b
i
t

e
c
h
a
n
t
i
l
l
o
n

(
M
S
p
s
)
t
opt
CPU
Gros Grain
Corrige
(f) 4096 points
0
20
40
60
80
100
200 400 600 800 1000
D
e
b
i
t

e
c
h
a
n
t
i
l
l
o
n

(
M
S
p
s
)
t
opt
CPU
Corrige
(g) 8192 points
Figure A.3 Rsultats complets pour la IIR
97
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
98
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
Annexe B
Paralllisation dun ltre IIR
L
objectif de ce chapitre est de dmontrer la correction de lalgorithme IIR compatible avec
larchitecture SIMD du GPU. Cet algorithme est utilis pour limplmentation de la radio
logicielle sur le GPU en 4. On prsente dabord dans ce chapitre le principe du calcul et de la
dmonstration, puis on eectuera la dmonstration proprement dite.
B.1 Principe
On cherche calculer le ltre linaire IIR sur un ux de taille innie. Une taille innie nexiste
pas en pratique, mais on considre que ce ux est un vecteur de taille M trs grande. La formule
gnrale pour le calcul du ltre est :
IIR(n) =
min(n,F)
i=0
b
i
x(n i)
min(n,B)
j=1
a
j
IIR(n j), n N (B.1)
Lobjectif est dobtenir un calcul du ltre qui soit paralllisable sur une architecture de type
SIMD. Pour cela, on utilise un calcul du ltre IIR en bloc, sans dpendance entre les blocs :
IIR
t
(n) =
F
i=0
b
i
x(tN + n i)
min(n,B)
j=1
a
j
IIR
t
(n j), n {0 . . . N 1} (B.2)
Ce calcul seectue sur un vecteur de taille N. On pose comme condition que N > B. On
cherche montrer :
_
_
IIR(tN + n) = IIR
t
(n)
B
j=1
c
j
(n)IIR(tN j)
c
j
(0) = a
j
c
j
(n) = a
j+n

n
k=1
a
k
c
j
(n k)
n {0 . . . N 1}, t N (B.3)
Pour simplier les notations dans la suite, on dnit a
j
sur {1 . . . N}, en dnissant :
a
j
= 0, j > B (B.4)
B.2 Dmonstration
On cherche donc dmontrer que la formule (B.3) est vraie. On distingue pour cela deux cas
pour la valeur de t.
Dans le premier cas, on a t = 0. La dmonstration est alors triviale.
IIR(n) = IIR
0
(n), n = 0 . . . N 1 (B.5)
99
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
B.2. DMONSTRATION ANNEXE B. PARALLLISATION DUN FILTRE IIR
Dans le deuxime cas, on a t > 0. On utilise une rcurrence sur n.
Le cas initial n = 0 peut se montrer relativement simplement. On a t > 0 et N > B par
hypothse, donc min(tN, B) = B. Si on applique la dnition de IIR
t
et IIR, on obtient :
IIR
t
(0) =
F
i=0
b
i
x(tN i)
IIR(tN) =
F
i=0
b
i
x(tN i)
B
j=1
a
j
IIR(tN j)
= IIR
t
(0)
B
j=1
a
j
IIR(tN j) (B.6)
On suppose maintenant que la relation est vraie pour tous les rangs strictement infrieur n.
On va montrer qualors elle est vraie pour le rang n.
Par dnition de IIR
t
, on peut crire :
IIR
t
(n) =
F
i=0
b
i
x(tN + n i)
min(n,B)
j=1
a
j
IIR
t
(n j)
En utilisant la formule de rcurrence pour tous les points dindice n 1, . . . , n min(n, B), on
obtient :
IIR
t
(n) =
F
i=0
b
i
x(tN + n i)
min(n,B)
j=1
a
j
_
_
IIR(tN + n j) +
B
k=1
c
k
(n j)IIR(tN k)
_
_
(B.7)
On en dduit :
IIR
t
(n) +
min(n,B)
j=1
a
j
B
k=1
c
k
(n j)IIR(tN k) =
F
i=0
b
i
x(tN +n i)
min(n,B)
j=1
a
j
IIR(tN +n j) (B.8)
Par dnition de IIR au point tN + n on a :
IIR(tN + n) =
F
i=0
b
i
x(tN + n i)
min(tN+n,B)
j=1
a
j
IIR(tN + n j)
Comme t 1 et N B, on a min(tN + n, B) = B, do :
IIR(tN + n) =
F
i=0
b
i
x(tN + n i)
B
j=1
a
j
IIR(tN + n j) (B.9)
=
F
i=0
b
i
x(tN + n i)
min(n,B)
j=1
a
j
IIR(tN + n j)
j=min(n,B)+1
a
j
IIR(tN + n j) (B.10)
100
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
ANNEXE B. PARALLLISATION DUN FILTRE IIR B.2. DMONSTRATION
On distingue ici deux cas, n < B et n B.
Dans le premier cas, on a n < B, cest dire min(n, B) = n. On peut donc simplier lquation
(B.10) :
IIR(tN + n) =
F
i=0
b
i
x(tN + n i)
n
j=1
a
j
IIR(tN + n j)
j=n+1
a
j
IIR(tN + n j) (B.11)
En modiant lindice de la deuxime somme, on obtient :
IIR(tN + n) =
F
i=0
b
i
x(tN + n i)
n
j=1
a
j
IIR(tN + n j)
Bn
j=1
a
j+n
IIR(tN j) (B.12)
En injectant (B.8) avec min(n, B) = n, on sabstrait de la dpendance aux IIR pour le t courant :
IIR(tN + n) = IIR
t
(n) +
n
j=1
a
j
B
k=1
c
k
(n j)IIR(tN k)
Bn
j=1
a
j+n
IIR(tN j) (B.13)
On dveloppe et on inverse lordre de la double somme pour obtenir :
IIR(tN + n) = IIR
t
(n) +
B
k=1
n
j=1
a
j
c
k
(n j)IIR(tN k)
Bn
j=1
a
j+n
IIR(tN j) (B.14)
On change les indices j et k de la double somme :
IIR(tN + n) = IIR
t
(n) +
B
j=1
n
k=1
a
k
c
j
(n k)IIR(tN j)
Bn
j=1
a
j+n
IIR(tN j) (B.15)
Daprs (B.4), on a a
j
= 0 pour j > B. On a donc a
j+n
= 0 pour j > B n, do :
IIR(tN + n) = IIR
t
(n)
B
j=1
_
_
a
j+n

n
k=1
a
k
c
j
(n k)
_
_
IIR(tN j) (B.16)
Si on sintresse maintenant au deuxime cas, on a n B, et donc min(n, B) = B. On peut
donc simplier lquation (B.10) :
IIR(tN + n) =
F
i=0
b
i
x(tN + n i)
B
j=1
a
j
IIR(tN + n j)
101
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
B.3. CONCLUSION ANNEXE B. PARALLLISATION DUN FILTRE IIR
On injecte (B.8) avec min(n, B) = B, ce qui donne :
IIR(tN + n) = IIR
t
(n) +
B
j=1
a
j
B
k=1
c
k
(n j)IIR(tN k) (B.17)
On dveloppe, on inverse lordre de la double somme et on change les indices j et k (cf.
(B.14) et (B.15)), ce qui nous donne :
IIR(tN + n) = IIR
t
(n) +
B
j=1
B
k=1
a
k
c
j
(n k)IIR(tN j) (B.18)
On a n > B, donc j + n > Bj N. En utilisant (B.4), on obtient donc que a
j+n
= 0 dans ce
cas. On a donc
a
j+n
a
k
c
j
(n k)IIR(tN j) = a
k
c
j
(n k)IIR(tN j) (B.19)
De mme, en utilisant toujours (B.4), et comme n > B, on a :
B
k=1
a
k
m =
n
k=1
a
k
m (B.20)
En utilisant (B.19) et (B.20) avec (B.18), on obtient :
IIR(tN + n) = IIR
t
(n)
B
j=1
_
_
a
j+n

n
k=1
a
k
c
j
(n k)
_
_
IIR(tN j) (B.21)
On obtient donc, dans les deux cas, une formule de la forme :
IIR(tN + n) = IIR
t
(n)
B
j=1
c
j
(n)IIR(tN j) (B.22)
avec
c
j
(n) = a
j+n

n
k=1
a
k
c
j
(n k) (B.23)
La formule est donc vraie au rang n.
Comme la formule est vraie au rang 0, et quelle est vraie au rang n si elle est vraie pour tout
rang strictement infrieur n, elle est vraie quelque soit n N.
B.3 Conclusion
Cette mthode permet dobtenir un gain pour le calcul dun ltre IIR en utilisant le GPU.
102
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
Annexe C
Prsentation gnrale de linterface de
FRK
C
e chapitre est consacr lAPI de FRK. On donne les structures et les fonctions princi-
pales des direntes fonctions constituant lenvironnement, avec leur eet et leur objectif.
Ce chapitre est organis librairie par librairie, avec une section supplmentaire qui dtaille les
mthodes de monitoring. On ne donne pas ici les implmentations, qui peuvent dpendre de la
plateforme, uniquement les prototypes.
C.1 OPM et communications
C.1.1 Structures
C.1.1.1 Opration
typedef struct frk_op_s frk_op_t;
struct frk_op_s {
unsigned int id;
int num_inputs;
int *minimal_inputs;
frk_op_s *inputs;
int num_outputs;
int *minimal_outputs;
frk_op_s *outputs;
int required_throughput;
rhal_config_t *implem;
};
Une opration est un type gnrique utilis pour reprsenter nimporte quelle opration de
FRK. Elle est constitue de huit lments. Lidentiant id est unique pour chaque type dopration,
dni laide dun enum. De manire gnrale, toutes les structures de FRK ont un identiant. Les
six paramtres suivants permettent de reprsenter le graphe en donnant, pour les entres puis les
sorties, le nombre, la taille minimale des donnes (qui permet dobtenir le ratio entres/sorties
minimal), et les oprations avec lesquels il y a connexion. Lavant-dernier paramtre nest pas
encore rellement utilis, il permet de dnir le dbit minimal requis pour cette opration an de
slectionner une implantation adapte. Le dernier paramtre permet de renseigner limplantation
choisie pour une opration. Il est utilis, entre autres, pour permettre aux applications de haut-
niveau de ne fonctionner quavec les oprations gnriques, sans pour autant perdre le lien avec
limplantation au niveau de la R-HAL. Ce type des oprations gnriques est ensuite tendu an
de permettre une spcialisation, comme pour lopration name.
typedef struct frk_name_s frk_name_t;
struct frk_name_s {
103
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
C.1. OPM ET COMMUNICATIONS ANNEXE C. API FRK
frk_op_t param;
// Parametres specifiques de loperation name
};
C.1.1.2 Waveform
La waveform est lapplication gnrique de FRK. On donne ici sa structure, mme si elle nest
pas ncessairement utilise par le dveloppeur, qui peut utiliser les fonctions proposes. La struc-
ture comporte un numro didentiant comme toutes les structures de FRK. Elle comporte gale-
ment le nombre dlments de la waveform, les lments tant les oprations. Ces lments sont
ensuite donns dans op_list. Ce paramtre reprsente un tableau doprations, mais ces opra-
tions peuvent galement tre adresses comme des listes, puisque lapplication a une structure de
graphe et que le type frk_op_t contient les liaisons entre les direntes oprations.
typedef struct frk_wf_s frk_wf_t;
struct frk_wf_s {
unsigned int wid;
unsigned int num_elements;
frk_op_t *op_list;
frk_ci_t *implem;
};
C.1.1.3 CI
La traduction de la waveform permet dobtenir la reprsentation de lapplication au niveau
R-HAL. Cette reprsentation sappelle la CI. La structure de la CI est similaire la structure de la
waveform quelques dtails prs :
on ne travaille pas sur des oprations mais sur des rhal_config_t, qui correspondent aux
oprations de la R-HAL;
les oprations sont direncies en fonction de la cible qui va les excuter ;
les entres et sorties sont marques, elles sont tout de mme enregistres dans la liste globale
mais on a besoin de pouvoir y accder rapidement ;
les canaux de transferts de donnes sont explicites, sous la forme dune liste de canaux ;
la structure de graphe est perdue (en fait, elle peut se retrouver en utilisant le pointeur sur
lopration gnrique associe).
typedef struct frk_ci_s frk_ci_t;
struct frk_ci_s {
unsigned int id;
unsigned char loaded; /* boolean */
unsigned char active; /* boolean */
rhal_config_t *source_lists;
rhal_config_t *sink_lists;
rhal_config_t *config_lists[PLATFORM_NUM_TARGETS];
rhal_channel_t *comm_list;
frk_wf_t *waveform;
};
104
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
ANNEXE C. API FRK C.2. INTERFACE R-HAL
C.1.2 Fonctions
C.1.2.1 Oprations
Les premires fonctions de lOPM sont les fonctions de gestion des oprations. Elles permet-
tent, entre autres, dinitialiser (et de nettoyer) ces dernires. Elles ont les prototypes suivants :
int init_name(frk_name_t *operation);
int clean_name(frk_name_t *operation);
Linitialisation permet de gnrer certains paramtres comme lID, que lon veut masquer
par simplicit lutilisateur. Les paramtres spciques de lopration sont mettre en place par
lutilisateur.
C.1.2.2 Cration de la waveform
An de crer la waveform partir des oprations proposes, on fournit tout dabord une fonc-
tion de connection des oprations, qui permet de construire les arrtes du graphe. Cette fonction
est la mme que la fonction connect de GNURadio. On donne le prototype dans FRK.
int connect (frk_op_t *source, int input_id , frk_opt_t *sink, int
output_id);
On ore galement des fonctions de gnration de waveform, qui permettent dinitialiser la
structure (gnration dun identiant unique, allocation des structures, . . . ), et dajouter les opra-
tions la waveform.
int init_waveform(frk_wf_t *waveform, int num_ops);
int add_op(frk_op_t *operation , frk_wf_t *waveform);
C.1.2.3 Traduction
Finalement, deux fonctions de traduction sont fournies qui permettent pour lune de gnrer
compltement une CI partir dune waveform, pour lautre de modier une opration.
int translate(frk_wf_t *waveform, rhal_config_t *ci);
int update(frk_wf_t *waveform, frk_op_t *operation);
La fonction update pour les modications ponctuelles permet en fait de prendre en compte
des modications dj eectues. Lopration doit tre prsente dans la waveform. Une fonction
de remplacement dune opration par une autre existe.
int replace(frk_wf_t *waveform, frk_op_t *old, frk_op_t *new);
C.2 Interface R-HAL
La R-HAL permet dabstraire les units dexcution qui vont tre utilises. Elle dnit en
particulier les fonctions qui seront utilisables par les couches suprieures, linterface avec lOPM,
ainsi que certaines fonctions pour les TaME.
105
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
C.2. INTERFACE R-HAL ANNEXE C. API FRK
C.2.1 Structures
C.2.1.1 Transferts de donnes
Contrairement lOPM qui dnit les oprations gnriques, la R-HAL ajoute de manire
explicite les transferts de donnes. Ces transferts ne sont pas implants au niveau de linterface,
mais au niveau du TaME. Cependant, an de permettre linteraction entre les direntes cibles,
une structure gnrique de transferts de donnes, contenant principalement lensemble des fonc-
tions permettant dagir sur le transfert ainsi quun identiant. On donne galement un lien avec
la cible qui sera responsable des transferts. Ce lien nest pas forcment ncessaire, mais permet
de simplier la gestion des applications au niveau de linterface. La structure rhal_channel_t
est un hritage des premires versions de FRK, et nest plus rellement ncessaire. Lobjectif de
cette structure tait lorigine de permettre une abstraction du canal de communication, quand
elle ntait pas ncessairement gre par la cible, pour les FIFO gnriques. Cependant, dans les
nouvelles interfaces, tame_channel_t est dja une abstraction du canal, qui est ensuite tendue
en fonction de la cible. Elle est voue disparatre, an dtre remplace par une version tendue
de tame_channel_t. Un ajout dune cible gnrique est en eet au programme, pour mutualiser
certaines oprations.
typdef struct rhal_channel_s rhal_channel_t;
struct rhal_channel_s {
unsigned int id;
unsigned int target_id_source;
unsigned int target_id_sink;
unsigned int width;
tame_channel_t *channel;
int (*read) (tame_channel_t , void *, int);
int (*write) (tame_channel_t , void *, int);
int (*deactivate) (tame_channel_t);
int (*activate) (tame_channel_t);
}
Les quatre fonctions ne sont pas les seules fonctions pour grer une FIFO. Cependant, ce sont
les seules dont lopration qui va les utiliser peut avoir besoin. On dnit le type tame_channel_t
dans la section C.3. Les fonctions read et write sont les fonctions qui permettent de lire et crire
dans la FIFO. Cette lecture (resp. criture) se fait dans (resp. depuis) le buer dnit comme
second argument des fonctions. La taille du transfert est dnie par le troisime argument. La
largeur width de ce transfert est xe pour un transfert. Elle est de toute manire rappele dans
tame_channel_t.
On notera que cette structure va se retrouver dans deux oprations direntes. Il y a donc
ncessit de protger correctement lappel aux direntes fonctions. Ceci est fait au niveau du
TaME.
C.2.1.2 Oprations
La R-HAL dnit galement limplantation sur cible.
typedef struct rhal_config_s rhal_config_t;
struct rhal_config_s {
unsigned int cid;
unsigned int target_id;
unsigned char state; /* Charge ou non ? */
unsigned char active; /* Active ou non ? */
106
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
ANNEXE C. API FRK C.3. TAME
frk_op_t *operation;
frk_ci_t *ci;
/* I/O */
rhal_channel_t *inputs;
rhal_channel_t *outputs;
}
Au mme titre que lopration gnrique dnie dans lOPM, cette implantation est gnrique
pour toutes les cibles. Elle est tendue par chaque cible an de prendre en compte dventuelles
arguments supplmentaires. On donne dans les oprations R-HAL un rappel de lopration
gnrique operation, ainsi que lidentiant de la cible de cette opration. Ceci permet de faire
appel aux fonctions du TaME associ lopration. On ne rappelle pas dans cette structure le
nombre dentres et de sorties pour lopration, puisquil est dni dans lopration gnrique.
C.2.2 Fonctions
int load_ci (frk_ci_t *);
int unload_ci (frk_ci_t *);
int activate_ci (frk_ci_t *);
int deactivate_ci (frk_ci_t *);
int get_info (unsigned int info_code , unsigned int *info_size , void **
info);
int set_prioritarty(frk_ci_t *);
int set_daemon(frk_ci_t *);
Les fonctions implantes dans la R-HAL sont des fonctions lies la gestion de la CI. Chacune
de ces fonctions excute des lments propres la R-HAL, avant dappeler les fonctions corre-
spondantes pour les cibles de la plateforme. Tout dabord, les fonctions de chargement load_ci
et dchargement unload_ci dapplications. Ces fonctions permettent de charger les direntes
oprations en appelant les fonctions des cibles associes, et dinitialiser les les associes. Les
fonctions dactivation activate_ci et de dsactivation deactivate_ci permettent, comme leur
nom lindique, dactiver et de dsactiver une CI. La fonction update a dj t dnie, elle sim-
plante en fait au niveau de la R-HAL Une fonction de rcupration dinformation get_info per-
met de rcuprer certaines informations prdnies, en fonction du code de linformation requise
info_code. La taille de la rponse est donne dans info_size, et la rponse elle mme est donne
dans info. Finalement, deux fonctions permettent de modier le type de la CI, savoir la rendre
prioritaire (set_prioritary) ou dmon (set_daemon).
C.3 TaME
On donne dans cette section les structures utiliser et les fonctions implanter pour intgrer
une nouvelle cible dans FRK. Les extensions de la HAL sont propres chaque cible, et il ny a
pas dinterface dnie pour cette partie. Seule le TaME sera utilis par les couches suprieures,
et elle devra tre implant pour chaque cible. On notera cependant que mme si pour chaque
plateforme, on dnit une nouvelle cible, beaucoup dlments peuvent tre rutiliss. Ceci est
particulirement vrai pour la cible des acclrateurs matriels.
107
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
C.3. TAME ANNEXE C. API FRK
C.3.1 Structures
C.3.1.1 Structure dun TaME
La structure principale de TaME est sa propre reprsentation. En eet, une instance de FRK
pouvant contenir plusieurs TaME, pour garder une certaine gnricit, il est ncessaire dencap-
suler la description dune cible dans une structure.
typdef struct frk_tame_s frk_tame_t;
struct frk_tame_s {
unsigned int id;
/* Infos etat */
unsigned char state; /* Utilisable ou non */
/* Fonctions CI*/
int (*register_ci) (frk_ci_t *);
int (*unregister_ci) (frk_ci_t *);
int (*activate_ci) (frk_ci_t *);
int (*deactivate_ci) (frk_ci_t *);
int (*set_prioritary) (frk_ci_t *);
int (*set_daemon) (frk_ci_t *);
/* Fonctions operations*/
int (*init_config) (rhal_config_t *);
int (*load_config) (rhal_config_t *);
int (*unload_config) (rhal_config_t *);
int (*activate_config) (rhal_config_t *);
int (*deactivate_config) (rhal_config_t *);
int (*set_priority) (rhal_config_t *, int);
int (*set_mode) (rhal_config_t *, int);
int (*get_state) (rhal_config_t *, unsigned char *state);
/* Gestion des transferts de donnees */
int (*register_channel) (rhal_channel_t *, rhal_config_t *);
int (*unregister_channel) (rhal_channel_t *);
};
C.3.1.2 Oprations
Dans les structures accessibles de la TaME, on trouve principalement la structure dune opra-
tion pour cette cible. Dans les faits, cette structure peut galement tre tendue. Lexemple de
la cible des acclrateurs matriels, dans laquelle plusieurs acclrateurs peuvent tre regroups
malgr le fait quils aient une interface dirente, est caractristique, on donne donc les instances
pour ce TaME et pour le codeur convolutif prsent dans le chapitre 5. Ce codeur ne ncessite
pas rellement dextension. On donne ici la reprsentation dun acclrateur dans le TaME, et la
reprsentation dune opration pour ce TaME.
typedef struct coder_magnet_config_s coder_magnet_config_t;
typedef struct coder_magnet_device_s coder_magnet_device_t;
struct magnet_config_s {
rhal_config_t gen;
unsigned int device_id; /* Cible de la configuration */
unsigned char state; /* Actif ou non */
unsigned char loaded; /* charge ou non */
unsigned char candidate;
unsigned char executable;
108
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
ANNEXE C. API FRK C.3. TAME
unsigned int num_constant;
unsigned int num_volatile;
unsigned int *constant_val;
unsigned int *volatile_val;
};
struct magnet_device_s {
unsigned int device_id;
unsigned char state; /* Actif ou non */
magnet_config_t *running;
unsigned int *base_address;
unsigned int num_constant;
unsigned int num_volatile;
unsigned int **constant_addr;
unsigned int **volatile_addr;
};
La reprsentation de lacclrateur est donne titre indicatif, puisquelle nest pas ncessaire
pour lutilisateur. Cette reprsentation est propre la plateforme.
La structure pour les transferts de donnes contient galement lintgralit des fonctions req-
uises. Ces fonctions sont dcrites plus prcisment dans la partie adquate.
Comme nous lavons voqu en prsentant rhal_channel_t, la structure des First In First
Out (FIFO) est amene changer, cause de son manque de cohrence. Il y a donc beaucoup de
points communs. Chaque FIFO a un id unique, et dnit sa largeur (taille dun lment) et sa pro-
fondeur (nombre dlments). Quatre fonctions sont renseignes lors de la connexion de la FIFO
aux lments qui vont lutiliser. Les fonctions deactivate_prod et activate_prod sont utilises
pour dsactiver et activer lopration qui crit dans la FIFO. Comme les mthodes dactivation et
de dsactivation des lments sont propres chaque cible, il est ncessaire de dnir ces fonc-
tions dans la structure accessible par les fonctions read et write. Le fonctions activate_cons et
deactivate_cond sont utilises pour lopration qui lit la FIFO.
La structure tame_channel_s est commune tous les TaME. Elle peut cependant tre tendue
pour les besoins spciques de certaines cibles, comme par exemple les coprocesseurs qui ont
besoin des seuils.
struct tame_channel_s {
int id;
int width;
int depth;
rhal_channel_t *gen;
int (*deactivate_prod)();
int (*activate_prod)();
int (*deactivate_cons)();
int (*activate_cons)();
/* Fonctions de la FIFO */
int read(tame_channel_t *fifo, void *buffer, int size);
int write(tame_channel_t *fifo, void *buffer, int size);
int purge(tame_channel_t *fifo);
int create(tame_channel_t **fifo); //fifo non allouee
int activate(tame_channel_t *fifo);
int deactivate(tame_channel_t *fifo);
int register_fifo(tame_channel_t *fifo);
109
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
C.3. TAME ANNEXE C. API FRK
};
struct magnet_channel_s {
tame_channel_t channel;
int min_threshold;
int med_threshold;
int max_threshold;
}
C.3.2 Fonctions
Les fonctions du TaME sont toutes reprsentes dans la structure descriptive frk_tame_t. On
dcrit plus prcisment leurs eets ici.
C.3.2.1 CI
An de permettre la gestion de la CI dans son ensemble, les TaME doivent implanter quatre
fonctions. register_ci sert enregistrer une CI au niveau du TaME. Ceci permet dinitialiser par
exemple le verrou associ la CI pour la cible logicielle. Lenregistrement de la CI ne charge pas
les oprations. unregister_ci permet de librer lespace pris par la CI dans la cible. Les fonctions
activate_ci et deactivate_ci servent activer ou dsactiver la CI (en prenant le verrou pour la
cible logicielle). Les fonctions set_prioritary et set_daemon sont redondantes avec la fonction
set_priority des oprations, et servent marquer dun coup une CI comme prioritaire.
C.3.2.2 Oprations
Les fonctions lies aux oprations sont utilises par la R-HAL pour rpercuter les actions sur
les cibles. La fonction init_config permet, comme son nom lindique, dinitialiser une congura-
tion pour la cible. Cette fonction nest utilise que pour des tests, linitialisation de la conguration
tant gr dans lOPM.
Les fonctions load_config et unload_config permettent dajouter une conguration (ou de
la retirer) dans la liste des oprations traiter par le TaME. Les fonctions activate_config et
deactivate_config ne sappliquent que sur une opration charge. Elles permettent de la rendre
excutable ou non excutable sur la cible, suite par exemple la dsactivation dune CI.
Les trois dernires fonctions lies aux oprations servent modier certains paramtres des
oprations. set_priority nest pas encore implante, mais sera utiliser pour grer une priorit
par CI dans FRK. set_mode permet de faire passer une opration en mode prioritaire ou en mode
dmon. get_state est la seule fonction de monitoring passif implante pour linstant, dautres
suivront en fonction des besoins lors du dveloppement de la PL. FRK propose galement un
mcanisme de monitoring actif, dtaill dans la section C.4.
Finalement, les dernires fonctions prsentes ici sont les fonctions lies au transfert de don-
nes. Pour chaque type de FIFO implantes, les fonctions prsentes dans la suite doivent tre
implantes, lexception de register. On notera que limplantation peut ne rien faire si elle ne
prsente pas dintrt pour le cas prsent. Les fonctions de synchronisation dont nous avons dis-
cut au chapitre 5, utilises pour les FIFO gnriques, sont en fait une instanciation des fonctions
ci-aprs. Chaque cible implante donc au minimum les fonctions pour les FIFO gnriques, et
ajoutent ensuite autant dimplantation quelle le souhaite.
110
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
ANNEXE C. API FRK C.4. MONITORING
int read(tame_channel_t *fifo, void *buffer, int size);
int write(tame_channel_t *fifo, void *buffer, int size);
int purge(tame_channel_t *fifo);
int create(tame_channel_t **fifo); //fifo non allouee
int activate(tame_channel_t *fifo);
int deactivate(tame_channel_t *fifo);
int register_fifo(tame_channel_t *fifo);
Les premires fonctions sont explicites. purge permet de vider une FIFO pour des raisons de
"maintenance", quand il y a saturation. create est utilise lors de linitialisation des canaux, au
chargement. activate et deactivate permet de dbloquer ou de bloquer une FIFO. Ceci est utile
quand on veut empcher une opration dtre approvisionn en donner. Cest une mthode pour
dsactiver un coprocesseur matriel, par exemple, si celui-ci na pas de support pour la dsactiva-
tion ;
register_fifo est plus complexe. Elle est optionnelle, et est utilise si besoin lors de lappel
aux fonctions gnrales denregistrement des FIFO dnies dans la TaME.
int register_channel(rhal_channel_t *fifo, rhal_config_t *source,
rhal_config_t *sink);
int unregister_channel(rhal_channel_t *fifo);
Quand lenregistrement requiert une action au niveau de la FIFO, la fonction register_fifo
permet deectuer cette action. Les fonctions register_channel et unregister_channel perme-
ttent denregister une FIFO au niveau dune cible, en prcisant quelle opration sera productrice
(source), et quelle opration sera consommatrice (sink). Elles sont utilises lors du chargement
dune CI.
C.4 Monitoring
On nit ce chapitre prsentant lAPI par une prsentation rapide du principe du monitoring
dans FRK. Implanter le monitoring dans FRK nest pas vident, du fait de la construction sous
forme de librairie de lenvironnement.
Cet aspect de FRK nest pas encore extrmement dvelopp, mais il est bas sur le principe
de handlers fournis par les fonctions appelantes. FRK ore lextrieur une structure permet-
tant denregistrer un certain nombre de fonctions. Ces fonctions sont enregistres pour tre ap-
peles des moments prcis de lexcution. En ltat actuel de lenvironnement, trois points sont
disponibles. Dautres seront mis disposition au fur et mesure des besoins. On ne peut pour
linstant quenregistrer une fonction par condition.
struct frk_mon_s {
int (*saturation)();
int (*read_alert)();
rhal_channel_t *read_pointer;
int (*switch)();
};
Elles sont dnies sans paramtres pour linstant. La premire est appele ds quil y a satu-
ration dans FRK. On dnit par saturation le non-respect du dbit attendu. Dans ltat actuel de
FRK, les notions de temps ntant pas encore mises en place, la saturation correspond la perte de
donnes dans un lment non contrlable. Si une opration lit ses donnes dans une FIFO remplie
111
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
C.5. RSUM ET CONCLUSION ANNEXE C. API FRK
par une entre du systme que lon ne peut pas arrter, et que cette opration ne suit pas la cadence,
il y a saturation.
La seconde est appele ds quune lecture est faite dans la FIFO read_pointer. La dernire
permet de signaler quune commutation a eu lieu dans une cible matrielle.
C.5 Rsum et conclusion
On rsume la dnition des structures et des fonctions sous la forme du diagramme de classe
propos en gure C.1. Les fonctions ne sont pas reprsentes sur ce diagramme.
Figure C.1 Diagramme de classe des structures de FRK
LAPI de FRK dans sa version actuelle a t prsent dans ce chapitre. Cette API est fonction-
nelle, mais est amene voluer au fur et mesure des volutions de lenvironnement. Lide direc-
trice de rpartition en cibles et en couches restera cependant. Dautres fonctions sont disponibles
dans FRK, pour du test et du dveloppement, mais ne sont pas prsentes ici.
112
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
Annexe D
Intgration de matriel ddi dans FRK
D.1 Utilisation de MAGNET
On prsente ici une utilisation dtourne de FRK pour le contrle de matriel ddi. LOPM
permet en eet de rajouter des oprations spciques une plateforme, pas ncessairement porta-
bles sur dautres plateformes. Ces oprations sont typiquement des chanes de communication non
normalises, mais compltes. On prsente ici lintgration dune chane de communication utilise
pour un PAN haut dbit, et le contrle dun protocole de retransmission associ. Le PAN utilis
est issu du projet europen MAGNET On trouvera dans [Pra10] des informations sur lapplication
radio associe.
D.1.1 Plateforme MAGNET
La chane de communication de MAGNET est implante en matriel. Dun point de vue
pratique, elle est actuellement dploye sur le FPGA de la plateforme base sur le Atmel
AT91RM9200 prsente au chapitre 5, dans la gure 5.13. Lapplication MAGNET est base
sur une modulation Orthogonal Frequency Division Multiplexing (OFDM). Elle permet de faire
varier le dbit, en jouant en particulier sur la modulation utilise (Quadrature Phase Shift Key-
ing (QPSK), 16-Quadrature Amplitude Modulation (QAM), 64-QAM). Le 64-QAM est prvu,
mais dicilement fonctionnel. Un codage canal est galement utilis. Cest un code convolutif
trois additionneurs. Le code en lui-mme est xe, cependant, il est poinonnable an dautoriser
une modication du rendement (et donc du dbit). Ct rception, on utilise des soft-bits et un
dcodeur Viterbi.
D.1.2 Reprsentation
Limplantation matrielle de MAGNET est un priphrique, du point de vue du processeur.
Ce priphrique est branch sur le bus des extensions du systme AT91. Deux intgrations du
composant dans le noyau Linux du composant sont disponibles, sans FRKUne premire version de
dmonstration rside dans lespace utilisateur. Elle mappe les adresses du composant directement
dans lespace adressable. Ces adresses sutilisent ensuite comme des pointeurs de base. Ce mode
de fonctionnement se fait ncessairement en utilisant la scrutation (polling) pour vrier ltat du
composant. Une deuxime version utilise linterface device du noyau, et permet lutilisation des
interruptions. Cette intgration se fait donc dans lespace noyau.
Le priphrique MAGNET est un composant ddi, qui ne peut raliser que le protocole MAG-
NET. Il est intgr dans FRK en tant que priphrique ddi. Plus particulirement, il est intgr
en tant que deux acclrateurs ddis, lun pour lmission, lautre pour la rception. Ces deux
acclrateurs sont respectivement vus comme une entre et une sortie.
Au niveau de lOPM, on rajoute donc une opration ddie implantable uniquement sur la
cible MAGNET. Les oprations ddies ont par convention dans FRK un identiant "ngatif".
Lidentiant tant strictement positif, lidentiant ngatif est en fait un identiant dont le premier
bit est un 1. On donne la cration de lopration dmission, avec seulement certains paramtres.
Plus de paramtres sont disponibles dans lopration relle, mais napportent pas grand chose la
113
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
D.1. UTILISATION DE MAGNET ANNEXE D. MATRIEL DDI
comprhension du mcanisme. On donne dans cette section quelques lments reprsentatifs de
limplantation.
struct frk_magnettx_s {
frk_op_t param;
unsigned short interframe;
unsigned short packet_size;
unsigned char rate; /* base sur un enum */
}
init_magnettx(frk_op_t *op) {
op->id = (unsigned_int)MAGNET_TX_ID;
op->num_inputs = 1;
op->num_outputs = 0;
op->min_val_in = 2;
op->min_val_out = 0;
op->required_throughput = 0;
}
Lintgration du composant dans FRK utilise les interruptions, et se fait donc partiellement
dans lespace noyau. On cre donc un module spcique dans le noyau pour le contrle du com-
posant MAGNET. Ce module correspond aux extensions HAL. On dnit plusieurs choses dans
ce module.
Tout dabord, on donne la structure du composant, sous la forme constantes/volatiles dnie au
chapitre 5. Limplantation de lopration se base sur cette structure. On donne galement limplan-
tation des FIFO pour cette cible. Dans le cas de MAGNET, une FIFO matrielle est disponible
1
.
struct magnettx_channel_s {
tame_channel_t fifo;
unsigned short *magnet_fifo_tx;
unsigned short *more_buffer;
int read_idx; /* indice pour more_buffer */
int write_idx;
int used; /* Remplissage de more_buffer*/
}
create_magnettx_channel(tame_channel_t *fifo)
{
magnettx_channel_t *ext_fifo = (magnettx_channel_t *)fifo;
fifo->id = get_channel_id();
fifo->width = 2;
fifo->depth = MAGNET_FIFO_SIZE + ADDITIONNAL_MAGNET_SIZE;
ext_fifo ->magnet_fifo_tx = (unsigned short *)MAGNET_TX_FIFO_ADDR;
ext_fifo ->more_buffer = kmalloc((ADDITIONNAL_MAGNET_SIZE) * sizeof(
unsigned short), GFP_KERNEL);
}
Il ny a pas de lecture dans la FIFO dmission, le composant qui va lire est en eet le com-
posant matriel, et la lecture nest pas contrlable. On prsente donc limplantation de la fonction
write. Cette fonction se base sur de la scrutation pour dtecter si la FIFO matrielle est pleine ou
non. An daugmenter la taille de stockage disponible, on utilise le buer logiciel more_buffer.
A chaque appel write, on synchronise les deux lments. On synchronise galement quand le
1. il y a en fait deux FIFO, une pour lmission, et une pour la rception, mais on ne sintresse ici qu lmission
114
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
ANNEXE D. MATRIEL DDI D.1. UTILISATION DE MAGNET
ag almost_empty de la FIFO matrielle se lve. Ce ag gnre une interruption qui lance la syn-
chronisation. Lors de lappel write, la premire action est donc de dsactiver cette interruption,
pour viter la concurrence. Il ny a pas de priphriques DMA disponibles avec le composant
MAGNET, la copie se fait donc explicitement.
int write(tame_channel_t *fifo, void *buffer, int size)
{
magnettx_channel_t *ext_fifo = (magnettx_channel_t *)fifo;
unsigned int buffer_idx = 0;
unsigned short *ext_buffer = (unsigned short *)buffer;
disable_txfifo_interrupts();
/* Synchronisation more_buffer/composant */
if (!magnet_fifo_tx_full()) {
while(!magnet_fifo_tx_full() && (ext_fifo ->used != 0)) {
*(ext_fifo ->maget_fifo_tx) = ext_fifo ->more_buffer[ext_fifo
->read_idx];
ext_fifo ->read_idx+=1;
if (ext_fifo->read_idx >= ADDITIONNAL_MAGNET_SIZE) {
ext_fifo ->read_idx = 0;
}
ext_fifo ->used -=1;
}
/* Inutile dactiver ici, on ne peut pas etre desactive */
}
/* Synchronisation termine, debut de lecriture de buffer */
while (!magnet_fifo_tx_full() && (buffer_idx < size)) {
*(ext_fifo ->magnet_fifo_tx) = ext_buffer[buffer_idx];
buffer_idx++;
}
while (buffer_idx < size) {
if (ext_fifo->used < (ADDITIONNAL_MAGNET_SIZE - 1)) {
ext_fifo ->more_buffer[ext_fifo ->write_idx] = ext_buffer[
buffer_idx];
buffer_idx ++;
ext_fifo ->write_idx++;
if (ext_fifo->write_idx == ADDITIONNAL_MAGNET_SIZE) {
ext_fifo ->write_idx = 0;
}
used++;
} else {
enable_txfifo_interrupts();
magnet_schedule(MAGNETTX_ID);
fifo->deactivate_prod();
disable_txfifo_interrupts();
}
}
if ((used + MAGNET_FIFO_SIZE) > tame_fifo ->med_threshold) {
magnet_schedule(MAGNETTX_ID);
}
enable_txfifo_interrupts();
}
Si il ny a plus de place pour crire, la FIFO dsactive lappelant en utilisant la fonction
115
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
D.2. CONCLUSION ANNEXE D. MATRIEL DDI
renseigne linitialisation. La fonction de synchronisation appele en cas dinterruption active
automatiquement lappelant, puisquelle libre de lespace. De mme, quand le seuil moyen est
atteint, on appelle lordonnanceur, qui va vrier si il est ncessaire de modier la conguration
du composant. MAGNETTX_ID est lidentiant du composant dmission dans la cible.
D.2 Conclusion
Nous avons montr dans ce chapitre quelques lments de lintgration dun acclrateur sp-
cialis dans FRK. Cet acclrateur permet dexcuter toute la chane de communication de MAG-
NET.
116
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
Publications
Nous donnons ici la liste des direntes communications ayant t ralises durant cette thse.
Confrences internationales
Damien Hedde, Pierre-Henri Horrein, Frdric Ptrot, Robin Rolland et Franck Rousseau,
"A MPSoC Prototyping Platform for Flexible Radio Applications", Digital System Design
Conference (DSD), Patras, Grce, Aot 2009
Pierre-Henri Horrein, Christine Hennebert et Frdric Ptrot, "A Flexible Buerless H-ARQ
Processor Based on Dataow Scheduling", 1
st
International Conference on Advances on Cogni-
tive Radio (COCORA), Budapest, Hongrie, Avril 2011
Pierre-Henri Horrein, Christine Hennebert et Frdric Ptrot, "Adapting a SDR environment
to GPU architectures", Wireless Innovation Forum Conference (WinnComm), Bruxelles, Bel-
gique, Juin 2011
Pierre-Henri Horrein, Christine Hennebert et Frdric Ptrot, "An Environment for
(re)conguration and Execution Management of Flexible Radio Platforms", Digital System
Design Conference (DSD), Oulu, Finlande, Septembre 2011
Articles de journal
Pierre-Henri Horrein, Christine Hennebert et Frdric Ptrot, "Integration of GPU computing in
an Software Radio environment", Springer Journal of Signal Processing Systems, accept
Pierre-Henri Horrein, Christine Hennebert et Frdric Ptrot, "An Environment for
(re)conguration and Execution Management of Heterogeneous Flexible Radio Platforms",
Elsevier MICPRO, conditionnellement accept
Brevet
1 brevet en cours de dpt par Florian Pebay-Peyroula et Pierre-Henri Horrein.
Poster
Pierre-Henri Horrein, Christine Hennebert et Frdric Ptrot, "Designing software radio applica-
tions for GPU parallel architecture", DEPCP (DATE Friday Workshop), Grenoble, France, Mars
2011
117
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
PUBLICATIONS PUBLICATIONS
118
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
Bibliographie
[Abd10] Riadh Ben Abdallah. Machine Virtuelle pour la Radio Logicielle. PhD thesis, INSA
Lyon, 2010.
[Alh10] Laurent Alhaus. Architecture Recongurable pour un quipement Radio Multistan-
dard. PhD thesis, Universit de Rennes 1, 2010.
[alo] ALOE Middleware - FlexNets. http://flexnets.upc.edu/trac, visit le
07/07/2011.
[ANJ
+
04] D. Andrews, D. Niehaus, R. Jidin, M. Finley, W. Peck, M. Frisbie, J. Ortiz, Ed Komp,
and P. Ashenden. Programming Models for Hybrid FPGA-CPUComputational Com-
ponents : A Missing Link. Micro, IEEE, 24(4) :42 53, jul. 2004.
[APR
+
11] L. Alaus, J. Palicot, C. Roland, Y. Louet, and D. Noguet. Promising technique of
parameterization for recongurable radio, the common operators technique : Funda-
mentals and examples. Journal of Signal Processing Systems, 62 :173185, 2011.
10.1007/s11265-009-0353-4.
[arc11] [Discuss-gnuradio] GNURadio and CUDA reprised. http://lists.gnu.
org/archive/html/discuss-gnuradio/2011-01/msg00220.html visit le
05/07/2011, January 2011.
[ARFD09] Riadh Ben Abdallah, Tanguy Risset, Antoine Fraboulet, and Yves Durand. The radio
virtual machine : A solution for sdr portability and platform recongurability. In
IEEE International Symposium on Parallel Distributed Processing, 2009, may 2009.
[ARFM10] Riadh Ben Abdallah, Tanguy Risset, Antoine Fraboulet, and Jrme Martin. Virtual
machine for software dened radio : Evaluating the software vm approach. In IEEE
International Conference on Computer and Information Technology 2010, CIT 2010,
2010.
[arm] Mali T604 - ARM. http://www.arm.com/products/multimedia/
mali-graphics-hardware/mali-t604.php Visit le 17/08/2011.
[ARM05] ARM. ARM1136JF-S and ARM1136J-S Technical Reference Manual, 2005.
[ASM
+
07] K. Amiri, Y. Sun, P. Murphy, C. Hunter, J. R.Cavallaro, and A. Sabharwal. WARP,
a Unied Wireless Network Testbed for Education and Research. In Proceedings of
IEEE MSE, 2007.
[bea] OpenCL Fast Fourier Transform. http://www.bealto.com/gpu-fft.html Visit
le 08/08/2011.
[bea10] BeagleBoard-xM Rev C System Reference Manual, april 2010.
[BZZ08] Steve Bernier and Juan Pablo Zamora Zapata. The deployment of software com-
ponents into heterogeneous SCA platforms. In SDR 08 Technical Conference and
Product Exposition, 2008.
[CAL] CALIT2. Calradio. http://calradio.calit2.net/index.htm, visited on
30/06/2011.
[CDPR10] Andrew R Cormier, Carl B Dietrich, Jeremy Price, and Jerey H Reed. Dynamic
reconguration of software dened radios using standard architectures. Physical
Communication, 3(2) :7380, 2010.
[cog] Cogeu. http://www.ict-cogeu.eu/ Visit le 11/07/2011.
119
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
BIBLIOGRAPHIE BIBLIOGRAPHIE
[Cor08] Andrew R. Cormier. Recongurable SCA System Development Using Encapsulated
Waveform Applications and Components. Masters thesis, Virginia Polytechnic In-
stitute and State University, 2008.
[DBRC05] Maxime Dumas, Louis Blanger, Sbastien Roy, and Jean-Yves Chouinard. Devel-
opment of a SCA 3.1 compliant W-CDMA waveform on DSP/FPGA specialized
hardware. In SDR 05 Technical Conference and Product exposition, 2005.
[DDL10] Mickael L. Dickens, Brian P. Dunn, and J. Nicholas Laneman. Thresholding for
Optimal Data Processing in a Software Dened Radio Kernel. In Proceedings of the
Karlsruhe Workshop on Software Radios (WSR), March 2010.
[Dic] Mickael L. Dickens. Conversation personnelle, juin et septembre 2011, article
venir.
[DLD11] Mickael L. Dickens, J. Nicholas Laneman, and Brian P. Dunn. Seamless Dynamic
Runtime Reconguration in a Software-Dened-Radio. In Proceedings of SDR11-
WinnComm-Europe, June 2011.
[DMLP05] Jean-Philippe Delahaye, Christophe Moy, Pierre Leray, and Jacques Palicot. Man-
aging dynamic partial reconguration on heterogeneous SDR platforms. In SDR 05
Technical Conference and Product exposition, 2005.
[DPML07] J.-P. Delahaye, J. Palicot, C. Moy, and P. Leray. Partial Reconguration of FPGAs
for Dynamical Reconguration of a Software Radio Platform. Mobile and Wireless
Communications Summit, 2007. 16th IST, pages 15, July 2007.
[DZD
+
05] Ioannis Dagres, Andreas Zalonis, Nikos Dimitriou, Konstantinos Nikitopoulos, and
Andreas Polydoros. Flexible Radio : A Framework for Optimized Multimodal Op-
eration via Dynamic Signal Design. EURASIP Journal on Wireless Communications
and Networking, 3 :284297, 2005.
[fIT03] IEEE Standard for Information Technology. 1003.26 - Portable Operating System
Interface (POSIX) - Part 26 : Device Control Application Interface (API) [C Lan-
guage], 2003.
[GC97] Andrea J. Goldsmith and Soon-Ghee Chua. Variable-Rate Variable-Power MQAM
for Fading Channels. IEEE Transactions on Communications, Vol. 45, October 1997.
[GMBG10] Ismael Gomez, Vuk Marojevic, Jordi Bracke, and Antoni Gelonch. Performance
and Overhead Analysis of the ALOE Middleware for SDR. In The 2010 Military
Communications Conference. IEEE, 2010.
[GMSG08] Ismael Gomez, Vuk Marojevic, Jose Salazar, and Antoni Gelonch. A Lightweigh
Operating Environment for Next Generation Cognitive Radios. In 11th Euromicro
Conference on Digital System Design Architectures, Methods and Tools, 2008.
[gnua] Beagle Board SDR. www.opensdr.com/node/10, visit le 05/07/2011.
[gnub] GNU Radio. http://gnuradio.org.
[Gue10] Xavier Guerin. Approche ecace de dveloppement de logiciel embarqu pour des
systmes multiprocesseurs sur puces. PhD thesis, Institut National Polytechnique de
Grenoble, 2010.
[HCS11] Ke He, Louise Crockett, and Robert Stewart. Dynamic Reconguration Technolo-
gies Based on FPGA in Software Dened Radio System. In Proceedings of SDR11-
WinnComm-Europe, June 2011.
[HHP
+
09] D. Hedde, P.-H. Horrein, F. Petrot, R. Rolland, and F. Rousseau. A MPSoC Proto-
typing Platform for Flexible Radio Applications. In Digital System Design, Architec-
tures, Methods and Tools, 2009. DSD 09. 12th Euromicro Conference on, pages 559
566, 27-29 2009.
120
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
[HPA01] Denis Hommais, Frdric Ptrot, and Ivan Aug. A practical tool box for system
level communication synthesis. In CODES, pages 4853, 2001.
[HSM
+
08] George Harrison, Ambrose Sloan, Wilbur Myrick, Joe Hecker, and David Eastin.
Polyphase Channelization utilizing General-Purpose computing on a GPU. In SDR
2008 Technical Conference and Product Exposition, 2008.
[JCS11] Hyunwoo Ju, Junho Cho, and Wonyong Sung. Memory Access Optimized Imple-
mentation of Cyclic and Quasi-Cyclic LDPC Codes on a GPGPU. Springer Journal
of Signal Processing Systems, 64 :149159, 2011.
[Jon02] Friedrich Jondral. Parametrization - A technique for SDR implementation. In Wal-
ter Tuttlebee, editor, Software Dened Radios : Enabling Technologies, pages nm.
Wiley, 2002.
[Jon05] Friedrich K. Jondral. Software-Dened RadioBasics and Evolution to Cognitive
Radio. EURASIP Journal on Wireless Communications and Networking, Vol.3 :275
283, 2005.
[JXJQ09] Guan Jianxin, Ye Xiaohui, Gao Jun, and Liu Quan. The Software Communication
Architecture specication : Evolution and trends. In Computational Intelligence and
Industrial Applications, 2009. PACIIA 2009. Asia-Pacic Conference on, volume 2,
pages 341 344, nov. 2009.
[KB05] J. Kulp and M. Bicer. Integrating specialized hardware to JTRS/SCA software de-
ned radios. In Military Communications Conference, 2005. MILCOM 2005. IEEE,
pages 839 844 Vol. 2, oct. 2005.
[KH00] Thomas Keller and Lakos Hanzo. Adaptive Modulation Technique for Duplex
OFDM Transmission. Transactions on Vehicular Technology, vol. 47, september
2000.
[Kha02] Shoab Ahmed Khan. Digital Design of Signal Processing Systems : A Practical
Approach. Wiley, 2002.
[KHC10] June Kim, Seungheon Hyeon, and Seungwon Choi. Implementation of an SDR
System Using Graphics Processing Unit. IEEE Communication Magazine, pages
156162, March 2010.
[KM02] Apostolos A. Kountouris and Christophe Moy. Reconguration in software radio
systems. 2
nd
Karlsruhe Workshop on Software Radios, 2002.
[KMR00] Apostolos A. Kountouris, Christophe Moy, and Luc Rambaud. Recongurability : A
key property in software radio systems. 1
st
Karlsruhe Workshop on Software Radios,
2000.
[Kut08] Rade Kutil. Parallelization of IIRlters using SIMDextensions. In 15th International
Conference on Systems, Signals and Image Processing (IWSSIP), pages 6568, June
2008.
[LNT
+
09] D. Liu, A. Nilsson, E. Tell, D. Wu, and J. Eilert. Bridging dream and reality : Pro-
grammable baseband processors for software-dened radio. Communications Mag-
azine, IEEE, 47(9) :134 140, sep. 2009.
[LP08] Enno Lubbers and Marco Platzner. A portable abstraction layer for hardware threads.
In International Conference on Field Programmable Logic and Applications, pages
1722, 2008.
[mal] Annonce ARM Mali T604. http://blogs.arm.com/multimedia/
318-arm-mali-t604-new-gpu-architecture-for-highest-performance-
flexibility/, Visit le 17/08/2011.
121
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
[MBGS03] Klaus Moessner, Didier Bourse, Dieter Greifendorf, and Joerg Stammen. Software
radio and reconguration management. Computer Communications, 26(1) :26 35,
2003.
[MGT01] K. Moessner, S. Gultchev, and R. Tafazolli. Software Dened Radio reconguration
management. In Personal, Indoor and Mobile Radio Communications, 2001 12th
IEEE International Symposium on, volume 1, pages D91 D95 vol.1, sep. 2001.
[MHV
+
09] Benot Miramond, Emmanuel Huck, Franois Verdier, Amine Benkhelifa, Bertrand
Granodo, Thomas Lefebvre, Mehdi Aichouch, Jean-Christophe Prevotet, Yaset Oliva,
Daniel Chillet, and Sbastien Pillement. OveRSoC : A Framework for the Explo-
ration of RTOS for RSoC Platforms. International Journal of Recongurable Com-
puting, 2009.
[Mil10] Joel Gregory Millage. GPU integration into a Software Dened Radio Framework.
Masters thesis, Iowa State University, 2010.
[MIP92] MIPS. Assembly Language Programmers Guide, 1992.
[Mit92] III Mitola, J. Software radios-survey, critical evaluation and future directions.
Telesystems Conference, 1992. NTC-92., National, pages 13/1513/23, May 1992.
[MM99] Joseph Mitola and Gerald Q. Maguire. Cognitive Radio : Making Software Radios
More Personal. IEEE Personal Communications, pages 1318, August 1999.
[MSA06] P. Murphy, A. Sabharwal, and B. Aazhang. Design of WARP : A Flexible Wireless
Open-Access Research Platform. In Proceedings of EUSIPCO, 2006.
[NKM
+
09] Dominique Nussbaum, Karim Kalfallah, Christophe Moy, Amor Nafkha, Pierre Ler-
ary, Julien Delorme, Jacques Palicot, Jerome Martin, Fabien Clermidy, Bertrand
Mercier, and Renaud Pacalet. Open Platform for Prototyping of Advanced Software
Dened Radio and Cognitive Radio Techniques. In Digital Systems Design, Euromi-
cro Symposium on, volume 0, pages 435440, Los Alamitos, CA, USA, 2009. IEEE
Computer Society.
[NVI10] NVIDIA. OpenCL Programming Guide for the CUDA Architecture, August 2010.
[NVI11] NVIDIA. NVIDIA CUDA C Programming Guide Version 4.0, June 2011.
[OMG08] OMG. Common Object Request Broker Architecture (CORBA/IIOP), April 2008.
[ope10] The OpenCL Specication, Version 1.1, September 2010.
[ora] Oracle. http://cordis.europa.eu/fetch?CALLER=PROJ_ICT&ACTION=
D&CAT=PROJ&RCN=80719 Visit le 11/07/2011.
[Pra10] Ramjee Prasad. My personal Adaptive Global NET (MAGNET). Springer, 2010.
[PRR
+
03] Andreas Polydoros, Jukka Rautio, Giuseppe Razzano, Hanna Bogucka, Diego
Ragazzi, Panos I. Dallas, Aarne Mmmel, Michael Benedix, Manuel Lobeira, and
Luigi Agarossi. WIND-FLEX : Developing a Novel Testbed for Exploring Flexible
Radio Concepts in an Indoor Environment. IEEE Communications Magazine, July
2003.
[PZB
+
11] William Plishker, George F. Zaki, Shuvra S. Bhattacharyya, Charles Clancy, and John
Kuykendall. Applying Graphics Processor Acceleration in a Software Dened Radio
Prototyping Environment. In Proceedings of the International Symposium on Rapid
System Prototyping, Karlsruhe, Germany, May 2011.
[qos] Qosmos. http://www.ict-qosmos.eu/ Visit le 11/07/2011.
[Ram07] Ulrich Ramacher. Software-Dened Radio Prospects for Multistandard Mobile
Phones. Computer, pages 6267, October 2007.
122
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
[RGMF05] Xavier Revs, Antoni Gelonch, Vuk Marojevic, and Ramon Ferrs. Software Radios :
Unifying the Reconguration Process over Heterogeneous Platforms. EURASIP
Journal on Applied Signal Processing, 2005(16) :26262640, 2005.
[sca01] Software Communications Architecture Specications - MSRC-5000SCA - V2.2,
2001.
[SCA11] Software Communications Architecture Specications - Version Next(draft) 1.0.0.2,
2011.
[SH09] Piotr Szegvari and Christian Hentschel. Scalable Software Dened FM-Radio Re-
ceiver Running on Desktop Computers. In The 13th IEEE Internation Symposium on
Consumer Electronics, 2009.
[SMM05] Je Smith, David Murotake, and Antonio Martin. Software communication archi-
tecture : Evolution and status update. Military Embedded Systems, pages 2831,
October 2005.
[Tec] Virginia Tech. OSSIE - SCA-Based Open Source Software Dened Radio. http:
//ossie.wireless.vt.edu/.
[TR08] Yahia Tachwali and Hazem Refai. Implementation of a BPSK Transceiver on Hybrid
Software Dened Radio Platforms. In 3rd International Conference on Information
and Communication Technologies From Theory to Applications. IEEE, 2008.
[Tut02] Walter Tuttlebee. Software Dened Radio - Enabling Technologies. Wiley, 2002.
[WCW
+
09] Ying Wang, Wei-Nan Chen, Xiao-Wei Wang, Hon-Jun You, and Cheng-Lian Peng.
The Hardware Thread Interface Design and Adaptation on Dynamically Recongu-
rable SoC. In International Conference on Embedded Software and Systems, pages
173178, 2009.
[WEL11] Di Wu, Johan Eilert, and Dake Liu. Implementation of a High-Speed MIMO Soft-
Output Symbol Detector for Software Dened Radio. Springer Journal of Signal
Processing Systems, 63 :2737, January 2011.
[WSC10] Michael Wu, Yang Sun, and Joseph R. Cavallaro. Implementation of a 3GPP LTE
turbo decoder accelerator on GPU. In IEEE Workshop on Signal Processing Sytems
(SIPS), pages 192197, October 2010.
[WSGC11] Michael Wu, Yang Sun, Siddharth Gupta, and Joseph R. Cavallaro. Implementation
of a High Throughput Soft MIMO Detector on GPU. Springer Journal of Signal
Processing Systems, 64 :123136, 2011.
[Xil10] Xilinx. Partial Reconguration User Guide, May 2010.
123
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2
Rsum :
Lutilisation de la radio exible permet denvisager des rseaux sans l volutifs, plus ecaces
et plus intelligents. Le terme radio exible est un terme trs gnral, qui peut sappliquer
une implantation logicielle des oprations, une implantation matrielle adaptable base sur
des acclrateurs matriels, ou encore des implantations mixtes. Il regroupe en fait toutes les
implantations de terminaux radio qui ne sont pas ges.
Les travaux raliss durant cette thse tournent autour de deux points. Le premier est lutil-
isation des processeurs graphiques pour la radio exible, et plus particulirement pour la radio
logicielle. Ces cibles orent des performances impressionnantes en termes de dbit brut de calcul,
en se basant sur architecture massivement parallle. Le paralllisme de donnes utilis dans ces
processeurs dire cependant du paralllisme de tches souvent exploites dans les applications
de radio logicielle. Direntes approches pour rsoudre ce problme sont tudies. Les rsultats
obtenus sur ce point permettent une nette amlioration du dbit de calcul atteignable avec une
implantation logicielle, tout en librant le processeur pour dautres tches.
Le deuxime point abord dans cette tude concerne la dnition dun environnement perme-
ttant de supporter direntes possibilits dimplantation de la radio exible. Cet environnement
englobe le support de la plateforme htrogne, et la gestion des applications sur ces plateformes.
Bien quencore exprimental, les premiers rsultats obtenus avec lenvironnement montrent ses
capacits dadaptation, et le rendent utilisable pour des applications radio varies sur des plate-
formes htrognes.
Abstract :
The development of exible radio may lead to evolving wireless networks. This character-
istic enables more ecient and smarter networks. Flexible radio is not a precise denition. It
can be used to describe a software implementation of radio operations, as well as a hardware
implementation based on congurable hardware coprocessors. It can also refer to heterogeneous
implementations. It describes any implementation which can evolve.
During this PhD, we focused on two dierent aspects of exible radio. First, the use of graphi-
cal processors for exible radio (and especially software radio) is studied. These execution targets
enable impressive performances, when studying raw attainable processing throughput, through the
use of massively parallel architectures. The problem is that the data parallelism exhibited by these
processors does not match the task parallelism of software radio applications. Dierent approaches
to correct this mismatch are studied in this work. The displayed results show an improvement in
the attainable software implementation, while letting the processor process other tasks.
The other issue addressed in this work is the denition of an environment able to support dif-
ferent implementation choices for exible radio. Support for multiple implementations includes
heterogeneous platforms support, as well as application management on these platforms. While
this environment is still in early development stage, preliminary results demonstrate its adaptabil-
ity, and eases development of applications on dierent heterogeneous platforms.
t
e
l
-
0
0
6
8
0
0
8
0
,

v
e
r
s
i
o
n

1

-

1
7

M
a
r

2
0
1
2

Vient Et Part Vient Et Part

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Vient Et Part Vient Et Part

Hochgeladen von

Copyright:

Verfügbare Formate

THSE

Pour obtenir le grade de

Radio cognitive Radio Ilexible

Das könnte Ihnen auch gefallen