These Delahaye 2007

No d’ordre : 3482
Thèse
présentée devant
l’UNIVERSITE ´ DE RENNES I
pour obtenir le grade de

Docteur de l’Université de Rennes I
Mention : Électronique
par
Jean-Philippe Delahaye
Équipe d’accueil : Institut d’électronique et de télécommunications de Rennes

École doctorale : Matisse
Composante universitaire : Université de Rennes I
Plate-forme hétérogène reconfigurable : application à

la radio logicielle
Soutenue le 18 avril 2007 devant la commission d’examen
Composition du jury
Rapporteurs
M. Michel Auguin Directeur de recherche CNRS, Lab. I3S-UNSA-CNRS, Nice
M. Jean-Luc Philippe Professeur des Universités, Université de Bretagne Sud - LESTER, Lorient
Examinateurs
M. Antoni Gelonch Professeur associé, Universitat Politècnica de Catalunya, Barcelona
M. Jean-François Hélard Professeur des Universités, IETR/INSA, Rennes
M. Bernard Uguen Professeur des Universités, Université de Rennes I - IETR, Rennes
M. Pierre Leray Professeur associé, IETR/Supélec, Rennes
M. Jacques Palicot Professeur, IETR/Supélec, Rennes
Remerciements
Cette thèse a été effectuée sous la direction de Monsieur Jacques Palicot, responsable du
laboratoire Signal Communication et Electronique Embarquée (SCEE) à Supélec Rennes.
L’encadrement, les conseils, le soutien dont il m’a fait bénéficier durant ce travail se sont
révélés précieux.
Je tiens à remercier Pierre Leray et Yves Louët de m’avoir proposé le sujet de thèse,
je tiens particulièrement à remercier Pierre Leray pour son implication tout au long de
cette thèse et pour sa grande contribution au travail réalisé autour des plates-formes
d’expérimentations matérielles.
Je remercie Monsieur Jean-François Hélard, Professeur des Universités à l’Institut

d’Electronique et des Télécommunications de Rennes (IETR INSA), qui m’a fait l’hon-
neur de présider la commission d’examen.
Je remercie tout particulièrement Monsieur Michel Auguin, Directeur de Recherche au
CNRS, du Laboratoire Informatique Signaux et Systèmes, ainsi que Monsieur Jean-Luc
Philippe Professeur des Universités à l’Université de Bretagne Sud, qui ont accepté de
juger ce travail et d’en être les rapporteurs.
Je remercie également Monsieur Antoni Gelonch, Professeur associé à l’Université Poly-
technique de Catalogne, tout d’abord, pour son accueil à Barcelone au laboratoire radio
communication de l’UPC pendant l’été 2005, puis pour sa participation au jury de cette
thèse. Je tiens aussi à remercier Monsieur Xavier Revés pour sa disponibilité et les dis-
cussions intéressantes notamment autour du P-HAL au cours du “NEWCOM Summer
Camp” à Barcelone.
Je remercie également Monsieur Bernard Uguen, Professeur de l’Université de Rennes 1
d’avoir accepter, au pied levé, de participer à ce jury de thèse.
Je remercie chaleureusement, Christophe Moy enseignant chercheur à SCEE pour son en-
thousiasme et sa disponibilité, les échanges d’idées et le suivi attentif pendant la rédaction
de cette thèse.
Mes amicaux remerciements vont à Guy Gogniat du LESTER et à Lilian Bossuet du
laboratoire IXL dont la relecture et les critiques furent stimulantes, sans oublier leur dis-
ponibilité lors d’un agréable et constructif week-end de répétitions de soutenance. Je tiens
à remercier plus particulièrement Guy Gogniat du LESTER pour ses lectures attentives
et ses critiques bienveillantes des versions antérieures de cette thèse qui m’ont permis d’en
améliorer la qualité.
Je souhaite exprimer toute ma sympathie aux doctorants de Supélec et aux doctorants

de l’IETR/INSA et de IETR/Rennes 1.
Toute mon amitié va notamment à Sid Zabré Kiéta avec qui j’ai partagé le bureau pen-
ii Remerciements
dant ces années, et avec qui j’ai eu tant de discussions radio logicielle et bien d’autres
fructueuses.
A Messieurs Hongzhi Wang, Loı̈g Godard doctorants et Amor Naftha post-doctorant de-
venu depuis enseignant-chercheur à Supélec, avec qui j’ai eu la joie de travailler sur de
nombreux aspects des architectures reconfigurables.
A Monsieur David Elleouët, avec qui j’ai pu travailler sur les aspects consommation de
la reconfiguration dynamique des FPGA, et aussi aux sessions à ramer ensemble pour
prendre les bonnes vagues.
Je souhaite remercier ma chère tante Monique De La Gontrie pour la très précieuse

et méticuleuse relecture orthographique intégrale de la thèse dont cette version finale est
issue.
Ces remerciements s’adressent également à mes parents et amis qui ont soutenu, supporté
avec compréhension les étapes de cette thèse.
Résumé
Les techniques radio logicielle visent à offrir un accès à un large choix de standards de
radiocommunications sur une architecture matérielle unique. Une grande flexibilité de
l’architecture d’un système radio logicielle est nécessaire afin de répondre à la diver-
sité des traitements à exécuter. Les techniques de communications numériques employées
dans les standards entraı̂nent des besoins en ressources de traitements hétérogènes. La
reconfigurabilité d’une plate-forme d’exécution hétérogène est donc un point clef techno-
logique à l’apparition de systèmes radio logicielle. La diversité des traitements induit aussi
une variété de configurations de l’architecture. La reconfigurabilité des systèmes RL doit
répondre aux besoins d’adaptation des algorithmes de traitement du signal afin de s’adap-
ter aux demandes de changements de contexte applicatifs. Une analyse des applications
multistandard est donc nécessaire pour déterminer les besoins de flexibilité des applica-
tions. Nos travaux s’appuient sur l’analyse des traitements des couches physiques dans les
chaı̂nes d’émission des 3 standards de radiocommunications UMTS, GSM, WLAN 802.11g
(mode OFDM) choisi pour la diversité des traitements en bande de base effectués.
Afin que la reconfigurabilité potentielle soit exploitable lorsque le système est autonome,
la gestion de configuration est une caractéristique essentielle d’un réel système RL. Nous
proposons une approche hiérarchique et distribuée de la gestion de configuration afin de
répondre au besoins de flexibilité des applications orientées flots de données implantées
sur des ressources hétérogènes.
La mise en œuvre d’applications sur des plates-formes hétérogènes reconfigurables et en
particulier sur des circuits logiques configurables, nécessite la mise en place de méthodologies
de conception afin d’extraire la reconfigurabilité potentielle de ces circuits. Nous apportons
dans ses travaux des approches de conception des applications particulièrement sur circuit
de type FPGA permettant de réaliser des traitements reconfigurables dynamiquement.
Table des matières
Remerciements i
Résumé iii
Table des matières v
Introduction 1
I Applications radio logicielle 7
1 Introduction à la radio logicielle 9

1.1 Définitions et généralités . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2 Contraintes et besoins pour les architectures systèmes . . . . . . . . . . . 16
2 Étude des standards : vers une application multistandard 19

2.1 Motivations sur les choix des standards . . . . . . . . . . . . . . . . . . . 21
2.2 Le système cellulaire GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.1 Les caractéristiques générales du système . . . . . . . . . . . . . . 23
2.2.2 Les traitements en bande de base . . . . . . . . . . . . . . . . . . . 24
2.3 Le système cellulaire UMTS/FDD . . . . . . . . . . . . . . . . . . . . . . 26
2.3.1 L’interface radio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.4 Le système de réseaux sans fil WLAN 802.11g . . . . . . . . . . . . . . . . 28
2.4.1 Les évolutions de l’IEEE 802.11 . . . . . . . . . . . . . . . . . . . . 28
3 Analyse radio logicielle des applications multi-standards 33

3.1 Introduction aux études de paramétrisation . . . . . . . . . . . . . . . . . 34
3.1.1 Fonctions communes . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.1.2 Opérateurs communs . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.1.3 Multiplexage de fonctions . . . . . . . . . . . . . . . . . . . . . . . 35
3.1.4 Chaı̂ne de traitement commune . . . . . . . . . . . . . . . . . . . . 36
3.2 Etude de la chaı̂ne de transmission tri-standards . . . . . . . . . . . . . . 39
3.2.1 La factorisation fonctionnelle . . . . . . . . . . . . . . . . . . . . . 39
3.2.2 Classification en groupe fonctionnel . . . . . . . . . . . . . . . . . 42
v
vi table des matières
3.2.3 Analyse des besoins de gestion de configuration de l’application

multi-standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
II Systèmes reconfigurables pour la radio logicielle 49
4 Architectures systèmes radio logicielle 51

4.1 Les ressources matérielles . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.1.1 Flexibilité des systèmes radio logicielle . . . . . . . . . . . . . . . . 54
4.1.2 Systèmes à architecture matérielle fixe . . . . . . . . . . . . . . . . 54
4.1.3 Systèmes flexibles à la conception . . . . . . . . . . . . . . . . . . . 54
4.1.4 Systèmes flexibles à l’exécution . . . . . . . . . . . . . . . . . . . . 55
4.2 Architectures des couches logicielles . . . . . . . . . . . . . . . . . . . . . 58
4.2.1 Couche logicielle intermédiaire : Exemple de l’architecture SCA . . 59
4.2.2 SCA et architecture MODEM . . . . . . . . . . . . . . . . . . . . . 61
4.2.3 La couche logicielle intermédiaire P-HAL . . . . . . . . . . . . . . 62
4.3 La gestion de configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.3.1 Nature des configurations à gérer . . . . . . . . . . . . . . . . . . . 65
4.3.2 Les architectures de gestion de configuration . . . . . . . . . . . . 67
5 Un modèle d’architecture pour la radio logicielle 75

5.1 Double chemin de données : configuration/traitement . . . . . . . . . . . . 76
5.2 Modèle de la voie de gestion de configuration . . . . . . . . . . . . . . . . 78
5.2.1 Le niveau hiérarchique 1 . . . . . . . . . . . . . . . . . . . . . . . . 79
5.3 Le modèle de la voie de traitement . . . . . . . . . . . . . . . . . . . . . . 84
5.3.1 Le fonctionnement d’un composant de traitement . . . . . . . . . . 85
5.3.2 Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
III Plateforme radio logicielle 91
6 Conception et intégration des applications SDR sur plate-forme recon-

figurable 93
6.1 Intégration de l’application flot de données sur plate-forme hétérogène . . 94
6.1.1 Reconfiguration dynamique . . . . . . . . . . . . . . . . . . . . . . 97
6.1.2 Reconfiguration partielle de FPGA . . . . . . . . . . . . . . . . . . 100
6.2 Approches de conception d’IP reconfigurable sur FPGA . . . . . . . . . . 104
6.3 Flots de conception d’IP reconfigurables sur FPGA . . . . . . . . . . . . . 109
6.3.1 Flot : “Module-Based Partial reconfiguration” . . . . . . . . . . . . 110
6.3.2 Flot : “MoDiff-Based Partiel Reconfiguration” . . . . . . . . . . . 111
6.3.3 Flot : “Partial Reconfiguration” . . . . . . . . . . . . . . . . . . . . 113
6.3.4 Connexion d’une région reconfigurable . . . . . . . . . . . . . . . . 115
6.3.5 Création d’une macro . . . . . . . . . . . . . . . . . . . . . . . . . 118
6.4 Etude de cas : la fonction de filtrage FIR . . . . . . . . . . . . . . . . . . 121
table des matières vii
7 Réalisation : plate-forme radio logicielle et implantation 127

7.1 Gestion de configuration hiérarchique sur la plate-forme . . . . . . . . . . 128
7.1.1 Portage de la structure de gestion de configuration sur la plate-forme
hétérogène . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
7.1.2 Implantation de la structure de gestion de configuration sur la plate-
forme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
7.2 Procédures et scénarios de reconfiguration sur la plate-forme . . . . . . . 132
7.2.1 Initialisation de la plate-forme . . . . . . . . . . . . . . . . . . . . 132
7.2.2 Reconfiguration de fonctions sur la plate-forme . . . . . . . . . . . 133
7.2.3 Scénarios de reconfiguration des applications multistandard . . . . 137
7.3 Implantation de la voie de traitement sur la plate-forme . . . . . . . . . . 139
7.3.1 Architecture du chemin de traitement sur la plate-forme . . . . . . 139
7.4 Exemples d’implantation de fonctions . . . . . . . . . . . . . . . . . . . . 142
7.4.1 Mise en constellation . . . . . . . . . . . . . . . . . . . . . . . . . . 142
7.4.2 Codeur convolutif . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
7.4.3 Filtre FIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Conclusions et perspectives 151
Annexe 159
A Travaux issus de collaborations 161

A.1 Conception d’interface pour Objet P-HAL partiellement reconfigurable . . 162
A.2 Étude de consommation de la reconfiguration . . . . . . . . . . . . . . . . 163
B Les standards 165

B.1 GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
B.2 UMTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
B.3 WLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
B.3.1 Fonctions bande de base 802.11g Mode ERP-OFDM . . . . . . . . 170
B.4 Paramètres des fonctions multistandards . . . . . . . . . . . . . . . . . . . 172
C Architectures systèmes 175

C.1 Modélisation de l’architecture logicielle . . . . . . . . . . . . . . . . . . . . 176
C.2 L’architecture du SCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
C.3 Les limitations de l’approche SCA . . . . . . . . . . . . . . . . . . . . . . 179
C.4 Couches logicielles intermédiaires : autres travaux . . . . . . . . . . . . . . 180
C.5 Circuits : compléments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
C.5.1 GPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
C.5.2 DSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
C.5.3 ASIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
C.5.4 Architectures reconfigurables, un peu d’histoire ! . . . . . . . . . . 182
C.5.4.1 FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
C.6 Description de la plate-forme de prototypage . . . . . . . . . . . . . . . . 184
Table des figures 187

viii table des matières
Liste des tableaux 191
Bibliographie 193
Introduction
Les acteurs de l’industrie des télécommunications, opérateurs et équipementiers font face à

une profonde mutation du domaine, à un changement de modèle économique. En effet, les
constantes innovations des technologies radio entraı̂nent une évolution de l’offre, composée
aujourd’hui de réseaux indépendants faits de multiples standards de communication, à une
offre, composée demain de services multiples (voix, données, positionnement, mobilité) sur
un réseau intégré, transparent à l’utilisateur. Ces services multiples seront accessibles de-
puis un réseau enfoui reposant sur de multiples standards d’accès. Ces standards, dont la
multiplication a été observée au cours des dernières années, ne vont pas devenir des offres
concurrentes, mais bien des technologies coexistantes contribuant à fournir une offre de
services diversifiés.
De grands efforts d’innovations technologiques sont à réaliser avant de pouvoir offrir un
terminal mobile universel avec lequel le réseau sera transparent à l’utilisateur. Ce dernier
se posera à l’avenir uniquement la question des services qu’il souhaite recevoir depuis
son objet communiquant, le choix d’un terminal en fonction du nombre de standards
ou de bandes de fréquences supportées n’aura plus de sens économique. Déjà aujourd’hui,
l’exemple de la dissémination de bornes d’accès sans fil libres montre que l’accès au réseau
et le coût de cet accès n’est plus l’intérêt principal, mais que ce sont bien les services offerts
par un “tuyau” auquel s’attache l’utilisateur.
Le domaine de la radio logicielle vise à répondre à ces évolutions de la demande et des
technologies en offrant un ensemble de techniques telles que la convergence des réseaux,
l’accès à de multiples interfaces air, la flexibilité des systèmes de traitement pour un accès
à la diversité des techniques de modulations.
En 1995, J. Mitola a défini dans [1] les principaux concepts de la radio logicielle en for-
malisant notamment l’architecture des transmetteurs et en établissant une architecture
dite de radio logicielle “idéale”. Cette architecture de transmetteurs constituée d’une an-
tenne large bande directement suivie par un convertisseur analogique numérique à haute
fréquence d’échantillonnage et large bande permettent à un circuit de type processeur
infiniment rapide de traiter ensuite un signal numérique contenant un ensemble de si-
gnaux issus de divers standards. La reprogrammabilité des processeurs est utilisée afin
que de tels systèmes radio logicielle soient capables de s’adapter aux différents standards
en téléchargeant de simples logiciels. Cela pose d’ailleurs de nouveaux problèmes tels
que la sûreté des téléchargements et de fonctionnement d’équipements radio, problèmes
inhérents au monde informatique, mais aussi au niveau régulation tel que la certification
de système dont le comportement pourra être modifié au niveau électromagnétique après
sa mise sur le marché.
Toutefois, il existe à l’heure actuelle de nombreuses limitations technologiques ne permet-
tant pas de réaliser une telle architecture, dont le manque de puissance de calcul, la forte
2 Introduction
consommation des processeurs, les limites de performances des convertisseurs et la limi-

tation en terme de bande passante des amplificateurs, mélangeurs ainsi que des antennes.
Cependant les techniques et concepts de la radio logicielle sont étroitement liés au do-
maine de l’électronique et suivent donc les évolutions perpétuelles de ce dernier. Dès lors,
en allant vers cette radio logicielle idéale, les intérêts et les conséquences pour les acteurs
des télécommunications se multiplient. Une standardisation de l’architecture logicielle des
récepteurs permettrait de réduire le temps de mise sur le marché des équipements. Lors
d’évolutions dans les normes, les infrastructures réseaux et les stations de base, conçues
à l’aide des circuits reprogrammables permettront une évolutivité et une maintenance
plus rapide de ceux-ci, par téléchargement à distance de programmes logiciels au lieu
d’un remplacement physique et ainsi pérenniseront les investissements matériels. Un jour,
nous parlerons peut-être de “développement durable” des systèmes de télécommunications
grâce à la radio logicielle.
Aujourd’hui, la radio logicielle est la convergence entre radiocommunication et informa-

tique comme en témoigne par exemple le programme “Radio Free Intel”(1) d’un des leaders
du marché des semi-conducteurs pour le monde informatique.
Le secteur des semi-conducteurs, très actif, est donc un des moteurs des rapides évolutions
technologiques ayant ainsi permis à la radio logicielle de voir le jour, et qui lui permet-
tra de devenir une réalité industrielle. De nombreuses entreprises proposent des produits
permettant de réaliser différents standards de communication notamment pour les sta-
tions de base des sociétés comme l’anglaise PicoChip(2) , les américaines Airnet(3) et Vanu
(4) qui sont parmi les plus actives. D’autres sociétés, “fabless”, ou fondeurs, proposent
des circuits spécialisés sur des technologies reconfigurables comme par exemple QuickSil-
ver Technologies(5) , Infineon ayant racheté Morphics Technology(6) , Philips ayant absorbé
Systemonic(7) , et Motorola Morpho Technologies(8) et elles regardent la radio logicielle
comme un des domaines applicatifs les plus attractifs pour ce nouveau type de circuits.
Les promoteurs historiques du reconfigurable que sont les circuits FPGA (Field Program-
mable Gate Array) avec en tête la société Xilinx(9) proposent aujourd’hui des circuits
matures de plus en plus intéressants, tant sur le plan technique qu’économique. La société
Xilinx s’implique d’ailleurs dans les programmes de recherche concernant la radio logicielle.
Le domaine de la recherche académique en radio logicielle représente une thématique

de recherche forte. Au niveau européen notamment, de vastes programmes de recherche
bénéficiant de moyens très importants sont en cours, comme par exemple le projet E2 R [2].
Les ambitieux objectifs d’un tel programme sont d’apporter une reconfigurabilité de bout
en bout de la chaı̂ne de communication. Les études algorithmiques afin de rendre efficaces
et réutilisables les nombreux traitements numériques, l’optimisation de la consommation
(1)
http ://www.intel.com/technology/techresearch/radio/
(2)
http ://www.picochip.com
(3)
http ://www.aircom.com
(4)
http ://www.vanu.com
(5)
http ://www.qstech.com
(6)
http ://www.morphics.com
(7)
http ://www.systemonic.com
(8)
http ://www.morphotech.com
(9)
http ://www.xilinx.com
Introduction 3
en ressources matérielles par le partage de celles-ci entre plusieurs standards de communi-

cations ou l’exploration des architectures reconfigurables sont autant d’axes de recherche
ouverts pour offrir et optimiser la reconfigurabilité potentielle des futurs systèmes radio
logicielle.
Cette reconfigurabilité, afin d’être exploitée dans des systèmes embarqués autonomes doit
être gérée de façon à la rendre accessible aux applications de haut niveau et aux applica-
tions radio, car dans un contexte RL la chaı̂ne de traitement radio devient elle-même une
application. Pour les couches hautes des systèmes, souvent supportées par des systèmes
d’exploitation, des études proposant des architectures de gestion de configuration ont été
réalisées. Ces études, souvent issues du domaine informatique sont consommatrices en
ressources matérielles et mal adaptées aux systèmes embarqués. De plus, ces exécutifs de
haut niveau d’abstraction, n’ont pas été dimensionnés pour exploiter la reconfigurabilité
et les spécificités des architectures reconfigurables.
Les processeurs, bien qu’ils offrent une grande flexibilité, particulièrement les processeurs
généralistes ont une efficacité énergétique faible pour les traitements intensifs de données.
Il existe aussi des processeurs spécialisés de traitement du signal, (DSP Digital Signal Pro-
cessor) cependant ils ne peuvent pas prendre en charge l’ensemble des traitements d’une
chaı̂ne radio. La mise en oeuvre des circuits spécifiques à l’application développée (ASIC,
Application Specific Integrated Circuit), circuits actuellement les plus performants, im-
plique une approche classique pour définir une chaı̂ne de transmission multi-standard
et de mettre en parallèle les chaı̂nes de transmissions de chaque standard. Ces circuits
n’offrent effectivement pas de flexibilité. Cette approche est valable lorsque le nombre de
standards est faible, mais le coût en surface est important, et surtout, l’architecture est
non-évolutive.
Les architectures reconfigurables et notamment les FPGA (Field Programmable Gate
Array), par le compromis flexibilité / performance qu’elles offrent par rapport aux pro-
cesseurs et aux ASIC, sont des candidats pour définir les architectures des systèmes radio.
Or le contrôle et la gestion de configuration de ces architectures sont spécifiques et les
études manquent afin d’exploiter leur reconfigurabilité dans des systèmes embarqués.
Problématique de l’étude
La problématique de l’étude présentée dans ce document est la suivante : face à la multi-
tude des standards de communications, impliquant une grande diversité des traitements
numériques et face à l’hétérogénéité nécessaire des ressources pour répondre efficacement
aux besoins de traitement, est-il possible d’offrir une architecture de gestion de configu-
ration répondant à la fois aux besoins de changement de contextes applicatifs et capable
d’exploiter la reconfigurabilité offerte par une plate-forme d’exécution hétérogène sans le
surcoût d’un exécutif de haut niveau ? Aujourd’hui, il existe peu d’études sur les archi-
tectures de gestion de configuration qui représentent pourtant le réel point distinctif des
systèmes radio logicielle par rapport à d’autres domaines exploitant les avancées du recon-
figurable. Dans le même temps, de nouvelles normes de communication voient le jour et le
domaine des architectures reconfigurables évolue rapidement. Une architecture de gestion
de configuration doit donc présenter un niveau d’abstraction suffisant afin de s’adapter à
ces futures évolutions.
La mise en œuvre des applications sur des plates-formes hétérogènes et en particulier
4 Introduction
des circuits reconfigurables, nécessite de mettre en place des méthodologies de conception

afin d’extraire la reconfigurabilité potentielle de ces circuits et répondre ainsi aux besoins
d’adaptation des algorithmes de traitements du signal afin de s’adapter aux changements
de contextes applicatifs. Les méthodologies de conception sont donc aussi un point essen-
tiel à la réalisation de systèmes radio logicielle.
Contributions
Les contributions de ces travaux s’articulent, autour de la reconfigurabilité, sur trois
thèmes complémentaires :
• L’analyse d’applications multi-standards (traitements de la couche physique) et des
besoins en reconfiguration.
• L’architecture de gestion de configuration pour exploiter la reconfigurabilité à l’exécution
et l’architecture flot de données associée, adaptée à des traitements reconfigurables.
• Les méthodologies de conception (FPGA) pour la mise en œuvre de la reconfigura-
bilité.
Les travaux décrits dans ce document proposent une architecture de traitement orientée
flot de données étroitement associée à une structure de gestion de configuration. Ce
modèle destiné à être déployé sur tous types de plates-formes matérielles hétérogènes
vise à répondre aux besoins de changement de contextes des applications multi-standards.
Cela passe obligatoirement par une analyse des recouvrements en terme de nature de
traitement entre standards. Ce point garantit l’efficacité dynamique de l’exécution. A tra-
vers le modèle d’architecture proposé, nos travaux permettent de mieux appréhender la
conception d’applications radio logicielle sur des plates-formes matérielles hétérogènes.
Dans le cadre de nos études sur les approches de conception possibles pour répondre
aux besoins en reconfiguration de la radio logicielle, nous nous sommes particulièrement
intéressés aux méthodologies de conception des FPGA et notamment à la mise en œuvre
de la reconfiguration partielle comme moyen de fournir de l’adaptabilité aux applications.
Nos travaux sur la gestion de configuration ont été reconnus au SDR Forum, organisme
de réflexion sur la RL, et ont donné lieu à une coopération avec Xilinx. Les travaux,
notamment ceux autour de la reconfiguration dynamique de FPGA, sont engagés dans
des projets européens dont NEWCOM et E 2 R nécessitant de confronter nos approches de
conception à de nouvelles applications et plates-formes matérielles.
Contexte
Les travaux décrits dans ce document ont été réalisés à l’origine au sein de l’équipe de
recherche ETSN devenue ensuite l’équipe SCEE à Supélec campus de Rennes. Historique-
ment, l’équipe de recherche s’est toujours intéressée à l’étude et à la conception de systèmes
pour des applications en traitement du signal et de l’image. Depuis trois ans, l’équipe s’est
tournée davantage vers le domaine de la radio logicielle et de la radio intelligente à tra-
vers l’étude des systèmes de traitement du signal et des systèmes de communications
numériques. Ces travaux ont donc initié et contribué à développer des compétences de
l’équipe dans le domaine de la conception d’applications radio logicielle sur des archi-
tectures hétérogènes reconfigurables. Les outils et méthodologies de conception mis en
Introduction 5
place au cours de cette étude permettent aujourd’hui la réalisation d’autres travaux, par
exemple autour de MIMO.
Plan du mémoire
Les travaux présentés, dans ce document en trois parties, nous ont amené à développer une
architecture de traitement sur plate-forme hétérogène pour les applications de la couche
physique radio logicielle.
1. Dans la première partie de ce rapport, il nous a semblé important de donner au
lecteur les éléments sur les aspects applicatifs de la radio logicielle, sur lesquels
nous nous appuyons par la suite pour proposer des solutions d’implantations des
traitements multi-standard.
• Le premier chapitre donne au lecteur un aperçu plus détaillé du domaine de
la radio logicielle, permettant de situer de manière plus technique les choix et
motivations de cette étude.
• Le second chapitre présente les principales informations sur les trois standards de
communications utilisés comme applications au cours de l’étude.
• Suite à la présentation des trois standards, nous exposons les différentes approches
de paramétrisation des traitements multi-standards et nous exposons notre ana-
lyse RL, nous amenant à proposer une chaı̂ne de transmission tri-standard. Nous
dégageons également les différents besoins en reconfigurabilités de ces applications.
2. Le premier chapitre de la seconde partie propose un état de l’art sur les technologies
candidates à la constitution d’un système radio logicielle.
Au second chapitre de cette partie, nous proposons un modèle d’architecture répondant
aux besoins de la radio logicielle.
• Le quatrième chapitre présente successivement un état de l’art des trois prin-
cipales composantes d’une architecture de système radio logicielle que sont les
architectures matérielles, les architectures logicielles de couche intermédiaire et
celles de gestion de configuration.
• Après cette analyse de l’existant, nous proposons dans le cinquième chapitre, un
modèle qui se compose d’un double chemin de données de traitement et de configu-
ration. La structure de gestion de configuration “HDCM” (Hierachical Distributed
Configuration Management) s’appuie sur l’analyse des besoins applicatifs donnée
dans la première partie.
3. La dernière partie du rapport est consacrée à la mise en œuvre sur plate-forme du
modèle d’architecture proposé, en s’intéressant à la fois aux aspects méthodologie
de conception et à la réalisation d’une chaı̂ne de traitement reconfigurable.
• Nous proposons, dans le sixième chapitre, une approche de conception d’applica-
tion flot de données pour plate-forme hétérogène. Puis nous nous intéressons plus
particulièrement aux méthodologies de conception pour exploiter la reconfigura-
bilité des FPGA notamment par reconfiguration partielle.
• Le dernier chapitre présente la mise en œuvre d’une plate-forme matérielle hétérogène
utilisée à travers l’implantation du modèle d’architecture défini au cinquième cha-
pitre. Ce chapitre montre l’adaptation de ce modèle à l’architecture physique de la
plate-forme et l’exploitation de celui-ci à travers des scénarios de reconfiguration.
Des exemples de réalisations d’algorithmes illustrent aussi la mise en œuvre de la
6 Introduction
chaı̂ne de traitement. Les implantations de ces algorithmes reconfigurables per-

mettent de bien comprendre l’intérêt des méthodologies de conception proposées
au chapitre précédent.
La conclusion propose une synthèse des travaux présentés pour amener le lecteur à une
discussion sur les perspectives de ces travaux. Les annexes concernent les rappels sur les
standards de communications étudiés, sur les architectures logicielles et matérielles pour
les systèmes radio logicielle.
Première partie
Applications radio logicielle

Chapitre 1
Introduction à la radio logicielle
Sommaire
3.1 Introduction aux études de paramétrisation . . . . . . . . . . 34
3.1.1 Fonctions communes . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.1.2 Opérateurs communs . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.1.3 Multiplexage de fonctions . . . . . . . . . . . . . . . . . . . . . . 35
3.1.4 Chaı̂ne de traitement commune . . . . . . . . . . . . . . . . . . . 36
3.2 Etude de la chaı̂ne de transmission tri-standards . . . . . . . 39
3.2.1 La factorisation fonctionnelle . . . . . . . . . . . . . . . . . . . . 39
3.2.2 Classification en groupe fonctionnel . . . . . . . . . . . . . . . . 42
multi-standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Comme nous l’avons évoqué dans l’introduction générale, l’architecture radio logi-
cielle “idéale” (Software Radio - SWR) telle qu’elle a été définie par Mitola en 1995 [1] est
construite autour d’un circuit de type processeur généraliste et sa mémoire, exécutant
toutes les fonctions radio. Dans ce cas, les traitements en réception (respectivement
émission) sont effectués en radio fréquence de façon numérique après une conversion (res-
pectivement avant) A/N(1) (respectivement N/A(2) ) large bande. Encore aujourd’hui, de
nombreux verrous technologiques, notamment la performance des convertisseurs A/N et
N/A ne rendent pas envisageable ce type d’architecture dite de radio logicielle idéale. Au-
delà des limitations des convertisseurs, la puissance de traitement des circuits numériques
actuels ne permet pas d’atteindre les capacités de calcul requises pour effectuer les traite-
ments dans le domaine radio fréquence pour des standards déjà existants tels que UMTS
ou GSM/EDGE comme le montre l’étude de Greifendorf et al. [3]. Selon cette étude les
performances estimées peuvent varier pour les traitements en bande de base de 10 GIPS(3)
pour le GSM à 100 GIPS pour l’UMTS et représentent un réel verrou au niveau consom-
mation si des circuits généralistes sont utilisés. L’évolution technologique rendra peut-être
faisable dans le futur la radio logicielle idéale. Toutefois, attendre la seule évolution des
technologies CMOS n’est pas suffisant à moyen terme ! Une optimisation des ressources
(1)
Analogique / Numérique
(2)
Numérique / Analogique
(3)
Giga Instruction Per Second
9
10 Introduction à la radio logicielle
matérielles utilisées est nécessaire, dès à présent afin d’arriver à des premiers résultats,
mais également sur la durée afin de limiter les coûts. C’est pourquoi la radio logicielle
n’est pas un but clairement identifié, un idéal à atteindre, mais une évolution constante
sur le long terme.
Face aux contraintes technologiques et à la diversité des traitements à exécuter, l’adop-
tion d’architectures pragmatiques semble être la seule solution possible [4]. La différence
est donc faite entre la radio logicielle “idéale” et la radio logicielle “restreinte” (Software
Defined Radio, SDR). Ces récepteurs s’appuient sur des architectures matérielles étagées
en plusieurs segments technologiques. De façon schématique, un émetteur/récepteur radio
contient un segment analogique pour la partie RF et FI(4) (la FI est aussi envisagée en
numérique), des circuits numériques pour l’étage bande de base et enfin des solutions logi-
cielles pour les couches applicatives. Dans les approches pragmatiques, chaque étage suit
une évolution tendant à remplacer progressivement les circuits spécialisés par des compo-
sants plus généralistes et programmables. La numérisation se rapproche de l’antenne et
le front-end, étage analogique d’entrée, se réduit. Les circuits ASIC de l’étage numérique
d’entrée se voient remplacer par des circuits programmables et les formes d’ondes de-
viennent des applications logicielles. Les premiers projets sont à l’initiative du domaine
militaire américain. Le projet SpeakEasy [5] phase I de 1992 à 1995 avait pour objectif
de produire un système radio pouvant opérer entre 2 MHz et 2 GHz pour offrir l’in-
teropérabilité entre les systèmes de communications des armées américaines (armée de
terre en VHF, FM et SINCGARS, armée de l’air VHF et AM, marine VHF, AM et
HF). La phase II de SpeakEasy [6] a vu l’apparition d’un démonstrateur reprogram-
mable basé sur une architecture logicielle “ouverte”. En effet, afin que les systèmes soient
interopérables entre eux, des modèles d’architectures sont définis. Le PMCS (Program-
mable Modular Communications System) [7] est un exemple de ce type d’architecture,
destiné au domaine militaire il présente un module “Infosec” de sécurisation et d’encryp-
tion protégeant les informations du Modem. Ce modèle résulte du projet de recherche
SpeakEasy. Nous pouvons noter qu’une autre innovation de ce projet est qu’il a été utilisé
des FPGA pour les traitements numériques des radiocommunications.
Fig. 1.1 – PMCS [7], le modèle de référence proposé par le JTRS
(4)
Fréquence intermédiaire
11
Ensuite, un vaste programme radio logicielle a été lancé par le DoD américain et les
membres de l’OTAN pour définir une radio logicielle interopérable “à plus grande échelle”.
En 1998, il résulte de ce programme une série de documentations et de spécifications, base
d’une architecture système SDR modulaire de référence. Dans l’industrie, Motorola, par
ailleurs un des principaux participants du projet JTRS, propose sa propre architecture,
Digital Modular Radio (DMR) [8] directement issue des travaux du JTRS.
En 1998, à l’époque des Pentium 166, Pentium 200 Pro et autres stations Sun Ultra M170,
Vanu G. Bose et al. [9] proposent une première implantation radio logicielle sur PC, d’un
système de radio communication FSK et ensuite une implantation logicielle [10] du stan-
dard de radiocommunication civile GSM.
L’évolution de la radio logicielle amène à considérer des applications multi-standards
nécessitant de traiter de multiples couches physiques sur la même plate-forme afin d’offrir
différents types de services. On peut imaginer retrouver dans un terminal de nombreux
standards afin d’offrir l’accès aux systèmes mobiles (GSM et UMTS), de diffusion (DVB-H
et DAB), de positionnement (GPS) et un accès à un réseau WPAN (Bluetooth) et WLAN
(WiFi) comme l’illustre le tableau 1.1.
Diffusion Positionnement Mobile Réseaux

sans fil
DVB -S/-H/-T GPS GSM/GPRS 802.16 WiMAX (WMAN)
DAB Galiléo PDC 802.11 a/b/g (WLAN)
DRM PHS HiperLAN /HLAN
UMTS 802.15 (WPAN)
CDMA2000 Bluetooth
Tab. 1.1 – Services et standards de radiocommunications
Les importantes capacités de calcul requises par les traitements en bande de base
rendent indispensable l’utilisation de circuits divers afin d’optimiser l’efficacité de cal-
cul, suivant la nature des traitements divers et variés à effectuer dans le MODEM. Les
architectures d’exécution sont donc hétérogènes afin de répondre à la diversité de ces
traitements. Afin de ne pas multiplier le nombre de circuits d’un système embarqué, son
architecture doit être flexible. La tendance est donc de s’orienter vers des circuits de types
processeurs, ceux de type généraliste (GPP) offrant le maximum de flexibilité. Cependant
ces circuits généralistes ont une mauvaise efficacité énergétique par rapport à des circuits
de traitement du signal spécialisés, et l’évolution des technologies CMOS n’effacera pas
cette différence puisqu’il n’est pas dans l’objectif des GPP d’économiser l’énergie, mais de
fournir toujours plus de puissance.
La conception d’architecture pour les traitements en bande de base des applications radio
logicielle doit donc répondre au compromis optimisation/flexibilité qui conduira certaine-
ment à la conception d’architectures hétérogènes comme l’illustre la figure 1.2.
Les architectures d’exécution des systèmes radio logicielle et les circuits de traitements en
bande de base sont présentés dans le paragraphe 4.4.1.
Par la suite, nous nous intéressons plus particulièrement aux architectures de la partie
MODEM du modèle illustré par la figure 1.1, qui comprend les traitements en bande de
base et en FI, ce qui constitue la couche basse ou couche physique (en partie car RF et
antenne sont séparées), des systèmes radio logicielle.
Fig. 1.2 – Évolution de la radio logicielle et des technologies utilisées
1.1 Définitions et généralités

La radio logicielle est un ensemble de techniques visant à répondre aux évolutions des ra-
diocommunications. Nous donnons dans cette section quelques définitions établies concer-
nant le domaine de la radio logicielle. Le terme radio logicielle se décline en plusieurs
expressions, précédemment évoquées dans l’introduction, suivant l’architecture du trans-
metteur.
Fig. 1.3 – Principales architectures de récepteurs radio
– La “radio logicielle idéale” (“SoftWare Radio” SWR) est la radio logicielle opti-
male avec comme principale caractéristique une conversion large bande située après
l’antenne suivie d’une architecture de traitement numérique programmable. L’ar-
chitecture correspondant à la radio logicielle idéale est illustrée figure 1.3.b. Cette
architecture correspond à l’architecture de référence présentée par J. Mitola [1].
1.1 Définitions et généralités 13
Dans le cas de la RL idéale, tous les traitements depuis les fonctions radio fréquence
jusqu’aux couches applicatives en passant par les traitements en bande de base sont
donc réalisés de façon numérique.
– La radio logicielle “restreinte”, terme introduit dans [4] est la “Software Defined
Radio” SDR correspond aux caractéristiques d’une numérisation par bande radio
restreinte réalisée en fréquence intermédiaire ou en bande de base. Deux architec-
tures sont possibles. La figure 1.3.c présente l’architecture en conversion en fréquence
intermédiaire qui est un compromis avec la RL idéale. La figure 1.3.d illustre l’ar-
chitecture en conversion directe pour laquelle le principal inconvénient se situe au
niveau de l’oscillateur local qui doit être capable de synthétiser toutes les fréquences
porteuses des standards visés.
– Les récepteurs actuels de type super-hétérodyne par une sélection de bande étroite
ne permettent pas la réception de plusieurs standards autrement que par duplication
physique des récepteurs.
Le SDR Forum [11], principal consortium de promotion de la radio logicielle basé aux
États-Unis, rassemblant des acteurs industriels, des organisations gouvernementales et
académiques a pour but de promouvoir les technologies radio logicielle. Le SDR Forum
donne une terminologie (cf. tableau 1.2) de la radio logicielle qui exprime par la même
occasion les évolutions à venir des systèmes RL. Le SDR forum a donc défini plusieurs
niveaux de “SDR” désignant les capacités et la flexibilité atteignables par ces “SDR”.
Nous avons donné dans [12] un aperçu des principaux projets dans le domaine RL.
Les premières actions au niveau européen ont été menées dans le cadre des programmes
ACTS (Advanced Communications Technologies and Services) et IST disponibles dans le
rapport ACTS [13].
Par la suite les projets européens se sont multipliés sur de très divers axes de recherches
montrant que la radio logicielle recouvre de vastes thématiques de recherche.
Lors du lancement par l’IST du “Framework Programme” (FP5), un point de recherche
essentiel a été la re-configurabilité des systèmes radio. Ceci a donné lieu à de nombreux
projets dont ceux de l’IST comme CAST, TRUST, Pastoral, WIND-FLEX présentés ci-
dessous. D’autres projets européens provenant aussi du FP5 tels que Adriatic, SORT,
SCOUT, se sont intéressés aux systèmes radio reconfigurables. La reconfigurabilité a été
étudiée sous des aspects très variés dans ces différents projets comme l’illustre la figure
1.4. Les études portent sur la re-configurabilité des couches réseaux physiques dans les
infrastructures et les terminaux. L’un des premiers et aussi des plus vastes projets est
TRUST. Un des objectifs était l’évaluation des besoins de l’utilisateur en reconfigurable
et ses travaux sur la reconfigurabilité ont notamment été menés sous l’angle de scénarios.
Ces scénarios définissent des usages de la reconfiguration par l’utilisateur. TRUST a aussi
proposé la mise en place de politiques de reconfiguration afin de contribuer à une norma-
lisation de ces mécanismes. Les projets CAST et TRUST ont contribué à la gestion des
ressources re-configurables, sur les procédures et protocoles pour télécharger et manipuler
les reconfigurations via l’interface air et le réseau.
IST-TRUST 2000-2002 : Transparently Reconfigurable Ubiquitous Terminal. Analyse
de besoins de reconfiguration du point de vue utilisateur et opérateur par une ap-
proche basée sur des scénarios. L’objectif était d’identifier les caractéristiques des
systèmes (notamment au niveau réseau) pour supporter la reconfigurabilité des ra-
dios.
Niveau Terme Description

Niveau 0 Hardware Radio (HR) Une radio seulement basée sur des composants
matériels ne pouvant pas être modifiés autrement que
par une intervention physique
Niveau 1 Software Controlled Radio Seules les fonctions de contrôles d’une SCR sont
(SCR) implantées en logiciel. Un nombre limité de fonc-
tions peut changer, comme les interconnections,
les niveaux de puissance, mais pas les bandes de
fréquences ou les types de modulations utilisées.
Niveau 2 Software Defined Radio Les systèmes SDR fournissent un contrôle ainsi que
(SDR) des techniques de modulation sous forme logicielle.
Les contraintes des systèmes SDR se situent sur la
couverture des bandes de fréquences car au niveau du
“front-end” un multiplexage entre plusieurs antennes
est nécessaire.
Niveau 3 Ideal Software Radio L’ISR représente une grande évolution technolo-
(ISR) gique par rapport aux systèmes SDR en supprimant
les étages analogiques de types superhétérodynes.
La programmabilité du système est étendue à l’en-
semble du système avec une conversion analogique-
numérique à l’antenne.
Niveau 4 Ultimate Software Radio Cette définition est donnée dans le seul but de pou-
(USR) voir comparer les systèmes réels à une référence
ultime. Un système permettant de se reprogram-
mer pour accepter tout type de traffic, toutes
données de contrôle et acceptant une grande plage
de fréquences, d’interfaces air et d’applications. Les
performances de reprogrammabilité permettraient de
basculer d’une interface air à une autre en quelques
millisecondes et offriraient de multiples services de
suivi de positionnement GPS, vidéo à la demande à
partir d’une station de base locale ou par diffusion
satellite.
Tab. 1.2 – Terminologie radio logicielle définie par le SDR Forum
Fig. 1.4 – Projets traitant de la re-configurabilité

1.1 Définitions et généralités 15
IST-CAST 04/2000-12/2002 : Configurable Radio with Advance Software Technology.

L’objectif de CAST fut d’examiner les technologies permettant de réaliser des systèmes
radio configurables (couche physique). Les contributions du projet concernent la ges-
tion des ressources re-configurables, les procédures et protocoles pour télécharger et
manipuler les reconfigurations et la mise en place d’un contrôleur de configuration
pour la gestion des ressources matérielles reconfigurables.
IST-Pastoral 01/2000-06/2002 : Platform And Software for Terminals : Operationally
Re-configurAbLe, L’objectif de ce projet fut d’offrir une plate-forme reconfigu-
rable pour mobiles 3G. Les contributions du projet concernent le développement
de couches physiques, les méthodologies de co-simulation et de co-design orientées
ASIC, avec les développements sur plates-formes FPGA. Les problèmes traités dans
ce projet sont la complexité du terminal, la consommation.
IST-WindFlex 01/2000-06/2003 : Wireless Indoor Flexible High Biterate Modem Ar-
chitecture. Les recherches menées dans ce projet ont porté sur la définition d’une
architecture de modem WLAN configurable.
MuMoR 05/2002-10/2004 : Multi-Mode Radio Architecture Platform for Enhanced 3G
[14]. Ce projet a contribué à définir une bande de base re-configurable pour les
systèmes 3G UMTS/FDD, TDD et HSDPA/FDD. Le projet a mis plusieurs ob-
jectifs en avant, la comparaison fonctionnelle entre les standards puis l’optimisa-
tion algorithmique multi-standard pour une approche de conception de récepteur
multi-standard. Le développement de composants, accélérateurs ou ASIP pour les
opérations multi-standards.
SCOUT 2002-2004 : Smart user-Centric cOmmUnication environmenT est la suite du
projet TRUST. L’objectif du projet est l’étude des besoins et des interactions de
l’utilisateur avec un terminal radio reconfigurable [15].
IST-ADRIATIC 2001-2004 : Advanced Methodology for Designing Reconfigurable SOC
and Application Targeted IP-entities in wireless Communications. Le projet a servi à
définir une méthodologie de co-design pour le développement des applications sur un
SoC reconfigurable. Le projet a défini des besoins en reconfiguration de circuits SoC
pour les applications de traitements en bande de base pour WCDMA et HiperLAN/2
ainsi que multimédia avec un décodeur MPEG-2. Le projet a aussi fait des études
[16, 17, 18] sur les technologies reconfigurables (architectures et méthodologies) exis-
tantes pouvant satisfaire les besoins des futurs systèmes de communications.
Cette liste de projets n’est pas exhaustive, il est à noter que les informations sur certains
projets sont parfois difficiles à obtenir, les rapports étant souvent internes aux projets ;
dans d’autres cas, le site Internet du projet n’est plus maintenu.
La reconfigurabilité est une partie essentielle des futurs systèmes liés aux concepts
de radio logicielle. La diversité des projets portant sur le sujet montre que cette notion
recouvre beaucoup d’aspects décrits notamment dans [19]. Aujourd’hui, elle est désignée
comme étant une des caractéristiques majeures pour définir les systèmes de communi-
cations mobiles qui succéderont aux systèmes 3G, aussi appelés “beyond 3G systems”.
Un exemple de l’importance de cette activité de recherche est donné par le projet eu-
ropéen End-to-End Reconfigurability (E2 R) [2]. Ce projet réalisé, en 2 phases (Phase I :
2004-2005, Phase II 2006-2007), dans le cadre du FP6 est le plus important projet en
cours dans le domaine radio logicielle civile. Il s’intéresse à la reconfigurabilité dans une
approche globale, de bout en bout, (“End to End”) des systèmes de radio communica-
tion. La reconfigurabilité des futurs systèmes s’étend sur l’ensemble des couches logicielles
(transport, network, data-link and physical layers), tant au niveau des équipements utili-
sateurs qu’au niveau des réseaux et de l’offre en termes d’applications.
Actuellement le projet E2 R est en phase 2, les travaux de cette thèse sont soumis à contri-
bution [20] dans la réalisation d’un démonstrateur.
Au niveau national, une plate-forme ouverte [21] a été développée par l’institut Eu-
recom dans le cadre des projets PLATON et RHODOS. Cette plate-forme mise en place
pour le système 3G (UTRA TDD) implante sous forme logicielle entièrement program-
mable les protocoles (PHY/MAC/L3). Un nouveau projet RNRT Idromel a débuté en fin
2006. Le projet s’intéresse à l’impact des équipements reconfigurables pour le déploiement
des futurs réseaux mobiles. L’objectif est aussi de proposer à la communauté nationale et
internationale une plate-forme ouverte d’expérimentation d’équipements reconfigurables.
Nous nous intéressons dans cette étude à la reconfigurabilité des systèmes de traite-
ment numérique du signal composés de circuits électroniques. Au niveau d’un circuit de
traitement, la reconfigurabilité est selon Polydoros et al. [22] la capacité d’un circuit à
effectuer des changements structurels de son architecture de traitement. La reconfigura-
bilité traduit par exemple la flexibilité des circuits de type FPGA. Dans le cas de circuits
de type processeur la flexibilité est synonyme de reprogrammabilité. La reprogrammabi-
lité selon Polydoros et al. [22] est la capacité d’un circuit à effectuer un changement de
fonction en changeant la mémoire programme d’une architecture d’exécution donnée.
Nous utiliserons par la suite le terme de reconfigurabilité dans un sens large.
1.2 Contraintes et besoins pour les architectures systèmes

Nous avons vu dans l’introduction que le concept de radio logicielle (“idéale”) est face à des
verrous technologiques. L’un de ces verrous est la puissance de calcul des architectures de
traitement numérique. La figure 1.5 adaptée des travaux de Mitola [23] présente l’évolution
des systèmes radio logicielle avec la terminologie du SDR Forum présentée précédemment.
Cette évolution que nous pensons “idéale” vise à utiliser des processeurs généralistes
(GPP) afin d’obtenir une flexibilité maximale du système. Or dans une approche globale
d’évaluation des contraintes [24] la flexibilité des GPP a un coût très élevé en consom-
mation. Dans les systèmes embarqués cette contrainte de consommation est, et restera
forte. Quelle que soit l’évolution des performances brutes des processeurs généralistes,
il sera donc toujours nécessaire de recourir à des architectures présentant des efficacités
énergétiques meilleures pour des traitements intensifs. L’émergence de nouveaux para-
digmes architecturaux, dont le reconfigurable, représente des solutions pour répondre aux
besoins de performances et de flexibilité. Les systèmes actuels (HR) principalement basés
sur des ASIC, non flexibles, sont faiblement paramétrables et ne donnent pas cette flexi-
bilité.
La diversité des fonctions implique un besoin de flexibilité de l’architecture d’exécution,
afin que celle-ci reste aussi évolutive vers de nouveaux traitements. Les besoins des fonc-
tions à exécuter sont différents en terme de capacité de calcul, capacité mémoire, cadence
1.2 Contraintes et besoins pour les architectures systèmes 17
Fig. 1.5 – Evolutions “Idéales” des systèmes SDR en fonction des capacités matérielles
de fonctionnement. Les architectures reconfigurables ou processeurs spécialisés peuvent

donc satisfaire à la diversité apportée par les multiples standards. La diversité des appli-
cations engendre aussi des besoins en contrôle de configuration auxquels peuvent répondre
les architectures, de processeurs généralistes, orientées contrôle.
Fig. 1.6 – Besoins en ressources de traitements des systèmes RL
Un système embarqué SDR doit donc s’appuyer sur une architecture dédiée pour une
optimisation des traitements à réaliser. Cela implique que l’architecture soit hétérogène
comme le montre la figure 1.6. Ceci afin de répondre avec une bonne efficacité énergétique
à la diversité des fonctions à réaliser.
Conclusion
Dans un contexte applicatif de plus en plus multi-standard, la reconfigurabilité est, à
tous les niveaux (cf. projets européens), un axe central des recherches dans le domaine
de la RL. Parmi les défis que soulève la radio logicielle, celui de la reconfigurabilité des
plates-formes matérielles est l’un des principaux de par le fait que l’utilisation seule de
processeurs généralistes ne semble pas être une solution ni à court, ni à long terme. Une
architecture pragmatique de plates-formes sera hétérogène pour traiter, avec efficacité
énergétique, la diversité des fonctions en bande de base issues des différents standards.
Chapitre 2
Étude des standards : vers une

application multistandard
Sommaire
4.1 Les ressources matérielles . . . . . . . . . . . . . . . . . . . . . 52
4.1.1 Flexibilité des systèmes radio logicielle . . . . . . . . . . . . . . . 54
4.1.2 Systèmes à architecture matérielle fixe . . . . . . . . . . . . . . . 54
4.1.3 Systèmes flexibles à la conception . . . . . . . . . . . . . . . . . . 54
4.1.4 Systèmes flexibles à l’exécution . . . . . . . . . . . . . . . . . . . 55
4.2 Architectures des couches logicielles . . . . . . . . . . . . . . . 58
4.2.1 Couche logicielle intermédiaire : Exemple de l’architecture SCA . 59
4.2.2 SCA et architecture MODEM . . . . . . . . . . . . . . . . . . . . 61
4.2.3 La couche logicielle intermédiaire P-HAL . . . . . . . . . . . . . 62
4.3 La gestion de configuration . . . . . . . . . . . . . . . . . . . . 64
4.3.1 Nature des configurations à gérer . . . . . . . . . . . . . . . . . . 65
4.3.2 Les architectures de gestion de configuration . . . . . . . . . . . 67
Introduction aux applications multi-standards

L’environnement des communications mobiles devient de plus en plus multi-X [25]. Dans
ce terme multi-X, emprunté à Brakensiek et al. [25], le X désigne les caractéristiques
des systèmes : standards, modes, services, bandes, etc. Ces caractéristiques multi-X de-
mandent une flexibilité des systèmes pour s’y adapter. Les technologies reconfigurables
s’imposeront à mesure que le nombre de caractéristiques prises en compte dans la concep-
tion des équipements augmentera.
Multi-bandes
Un système multi-bandes supporte une ou plusieurs bandes radio utilisées par un standard
(i.e. GSM 900, GSM 1900, ou WLAN OFDM 2.4 GHz et 5 GHz, 802.11g et 802.11a). La
notion de multi-bandes est seulement importante pour la partie Front-End RF du système.
La reconfiguration de cette partie du système, qui reste encore souvent analogique, est
limitée. Cette problématique n’est pas l’objet de cette thèse.
19
20 Étude des standards : vers une application multistandard
multi-standards
Le terme standard recouvre un large ensemble de technologies mises en œuvre pour définir
un système, depuis la couche applicative définissant les types de services visés, jusqu’aux
techniques d’accès employées, en passant par le type de réseau déployé. Dans ces condi-
tions, il est difficile de donner une seule définition de ce que sera un système multi-
standards et selon Brakensiek et al. [25], un système multi-standards peut être défini
suivant plusieurs critères. Dès lors que l’interface air change, un système de radiocommuni-
cations est dit multi-standards. Dans ce cas, un système accédant à l’UMTS UTRA/TDD
et à l’UTRA/FDD est multi-standards alors qu’au niveau du cœur de réseau, le même
système est utilisé. D’un autre côté le 3GPP désigne l’UMTS comme un système basé sur
la technologie UTRA à deux techniques de duplexage, le FDD et le TDD. Enfin, le 3GPP
définit dans [26] un terminal compatible à la fois UMTS (UTRA/FDD ou UTRA/TDD)
et GSM comme bi-mode, lorsque les deux systèmes partagent le même cœur de réseau.
En outre, le 3GPP propose une classification des terminaux bi-mode décrite ci-après.
Il est donc difficile de poser une seule définition du terme multi-standards. De plus, C.
Roland propose dans sa thèse [27] de distinguer les termes norme et standard. Le terme
norme est utilisé pour nommer un type de transmission sans préciser dans quelles bandes
il s’applique, par exemple le GSM. Le terme standard est préféré lorsque les bandes de
fréquences particulières sont prises en compte ex : DCS1800, GSM900 PCS1900.
L’évolution des systèmes passera progressivement du traitement mono canal, à des systèmes
traitant simultanément plusieurs canaux (multi-canaux). Les systèmes évolueront, d’une
bande (mono standard) vers des multi-canaux et multi-bandes au fur et à mesure de
l’introduction des techniques “radio logicielle”.
Multi-modes
Un système multi-modes est défini comme la combinaison de systèmes multi-bandes et
multi-standards par Brakensiek et al [25]. Cependant, remarquons que certains standards
sont définis par plusieurs modes de transmissions, i.e. l’UMTS mode TDD mode FDD,
ou le 802.11g qui est une combinaison de modes de transmissions variés DSSS, FHSS,
OFDM. Ces terme font référence aux traitements en bande de base de la couche physique.
Un terminal multi-modes est un terminal supportant plusieurs modes de transmissions.
Un terminal multi-standards est multi-modes mais l’inverse n’est pas vrai.
Multiplex de porteuses
Un système est dit à porteuses multiples lorsqu’il supporte une transmission simultanée sur
plusieurs porteuses. Cependant, dans le cadre de systèmes radio logicielle, il est nécessaire
de distinguer deux types de signaux à porteuses multiples. Le terme de multiplex de
porteuses est donc proposé par S. Zabré et al. [28] pour faire la distinction entre un signal
à plusieurs porteuses dont l’espace entre porteuses est constant et un signal à plusieurs
porteuses dont l’écart entre porteuses est variable. Le terme utilisé pour désigner un signal
multiplex de porteuses à écart constant est multi-porteuses. Ce signal multi-porteuses (cf.
équation 2.1) n’a de sens que pour un standard, c’est le cas par exemple des signaux
OFDM.
2.1 Motivations sur les choix des standards 21

Ps
Ss (t) = rs,p (t)e2iπ(fs,0 +(p−1)ps )t (2.1)
p=1
Un signal RL, donné par l’équation 2.2, multiplex de porteuses, est un signal multi-
bandes :
s Pi
x(t) = (f emi (t) ∗ mi,p (c(t)))e2iπfi,p t (2.2)
i=1 p=1
où
– mi,p (t) est la modulation relative à la porteuse p avec
– f emi (t) le filtre de mise en forme
– s le nombre de standards
– Pi le nombre de porteuses (donc de canaux dans le cas mono porteuse) dans le
standard i
Le signal multiplex RL peut aussi se mettre sous la forme :

s
Ps
x(t) = rs,p (t)e2iπfs,p t (2.3)
s=1 p=1
Multi-usages
Nous pouvons aussi affiner les types de fonctionnement d’un terminal multi-X en s’ap-
puyant sur une classification des usages de terminaux multi-modes proposée par le 3GPP
dans le TR 21.910 [26] ; ce classement peut être étendu à des terminaux reconfigurables.
Le 3GPP considère le cas où l’utilisateur a une souscription unique aux modes supportés.
Il donne l’exemple de terminaux bi-mode GSM et UMTS en établissant 4 types de termi-
naux et en supposant que le terminal est constitué de deux émetteurs/récepteurs :
Type 1 : Un seul mode est actif, la partie radio du mode inactif ne fait aucune mesure sur
le réseau non utilisé. La sélection de mode est manuelle et réalisée par l’intervention
de l’usager. Le terminal se comporte comme un terminal mono-mode. Ce type de
terminal est parfois appelé dual-mode.
Type 2 : Lorsque le terminal mobile est connecté à un mode cela permet de faire des
mesures sur l’autre mode et de basculer automatiquement d’un réseau radio à un
autre suivant la qualité de réception, en supposant que le cœur de réseaux soit le
même.
Type 3 : Le terminal de type 3 peut recevoir simultanément plusieurs modes. Par contre
l’émission s’effectue dans un seul mode.
Type 4 : Le terminal permet à la fois de recevoir et de transmettre simultanément sur
plusieurs modes et de passer d’un réseau à l’autre automatiquement.
2.1 Motivations sur les choix des standards

Nous nous intéressons seulement à la couche physique. Nous choisissons donc de restreindre
la portée du terme multi-standards aux systèmes permettant d’accéder à plusieurs inter-
faces air. Notre étude porte donc uniquement sur les traitements en bande de base mis en
jeu dans les différents standards. Le choix des standards a donc été orienté par le souhait
d’avoir une diversité de formes d’ondes. Les différentes techniques d’accès, de multiplexage,
de modulation sont illustrées par le tableau 2.1. L’UMTS apporte une forme d’onde mono
porteuse à étalement de spectre, le GSM une mono porteuse et le 802.11g fournit un mode
multi-porteuses OFDM. Nous mentionnons en annexe, dans les tableaux B.6 et B.7 les
autres modes existants en 802.11g. Nous nous intéressons au mode OFDM du 802.11g qui
fournit les débits les plus importants.
Le choix des standards GSM, UMTS/FDD, et WLAN 802.11g est motivé en premier
lieu pour la diversité des traitements qu’ils apportent. Bien que les couches hautes ap-
plications ne soient pas l’objet de l’étude, notre choix se justifie aussi par rapport à la
complémentarité des services apportés. En effet, les trois standards offrent une diversité
de services de type voix et données de faible ou grande mobilité. Le choix de ces trois
standards nous semble donc cohérent du point de vue des services auxquels ils permettent
d’accéder, service voix pour le GSM et l’UMTS, données bas débit et services multimédia
avec une grande mobilité pour l’UMTS et un service données haut-débit faible mobilité
concernant le 802.11g.
Systèmes GSM900 DCS1800 UMTS/FDD 802.11g

Duplexage FDD FDD FDD TDD
Bande de 890-915 (VM) 1710-1785 (VM) 1920-1980 (VM) (ISM)
fréquence 935-960 (VD) 1805-1880 (VD) 2110-2170 (VD) 2400-2500
(MHz)
Largeur 2* 25Mhz 2*75 Mhz 2*60 Mhz 100 Mhz
Écart duplex 45Mhz 95Mhz 190Mhz X
∆W
Séparation 200kHz 200kHz 5MHz 5MHz
entre sous-pr :
porteuses 20/64MHz
Nb canaux 124 374 38 14
Accès Multiple TDMA TDMA CDMA CSMA
Modulation GMSK BT=0.3 GMSK BT=0.3 BPSK(VM) OFDM
QPSK(VD)
Tab. 2.1 – Caractéristiques des interfaces air des standards étudiés
Nous nous plaçons dans nos études, dans le cas d’un terminal de type 1 à l’émission
(voie montante) où un seul mode de transmission est actif, sans perte de généralité par
rapport à notre sujet d’intérêt sur la reconfiguration et sa gestion. Le terminal de type 1
reconfigurable est donc “multi-services” avec un seul mode actif simultanément.
En effet, en considérant une réalisation de ce type sur une architecture reconfigurable,
seule une chaı̂ne de transmission est implantée, à la différence des architectures de ter-
minaux dual-mode de type 1 actuelles où les chaı̂nes de transmission sont implantées
parallèlement et une seule est active. Dans la perspective de l’évolution de la classe du
terminal vers le type 4, il est nécessaire de mettre en place en parallèle un nombre de
chaı̂nes égal au nombre de modes simultanés possibles.
Le tableau 2.1 illustre aussi les principales caractéristiques des interfaces radio des trois
2.2 Le système cellulaire GSM 23
standards. En GSM et UMTS/FDD les voies montantes (VM) et descendantes (VD) sont
séparées en fréquence. En 802.11g une seule bande (la bande libre ISM(1) ) est utilisée et
la technique de multiplexage est le CSMA/CD. Nous ne traitons pas de la partie RF mais
un étage RF multi-bandes dans le cas de ces trois standards devrait couvrir une largeur
de bande d’environ 1,6 GHz.
Dans la suite de ce chapitre, les standards choisis sont présentés individuellement à
travers leurs principales caractéristiques. Nous décrivons pour chaque standard de façon
succincte sa couche physique, les détails sur chaque standard étant donnés dans l’an-
nexe B. Puis nous nous appuierons, dans le prochain chapitre sur les caractéristiques de
chaque standard pour proposer une étude des traitements bande de base d’une chaı̂ne de
transmission multi-standards.
2.2 Le système cellulaire GSM

Le GSM (Global System for Mobile Communications) est un système de communication de
deuxième génération basé sur un réseau cellulaire. Ce système opère sur plusieurs bandes
de fréquences (cf tableaux B.1), les plus connus sont GSM900 et GSM1800 reportés dans
le tableau 2.1.
2.2.1 Les caractéristiques générales du système

La bande GSM, par exemple 25 Mhz en GSM900, est divisée en 124 canaux espacés de
200khz. La méthode d’accès multiple TDMA (Time Division Multiple Access) ou AMRT
(Accès multiple par répartition en temps) permet de partager temporellement une bande
de fréquence entre de multiples utilisateurs. Cette division temporelle appelée time slot
(8 connexions voix sur un time slot) est réalisée dans une trame TDMA.
La durée d’un slot est Tslot = 0.557 ms. Sur chaque porteuse les slots sont groupés par
8, la durée de la trame TDMA est de TT DM A = 8 Tslot = 4.652 ms. Le signal électrique
formant le slot s’appelle un burst. Au niveau du mobile, l’émission et la réception des
slots sont décalées de trois time slots. Le débit par canal est de 270 kbit/s. Le GSM est un
système ouvert et les spécifications complètes définies par l’ETSI(2) en partenariat avec
3GPP(3) en charge du maintien et de l’évolution du standard. Les spécifications concernant
la couche physique et l’interface radio sont disponibles dans le document 3GPP TS 05-01
[29].
Principaux canaux logiques et physiques

Il existe dans le système plusieurs types de canaux logiques qui sont associés à divers
types de canaux physiques afin de gérer les différents types d’informations transmises
sur l’interface air. Ces informations sont générées par le trafic voix numérisée (sur le
Traffic Channel associé à un canal de contrôle SACCH). Les autres fonctions sont la
diffusion d’informations, la gestion des appels entrants et procédures associées, contrôle
des paramètres physiques de la transmission, signalisation. A chacune de ces fonctions
sont associés un ou plusieurs canaux logiques. (cf. tableau récapitulatif B.2 en annexe).
(1)
industrial, scientific and medical (ISM) radio bands
(2)
European Telecommunications Standards Institute
(3) rd
3 Generation Partnership Project
La chaı̂ne de transmission est similaire sur tous ces canaux, seuls les paramètres des
fonctions changent, définis dans le document 3GPP TS 05-03 [30].
2.2.2 Les traitements en bande de base

Les traitements de la couche physique du GSM sont présentés par le schéma 2.1.
Fig. 2.1 – Diagramme en blocs des traitements en bande de base GSM
Parmi les fonctions en bande de base, certaines sont toujours exécutées sur tous les
canaux de communications (codage en blocs, codage convolutif), et suivent divers schémas
de traitements en fonction du type d’information traitée. Des fonctions sont optionnelles,
dont l’unité de chiffrement. Enfin des fonctions ne dépendent pas du type d’information
traitée, telle que la modulation.
Codage en blocs
Les bits d’information issus de la couche supérieure sont codés avec un code en bloc
(“Coding 1 (Block)”). En sortie sont obtenus des mots d’information augmentés de bits
de parité par utilisation de codes cycliques ou codes Fire(4) . Suivant les canaux logiques,
les générateurs de CRC sont différents, les paramètres sont la taille du bloc d’information à
coder et les polynômes générateurs utilisés. Quelques exemples des polynômes générateurs
des principaux canaux sont donnés dans le tableau B.12 en annexe.
Codage canal
Le codage canal en GSM est de type convolutif (“Coding 2 (convolutional)”). Les pa-
ramètres du codage convolutif dépendent du type de canal de transmission. Ces paramètres
sont le taux d’encodage 1/2, 1/3, 1/6, la longueur de contrainte, la taille du bloc d’in-
formation et les polynômes générateurs définissant les codes. Les encodeurs utilisés sur
les principaux canaux de trafic voie sont donnés dans le tableau B.13. Les spécifications
complètes sont données dans le 3GPP TS 05.03 [30].
Entrelacement
Les fonctions d’entrelacements (“Interleaving”) sont associés aux encodeurs et de même
manière spécifiques à chaque canal logique. L’entrelacement comporte les opérations sui-
vantes : mélange des bits d’un bloc d’information et répartition des symboles brassés sur
(4)
Sur les informations transmises sur les canaux de contrôle et de signalisation, un code Fire est utilisé,
outre la détection d’erreur ce code permet une correction
2.2 Le système cellulaire GSM 25
plusieurs bursts.
Il existe trois types d’entrelaceurs appelés “block diagonal”, “block rectangular” et ‘‘dia-
gonal interleaver” [30]. Les paramètres des entrelaceurs sont le nombre de blocs ou bits
en entrée et en sortie de l’entrelaceur. Par exemple l’entrelacement sur le canal de parole
plein débit TCH/FR est un entrelacement “block diagonal”. Le bloc d’information de taille
k = 456 bits est écrit dans une matrice 57L ∗ 8C en suivant une règle de permutation
interne des bits suivante.
j = 2((49k) mod 57 + ((k mod 8))/4) (2.4)
La lecture des bits s’effectue par colonne pour constituer 8 sous blocs de 57 bits. Chaque
sous bloc est ainsi associé à un champ information d’un “Normal Burst” formant ainsi un
demi burst. Cet entrelacement est dit par bloc diagonal et est qualifié de convolutif. Un
Burst est formé avec deux sous blocs Ai de 57 bits appartenant à deux blocs de 456 bits
sur des trames différentes, de la manière suivante :
Soit n une trame :
B(0) = A4 (n − 1) ∪ A0 (n)
B(1) = A5 (n − 1) ∪ A1 (n)
B(2) = A6 (n − 1) ∪ A2 (n)
B(3) = A7 (n − 1) ∪ A3 (n) (2.5)
Les bits de B(i) sont aussi entrelacés : les bits de la trame n-1 occupent les positions
impaires et les bits de la trame n les positions paires.
Chiffrement
Les données entrelacées subissent un chiffrement qui est une fonction optionnelle (“Cryp-
tological unit”). Le chiffrement s’effectue par addition bit à bit des informations avec une
clé de cryptage conformément à l’algorithme A5 utilisé [30].
Codage différentiel
Avant d’entrer dans le modulateur, le flux binaire passe par un codeur différentiel (“Dif-
ferential encoding”). L’opération effectuée par ce modulateur utilise l’addition modulo 2
entre deux bits consécutifs di et di−1 . Les données en sortie du modulateur sont les αi :
dî = di ⊕ di−1
αi = 1 − 2dî [31] (2.6)
Modulation
La modulation utilisée en GSM est une “Gaussian Minimum Shift Keying” (GMSK) [32]
avec un BT de 0.3, le débit binaire est de 270,83 kbit/s. Le filtrage gaussien de réponse
impulsionnelle h(t) est appliqué aux données ai avant la modulation de type (“Frequency
Shift Keying”) FSK.
−t2 √
e 2δ2 T 2 ln 2
h(t) = √ avec δ = (2.7)
2πδT 2πBT
GPRS/EDGE
Le standard GSM a évolué vers les systèmes GPRS (General Packet Radio Service) et
EDGE (Enhanced Data rates for GSM Evolution) avec la possibilité d’utiliser plusieurs
time slots par communication pour augmenter le débit. EDGE utilise une modulation “8
Phase Shift Keying” (8-PSK) à 3 bits par symbole. Le tableau B.4 donne l’encodage bit à
symbole réalisé en 8-PSK. La communication réalisée sur 4 time slots permet d’atteindre
un débit 236.8 kbit/s et sur 8 time slots théoriquement un débit de 473.6 kbit/s.
2.3 Le système cellulaire UMTS/FDD

L’UMTS (Universal Mobile Telecommunications System) est l’un des systèmes de com-
munication cellulaire de troisième génération (3G). L’UMTS est standardisé par le 3GPP.
Il existe un mode FDD de duplexage en fréquence de la voie montante et descendante,
et un mode de duplexage en temps le TDD (“Time Division Duplex”). Dans son mode
de duplexage FDD auquel nous nous intéressons, l’UMTS fonctionne en Europe dans
les bandes 1900Mhz et 2100Mhz (cf. tableau B.1). Les débits supportés par ce mode vont
théoriquement jusqu’à 1920 kbit/s. Néanmoins le débit utile n’excède pas dans la pratique
384 kbit/s.
2.3.1 L’interface radio

l’UMTS est basé sur une technique d’accès multiple par répartition en code (AMRC)
large bande ou W-CDMA (“Wideband Code Division Multiple Access”). En UMTS, cette
technique permet de multiplexer par code, sur une bande de 5 Mhz, les canaux logiques
voix, données ou services. Les informations véhiculées sur la couche physique [33] en
UMTS sont séparées en canaux à l’aide de la technologie d’accès multiple par code. Sur
la couche physique, il existe deux catégories de canaux, Les canaux de transports et les
canaux physiques (cf annexe figure B.1).
Fig. 2.2 – Couche physique de l’UMTS basée sur l’étalement de spectre
Les informations transitant depuis les couches hautes vers la couche physique sont
réparties sur canaux de transport pour offrir les différents services de transport de la
liaison radio. Les traitements effectués [34] sur les informations des canaux de transport
sont un codage de correction d’erreur, le multiplexage des canaux, l’adaptation du débit,
l’entrelacement. Les canaux de transport sont ensuite combinés dans les canaux physiques
[35]. Les opérations sur les canaux physiques, décrit dans par 3GPP TS 25-213 [36], sont
2.3 Le système cellulaire UMTS/FDD 27
l’étalement de spectre consistant à la canalisation suivie d’un embrouillage, puis d’une

modulation.

Le diagramme en blocs de la figure 2.3 présente les fonctions en bande de base de
la voie montante de l’UMTS/FDD. Les fonctions appliquées aux canaux logiques sont
représentées dans la partie supérieure du diagramme en blocs 2.3. Les fonctions appliquées
aux canaux physiques sont représentées dans la partie inférieure. Nous détaillons dans la
suite uniquement les opérations sur les canaux physiques. Le codage canal met en jeu des
fonctions similaires à celle que l’on retrouve dans les autres standards. Elles sont décrites
en annexe B.2.
Fig. 2.3 – Diagramme en blocs des traitements en bande de base de l’UMTS
Étalement de spectre
L’étalement de spectre consiste en deux opérations de codage comme l’illustre la figure 2.4.
Le premier codage est l’étalement avec un code de canalisation, la seconde opération est
l’application d’un code d’embrouillage sur la séquence étalée. En UMTS après l’étalement
de code le débit dit “chip” est de 3.84M chip/s. L’étalement est effectué sur des trames
radio de 10 ms contenant donc 38400 chips.
Fig. 2.4 – Étalement sur les voies montantes DPCCH et DPDCH [36]
Les codes de canalisation OVSF (“Orthogonal Variable Spreading Factor”) permettent

de distinguer les canaux physiques. Les utilisateurs sont distingués par les codes d’em-
brouillages. Les principaux codes utilisés en UMTS sont détaillés dans le tableau B.5.
Sur la liaison montante, la figure 2.4 illustre l’opération d’étalement qui transforme les
symboles en chips avec un code alloué (code de canalisation) pour les canaux DPDCH
(données) et DPCCH (contrôle). Ces chips sont ensuite combinés ensemble. Une partie
des canaux est combinée sur une voie I et l’autre ensemble de canaux est combiné sur
la voie Q. Les deux voies I et Q sont ensuite multipliées entre elles. Les chips de valeurs
complexes ainsi obtenus sont embrouillés par un code d’embrouillage complexe.
– Codes de canalisation : La taille du code de canalisation est variable, c’est le fac-

teur d’étalement ou “spreading factor” (SF). Sur la voie montante, les utilisateurs
peuvent utiliser les mêmes codes de canalisation car les émissions ne sont pas syn-
chronisées. Le débit chip constant est fixé à 3,84 MHz, le débit symbole est donc
adapté par le choix de la valeur du SF. Le débit symbole maximal est atteint pour
une valeur de facteur d’étalement la plus petite, sur la VM (SF=4). Un facteur
de pondération (non représenté figure 2.4) quantifié sur 4 bits est affecté à chaque
séquence chip étalée par un code de canalisation.
– Code d’embrouillage : Tous les canaux physiques de la voie montante sont em-
brouillés à l’aide d’un code à valeurs complexes.
Modulation Après l’étalement de spectre chaque chip complexe subit une mise en
constellation QPSK puis un filtrage de type RRC, décrit dans [37], avant la mise sur
porteuse.
Filtre de mise en forme Le filtrage numérique est de type cosinus surélevé (RRC
Root Raised Cosine) avec un facteur α = 0.22 (roll-off).
La réponse impulsionnelle du filtre est RC0 (t) :

sin π Ttc (1 − α) +4α Ttc cos Ttc (1 + α)
RC0 (t) = 2 (2.8)
π Tc 1 − 4α Tc
t t
Avec un temps chip est égale à Tc :
Tc = 1/débitchip ≈ 0.26042µs
2.4 Le système de réseaux sans fil WLAN 802.11g

Les systèmes WLAN (Wireless Local Area Network) ont le même type de fonctionnement
que les réseaux LAN mais offrent une couche physique d’accès radio. Les standards les
plus connus sont définis par l’IEEE dans la série des spécifications 802.11. L’HiperLAN
et l’HiperLAN2 sont les standards européens définis par l’ETSI, semblables au 802.11b et
802.11a.
2.4.1 Les évolutions de l’IEEE 802.11

Le 802.11 est une couche physique qui a été définie par des évolutions successives de
techniques d’accès utilisées. Il en résulte que de nombreux modes ont été normalisés. Un
rapide historique permet de les présenter.
2.4 Le système de réseaux sans fil WLAN 802.11g 29
Le 802.11 a été initialement définit en 1997 par l’IEEE dans [38]. Cette norme WLAN/1G
spécifie la couche MAC commune à l’ensemble des couches physiques d’accès à l’interface
air définies depuis. Cette première version définit trois couches physiques distinctes, dont
deux sont à étalement de spectre direct et une à infrarouge.
En 1999, l’extension IEEE 802.11b [39] dans la bande ISM 2.4 GHz, en 1999 également
l’extension IEEE 802.11a est définie [39] pour des bandes de fréquence dans les 5 GHz.
Puis en 2003, dans le 802.11g [40] de nouveaux modes de transition haut débit dans la
bande 2.4 GHz sont définis. Les spécifications de la couche physique OFDM 802.11a ont été
reprises et adaptées à la bande 2.4 GHz sous le nom de ERP-OFDM (Extended Rate PHY
OFDM) et offrent des débits de 6 à 54Mbit/s. Le 802.11g offre aussi une compatibilité
descendante avec les spécifications antérieures.
La dernière évolution des spécifications du IEEE 802.11 est en cours de standardisation,
le 802.11n. Cette version MIMO est prévue pour fonctionner dans les deux bandes 2.4
GHz et 5 GHz.
Les spécifications des modes transmissions des différentes interfaces radio sont reportées
en annexe dans deux tableaux B.6 et B.7.

Nous avons choisi de présenter le mode ERP-OFDM du 802.11g. Les traitements en bande
de base mis en jeu dans ce mode sont illustrés par le diagramme 2.5.
Fig. 2.5 – Diagramme en blocs des traitements en bande de base du 802.11g mode OFDM
Le mode ERP-OFDM de fonctionnement utilise une modulation multi-porteuses de

type OFDM (“Orthogonal Frequency Division Multiplex”). Le mode ERP-OFDM reprend
les spécifications du mode OFDM de 802.11a, en les adaptant à la bande 2.4GHz. La
spécificité au niveau des traitements en bande de base dans ce standard par rapport aux
deux précédents est la modulation OFDM.
Embrouillage
La fonction d’embrouillage (“scrambling”) utilise un polynôme générateur, équation 2.9
identique pour l’embrouillage et le désembrouillage. Les données “data in” sont blanchies
par une addition modulo-2 avec une séquence “scrambled seq” créée par le générateur,
comme l’illustre la figure 2.6.
S(x) = x7 + x4 + 1 (2.9)
Fig. 2.6 – générateur de séquence d’embrouillage en 802.11g
Codage canal
Les caractéristiques du codage canal de type convolutif et d’entrelacement pour l’adap-
tation des données sont décrites en détails en annexe B.3.1. Le codeur convolutif utilisé
dans le mode OFDM est unique.
Mise en constellation
La mise en constellation est effectuée après l’entrelacement. Plusieurs encodages sont
possibles BPSK, QPSK, 16-QAM ou 64-QAM et permettent d’atteindre différents débits.
Les encodages bits à symboles effectués par ces mises en constellations sont respectivement
détaillés en annexe dans les tableaux (B.8, B.9, B.10, B.11).
Modulation OFDM
La modulation OFDM est illustrée par la figure 2.7.
Après la mise en constellation, une conversion série à parallèle permet de répartir 48
symboles en entrée de la FFT. La modulation OFDM en 802.11g est réalisée par une
FFT sur 64 points comportant 52 sous porteuses dont 4 sont des sous porteuses pilotes.
Les 4 sous porteuses pilotes sont modulées en BPSK et les 48 sous-porteuses utiles sont
celles modulées en BPSK, QPSK, 16-QAM ou 64-QAM. La sortie de la FFT est ensuite
convertie de parallèle à série pour la mise sur fréquence porteuse.
Un symbole OFDM est donc constitué de 52-4=48 symboles numériques. Le symbole
OFDM à une durée de Ts = 4.0µs avec un intervalle de garde GI = 0.8µs.
Les principales caractéristiques de l’OFDM en 802.11 sont récapitulées dans le tableau
2.2.
2.4 Le système de réseaux sans fil WLAN 802.11g 31
Fig. 2.7 – Modulateur OFDM, répartition des porteuses
Paramètres Valeurs
Fréquence porteuse 2,4 GHz
Largeur de bande 20 MHz
Fréquence d’échantillonnage Ts = 1/20 M hz = 50 ns
Nombre de points FFT 64
Nombre de 52=48+ 4 pilotes
sous-porteuses utiles
Période symbole OFDM 4µs (80 Ts )
Taille du préfixe cyclique 0.8µs (16 Ts )
Période symbole FFT 3.2µs 64 Ts )
Durée d’une trame 500 symb. OFDM
taille d’un LCH : 54 octets
“Packet Data Unit” SCH : 9 octets
Tab. 2.2 – Tableau récapitulatif des caractéristiques de OFDM du 802.11g

Conclusion
La présentation des couches physiques des trois standards a montré la diversité des fonc-
tions utilisées d’un standard à l’autre. Pour illustrer cette diversité nous avons choisi des
standards de systèmes cellulaires de générations différentes 2G (GSM) et 3G (UMTS), et
de transmission sans fil (802.11g), donnant des services voix et données.
Nous pouvons dégager plusieurs remarques de cette présentation des standards. Les bandes
de fréquences allouées aux standards sont toutes différentes, sauf dans la bande ISM où
coexistent plusieurs standards. Les modules analogiques, antennes, amplificateurs sont
très différents, la définition d’un front-end RF commun à tous les standards est donc
difficilement envisageable à court terme. Cependant cette question relative à l’étage ra-
dio fréquence est hors de cette étude centrée sur les traitements numériques en bande de
base. Dans le prochain chapitre, nous présenterons les études visant à réduire le très grand
nombre de fonctions de traitement présentes dans ces multiples standards par des tech-
niques de paramétrisation. Nous proposerons ensuite, par une approche de factorisation,
une chaı̂ne de traitement commune à ces trois standards.
Chapitre 3
Analyse radio logicielle des

applications multi-standards
Sommaire
5.1 Double chemin de données : configuration/traitement . . . . 76
5.2 Modèle de la voie de gestion de configuration . . . . . . . . . 78
5.2.1 Le niveau hiérarchique 1 . . . . . . . . . . . . . . . . . . . . . . . 79
5.3 Le modèle de la voie de traitement . . . . . . . . . . . . . . . . 84
5.3.1 Le fonctionnement d’un composant de traitement . . . . . . . . . 85
5.3.2 Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Introduction
Précédemment, nous avons présenté séparément les 3 standards choisis et nous avons
constaté la diversité des traitements qu’ils donnent. Une chaı̂ne de traitement multi-
standards doit pouvoir donner accès à toutes les fonctions des standards visés. Le change-
ment de fonction sera supporté au moment de l’implantation de celle-ci par différents
mécanismes : par changement de paramètres, par le chargement d’un nouveau code
d’exécution, par reconfiguration.
Quel que soit le type de mécanisme utilisé pour effectuer ce changement, il est important
de minimiser son coût par une analyse multi-standards au niveau algorithmique. En effet,
des traitements similaires sont appelés entre les différents standards, où nous retrouvons
systématiquement par exemple un codage canal, un entrelacement, une modulation.
Dans cette partie nous présentons au paragraphe 3.1 les différentes approches d’études
des similitudes. Ces études proposées dans la littérature sous le terme de paramétrisation
sont réalisées aux niveaux, fonction ou opérateurs. Nous discuterons sur l’impact des ces
approches sur la conception d’une chaı̂ne entière. Puis nous présenterons au paragraphe
3.2 une approche pragmatique que nous nommons de “factorisation” basée sur l’étude
tri-standard GSM/UMTS/802.11g-OFDM et nous proposons une chaı̂ne unifiée multi-
standards.
33
34 Analyse radio logicielle des applications multi-standards
3.1 Introduction aux études de paramétrisation

L’objectif général des études de paramétrisation est de mettre en évidence dans un pre-
mier temps, les traitements “les plus populaires” réalisés dans une chaı̂ne de traitement.
On les appelle traitements communs (“Common Processing”) réalisés dans les chaı̂nes
de transmission de différents standards. Avec l’idée que ces traitements communs soient
d’un niveau de granularité le plus élevé possible. Ce type de recherches au niveau algorith-
mique est nécessaire pour exploiter les concepts sur les similarités et les communités(1)
entre traitements très tôt dans la conception d’applications multi-standards. Le terme
de paramétrisation utilisé en radio logicielle recouvre différentes approches d’étude de
traitements communs. Ces approches bien que différentes ont pour objectif de mettre en
évidence les similitudes entre standards dans les traitements à réaliser. On peut distin-
guer deux approches en paramétrisation, émergées de la littérature, l’approche fonction
commune et l’approche opérateur commun.
3.1.1 Fonctions communes

Le premier type de paramétrisation est l’approche appelée fonctions communes. L’analyse
des similarités se fait au niveau fonction. Le but de ce type d’approche est de définir des
structures de traitements, sortes de macro-fonctions paramétrables communes à plusieurs
standards. Une liste de paramètres est associée à la fonction et permet de déterminer son
mode de fonctionnement, parmi un ensemble de modes.
Fig. 3.1 – Fonction de modulation paramétrable [41]
Les travaux de A. Wiesler et al. [42], [41] proposent des structures paramétrables pour
les fonctions de modulation d’égalisation communes aux standards GSM, DECT, UMTS
UTRA/FDD et IS-136. Cet exemple de fonction commune est illustré figure 3.1. Les tra-
vaux menés par la même équipe de recherche ont conduit A.-R. Rhiemeier à proposer
une approche fonction commune de codage canal [43]. Dans ce type d’approche, toutes
les informations sur les standards visés doivent être connues au moment de la conception
de la structure commune. L’avantage est qu’il est suffisant de stocker un nombre limité
de paramètres pour décrire plusieurs modes de fonctionnement et que le temps de chan-
gement de modes est négligeable.
(1)
Le fait, pour certains matériels, d’avoir des caractères communs, du point de vue de la conception, de
la fabrication et de la maintenance, l’ensemble de ces caractères, Journal officiel du 30 janvier 2005
3.1 Introduction aux études de paramétrisation 35
D’autres exemples de structures s’apparentant à des fonctions sont décrits dans la littérature,
telle que l’architecture nommée VITURBO [44] proposant une structure unifiée de décodage
de Viterbi et de turbo décodage pour les systèmes 3G. Cependant A.-R. Rhiemeier [43]
décrit aussi les limites d’une telle approche. L’inconvénient est que la structure ne peut
être changée et ne peut pas supporter de nouveaux standards. De plus au moment de
l’exécution, il y a toujours certains blocs de traitement, non requis par les paramètres
sélectionnés, qui restent inactifs. Alors que des modes de coupures d’alimentation sont
aisément réalisables sur des fonctions entières, il est plus difficile d’imaginer de couper
l’alimentation sur des sous-blocs d’une même structure. La structure consomme donc
dans sa totalité, il en résulte une perte d’efficacité énergétique. Le coût en surface de
telles structures peut aussi être significatif.
3.1.2 Opérateurs communs

L’approche opérateur commun se situe à un niveau de granularité intermédiaire entre
fonction commune et opérateur arithmétique classique. La philosophie consiste à élever
le niveau de granularité des opérateurs communs qui pourraient intervenir dans plusieurs
standards de communication. L’approche opérateur commun consiste donc à définir des
structures de calcul ou à utiliser celles existantes pour les appliquer à un grand nombre de
fonctions. En effet, l’analyse de différentes chaı̂nes de transmission a montré que certains
motifs de traitement sont utilisés dans plusieurs fonctions. Palicot et al. [45] introduisent
cette notion d’opérateur commun en radio logicielle en donnant l’exemple du papillon
FFT4. Dans l’objectif de réutiliser au maximum cet opérateur, certaines fonctions peuvent
être réalisées dans le domaine fréquentiel, et tirer bénéfice d’une architecture matérielle
disposant de papillons FFT performants. Notamment A. Al Ghouwayel [46] propose une
paramétrisation de l’opérateur FFT dans le champ de Galois pour la réalisation d’un
encodeur Reed-Salomon.
3.1.3 Multiplexage de fonctions

Nous pouvons mettre en perspective les deux approches de paramétrisation avec une
approche plus classique de réalisation de traitements multi-standards à l’aide du tableau
comparatif 3.1.
Fonction Fonction Opérateur Fonction

fixe reconfigurable commun commune
Performance +++ ++(+) + ++(+)
Surface -- ++ ++ -
Consommation Énergétique -- ++ ++ -
Temps de changement de contexte +++ – + +++
Potentiel de réutilisabilité -- ++ +++ +
Complexité de conception +++ ++ -- +
Tab. 3.1 – Comparatif des approches de conception des multi-traitements
De manière classique une fonction multi-standards peut être réalisée par multiplexage
de plusieurs fonctions dédiées sans recherche de parties communes. En utilisant des tech-
nologies de type ASIC, toutes les fonctions dédiées sont alors implantées en parallèle.
En utilisant un circuit reconfigurable par exemple FPGA, le multiplexage des fonctions

peut-être réalisé par reconfiguration d’une fonction. Nous verrons plus en détails les ap-
proches de conception de composants reconfigurables sur FPGA, dans la partie relative
aux méthodologies de conception chapitre 6.
3.1.4 Chaı̂ne de traitement commune

Avec l’approche “fonction commune” présentée précédemment, chaque bloc fonctionnel
ainsi défini est considéré séparément dans la chaı̂ne de traitement.
Fig. 3.2 – Chaı̂ne de traitement multi-standards basée sur des fonctions dédiées
En utilisant de telles fonctions la démarche de conception d’une chaı̂ne multi-standards

est alors de mettre les blocs fonctionnels à suivre séparément. Il est alors aisé d’utiliser
des mécanismes de basculement pour passer d’une bande de base à l’autre. Cependant
lors d’une implantation l’occupation en surface d’une telle solution peut-être élevée. Il est
à noter que cette approche de conception d’une chaı̂ne multi-standards peut aussi être
réalisée sur des fonctions multiplexées basées sur les “approches classiques” de conception
de fonctions. Ce type de chaı̂ne est représenté par une succession de fonctions (cf. figure
3.2).
CCTrCH
TrCH (multiple instances)

TrCh
Mux
TDD
Channel
Coding
TDD
FDD Bit Scrambling
Radio Frame
Equalisation
Mux
Physical channel
1. Interleaver
Segmentation
Radio Frame 2. Interleaver

Segmentation
FDD TDD
TDD & FDD UL FDD PhCh TDD PhCh

Rate Matching Mapping Mapping
Mux
Fig. 3.3 – Voie montante Tx UMTS FDD/TDD (projet Mumor, extrait de [47])
Un exemple d’implantation d’une chaı̂ne complète basée sur des fonctions communes,
figure 3.3, a été réalisé dans le projet MuMor [14]. Ce projet a étudié les standards UMTS
FDD/TDD et HSDPA de la même “famille” 3G, HSDPA étant une évolution de l’UMTS,
il en résulte des similitudes naturelles entre les standards. Les fonctions propres à chaque
3.1 Introduction aux études de paramétrisation 37
standards sont multiplexées.
La définition d’une chaı̂ne de fonction multi-standards unifiée peut s’arrêter à la

définition de fonctions communes et fonctions multiplexées. Toutefois une telle chaı̂ne
de traitement est commune à un nombre limité de standards. Ceci n’est pas suffisant pour
garantir que sa structure soit évolutive vers d’autres standards.
D’un autre côté, les études s’appuyant sur l’approche “opérateurs communs” considèrent
l’ensemble des blocs de traitement d’une chaı̂ne pour définir ces opérateurs. Les opérateurs
peuvent alors être partagés entre plusieurs blocs fonctionnels d’une chaı̂ne multi-standards.
Fig. 3.4 – Modélisation d’un système radio multi-standards sous forme de graphe [48]
A Supélec, des travaux proposés sur la recherche de communités sont basés sur des
graphes d’opérateurs [48]. Ces graphes à plusieurs niveaux de granularité permettent de
formaliser les études de paramétrisation. L’objectif de telles études est une optimisation
des graphes afin de déterminer les coûts des implantations des chaı̂nes multi-standards
basées sur des opérateurs plus ou moins gros grains. Nous pouvons alors situer aux 2
extrémités de tels graphes, les deux approches extrêmes [48] pour réaliser une chaı̂ne
multi-standards.
L’approche “Velcro” permet de supporter plusieurs standards en se basant sur quelques
fonctions de grande granularité de chaque standard. Lorsque la granularité d’une fonction
d’un opérateur augmente alors son efficacité augmente par une implantation plus opti-
misée, mais la réutilisabilité à travers plusieurs standards diminue. A l’autre extrémité, la
façon de pouvoir supporter tous les standards est d’utiliser les opérateurs de granularité
fine (add, mult, mac, etc.). Les opérateurs de granularité plus fine sont plus réutilisables
car communs à de nombreux traitements. Mais la complexité d’une fonction basée sur
l’appel à des opérateurs de grains fins est très élevée.
L’étude des graphes aide à déterminer le compromis qui consiste à augmenter l’efficacité
de traitement (en temps d’exécution, occupation matérielle) tout en conservant au maxi-
mum la modularité et la réutilisabilité des opérations de traitement.
Le graphe illustré à la figure 3.4 est un sous-graphe montrant la décomposition de plu-

sieurs fonctions de traitement (“equalisation”, “channelisation” (notée “multi-channel”)
et “OFDM”) mis en jeu dans de multiples standards. Ce graphe montre quelques unes
des alternatives pour réaliser ces fonctions en utilisant différents sous blocs de traitement.
Notamment, dans cet exemple la FFT peut être utilisée pour réaliser ces fonctions. Il
pourra alors être judicieux de réaliser une implantation particulièrement optimisée de
cette fonction afin de réduire le coût global en surface de la réalisation.
Les études en cours à Supélec se focalisent dans un premier temps sur les traitements
de couche physique sur laquelle sont les plus fortes contraintes, mais ce type d’études
peut s’étendre pour être appliqué à l’ensemble des couches protocolaires d’un système de
communication.
3.2 Etude de la chaı̂ne de transmission tri-standards 39
3.2 Etude de la chaı̂ne de transmission tri-standards

Nous proposons dans les paragraphes suivants, notre étude d’une chaı̂ne de transmission
multi-standards. Cette étude est basée, de façon volontaire sur des standards dont les
caractéristiques sont très différentes. Dans un premier, temps nous proposons une fac-
torisation fonctionnelle des trois chaı̂nes étudiées. Puis nous proposons une classification
des traitements multi-standards en fonction des cadences de traitement et natures des
données traitées.
Fig. 3.5 – Vers une chaı̂ne de transmission multi-standards unifiée
3.2.1 La factorisation fonctionnelle

L’objectif de la factorisation fonctionnelle proposée ici est de définir une chaı̂ne de traite-
ment commune en s’appuyant sur les trois standards GSM/UMTS/802.11g-OFDM. Notre
étude porte donc sur la flexibilité à atteindre dans une chaı̂ne afin de répondre à la diver-
sité des traitements. Nous avons donc choisi de nous intéresser aux traitements en bande
de base à l’émission de trois standards reflétant une grande diversité et une moindre com-
plexité, en vue d’une réalisation, en comparaison avec la réception.
Nous avons mis en correspondance chaque chaı̂ne de traitement des 3 standards

étudiés, dans la partie gauche de la figure 3.5. Ces chaı̂nes présentent fonctionnellement un
certain nombre de fonctions similaires tel que le présente la colonne centrale des fonctions
appelées multi-standards. Les fonctions de types multi-standards sont présentes dans au

moins 2 des trois standards. Dans la partie droite de la figure se trouvent les fonctions
que nous avons identifiées comme spécifiques à chaque standard par rapport aux 2 autres.
Les fonctions dont le nom est “Data structuring” sont des fonctions différentes. Ce sont
des fonctions de structuration de données pour former les trames de données, adapter la
taille des blocs, concaténer ou segmenter les blocs. Nous avons groupé ces fonctions en
une classe de traitement “Data structuring” présentée dans le paragraphe suivant.
Fig. 3.6 – Chaı̂ne de transmission multi-standards unifiée
Nous proposons d’ajouter les parties spécifiques (à droite figure 3.5) à la partie des
fonctions multi-standards afin d’obtenir une chaı̂ne multi-standards unifiée. Cette chaı̂ne
est présentée figure 3.6.
Sans distinction de cible d’exécution à ce niveau, chaque fonction de cette chaı̂ne unifiée est
reconfigurable, figure 3.7, afin de répondre aux changements de configuration nécessaire
pour passer d’un standard à un autre. Dans le cas des fonctions non présentes dans les 3
standards un configuration “Identité” est nécessaire pour rendre la fonction transparente.
Le fait que les fonctions de la chaı̂ne soient reconfigurables permet de la rendre évolutive
contrairement aux solutions paramétrables.
Fig. 3.7 – Fonction reconfigurable de la chaı̂ne unifiée
La décomposition en blocs fonctionnels nous a permis d’identifier un premier niveau

de factorisation entre certaines fonctions des 3 standards et de proposer une chaı̂ne de
traitement unique. Ensuite, nous proposons d’inclure un second niveau de factorisation
pour chaque fonction. En effet, certaines structures de calcul sont relativement simples
à identifier entre les différentes configurations d’une même fonction. Le ou les éléments
de calcul ainsi identifiés communs à l’ensemble des configurations d’une fonction peuvent
alors être fixés et sont non reconfigurables. De même un mode de fonctionnement iden-
tifié comme régulièrement utilisé peut être fixé et mis en parallèle du reste de la fonction
reconfigurable. C’est le cas du mode transparent dans l’exemple de la figure 3.7.b.
En substance, l’approche de factorisation est une approche pragmatique entre l’ap-

proche “fonctions communes” qui représente une solution paramétrable et l’approche plus
modulaire “opérateurs communs” où des blocs peuvent être définis communs entre plu-
sieurs fonctions. De même, le multiplexage de configurations de fonctions peut-être mis
en œuvre dans la chaı̂ne lorsque la fonction présente des modes régulièrement utilisés.
Exemple
La figure 3.8 montre la chaı̂ne unifiée dans le mode 802.11g où la fonction de modulation
OFDM est détaillée en sous blocs. Par exemple l’implantation sur FPGA de cette fonction
peut suivre un scénario dans lequel tous les blocs sont fixes à l’exception du bloc FFT64
reconfigurable.
Fig. 3.8 – Chaı̂ne de traitement unifiée et détail du modulateur OFDM
La reconfigurabilité d’un bloc peut être utilisée pour changer ses paramètres de traite-
ment et aussi pour changer les conditions de fonctionnement du bloc. En 802.11g, l’OFDM
décrit au chapitre 2.4 est toujours basée sur une FFT64, alors la reconfigurabilité du bloc
FFT64 peut servir à changer d’architecture de FFT afin de donner d’autres comporte-
ments en terme de cadence de traitement et en consommation. Dans ce sens, une étude
connexe aux travaux de cette thèse a été réalisée en collaboration avec David Elléouet
de l’Université de Rennes I à l’IETR INSA. Cette étude, décrite en annexe A.2, porte
sur l’estimation de consommation sur FPGA d’une FFT64 suivant différentes architec-
tures afin d’offrir par la suite différents compromis performance / consommation par la
reconfiguration dynamique. Dans cette étude nous avons aussi mesuré et pris en compte
la consommation de la reconfiguration d’une cible FPGA.
3.2.2 Classification en groupe fonctionnel

L’analyse fonctionnelle de factorisation des traitements est une étape importante dans
l’analyse multi-standards afin de mutualiser les traitements de sorte à réduire le nombre
de configurations et de ressources. Dans un second temps, il est aussi nécessaire de prendre
en compte d’autres critères que la fonctionnalité. Pour cette classification, proposée dans
[49], les critères de diversité de configurations des fonctions, la dynamique des données
et la nature des opérateurs utilisés par les différentes fonctions sont retenus. Ainsi selon
ces critères, nous proposons donc un classement des traitements en bande de base des 3
standards en 3 classes de traitements tel que le présente le tableau 3.2.
Class of GSM 900 UMTS /FDD 802.11g

Functions (Uplink) (Uplink) (OFDM Mode)
Coding -Block Coding -CRC Coding -CRC Coding
-Conv. Coding -Conv. Coding -Scrambling
-Interleaving -Turbo Coding -Conv. Coding
-Crypto -(1st , 2nd ) -Interleaving
Interleaving
Data -Reordering -Block Concat. -Puncturing
Structuring -Partitioning -Block Segment. -Phy Burst
-Burst Building -Frame Equal. forming
-Burst -Frame Segment.
Multiplexing -Rate Matching
-TrCh. Multiplex.
-PhyCh Segment.
Modulation -Diff. Encoding -Spreading -Mapping
-LGP Filtering -Scrambling -IFFT,
-Mapping -Cyclic Pref.
-RRC Filtering & Pilot Inser.
-Symbol shaping
Tab. 3.2 – Classement fonctionnel des traitements multi-standards à l’émission
Ces trois classes fonctionnelles regroupent les traitements de modulation “Modulation

Class”, de codage “Coding Class” et les traitements de manipulations de données “Data
Structuring Class”. Chacun de ces 3 groupes fonctionnels est commun aux 3 standards
visés.
• La classe de fonction nommée “Coding Class” regroupe les fonctions de codage canal,
comme le codage cyclique, convolutif ou turbo. Cette classe est caractérisée par la
diversité des schémas de codage à gérer. Les fonctions traitant des informations
de type bit sont souvent basées sur des structures de calcul utilisant des registres
linéaires à décalage et des opérateurs modulo2.
• Les fonctions entrant dans la classe “Data structuring Class” sont des fonctions
de mise en forme de données. Les fonctions réalisées sont des traitements orientés
contrôle, réalisant des concaténations, segmentations ou le multiplexage de paquets
de données de tailles variables. Ces fonctions manipulant des données nécessitent en
premier lieu des ressources de mémoire.
• Les fonctions liées à la modulation sont regroupées dans une classe appelée “Modu-
lation Class”. Les fonctions de cette classe correspondent aux traitements réalisés
avant la transposition en fréquence du signal. Ces fonctions de ce groupe telles que
le filtrage de mise en forme sont les fonctions nécessitant le plus de ressources de
calculs.
Le partitionnement matériel / logiciel n’est pas l’objet de cette étude bien que cela
soit une part importante dans la conception des systèmes hétérogènes. Néanmoins nous
proposons cette classification qui permet de dessiner l’orientation des besoins en termes
architecture de traitements selon chaque groupe fonctionnel comme le présente la figure
3.9. Le principal besoin des fonctions de la classe “Coding” est la flexibilité de l’architecture
d’exécution pour répondre à la diversité des schémas de codage. Le besoin des fonctions
de la classe “Data structuring” est la capacité mémoire pour la manipulation de données.
Le besoin des fonctions de la classe “Modulation” est la capacité de calcul de l’architecture
d’exécution.
Fig. 3.9 – Orientation des architectures par rapport aux besoins fonctionnels
La complexité des traitements bande de base et la cadence de fonctionnement des

différentes fonctions déterminent les capacités de calcul nécessaires afin de répondre aux
contraintes de temps d’exécution. Ce critère est essentiel dans le choix d’une cible d’exécution.
Les cadences de fonctionnement sont différentes suivant le groupe de fonctions. Selon
le standard de communication une même fonction nécessite des cadences de traitement
différentes.
Les complexités globales des différents standards ont été estimées dans plusieurs études.
Notamment l’étude [50] rapporte une complexité du 802.11g de 4 500 MIPS(2) , pour
l’UMTS une complexité de 3 500 MIPS, celle du GPRS de 400 MIPS. Une autre étude
[51] estime la complexité du GSM à 10 MIPS, celle du GPRS à 100 MIPS, EDGE à 1 000
MIPS, l’UMTS à 10 000 MIPS et le WLAN-OFDM à 5 000 MIPS. Au delà des différences
d’estimations entre les études, nous pouvons constater que les variations de complexité
entre standards sont élevées. L’un des facteurs de cette variation est la différence de débit
entre les différents standards. A cause d’un haut débit de 54 Mbps le 802.11g-OFDM est
celui qui requiert la plus grande capacité de calcul. Ensuite en UMTS le débit “chip” est
de 3.84 Mcps alors qu’en GSM le débit est de 270 kbps.
De plus, la cadence de fonctionnement varie sur l’ensemble de la chaı̂ne de traitement
et en fonction des modes de traitement. En effet, pour le 802.11 OFDM et l’UMTS les
débits sont variables. Les estimations précédemment citées sont donc réalisées pour le débit
maximal atteint par chaque fonction. En UMTS, les cadences des traitements effectués
avant la fonction d’étalement dépendent du facteur d’étalement. Le cas le plus contrai-
gnant vient lors de l’utilisation du code d’étalement le plus petit (V M : SFm in = 4).
Avec ce facteur d’étalement SF=4, la cadence des fonctions effectuées avant l’étalement
est donc de 0.96 M Sym/s.
Sur l’exemple de la fonction d’encodeur convolutif commune aux 3 standards nous pou-
vons comparer les différences de besoins entre standards. Les estimations du tableau 3.2.2
de complexité est réalisée en calculant le nombre d’opérations (opération arithmétique,
accès mémoire) effectuées par un traitement séquentiel de la fonction, de manière identique
aux calculs de complexité réalisés dans le cadre du projet IST EASY [52] sur le standard
HiperLAN. Les paramètres des encodeurs convolutifs sont donnés dans le tableau B.13.
Pour l’UMTS, le tableau 3.2.2 donne le cas “test case” du TS 25.101 chap. A2-4 [37], pour
le GSM le cas de l’encodeur utilisé sur le canal TCH/HS, le 802.11g présente un unique
encodeur.
802.11g UMTS GSM
Standard
(DCCH) (TCH/FS)
Taille du bloc de 288 bits 120 bits 267 bits
données d’entrée
Débit requis de la 54 Mbps 0.96 Mbps 12 kbps
fonction
8 XOR 15 XOR 5 XOR
Nombre d’opérations 18 SRA 30 SRA 12 SRA
1 In RA 1 In RA 1 In RA
2 Out RA 3 Out RA 2 Out RA
Complexité de calcul 1566 MOPS 47 MOPS 228 kOPS
Tab. 3.3 – Complexité de l’encodeur convolutif
La grande variation des cadences de traitements suivant les standards peut entraı̂ner
des solutions de partitionnement très différentes pour une même fonctionnalité et des
changements de partitionnement en cours d’exécution. Par la suite, nous avons suivi une
approche de scénarios pour proposer un partitionnement matériel / logiciel de la chaı̂ne
(2)
Million d’Instruction Par Seconde
de traitement. Cette approche basée sur des scénarios décrits au chapitre 7.2.3 permet
de dégager les besoins en terme d’architecture de la plate-forme et aussi les besoins de
gestion de configuration décrits.
Un exemple d’architecture adaptée à la réalisation des fonctions de “Modulation” sera

de type accélérateur matériel dédié. L’architecture d’exécution effectuant les fonctions
du “Data structuring” nécessite un maximum de flexibilité afin de traiter des blocs de
données de tailles différentes mais ces fonctions demandent peu de spécialisation. Une
architecture de processeur associé à de la mémoire répond à ces besoins. Un processeur
spécialisé peut permettre de répondre à la diversité des fonctions de “Coding”.
Afin de continuer la discussion sur les besoins il serait intéressant de poursuivre l’étude
sur les fonctions à la réception. Mais cela n’est pas l’objet de cette étude. Nous pouvons
néanmoins constater que les chaı̂nes à la réception incluent des traitements additionnels
tels que l’estimation de canal et la synchronisation. Il en résultera donc une chaı̂ne com-
mune à la réception avec plus de traitements complémentaires. La plus grande complexité
des traitements en réception requiert aussi plus de capacités de calcul par rapport à celles
nécessaires pour les traitements à l’émission.

multi-standards
Nous avons fait, dans les paragraphes précédents, l’analyse des fonctions de traitements
en bande de base afin de rendre flexible une chaı̂ne de traitement. Notre approche de
factorisation et la proposition d’une chaı̂ne unifiée a pour objectif de réduire le coût de
la flexibilité en réduisant le nombre de configurations d’une chaı̂ne de traitement multi-
standards et de réduire les coûts en ressources matérielles (recherche de communités), cela
aussi dans le but de réduire le nombre de configurations à gérer. Une fois le nombre de
configurations réduit, il est aussi nécessaire de minimiser le coût de la reconfiguration pour
changer de contexte. Dans un premier temps, nous avons donc identifié différents besoins
de changements de contexte que nous décrivons ci-dessous. Par la suite, nous proposons
au chapitre 5 une structure de gestion de configuration permettant une gestion de recon-
figuration optimisée où seuls les blocs de traitements spécifiques au nouveau contexte par
rapport au précédent se verront modifiés afin d’éviter un rechargement total du contexte
d’exécution.
Les changements de contexte de la couche physique que nous avons identifiés pour une
chaı̂ne radio logicielle sont les suivants :
– Changement de Standard : Un changement complet de standard implique une
refonte profonde de la chaı̂ne de transmission. Les chaı̂nes de transmissions entre les
standards étant très différentes, c’est le type de changement de contexte qui demande
les plus larges reconfigurations. Il est à noter qu’un changement de standard concerne
aussi les couches supérieures du modèle OSI.
– Changement de Mode : Certains standards spécifient plusieurs modes de fonc-
tionnement. Un basculement de mode est donc un changement de contexte intra-
standard alors qu’un changement de standard est un changement inter-standard.
Dans la plupart des cas, le changement de mode ne concerne donc pas les couches
hautes. Les paramètres du changement de mode pour la couche physique sont
déterminés par la couche MAC. Par exemple, le standard 802.11g possède plusieurs
modes de fonctionnement DSSS, FHSS, OFDM.
– Changement de Service : Un changement de service sur la couche physique reste
un changement de contexte intra-standard contrairement à un service switch au ni-
veau applicatif pouvant entraı̂ner un standard switch. Ce changement peut corres-
pondre par exemple à une demande de changement de débit, la chaı̂ne de traitement
est généralement peu modifiée. Ce changement peut-être effectué par paramétrage
ou par reconfiguration d’une partie des fonctions. Par exemple en mode OFDM du
802.11g, lors d’une demande d’augmentation de débit de 6Mbit/s à 54Mbit/s, la
fonction de mapping change respectivement de BPSK à 64-QAM.
– Amélioration de performance, correction d’erreur : La possibilité de changer
un motif de traitement en vue de l’amélioration de ses performances ou dans le but
de corriger une erreur peut correspondre à divers types de situations. La possibilité
de réaliser ce type de petits changements nécessite la mise en place de règles de
développement des algorithmes par composants de traitements rendant leur reconfi-
guration possible de manière indépendante. Ceci nécessite en outre la mise en place
de mécanismes de contrôle afin de limiter la discontinuité de traitement occasionnée.
Les changements d’architectures de calcul évoqués dans l’exemple de la FFT sont
aussi inclus dans cette catégorie.
L’analyse des différents besoins de changement de contexte, effectuée ci-dessus, a mis

en évidence qu’il existe différents niveaux de granularité des changements de contexte. Il
est donc nécessaire de pouvoir gérer cette multi-granularité au niveau de la reconfiguration
de l’architecture système afin d’en améliorer l’efficacité. Nous proposons dans le chapitre
5, une architecture de gestion de configuration hiérarchique répondant à ces besoins de
gestion de la multi-granularité de configuration liés aux applications radio logicielle.
Conclusion
En radio logicielle, le bénéfice d’une analyse algorithmique des similitudes s’accroı̂t à me-
sure que le nombre de standards pris en compte augmente. Chaque fonction présente un
ensemble limité de techniques. Le tableau de synthèse B.14 montre par exemple que sur
un grand nombre de standards les techniques de la mise en constellation sont en nombre
limité. Le taux de réutilisation des techniques de traitement augmente donc potentielle-
ment à mesure que le nombre de standards considérés augmente.
Les implantations matérielles tirant partie des similitudes entre traitements, permettront
de minimiser les coûts de changements de configuration et seront optimisées en terme de
surface. Le nombre de configurations d’une application multi-standards à gérer ayant accès
à toutes les fonctions et exploitant les similitudes entre traitements sera réduit. Des études
concernant la réalisation d’opérateurs communs sur cible sont en cours. Par exemple dans
le cadre du réseau NEWCOM Loı̈g Godard, en thèse à Supélec, a effectué une étude en
partenariat avec l’Université d’Aix-la-Chapelle (RWTH) et l’UPC pour définir des ASIP
(Application Specific Instruction Processor) conçus autour d’opérateurs communs.
Notre étude a porté sur les chaı̂nes à l’émission qui sont très orientées flot de données.
Il en résulte donc une chaı̂ne unifiée de même nature. Il sera donc préférable de s’orienter
vers des architectures d’exécution flot de données. De l’autre côté, il est aussi nécessaire
de privilégier la flexibilité généralement donnée par des circuits plus orientés contrôle.
Ce sont donc des compromis performance / flexibilité / efficacité énergetique qu’il est
nécessaire d’établir lors de la conception d’un système radio logicielle.
Nous proposons donc de présenter dans la partie suivante les technologies suscep-
tibles de répondre aux besoins de flexibilité de ces applications multi-standards. Nous
avons choisi de nous intéresser à trois parties constitutives et fondamentales des futures
plates-formes RL. Ces parties sont les architectures matérielles, les architectures logi-
cielles et les architectures de gestion de configuration. Ces éléments du système apportent
chacun une flexibilité aux systèmes et doivent être obligatoirement associés de manière
complémentaire.
Nous présentons donc dans un premier temps, un état de l’art portant sur ces 3 parties
des systèmes radio logicielle et nous verrons à travers les travaux effectués quelle flexibilité
est apportée par les différentes parties de ces systèmes.
Le second chapitre présente notre contribution pour apporter de la flexibilité au système
RL à travers la modélisation d’une double chaı̂ne de traitement destinée a être exécutée
sur une plate-forme matérielle hétérogène. Cette chaı̂ne de traitement comprend une voie
constituée de blocs reconfigurables dédiés aux traitements en bande de base. Cette voie
reconfigurable est surmontée par une voie dédiée à sa gestion. L’architecture de gestion
de configuration hiérarchique que nous proposons s’appuie notamment sur l’étude des
besoins de reconfigurabilité des applications multi-standards, précédemment menée.
Deuxième partie
Systèmes reconfigurables pour la

radio logicielle
Chapitre 4
Architectures systèmes radio

logicielle
Sommaire
6.1 Intégration de l’application flot de données sur plate-forme
hétérogène . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
6.1.1 Reconfiguration dynamique . . . . . . . . . . . . . . . . . . . . . 97
6.1.2 Reconfiguration partielle de FPGA . . . . . . . . . . . . . . . . . 100
6.2 Approches de conception d’IP reconfigurable sur FPGA . . . 104
6.3 Flots de conception d’IP reconfigurables sur FPGA . . . . . . 109
6.3.1 Flot : “Module-Based Partial reconfiguration” . . . . . . . . . . . 110
6.3.2 Flot : “MoDiff-Based Partiel Reconfiguration” . . . . . . . . . . 111
6.3.3 Flot : “Partial Reconfiguration” . . . . . . . . . . . . . . . . . . . 113
6.3.4 Connexion d’une région reconfigurable . . . . . . . . . . . . . . . 115
6.3.5 Création d’une macro . . . . . . . . . . . . . . . . . . . . . . . . 118
6.4 Etude de cas : la fonction de filtrage FIR . . . . . . . . . . . . 121
Introduction
Nous avons choisi de nous intéresser aux architectures des systèmes radio logicielle en
distinguant 3 grandes parties illustrées schématiquement figure 4.1. La partie basse cor-
respond à la couche matérielle composée des ressources matérielles hétérogènes de la plate-
forme RL. La plate-forme supporte une partie intermédiaire constituée de couches logi-
cielles de service. Une partie importante et spécifique aux systèmes RL est la gestion de
configuration permettant d’exploiter la reconfigurabilité potentielle de la plate-forme et
d’offrir la capacité aux applications d’évoluer en cours d’exécution.
Nous donnons dans ce chapitre un aperçu des technologies émergentes pour définir les 3
parties d’un système radio logicielle. Dans un premier temps, nous donnons un aperçu des
différents types de circuits existants et émergents du point de vue du type de flexibilité
qu’ils apportent à un système radio logicielle. Puis nous proposons de nous intéresser à
l’architecture des couches logicielles intermédiaires qui sont progressivement intégrées sur
les plates-formes matérielles. Ces couches logicielles sont amenées pour fournir des services
51
52 Architectures systèmes radio logicielle
visant à faciliter l’intégration d’applications toujours plus complexes sur des plates-formes
matérielles hétérogènes aussi de plus en plus complexes à programmer. Les couches lo-
gicielles intermédiaires ont d’autres objectifs, tels qu’apporter l’interopérabilité entre les
applications et les plates-formes matérielles.
Fig. 4.1 – 3 parties d’un système radio logicielle
Cependant suivant la couche logicielle, la “souplesse” logicielle a de nombreux coûts :

poids et consommation de la couche logicielle, latence de transmission des données. Nous
proposons aussi à travers la présentation du P-HAL (“Physical-Hardware Abstraction
Layer”) conçu par l’UPC [53], une couche logicielle intermédiaire d’un faible encom-
brement, la description de services apportés par une couche d’abstraction. Enfin, une
présentation de différentes architectures de gestion de configuration, partie essentielle des
systèmes RL, est faite en dernière partie de cet état de l’art sur les systèmes radio logicielle.
4.1 Les ressources matérielles

Les plates-formes matérielles radio logicielle suivent l’évolution de l’offre des circuits. Dans
ce paragraphe, nous allons donner un aperçu de quelques architectures et circuits poten-
tiellement candidats aux traitements numériques en bande de base. Nous présentons les
architectures suivant la flexibilité qu’elles apportent aux systèmes radio logicielle.
Flexibilité : La flexibilité est la capacité d’un système (radio logicielle) à répondre à

des changements de contexte. Ce mot générique est utilisé pour désigner les caractéristiques
d’un applicatif à répondre aux besoins de changements de services (changement de l’accès
dû à la mobilité, changement du taux d’erreur binaire). Le terme est aussi utilisé pour
désigner la capacité des circuits à changer de traitements (par exemple changement des
traitements de la couche physique pour répondre à un changement de réseau d’accès).
Le terme de flexibilité introduit donc des notions distinctes telles que la reconfigurabilité
/ reprogrammabilité, l’adaptabilité, la modularité. Une définition des termes flexibilité,
adaptabilité et reconfigurabilité (FAR) est proposée dans [22] dans le cadre du projet
4.1 Les ressources matérielles 53
européen WIND-FLEX.
Fig. 4.2 – Ressources matérielles hétérogènes d’un système radio logicielle
Historiquement, les circuits disponibles sont les circuits spécialisés de type ASIC et
les processeurs (GPP et DSP). Les ASIC présentent de hautes performances de traite-
ment mais leur manque de flexibilité est un handicap dans la définition d’un système
RL. A l’opposé, la programmabilité des circuits de type processeurs en font les cibles
les plus flexibles. Mais cette flexibilité a un coût, notamment en consommation, et les
performances des processeurs peuvent être insuffisantes face aux demandes de traitement
du signal des applications complexes. Le manque d’efficacité énergétique par rapport aux
performances peut alors être un frein pour l’intégration de ces circuits dans des systèmes
embarqués.
Fig. 4.3 – Modèle d’architecture de plate-forme SoC du projet Adriatic
L’architecture de plate-forme définie autour de ressources hétérogènes, illustrée par

exemple figure 4.3 présente divers type de flexibilité et de performances est la solution
aux différents besoins RL proposée dans le projet Adriatic. L’architecture du SoC reconfi-
gurable issue du projet Adriatic est bien représentative du besoin en ressources matérielles
hétérogènes des applications multi-standards. Dans le projet Adriatic, ce modèle d’archi-
tecture reconfigurable a permis d’accueillir les couches physiques d’un système Hiperlan/2,
ainsi qu’une application multimédia de décodage source (MPEG-2).
4.1.1 Flexibilité des systèmes radio logicielle

Nous avons vu que le terme flexibilité recouvre plusieurs notions. Nous distinguons plu-
sieurs types de systèmes apportant diverses flexibilités logicielle ou matérielle. Nous allons
par la suite détailler les systèmes suivants :
Les systèmes dont la flexibilité est amenée uniquement par logiciel, à la conception et à
l’exécution, sont appelés à architecture matérielle fixe. Il existe ensuite des systèmes dont
la flexibilité à la fois matérielle et logicielle est donnée au moment de la conception, ils
sont nommés systèmes flexibles à la conception. Enfin, le dernier type de système présenté
est celui dont la flexibilité matérielle est apportée au moment de l’exécution, ces systèmes
sont appelés systèmes flexibles à l’exécution.
4.1.2 Systèmes à architecture matérielle fixe

Les systèmes SDR à architecture matérielle fixe sont constitués de modules matériels stan-
dards, non modifiables ni au moment de l’exécution ni à la conception, typiquement de
processeurs de type GPP (cf. annexe C.5.1) ou DSP (cf. annexe C.5.2). Néanmoins ces
architectures peuvent offrir de la flexibilité logicielle à deux niveaux. La reprogrammabi-
lité des processeurs offre la flexibilité logicielle à la conception. En utilisant des couches
logicielles, telles que le SCA décrit par la suite, la flexibilité sur les fonctions logicielles
de haut niveau peut être obtenue à l’exécution. Il est à noter qu’une couche logicielle du
type SCA s’appuie sur une architecture matérielle fixe.
Les technologies processeurs sont matures (outils, architectures), pour cette raison
l’industrie s’est tournée en premier lieu vers ce type de circuit pour proposer des solu-
tions dédiées à la RL. La société Sandbridge Technologies [54] propose une famille de
processeurs SB3000 de traitements en bande de base. Ces processeurs Sandblaster [55]
sont capables de supporter les combinaisons des standards GSM, W-CDMA, CDMA200,
TD-SCDMA, Bluetooth, WLAN, WiMax. La flexibilité est uniquement introduite par le
logiciel développé par l’utilisateur et modifiable à l’exécution. De même, Intrinsity [56] est
une autre société basée aux USA, proposant des processeurs de traitement destinés aux
systèmes SDR. Les processeurs de traitement du signal FastMATH [57] sont basés sur une
architecture avec un coeur de type “central processing unit” (CPU) et une matrice de co-
processeurs mathématiques. Cette architecture “dual-core” est par ailleurs très similaire
au processeur de la famille SB3000.
4.1.3 Systèmes flexibles à la conception

La flexibilité des architectures suivantes est à la fois logicielle et matérielle au moment
de la conception. La flexibilité à l’exécution est donnée par le logiciel. Ces architectures
sont constituées de modules matériels standards ou des modules spécifiques définis à la
conception. Les ASIP (Application Specific Istructrion Processor) [58] (cf. annexe C.5.3)
représentent une famille de processeur, dont le concepteur d’application peut déterminer
le jeu d’instructions afin qu’il corresponde aux applications visées. Les instructions d’un
ASIP peuvent prendre la forme de co-processeurs câblés.
L’université de Twente aux Pays-Bas propose une architecture SoC hétérogène constituée
d’un cœur de processeur généraliste (ARM), d’un accélérateur FPGA, et d’une matrice
d’éléments de calculs appelée FPFA [59]. Chaque élément de calcul nommé tuile reçoit son
flot d’instructions propres et permet des calculs en parallèle. Chaque tuile est constituée
d’une ALU configurable, d’une mémoire programme, d’une mémoire locale, d’une unité
de contrôle et une unité de communications.
Dans ce type de technologies, les outils de conception des architectures de processeurs
et ensuite de compilateurs associés jouent un grand rôle afin de pouvoir exploiter les
spécificités du circuit défini. Adelante propose sa technologie Galaxic DSP. Cette tech-
nologie comprend une famille de cœurs de DSP ouverts, des co-processeurs spécifiques
pour applications et les outils de développement “C-based Atmosphere”. Cette techno-
logie associée aux plates-formes Nexperia de Philips offrent une solution système pour
l’implantation d’applications SDR. Les co-processeurs peuvent notamment être spécifiés
à la conception et fournissent une flexibilité matérielle supérieure à celle des accélérateurs
spécifiques prédéfinis.
4.1.4 Systèmes flexibles à l’exécution

La flexibilité à l’exécution peut être obtenue par le logiciel ou par le matériel.
Approche de paramétrisation
Les architectures définies suivant l’approche de paramétrisation proposée par Jondral et
al. [42] offrent une flexibilité matérielle à la frontière avec les architectures matérielles
reconfigurables. Nous avons décrit cette approche dans le paragraphe 3.1 en soulignant
que les applications visées doivent être connues au moment de la conception. Ensuite
l’architecture de l’application définie est paramétrable en cours d’exécution. Harada et al.
[60] proposent une implantation d’un récepteur multi-modes contrôlé par des paramètres.
Architectures reconfigurables
Les architectures reconfigurables pour les applications de traitement du signal offrent les
capacités de faire des changements structurels d’éléments de calculs câblés. Compton et
al. [61] font un examen des principes et des principales caractéristiques des architectures
reconfigurables.
Fig. 4.4 – Rapport flexibilité/performance des architectures

Les travaux en matière d’architectures reconfigurables sont très prolifiques depuis

quelques années. Nous y consacrons ce paragraphe.
En effet, l’espace de conception entre processeurs et ASIC laisse place à d’autres para-
digmes architecturaux dont l’objectif est de remplir les compromis flexibilité/performance
(cf. figure 4.4) attendus par les nouvelles applications.
Ces paradigmes architecturaux sont regroupés sous l’appellation d’architectures reconfigu-
rables ou “Configurable Computing”. L’idée des architectures reconfigurables est apparue
relativement tôt dans l’histoire de l’électronique. En effet, c’est en 1960 que G. Estrim [62]
propose une première architecture reconfigurable, (cf. figure C.4), mais il a fallu attendre
l’émergence des technologies SRAM au début des années 1980 avant de véritablement voir
apparaı̂tre des circuits intégrés reconfigurables. L’architecture de G. Estrim, composée
d’une partie fixe et d’une partie variable (figure C.4), est intéressante car elle préfigure de
nombreuses architectures SoC reconfigurables conçues d’une partie fixe avec un processeur
et de co-processeurs ou accélérateurs de grain gros ou fin reconfigurables.
Aujourd’hui de nombreuses propositions d’architectures reconfigurables sont du même
type, des parties reconfigurables associées à un processeur comme unité de contrôle. Ces
architectures ont été classées par L. Bossuet [63] dans la catégorie architecture multi-
grains à processeur plus coprocesseur.
Il existe d’autres types d’architectures reconfigurables et les projets sont nombreux dans
ce domaine devenu un important sujet de recherche. C’est pourquoi, d’importants travaux
de classification [64, 65, 63, 66] ont été effectués ces dernières années.
En 2001, R. Harteinstein [64] donne une étude rétrospective d’une décennie de projets en
architectures reconfigurables. Cette étude concerne plus particulièrement les architectures
reconfigurables à gros grains. D’autres études présentent aussi bon nombre de projets par
exemple dans [65]. J.P. David [67] analyse dans sa thèse les architectures reconfigurables
et propose un classement en 3 grandes catégories, les architectures reconfigurables gros
grains sans processeurs, les architectures gros grain avec processeur et les architectures
grain fin.
Plus récemment, L. Bossuet [63] propose une classification des architectures reconfigu-
rables suivant les caractéristiques de granularité des ressources de traitement, granularité
des ressources de communication, topologie du réseau de routage, couplage avec un mi-
croprocesseur. Les caractéristiques de granularité, de couplage avec un processeur et de
reconfigurabilité sont aussi proposées par Ben Chehida [66] en vue d’une classification
des architectures. Il présente trois grandes familles, les architectures reconfigurables au
niveau porte logique, fonction et système. Par ailleurs Srikanteswara et al. [68] propose
une synthèse sur les architectures reconfigurables pour les applications radio logicielle.
Pour les applications de radio communications nous pouvons citer par exemple les
architectures, DReAM (Dynamically Reconfigurable Architecture for Mobile System) [69]
sur laquelle un exemple d’implantation [70] d’un recepteur rake pour l’UMTS a été réalisé.
MorphoSys [71] est une architecture de type processeur RISC et coprocesseur reconfigu-
rable de type matrice 8x8 de cellules de calcul reconfigurable. Les travaux [72] décrivent
MorphoSys II et l’implantation sur cette architecture d’un récepteur OFDM. Au niveau
national, SystolicRing [73] architecture reconfigurable dynamiquement pour les systèmes
sur puce a été développée par le laboratoire LIRMM de l’Université de Montpellier et
DART [74] architecture reconfigurable dynamiquement pour applications mobiles a été
développée au laboratoire LASTI de l’Enssat de Lannion. Les architectures reconfigu-

rables gros grain développées par l’industrie sont moins nombreuses, nous pouvons citer
l’architecture PicoArray proposée par Quicksilver Technologie. Une architecture recon-
figurable de type multi-grains avec un processeur+coprocesseur [75] est développée par
Universitaet Karlsruhe et la société PACT XPP Technologies.
Cependant, dans ce domaine très actif, de nombreuses architectures voient le jour sans
jamais aboutir à des circuits. De plus, le manque d’outils associés à ces nouvelles architec-
tures est un inconvénient majeur au développement des applications et limite la diffusion
de ces circuits. Ceci est particulièrement valable concernant les architectures à gros grain,
ne bénéficiant pas du développement fait sur les outils dédiés aux architectures à grain
fin tirés par l’industrie des FPGA.
Effectivement, dans le vaste espace de conception d’architecture reconfigurable, les cir-

cuits les plus répandus et disponibles commercialement sont les FPGA. L’architecture des
FPGA (cf. annexe C.5.4.1) est de type grain fin. Ils sont parfois classés dans la catégorie
des architectures reconfigurables généralistes (General Purpose Programmable Logic) ceci
leur permet de répondre potentiellement à une grande variété d’applications.
Cependant, nous pouvons constater une augmentation de la granularité des architectures
de FPGA. Des blocs câblés de calcul, de mémoire, sont progressivement intégrés aux
architectures, par exemple des multiplieurs câblés 18x18 sur des Xilinx Virtex-II et des
blocs DSP48 sur Virtex-4. Cette tendance s’accompagne donc par une spécialisation des
familles de FPGA en domaines d’applications. Ainsi Xilinx a introduit, avec ses dernières
générations de FPGA Virtex-4, les architectures ASMB (Advanced Silicon Modular Block)
donnant 3 familles de FPGA. Les Virtex-4 -LX sont orientés logique programmable et res-
tent généralistes. Les Virtex-4 -SX intègrent des blocs DSP en plus grand nombre pour les
applications traitement de signal. Les Virtex-4 -FX possèdent des cœurs de processeurs
pour les applications plus orientées contrôle.
Les FPGA de larges capacités offrent la possibilité de concevoir des architectures hétérogènes
complexes SoC/SoPC intégrant des processeurs embarqués soft ou hard, de large capacité
mémoire, des accélérateurs dédiés basés sur des blocs logiques ou des blocs spécialisés don-
nant les différents types de flexibilité, logicielle, matérielle, à la conception ou à l’exécution.
La grande flexibilité de conception d’architectures SoPC permet de répondre aux besoins
de flexibilité des applications radio logicielle tout en offrant des capacités de calculs élevées.
Selon M. Cummings [76] le compromis performance/flexibilité apporté par les FPGA

en fait un bon candidat pour les applications radio logicielle par rapport aux ASIC et DSP.
Nous nous sommes particulièrement intéressés à ce type de circuits et leur mise en oeuvre
dans les applications radio logicielle. Nous avons donc privilégié Xilinx pour les capacités
offertes de ses FPGA. Ce fabricant est aussi particulièrement impliqué dans le domaine
de la radio logicielle par exemple par sa participation au SDR Forum. La flexibilité des
FPGA dépend aussi des méthodologies de conception utilisées pour en tirer partie. Nous
reviendrons plus en détails sur les implications des méthodologies de conception des FPGA
sur la flexibilité donnée à un système radio logicielle dans le chapitre 6.
4.2 Architectures des couches logicielles

L’augmentation de la part de conception logicielle dans le développement des systèmes ra-
dio est expliquée par des raisons économiques et techniques décrites dans [77]. L’intégration
de couches logicielles intermédiaires représente une tendance dans l’évolution des systèmes
embarqués. De façon générale, les couches logicielles intermédiaires apportent une abstrac-
tion des ressources matérielles et ressources logicielles de bas niveau. Elles visent à fournir
des services pour faciliter l’interopérabilité, l’intégration et la réutilisabilité des applica-
tions. Les deux concepts d’interopérabilité et réutilisabilité des applications, notamment
mis en avant par Mitola en 1995 [1], sont essentiels à la définition de système radio logi-
cielle.
– L’interopérabilité implique la définition d’architectures (matérielles et logicielles )
ouvertes utilisant des interfaces de communications standardisées. L’interopérabilité
permet à des composants issus de différents développements sur différentes plates-
formes de fonctionner entre eux.
– La réutilisabilité des applications implique des règles de conception communes four-
nies à travers des interfaces de programmation (“Applications Programming Inter-
face”, API) indépendantes des ressources matérielles.
Fig. 4.5 – Couches logicielles intermédiaires des systèmes RL
L’introduction de couches logicielles intermédiaires dans les systèmes radio répond

donc aux différentes considérations évoquées précédemment. En parallèle, les langages de
hauts niveaux comme Java et les exécutifs, OS et couches intermédiaires, (Linux, Corba)
évoluent vers des versions dédiées aux systèmes embarqués. Dans le même temps, un im-
portant effort, notamment apporté par le SDR Forum, de modélisation des systèmes RL
(cf. annexe C.1) est réalisé à l’aide d’outils de conception de haut niveau (UML). Cette
modélisation permet une formalisation des spécifications des systèmes RL en vue d’une
standardisation. La figure 4.5 montre un modèle en couches complet, issu de l’architecture
logicielle de référence SCA [78]. A l’image du modèle OSI pour les réseaux, l’intégration
des couches logicielles intermédiaires peut être adaptée suivant les services et le niveau
4.2 Architectures des couches logicielles 59
d’abstraction souhaité dans le système RL. La figure 4.6 présente plusieurs niveaux d’abs-
traction.
Fig. 4.6 – Plusieurs niveaux d’abstraction des couches logicielles intermédiaires
Les couches intermédiaires (les termes middleware ou intergiciel sont aussi employés)
se trouvent dans diverses applications où sont mis en jeu des composants hétérogènes. Les
couches logicielles intermédiaires fournissent aussi un cadre d’application (“application fra-
mework”), offrent de nombreux avantages pour l’intégration d’application. Cela facilite le
développement et la collaboration des composants par la standardisation des interfaces de
communication. La couche logicielle fournit aussi une interface de programmation (API).
Cette interface met à disposition des mécanismes de programmation permettant d’assurer
indépendamment le développement des applications et l’évolution de la plate-forme.
L’utilisation de couches logicielles intermédiaires dans les systèmes RL est largement

discutée [79], [80] depuis plusieurs années dans la communauté scientifique. Nous avons
évoqué ci-dessus des raisons pour justifier cette évolution des systèmes radio. Les couches
logicielles sont introduites afin de rendre la cible d’exécution transparente par rapport à
la partie applicative et ainsi augmenter la portabilité des composants radio logicielle et
leur réutilisabilité. L’abstraction de l’architecture matérielle permet de rendre l’application
indépendante du matériel sur lequel elle est exécutée. Ainsi le développeur de l’application
pourra augmenter la réutilisation de son application sur diverses cibles matérielles. La
complexité de cette couche d’abstraction dépend des fonctionnalités qu’elle offre. Les
couches logicielles intermédiaires les plus complexes ont pour objectif de proposer une
architecture logicielle standardisée permettant une interopérabilité et une évolutivité des
parties matérielles et logicielles d’un terminal. Cette tendance est portée principalement
par le projet SCA, référence et première proposition (militaire à l’origine) de ce type de
couche logicielle.
4.2.1 Couche logicielle intermédiaire : Exemple de l’architecture SCA

Nous avons souligné que le SCA vise à rendre transparent les détails de la plate-forme
matérielle aux applications. Cette couche fournit un niveau d’abstraction élevé se situant
dans le cas fig.4.6.a et assure la portabilité des applications sur toute la gamme des plates-
formes compatibles avec la couche logicielle.
Nous présentons le modèle de référence SCA (Software Radio Architecture) de couches

logicielles intermédiaires. En fait, le SCA ne représente pas les spécifications d’un système
mais définit un ensemble de règles de conception de systèmes SDR.
Historiquement le premier projet sur les couches logicielles pour la radio logicielle vient
des recherches initiées par le “Departement of Defence” américain (DoD) dans son pro-
gramme “Joint Tactical Radio System” (JTRS). Ces recherches ont donné lieu au projet
de système radio logicielle PMCS (“Programmable, Modular Communications System”)
dont la définition d’une architecture logicielle est une partie essentielle. Le SDR Forum a
ensuite repris ces travaux afin de les adapter et assurer l’évolution et la promotion du SCA
dans l’ensemble de la communauté scientifique. Le SCA provenant de ce projet PMCS est
ainsi devenu la référence en architecture logicielle dans le domaine des radiocommunica-
tions et deviendra un élément incontournable de la conception des futurs systèmes RL.
Pour ces raisons nous avons donc choisi de le décrire succinctement.
Maintenant reconnu comme un standard ouvert et non-propriétaire, le SCA est défini
par un ensemble de règles dont l’évolution est maintenue par le JTRS et le SDR Forum.
La version actuelle du SCA v3.3 se trouve dans des documents de référence décrivant les
règles de conception à l’aide du langage de description UML.
L’architecture du SCA se forme d’une couche d’application et d’une couche appelée “Ope-
rating Environment” (OE Layer). Cette couche OE se compose d’un RTOS, d’une couche
ORB CORBA, et d’un Core Framework, comme illustré par le modèle en couches au
centre de la figure 4.5. Par ailleurs plus de détails sont donnés en annexe C.2. Le SCA
définit le standard d’implantation des applications (formes d’ondes) par :
– La standardisation des interfaces logicielles (APIs) et matérielles.
– La standardisation de la définition des services, OS, format des messages (CORBA),
Core Framework.
La couche logicielle rend la plate-forme matérielle transparente par :
– L’encapsulation du matériel à l’aide de drivers logiciels.
– L’utilisation d’un bus logiciel ORB (“Object Request Broker”) s’appuyant sur la
norme CORBA (Common Object Request Broker Architecture)
Le choix d’architecture en couches (cf. fig. 4.5) permet d’isoler chaque partie du système
depuis l’application jusqu’aux ressources matérielles. La couche de niveau n fournit une
interface standardisée et un ensemble de services à la couche n+1 la rendant indépendante
des spécificités de la couche n − 1. Ainsi modélisée en couche, l’architecture est à même
de répondre aux exigences de reprogrammabilité, modularité, interopérabilité de la radio
logicielle. A l’image du modèle OSI, cette architecture logicielle s’adapte en fonction des
implantations systèmes et n’est en aucun cas un modèle unique.
Ce type d’architecture est supporté par une couche matérielle généralement articulée
autour d’une structure de bus de type VME, PCI, cPCI et de modules matériels standards
VME/cPCI. Le système d’exploitation temps réel (RTOS), (i.e. LinuxRT, QnX, VxWorks,
etc. ), fournit des services aux couches supérieures et les drivers de la couche matérielle.
Il est à noter que les architectures de type SoC ne sont pas bien gérées par les OS actuels
et que le SCA a été défini à l’origine pour être supporté par des processeurs généralistes.
Des travaux pour définir des systèmes d’exploitation destinés aux architectures SoC re-
configurables hétérogènes sont donc importants. Par exemple, Nollet et al. propose un tel
OS [81] nommé OS4RS.
Au dessus du RTOS est ajouté un Object Request Brocker (ORB) (i.e. CORBA,
DCOM, JAVATM RMI, etc.). CORBA est utilisé dans le cas du SCA. Un ORB fournit
des mécanismes de formatage standardisé des messages passant les communications inter
processus et permet ainsi de relier des composants entre eux à travers des plates-formes
diverses. Le “Core Framework” (CF) composé des spécifications des interfaces et d’un
“profile” est une description des informations de configuration matérielle et logicielle de
la plate-forme. La couche de contrôle permet de gérer les ressources et services fournis par
la plate-forme.
Pour résumer, les principaux services des couches logicielles sont la virtualisation des
ressources matérielles, la standardisation des interfaces de communications entre com-
posants, la gestion des configurations des composants. La définition d’interfaces de pro-
grammation est une partie essentielle à l’émergence de systèmes radio logicielle comme le
décrit [82]. Nous décrivons dans la suite, les couches fournissant des services spécifiques
aux systèmes radio logicielle, la couche middleware et la couche de contrôle de la plate-
forme incluant la gestion de configuration.
4.2.2 SCA et architecture MODEM

Nous avons déjà souligné que la couche logicielle SCA est spécifiée à l’origine pour être
supportée par des plates-formes seulement multi-processeurs GPP. En effet, le SCA est
basée sur CORBA qui ne gère pas nativement les circuits spécialisés de type DSP ou
FPGA. Or ces circuits sont utilisés dans les modules modem. Pour étendre le support de
CORBA à l’intérieur du modem, il est nécessaire que chaque circuit du modem supporte
le bus logiciel CORBA utilisé afin de faire collaborer des composants logiciels exécutés sur
différents circuits. Or les circuits de type DSP et FPGA sont non compatibles CORBA. Il
est donc nécessaire de prévoir des extensions à CORBA à l’intérieur des architectures du
modem. Pucker et al. [83] propose l’ajout d’un adaptateur réalisé sur GPP. Ces adapta-
teurs ou ‘‘logical device” jouent le rôle de pont entre le bus logiciel CORBA et l’interface
de programmation spécifique au circuit. Ces adaptateurs rendent possible l’instanciation
et le contrôle des composants à travers CORBA pour les DSP ou les FPGA. Une entité
supplémentaire est nécessaire afin de gérer ces “Logical Devices”. Ce gestionnaire ou “de-
vice manager” exécuté sur le GPP du modem est lancé au démarrage de celui-ci, puis à
son tour est chargé de l’instanciation de chaque “logical device”. Au sein d’un modem, le
chemin de données entre les composants doit supporter des débits élevés et des temps de
latences faibles. La connexion directe entre circuits est souvent la seule solution mais est
incompatible avec le SCA. Toujours selon les travaux de [83] les auteurs proposent deux
techniques. La première technique consiste à ajouter un adaptateur dit “cumulative logical
device” permettant la connexion de ports entre les adaptateurs de circuits afin de main-
tenir la compatibilité avec le SCA. Cette technique par connexion directe pour maintenir
des débits élevés entre composants réduit la flexibilité de la plate-forme radio. L’autre
réponse à ce problème de connectivité, par ailleurs soulevée dans [84] et [85], est l’ajout
de bus rapide comme RapidIO entre les circuits. Les connexions entre circuits sont définies
dans les processeurs logiques associés aux circuits. Ainsi les communications entre compo-
sants de traitements sont établies via les “logical device”. Cette technique compatible SCA
donne le maximum de flexibilité. Aussi d’autres travaux proposent l’extension du SCA à
d’autres circuits que les processeurs généralistes. La technologie Spectra ICO (Integrated
Circuit Object Request Broker) développée par Prism Tech(1) est une version de CORBA
pour un processeur embarqué sur un FPGA. En effet, il est possible de rendre les FPGA
compatibles CORBA, sans l’aide de processeurs extérieurs jouant le rôle de proxy, lorsque
ceux-ci offrent la possibilité de mettre en oeuvre des processeurs embarqués. Xilinx pro-
pose aussi une telle solution avec d’autres partenaires sur des plates-formes Virtex-4 où
le SCA “Operating Environment” est exécuté sur un PowerPC 405 embarqué. Dans cette
implantation, le SCA OE se compose d’un RTOS “POSIX-compliant” (de Green Hills IN-
TEGRITY), du middleware CORBA OrbExpress (de Objective Interface Systems) et d’un
SCA Core Framework provenant du CRC (Communications Research Centre d’Ottawa).
Il existe encore de nombreuses limitations, détaillées en annexe C.3, à l’utilisation de
Corba à l’intérieur des architectures modem, comme les délais de transmission, le surcoût,
logiciel et matériel qu’implique l’ajout d’un bus logiciel non dimensionné à l’origine pour
les applications embarquées.
4.2.3 La couche logicielle intermédiaire P-HAL

Il existe d’autres travaux que le SCA sur les couches intermédiaires notamment ceux issus
des recherches académiques. Parmi ces travaux, nous avons choisi de présenter, suite à une
collaboration décrite en annexe A.1, l’approche proposée à l’UPC (Universitat Politècnica
de Catalunya) par Revés et al. [53]. Le niveau d’abstraction de cette couche est inférieur
à celui du SCA afin de minimiser le surcoût apporté par les couches intermédiaires, il se
situe dans le cas b illustré par la figure 4.6.
Fig. 4.7 – Architecture logicielle du P-HAL
Avec l’objectif d’apporter des services d’abstraction de la couche matérielle la couche

d’abstraction appelée P-HAL pour Physical-Hardware Abstraction Layer est dimensionnée
pour les plates-formes matérielles hétérogènes et destinée aux applications modem RL.
Cette couche permet d’abstraire l’architecture matérielle et la rendre transparente par rap-
port à l’application. Le P-HAL est destiné à fournir un environnement de développement
(1)
http ://www.prismtech.com
commun aux applications radio et les rendre indépendantes de la couche matérielle. Dans
les travaux de l’UPC, la couche matérielle se compose de plates-formes reliées par des
interfaces physiques de type bus. Les plates-formes se composent aussi bien de systèmes
basés sur des GPP avec un (OS) que de plates-formes formées de plusieurs circuits DSP
ou FPGA. Chaque plate-forme est vue par une adresse représentant son point d’accès
pour les transferts de données. Avant l’initialisation du système, une seule plate-forme
désignée comme maı̂tre connaı̂t l’ensemble des adresses. Puis le maı̂tre distribue la table
d’adressage aux autres plates-formes pour construire l’environnement du P-HAL. Les ou-
tils de description des applications supportées par le P-HAL sont spécifiques aux circuits
contrairement au seul langage IDL utilisé pour décrire les applications sur CORBA. Mais
les services, et interfaces de programmation (API) sont similaires suivant les différentes
cibles architecturales supportées par le P-HAL. L’API est défini en C pour les circuits
GPP et DSP, et est disponible en VHDL pour les FPGA. Les applications sont décrites
dans une approche de développement orientée objet. L’interaction de plusieurs objets
situés sur différentes plates-formes est assurée par le P-HAL. Les principaux mécanismes
fournis par le P-HAL à travers l’API sont :
BRIDGE est en charge de l’échange des données entre les objets en temps réel sur un
système distribué.
SYNC assure la synchronisation des données et des traitements entre les plates-formes
en maintenant une référence de temps local identique sur chaque plate-forme. En
d’autres termes, l’objectif est d’observer une seule base de temps virtuelle partout
sur la plate-forme unifiée.
KERNEL est en charge de la coordination des tâches de traitements sur les plates-formes
(“scheduling”) et du contrôle des erreurs.
STATS fournit des services de contrôle de la plate-forme en donnant des informations
sur l’exécution des objets. L’acquisition des informations permet de réaliser des
statistiques sur l’exécution des objets. De même cette interface sert au monitoring.
Ces mécanismes sont présents sur chaque plate-forme matérielle comme l’illustre la fi-
gure 4.7. Du point de vue de la couche applicative, les trois premiers mécanismes offrent
une plate-forme d’exécution unique. Une application décrite sur cette unique plate-forme
virtuelle peut donc être exécutée indifféremment sur un système mono processeur ou de
façon distribuée sur un système hétérogène multi-plateformes.
Un premier partitionnement de l’application est réalisé au moment de la description de

l’application dans la mesure où deux langages de description sont utilisés. Les auteurs du
P-HAL soulignent que l’unification du langage de description n’est pas l’objet des travaux
du P-HAL et un partitionnement manuel est à considérer vu le manque d’outils actuel-
lement disponibles. Après le développement des fonctions de l’API pour les processeurs
généralistes, puis pour les DSP, l’API a été adaptée au FPGA et décrit dans [86].
Du point de vue des FPGA, l’API est un ensemble de blocs implantés avec le bloc
de traitement d’un objet sur le FPGA. Les blocs de l’API jouent le rôle d’interface entre
l’objet et le reste de l’application. Dans un FPGA le nombre d’objets implantés n’est pas
limité et chaque objet est associé à ses propres routines API. La liste des services fournis
par l’API d’un FPGA est similaire à celle disponible sur les processeurs. Ces services sont
donnés par les éléments illustrés dans la figure 4.8 :
– Le service de lecture et d’écriture de données d’un objet vers une interface virtuelle
est donné par l’interface “traffic switch”. Cette interface est en charge de router les
paquets de données vers les interfaces physiques de communication.
– L’acquisition de données d’initialisation se fait par cette interface sous le contrôle
de l’élément de contrôle de l’exécution au moment de l’initialisation.
– Le service de récupération et de changement de valeurs des paramètres d’un objet
observable par le système est réalisé par l’interface de contrôle de l’objet nommée
“Port control”.
– L’interface d’adaptation de RAM “P-HAL RAM adaptation” est disponible pour
les objets nécessitant un accès RAM. Elle est spécifique à l’implantation du P-HAL
sur FPGA. Cet adaptateur de RAM fournit à l’objet une procédure d’accès unique
à la RAM quel que soit le type de RAM utilisé (SDSRAM, SDRAM, SRAM).
– Les blocs “Time” et “Status” sont utilisés pour contrôler l’exécution de l’objet
suivant ces phases de vie et les données traitées par celui-ci.
Fig. 4.8 – Implantation d’un objet et adaptation des interfaces API P-HAL sur FPGA
D’autres travaux académiques sur les couches d’abstraction non basées sur Corba sont
décrits dans l’annexe C.4. Les objectifs sont en général de réduire les surcoûts par rapport
à Corba et d’adapter les architectures logicielles aux plates-formes matérielles destinées
aux applications RL.
4.3 La gestion de configuration

Par le passé, le contrôle de configuration de la couche physique des terminaux mobiles
se limitait au contrôle des changements de services supportés par le standard, prédéfinis
au moment de la conception. Ces changements se résument à des basculements simples
entre services données, voix ou des changements de qualité de service, par exemple par le
basculement entre différents codec implantés en parallèle sur les ressources matérielles. La
configuration est établie pour toute une connexion sans changement en cours. Les configu-
rations et services établis au niveau des standards sont donc implantés dans les systèmes
préalablement à leurs mises en service. De même, au début des réalisations de terminaux
multi-modes, l’approche “velcro” était adoptée, dans laquelle chaque mode est réalisé
4.3 La gestion de configuration 65
indépendamment des autres. Le changement de mode s’effectue alors par basculement

entre implantations indépendantes. L’approche reconfigurable permet la réutilisation des
ressources et les travaux présentées dans ce chapitre, s’intéressent aux moyens de contrôler
la reconfiguration, plus particulièrement sur les fonctionnalités de la couche physique au
moment de l’exécution. La gestion de configuration représente donc la partie spécifique
des systèmes RL.
Fig. 4.9 – Disposition de la gestion de configuration dans les systèmes RL
Nous présentons donc dans les paragraphes suivant plusieurs travaux portant sur la
gestion de configuration. Dans un premier temps, nous nous intéressons à la nature des
configurations à gérer. La présentation des couches logicielles intermédiaires nous a montré
que plusieurs niveaux d’abstraction étaient possibles (cf. fig. 4.6). De même plusieurs
niveaux d’abstraction sur la nature des configurations peuvent être introduits comme
nous le présentons dans le paragraphe suivant.
4.3.1 Nature des configurations à gérer

Ce paragraphe est à relier aux réflexions sur les architectures systèmes vues dans les
précédents paragraphes (architectures logicielles et matérielles). Il porte sur la nature des
configurations gérées par les architectures de gestion de configuration présentées dans
ce chapitre, enfin les méthodologies de conception présentés dans le paragraphe suivant
dépendent aussi du choix de la nature des entités reconfigurables manipulées. Néanmoins
l’introduction d’une couche middleware de type Corba ou l’utilisation de technologie Java
est très consommatrice en ressources de calcul sur un terminal embarqué. Il est donc
nécessaire de définir des solutions moins génériques pour la couche d’abstraction.
La complexité et le coût de la reconfigurabilité dépendent aussi de la forme logicielle

des composants reconfigurables manipulés. En effet, les composants stockés en librairie,
qu’il s’agisse de configurations locales ou téléchargées via l’interface air, peuvent être
exprimés sous différents types : code compilé, code interprété ou code source. Le choix du
type de code manipulé influe sur la taille, la réutilisabilité, la flexibilité des composants
reconfigurables.
Le code compilé La figure 4.10 présente schématiquement une plate-forme matérielle

reconfigurable, dont les bibliothèques de configurations sont sous forme de code
compilé. Un des inconvénients de cette solution est la taille élevée d’un code compilé
exécutable. La portabilité du code compilé est limitée aux circuits pour lesquels ce
code est compilé. Le principal avantage de cette approche est la simplicité qu’elle
fournit au niveau de sa mise en œuvre. Aucun outil de compilation et de synthèse
embarqués n’est nécessaire. En outre le temps de reconfiguration est réduit au seul
temps de chargement du code binaire sur le circuit.
Fig. 4.10 – Portage direct des codes binaires sur plate-forme
Le code source Le choix de codes non compilés (code source) permet d’utiliser un même
code pour plusieurs cibles matérielles. Cela présente un avantage, par exemple dans
le cas d’une mise à jour d’un standard, un code unique peut-être envoyé à l’en-
semble des plates-formes matérielles sans se préoccuper des versions de circuit. Par
exemple, le même code source peut être envoyé pour les FPGA Virtex-II, Virtex-
4 etc. Chaque plate-forme se charge ensuite de synthétiser le code. Cela nécessite
d’embarquer sur chaque plate-forme, les différents compilateurs et outils de synthèse
en fonction des circuits utilisés. Nous avons illustré ce cas par la figure 4.11 où un
contrôleur de configuration est couplé aux compilateurs/synthétiseurs embarqués.
Cela pose en outre des problèmes de protection de code lors des téléchargements et
des stockages des sources sur les cibles finales.
Fig. 4.11 – Plate-forme avec outils de compilation/synthèse embarqués
Sur les circuits FPGA de plus en plus complexes, les outils de synthèse et place-
ment/routage demandent des fortes puissances de calculs, il est donc difficile ac-
tuellement d’envisager de porter ces outils sur des systèmes embarqués. Néanmoins,
il existe des travaux notamment ceux de Vahid et al. [87] montrant que le pla-
cement/routage dynamique est possible sous certaines conditions par exemple en
réduisant l’espace des possibilités de placement/routage.
Code de haut niveau interprété L’utilisation d’un langage de haut niveau d’abstrac-
tion tel que Java permet la description de l’application à l’aide de cet unique lan-
gage.
Dans ce cas, il est nécessaire d’implanter sur la plate-forme matérielle une ma-
chine d’interprétation du langage (machine virtuelle), cela nécessite aussi l’ajout de
couches logicielles intermédiaires afin que la machine virtuelle soit supportée. Nous
avons schématisé ce cas par la figure 4.12. Les reconfigurations interviennent alors
au niveau fonctionnel par changement du code interprété, et non matériel.
Fig. 4.12 – Plate-forme supportant un langage de haut niveau
4.3.2 Les architectures de gestion de configuration

Nous avons vu dans le paragraphe précédent les différentes catégories des codes et la
nature des différentes configurations. Cela influera sur l’architecture du gestionnaire de
configuration mise en œuvre. Dans le cas de l’utilisation de codes compilés figure 4.10,
le gestionnaire de configuration effectue seulement le téléchargement du code exécutable
dans la mémoire d’exécution de la cible. Le code ainsi manipulé est paramétré au mo-
ment de la conception. Dans les autres cas, figure 4.11 et figure 4.12, la configuration
peut prendre la forme d’un code source unique et générique qui sera paramétré au mo-
ment de l’exécution. Dans ces deux derniers cas, il est nécessaire d’ajouter au temps de
chargement du code le temps de la compilation ou de l’interprétation selon la cible choisie.
Ensuite quelle que soit la nature du code choisi pour décrire les différentes configu-
rations des fonctions de traitements, il est nécessaire de garantir le comportement et le
fonctionnement des fonctions entres elles quelles que soit leurs configurations.
Les méthodologies de conception par composants permettent de fournir des fonctions

indépendantes et de garantir leur fonctionnement de leur interface vers l’extérieur, no-
tamment en utilisant des mécanismes d’encapsulation. Les approches de conception par
composants sont généralement retenues en radio logicielle comme le présente Koutouris
et al. dans un état de l’art [88]. Une représentation orientée objet d’un composant de
traitement est illustrée par la figure 4.13. Cette représentation donnée dans le cadre du
projet CAST définit de façon générale les interfaces d’un composant reconfigurable.
Fig. 4.13 – Représentation orientée objet d’une fonction reconfigurable (projet CAST)
Composant reconfigurable : Selon une définition proposée dans le projet E2 R [2],

un composant reconfigurable permet de changer sa configuration, c’est-à-dire l’algorithme
qu’il exécute, les interfaces d’entrées / sorties. Dans le cas de composants complexes, la
reconfiguration peut signifier, le changement d’un sous-composant, le changement des in-
terconnexions des sous-composants. Les composants peuvent être logiciels ou matériels
suivant le circuit sur lequel ils sont exécutés. Dans le cas de composant simple, les chan-
gements de comportement par paramètres sont possibles (composants adaptables).
Le projet E2 R [2] donne également une définition de la notion de configuration :
Configuration : Une configuration est un ensemble de paramètres désignant le fonc-

tionnement d’un système ou d’une partie du système. Une configuration définit comment
les composants sont associés. Le comportement du système dépend aussi du comporte-
ment de chaque composant et de leurs interconnexions. La configuration est une descrip-
tion d’un mode de fonctionnement d’un système. Cette description inclut des informations
structurelles (les composants reconfigurables et les interconnexions entre composants), des
informations sur les comportements des composants (algorithmes, paramètres) et des in-
formations sur l’ordonnancement d’exécution des traitements.
Un point important dans la conception de ces composants est donc la nécessaire encap-
sulation des entités reconfigurables afin d’assurer l’indépendance des interfaces d’entrées
/ sorties par rapport aux changements de fonctionnalités des traitements.
Un gestionnaire de configuration est ensuite en charge de la configuration de la chaı̂ne

de traitement. De façon générale, il est en charge de contrôler les procédures de confi-
guration afin d’assurer le fonctionnement global de l’application. Ces procédures sont
l’allocation de ressources à un traitement, l’insertion, la suppression ou changement de
configuration d’un composant configurable. La gestion de configuration est donc un des
points clef du succès des futurs systèmes.
Le projet CAST a proposé un contrôleur de configuration et des algorithmes pour
les procédures de configuration afin de gérer l’ensemble des ressources matérielles et les
applications. Ce contrôleur, le “Reconfigurable Resource Controller” (RSC), est un mo-

dule logiciel manipulant à un niveau d’abstraction objet, les ressources et les fonctions
représentées par des classes en Java et illustrées par la figure 4.14. Ces travaux sont no-
tamment présentés par Rábai et al dans [89]. Le RSC ainsi défini se place dans le cas
illustré précédemment par la figure 4.13 de configurations manipulées sous forme de code
de haut niveau d’abstraction.
Fig. 4.14 – Modélisation des applications et des ressources en Java (extrait de [89])
La modélisation objet de la chaı̂ne de traitement, des fonctions en bande de base

et des ressources matérielles assure que les procédures de configuration établies dans le
RSC soient indépendantes des circuits ou plates-formes matérielles. Le projet a considéré
qu’une plate-forme matérielle reconfigurable universelle existait. CAST s’est donc intéressé
à définir les algorithmes de décisions intelligentes de reconfiguration issues d’informations
des modèles comportementaux des applications utilisateurs et d’ informations provenant
des réseaux.
Le projet TRUST connexe à CAST a suivi une approche de contrôle strictement
procédurale basée sur des fonctions de contrôle de configuration bien définies. La gestion
de configuration dans ce projet concerne la bande de base avec des traitements exécutés
purement en logiciel. Une méthodologie de conception orientée objet ayant été adoptée, ces
traitements sont représentés comme des méthodes de classes. En vue de leur manipulation
(reconfiguration), ces traitements sont encapsulés dans des objets nommés “Baseband Pro-
cessing Cell” (BPC). Le contrôle de configuration de la chaı̂ne, formée par les objets BPC,
est assuré par un module nommé Reconfigurable baseband Management Module (RMM).
Le module s’occupe de la création, le remplacement des BPC dans la chaı̂ne de traite-
ment. L’architecture du système de traitement en bande de base est basée sur plusieurs
chaı̂nes avec des chaı̂nes actives et des chaı̂nes inactives appelées “Shadow Chain”. Les
détails de l’architecture reconfigurable adoptée dans TRUST et les détails des procédures
de contrôle de configuration sont décrits dans [90].
Des évolutions de TRUST réalisées dans le projet SCOUT permettent de prendre
en charge les traitements en bande de base implantés sur des plates-formes hétérogènes.
Ceci est fait à travers une architecture logicielle, le “SCOUT software framework” sup-
portée par un middleware. L’architecture de contrôle de configuration dans SCOUT, gère
les objets instanciés au niveau “software framework” et prend en compte les contraintes
temps réel liées à la reconfiguration. L’architecture logicielle est séparée en 2 modèles,
l’“Algorithm Model” et l’“Architecture Model” permettant la gestion des composants
d’application et ressources matérielles indépendamment d’une plate-forme. L’“Algorithm
Model” est constitué de composants logiciels. Ces composants décrits comme des proxy
(cf. chapitre sur les architectures des couches logicielles) sont configurés afin de créer la
description des fonctions en bande de base. L’“Algorithm Model” comprend aussi la des-
cription de liens de communication entre ces composants. Chaque proxy est connecté à
une ressource matérielle via le modèle d’architecture (“Architecture Model”). Il est à no-
ter que la connectivité des composants de traitement, dans ce projet de même que dans
CAST et TRUST, est logicielle.
Les travaux des différents projets se retrouvent dans la littérature, par exemple ceux
de Moessner et al. [91] sur le détail de l’architecture de gestion de configuration (Configu-
ration Manager CM). Les travaux [92] définissent les procédures associés au contrôle de
reconfiguration (séquence d’initialisation, procédures de demande de reconfiguration).
E2 R est le projet européen le plus récent traitant de ces aspects, il s’appuie sur les
résultats des projets européens passés notamment CAST et TRUST. Dans E2 R les tra-
vaux sur la gestion de configuration sont étendus à l’ensemble des éléments des systèmes
RL pour une reconfiguration de bout en bout. La gestion de configuration globale de
E2 R est une plate-forme permettant la reconfiguration des éléments distribués dans les
parties cœur de réseau, points d’accès réseau et terminaux. Cette plate-forme de gestion
de configuration décide et prend en charge les actions de reconfiguration sur l’ensemble
du système. Dans les terminaux, le contrôle de configuration présenté dans [93] concerne
l’ensemble des couches OSI, applications, protocoles et modem.
Fig. 4.15 – Architecture logicielle des équipements terminaux radio proposée dans E2 R
L’architecture de gestion de configuration, côté équipement utilisateur, fonctionne sur

un modèle à trois niveaux d’abstraction illustré par la figure 4.15. Ces niveaux sont in-
titulés “function abstraction”, “system abstraction” et le niveau le plus bas “hardware

abstraction”. Ces niveaux apportent une indication sur la nature des composants mani-
pulés par chaque entité de gestion de configuration.
E2 R se basant en partie sur les travaux existants, l’architecture proposée présente des
similitudes avec les précédents projets. Les entités de gestion de configuration du terminal
de E2 R sont décrites en détails dans [94] et [95]. Les principales entités constituant cette
architecture sont :
Configuration Management Module (CMM) Cette entité est responsable des déci-
sions de configurations sur l’ensemble du terminal. D’une part le CMM commu-
nique avec les entités nommées “Configuration Control Module” (CCM) réparties
sur chaque sous partie du système pour distribuer les configurations. D’autre part,
le CMM est en relation avec le réseau par sa collaboration avec une entité nommée
“Reconfiguration Manager” (RCM).
Configuration Control Module (CCM) Il existe trois modules de contrôle de confi-
guration (CCM) pour la partie modem, la partie protocole, et la partie applica-
tion du terminal. Les CCM initient, contrôlent et exécutent les configurations dans
chaque sous-partie configurable du système. D’un côté le CCM est interfacé avec le
CMM pour échanger les informations de contrôle et les données de configuration,
de l’autre côté communique avec l’environnement d’exécution de chaque sous-partie
du système en fournissant ainsi des procédures de reconfiguration indépendantes de
la plate-forme. Les CCM interagissent avec les 2 niveaux de pilotes illustrés dans la
figure 4.15, les “logical device drivers” et les “physical device drivers”. Les premiers
fournissent une abstraction des spécificités des composants matériels s’appuyant sur
les services fournis par les seconds.
Les composants exécutés sur les ressources matérielles et dont la configuration
dépend du type de ressources sont nommés les “Configurable Execution Module”
(CEM). Les CEM sont les équivalents des BPC proposés dans TRUST.
Configurable Execution Module (CEM) Le CEM est un module matériel doté d’une
interface de configuration en lien avec les entités de contrôle de configuration. Un
CEM encapsule les blocs de traitement formant une fonction, ceci permet de les
intégrer dans le système reconfigurable. Sa représentation peut se rapporter au com-
posant reconfigurable illustré figure 4.13.
Nous avons vu à travers la présentation des principaux travaux autour de la gestion
de configuration que le contrôle des composants de traitement est réalisé en manipulant
des entités logicielles à travers des couches d’abstraction. La connectivité des composants
manipulés est donc assurée en logiciel par dessus ces couches d’abstraction. Nous avons
déjà noté précédemment le coût potentiellement élevé de ces couches logicielles auquel il
faut ajouter ceux liés à ce type d’architecture de gestion de configuration. Le SDR Forum
souligne d’ailleurs le fait que la complexité de la gestion de configuration des systèmes
SDR pourrait dépasser les capacités des terminaux avec alors la nécessité de déporter les
fonctions de gestion de configuration quelque part dans l’infrastructure des réseaux.
Afin de réduire les surcoûts en logiciel, d’autres travaux s’intéressent donc au contrôle
de configuration du point de vue matériel. Cette possibilité de gérer la reconfiguration des
composants de traitement sans y adjoindre individuellement des entités logicielles peut
permettre de réduire le coût du logiciel. De plus la conservation d’une connectivité directe
entre composants reconfigurables est un avantage en terme de performance des délais de

propagation des données entre fonctions dans les applications orientées flot de données
telles que les chaı̂nes de traitements en bande de base.
Par exemple, le projet Pastoral a proposé de développer la reconfigurabilité d’une

plate-forme matérielle pour une application de couche physique basée sur les standards
3G côté terminal. Les fonctions des différents standards sont implantées sur des circuits
DSP, FPGA, ASIC pour former les chaı̂nes de traitement. Nous avons vu avec l’exemple
du projet Mumor figure 3.3 que les standards 3G présentaient de fortes similitudes, la re-
configuration proposée dans Pastoral est donc une reconfiguration du chemin de données
de la chaı̂ne de traitement. Un séquenceur est ensuite utilisé afin d’ordonnancer les fonc-
tions de traitement et ainsi former la chaı̂ne correspondant au standard souhaité.
A l’inverse, une architecture reposant sur un chemin de données unique, où les com-
posants de traitement sont reconfigurables, est proposée par Srikanteswara et al. [96].
Cette approche de chemin de données unique transportant les données de traitement et
de configuration implique l’encapsulation des données dans des trames de transport afin
d’en distinguer leur type. Ceci repose sur un modèle en couches illustré par la figure 4.16.
Chaque élément de traitement, appelé “Processing Element” (PE), doit être capable d’in-
terpréter les paquets de données (partie de contrôle de trame implantée en statique) pour
ensuite exploiter les données de traitement ou de configuration.
Fig. 4.16 – Modèle de flot de données en couches [96]
Conclusion
L’évolution des circuits reconfigurables vers des architectures de plus en plus orientées sur
un domaine applicatif est une nécéssité à laquelle les applications RL n’échapperont pas
malgré “l’idéal” du tout processeur généraliste. L’analyse des applications multi-standards
conduit à choisir des architectures hétérogènes qui offriront divers type de flexibilité pour
répondre aux besoins RL.

Les “good old days” de la HDR (Hardware Defined Radio), c’est-à-dire des systèmes ra-
dio essentiellement basés sur la conception matérielle, semblent bien être révolus face
aux vastes projets de recherche qui deviennent de plus en plus des projets de conception
logicielle. En effet les travaux s’appliquant à définir des couches d’abstraction des as-
pects matériels des plates-formes représentent une tendance lourde dans le domaine de la
RL. Néanmoins ces couches logicielles devront être définies pour répondre aux spécificités
d’execution temps réel des systèmes radio et s’adapter à l’hétérogénéité des plates-formes
matérielles. Ces couches devront aussi être optimisées de façon à être implantées dans des
systèmes embarqués.
L’architecture d’une plate-forme et le type de ressources matérielles, l’abstraction four-

nie par d’éventuelles couches logicielles sont les aspects dont nous avons donné un aperçu
dans ce chapitre. L’ensemble de ces facteurs influe évidemment sur la nature des configura-
tions et l’architecture permettant la gestion des ressources. L’architecture de cette gestion
de configuration qui représente la spécificité d’un système radio logicielle en garantissant
le niveau de reconfigurabilité du système une fois celui-ci devenu autonome, dépend donc
des facteurs précédemment évoqués. Or la plupart des architectures de gestion de confi-
guration s’appuient sur des couches d’abstraction logicielle et fournissent par conséquent
une modularité de l’application au niveau logiciel. En effet une des limitations actuelles
des couches logicielles réside dans le fait qu’un circuit de type FPGA est considéré comme
pouvant accueillir un seul traitement configurable même si ce traitement peut tout à fait
être un agrégat de plusieurs fonctions complexes au vu des ressources disponibles dans
les FPGA récents. Il est donc nécessaire d’offrir une gestion de configuration matérielle
utilisant la capacité de reconfiguration partielle d’un FPGA afin de considérer plusieurs
fonctions reconfigurables indépendantes dans un FPGA.
C’est donc après la présentation de ces systèmes SDR, objet de ce chapitre, que nous
consacrerons le chapitre suivant à notre proposition d’architecture de gestion de configura-
tion répondant à la gestion des fonctions implantées sur plate-forme incluant des circuits
de logique reconfigurable. L’analyse de factorisation vue précédemment permet de réduire
le nombre de configurations. De même nous adoptons des méthodologies de conception
décrites au chapitre 6 utilisant la reconfiguration partielle, afin de limiter le nombre de
configurations et la mémoire de stockage des fichiers binaires volumineux (les bitstreams
de FPGA).
Chapitre 5
Un modèle d’architecture pour la

radio logicielle
Sommaire
7.1 Gestion de configuration hiérarchique sur la plate-forme . . . 128
7.1.1 Portage de la structure de gestion de configuration sur la plate-
forme hétérogène . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
7.1.2 Implantation de la structure de gestion de configuration sur la
plate-forme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
7.2 Procédures et scénarios de reconfiguration sur la plate-forme 132
7.2.1 Initialisation de la plate-forme . . . . . . . . . . . . . . . . . . . 132
7.2.2 Reconfiguration de fonctions sur la plate-forme . . . . . . . . . . 133
7.2.3 Scénarios de reconfiguration des applications multistandard . . . 137
7.3 Implantation de la voie de traitement sur la plate-forme . . . 139
7.3.1 Architecture du chemin de traitement sur la plate-forme . . . . . 139
7.4 Exemples d’implantation de fonctions . . . . . . . . . . . . . . 142
7.4.1 Mise en constellation . . . . . . . . . . . . . . . . . . . . . . . . . 142
7.4.2 Codeur convolutif . . . . . . . . . . . . . . . . . . . . . . . . . . 144
7.4.3 Filtre FIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Introduction
Dans le précédent chapitre, nous avons dressé un état de l’art des systèmes RL en
s’intéressant plus particulièrement à trois parties essentielles de ces systèmes, les plates-
formes matérielles, les couches logicielles, et les architectures de gestion de configuration.
Nous avons notamment vu l’importance que la gestion de configuration prend dans le
fonctionnement des systèmes radio logicielle. Le choix des ressources matérielles, avec les
forts besoins de flexibilité qu’engendre la RL est un autre point clef de la définition de ces
systèmes. Nous proposons dans ce chapitre un modèle adressant ces deux parties essen-
tielles à la définition d’un système RL.
Le modèle fonctionnel abstrait a pour objectif de permettre le déploiement d’une applica-
tion configurable flot de données sur une plate-forme matérielle hétérogène. Nous propo-
sons un modèle dit fonctionnel dans le sens où il est indépendant de toute implantation
75
76 Un modèle d’architecture pour la radio logicielle
matérielle. Ce modèle se base sur l’analyse algorithmique des applications multi-standards

décrite dans le chapitre 3. Nous proposons à travers ce modèle de prendre en compte les
besoins de reconfigurabilité mis en évidence lors de cette étude.
Dans une première section nous présentons de façon globale l’architecture du modèle fonc-
tionnel, sous forme d’un double chemin de données, de configuration et de traitement. Nous
détaillons ensuite chacune des parties : la voie de configuration et la voie de traitement.
La voie de configuration repose sur une structure de gestion de configuration hiérarchique
permettant de répondre aux besoins en terme de reconfigurabilité. Nous présentons en-
suite la voie de traitement qui permet le déploiement d’une chaı̂ne de transmission sur
une plate-forme hétérogène.
Cette modélisation fonctionnelle permettra de mettre en œuvre la reconfiguration des
formes d’ondes implantées sur des ressources matérielles hétérogènes. Un des objectifs sur
la voie de traitement est notamment le portage direct des formes d’ondes sur les circuits
spécialisés de type DSP ou FPGA ; ceci afin de bénéficier entièrement de leur puissance
de calcul pour exécuter les fonctions de traitement en bande de base. En particulier, nous
décrivons dans ce chapitre la gestion hiérarchique, dont la singularité est la gestion de
configuration des ressources logiques configurables.
5.1 Double chemin de données : configuration/traitement

Les applications du modem en bande de base mais aussi en FI et RF sont orientées flot
de données. Le traitement du flot de données est généralement séparé en plusieurs entités
correspondant aux fonctions de traitement. Nous utiliserons aussi par la suite le terme
de composant de traitement pour désigner l’implantation d’une fonction de traitement
sur des ressources matérielles. En supposant que chaque entité ou composant de ce che-
min de traitement soit configurable, chacune possède alors ses données de configurations
propres dont la nature dépend de la fonctionnalité, du type d’implantation et des res-
sources matérielles utilisées. Par exemple une fonction de codage convolutif paramétrable
implantée sur DSP n’est pas représentée par les mêmes données de configuration que la
même fonction sous forme d’un composant reconfigurable implanté sur FPGA. Il est donc
nécessaire de pouvoir adresser individuellement la configuration de chaque composant.
Le fait d’établir un même chemin pour les données de traitement et de configuration
comme le propose le modèle en couche présenté précédemment figure 4.16 augmente la
complexité des éléments de calculs par l’ajout de contrôle. Des trames de données (portant
les données de configuration ou de traitement) sont formés par les couches supérieures et
sont transmises sur l’ensemble de la chaı̂ne de transmission engendrant de plus un surcoût
de données transmises. En effet, chaque donnée est encapsulée dans une trame afin d’en
déterminer la nature.
Afin d’éviter ces surcoûts, nous proposons de séparer les flux de données (configura-
tion et traitement) et ainsi assurer que chaque entité reconfigurable puisse être adressée
directement par une entité séparée de contrôle séparée de configuration. La partie haute
de la figure 5.1 illustre ce modèle basé sur la séparation de la voie de traitement et de la
voie de configuration.
5.1 Double chemin de données : configuration/traitement 77
Fig. 5.1 – Modèle fonctionnel à double chemin de données configuration et traitement

Le besoin de reconfiguration individuelle de chaque fonction, augmenté de la diversité

des types de reprogrammation possible (plateformes hétérogènes), nous ont conduit à pro-
poser ce double chemin de données. Dans ce double chemin, chaque élément de traitement
est associé à une unité de gestion de configuration dédiée. La gestion distribuée permet
de répondre aux deux besoins soulevés précédemment.
Une gestion distribuée répond de manière simple aux besoins de reconfiguration indivi-
duelle des blocs de traitements.
La spécialisation des unités de contrôle reconfiguration diminue leur complexité et per-
met de gérer les spécificités de chaque fonctionnalité implantée dans les PBU (Processing
Block Unit).
De plus, les cadences de transmission de données de contrôle de configuration et celles
des données de traitement sont différentes. La séparation des 2 types de flux de données
permet de les dissocier. Chaque Configuration Manager Unit (CMU) est associé à un bloc
de traitement PBU. Un CMU est dédié au contrôle d’un PBU. Chaque entité de gestion
de configuration déployée sera donc optimisée pour gérer un type de ressources reconfigu-
rables.
Le fonctionnement de cette double entité (PBU/CMU) est résumé dans la partie basse de
la figure 5.1.
Les objectifs du contrôle de configuration effectué par les CMU sont de réaliser sous
contraintes de temps :
– L’adaptation de la fonctionnalité des traitements en bande de base aux besoins de
l’application.
– Les changements de contexte des traitements en procédant au chargement des
données de configuration sur les ressources matérielles.
– Le contrôle des procédures de reconfiguration.
La gestion de configuration distribuée permet de simplifier la gestion de configuration
lorsque les ressources sont hétérogènes. Chaque CMU est dédié à une fonctionnalité et
à bas niveau aux types de ressources matérielles. Les procédures de contrôle sont ainsi
simplifiées.
Cependant, il est difficile avec une gestion uniquement distribuée de contrôler la confi-
guration globale d’une chaı̂ne de traitement, c’est l’une des raisons pour lesquelles nous
introduisons la gestion hiérarchique. Nous allons décrire dans le paragraphe suivant notre
proposition de gestion de configuration hiérarchique. Cette gestion permet de développer
plus en avant les concepts de gestion de configuration distribuée.
5.2 Modèle de la voie de gestion de configuration

Nous proposons ici le modèle de gestion de configuration “HDCM” “Hierarchical Distri-
buted Configuration Management” issu de notre analyse de la problématique de la RL. Ce
modèle s’appuie sur l’analyse algorithmique des applications multi-standards présentée au
chapitre 3 et s’appuie sur le modèle de séparation des voies de configuration et de traite-
ment exposé précédemment.
Le modèle de gestion tel qu’il est illustré par la figure 5.2 est proposé dans [97]. Il possède
trois niveaux de hiérarchie. Il permet de répondre aux besoins de reconfigurabilité des ap-
plications en vue des différents types de changements de contexte (basculement de stan-
dard, de mode, amélioration de performance (“algorithm enhancement”), correction de
5.2 Modèle de la voie de gestion de configuration 79
bugs (“bug fixing”) ). Cette architecture fonctionnelle est donc établie indépendamment
des plates-formes matérielles, afin de s’adapter quelle que soit l’architecture matérielle
choisie.
Nous décrirons dans un premier temps les objectifs auxquels répond le modèle, par la
suite nous détaillerons le rôle de chaque niveau de gestion.
Ce modèle s’appuie sur l’analyse algorithmique effectuée sur les traitements de la

chaı̂ne de transmission multi-standards unifiée décrite dans le chapitre 3. De plus, en
s’appuyant sur des études de paramétrisation comme le propose [45], le coût de reconfi-
guration lors d’une demande de changement de contexte peut être réduit. Par exemple, si
des fonctions ou des motifs d’exécution communs au précédent contexte sont disponibles,
alors la reconfiguration de la chaı̂ne de traitement sera partielle.
La modélisation “HDCM” de la gestion de configuration permet de répondre à plu-

sieurs besoins :
1. Basée sur le modèle double chemin de données, la gestion hiérarchique est distribuée.
Cette séparation verticale de gestion en unités distinctes permet d’adresser directe-
ment et individuellement les entités à reconfigurer.
2. Les différents niveaux hiérarchiques à travers la séparation horizontale permettent
d’introduire une gestion de données de configuration de différentes natures. No-
tamment sur les deux niveaux hiérarchiques supérieurs la gestion de configuration
s’effectue par paramètre, ceci afin de réduire le volume de données de configuration.
3. L’analyse des différents besoins de changement de contexte effectuée au paragraphe
3.2.3 a mis en évidence différents niveaux de granularité des changements de contexte.
Les niveaux hiérarchiques de ce modèle fonctionnel ont été définis en correspondance
avec les besoins en terme de reconfigurabilité des applications.
4. Les changements d’applicatifs peuvent mettre en jeu un nombre variable de traite-
ments à reconfigurer. La gestion hiérarchique permet de répondre à ces besoins de
gestion de granularité multiple de configuration.
5. La gestion hiérarchique permet de centraliser au niveau supérieur et sous forme de
paramètres, les configurations de l’ensemble de la chaı̂ne et ainsi offrir une connais-
sance de l’état global de configuration de la chaı̂ne pour permettre les prises de
décision de configuration.
Chaque unité de gestion traite en entrée des paramètres de configuration reçus du
niveau supérieur et en sortie fournit les paramètres ou données de configuration à desti-
nation de l’unité de gestion du niveau inférieur. Chaque unité de gestion de configuration
est une interface entre deux niveaux de configuration. Ce rôle d’interface est commun à
chaque unité de configuration. Le rôle propre à chaque niveau de configuration est détaillé
ci-dessous.
5.2.1 Le niveau hiérarchique 1

La grande diversité des traitements utilisés par les différents standards implique un grand
nombre de configurations à gérer.
Config. Management Level 1 Std

SW1 Std
SW2 Std
SW3
_____
______ _____
______ _____
______
_____
______ _____
______ _____
______
Config. Manager _____
______ _____
______ _____
______
L1_CM Standards Parameters

Standard Set
Config. Management Level 2

Functions
Library
L2_CMU
Function Set
L2_CMU
Function Set
L2_CMU
Function Set
… Function
L2_CMU
Set
L3_CMU
Block Set
L3_CMU
Block Set
… L3_CMU
Block Set
HW/SW
Blocks
Library
Config. Management Level 3
Fig. 5.2 – Gestion de configuration hiérarchique

Le gestionnaire de configuration au niveau 1, nommé L1 CM (“Level 1 Configuration

Manager”) a le rôle de superviseur général de configuration. Les interactions du L1 CM
sont illustrées figure 5.3. Le L1 CM est interfacé avec l’extérieur et prend en charge les
demandes de changement de contexte venant des couches supérieures ( gestionnaire de
configuration de plus haut niveau venant des couches applicatives d’interface avec l’utili-
sateur ou du réseau donnant les ordres de reconfiguration).
Les paramètres envoyés par l’application utilisateur sont interprétés par le L1 CM. En
fonction de la requête et des paramètres de la configuration courante, le L1 CM envoie à
destination des unités de gestion de configuration de plus bas niveau, les paramètres de
configuration contenant les informations sur les fonctionnalités à changer.
Le L1 CM est donc en charge du contrôle des paramètres des différents standards et de
la mise à jour des paramètres courants. Du point de vue du L1 CM les fonctions sont des
paramètres. La configuration des fonctions n’est pas effectuée à ce niveau.
Fig. 5.3 – Rôle de superviseur de configuration du L1 CM
Le changement de standard est le cas de changement de contexte de niveau de granu-

larité fonctionnelle le plus élevé. Il correspond le plus souvent à un changement complet
de la configuration de la chaı̂ne de traitement. En d’autres termes, les paramètres de
configuration courants sont en grande majorité différents des futurs paramètres. Dans ce
cas, les paramètres de configurations sont envoyés à l’ensemble des unités de configuration
de niveau inférieur afin que l’ensemble des fonctions soit changé.
Dans le cas évoqué ci-dessus, la gestion hiérarchique peut paraı̂tre lourde dans sa mise en
œuvre. En effet, des ordres de reconfiguration doivent être envoyés du L1 CM à chacun
des L2 CMU, dans la mesure où de nombreuses fonctions changent de configuration entre
standards. Alors que dans le cas d’une gestion de configuration centralisée le changement
de standard peut se résumer en un seul ordre et une seule reconfiguration globale de toute
la chaı̂ne de traitement.
La gestion hiérarchique permet d’adresser individuellement les fonctions de traitement.
De ce fait, elle est adaptée aux cas où la granularité de changement de contexte est plus
faible lorsque les besoins de changement sont partiels dans la chaı̂ne. Dans ces cas nom-
breux, par exemple changement de mode, seules quelques demandes de changement de
configuration sont adressées par le L1 CM aux unités de gestion en charge des fonctions
à modifier. Les paramètres de configuration sont ensuite transmis aux unités de gestion
associées aux fonctions à reconfigurer.
Du point de vue du temps de configuration, il n’existe pas de contrainte temporelle de
reconfiguration lors d’un changement inter-standard. Une reconfiguration temps réel inter-
standard nécessite l’établissement de deux communications en même temps pendant une
certaine durée, alors l’option d’une duplication même partielle, est préférable. Par contre
pour les changements de configuration plus fins, par exemple intra-standard, il peut exis-
ter des contraintes temporelles comme par exemple le respect du temps trame.
La gestion distribuée comparée à une gestion globale présente l’avantage du nombre

de configurations à gérer. Par exemple avec 3 standards et Nf fonctions dont chacune
possède Cf i configurations le nombre de configurations globales de toutes les combinaisons
de configurations de fonctions représente NGC :

NGC = 3 ∗ Nf ∗ Cf i (5.1)
i
Dans le cas d’une gestion de configuration par fonction par une structure distribuée,
le nombre de configurations à maintenir est le nombre CF C :

NF C = Cf i (5.2)
i

Les unités de gestion de configuration de niveau 2, les L2 CMU (Configuration Manager
Unit) prennent en charge la mise en place des fonctions de traitement dans la chaı̂ne de
transmission. Les L2 CMU sont interfacés avec le L1 CM afin de récupérer les ordres de
configuration et les paramètres des fonctions que ce dernier distribue.
Le standard et son mode de fonctionnement sont choisis suivant les demandes de l’utilisa-
teur. Suivant le service demandé, Le L1 CM spécifie donc les paramètres de configuration
de l’ensemble des fonctions. Un L2 CMU gère la fonction à laquelle il est associé et ses
paramètres. Par exemple pour la fonction de codage bit à symbole, le paramètre principal
est la constellation, BPSK, QPSK, 16-QAM, ou 64-QAM.
Dans ce modèle, le maximum de L2 CMU instanciés correspond au nombre de fonctions
génériques présentes dans la chaı̂ne unifiée.
Cependant, le nombre de L2 CMU instanciés peut être diminué, en regroupant la
gestion par un seul L2 CMU de plusieurs fonctions. En effet, certaines fonctions, pas très
complexes, ont peu de paramètres donc un nombre de configurations différentes faible et
sont réalisées par un seul bloc de traitement, ce qui entraı̂ne de ne pas mettre en œuvre
un L2 CMU dédié à une fonction.
Le L2 CMU détermine quelle configuration de traitement mettre en œuvre afin d’exécuter
la fonction paramétrée. Cette configuration dépend du débit à attendre, de la cible
d’exécution. Le L2 CMU doit donc sélectionner les blocs de traitement à instancier. Il en-
voie les ordres de configuration au niveau de gestion hiérarchique inférieur afin de réaliser
ces configurations.
Finalement, un L2 CMU est l’interface entre la gestion de haut niveau sous forme de
Fig. 5.4 – Le rôle d’interface d’un L2 CMU
paramètres réalisée par le L1 CM et la gestion de configuration des ressources matérielles

effectuée par les L3 CMU.

Nous rappelons qu’un L2 CMU est en charge de la gestion de configuration des fonctions
sous forme de paramètres. Une fonction est composée de plusieurs sous blocs de traite-
ment ou motifs de traitement. Un L3 CMU est associé à un bloc de traitement et a deux
rôles principaux.
Le premier rôle d’un L3 CMU est de paramétrer le sous-bloc dont il a la charge, suivant
les critères définis par le L2 CMU. Le L3 CMU est ensuite en charge de l’instanciation du
bloc de traitement paramétré. Sa fonction est de configurer les ressources matérielles en
vue de l’exécution de chaque élément de traitement paramétré. Le portage des traitements
est direct sur les ressources matérielles, la nature des données de configuration manipulées
par un L3 CMU dépend donc du type de ressources utilisées.
Pour un traitement réalisé sur un processeur, par exemple un DSP, le rôle de configuration
du L3 CMU se résume en une transformation des paramètres donnés par le L2 CMU en
paramètres passés à une routine logicielle. La configuration dans le cas logiciel est classi-
quement, un passage de paramètres par valeur à une fonction instanciée, ou par pointeur
sur une fonction disponible dans une bibliothèque. Pour un traitement sur des ressources
de logique configurable, la conception architecturale d’une fonction impacte aussi la na-
ture de la configuration réalisée par le L3 CMU. L’architecture sera choisie notamment
en fonction des performances requises ou de la consommation. Nous détaillerons dans le
prochain chapitre nos différentes approches de conception et les architectures reconfigu-
rables possibles des traitements.
Nous développons dans le chapitre 7, la description de l’architecture de gestion de

configuration sur la plate-forme matérielle et donc particulièrement la mise en oeuvre
des L3 CMU. Dans cette partie 7, nous abordons aussi l’adaptation de notre modèle à
l’architecture de plate-forme choisie. Aussi nous verrons plus en détails les procédures liées
à la gestion de l’architecture de la chaı̂ne de traitement dans ce chapitre 7.
La gestion hiérarchique par rapport aux autres approches

L’approche hiérarchique est d’une part appropriée pour gérer divers types de données de
configuration et diverses granularités de configuration. D’autre part, la gestion distribuée
facilite le contrôle de la reconfiguration partielle de la chaı̂ne de traitement. Notamment,
elle gère le flot de données pendant les phases de reconfigurations.
La gestion hiérarchique rend possible l’exploitation de la reconfigurabilité de chaque
bloc de traitement d’une application modem et ainsi accroı̂t sa flexibilité. La découpe
hiérarchique répond aussi aux différents besoins de changement de contexte identifiés dans
le paragraphe 3.2.3. Suivant le type de changement de contexte demandé, les différents
niveaux de gestion de configuration sont utilisés. Le changement de standard utilisera la
plupart des unités de configuration du L1 CM au L3 CMU. Lors d’un changement de
service où une seule fonction est changée, seul le L2 CMU associé est utilisé. Dans le cas
d’une correction de programme (“bug fixing”) intervenant sur quelques motifs de traite-
ments seul un L3 CMU peut-être sollicité.
La solution d’une architecture distribuée pour la voie de configuration permet de

répartir les tâches de gestion de configuration sur les ressources disponibles de la plate-
forme sans créer de surcoût de contrôle important sur une ressources en particulier. Alors
qu’une gestion centralisée des ressources nécessite pour son exécution l’ajout d’un proces-
seur dédié à cette tâche.
Les différentes architectures de gestion de configuration n’adressent pas la configura-

tion au même niveau. Nous avons vu au paragraphe 4.3.2 que dans le récent projet E2 R la
reconfiguration était gérée du point de vue logiciel, s’appuyant notamment sur les résultats
du projet TRUST. Dans ces cas les composants reconfigurables ont une connectivité four-
nie par logiciel. Le modèle que nous proposons vise à gérer des configurations logicielles
et matérielles avec une connectivité directe entre composants. Notre modèle ne s’appuie
pas sur un haut niveau d’abstraction donné par des couches logicielles intermédiaires,
ce sont les traitements exécutés sur les circuits dont notre modèle s’occupe de gérer la
configuration.
5.3 Le modèle de la voie de traitement

Nous discutons du modèle de la chaı̂ne de traitement flot de données appelée voie de
traitement dans le schéma 5.1. Nous pouvons caractériser cette voie par 3 différents ni-
veaux comme l’illustre la figure 5.5. Le premier niveau correspond à la classification, déjà
vue précédemment au paragraphe 3.2.2 où nous distinguons 3 groupes de fonctions. De
ce classement, il s’ensuit un choix de plate-forme hétérogène afin d’exécuter au mieux
les différentes fonctions. La chaı̂ne de traitement, illustrée par le niveau fonction de la
figure 5.5, est donc répartie sur des cibles d’exécution différentes. Dans le cas de notre
plate-forme, il s’agira de circuits GPP, DSP et FPGA. Les composants de traitements
exécutant ces fonctions doivent pouvoir communiquer entre eux dans un schéma flot de
données. Nous avons donc choisi de définir un composant de traitement standard dont
le comportement de l’interface de communication est identique sur toutes les cibles de
traitement. Nous pouvons donc dire que ce composant a N instances si la chaı̂ne com-
porte N traitements. Le composant fournit des interconnections point à point à interface
5.3 Le modèle de la voie de traitement 85
standards permettant d’assurer les échanges de données entre fonctions. Notre choix s’est
orienté sur un mécanisme de transmission asynchrone des données entre composants. Ce
mode d’échange des données permet de s’affranchir des problèmes de synchronisation dûs
aux différences de cadences de fonctionnement entre circuits. Dans ce composant sont
encapsulés, les blocs, formant la fonction de traitement. Ils sont représentés par le ni-
veau bloc dans la figure 5.5. Ces blocs ont un fonctionnement synchrone. Au final, la
chaı̂ne aura un fonctionnement de type GALS(1) [98] sur l’ensemble des ressources dispo-
nibles sur la plate-forme (GPP/DSP/FPGA). Le fonctionnement de type GALS donne
une indépendance des données vis-à-vis de la communication entre composants.
Fig. 5.5 – Modèle 3 niveaux fonctionnels de la voie traitement
5.3.1 Le fonctionnement d’un composant de traitement

Chaque traitement synchrone est encapsulé dans un composant (au niveau fonction de
la figure 5.5) comme nous venons de le voir. Un composant a pour fonction de contrôler
localement la production / consommation de données vis-à-vis de la consommation / pro-
duction des composants auxquels il est connecté. Nous allons décrire le fonctionnement
de ce composant d’adaptation détaillé figure 5.6.
La production et la consommation de données sont respectivement contrôlées par les par-
ties “timing data out” et “timing data in” du composant.
Un traitement se termine toujours par la production de données. Avant d’autoriser cette
production, le composant par l’intermédiaire du bloc “timing data out” doit donc vérifier
qu’il est possible d’envoyer sur sa sortie une donnée. Si cette condition est vérifiée, alors le
(1)
Globally Asynchronous Locally Synchronous est à l’origine un fonctionnement fait pour réduire la
consommation par interruption du signal d’horloge qui est un des principaux facteurs de consommation.
Ici le terme GALS est utilisé par commodité pour figurer le fonctionnement du transfert de données par
composant
composant vérifie la présence de données à son entrée, par l’intermédiaire du bloc “timing
data in”. Si la condition de consommation est vérifiée, alors le composant autorise le fonc-
tionnement du traitement synchrone. Les signaux de contrôle pour l’échange asynchrone
de données proviennent des blocs “timing data out” et “timing data in”. Ces signaux de
contrôle sont associés à des boı̂tes aux lettres permettant de vérifier la présence de données
en sortie et en entrée. Ces données sont stockées dans des FIFO. En fonction du nombre
de données produites ou consommées par une fonction par cycle, “timing data in” et “ti-
ming data out” sont adaptés afin de maintenir un fonctionnement standard des interfaces
de transmission de données “Adapt Tx Data” et “Adapt Rx data”. Par ces mécanismes,
le rythme de traitement de la chaı̂ne est automatiquement régulé.
Fig. 5.6 – Composant d’adaptation pour un fonctionnement “GALS” de la voie de trai-

tement
Le mode de fonctionnement contrôlé par le bloc “timing reconf ”, spécifie l’état de la

fonction en cours de traitement (initialisation, traitement, transparent). Les signaux de
contrôle de configuration permettent de contrôler la configuration du composant et de
maintenir l’état des interfaces de transfert de données au cours d’une reconfiguration.
Les signaux de contrôle de mode de fonctionnement et ceux de configuration diffèrent
suivant les besoins de la fonction. Par exemple, les signaux de contrôle de configuration
concernant des changements structurels par reconfiguration sont mis en œuvre seulement
dans le cas d’une implantation sur FPGA. Pour les fonctions logicielles il s’agit dans
notre cas uniquement de changements par paramètre. La reconfiguration logicielle au sens
rechargement de code n’a pas été adressée dans notre travail. Ceci a été réalisé dans les
travaux présentés dans [88]. Par contre faire le rechargement de code dans le cadre matériel
apporte une réelle innovation, d’où l’accent mis sur ce thème. Nous donnerons donc dans
la partie suivante les détails de l’intégration en fonction des cibles matérielles.
5.3.2 Exemple
Un exemple illustrant l’intérêt de la distribution de la gestion rendant chaque fonction
du modem atteignable individuellement est le suivant. Lors d’une demande de change-
ment de mode en 802.11g pour augmenter le débit, la fonction de codage bit à symbole
est reconfigurée par exemple de QPSK à 16-QAM. Alors seul le L2 CMU associé à la
fonction à reconfigurer est invoqué. De plus dans ce cas simple nous supposons que seul
le bloc de traitement mise en constellation est à modifier. La figure 5.7 illustre donc la
mise en œuvre de la voie de gestion de configuration à travers le séquencement des ordres
de configuration entre les différentes unités de gestion de configuration. La situation de
changer plusieurs blocs de traitement revient à réaliser plusieurs échanges entre le L2 CM
et les L3 CMU. Les demandes de changement d’une seul partie des fonctions de la chaı̂ne
se présentent dans le cas de changements intra-standard ou de changements de modes. Il
est alors possible d’adresser individuellement les fonctions sans reconfigurer l’ensemble de
la chaı̂ne en adressant chaque L2 CMU concerné.
Fig. 5.7 – Séquencement des messages entre les unités de gestion : cas d’un bloc reconfiguré
Les échanges d’informations entre les niveaux L1 et L2, sont d’un faible volume, de
même entre les niveaux L2 et L3. Les données de reconfigurations envoyées par le niveau
L3 dépendent de l’implantation des blocs de traitements. La taille des données, très va-
riable, se situe donc entre des valeurs de quelques paramètres pour une fonction logicielle
paramétrable et un fichier binaire de configuration pour un FPGA.
En reprenant la modélisation en trois parties utilisée dans le chapitre 4, nous pouvons

illustrer le modèle du système radio logicielle par la figure 5.8. Par souci d’efficacité en
terme de puissance de calcul et de gestion mémoire dans nos travaux, nous n’avons pas
abordé le déploiement de couches logicielles d’abstraction sur plate-forme hétérogène tou-
tefois représentées dans la figure 5.8. Les applications portées sur le GPP sont développées
sous le système d’exploitation standard. Les composants de traitement exécutés sur le DSP
et le FPGA sont portés de façon directe. Nous nous sommes donc intéressés à la gestion de
configuration basée sur la gestion de bibliothèque de composants portés sur les ressources
DSP et FPGA. Le portage sur la plate-forme matérielle de notre modèle de gestion de
configuration hiérarchique est aussi direct sur les modules matériels DSP et FPGA. Nous
allons aborder ce point dans le prochain chapitre.
Fig. 5.8 – Représentation en 3 parties de la plate-forme radio logicielle
Conclusion
L’un des éléments indispensables à la flexibilité à l’exécution des systèmes SDR est le
contrôle et la gestion de la configuration. La diversité des traitements en bande de base
nécessite l’introduction d’une architecture de gestion de configuration. Ce modèle pourra
s’appliquer aux fonctions des chaı̂nes d’émission et de réception, de même qu’il pourra
être étendu à la gestion de configuration d’autres standards car les besoins de gestion de
configuration sont similaires à l’émission et à la réception dans tous les standards, no-
tamment au niveau de la granularité de configuration. Les procédures de reconfiguration
lors d’un changement d’application (standard, mode, ...) sont définies dans nos études
suivant des scénarios. Une évolution de l’architecture de gestion de configuration en in-
cluant des règles d’optimisation de graphe d’exécution rendrait possible l’optimisation des
configurations en cours d’exécution suivant des remontées d’information provenant de di-
vers capteurs. Ce modèle de gestion de configuration RL évoluera ainsi vers un modèle de
gestion de configuration de radio intelligente. Ces études dépassent le cadre de ce travail
et sont poursuivies actuellement dans la thèse de L. Godard. Ces travaux ont fait l’objet
d’une publication [99] ou nous pensons que la structure de gestion hiérarchique se prête
particulièrement à cette évolution des systèmes RL vers la RI.
Alors que notre proposition “HDCM” adresse la reconfiguration par partie de la couche
physique des applications composées de composants hétérogènes, les architectures jusqu’à
maintenant proposées dans la littérature adressent une gestion de configuration de plus
haut niveau. Soit en ajoutant une couche d’abstraction logicielle afin de réaliser la gestion
de configuration de façon logicielle, soit en considérant le modem comme un module uni-
taire d’un système disposant de capacité de reconfiguration par module. Nous considérons
que l’approche “HDCM” est tout à fait adéquate pour gérer l’ensemble des couches d’un
terminal depuis la couche PHY jusqu’aux couches applicatives. Nous nous sommes ici
contentés de l’illustrer pour la partie modem qui est la partie la plus spécifique à la RL.
Dans la prochaine partie de ce manuscrit, nous discuterons de la mise en œuvre du

modèle “HDCM”. Dans le premier chapitre de cette partie, nous discutons de la conception
des systèmes SDR et des approches de conception permettant de tirer avantageusement
partie de leur flexibilité “potentielle”. Nous proposons une démarche de conception pour le
portage des applications de traitement en bande de base suivant l’analyse multi-standards
que nous avons apportée dans la première partie et aussi suivant la modélisation en double
chemin de traitement proposée en s’intéressant en particulier à la reconfiguration partielle
de la chaı̂ne de traitement et la reconfiguration partielle des traitements situés sur FPGA.
Enfin nous présentons dans le dernier chapitre (chapitre 7) la réalisation sur une plate-
forme matérielle d’une application multi-standards de traitement en bande de base. Nous
présentons le portage de la double structure “voies de traitement et de configuration”.
Les différentes méthodologies de conception seront illustrées à travers des exemples de
conception avancées de traitement en bande de base.
Troisième partie
Plateforme radio logicielle

Chapitre 6
Conception et intégration des

applications SDR sur plate-forme
reconfigurable
Introduction
Ce chapitre décrit la démarche que nous avons suivie pour l’intégration de la chaı̂ne
de traitement en bande de base sur une plate-forme hétérogène GPP/DSP/FPGA. La
définition de flots de conception d’applications pour plate-forme hétérogène n’a pas été
l’objectif de ce travail. Néanmoins nous avons mené des réflexions autour de la concep-
tion d’IP sur FPGA, notamment afin de nous permettre d’exploiter les caractéristiques
de reconfigurabilité qu’offrent ces composants. Nous n’avons de même pas utilisé d’outils
de co-conception pour déterminer le partitionnement logiciel/matériel. Les partitionne-
ments sont réalisés suivant des scénarios. Les langages de haut niveau tel que SystemC
ou SystemVerilog et les outils de co-conception associés ne permettent pas par exemple
d’exploiter les caractéristiques de reconfigurabilité avancées des FPGA telles que la re-
configuration partielle (RP). La RP est l’un de nos intérêts principaux et une mise en
œuvre de la PR dès 2003 [100] en utilisant les premiers flots. Néanmoins, nous avons mis
en oeuvre une démarche de conception qui nous a amenés à utiliser des outils et flots de
conception associés à chaque cible de la plate-forme. Nous avons vu dans le chapitre 4 que
la flexibilité d’un système SDR dépend de son architecture matérielle et logicielle. Notre
démarche répond à la problématique de la flexibilité de la couche physique des systèmes
SDR. Les différents types de flexibilité évoqués précédemment sont aussi indissociables des
méthodologies de conception utilisées. Nous verrons particulièrement ce point à travers la
conception d’IP reconfigurables sur FPGA.
Dans ce chapitre, nous décrirons les implications de la conception d’IP reconfigurables
sur FPGA et les améliorations de performances potentiellement apportées sur la reconfi-
guration dynamique. La réalisation d’IP reconfigurables sur FPGA implique l’adoption de
flots de conception particuliers que nous présenterons dans le paragraphe 6.3. Ceci nous
permettra entre autre de présenter l’étude d’une IP de filtrage de mise en forme de type
FIR, avant d’aborder dans le dernier chapitre sa réalisation sur la plate-forme.
93
94 Conception et intégration des applications SDR sur plate-forme reconfigurable
6.1 Intégration de l’application flot de données sur plate-

forme hétérogène
Les composants de traitement “GALS” dont nous avons décrit le comportement dans le
paragraphe 5.3 se trouvent portés sur une plate-forme DSP, GPP et FPGA. En général,
la conception logicielle suit des méthodologies orientées objets déjà bien établies et dont
les avantages ont été largement prouvés dans la littérature, notamment par les modèles
de conception réutilisables [101].
Nous n’adresserons pas particulièrement la conception logicielle, nous indiquerons seule-
ment la manière dont sont intégrés les composants logiciels dans la chaı̂ne de traitement
unifiée.
Fig. 6.1 – Portage de la chaı̂ne unifiée sur plate-forme hétérogène
Nous nous sommes par contre intéressés à la conception de composants sur FPGA où
de nombreux problèmes restent posés.
Les composants logiciels exécutés sur les processeurs sont développées en utilisant les lan-
gages C/C++.
Les composants de traitement exécutés sur le FPGA sont développés en utilisant le langage
VHDL à l’exception des fonctions(1) exécutées sur le processeur embarqué (MicroBlaze)
du FPGA. Les composants implantés sur FPGA sont aussi appelés, fonction matérielle
ou IP matérielle.
Chaque fonction de traitement est encapsulée dans un composant logiciel garantissant

un comportement de type “GALS” de traitement des données. Le composant “GALS”
donne une encapsulation, ou un cadre, à la conception des fonctions de traitement. Cette
encapsulation permet de développer les fonctionnalités indépendamment les unes des
autres que ce soit des composants logiciels ou matériels. L’encapsulation assure aussi
que les fonctions puissent être connectées ensemble pour former la chaı̂ne de traitement.
Le composant d’encapsulation fournit un contrôle du flot de données, par un mécanisme
de requête / acquittement identique sur GPP, DSP et FPGA (HW et SW).
Le prototype de la fonction C du composant d’encapsulation correspond à l’encadré
supérieur de la figure 6.2. Cette figure permet de comparer ce prototype de fonction
logicielles à la déclaration d’entité des IP matériel (VHDL).
(1)
Les fonctions de la chaı̂ne de traitement exécutées sur MicroBlaze sont de fonctionnement équivalents
aux fonctions logicielles développées en C sur processeur.
6.1 Intégration de l’application flot de données sur plate-forme hétérogène 95
Fig. 6.2 – Comparaison des déclarations logicielle et matérielle du composant GALS
Afin d’assurer le fonctionnement de type “GALS” des composants logiciels et matériels

entre eux, les arguments suivants sont au minimum communs entre fonctions logicielles
et entités matérielles :
[mode ] Cet argument permet de contrôler le mode de fonctionnement de la fonction. Il
existe plusieurs modes de fonctionnement, les modes “initialisation”, “en traitement”
et“transparent” sont les principaux.
[flagMail in ] Cet argument permet de contrôler la présence de données à consommer à
l’entrée.
[data in ] Cet argument représente l’adresse à laquelle se trouvent les données d’entrée
à consommer.
• Dans le cas d’une fonction, * data in peut correspondre soit à une adresse de
variable interne (pointeur sur un tableau), soit à une adresse d’un bus physique
externe (par exemple vers une FIFO) lorsque la donnée provient par exemple
d’une entité matérielle et les valeurs à l’adresse * data in sont transmises sur le
bus de données associé.
• Dans le cas d’une entité, data in correspond au bus de données du composant, en
général interconnecté à une FIFO.
[flagMail out ] Cet argument permet de contrôler la présence de données produites en
sortie. Le traitement n’est pas lancé si la mémoire de stockage utilisé en sortie est
pleine.
[data out ] Cet argument est l’équivalent de data in pour les données produites par le
composant.
• Dans le cas d’une fonction, * data out peut correspondre soit à une adresse de
variable interne, soit à une adresse d’un bus physique externe vers laquelle les
données produites sont écrites.
• Dans le cas d’une entité data out correspond à un bus de données.
[... ] Dans le cas d’une fonction logicielle, des arguments optionnels propres à la fonction
de traitement peuvent être passés en addition. Ceci assure aussi l’évolutivité de la
fonction d’encapsulation.
En cours de traitement, le changement de valeur des arguments d’une fonction peut mo-
difier le chemin de données, soit par le changement de mode de fonctionnement, soit par
changement de la source ou de la destination des données en traitement.
De la même manière qu’une fonction logicielle, une fonction matérielle est encapsulée
dans un composant matériel de type “GALS” représenté sur la figure 6.3. Nous avons
déjà décrit dans le chapitre précédent le rôle de ce composant “GALS” et de ses interfaces
timing.
Sur DSP, toutes les fonctions sont appelées successivement en testant si elles doivent trai-
ter des données, sinon les fonctions passent la main (“pooling”).
Sur un FPGA de type Virtex-II, la logique utilisée par cette partie est inférieure à 10
slices (hors utilisation de FIFO). Ceci représente un surcoût de surface faible lorsque le
traitement encapsulé utilise généralement des centaines ou des milliers de slices. Comme
le représente la figure 6.3, nous avons séparé les parties contrôle et traitement synchrone.
La partie “Control processing” est interfacée d’un côté avec le composant d’encapsulation
qui fournit les 4 signaux de contrôle du flot de données vers l’extérieur “data inReady”,
“data inBusy”, “data outReq”, “data outAck”. Dans le cas où des FIFO sont utilisées,
cette partie gère aussi les signaux de lecture et d’écriture dans les FIFO en fonction
des signaux issus du timing. La partie traitant les données est en fonctionnement sous
le contrôle principal du signal “ena” qui autorise le traitement. Pour le moment nous
n’avons pas couplé ce signal à celui d’un signal d’horloge de la fonction. Pour cette raison
nous parlons de fonctionnement de type GALS du point de vue du traitement des données.
Fig. 6.3 – Composant de traitement sur FPGA

Pour les IP dont la structure doit évoluer au cours du temps, la capacité de reconfigu-
ration des FPGA est utilisée et les IP sont alors appelées IP reconfigurables. Les autres
IP sont dites fixes. La reconfiguration est dynamique lorsque le système a la capacité de
reconfigurer une partie de ses ressources pendant l’exécution d’une application. Nous dis-
cutons plus en détails la notion de reconfiguration dynamique dans le paragraphe suivant.
6.1.1 Reconfiguration dynamique

La reconfiguration dynamique ou reconfiguration active est le fait de reconfigurer le
système alors que l’application utilisateur est en cours d’exécution. A l’inverse, la notion
de reconfiguration statique implique l’arrêt de l’application pour procéder à la reconfigu-
ration. La reconfiguration statique est généralement suivie d’un “reset” du circuit afin de
le relancer.
Nous pouvons appliquer la notion de reconfiguration dynamique dans le cas d’un système
multi-FPGA, si ce système a la capacité de reconfigurer un FPGA pendant que le reste
du système est en cours d’exécution, alors nous pouvons considérer que le système est
reconfigurable dynamiquement.
Cependant, la notion de reconfiguration dynamique est le plus souvent associée à la re-
configuration d’un seul FPGA. Dans ce cas, la notion de reconfiguration dynamique est
aussi liée à la capacité de reconfiguration partielle du FPGA.
L. Bossuet [63] souligne que la reconfiguration dynamique est une tâche exécutée concur-
rentiellement aux tâches de traitement de l’application. En effet, nous pouvons considérer
que la reconfiguration dynamique d’un FPGA permet un multiplexage temporel d’un
ensemble d’éléments reconfigurables. Les éléments configurables de cet ensemble sont
réutilisés sous différentes configurations après le lancement d’une application. Nous avons
distingué dans [102] plusieurs cas de mise en œuvre de la reconfiguration dynamique
illustrée par la figure 6.4 :
Fig. 6.4 – Partage des ressources par reconfiguration
Reconfiguration dynamique avec une dépendance de données : Dans le cas no 1

de la figure 6.4, les ressources logiques contenues dans la zone reconfigurable “RC
area” (ReConfigurable area) sont partagées durant un même flot de traitement.
Fig. 6.5 – Chronogrammes de multiplexage par reconfiguration : cas avec dépendance de

données
Les tâches successives T2 et T3 se partagent les ressources. Il est donc nécessaire d’ef-
fectuer une sauvegarde des données après T2 et avant de reconfigurer pour passer à
T3 . Ceci est traduit, sur le chronogramme de la figure 6.5, par la prise en compte du
temps de reconfiguration dans le temps total d’exécution du traitement. Ce chro-
nogramme illustre les cas d’exécutions séquentielle et parallèle du traitement. Ce
type de reconfiguration avec dépendance de données est par exemple utilisé dans
une application de décodeur MIMO décrite dans [102](2) .
Il existe d’autres exemples, dans des architectures reconfigurables de traitement
d’image, les traitements sont complexes. Ils sont alors multiplexés sur un FPGA
pour être appliqués à une même image. C’est le cas par exemple de l’architecture
proposée dans le cadre du projet ARDOISE [103, 104].
Le cas no 1 peut se présenter lorsque le nombre de ressources nécessaires pour im-
planter un traitement est plus grand que le nombre de ressources offertes par le
circuit. Une partie des ressources est partagée dans le temps afin de réaliser le trai-
tement complet. Ceci peut aussi être une stratégie de conception pour utiliser des
circuits plus petits, donc moins coûteux et moins consommateurs d’énergie.
Reconfiguration dynamique sans dépendance de données : Dans le cas no 2 illustré
dans la figure 6.4, la zone reconfigurable “RC area” est partagée entre deux trai-
tements distincts. La reconfiguration est utilisée pour effectuer un changement de
contexte de l’application. Il n’y a pas de sauvegarde de données à assurer avant la
reconfiguration car les données à traiter entre les deux configurations sont distinctes.
Ce cas de reconfiguration intervient par exemple lors d’un changement de service
dans l’application. Un exemple est donné dans [12] pour le changement d’une fonc-
tion de mise en constellation dans une chaı̂ne de transmission. Le chronogramme de
la figure 6.6 est associé à ce cas d’utilisation de la reconfiguration. Ce chronogramme
(2)
Ce travail est réalisé dans le cadre de la thèse de H. Wang à Supélec, campus de Rennes
montre lorsque la demande de reconfiguration (“reconf req”) intervient avant (“case

1”) et après (“case 2”) le traitement par la fonction reconfigurable. Par contre, pen-
dant l’exécution de T2 les demandes de reconfigurations ne sont pas prises en compte.
Fig. 6.6 – Chronogramme de multiplexage par reconfiguration : cas sans dépendance de

données
Les changements de services pouvant illustrer ce cas de reconfiguration sont nom-

breux, comme le changement de traitement suite à un changement de standard, un
changement d’architecture d’une IP, pour changer les performances ou la consom-
mation de la fonction. Ce type de reconfiguration peut aussi être utilisé lors d’une
correction d’erreur sur une IP (“bug fixing”).
Dans les deux cas de reconfiguration dynamique exposés ci-dessus, le temps de reconfi-
guration est une caractéristique qui influe sur les performances des traitements l’utilisant.
Nous le voyons sur les chronogrammes par la dépendance de données entre les tâches T2
et T3 que le temps de reconfiguration est inclus dans le temps d’exécution de l’application.
Il existe des techniques qui permettent de réduire le temps de configuration sur FPGA.
Le temps de reconfiguration
Les architectures reconfigurables de type grain fin, avec comme principal exemple les
FPGA à plusieurs millions de portes logiques à mémoire de configuration (SRAM ou
RAM), sont a priori peu performantes en terme de temps de reconfiguration. En effet,
il faut plusieurs millions de cycles d’horloge pour effectuer une configuration totale d’un
FPGA. En premier lieu, le type de plan mémoire disponible affecte directement les per-
formances de reconfiguration. Dans [61] K. Compton et al. font état de plusieurs types de
plans mémoire.
Les mémoires de configuration à plans multiples permettent un pré-chargement des con-
textes. Le contexte actif correspond à un plan, les autres plans mémoire inactifs sont alors
disponibles pour être rechargés parallèlement à l’exécution. Le changement de configura-
tion est réalisé par basculement d’un plan mémoire à l’autre en un cycle d’horloge. Le
problème dans ce cas est la multiplication des ressources de stockage de configuration
impliquant une augmentation de la consommation statique.
Il existe ensuite les mémoires de configuration à un seul contexte. Ces mémoires sont
moins performantes vis-à-vis des mémoires multi-contextes. Mais ce type de plan est
moins consommateur en ressources mémoires.
Une autre alternative est l’utilisation de plan mémoire partiellement reconfigurable. Cette
capacité est notamment disponible sur les FPGA Xilinx de la famille Virtex, à partir de
la série Virtex-E. Entre 2 configurations il est possible qu’une partie des ressources reste
identique, alors la reconfiguration partielle représente le moyen de réduire significative-
ment le temps de reconfiguration par le chargement de la seule partie variable entre les
configurations. La contrainte ici est de connaı̂tre les parties à configurer et celles restant
inchangées. La diminution de la taille des bitstreams passe par des approches de concep-
tion privilégiant la réutilisation de ressources que nous aborderons dans les paragraphes
6.3. Ces approches de conception sont rendues possible par la capacité de reconfiguration
partielle des FPGA. Enfin cette capacité de reconfiguration partielle est mise en œuvre à
travers des flots de conception également décrits dans les prochains paragraphes.
La réduction du temps de reconfiguration est une préoccupation majeure car un proces-
seur en charge du chargement des bitstreams reste inexploité pour d’autres traitements
durant les chargements. Les techniques aidant à la réduction du temps de configuration
ont fait l’objet de plusieurs études. Les techniques de compression de bitstream [105],
[106] ou les techniques de “configuration caching” [107] permettent de réduire le temps
de reconfiguration.
Il existe aussi la technique de “configuration prefetching” [108] [109] qui permet d’exécuter
la reconfiguration en même temps que du traitement.
Le temps de configuration dépend de la taille du bitstream bien sûr, mais aussi du débit
de l’interface de configuration. Sur un FPGA Virtex-II, que nous avons principalement
utilisé, l’interface de configuration fonctionne à une fréquence de 50 MHz avec des données
de 8 bits. Sur les nouvelles générations de FPGA telles que les Virtex-4, l’interface de
configuration peut fonctionner jusqu’à une fréquence de 100 MHz avec des mots de 32
bits. La vitesse de configuration peut ainsi être augmentée par 8.
Sur le Virtex-II 2000 dont nous disposons, nous avons généré des tailles de bitstreams
variables. La valeur maximale et la valeur minimale de taille de bitstream que nous avons
atteintes sont reportées dans le tableau 6.1 ci-dessous. Tous les temps de reconfiguration
intermédiaires sont possibles, en fonction du nombre de ressources à reconfigurer.
Virtex-II 2000 Bitstream total Bitstream partiel

minimal
Taille du bitstream 830 ko 2 ko
Temps de configuration 16, 6 ms 40 µs
Tab. 6.1 – Temps de reconfiguration d’un Virtex-II 2000
La taille des bitstreams dépend du nombre de ressources à configurer, mais aussi de

la cible et du flot de conception utilisé.
Le temps de configuration est aussi à mettre en rapport avec les besoins applicatifs et
la cadence de traitement à laquelle il doit être exécuté.
6.1.2 Reconfiguration partielle de FPGA

La reconfiguration partielle (RP) est une des techniques permettant de réduire le temps
de configuration du FPGA et nous avons dégagé plusieurs degrés dans l’exploitation de la
RP. D’abord, nous pouvons présenter la reconfiguration partielle sous plusieurs angles :
La reconfiguration partielle permet de reconfigurer seulement la partie d’un design qui

diffère entre 2 configurations successives. Sans la capacité de reconfiguration partielle du
FPGA, lors d’un changement de contexte, même des parties restant identiques entre les
configurations sont reconfigurées. La reconfiguration partielle utilisée suite à l’identifica-
tion des parties communes entre les traitements apporte donc un premier gain en terme
de volume de données de configuration à gérer et réduit le temps de reconfiguration. Dans
les méthodologies de conception d’application partiellement reconfigurable dont celle pro-
posée par [110], le but est bien de maximiser la partie statique d’un design à la fois
fonctionnellement et physiquement pour minimiser la taille de la partie dynamique. Dans
le cas de nos applications, nous avons réalisé cette analyse fonctionnelle en identifiant une
chaı̂ne de traitement commune.
Nous constatons ensuite que la reconfiguration partielle est une capacité inhérente aux
FPGA. Nous pouvons donc aussi l’utiliser pour charger les paramètres d’une applica-
tion. Ceci est aussi la seule solution afin de faire évoluer les paramètres constants, d’une
application déjà conçue et implantée. L’utilisation de la reconfiguration partielle pour ef-
fectuer des opérations de changements de paramètres est aussi un choix de conception afin
de réduire ou de supprimer des parties de contrôle d’une application dédiées au change-
ment de paramètres. Nous le verrons à travers les exemples d’implantations de fonctions
présentées dans le chapitre 7. Dans le cas de la fonction de filtre FIR, l’utilisation de la
reconfiguration partielle nous a permis de changer les coefficients du filtre sans avoir à
utiliser des ressources logiques et de routage du FPGA pour contrôler l’envoi de ces coeffi-
cients. Cela évite d’instancier un bus de données et la logique d’adressage afin d’acheminer
les valeurs de paramètres à l’IP.
La reconfigurabilité partielle offerte par un FPGA dépend de l’architecture du plan mémoire
de configuration. Cette caractéristique technologique évolue et il existe plusieurs types de
plan mémoire partiellement reconfigurable. La reconfigurabilité par rapport à l’architec-
ture du plan mémoire est caractérisée par exemple sous forme d’un taux de reconfiguration
proposé par [63]. Ce rapport est défini comme le nombre minimum d’éléments configu-
rables reconfigurés sur le nombre total d’éléments configurables disponibles.
L’utilisation de la reconfiguration partielle du FPGA passe par la création de bitstreams.
La taille de ces fichiers de configuration partielle dépend directement de l’architecture du
plan de mémoire de configuration des FPGA.
Nous proposons d’illustrer la relation entre taille de bitstream Tbitstream et le nombre
d’éléments effectivement configurés nec en fonction de la taille du bloc unitaire de données
configuration Tbu contenant Nbu éléments configurables.
Cette relation, illustrée par le schéma 6.7, est la suivante.
Tbitstream = Tbu ∗ (1 + E(nec mod Tbu ))
Nous proposons aussi de distinguer les types de plan mémoire existants par le classe-
ment, en ordre de flexibilité croissante, suivant :
0D Nous appelons 0D, les plans mémoires offrant uniquement la possibilité de reconfigu-
ration totale. Dans ce cas, la création d’un bitstream partiel est impossible. Le bloc
unitaire est le bitsream total. Le bitstream a une taille fixe quel que soit le nombre
d’éléments à configurer.
1D Le plan de configuration 1D permet de créer des bitstreams partiels dont la taille
varie en fonction du nombre de colonnes d’éléments logiques à configurer. Dans ce
cas, le bloc unitaire est la colonne.
2D-soft Nous appelons 2D-soft, les plans mémoires 1D permettant de réaliser des régions
reconfigurables de hauteur non égale à des colonnes entières. Ceci permet de partager
des colonnes d’éléments logiques entre plusieurs régions reconfigurables et statiques.
Cette caractéristique est accessible par exemple sur les FPGA Virtex -II/ -II Pro
pourtant dit FPGA reconfigurables par colonne (1D). Nous avons donc appelé ce
type de plan mémoire 2D-soft, car cette caractéristique de reconfiguration de zones
rectangulaires des plans mémoire 1D, dépend du flot de conception et des outils
logiciels mis en œuvre. De plus, dans ce cas la taille du bitstream partiel dépend
bien de la caractéristique physique et donc 1D du plan mémoire. La taille du bits-
tream varie donc seulement en fonction du nombre de colonnes d’éléments logiques
utilisés, et non pas en fonction du nombres d’éléments logiques contenus dans la
zone rectangulaire comme c’est le cas avec les plans mémoire à accès matriciel (plan
2D).
2D-Bloc Nous pouvons distinguer le plan mémoire 2D-Bloc. Les colonnes de configu-
ration sont divisées en sous blocs, ce qui peut être vu comme une architecture à
mi-chemin entre les plans 1D et 2D. Ceci permet d’optimiser la taille du bitstream
et le temps de configuration par rapport au plan mémoire 1D dans les cas de régions
reconfigurables dessinées sur une partie non entière de colonne. Ce type de mémoire
de configuration se trouve dans les FPGA Xilinx de la famille Virtex -4 et Virtex
-5. Ceci semble aussi être un compromis intéressant entre le 1D et le 2D, en effet
peu d’applications nécessitent la création de zones reconfigurables de forme autre
que rectangulaire ou regroupant un nombre très limité d’éléments logiques.
2D Avec un plan mémoire 2D physique, l’accès aux éléments mémoire est matriciel. Les
bitstreams sont de taille proportionnelle au nombre d’éléments logiques à configurer.
Ce type de plan mémoire permet d’obtenir la plus grande flexibilité de reconfigura-
tion du plan logique et aussi la meilleure optimisation du temps de reconfiguration.
Ce type de plan mémoire est disponible par exemple sur les FPGA d’Atmel AT40K.
Fig. 6.7 – Evolution des tailles de bitstream partiel suivant la mémoire de configuration
Dans les FPGA des séries Virtex-E, Virtex-II/II Pro, le plan mémoire est structuré
en colonnes comme l’illustre la figure 6.8. Les structures de la mémoire et des bitstreams
sont détaillées dans une note d’application Xilinx [111].
Fig. 6.8 – Structure de la mémoire de configuration des Virtex
Une frame est l’élément unitaire de configuration. Une colonne de CLB est par exemple
configurable par 48 frames. Cependant, nous avons remarqué par nos expériences que les
éléments effectivement configurés au chargement d’un bitstream sont les éléments dont la
configuration est différente entre les 2 contextes. Les éléments restant inchangés entre 2
contextes ne sont pas reconfigurés. Il est donc bien possible de placer des zones reconfigu-
rables de forme rectangulaire sur les FPGA de type Virtex -II moyennant l’utilisation de
flots de conception particuliers. Nous reviendrons plus en détails sur ces flots de concep-
tion mis en place pour les FPGA Virtex, permettant d’exploiter la caractéristique de
reconfiguration 2D-soft.
La reconfiguration partielle est aujourd’hui exploitée dans diverses applications. Le
projet ADRIATIC par exemple s’est intéressé à développer une méthodologie de concep-
tion, décrite dans [112], et à exploiter notamment la reconfigurabilité partielle des FPGA.
Pour cela les fonctions n’ont pas été implantées d’un seul bloc, ceci limitant l’efficacité de
la reconfiguration, mais sont scindées en sous-blocs. Les sous blocs désignés communs sont
fixes, les autres sont reconfigurables. Cette méthodologie de conception a été appliquée
à un détecteur WCDMA implanté sur un Virtex-II Pro [113]. La zone dynamiquement
reconfigurable du FPGA est alternativement utilisée par 2 contextes. Un premier contexte
est formé du sous bloc d’estimation de canal du détecteur WCDMA. Le second contexte
est formé des sous blocs, filtre adaptatif, “combiner” et “correlater” du détecteur. Cette
approche a permis de réduire la surface nécessaires à l’implantation des fonctions par
utilisation de la reconfiguration (multiplexage temporel).
Nous présentons dans la prochaine section une discussion sur les approches de concep-
tion d’IP reconfigurables sur cible FPGA. Nous nous sommes particulièrement intéressés
aux implications de l’approche de factorisation de traitement et opérateurs communs
évoqués au chapitre 3.
Afin de réaliser des IP reconfigurables il est nécessaire d’adopter des flots de conception
spécifiques pour mettre en œuvre la reconfiguration partielle de FPGA. La mise en œuvre

de la reconfiguration partielle présente des bénéfices, mais l’intégration d’IP reconfigu-
rables présente aussi ses contraintes notamment au niveau des flots de conception. Nous
verrons dans les prochains paragraphes ces flots de conception avancée.
6.2 Approches de conception d’IP reconfigurable sur FPGA

Nous avons vu dans le chapitre 4 présentant les architectures d’exécutions, que différents
types de flexibilité sont apportés suivant les cibles architecturales choisies. Dans le cas du
FPGA, une grande flexibilité à l’exécution peut être apportée par la reconfiguration dy-
namique. Dans cette section, nous proposons une discussion autour de la flexibilité des IP
reconfigurables en fonction de l’approche de conception suivie et en regard de paramètres
tels que le temps de reconfiguration, le stockage des données de reconfiguration, la gra-
nularité de reconfiguration, la surface de l’IP reconfigurable. D’autres aspects importants
sont aussi à prendre en compte tels que le temps de conception de l’IP ou la notion de
réutilisabilité de celui-ci.
Nous proposons de distinguer 3 familles d’architectures d’IP flexibles : les architectures

d’IP paramétrables, génériques et spécialisées. Nous les avons illustrées par la figure 6.9.
Une IP paramétrable est représentée schématiquement sur la figure 6.9.a. Il est à noter
que l’IP paramétrable peut aussi être l’implantation d’une fonction commune telle qu’elle
a été définie par H. Rhiemeier [114]. La flexibilité de l’IP est donnée par le changement
de valeur des paramètres. Cette flexibilité augmente si la partie opérative peut répondre
à une grande dynamique de données avec par exemple des registres et des opérateurs
arithmétiques sur 32 bits. L’utilisation d’opérateurs paramétrables du type ALU permet-
tant de réalisés plusieurs types d’opération d’addition et de soustraction augmente la
flexibilité de ce type d’architecture. La partie contrôle donne aussi la flexibilité à l’IP et
doit permettre à une grande variété des paramètres applicatifs d’être pris en compte. Le
contrôle doit permettre de gérer le paramétrage de la partie opérative.
Fig. 6.9 – Les différentes architectures d’IP flexibles

6.2 Approches de conception d’IP reconfigurable sur FPGA 105
A l’opposé, sur la figure 6.9.c est représentée une IP spécialisée exploitant la granularité
fine des ressources logiques du FPGA. Cette approche offre la possibilité de concevoir des
architectures dédiées à chaque fonction. Dans ce cas, la partie opérative est dimensionnée
pour traiter un type de données. Tous les opérateurs instanciés sont utilisés pendant le
traitement. La partie contrôle est limitée à un séquencement unique des données d’entrée
et des opérateurs. Dans ce cas la flexibilité de l’IP vient uniquement du fait que l’IP a
la propriété d’être globalement reconfigurable. En d’autres termes ceci correspond sim-
plement à instancier l’IP dans une région reconfigurable du FPGA. Un changement de
paramètres au niveau fonctionnel implique donc de reconfigurer totalement l’IP.
La figure 6.9.b schématise les IP dites génériques dont la conception se situe à mi-chemin
entre les solutions entièrement paramétrables n’exploitant pas la capacité de reconfigura-
tion du FPGA, et la solution des IP spécialisées nécessitant la reconfiguration complète
à chaque changement fonctionnel. La conception de ces IP génériques est caractérisée
par une partie opérative permettant de répondre à de nombreux besoins. Ainsi la par-
tie opérative est réutilisable à l’exécution dans plusieurs contextes fonctionnels. Certains
opérateurs peuvent aussi être reconfigurables pour adapter l’architecture de l’IP aux be-
soins applicatifs. La partie contrôle est conçue comme dans le cas d’une IP dédiée soit
pour chaque contexte fonctionnel, soit avec une capacité de gestion d’un nombre limité
de paramètres. Ceci afin de limiter les ressources physiques consommées par la partie
contrôle. Les changements fonctionnels sont alors réaliser par reconfiguration de la seule
partie contrôle de l’IP.
Nous voyons que la capacité de reconfiguration partielle peut être mise en œuvre à
différents niveaux de granularité dans les designs (3) implantés sur un FPGA. Les parties
reconfigurables des designs sont encadrées en rouge dans la figure 6.9. Nous verrons à
travers l’étude d’une IP de filtrage au paragraphe 6.4 et à travers d’autres exemples d’im-
plantation au chapitre 7, les proportions de complexité entre contrôle et traitement dans
les IP afin de mesurer l’impact d’une telle approche.
Nous sommes conscients que les trois familles d’architectures décrites ci-dessus ne repré-
sentent pas une étude exhaustive d’exploration architecturale sur les IP flexibles. Néanmoins
la présentation de ces trois familles d’IP flexibles va nous permettre de mettre en balance
simultanément trois approches de conception sous le critère de la flexibilité et de discuter
des compromis de conception autour des IP reconfigurables.
La discussion qu’ouvre la notion d’IP flexible ou d’IP reconfigurable permet de dessi-

ner un espace de conception représenté par la figure 6.10. En effet, la plupart des travaux
rencontrés dans la littérature utilisent la capacité de reconfiguration dynamique partielle
des FPGA pour mettre en œuvre des designs se situent dans la zone IP totalement recon-
figurable, ou dans la zone des IP paramétrables sans utiliser la reconfiguration, (cf. figure
6.10).
Le temps de reconfiguration est une caractéristique des IP flexibles. Ce temps de

configuration est proportionnel au volume de données de configuration. Dans le cas d’IP
paramétrables le coût du stockage des contextes est minimal (stockage de valeurs de pa-
ramètres) et représente une taille négligeable comparée aux bitstreams à stocker dans le
(3)
le mot design est utilisé afin de définir une architecture intégrée sur un composant.
Fig. 6.10 – Espace de conception des IP flexibles sur FPGA

6.2 Approches de conception d’IP reconfigurable sur FPGA 107
cas des IP reconfigurables. L’IP paramétrable n’exploite pas la capacité de reconfiguration

des FPGA, le temps de configuration est en fait nul, le changement de contexte corres-
pond au chargement en un cycle d’horloge de nouvelles valeurs de paramètres. Le temps
de reconfiguration des IP génériques est plus faible que celui des IP spécialisées dans la
mesure où seulement une partie d’une IP générique est désignée comme reconfigurable.
Dans le cas d’IP spécialisées, la consommation de mémoire de stockage est très impor-
tante. En effet chaque bitstream correspond à la totalité de la configuration d’une IP, alors
que dans le cas d’une IP générique les bitstreams contiennent seulement la configuration
d’une partie de l’IP.
La complexité d’une IP détermine la surface occupée une fois placée et routée sur
le FPGA. Dans le cas d’une IP paramétrable, l’utilisation d’opérateurs sur 32 bits ainsi
que la conception de parties de contrôle complexes permettant de paramétrer l’exécution
sont très consommatrices en ressources logiques en conception sur FPGA. La surface et
donc la consommation des IP paramétrables sont plus élevées que les IP dimensionnées
exactement pour exécuter une fonction comme les IP spécialisées. En remarquant que le
contrôle est très consommateur en ressources dans les designs FPGA, la conception d’IP
génériques avec des parties opératives réutilisables, mais des parties contrôles dédiées per-
met de réduire la complexité globale de l’IP par rapport aux IP paramétrables.
La consommation devrait être le critère prédominant dans la conception d’IP pour des
systèmes embarqués (4) . Dans la conception d’IP reconfigurables, le critère de consomma-
tion globale d’une IP doit inclure non seulement la consommation énergétique lors de
l’exécution mais aussi la consommation de chaque reconfiguration. L’énergie dépensée
lors d’une reconfiguration est proportionnelle au temps de reconfiguration donc plus le
bitstream est grand plus le coût de reconfiguration est élevé.
Dans une problématique globale de réduction de consommation, un composant conçu

de manière spécialisée, notamment afin de réduire sa consommation à l’exécution peut
s’avérer globalement moins consommateur si les demandes de reconfigurations sont trop
fortes. Pour cela les architectures de composants paramétrables bien que pouvant répondre
à un nombre fini de configurations ont une consommation plus élevée mais ne dépendant
pas des demandes de changement de contextes. Du point de vue de la consommation les
architectures dites génériques peuvent se présenter comme un compromis en offrant des
reconfigurations de plus faibles tailles.
Enfin des critères comme le temps de configuration à la mise sous-tension ou le temps

de conception sont des critères non directement liés à la flexibilité d’une IP mais dont
l’impact peut être important. Lors de la configuration initiale, le moins pénalisant est
la configuration d’une IP spécialisée alors qu’une IP paramétrable occupant plus de res-
sources sur le FPGA est plus longue à configurer.
(4)
Pour cette raison nous avons mené avec David Elléouet, (Thèse [115] du LESTER Lorient et
IETR/INSA Rennes) dont les travaux portent sur l’estimation de consommation au niveau système des
FPGA, une étude conjointe sur la consommation de la reconfiguration des FPGA.
Fig. 6.11 – Compromis pour la conception d’IP reconfigurables
Le temps de conception est une donnée importante du coût économique de développement

d’une IP et de son délai de mise sur le marché. Le temps de conception d’une IP pa-
ramétrable peut être important du fait que sa description soit réalisée au niveau archi-
tecturale dans un but de performances. Les objectifs de performances impliquent que
certaines parties des IP soient développées au niveau RTL afin exploiter les performances
du FPGA. En effet, l’instanciation de primitives (éléments logiques câblés) telles que des
blocs RAM, FIFO, multiplieurs câblés ou blocs DSP est parfois nécessaire afin atteindre
de bonnes performances sur des IP utilisées intensivement. Les temps de conception plus
court sont atteints en réalisant des descriptions comportementales et en s’appuyant sur les
performances des outils de synthèse. Ceci peut convenir à la réalisation d’IP spécialisées
dont la durée de vie aussi a priori plus courte.
Le temps de conception des IP génériques est allongé par la difficulté encore grande de
spécifier des IP reconfigurables par parties. Le manque de maturité des outils de conception
face à ce type d’approches de conception est à regretter. Bien que les récentes évolutions
des outils de conception facilitent l’utilisation de la reconfiguration partielle de FPGA en
rendant moins lourd les flots de conception, la mise en œuvre d’une IP partiellement re-
configurable n’est pas aisée. Nous verrons dans le prochain paragraphe les différents flots
de conception donnant accès à la création de bitstreams partiels.
Notre démarche nous a aussi poussés à exploiter les alternatives existantes entre les
deux extrémités de l’espace de conception que sont les architectures paramétrables et
les IP spécialisées. Ces alternatives sont à rapprocher des idées de factorisation et pa-
ramétrisation données au niveau algorithmique (présentées au chapitre 2). Cette zone d’ex-
ploration est caractérisée par la conception d’IP que nous nommons semi-reconfigurables.
6.3 Flots de conception d’IP reconfigurables sur FPGA 109
C’est-à-dire que le composant de traitement est lui-même partiellement reconfigurable.

La séparation des parties opératives et de contrôles des composants de traitement, lors de
la description comportementale ou RTL, et le maintient de cette séparation à l’étape de
placement routage par l’ajout de contraintes de surface, rend possible cette approche de
conception d’IP semi-reconfigurable. Par exemple, dans le cas de l’utilisation d’opérateurs
communs, les ressources de traitement génériques sont réutilisées alors que la partie
contrôle peut être dédiée et reconfigurée pour changer la fonctionnalité. La reconfiguration
est alors une solution qui permet de réduire la surface occupée par la partie contrôle d’une
fonction.
6.3 Flots de conception d’IP reconfigurables sur FPGA

Nous décrivons dans ce paragraphe les méthodologies permettant de concevoir les IP
reconfigurables de type spécialisé ou générique évoquées dans le paragraphe précédent.
Notons que pour les IP paramétrables ne tirant pas leur flexibilité de la reconfiguration,
leur conception peut suivre des flots classiques.
Il existe de nombreux outils et flots de conception permettant de mettre en oeuvre la
reconfiguration partielle sur FPGA. Un large aperçu des outils dédiés à la conception
d’applications partiellement reconfigurables est donné par Mesquita et al. dans [116] et
présente que les possibilités de conception des applications PR sont directement liées aux
capacités offertes par ces outils. Nombre de ces outils sont développés dans le cadre de
recherches académiques et souffrent malheureusement d’un manque de support à diverses
familles de FPGA et de suivi d’évolution des cibles. Nous avons donc choisi de nous baser
sur les outils standards de conception offerts par Xilinx pour proposer des méthodologies
de conception permettant de concevoir trois types d’IP reconfigurables.
Fig. 6.12 – Description système avec IP Reconfigurables
Nous pouvons schématiser la description de la réalisation des IP reconfigurables par

les trois cas illustrés dans la figure 6.12.
Dans le cas a), une IP spécialisée est placée dans une zone reconfigurable dynamiquement
(RPR Region Partiellement Reconfigurable).
Le cas b) peut correspondre à une IP générique avec une partie faiblement reconfigurable,
concernant seulement la reconfiguration de quelques blocs logiques.

Le cas c) correspond à une IP générique dont une sous-partie, incluant les ressources lo-
giques et de routage est reconfigurable.
Suivant le contexte applicatif chacune de ces approches ont un intérêt, comme le montre
l’étude de cas du paragraphe 6.4 et les exemples d’IP présentés dans le chapitre 7.
Les flots de conception doivent permettre d’atteindre les différentes granularités de

reconfiguration partielle requises par les cas exposés. Afin de générer les fichiers de confi-
gurations correspondant à ces différentes granularités de reconfiguration, il est nécessaire
de mettre en œuvre des flots de conception avancée basés sur une conception modulaire
proche de celle utilisée en conception d’ASIC. Quel que soit le flot où le type de ressources
à reconfigurer le but est de générer des fichiers de configuration partielle. Historiquement,
il existe deux flots de conception proposés par Xilinx dans [117] permettant de mettre en
œuvre la reconfiguration partielle. Ces flots sont nommés “Module-Based Partial Reconfi-
guration” et “Difference-Based Partial Reconfiguration”. “Module-Based PR” permet de
créer des bitstreams partiels pour des modules reconfigurables (MPR Module Partielle-
ment Reconfigurable) placés/routés dans une RPR. Ce flot est basé sur la conception par
module présenté par la figure 6.13.
Le second flot, “Difference-Based Partial Reconfiguration”, est présenté par Xilinx comme
permettant d’accomplir de petits changements sur un design placé/routé. Le bitstream
partiel est généré par différence entre un design d’origine et ce même design ayant eu
quelques modifications. Le bitstream partiel représente les différences entre ces deux de-
signs.
Nous présenterons aussi notre méthodologie de conception basée sur un flot de conception
proposé plus récemment par Xilinx.
6.3.1 Flot : “Module-Based Partial reconfiguration”

Ce flot est basé sur une méthodologie de conception modulaire proposée par Xilinx et
appelée “Modular Design” [118]. Cette méthodologie de conception permet de placer et
router chaque IP d’un design, indépendamment, dans des zones prédéfinies à l’avance
par des contraintes de surface. Les modules reconfigurables sont identifiés au moment
de la création de ces contraintes et les bitstreams sont ensuite générés pour ces modules
placés/routés. Le flot “Module-Based Partial Reconfiguration” que nous avons décrit en
détail dans [12], permet de répondre à la problématique de conception d’IP spécialisées,
mais ne permet pas de concevoir des IP génériques. Le MPR créé à l’aide de ce flot est
interconnecté avec le reste du design par des interfaces spéciales appelées Bus Macro
(voir le paragraphe ci-après sur les Bus Macro pour une description détaillée). Mais ce
flot principalement destiné à la cible Virtex-/-E/-II/-II Pro présente quelques contraintes
pour créer des MPR. La principale contrainte est que la taille de la zone reconfigurable
doit être d’une hauteur entière de colonne de CLB et de largeur minimale de 4 colonnes de
CLB. Ceci représente une limitation forte à la conception sur les possibilités de placement
des modules à la surface du FPGA. Les Bus Macro utilisables avec ce flot sont les Bus
Macro basés sur des “3-State Buffers” BUFT et ne permettent pas une grande flexibilité
de conception. De plus, ces interfaces sont seulement instanciables au niveau le plus haut
Fig. 6.13 – Flot de concepion modulaire sur FPGA
dans la description de l’application (dans le Top-Level design) comme l’illustre le cas a)

de la figure 6.12. Notons que ce flot ne semble plus maintenu pour les cibles Virtex-4.
6.3.2 Flot : “MoDiff-Based Partiel Reconfiguration”

Une possibilité pour générer des bitstreams partiels est de réaliser, à la fin du flot de
conception, entre deux designs complètement placés/routés, leur différence. Il est à noter
que dans ce cas aucune zone du FPGA n’est désignée comme reconfigurable à l’inverse
du flot “Module-based PR”. Un flot de conception classique peut donc être suivi jusqu’au
placement/routage final.
Xilinx présente la méthode par différence par le flot nommé “Difference-Based PR” comme
une solution pour générer un bitstream partiel lorsqu’un design est modifié après place-
ment routage à l’aide de l’éditeur de design “fpga editor”. Les modifications apportées
après placement routage sont donc en général limitées à des changements de configuration
d’éléments logiques (CLB, BRAM, DCM). Ces modifications sont réalisées manuellement
via l’interface graphique de “fpga editor”.
Nous avons étendu l’utilisation de la méthode par différence afin de générer des bits-
treams partiels de modules complets comme l’illustre la figure 6.14. En combinant le flot
Modular Design, afin de pouvoir placer des contraintes de surface, décrites dans [119], sur
les modules placés individuellement, et en utilisant la méthode de génération de bitstream
par différence, nous proposons un flot que nous appelons MoDiff-Based Partial Reconfigu-
Fig. 6.14 – Création de bitstream de configuration partielle : Méthode par différence
ration (5) . Il n’est pas nécessaire d’utiliser des Bus Macro avec ce flot. En revanche l’uti-
lisation de wrapper décrit au paragraphe A.1 pour assurer le routage des interconnexions
d’un module reconfigurable permet d’assurer qu’il n’y aura pas de différence de placement
routage dans la zone ne changeant pas de configuration. Cette méthode a l’avantage de
permettre la création de zones reconfigurables de n’importe quelle forme rectangulaire et
non pas seulement en colonnes entières de CLB. Ce flot est disponible sur n’importe quelle
famille de FPGA, sans attendre l’évolution des outils de conception ni la disponibilité des
Bus Macro.
Lorsque la reconfiguration concerne des ressources de routage, l’inconvénient de ce flot

est que le bitstream généré par différence représente un bitstream des différences relatives
entre deux configurations et non pas un bitstream absolu d’une configuration d’un module.
Par contre, lorsqu’aucune ressource de routage est reconfigurée, le bitstream par différence
représente un bitstream absolu. Ce flot permet de concevoir des IP reconfigurables dans le
cas a) et c) avec plus de flexibilité que le flot “Module-Based PR”. Avec le flot MoDiff nous
avons en fait anticipé, avec la même philosophie de conception, le futur flot proposé par
Xilinx. Il préfigure cette nouvelle génération de flot de conception, plus souple d’utilisation,
développé par Xilinx. Mais l’avantage de MoDiff est sa disponibilité sur toutes les versions
des outils de conception classiques(6) .
Nous avons aussi utilisé le flot “MoDiff-Based PR” couplé à la conception de macros. Lors
de la description système en VHDL, il est possible de réaliser des macros par instantiation
de primitives physiques [120] (les éléments logiques : LUT, BRAM, MULT18X18, SRL16).
(5)
Nous avons choisi le nom MoDiff-Based PR par contraction de nom de flot Modular-Based et
Difference-Based Partial Reconfiguration
(6)
A partir de ISE Fundation v5.2i, sur les Virtex-II/-II Pro/-4
Fig. 6.15 – Création du bitstream partiel d’une Macro : Méthode “Macro PR Difference-
Based Design Flow”
Ainsi les éléments logiques à modifier sont identifiés à haut niveau. Nous décrivons de
cette façon les différents changements de configuration de ces macros au niveau système,
en VHDL, et non plus après l’étape de placement routage. Cela peut répondre à certains
cas d’utilisation de type b,c de la figure 6.12.
Cette approche de l’utilisation de la génération de bitstreams par différence est illustrée
figure 6.15. Dans ce cas les bitstreams générés ne contiennent aucune information de
routage, la macro les ayant fixées, les bitstreams représentent donc des contextes absolus
et non plus des changements relatifs entre deux contextes.
6.3.3 Flot : “Partial Reconfiguration”

Suite à la conférence du SDR Forum 2005 et à l’intérêt que Xilinx a porté aux travaux
que nous y avons présenté [49], nous avons, grâce au contact de Xilinx, accès à leurs outils
de conception avancée comme “Selected Customer”. La méthodologie présentée ici repose
donc sur les futures versions des outils et flots de conception Xilinx, non commerciale-
ment disponible. Ce nouveau flot n’ayant pas de nom “commercial” nous le désignons par
“Partial Reconfiguration”.
Ce flot permet de réaliser des bitstreams de configuration de modules en augmentant la
flexibilité de conception par rapport au flot “Module-Based PR”.
Ce flot est utilisable avec de nouvelles versions de Bus Macro disponibles pour Virtex-II/-
II Pro et V4. Il est basé sur la méthode par différence pour la génération des bitstreams
partiels. Ceux-ci sont créés par différence entre un design complètement placé et routé
contenant le module reconfigurable et le design contenant uniquement la partie statique.
La différence ainsi créée représente bien la configuration du module MPR. Un exemple

d’application utilisant ce flot est illustré par la figure 6.17.
Sur la base de ce nouveau flot, nous avons développé une méthodologie de conception
à l’aide de l’outil PlanAhead. Cette méthodologie permet de réaliser tous les types de
modules reconfigurables présentés figure 6.12. Les cas a et c sont traités de façon similaire
à celle décrite dans les paragraphes précédents. La méthodologie que nous proposons de
suivre pour réaliser des IP semi-reconfigurables (cas a figure 6.12) est illustrée par la figure
6.16.
Fig. 6.16 – Flot de conception d’IP reconfigurable sur FPGA
Cette méthodologie présente une étape de transcription des “netlists”, supplémentaire

par rapport aux autres flots notamment “Module-Based”. Cette étape de transcription
est réalisée à l’aide de l’outil de “floorplanning” hiérarchique PlanAhead. Ceci permet de
dissocier complètement la description de haut niveau du système réalisée en VHDL, de la
description du système permettant de réaliser le placement routage sur le FPGA.
Les descriptions du niveau le plus élevé et des IP sont synthétisées avec un outil de
synthèse (par exemple XST Xilinx Synthesis Tool) avant d’être transcrites à l’aide de
PlanAhead. PlanAhead garde les niveaux de hiérarchie des descriptions VHDL. A l’étape
de transcription, les parties reconfigurables des IP sont donc extraites afin d’être placées
dans des zones reconfigurables RPR en vue du placement routage suivant les contraintes
de surface définies.
Il est à noter que PlanAhead permet d’automatiser la suite du flot de conception jusqu’à
la création automatique de tous les bitstreams partiels et totaux.
Fig. 6.17 – Création du bitstream partiel d’un module : Méthode “PR Design Flow”
6.3.4 Connexion d’une région reconfigurable

Le placement/routage des signaux d’entrées sorties d’une zone reconfigurable doit être
identique d’une configuration à l’autre. Afin de garantir le bon fonctionnement des inter-
connexions entre une partie reconfigurable et le reste du design reconfigurable ou statique,
les signaux d’interconnexion passent par des interfaces appelées Bus Macro.
Ces Bus Macro sont des composants pré-routés qui sont placés à cheval entre une
région reconfigurable et une autre région reconfigurable ou statique. Les Bus Macro sont
fournis par Xilinx pour les différentes familles de FPGA. La première génération de Bus
Macro est basée sur des BUFT (cf. figure 6.18) et disponible pour les séries Virtex-E/-
II/-II Pro. Chaque BUFT-Based Bus Macro est une interface de communication 4 bits où
le BUFT est seulement utilisé comme point de jonction à une ligne de routage. Ces Bus
Macro ne sont pas d’une utilisation souple comme le souligne C. Patterson dans [121]. En
effet, les BUFT sont reliés par des lignes de routage longues dont la densité est faible sur
les FPGA. Le routage des signaux par ces lignes longues affecte les délais de propagation
et la consommation.
Virtex-/-E Virtex-II/- Virtex-4

II Pro
Largeur d’1/2 BUFT-Based BM 4 colonnes 2 colonnes /
de CLB de CLB
Largeur d’1/2 LUT-Based BM 2 colonnes 2 colonnes 2 colonnes
de CLB de CLB de CLB
Largeur d’1/2 wrapper 1/2 colonne 1/2 colonne 1/2 colonne
de CLB de CLB de CLB
densité de signaux par CLB :
Cas du BUFT-Based BM 1 sig./CLB 2 sig./CLB /
Cas du LUT-Based BM 4 sig./CLB 4 sig./CLB 4 sig./CLB
Cas du wrapper 8 sig./CLB 8 sig./CLB 8 sig./CLB
Tab. 6.2 – Comparaisons des densités d’intégration des Bus Macro
Fig. 6.18 – BUFT-Based et LUT Based Bus Macro sur FPGA Virtex-II
Une nouvelle génération de Bus Macro représentée dans le figure 6.18 est proposée
par Xilinx. Ces Bus Macro sont basés sur des LUT et sont mono-directionnelles (“Left-
ToRight” et “RightToLeft”). Ils sont déclinés en plusieurs versions dont notamment une
version 4 bits et une version 8 bits. Nous avons utilisé ces Bus Macro fournis pour les cibles
Virtex-II/-II Pro/-4. Il est à noter que sur les FPGA Virtex-4 d’une part il n’existe plus
de BUFT, et d’autre part que Xilinx a créé des versions “Bottom2Top” et “Top2Bottom”
de Bus Macro comme l’illustre la figure 6.19. De notre côté, nous avons développé les ver-
sions de Bus Macro Bottom2Top et Top2Bottom fonctionnant pour les cibles Virtex-II.
Les versions LUT-based Bus Macro améliorent la flexibilité de la reconfiguration, par la
densité d’intégration plus forte offerte par les LUT comparées au BUFT et par la dis-
ponibilité de déclinaisons horizontales et verticales de ces interfaces. Par exemple dans
un FPGA Virtex-II la densité de LUT par CLB est le double de celle des BUFT comme
l’indique le tableau 6.2. De plus, les possibilités de routage pour atteindre les LUT sont
plus élevées que celles offertes pour atteindre les BUFT-based BM.
Fig. 6.19 – Horizontal et Vertical LUT Based Bus Macro sur FPGA Virtex-II
Nous avons aussi mis en œuvre dans le cadre du travail effectué en collaboration avec
l’Universitat Politècnica de Catalunya (UPC), décrit au paragraphe A.1, une solution d’in-
terconnexion d’une zone reconfigurable dans le cas où celle-ci présente un grand nombre
de signaux d’entrées/sorties. Dans ce cas, l’instanciation de Bus Macro est fastidieuse et
coûteuse en ressources. Nous proposons une solution de wrapper basés sur des LUT. Ces
wrapper s sont décrits sous forme de macro dans laquelle sont instanciés les LUT. Une
solution de wrapper est aussi proposée dans [121] à la place des Bus Macro basés sur des
BUFT. Ces wrapper s utilisent les ressources logiques des CLB et aussi les ressources de
routage à travers les “switch matrix” adjacentes aux CLB. La conception de ces interfaces
repose donc à la fois sur l’utilisation des outils classiques ISE pour les ressources logiques
mais aussi sur un outil, Jroute [122], pour la manipulation des ressources de routage du
FPGA. Or cet outil, le seul outil orienté sur les ressources de routage, est basé sur JBits
[123, 124, 125, 126], expérimental il n’est pas diffusé, et ne supporte pas toutes les familles
de FPGA. Ceci représente donc les fortes limitations de cette proposition.
6.3.5 Création d’une macro
Fig. 6.20 – Macro placée et routée sur une colonne de CLB de Virtex-II
Les macro créées sont de type RPM “Relationally Placed Macro”. Nous décrivons ce
type de macro en VHDL par instanciation directe de primitives FPGA. Les primitives dis-
ponibles pour réaliser des macros sont les registres, ROM, RAM, RAMD, LUT, MUXCY,
XORCY, MULT AND, SRL16. Une macro est réalisée en créant des contraintes de pla-
cement relatives sur les primitives (RLOC) [119]. La macro est ensuite placée de façon
absolue, comme n’importe quel module à l’étape de “floorplanning”. Toutes les configu-
rations sont décrites au niveau VHDL. La description sous forme de macro et le flot de
conception modulaire garantissent un placement routage identique à la macro dans toutes
les configurations. Les bitstreams partiels peuvent donc être générés pour chaque confi-
guration par la méthode par différence et sont de taille minimale.
Afin de minimiser la taille du bitstream, il est nécessaire d’implanter les primitives

dans le minimum de colonnes de CLB. Nous proposons donc un algorithme de parcours
vertical des slices. Cet algorithme sert à déterminer les contraintes RLOC de placement
relatif par rapport aux coordonnées relatives de placement des slices illustrées dans la
>for i = 0 to N - 1
> sliceRowIndex(i) = i mod 2 + 2 * (i/4)
> sliceColumnIndex(i) = (i/2) mod 2
>Endfor
Fig. 6.21 – Placement des contraintes de location sur slice Virtex-II
figure 6.20. Dans le cas où une seule colonne de CLB est utilisée la taille du bitstream
partiel de configuration est minimale.
Nous pouvons illustrer l’utilisation de la reconfiguration pour réduire la complexité
matérielle par rapport à des solutions paramétrables en donnant l’exemple de la fonction
simple de multiplexage 2x1 figure 6.22. Alors qu’une implantation paramétrable utilise
des LUT trois entrées, l’implantation reconfigurable par le remplacement du signal de
sélection par la reconfiguration permet d’utiliser deux configurations de LUT deux entrées
(cf. figure 6.22).
Fig. 6.22 – Implantation de multiplexeur sur FPGA
Dans les FPGA les LUT sont à 4 entrées (LUT4), il n’y a pas de gain en terme de res-
sources logiques dans le cas cité précédemment, mais un gain en ressource de routage. Le
gain en ressources logiques est réalisé sur des multiplexeurs de plus grandes tailles comme
l’illustre le tableau 6.3. Dans ce tableau, la complexité est donnée sous forme d’une LUT
à N entrées avec N = M + log2 (M ) et M représente le nombre de bits d’entrées du mul-
tiplexeur, log2 (M ) le nombre de bits de sélection du multiplexeur. Les nombres de LUT4
de Virtex-II sont donnés par les rapports de synthèse sous XST.
Un exemple montrant l’intérêt de multiplexeurs reconfigurables en remplacement du

paramétrage a été récemment donné par F. Fons et al. dans [127]. Ces travaux portent sur
un accélérateur CORDIC utilisant des multiplexeurs 3x1 dont l’implantation est réalisée
sur un FPGA Atmel AT94K40.

Un autre exemple [128] sur cible Virtex-II est proposé par S. Young et al. de Xilinx.
L’application représente un cas extrême de nombre de multiplexeurs utilisés par un com-
mutateur reconfigurable “crossbar switch”. Le commutateur est de dimension 928 entrées
et 928 sorties. 53 824 CLB seraient nécessaire pour une implantation paramétrable alors
qu’un FPGA Virtex-II xc2v6000 compte 8 448 CLB. Pour atteindre une telle dimension de
928x928 les auteurs de Xilinx, ont utilisé les matrices de routage du FPGA comme multi-
plexeur 8x1. Des multiplexeurs 32x1 reconfigurables ont donc pu être implantés dans une
seule LUT4 précédée de 4 matrices 8x1. Cette implantation représente un optimum de
l’utilisation de la reconfiguration mais sa mise en œuvre n’est pas reproductible avec les
outils commercialement disponibles contrairement à l’approche de macro reconfigurable
que nous proposons.
Paramétrable Reconfigurable
MUX
Complexité Nb LUT4 Complexité Nb LUT4 &
matérielle de Virtex-II matérielle Nb config. V-II
MUX 2x1 1 LUT3 1 LUT4 1 LUT2 1 LUT4 & 2 cfg.
MUX 16x1 1 LUT20 8 LUT4 4 LUT4 4 LUT4 & 16 config.
Tab. 6.3 – Multiplexeur paramétrable versus reconfigurable

6.4 Etude de cas : la fonction de filtrage FIR 121
6.4 Etude de cas : la fonction de filtrage FIR

Nous avons ici choisi de présenter les différentes implantations d’IP reconfigurables en
prenant l’exemple d’un filtre FIR.
En effet, les fonctions de filtrage sont des fonctions très largement répandues dans les ap-
plications de transmission. Les filtres numériques de types FIR représentent une solution
bien connue pour réaliser ces fonctions. De très nombreuses études sont disponibles dans
la littérature proposant différentes architectures et leurs implantations sur FPGA. Sur
FPGA Altera J. Valls et al. [129] proposent une étude comparative des implantations de
plusieurs architectures de filtres. Récemment, Xilinx présente dans [130] plusieurs archi-
tectures de filtre FIR et leurs implantations sur Virtex-4. En 2006, Y.-J Oh [131] propose
une architecture de filtre FIR dynamiquement reconfigurable sur FPGA Virtex-II Pro. Ce
filtre reconfigurable de structure parallèle est réalisé à l’aide de la méthodologie de concep-
tion classique “Module-Based PR”. Le filtre est partiellement reconfigurable et possède 2
configurations 12 ou 20 taps. L’architecture parallèle du filtre est partagée en une partie
statique comprenant le filtre 10 taps et la partie partiellement reconfigurable afin d’at-
teindre 20 taps.
Le propos de cette étude n’est pas de comparer les performances de différentes archi-
tectures de filtres FIR, de nombreuses études sont depuis longtemps disponibles comme
nous l’avons souligné précédemment. Nous souhaitons ici illustrer à travers un filtre FIR
donné, les différentes implantations possibles en IP reconfigurables. L’architecture du filtre
que nous avons choisie est un filtre de structure canonique possédant 4 taps cascadés per-
mettant de réaliser des longueurs jusqu’à 32 taps. L’architecture du filtre est par ailleurs
détaillée dans le prochain chapitre.
Le filtre est décrit en VHDL comme le composant que nous avons vu figure 6.3. Les res-
sources logiques nécessaire à l’implantation(7) de ce FIR sont données dans le tableau
6.4. Nous pouvons remarquer que la partie contrôle de ce composant représente 58% de
ressources en slices utilisés dans l’IP. Cet exemple montre bien que le contrôle est très
consommateur de ressources dans les implantations FPGA.
Virtex-II FIR complet FIR partie opérative FIR partie contrôle

Slices 325 138 (42%) 187 (58%)
BRAM 5 4 1
MULT18x18 4 4 0
Tab. 6.4 – Ressources utilisées par l’implantation du filtre sur Virtex-II
La figure 6.23 illustre trois implantations différentes en IP reconfigurable de ce même

FIR où la zone reconfigurable est marquée par un cadre rouge. Les trois implantations
sont réalisées à partir de la même description de FIR, dont les résultats de synthèse sont
reportés dans le tableau 6.4, afin de comparer uniquement les implantations en terme de
reconfigurabilité.
(7)
La description VHDL a été synthétisée pour FPGA Virtex-II en utilisant XST [132] sous ISE Fundation
v6.3i.
Le premier schéma 6.23.a est le cas d’une implantation sous forme d’une IP entièrement
reconfigurable pouvant figurer comme un exemple d’IP spécialisée. Dans ce cas, quel que
soit le paramètre à changer dans la fonction de filtrage, l’IP est entièrement reconfigurée.
Cette implantation peut être réalisé par le flot de conception classique “Module-based
PR”.
Dans le second cas, 6.23.b, les ROM sont identifiées comme une macro reconfigurable. Cet
exemple permet d’illustrer le cas d’une IP qui serait générique. Cela permet de changer
les coefficients du filtre par reconfiguration du contenu des ROM sans avoir à utiliser de
ressources supplémentaires pour gérer le chargement des données par valeurs. Les jeux de
coefficients des filtres sont donc contenus dans des bitstreams générés par le flot “MoDiff-
PR”. Dans ce cas, aucune zone n’est définie à la conception comme reconfigurable. Les
ROM sont conçues sous forme d’une macro afin d’en fixer l’emplacement lors du placement
routage de l’IP.
Fig. 6.23 – Différents types d’IP reconfigurables à l’implantation du FIR
Le schéma 6.23.c illustre le cas d’une IP semi-reconfigurable. La zone désignée comme

reconfigurable se situe à l’intérieur de l’IP. Dans notre exemple de filtre FIR, il s’agit de
la partie contrôle. La reconfiguration du contrôle permet de changer la machine d’état
gérant le traitement afin d’effectuer divers types de filtres par exemple de longueurs ou
de taux de sur-échantillonnage différents. Nous pouvons noter qu’entre la partie contrôle
(reconfigurable) et la partie opérative (statique), il est nécessaire d’ajouter des Bus Macro.
Dans un flot de conception classique pour la reconfiguration partielle, l’instantiation de
modules en zone reconfigurable et de Bus Macro n’est autorisée qu’au niveau du top-level
(entre IP). Or dans une IP semi-reconfigurable, la sous partie reconfigurable de l’IP et les
Bus Macro sont déclarés à un niveau inférieur au top-level (les Bus Macro et le MPR sont
à l’intérieur de l’IP). Ceci nous a amenés à définir la méthodologie de conception illustrée
par le diagramme figure 6.16 où l’étape de transcription de netlist est ajoutée dans le flot
de conception (cf. paragraphe décrivant le flot “Partial Reconfiguration”) et permet de
telles implantations. L’implantation en IP semi-reconfigurable convient pour les IP dites
génériques.
Le même filtre FIR a ici été utilisé afin de comparer les différentes approches de concep-
tion que nous avons présentées dans les paragraphes précédents. En effet, les différentes
implantations ne présentent pas les mêmes caractéristiques de reconfigurabilité et de res-
sources à reconfigurer. Les résultats issus des 3 types d’implantations décrites ci-dessus
sont rapportés dans le tableau 6.5. Ces résultats nous amènent à plusieurs constatations.
L’IP FIR implantée de façon entièrement reconfigurable occupe une surface de 22LCLB ∗
6CCLB . La taille du bitstream associé est directement liée au nombre des 6 colonnes de
CLB nécessaire à l’implantation de l’IP.
L’adaptation du filtre par changement des valeurs de coefficients, en utilisant la reconfi-
guration pour changer le contenu des ROM, est effectuée avec des bitstreams de taille très
réduite de 2 ko donc un très faible surcoût en terme de temps de reconfiguration.
Virtex-II IP FR IP SR IP macro R.
Taille de la zone reconfigu- 22L ∗ 6C 22L ∗ 2C 4 BRAM
rable (en Li ∗ Col de CLB)
Taux d’occupation en slices de 81,3% 81,2% /
la zone RP
Taille bitstream partiel sur 54,2 ko 18,7 ko 2 ko
xc2v1000
Taille bitstream partiel sur 74.7 ko 25.7 ko 2 ko
xc2v2000
Tab. 6.5 – Résultats des implantations du FIR sur Virtex-II
La reconfiguration de la partie contrôle, rendue possible par une implantation sous

forme d’IP semi-reconfigurable, occupe une zone PR de 22LCLB ∗ 2CCLB . Cette approche
permet de réaliser des bitstreams partiels de taille réduite (18,7ko dans le cas du xc2v1000)
par rapport à une implantation en IP entièrement reconfigurable. Ceci représente entre
les deux cas, sur la taille des bitstreams et temps de reconfiguration un gain de 65%.
Afin de minimiser la taille des bitstreams il serait possible à surface équivalente de modifier
la forme de la zone reconfigurable, en augmentant la hauteur de la zone reconfigurable et
réduisant sa largeur. Mais ceci a trois conséquences, la première est d’englober dans la zone
reconfigurable, des ressources rares, BRAM et MULT18 non utilisées qui pourraient être
nécessaires à d’autres fonctions, deuxièmement de risquer des difficultés de routage dûes
à la forme longiligne de la zone et risquer de diminuer les performances post placement
routage de l’IP en augmentant les longueurs des chemins de routage. La minimisation de
la taille du bitstream dans le cas de l’IP totalement reconfigurable donne les résultats
présentés dans le tableau 6.6. Avec un minimum de 4 colonnes de CLB allouées à l’IP et
un taux d’occupation en slices quasi-identique, le gain apporté sur la taille du bitstream
partiel est de 35%.
De nombreuses autres solutions architecturales existent dans le cas du FIR, pour les-
quelles les trois types d’implantations en IP reconfigurables présentées seront plus ou moins
adaptées, suivant la flexibilité et les performances que le concepteur souhaite introduire
dans son système. Nous pensons notamment que les architectures de traitement parallèle
où le contrôle représente une partie moindre des ressources face à la partie opérative,
les implantations de type IP entièrement reconfigurables sont plus adaptées. De plus,
les architectures de type parallèle sont mises en œuvre lorsque les performances sont re-
cherchées et dans ce cas, les opérateurs dédiés sont préférables aux opérateurs génériques.
L’implantation en IP entièrement reconfigurable se justifie donc doublement. A l’inverse
les architectures de traitement itératif où l’utilisation opérateurs communs génériques est
privilégiée, le contrôle représente une partie plus grande des ressources consommées. Afin
de réduire le nombre de branchements, de paramètres à gérer de façon variable, l’utilisation
d’IP semi-reconfigurables où la partie contrôle n’est pas paramétrable mais reconfigurable
permet de réduire le nombre de ressources utilisées puisque la capacité de reconfiguration
est intrinsèque au FPGA.
FIR complet xc2v1000 Zone PR 22L ∗ 6C CLB Zone PR 43L ∗ 3C CLB

Taux d’utilisation Slices 81.3% 81.6%
BRAM disponibles 5 8
Taux d’utilisation BRAM 100% 62.5%
MULT18x18 disponible 5 8
Taux d’utilisation MULT18x18 80% 50%
Taille des bitstreams partiels 54,2 ko 35.6 ko
Tab. 6.6 – Minimisation de la taille du bitstream par changement de forme de la zone PR
Conclusion
Ce chapitre apporte nos réflexions sur les méthodologies de conception concernant l’ar-
chitecture des composants de traitement reconfigurables pour les applications de chaı̂nes
de communications, dans une optique d’une amélioration de la reconfigurabilité. L’adop-
tion des méthodologies de conception décrites dans ce chapitre 6 est un moyen de réduire
les coûts liés à la reconfiguration. La reconfiguration partielle de FPGA est notamment
adoptée afin de limiter la surcharge imposée par la reconfiguration en terme de temps
d’adaptation, de mémoire occupée ou même de bande occupée en cas de téléchargements
via l’interface air (Over-The-Air-Reconfigurtion OTAR).
Afin de résumer les notions essentielles vues dans ce chapitre nous pouvons dire que la
notion de reconfiguration dynamique permet d’exécuter des traitements en partageant les
ressources physiques reconfigurables. La notion de reconfiguration partielle étend celle de
la reconfiguration dynamique avec un partitionnement des applications de façon à ressor-
tir les parties présentant des communités à la fois fonctionnellement et physiquement. La
transition entre configurations est finalement accomplie en changeant les différences entre
ces configurations. Nous avons vu à travers nos expériences que les flots de conception
jouent un rôle important pour tirer profit des capacités de reconfiguration des FPGA. Au
delà des performances de reconfiguration des FPGA qui sont dépendantes de la technolo-
gie comme nous avons pu le suivre ces dernières années avec l’évolution des FPGA et des
outils de conception, nos approches de conception d’IP reconfigurables visent à apporter
principalement une flexibilité aux applications multistandard. Elles sont validées par des
implémentations sur FPGA de fonctions de traitement du signal présentées dans le cha-
pitre 7.
Nous avons aperçu que dans la zone de conception appelée “reconfiguration partielle
de composant” de la figure 6.10 les solutions architecturales sont très variées, nous en
donnerons les exemples dans la partie 7 avec l’implantation de composants flexibles de
traitement. Nous avons apporté en outre une méthodologie afin de rendre possibles les
implantations de solutions originales d’IP reconfigurable comme par exemple les IP semi-
reconfigurables. Nous pensons que cela augmente très significativement les solutions archi-
tecturales offertes par la reconfiguration partielle des FPGA. Mais nous sommes conscients
de ne pas avoir répondu de façon exhaustive à la question des IP flexibles par une ap-
proche formelle de leurs conception. Des architectures originales de composants sont encore
à découvrir dans cet espace, néanmoins il existe des contraintes de réalisation difficiles à
contourner et qui peuvent limiter la conception.
A travers, les différentes méthodologies de conception sur FPGA proposées dans ce cha-
pitre, nous avons aussi présenté, les différents niveaux de granularité de reconfiguration
atteignable par ces approches. En effet, la reconfiguration peut être mise en œuvre sui-
vant les besoins et les contraintes au niveau des opérateurs logiques, par exemple sur des
multiplexeurs, à des niveaux de granularité plus gros par la réalisation d’une IP semi-
reconfigurable et au niveau fonction par une IP totalement reconfigurable.
Enfin pour élargir notre réflexion sur la conception dans le domaine de la RL, il est
difficile d’envisager qu’une méthodologie ou qu’un flot intégré à un outil puisse répondre
à l’ensemble des contraintes que pose la conception de tels systèmes, tant les standards
sont multiples et les plates-formes diverses. De plus, il faut tenir compte de la longueur
du cycle de développement d’un outil pour qu’il atteigne sa maturité, devienne stable et
robuste, face à l’évolution rapide des composants. Afin d’être performants, les outils et
méthodologies ne peuvent répondre que de façon ciblée et partielle à la problématique
générale. Pour ces raisons, le flot de conception d’applications SDR est actuellement-et
sans doute encore pour longtemps, une combinaison d’étapes de conception qui fait appel
à de nombreux outils adresse chacun de manière efficace une étape de la conception.
Chapitre 7
Réalisation : plate-forme radio

logicielle et implantation
Sommaire
A.1 Conception d’interface pour Objet P-HAL partiellement re-
configurable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
A.2 Étude de consommation de la reconfiguration . . . . . . . . . 163
Introduction
Dans ce dernier chapitre, nous nous intéressons à la plate-forme radio logicielle que nous
avons mise en œuvre. La plate-forme matérielle est hétérogène et comporte un processeur
GPP, un DSP et un FPGA. Cette plate-forme s’approche en terme de variété d’exécution
offerte, des besoins des classes de traitements exprimés dans la section 3.2.2. En cela la
plate-forme est représentative de ce que sera un système SDR.
Suivant l’analyse algorithmique des fonctions multistandard développées dans le chapitre
3, nous proposons dans ce chapitre des implantations de fonctions multistandard de traite-
ment en bande de base. Ces implantations nous permettent aussi de valider les différentes
approches de conception proposées dans le chapitre 6. De plus, les traitements sont im-
plantés sous forme d’une chaı̂ne de traitement comme nous l’avons décrit dans le para-
graphe 6.1. Le fonctionnement de cette chaı̂ne sur notre plate-forme nous permet de valider
notre approche de conception d’application flot de données de type “GALS” portée sur
des ressources matérielles hétérogènes.
Nous décrivons aussi, dans un premier temps, l’adaptation à la plate-forme matérielle du
modèle de gestion de configuration hiérarchique proposé dans le chapitre 5.
127
128 Réalisation : plate-forme radio logicielle et implantation
7.1 Gestion de configuration hiérarchique sur la plate-forme

7.1.1 Portage de la structure de gestion de configuration sur la plate-
forme hétérogène
La réalisation sur plate-forme matérielle sert à valider le modèle fonctionnel décrit au cha-
pitre 5. Nous décrivons ci-dessous la structure de gestion de configuration hiérarchique telle
qu’elle a été portée sur la plate-forme. La description fonctionnelle est indépendante des
aspects plate-forme matérielle et permet une adaptation de celle-ci lors de la réalisation.
Dans l’implantation proposée ici, le niveau opérateur est confondu avec le niveau fonction.
De ce fait, il existe donc un L3 CMU par fonction et au niveau supérieur un L2 CMU
gère un groupe de fonctions. Nous avons donc élevé le niveau de granularité des entités
gérées par les unités de gestion de configuration. Avec cette adaptation nous conservons
cependant les caractéristiques d’une gestion hiérarchique et distribuée propres au modèle
de gestion de configuration proposé chapitre 5. La principale différence se situe donc au
niveau des entités gérées par les unités de configuration. En effet, dans le modèle fonc-
tionnel nous proposons que chaque fonction constituée en sous-fonctions de traitement
soit gérée par un L2 CMU, puis que chacune des sous-fonctions soit prise en charge par
un L3 CMU. Le modèle fonctionnel autorise aussi qu’un L2 CMU soit responsable d’un
ensemble de fonctions, un L3 CMU est alors en charge de la gestion de configuration
d’une fonction. C’est le choix que nous avons fait pour toutes les unités de gestion. Le
nombre d’unités de gestion de configuration à déployer sur la plate-forme est ainsi réduit
au maximum. La mise en œuvre de la gestion hiérarchique est alors simplifiée et l’approche
validée sur la plate-forme matérielle. Ci-dessous, la description de notre gestion de confi-
guration hiérarchique portée sur la plate-forme matérielle illustre le fonctionnement de
cette structure notamment sur le protocole de communication entre les unités de gestion
et les procédures de mise en œuvre de la reconfiguration.
L1 CM
Le L1 CM est un composant logiciel indépendant du matériel, dont l’instance sur un
système est unique. Le module matériel sur lequel le L1 CM est implanté devient le module
maı̂tre de la plate-forme. Ce module est alors nommé HOST. Le L1 CM se situe entre
l’entité de gestion de service applicatif utilisateur et les unités de gestion de configuration
de niveau 2, (suivant les standards et les services, l’entité de service applicatif utilisateur
noté “User Application Manager” peut être située dans des couches supérieures, la couche
MAC(1) ou la couche application utilisateur).
Le L1 CM est l’unité centrale de gestion de configuration pour l’ensemble de la plate-
forme pendant son fonctionnement. Le L1 CM a un rôle de gestion de configuration de
haut niveau des composants de traitement.
La bibliothèque de configuration associée au L1 CM est une mémoire sur le Host

contenant les configurations sous forme de listes d’informations. Une liste contient les in-
formations sur les fonctions de traitement disponibles sur la plate-forme, leurs paramètres
ainsi que leurs implantations possibles sur les modules matériels. Une seconde liste contient
les informations sur les fonctions paramétrées et actives dans la chaı̂ne de traitement et
(1)
Couche liaison de données “Medium Access Control” (couche Layer2 dans le modèle OSI)
7.1 Gestion de configuration hiérarchique sur la plate-forme 129
donne au L1 CM l’état de la configuration de la chaı̂ne de traitement. La liste active

est maintenue à jour après chaque reconfiguration. Les deux listes sont consultées par le
L1 CM lors d’une demande de changement de services.
L2 CMU
Nous avons vu lors de la présentation du modèle fonctionnel de gestion hiérarchique la
possibilité qu’un L2 CMU soit en charge d’un groupe de fonctions au lieu de gérer une
fonction constituée de sous-blocs de traitement. Ce groupement élève donc le niveau de
granularité des entités gérées par le L2 CMU. Dans ce cas, il en est de même concernant
les L3 CMU. Ceci a deux effets principaux. Le premier est de réduire la flexibilité de confi-
guration de l’application, car le nombre d’entités à gérer est plus faible. Ceci découle de
l’augmentation de la granularité des entités. La diminution du nombre d’entités à gérer en-
traı̂ne la diminution du nombre de L2 CMU à déployer. La seconde conséquence est donc
la réduction de la complexité de mise en oeuvre de la structure de gestion dynamique.
Suite à la découpe en trois catégories de traitement proposée au chapitre 3.2.2, nous pou-
vons pousser le raisonnement en réduisant jusqu’à 3 le nombre de L2 CMU à mettre en
œuvre. Chaque catégorie de traitement s’exécute sur une cible matérielle différente.
Un L2 CMU devient donc, dans ce cas, l’unité de gestion de configuration d’un module
matériel et assure l’adaptation des demandes de configurations émises par le L1 CM. Nous
avons choisi, cette solution pour le déploiement de la structure de gestion sur la plate-
forme en faisant le choix de réduire la complexité d’implantation de la gestion hiérarchique.
Ceci étant, il est envisageable pour certaines fonctions de conserver un L2 CMU dédié à
une fonction. Ceci se justifie pour des fonctions complexes et présentes dans un grand
nombre d’applications. La fonction doit alors posséder une grande flexibilité donnée par
une gestion de configuration en sous-blocs fonctionnels afin de s’adapter à chacune des
applications.
Dans le cas de l’implantation réalisée ici, qui est une sous-partie restreinte d’un système
d’émission multistandard, le nombre de L2 CMU instancié est de 3. Un L2 CMU est im-
planté sur chaque module matériel de la plate-forme.
Ces unités de gestion de configuration sont responsables de la configuration des fonctions
de traitement mises en œuvre sur chaque module. Les L2 CMU ont deux fonctionnalités
principales. Le rôle du L2 CMU est de répartir les paramètres de configuration de chaque
fonction aux L3 CMU associés à ces fonctions. Le L2 CMU est, de plus, en charge de la
configuration du chemin de données de traitement (processing datapath). Ce chemin de
données est configuré par les L2 CMU à l’aide des adresses de chaque composant. (Une
interface d’adaptation du format de données peut être mise en place par le L2 CMU entre
deux composants de traitement.)
Le L2 CMU initie les procédures d’insertion et de suppression de fonctions sur le module
dont il est en charge. Un L2 CMU gère la modification du chemin de données qu’implique
la modification de l’architecture du chemin de données sur le composant.
Le type de changement de contexte est décidé par le L2 CMU, en fonction des paramètres
de configuration et en relation avec la capacité de reconfiguration de l’instance du com-
posant (par paramètre, par reconfiguration).
L3 CMU
Nous avons précédemment justifié notre choix du regroupement des fonctions, afin de
réduire le nombre d’instances de L2 CMU. Ceci a pour effet d’augmenter le niveau de
granularité des entités gérées par les L3 CMU.
Fig. 7.1 – Composant paramétrable et reconfigurable, liaison avec le L3 CMU
Le L3 CMU se charge de la reconfiguration ou du changement de paramètres d’une

fonction de traitement implantée sous forme d’un composant “GALS”. Le composant
“GALS” fournit le contrôle de configuration, selon les besoins du traitement, soit des
signaux d’autorisation soit de demande de configuration, au L3 CMU.
Un signal d’autorisation est donné suite à une demande de reconfiguration du L3 CMU,
lorsque le bloc n’a plus de données à traiter. Une fois l’autorisation reçue par L3 CMU,
celui-ci effectue le chargement effectif du fichier de configuration via une interface de
configuration (dont le détail est donné au paragraphe suivant).
Un signal de demande de configuration est nécessaire lorsque les reconfigurations sont
à l’initiative du traitement lui-même, nous en donnons un exemple dans [102]. Lorsque
la demande de configuration est initiée par la fonction de traitement elle-même, cette
demande est réalisée à l’aide d’un signal reconf req émis par le contrôle de la fonction vers
le L3 CMU. C’est le cas d’une fonction dont les sous-blocs de traitement partagent les
mêmes ressources (cf. paragraphe 6.1.1 sur la reconfiguration dynamique avec dépendance
de données). Ce signal est envoyé au L3 CMU qui adresse, un ordre de chargement du
fichier de configuration au contrôleur de configuration.
Dans le cas d’un changement de contexte par paramètres, les paramètres de configuration
sont envoyés par le L2 CMU au L3 CMU qui les interprète en fonction de l’implantation
de la fonction puis envoie à la partie contrôle du composant ces paramètres. Les deux cas
de composant paramétrable et reconfigurable associé à un L3 CMU sont illustrés par la
figure 7.1.
7.1 Gestion de configuration hiérarchique sur la plate-forme 131
7.1.2 Implantation de la structure de gestion de configuration sur la

plate-forme
La plate-forme matérielle utilisée pour le prototypage se compose d’un GPP sous forme
d’une station de travail PC, d’un DSP et d’un FPGA. Ces deux circuits sont disposés sur
une carte de prototypage Sundance décrite en annexe C.6. Sur cette plate-forme matérielle
la structure de gestion de configuration est implantée comme l’illustre la figure 7.2, de la
manière suivante :
Le L1 CM est implanté sur le GPP. Le GPP est donc le Host. Un L2 CMU est implanté
sur chaque module matériel. Il existe donc trois instances de L2 CMU, sur le GPP, le
DSP et sur le processeur embarqué du FPGA. Chaque fonction du chemin de traitement
a un L3 CMU associé. Sur le FPGA, il existe deux types de traitements. Les traitements
implantés sous forme d’IP fixes, éventuellement paramétrables et les IP reconfigurables
implantées dans les régions reconfigurables. Les L3 CMU des IP fixes sont implantés locale-
ment à la fonction afin de réduire les chemins de contrôle des paramètres. Les L3 CMU des
IP reconfigurables sont déportés dans le processeur embarqué MicroBlaze. Les L3 CMU
sont reliés à un contrôleur de configuration. Le contrôleur de configuration du FPGA, dont
nous parlons dans le paragraphe suivant, est responsable du chargement des bitstreams
à travers l’interface de configuration du FPGA. La reconfiguration du FPGA étant in-
trinsèque à son architecture, il n’y a pas besoin de bus de données de configuration entre
une IP reconfigurable et le L3 CMU, à l’inverse du cas d’une IP paramétrable. En effet,
la reconfiguration d’une IP est atteinte par le plan mémoire de configuration du FPGA.
Fig. 7.2 – Portage de la structure de gestion de configuration sur la plate-forme

Contrôle de configuration sur FPGA

Un contrôleur de configuration sur FPGA est l’entité responsable du chargement des fi-
chiers de configuration (bitstreams) dans le plan mémoire du FPGA via une interface
de configuration. Il existe plusieurs interfaces de configuration dont deux externes et une
interne permettant de réaliser des reconfigurations partielles. Les interfaces externes le
port SelectMap ou le BoundaryScan sont disponibles sur tous les composants FPGA de
Xilinx. L’interface SelectMap est la plus rapide, sur Virtex-II elle fournit typiquement une
cadence de chargement des données sur 8 bits à 50 MHz. Il existe une interface de confi-
guration interne appelée ICAP (Internal Configuration Access Port) [120] disponible sur
les Virtex-II/-II Pro et V4 et répond aux mêmes spécifications que l’interface SelectMap.
Afin de contrôler le processus de configuration décrit dans [133] et d’envoyer les bitstreams
sur une des interfaces de configuration, il existe deux solutions de contrôleur comme
l’illustre la figure 7.3. Un contrôleur externe peut-être par exemple un processeur GPP ou
un DSP, de même un contrôleur interne peut-être un processeur de type MicroBlaze/PPC
ou plus simplement une machine d’état. La solution que nous avons retenue est d’utiliser
le processeur MicroBlaze connecté à l’interface de configuration ICAP par l’intermédiaire
d’un contrôleur d’ICAP. Cette interface ICAP permet de réaliser des reconfigurations
uniquement partielles. Blodget et al. dans [134, 135] parlant d’auto-reconfiguration ou de
“self-reconfiguration” [135] du FPGA.
Fig. 7.3 – Deux solutions de contrôleur de configuration pour FPGA
7.2 Procédures et scénarios de reconfiguration sur la plate-

forme
Nous décrivons dans cette section les procédures de configuration de la plate-forme. Nous
avons distingué les procédures d’initialisation de la plate-forme à sa mise sous tension,
des procédures de reconfiguration en cours d’exécution.
Enfin nous illustrerons la mise en œuvre de la gestion de configuration à travers des
scénarios de reconfiguration applicatifs.
7.2.1 Initialisation de la plate-forme

La configuraton initiale de l’ensemble du système assure à la fois la configuration de la
structure de gestion de configuration et celle du chemin de traitement des données.
Lors de l’initialisation du chemin de données, certaines fonctions de traitement sont actives

et d’autres inactives (mode transparent). La procédure d’initialisation de la plate-forme
comprend :
– L’initialisation des modules de la plate-forme avec une configuration initiale.
– La configuration des interfaces de communication des différents modules.
– L’instanciation de la structure de gestion de configuration (le gestionnaire de confi-
guration L2 de chaque module)
– L’instanciation des composants de traitement matériels et logiciels (HW et SW),
(pendant la procédure d’initialisation les L3 CMU sont vus comme des composants
HW ou SW)
7.2.2 Reconfiguration de fonctions sur la plate-forme

Suite à la configuration initiale, la chaı̂ne de traitement est prête à recevoir des données.
De même, la structure de gestion de configuration est prête à recevoir des demandes de
reconfiguration. Cependant nous pouvons distinguer deux types de procédures de recon-
figuration :
Reconfiguration totale de la plate-forme : la (re)configuration totale de la plate-
forme correspond à une (ré)initialisation de la plate-forme. Cette procédure peut
être réalisée afin de changer l’architecture du chemin de données implanté sur la
plate-forme. Nous verrons dans le paragraphe 7.3, les différentes topologies envisa-
geables, sur la logique configurable, pour le chemin de traitement. Les différentes
implantations de chemins de traitement sont nommées profils plate-forme. Le chan-
gement de profil d’une plate-forme peut aussi être partiel par exemple lorsque seul
le design implanté sur le FPGA est changé. Aucun service n’est maintenu lors de ce
type de procédure, il n’y a donc pas de notion de reconfiguration dynamique.
Reconfiguration partielle de la plate-forme : les changements de contexte applica-
tif effectués sous un profil matériel défini (chemin de données établi) sont pris en
charge par la structure de gestion de configuration.
Le changement de contexte applicatif est initié par un service de l’application utilisa-
teur qui est transmit au L1 CM. Le L1 CM retransmet aux L2 CMU les demandes de
reconfiguration de l’application, sur le bus de données de configuration. Les L2 CMU
transmettent ensuite les ordres de configuration aux L3 CMU en charge d’effectuer
l’adaptation des traitements en fonction de leurs implantations.
Ensuite sur une plate-forme hétérogène, deux cas de reconfiguration partielle du chemin de
données sont possibles. Un premier cas où la fonction reste sur le même module matériel.
Un second cas où la fonction change de module. Les procédures de gestion de configuration
à travers la structure hiérarchique correspondant à ces deux cas sont décrites ci-dessous.
Les descriptions suivantes sont données pour le changement de paramètres d’une fonction,
un changement de service peut concerner plusieurs fonctions.
Cas n˚1 : Fonction restant sur le même module
Fig. 7.4 – Fonction restant sur le même module
L1 CM
Notification de la demande : le L1 CM reçoit les demandes de changement de service
de l’utilisateur. En fonction de la nature du changement et de la liste des fonctions de
traitement le L1 CM détermine vers quel L2 CMU envoyer un ordre de changement.
La consultation de la liste de fonction permet de connaı̂tre le L2 CMU en charge de la
fonction à changer. Une fois le changement de fonction effectué, la liste des fonctions
actives et les paramètres utilisés seront mis à jour sur réception d’un acquittement
du L2 CMU.
Envoi trame de commande : une trame de commande (Type 1 fig. 7.6) envoyée par le
L1 CM contient l’adresse du L2 CMU concerné par la reconfiguration, l’identifiant
de la fonction et la valeur des nouveaux paramètres de la fonction.
L2 CMU
Identification : identification par le niveau L2 CMU dans la trame de commande en-
voyée par le L1 CM du champ de l’adresse logique du L2 CMU. Dans le cas où un
bus d’adresse est disponible entre les niveaux L1 et L2, l’envoi de la trame peut être
direct, par adressage physique.
Réception : le L2 CMU responsable de la fonction en question reçoit la trame de com-
mande envoyée par le L1 CM et interprète les champs de la trame avec l’identifica-
tion de la fonction de configuration.
Envoi paramètres : les nouveaux paramètres sont envoyés au L3 CMU en charge du
changement effectif de la fonction.
L3 CMU
Réception paramètres : en fonction des nouveaux paramètres envoyés par le L2 CM
et la nature de l’implantation de la fonction, le L3 CMU va effectuer le changement
de configuration.
Contrôle de la reconfiguration : Le L3 CMU effectue le changement de contexte de
la fonction en contrôlant l’état de la fonction. Dans le cas d’un IP HW le L3 CMU
par un signal reconf req stoppe la fonction. En fin de reconfiguration le L3 CMU
donne l’acquittement de configuration au L2 CMU retransmis ensuite au L1 CMU
pour la mise à jour de la liste de fonction.
Changement effectif de fonction : Si la fonction est un composant paramétrable,
alors le changement de contexte est un chargement de paramètres. Si la fonction cor-
respond à un composant reconfigurable, alors le changement de contexte est réalisé
par chargement de la nouvelle configuration (bitstream).
Cas n˚2 : Fonction changeant de module (FPGA/DSP)
Fig. 7.5 – Fonction changeant de module
L1 CM
Notification de la demande : la notification par l’utilisateur de demande est identique
à celle du cas n˚1. Dans ce cas les nouveaux paramètres ne correspondent pas à ceux
gérés par le L2 CMU de la fonction active. Le L1 CM prend la décision de changer
la fonction de L2 CMU. Le L1 CM doit donc activer sur un L2 CMU la fonction
dont les paramètres sont pris en charge et faire une demande de mode transparent
au L2 CMU d’origine.
Envoi trames de commande : deux trames de commande désignant les L2 CMU con-
cernés par la reconfiguration sont envoyées. Une première trame tr a est destinée au
module dont une fonction est désactivée. La trame tr b est destinée au module sur
lequel la fonction est activée. La trame tr a contient l’adresse de la fonction passant
en mode transparent. La trame tr b contient l’adresse de la fonction passant en
mode actif et les nouveaux paramètres de la fonction.
L2 CMU
Modification du chemin de traitement : chaque L2 CMU modifie sur le module dont
il est en charge le chemin de données pour assurer la connectivité de la fonction
déplacée. Le L2 CMU est associé à une table de routage qui maintient l’adressage
logique entre les fonctions.
Autres procédures : les autres procédures prises en charge à ce niveau sont semblables
à celles décrites dans le premier cas.
L3 CMU Les procédures mises en place au niveau L3 ne changent pas entre ce cas et
le premier.
Trame de commande de configuration

Les commandes de configuration sont envoyées entre les différentes unités de gestion de
configuration sous forme de trames. La principale trame de type 1, illustrée figure 7.6 est
mise en oeuvre entre le L1 CM et le L2 CMU. Lors d’une demande de changement de
service, le L1 CM formate pour chaque L2 CMU concerné pour un ou plusieurs change-
ments de fonctions une trame de type 1 contenant l’ensemble des paramètres sur chaque
fonction à reconfigurer. Les trames de type 1 ne contiennent pas d’informations relatives
à l’implantation des fonctions comme les trames de paramètres envoyées par les L2 CMU
aux L3 CMU. Ceci est un élément assurant l’indépendance des niveaux L1 et L2 vis-à-vis
des implantations des fonctions.
Fig. 7.6 – Trame (Type 1) pour l’échange des informations de gestion configuration entre
L1 et L2
Cette trame est dimensionnée pour des L2 CMU gérant jusqu’à 16 fonctions. Il est à
noter qu’actuellement il existe 13 fonctions au maximum dans le modèle de chaı̂ne unifiée
dont la gestion est répartie sur plusieurs L2 CMU. Le nombre maximum de paramètres
par fonction est de 8 paramètres codés sur 4 bits. La taille maximale théorique de cette
trame est de 584 bits. Cette taille de trame est difficilement atteignable, elle signifierait
que 16 fonctions à 8 paramètres doivent être reconfigurées pour un changement de service.
Ce qui correspondrait éventuellement à un changement de standard exécuté sur un seul
module matériel. A l’inverse, lorsqu’une seule fonction à 4 paramètres est à changer sur un
module, la taille de la trame de type 1 est de 28 bits. Ceci correspond à l’envoi d’un seul
mot de configuration sur un bus 32 bits. Ceci est une faible surcharge de la bande passante.
La réalisation actuelle de la gestion de configuration permet des configurations en mu-

tuelle exclusion des différents modes de fonctionnement du modem. Ceci ne peut garantir
le fonctionnement de “soft handover” entre modes. Il est nécessaire d’avoir deux chaı̂nes
de transmission actives afin de garantir un “soft handover” (cf. discussion sur les types
de terminaux au chapitre 2).
Outre les procédures de changement de configurations locales que nous avons détaillées
ci-dessus, la structure de gestion de configuration pourra être sollicitée pour le chargement
de nouvelles configurations.
Il s’agit de chargements à distance utilisés pour l’ajout de nouvelles configurations, la
mise à jour ou la correction de fonctionnalité. Dans de tels cas la liste des fonctions de la
librairie de configuration du L1 CM doit être étendue et contenir le code correspondant
à la nouvelle fonctionnalité téléchargée. Cette procédure pourra être prise en charge par
le L1 CM qui devra mettre à jour la hiérarchie de gestion de configuration. Ces nouvelles
configurations peuvent être de différents types, profil de plate-forme, nouvelles fonction-
nalités, nouvelles configurations d’une fonction, nouveaux paramètres d’une fonction.
7.2.3 Scénarios de reconfiguration des applications multistandard

Nous décrivons dans ce paragraphe différentes configurations de la chaı̂ne de traitement
pour le standard 802.11g. Nous donnons à travers 4 modes de ce standard, 4 configurations
de la chaı̂ne de transmission 802.11g illustrées figure 7.7.
A partir de ces 4 configurations nous définissons des scénarios de reconfigurations as-
sociés. Ces scénarios de changement intra-standard permettent de mettre en œuvre les
mécanismes d’insertion, de suppression ou de paramétrage des fonctions, utilisés dans
tous les types de reconfiguration de la chaı̂ne de traitement. De même, le partitionnement
logiciel/matériel des 4 configurations est donné pour illustrer les cas de reconfigurations
de fonctions décrites ci-dessus.
La gestion de configuration hiérarchique est impliquée dans les 4 scénarios différents

de changement de contexte applicatif détaillés ci-dessous. Sa mise en œuvre est similaire
à d’autres scénarios de reconfiguration impliquant GSM et UMTS pour des changements
intra-standard et inter-standards.
Scénario 1 : Changement de la configuration 1 vers la configuration 2 (figure 7.7).
La demande de changement de traitement est prise en compte par le L1 CM puis re-
distribuée aux L2 CMU concernés. Dans ce scénario seul un L2 CMU (celui situé sur
le DSP) est sollicité pour la fonction de poinçonnage. La fonction de poinçonnage est

activée dans la chaı̂ne de traitement, c’est-à-dire qu’elle passe du mode transparent
à un mode actif avec la configuration r=3/4.
Scénario 2 : Changement de la configuration 2 vers la configuration 3.
Ce scénario implique la reconfiguration du traitement effectué par la fonction de mise
en constellation. En plus de l’augmentation de l’ordre de constellation, la fonction de
mise en constellation est changée de composant matériel et passe du DSP au FPGA.
C’est alors le cas n˚2 de reconfiguration évoqué précédemment qui est sollicité par le
L1 CM. Deux ordres de reconfiguration sont transmis par le L1 CM aux L2 CMU
du FPGA et du DSP en charge du changement de la fonction constellation. Le
L3 CMU est en charge de la reconfiguration du traitement constellation avec la
valeur “QPSK” transmise par le L2 CMU.
Fig. 7.7 – Configurations de la chaı̂ne de transmission en 802.11g

Dans ce scénario, plusieurs fonctions de traitement sont concernées par une recon-
figuration de type cas n˚2. Plusieurs ordres de reconfiguration sont donc envoyés
par le L1 CM. L’ordonnancement des tâches de reconfiguration vise à favoriser la
première fonction productrice de données. Les ordres sont donc en tout premier lieu
envoyés pour les fonctions situées le plus en amont de la chaı̂ne. Dans ce scénario,
les ordres de reconfigurations sont envoyés successivement à la fonction scrambler,
puncturing puis interleaver.
Dans ce scénario, les tâches de gestion de configuration sont la suppression d’une
fonction (puncturing) (ou la mise en état transparent) et le changement de mo-
dule pour 4 fonctions dont une change de configuration. En fait, la suppression
d’une fonction peut se réaliser de deux manières. Soit la fonction est stoppée et les
données à traiter sont re-adressées. Dans ce cas la fonction n’est plus dans la chaı̂ne
7.3 Implantation de la voie de traitement sur la plate-forme 139
de traitement. Soit la fonction est reconfigurée dans un mode de fonctionnement

transparent, et le re-adressage n’est pas nécessaire.
Le nombre de scénarios de changements applicatifs possibles est très élevé, mais nous
constatons que le nombre de mécanismes de gestion de configuration auxquels ils font
appel dans la gestion hiérarchique reste limité. Suivant les scénarios, c’est le nombre de
changements dans la chaı̂ne qui diffère. Les changements de configurations inter-standards
impliquent de très nombreux changements sur la chaı̂ne de traitement. Le changement de
standard peut demander le re-partitionnement de la presque totalité des fonctions sur
l’architecture d’exécution. Dans ce cas, une reconfiguration totale de la chaı̂ne peut être
effectuée et s’apparente à une procédure d’initialisation. Il y a coupure de service comme
dans le roaming.
Nous allons dans le prochain paragraphe décrire les architectures permettant de donner
la flexibilité nécessaire à la réalisation des différents scénarios décrits ci-dessus.
7.3 Implantation de la voie de traitement sur la plate-forme

7.3.1 Architecture du chemin de traitement sur la plate-forme
Plusieurs chemins de traitement sont réalisables sur la plate-forme GPP/DSP/FPGA.
La configuration de la plate-forme que nous avons choisie de mettre en œuvre est l’ar-
chitecture illustrée par la figure 7.8. Sur les modules de type processeur, les chemins de
données internes sont aisément réalisables, ils correspondent simplement à un adressage
de mémoires partagées.
Fig. 7.8 – Architecture de la plate-forme matérielle

Le FPGA offre une grande liberté de conception pour définir un chemin de données
correspondant à des liaisons physiques ou dans le processeur embarqué à des adressages
mémoires. Les goulots d’étranglement se situent sur les bus physiques disponibles entre
les différents modules matériels. Sur la plate-forme une seule liaison, appelée ComPort
(CP), est disponible entre le GPP et le FPGA. Ce bus est donc partagé entre la voie de
traitement et la voie de configuration pour la transmission des données entre le GPP et le
FPGA. De même, il existe un seul bus (EMIF) entre le FPGA et le DSP et il n’y a pas de
liaison directe entre le GPP et le DSP, par conséquent toutes les données transmises entre
GPP et DSP passent par le FPGA. Ces bus inter-modules sont les principales limitations
de la plate-forme notamment au niveau des débits du CP. Les liens uniques de commu-
nication entre modules et notamment entre le HOST et le FPGA avec le CP nécessitent
l’ajout d’un contrôle (avec ajout d’un en-tête de trame) pour distinguer les deux types
de données transmises sur ce bus. Ce contrôle est non nécessaire dans le cas d’une plate-
forme matérielle disposant de bus d’adresse distincts pour le transfert des deux types
de données transitant entre modules matériels. Nous avons proposé dans [49] le modèle
structurel abstrait d’architecture de plate-forme s’accordant à la structure de gestion de
configuration afin de respecter la séparation physique des types de données. Cependant
“l’overhead” introduit par le mot d’en-tête ajouté dans le cadre de cette implantation est
faible par rapport au volume de données transmises en mode traitement.
Cas particulier des communications internes au FPGA

A l’intérieur du FPGA, plusieurs bus de communication peuvent être dimensionnés pour
répondre aux besoins de transmission des deux types de données. Ceci concerne les liens
entre le L2 CMU du FPGA et les L3 CMU et les bus de transmission de paramètres entre
L3 CMU et IP paramètrables. Nous rappelons que les données de configuration des IP
reconfigurables sont transmises par un lien intrinsèque au FPGA qu’est le plan mémoire
de configuration via une interface de configuration.
Fig. 7.9 – 3 solutions de chemin de données sur FPGA
Outre cela, la grande flexibilité du FPGA permet d’envisager de nombreuses solutions

architecturales afin de définir un chemin de données entre les composants de traitement.
La principale difficulté est de concevoir un chemin de données pour interconnecter les com-
posants de traitement reconfigurables. En effet d’une part nous avons vu que les signaux
passant à travers une région reconfigurable doivent avoir un routage fixe par des Bus Ma-
cro afin de garantir la connexion de multiples configurations implantées dans la région.
7.3 Implantation de la voie de traitement sur la plate-forme 141
D’autre part l’architecture d’interconnexion des fonctions de traitement doit permettre de

réaliser un chemin de données sur lequel une fonction peut-être interchangée de module et
passer d’une exécution logicielle à matérielle, comme l’envisage le cas de changement de
fonction du paragraphe 7.2.2. Nous avons distingué ci-dessous trois solutions (topologies)
de chemin de données pour interconnecter des IP reconfigurables, illustrées dans la figure
7.9.
Cas a : Dans ce cas, les blocs de traitement sont connectés à un bus de données commun.
Cette solution a l’avantage d’être la plus flexible du point de vue de la configura-
tion du chemin de données. Les traitements reconfigurables sont toujours connectés
physiquement au même bus. Ullmann et al. présente dans [136] une architecture
sur un Virtex-II sur laquelle les zones reconfigurables sont interconnectées via des
BusMacro à un bus de données. Ceci permet une grande souplesse d’utilisation pour
multiplexer plusieurs fonctionnalités. Cependant le contexte de l’étude [136] n’est
pas une application orientée flot de données. La solution d’un bus de données n’est
pas optimale pour des applications orientées flot de données déployées sur FPGA.
Cas b : La topologie point-à-point (connectivité directe) est optimale du point de vue
des ressources utilisées et des performances. L’inconvénient de cette architecture est
que le chemin de données est statique. Il est donc difficile avec une telle architecture
de pouvoir déplacer une fonction d’un module matériel à un autre. Nous avons
donné dans [12] un exemple d’application avec des connexions point-à-point entre
une fonction reconfigurable et des fonctions de traitement statiques.
Cas c : Dans ce cas, les fonctions sont interconnectées via une matrice d’interconnexion
reconfigurable. Nous avons appelé cette matrice “ReconfigurableSwitchBox”. La RSB
permet d’assurer une connectivité directe entre fonctions ou un passage par le Mi-
croBlaze. Cette solution a l’avantage d’offrir un compromis connectivité / flexibilité
situé entre le cas a et b. L’inconvénient de cette approche est la plus grande com-
plexité de conception engendrée par la mise en place de la RSB comme un bloc re-
configurable. Il est donc nécessaire que les différentes configurations de la RSB soient
gérées par le gestionnaire de configuration, par exemple le L2 CMU du FPGA.
Nous avons fait le choix de la matrice “ReconfigurableSwitchBox”. Cette solution per-
met de maintenir une connectivité point-à-point entre des traitements matériels et d’offrir
la possibilité de changer le chemin de données lorsque par exemple une fonction change
de cible d’exécution. Une RSB est seulement constituée de lignes de routage pour inter-
connecter les signaux entre traitements.
Le composant de traitement défini au chapitre 6 dans la figure 6.3 possède des in-
terfaces d’adaptation afin que les données soient formatées sur 32 bits. La RSB possède
donc uniquement des port d’entrées/sorties définis sur 32 bits. Ainsi les composants sont
interconnectables entre eux indifféremment, que le traitement soit réalisé sur processeur
ou sous forme d’une IP matérielle. La figure 7.10 illustre deux configurations de la RSB
pour le passage de la fonction 1 d’une exécution matérielle à logicielle.
Fig. 7.10 – 2 configurations de “ReconfigurableSwitchBox”
7.4 Exemples d’implantation de fonctions

Nous présentons dans ce paragraphe des exemples de traitements reconfigurables portés
sur la plate-forme afin d’illustrer les différentes approches d’IP reconfigurables vues dans
le chapitre 6. Nous décrirons les architectures d’IP reconfigurables réalisant les fonctions
de filtrage de mise en forme, de codeurs convolutifs et de mise en constellation. Nous
décrivons donc la partie traitement synchrone des composants de type GALS pour ces
trois fonctions. Nous présentons aussi en annexes A.1 et A.2 les travaux de conception
menés dans le cadre de collaborations où les approches de réutilisation de ressources
communes et de reconfiguration partielle ont été mises en œuvre dans des but différents.
7.4.1 Mise en constellation

La partie traitement de la fonction de mise en constellation est un encodage d’un train
binaire d’entrée en symboles. Selon la mise en constellation utilisée, de 1 à 6 bits sont
utilisés en entrée pour créer un symbole. C’est le rôle de l’interface d’adaptation de fournir
les paquets de bits dont la taille est en correspondance avec la constellation.
Pour les constellations BPSK, QPSK, 16-QAM, 64-QAM utilisées en 802.11g des co-
dages bits à symboles sont détaillés dans les tableaux B.8, B.9, B.10, B.11. Il existe de
plus, les codages bit à symboles 8-PSK et encodage différentiel utilisés en GSM reportés
en annexe dans les tableaux B.3, B.4. Le codage bit à symbole est effectué par le bloc de
traitement “bit2Symb”.
La fonction de mise en constellation est donc simple et utilise peu de ressources. Pour
une implantation FPGA, les tables d’encodages du bloc “bit2Symb” sont réalisées avec
un faible nombre de LUT. La complexité des différents encodages est similaire. L’ap-
proche d’une IP entièrement reconfigurable, illustrée figure 7.11, est donc bien adaptée
dans ce cas. Nous avons comparé les approches de conception IP reconfigurable et IP
paramétrable sur cette fonction simple. Les résultats en terme d’occupation de ressources
sur un FPGA Virtex-II sont détaillés dans les tableaux tab.7.1 et tab.7.2. Le tableau 7.1
7.4 Exemples d’implantation de fonctions 143
donne les ressources utilisées seulement par la partie codage bit à symbole de l’IP mapper.
Fig. 7.11 – Fonction de mise en constellation sous forme d’IP totalement reconfigurable
L’IP paramétrable possède un paramètre sur trois bits permettant de sélectionner

l’un des 6 types d’encodage pris en compte à la conception. L’IP mapper reconfigurable
possède 6 configurations associées à 6 bitstreams partiels.
Partie codage Bit Symb BPSK Diff QPSK 8PSK 16-QAM 64-QAM
Paramétrable (Slices) 41 Slices
Reconfigurable (Slices) 4 4 5 6 6 7
Tab. 7.1 – Tableau comparatif d’implantation de l’encodage bit à symbole
Les résultats des implantations complètes de l’IP de mise en constellation, incluant le

composant d’encapsulation, sont donnés dans le tableau 7.2. L’IP reconfigurable utilise en
moyenne 45 slices ( slice cf. fig. C.6), avec une variation de quelques slices en fonction de
la configuration choisie. La zone reconfigurable est dimensionnée pour la configuration 64-
QAM, représentant “le pire cas” avec 52 slices. L’immobilisation de ressources non utilisées
dans les autres configurations est donc très faible, et en moyenne le taux d’utilisation de
la zone est donc de 90%.
L’IP paramétrable utilise 211 slices par le fait qu’à la fois les blocs d’adaptation d’entrée
et de codage bit à symbole soient paramétrables. Quel que soit le paramétrage utilisé,
si la surface de l’IP paramétrable est rapportée à la surface utilisée en moyenne par une
configuration, soit environ 45 slices, nous pouvons considérer que moins de 25% des slices
de l’IP paramétrable sont effectivement utiles, pendant que le reste dégrade l’autonomie
du système par consommation statique.
IP mapper Resources Taux d’utilisation

Paramétrable 211 Slices ≤ 21 %
Reconfigurable ≈ 45 Slices ≈≥ 90 %
Tab. 7.2 – Occupation de ressources de l’IP encodage bit à symbole
L’avantage de l’IP paramétrable est le temps de reconfiguration qui est nul pour passer
d’un mode à l’autre de la fonction. L’inconvénient de l’IP paramétrable en radio logicielle
est qu’elle n’est pas évolutive. Les six configurations incluses au moment de la conception
sont les seules possibles. Alors qu’il est toujours possible d’ajouter de nouvelles configu-
rations sur une IP reconfigurable (par exemple π/4 − 8P SK,π/4 − QP SK, 128-QAM
...).
7.4.2 Codeur convolutif

Il existe une grande variété de schémas de codage de la fonction d’encodage convolutif
utilisée dans une application multi-standard. Les schémas de codage sont déterminés par
les polynômes générateurs, (voir le tableau B.13), utilisés par les codeurs. Un exemple de
codeur est illustré figure 7.12.
Fig. 7.12 – Codeur convolutif en 802.11g
Il est donc nécessaire d’adopter une architecture de codeur flexible afin de permettre
tous les types de codage. La longueur de codage k détermine la longueur de la ligne de re-
gistre à décalage linéaire représentée par la “delayline” dans la figure 7.13. Nous pouvons
remarquer à l’aide du tableau des polynômes Pi (cf. tab.B.13) que k est toujours inférieur
ou égal à 8 dans les cas considérés. Le nombre de sorties du codeur est déterminé par le
nombre de polynômes utilisés.
Fig. 7.13 – Codeur convolutif générique
Afin de réaliser un codeur universel de la figure 7.13 sur FPGA, nous pouvons donc
fixer la longueur de la “delayline” à 8 registres (9 entrées X sur le bloc “Polynomial de-
termination”), et le nombre de sorties du codeur a été fixé à 6+1 sortie de “delayline”.

Les polynômes sont déterminés dans la zone nommée “Polynomial determination” par les
connexions entre les sorties des registres et l’entrée des opérateurs ou-exclusif.
Dans ce codeur universel, le seul bloc à paramétrer est donc le bloc “Polynomial determi-
nation” où les polynômes sont déterminés par la matrice 9X6 “d’interrupteurs X-Y”.
Une première solution est de rendre paramétrable ce bloc. Dans un FPGA un interrupteur
peut être réalisé à l’aide d’une porte logique AND. Cette solution nécessite d’utiliser un
signal de sélection de taille 9*6 bits.
La seconde solution est de réaliser le bloc de détermination polynômiale en utilisant la
reconfiguration afin de supprimer le signal paramètre de sélection. Le tableau 7.3 permet
de comparer les deux implantations. La principale différence vient du nombre de signaux
utilisés par le bloc “Polynomial determination”. Le paramètre de sélection des polynômes
est un signal de 54 bits. Cette différence de 54 bits se répercute sur le nombre de signaux
externes de l’IP paramétrable. En effet, ce signal de sélection est relié au L3 CMU en
charge de la configuration du traitement. Dans le cas de l’IP reconfigurable, le L3 CMU
paramètre le polynôme par reconfiguration. Nous voyons donc sur cet exemple qu’aucun
bus de données n’est nécessaire pour relier le L3 CMU à l’IP reconfigurable puisque le
paramétrage passe par le plan de configuration du FPGA.
Bloc “Polynomial determination” Ressources utilisées Signaux externes

Paramétrable 31 Slices / 54 LUT2 117 (IOB)
Reconfigurable 31 Slices / 54 LUT1 63 (IOB)
IP codeur convolutif Slices utilisés Signaux externes
Paramétrable 171 Slices 130 (IOB)
Reconfigurable 149 Slices 70 (IOB)
Tab. 7.3 – Tableau encodage bit à symbole BPSK
Nous pouvons remarquer dans le tableau 7.3 que des LUT2 sont nécessaires dans le
cas paramétrable et des LUT1 pour l’IP reconfigurable, mais ceci n’a pas d’influence sur
le nombre de slices utilisés car seul des LUT4 sont disponibles sur les FPGA Virtex-II.
Afin de minimiser le coût de la reconfiguration de la macro, il est nécessaire que la
macro soit pré-placée dans le minimum de colonnes de CLB. Les instances de LUT1 sont
donc placées les unes par rapport aux autres verticalement. Une macro placée et routée
de ce type est illustrée par la figure 6.20. La taille de la macro RPM résultante avec 54
LUT1 à placer est de 7LCLB ∗ 1CCLB .
7.4.3 Filtre FIR

Cette IP a été présentée en 2006 dans le cadre de la première édition du concours national
de conception d’application organisé par le CNFM, en partenariat avec la société Xilinx.
Ce projet a obtenu le premier prix dans la catégorie des projets étudiants doctorants.
L’étude des différentes implantations d’IP reconfigurable présentées au chapitre précédent
(paragraphe 6.4) s’appuie sur cette IP FIR. Nous rappelons que l’occupation en terme de
nombre de slices de cette IP est donnée dans le tableau 6.4.
La partie synchrone réalisant le traitement de filtrage est encapsulée, comme chaque

IP de la chaı̂ne de traitement, dans un composant (cf. figure 6.3 ) qui assure les transferts
asynchrones de données vers l’extérieur. La partie synchrone est séparée en une partie
contrôle et une partie opérative permettant notamment une implantation en IP semi-
reconfigurable.
Fig. 7.14 – Architecture de calcul de l’opérateur 4TAP FIR
La partie opérative est conçue autour de 4 multiplieurs accumulateurs (MAC) mis

en cascade alimentés par les échantillons et les coefficients. Les échantillons d’entrées
sont stockés dans des registres à décalage et les coefficients du filtre dans des blocs
mémoire. Cette partie constitue l’opérateur commun nommé FIR 4TAP. La structure
de cet opérateur est illustrée par la figure 7.14. L’IP FIR basée sur un seul opérateur de
ce type permet de réaliser des filtres jusqu’à une longueur de 32 taps suivant le contrôle
réalisé.
Le FPGA étant choisi comme cible définitive, nous avons aussi exploité les possibi-
lités intrinsèques qu’offre le FPGA concernant les éléments de calcul. En effet, la partie
opérative utilise 4 multiplieurs câblés MULT18x18 du FPGA. Les registres à décalages
utilisés pour stocker les échantillons d’entrées sont les registres de type SRL16 [137] (Shift
Register LUT). Les implantations de filtres FIR exploitant les SRL16 suivant différentes
manières pour le stockage des échantillons, des coefficients a fait l’objet de plusieurs tra-
vaux, dont par exemple [138] dans le cas d’un filtre à architecture parallèle où les SRL
sont utilisés en sorties du filtre.
Dans la partie opérative du filtre, les slices sont donc utilisés pour instancier les re-
gistres à décalage de type SRL16 et aussi les additionneurs des opérateurs MAC. Les
coefficients du filtre sont stockés dans des blocs RAM configurés en ROM. La partie
contrôle du filtre n’a donc pas à gérer l’adressage en écriture de blocs RAM pour le chan-
gement de valeurs des coefficients du filtre. Le changement des coefficients est néanmoins
possible par reconfiguration du contenu des ROM. Les reconfigurations sont effectuées par
le L3 CMU du FIR en relation avec le contrôleur de configuration par chargement d’un
bitstream. Les bitstreams contenant un jeu de coefficients ont une taille fixe de 2 ko, le
changement de coefficients est donc réalisable en 40 µs.
Ceci amène à la même réflexion que dans le cas du codeur convolutif. Le contrôle des
coefficients, est réalisé entre le L3 CMU et l’IP sans besoin d’ajout de logique de contrôle
avec bus de données et d’adressage de RAM pour le passage de nouvelles valeurs de coef-
ficients du filtre.
La partie contrôle gère donc les lectures des coefficients du filtre dans les ROM, et des
échantillons dans les SRL16. La partie contrôle gère de plus deux phases d’utilisation de
l’opérateur FIR 4TAP. La phase d’initialisation pendant laquelle les premiers échantillons
reçus sont chargés dans les SRL ; pendant cette phase aucun résultat n’est produit. La
seconde phase est celle de traitement, pendant laquelle les valeurs de sorties sont calculées
en fonction du paramètre de longueur du filtre et de sur-échantillonnage. Ces paramètres
ne sont pas modifiables par valeurs, ceci augmenterait considérablement la complexité de
la machine d’état de contrôle du FIR. Par conséquent, ces paramètres sont changés par
reconfiguration de la partie contrôle du filtre FIR. Cette partie contrôle utilise de plus un
bloc RAM configuré en FIFO pour le stockage des données produites par le FIR. Cette
FIFO joue le rôle de l’interface d’adaptation de sortie du composant GALS. En fonction
du taux de sur-échantillonnage, le nombre de données en sortie varie pour un échantillon
consommé à l’entrée.
P. James-Roxby et al. comparent [139, 140] l’utilisation de ROM et de RAM implantées
dans des slices. Dans l’application (un réseau de neurones) présentée dans [139, 140]
l’utilisation de ROM permet de réduire le nombre de slices (de 20%), et d’augmenter la
fréquence de traitement. Cette implantation utilise un outil appelé JBits [125, 126] qui
permet d’accéder à travers une API java aux ressources bas niveau du FPGA.
Conclusion
Les résultats présentés dans ce chapitre ainsi que le précédent nous ont permis de valider
les concepts proposés dans les deux précédentes parties de cet ouvrage.
En particulier, ce chapitre a présenté dans une démarche de conception de système RL, la
réalisation sur une plate-forme matérielle hétérogène d’applications reconfigurables de trai-
tement flot de données. Nous avons vu à travers la description du portage de la structure
de gestion de configuration que dans ce modèle les deux niveaux hiérarchiques supérieurs
et leurs échanges de données de configuration sont indépendants de l’implantation des
fonctions de traitements. Ce modèle s’adapte à une architecture physique hétérogène qui
n’a pas été dimensionnée à l’origine pour recevoir le modèle, cela indique bien que l’ap-
proche hiérarchique distribuée s’applique à la gestion de configuration d’applications RL
exécutées sur plate-forme hétérogène.
L’encapsulation des fonctions de traitement dans un composant standard “GALS” nous
permet de rapidement intégrer les fonctionnalités dans une chaı̂ne complète de traite-
ment déployée sur des cibles hétérogènes sans souci d’interconnexion, aussi bien au niveau
rythme qu’au niveau nature du circuit de traitement (DSP, GPP, FPGA, ...).
Sur FPGA, trois exemples d’IP reconfigurables, sur les cinq fonctions identifiées comme
communes lors de l’analyse des trois standards effectuée au chapitre 3, ont été décrites
dans ce chapitre. A travers ces trois exemples nous avons illustré l’intérêt des différentes
approches de conception d’IP reconfigurables que nous avons présentées au chapitre 6.
Leurs implantations nous ont permis de mettre en œuvre les différents flots de conception
décrits dans ce chapitre. Dans les cas de l’IP codeur convolutif et du FIR, mettant en jeu
les méthodologies de conception les plus avancées d’IP semi-reconfigurables, les descrip-
tions de haut niveau des IP sont génériques. Lors du placement routage certaines valeurs
sont fixées (par exemple pour l’IP codeur, longueur et taux). Les autres paramètres sont
ensuite variables par reconfiguration dynamique comme celui qui détermine les polynômes
générateurs.
D’autres exemples d’implantations mettant en œuvre ces méthodologies et flots de

conception, sont présentés en annexes A.1 et A.2 pour des études d’IP reconfigurables
menées en collaboration dans d’autres cadres applicatifs.
Conclusion et perspectives
Conclusions et perspectives
Conclusion
Devant un paysage des radiocommunications dans lequel foisonne une grande diversité
de standards, les techniques radio logicielle deviennent indispensables aux opérateurs de
réseaux et aux équipementiers pour étudier et proposer à l’avenir des systèmes de transmis-
sion génériques. La notion de reconfigurabilité introduite dans toutes les parties (couches
physiques, piles protocolaires, applications) des systèmes (réseaux, terminaux) RL est donc
fondamentale. La plate-forme matérielle reconfigurable pour l’exécution d’une couche phy-
sique multistandard est le segment du système RL présentant le plus de contraintes par
rapport à la reconfiguration : réactivité, occupation de ressources. La réponse ne réside
pas dans un processeur généraliste puissant supportant l’ensemble des traitements. La
conception d’architectures optimisées se définira par la maı̂trise d’un ensemble de do-
maines pluridisciplinaires de recherche et de technologies émergentes que cible le domaine
de la RL.
Ce travail initiant cette thématique de recherche au sein de l’équipe SCEE, nous avons
voulu proposer dans cet ouvrage une synthèse des différentes techniques relatives à la
conception d’une plate-forme reconfigurable RL, à savoir l’optimisation algorithmique des
traitements multistandard, les architectures matérielles reconfigurables, les architectures
logicielles et de gestion de configuration.
A travers un choix de trois standards représentatifs de la diversité du paysage des radio-
communications, nous avons présenté une approche de conception basée sur une analyse
des applications pour aboutir à la définition d’une architecture de traitement reconfigu-
rable sur plate-forme hétérogène.
Réponse à la problématique
La caractéristique singulière apportée par un système RL réel par rapport à d’autres
systèmes reconfigurables est la gestion de configuration. Nous avons souligné au cours de
ce document l’importance primordiale de la gestion de configuration en RL, sans laquelle
la reconfigurabilité potentielle d’un système ne peut être exploitée en cours de fonction-
nement, pour répondre aux demandes de changements applicatifs. La proposition dans
le chapitre 5, d’une structure de gestion de configuration répond à cette problématique
présentée dans l’introduction. En effet, nous avons pris en compte à la fois les besoins
de changements de contextes applicatifs (les diverses granularités de reconfiguration de
la chaı̂ne) et l’hétérogénéité des cibles configurables par la définition d’une gestion de
configuration hiérarchique et distribuée. Nous avons introduit au niveau de la couche
physique la capacité de reconfiguration partielle de la chaı̂ne de traitement et la gestion
152 Conclusions et perspectives
des composants de traitement matériels : Ceci se démarque des architectures de gestion

de configuration se situant à un plus haut niveau d’abstraction et supportant essentielle-
ment la configuration des composants logiciels. En outre, notre analyse de factorisation
fonctionnelle combinée à la capacité de reconfiguration partielle de la chaı̂ne permet de
réduire le nombre de configurations à gérer.
D’autre part, l’architecture du chemin de traitement proposée permet de déployer des ap-
plications orientées flot de données sur des plate-formes matérielles hétérogènes. Un effort
tout particulier a été mené sur la logique configurable (FPGA). Les FPGA présentent le
plus de degrés de flexibilité mais aussi de complexité de mise en œuvre de cette flexibilité
(conception et gestion des IP reconfigurables). La connectivité physique point à point
assurant l’efficacité des applications flots de données a été rendue plus flexible au niveau
matériel (FPGA) par la mise en place de chemins de données reconfigurables.
Ceci va au-delà de la simple amélioration de l’utilisation des FPGA. C’est un nouvel ho-
rizon qui s’ouvre en dotant la performance du matériel (reconfigurable) la souplesse du
logiciel, quelle que soit la granularité de configuration.
Concernant la mise en œuvre des méthodologies de conception qui fait partie intégrante
de la problématique d’exploitation de la reconfigurabilité des plates-formes, nous avons
proposé, à travers différentes alternatives de conception d’IP reconfigurables, plusieurs
approches mettant en jeu des flots de conception spécifiques. Nous avons mis en évidence
la faisabilité de telles IP reconfigurables offrant les performances d’accélérateurs matériels
avec une flexibilité logicielle.
Résultats
Une concrétisation du travail sur la conception et la gestion de la reconfiguration dy-
namique sur plate-forme hétérogène est la sélection de l’équipe SCEE, depuis 2005, par
Xilinx comme ”Selected Customer” afin d’évaluer les nouveaux outils et flots de concep-
tion FPGA de Xilinx.
Nos travaux de modélisation de la gestion de configuration de plates-formes RL dynami-
quement reconfigurables ont été récompensés au SDR Forum en 2006 par un prix outstan-
ding paper award. Au niveau national, nos approches de conception d’IP reconfigurable
pour les applications radio logicielle a reçu le prix du concours 2006 de conception organisé
par Xilinx et le CNFM. Enfin, la réalisation sur plate-forme hétérogène d’une application
dynamiquement et partiellement reconfigurable, issue des nos travaux de thèse est l’objet
d’une démonstration présentée dans le cadre d’un audit du projet E2 R phase II.
Cependant la mise en œuvre d’applications reconfigurables est encore fastidieuse et de-

mande des temps de conception plus longs que des flots classiques car les outils n’intègrent
pas encore toutes les fonctionnalités nécessaires à la conception de système PR. Ceci
présente une forte contrainte lors de l’implantation sur cible. De ce fait, la réalisation
complète de la chaı̂ne de traitement demanderait encore du temps de développement.
Perspectives et valorisation des résultats

Les études menées dans le cadre de cette thèse ouvrent de nombreuses perspectives. Du
point de vue des réalisations, les perspectives à court terme sont dans un premier temps
de porter le modèle proposé sur des plates-formes matérielles permettant de dissocier
physiquement les chemins de configuration et de traitement en utilisant différents types

de liaisons physiques : bas débit pour le chemin de données de configuration et haut
débit pour le chemin de traitement. Cela permettra de valider en terme de performances
l’architecture mise en place sous la contrainte des débits réalistes élevés. Nous pouvons
aussi faire évoluer l’architecture vers la gestion de deux chaı̂nes de traitement. En effet,
l’implantation de deux chaı̂nes permet d’assurer la continuité de service dans tous les cas
de reconfiguration et notamment ceux inter-standards (soft-handover). Le prix est d’un
facteur deux quel que soit le nombre de standards supportés par le système pour supporter
les cas de soft-handover.
Nous avons vu que la tendance actuelle est à l’intégration progressive de couches logicielles
intermédiaires dans la conception des systèmes radio. Un futur axe de recherche est l’étude
de l’interaction entre la gestion de configuration hiérarchique et les couches d’abstraction
logicielle notamment :
– en poursuivant la collaboration avec l’UPC sur le thème gestion de configuration
hiérarchique et le P-HAL constituant ainsi un système radio logicielle préparé à
évoluer vers la définition d’un système de radio intelligente.
– En s’intéressant à l’intégration du SCA et de l’architecture de gestion de reconfigu-
ration proposée sur les plates-formes RL à Supélec.
Les travaux initiés par cette thèse sont d’ores et déjà poursuivis par la thèse de Loı̈g
Godard. Les travaux de thèse de L. Godard s’inscrivent dans les perspectives d’évolution
de notre modèle de gestion de configuration hiérarchique vers un modèle destiné aux
systèmes radio intelligente (RI). Pour cela un modèle de gestion de configuration RI s’in-
terface au modèle de gestion RL. Ce modèle de gestion RI est en charge du contrôle des
différentes informations issues des capteurs d’environnement et des prises de décisions.
Les besoins des systèmes RI sont en cours de spécification dans cette thèse. De plus, la
modélisation de la gestion de configuration RI s’appuyant sur la structure de gestion de
configuration RL va se poursuivre dans un cadre de formalisation de type UML.
Au niveau de l’architecture de traitement, il pourrait être envisageable à plus long

terme de baser le partitionnement logiciel/matériel de l’application non pas sur des scéna-
rios mais sur un contrôleur de partitionnement et d’ordonnancement dynamique em-
barqué.
L’expérience sur la conception d’application RL sur plate-forme hétérogène reconfi-

gurable développée au cours de nos travaux est capitalisée à travers plusieurs projets
collaboratifs. Parmi ces projets, nous pouvons citer comme projet déjà en cours, la parti-
cipation de Supélec au Smart Radio Challenge organisé par le SDR Forum entre équipes
universitaires au niveau international. Le projet “MENHIR” de Supélec a été retenu pour
concourir à la première édition de ce concours (en confrontation à Pennsylvania State Uni-
versity, Virginia Tech ...) et met en avant comme originalité une gestion de reconfiguration
de différentes formes d’ondes sur des plates-formes hétérogènes en mettant en œuvre des
techniques de reconfiguration dynamique partielle de FPGA (Xilinx Virtex-IV).
Les résultats des travaux présentés dans cette thèse sont la source de contributions de
l’équipe SCEE dans le cadre du projet intégré européen (IST) E2 R (2006-2007) et du
projet RNRT Idromel (2006-2007) pour le prototypage des démonstrateurs de ces deux
projets. Ces projets valoriseront l’expérience acquise sur la conception d’applications sur
plates-formes hétérogènes issues des travaux de cette thèse.

Le projet RNTL Mopcom (2007-2009) s’appuie sur l’expertise acquise ici en terme de
méthodologie et de conception d’applications reconfigurables pour explorer les futures
méthodes de conception basées sur des abstractions de plus en plus élevées et en utilisant
des transformations de modèles pour redescendre à la génération de code. Cette approche
est nécessaire à la conception de systèmes de plus en plus hétérogènes et complexes asso-
ciant flot de données et contrôle (reconfig.) tels qu’exigés par la RL et la RI.
La gestion de configuration hiérarchique et distribuée est en outre au cœur de proposi-
tions techniques dans plusieurs projets pour l’appel en cours du RNRT et du FP7 de la
commission européenne.
Publications personnelles
Publications internationales
Jean-Philippe Delahaye, Guy Gogniat, Christian Roland, Pierre Bomel, “Software Radio
and Dynamic Reconfiguration on a DSP/FPGA platform”, Frequenz Journal of Tele-
communications, pages 152-159, N˚58, 5-6/2004.
Hongzhi Wang, Jean-Philippe Delahaye, Pierre Leray, Jacques Palicot, “Managing dyna-
mical reconfiguration on a MIMO Decoder”, 14th Reconfigurable Architectures Workshop,
26-27 Mars 2007, Long Beach, California, USA.
Jean-Philippe Delahaye, Jacques Palicot, Christophe Moy, Pierre Leray, “Partial Reconfi-
guration of FPGAs for Dynamical Reconfiguration of a Software Radio Platform”, (paper
submitted to) 16th IST Mobile & Wireless Communications Summit 2007, Budapest (Hun-
gary), 1-5 July 2007.
Amor Nafkha, Renaud Seguier, Jacques Palicot, Christophe Moy, Jean-Philippe Dela-
haye, “A Reconfigurable Base-Band Transmitter for Adaptive Coding”, (paper submitted
to) 16th IST Mobile & Wireless Communications Summit 2007, Budapest (Hungary), 1-5
July 2007.
Jean-Philippe Delahaye, Pierre Leray, Christophe Moy, Jacques Palicot, “Managing Dy-
namic Partial Reconfiguration on Heterogeneous SDR Platform”, SDR Forum Technical
Conference, Anaheim (USA), novembre 2005.
Cette publication a reçu le prix “Outstanding Paper Award” du SDR Forum Technical
Committe Chair, november 2006.
Jean-Philippe Delahaye, Jacques Palicot, Pierre Leray, “A hierarchical modeling approach

in software defined radio system design”, IEEE Workshop on Signal Processing Systems
Design and Implementation (SIPS), Page(s) : 42-47, Athens (Grèce), 2-4 novembre 2005.
Jean-Philippe Delahaye, Guy Gogniat, Christian Roland, Pierre Bomel, “Software Ra-
dio and Dynamic Reconfiguration on a DSP/FPGA platform”, 3rd Karlsruhe Workshop
on Software Radios, Karlsruhe (Germany), 17-18 mars 2004.
Publications nationales
Hongzhi Wang, Pierre Leray, Jacques Palicot et Jean-Philippe Delahaye, Utilisation de
la reconfiguration dynamique partielle dans l’implémentation d’un décodeur MIMO V-
BLAST, (article soumis au) 21e colloque GRETSI sur le traitement du signal et des
images, Troyes, France, 11-13 septembre 2007.
Jean-Philippe Delahaye, “Fonction de filtrage de mise en forme : Un IP reconfigurable pour

les applications Radio Logicielle” rapport technique, Prix catégorie Docteur du concours
Coordination National de Formation en Microéléctronique en partenariat avec la société
Xilinx, Saint-Malo (France), journées du CNFM, 23 novembre 2006.
Jean-Philippe Delahaye, Jacques Palicot, Pierre Leray, “Un Modèle Hiérarchique pour
les Architectures Reconfigurables en Radio Logicielle”, 20e colloque GRETSI sur le traite-
ment du signal et des images, Louvain-la-Neuve (Belgique), 6-9 septembre 2005.
Jean-Philippe Delahaye, “De la maison en T aux architectures reconfigurables”, Docto-

riales de Bretagne 2005, St Brieuc (France), 20-25 novembre 2005.
Jean-Philippe Delahaye, “Applications multi-standards et architectures reconfigurables”,

Journée des doctorants en électronique de Bretagne, LESTER, Lorient (France), 4 Décem-
bre 2004.
Jean-Philippe Delahaye, “Software radio and dynamic reconfiguration on a DSP/FPGA

platform”, Université Bretagne Sud, LESTER, Master Thesis, Lorient (France), Sep-
tembre 2003.
Communications orales
Jean-Philippe Delahaye, “Radio logicielle et Reconfiguration dynamique sur une plate-
forme DSP/FPGA”, Séminaire ETSN du 10 mars 2004, Supélec, campus de Rennes.
Jean-Philippe Delahaye, “Techniques de conception et applications sur FPGAs partielle-

ment reconfigurables”, Séminaire SCEE du 17 novembre 2005, Supélec, campus de Rennes.
Jean-Philippe Delahaye, “Managing Dynamic Partial Reconfiguration on Embedded SDR

Platforms”, Invited Tutorial, RECOPS Project Meeting, MBDA Vélizy, February 2006.
Jean-Philippe Delahaye, “Design Flows on Xilinx FPGA : a Tutorial”, Tutorial, ICTeR

Project, LESTER Lorient, December 2006.
Annexe
Annexe A
Travaux issus de collaborations
161
162 Travaux issus de collaborations
A.1 Conception d’interface pour Objet P-HAL partielle-

ment reconfigurable
Les travaux présentés dans ce paragraphe sont le résultat d’une collaboration effectuée
dans le cadre du Réseau d’Excellence NEWCOM [141] à l’Universitat Politècnica de Ca-
talunya avec Antoni Gelonch et Xavier Revés. Suite à l’analyse de l’application P-HAL
développée par l’UPC et présentée au paragraphe 4.2.3, un des objectifs était d’introduire
la reconfiguration partielle sur les FPGA d’une plate-forme gérée par la couche d’abstrac-
tion P-HAL. Avec le P-HAL, les traitements exécutés sur FPGA sont des objets illustrés
par la figure 4.8 possédant des interfaces d’adaptation décrites au paragraphe 4.2.3.
Fig. A.1 – Implantation des objets P-HAL en modules partiellement reconfigurables
Sur les FPGA de faible capacité, il est implanté un seul objet par FPGA. Sur les
FPGA de plus grande taille, deux objets se partagent une interface P-HAL commune
comme l’illustre la figure A.1. Initialement, lorsqu’un objet était changé en cours de trai-
tement, le FPGA accueillant l’objet et sa partie P-HAL était totalement reconfiguré. Or
la partie du P-HAL implantée sur FPGA est constituée par les interfaces autour de l’objet
et sont illustrées dans la figure A.1. Elles peuvent être adaptées pour rester inchangées
d’une implantation d’objet à l’autre. Ceci nous a permis d’envisager le chargement uni-
quement de l’objet par reconfiguration partielle du FPGA. L’adaptation des interfaces a
été réalisée avec la conception de wrapper se plaçant entre l’objet partiellement reconfigu-
rable et les services P-HAL restant en partie statique du FPGA. Les wrapper s sous formes
de macros sont décrits dans le chapitre 6 sur les méthodologies. Ces wrapper s instanciant
des LUT1 pour garantir le routage des signaux externes des objets ont été développés
pendant cette collaboration. La solution des wrapper s a été retenu face au Bus Macro
car les objets implantés sur FPGA possèdent de nombreux signaux. Les wrapper s per-
mettent de diviser par 2 le nombre de CLB consommés pour fixer le routage des signaux
externes des objets. De plus, la description les wrapper s est réalisée en VHDL comme des
A.2 Étude de consommation de la reconfiguration 163
entités génériques permettant un temps de développement plus rapide que la description

manuelle avec les Bus Macro. Cette étude a été enrichissante des deux côtés. Elle a per-
mis à la partie catalane d’appréhender les contraintes liées à la conception d’application
partiellement reconfigurable et à la partie bretonne de confronter les méthodologies de
conception développées dans le cadre de ses applications à d’autres applications et de
s’initier aux couches d’abstraction pour plates-formes radio.
A.2 Étude de consommation de la reconfiguration

Les travaux présentés dans ce paragraphe sont le résultat d’une collaboration effectuée
avec David Elléouet docteur de l’Université de Rennes 1 à IETR/INSA. Ces travaux sont
détaillés dans la thèse de D. Elléouet [115], ce paragraphe en présente un résumé.
Nous proposons d’évaluer la consommation électrique d’un système, travaux de la thèse
de D. Elléouet, en incluant la consommation de la reconfiguration dynamique. L’étude est
illustrée par l’exemple d’une IP FFT 64 points implantée sur un Virtex-II Pro XC2VP4
Xilinx. A travers cette implantation de la transformée de Fourier rapide sur un Virtex-II
Pro, il est montré l’intérêt de l’utilisation de la reconfiguration dynamique pour optimiser
dynamiquement la consommation d’une IP.
L’idée de cette étude est d’évaluer la consommation de l’IP en cours d’exécution, en fonc-
tion de ses performances, puis d’évaluer la consommation de la reconfiguration suivant
le changement d’architecture de l’IP effectué. De plus, il y est proposé un gestionnaire
dynamique de consommation pour système reconfigurable.
Dans un premier temps, la consommation à l’exécution de l’IP, pour chaque type d’archi-
tecture, est déterminée d’après des modèles de consommation développés par D. Elléouet
[142]. L’IP FFT 64 points est exécutée à une fréquence fixée à 50M Hz. Cette IP peut-
être réalisée suivant plusieurs architectures de papillons Radix2, Radix4 et Pipeline et la
consommation de chaque architecture est comme l’indique la table (A.1). Il est possible
d’affecter selon le type d’architecture un contexte d’utilisation. Quand l’application re-
quiert de la performance, l’architecture de FFT retenue est pipeline. Lorsque le contexte
demande ou permet un fonctionnement en basse-consommation, la FFT est configurée
en FFT de type Radix2. Enfin l’architecture en FFT Radix4 représente un compromis
performance consommation En résumé, la fonctionnalité reste identique, seul le type d’ar-
chitecture change en fonction du service souhaité.
Fonction Butterfly PF F T 64 Cycle QoS

configuration (mW ) number
FFT 64 Pipelined 294,03 64 Peformance
FFT 64 radix4 200,98 91 Low Power and Performance
FFT 64 radix2 124,88 265 Low Power
Tab. A.1 – Affectation d’une qualité de service suivant le type d’architecture de la FFT.
La méthodologie utilisée pour mesurer l’énergie consommée durant la reconfiguration

entre deux contextes est la même utilisée que dans [143]. Ici, la reconfiguration partielle est
utilisée pour des changements de contexte correspondant à des bitstreams partiels créés
à l’aide du flot MoDiff-PR présenté au paragraphe 6.3.2. La table A.2 donne le temps
164 Travaux issus de collaborations
de reconfiguration TReconfP revious→Next pour différents changement de contextes ainsi que

la puissance consommée durant la reconfiguration PReconf . Les reconfigurations ont été
effectuées par l’interface BoudaryScan du Virtex-II Pro à une cadence de 5 Mbit/s ce qui
explique que les temps de reconfiguration mesurés sont relativement longs.
Previous Actual TReconfP revious→Next PReconf

configuration configuration (ms) (mW)
pipelined radix2 432 342
radix2 pipelined 595 342
pipelined radix4 80.9 342
radix4 pipelined 82.6 342
radix2 radix4 600 342
radix4 radix2 487.2 342
Tab. A.2 – Temps et puissance consommée durant la reconfiguration.
Nous avons clairement constaté que la consommation en énergie de la reconfiguration

dépend du temps de reconfiguration. La reconfiguration partielle et l’adoption de flot d’un
conception permettant de réduire la taille des bitstream partiels tels que nous les avons
proposés dans le chapitre 6 permettent donc de réduire l’énergie consommée par la confi-
guration. Le tableau A.3 donne des estimations de consommation de la reconfiguration
sur FPGA et illustre les gains en consommation d’énergie possible en utilisant la recon-
figuration partielle mise en œuvre par le flot MoDiff-PR par rapport à la reconfiguration
partielle issue d’un flot Modular Design classique sur l’exemple d’une IP FFT 64 points.
Contexte Nouveau TReconf Vcore EM D−P R EM oDif f Gains

précédent contexte (ms) (V ) (mJ) (mJ) (%)
FFT 64 radix 4 FFT 64 radix 2 883,1 1,5 181,1 100,69 44,34
FFT 64 pipelined FFT 64 radix 2 892 1,5 265,94 128,8 51,57
FFT 64 pipelined FFT 64 radix 4 886,2 1,5 264,15 24,15 90,87
Tab. A.3 – Comparaison de l’énergie consommée entre la reconfiguration partielle et par

différence.
L’utilisation de la reconfiguration partielle permet de réduire considérablement le

temps et l’énergie consommée durant le changement de contexte. Le gestionnaire proposé
dans [115] préfigure une gestion de configuration prenant en compte une qualité de service
liée à la consommation électrique des fonctions. Ceci permettra d’assurer une meilleure
autonomie des applications sur FPGA. C’est typiquement l’une des fonctionnalités que
l’on attendra des futurs systèmes radio intelligente (cognitive radio) [99].
Annexe B
Les standards
165
166 Les standards
B.1 GSM
System Band Uplink Downlink Channel Number

GSM 850 850 824.0 - 849.0 869.0 - 894.0 128 - 251
GSM 900 (P-GSM) 900 890.0 - 915.0 935.0 - 960.0 1 - 124
GSM 900 (E-GSM) 900 880.0 - 915.0 925.0 - 960.0 975 - 1023, (0, 1-124)
GSM-R (R-GSM) 900 876.0 - 880.0 921.0 - 925.0 955 - 973
DSC 1800 1800 1710.0 - 1785.0 1805.0 - 1880.0 512 - 885
PCS 1900 1900 1850.0 - 1910.0 1930.0 - 1990.0 512 - 810
Tab. B.1 – Bandes de fréquences allouées en GSM
Frequency Correction Calage sur la

Channel (FCCH) ↓ fréquence porteuse
Broadcast Channel Synchronisation Synchronisation +
(BCH) Channel (SCH) ↓ Identification
Canaux non dédiés Broadcast Control Information systèmes (SI)
Channel (BCCH) ↓
Paging Channel Appel du mobile
(PCH)↓
Random Access Accès aléatoire
Channel (RACH)↑ du mobile
Access Grant Allocation
Common Control Channel (AGCH)↓ de ressource
Channel Cell Broadcast Messages courts
Channel (CBCH)↓ diffusés
Stand-Alone Dedicated Signalisation
Control Channel (SDCCH)↓↑
Fast Associated Control Supervision
Dedicated Control Channel (FACCH)↓↑ de la liaison
Channel Fast Associated Control Exécution du handover
Canaux dédiés Channel (FACCH) ↓↑
Traffic Channel Traffic Channel for Voix plein/
(TCH) coded speech (TCH) ↓↑ demi débit
Tab. B.2 – Les canaux logiques en GSM

B.2 UMTS 167
Bit d’entrée di di−1 ) dî 1 − 2dî

00 0 1
01 1 -1
10 1 -1
11 0 1
Tab. B.3 – Tableau encodage différentiel bit à symbole
Bit d’entrée (B0 B1 B2 ) Sortie I Sortie Q

000 1 0
001 π/4 π/4
010 0 1
011 -π/4 π/4
100 -1 0
101 -π/4 -π/4
110 0 -1
111 π/4 -π/4
Tab. B.4 – Tableau encodage bit à symbole 8-PSK
B.2 UMTS
Fig. B.1 – Transport channels to physical channel mapping in the UMTS/FDD uplink
Traitements en bande de base en UMTS : compléments

Codage cyclique : Un CRC est inséré à chaque blocs de transport. Le nombre de bits
de parité ajoutés est déterminé par le polynôme générateur qui est choisi par les
couches supérieures. Plusieurs polynômes sont utilisés :
(1)gCRC24 (D) = D24 + D23 + D6 + D5 + D + 1

(2)gCRC16 (D) = D16 + D12 + D5 + 1
(3)gCRC12 (D) = D12 + D12 + D5 + 1
(4)gCRC8 (D) = D8 + D7 + D4 + D3 + D + 1
(B.1)
168 Les standards
Concaténation ou segmentation : Cette opération est effectuée avant le codage canal

afin d’adapter la taille des blocs de transport à la séquence de bit traité par le codeur
canal. Cette taille ne devant pas dépasser une valeur maximale Z dépendante du type
de codage canal Z=504 bits dans le cas du codage convolutif et Z=5114 bits dans le
cas du codage turbo.
Codage correcteur d’erreur : Les techniques de codage canal utilisées, sont décrites
dans le TS 25.212 [34]. Pour la voie montante, les techniques sont de deux types
suivant le canal de transport considéré. Les paramètres de codage canal sont : le type,
la longueur de contrainte, le taux de codage, et les polynômes générateurs utilisés.
La longueur de contrainte maximale du codage convolutif est N=9 en UTRA/FDD
à comparer avec le cas du GSM N=5. L’encodeur turbo est vu comme formé de deux
codeurs convolutifs et d’un entrelaceur interne.
Ajustement : Ce traitement concerne uniquement la voie montante. Il s’agit de scinder
des séquences de bits codés en segment de même taille.
Premier entrelacement : Le premier entrelacement est un entrelacement par bloc ap-
pelé inter trame. Les opérations effectuées sont des permutations de colonnes dont
l’ordre est prédéfini. Le nombre de colonnes à permuter dépend de la valeur du
TTI (1 colonne par 10ms donc TTI de 10 ms pas de permutation), le nombre de
lignes (bit par colonnes) est calculé par division du nombre de bit de la trame par
le nombres de colonnes.
Segmentation : La segmentation de séquence de bits contenu dans un TTI, afin d’adap-
ter le contenu d’un TTI en un nombre entier de trame radio. La segmentation in-
tervient sur des séquences dont le TTI est supérieur à 10 ms.
Adaptation de débit : Adapter le débit à la sortie de chaque canal de transport au
débit du canal physique. Deux techniques sont possibles : le poinçonnage (punctu-
ring) ou la répétition (repeating). En voie montante cette fonction sert à adapter
les débits des canaux CCTrCH au débit des PhCH. Les détails des algorithmes
utilisés sont donnés dans le TS 25.212 [34], il est à noter que les puncturing sont
différents suivant : les canaux, les encodages canal (convolutif ou Turbo) de même
le taux de poinçonnage est calculé à partir d’informations fournies par les couches
supérieures, c’est un attribut dit “quasi statique” . Il est à noter que le poinçonnage
des séquences encodées par technique Turbo subit une opération de séparation, car
les bits de parité ne doivent pas être supprimés. Une opération de ré-assemblage
(“bit collection”) est effectuée après le poinçonnage.
Multiplexage : (des canaux de transport) Le multiplexage est la mise en série des trames
radio de chaque TrCH et arrivant toutes le 10 ms pour former une trame unique ou
CCTrCH.
Segmentation (des canaux physiques) La segmentation s’applique lorsque plusieurs ca-
naux physiques sont utilisés pour la transmission d’un même CCTrCH. Le cas d’une
transmission en multicode.
Deuxième entrelacement : Cet entrelacement appelé intratrames est réalisé par blocs.
Les bits d’entrée sont structurés sous forme de matrice. Les permutations inter-
viennent entre colonnes. Une opération de padding peut être associée pour compléter
les matrices afin d’obtenir un nombre entier de lignes. Le nombre de colonnes à per-
muter est fixe et égal à 30.
B.2 UMTS 169
Synchronisation Channelisation Scrambling Scrambling

Codes Codes Codes, UL Codes, DL
Type Gold Codes OVSF codesab Gold Codec Gold Code
PSCd (long) ou (short) Segments
et SSCe PNf codes
PN codes
longueur 256 4-512 38400 ou 256 38400
(chips)
Durée 66.67µs 1.04µs − 133.34µs 10ms ou 66.67µs 10ms
Nb 1 PCg et = SF 16,777,216 512 PC et
codes 16 SCh UL : 4..256 15 SC for
DL : 4..512 each PC
Etalement Noi Yesj No No
Usage To enable UE to UL : to separate physical data Separation of Separation
locate and synchro and control data from same UE UE of sectors
to the cells’ main DL : to separate connection
control channels to different UE in a same cell
Tab. B.5 – Code d’étalement et utilisation en UMTS

a
Orthogonal Variable Spreading Factor
b
parfois nommées Walsh Codes
c
Complex-Valued Gold Code Segments
d
Primary Synchronization Codes
e
Secondary Synchronization Codes
f
Pseudo Noise
g
Primary Code
h
Secondary Code
i
does not change bandwidth
j
increases bandwidth
170 Les standards
B.3 WLAN
Protocoles date Bandes accès Débits

de standardisation de Fréquences
802.11 1997 2.4Ghz FHSS 1 − 2M bit/s
DSSS
802.11a 1999 5Ghz OFDM 6 − 54M bit/s
802.11b 1999 2.4Ghz CCK 1 − 11M bit/s
802.11g 2003 2.4Ghz OFDM 6 − 54M bit/s
802.11n 2008 2.4Ghz MIMO 200 − 540M bit/s
5Ghz
Tab. B.6 – Évolution des spécifications du 802.11
protocoles 802.11 802.11b 802.11g

accès FHSS DSSS CCK PBCC OFDM
Nb de canaux 79 79 14 14 14
accès FHSS DSSS CCK PBCC OFDM
Largueur 1 MHz 22 MHz 22 MHz 22 MHz 20 MHz
des canaux
Espacement 1 MHz 5 MHz 5 MHz 5 MHz 5 MHz
entre canaux
Modulation 2-GFSK/ DBPSK/ DQPSK BPSK/ BPSK, QPSK
4-GFSK DQPSK QPSK 16-QAM, 64-QAM
débits (Mbit/s) 1/2 1/2 5.5, 11 2.5, 5.5, 11 6,9,12,18,24,36,48,54
Tab. B.7 – Spécifications des couches PHY 802.11
B.3.1 Fonctions bande de base 802.11g Mode ERP-OFDM

Convolutional coding
Le taux de codage peut-être égal à R=1/2, 2/3,3/4 suivant le débit choisi Les polynômes
générateurs utilisés sont g0 = 1338 , g1 = 1718 et k=7. Le codage convolutif est effectué
à R=1/2, les débits plus hauts sont réalisés avec la technique de poinçonnage, (“Punctu-
ring”). Lors de la transmission certains bits ne sont pas envoyés, à la réception des bits à
zéro sont insérés pour remplacer les bits omis. Le décodage est effectué par l’algorithme
de Viterbi.
Partitionnement
Les bits encodés sont partitionnés “Partitioning” en blocs de longueurs finies de taille
NCBP S afin que l’opération d’entrelacement soit effectuée par blocs.
Avec NBP SC représentant le nombre de bits codés par sous porteuses (“Coded Bit Per
Sub Carrier”)
B.3 WLAN 171
Entrelacement
Les données sont entrelacées “Interleaving” par blocs dont la taille correspond au nombre
de bits dans un symbole OFDM.
La permutation est définie en 2 étapes, la première assurant que les bits adjacents ne sont
pas “mappés” dans des sous porteuses adjacentes. La seconde assure que les bits sont
mappés alternativement sur les LSB et MSB de la constellation. La première permutation
est une permutation par bloc, écriture en ligne de longueur 3 ∗ NBP SC bits des NCBP S bit
d’un symbole. Le nombre de ligne est ainsi égal à 18. Puis lecture des 3 ∗ NCBP S colonnes.
Les colonnes impaires subissent une permutation rotative intra vecteur.
Avec NCBP S représentant le nombres de bits codés par symbole (“Coded Bits Per Sym-
bol”)
Mise en constellation
Chaque sous porteuse est modulée suivant le débit souhaité par les “mapping” BPSK,
QPSK, 16-QAM, 64-QAM. Les bits sont donc groupés par 1, 2 4, ou 6 et convertis par
un code Gray suivant la constellation choisie. Les valeurs de sorties, D, sont normalisées
par un facteur Km od suivant la modulation choisie.
D = (I + jQ)Km od
(B.2)
Le type de modulation peut changer entre le début et la fin de la transmission d’une

trame et la puissance d’émission doit rester constante. Les facteurs de normalisations et
les tableaux de mapping des différentes constellations sont dans la section 17.3.5.7.
Bit d’entrée I-(B0 ) Sortie I Sortie Q

0 -1 0
1 1 0
Tab. B.8 – Tableau encodage bit à symbole BPSK
Bit d’entrée I-(B0 ) Q-(B1 ) Sortie I Sortie Q

0 -1 -1
1 1 1
Tab. B.9 – Tableau encodage bit à symbole QPSK

172 Les standards
Bit d’entrée I-(B0 B1 ) Q-(B2 B3 ) Sortie I Sortie Q

00 -3 -3
01 -1 -1
11 1 1
10 3 3
Tab. B.10 – Tableau encodage bit à symbole 16-QAM
Bit d’entrée I-(B0 B1 B2 ) Q-(B3 B4 B5 ) Sortie I Sortie Q

000 -7 -7
001 -5 -5
011 -3 -3
010 -1 -1
110 1 1
111 3 3
101 5 5
100 7 7
Tab. B.11 – Tableau encodage bit à symbole 64-QAM
Filtrage
La fonction de “Windowing” consiste en une multiplication du signal OFDM par une
fenêtre ayant pour rôle de limiter le spectre d’émission. Cette fonction simple dans le
cas de présent peut aussi être remplacée par une fonction de filtrage plus complexe dans
d’autres systèmes OFDM. Dans ce cas le filtrage a lieu dans le domaine temporel par
convolution. Une implémentation pour 802.11 de la fonction de “windowing” pour une
symbole de durée T = 4µs et des intervalles de transition de TTR=100 ns avec une
vitesse d’échantillonnage de 20 Msps est W T [n] = (1, n[1; 79]; 0.5, n[0], [79]; 0sinon)
B.4 Paramètres des fonctions multistandards

B.4 Paramètres des fonctions multistandards 173
Standard/ Taille Frame Polynôme

Mode In/Out (bits) Generateur
GSM I : 112 D8 + D3 + D1 + 1
TCH/HS O : 121
FS I : 260 D8 + D4 + D3 + D2 + 1
O : 267
AFS I : 244 D6 + D5 + D3 + D2 + D1 + 1
O : 250
WLAN 802.11g I :16 D16 + D12 + D5 + 1
O :32
UMTS I :640 D24 + D23 + D6 + D5 + D1 + 1
DCH O :656 D16 + D12 + D5 + 1
D12 + D5 + 1
D8 + D7 + D4 + D3 + D1 + 1
Tab. B.12 – Parameters Cyclic coding (1)
Multi-Standards Coding Generator Polynomial

Conv. Coding Rate
GSM 1/2 G0 = D4 + D3 + 1
TCH/FH G1 = D4 + D3 + D + 1
TCH/HS 1/3 G4 = D6 + D5 + D3 + D2 + 1
G5 = D6 + D4 + D + 1
G6 = D6 + D4 + D3 + D2 + D + 1
UMTS 1/2 G0 = D8 + D6 + D5 + D4 + 1
BCH, PCH, RACH G1 = D8 + D7 + D6 + D5 + D3 + D + 1
CPCH, DCH ... 1/3 G0 = D8 + D6 + D5 + D3 + D2 + D + 1
G1 = D8 + D7 + D5 + D4 + D + 1
G2 = D8 + D7 + D6 + D3 + 1
802.11g 1/2 Ga = D6 + D4 + D3 + D + 1
(OFDM Mode) Gb = D6 + D5 + D4 + D3 + 1
Tab. B.13 – Polynômes générateurs utilisés par les encodeurs convolutifs

174 Les standards
Type de modulation PSK FSK QAM

2G/2.5G (GSM/GPRS)→GMSK
Cellulaire IS-95→BPSK
D-AMPS→B-FSK
(IS-94/IS-136/PDC/PHS)
→D-QPSK
EDGE→8PSK
3G/3,5G UMTS→QPSK
Cellulaire HSDPA→16-QAM
WLAN 802.11 802.11
→(DBPSK,DQPSK) →(2-GFSK,4-GFSK)
802.11b
→(BPSK,QPSK,DQPSK)
802.11a/g/HiperLAN2 802.11a/g/HiperLAN2
→(BPSK,QPSK) →(16-QAM,64-QAM)
WMAN WIMAX/HyperMAN WIMAX/HyperMAN
→(BPSK,QPSK) →(16-QAM,64-QAM)
Broadcast DAB→DQPSK
DVB-T→QPSK DVB-T
→(16-QAM,64-QAM)
DVB-S/DVB-S2 DVB-S→16-QAM
→(QPSK,8PSK)
DMB→4-DPSK
Tab. B.14 – modulations, mise en constellations utilisées dans les systèmes de radio
communications
Annexe C
Architectures systèmes
175
176 Architectures systèmes
C.1 Modélisation de l’architecture logicielle

Le SDR Forum propose de modéliser à haut niveau l’ensemble d’un système SDR en le
décomposant à travers 4 éléments “Waveform/application Architecture”, “Service Archi-
tecture”, “Management Architecture” et “Computational Architecture”. Ces éléments sont
illustrés sous forme d’un modèle en couches par la figure C.1.
Fig. C.1 – Modèle en couches des 4 éléments d’un système RL
La figure C.2 illustre ce modèle et les relations entre ces différents éléments. Les ap-
plications (“waveform”) utilisent les services fournis par la plate-forme, contrôlés par une
architecture de management.
Fig. C.2 – Vue UML globale de l’architecture SDR proposée par le SDR Forum
Les 4 éléments du modèle sont empruntés aux concepts formulés dans “Principles of
TINA” [144] en 1995 et adaptés par le SDR Forum aux applications civiles de la radio
C.2 L’architecture du SCA 177
logicielle. Le “Telecommunications Information Network Architecture” (TINA) a été défini

par un consortium établi en 1992 et constitué de plus de 50 membres, industriels des
télécommunications, équipementiers et opérateurs.
“computational architecture” désigne la plate-forme matérielle formée par les res-
sources de type processeurs généralistes et spécialisés traitement du signal. Cet
élément inclut aussi les interfaces de programmation des ressources matérielles, aussi
appelé “Core Framework”. Cette partie est définie pour masquer les spécificités des
ressources matérielles et composants logiciels à l’élément “Management architectu-
re”.
“Management Architecture” définit les règles de conception, spécifications, implanta-
tions des composants logiciels utilisés pour gérer, contrôler l’ensemble des opérations
des traitements radio (les services) en relation avec les couches basses du système
(les ressources SW/HW composant le système SDR). L’architecture de manage-
ment inclut par ailleurs des mécanismes tels que la gestion de configuration, ainsi
que d’autres mécanismes (Fault Management, Performance Management, Virtual
Channel Management, Network Management, and Security Management). Cette
partie peut être vue comme l’application du point de vue de la “computational
architecture”.
“Service Architecture” définit les régles de conception, spécifications, implantations
et de gestion des services à fournir aux applications SDR. Les services incluent
antennes, amplificateurs, RF, MODEM, etc. Cet élément fournit aux applications
les interfaces des services.
“Waveform/Application Architecture” fournit les spécifications des applications uti-
lisateur (formes d’ondes) qui utilisent l’ensemble des services fournis par la plate-
forme.
C.2 L’architecture du SCA

Les détails de l’architecture du SCA décrits ci-dessous sont extraits du document de
spécifications du SCA. La figure C.3 illustre la structure logicielle du SCA pour la partie
terminal embarqué.
La couche Bus L’architecture logicielle offerte par le SCA est supportée par des archi-
tectures de bus commerciales. Les bus supportés par l’OE sont VME, PCI, cPCI,
FireWire (IEEE-1394) et Ethernet.
Les interfaces série et réseaux L’architecture logicielle repose sur des composants com-
merciaux. Les interfaces séries et couche physique de communications supporté sont
RS-232, RS-422/423/485, Ethernet et 802.x. Les protocoles de communications as-
sociés à ces couches physiques incluent PPP, SLIP, LAPx.
Système d’exploitation L’architecture logicielle inclut un système d’exploitation em-
barqué temps réel pouvant offrir les fonctionnalités multi-tâches nécessaires aux
applications. L’interface de l’OS doit être standard à l’image de POSIX afin de
faciliter la portabilité des applications. Afin d’éviter de déployer les spécifications
POSIX complètes qui surchargeraient le système, le SCA définit les spécifications
minimales d’un POSIX pour ses besoins.
Le Core Framework Le CF est une partie essentielle du SCA permettant de définir les
applications indépendamment des spécificités du système. Les interfaces et services
du CF fournissent une abstraction des couches logicielles et matérielles inférieures.
Le CF comprend les interfaces de bases des composants (Hw/Sw) fournies aux appli-
cations, les interfaces de contrôle pour contrôler le système, les interfaces aux services
fournis par les systèmes. Le CF comprend également des fichiers (XML) de profil
décrivant les propriétés des ressources matérielles (Device Profile) et des composants
logiciels (Software Profile). Les fichiers de profils décrivent les caractéristiques des
ressources, fonctionnalité, emplacement, connectivité, et autres paramètres spécifiques
à décrire le composant. Toutes les interfaces du CF sont définies dans un langage
IDL.
Fig. C.3 – Structure logicielle du SCA
CORBA Ce standard de communication édité par l’OMG est présenté dans son fonc-
tionnement et ses concepts dans livre le [145]. CORBA est la version orientée objet
d’une technologie plus ancienne appelée RPC (Remote Procedure Call). CORBA
est désigné comme la couche middleware dans le sens où c’est utilisé entre plusieurs
logiciels hétérogène pour les faire communiquer. CORBA est aussi un middleware
distribué, ce qui permet à 2 applications de pouvoir communiquer ensemble lors-
qu’elles sont exécutées sur des processeurs distincts et de différents types, sur des
systèmes d’exploitations différents et indépendamment des langages dans lesquels
elle sont développées. Pour cela, un CORBA Interface Design Langage (IDL) spécifie
complètement toutes les interfaces des objets indépendamment des processeurs et
des langages spécifiques.
CORBA est donc utilisé dans le SCA pour acheminer les messages entre différents
objets dans un environnement de traitement distribué.
C.3 Les limitations de l’approche SCA 179
La couche application La couche application exécute la fonction de communication de

type MODEM, les protocoles de niveau L2, link layer. Les applications (waveforms)
sont donc composées d’objets CORBA conforment aux spécifications du Core Fra-
mework et déployées par l’intermédiaire d’un OS sur une plate-forme.
La couche matérielle L’architecture logicielle est exécutée sur une architecture matérielle
composée de modules. Ces modules matériels sont interconnectés entre eux via des
bus standards afin d’assurer la compatibilité avec l’architecture SCA.
Dans les modules, l’intégration des circuits de type processeurs généralistes est in-
diquée par l’approche SCA. Ce type de circuit est supporté nativement par l’envi-
ronnement opératif du SCA (OE SCA) et le modèle de communications basé sur
CORBA, ce qui assure d’offrir le maximum de portabilité aux composants logiciels
portés sur ces circuits.
Néanmoins nous avons vu que ces circuits n’ont pas la meilleure efficacité de trai-
tement. La consommation énergétique et la puissance dissipée par ces circuits pour
atteindre les performances requises particulièrement pour les fonctions de traitement
du modem représente un coût prohibitif dans les systèmes embarqués. L’utilisation
de circuits spécialisés DSP et FPGA est donc nécessaire dans les modules modem.
L’approche SCA ne pose aucune contrainte sur l’architecture des modules et toutes
les combinaisons de GPP, DSP, et FPGA sont possibles. Dans ce type de modules
hétérogènes, les circuits sont interconnectés de manière spécifique et les applications
sont développées de façon dédiées.
La compatibilité avec le SCA peut donc seulement être garantie à l’interface du
module comme le définissent les spécifications du SCA 2.2 API [78].
C.3 Les limitations de l’approche SCA

Le SCA a adopté des outils et exécutifs (OS et middleware) puissants afin de répondre
aux préceptes de la radio logicielle idéale (interopérabilité, réutilisabilité, modularité, re-
programmabilité). Ces outils et exécutifs non initialement conçus pour des applications
de radio communications évoluent vers des versions temps réel embarqués et adaptées aux
besoins radio logicielle. Néanmoins, la volonté du JTRS de baser son architecture sur des
technologies éprouvées dans d’autres domaines et commercialement disponibles COTS
présente des limitations. Premièrement, le développement des versions dédiées à l’em-
barqué des langages (UML, java...) et exécutifs manque de support de plate-forme et s’ac-
compagne de façon générale d’un manque d’outils associés de compilation, de vérification
et de test.
Il manque aux outils tels que CORBA des caractéristiques propres aux systèmes radio
logicielle telle que la gestion de la re-configurabilité.
Il existe aussi des limitations de l’approche du SCA liées à l’utilisation de CORBA plus
particulièrement dans les modules tels que le modem. L’étude de J. Bertrand et Al. [146]
montre les délais de latence introduit CORBA sur l’envoi des messages entre processus.
De même l’encapsulation des données dans CORBA peut-être très pénalisant pour les
taux de transfert. Selon cette étude l’overhead d’encapsulation mesuré peut représenter
jusqu’à 46% de la taille d’un paquet à transmettre dans le cas de pacquets de petites
tailles. Ces temps de latence sont illustrés dans les tableaux ci-dessous dont les chiffres
sont donnés pour un ORB CORBA C++ exécuté sur un processeur Pentium cadencé à
266Mhz embarqué sur une carte PC104.
ORB Msg Bytes CORBA Transport Speed Instruction

Type Latency Latency Cycles
Commercial Local 256 9 µs 0 µs 266 Mhz 2394
C++ ORB Remote 32 553 µs 471 µs 266 Mhz 147087
Tab. C.1 – Temps de latence dans CORBA [146]
Le SCA initialement défini pour les architectures uniquement multi-processeurs ne

peut gérer nativement des circuits spécialisés qu’au prix d’augmentation de ressources
matérielles coûteuses dans des systèmes embarqués. En effet, les évolutions que suit le
SCA pour rendre possible l’intégration de circuits non compatible CORBA comme le
propose Pucker et Al. [83] impliquent l’ajout de GPP dans chaque module modem. De
plus, les architectures compatibles SCA sont réalisées à l’aide de bus de communications
VME, PCI trop complexes pour des solutions faible consommation. Au niveau logiciel,
la nécessité d’embarquer un OS afin de supporter CORBA fait de la modularité et de
l’intéropérabilité offertes par l’approche SCA une solution coûteuse en ressources. Il est
aussi important de regarder l’espace mémoire nécessaire au stockage de CORBA qui est
encore très élevé. L’ensemble de ces contraintes rend l’approche SCA peu attractive pour
définir des architectures faible consommation pour des applications civiles embarquées.
C.4 Couches logicielles intermédiaires : autres travaux

Aujourd’hui le SDR Forum qui rassemble un nombre important d’acteurs du domaine
s’appuie sur les spécifications du SCA en vue d’une standardisation de cette couche
pour les applications radio civiles. 2 groupes de travail du SDR Forum reprécisent les
spécifications du SCA. Le System Interface Working Group (SIWG) du SDR Forum ap-
porte ses contributions [147] sur la standardisation d’un environnement de développement
commun aux applications SDR. Le but est de définir un modèle d’application indépendant
des plates-formes par le développement d’API. Le Hardware Abstraction Layer Working
Group apporte des recommandations [148] relatives à la portabilité des applications sur
les plates-formes radio notamment en ce qui concerne les FPGA. Par sa force de pro-
position le SCA s’impose comme le standard, toutefois il existe d’autres travaux dans le
domaine. Les travaux [149] proposent une couche logicielle intermédiaire non basée sur
CORBA. Ils proposent une architecture logicielle semblable au “Core Framework” mais
directement au niveau de l’OS. Les auteurs répondent ainsi au manque d’efficacité de
CORBA dans les communications. La couche logicielle proposée est une extension de l’OS
pour le support des caractéristiques propres aux systèmes SDR comme la reconfiguration
dynamique. Les entités du “Core Framewore” proposé sont similaires à celles présentées
dans le SCA à la différence que cette couche est interfacée directement à une couche
d’abstraction matérielle. Le “Core Framework” gère et configure l’ensemble des compo-
sants logicielles incluant les entités de contrôles tels qu’un “Software Modules Manager”
et les entités de traitement tels que les modules logiciels et les modules matériels. Cette
approche de CF inclus dans l’OS permet d’instancier directement des modules logiciels
sur les ressources de la plate-forme matérielle. Dans cette approche, la standardisation des
C.5 Circuits : compléments 181
interfaces et la compatibilité avec une couche logicielle n’est pas recherchée. Ceci réduit
le nombre de ressources allouées à la mise en compatibilité des plates-formes. L’ajout
de processeurs généralistes, pour créer des ponts entre CORBA et les circuits spécialisés
n’est pas nécessaire afin de prendre en charge ces circuits. De plus, les auteurs estiment
aussi que le développement des plates-formes matérielles doit rester propriétaire. Et le
développement de drivers spécifiques est considéré comme le moyen de garantir le maxi-
mum de performance d’une plate-forme en opposition avec l’approche CORBA.
C.5 Circuits : compléments

C.5.1 GPP
Les architectures de GPP les plus répandues sont les CISC (Complex Instruction Set
Computer) comme par exemple Intel Pentium ou AMD Athlon, et les RISC (Reduced
Instruction Set Computer), comme les Sparc, ou ARM. Les GPP sont utilisés pour les
tâches de contrôle. Pour les tâches de calculs ils compensent leur faible spécialisation
par des cadences de calcul très élevées. Mais par conséquent ils consomment trop et cela
limite leur emploi dans les systèmes embarqués. Dans les systèmes SDR non embarqués,
les GPP présentent plusieurs avantages sur les autres catégories de processeurs DSP ou
ASIP. La plupart des GPP sont accompagnés par de nombreux outils de développement
puissants (compilateurs, debuggers). De plus, les GPP sont compatibles avec de nombreux
environnements d’exécution (OS). Un GPP est capable d’exécuter des applications multi-
tâches et le développement de celle-ci est facilité par l’aide de l’OS chargé de la gestion des
tâches (scheduling). Ces facteurs rendent plus aisée la description d’applications complexes
à l’aide de langages de programmation de haut-niveau.
C.5.2 DSP
Les DSP ont des architectures de type Harvard. Les bus de données et d’adresses sont
séparés. Ils sont orientés traitement du signal à virgule fixe ou à virgule flottante. Les
jeux d’instruction réduits sont spécialisés (SIMD) “Single Instruction Multiple” Data sont
généralement constitués au moins d’unités de calcul MAC en cascade ou parallélisées.
La description des applications peut-être réalisée avec des langages de programmation
de haut-niveau par exemple C/C++, et des compilateurs dédiés aux DSP permettent
d’exploiter les jeux d’instructions spécifiques.
C.5.3 ASIP
L’architecture type de processeur est spécialisée pour optimiser l’exécution d’une classe
application comme par exemple LISA [150, 151, 152] issu des travaux de l’université de
Aix-La-Chapelle. Les ASIP peuvent avoir des architectures proches des DSP ou des GPP
suivant les applications. Pour les traitements en bande de base les ASIP ont des chemins
de traitement de données spécialisés, par exemple la famille de coeur de DSP CEVA-X
[153] dont l’architecture est une combinaison SIMD et VLIW proposant l’accélération des
opérations Add-Compare-Select pour l’algorithme de Virterbi. En particulier, le coeur
CEVA-X1622 vise les applications radio 3G/3.5G/HSDPA et RL. La génération auto-
matique des compilateurs pour ASIP est un élément essentiel pour exploiter toutes les
performances de ces circuits avec des langages de description haut niveau. Aujourd’hui,
des environnements de développement de compilateurs existent tel que Cosy [154].
C.5.4 Architectures reconfigurables, un peu d’histoire !

Le domaine des architectures reconfigurables a connu un formidable essor et depuis une
décennie les propositions d’architectures, nombreuses, sont bien documentées dans la
littérature. Il est intéressant de regarder encore quelques années en arrière.
Fig. C.4 – Architecture à structure variable de Gerald Estrin (1960)
La figure C.4 montre les relations entre la partie fixe de traitement (F), la structure
reconfigurable (V), les entrées / sorties, la partie de contrôle et l’homme (gestionnaire des
configurations) !
Fig. C.5 – Éléments de l’architecture de G. Estrin

C.5 Circuits : compléments 183
La figure C.5 montre les photos des différentes parties du système : fig. C.5.a les
modules reconfigurables, fig. C.5.b la carte mère et les fils de câblages de la carte mère
sur fig. C.5.c. L’auteur est montré en fig. C.5.d utilisant un oscilloscope pour observer et
superviser l’activité du système.
C.5.4.1 FPGA
Les FPGA sont des architectures reconfigurables à grain fin, les FPGA étaient initialement
utilisés comme circuit de prototypage d’applications ou glu logique. Depuis leur apparition
au début des années 1980, les performances en consommation et la puissance de calcul des
circuits FPGA ont considérablement évolué. De plus des avantages comme un cycle de
développement et de mise sur le marché des applications plus court que l’ASIC, font des
FPGA une solution de plus en plus retenue dans les systèmes manufacturés. Le succès des
FPGA est montré par leur utilisation dans de nombreux systèmes : défense, aérospatial,
imagerie médicale, télécommunications, reconnaissance de parole, cryptographie. Il existe
donc de nombreux produits, mais le marché des FPGA de grande capacité est toujours
dominé par deux fabricants Xilinx et Altera. Depuis quelques années, les FPGA à plu-
sieurs millions de portes possèdent des blocs de mémoire RAM, des multiplieurs câblés,
rendent possible la conception de systèmes sur puce, SoPC, en embarquant des coeurs de
processeurs cablés comme le IBM PowerPC 405 dans les Virtex -II Pro, ou des coeurs de
processeurs logiciels comme les NIOS et NIOS II chez Altera, PicoBlaze et MicroBlaze
chez Xilinx, ou l’open source Lattice Mico8.
Les principaux acteurs sont :
– ATMEL, avec la famille de FPGA AT40K dont la capacité va jusqu’à 50 000
éléments logiques cadencés à 100 MHz, est la seule famille de FPGA offrant une
reconfigurabilité partielle au niveau élément logique. En 1998, le projet ARDOISE
[104] initié au sein du GDR ISIS, a choisi ces FPGA afin d’évaluer des architectures
de traitement d’images utilisant ces propriétés.
– Altera dont les FPGA les plus performants sont la famille Stratix et Stratix II,
manufacturé en technologie 90nm donne des capacités jusqu’à 180 000 éléments lo-
giques. Ces FPGA intègrent des blocs RAM, des multiplieurs câblés 18*18, pouvant
former des blocs DSP cadencés jusqu’à 450Mhz.
– Lattice Semiconductor avec les FPGA LatticeSC est le troisième fabricant après
Altera et Xilinx à produire des FPGA en technologie 90nm. Le nombre d’éléments lo-
giques offerts atteint 115 000 avec des signaux d’horloge globale cadencés à 700Mhz.
– Xilinx probablement leader sur le marché des FPGA est très impliqué dans le do-
maine de la radio logicielle. Xilinx est par exemple le premier, en partenariat avec
ISR technologies, à proposer depuis 2006 un kit de développement SDR complet lo-
giciel et matériel compatible JTRS basé sur les FPGA Virtex 4 et la couche logicielle
SCA du JTRS. Xilinx est aussi le premier à offrir des FPGA de grande capacité
offrant une reconfigurabilité partielle par colonne à partir de la famille Virtex, Vir-
tex -E puis sur les Virtex -II et Virtex -II Pro ainsi que sur les FPGA “low-cost”
Spartan -III. Les générations plus récentes sont fabriquées en technologie 90 nm
pour les Virtex 4. Ces FPGA ont des capacités jusqu’à 200 000 éléments logiques.
Le changement technologique à 65 nm au passage à Virtex 5, Xilinx a annoncé que
la capacité atteindra 330 000 éléments logiques.
Le Virtex-II est le FPGA sur la plate-forme Sundance utilisée. Les détails de l’archi-
tecture du Virtex-II sont illustrés par la figure C.6 inspirée par les spécifications complètes
disponibles dans [155].
Fig. C.6 – Détails de l’architecture des FPGA Xilinx famille Virtex-II [155]
C.6 Description de la plate-forme de prototypage

Les cartes de prototypage utilisées à Supélec sont les solutions commercialisées par la
société Sundance. Les réalisations effectuées dans le cadre de cette thèse ont été portées
sur la plate-forme “Software Defined Radio Development (SDR) Kit SMT8036”. Cette
plate-forme de prototypage Sundance se compose d’une carte mère compatible PCI sur
laquelle sont insérés une carte fille DSP SMT365 et un module de conversion A/N SMT370.
La carte mère utilisée est la SMT310Q C.7, elle permet d’accueillir 4 modules au for-
mat TIM (Texas Instrument Module).
Les principales interfaces de communications entre la carte mère et le Host (PC) sont le
“Global Bus” sur 32 bits (un débit max. de 100 Mbytes/s @ 33MHz PCI clock) et le “Host
CommPort” sur 8 bits d’un débit maximal théorique de 10 Mbytes/s.
La carte fille SMT365 est une carte DSP TMS320C6416 TI à virgule fixe cadencée à 600
MHz. L’architecture de cette carte fille est illustrée figure C.8. Cette carte dispose de ca-
pacité mémoire de type ZBTRAM cadencé à 133 MHz d’une capacité de 8 Mbytes. Nous
pouvons aussi remarquer que cette carte comporte un FPGA Xilinx Virtex-II XC2V2000-4
en package FF896. Sur cette carte le FPGA est dédié à fournir les interfaces de communica-
tions entre le DSP et le Host. Nous avons utilisé ce FPGA, en modifiant sa configuration
C.6 Description de la plate-forme de prototypage 185
initiale pour maintenir uniquement le lien de communication de type CommPort (CP)

vers le Host libérant ainsi la logique configurable, utilisée par les autres protocoles de
communication, pour nos propres applications.
Buffered External
JTAG connector
HOST JTAG In, Internal
JTAG Out, Internal
7
JTAG
Reset Header
32-bit GLOBAL BUS
TIM 1 TIM 2 TIM 3 TIM 4

SRAM
HOST 8-bit
comport 6 ports 6 ports 6 ports
6 ports
Connection
COMPORT CONNECTION MATRIX
control
HOST
SDB
8-bit 8-bit 8-bit 8-bit
16-bit
CBuf FMS FMS FMS
Buffered
Comport
Fig. C.7 – Architecture de la carte mère (source DS Sundance)
J1 Top Primary TIM Connector

Comm-Port 0 & 3 DC-DC Converters
1.5V & 1.4V
Clocks, Timer, Interrupts, PXI.
2x Comm-Ports/SDL
McBSP/Utopia/GPIO
(all non-TIM I/O pins)
5V<>3V3 level translator 4 LEDs
4 LEDs &
JTAG Header FPGA Controller 4 I/O pins
Virtex-II, FF896
XC2V1000E-4 - XC2V2000E-4 DSP
432-624 I/O Pins 600MHz 'C6416
1.5V Core 104 I/O pins - EMIFA 525 pins - 1.4V Oscillators
2 x Sundance High- 3.3V I/O
speed Bus (SHB) 120 I/O Pins; 32-bit Data
60-way Samtec QSH
5V<>3V3 level translator 4/8/16Mbytes ZBTRAM
(4 x 512k/1M/2M x16
4x Comm-Port/SDL
133MHz)
Global Bus
EMIFA
8Mbyte Flash (EMIFB CE1)
J2 Bottom Primary TIM

J3 Global Expansion
Connector
Connector
Comm-Port 1, 2, 4 & 5
Fig. C.8 – Architecture du module DSP (source DS Sundance)

Table des figures
1.1 PMCS [7], le modèle de référence proposé par le JTRS . . . . . . . . . . 10

1.2 Évolution de la radio logicielle et des technologies utilisées . . . . . . . . 12
1.3 Principales architectures de récepteurs radio . . . . . . . . . . . . . . . . 12
1.4 Projets traitant de la re-configurabilité . . . . . . . . . . . . . . . . . . . 14
1.5 Evolutions “Idéales” des systèmes SDR en fonction des capacités matérielles 17
1.6 Besoins en ressources de traitements des systèmes RL . . . . . . . . . . . 17
2.1 Diagramme en blocs des traitements en bande de base GSM . . . . . . . 24

2.2 Couche physique de l’UMTS basée sur l’étalement de spectre . . . . . . . 26
2.3 Diagramme en blocs des traitements en bande de base de l’UMTS . . . . 27
2.4 Étalement sur les voies montantes DPCCH et DPDCH [36] . . . . . . . . 27
2.5 Diagramme en blocs des traitements en bande de base du 802.11g mode
OFDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.6 générateur de séquence d’embrouillage en 802.11g . . . . . . . . . . . . . 30
2.7 Modulateur OFDM, répartition des porteuses . . . . . . . . . . . . . . . . 31
3.1 Fonction de modulation paramétrable [41] . . . . . . . . . . . . . . . . . . 34

3.2 Chaı̂ne de traitement multi-standards basée sur des fonctions dédiées . . 36
3.3 Voie montante Tx UMTS FDD/TDD (projet Mumor, extrait de [47]) . . 36
3.4 Modélisation d’un système radio multi-standards sous forme de graphe [48] 37
3.5 Vers une chaı̂ne de transmission multi-standards unifiée . . . . . . . . . . 39
3.6 Chaı̂ne de transmission multi-standards unifiée . . . . . . . . . . . . . . . 40
3.7 Fonction reconfigurable de la chaı̂ne unifiée . . . . . . . . . . . . . . . . . 40
3.8 Chaı̂ne de traitement unifiée et détail du modulateur OFDM . . . . . . . 41
3.9 Orientation des architectures par rapport aux besoins fonctionnels . . . . 43
4.1 3 parties d’un système radio logicielle . . . . . . . . . . . . . . . . . . . . 52

4.2 Ressources matérielles hétérogènes d’un système radio logicielle . . . . . . 53
4.3 Modèle d’architecture de plate-forme SoC du projet Adriatic . . . . . . . 53
4.4 Rapport flexibilité/performance des architectures . . . . . . . . . . . . . 55
4.5 Couches logicielles intermédiaires des systèmes RL . . . . . . . . . . . . . 58
4.6 Plusieurs niveaux d’abstraction des couches logicielles intermédiaires . . . 59
4.7 Architecture logicielle du P-HAL . . . . . . . . . . . . . . . . . . . . . . . 62
4.8 Implantation d’un objet et adaptation des interfaces API P-HAL sur FPGA 64
4.9 Disposition de la gestion de configuration dans les systèmes RL . . . . . . 65
4.10 Portage direct des codes binaires sur plate-forme . . . . . . . . . . . . . . 66
4.11 Plate-forme avec outils de compilation/synthèse embarqués . . . . . . . . 66
187
188 table des figures
4.12 Plate-forme supportant un langage de haut niveau . . . . . . . . . . . . . 67

4.13 Représentation orientée objet d’une fonction reconfigurable (projet CAST) 68
4.14 Modélisation des applications et des ressources en Java (extrait de [89]) . 69
4.15 Architecture logicielle des équipements terminaux radio proposée dans E2 R 70
4.16 Modèle de flot de données en couches [96] . . . . . . . . . . . . . . . . . . 72
5.1 Modèle fonctionnel à double chemin de données configuration et traitement 77

5.2 Gestion de configuration hiérarchique . . . . . . . . . . . . . . . . . . . . 80
5.3 Rôle de superviseur de configuration du L1 CM . . . . . . . . . . . . . . 81
5.4 Le rôle d’interface d’un L2 CMU . . . . . . . . . . . . . . . . . . . . . . . 83
5.5 Modèle 3 niveaux fonctionnels de la voie traitement . . . . . . . . . . . . 85
5.6 Composant d’adaptation pour un fonctionnement “GALS” de la voie de
traitement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.7 Séquencement des messages entre les unités de gestion : cas d’un bloc
reconfiguré . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.8 Représentation en 3 parties de la plate-forme radio logicielle . . . . . . . 88
6.1 Portage de la chaı̂ne unifiée sur plate-forme hétérogène . . . . . . . . . . 94

6.2 Comparaison des déclarations logicielle et matérielle du composant GALS 95
6.3 Composant de traitement sur FPGA . . . . . . . . . . . . . . . . . . . . . 96
6.4 Partage des ressources par reconfiguration . . . . . . . . . . . . . . . . . 97
6.5 Chronogrammes de multiplexage par reconfiguration : cas avec dépendance
de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
6.6 Chronogramme de multiplexage par reconfiguration : cas sans dépendance
de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
6.7 Evolution des tailles de bitstream partiel suivant la mémoire de configuration102
6.8 Structure de la mémoire de configuration des Virtex . . . . . . . . . . . . 103
6.9 Les différentes architectures d’IP flexibles . . . . . . . . . . . . . . . . . . 104
6.10 Espace de conception des IP flexibles sur FPGA . . . . . . . . . . . . . . 106
6.11 Compromis pour la conception d’IP reconfigurables . . . . . . . . . . . . 108
6.12 Description système avec IP Reconfigurables . . . . . . . . . . . . . . . . 109
6.13 Flot de concepion modulaire sur FPGA . . . . . . . . . . . . . . . . . . . 111
6.14 Création de bitstream de configuration partielle : Méthode par différence 112
6.15 Création du bitstream partiel d’une Macro : Méthode “Macro PR Difference-
Based Design Flow” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
6.16 Flot de conception d’IP reconfigurable sur FPGA . . . . . . . . . . . . . 114
6.17 Création du bitstream partiel d’un module : Méthode “PR Design Flow” 115
6.18 BUFT-Based et LUT Based Bus Macro sur FPGA Virtex-II . . . . . . . 116
6.19 Horizontal et Vertical LUT Based Bus Macro sur FPGA Virtex-II . . . . 117
6.20 Macro placée et routée sur une colonne de CLB de Virtex-II . . . . . . . 118
6.21 Placement des contraintes de location sur slice Virtex-II . . . . . . . . . . 119
6.22 Implantation de multiplexeur sur FPGA . . . . . . . . . . . . . . . . . . 119
6.23 Différents types d’IP reconfigurables à l’implantation du FIR . . . . . . . 122
7.1 Composant paramétrable et reconfigurable, liaison avec le L3 CMU . . . 130

7.2 Portage de la structure de gestion de configuration sur la plate-forme . . 131
7.3 Deux solutions de contrôleur de configuration pour FPGA . . . . . . . . 132
table des figures 189
7.4 Fonction restant sur le même module . . . . . . . . . . . . . . . . . . . . 134

7.5 Fonction changeant de module . . . . . . . . . . . . . . . . . . . . . . . . 135
7.6 Trame (Type 1) pour l’échange des informations de gestion configuration
entre L1 et L2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
7.7 Configurations de la chaı̂ne de transmission en 802.11g . . . . . . . . . . 138
7.8 Architecture de la plate-forme matérielle . . . . . . . . . . . . . . . . . . 139
7.9 3 solutions de chemin de données sur FPGA . . . . . . . . . . . . . . . . 140
7.10 2 configurations de “ReconfigurableSwitchBox” . . . . . . . . . . . . . . . 142
7.11 Fonction de mise en constellation sous forme d’IP totalement reconfigurable143
7.12 Codeur convolutif en 802.11g . . . . . . . . . . . . . . . . . . . . . . . . . 144
7.13 Codeur convolutif générique . . . . . . . . . . . . . . . . . . . . . . . . . 144
7.14 Architecture de calcul de l’opérateur 4TAP FIR . . . . . . . . . . . . . . 146
A.1 Implantation des objets P-HAL en modules partiellement reconfigurables 162
B.1 Transport channels to physical channel mapping in the UMTS/FDD uplink167
C.1 Modèle en couches des 4 éléments d’un système RL . . . . . . . . . . . . 176

C.2 Vue UML globale de l’architecture SDR proposée par le SDR Forum . . . 176
C.3 Structure logicielle du SCA . . . . . . . . . . . . . . . . . . . . . . . . . . 178
C.4 Architecture à structure variable de Gerald Estrin (1960) . . . . . . . . . 182
C.5 Éléments de l’architecture de G. Estrin . . . . . . . . . . . . . . . . . . . 182
C.6 Détails de l’architecture des FPGA Xilinx famille Virtex-II [155] . . . . . 184
C.7 Architecture de la carte mère (source DS Sundance) . . . . . . . . . . . . 185
C.8 Architecture du module DSP (source DS Sundance) . . . . . . . . . . . . 185
Liste des tableaux
1.1 Services et standards de radiocommunications . . . . . . . . . . . . . . . 11

1.2 Terminologie radio logicielle définie par le SDR Forum . . . . . . . . . . . 14
2.1 Caractéristiques des interfaces air des standards étudiés . . . . . . . . . . 22

2.2 Tableau récapitulatif des caractéristiques de OFDM du 802.11g . . . . . . 31
3.1 Comparatif des approches de conception des multi-traitements . . . . . . 35

3.2 Classement fonctionnel des traitements multi-standards à l’émission . . . 42
3.3 Complexité de l’encodeur convolutif . . . . . . . . . . . . . . . . . . . . . 44
6.1 Temps de reconfiguration d’un Virtex-II 2000 . . . . . . . . . . . . . . . . 100

6.2 Comparaisons des densités d’intégration des Bus Macro . . . . . . . . . . 116
6.3 Multiplexeur paramétrable versus reconfigurable . . . . . . . . . . . . . . 120
6.4 Ressources utilisées par l’implantation du filtre sur Virtex-II . . . . . . . 121
6.5 Résultats des implantations du FIR sur Virtex-II . . . . . . . . . . . . . . 123
6.6 Minimisation de la taille du bitstream par changement de forme de la zone
PR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
7.1 Tableau comparatif d’implantation de l’encodage bit à symbole . . . . . . 143

7.2 Occupation de ressources de l’IP encodage bit à symbole . . . . . . . . . 143
7.3 Tableau encodage bit à symbole BPSK . . . . . . . . . . . . . . . . . . . 145
A.1 Affectation d’une qualité de service suivant le type d’architecture de la FFT.163

A.2 Temps et puissance consommée durant la reconfiguration. . . . . . . . . . 164
A.3 Comparaison de l’énergie consommée entre la reconfiguration partielle et
par différence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
B.1 Bandes de fréquences allouées en GSM . . . . . . . . . . . . . . . . . . . 166

B.2 Les canaux logiques en GSM . . . . . . . . . . . . . . . . . . . . . . . . . 166
B.3 Tableau encodage différentiel bit à symbole . . . . . . . . . . . . . . . . . 167
B.4 Tableau encodage bit à symbole 8-PSK . . . . . . . . . . . . . . . . . . . 167
B.5 Code d’étalement et utilisation en UMTS . . . . . . . . . . . . . . . . . . 169
B.6 Évolution des spécifications du 802.11 . . . . . . . . . . . . . . . . . . . . 170
B.7 Spécifications des couches PHY 802.11 . . . . . . . . . . . . . . . . . . . . 170
B.8 Tableau encodage bit à symbole BPSK . . . . . . . . . . . . . . . . . . . 171
B.9 Tableau encodage bit à symbole QPSK . . . . . . . . . . . . . . . . . . . 171
B.10 Tableau encodage bit à symbole 16-QAM . . . . . . . . . . . . . . . . . . 172
191
192 liste des tableaux
B.11 Tableau encodage bit à symbole 64-QAM . . . . . . . . . . . . . . . . . . 172

B.12 Parameters Cyclic coding (1) . . . . . . . . . . . . . . . . . . . . . . . . . 173
B.13 Polynômes générateurs utilisés par les encodeurs convolutifs . . . . . . . 173
B.14 modulations, mise en constellations utilisées dans les systèmes de radio
communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
C.1 Temps de latence dans CORBA [146] . . . . . . . . . . . . . . . . . . . . 180

Bibliographie
[1] Joseph Mitola, « The software Radio architecture ». IEEE Communications Ma-
gazine, vol. 33, pages 26–38, May 1995.
[2] Informations sur End-to End Reconfigurability Project, IST IP E2 R project
phase 2, « http ://e2r2.motlabs.com ».
[3] D. Greifendorf, J. Stammen, S. Sappok, M. Van Ackeren et P. Jung, « A novel
hardware design paradigm for mobile ’software defined radio’ terminals ». In IEEE
Seventh International Symposium on Spread Spectrum Techniques and Applications,
vol. 3, pages 828–831, 2002.
[4] Jacques Palicot et Christian Roland, « La radio logicielle : enjeux, contraintes et
perspectives ». In Revue de l’Électricité et de l’Électronique, vol. 11, décembre 2001.
[5] R.I. Lackey et D.W. Upmal, « Speakeasy : the military software radio ». IEEE
Communications Magazine, vol. 33, no 5, pages 56–61, May 1995.
[6] Peter G. Cook et Wayne Bonser, « Architectural overview of the SPEAKeasy
system ». In IEEE Journal on Selected Areas in Communications, vol. 17, pages 650–
661, April 1999.
[7] US Department of Defense, « Programmable Modular Communications System
(PMCS), Guidance Document ». Rapport, July 1997.
[8] Byron Tarver, Eric Christensen, Annamarie Miller et Elisa R. Wing, « Di-
gital Modular Radio (DMR) as a Maritime/Fixed Joint Tactical Radio System
(JTRS) ». In IEEE Military Communications Conference, MILCOM, Communi-
cations for Network-Centric Operations : Creating the Information Force, vol. 1,
pages 163–167, 2001.
[9] Vanu G. Bose, Alok B. Shah et Michael Ismert, « Software Radios for Wireless
Networking. ». In INFOCOM, pages 1030–1036, 1998.
[10] Thierry Turletti, H. Bentzen et D. Tennenhouse, « Towards the software rea-
lization of a gsm base station ». In IEEE/JSAC, Special Issue on Software Radios,
April 1999.
[11] « SDR Forum, Accelerating the proliferation of software defined radio technologies ».
http ://www.sdrforum.org.
[12] Jean-Philippe Delahaye, Guy Gogniat, Christian Roland et Pierre Bomel,
« Software Radio and Dynamic Reconfiguration on a DSP/FPGA Platform ». In
Proc. 3rd Workshop on Software Radios, (Karlsruhe, Germany), pages 143–151,
March 2004.
193
194 bibliographie
[13] D. Ikonomou, J. M. Pereira et J. da Silva, « EU funded R&D on Re-configurable

Radio Systems and Networks : The story so far ». Rapport, ACTS, 2000.
[14] IST MuMor, « Multi-Mode Radio, projet IST, Information sur le projet :
http ://www.mumor.org/ ». Rapport.
[15] John Hamard, Genevieve Conaty et Raquel Navarro-Prieto, « A User-Centric
Approach for the Development of Usable Reconfigurable Terminals ». In 12th IST
Mobile & Wireless Communications Summit 2007, (Aveiro, Portugal), June 2003.
[16] Adriatic, « D1.2 Survey of existing reconfigurable capabilities, Rapport, May 2002.
[17] Adriatic Project IST-2000-30049, « D1.3 ADRIATIC targeted reconfigurable tech-
nology, Rapport, August 2002.
[18] Adriatic Project IST-2000-30049, « D2.1 Survey of existing hardware/software co-
design methodologies, Rapport, May 2002.
[19] Massimiliano Laddomada, « Reconfiguration issues of future mobile software ra-
dio platforms ». Wireless Communications and Mobile Computing, vol. 2, no 8,
pages 815–826, 2002.
[20] Jean-Philippe Delahaye, Jacques Palicot, Christophe Moy et Pierre Leray,
« Partial Reconfiguration of FPGAs for Dynamical Reconfiguration of a Software
Radio Platform ». In 16th IST Mobile & Wireless Communications Summit 2007,
(Budapest, Hungary), 1-5 July 2007. submitted to.
[21] Christian Bonnet, Giuseppe Caire, Alain Enout, Pierre A Humblet, Giuseppe
Montalbano et Alessandro Nordio, « An open software-radio architecture sup-
porting advanced 3G + systems ». Annales des télécommunications Volume 56 N˚5-6
Mai-juin 2001, 2001.
[22] A. Polydoros et al., « WIND-FLEX : Developing a Novel Testbed for Explo-
ring Flexible Radio Concepts in an Indoor Environment ». IEEE Communications
Magazine, vol. 41, pages 116–122, July 2003.
[23] Joseph Mitola III, Cognitive Radio An Integrated Agent Architecture for Software
Defined Radio. Thèse de Doctorat, Royal Institute of Technology (KTH Kista),
Stockholm, Suède, 2000.
[24] Rupert Baines et Doug Pulley, « A total cost approach to evaluating different
reconfigurable architectures for baseband processing in wireless receivers ». IEEE
Communications Magazine, vol. 41, pages 105–113, January 2003.
[25] M. Darianian J. Brakensiek, R. Wittmann, « Software Defined Radio Technology
for Multistandard Terminal ». In Proc. 2nd Workshop on Software Radios, (Karls-
ruhe, Germany), March 2002.
[26] 3GPP, « Multi-mode UE issues ». Rapport, 3GPP, 2000.
[27] Christian Roland, Étude d’un récepteur universel auto-adaptatif pour les trans-
missions sans fil. Thèse de Doctorat, Conservatoire National des Arts et Métiers,
2001.
[28] Jacques Palicot et Sidkieta Zabre, « PAPR Analysis of a Multiplex of Modulated
Carriers in a Software Radio Context ». Frequenz, Journal of RF-Engineering and
Telecommunications, vol. 58, May-June 2004.
bibliographie 195
[29] 3GPP, « Physical Layer on the Radio Path : General Description ». Rapport, 3GPP,
2000.
[30] 3GPP, « Channel coding : coding, reordering and partitioning, and interleaving ».
Rapport, 3GPP, 2001.
[31] 3GPP, « Modulation : differential encoding, and modulation ». Rapport, 3GPP,
2001.
[32] Alfredo Linz et Alan Hendrickson, « Efficient implementation of an I-Q GMSK
modulator ». IEEE Transactions on Circuits and Systems II : Analog and Digital
Signal Processing, vol. 43, no 1, pages 14–23, January 1996.
[33] Harri Holma et Anti Toskala, « WCDMA fo UMTS : Radio Access For Third
Generation Mobile Communications ». In John Wiley & Sons, 2000.
[34] 3GPP, « Multiplexing and Channel Coding (FDD) ». Rapport, 3GPP, 2001.
[35] 3GPP, « Physical Channel and Mapping of Transport Channels onto Physical Chan-
nels (FDD) ». Rapport, 3GPP, 2001.
[36] 3GPP, « Spreading and Modulation (FDD) ». Rapport, 3GPP, 2001.
[37] 3GPP, « UE Radio transmission and Reception (FDD) ». Rapport, 3GPP, 2001.
[38] IEEE, « Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)
Specification ». Rapport, IEEE, 1997.
Specifications. Amendment 1 High-speed Physical Layer in the 5Ghz Band ». Rap-
port, IEEE, 1999.
Specifications ; Amendment 4 Further Higher Data Rate Extension in the 2.4Ghz
Band ». Rapport, IEEE, 2003.
[41] Anne Wiesler et Friedrich Jondral, « A software radio for second- and third-
generation mobile systems ». IEEE Transactions on Vehicular Technology, vol. 51,
no 4, pages 738–748, July 2002.
[42] Anne Wiesler, H. Schober, R. Machauer et Friedrich Jondral, « Software
radio structure for UMTS and second generation mobile communication systems ».
In 50th IEEE Vehicular Technology Conference (VTC), vol. 2, pages 939–942, Sep-
tember 1999.
[43] Arnd-Ragnar Rhiemeier, « Benefits and limits of parameterised channel coding for
software radio ». In Proc. 2nd Workshop on Software Radios, (Karlsruhe, Germany),
pages 107–112, March 2002.
[44] J. Cavallaro et M. Vaya, « VITURBO : A Reconfigurable Architecture for Viterbi
and Turbo Decoding ». In IEEE International Conference on Acoustics, Speech, and
Signal Processing (ICASSP), vol. 2, (Hong Kong, China), April 2003.
[45] Jacques Palicot et Christian Roland, « FFT a basic Function for a Reconfigurable
receiver ». In Proc. 10th International Conference on Telecommunications, (Papeete,
Tahiti), pages 898–902, Febuary 2003.
[46] Ali Al Ghouwayel, Yves Louet et Jacques Palicot, « A reconfigurable archi-
tecture for the FFT operator in a software radio context ». In IEEE International
Symposium on Circuits and Systems, ISCAS, May 2006.
196 bibliographie
[47] Multi-Mode Radio IST MuMor, « D3.2 Methodology Evaluation Report ». Rap-
port, March 2003.
[48] Virgilio Rodriguez, Christophe Moy et Jacques Palicot, « An optimal architec-
ture for a multi-standard reconfigurable radio : A network theory re-formulation ».
In The 17th Annual IEEE International Symposium on Personal, Indoor and Mobile
Radio Communications (PIMRC’06), (Helsinki, Finland), 11-14 September 2006.
[49] Jean-Philippe Delahaye, Pierre Leray, Christophe Moy et Jacques Palicot,
« Managing Dynamic Partial Reconfiguration on Heterogeneous SDR Platform ».
In SDR Forum Technical Conference, (Anaheim, USA), November 2005.
[50] E. Sereni, G. Baruffa, F. Frescura et P. Antognoni, « A Software Reconfi-
gurable Architecture for 3G and Wireless Systems ». In Proceedings of 3G Wireless
2002, Febuary 2002.
[51] Jurgen Helmschmidt, Eberhard Schüler, Prashant Rao, Sergio Rossi, Serge
di Matteo et Rainer Bonitz, « Reconfigurable Signal Processing in Wireless Ter-
minal ». In Proc. Design, Automation, and Test in Europe (DATE), (Munich, Ger-
many), pages 20244–20249, 2003.
[52] Energy-Aware SYstem on-chip design of the HIPERLAN/2 standard,
« http ://easy.intranet.gr/ ». Rapport, 2004.
[53] Xavier Revés, Vuk Marojevic et Antoni Gelonch, « Run-time and development
framework for heterogenous hardware Radios ». Rapport, Barcelona, Spain, Sep-
tember 2004.
[54] Sandbridge Technologies. www.sandbridgetech.com.
[55] C. John Glossner, Mayan Moudgill, Daniel Iancu, Gary Nacer, Sanjay Jin-
turkar, Stuart Stanley, Michael Samori, Tanuj Raja, Michael J. Schulte et
Stamatis Vassiliadis, « Future wireless convergence platforms ». In CODES+ISSS
(Petru Eles, Axel Jantsch et Reinaldo A. Bergamaschi (eds.)), pages 7–12,
ACM, 2005.
[56] Intrinsity, www.intrinsity.com.
[57] C. Maxfield, Reconfiguring Chip Design. EEDesign, http ://www.eedesign.com/,
September 2002.
[58] J. Brakensiek, B. Oelkrug, M. Bucker, D. Uffmann, A. Droge et M. Daria-
nian, « Software Radio Approach for Reconfigurable Multi Standard Radios ». In
The 13th Annual IEEE International Symposium on Personal, Indoor and Mobile
Radio Communications (PIMRC’02), pages 110–114, september 2002.
[59] P. M. Heysters, H. Bouma, J. Smit, G. J. M. Smit et P. J. M. Havinga, « A re-
configurable function array architecture for 3G and 4G wireless terminals ». In World
Wireless Congress, San Francisco, California, (Cupertino, California), pages 399–
405, Delson Group, May 2002.
[60] Hiroshi Harada, Yukiyoshi Kamio et Masayuki Fujise, « Multimode Software
Radio System by Parameter Controlled and Telecommunication Component Block
Embedded Digital Signal Processing Hardware ». EICE TRANSACTIONS on Com-
munications, vol. E83-B, no 6, pages 217–1228, 2000.
[61] Katherine Compton et Scott Hauck, « Reconfigurable Computing : A Survey of
Systems and Software ». ACM Computing Surveys.
bibliographie 197
[62] Gerald Estrin, « Organization of Computer Systems-The Fixed Plus Variable

Structure Computer ». In Western Joint Computer Conference, (New York),
pages 33–40, 1960.
[63] Lilian Bossuet, Exploration de l’espace de conception des architectures reconfigu-
rables. Thèse de Doctorat, Université Bretagne Sud, LESTER, 2004.
[64] Reiner W. Hartenstein, « Coarse grain reconfigurable architecture (embedded
tutorial) ». In ASP-DAC, pages 564–570, ACM, 2001.
[65] Patrick Schaumont, Ingrid Verbauwhede, Kurt Keutzer et Majid Sarrafza-
deh, « A Quick Safari Through the Reconfiguration Jungle ». In DAC, pages 172–
177, ACM Proceedings of the 38th Design Automation Conference, DAC 2001, Las
Vegas, NV, USA, June 18-22, 2001.
[66] Karim Ben Chehida, Méthodologie de Partitionnement Logiciel/Matériel pour Pla-
teformes Reconfigurables Dynamiquement. Thèse de Doctorat, Université de Nice-
Sophia Antipolis - UFR Sciences, 2004.
[67] Jean Pierre David, Architecture synchronisée par les données pour système reconfi-
gurable. Thèse de Doctorat, Université catholique de Louvain, Faculté ses sciences
appliquées - Laboratoire de microélectronique, 2002.
[68] Srikathyayani Srikanteswara, Ramesh Chembel Palat, Jeffrey H. Reed et Peter
Athanas, « An overview of Configurable Computing Machines for Software Radio
Handsets ». IEEE Communications Magazine, vol. 41, pages 134–141, July 2003.
[69] Ahmad Alsolaim, Jürgen Becker, Manfred Glesner et Janusz Starzyk, « Ar-
chitecture and Application of a Dynamically Reconfigurable Hardware Array for
Future Mobile Communication Systems ». in FCCM [156].
[70] Jürgen Becker, T. Pionteck et Manfred Glesner, « An Application-tailored
Dynamically Reconfigurable Hardware Architecture for Digital Baseband Proces-
sing ». In Proc. of XIII Brazilian Symposium on Integrated CircuitDesign (XIII
SBCCI, ”Chip In The Jungle”), (Manaus, Brazil), 18-22 September 2000.
[71] H. Singh, M.-H. Lee, G. Lu, F. J. Kurdahi, N. Bagherzadeh et E. M. C.
Filho, « Morphosys : an integrated reconfigurable system for data-parallel and
computation-intensive applications ». In IEEE Trans. on Computers, vol. 49,
pages 465–481, 2000.
[72] Amir H. Kamalizad, Chengzhi Pan et Nader Bagherzadeh, « Fast Parallel
FFT on a Reconfigurable Computation Platform ». In Proceedings of the 15th
Symposium on Computer Architecture and High Performance Computing (SBAC-
PAD’03), 2003.
[73] G. Sassatelli, Architectures reconfigurables dynamiquement pour les systèmes sur
puce. Thèse de Doctorat, Université de Montpellier, France, 2002.
[74] R. David, Architectures reconfigurables dynamiquement pour applications mobiles.
Thèse de Doctorat, Université de Rennes 1, France, 2003.
[75] Jürgen Becker et Martin Vorbach, « Architecture, Memory and Interface Techno-
logy Integration of an Industrial/Academic Configurable System-on-Chip (CSoC) ».
In Proceedings of the IEEE Computer Society Annual Symposium on VLSI (ISVL-
SI’03), 2003.
198 bibliographie
[76] Mark Cummings et S. Haruyama, « FPGA in the Software Radio ». IEEE Com-
munications Magazine, vol. 37, no 2, pages 108–112, 1999.
[77] David M. Pearson, « SDR (systems defined radio) : how do we get there from
here ? ». In MILCOM, Military Communications Conference, Communications for
Network-Centric Operations : Creating the Information Force, Proceedings, vol. 1,
pages 571–575, October 2001.
[78] JTRS, « SCA Software Communications Architecture, (SCA v2.2) ». Rapport.
[79] Alistair Munro, « Mobile middleware for the reconfigurable software radio ». IEEE
Communications Magazine, vol. 38, pages 152–161, August 2000.
[80] (OMG) Object Modelling Group, http ://www.omg.org.
[81] Vincent Nollet, Paul Coene, Diederik Verkest, Serge Vernalde et Rudy Lau-
wereins, « Designing an Operating System for a Heterogeneous Reconfigurable
So. ». in IPDPS [157], page 174.
[82] Byron Tarver, Eric Christensen et Annamarie Miller, « Software defined ra-
dios (SDR) platform and application programming interfaces (API) ». In IEEE Mili-
tary Communications Conference, MILCOM, Communications for Network-Centric
Operations : Creating the Information Force, vol. 1, pages 153–157, 2001.
[83] Lee Pucker et Geoff Holt, « Extending the SCA core framework inside the modem
architecture of a software defined radio ». IEEE Communications Magazine, vol. 42,
no 3, pages 21–25, 2004.
[84] D. Dohse et al., « Successfully Introducing CORBA into the Signal Processing
Chain of a Software Defined Radio ». In COST Journal, pages 32–37, January 2003.
[85] D. Murotake, « Use of Switched Fabrics ». In Implementation of Software Defined
Radio Smart Antenna and Interference Cancellation Signal Processing SDR Forum
proc., vol. 2, November 2002.
[86] Xavier Revés, Vuk Marojevic, Ramon Ferrús et Antoni Gelonch, « FPGA’s
Middleware for Software Defined Radio Applications. ». In FPL (Tero Rissa, Steven
J. E. Wilton et Philip Heng Wai Leong (eds.)), pages 598–601, IEEE Proceedings
of the 2005 International Conference on Field Programmable Logic and Applications
(FPL), Tampere, Finland, August 24-26, 2005.
[87] Roman Lysecky, Frank Vahid et Sheldon X.-D. Tan, « Dynamic FPGA Rou-
ting for Just-in-Time Compilation ». In Proceedings of the 41th Design Automation
Conference, DAC, 2004.
[88] Apostolos A. Kountouris et Christophe Moy, « Reconfiguration in Software Ra-
dio Systems ». In Proc. 2nd Workshop on Software Radios, (Karlsruhe, Germany),
March 2002.
[89] Gyula Rábai, Sándor Imre, József Kovács et Péter Kacsuk, « Resource Manage-
ment in Software Radio Architectures ». In Proc. 2nd Workshop on Software Radios,
(Karlsruhe, Germany), March 2002.
[90] Mehul Mehta et M. Wesseling, « Adaptive baseband sub-system for TRUST ».
In The 11th IEEE International Symposium on Personal, Indoor and Mobile Radio
Communications, , (PIMRC), vol. 1, pages 29–33, 2000.
bibliographie 199
[91] Klaus Moessner, Stoytcho Gultchev et Rahim Tafazolli, « Software Defined

Radio Reconfiguration Management ». In The 12th IEEE International Symposium
on Personal, Indoor and Mobile Radio Communications, (PIMRC), vol. 1, pages 91–
95, September 2001.
[92] S. Gultchev, K. Moessner et R. Tafazoli, « Management and Control of Re-
configuration Procedures in Software Radio Terminals ». In Proc. 2nd Workshop on
Software Radios, (Karlsruhe, Germany), pages 125–129, March 2002.
[93] J. Brakensiek, D. Lenz, S. Gultchev, R. Tafazolli, A. Bisiaux, C. Moy,
M. Halimic et C. Dolwin, « Management and Controlling Architecture in E2 R
Reconfigurable Terminals ». In Proc. 3nd Workshop on Software Radios, (Karlsruhe,
Germany), March 2004.
[94] J. Vogler et al., « Equipment Management and Control Architecture ». E2 R
White Paper, http ://e2r.motlabs.com/whitepapers/, 2005.
[95] C. Dolwin, S. Mende et J. Brakensiek, « The Role of the Configuration Control
Module in an End to End Reconfigurable System ». Software Defined Radio Tech-
nical Conference, November 2004.
[96] Srikathyayani Srikanteswara, Jeffrey H. Reed, Peter Athanas et Robert
Boyle, « A soft radio architecture for reconfigurable platforms ». IEEE Communi-
cations Magazine, vol. 38, pages 140–147, Febuary 2000.
[97] Jean-Philippe Delahaye, Jacques Palicot et Pierre Leray, « A Hierarchical Mo-
deling Approach in Software Defined Radio System Design ». In IEEE Workshop
on Signal Processing Systems Design and Implementation (SIPS), pages 42–47, No-
vember 2005.
[98] Akarsh Reddy Ravi, « Globally-Asynchronous Locally-Synchronous Wrapper Confi-
gurations For Point-To-Point and Multi-Point Datacommuncations ». Master’s the-
sis, University of Central Florida, Orlando, Florida, 2001.
[99] Loı̈g Godard, Christophe Moy et Jacques Palicot, « From a configuration mana-
gement to a cognitive radio management of SDR system ». In Proc. IEEE Crown-
Com, (Karlsruhe, Germany), June 2006.
[100] Jean-Philippe Delahaye, Guy Gogniat, Christian Roland et Pierre Bomel,
« Software Radio and Dynamic Reconfiguration on a DSP/FPGA Platform ». Fre-
quenz, Journal of RF-Engineering and Telecommunications, vol. 58, May-June 2004.
[101] Erich, Gamma, Richard Helm, Ralph Johnson et John M. Vlissides, « Design
Patterns : Elements of Reusable Object-Oriented Software ». page 416, Addison
Wesley Professional, October 1994.
[102] Honghzi Wang, Jean-Philippe Delahaye, Pierre Leray et Jacques Palicot,
« Managing Dynamical Reconfiguration on MIMO Decoder ». In IPDPS, IEEE
Computer Society, 21th International Parallel and Distributed Processing Sympo-
sium (IPDPS 2007), Long Beach, CA, USA, 26-30 March, 2007.
[103] L. Kessal, D. Demigny, R. Bourguiba et N. Boudouani, « Architecture re-
configurable méthodologie et modélisation VHDL pour la mise au point d’applica-
tions ». In 6èmes Symposium en Architectures Nouvelles de Machines, SympA’06,
(Besançon, France), 19-22 juin 2000.
200 bibliographie
[104] D. Demigny, M. Paindavoine et S. Weber, « Architecture Reconfigurable Dyna-

miquement pour le Traitement Temps Réel des Images ». Revue technique et Sciences
de l’information, Numéro Spécial programmation des Architectures Reconfigurables,
1998.
[105] Scott Hauck, Zhiyuan Li et Eric J. Schwabe, « Configuration compression for the
Xilinx XC6200 FPGA ». IEEE Trans. on CAD of Integrated Circuits and Systems,
vol. 18, no 8, pages 1107–1113, 1999.
[106] Zhiyuan Li et Scott Hauck, « Configuration Compression for Virtex FPGAs ». In
9th IEEE Symposium on Field-Programmable Custom Computing Machines (FCCM
2001), (Los Alamitos, CA, USA), pages 147–159, IEEE Computer Society, 2001.
[107] Zhiyuan Li, Katherine Compton et Scott Hauck, « Configuration Caching Mana-
gement Techniques for Reconfigurable Computing. ». in FCCM [156], pages 22–38.
[108] Scott Hauck, « Configuration Prefetch for Single Context Reconfigurable Copro-
cessors. ». In FPGA, pages 65–74, 1998.
[109] Zhiyuan Li et Scott Hauck, « Configuration prefetching techniques for par-
tial reconfigurable coprocessor with relocation and defragmentation ». In FPGA,
pages 187–195, 2002.
[110] James D. Hadley et Brad L. Hutchings, « Design methodologies for partially
reconfigured systems ». In FCCM, pages 78–84, 3rd IEEE Symposium on Field-
Programmable Custom Computing Machines (FCCM ’95), Napa Valley, CA, USA,
19-21 April, 1995.
[111] Xilinx, Virtex Series Configuration Architecture User Guide. Xilinx, Inc., 2100
Logic Drive, San Jose, CA 95124, March 2003. Application Note 151.
[112] Adriatic Project IST-2000-30049, « D3.2 ADRIATIC back-end design tools for the
reconfigurable logic blocks ». Rapport, November 2003.
[113] Adriatic Advanced Methodology for Designing ReconfIgurable SoC et
Application-Targeted IP entities in wireless Communications Project IST-
2000-30049, « Final Report, month = ». Rapport.
[114] Arnd-Ragnar Rhiemeier et Friedrich Jondral, « A software radio view of modu-
lation and spreading for UTRA FDD and UTRA TDD ». In Third International
Conference on 3G Mobile Communication Technologies, no. 489, pages 464–468,
May 2002.
[115] David Elléouet, Méthodes de modélisation, d’estimation et d’optimisation de la
consommation d’applications du TDSI pour la conception de système reconfigurable
de type FPGA. Thèse de Doctorat, Université Rennes 1, IETR/INSA, Université
Bretagne Sud, LESTER, 2006.
[116] Daniel Mesquita, Fernando Gehm Moraes, José Palma, Leandro Möller et Ney
Laert Vilar Calazans, « Remote and Partial Reconfiguration of FPGAs : Tools and
Trends. ». in IPDPS [157], page 177.
[117] D. Lim et M. Peattie, Two Flows for Partial Reconfiguration : Module Based or
Small Bit Manipulations. Xilinx, Inc., 2100 Logic Drive, San Jose, CA 95124, 2002.
Application Note 290.
[118] Xilinx, Inc., 2100 Logic Drive, San Jose, CA 95124, Development System Reference
Guide. http ://www.xilinx.com.
bibliographie 201
[119] Xilinx, Inc., 2100 Logic Drive, San Jose, CA 95124, Constraints Guide.
http ://www.xilinx.com.
[120] Xilinx, Inc., 2100 Logic Drive, San Jose, CA 95124, Libraries Guide.
http ://www.xilinx.com.
[121] Cameron Patterson, « A Dynamic Module Server for Embedded Platform FP-
GAs. ». In Engineering of Reconfigurable Systems and Algorithms (Toomas P. Plaks
(ed.)), pages 31–40, CSREA Press Proceedings of the International Conference on
Engineering of Reconfigurable Systems and Algorithms, Las Vegas, Nevada, USA,
June 23 - 26, 2003.
[122] Eric Keller, « JRoute : A Run-Time Routing API for FPGA Hardware. ». In
IPDPS Workshops (José D. P. Rolim (ed.)), vol. 1800 of Lecture Notes in Computer
Science, pages 874–881, Springer Proceedings of Parallel and Distributed Processing,
IPDPS 2000 Workshops, Cancun, Mexico, May 1-5, 2000.
[123] Xilinx, Inc., 2100 Logic Drive, San Jose, CA 95124, JBits SDK, Febuary 2001.
http ://www.xilinx.com/products/software/jbits/.
[124] Cameron Patterson et Steven A. Guccione, « JBits” Design Abstractions ».
In FCCM ’01 : Proceedings of the the 9th Annual IEEE Symposium on Field-
Programmable Custom Computing Machines, (Washington, DC, USA), pages 251–
252, IEEE Computer Society, 2001.
[125] Steven A. Guccione et Delon Levi, « XBI : a Java-based interface to FPGA hard-
ware ». In Proc. SPIE Vol. 3526, Configurable Computing : Technology and Appli-
cations (John Schewel (ed.)), pages 97–102, October 1998.
[126] Steven A. Guccione, Delon Levi et Prasanna Sundararajan, « JBits : A Java-
based Interface for Reconfigurable Computing ». In 2nd Annual Military and Aeros-
pace Applications of Programmable Devices and Technologies Conference (MAPLD),
September 1999.
[127] Francisco Fons, Mariano Fons, Enrique Cantó et Mariano López, « Trigonome-
tric computing embedded in a dynamically reconfigurable cordic system-on-chip ».
In International Workshop on Applied Reconfigurable Computing, (ARC’2006),
March 2006.
[128] Steve Young, Peter Alfke, Colm Fewer, Scott McMillan, Brandon Blodget
et Delon Levi, « A High I/O Reconfigurable Crossbar Switch ». In 11th IEEE Sym-
posium on Field-Programmable Custom Computing Machines (FCCM 2003), (Los
Alamitos, CA, USA), page 3, 2003.
[129] J. Valls, M.M. Peiro, T. Sansaloni et E. Boemo, « A study about FPGA-
based digital filters ». In IEEE Workshop on Signal Processing Systems, SIPS 98,
pages 192–201, 8-10 October 1998.
[130] Xilinx, Inc., 2100 Logic Drive, San Jose, CA 95124, Virtex-4 User Guide, September
2004. http ://www.xilinx.com.
[131] Yeong-Jae Oh, Hanho Lee et Chong-Ho Lee, « Dynamic Partial Reconfigurable
FIR Filter ». In International Workshop on Applied Reconfigurable Computing, ARC
2006, pages 30–35, March 2006.
[132] Xilinx, Inc., 2100 Logic Drive, San Jose, CA 95124, XST User Guide, (Xilinx Syn-
thesis Tool). http ://www.xilinx.com.
202 bibliographie
[133] Xilinx, « Virtex FPGA Series Configuration and Readback ». Rapport, Xilinx, Inc.,
2100 Logic Drive, San Jose, CA 95124, 2002. Application Note 138.
[134] Brandon Blodget, Scott McMillan et Patrick Lysaght, « A Lightweight Ap-
proach for Embedded Reconfiguration of FPGAs ». In DATE, pages 10399–10401,
Design, Automation and Test in Europe Conference and Exposition (DATE 2003),
Munich, Germany, 3-7 March, 2003.
[135] Brandon Blodget, Philip James-Roxby, Eric Keller, Scott McMillan et Pra-
sanna Sundararajan, « A Self-reconfiguring Platform ». In FPL (Peter Y. K.
Cheung, George A. Constantinides et José T. de Sousa (eds.)), vol. 2778 of
Lecture Notes in Computer Science, pages 565–574, Springer Proceedings of Field
Programmable Logic and Application, 13th International Conference, (FPL 2003),
Lisbon, Portugal, September 1-3,, 2003.
[136] Michael Ullmann, Michael Hübner, Björn Grimm et Jürgen Becker, « An FPGA
Run-Time System for Dynamical On-Demand Reconfiguration. ». In IPDPS, IEEE
Computer Society, 26-30 April 2004.
[137] Maria George et Peter Alfke, Linear Feedback Shift Registers in Virtex Devices.
Xilinx, Inc., 2100 Logic Drive, San Jose, CA 95124, March 2000. Application Note
210.
[138] A. Benkrid, K. Benkrid et D. Crookes, « Design and Implementation of Novel
FIR Filter Architecture for Efficient Signal Boundary Handling on Xilinx VIRTEX
FPGAs ». ISVLSI, page 222, 2004.
[139] Philip James-Roxby et Brandon J. Blodget, « A study of high-performance re-
configurable constant coefficient multiplier implementations ». In SPIE proceedings
series (SPIE proc. ser.) International Society for Optical Engineering proceedings
series, vol. 4693, pages 150–161, 2002.
[140] Philip James-Roxby et Brandon J. Blodget, « A study of high-performance re-
configurable constant coefficient multiplier implementations ». In IEEE Symposium
on Field-Programmable Custom Computing Machines (FCCM), pages 335–336, 17-
19 April 2002.
[141] « Network of Excellence in Wireless Communications ». http ://newcom.ismb.it/.
[142] David Elleouet, Nathalie Julien et Dominique Houzet, « An FPGA Run-Time
System for Dynamical On-Demand Reconfiguration. ». In 20th International Pa-
rallel and Distributed Processing Symposium (IPDPS 2006), CD-ROM / Abstracts
Proceedings, 25-29 April 2006, Rhodes Island, Greece, IEEE Computer Society, 2006.
[143] Juergen Becker, Michael Huebner et Michael Ullmann, « Power Estimation
and Power Measurement of Xilinx Virtex FPGAs : Trade-Offs and Limitations ». In
SBCCI ’03 : Proceedings of the 16th symposium on Integrated circuits and systems
design, (Washington, DC, USA), page 283, IEEE Computer Society, 2003.
[144] TINA Consortium, « Principles of TINA, (Telecommunications Information Net-
work Architecture) ». Rapport, 1995.
[145] Ciaran McHale, « CORBA Explained Simply ». Rapport, October 2004.
[146] J. Bertrand, J.W. Cruz, B. Majkrzak et T. Rossano, « CORBA delays in a
software-defined radio ». IEEE Communications Magazine, vol. 40, no 2, pages 152–
155, 2002.
bibliographie 203
[147] SDR Forum, « API Position Paper System Interface Working Group ». Rapport,
2003.
[148] SDR Forum, « Request for Information - Hardware Abstraction Layer ». Rapport,
2004.
[149] Shiao-Li Tsao, Chia-Ching Lin, Chin-Lien Chiu, Hung-Lin Chou et Min-Chiao
Wang, « Design and implementation of software framework for software defined
radio system ». In IEEE 56th Vehicular Technology Conference, Proceedings, vol. 4,
pages 2395–2399, September 2002.
[150] Stefan Pees, Andreas Hoffmann, Vojin Zivojnovic et Heinrich Meyr, « LISA
- Machine Description Language for Cycle-Accurate Models of Programmable DSP
Architectures. ». In DAC, pages 933–938, 1999.
[151] Andreas Hoffmann, Oliver Schliebusch, Achim Nohl, Gunnar Braun, Oliver
Wahlen et Heinrich Meyr, « A Methodology for the Design of Application Specific
Instruction Set Processors (ASIP) using the Machine Description Language LISA. ».
In ICCAD, pages 625–630, 2001.
[152] Oliver Schliebusch, Andreas Hoffmann, Achim Nohl, Gunnar Braun et Hein-
rich Meyr, « Architecture Implementation Using the Machine Description Language
LISA. ». In ASP-DAC, pages 239–244, IEEE Proceedings of the ASPDAC 2002 /
VLSI Design 2002, Bangalore, India, 7-11 January, 2002.
[153] CEVA DSP, http ://www.ceva-dsp.com/.
[154] ACE CoSy, http ://www.ace.nl/compiler/cosy-technology.html.
[155] Xilinx, Xilinx Virtex-II Platform FPGAs : Complete Data Sheet. Xi-
linx, Inc., 2100 Logic Drive, San Jose, CA 95124, 2005. http ://di-
rect.xilinx.com/bvdocs/publications/ds031.pdf.
[156] 8th IEEE Symposium on Field-Programmable Custom Computing Machines (FCCM
2000), 17-19 April 2000, Napa Valley, CA, Proceedings, IEEE Computer Society,
2000.
[157] 17th International Parallel and Distributed Processing Symposium (IPDPS 2003),
22-26 April 2003, Nice, France, CD-ROM/Abstracts Proceedings, IEEE Computer
Society, 2003.

These Delahaye 2007

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

These Delahaye 2007

Transféré par

Droits d'auteur :

Formats disponibles

No d’ordre : 3482

pour obtenir le grade de

Équipe d’accueil : Institut d’électronique et de télécommunications de Rennes

Plate-forme hétérogène reconfigurable : application à

Soutenue le 18 avril 2007 devant la commission d’examen

Je remercie Monsieur Jean-François Hélard, Professeur des Universités à l’Institut

Je souhaite exprimer toute ma sympathie aux doctorants de Supélec et aux doctorants

Je souhaite remercier ma chère tante Monique De La Gontrie pour la très précieuse

Table des matières v

I Applications radio logicielle 7

1 Introduction à la radio logicielle 9

2 Étude des standards : vers une application multistandard 19

3 Analyse radio logicielle des applications multi-standards 33

3.2.3 Analyse des besoins de gestion de conﬁguration de l’application

II Systèmes reconﬁgurables pour la radio logicielle 49

4 Architectures systèmes radio logicielle 51

5 Un modèle d’architecture pour la radio logicielle 75

III Plateforme radio logicielle 91

6 Conception et intégration des applications SDR sur plate-forme recon-

7 Réalisation : plate-forme radio logicielle et implantation 127

Conclusions et perspectives 151

A Travaux issus de collaborations 161

B Les standards 165

C Architectures systèmes 175

Table des ﬁgures 187

Liste des tableaux 191

Les acteurs de l’industrie des télécommunications, opérateurs et équipementiers font face à

consommation des processeurs, les limites de performances des convertisseurs et la limi-

Aujourd’hui, la radio logicielle est la convergence entre radiocommunication et informa-

Le domaine de la recherche académique en radio logicielle représente une thématique

en ressources matérielles par le partage de celles-ci entre plusieurs standards de communi-

des circuits reconﬁgurables, nécessite de mettre en place des méthodologies de conception

chaı̂ne de traitement. Les implantations de ces algorithmes reconﬁgurables per-

Applications radio logicielle

Introduction à la radio logicielle

Fig. 1.1 – PMCS [7], le modèle de référence proposé par le JTRS

Diﬀusion Positionnement Mobile Réseaux

Tab. 1.1 – Services et standards de radiocommunications

Fig. 1.2 – Évolution de la radio logicielle et des technologies utilisées

1.1 Déﬁnitions et généralités

Fig. 1.3 – Principales architectures de récepteurs radio

Niveau Terme Description

Tab. 1.2 – Terminologie radio logicielle déﬁnie par le SDR Forum

Fig. 1.4 – Projets traitant de la re-conﬁgurabilité

IST-CAST 04/2000-12/2002 : Conﬁgurable Radio with Advance Software Technology.

1.2 Contraintes et besoins pour les architectures systèmes

de fonctionnement. Les architectures reconﬁgurables ou processeurs spécialisés peuvent

Fig. 1.6 – Besoins en ressources de traitements des systèmes RL

Étude des standards : vers une

Introduction aux applications multi-standards

2.1 Motivations sur les choix des standards

Systèmes GSM900 DCS1800 UMTS/FDD 802.11g

Tab. 2.1 – Caractéristiques des interfaces air des standards étudiés

2.2 Le système cellulaire GSM

2.2.1 Les caractéristiques générales du système

Principaux canaux logiques et physiques

2.2.2 Les traitements en bande de base

Fig. 2.1 – Diagramme en blocs des traitements en bande de base GSM

j = 2((49k) mod 57 + ((k mod 8))/4) (2.4)

2.3 Le système cellulaire UMTS/FDD

2.3.1 L’interface radio

Fig. 2.2 – Couche physique de l’UMTS basée sur l’étalement de spectre

l’étalement de spectre consistant à la canalisation suivie d’un embrouillage, puis d’une

2.3.2 Les traitements en bande de base