MACHINE VIRTUELLE POUR LA RADIO LOGICIELLE

N d ordre 2010-ISAL-0086 Année 2010 THÈSE DE DOCTORAT Présentée devant L INSTITUT NATIONAL DES SCIENCES APPLIQUÉES DE LYON Pour l obtention DU GRADE DE DOCTEUR Par Riadh BEN ABDALLAH MACHINE VIRTUELLE POUR LA RADIO LOGICIELLE Encadré par Tanguy RISSET et Antoine FRABOULET Projet SWING-INRIA, Laboratoire CITI, INSA de Lyon École Doctorale Informatique et Mathématiques En partenariat avec Jérôme MARTIN et Yves DURAND Laboratoire LETI/LISAN, CEA de Grenoble Soutenue le 20 octobre 2010 devant la commission d examen Jury Gilles MULLER Directeur de recherche, INRIA Rapporteur Olivier SENTIEYS Professeur des universités, ENSSAT Lanion Rapporteur Dominique HOUZET Professeur des universités, INPG Examinateur Frédéric PÉTROT Professeur des universités, INPG Examinateur Yves DURAND Ingénieur de recherche à Kalray Examinateur Jérôme MARTIN Ingénieur de recherche au CEA de Grenoble Encadrant de thèse Tanguy RISSET Professeur des universités, INSA de Lyon Directeur de thèse Antoine FRABOULET Maitre de conférence, INSA de Lyon Co-directeur de thèse

A ma grand-mère, A mes parents, A mes frères, A toute ma famille et tous mes amis

Remerciements Je remercie tout d abord Olivier SENTIEYS et Gilles MULLER pour l intérêt qu ils ont porté à mon travail et d avoir accepté d en être les rapporteurs. Merci également aux autres membres du jury qui ont accepté de juger ce travail : Frédéric PETROT et Dominique HOUZET professeurs des universités à l INPG et Yves DURAND Ingénieur de recherche à Kalray. Je tiens tout particulièrement à exprimer mes remerciements à Tanguy RISSET et Antoine FRABOULET qui ont dirigé cette thèse dans la continuité de mon stage de Master. Tout au long de ces trois années, ils m ont patiemment encadré et étaient toujours disponibles même pendant ma deuxième année de thèse, lorsque j étais accueilli dans les laboratoires du CEA-Leti à Grenoble. Leurs conseils et leurs encouragements ont été déterminants pour la réussite de cette thèse. Je les remercie vivement. Je remercie aussi mon encadrant au laboratoire LISAN du CEA-Leti : Jérôme MARTIN pour son aide précieuse qui m a permis d appréhender rapidement les concepts fondamentaux du démonstrateur MA- GALI sur lequel s appuie mes travaux de recherche. Je le remercie aussi pour sa disponibilité, ses conseils pertinents et ses directives déterminantes pour la mise en œuvre des concepts proposés dans cette thèse. J ai eu également le plaisir de collaborer avec Yves DURAND qui m a encadré en début de thèse avant son départ à Kalray. Je le remercie vivement d avoir orienter au bon moment mes axes de recherches et pour ses conseils qui étaient déterminants pour la suite de la thèse. Je le remercie aussi de son suivi du déroulement de la thèse même après son départ du CEA. Je remercie tous les membres du laboratoire LISAN où j ai passé un an et demi pour avoir accès aux technologies de pointe concernant les architectures numériques de radio logicielle. Un grand merci à François BERTRAND qui m a accueilli au sein de son équipe et surtout à Frédéric HEITZMANN et Romain LEMAIRE pour leurs aides indispensables. Enfin, Je voudrais aussi remercier chaleureusement toutes les personnes que j ai côtoyé ces dernières années : toute l équipe du laboratoire CITI, mes amis et ma famille, et particulièrement mes parents qui m ont toujours soutenu et encouragé.

Résumé Résumé Les architectures matérielles dédiées à la radio logicielle sont complexes à manipuler. L automatisation du passage de la modélisation à l implémentation a beaucoup d avantages et représente des enjeux économiques importants. Dans la littérature, les approches proposées de modélisation de la radio logicielle sont spécifiques à des plateformes particulières. Le passage à l implémentation se fait généralement par des techniques de compilation et de génération de code. Dans tous les cas, le programme exécutable généré est spécifique à une plateforme cible. Dans cette thèse, on propose un modèle de programmation orienté machine virtuelle qui permet d exprimer différents protocoles de niveau physique indépendamment de la plateforme cible. A ce modèle on associe un langage compilable vers un byte-code exécuté par la machine virtuelle radio (elle même est exécutée par un processeur natif ou réalisée par un matériel dédié) pour la configuration et le contrôle des plateformes radios. La machine virtuelle radio a été d abord expérimentée fonctionnellement sur une plateforme logicielle (PC) puis sur une plateforme réaliste avec considération des contraintes temps réel sur le système sur puce MAGALI (circuit du CEA-Leti). Pour valider le concept, des services de standards existants de couches physiques ont été implémentés. Les surcoûts de la machine virtuelle et du modèle de programmation ont été étudiés. Une évaluation quantitative expérimentale de ce surcoût a été réalisée et des techniques d optimisations ont été proposées. Abstract The hardware architectures dedicated to software radio are complex to handle. Automatic transition from modeling to implementation has many benefits and represents important economic perspectives. However the proposed approaches for software radios modeling, found in the state of the art, are specific to particular execution platforms. Indeed, moving to implementation is generally done through compilation and code generation techniques. In all cases, the generated executable program is definitively targeted for a specific platform. In this thesis, we propose a virtual machine based programming model which can express different physical layer protocols independently of the target platform. To this model we defined an associated language compilable into a high level byte-code to be executed by the radio virtual machine (which itself is executed by either a classic native processor or dedicated hardware) for configuration and control of radio platforms. The radio virtual machine was first tested functionally on a software platform (PC) Then it has been experimented on a realistic platform with real-time constraints consideration : the CEA-Leti MAGALI chip. To validate the concept, several transmit and receive services of existing physical layer standards have been implemented. The additional costs of the virtual machine and the programming model were studied. A quantitative experimental evaluation of these additional costs have been realized and optimization techniques have been proposed.

Table des matières 1 Introduction............................................................................ 2 1.1 Introduction Générale...................................... 3 1.2 Contexte radio logicielle.................................... 3 1.3 Problématiques de la thèse................................... 5 1.4 Motivations et contributions de la thèse............................ 7 1.5 Organisation du manuscrit................................... 8 2 État de l art............................................................................. 10 Introduction.............................................. 11 2.1 Plateformes matérielles pour la radio logicielle........................ 11 2.1.1 Aperçu des plateformes de radio logicielle existantes................. 12 2.1.2 Cycle de développement des radios logicielles.................... 14 2.2 Spécification des formes d ondes................................ 16 2.2.1 Modélisation des formes d ondes........................... 17 2.2.2 Langages de description des formes d ondes...................... 18 2.3 Architectures logicielles et environnements d exécutions................... 27 2.3.1 Architecture SCA (Software Communication Architecture).............. 27 2.3.2 Environnement d exécution radio logicielle de l UPC................. 30 2.4 Les radios virtuelles....................................... 31 2.4.1 Proposition de Gudaitis et Mitola........................... 31 2.4.2 Implémentations propriétaires............................. 32 Conclusion.............................................. 33 3 Modèle de programmation rkpn........................................................ 34 Introduction.............................................. 35 3.1 Modèle de calcul rkpn (reconfigurable KPN).......................... 35 3.1.1 Définitions et modèles antérieurs............................ 36 3.1.2 Proposition du modèle rkpn.............................. 39 3.1.3 Proposition d un modèle d exécution associé..................... 42 3.2 PLDL (Physical Layer Description Language)......................... 43 3.2.1 Description du langage PLDL.............................. 43 3.2.2 Implémentation du IEEE802.11a en PLDL....................... 45 3.3 Proposition du dispositif «programmable pipe»........................ 50 3.3.1 Problème visé...................................... 51 3.3.2 Description du dispositif PP.............................. 51 ix

Table des matières 3.3.3 Exemple d utilisation du PP : bloc d estimation de canal d un récepteur IEEE802.11a 54 Conclusion.............................................. 56 4 Implémentation logicielle de la MVR sur MAGALI....................................... 58 Introduction.............................................. 59 4.1 Aperçu du SoC MAGALI.................................... 60 4.1.1 Architecture et concepts fondamentaux de MAGALI.................. 60 4.1.2 Environnements de simulation et de développement.................. 64 4.1.3 Choix du circuit MAGALI comme plateforme de preuve de concept.......... 67 4.2 Réalisation des primitives du PLDL sur MAGALI........................ 67 4.2.1 Architecture logicielle existante............................ 67 4.2.2 Implémentation de la RVM API sur le SoC MAGALI.................. 70 4.3 Extension de la machine virtuelle «Lua» en MVR....................... 74 4.3.1 Machines virtuelles candidates............................. 75 4.3.2 Portage de la machine virtuelle «Lua» sur le processeur ARM1176JZF-S...... 77 4.3.3 Intégration globale................................... 78 4.4 Réalisation du dispositif «Programmable Pipe» (PP)..................... 80 4.4.1 L association ARM-SME................................ 80 4.4.2 Réalisation du PP et de ses primitives......................... 82 Conclusion.............................................. 84 5 Expérimentations....................................................................... 86 Introduction.............................................. 87 5.1 1 re expérimentation : Un seul opérateur fonctionnel (FFT)................... 87 5.1.1 Protocole d expérimentation.............................. 87 5.1.2 Résultats expérimentaux................................ 90 5.1.3 Analyse des résultats.................................. 91 5.2 2 e expérimentation : Estimation du CFO IEEE802.11a..................... 94 5.2.1 Protocole d expérimentation.............................. 94 5.2.2 Résultats expérimentaux................................ 96 5.2.3 Analyse des résultats.................................. 98 5.3 Proposition de techniques d optimisation............................ 99 5.3.1 Compilation à la volée................................. 99 5.3.2 Traduction de code................................... 100 5.3.3 Accélération matérielle................................. 102 Conclusion.............................................. 102 6 Démonstrateur 3GPP/LTE............................................................... 104 Introduction.............................................. 105 6.1 Le standard 3GPP LTE..................................... 105 6.1.1 Aperçu du standard 3GPP/LTE............................. 106 6.1.2 La couche physique 3GPP/LTE............................. 108 6.2 Implémentation d un récepteur 3GPP/LTE sur MAGALI.................... 110 6.2.1 Partitionnement de l application sur MAGALI.................... 111 6.2.2 Schémas de configuration et de contrôle........................ 113 x

Table des matières 6.3 Implémentation par la machine virtuelle radio......................... 115 6.3.1 Conception de l application récepteur LTE (mode (5))................. 115 6.3.2 Résultats et Analyse.................................. 119 Conclusion.............................................. 121 7 Conclusion............................................................................. 122 7.1 Synthèse............................................. 123 7.2 Perspectives........................................... 124 7.2.1 Utilisation des processeurs mutlicœurs pour la radio logicielle............ 124 7.2.2 Ingénierie de bytecode pour optimiser l adéquation algorithme-architecture..... 125 7.2.3 Support de l exécution simultanée de multiple applications radios.......... 125 Liste des publications.......................................................................... 128 Bibliographie................................................................................. 130 Annexes...................................................................................... 136 A Programmes de l émetteur / récepeteur IEEE802.11a................................... 137 A.1 Programme de l émetteur IEEE802.11a............................ 138 A.2 Programme du récepteur IEEE802.11a............................. 142 B Liste non exhaustive des machines virtuelles existantes.................................. 151 B.1 Liste des machines virtuelles libres............................... 152 B.2 Liste des machines virtuelles Java............................... 153 xi

Table des figures 1.1 Convergence des standards vers la radio logicielle....................... 4 1.2 Architecture classique d un émetteur-récepteur........................ 5 1.3 Les objectifs majeurs de la radio logicielle........................... 6 1.4 Proposition du concept de machine virtuelle pour la réalisation de la radio logicielle..... 6 2.1 Plateformes radios logicielles.................................. 12 2.2 Flot classique de conception de systèmes............................ 14 2.3 Étapes de la conception dirigée par les modèles........................ 15 2.4 Exemple de raffinement par décomposition d une entité.................... 19 2.5 Exemple d un assemblage RDL................................. 21 2.6 Flot de données de l assemblage de la figure FIG. 2.5..................... 21 2.7 Architecture logicielle pour l exécution du RDL (extrait de [33])............... 22 2.8 Architecture de configuration et de contrôle des équipements radio E 2 R........... 22 2.9 Extrait d un programme écrit en E 2 R FDL d un émetteur IEEE802.11a............ 24 2.10 Exemple de code Kernel SPEX (extrait de [36])........................ 25 2.11 Exemple de code Stream SPEX (extrait de [36])........................ 26 2.12 Exemple de code Synchronous SPEX (extrait de [36])..................... 26 2.13 Architecture SCA d un système radio.............................. 29 3.1 Exemple de graphe KPN.................................... 36 3.2 Exemple d un processus de kahn (extrait de [50])....................... 37 3.3 Exemple de graphe SDF..................................... 37 3.4 Exemple de graphe CSDF.................................... 38 3.5 Un KPN (à gauche) et le rkpn associé............................. 40 3.6 Un rkpn pendant et après reconfiguration........................... 40 3.7 Exemple de composant radio, FFT............................... 41 3.8 Modèle d architecture d exécution adapté à rkpn....................... 43 3.9 Architecture de la couche 802.11................................ 46 3.10 Format d un PPDU IEEE802.11a extrait de [58]........................ 46 3.11 Architecture globale du démonstrateur IEEE802.11a..................... 47 3.12 Diagramme de séquences de l estimation de l erreur CFO................... 49 3.13 Synoptique du programmable pipe............................... 52 3.14 Synoptique du programmable pipe (version avec deux buffers)................ 54 3.15 Séquence d apprentissage d un PPDU IEEE802.11a...................... 55 3.16 Chaîne de traitement pour l estimation de canal et son égalisation............... 55 4.1 Le système sur puce MAGALI.................................. 59 4.2 Contrôleur CCC intégré dans une ressource de MAGALI.................... 61 4.3 Exemple du protocole de configuration et de communication sur MAGALI.......... 62 xii

Table des figures 4.4 Micro architecture d une unité de traitement du circuit MAGALI (figure extraite de [69])... 63 4.5 Différents modes de simulation du processeur ARM sur MAGALI.............. 65 4.6 Compilateur de communication COMC............................. 66 4.7 Découpage de l API FAUST2.................................. 68 4.8 Architecture logicielle de la machine virtuelle radio...................... 75 4.9 Modules fonctionnels qui composent l environnement Lua (figure extraite de [81])..... 76 4.10 Association ARM1176 - SME.................................. 80 4.11 Micro-architecture du SME................................... 81 4.12 Exécution d un processus de «programmable pipe» (L_pp) par le processeur ARM..... 82 5.1 Exécution de la FFT sur un nombre variable de données : les 3 implémentations de la 1 re expérimentation......................................... 88 5.2 Temps total d exécution simulés des trois configurations d implémentation.......... 90 5.3 Chronogrammes pour le processeur et l IP FFT pour les trois configurations : native (a), RVM API (b), RVM complète (c).................................... 91 5.4 Décomposition du temps d exécution de la 1 re expérimentation pour les trois configurations d implémentation........................................ 93 5.5 CFO Implémentation de l estimation CFO selon la configuration native............ 94 5.6 Structure d une trame IEEE802.11a.............................. 95 5.7 Les phases d exécution de l application CFO selon les 3 configurations d implémentation.. 98 5.8 Traduction de code appliquée à un programme radio...................... 101 6.1 Architecture de l interface radio LTE.............................. 107 6.2 Structure de la trame de niveau physique LTE type-1...................... 108 6.3 Structure d un slot de trame type-1 LTE............................ 108 6.4 Décomposition d un slot de trame LTE en blocs de ressources................. 109 6.5 Structure d un symbole OFDM de référence LTE........................ 110 6.6 Découpage en modules fonctionnels du récepteur LTE réalisé par le laboratoire LISAN du CEA-LETI............................................ 111 6.7 Les flots de traitement de données nécessaires aux quatre phases d exécution d un récepteur LTE (figure extraite de [66])................................... 113 6.8 Chronogramme des phases d exécution de l application LTE (figure extraite de [66])..... 114 6.9 Flot de traitement de données correspondant à la phase (a) (avec MVR)............ 116 6.10 Diagramme de séquence de la phase d exécution (a) (avec MVR)............... 116 6.11 Scénario de calcul des paramètres de configuration par le PP................. 117 6.12 Flot de traitement de données correspondant à la phase (c) (avec MVR)............ 117 6.13 Flot de traitement de données correspondant à la phase (c) (avec MVR)............ 118 6.14 Chronogramme des phases d exécution de l application LTE implémenté avec le concept de MVR............................................... 119 7.1 Cas d utilisation de la MVR avec une ingénierie de bytecode préalable adaptée à l architecture cible au niveau de l opérateur............................... 125 xiii

Liste des tableaux 2.1 Temps de développement (homme heures) - Approche traditionnelle (extrait de [19]).... 15 2.2 Temps de développement (homme heures) - Approche rapide (extrait de [19])........ 16 2.3 Principaux types de données pour la configuration des modems radios............ 23 2.4 Statistiques du FDL IEEE802.11a (extrait de [35])....................... 24 3.1 Paramètres associés à chaque débit du IEEE802.11a...................... 47 3.2 Résumé des résultats de l implémentation du démonstrateur IEEE802.11a.......... 50 4.1 Jeu d instruction du CCC qui manipule les configurations stockées dans les slots de la mémoire interne aux unités de traitement............................. 71 4.2 Machines virtuelles candidates................................. 76 5.1 Les paramètres de régression linéaire du temps d exécution total pour les trois configurations 90 5.2 Taille des programmes de la 1 re expérimentation pour les trois configurations........ 91 5.3 Les temps d exécutions globaux de l application d estimation de l erreur CFO selon les différentes configurations du processeur.............................. 96 5.4 Taille des programmes de la 2 e expérimentation pour les trois configurations......... 97 6.1 Les paramètres principaux du prototype de système LTE.................... 110 6.2 Les débits des transmissions descendantes du prototype de système LTE........... 112 6.3 Composition du code exécutable de l application récepteur LTE et tailles mémoire associées 119 xiv

Glossaire 3GPP AGC API ASIC BPSK BSP CEA CFO CITI CORBA DMA DSL DSP DSR FAUST FDD FFT FPGA FPU FSM GIPS GMAC GOPS GPP HAL HARQ IP 3rd Generation Partnership Project Automatic Gain Control Application Programming Interface Application Specific Integrated Circuit Binary Phase-Shift Keying Board Support Package Commissariat à l Energie Atomique Carrier Frequency Offset Centre d Innovation en Télécommunications et Intégration de services Common Object Request Broker Architecture Direct Memory Access Domain Specific Language Digital Signal Processor Deferred Service Routine Flexible Architecture of Unified System for Telecom Frequency Division Duplex Fast Fourier Transform Field Programmable Gate Array Floating Point Unit Finite State Machine Giga Instructions Per Second Giga Multiply ACcumulate Giga Operations Per Second General Purpose Processor Hardware Abstraction Layer Hybrid Automatic Repeat Request Intellectual Property xv

Glossaire ISR JIT JTRS LISAN LTE LTS MIMO MMU MVR NoC OFDM PLDL POSIX PP PRB QAM QPSK rkpn RL RTL SCA SDF SIMD SME SoC STS TDD TLM TTI VHDL VLIW VM Interrupt Service Routine Just In Time Joint Tactical Radio Systems Laboratoire d Intégration Silicium des Architectures Numériques Long Term Evolution Long Training Sequence Multiple-Input Multiple-Output Memory Management Unit Machine Virtuelle Radio Network on Chip Orthogonal Frequency Division Multiplexing Physical Layer Description Language Portable Operating System Interface for UniX Programmable Pipe Physical Resource Block Quadrature Amplitude Modulation Quadrature Phase-Shift Keying Reconfigurable Kahn Process Network Radio Logicielle Register Transfer Level Software Communication Architecture Synchronous Data Flow Single Instruction Multiple Data Smart Memory Engine System on Chip Short Training Sequence Time Division Duplex Transaction-Level Modeling Transmission Time Interval Very high speed integrated circuit Hardware Description Language Very Large Instruction Word Virtual Machine xvi

1 CHAPITRE Introduction Sommaire 1.1 Introduction Générale................................... 3 1.2 Contexte radio logicielle.................................. 3 1.3 Problématiques de la thèse................................ 5 1.4 Motivations et contributions de la thèse......................... 7 1.5 Organisation du manuscrit................................ 8 2

1.1 Introduction Générale 1.1 Introduction Générale Ce mémoire de thèse est intitulé «machine virtuelle pour la radio logicielle». Il résume mes travaux réalisés durant les trois années de thèse à travers deux laboratoires de recherche : le Centre d Innovation en Télécommunications et Intégration de services (CITI) de l INSA de Lyon et ses équipes SWING et AMA- ZONES affiliées à l INRIA, et le laboratoire d Intégration Silicium des Architectures Numériques (LISAN) du CEA de Grenoble. Cette collaboration entre les deux laboratoires a permis de réunir des compétences logicielles (machine virtuelle, compilation, programmation des systèmes embarqués) et des compétences matérielles et de traitement du signal (définition d architecture numériques pour les systèmes de télécommunication) qui sont les domaines traités dans cette thèse. Le sujet de cette thèse se situe dans un contexte de radio logicielle (RL)[1]. On peut définir brièvement cette technologie comme étant la réalisation en logiciel des fonctionnalités de traitement du signal nécessaires à la radio. Celles-ci étaient réalisées auparavant par des circuits dédiés à un seul standard. Le logiciel permet plus de flexibilité par rapport à un matériel figé. Nous présentons dans la section 1.2 une synthèse des éléments clefs de cette technologie et les intérêts à la fois économiques et stratégiques qu elle représente pour les acteurs du marché des télécommunications : opérateurs de télécommunication et industriels d équipements radios. La première étape dans cette thèse a été d explorer les différentes problématiques de la RL à travers une étude critique de l état de l art. Appliquer les meilleurs concepts du domaine logiciel tels que la réutilisation, la modularité, la portabilité, la spécification par modélisation et le passage automatique à l implémentation sur des plateformes d exécution matérielles sont les principaux axes de recherches de la RL étudiés. Ainsi j ai constaté que la réalisation d une application radio, appelée aussi forme d onde, nécessite le passage par un cycle de développement complexe qui exige des compétences multi disciplinaires (logiciel embarqué, architectures numériques et traitement du signal). Réduire la complexité de réalisation des applications radios et augmenter leur portabilité sont les objectifs principaux auxquels cette thèse contribue à amener des solutions. Dans la section 1.3, je présente les problématiques majeures de la radio logicielle à savoir la reconfigurabilité et la portabilité des applications radios et comment le concept proposé de «machine virtuelle radio» (MVR) permet d apporter des solutions à celles-ci. Dans la section 1.4 de ce chapitre nous présentons un aperçu des contributions de cette thèse. Cellesci consistent principalement à la définition des principes fondamentaux sous-jacents au concept de MVR qui seront détaillés tout le long de ce manuscrit : d abord, nous expliquons le mode de fonctionnement de la MVR. Puis, nous décrivons notre proposition de modèle de programmation et de modèle d exécution adaptés au contexte radio. Nous présentons par la suite notre implémentation de la MVR sur un circuit existant de radio logicielle et enfin, nous détaillons l ensemble des expérimentations réalisées nous permettant d évaluer le concept et ses perspectives d utilisation. Enfin, dans la section 1.5, nous présentons les différents chapitres qui constituent ce mémoire. 1.2 Contexte radio logicielle La diversité des besoins en services de télécommunication fait aujourd hui que les équipements mobiles doivent supporter un ensemble croissant de standards de communication. Cette diversité peut se traduire par les nouvelles applications que doivent supporter ces équipements. Celles-ci doivent être capable de transmettre et recevoir en plus de la voix, des données, des images, des flux vidéos numériques, etc. Ces applications ont ainsi différents besoins en terme de débit de transmission et de latence. L idée de la radio logicielle (RL) est de concevoir un système de communication universel permettant 3

1.2 Contexte radio logicielle d être reconfiguré, paramétré ou reprogrammé pour supporter différents standards de télécommunication. Par conséquent, un seul circuit universel serait suffisant pour remplacer la multitude de circuits correspondants aux différents standards radios à supporter par l équipement de télécommunication. L origine de la RL remonte aux années 70 avec les radios militaires définies par le département américain de la défense (DoD). A cette époque on a décrit une radio VLF (Very Low Frequency) qui utilise un convertisseur analogique numérique et un processeur 8085 [2]. Cependant le terme «radio logicielle» n est apparu pour la première fois qu au début des années 90 par Joseph Mitola [1] qui présenta une architecture RL idéale et expliqua les défis technologiques à surmonter pour l atteindre. Le JTRS (Joint Tactical Radio Systems) est un programme militaire du DoD qui a pour objectif la définition de radios flexibles et interopérables. Ce projet a permis de définir un standard pour la réalisation de radios en logiciel appelé SCA (Software Communication Architecture) [3]. Ce standard est basé sur l utilisation de l intergiciel CORBA [4] et du système d exploitation POSIX pour faire coordonner différents modules logiciels de traitements radios. Il est ouvert pour permettre d attirer les industriels et échanger les expertises dans le domaine de la RL. Borne WiFi à accès public réseau personnel sans fil (WPAN) Bluetooth WLAN 802.11 Protocoles cellulaires GSM / UMTS Environnement pervasif de communications Radio logicielle Sans fil à accès fixe 802.16 Les standards du futur FIG. 1.1: Convergence des standards vers la radio logicielle Malgré les origines militaires de la RL, aujourd hui les industriels d équipements radios sont en train d investiguer cette piste et de repenser leurs architectures matérielles. En effet, les standards radios actuels ont tous des fonctionnalités de traitement du signal en communs et pourraient être implémentés par des accélérateurs matériels paramétrables. Toutefois, les spécificités de chaque standard seront réalisées en logiciel. La figure FIG. 1.1 illustre la convergence des standards actuels et ceux du futurs vers une réalisation en RL. En effet, la RL offre beaucoup d avantages : elle optimise la réalisation des radios multi-modes ceci en reconfigurant à chaque fois un même ensemble de composants fonctionnels au lieu de dupliquer la chaîne de traitement radio autant de fois que de modes opératoires. Elle permet aussi de réduire les coûts de production : en effet le cycle de développement logiciel est souvent beaucoup plus court que celui de réalisation d un nouveau circuit et surtout nécessite des phases de vérification et de validation moins complexes. De plus, la RL permet le prototypage rapide de nouveaux standards et de réduire le temps de mise sur le marché des nouveaux produits. D autre part elle facilite la mise à jour et la maintenance des radios et permet ainsi d augmenter la durée de vie des équipements de télécommunication. En résumé, la RL a des perspectives économiques intéressantes qui permettraient de créer de nouvelles opportunités de marché et la création de nouveaux services comme par exemple, l accès à des réseaux privés par téléchargement de code. 4

1.3 Problématiques de la thèse 1.3 Problématiques de la thèse La radio logicielle (RL) fait réunir différentes technologies pour sa réalisation. La conception d architectures matérielles de traitement dédiées à la RL, les technologies de traitement du signal en bande de base et les technologies RF (Radio Frequency) forment les trois principaux axes de recherche en RL. Les problématiques suscitées par la RL sont alors très variées, on peut citer par exemple : La définition d opérateurs fonctionnels reconfigurables de traitements radios (FFT, VITERBI, etc). La conception de processeurs dédiés à la RL. La spécification des formes d ondes et le passage automatique à l implémentation. Le partitionnement des applications radios et l adéquation forme d onde / architecture. Le déploiement et l ordonnancement des configurations des éléments de traitement dans un mode de calcul distribué. Dans cette thèse on s intéresse particulièrement aux problématiques liées à la réalisation des traitements en bande de base selon le concept de radio logicielle. YY RF ASIC Couche Physique Bande de base DSP + ASIC application + pile protocolaire (MAC, LINK, NET,..) GPP FIG. 1.2: Architecture classique d un émetteur-récepteur L architecture classique d un émetteur-récepteur est illustrée dans la figure FIG. 1.2. Il est constitué généralement de trois parties fondamentales qui sont : Une partie RF : en mode récepteur radio, son rôle consiste en l acquisition des signaux analogiques (les radios fréquences) à partir de l antenne. Cette partie réalise en plus des traitements analogiques, comme par exemple le filtrage, l échantillonnage ou le contrôle automatique de gain (AGC). La conversion des échantillons temporelles collectés en un flux numérique pour un traitement en bande de base est réalisée par des convertisseurs analogiques numériques. Une partie de traitement en bande de base appelée souvent «baseband» : réalise principalement les traitements de dé/modulation et dé/codage. La pile protocolaire de communication : c est un ensemble de couches logicielles pour la gestion des communications (couche MAC et supérieures). Dans un contexte de traitement en bande de base, la RL vise à remplacer le plus d éléments de calcul matériels (ASIC) par du logiciel (DSP). L idéal est d avoir un processeur «baseband» unique qui réalise tout le traitement en bande de base en logiciel. Cependant, la puissance de calcul des processeurs actuels n est pas en mesure de répondre aux contraintes temporelles des protocoles de couches physiques existants. Par conséquent, la réalisation de la radio logicielle nécessite aujourd hui une combinaison d éléments de calcul matériels et logiciels. L hétérogénéité des plateformes d exécution, le défaut de standardisation ainsi que les contraintes temps réel dures des applications radios sont les facteurs principaux de complexité de la RL. Le développement d une radio logicielle nécessite la connaissance des détails techniques de la plateforme d exécution et le portage d une application radio sur une autre plateforme revient à repasser par toutes les phases du cycle de développement. 5

1.3 Problématiques de la thèse Les objectifs majeurs de la radio logicielle sont illustrés dans la figure FIG. 1.3, ils consistent en : La reconfigurabilité des plateformes d exécution afin d avoir des radios multi-standards et multi-modes. Ceci revient à la facilité de reconfiguration des plateformes pour pouvoir supporter différents protocoles de couches physiques. La portabilité des formes d ondes afin d avoir des radios multi-plateformes. Une application radio peut ainsi être exécutée sur différentes plateformes sans un effort supplémentaire de développement. Forme d onde 1 Forme d onde 2 Forme d onde N Forme d onde 1 Forme d onde 2 Forme d onde N API radio API radio API radio Interface générique Abstraction 1 Abstraction 2 Platforme matérielle d exécution Platforme matérielle d exécution 1 Platforme matérielle d exécution 2 Radio multi-standards Radio multi-plateformes FIG. 1.3: Les objectifs majeurs de la radio logicielle Dans cette thèse on étudie l approche machine virtuelle pour la réalisation de la radio logicielle. «write once, run anywhere» a été la clé de succès du langage de programmation Java [5]. Ce slogan a été attribué par SunMicrosystems pour illustrer les avantages du langage Java qui est indépendant de la plateforme cible du fait qu il utilise une machine virtuelle pour son exécution. Standard PHY1 Standard PHY1 Autre Standard PHY Reconfigurabilité Machine Virtuelle Radio Portabilité Platforme d exécution 1 Platforme d exécution 2 Autre Platforme d exécution FIG. 1.4: Proposition du concept de machine virtuelle pour la réalisation de la radio logicielle Comme le montre la figure FIG. 1.4, la «machine virtuelle radio» (MVR) est une couche d abstraction logicielle qui offre une interface commune de programmation pour les radios. Elle propose ainsi à son utilisateur une architecture radio virtuelle indépendante de l architecture matérielle hôte. Le rôle principal de la MVR est donc d interpréter les primitives de haut niveau d abstraction (api radio) sur les plateformes d exécution hôtes, évitant ainsi toute la complexité de manipulation de l interface physique au programmeur radio. Toutefois, la MVR aura certainement un coût supplémentaire en terme de puissance de calcul et de mémoire requise à son exécution, que doit supporter la plateforme d exécution hôte. 6

1.4 Motivations et contributions de la thèse 1.4 Motivations et contributions de la thèse La RL est un concept qui représente un intérêt particulier pour les industriels d équipements radios et les opérateurs de télécommunications. Ceci est du principalement aux nombreux avantages de la RL à savoir la réduction des coûts de production, la réduction du temps de mise sur le marché de nouveaux produits, le développement du marché des composants matérielles dédiés à la radio (composants sur étagère appelés aussi COTS), etc. Aujourd hui l unique standard pour la RL est le SCA du JTRS. Il a eu beaucoup de critiques et on pense déjà à d autres alternatives pour définir la RL. Dans [6], on évoque un conflit d intérêts entre les radios commerciales et les radios militaires qui n ont pas les mêmes objectifs et ne répondent pas aux mêmes contraintes alors que le standard du JTRS est gérée par le département de la défense américain (le DoD). Les objectifs majeurs de la radio logicielle étant la reconfigurabilité et la portabilité. L ensemble des intergiciels et des environnements d exécution logiciels proposés dans la littérature apportent une réponse partielle à ces problématiques de la RL qui consiste généralement à une reconfigurabilité statique (définie à l avance de l exécution) et une portabilité restreinte, avec des mécanismes lourds à mettre en œuvre (par exemple l usage de CORBA dans SCA) et qui souvent imposent des hypothèses restrictives sur les architectures d exécution. Dans cette thèse on s intéresse à l exploration du concept de «machine virtuelle radio» (MVR) proposé par Gudaitis et Mitola dans [7]. Les principes de ce concept répondent aux objectifs de la RL. Il est adapté à l isolation entre les aspects protocolaires (fonctionnalités radios) et les contraintes d implémentation. De plus il est compatible avec le modèle économique de la RL : il permet aux opérateurs de télécommunication de restreindre leurs efforts de déploiement et de maintenance à la mise en œuvre d un seul bytecode par protocole. Quant aux industriels d équipements radios ils n auront à maintenir qu un seul module avec des interfaces standardisés (que ce soit en matériel ou en logiciel) qui est la MVR, au lieu de maintenir différentes piles protocolaires à valider pour de multiples circuits de traitements radios. Dans cette thèse on propose des concepts qui régissent le fonctionnement de la MVR. Nous proposons principalement un modèle de programmation qui permet d exprimer les services des protocoles de couches physiques indépendamment de l architecture d exécution. Le modèle de programmation proposé est adapté à une architecture d exécution radio virtuelle. Nous expliquons par la suite, à travers des exemples pratiques le mode de fonctionnement de la MVR et montrons comment celle-ci réalise l adaptation du modèle de programmation à une architecture physique existante de radio logicielle. Pour réaliser les traitements en bande de base en RL selon notre modèle de programmation, la MVR doit être capable de : (i) Contrôler des flots de données à haut débit entre des opérateurs fonctionnels de traitement spécialisés avec peu de surcoût de latence. (ii) Réaliser les fonctions arithmétiques et logiques classiques d une manière efficace, puisque la MVR doit dans certains cas accéder au flot de données pour réaliser des calculs spécifiques nécessaires pour la configuration des opérateurs fonctionnels de traitement. Nous proposons dans cette thèse un dispositif logiciel / matériel permettant à la MVR d accéder au flot de données d une façon transparente. Ce dispositif que l on a appelé «programmable pipe» fournit une abstraction qui cache la complexité de synchronisation avec le matériel afin d interagir sur le flot de données. Enfin, dans cette thèse on fournit aussi une qualification et une évaluation des facteurs de surcoûts de la MVR pour lesquels nous proposons des pistes d optimisations. Celles-ci devraient permettre de réduire les différents surcoûts afin d atteindre des performances raisonnables permettant de réaliser les services des protocoles de couches physiques existants. 7

1.5 Organisation du manuscrit 1.5 Organisation du manuscrit Ce document est organisé en sept chapitres qui correspondent aux différentes phases du déroulement de la thèse. Le premier chapitre est la présente introduction. Dans le second chapitre on présente une étude de l état de l art en ce concerne la réalisation de la RL. Nous exposons d abord les différentes classes de plateformes matérielles d exécution pour la RL et expliquons à travers une étude de cas la complexité de programmation de celles-ci. Nous étudions aussi l ensemble des techniques de spécification et de modélisation des formes d ondes qui sont proposés dans la littérature. Nous présentons par la suite quelques environnements d exécution de la RL et on s intéressera plus particulièrement à la proposition d environnement de type machine virtuelle. Enfin nous montrons les limites des approches existantes et présentons les questions ouvertes de recherches auxquelles nous essayons d apporter des réponses dans la suite de ce manuscrit. Le troisième chapitre étale l ensemble des propositions liées au concept de la MVR. Nous présentons principalement un modèle de programmation ayant des propriétés adaptées aux caractéristiques des applications radios. À ce modèle nous associons un modèle d exécution qui est une abstraction de l architecture d exécution radio virtuelle. Par la suite, nous proposons une extension de langage spécifique à la programmation radio et qui est conforme au modèle de programmation proposé. Enfin nous proposons un nouveau dispositif logiciel / matériel que l on a appelé «programmable pipe» permettant à la MVR de réaliser d une façon simple et optimisée des traitements spécifiques programmés en langage de la machine virtuelle. Le quatrième chapitre décrit l implémentation d une machine virtuelle radio sur MAGALI qui est un circuit existant de radio logicielle. Nous présentons d abord l environnement de développement et de simulation associé au circuit. Puis, nous expliquons le processus de développement classique d application radio sur cette plateforme. Ensuite, nous décrivons en détail comment on a réalisé notre implémentation de la MVR et son intégration à l infrastructure logicielle existante. Enfin nous exposons une proposition d implémentation du dispositif «programmable pipe». Dans le cinquième chapitre on présente une étude des facteurs de surcoûts de la MVR ainsi qu une évaluation analytique et expérimentale de ceux-ci. A travers deux expérimentations nous évaluons le surcoût de l adaptation de notre modèle de programmation aux caractéristiques de l architecture cible et aussi le surcoût d interprétation lié à la machine virtuelle utilisée. Nous proposons ensuite des techniques d optimisation qui devraient permettre d atteindre des performances proches de celles des applications implantées en natif. Le sixième chapitre décrit une étude de cas d implémentation d un protocole de couche physique de quatrième génération (3GP/LTE) par le concept de MVR. Nous présentons d abord une implémentation optimisée réalisée par le laboratoire LISAN du CEA-LETI sur le circuit MAGALI. Puis nous expliquons notre conception de l application pour une implantation faisant usage de la MVR tout en opposant celle-ci avec la conception de l implantation native. Enfin nous présentons les résultats de notre implantation et analysons les perspectives d usage de la MVR pour des protocoles existants en prenant en compte leurs contraintes temps réel. Enfin, dans le septième chapitre on conclut cette thèse et on présente les nouvelles problématiques et les perspectives qui découlent des travaux de recherche présentés dans ce manuscrit. 8

2 CHAPITRE État de l art Sommaire Introduction........................................... 11 2.1 Plateformes matérielles pour la radio logicielle..................... 11 2.1.1 Aperçu des plateformes de radio logicielle existantes............... 12 2.1.2 Cycle de développement des radios logicielles.................. 14 2.2 Spécification des formes d ondes............................. 16 2.2.1 Modélisation des formes d ondes......................... 17 2.2.2 Langages de description des formes d ondes.................... 18 2.3 Architectures logicielles et environnements d exécutions................ 27 2.3.1 Architecture SCA (Software Communication Architecture)............ 27 2.3.2 Environnement d exécution radio logicielle de l UPC............... 30 2.4 Les radios virtuelles.................................... 31 2.4.1 Proposition de Gudaitis et Mitola......................... 31 2.4.2 Implémentations propriétaires........................... 32 Conclusion............................................ 33 10

2.1 Plateformes matérielles pour la radio logicielle Introduction Dans ce chapitre on présente les travaux antérieurs en ce qui concerne la réalisation de la radio logicielle. On étudiera d abord comment sont implémentées les formes d ondes sur les plateformes matérielles existantes. Puis on présente l approche d implémentation par le concept de radio virtuelle, laquelle fera l objet d une étude approfondie dans le reste de ce manuscrit. La machine virtuelle radio, étant un environnement virtuel d exécution, elle repose sur un environnement d exécution physique : la plateforme matérielle de radio logicielle. Dans la section 2.1, on s intéressera aux architectures de ces plateformes. Nous analysons les éléments clefs de conception de celles-ci et montrons comment elle sont programmées. Dans la section 2.2, on présentera les travaux antérieurs réalisés autour des techniques de spécification des formes d ondes. Nous examinerons particulièrement l approche de spécification par les langages de description des formes d ondes. Cette approche est souvent utilisée dans les projets de recherche les plus significatifs dans le domaine de la radio logicielle. Les environnements logiciels d exécution et d exploitation des plateformes matérielles seront détaillés dans la section 2.3. Ces environnements proposent généralement des cadres de travail (framework) logiciels permettant de réaliser des formes d ondes sur des plateformes spécifiques. Un des objectifs de cette thèse étant d explorer l approche de machine virtuelle radio pour la réalisation des formes d ondes d une façon portable. On présentera dans la section 2.4 l état de l art concernant cette approche en soulignant les problématiques qui restent encore ouvertes à la recherche. 2.1 Plateformes matérielles pour la radio logicielle A la différence d un ordinateur, où on connaît avec précision les différents composants et comment ceuxci sont intégrés, l architecture matérielle pour la radio logicielle n est pas encore standardisée. Les plateformes matérielles pour la radio logicielle ont des architectures complexes. Elles sont généralement constituées d unités de traitement dynamiquement reconfigurables, avec des interconnexions rapides permettant de connecter celles-ci selon n importe quelle séquence. Elles sont constituées aussi d éléments de mémorisation agissant comme des sources ou des puits de données dans la chaîne de traitement radio, comme des tampons de stockage intermédiaires ou des dépôts de configurations (microcode et exécutables). Les plateformes de radio logicielle sont généralement hétérogènes : elle sont composées d unités de traitement matérielles et logicielles. Par le terme «unité logicielle» on fait référence aux unités de traitement programmables, par exemple les processeurs de traitement du signal appelés communément DSP (Digital Signal Processor), les processeurs à usage général ou GPP (General Purpose Processor), les microcontrôleurs, etc. Une unité de traitement matérielle appelée par la suite IP (Intellectual Property), est un composant câblé, dédié pour réaliser une ou un ensemble de fonctionnalités particulières dans la chaîne de traitement radio. Elle peut être implémentée par un ASIC (Application Specific Integrated Circuit), un FPGA (Field Programmble Gate Array) configuré ou tout autre circuit électronique qui implémente un traitement radio spécifique. La radio logicielle est un concept qui vise à réaliser le plus possible de fonctionnalités radios en logiciel. Réaliser la totalité des fonctionnalités de la couche physique en logiciel sur processeurs programmables n est pas aujourd hui possible. Cela est dû essentiellement à la puissance de traitement des processeurs 11

2.1 Plateformes matérielles pour la radio logicielle (a) Plateforme SFF SDR de Lyrtech (b) Carte USRP (GNU radio) (c) Système sur puce PicoArray FIG. 2.1: Plateformes radios logicielles actuels, qui n est pas encore suffisante pour réaliser les fonctionnalités requises par les protocoles existants, et leur consommation d énergie non adaptée aux équipements mobiles. Par exemple, l algorithme d un turbo-décodeur peut nécessiter une puissance de traitement atteignant les 150 GOPS dans les protocoles de quatrième génération. De plus, la réalisation des protocoles du futur, voire ceux qui sont en cours de conception, exige de plus en plus de puissance de traitement. En effet, les protocoles de télécommunication de quatrième génération doivent répondre à des spécifications de débit très élevé approchant le débit des réseaux filaires actuels pour permettre de supporter des services internet comme la visioconférence avec une haute résolution d images. Par exemple, le protocole 3GPP LTE peut atteindre des débits de 300 Mbps. La radio logicielle nécessitera toujours du matériel pour sa réalisation, du moins les processeurs de traitement du signal et les éléments analogiques de traitement des radio-fréquences. Le logiciel embarqué dans les plateformes radio servira ainsi à implémenter des fonctionnalités sur les processeurs présents et à contrôler les unités de traitement matérielles. La conception des plateformes matérielles pour la radio logicielle pose un réel défit pour les architectes des systèmes numériques. Le compromis flexibilité/performance du partitionnement logiciel/matériel de telles plateformes est difficile à décider. Un partitionnement optimal reste une question ouverte de recherche. Les plateformes matérielles de radio logicielle existantes sont pour la plupart conçues dès le départ pour pouvoir supporter une famille de protocoles existants ou en cours de spécification. Dans la littérature, on parle souvent de démonstrateur radio logicielle [8]. En effet la plupart des plateformes matérielles sont des plateformes expérimentales. Elles sont généralement issues des laboratoires de recherche publics ou privés, des industriels d équipements et des opérateurs de télécommunication. Dans ce qui suit, on présente un aperçu des plateformes matérielles existantes pour la radio logicielle. Ensuite, on expliquera comment celles-ci sont programmées. 2.1.1 Aperçu des plateformes de radio logicielle existantes Dans cette partie nous présentons brièvement les plateformes matérielles radios logicielles les plus connues. Notons que nous considérons comme plateforme matérielle de radio logicielle, tout système intégrant des composants programmables et/ou reconfigurables pour la réalisation de traitements radio. Dans l état de l art, on trouve d une part, des plateformes matérielles qui implémentent des radios complètes : constituées d un ensemble de cartes électroniques dédiées aux traitements en bande de base et de circuits analogiques agissant sur les radio-fréquences en provenance des antennes (voir figure 2.1 (a)). D autre part, on trouve des systèmes sur puce (System on Chip) capables d être programmé pour réaliser une partie ou l intégralité des traitements en bande de base (voir figure 2.1 (c)). 12

2.1 Plateformes matérielles pour la radio logicielle Nous proposons une classification de ces plateformes en deux catégories : 1. Plateformes principalement logicielles «DSP centric». 2. Plateformes hétérogènes. Dans ce qui suit nous détaillons chacune des deux catégories. Plateformes principalement logicielles «DSP centric» Les plateformes de cette catégorie sont hautement flexibles et permettent de définir des modules de traitement du signal totalement en logiciel. Une multitude d entreprises (Sandbridge, picochip, Fujitsu, Icera, Infineon, NXP, etc.) proposent des circuits intégrés basés sur les DSP. on cite quelques exemples typiques : Le processeur picoarray [9] de picochip : Ce circuit a une architecture qui intègre des centaines de petits DSP. PicoArray peut être programmé en ANSI C avec un environnement de développement dédié. La performance globale de traitement peut atteindre les 200 GIPS et 30 GMAC à une fréquence de 160 MHz. Ce circuit associe quelques IPs (FFT, décodeurs turbocodes,... ) et est capable d implémenter en logiciel un modem WCDMA complet. X-GOLD TM SDR-20 de Infineon technologies : est un processeur programmable de traitement du signal en bande de base pour des mobiles multi standard. Infineon fournit des solutions matérielles / logicielles qui permettent de supporter les protocoles suivants : GSM, GPRS, EDGE, W-CDMA, HSPDA, HSUPA, LTE, 802.11a/b/g/n, DVB-T/H. Cette plate-forme inclut aussi quelques accélérateurs matériels pour les algorithmes nécessitant une puissance élevée de calcul. EVP (Embedded Vector Processor) [10] de NXP : cette architecture est capable de supporter les différents modes du protocole LTE avec une conformance complète au draft de la révision 8 du standard 3GPP. On trouve aussi des travaux issus des laboratoires de recherche sur des architectures logicielles pour la radio : Dans [11], Lin et al. proposent un système de DSP qui consiste en un contrôleur et quatre éléments de traitement SIMD (Single Instruction Multiple Data). Ces processeurs ont la particularité de réaliser efficacement des calculs vectoriels très récurrents dans les algorithmes de traitement du signal. Cette architecture réalise deux chaînes de traitement très différentes : le 802.11a et le W-CDMA. Ceci, en respectant les caractéristiques de puissance et d énergie de ces protocoles. Tan et al. expérimentent dans [12] une approche originale pour la réalisation des traitements en bande de base sur des processeurs à usage général d une plateforme PC. Ils réalisent les couches physiques 802.11a/b et g entièrement en logiciel. Afin d atteindre les débits requis par le protocole, ils utilisent intensivement les dispositifs des processeurs multi-cœurs actuels. Il convient de mentionner qu un nombre important de plateformes radios logicielles «DSP-centric» sont mentionnées dans la littérature. Certes, elles sont hautement flexibles cependant elles sont limitées en terme de performance (rapidité de traitement et consommation d énergie) comparées à des plateformes intégrant des accélérateurs matériels dédiés. Plateformes hétérogènes Ces plateformes sont essentiellement composées d unités de traitement matérielles dédiées (IP). Un processeur est souvent nécessaire pour le contrôle des opérateurs matériels. Les plateformes expérimentales contiennent un ou plusieurs FPGA pour permettre l implémentation et l expérimentation des algorithmes récents de traitement de signal. Dans une moindre mesure, des DSP sont utilisés pour implémenter des 13

2.1 Plateformes matérielles pour la radio logicielle fonctionnalités spécifiques à certains standards. Généralement, ces fonctionnalités ne nécessitent pas une puissance de calcul élevée. Voici quelques exemples de plateformes hétérogènes : Small Form Factor (SFF SDR) Development Platform de Lyrtech : Cette carte embarque un DSP et un FPGA pour le traitement en bande de base. Ce dernier est connecté à une partie RF (Radio Frequency). Un environnement de développement dédié est fournit avec cette plateforme. Universal Software Radio Peripheral (USRP, voir FIG.2.1(b)) : est une plateforme matérielle conçue pour le projet GNU Radio [13]. Cette plateforme se connecte à un ordinateur à travers une interface USB. Kansas University Agile Radio (KUAR) platform [14] : est une plateforme radio logicielle expérimentale qui inclut un processeur Pentium M cadencé à 1.4GHz avec un 1GB de RAM et un FPGA Xilinx Virtex2. La carte se connecte un pc à travers, soit une interface gigabit Ethernet, soit un lien PCI-express. Dans tous les cas de plateformes hétérogènes, nous constatons la présence d un processeur central pour le contrôle et la configuration des IP qui constituent ces plateformes. 2.1.2 Cycle de développement des radios logicielles Une application radio est complexe à mettre en œuvre par rapport à une application logicielle dans un environnement PC. Elle nécessite un partitionnement judicieux des différents modules fonctionnels sur les différentes unités de traitement pour répondre essentiellement aux contraintes temps réel et de débit de l application. Il est souvent nécessaire de configurer préalablement les unités matérielles pour réaliser la fonctionnalité radio attendue (micro-programmes, initialisations de registres internes,... ). Notons aussi qu il faudrait réaliser un programme de contrôle pour piloter les unités de traitements de la plateforme ainsi que les communications entre celles-ci. FIG. 2.2: Flot classique de conception de systèmes Dans [15], Ahmadian et al. expliquent que le cycle de développement traditionnel d un système représenté dans FIG. 2.2 n est plus valable pour réaliser des applications complexes de radio logicielle. Cette méthodologie classique repose sur une spécification initiale des différentes fonctionnalités, rédigée par les ingénieurs concepteurs du système. Plusieurs cas peuvent se présenter : Les ingénieurs concepteurs peuvent ignorer des spécificités de la plateforme d exécution qui rend leurs spécifications non efficaces ou non adaptées. Les développeurs peuvent mal comprendre les idées contenues dans les spécifications. Les tests peuvent être erronés. Le processus de développement est par conséquent très lent et nécessite un effort considérable de test et de vérification. Les auteurs de [15], proposent alors d utiliser l approche de conception dirigée par les modèles (voir FIG.2.3). Avec cette méthode les systèmes complexes sont réalisés en utilisant des modèles mathématiques qui représentent les composants du système et leurs interactions. Ces modèles permettent à la fois de concevoir les différentes fonctionnalités du système, de réaliser des simulations, d analyser sa stabilité et appliquer 14

2.1 Plateformes matérielles pour la radio logicielle FIG. 2.3: Étapes de la conception dirigée par les modèles des tests fonctionnels. En associant des générateurs de code aux outils de modélisation, on pourrait rapidement et d une façon automatique prototyper le système attendu. Enfin, ils appliquent cette méthodologie et réalisent en logiciel un modem FM 3 TR (Future Multi-Band, Multi-Waveform, Modular, Tactical Radio). Pour cela ils ont fait usage de : Simulink [16] comme outil de modélisation graphique. le logiciel SMT6050 de Sundance [17] qui s interface avec Real Time Workshop [18] de MathWorks pour générer le code à embarquer sur les DSP de Sundance. Haessig et al. proposent dans [19] un étude de cas d implémentation d une forme d onde appelée SAT- COM définie par le département de défense américain sous la spécification Mil-Std-188-165a. Cette radio a été réalisée sur une plateforme hétérogène et les développements ont été essentiellement réalisés sur des FPGA XILINX. L objectif de cette étude est de comparer deux approches de développement : une approche de conception RTL (Register Transfer Level) traditionnelle. une approche de conception dirigée par les modèles incluant une génération automatique de code. A travers cette étude, ils affirment que l approche de conception dirigée par les modèles est dix fois plus efficace que l approche traditionnelle. Ils justifient leurs affirmation à travers des comparaisons quantitatives du temps nécessaire pour le développement du système, la documentation des algorithmes, la conception du code, le debug, l implémentation matérielle et la vérification (voir TAB. 2.1 et TAB.2.2). Algorithm Module Design Modeling, VHDL Coding VHDL Code Hardware Notes Interface Definition Simulation Behavioural Behavioural Integration Specification / and Design Verfication and Documentation Verification Lab Testing Reed Solomon RS Encode 40 40 0 40 60 20 Integrate purchased IP Reed Solomon Decode 20 80 0 60 100 20 Integrate purchased IP Scrambler / Descrambler 1 1 0 1 6 3 Convolutional Encode 1 1 0 1 1 1 Viterbi Decode 8 8 0 8 16 24 Integrate in-house IP, development not shown Differential Encoder / Decoder 1 1 0 1 4 2 Interleaver / Deinterleaver 40 16 0 16 36 60 PSK modulator ( 2,4,8) 5 5 0 4 3 3 RS frame Sync 4 6 0 4 6 4 TOTALS : 120 158 0 135 232 137 782 Proceeding of the SDR 05 Technical Conference and Product Exposition. Copyright c 2005 SDR Forum. All Rights Reserved TAB. 2.1: Temps de développement (homme heures) - Approche traditionnelle (extrait de [19]) Dans [15, 19, 20, 21, 22], on s accorde sur l idée qu une approche de conception basée sur la modélisation est adéquate pour la réalisation de systèmes radios logicielles. Ceci devrait augmenter la productivité et éviter les erreurs de spécification dès les premières phases du cycle de développement. Cette approche 15

2.2 Spécification des formes d ondes Algorithm Module Design Modeling, VHDL Coding VHDL Code Hardware Notes Interface Definition Simulation Behavioural Behavioural Integration Specification / and Design Verfication and Documentation Verification Lab Testing Reed Solomon RS Encode 1 0.25 2 0 0 * Integrate Xilinx Core Reed Solomon Decode 1 0.5 3 0 0 * Integrate Xilinx Core Scrambler / Descrambler 0 0.25 3 0 0 * Convolutional Encode 0 0.25 1.5 0 0 * Viterbi Decode 0 0.5 2 0 0 * Integrate Xilinx Core Differential Encoder / Decoder 0 0.25 1 0 0 * Interleaver / Deinterleaver 0 0.5 2 0 0 * Integrate Xilinx Core PSK modulator ( 2,4,8) 1 0.5 4 0 0 * RS frame Sync 1 4 16 0 0 * TOTALS : 4 7 34.5 0 0 * 45.5 Proceeding of the SDR 05 Technical Conference and Product Exposition. Copyright c 2005 SDR Forum. All Rights Reserved TAB. 2.2: Temps de développement (homme heures) - Approche rapide (extrait de [19]) permet aussi d automatiser la phase de codage et donc de réduire considérablement le temps de production de nouveaux systèmes. Cependant, on remarque que dans les exemples cités, les outils utilisés sont spécifiques à des plateformes matérielles précises et ne permettent pas de réutiliser les conceptions sur d autres plateformes. Le niveau d abstraction des modèles varie d un environnement de développement à un autre (niveau fonctionnel, niveau système,... ) et il est souvent dépendant de l architecture cible. Nous nous interrogeons maintenant sur «comment» est réalisée la modélisation des formes d ondes. Une modélisation idéale devrait permettre d abord d exprimer différentes formes d ondes (multi-applications) et de pouvoir être réalisée sur différentes plateformes radios logicielles (multi-plateformes). Dans la section suivante, nous exposons les techniques de modélisation des formes d ondes les plus utilisées. le passage de la modélisation à l implémentation est détaillé dans la section 2.3. 2.2 Spécification des formes d ondes Deux domaines d expertise sont requis pour la réalisation des systèmes de radio logicielle, à savoir : 1. Domaine du traitement de signal (définition des algorithmes à mettre en œuvre pour la réalisation de la forme d onde) Spécification de la forme d onde. 2. Domaine de la programmation de logiciel embarqué (implémentation, déploiement et configuration des plateformes matérielles) Implémentation de la forme d onde. La spécification est une étape cruciale dans le cycle de développement des systèmes radios. Le résultat de la spécification est traditionnellement un document qui précise les fonctionnalités à fournir par le système et aussi les contraintes auxquelles il devrait répondre. Ce document subit généralement une boucle de raffinement, jusqu à atteindre dans certains cas un niveau de détail pour être considéré comme une ébauche de conception. Ainsi la spécification peut prendre en compte les spécificités de la plateforme d exécution. Les spécifications des formes d ondes sont généralement difficiles à implémenter : des contraintes de temps réel, de consommation d énergie, de bande passante et de qualité du signal à produire doivent être respectées. Partir d une spécification pour implémenter une forme d onde est généralement un processus 16

2.2 Spécification des formes d ondes particulier à chaque plateforme d exécution. Pour faciliter l implémentation des formes d ondes sur différentes plateformes matérielles une méthode efficace de spécification devrait être identifiée. Dans la littérature on propose la modélisation comme approche de spécification pour les formes d ondes. Séparer la spécification de l implémentation permet de réutiliser celle-ci sur différentes plateformes. Dans ce qui suit, on étudiera les principes fondamentaux pour la spécification des formes d ondes. 2.2.1 Modélisation des formes d ondes Dans [23, 24] on montre que les spécification des formes d ondes par de larges documents textuels n est pas adaptée à la radio logicielle : cette approche est souvent source d ambiguïté et induit en des erreurs d interprétations. L usage de méthodes formelles utilisant des formulations mathématiques pour la spécification des formes d ondes permet de garantir la précision et la complétude. Cependant ce genre de spécifications est difficile à produire et peu de programmeurs sont capables de les comprendre. La modélisation est une approche qui se situe entre les deux extrêmes (textuels et mathématiques) et qui fournit une solution optimale au compromis de précision et de facilité d usage. Niveaux d abstraction La modélisation des formes d onde pourrait être réalisée selon différents niveaux d abstraction. Grassmann et al. expliquent dans [22] que les API (Application Programming Interface) fournies par les systèmes d exploitation dans un environnement PC sont considérées comme une abstraction de bas niveau qui restreint les alternatives possibles d architecture matérielles. Les couches d abstraction matérielles appelées HAL (Hardware Abstraction Layer), sont principalement utilisées et définies par les entreprises qui développent des systèmes d exploitation et sont souvent appelées BSP (Board Support Package). Ces API sont aussi très proches des caractéristiques du matériel et ne sont pas assez flexible pour être considérées comme une abstraction pour les plateformes de radio logicielle. Dans le même contexte, Yoo et al. introduisent dans [25] la notion de HAL comme la couche logicielle de premier niveau qui communique avec le matériel. Ils expliquent que cette couche est généralement dépendante de la plateforme cible. La définition d une HAL permet d établir un contrat permettant d avoir des processus de conception logiciel et matériel concurrents. Dans cet article les auteurs pensent qu il serait difficile et même impossible de définir un standard pour une HAL commune qui serait capable de supporter toutes les architectures et tous les composants matériels. Contrairement aux cartes électroniques conventionnelles (exemple carte mère PC), les systèmes multiarchitecturaux comme les systèmes sur puce, ne peuvent pas être gérés par un ensemble fixe d API. Une HAL commune consistera en la définition d un ensemble d API génériques issues des primitives communément définies dans les HAL du domaine applicatif (dans notre cas la radio) avec des mécanismes d extension. Modèle à composants adapté à la radio logicielle Moy et al. dans [26] proposent d utiliser une approche à base d opérateurs communs pour la réalisation d une radio logicielle multi-standards. Ces opérateurs seront fournis en logiciel (DSP) ou en matériel(fpga ou ASIC) sur les plateformes de radio logicielle. La paramétrisation des ces opérateurs permet une reconfiguration dynamique efficace de la plateforme radio. Des opérateurs communs à différents protocoles de communication radio ont étés identifiés dans la littérature : Exemples :FFT, décodeur VITERBI ou d autres 17

2.2 Spécification des formes d ondes de plus fine granularité comme l opérateur CORDIC. Dans [27, 28, 29, 30] sont proposées des architectures reconfigurables pour réaliser des opérateurs radio paramétrables. Cette approche nécessite l identification d un niveau de granularité optimal pour les opérations élémentaires de traitement du signal. Dans [26], Moy et al. présentent une modélisation mathématique des opérations en commun entre différents protocoles (par exemple : FFT, VITERBI, etc.) auxquels ils associent des coûts de composition. Ils montrent que plusieurs alternatives de composition sont possibles pour réaliser un protocole. Trouver les opérateurs communs optimaux revient à résoudre un problème d optimisation. Séparer la spécification de la plateforme matérielle cible Les auteurs de [31] présentent les avantages de séparer la description des formes d ondes de leurs implémentations sur des architectures matérielles spécifiques. ils proposent une approche qui repose sur deux étapes de spécifications séparées : une première spécification de l application à réaliser puis une spécification du matériel qui formera la plateforme d exécution. A partir de ces deux spécifications, un framework dédié appelé VRE (Virtual Radio Engine) génère les exécutables et les fichiers de configuration nécessaires pour réaliser l application radio sur la plateforme de spécification. Le langage VRE est un langage de description hiérarchique de niveau système, qui assemble des blocs fonctionnelles de traitements. la description d un bloc peut être raffinée jusqu à atteindre les primitives de plus bas niveaux. Celles-ci sont fournies par les bibliothèques associées au framework VRE. La spécification du matériel permet quand à elle au framework de savoir comment mapper les primitives de plus bas niveau sur le matériel et quel ordonnancement d exécution devrait être réalisé. Un des objectifs majeurs de la radio logicielle est de garantir la portabilité des formes d ondes sur différentes plateformes matérielles d exécution. Joint Tactical Radio System (JTRS) est un programme du département américain de la défense qui a défini une architecture logicielle ouverte appelée Software Communication Architecture (SCA) [3]. Celle-ci devrait permettre la séparation entre une application radio et le matériel d exécution sous-jacent. Cependant, ni les détails techniques pour la définition des formes d ondes, ni ceux pour la génération de code pour des plateformes matérielles spécifiques n ont étés évoqués dans les spécification de l architecture SCA. 2.2.2 Langages de description des formes d ondes La spécification des formes d ondes par des langages de description indépendants des plateformes cibles est la solution retenue dans la littérature. En effet, plusieurs projets de recherches ont commencé depuis l an 2000 pour la définition d un standard de définition de formes d ondes. Un des projets les plus significatifs est un programme de recherche militaire international appelé Advanced Transmission Language and Allocation of New Technology for International Communications and Proliferation of Allied Waveforms (ATLANTIC PAW) qui réunit les États unis, le Royaume-Uni, la France et l Allemagne et ayant pour objectif de mettre en œuvre un standard unique de spécification des formes d ondes. Chacun des partenaires du programme développera plus tard sa propre méthodologie pour porter une application radio sur ses plateformes matérielles. Dans ce qui suit, nous étudions différents projets pour standardiser la spécification des formes d ondes : Langage WDL (Waveform Description Language) est un langage de description de formes d ondes indépendant de la plateforme cible. Il a été définit principalement dans le programme Programmable Digital Radio (PDR) au Royaume-Uni. Dans [24], Willink définit le WDL comme une approche de description comportementale de système, réalisée par une décomposition hiérarchique mettant en œuvre principalement des machines d états et des diagrammes de blocs. 18

2.2 Spécification des formes d ondes Le WDL utilise une combinaison de principes de spécification définis dans différents domaines de recherche. Ce langage fait unifier les concepts graphiques des langages de diagrammes de blocs établis par des outils comme Ptolemy, COSSAP, SPW. Aussi, il réunit des concepts de machines d états hiérarchiques définis dans des outils comme ARGOS, SDL ou UML. Les diagrammes de blocs et les machines d états coexistent en faisant usage des concepts de langages de synchronisation comme Esterel. Les types de données manipulés sont définis par des langages orientés objets comme JAVA ou le C++. Willink fournit dans [24] un exemple qui illustre l usage du WDL pour la spécification d une partie de la forme d onde FM 3 TR. FIG. 2.4: Exemple de raffinement par décomposition d une entité La figure FIG.2.4(a) est une représentation graphique d une entité : module de transmission de données et de la voie selon le protocole FM 3 TR. Ce premier niveau d abstraction décrit les entrées/sorties du module. Un raffinement de cette abstraction par décomposition de cette entité est illustrée dans la figure FIG.2.4(b) : c est une machine d états qui qui met en œuvre différentes entités représentées par des diagrammes de blocs au sein de chaque état. La radio FM 3 TR agit en half-duplex. L état initial de l entité FSM est l état RX (réception) puis selon le cas : Si l entrée tx est activée alors le système passe à l état DATA_TX pour une transmission de données. Sinon, si l entrée voice_in est activée alors le système passe à l état VOICE_TX pour une transmission de voie. Enfin le système retourne à l état de réception dès qu il finit la phase de transmission. Les sous entités dans la figure FIG.2.4(b) ne sont pas encore totalement raffinées. Seul le premier niveau de décomposition est évoqué pour expliquer le formalisme WDL. A la différence de formalismes tels que UML, l ordonnancement dans la modélisation WDL est géré au sein de l entité. Chaque entité est responsable de son propre ordonnancement : des mécanisme de rendez- 19

2.2 Spécification des formes d ondes vous permettent de définir quand et comment l entité répond aux flux d entrées. Dans les diagrammes de collaboration d UML, l ordonnancement apparaît comme une annotation à prendre en compte par un ordonnanceur externe au diagramme. Ainsi, la décomposition en sous diagrammes n est pas possible en UML. En résumé, le WDL est un langage qui utilise une combinaison de plusieurs sémantiques pour exprimer les différentes facettes d abstraction des applications radios. Ce langage fait un usage particulier des diagrammes de blocs pour la description des fonctions à mettre en œvre et des machines d états pour exprimer les interactions entre ces blocs fonctionnels. L implémentation du WDL est réalisée par un raffinement successif d une description initiale et ce jusqu à atteindre un niveau de granularité assez concret fourni par un environnement de développement sous forme de bibliothèques logicielles / matérielles. On remarque que cette approche est orientée compilation : dans [24], on utilise le «WDL framework», un environnement dédié pour générer du code exécutable sur une plateforme matérielle particulière. La problématique de reconfiguration dynamique des blocs fonctionnels n a pas été abordée. Enfin, Willink ne fournit pas une preuve de son concept pour montrer comment implémenter un système radio à partir de sa description WDL. VANU RDL (Radio Description Language) est un langage de description radio, développé par VANU, Inc. Ce langage est conçu particulièrement pour améliorer la portabilité des formes d ondes. Chapin et al. présentent dans [32] les concepts fondamentaux du langage RDL. D abord le RDL sépare entre les fonctionnalités de traitement du signal et l ordonnancement de celles-ci : la partie de traitement de signal d une forme d onde est exprimée comme un graphe dont les nœuds sont les primitives de traitement du signal. Ces primitives incluent différents types de codeurs de convolution, de turbo-décodeurs, de filtres, etc. Une application radio décrite en RDL est un programme qui décrit l enchaînement des fonctionnalités de traitement de signal fournies sous formes de bibliothèques logicielles. Un interpréteur RDL est un environnement d exécution qui réalisera la forme d onde spécifiée. Cet interpréteur examine le graphe de description de la forme d onde et décide si des parties peuvent être réalisées par du matériel fournie par la plateforme d exécution. Dans ce cas il initialise les accélérateurs matériels relatifs aux fonctionnalités à implémenter. Dans l absence de support matériel pour une fonctionnalité, l interpréteur RDL assemble et configure des blocs logiciels prédéfinis. Le langage RDL définit deux éléments de bases : Modules : sont des opérateurs de traitement de signal qui forment les nœuds d un graphe. Assemblages (Assembly) : sont les graphes, constitués de modules et de sous graphes. Des notions de ports associés aux modules, de flux (streams) qui les interconnectent, et de canaux (channels) définissant le type de messages qui circulent dans les flux sont définis par le RDL. Un exemple d assemblage est illustré dans la figure FIG. 2.5. Un flux de données en provenance du module streamgen contient des données codées et d autres non codées. La fonction de cet assemblage est de décoder la partie codée de données par le module convdecoder et de la combiner au niveau de framegen avec la partie non codée. Cet assemblage fait intervenir trois modules. Chacun de ses modules peut être raffiné par une décomposition en d autres assemblage ou directement par une primitive fournie par le système d exécution. Dans la figure 2.6, on montre le flot de donnée associé à l assemblage de la figure FIG. 2.5. Une implémentation du protocole GSM a été réalisée en utilisant le RDL formant une preuve de concept. Le programme RDL de la couche physique du GSM fait usage de 36 différents modules et de 28 assemblages. La totalité du programme a nécessité 3190 lignes de codes RDL. Dans [33], Chapin et al. présentent des exemples d implémentation mettant en œuvre le langage RDL. Ils réalise les fonctionnalités d une station de base GSM totalement en logiciel et aussi les traitement en bande de base du HP ipaq PDA (un terminal mobile à ressources limitées). L architecture logicielle utilisée est illustrée dans la figure FIG.2.7. 20

2.2 Spécification des formes d ondes 1 module RxConvDecoder { p a r a m e t e r EncoderFormat f o r m a t ; 3 d a t a o u t GsmFrame o u t p u t ; d a t a i n GsmFrame i n p u t ; 5 } 7 assembly RxConvDecoderDef implements RxConvDecoder { 9 module ConvDecoder convdecoder ; module DecoderFrameGenerator framegen ; 11 module D e c o d e r S t r e a m G e n e r a t o r streamgen ; 13 / / d a t a f l o w s streamgen. m P r o t e c t e d O u t p u t > convdecoder. i n p u t ; 15 streamgen. munprotectedoutput > framegen. m U n p r o t e c t e d I n p u t ; streamgen. mheaderoutput > framegen. mheaderinput ; 17 convdecoder. o u t p u t > framegen. m P r o t e c t e d I n p u t ; 19 / / l i n k p o r t s framegen. moutput > o u t p u t ; 21 i n p u t > streamgen. minput ; } FIG. 2.5: Exemple d un assemblage RDL FIG. 2.6: Flot de données de l assemblage de la figure FIG. 2.5 Le concept de RDL permet d exprimer les couches physiques radios comme un assemblage de modules fonctionnels. Un programme radio écrit en RDL représente une machine d états qui contrôle l exécution de ces modules. La sémantique simpliste du langage RDL telle qu elle est décrite dans les publications de Chapin et al. ne permet de réaliser une reconfiguration dynamique des modules de traitement du signal. Par exemple, une reconfiguration avec des paramètres en provenance du flot de données. En plus, on ne retrouve pas dans leurs publications les détails de l environnement d exécution ni des blocs qui définissent son architecture. Par exemple : La boite Sprockit TM de la figure FIG.2.7 est décrite comme une couche intergicielle qui réalise les transferts de données, l intégration de modules et fournit une bibliothèque de fonctions radios. 21

2.2 Spécification des formes d ondes Flexible Control High Speed Data Portability Certification Ease of use RDL Description State machine UI Signal Processing Class libraries Reusable toolbox for new waveforms RDL Interpreter Sprockit TM Combine modularity and performance OS Linux or Other POSIX Hardware independance FIG. 2.7: Architecture logicielle pour l exécution du RDL (extrait de [33]) E 2 R FDL(Functional Description Language) E 2 R est l acronyme du projet de recherche européen End to End Reconfigurability qui vise à développer des architectures et des conceptions liées aux systèmes de communication reconfigurables pour le support de différents modes opérationnels. Burgess et al. ont étudié dans [34] le besoin de définition d un langage de configuration qui permettrait d unifier les spécifications des formes d ondes : Ils se sont principalement intéressés aux types de données que devrait manipuler un tel langage. Et Ils ont discuté l approche de formater les programmes de configuration selon le formalisme XML. Configuration Management Configuration Management Module Configuration Control Configuration Control Module Logical Device Driver Execution Environment Physical Device Driver Function Abstraction System Abstraction Hardware Abstraction Hardware Configurable Execution Module FIG. 2.8: Architecture de configuration et de contrôle des équipements radio E 2 R Le projet E 2 R définit une architecture logicielle pour les équipement radios appelée «E 2 R Configuration & Control architecture» (voir figure FIG.2.8). Cette architecture considère trois niveaux d abstractions : Abstraction fonctionnelle : elle est représentée par le «Configuration Management Module». Cette couche décide de la configuration à mettre en place. Elle interagit avec les couches réseaux de plus haut niveaux (MAC et supérieures). Abstraction système : Elle contrôle le processus de reconfiguration : ordonnance les configurations du matériel et utilise pour cela la couche drivers. Elle est représenté par le «Configuration Control Module» (CCM). Abstraction matérielle : est l abstraction de plus bas niveau. Elle interagit avec le matériel et est généralement constituée des drivers qui pilotent le matériel d exécution. 22

2.2 Spécification des formes d ondes Pour cette architecture, différents types de données ont été identifiés. Le tableau TAB. 2.3 (extrait de [34]) résume les principaux types de données pour un modem radio qui suit l architecture définie par E 2 R. Data Type Abstraction Target Form algorithm (a) functional software modem data-flow graph & RT constraints signal-process (b) functional software modem data-flow graph & RT constraints signal-process-parameters (c) functional signal-process list : parametervalue pairs spatial configuration (d) system software modem & list : parameterbaseband algorithm value pairs temporal configuration (e) system software modem & schedule : process baseband algorithm executions logical device driver (f) system hardware CCM binary executable Physical device driver (g) hardware execution environment binary executable µ-processor task (h) na µ-processor binary executble digital logic (i) na reconfigurable logic binary bitsream device implementation arguments (j) na task arguments, HW list : argument - value regisers pairs TAB. 2.3: Principaux types de données pour la configuration des modems radios Les types de données (a),(b) et (c) permettent de définir le graphe d exécution globale de l application radio. Ils sont indépendants de la plateforme cible et sont nécessaires à la configuration du CCM. Le type de donnée (d) permet de spécifier le partitionnement de l application sur les processeurs d exécution de la plateforme matérielle. Quand au type de donnée (e), il permet de définir l ordonnancement pour l exécution de chaque processus sur son processeur hôte. les type de données (f) et (g) sont spécifiques à la plateforme matérielle : ils permettent de configurer les dispositifs matériels. Dans [34], l approche de spécification des formes d ondes par le langage XML a été explorée. Cette approche n est pas nouvelle pour la spécification des formes d ondes : Plusieurs projets de reconfigurabilté IST(Information Society Technologies) utilisent XML. L architecture logicielle SCA du JTRS utilise aussi ce formalisme. Dans le projet E 2 R est définit le langage FDL (Functional Description Language). Celui-ci repose sur le formalisme XML. Un schéma XML a été identifié pour les descriptions fonctionnelles : c est le modèle de données du FDL. Les classes principales de données sont : process, channel et port. process définit un processus de traitement de signal et peut être décomposé en sous processus qui sont aussi de type process. Chaque process a des attributs qui définissent les contraintes temps réel (les délais) qui lui sont associés. channel représente un lien de communication entre deux processus. Un port est lié à une extrémité d un channel, il définit le type de données qui vont passer à travers lui. un exemple qui illustre l usage du FDL est présenté dans la figure FIG.2.9. Dans [35], Zhong et al. expérimentent le FDL en réalisant un émetteur récepteur IEEE802.11a. Une évaluation du surcoût de reconfiguration en utilisant le FDL est fournie dans le tableau TAB. 2.4. On remarque que les fichiers de description ont une faible taille pouvant être facilement stockés dans des systèmes embarqués ayant une mémoire réduite. Par contre le temps pour analyser ces fichiers est très 23

2.2 Spécification des formes d ondes <xml version="1.0" encoding="utf-8"> 2 < P r o c e s s ID=" 802.11 atxbaseband " x m l n s : x s i =" h t t p : / /www. w3. org / 2 0 0 1 / XMLSchema i n s t a n c e " 4 xsi:nonamespaceschemalocation =" AlgorithmSchema. xsd "> < d e a d l i n e u n i t s =" us ">10< / d e a d l i n e > 6 <! a l g o r i t h m c h a n n e l s > < subchannel name=" Ch1 " / > 8 < subchannel name=" Ch2 " / > <! i n t e r l e a v e r sub p r o c e s s > 10 < s u b P r o c e s s name=" I n t e r l e a v e "> < o u t p u t datatype =" frame " name=" I n t e r l e a v e O u t P o r t "> 12 < o u t p u t C h a n n e l r e f e r e n c e =" Ch1 " / > < / o u t p u t > 14 < / s u b P r o c e s s > <! mapper sub p r o c e s s > 16 < s u b P r o c e s s name=" Mapper "> < i n p u t datatype =" frame " name=" MapperInPort "> 18 < i n p u t C h a n n e l r e f e r e n c e =" Ch1 " / > < / i n p u t > 20 < o u t p u t datatype =" complex " name=" MapperOutPort "> < o u t p u t C h a n n e l r e f e r e n c e =" Ch2 " / > 22 < / o u t p u t > < / s u b P r o c e s s > 24 <!... i f f t sub p r o c e s s n o t shown > < / P r o c e s s > FIG. 2.9: Extrait d un programme écrit en E 2 R FDL d un émetteur IEEE802.11a 802.11a XML Zipped Parsing time (s) Size Size (Kbytes) (Kbytes) Win Linux Nokia 770 Receiver 18.3 1.8 0.12 0.11 0.31 Transmitter 17.6 1.9 TAB. 2.4: Statistiques du FDL IEEE802.11a (extrait de [35]) lent par rapport au temps nécessaire au traitement d une trame IEEE802.11a (quelques microsecondes). L approche du FDL repose sur une configuration statique des modules de traitements. Pour chaque phase de traitement il faut réaliser une description du schéma de configuration adéquat par un fichier XML. Le langage XML est statique et n est pas adaptée pour la description de la dynamique de reconfiguration des protocoles de couches physiques radios. En plus les analyseurs existants du format XML sont dans la plupart très consommateurs de mémoire et leurs performances ne permettent pas une interprétation dynamique (durant l exécution) du contenu de la configuration. Langage SPEX est un langage de programmation pour la radio logicielle, conçu et développé par le Michigan university SDR (Sofwtare Defined Radio) group. Lin et al. propose dans [36] le langage SPEX pour spécifier les formes d ondes d une façon abstraite qui n est pas totalement indépendante de la plateforme cible. Ce langage est plutôt dédié pour une exécution sur une famille de DSP particuliers qui sont SIMD. 24

2.2 Spécification des formes d ondes Le langage SPEX repose sur une philosophie du paradigme «diviser pour régner» : il divise la description d une forme d onde selon trois facettes d abstractions : Kernel SPEX (voir figure FIG.2.10) : est un langage impératif qui supporte les opérations arithmétiques natives des DSP, et les opérations vectorielles de bases. Cette sémantique sert à définir l algorithme de traitement de signal (niveau opérateur, exemple : FFT) à implémenter sur un DSP. 1 t e m p l a t e < c l a s s T, TAPS, S> c l a s s FIR { 3 p r i v a t e : v e c t o r <T, TAPS> c o e f f ; 5 p u b l i c :... 7 k e r n e l run ( channel <T, S+TAPS 1> in, channel <T, S> &o u t ) 9 { v e c t o r <T, TAPS> v ; 11 f o r ( i = 0 ; i < S ; i ++) { v = i n ( i, i +TAPS 1); 13 o u t [ i ] = sum ( v c o e f f ) ; } 15 } } FIG. 2.10: Exemple de code Kernel SPEX (extrait de [36]) Stream SPEX (voir figure FIG.2.11) : est un langage dédié à la description des flots de données, permettant ainsi de spécifier les communications de données nécessaires entre les modules fonctionnels d un protocole. Synchronous SPEX (voir figure FIG. 2.12) : est un langage parallèle permettant de définir les contraintes temps réel pour l exécution du protocol à réaliser. Le langage SPEX définit des types de données particuliers qui ne sont pas proposés par les langages classiques de programmation de processeurs à usage général : SPEX inclut des types de données inspirés de SystemC permettant de spécifier des variables arithmétiques à point fixe, la précisions des données, etc. SPEX définit aussi des types de données inspirés de l outil Matlab pour la déclaration de vecteurs et de matrices. Les objets manipulés par le langage SPEX utilisent un mécanisme de passage de messages appelée : Channel. Ce sont des canaux de communication, implémentés par des méthodes au sens C++. Ils permettent d échanger des variables de type vecteurs de données. Pour garantir la cohérence des données échangées, dans le cas où les objets communicants s exécutent sur des processeurs différents, les Channels ne peuvent pas être à la fois en mode lecture et écriture. SPEX définit des mécanismes de synchronisation par l usage des objets Signal. Ces objets sont liés à la notion de mémoire partagée. Ils permettent d échanger des variables d une manière asynchrones et servent souvent pour l implémentation du contrôle global spécifié avec la sémantique «synchronous». En résumé, le langage SPEX permet : (i) avec sa sémantique kernel de définir un processus de traitement de signal pouvant être compilé et exécuté sur un DSP SIMD. (ii) avec sa sémantique stream de définir le flot de données à réaliser. (iii) avec sa sémantique synchronous d ordonnancer les opérateurs définis dans (i). Cette approche est purement logicielle. Elle est orientée compilation et le code généré est spécifique à une plateforme particulière. 25

2.2 Spécification des formes d ondes t e m p l a t e < s p e x _ t y p e T, S> 2 c l a s s DCH { 4 p r i v a t e :... 6 Rake <T, S> r a k e [ m a x _ r a k e _ f i n g e r s ] ; V i t e r b i <256,S> v i t e r b i ; 8 Combiner <T, S> combiner ; channel <T, S> ch1 [ m a x _ r a k e _ f i n g e r s ] ; 10 channel <T, S> ch2 ; p u b l i c : 12... s t r e a m run ( channel <T, S> ADC_in, channel <T, S> s e a r c h e r _ i n, 14 channel <T, S> & out_mac, s i g n a l < i n t > & done ) { f o r ( i n t i =0; i < n u m _ r a k e _ f i n g e r s ; i ++) 16 r a k e. run ( ADC_in, s e a r c h e r _ i n, ch1 [ i ] ) ; combiner. run ( ch1, ch2 ) ; 18 v i t e r b i. run ( ch2, out_mac ) ; b a r r i e r ; 20 done = t r u e ; } 22 } FIG. 2.11: Exemple de code Stream SPEX (extrait de [36]) c l a s s WCDMA{ 2... AdcFir < i n t 1 6, wcdma_frame > a d c f i r ; 4 DCH< i n t 1 6, wcdma_frame > dch ; Clock < s l o t, 15> f r a m e _ c l o c k ; 6 S i g n a l <bool > bch_done, dch_done ;... 8 s y n c h r o n o u s run ( ) { when ( c l o c k == 0){ 10 a d c f i r ( ch1 ) ; bch ( ch1, bch_done ) ; 12 c h a n _ e s t ( ch1, ch2, n u m _ f i n g e r s ) ; i f ( wcdma_data_mode ) 14 dch ( ch1, ch2, num_fingers, dch_done ) ; } 16 when ( c l o c k == b c h _ d e a d l i n e ) a s s e r t ( bch_done == t r u e ) ; 18 when ( c l o c k == d c h _ d e a d l i n e ) a s s e r t ( dch_done == t r u e ) ; 20 } } FIG. 2.12: Exemple de code Synchronous SPEX (extrait de [36]) 26

2.3 Architectures logicielles et environnements d exécutions 2.3 Architectures logicielles et environnements d exécutions L usage des intergiciels (middleware) dans les serveurs d applications d entreprises a eu beaucoup de succès ces dernières années. Les intergiciels définissent des interfaces standardisés permettant de faire communiquer des composants logiciels hétérogènes et distribués. Ils permettent aussi d isoler les services applicatifs de hauts niveau (couche métier) des détails techniques du système hôte (couche infrastructure). Exemple : accès aux bases de données, protocoles de communication réseau, etc. Les intergiciels sont des logiciels qui implémentent une abstraction intermédiaire entre les applications et les différents matériels d exécution. Leurs but est de faciliter le développement d application en masquant l hétérogénéité des systèmes d exécution sous-jacents. La radio logicielle est un domaine issue du monde du logiciel. Il a pour principe de tirer profit des meilleurs concepts et des bonnes pratiques déjà utilisés dans le domaine informatique. Beaucoup de recherches ont étés réalisées afin de définir des architectures logicielles spécifiques aux applications radios. Ces architectures ont pour rôle de structurer le développement des formes d ondes (définition d API) et de définir un modèle d exécution unifié indépendant du matériel d exécution. 2.3.1 Architecture SCA (Software Communication Architecture) L architecture SCA [3, 37] a été conçue initialement dans le programme militaire américain «Joint Tactical Radio Systems (JTRS)» pour le développement du concept de la radio logicielle. Elle est considérée comme un intergiciel ayant pour objectif l abstraction des plateformes matérielles pour l exécution des applications radios. En d autres termes, SCA unifie la reconfigurabilité et la programmation de différents matériels radios. SCA est à la fois un «framework», une architecture logicielle à base de composants, et un standard de spécification commun pour la radio logicielle. SCA est aujourd hui une architecture ouverte, elle reste certainement influencée par les radio militaires, mais est de plus en plus utilisée dans les applications radios commerciales et civiles. L objectif initial de cette architecture étant la reconfigurabilité des plateformes. Puis, elle s est adressée à la problématique de la portabilité des formes d ondes. Aujourd hui la portabilité est un sujet encore ouvert à la recherche : le JTRS vient de publier récemment un guide sur les bonnes pratiques pour améliorer la portabilité des formes d ondes [38]. Historique de SCA Le «wireless innovation Forum» appelé précédemment «SDR Forum» (SDRF) [39] est un organisme qui rassemble les recherches dans le domaine de la radio logicielle, s est associé avec le «Joint Program Office» (JPO) du JTRS pour l assister au développement de l architecture ouverte SCA pour la radio logicielle. La première spécification de SCA est ainsi apparue en 2000 avec la version 0.9. Aujourd hui SCA est à sa version 2.2.2 [3]. Une version 3.0 du SCA a été publié en 2004, cette spécification propose pour la première fois des approches et des concepts pour fournir la portabilité des applications radios. Cette version n est pas aujourd hui supportée par le JTRS et la communauté radio logicielle estime que celle-ci manque encore de plus d approfondissement pour qu elle puisse être appliquée efficacement. Éléments clés de l architecture SCA La spécification SCA définit principalement un environnement d exécution et d exploitation des ressources radios, appelé communément «Core Framework». Cet environnement d exécution a pour rôle la gestion, le déploiement, la configuration et le contrôle du système radio et des applications qui s exécutent sur celui-ci. 27

2.3 Architectures logicielles et environnements d exécutions Le JTRS a définit un ensemble d objectifs que l architecture SCA devrait permettre : Améliorer la reconfigurabilité et l interopérabilité. Réduire le coût de développement et de maintenance. Faciliter la mise à jour, et plus particulièrement l insertion de nouvelles fonctionnalités dans un système radio existant. Pour répondre à ces objectifs la spécification SCA a été structuré selon différents axes : Portabilité des formes d ondes sur les différentes implémentation de SCA. Développement des standards industriels existants pour réduire les coûts. Réutilisation des conceptions et des modules fonctionnels développés dans l industrie. Cette pratique est appelée réutilisation de composants pris sur étagère (commercial off-the-shelf ou COTS). Environnement d exploitation SCA est constitué essentiellement de trois éléments : «Core Framework (CF)», l intergiciel ORB(Object Request Broker) de CORBA, et d un système d exploitation temps réel. L environnement SCA spécifie les interfaces, les règles, les contraintes et les procédures qui doivent être suivie pour implémenter un système radio conforme à la spécification. Les composants de l architecture SCA sont illustrés dans la figure FIG. 2.13. Le «Core Framework» fournit un ensemble de services communs pour la définition des formes d ondes. C est la couche logicielle qui permet l installation, la configuration, la gestion et le contrôle des formes d ondes. Il fournit une abstraction du matériel réalisant les fonctionnalités de la couche physique. Enfin, il implémente un système de fichier, qui lui est nécessaire pour le stockage des informations de configuration (les configurations sont stockées sous la forme de fichiers XML). L ORB de CORBA est considéré comme un conduit logique par lequel les requêtes sur des objets transitent entre client et serveurs. Dans le contexte de l architecture SCA, l ORB de CORBA est utilisé pour faire communiquer les composants fonctionnels de haut niveau d abstraction qui sont déployés sur différents éléments de traitement matériels (DSP et FPGA). CORBA définit un ensemble de services sur les objets (appelé Common Object Services). Les composants SCA utilisent principalement les services suivants : Service de nommage : appelé «Naming service», permet à un composant de localiser un service (un autre composant) afin de communiquer avec lui. Service d évènements : appelé «Event service», permet à un composant de publier une information asynchrone sur un canal d évènement. Les composants qui attendent cette information doivent au préalable s enregistrer sur ce canal. Service de log : enregistre des traces d exécution relatives à un composant particulier. Service de fichier : permet à un composant de se configurer depuis des fichiers XML qui contiennent les paramètres fonctionnels et de contrôle. Tout deux, le «Core Framework» et l ORB reposent sur les services de bas niveau d abstraction du système d exploitation. SCA ne fait pas de restriction sur le système d exploitation à utiliser. Généralement un système d exploitation POSIX est recommandé. Le «framework» SCA est l architecture radio logicielle la plus populaire. La plupart des entreprises qui développent des intergiciels pour la radio logicielle suivent cet unique standard. On cite Prismtech [40], Zeligsoft[41] et OIS[42] qui implémentent le framework SCA sur différentes plateformes matérielles. En résumé, l architecture SCA repose principalement sur l intergiciel CORBA. Il permet d abstraire l application radio en des composants logiciels déployés sur une architecture distribuée. Il est évident que CORBA a un surcoût de performance important et qu il n est pas adapté au systèmes temps réel. Les entreprises qui supportent le développent de SCA proposent des implémentations réduites de CORBA appelées souvent «lightweight, real time ou embedded» CORBA. De plus cette architecture a été initialement pensée pour les standards militaires n ayant pas les mêmes contraintes des standards commerciaux [43]. 28

29 Applications RF Environnement d exploitation SCA API PHY Composants modem CORBA ORB services (middleware) Composants Liaison Core Framework IDL (Interface Description Language) = Bus logique de communication logiciel Système d exploitation Couche drivers, BSP(Board Support Package) Matériel X Services du Core Framework Composants réseaux Composants sécurité API MAC API liaison API réseau API de sécurité CORBA ORB services (middleware) COTS (composant sur étagère) Core Framework (CF) FIG. 2.13: Architecture SCA d un système radio Système d exploitation Couche drivers, BSP(Board Support Package) Matériel Y Services du Core Framework 2.3 Architectures logicielles et environnements d exécutions

2.3 Architectures logicielles et environnements d exécutions 2.3.2 Environnement d exécution radio logicielle de l UPC Dans cette partie, on s intéressera aux études réalisées à l université polytechnique de catalogne (UPC) pour la conception d intergiciels dédiés à la radio logicielle : Gelonch et al de l UPC, proposent dans [44] le framework P-HAL (Platform and Hardware Abstraction Layer) ayant pour objectif de définir un environnement commun de développement et de déploiement d applications radios indépendamment de la plateforme cible. Le concept P-HAL repose sur l abstraction des plateformes matérielles radios par des services fonctionnelles. Ceux-ci se résument en trois classes de services permettant : Le contrôle temps réel de l exécution des processus radios. L échange de données entre éléments de traitements (dans un environnement distribué). Le paramétrage et la supervision des modules fonctionnels. L intergiciel P-HAL implémente une couche logicielle sur les différentes plateformes matérielles dédiées à la réalisation des applications radios. Il fournit les services suivants : BRIDGE : service qui permet la communication temps réel de données entre plateformes qui implémentent P-HAL. SYNC : service de synchronisation des processus qui s exécutent sur différentes plateformes P-HAL. KERNEL : service d ordonnancement et de contrôle des modules fonctionnels de traitement sur chaque plateforme. STATS : service de supervision et de statistiques concernant les modules fonctionnelles radios. P-HAL hérite de la littérature les notions de découpage de l application radio en objets ou modules fonctionnels paramétrables. Il introduit principalement deux nouvelles notions : le contrôle des contraintes temps réel d exécution intra-plateforme et la synchronisation de plusieurs plateformes d exécution dans le cadre d une exécution distribuée (au sens inter-plateforme). Les modules fonctionnels à fournir par un environnement d exécution devraient être conçus pour être réutilisés par différentes applications. Conscient de cela, Gelonch et al pensent que le contrôle des contraintes temporelles doit être complètement externe aux objets de l application. L idée de conception de P-HAL est de réaliser une division du temps d exécution en slots. Cela permettrait de contrôler facilement que chaque tache s est terminée dans le délai précisé. Ensuite cela permettrait de définir un quota d exécution pour chaque tache, ce qui est utile pour réaliser des pipeline de traitements. Les taches peuvent après être déployées sur un ou plusieurs processeurs. L exécution d une application radio sur le framework P-HAL est basée sur la notion d intervalle de temps appelés slot. La synchronisation entre plateformes implémentant P-HAL devrait être relativement précise par rapport au temps du slot. Exemple : lorsque le slot dure 1ms, et la différence maximale acceptée entre références de slots est de 0.5%, une procédure de synchronisation devrait être exécutée toutes les 50ms. Pour réaliser cette synchronisation, on fait usage à des horloges locales. On choisit initialement une plateforme comme référence de temps (de préférence celle qui contient les oscillateurs de conversion analogique/numérique), et après chaque machine propage sa référence temporelle à celle qui lui est liée. Des travaux récents à l UPC, ont réalisé l environnement P-HAL et étendu ses services initiaux à des fonctionnalités encore de plus haut niveau permettant la réalisation des radios cognitives. Dans [45], Gomez et al. présentent les limitations de l architecture SCA et fournissent une comparaison avec P-HAL : Ils prétendent que le surcoût de P-HAL est inférieur à 10% du temps CPU total, que son empreinte mémoire est de 50Ko comparé au 1426Ko de l implémentation OSSIE[46] de SCA sur la même plateforme matérielle (DSP TI6416). 30

2.4 Les radios virtuelles 2.4 Les radios virtuelles Une radio virtuelle est une couche logicielle qui fournit des interfaces de programmation (API) permettant de définir une radio et leurs implémentations sur une plateforme matérielle hôte. Le but est de simplifier le développement des applications radios : les ingénieurs des protocoles de communication (en particulier des couches physiques) utiliseront des interfaces de programmation. Ceux des systèmes numériques réaliseront des composants matérielles reconfigurables dédiés qui optimisent la réalisation de ces API. Ce concept garantit la portabilité des formes d ondes sur les plateformes qui implémentent une machine virtuelle radio. De notre connaissance, cette approche a été évoqué pour la première fois par Gudaitis et Mitola (qui a initié le terme radio logicielle) dans [7]. Dans ce qui suit, nous proposons un résumé de cette proposition. Puis nous présenterons un aperçu des implémentations de machines virtuelles existantes. 2.4.1 Proposition de Gudaitis et Mitola En 2000, il n y avait pas encore de standard pour le développement d applications radios logicielles. C est ainsi que Gudaitis et Mitola ont eu l idée de proposer dans [7], le concept de machine virtuelle pour l appliquer à la radio logicielle : Le but était de fournir à la fois un standard pour le développement d applications radios et de fournir une approche qui garantit la portabilité des applications sur différentes plateformes matérielles. La proposition de Gudaitis et Mitola apparaît comme un «brainstorming» dans lequel il discutent les approches techniques permettant de mettre en œuvre le concept, ses enjeux économiques, et comment il pourrait évoluer. En résumé, le concept de machine virtuelle radio est un concept qui n est pas totalement nouveau, il est plutôt une combinaison des meilleurs concepts, paradigmes, et idées du domaine informatique façonnés pour la radio logicielle. Le modèle de la machine virtuelle Java comme point de départ Java a révolutionné le domaine des technologies de l information en utilisant un modèle de programmation à base de composants. En effet la réutilisation des composants par différentes applications permet d amortir leur coût de développement. Le succès du slogan de Java «write-once run-anywhere» est le résultat de la machine virtuelle. Il est inévitable que l exécution d un langage par une machine virtuelle soit moins efficace que sur le matériel natif. Cependant, l évolution de la puissance de calcul des processeurs, ainsi que le développement de techniques d optimisations telles que les compilateurs dynamiques à la volée (JIT, Just In Time), ont permis de réduire ce surcoût pour le rendre acceptable pour des applications dans le domaine de l IT (Information Technolgies). Une machine virtuelle radio selon Gudaitis et Mitola est une machine virtuelle comme celle du langage Java, qui fournirait un intergiciel commun pour les développeurs logiciels et matériels. Cela permettrait de séparer le cycle de développement en : développement logiciel en langage de la machine virtuelle. développement de matériel qui optimise l exécution de la machine virtuelle. Toutefois, la machine virtuelle Java ne fournit pas les fonctionnalités nécessaires à la radio logicielle. Exemple : absence de méthodes efficaces pour le calcul vectoriel ou de flux binaires, absence de dispositifs pour le contrôle des ASIC, etc. La machine virtuelle Java reste candidate pour être utilisée en tant que machine virtuelle radio après extension par des fonctionnalités radios. 31

2.4 Les radios virtuelles Éléments clés de la machine virtuelle radio Gudaitis et Mitola proposent un ensemble d impératives qu une machine virtuelle radio devrait permettre : Fournir un langage de programmation permettant de réaliser des couches physiques compilable en une forme exécutable (bytecode). Réaliser une abstraction selon un modèle à composants. Répondre aux limitations de la machine virtuelles Java, essentiellement, les contraintes temps réel et l absence de méthodes d accès au matériel. Gérer une précision arithmétique variable. Pour utiliser la machine virtuelle Java, il faut principalement l étendre avec un compilateur à la volée JIT(Just In Time) : celui-ci compile le bytecode en natif, lorsqu il sera exécuté pour la première fois. Le moteur d exécution de la machine virtuelle devrait aussi déterminer les ASIC à utiliser et mapper les binaires de configuration sur les FPGA pour réaliser les classes radios. 2.4.2 Implémentations propriétaires Dans cette partie, on présentera les implémentations propriétaires et les brevets déposés liés au concept de machine virtuelle radio. Dans [47], Ferris propose la CVM (Communication Virtual Machine) de Radioscape.Ltd : une machine virtuelle radio pour les stations de base. Elle fournit une interface de programmation faisant l abstraction des ressources radio et leur contrôle. La CVM inclut une large bibliothèque des fonctions les plus communément utilisées dans l implémentation des standards de couches physiques radio. «Configuration method» [48] est un brevet de Toshiba dans lequel est décrite une méthode de configuration pour les équipements radio reconfigurables. Cette méthode repose sur l usage de représentations logicielles abstraites des composants fonctionnels réalisés par une plateforme matérielle radio. Chaque représentation abstraite (abstract proxy component) est l équivalent d une classe abstraite dans le paradigme de la programmation orientée objet. A chaque représentation abstraite correspond une ou plusieurs représentations concrètes (concret proxy component) : un composant radio pourrait être fourni concrètement par du logiciel sur un DSP, ou par un ASIC, ou les deux. Dans ce document, les auteurs propose un intergiciel équivalent à une machine virtuelle radio. Celui-ci réalise le lien entre une représentation fonctionnelle abstraite et sa représentation concrète. Moy et al. proposent dans [49] une architecture logicielle pour les équipements de télécommunication permettant la reconfiguration en temps réel de celui-ci afin de réaliser des algorithmes qui nécessitent une reconfiguration dynamique. Cette architecture repose sur des modules de traitement logiciels et matériels reconfigurables, une mémoire qui contient les informations de reconfiguration et un processeur d ordonnancement des configurations qui réalise des fonctionnalités de la machine virtuelle radio. Questions de recherche ouvertes Certes, le concept de machine virtuelle radio a été proposé par Gudaitis et Mitola : dans [7], ils exposent seulement des généralités et quelques grandes lignes à suivre pour le développement du concept. Cependant, aucun article dans la littérature ne propose une architecture logicielle détaillée pour la réalisation d une machine virtuelle radio. Comment peut on réaliser une machine virtuelle radio? Quel est le modèle de programmation à adopter? Quelle est la machine virtuelle à choisir? Quels sont les fonctionnalités à fournir? quel est le surcoût de la machine virtuelle radio? et quelle est sa nature? Peut on réaliser les protocoles radios actuels avec ce concept? Ces questions et beaucoup d autres sont encore des pistes non investiguées, auxquelles on a réalisé durant cette thèse des études pour apporter des réponses. 32

2.4 Les radios virtuelles Conclusion Au cours de cette étude de l état de l art, nous avons étudié les architectures matérielles permettant de réaliser la radio logicielle. Ces architectures sont diverses et complexes à manipuler. L usage de modèles pour spécifier et implémenter des couches physiques sur ces plateformes est indispensable pour augmenter la productivité. L approche de modélisation par des langages de spécifications qui combine des principes issus de différents domaines (machine d états, diagrammes de blocs, langages de synchronisation, langages parallèles,... ) est l approche la plus utilisée. La plupart de ces langages adoptent le modèle à composants. Le passage de la spécification à l implémentation est réalisé généralement par raffinement successif puis par l usage de techniques de génération de code et de compilation sur des plateformes spécifiques. Les environnements de développement et d exécution n ont pas encore atteint leurs maturité. L unique standard en cours de développement est le SCA. Bien qu il soit aujourd hui considéré par les industriels, il reste fortement influencé par les radios militaires. De mon point de vue, SCA ne semble pas être adapté à des équipements mobiles à ressources limités : l ORB CORBA implémente des mécanismes lourds qui à leurs origines étaient conçus pour des serveurs d applications et qui ne permettent pas de supporter les contraintes temps réel des protocoles actuels. L approche de machine virtuelle pour la radio logicielle est bien adaptée pour répondre aux objectifs de la radio logicielle : la reconfigurabilité et la portabilité. Cependant, la littérature ne fournit pas de détails sur cette approche. Dans la suite de ce manuscrit on développera notre proposition du modèle de programmation associé au concept de machine virtuelle radio. 33

3 CHAPITRE Modèle de programmation rkpn Sommaire Introduction........................................... 35 3.1 Modèle de calcul rkpn (reconfigurable KPN)...................... 35 3.1.1 Définitions et modèles antérieurs.......................... 36 3.1.2 Proposition du modèle rkpn............................ 39 3.1.3 Proposition d un modèle d exécution associé................... 42 3.2 PLDL (Physical Layer Description Language)...................... 43 3.2.1 Description du langage PLDL............................ 43 3.2.2 Implémentation du IEEE802.11a en PLDL..................... 45 3.3 Proposition du dispositif «programmable pipe».................... 50 3.3.1 Problème visé.................................... 51 3.3.2 Description du dispositif PP............................ 51 3.3.3 Exemple d utilisation du PP : bloc d estimation de canal d un récepteur IEEE802.11a 54 Conclusion............................................ 56 34

3.1 Modèle de calcul rkpn (reconfigurable KPN) Introduction Les applications radios forment une classe d applications ayant des spécificités particulières. Un modèle de calcul adapté à ces spécificités devrait être défini afin d exprimer ces applications d une façon pragmatique permettant : Une analyse et une vérification formelle des spécifications. Un passage aisé à l implémentation. Dans la section 3.1, on propose un modèle de calcul qu on a appelé réseau de processus de Kahn reconfigurable ou «reconfigurable Kahn Process Network» (rkpn) pour la modélisation des applications radios. On expliquera les fondements théoriques du modèle et on montrera qu il est adapté aux spécificités des applications radios. Ensuite on présentera notre proposition du modèle d exécution associé. C est l abstraction de l architecture sur laquelle le modèle de calcul sera exécuté. Dans notre cas d étude, cette abstraction modélise une plateforme d exécution radio virtuelle. On propose dans la section 3.2 un langage de programmation pour la machine virtuelle radio (MVR), qu on a appelé PLDL (Physical Layer Description Language). Ce langage est une représentation exploitable du modèle de calcul rkpn. On expliquera les différentes primitives du langage. Un cas d étude faisant usage du langage sera présenté dans la section 3.2.2. Enfin, on présente dans la section 3.3 le dispositif de pipeline programmable que nous appellerons «Programmable pipe» dans la suite du document : il permet la définition d un bloc de traitement du flot de données en logiciel et son insertion dans une chaîne de traitement radio. On expliquera d abord son contexte d usage, puis on détaillera son architecture et le jeu d instruction qu il implémente. Un exemple d utilisation sera aussi présenté pour comprendre concrètement son intérêt. 3.1 Modèle de calcul rkpn (reconfigurable KPN) Les approches de modélisation des formes d ondes considérées dans la littérature adoptent des points fondamentaux communs : Modélisation à base de composants. Modèle de calcul inspiré du modèle flot de données synchrone appelé SDF (Synchronous Data Flow). Séparation entre le plan de traitement et le plan de contrôle, considérés comme deux niveaux d abstraction différents. Exemple : dans SPEX [36], on définit une sémantique Kernel pour la définition des noyaux de traitement nécessaires pour construire la chaîne de traitement et la sémantique Stream pour décrire le séquencement de l exécution. Considération des contraintes principalement temps-réel. Celles-ci sont interprétées lors de l exécution comme des points de contrôle et souvent gérés comme des exceptions au sens des langages de programmation orientés objet. Le modèle de calcul SDF est adapté à la modélisation des traitements synchronisés par l arrivée de flux de données et qui s exécutent en pipeline. La dynamicité de contrôle et de configuration des composants fonctionnels des protocoles radios actuels ne pourra pas être exprimée par une telle modélisation. En effet, le modèle SDF montre des limitations lorsque les nœuds de traitement doivent changer de mode de fonctionnement au cours de l exécution. De plus ce modèle ne supporte pas l apparition et la disparition des nœuds de traitement qui est un fait récurrent dans les protocoles radios. Dans la littérature, on propose des extensions au modèle SDF afin de pouvoir exprimer les spécifications des formes d ondes des protocoles actuels. 35

3.1 Modèle de calcul rkpn (reconfigurable KPN) Dans ce qui suit on présentera d abord quelques définitions des principaux modèles de calculs utilisés pour la modélisation des applications radios. On expliquera leurs cas d usage et leurs limitations. Puis on introduira notre modèle en expliquant ses principes fondamentaux et nos choix conceptuels. 3.1.1 Définitions et modèles antérieurs Les réseaux de processus de kahn (Kahn Process Network), le modèle flot de données synchrone (SDF) et ses dérivés sont les modèles de calcul les plus communément utilisés pour la description des applications de traitement du signal. Ces modèles fournissent principalement une abstraction structurelle de l application à réaliser. Les machines à états finis ou «Finite State Machine» (FSM) sont couramment utilisées pour la modélisation de la partie de contrôle des systèmes de traitement de signal. Les FSM fournissent une description comportementale de l application. Les modèles existants permettent l abstraction de différentes facettes de l application à réaliser : ils permettent surtout d exprimer l architecture globale et les interactions entre les différents composants de l application. Ces modèles servent généralement à spécifier les applications indépendamment de leurs implémentations. Ce qui permet d avoir une représentation générique de l application à réaliser pouvant être exploitée pour vérifier certaines propriétés (exemple : absence d interblocage, complétude, déterminisme, etc) et éventuellement pour générer du code exécutable pour différentes plateformes d exécution. Réseaux de processus de kahn, KPN Les réseaux de processus de Kahn (KPN) ont étés introduit par Gilles Kahn en 1970 [50]. KPN est un modèle de calcul distribué qui a été conçu dans le but de définir les sémantiques des langages de programmation parallèle. Aujourd hui il est largement utilisé pour la modélisation des systèmes de traitement du signal. KPN modélise une application par un ensemble de processus séquentiels qui communiquent de manière asynchrone à travers des canaux de communication infinis de types FIFO. [0,3,2,4,... ] [5,0,1,...] P 1 P 2 P 3 FIG. 3.1: Exemple de graphe KPN La figure FIG.3.1 illustre un exemple de graphe KPN. Les processus P1, P2 et P3 se communiquent des données d une manière asynchrone. Le processus P1 attend les données en provenance de deux sources. Dans KPN, il n y a pas d hypothèse sur l ordre de consommation des données. Exemple : un processus peut alterner la lecture depuis deux ports d entrées comme le montre l exemple de la figure FIG. 3.2. Dans le formalisme KPN, les canaux de communication sont des liens point à point entre deux processus. Un processus écrit des données sur une extrémité, le second les lit de l autre coté. Les écritures de données ne sont pas bloquantes et sont toujours autorisées. Tandis que les opérations de lecture bloquent le processus jusqu à disponibilité des données sur le canal. Notons aussi qu il n y a pas d instruction pour tester la 36

3.1 Modèle de calcul rkpn (reconfigurable KPN) 1 p r o c e s s f ( i n i n t u, i n i n t v, o u t i n t w) { 3 i n t i ; bool b = t r u e ; f o r ( ; ; ) { 5 i = b? w a i t ( u ) : w a i t ( v ) ; p r i n t f ( "%i \ n ", i ) ; 7 send ( i, w ) ; b =! b ; 9 } } U V f W FIG. 3.2: Exemple d un processus de kahn (extrait de [50]) présence ou l absence de données dans un lien entre deux nœuds de traitement. Une propriété fondamentale des processus de Kahn est qu ils sont déterministes : pour un ensemble de valeurs de données en entrée, les valeurs des sorties sont les mêmes indépendemment du temps d exécution. Modèle flot de données et ses variantes Le modèle flot de données représente une application par un graphe orienté de nœuds de traitement appelés «acteurs» interconnectés par des arcs appelés «canaux». Les nœuds de traitement représentent des opérations élémentaires, des fonctions ou des programmes entiers. Les arcs sont des canaux de communications à travers lesquelles les données transitent. Dans le formalisme flot de données, les données sont souvent appelées «jetons» (token). N1 2 3 3 1 N2 N3 1 2 3 1 3 1 N4 N5 N6 2 1 3 3 1 N7 3 1 1 N8 FIG. 3.3: Exemple de graphe SDF SDF est le modèle de flot de données synchrone (voir figure FIG. 3.3). Ce modèle a été conçu par Lee et Messerschmitt dans [51, 52] en 1987. Il a été ensuite intégré par Lee dans Ptolemy[53] : un framework de modélisation et de simulation d applications pour l embarqué. Un modèle flot de donnée est synchrone lorsqu il vérifie les propriétés suivantes : Le nombre de données produites et consommées est connu à l avance (lors de la modélisation). Dans le formalisme SDF, à chaque extrémité d un arc de communication est associée une valeur : elle représente le nombre de données produites ou consommées par un nœud pendant un cycle d exécution. La valeurs des jetons ne change en aucun cas le comportement de l application : le contrôle est indépendant des données. Les arcs sont des mémoires tampons (ils modélisent des FIFOs infinies). Les acteurs exécutent un traitement périodique qui alimente les mémoires tampons en continu. 37

3.1 Modèle de calcul rkpn (reconfigurable KPN) SDF est utilisé à la fois pour modéliser les applications à exécution séquentielle et des applications à exécution concurrente. Les traitements du modèle SDF sont exprimés en parallèle. Le contrôle de l exécution de l application est souvent implémenté par une entité externe. Celle-ci réalise l ordonnancement des différents traitements modélisés. Cet ordonnancement est établi statiquement dès la modélisation. Il est réalisé d une façon étudiée pour éviter les interblocages et réduire la taille des éléments de mémorisation et le temps global d exécution. Un exemple de calcul de l ordonnancement est décrit dans [54]. Plusieurs extensions ont été apportées au modèle SDF. On cite principalement, le modèle CSDF (Cyclo- Static Data Flow) [55] et le modèle BDF (Boolean-Controlled Data Flow) [56]. Le modèle CSDF est un modèle SDF avec une extension qui introduit une notion de routage pour les flux de données. Dans ce modèle certains nœuds agissent comme des multiplexeurs / démultiplexeur. Comme dans SDF, l ordonnancement des traitements dans le modèle CSDF est fait d une manière statique. La consommation ou la production des données dans le modèle CSDF a la particularité d être faite selon une manière cyclique avec un comportement prédéfini. N1 2,0 l1 1,1 N2 0,2 l3 1 N4 0,1 3 l2 1 N3 1 l4 FIG. 3.4: Exemple de graphe CSDF Dans la figure FIG.3.4, on voit que le nœud N 1 produit 2,0 sur le lien l1 et 0,1 sur le lien l2. Cela revient à dire que le nœud N 1 envoie lors de sa première itération deux tokens au nœud N 2 et ne lui envoie rien (0 token) lors de sa deuxième itération. De la même façon, il n envoie rien vers le nœud N 3 lors de sa première itération et lui envoie un token lors de sa deuxième itération. Ce modèle est répété d une façon cyclique lors des itérations 1,3,5, etc. Ceci se résume par un envoie de données alterné vers les nœuds N 2 et N 3. Le modèle BDF est représenté par un graphe de flot de données classique ayant des nœuds de traitement, auquel sont rajoutés deux nouveaux nœuds qui sont les opérateurs «Merge» et «Select». Ils ont le rôle de séparer ou rassembler des flots de données. Le «select»/«merge» est réalisé selon une condition non spécifiée. Les nœuds «Merge» (resp. «Select») ont exactement deux entrées distinctes (resp. sorties) et exactement une sortie (resp. une entrée). La décision de choix du canal sur lequel on consomme (resp. produit) est prise à l intérieur de l opérateur. Le modèle BDF implémente un mécanisme permettant de modéliser l aiguillage de données avec des structures conditionnelles comme celle du «if-then-else». Cependant, ce modèle perd son déterminisme par rapport au modèle SDF puisqu on ne pas prédire combien de fois les données vont être envoyées ou reçues sur chaque canal. Machine à états finis, FSM Le modèle «machines à états finis, ou FSM» est un modèle de calcul simple qui exprime l aspect comportemental d un système. Il est adéquat pour les systèmes ayant un nombre fini de modes fonctionnels (états) et qui transitent d un mode à un autre selon l évaluation de conditions. Les machines à états finis sont souvent utilisés pour modéliser le contrôle des systèmes. Une FSM a obligatoirement un état initial qui 38

3.1 Modèle de calcul rkpn (reconfigurable KPN) forme le point d entrée du modèle. Chaque fois que le système passe à un état, il sauvegarde celui ci, qui devient son état courant. Le formalisme FSM repose sur quatre éléments de bases qui sont : Les «états» : définissent un comportement particulier du système et peuvent produire un ensemble d actions. Les «transitions» : ce sont les passages d un état à un autre. Les «conditions» : qui devraient être vérifiées pour permettre une transition. Les «évènements» : sont générés depuis l extérieur ou par un état du système et permettent de passer une transition d état. Le modèle FSM a l avantage d être : Simple à comprendre : ceci facilite le processus d implémentation et de test. Déterministe : pour un ensemble donné d entrées et à partir d un état courant connu on peut connaître l état suivant. Hiérarchique : chaque état peut être décomposé en une ou plusieurs machines à états finis concurrentes et communicantes entre elles [57]. Ce modèle a aussi quelques limitations, surtout pour la description des systèmes de grandes tailles : en suivant le fil d exécution, les transitions entre états s entremêlent et la compréhension du comportement devient complexe. De plus, il est non adapté pour les systèmes ne pouvant pas être décomposés en différents états dont les transitions sont régies par des conditions bien définies. 3.1.2 Proposition du modèle rkpn Nous proposons dans cette partie un modèle calcul qu on a appelé réseau de processus de Kahn (rkpn). Nous discutons les principes fondateurs du modèle et nous montrons comment il est adapté aux caractéristiques des couches physiques des protocoles de communications radios. Principes de rkpn La plupart des spécifications de standards existants font un usage extensif des machines d états pour la description du contrôle et des diagrammes de flot de données pour la modélisation des traitements. Par exemple, dans la spécification du standard IEEE802.11a [58], les différents modules de traitements nécessaires pour la réception d une trame sont spécifiés par un diagramme de blocs. Il est équivalent à un diagramme de flot de données simple qui fournit une représentation statique des entités du système. La dynamique de transition entre les phases de traitements de l application est fournie sous la forme d un diagramme d états. Certes, la différenciation entre la description du contrôle et celle des traitements permet de séparer deux niveaux d abstractions différents. Ceci simplifie d abord la compréhension de la spécification et puis son implémentation. Cependant, les standards récents supportent différents modes de fonctionnement et nécessitent une reconfiguration dynamique de modules fonctionnelles de traitement réutilisables. Ceci revient à un entrelacement entre le plan de contrôle et le plan de traitement. En effet, le passage d un mode applicatif à un autre, nécessite dans certains cas, la reconfiguration des modules fonctionnelles de traitement avec des paramètres en provenance de résultats de traitements précédents. Par exemple, dans le standard IEEE802.11a, la démodulation de la sous trame de données nécessite la connaissance de la technique de modulation utilisée (QPSK, QAM16, QAM32, etc). Cette information est disséminée dans la sous trame SIGNAL et donc son décodage et démodulation devraient être préalablement réalisés pour déduire les paramètres de reconfiguration de la phase suivante de calcul. De plus, l adaptation des traitements aux conditions du canal de transmission nécessite souvent l accès au flot de données. Par 39

3.1 Modèle de calcul rkpn (reconfigurable KPN) exemple : les symboles pilotes permettent de calculer les coefficients de correction du signal. Dans ce contexte, nous proposons le modèle rkpn qui fournit une description unifiée et intégrée d une application radio : il modélise à la fois le contrôle, la configuration, les traitements et les interactions entre ces trois niveaux d abstraction. Le modèle rkpn permet ainsi la reconfigurabilité des plateformes matérielles de radio logicielle, d une manière à supporter différentes applications radios ou des applications multimodes. rkpn est un modèle simple, facilement exploitable et ne faisant pas d hypothèses restrictives sur les architectures cibles d exécution : Ceci permet de garantir la portabilité des applications modélisées. La figure FIG. 3.5 (à gauche) montre un exemple de KPN : chaque nœud est un processus et chaque arc est une FIFO. Notre modèle de calcul rkpn consiste à définir une séquence alternée de phases de calcul modélisées par des KPN et de phases de contrôle et de reconfiguration du KPN. Dans notre modèle on suppose l existence d une entité supplémentaire (que nous appelons le contrôleur) qui réalise de manière centralisé l exécution de la phase de contrôle et de configuration. P1 Ctrl Interruption 70 P1 60 P0 P2 Source 100 120 P0 20 P2 Puit FIFO P3 Processus KPN 70 P3 60 rkpn FIG. 3.5: Un KPN (à gauche) et le rkpn associé Une phase de calcul est exactement un KPN avec les différences suivantes (voir figure FIG. 3.5 (à droite)) : En plus des nœuds de calcul classiques du KPN, il existe deux types particuliers de nœuds : les sources et les puits de données. Ils représentent des dépôts de données programmables capables d envoyer (respect. recevoir) des données vers (respect. depuis) plusieurs nœuds destinations (respect. sources). Le nombre de données à traiter par chaque nœud, pour une configuration donnée, est connu statiquement. Chaque nœud de calcul peut être configuré pour envoyer une notification de fin de traitement au contrôleur central (MVR) provoquant ainsi la commutation vers une nouvelle phase de configuration. Configuration Lecture/écriture de données Ctrl Ctrl Interruption P1 P1 60 70 Source P0 P2 Puit Source 100 P0 20 120 P2 Puit P3 70 P3 60 FIG. 3.6: Un rkpn pendant et après reconfiguration La figure FIG. 3.6 représente un rkpn en phase de configuration : le contrôleur configure les processus (modifie leurs états) et configure les connexions entre processus. Lors de cette configuration il a accès aux données des processus, les actions de configuration peuvent dépendre de ces données. 40

3.1 Modèle de calcul rkpn (reconfigurable KPN) Une configuration est un ensemble de paramètres qui spécifient les interconnexions entre nœuds de calcul et leurs modes de fonctionnement. Pendant une phase de configuration, le contrôleur central peut : Attendre une ou plusieurs notifications de fin de traitement depuis les nœuds de traitements. Modifier les connexions entre les processus. Ajouter/supprimer/re-paramétrer des processus. Accéder aux données résultantes de la dernière phase de calcul pour calculer les nouveaux paramètres et prendre les décisions pour faire les modifications précédentes. Activer les différents processus du nouveau KPN crée. Dans notre cas, les processus seront des composants matériels ou logiciels et le contrôleur sera implémenté par la machine virtuelle radio (MVR). Un modèle à composants adapté aux pipelines de traitement du signal Le modèle flot de données repose sur deux notions : les processus et les canaux d interconnexions. Les processus interconnectés s échangent des données selon un modèle producteur-consommateur. Les mêmes processus sont généralement réutilisés par différents standards de couches physiques de protocoles radios. Afin de répondre aux spécificités de chaque standard, les processus sont à chaque fois configurés différemment. Dans notre modèle rkpn, nous considérons que les nœuds sont des composants radios conçus pour réaliser d une façon optimisée un algorithme de traitement de signal. Le composant est un modèle issue du domaine logiciel, c est l élément de base pour construire une application distribuée. Il constitue un module autonome, reconfigurable, pouvant être réutilisé par différentes applications et déployable sur différentes plateformes d exécution. L approche de modélisation par composant est adaptée à la radio logicielle : elle permet de séparer les interfaces de leurs implémentations. Un composant radio a les interfaces standardisées suivantes : Interface de configuration : pour la définition des paramètres fonctionnelles du module. Interface de communication : pour le passage de données entre composants. Interface de contrôle : pour contrôler l exécution du composant. Interface de notification : permet de notifier le contrôleur central lors de l occurrence d un évènement spécifique. Machine Virtuelle Radio Configuration Contrôle Notification de fin de traitement FFT FIG. 3.7: Exemple de composant radio, FFT Chaque composant radio inclut un processus principal qui peut être implémenté en logiciel ou en matériel. Ce processus fournit un service élémentaire reconfigurable de traitement de signal. Dans la figure FIG. 3.7 est illustré un exemple de composant radio. 41

3.1 Modèle de calcul rkpn (reconfigurable KPN) La programmation d une couche physique selon le modèle rkpn se fait alors par un assemblage de composants dont les interfaces sont fournies sous formes de bibliothèques logicielles. Quant à leurs implémentations, elles sont réalisées par des processeurs soit par les accélérateurs matériels de la plateforme d exécution. Le modèle rkpn est extensible, en l absence de composants réalisant des fonctionnalités spécifiques à un standard particulier, il permet de spécifier l algorithme d un nouveau composant pour une implémentation logicielle exécutée par le contrôleur central. Nous expliquons la mise en œuvre de ce dispositif dans la section 3.3. Les composants du modèle rkpn sont capables de compter le nombre de données traitées. Cette hypothèse est facilement réalisable et n implique pas des contraintes aux systèmes matériels implémentant les composants. Cette capacité permet de configurer un composant pour qu il envoie au contrôleur central une notification lorsqu il a terminé l exécution d un nombre de données spécifié. Ce dispositif est très important surtout que les protocoles existants font usage de la notion de trame de données. Le fait de compter les données permet de se positionner par rapport à la trame. Contrôle par une machine d états Le modèle rkpn définit un processus particulier, celui du contrôleur central (MVR). Ce processus implémente la machine d états du protocole radio à réaliser. À chaque état du système correspond un pipeline de traitement modélisé par un KPN. Quand un composant envoie une notification au contrôleur central, celui ci réalise une liste d actions (transition à un autre état de calcul). Ces actions forment le cœur des interactions entre pipeline de traitement et la machine d états du protocole. Les transitions sont les résultats d événements asynchrones (les notifications en provenance du pipeline de traitement). Ceci est du à la propriété asynchrone des communications de données par les processus de Kahn. Dans un système radio à architecture synchrone classique, il y a toujours présence d une unité de contrôle centralisée. Celle-ci agit selon une horloge globale et a la tache d ordonnancer et de synchroniser les différents processus du système. L asynchronisme du modèle rkpn a plusieurs avantages : il permet d éliminer le couplage entre composants radio, facilite l intégration de nouveaux composants et augmente la portabilité du modèle lors du passage à l implémentation. Par contre, un surcoût en traitement devrait être supporté pour intercepter les événements en provenance des processus de calcul. 3.1.3 Proposition d un modèle d exécution associé Le modèle d exécution est une abstraction de l architecture sur laquelle un rkpn va s exécuter. Dans notre cas d étude, le modèle d exécution est une plateforme radio virtuelle. Elle est constituée d un ensemble d IP interconnectées par un mécanisme de communication efficace. Ces IP sont reconfigurables et peuvent être logicielles ou matérielles. Le contrôleur central du modèle rkpn est réalisé par un processeur généraliste ou une IP dédiée. Notons aussi que notre modèle d exécution nécessite le partage des données entre les IP et le contrôleur central. En effet, le contrôleur doit être capable d accéder aux données en provenance des IP afin de calculer les paramètres de reconfiguration et en particulier celles des unités de traitements adaptatifs. Par le biais de ce mécanisme, est réalisé un lien logique entre le plan de contrôle et celui de traitement, nécessaire pour un contrôle dynamique des pipelines de traitements du signal. Ceci ne restreint pas l ensemble des architectures d exécution cibles. En effet, la plupart des plateformes matérielles existantes incluent des mémoires partagées agissant comme des mémoires tampons ou comme moyen de communication entre les IP qu on pourrait utiliser pour implémenter le partage de données. Les sources et puits de données représentent des nœuds particuliers du modèles rkpn. Ceux ci peuvent 42

3.2 PLDL (Physical Layer Description Language) être implémentés aussi par une mémoire partagée à laquelle on pourrait associer un DMA (Direct Memory Access) (optionnel, pour des raisons de performance). Le processeur de la MVR a un lien privilégié pour accèder à la mémoire Motreur d exécution de la MVR CPU ou IP dédiée RAM DMA (optionnel) Architecture à mémoire partagée matériel d interconnexion (Bus / NoC / HW dédié) IP/DSP 1 IP/DSP 2 IP/DSP 3 IP/DSP X Les IPs accèdent la mémoire partagée à travers le matériel d interconnexion FIG. 3.8: Modèle d architecture d exécution adapté à rkpn La figure FIG. 3.8 montre une architecture d exécution adaptée au modèle rkpn. Dans une architecture idéale, le processeur qui réalise la MVR possède un lien direct et privilégié qui le connecte à la mémoire globale du système. Ceci permettrait d éviter les contraintes liées au partage de la ressource de communication entre IP. La cohérence des données est garantie par le modèle de calcul. En effet, les phases de reconfiguration et de contrôle susceptibles de réaliser des opérations de lectures / écritures sur la mémoire, ne peuvent commencer qu après notification de fin de traitement du pipeline de traitement en cours. 3.2 PLDL (Physical Layer Description Language) Le PLDL est un langage de description de couches physiques que l on a conçu pour programmer la MVR. Pour une mise en œuvre du PLDL, on a défini une bibliothèque logicielle qu on a appelé RVM (Radio Virtual Machine) API : elle consiste en un ensemble de primitives radios et de structures de données adéquates au concept de MVR. PLDL est réalisé sous la forme d extension d un langage existant afin de définir un langage «spécifique» appelé aussi «Domain Specific Langage» (DSL) à la radio. PLDL est un langage qui exprime le modèle de calcul rkpn. Dans cette partie, on explique d abord les éléments constituants l extension radio. Ensuite, nous présentons un cas d étude où on a implémenté en PLDL les services d émission et de réception du standard de couche physique IEEE802.11a. 3.2.1 Description du langage PLDL Le modèle de programmation associé au langage PLDL représente une autre manière permettant d exprimer les phases alternées de calcul et de reconfiguration du modèle de calcul rkpn. Chaque phase de calcul correspond à un KPN à mettre en œuvre par la MVR. Dans rkpn les processus de traitement de signal sont modélisés par des composants reconfigurables. Chaque composant héberge un processus physique élémentaire. Dans le modèle de programmation que l on conçu, un composant est un «wrapper» logiciel qui encapsule l implémentation native d un processus de traitement du signal. Pour une plateforme matérielle radio logicielle, l ensemble des composants est fourni à la MVR sous la forme de bibliothèques logicielles. Ces bibliothèques permettent d implémenter les primitives suivantes du PLDL : 43

3.2 PLDL (Physical Layer Description Language) 1) Allocation / libération des ressources radios : comp_desc rvm.allocate ( comp_type ) : Alloue un bloc matériel ou crée une instance d un composant logiciel réalisant les fonctionnalités d un opérateur du type comp_type spécifié. Cette primitive retourne un descripteur du composant alloué (comp_desc). rvm.free ( comp_desc ) : libère le bloc matériel, ou désalloue l instance logicielle gérée par le descripteur de composant comp_desc. 2) Configuration des composants radios : core_config_desc rvm.build_core_config ( comp_desc, core_parameters_list ) : Construit une configuration native pour le cœur de traitement du composant alloué à partir des paramètres fonctionnelles spécifiés. Elle retourne un descripteur de configuration. com_config_desc rvm.build_com_config ( comp_desc, com_parameters_list ) : Construit une configuration pour les dispositifs physiques de communication du composant alloué (Exemple : configuration d un contrôleur d entrée/sortie). Elle retourne un descripteur de configuration. rvm.free_config ( com_config_desc core_config_desc ) : libère la mémoire réservée pour le stockage de la configuration spécifiée. rvm.configure ( comp_desc, core_config_desc, com_config_desc, event_type ) : configure le composant alloué qui est spécifié par comp_desc par les deux configurations stockés en mémoire de la MVR ( core_config_desc et com_config_desc). Le paramètre event_type spécifie si le composant doit envoyer une notification à la MVR lors de l occurrence d un évènement particulier. rvm.connect ( comp_desc_src, port_num_src, comp_desc_dest, port_num_dest, data_type ) : interconnecte le port de sortie spécifié du composant source au port de sortie spécifié du composant destination. Le paramètre data_type permet sur certaines plateformes d exécution de configurer les canaux de communication au type de données qu elles doivent transférer. 3) Contrôle de l exécution des composants radios : rvm.start ( comp_desc ) : Cette primitive active le fonctionnement d un composant préalablement configuré. Notons que parfois, l exécution de certains composants matériels est activée implicitement par l arrivée des données. rvm.stop ( comp_desc ) : désactive le fonctionnement du composant spécifié en paramètre. Les composants sont conçus de la sorte qu après leurs activations chacun s arrête implicitement lorsqu il a fini de traiter les données correspondant à sa configuration. Dans certains cas, il est utile d arrêter explicitement un composant même s il n a pas fini son traitement. rvm.wait ( event_type, [comp_desc_event_source] ) : cette primitive bloque l exécution de la MVR jusqu à l occurrence de l événement spécifié. Optionnellement on pourrait aussi spécifier le composant depuis lequel la MVR attend la notification. Le PLDL inclut aussi des primitives permettant de manipuler les données en provenance du flot de données. Un traitement spécifique de celles-ci est parfois nécessaire pour reconfigurer la plateforme d exécution. Cependant, il est à noter qu il est à la charge du programmeur de vérifier la cohérence mémoire en invoquant la primitive de synchronisation rvm.wait. 44

3.2 PLDL (Physical Layer Description Language) 4) Primitives d accès au flot de données : coarse_data_struct rvm.read ( mem_ptr, size ) : copie un bloc de données de taille size stocké à l adresse logique mem_ptr dans l espace mémoire de la MVR. La primitive read retourne une référence sur le bloc de données lues. rvm_data_table rvm.convert2rvm ( coarse_data_struct, data_type ) : convertit les données lues dans leur état brute en un tableau de données en langage MVR. Les données du tableau sont alors du type spécifié par data_type. coarse_data_struct rvm.convert2platform ( rvm_data_table, data_type ) : convertit un tableau de données depuis le format MVR vers un format supporté par la plateforme d exécution. rvm.write ( coarse_data_struct, mem_ptr ) : copie le bloc de données référencé par coarse_data_struct à l emplacement mémoire spécifié par mem_ptr. Les sources et les puits de données du modèle rkpn peuvent être implémentés par des DMA : ce sont des composants matériels spécialisés pour faire des transferts de blocs de données d une façon efficace. Les DMA récents sont programmables et permettent de réaliser des opérations complexes sur les données. Par exemple, combiner des flots de données depuis plusieurs sources ou démultiplexer des flots de données selon des schémas complexes vers plusieurs sorties. En résumé, l extension proposée permet d instancier, de configurer et de contrôler l ensemble des composants qui sont en charge d implémenter les fonctionnalités radios. Le PLDL a été réalisé comme un DSL embarqué au sein d un autre langage généraliste sous la forme de bibliothèques de fonctions dédiés. Cette approche a pour avantage de ne pas développer de compilateur et d utiliser celui du langage «hôte». Les structures itératives et de contrôles des langages classiques ainsi que toute la sémantique des opérations arithmétiques sont fournies par le langage «hôte». Dans la partie suivante, nous allons montrer un cas d usage du PLDL pour implémenter les services du standard IEEE802.11a. 3.2.2 Implémentation du IEEE802.11a en PLDL Afin d expérimenter notre modèle de programmation nous avons vérifié sa capacité à exprimer des services de standards existants de couches physiques. Nous avons alors réalisé un démonstrateur IEEE802.11a faisant usage du concept de MVR. Dans ce qui suit, nous exposons d abord un aperçu du standard IEEE802.11a. Ensuite, nous détaillons l architecture du démonstrateur et sa mise en œuvre. Enfin nous analysons les résultats d expérimentations que nous avons réalisées pour la validation fonctionnelle du démonstrateur. Aperçu de la couche physique IEEE802.11a Le standard IEEE802.11 inclut plusieurs variantes de couches physiques. Exemple : 802.11a, 802.11b, 802.11g,802.11n, etc. Chacune des couches PHY IEEE802.11 a ses propres caractéristiques (largeur de la bande de fréquence utilisée, techniques de codage et de modulation, etc). La couche physique IEEE802.11 est ainsi organisé en deux sous couches (voir figure FIG. 3.9) : la sous couche PLCP (PHY Layer Convergence Protocol) et la sous couche PMD (PHY Medium Dependent). La sous couche PLCP fournit à la couche MAC (Medium Access Control) des services principalement d écoute de canal, d émission et de réception des trames MPDU (MAC Protocol Data Unit). Cette sous couche est commune aux différentes variantes du protocole IEEE802.11. La sous couche PMD définit exactement une variante du protocole et c est celle-ci qui réalise les traitements du signal nécessaire à la transmission d une 45

3.2 PLDL (Physical Layer Description Language) Couche MAC Couche Physique Sous couche PLCP Sous couche PMD 802.11a / b / g / n FIG. 3.9: Architecture de la couche 802.11 trame. La sous couche PMD du IEEE802.11a utilise la technique de multiplexage de signaux numériques par répartition en fréquences orthogonales (OFDM ou Orthogonal Frequency Division Multiplexing) pour la transmission des données. IEEE802.11a permet de fournir un débit maximale de 54Mbps dans la bande de fréquence des 5GHz. La technique OFDM permet de réduire le taux d erreur de transmission lié au problème de propagation multi-chemins (exemple : les interférences causées par la réception de multiples réflexions radios dans un bâtiment) et une meilleure utilisation de la bande de fréquence. PLCP Header RATE 4 bits Reserved 1 bit LENGTH 12 bits Parity 1 bit Tail 6 bits SERVICE 16 bits PSDU Tail 6 bits Pad Bits Coded/OFDM (BPSK, r=1/2) Coded/OFDM (RATE is indicated in SIGNAL) PLCP Preamble 12 Symbols SIGNAL One OFDM Symbol DATA Variable Number of Symbols FIG. 3.10: Format d un PPDU IEEE802.11a extrait de [58] Un émetteur IEEE802.11a peut être modélisé comme un système qui : reçoit en entrée : un PSDU (PLCP Service Data Unit) qui est l unité de donnée à transmettre en provenance de la couche MAC. réalise un traitement : qui consiste à encapsuler le PSDU dans un PPDU (PLCP Protocol Data Unit) en ajoutant une entête et un préambule PLCP, puis transformer cette représentation binaire en des échantillons temporels complexes (I, Q) à transmettre sur le canal radio. produit en sortie : les échantillons temporels correspondant au PPDU (voir figure FIG. 3.10). Dans la figure FIG. 3.10, le PPDU est représenté par une suite de sous-trames dont chacune est constituée d un ou plusieurs symboles. Un symbole correspond aux échantillons temporels du signal résultants de l application de l opérateur IFFT sur une fenêtre de valeurs complexes (fréquences). Dans un cas idéal où le canal de communication est parfait (absence de phénomènes perturbateurs), un récepteur IEEE802.11a réalise exactement les opérations inverses d un émetteur. Cependant dans la réalité, un récepteur doit implémenter des fonctionnalités de correction de signal pour éviter les erreurs dues aux imperfections du canal radio. 46

3.2 PLDL (Physical Layer Description Language) Le standard IEEE802.11a supporte différents débits de transmission : 6, 9, 12, 18, 24, 36, 48 et 54Mbps. À chaque débit une technique de modulation m-aire particulière (BPSK, QPSK, 16-QAM ou 64-QAM) et un codage de convolution avec un taux de codage particulier sont utilisés. Le tableau TAB. 3.2.2 montre les différents paramètres associés à chaque débit. Coded bits Coded bits Data bits Date rate Modulation Coding rate per per ofdm per ofdm (Mbits/s) (R) subcarrier symbol symbol (N BPSC) (N CBPS) (N DBPS) 6 bpsk 1/2 1 48 24 9 bpsk 3/4 1 48 36 12 qpsk 1/2 2 96 48 18 qpsk 3/4 2 96 72 24 16-qam 1/2 4 192 96 36 16-qam 3/4 4 192 144 48 64-qam 2/3 6 288 192 54 64-qam 3/4 6 288 216 TAB. 3.1: Paramètres associés à chaque débit du IEEE802.11a MVR Programme 802.11a RX (écrit en PLDL) ifft1=rvm.allocate(t_ifft) rot1 =rvm.allocate(t_rot)... Bytecode 802.11a RX 0xFFA410AE 0xDEADBEEF... Encoder / Puncturer Scrambler Viterbi Decoder Interleaver IFFT De-interleaver GI adder Mapper Constellation Compilateur Environnement de développement Bytecode commun à toutes les plateformes FIR De-puncturer FFT DMA Rotor Phase Estimator MVR et plateforme d exécution FIG. 3.11: Architecture globale du démonstrateur IEEE802.11a Démonstrateur IEEE802.11a Nous avons réalisé un démonstrateur logiciel d un émetteur / récepteur «WiFi» selon le standard IEEE802.11a. Le logiciel du démonstrateur est disponible en ligne (voir [59]). La figure FIG. 3.11 décrit l architecture glo- 47

3.2 PLDL (Physical Layer Description Language) bale du démonstrateur. Il est constitué de : Une plateforme matérielle d exécution : dans notre cas, elle est émulée sur ordinateur. Une MVR : est une machine virtuelle logicielle classique étendue avec une bibliothèque qu on a appelé «RVM API». Celle ci implémente les primitives du PLDL. Un byte-code : est le résultat de la compilation d un programme écrit en PLDL. Ce programme correspond à un service physique (émission ou réception d une trame). La plateforme d exécution est émulée sur un micro-ordinateur avec un système d exploitation Linux. Les processus des composants radios nécessaires pour réaliser les services d émission et de réception de trames IEEE802.11a ont été implémentés totalement en logiciel par des threads POSIX et donc sont exécutés en parallèles. Le code d un programme séquentiel qui modélise la couche physique IEEE802.11a, disponible sur [60], nous a été utile pour notre implémentation des composants radios. Les liens de communication de données entre les composants sont des FIFOs instanciés à la demande par la MVR. L objectif du démonstrateur est d évaluer la facilité d expression des standards de couches physiques avec le modèle de programmation qu on a conçu. Il n est pas du fait un prototype qui respecte les contraintes temps réel. Une preuve de concept de la MVR a été réalisé en intégrant la bibliothèque logicielle «RVM API» à la machine virtuelle du langage Lua [61]. Le choix de Lua comme langage de programmation est principalement lié au fait que c est un langage conçu pour être étendu en langage «spécifique» [62]. En effet, Lua est un langage ayant les caractéristiques suivantes : Sémantique simple : il ne contient que les structures de bases. Interprété et sa machine virtuelle est modulaire (les modules accessoires peuvent être supprimés). Extensible : une API permettant d intégrer de nouveaux modules à la machine virtuelle est fournie. Nous avons écrit en PLDL les programme pour émettre / recevoir une trame IEEE802.11a (voir Annexe A). Le programme de l émetteur est simple par rapport à celui du récepteur. En effet, trois phases indépendantes doivent être réalisés pour transformer un PSDU en échantillons temporels : La sous trame PREAMBLE est une partie fixe, dont les données sont connues à l avance qui sera envoyée en premier. La sous trame SIGNAL est construite à partir des 24 premiers bits de de l entête PLCP (cf FIG. 3.10). Ceux-ci sont traités par un pipeline de processus (codeur de convolution, entrelaceur ou «interleaver», modulation m-aire ou «mapper», transformée de Fourier,... ). Les paramètres de configuration des composants sont connus à l avance (un taux de codage 1/2, une modulation m-aire BPSK,... ). La sous trame DATA est construite à partir de la partie restante du PPDU. les mêmes composants seront réutilisés, auquel le composant embrouilleur ou «scrambler» est rajouté. Selon le débit de transmission, ces composants sont configurés. Le nombre des échantillons temporels correspondant à chaque sous trame est connu à l avance. Un puit de données est configuré à chaque fois par la MVR pour envoyer une notification de fin de traitement permettant de séquencer les phases de calcul. Le programme du récepteur nécessite une reconfiguration dynamique des composants radios. Ce cas de reconfiguration est rencontré dans 3 situations : L estimation de l erreur CFO (Carrier Frequency Offset) est calculée à partir des symboles STS (Short Training Sequence) et LTS (Long Training Sequence) du préambule PLCP avec la méthode décrite dans 48

3.2 PLDL (Physical Layer Description Language) [63]. Le déphasage dû à l erreur CFO est alors compensé par l usage d un rotor configuré avec celui-ci. Les symboles STS et LTS sont des symboles d apprentissage : ils représentent un schéma d échantillons temporels connu par le récepteur et qui servent en général à la synchronisation pour la détection du début de trame, la correction de l erreur CFO et au calcul de la réponse impulsionnelle du canal. RF front end Lecture/écriture de données Configuration / Wait (interruption) Flux de données Configuration pour l estimation CFO MVR DMA 1 Phaseestimator rotor DMA 2 Estimation grossière du déphasage Estimation fine du déphasage FIG. 3.12: Diagramme de séquences de l estimation de l erreur CFO Dans la figure FIG. 3.12, La MVR configure un premier KPN (DMA_1, phaseestimator et DMA_2) pour calculer une estimation grossière du déphasage (coarse phase drift estimation). Ensuite, elle reconfigure un deuxième KPN (DMA_1, rotor, phaseestimator et DMA_2) pour calculer une estimation fine du déphasage (fine phase drift estimation). Dans ce cas, le rotor est configuré avec la valeur du déphasage calculé par le première chaîne de traitement. Enfin, la MVR configure le rotor pour corriger la suite des échantillons temporels de la trame. Le calcul des coefficients de la réponse impulsionnelle du canal est réalisé selon la méthode décrite dans [64] à partir des deux symboles LTS. Ces coefficients sont utilisés pour configurer l égaliseur qui se situe après le composant FFT dans la chaîne de traitement. La sous trame SIGNAL incorpore les informations de signalisation, comme le débit utilisé pour la transmission. Le décodage de cette sous trame est alors nécessaire afin d en déduire les paramètres de codage et de modulation (décrits dans le tableau TAB. 3.2.2) utilisés pour la sous trame DATA. Expérimentations et résultats Dans cette partie on présente d abord les tests réalisés pour valider les fonctions d émission et de réception exécutés par la MVR. Ensuite, nous analysons les résultats des expérimentations réalisés. Dans la spécification [58] sont fournis : un message de référence (PSDU), le PPDU et les échantillons temporels résultants du processus de codage et de modulation qui lui correspondent. Pour valider l émetteur, on a repris ce message de référence et comparé les échantillons temporels résultants de notre programme avec ceux de la référence. De la même façon on a comparé le message de référence avec le message décodé par notre programme du récepteur à partir des échantillons temporels de référence. Dans les deux cas, les résultats étaient identiques aux références. On a aussi vérifié l interopérabilité de l émetteur et du récepteur : un message généré aléatoirement est modulé par l émetteur. Les échantillons temporels résultants sont démodulés par le récepteur et on retrouve le même message envoyé. Enfin, on a inséré entre l émetteur et le récepteur une implémentation d un modèle de canal paramétrable qui réalise les phénomènes physiques suivants : propagation multi-chemins, bruit blanc gaussien ou AWGN (Additive White Gaussian Noise) et erreur CFO. Le récepteur implémenté retrouve 49

3.3 Proposition du dispositif «programmable pipe» dans tous les cas le message envoyé. Programme Temps de Nombre de Taille du code développement (JH) lignes de code exécutable (Ko) Émetteur 6 100 3 Récepteur 11 300 6 rvm api >200 7000 1000 TAB. 3.2: Résumé des résultats de l implémentation du démonstrateur IEEE802.11a Le tableau TAB. 3.2 résume les résultats obtenus à partir de notre implémentation du démonstrateur. On remarque que le temps mis pour la réalisation des programmes émetteur et récepteur est faible par rapport à celui passé à la réalisation de la «RVM API». La «RVM API» est implémentée une seule fois par plateforme par contre elle est réutilisée par tous les programmes. On note aussi que la taille des programmes est de moins de 10 kilo-octets. Ce qui permet des perspectives de téléchargement de byte-code. Retour d expérience La réalisation d un protocole de couche physique radio existant valide fonctionnellement notre modèle de programmation rkpn et montre que c est un modèle viable. Lors de notre expérience de développement, on a été confronté à la problématique de réaliser des fonctionnalités spécifiques qui ne sont pas nécessairement fournis par l environnement de la MVR. Lorsqu un opérateur spécifique de traitement du signal n est pas fourni par la MVR, il est possible d utiliser la MVR, elle-même pour réaliser le traitement. Pour cela il faut faire les actions suivantes : 1. Configurer un puit de données pour recevoir le nombre de données nécessaires et notifier le contrôleur central. ce qui revient à arrêter le flux de données momentanément. 2. Le contrôleur central (la MVR) accède en lecture / écriture aux données. 3. Le contrôleur central relance le traitement. Dans la section suivante nous proposons un nouveau dispositif compatible avec notre modèle de programmation permettant de résoudre cette problématique d une façon efficace. 3.3 Proposition du dispositif «programmable pipe» Le modèle de programmation qu on a conçu permet d exprimer des phases alternées de contrôle et de calcul. Le contrôle est réalisé par un contrôleur central alors que les calculs sont réalisés par des composants ayant des interfaces standardisés. Cela suppose la présence d un ensemble de composants fonctionnels reconfigurables permettant d être invoqués à la demande par le programme de contrôle. Concrètement sur une plateforme matérielle, ces composants sont fournis soit par des IP dédiés, soit en logiciel sur des DSP. Cependant, un modèle de programmation pour la radio logicielle doit être extensible pour pouvoir supporter un ensemble large de standards radios (ceux qui existent et ceux du futur). Pour cela, on propose dans ce qui suit, un nouveau dispositif qu on a appelé «programmable pipe (PP)» permettant de définir d une façon abstraite les traitements spécifiques afin de permettre leurs exécutions en logiciel. D abord on détaille le problème résolu par ce dispositif. Ensuite nous décrivons son architecture et les 50

3.3 Proposition du dispositif «programmable pipe» fonctionnalités qu il est censé implémenté. Enfin nous présentons un cas d usage du PP à travers un exemple d application. 3.3.1 Problème visé Pour effectuer un traitement du signal complexe de manière efficace, on utilise souvent des blocs matériels intervenant les uns à la suite des autres le long de la chaîne de calcul. Cependant, dans les architectures multiapplicatives, on a souvent besoin de plus de flexibilité pour implémenter des blocs de calcul spécifiques. Pour répondre à ce besoin, on utilise traditionnellement des blocs logiciels implémentés sur des processeurs spécialisés pour le traitement du signal appelés DSP (Digital Signal Processor). Comme tout processeur, un DSP exécute un programme pour agir sur des données stockées en mémoire. Des mécanismes logiciels / matériels sont généralement mises en œuvre pour réaliser la synchronisation avec la disponibilité des données en provenance d autres blocs de calcul. Par exemple, on utilise des mécanismes de FIFO intégrés d une manière spécifique au DSP pour traiter efficacement les flux de données en entrées. Dans un cas d usage ponctuel d un DSP (par exemple, pour calculer une seule fois une fonction donnée), le contrôleur central de la plateforme matérielle est souvent celui qui a la charge de notifier le DSP de la disponibilité des données. Exemple : dans la famille de circuits OMAP [65] de Texas Instrument, un mécanisme matériel de «mail box» permet à un processeur GPP de notifier le DSP de la disponibilité des données sur une mémoire partagée. Cette approche a l inconvénient de complexifier le processus de contrôle qui aura la charge de gérer le protocole de passage de messages entre les composants logiciels. Dans un contexte d architecture matérielle de traitement du signal intensif, les DSP sont intégrés d une manière adaptée au modèle flot de données : on associe souvent des composants DMA aux DSP, leurs permettant ainsi de défiler les données vers ou depuis d autres blocs de calcul. La programmation d un DSP est alors complexe et surtout dépendante de l architecture cible : le programme manipule des primitives de niveau «drivers» pour contrôler le DMA et nécessite la connaissance des adresses physiques en mémoire. Le but du dispositif «programmable pipe (PP)» est de permettre de manière aisée d insérer dans une chaîne de calcul des traitements de type logiciel, c est-à-dire effectués par un programme exécuté par un processeur ou un DSP. 3.3.2 Description du dispositif PP Le «programmable pipe» (PP) est une unité virtuelle de traitement en mode flot de donnée, qui une fois programmée réalise un traitement spécifique nécessaire à un protocole particulier. Cela permet d implémenter des fonctionnalités qui n étaient pas prévues lors de la conception de plateforme matérielle hôte. Certes ce genre de mécanisme est possible avec les circuits existants de radio logicielle. Cependant, la particularité du PP consiste dans son programme exécutable qui ne dépend pas d une architecture particulière : le langage utilisé pour le programmer est un langage généraliste étendu principalement avec des primitives de gestion de flot de données. Dans le contexte du concept de MVR, le PP est vu comme tout composant radio : il présente les mêmes interfaces de contrôle, de configuration (programmation dans le cas du PP), de communications et de notification. Une MVR peut instancier un PP, le programmer, l interconnecter avec d autres composants et attendre une notification de fin de traitement de celui-ci. Une caractéristique particulière du PP, est qu il est capable d échanger des données pendant l exécution de son traitement avec le contrôleur centrale (MVR). 51

3.3 Proposition du dispositif «programmable pipe» Architecture du matériel idéal La synoptique du matériel pour réaliser le PP est illustrée dans la figure FIG. 3.13. Signaux de synchronisation (2) gestionaire de tampon (5) processeur/dsp Données entrantes adr_début adr_in adr_out adr_fin Données sortantes (3) (1) zone de mémorisation (4) Tampon Données valides du tampon FIG. 3.13: Synoptique du programmable pipe Le PP est constituée de : (1) une zone de mémorisation des données, accessible en lecture et écriture par plusieurs des éléments décrits ci-après ; (2) un dispositif de gestion d un tampon (FIFO) chargé de : a. mémoriser les limites du tampon considéré dans (1), représentées par adr_début et adr_fin, b. tenir à jour l adresse de stockage de la prochaine donnée entrante depuis (3), représentée par adr_in, c. tenir à jour l adresse de lecture de la prochaine donnée du tampon qui sera envoyée à (4), représentée par adr_out, d. exécuter des opérations spécifiques de synchronisation (correspondant aux «primitives», détaillées par ailleurs) avec (6) par un échange de signaux, l enchaînement des opérations étant décrit par l intermédiaire d un programme ; (3) un dispositif de réception de données (envoyées par un composant fonctionnel ne faisant pas partie du PP), chargé de stocker chaque donnée entrante dans la zone mémoire à l adresse définie par (2) b. (4) un dispositif d émission de données (vers un composant fonctionnel ne faisant pas partie du PP), chargé sur ordre de (2) de lire chaque donnée depuis l adresse définie par (2) c et de l envoyer vers l extérieur ; (5) un dispositif programmable tel qu un processeur ou un DSP, capable d accéder aux données stockées dans (1), d effectuer des opérations arithmétiques sur celles-ci et d exécuter par un échange de signaux avec (2) des opérations spécifiques de synchronisation (cf. (2) d). 52

3.3 Proposition du dispositif «programmable pipe» Les primitives de gestion de flot de données du PP Les primitives spécifiques à la gestion de flot de données sont réalisées par le gestionnaire de tampon du PP suite à des commandes envoyées par le processeur du PP. Voici une description de ces primitives : WAIT_DATA Cette primitive bloque le programme jusqu à ce qu un nombre spécifié de données soient disponibles dans la mémoire du PP. SEND_DATA Envoie le nombre spécifié de données vers la sortie du PP, et donc vers un bloc de traitement distant de la chaîne considérée. DELETE_DATA Supprime le nombre spécifié de données du PP (les données les plus anciennes de la FIFO). READ_DATA Fournit au processeur/dsp des données depuis la mémoire du PP, afin qu il puisse effectuer un traitement logiciel sur ces données. WRITE_DATA Incorpore les données modifiées par le processeur/dsp dans le mémoire du PP, à la place des données qui lui ont été précédemment fournies par READ_DATA. INSERT_DATA Ajoute des données calculées par le processeur/dsp à celles du tampon. Cette primitive permet d insérer des données dans le flot. En plus de ces primitives, le langage du PP inclut des fonctions mathématiques agissant sur des variables scalaires et vectorielles. Ainsi que les structures itératives et de contrôle des langages de programmation classiques. Zone des données valides La zone des données valides est représentée dans la figure FIG. 3.13 par la partie grisée du tampon mémoire de PP délimitée d une part par l adresse notée adr_in et de l autre part par l adresse notée adr_out. Le gestionnaire de tampon a la tache de gérer des pointeurs d adresses correspondant aux adresses adr_in et adr_out pour réaliser les opérations de lecture / écriture selon le mécanisme de FIFO circulaire. La zone des données valides correspond aux emplacements de la zone de mémorisation qui contiennent les données rentrées dans la FIFO circulaire et qui ne sont pas encore lues. Le dispositif de PP permet de cacher la complexité de gestion de la zone de mémorisation : le programme à exécuter par le processeur du PP consiste en un ensemble de primitives de commandes de gestion du flot de données (lecture, écriture, synchronisation, etc) et de calcul agissant sur les données situés dans la zone des données valides. Celle-ci est est vue par l utilisateur comme un tableau de taille infini qui stocke les données d une façon contiguë. Alternatives d implémentation de la primitive INSERT_DATA La primitive INSERT_DATA comme elle est décrite précédemment permet d insérer des données dans le flot de données : cela en envoyant directement les données en provenance du processeur/dsp (5) vers l unité d émission de données (4). Pour sa réalisation on pourrait considérer une implémentation avec une seule zone de mémorisation comme dans la figure FIG. 3.13. Dans ce cas une partie de la zone de mémorisation (1) sera réservée pour l insertion des données. La primitive INSERT_DATA consiste alors à l écriture des données par le processeur/dsp (5) dans cette zone et puis celui-ci envoie une commande au gestionnaire de tampon (2) pour mettre ces données à disposition de l unité d émission de données (4). 53

3.3 Proposition du dispositif «programmable pipe» Signaux de synchronisation (2) gestionaire de tampon (5) processeur/dsp Données entrantes adr_début adr_in adr_out (1 ) adr_fin Données sortantes (3) (1) zone de mémorisation (6) (4) Tampon Données valides du tampon Multiplexeur FIG. 3.14: Synoptique du programmable pipe (version avec deux buffers) Une deuxième alternative d implémentation serait de mettre en œuvre deux zones de mémorisation distinctes (figure FIG. 3.14). Une première zone tampon (1) sera utilisée pour la gestion des données en provenance du flot de données comme expliqué précédemment. La deuxième zone (1 ) sera dédiée pour les insertions de données. Le processeur/dsp (5) écrit alors les données à insérer dans la zone tampon dédiée. Il envoie ensuite un signal à un multiplexeur (6) pour diriger les données vers l unité d émission de données (4). 3.3.3 Exemple d utilisation du PP : bloc d estimation de canal d un récepteur IEEE802.11a Dans cette partie, on explique à travers un exemple d application l utilisation du PP. Notre application consiste à réaliser le bloc d estimation de canal pour un récepteur IEEE802.11a par le mécanisme de PP. Suite aux imperfections du canal de transmission (propagation multi-chemins, évanouissement, etc), le signal transmis subit des modifications qui consistent essentiellement en l atténuation et le déphasage de certaines sous porteuses du signal initial. L estimation de canal consiste généralement à calculer la fonction de transfert associée au canal radio de transmission, appelée aussi réponse impulsionnelle du canal (CIR). Appliquer la fonction de transfert inverse au signal reçu permet de l égaliser. La spécification du standard IEEE802.11a n exige pas un algorithme particulier d estimation de canal. Chaque fabricant de circuit «modem» réalise son propre algorithme. Ceci rend possible le fait qu un circuit conforme à la norme soit meilleur qu un autre qui l est aussi. En effet, cet algorithme est important puisqu il influe considérablement sur la capacité d un récepteur à récupérer le signal émis malgré de mauvaises conditions de transmission. 54

3.3 Proposition du dispositif «programmable pipe» Nous avons choisi pour notre exemple d utiliser l algorithme décrit dans [64]. Le calcul de la fonction de transfert du canal pour le IEEE802.11a est réalisé à partir des représentations fréquentielles de deux fenêtres FFT C 1k et C 2k. C 1k correspond au symbole d apprentissage LTS1 avec un décalage de n 0 +16 échantillons temporels ; C 2k correspond au symbole d apprentissage LTS2 avec un décalage de n 0 échantillons temporels. n 0 est un décalage du à une erreur de synchronisation. (voir figure FIG. 3.15). Préfixe cyclique LTS 1 LTS 2 n + 16 0 n 0 Fenêtre FFT C (1, k) Fenêtre FFT C (2, k) FIG. 3.15: Séquence d apprentissage d un PPDU IEEE802.11a La formule pour le calcul des coefficients CIR est la suivante : Ĥk = Ĥ1k+Ĥ2k 2, k = 0, 1, 2,...,N 1. avec : { Ĥ 1k = C 1ke j2π16k N C x k = 1k e j2π16k N si x k 0 C 1k e j2π16k N si x k < 0 { Ĥ 2k = C 2k C2k si x x k = k 0 C 2k si x k < 0 Les x k sont les valeurs fréquentielles correspondant aux échantillons temporels d un symbole LTS de référence, ils peuvent avoir la valeur 1 ou 1. N est la taille de la fenêtre FFT (N = 64 pour le IEEE802.11a). Pour réaliser cet algorithme spécifique on peut utiliser le PP pour calculer le vecteur Ĥk qui servira comme paramètre de configuration de l égaliseur pour la correction des données du reste de la trame. MVR paramètres d égalisation (CIR) DMA PP (Estimation de canal) FFT égaliseur... FIG. 3.16: Chaîne de traitement pour l estimation de canal et son égalisation La figure FIG. 3.16 montre le flot de données à configurer par la MVR. Le programme du PP consiste à : 1. Synchronisation avec la disponibilité des échantillons temporels correspondant aux fenêtres C 1k et C 2k en provenance de l unité DMA (source de données), ceci en exécutant la primitive WAIT_DATA. 2. Récupérer C 1k et C 2k en exécutant la primitive READ_DATA. 3. Ordonner l envoi du reste de la trame au bloc suivant de la chaîne, ici, la FFT par la primitive SEND_DATA. 3. Calculer Ĥk (la fonction de transfert du canal). 4. Notifier la MVR de la disponibilité du résultat (Ĥk). Celle ci récupère alors Ĥk pour configurer l égaliseur et activer son exécution. En utilisant le PP, les données utiles (sans les symboles d apprentissage) en provenance de la partie RF sont renvoyés tout de suite au bloc FFT sans attendre que le PP termine le calcul de l estimation de canal. Dès que le résultat du PP est prêt, celui ci est récupéré par la MVR pour configurer le bloc égaliseur. 55

3.3 Proposition du dispositif «programmable pipe» Conclusion Dans ce chapitre, on a d abord proposé le modèle de calcul rkpn qui permet d exprimer les couches physiques des systèmes radios. Dans les couches physiques des standards de communication modernes, les blocs de calcul sont fréquemment reconfigurés avec la particularité suivante : la décision pour reconfigurer une chaîne de calcul ainsi que les paramètres de reconfiguration, dépendent souvent des résultats de phases de calcul précédentes. Le modèle conçu permet à la fois de décrire le contrôle, la reconfiguration, le calcul et les interactions entre ceux-ci. À ce modèle on a associé un modèle d exécution faisant abstraction de l architecture matérielle idéale pour réaliser le modèle proposé. Le modèle d exécution proposé (associé à rkpn) est simple et ne pose pas des contraintes fortes sur le matériel hôte. Ceci permet de ne pas restreindre les plateformes d exécution à un ensemble particulier d architectures. Ensuite, on a défini une extension de langage permettant d exprimer le modèle de calcul rkpn. On a proposé le langage PLDL qui est un DSL spécifique à la radio réalisé par l extension d un langage généraliste existant par une bibliothèque logicielle implémentant les fonctionnalités radios (RVM API). Afin de vérifier la viabilité du langage proposé, les services d émission / réception de la couche physique du standard IEEE802.11a ont été implémentés en PLDL. Certes ce démonstrateur ne nous donne pas une idée sur les aspects temps réels du concept de MVR puisque la plateforme matérielle n est pas dédié pour ce genre de traitements. Cependant des résultats permettant d évaluer la productivité (réduction du temps de développement) et d avoir un idée sur des propriétés de la MVR telles que la taille du byte-code ou l espace mémoire requis, ont motivé notre exploration du concept de MVR pour continuer sa mise en œuvre sur une plateforme réaliste. Enfin, dans la dernière section on a proposé un dispositif qu on a appelé «programmable pipe», ou PP qui permet de définir des cœurs de traitement en logiciel et de les insérer dans la chaîne de calcul d une façon transparente à l utilisateur. Le PP est très utile pour implémenter des traitements spécifiques non fournis par des composants fonctionnels de l environnement MVR. Un exemple d utilisation du PP a été aussi présenté permettant de mieux comprendre l intérêt de ce dispositif. Dans le chapitre suivant nous allons expliquer notre réalisation du concept de MVR sur une plateforme radio logicielle réelle : le système sur puce MAGALI. 56

4 CHAPITRE Implémentation logicielle de la MVR sur MAGALI Sommaire Introduction........................................... 59 4.1 Aperçu du SoC MAGALI.................................. 60 4.1.1 Architecture et concepts fondamentaux de MAGALI................ 60 4.1.2 Environnements de simulation et de développement................ 64 4.1.3 Choix du circuit MAGALI comme plateforme de preuve de concept........ 67 4.2 Réalisation des primitives du PLDL sur MAGALI.................... 67 4.2.1 Architecture logicielle existante.......................... 67 4.2.2 Implémentation de la RVM API sur le SoC MAGALI................ 70 4.3 Extension de la machine virtuelle «Lua» en MVR................... 74 4.3.1 Machines virtuelles candidates........................... 75 4.3.2 Portage de la machine virtuelle «Lua» sur le processeur ARM1176JZF-S.... 77 4.3.3 Intégration globale................................. 78 4.4 Réalisation du dispositif «Programmable Pipe» (PP)................. 80 4.4.1 L association ARM-SME.............................. 80 4.4.2 Réalisation du PP et de ses primitives....................... 82 Conclusion............................................ 84 58

Introduction La réalisation de la MVR sur une plateforme de radio logicielle existante est une preuve de concept qui met en évidence la généricité du modèle de programmation proposé. Par ailleurs, cette étape nous permet de mieux comprendre les problématiques réelles évoquées dans la littérature et qui sont liées à la complexité de programmation des plateformes matérielles de radio logicielle. Dans ce chapitre, on explique notre implémentation logicielle de la MVR sur le circuit MAGALI. Le démonstrateur logiciel obtenu servira pour la réalisation d expérimentations permettant par la suite d évaluer le surcoût introduit par la MVR. Ce chapitre est organisé en quatre sections : D abord, on présente dans la section 4.1 un aperçu du circuit MAGALI. On expliquera alors son architecture et les principes fondamentaux qui régissent sa conception. Puis on présente l environnement logiciel de simulation et de développement associé au circuit. Dans la section 4.2, on détaille notre réalisation des primitives du langage de description de couches physiques (PLDL) sur le circuit MAGALI. On discutera alors l implémentation de chaque primitive et on justifiera nos choix conceptuels. Dans le section 4.3, on explique notre choix de la machine virtuelle à étendre en MVR et comment celle ci a été portée sur le processeur ARM du circuit. Par ailleurs, on montre comment l intégration des primitives du PLDL à la machine virtuelle a été réalisée. Enfin dans la section 4.4, on présente notre implémentation du dispositif «Programmable Pipe» (PP). On explique d abord le fonctionnement de l unité matérielle utilisée pour réaliser le PP et comment celle ci a été configurée. Puis on montre comment ce dispositif a été intégré à la MVR. NOCIF CCC Modulat. SME Mephisto (MIMO) OFDM OFDM CCC CCC CCC CCC CCC SME CCC ARM1176 CCC 8151 CCC SME CCC LDPC (UWB) CCC Mephisto (CFO/est.) CCC OFDM CCC SME CCC Mephisto (MIMO) CCC Mephisto (MIMO) CCC TurboC (ASIP) CCC NOCIF OFDM Mephisto (CFO/est.) De- Modulat. SME LDPC Wiflex CCC CCC CCC CCC CCC CCC FIG. 4.1: Le système sur puce MAGALI 59

4.1 Aperçu du SoC MAGALI 4.1 Aperçu du SoC MAGALI MAGALI (voir figure FIG.4.1) est un système sur puce (SoC) dédié à la réalisation des traitements nécessaires aux couches physiques et d accès au medium (MAC) des standards de télécommunication de quatrième génération telles que 3GPP-LTE ou IEEE802.16e (WiMax) [66]. Dans ce qui suit, on présente d abord le circuit en synthétisant les éléments clefs de son architecture. Ensuite, on présentera les environnements de simulation et de développement qui lui sont associés. 4.1.1 Architecture et concepts fondamentaux de MAGALI MAGALI est principalement constitué d un réseau sur puce (NoC) 2D-mesh asynchrone. le NoC est composé de routeurs ayant 5 ports interconnectés entre eux par des liens bidirectionnels. Chaque unité de traitement du système sur puce est connecté à un port du routeur. Il y a plusieurs types d unités de traitement sur MAGALI : des IP, DSP, DMA, etc. Les IP sont des composants matériels dédiés pour réaliser un algorithme spécifique de traitement du signal. Par exemple, les IP présentes sur MAGALI sont celles nécessaires pour la réalisation des traitements OFDMA : FFT/iFFT, LDPC, turbo-codeur/décodeur, etc. MAGALI contient trois types d unités logicielles programmables : l unité «Smart Memory Engine (SME) [67]» : est un DMA programmable capable de sélectionner et réordonner les données. L unité Mephisto est un DSP VLIW utilisé pour réaliser des calculs de fonctions spécifiques qui nécessitent une haute flexibilité. Exemple : estimation de canal, décodage MIMO, etc. ARM1176JZFS [68] est un processeur à usage général qui fournit la facilité de programmation nécessaire pour le contrôle global de l application radio et aux traitements de la couche MAC. Il peut être aussi utilisé pour configurer et contrôler les autres unités de traitement de MAGALI. Dans le circuit MAGALI chaque unité de traitement est connectée à un routeur à travers un bloc matériel appelé «Contrôleur de configuration et de communication (CCC) [69]», représenté sur la figure FIG.4.1 comme une enveloppe pour les cœurs de traitement. La programmation d une application radio sur MAGALI consiste alors à configurer ce contrôleur d une manière à activer et contrôler : les flux d entrée, le cœur de calcul et les flux de données en sortie pour chaque composant de la plateforme. Pour des raisons de performance, le CCC est capable de gérer des séquences complexes de configurations où le composant peut simultanément recevoir et envoyer des données de/vers différents autres composants et réaliser différents modes de calcul. Ces séquences complexes de configurations réduisent la quantité de travail du processeur central ARM et permettent aussi la prévention de la congestion de ses interfaces réseaux. Modèle flot de données à contrôle distribué Aujourd hui, les standards de communication radios ont évolué en complexité et leurs implémentations par des pipelines statiques d ASIC n est plus possibles. Les nouveaux standards impliquent une forte dynamique de configuration et de communication qui nécessite un contrôle hautement flexible réalisé souvent par un processeur central. Certes, un processeur à usage général offre une grande flexibilité pour implémenter l ordonnancement des unités de traitements de la plateforme d exécution. Cependant, les expérimentations antérieures réalisées sur le circuit FAUST (Flexible Architecture of Unified System for Telecom) [70] ont montré que cette solution n est pas suffisante pour permettre le passage à l échelle, lorsque le nombre d unités de traitement devient important. Le surcoût en performance devient ainsi très important et le processeur central sera le goulot d étranglement du système. 60

4.1 Aperçu du SoC MAGALI Network Interface Data Data Mux/ Demux Credit Data Credit Config Flow Control Exec End Data Config Core Exec End Control / Config CCC End of Task FIG. 4.2: Contrôleur CCC intégré dans une ressource de MAGALI Le SoC MAGALI représente la deuxième génération du circuit FAUST. L amélioration principale ramenée par MAGALI consiste dans l ajout du bloc CCC au sein de chaque unité de traitement fonctionnelle du circuit. Ainsi au lieu d un processeur central qui réalise tout le contrôle, le CCC est responsable de l ordonnancement des configurations : comme le montre FIG.4.2, il envoie les configurations et les signaux de contrôle au cœur de traitement et au module de gestion des flux de données. Ceci a pour résultat de relaxer les contraintes de latences auxquelles le processeur central devraient répondre. Cette amélioration découle d un retour d expériences d implémentation d applications radios réalisées sur le SoC FAUST. La programmation du SoC MAGALI consiste alors à déployer les configurations nécessaires sur chaque unité de traitement, conjointement avec le contrôle requis pour l ordonnancement de celles-ci. Le processeur central reste encore présent sur MAGALI, il permet de réaliser ce déploiement de configurations et aussi de synchroniser les phases macroscopiques d exécution d une application radio : Le processeur peut recevoir une interruption depuis les ressources de la plateforme pour calculer à la volée les paramètres des configurations à déployer lors de phases de calculs postérieures. Dans le même contexte, MAGALI introduit une nouvelle unité matérielle dédiée au stockage et à la manipulation des données appelée SME ou «Smart Memory Engine». Un des principaux rôles que peut jouer cette unité est le rôle de serveur de configuration : les unités de calcul peuvent être configurées pour récupérer leurs configurations depuis un SME particulier. Cela permet d éviter au processeur central d être constamment sollicité pour envoyer les configurations aux unités de traitement. Protocole de configuration et de communication À travers le réseau sur puce de MAGALI, différents types de messages peuvent circuler entre les unités de traitement. On peut les regrouper en trois catégories : messages de configuration : ils permettent d envoyer des paramètres basiques d initialisation, ou des micro-programmes qui décrivent l ordonnancement des configurations au sein d une unité, et les configurations elles-mêmes référencées dans ces micro-programmes. messages de communication : sur le circuit MAGALI le contrôle de flux entre les unités est régie par l usage d un protocole d échange de crédits/données. Une unité censé recevoir des données envoie des crédits à l unité émettrice lui indiquant qu elle est prête à recevoir autant de données que de crédits reçus. Ceci permet d éviter la retransmission de données perdues par l unité destinataire au cas où celle-ci a ses FIFO d entrées pleines. 61

4.1 Aperçu du SoC MAGALI Host A B C Cfg Base configuration Microprograms Execution command Enable task Distributed configuration Execution (phase 1) Dynamic reconfiguration Execution (phase 2) Execution (phase 3) Configuration requests/ responses Credit/Data exchange Configuration requests/ responses Credit/Data exchange End of task IT Credit/Data exchange End of task IT a) Diagramme de séquence des messages de l exemple A B End of task IT Data C Cfg Host Control command Configuration b) Topologie associée FIG. 4.3: Exemple du protocole de configuration et de communication sur MAGALI messages de signalisation : une unité de calcul qui a fini l exécution de son micro-programme peut envoyer un message de signalisation de fin de traitement au processeur. Les messages de contrôle envoyés par le processeur aux unités de traitement appartiennent à cette catégorie. Enfin, ce type de messages est utilisé aussi dans certains cas de passage de paramètres entre unités de traitement et le processeur central ou pour le debug d applications. Dans le diagramme de séquence des messages de la figure FIG.4.3(a) (figure extraite de [69]) on montre les échanges de messages selon le protocole de configuration et de communication défini sur la plateforme MAGALI. La figure FIG.4.3(b) est la topologie associée à l exemple considéré. Lorsque le système est mis sous tension, le processeur central démarre et charge les informations d initialisations telles que la topologie de la plateforme et les identifiants des ressources. Puis le processeur commence à exécuter le programme d ordonnancement global de l application radio à réaliser. Dans la FIG.4.3 la ressource «cfg» représente un serveur de configuration qui dispose préalablement de toutes les configurations nécessaires à l application considérée. La première étape à réaliser par le processeur 62

4.1 Aperçu du SoC MAGALI central de MAGALI consiste alors à envoyer les micro-programmes nécessaires au séquencement des configurations, à toutes les ressources de la plateforme. Ensuite, ce dernier envoie des messages «ET» (Enable Task) à toutes les ressources pour activer leurs traitements et se met en attente (éventuellement le processeur peut être utilisé pour faire un traitement spécifique qui ne nécessite pas une puissance de calcul élevée pendant cette phase d attente). Après cette étape, les unités de traitement s auto-configurent et enchaînent différentes phases d exécution d une façon autonome. Enfin, chaque unité de traitement envoie un message de signalisation de fin de traitement au processeur lorsqu elle a fini l exécution de son micro-programme. Architecture du contrôleur de configuration et de communication (CCC) Data Credit ICC OCC slots Data Core Data Credit OCC Data ICC slots OCC slots Mux/ Demux Config Config request Exec/End CFM Config Exec/End OCC ConfigID ICC ConfigID Core ConfigID Enable Task OCC µprg CTM OCC ICC µprg Core µprg Network Interface Interrupt Config data Dump request/ data End of Task Status from ICCs/OCCS/Core ITM Read/Write access to all adress map RWD CCC FIG. 4.4: Micro architecture d une unité de traitement du circuit MAGALI (figure extraite de [69]) Les blocs de base d une unité de traitement du circuit MAGALI sont : une interface réseau, un contrôleur de communication et de configuration (CCC) et un cœur de traitement. La micro architecture de ces blocs est présentée dans la figure FIG.4.4. L interface réseau appelé NI (Network Interface) est composé de : un multiplexeur/démultiplexeur qui distribue les messages en provenance du réseau vers chaque bloc fonctionnel de l unité de traitement. Il permet aussi d arbitrer la sortie des messages vers le réseau. Des contrôleurs d entrées/sorties sont associés aux FIFO du cœur de traitement. Ces contrôleurs sont appelés ICC et OCC (Input/Output Communication Controller). Les contrôleurs d entrées/sorties et le cœur de traitement ont chacun des slots de mémoires dans lesquelles sont stockées les configurations à exécuter. Ces configurations sont déployées et ordonnancées par 63

4.1 Aperçu du SoC MAGALI le contrôleur CCC. Le contrôleur CCC représente le gestionnaire des configurations et des communications d une unité de traitement. Il est principalement composé des quatre contrôleurs suivants : RWD (Read-Write Decoder) : il reçoit des paquets de type «move», décode ceux ci et écrit les données encapsulées à l adresse mémoire spécifiée dans le paquet. Ce composant adresse tous les registres de configurations de l unité. RWD peut aussi recevoir des paquet de type «dump request» utilisés pour le debug. Dans ce cas il réalise un accès aux registres en lecture, encapsule les données lues et les envoie sous la forme d un paquet réponse «dump data». CTM (Context Manager) : c est le bloc qui reçoit les micro-programmes d ordonnancement des configurations pour tous les ICC, OCC et cœurs de traitement présents dans l unité en considération. Dans le jargon de MAGALI ces micro-programmes sont appelés des contextes. Lorsque le CTM reçoit un message de type «Enable Task» il commence à ordonnancer les configurations. Enfin quand il termine l exécution de tous les micro-programmes, il peut envoyer un message «End of Task» pour notifier le processeur central. CFM (Configuration Manager) : ce composant vérifie la présence d une configuration dans le slot approprié (lors de l exécution du micro-programme d ordonnancement de configuration). Dans le cas ou elle n a pas été préalablement chargée, il envoie une requête de configuration au serveur de configuration associé à la ressource, s assure que la configuration soit chargée dans le slot spécifié et attend les notification de fin d exécution de la part des ICC/OCC et le cœur de traitement. ITM (Interrupt Manager) : c est le composant responsable de vérifier l état de la ressource. Il envoie des interruptions au processeur central selon des masques d interruptions préprogrammés. L interruption «End of Task» est la plus utilisée pour notifier la fin de traitement d une ressource. 4.1.2 Environnements de simulation et de développement Au circuit MAGALI sont associés des environnements de simulation et de développement intégrant un ensemble d outils et de logiciels permettant de réaliser et de simuler au cycle près des applications radios à déployer directement sur la plateforme réelle. Cet environnement est basé sur des technologies diverses et de multiples outils : des logiciels libres, par exemple, gcc-g++, make, binutils, QEMU [71], SystemC [72, 73], etc. des outils propriétaires, par exemple, ModelSim [74] de Mentor Graphics, SimVision de Cadence, des bibliothèques logiciels SystemC/VHDL de ST Microelectronics et de ARM. des outils «maison» développés au sein du laboratoire LISAN (Laboratoire Intégration Silicium des Architectures Numériques) du CEA/Leti. Par exemple : le compilateur SME qui génère le microprogramme exécutable à partir d un code écrit en pseudo C. Environnement de co-simulation SystemC/VHDL L environnement de simulation du circuit MAGALI fournit pour chaque IP un modèle SystemC et son équivalent VHDL. Cette double modélisation est importante : la modélisation SystemC au niveau transactionnel (TLM) est utile pour valider rapidement et fonctionnellement l unité de traitement considérée. Quant à la modélisation VHDL au niveau transfert de registres (RTL) est une représentation d un niveau d abstraction encore plus fin, qui rapporte plus de précision au niveau temporelle et qui est nécessaire pour la synthèse du circuit. 64

4.1 Aperçu du SoC MAGALI En effet, Calazans et al. expliquent dans [75] que le modèle transactionnel est temporisé mais n est pas précis au cycle près. Cette modélisation permet d abstraire l horloge et les protocoles spécifiques de communications entre les éléments du système modélisé. En résumé, le modèle transactionnel réduit l effort nécessaire à la conception et accélère le temps de simulation. Il est possible de passer rapidement d une modélisation SystemC de niveau transactionnel à une modélisation SystemC de niveau RTL par un raffinement du premier modèle. Une modélisation SystemC de niveau RTL peut être traduite automatiquement en VHDL en utilisant des outils comme «SystemC Compiler» de Synopsys, «Catapult C» de Mentor, etc. Application Application ISS ARM QEMU ARM CORE SME MEM Application SME MEM CPU Bridge SME MEM CPU Bridge CCC CCC CCC i/ FULL_SYSTEMC mode ii/ QEMU_SYSTEMC mode iii/ FULL_RTL mode SystemC simulation Host binary code Hardware ARM binary code FIG. 4.5: Différents modes de simulation du processeur ARM sur MAGALI Le processeur ARM présent sur MAGALI est une unité particulière du circuit : c est une unité logicielle de traitement, qui d une part, peut jouer le rôle d un DSP, d autre part, est le contrôleur central de MAGALI qui a accès à toutes les autres unités de traitement. Sur l environnement de simulation de MAGALI, cette unité peut être simulée au choix selon l un des trois modes suivants (voir figure FIG.4.5) : i FULL_SYSTEMC : le code de l application de contrôle est compilé et lié avec le code la simulation SystemC. Par suite il est exécuté directement par la machine hôte de la plateforme de simulation. Ce mode de simulation est appelé souvent HCE (Host Code Execution). ii QEMU_SYSTEMC : Le code de l application de contrôle est compilé en un binaire exécutable compatible avec l architecture ARM. Un ISS (Instruction Set Simulator) ARM intégré au modèle SystemC de MAGALI exécute ce code. L ISS ARM consiste en une machine virtuelle QEMU configurée pour simuler un processeur ARM sur la machine hôte. iii FULL_RTL : ce mode de simulation utilise le modèle VHDL de l ARM1176JZFS de MAGALI. Sur le circuit réel MAGALI on remarque la présence de deux interfaces matérielles représentées par les «Nocif» dans la FIG.4.1. Celles-ci lui permettent de communiquer avec l extérieur. Dans la réalité, le circuit tel qu il est intégré dans la carte du démonstrateur, est connecté d une part avec la partie RF. D autre part, il est lié à un ordinateur à travers un port Ethernet. Sur la plateforme de simulation, des unités virtuelles codées en SystemC ont été rajoutées pour pouvoir piloter la plateforme. Les unités supplémentaires sont principalement : GEN : cette unité permet d envoyer un flux de données vers le réseau sur puce. Elle est configurée avec un fichier contenant les valeurs en représentation hexadécimal des données à envoyer. REC : à l inverse de l unité GEN, elle reçoit un flux de données depuis le réseau sur puce. Elle sauvegarde les valeurs en entrées dans un fichier. FAKE_CPU : est un faux processeur, qui exécute exclusivement des programmes écrits selon une API particulière. Ces programmes appelés scénario (fichiers ayant l extension.sno) sont interprétés direc- 65

4.1 Aperçu du SoC MAGALI tement par le faux processeur et permettent le déploiement des configurations et du contrôle sur les différentes unités de la plateforme. Cependant, le faux processeur n est pas capable de réaliser des calculs sur les données ni de créer les configurations à déployer. Celles-ci sont construites au préalables, stockés dans des fichiers (ayant l extension.cfg) et référencées dans le programme d une façon statique. L unité FAKE_CPU est un processeur à temps nul, qui permet d éviter la complexité de programmation du processeur ARM et surtout de valider fonctionnellement et rapidement des applications radios. Environnement de développement associé au circuit MAGALI Le circuit MAGALI représente une plateforme hétérogène de radio logicielle. La programmation d un standard radio sur ce circuit nécessite au préalable : la compréhension et la maîtrise des modes de fonctionnement de chaque IP, la façon de les configurer et aussi comment manipuler le réseau sur puce. L hétérogénéité des IP présents sur MAGALI impliquent l usage de différents outils et processus de développement. Description des flots de données COMC Application binaires des config. Code C MAGALI FIG. 4.6: Compilateur de communication COMC Une application radio peut être considérée comme un ensemble de configurations et de programmes d ordonnancement de celles-ci, à déployer sur les unités de traitement de la plateforme. A cela s ajoute un programme de contrôle global qui sera exécuté par le processeur central (le processeur ARM dans notre cas). Pour faciliter le développement d applications radios sur MAGALI, le compilateur de communications «COMC» a été développé au LISAN. Cet outil permet de générer à partir d une description abstraite d une application radio, l ensemble des binaires de configuration à déployer sur la plateforme et du code C support à lier avec le programme principal de contrôle (voir figure FIG.4.6). La description abstraite du flot de données de l application est modélisée par plusieurs fichiers XML. Trois types de fichiers sont nécessaires : Un fichier de topologie qui décrit les positions relatives des IP sur la plateforme. Un fichier qui indique à chaque unité le serveur de configuration auquel elle est rattachée. Un fichier de description du flot de données qui énumère les configurations pour chaque unité et indique les fichiers qui contiennent les binaires correspondants. Ce fichier contient aussi les informations concernant l ordonnancement de ces configurations et ceux des communications. D autres outils d aide au développement sur la plateforme MAGALI sont fournis. On cite, par exemple, le compilateur de configurations de cœurs de traitement appelé CORECFGC : il génère le binaire de confi- 66

4.2 Réalisation des primitives du PLDL sur MAGALI guration exécutable d une IP à partir de fichiers de paramètres au format textuel. Un autre outil est COM- PILO_CTX : il génère le micro-programme d ordonnancement des configurations, exécutable par le contrôleur CCC de chaque IP. Un environnement de développement à partir d outils libres est aussi fourni pour l unité ARM. Il est principalement constitué d une chaîne de développement croisée (gcc/g++, gdb, binutils, etc). ecos [76] est un système d exploitation temps réel dédié pour les systèmes embarqués a été porté sur la plateforme MAGALI pour faciliter le développement sur le circuit. Ce système d exploitation a l avantage d être totalement modulaire et facilement configurable. Le portage de ce système sur une plateforme donnée consiste à écrire le module HAL (Hardware Abstraction Layer) associé aux caractéristiques de la plateforme cible (adresse map de la mémoire, vecteurs d interruptions, horloge, timers, etc). Un outil graphique appelé «Configtool» est fourni avec ecos permet de générer rapidement diverses configurations (ajout/suppression de modules, paramétrage, etc) du système d exploitation. 4.1.3 Choix du circuit MAGALI comme plateforme de preuve de concept Le SoC MAGALI remplit plusieurs critères qui ont motivé notre choix pour la réalisation de la MVR sur cette plateforme. D abord, c est un circuit qui s adresse à la réalisation des standards de télécommunications de quatrième génération. Il est constitué d IP optimisées et par suite a suffisamment de puissance de calcul pour répondre aux défis de la radio logicielle. Ensuite, l utilisation d une telle plateforme hétérogène est un moyen pour évaluer notre modèle de programmation vis à vis de plusieurs familles d unités de traitement avec différents niveaux de configurabilité et de programmabilité. Nous considérons, qu au cas où il s avère que notre modèle est capable de réaliser ses objectifs sur ce circuit, il serait évident qu il le soit aussi sur des plateformes homogènes comme les plateformes DSP-centric citées dans le chapitre de l état de l art de ce manuscrit. Un autre avantage de ce circuit est qu il est capable de réaliser en logiciel les calculs spécifiques auxquels des IP dédiées n ont pas été prévues. Ceci représente un moyen pratique permettant d évaluer les capacités de la plateforme à réaliser les standards émergents. Enfin, l environnement logiciel associé à MAGALI rassemble tous les outils nécessaires pour prototyper efficacement la MVR : un système d exploitation temps réel, un simulateur de jeux d instruction pour le processeur ARM, un modèle SystemC pour des simulations rapides, et une carte d évaluation pour des expérimentations dans des conditions réelles. 4.2 Réalisation des primitives du PLDL sur MAGALI On rappelle tout d abord que les primitives du langage de description de couches physiques (PLDL) ont été décrites dans le chapitre précédent (voir la section 3.2). Celles-ci expriment le modèle de programmation rkpn qu on a proposé. Dans cette partie, nous allons présenter l architecture logicielle existante sur le SoC MAGALI. Puis nous détaillerons comment chaque primitive du PLDL a été implémentée. L ensemble de ces primitives, appelé RVM API, formera par la suite une extension d un langage interprété existant afin de garantir l indépendance du code exécutable vis à vis de l architecture du processeur de contrôle cible. 4.2.1 Architecture logicielle existante FAUST2_API est la première couche logicielle d abstraction matérielle qui a été développée sur le processeur ARM1176JZFS du SoC MAGALI. Cette couche représente la couche «drivers», appelé aussi BSP (Board Support Package). La nomination FAUST2 résulte du fait que MAGALI est considéré comme la deuxième génération du circuit FAUST. 67

4.2 Réalisation des primitives du PLDL sur MAGALI CCC configurations Core configurations ITM MTM CTM CFM... MEP TX bit OFDM... Configurations CCC configurations SME configuration CORE configurations NoC Protocol Send config. Send data Send credits Enable task Request session... HAL Network Registers Paths SME FIG. 4.7: Découpage de l API FAUST2 Les primitives de FAUST2_API sont simples et traduisent exactement les fonctionnalités natives fournies par le matériel. Par exemple, envoyer une configuration à une IP ; envoyer un message de signalisation pour activer le traitement d une IP ; ect. Bien que ces primitives soient de bas niveau d abstraction, la couche FAUST2_API est découpée en différents sous-niveaux d abstraction qui sont intimement liés à la structure du circuit. La figure FIG.4.7 montre une représentation structurelle de la couche FAUST2_API selon les parties suivantes : HAL (Hardware Abstraction Layer) : cette sous couche fournit les primitives indispensables pour configurer les unités (communication dans le NoC, accès à la mémoire, description des registres et de l adresse map). Le niveau HAL est suffisant pour programmer la plateforme. Un exemple de primitives de niveau HAL : f2_write_packet permet d envoyer un paquet binaire de données dans le NoC ; f2_get_packet_fifo_free permet de connaître la taille de l espace disponible dans la fifo d envoi de données de l ARM. La description des registres internes de chaque IP ansi que les opérations élémentaires associées (exemple, le formatage de données selon les champs d un registre) sont fournis sous forme de macros en langage C. Exemple : / D e f i n i t i o n s f o r r e g i s t e r f i e l d SOURCE_ID / 2 # d e f i n e ITM_CONFIG_CONFIG_1_SOURCE_ID_OFFSET 18 # d e f i n e ITM_CONFIG_CONFIG_1_SOURCE_ID_SIZE 7 4 # d e f i n e ITM_CONFIG_CONFIG_1_SOURCE_ID_SET ( _ v a l _ ) \ SET_VAL( _ v a l_, ITM_CONFIG_CONFIG_1_SOURCE_ID ) Le routage sur le circuit MAGALI se fait selon la technique «wormhole» ou «trou de ver». C est une méthode simple qui consiste à ajouter l information du chemin, depuis l unité source jusqu à l unité destination, dans l entête du paquet à transmettre. Cette entête permet de configurer les routeurs du NoC pour réserver le chemin indiqué jusqu à la transmission de tous les flits de données de ce paquet. La définition des chemins se fait par une succession de directions définies par des macros en langage C. Exemple : 68

4.2 Réalisation des primitives du PLDL sur MAGALI 1 # d e f i n e UNDEF 0 # d e f i n e NORTH 0 3 # d e f i n e EAST 1 # d e f i n e SOUTH 2 5 # d e f i n e WEST 3 # d e f i n e PATH( path0, path1,..., p a t h 8 ) ( path8 < < 1 6 +... + path1 <<2+ p a t h 0 ) 7 / Example / 9 unsigned i n t my_path ; my_path = PATH(NORTH, EAST, SOUTH,WEST, EAST, UNDEF, UNDEF, UNDEF,UNDEF ) ; NoC Protocol : ce niveau s appuie sur les primitives d envoi de paquets de la sous couche HAL, et permet de générer les différents types de paquets propres au NoC MAGALI. Les principales primitives de cette sous couches sont les suivantes : f2_write_data : envoie le contenu d un tampon de données vers une unité de traitement du circuit. Cette primitive s occupe du découpage des données en plusieurs paquets et de leurs encapsulation. f2_write_cfg_data : envoie un ou plusieurs paquets de configurations vers le contrôleur CCC d une unité de traitement. f2_send_credits : envoie des crédits au module de gestion de flots de données de l unité dont l identifiant est passé en paramètre. il faut aussi préciser : l identifiant de l unité qui devrait recevoir les données, le numéro de fifo d entrée et le nombre de places libres dans la fifo (le nombre de crédits). f2_write_enable_task : Cette fonction permet d activer (resp. désactiver) la tache courante sur l unité de traitement dont l identifiant est passé en paramètre. Configurations : s appuyant spécifiquement sur la primitive d envoi de configurations f2_write_cfg_data, ce niveau propose des fonctions de configuration dédiées respectivement aux cœurs de traitement, aux différents contrôleurs du CCC, et aux SME. La configuration d un cœur de traitement utilise la primitive f2_send_core_config. La configuration du contrôleur CCC se fait par bloc fonctionnel. Les SME sont configurés avec des micro-programmes résultants d un processus de compilation. CCC configuration : permet de configurer les différents blocs fonctionnels du CCC (bloc de gestion des interruptions ou ITM (Interrupt Manager), bloc de gestion de la multi-tache ou MTM (Multi-Task Manager, bloc d ordonnancement des configurations ou CTM (Context Manager), etc). Core configuration : chaque cœur de traitement possède son propre modèle de programmation. Pour cela, à chaque cœur on a associé une API spécifique. Malgré les différentes API de construction de configurations associées à chaque IP, toute configuration cœur se résume en un binaire qui sera envoyé par l API du niveau Configurations. Pour démarrer le processeur et initialiser ses registres internes, on utilise le système d exploitation ecos avec une configuration minimaliste. Cette configuration appelée «Minimal Kernel» contient, en plus du module FAUST2 HAL, les modules suivants : Common error code support Dynamic memory allocation I/O Sub-system ISO C and POSIX infrastructure Serial Device Driver ecos Common HAL ecos Kernel 69

4.2 Réalisation des primitives du PLDL sur MAGALI En résumé, une architecture logicielle classique (système d exploitation + couche «drivers») a été développée sur le circuit MAGALI. La programmation d une application radio sur cette architecture logicielle existante nécessite un effort considérable pour le codage et un long cycle d apprentissage des spécificités du circuit. Certes, les primitives de bas niveau d abstraction de cette architecture permettent au programmeur de réaliser des programmes fortement optimisés. Cependant, le code résultant de la compilation n est exécutable que sur le processeur ARM et n est valide que sur la plateforme MAGALI. 4.2.2 Implémentation de la RVM API sur le SoC MAGALI Dans cette partie, on s intéressera à l implémentation de la couche RVM (Radio Virtual Machine) API. Cette couche logicielle vient se greffer au dessus de l architecture existante pour fournir un haut niveau d abstraction, qui exprime le modèle de programmation rkpn et qui est indépendant de la plateforme de radio logicielle cible. On présentera alors les structures de données définies et les détails d implémentation de chaque primitive de la RVM API. Structures de données Le Système sur puce (SoC) est modélisé comme une liste de réseaux sur puces (NoC) interliés à travers des interfaces dédiées représentés dans la figure FIG.4.1 par les «NOCIF». Ceci afin de permettre d interconnecter le NoC MAGALI avec un autre NoC externe. Un NoC est modélisé comme une liste de ressources. t y p e d e f s t r u c t { 2 s t r u c t s _ t o p o _ s o c soc ; / r é f é r e n c e du SoC a u q u e l i l e s t a s s o c i é / t _ u i n t 3 2 i d ; / i d e n t i f i a n t du NoC / 4 t _ u i n t 3 2 s i z e _ x ; / l a r g e u r du NoC / t _ u i n t 3 2 s i z e _ y ; / l o n g u e u r du NoC / 6 } t _ t o p o _ n o c ; Chaque ressource de la plateforme est modélisé comme un nœud dans une grille a deux dimensions et caractérisé par ses cordonnées (x, y). La structure suivante définit la topologie du système sur puce : t y p e d e f s t r u c t { 2 t _ t o p o _ n o c noc ; / r é f é r e n c e du NoC a u q u e l i l e s t a s s o c i é / t _ u i n t 8 x ; / a b c i s s e / 4 t _ u i n t 8 y ; / ordonnée / t _ u i n t 8 r o u t e r _ p o r t ; / p o r t du r o u t e u r a u q u e l i l e s t r a t t a c h é / 6 t _ u i n t 8 i d ; / i d e n t i f i a n t du noeud / } t _ t o p o _ r e s ; Pour la gestion des ressources du circuit MAGALI, on a défini des structures de données qui pour chaque ressource décrivent : son type. 1 t y p e d e f enum { r e s _ t y p e _ c p u = 0, r e s _ t y p e _ t r x _ o f d m, 3 res_type_sme,... 5 } enum_res_type ; 70

4.2 Réalisation des primitives du PLDL sur MAGALI sa structure. 1 t y p e d e f s t r u c t { t _ u i n t 8 n b _ f i f o _ i n ; / nombre de \ t e x t s c { f i f o } d e n t r é e / 3 t _ u i n t 8 n b _ f i f o _ o u t ; / nombre de \ t e x t s c { f i f o } de s o r t i e / t _ u i n t 8 nb_core ; / nombre de \ t e x t s c { f i f o } de core / 5 } t _ s t r u c t u r e _ r e s o u r c e ; Enfin, on a défini une structure de donnée qui représente le catalogue global des ressources de MAGALI. Cette structure contient des informations concernant : l état des ressources de la plateforme (allouée, libre, etc), le nombre d unité de même type et les références de chaque ressource. 1 t y p e d e f s t r u c t { t _ t o p o _ r e s cpu ; / r é f é r e n c e du p r o c e s s e u r c e n t r a l / 3 t _ t o p o _ r e s r e s o u r c e s ; / i n d e x des r e s s o u r c e s i d e n t i f i é s par ( t y p e de r e s s o u r c e, r é f é r e n c e ) / 5 t _ u i n t 8 n b _ r e s o u r c e s ; / nombre de r e s s o u r c e de même t y p e / t _ u i n t 8 i s _ a l l o c a t e d ; / i n d e x d é t a t des r e s s o u r c e s / 7 } t _ p l a t f o r m ; Les primitives de la RVM API manipulent les structures de données précédentes pour la gestion des ressources de MAGALI. L implémentation de ces primitives utilisent aussi plusieurs autres structures de données définies dans la FAUST2 API. Allocation/libération des ressources radios Allouer un opérateur fonctionnel de traitement du signal revient à réserver une ressource depuis le catalogue global qui référencie les unités de traitement de MAGALI. Ensuite, il faut initialiser les registres internes de la ressource afin de la préparer pour l exécution de la fonctionnalité attendue. La fonction rvm.allocate permet ainsi d envoyer les micro-programmes d ordonnancement des configurations (configuration du cœur de traitement, des ICC et des OCC), appelés aussi «contextes» au bloc CTM du CCC. Un «contexte» est un microcode écrit selon un jeu d instruction simple détaillé dans le tableau TAB.4.1. Codeop, opérande(s) rc c s rcl c s ll n gl n lli r gli r stop Description Demande la configuration c depuis le slot s et l exécute Demande la configuration c depuis le slot s, l exécute et mém- -orise la position de l instruction courante pour l instruction ll Retourne à la position stockée de boucle. Boucler n fois Retourne à la première instruction. Boucler n fois Retourne à la position stockée de boucle. Boucler autant de fois que la valeur du registre r Retourne à la première instruction. Boucler autant de fois que la valeur du registre r fin du micro-programme TAB. 4.1: Jeu d instruction du CCC qui manipule les configurations stockées dans les slots de la mémoire interne aux unités de traitement 71

4.2 Réalisation des primitives du PLDL sur MAGALI Pour allouer une ressource, nous utilisons des micro-programmes triviaux permettant de séquencer les configurations ICC, OCC et celles des cœurs de traitement. Voici Le modèle de micro-programme utilisé : 1 RC i i / R e q u e s t c o n f i g u r a t i o n i from s l o t i and e x e c u t e i t / STOP Il consiste à faire exécuter un contrôleur ICC, un contrôleur OCC ou un cœur de traitement, la configuration i stockée dans le i eme slot. En fait, chaque unité de traitement peut incorporer plusieurs contrôleurs d entrées et/ou de sortie (ICC, OCC). Chacun de ces contrôlleurs a besoin d un micro-programme différent. Les unités de traitement du circuit MAGALI disposent d assez de slots mémoire pour stocker au moins une configuration pour chaque contrôleur. Les slots mémoire de configuration sont organisés par type (ICC, OCC, ou cœur de traitement). Dans ce cas, le i eme ICC utilisera la configuration ayant l identifiant i stockée dans le i eme slot de configuration des ICC. De la même façon, les OCC et les cœurs de traitement gèrent leurs configurations. Certes, ce modèle de micro-programme simpliste annule l intérêt du CCC par contre il adapte l infrastructure logicielle du circuit au modèle de programmation rkpn qui est plus générique. Libérer une ressource radio consiste à changer l état de celle ci de réservée à libre dans le catalogue global des unités de traitement. De plus, les micro-programmes déployés seront effacés du CCC de l unité considérée. Configuration des ressources radios La configuration d une ressource radio telle qu on l a définit consiste à spécifier : les paramètres fonctionnels du composant considéré. Par exemple pour la ressource TRX_OFDM on spécifie si c est une FFT ou une ifft, sa taille (64, 128, 256, 512 ou 1024 points), etc. En effet, Les interfaces de configuration des opérateurs communs aux chaînes de traitement radios doivent être standardisées. Dans notre cas on utilise les mêmes interfaces fournis par les ressources du circuit MAGALI. les paramètres de communications représentés par les nombres d unités de données à recevoir et à transmettre. Dans notre cas, cette unité est appelé «flit» et elle consiste en un mot de 32 bits. les évènements à être considérés par la ressource pour notifier le processeur central de leurs occurrences. Par exemple : lorsqu une ressource termine son exécution elle peut envoyer une notification au processeur central. La configuration des ressources radios se fait en deux étapes : d abord la création des configurations puis leur envoi aux slots mémoires appropriés du CCC. La primitive rvm.build_core_config reçoit les paramètres fonctionnels d une ressource du SoC MAGALI et génère le binaire correspondant à sa configuration. Cette primitive repose sur les fonctions de configuration des cœurs de traitement. Par exemple : pour configurer une FFT on fait appel à la fonction suivante de configuration d une ressource de type TRX_OFDM : t _ u i n t 3 2 r v m _ t r x _ o f d m _ b u i l d _ c f g _ p c k ( t _ u i n t 3 2 b y p a s s _ f f t, 2 t _ u i n t 3 2 f f t _ t y p e, t _ u i n t 3 2 l o g 2 _ s i z e _ f f t, 4 t _ u i n t 3 2 norm_power, t _ u i n t 3 2 g i _ i n s e r t i o n, 6 t _ u i n t 3 2 g i _ s i z e, t _ u i n t 3 2 s h i f t _ c a r r i e r, 8 t _ u i n t 3 2 s h i f t _ p a r i t y, t _ u i n t 3 2 f l o c, 10 t _ u i n t 3 2 maskit, t _ u i n t 3 2 mask_data [ 6 4 ], 12 t _ u i n t 3 2 m a s k _ p i l o t [ 6 4 ] ) 72

4.2 Réalisation des primitives du PLDL sur MAGALI Cette fonction réalise le formatage des paramètres selon les registres de configuration de l unité TRX_OFDM. L unité TRX_OFDM réalise trois opérations successives selon sa configuration : i/ en mode transmission : «framing» / ifft / ajout de l intervalle de garde. ii/ en mode réception : «deframing» / FFT / normalisation des puissances (pour que le module des valeurs complexes des fréquences en sortie soit égale à 1). Le «framing» consiste à créer la fenêtre de fréquences à partir de deux flux de données en entrées : un premier flux de données utiles et un deuxième flux de données pilotes. Le «deframing» est l opération inverse. La primitive rvm.build_com_config est la fonction qui construit les configurations de communications. Celles-ci correspondent à des configurations des contrôleurs d entrées/sorties (ICC et OCC). Un OCC a besoin de connaître principalement le nombre de données à envoyer, vers quelle unité et vers quel numéro de port (ICC). De la même façon un ICC a besoin de connaître le nombre de données à recevoir, depuis quelle unité et quel numéro de port (OCC). Enfin la primitive rvm.configure envoie la configuration fonctionnelle vers le cœur de traitement, la configuration de communication vers les ICC et les OCC, et enfin une configuration de l ITM pour que la ressource en question envoie une notification de fin de traitement au processeur central. La primitive rvm.connect construit les liens du graphe rkpn. Cette primitive configure l ICC spécifié en paramètre par un couple (unité de traitement destinatrice, numéro de port destination) pour qu il reçoive les données en provenance de l OCC spécifié par le couple (unité de traitement source, numéro de port source). En fait, cette primitive complète la configuration des contrôleurs ICC/OCC réalisé lors de l appel de la primitive rvm.configure par l ajout de l information du chemin depuis l unité source vers l unité destination au niveau de l OCC et inversement au niveau de l ICC. Le chemin qui lie les deux ressources du SoC MAGALI est calculé par la fonction topo_get_path de la FAUST2 API. Cette fonction implémente l algorithme de routage XY [77] qui consiste à se déplacer d abord horizontalement jusqu à atteindre l abscisse de la ressource destinatrice. Puis se déplacer verticalement jusqu à atteindre la destination. Cet algorithme a l avantage d être déterministe et ne présente pas d interblocage. Contrôle de l exécution Le contrôle sur MAGALI consiste principalement en l activation de l exécution des ressources par la primitive rvm.start. L arrêt de l exécution est spontanée à la fin du traitement et ne nécessite pas un contrôle explicite. Cependant, pour des raisons de debug, on peut forcer l arrêt d une ressource avant la fin de son traitement en faisant appel à la fonction rvm.stop. L implémentation de la primitive rvm.start (respectivement rvm.stop) consiste en l envoie d un paquet de type «Enable Task» (respectivement «Disable Task» vers le CCC de l unité à activer (respectivement désactiver). La synchronisation des phases de configuration et de contrôle se fait par un appel à la fonction rvm.wait qui bloque le processeur central jusqu à l arrivée d une interruption de fin de traitement depuis une ressource pré-configurée. L implémentation de cette primitive consiste à bloquer un sémaphore. Lorsqu une interruption de fin de traitement est reçue par le processeur, la routine associée libère le sémaphore. Pour implémenter cette routine, nous utilisons les services de gestion d interruption d ecos : / I n t e r r u p t S e r v i c e R o u t i n e / 2 c y g _ u i n t 3 2 i s r _ f u n c t i o n ( c y g _ v e c t o r _ t v e c t o r, cyg_addrword_t d a t a ) Cette fonction est exécutée directement à chaque réception d une interruption. Dans une ISR (Interrupt Service Routine), l usage de sémaphore n est pas permis par ecos. Pour cela, dans cette fonction, on sauvegarde 73

4.3 Extension de la machine virtuelle «Lua» en MVR seulement les données de l interruption dans un tableau. / D i f f e r e d S e r v i c e R o u t i n e / 2 v o i d d s r _ f u n c t i o n ( c y g _ v e c t o r _ t v e c t o r, cyg_ucount32 count, cyg_addrword_t d a t a ) Cette fonction est appelée routine d interruption différée : Dans la plupart des cas, elle est appelée directement après l ISR. Dans le cas d occurrence de plusieurs interruptions en rafale, l ISR est invoquée autant de fois que d interruptions, puis un seul appel à la fonction DSR est réalisé pour traiter toutes les interruptions. Dans une DSR l usage des sémaphore est permis. Accès au flot de données L accès au flot de données sur le SoC MAGALI est fait classiquement de la manière suivante : Configuration d un DMA particulier qui partage le même espace mémoire avec le processeur ARM pour recevoir les données en provenance de la chaîne de traitement. le DMA envoie une notification de disponibilité de données au processeur ARM à la réception du nombre spécifié d unités de données. le processeur ARM accède en lecture/écriture sur l espace mémoire connu d avance. Les fonctions utilisées sont alors celles présentées précédemment. Celles qui sont appliquées au DMA sont rvm.configure et rvm.start. rvm.wait est éxécutée par la MVR pour la synchronisation avec la disponibilité des données. Nous rappelons que les DMA se trouvent dans le composant SME (jusqu à 4 DMA par SME). Enfin on a implémenté les fonctions qui permettent les opérations de lecture / écriture suivantes : t _ u i n t 3 2 rvm_mem_read ( t _ u i n t 3 2 addr ) 2 { t _ u i n t 3 2 d a t a = addr ; 4 r e t u r n d a t a ; } 6 v o i d rvm_mem_write ( t _ u i n t 3 2 data, t _ u i n t 3 2 addr ) 8 { addr = d a t a ; 10 } On suppose que les données en provenance du flot de données suivent un format natif connu. Exemple : on sait que le flux en sortie d une ressource FFT est un flux de nombres complexes ; chaque nombre complexe est codé en virgule fixe avec une convention spécifique sur 32 bits (16 bits pour la partie réelle et 16 bits pour la partie imaginaire). Nous avons implémenté les fonctions de conversion pour chaque type de données natif en format de type de données de la machine virtuelle. 4.3 Extension de la machine virtuelle «Lua» en MVR La couche logicielle RVM API qu on a présentée dans la partie précédente permet d implémenter notre modèle de calcul rkpn. Bien que les primitives de la RVM API soient de haut niveau d abstraction, le code de l application radio reste encore dépendant du processeur cible (ARM). Dans ce contexte, nous avons rajouté la machine virtuelle au dessus de la couche RVM API pour se séparer totalement de la plateforme cible (voir figure FIG.4.8). Le code exécutable est alors un bytecode qui exprime le contrôle et la configuration des ressources d une plateforme radio logicielle quelconque. 74

4.3 Extension de la machine virtuelle «Lua» en MVR Machine Virtuelle RVM api Faust2 api ecos RTOS Hardware FIG. 4.8: Architecture logicielle de la machine virtuelle radio 4.3.1 Machines virtuelles candidates La MVR est une machine virtuelle dédiée au domaine spécifique de la la radio. Une machine virtuelle (VM) dans un environnement PC est considérée comme un processeur virtuel ayant son propre jeu d instructions. Dans un schéma classique d exécution, la VM interprète le bytecode (programme compilé selon le jeu d instruction de la VM) sur la plateforme cible. Ainsi pour chaque instruction du bytecode, la VM réalise un ensemble d opérations sur l architecture hôte (exemple : décodage de l instruction, recherche des opérandes en mémoire, exécution de l opération, etc). Les VM représentent les données selon des formats qui leurs sont propres et manipulent différentes structures de données (pile d exécution, un tas pour les allocations dynamique de mémoire et l instantiation d objets, des descripteurs d objets, des tables, etc). La MVR comme tout processeur n est pas capable de réaliser à elle seule tous les traitements nécessaires à la radio. Elle fait alors usage des accélérateurs matériels qui sont implémentés par les IP de la plateforme hôte de radio logicielle. Traditionnellement, les VM font appel à des primitives implémentées en code natif pour accéder au matériel. Le langage de la VM fournit ainsi une abstraction de haut niveau permettant de piloter le matériel. Dans la plupart des cas, les appels de fonctions natives sont implémentées en interne au moteur d exécution de la VM et l extension par l utilisateur n est pas permise ou bien elle nécessite un effort considérable de développement avec l usage de logiciels support (exemple : JNI (Java Native Interface)). En effet, l intégration de modules propriétaires implémentés en code natif par l utilisateur fait perdre la notion de portabilité et dans ce cas la VM n a plus de raison d être. Certains langages appelés langages d extension intègrent des méthodes permettant d encapsuler de nouvelles structures de données et d invoquer des méthodes natives agissant sur celles-ci. Afin de réaliser notre démonstrateur de MVR, nous avons choisi de réutiliser une machine virtuelle logicielle existante et de l étendre avec les mécanismes propres à la radio logicielle. Pour cela, nous avons mené une étude comparative sur une large liste de VM existantes (voir Annexe B). La VM à étendre en MVR doit répondre à un ensemble de critères : doit avoir un code libre et de préférence disponible pour un large ensemble des processeurs embarqués classiques (ou être facilement portable en utilisant un compilateur C pour l architecture cible). Pour notre cas d étude, on aura besoin d une version pour ARM11. Une faible empreinte mémoire et une haute performance d exécution (relativement à un programme exécuté directement sur le processeur hôte). bien documenté, et de préférence avec une communauté de développement active, ce qui serait utile dans le cas ou on aurait besoin de réaliser d importantes modifications de la VM. facilement extensible en s interfaçant avec des bibliothèques logicielles compilées en code natif du processeur. 75

4.3 Extension de la machine virtuelle «Lua» en MVR Selon ces critères, nous avons retenu une liste courte de VM candidates à être étendues en MVR. Cette liste est illustrée dans le tableau suivant : Lua Neko Python Squawk Kaffe LeJOS TinyVM NanoVM Waba empreinte mémoire faible x x x x x x x x performance x x x x x x x extensible x x x taille mémoire x x x x x x x x documentation x x x x x TAB. 4.2: Machines virtuelles candidates Squawk[78] et d autres machines virtuelles Java (JVM[5]) légères (qui implémentent partiellement les librairies du standards Java) sont de bonnes candidates pour être étendues en MVR : surtout lorsque les processeurs actuels peuvent incorporer des coprocesseurs dédiés à l exécution native du bytecode Java (e.g. Jazelle[79] qui est une machine virtuelle Java câblée incorporée dans certains processeurs ARM). Cependant, nous avons choisi la machine virtuelle Lua principalement pour les principes de sa conception [80] : elle est conçue dès le départ pour être rapide, légère, embarquable et facilement extensible (permet de définir des langages spécifiques). De plus, nous avons eu une première expérience de développement avec le langage Lua lors de l implémentation du démonstrateur de l émetteur/récepteur 802.11a et nous sommes familiarisés avec ses mécanismes internes. Client Application Common Utility Modules Libraries libs/* Lua Call Manager ldo.c Memory Management lmem.c Public API lapi.c Garbage Collector lgc.c Lexer Parser VM Kernel llex.c lparser.c lvm.c Debug Interface ldebug.c VM Code Generator lcode.c Function and Closure Manipulator lfunc.c Tables ltable.c FIG. 4.9: Modules fonctionnels qui composent l environnement Lua (figure extraite de [81]) 76

4.3 Extension de la machine virtuelle «Lua» en MVR 4.3.2 Portage de la machine virtuelle «Lua» sur le processeur ARM1176JZF-S Lua est un environnement de développement et d exécution constitué de différents modules : une machine virtuelle, un compilateur, un interpréteur de commande, etc. La décomposition en modules de l environnement Lua est illustré dans la figure 4.9. La VM Lua en tant que moteur d exécution est la partie qui nous intéresse et qui sera le point d entrée pour les programmes radios compilés en bytecodes Lua. En effet, la VM a le rôle d exécuter le bytecode qui pilotera les IP du SoC MAGALI. Afin d adapter la VM aux caractéristiques (espace mémoire disponible, performance, etc) de l architecture cible (ARM1176JZF-S) nous avons réalisé quelques modifications. Nous avons d abord supprimé les modules qui ne nous sont pas utiles, par exemple, l analyseur syntaxique (appelé aussi parseur), l analyseur lexical (appelé aussi lexeur) et le générateur de bytecode. Lua incorpore une liste de bibliothèques logicielles utilitaires que la machine virtuelle charge au lancement de son exécution. Celles-ci implémentent des fonctions qui s interfacent avec le noyau de la VM à travers l API d extension appelé aussi FFI (Foreign Function Interface). Pour alléger notre VM les bibliothèques suivantes ont été supprimés : lstrlib.c est la bibliothèque standard pour la manipulation de chaînes de caractères et de filtrage par motif (appelé aussi pattern-matching). ltablib.c est la bibliothèque standard pour la manipulation des tables. Les tables sont des structures de données très utilisées dans le langage Lua. Ce sont des tableaux associatifs qui permettent d implémenter des dictionnaires de données. loadlib.c est une bibliothèque qui fournit la fonction de chargement dynamique de bibliothèques. L implémentation de la fonction de chargement appelé «loadlib» dépend du système d exploitation utilisé : ces bibliothèques ont l extension.dll (Dynamic-Link Library) sur Windows,.so sur Linux,.dylib sur Mac-OS, etc. loslib.c est la bibliothèque qui gère les méthodes standards du système d exploitation. Par exemple : exécuter un programme, accès au système de fichiers (déplacer, renommer ou supprimer un fichier), demander l heure système, etc. liolib.c est la bibliothèque qui gère les flux d entrée/sortie. ldblib.c est la bibliothèque qui fournit une interface aux fonctionnalités de debug de Lua. Ces fonctions permettent à l utilisateur de connaître les informations concernant l état de la VM. Pour réduire la taille de l espace requis à l environnement d exécution, nous avons choisi que l infrastructure logicielle de la MVR n incorpore pas de systèmes de fichiers. Le bytecode est ainsi chargé et exécuté directement sur la mémoire de l ARM. La VM Lua est implémentée en ANSI C et sa compilation vers l architecture ARM nécessite les librairies du langages C (libc), celles-ci sont fournis par le système d exploitation ecos. Une difficulté particulière qu on a eu à résoudre lors de la compilation, est la représentation des flottants au format FPA spécifiques aux processeurs ARM. La représentation des valeurs des flottants dans le bytecode Lua est selon le format IEEE754 [82]. Pour conserver la spécification du bytecode Lua, la solution est de modifier la fonction de chargement des flottants de l interpréteur Lua. Enfin, la VM Lua obtenue, en sa version minimaliste, occupe moins de 90Ko de mémoire. Pour le test et le debug de la VM, nous utilisons sur l environnement de simulation la fonction printf de la librairie standard C des entrées/sorties (STDIO). Dans ecos la sortie de la fonction printf est redirigée vers le port série. Ce dernier est modélisé en SystemC de la sorte qu il affiche sur la sortie standard (l écran) les messages reçus. Une deuxième alternative pour le debug consiste à utiliser l outil gdb qui permet de tracer l exécution de l application. 77

4.3 Extension de la machine virtuelle «Lua» en MVR 4.3.3 Intégration globale La fonction principale main est le point d entrée du programme à exécuter par le processeur. Celle ci fait appel à l ordonnanceur du système d exploitation ecos pour créer un thread (appelé aussi, processus léger) afin d exécuter la MVR. En effet, le besoin de créer différents threads découle du fait que le processeur ARM a aussi le rôle de réaliser des traitements de la couche MAC, en parallèle avec le contrôle du SoC. Lua fournit une API permettant d instancier une machine virtuelle, de charger le bytecode correspondant à l application et de l exécuter. La structure de données de base, manipulée par la VM Lua est appelée LuaState. Elle correspond à un descripteur d état d un processus Lua qui décrit son contexte d exécution (pile d exécution, registres, compteur de programme, table des constantes, table des variables globales, etc). Le cycle de vie d une application Lua se résume dans les étapes suivantes : 1- Création d un processus Lua par l appel de la fonction lua_open. Cette fonction alloue une structure de données LuaState et retourne un pointeur qui la référencie. 2- Chargement des librairies standards (librairies de bases qui implémentent le langage Lua) et les librairies définies par l utilisateur. Pour cela on fait appel à la fonction lual_openlibs appliquée au contexte d exécution déjà alloué. 3- Chargement du bytecode et son association au contexte Lua alloué. Plusieurs variantes de fonctions de l API Lua permettent le chargement du bytecode. Exemple : lual_loadfile (depuis un fichier), lual_loadstring (depuis une chaîne de caractère), lual_loadbuffer (depuis un tampon mémoire). 4- Exécution du bytecode associé au contexte Lua en faisant appel à la fonction Lua_pcall. 5- A la fin de l exécution un appel à la fonction lua_close appliquée au contexte LuaState permet de libérer la mémoire allouée pour l application. L intégration de la RVM API à la machine virtuelle a été réalisée à travers l API d extension de Lua. A chaque fonction de la RVM API on associe un libellé. A l ensemble des couples (libellé i, fonction i ) on associe une librairie, qu on appellera rvm dans notre cas. L appel de la fonction fonction i depuis Lua se fait par l appel à rvm.libellé i. Exemple : s t a t i c c o n s t lual_reg rvmapi [ ] = { 2 { " i n i t ", l r v m _ i n i t }, { " a l l o c a t e ", l r v m _ a l l o c a t e }, 4 { " f r e e ", l r v m _ f r e e }, { " c o n n e c t ", l r v m _ c o n n e c t }, 6 { " d i s c o n n e c t ", l r v m _ d i s c o n n e c t }, { " s t a r t ", l r v m _ s t a r t }, 8 { " s t o p ", l r v m _ s t o p }, { " w a i t ", l r v m _ w a i t }, 10 { " c o n f i g u r e ", l r v m _ c o n f i g u r e }, 12... 14 {NULL, NULL} } ; 16 / F o n c t i o n a p p e l é e par l u a L _ o p e n l i b s / 18 LUALIB_API i n t l u a o p e n _ r v m a p i ( l u a _ S t a t e L ) { l u a L _ r e g i s t e r ( L, LUA_RVM, rvmapi ) ; 20... } 78

4.3 Extension de la machine virtuelle «Lua» en MVR Les fonctions associées aux libellés ont tous la même interface (prototype) : 1 s t a t i c i n t nom_fonction ( l u a _ S t a t e L ) ; 1 Le passage de paramètres Lua vers les fonctions qui implémentent les primitives des librairies chargées se fait par l usage de contexte Lua (descripteur de l application courante de type Lua_State) qui est une structure globale accessible par la VM. A chaque appel d une primitive en Lua, la VM cherche dans son catalogue la fonction correspondante par l usage d une fonction de hachage. Elle empile la liste des paramètres dans la pile d exécution du contexte global. Ensuite, elle déduit le type de fonction (fonction Lua, ou fonction C). Dans notre cas, les fonctions d extension sont des fonctions natives, celles-ci récupèrent dans leurs corps d implémentation les paramètres depuis la pile d exécution comme le montre l exemple suivant : s t a t i c i n t l r v m _ b u i l d _ c o r e _ c o n f i g ( l u a _ S t a t e L){ 3 enum_res_type r e s _ t y p e = l u a _ t o n u m b e r ( L, 1 ) ; t _ u i n t 3 2 cfg_pck ; 5 s w i t c h ( r e s _ t y p e ) { 7 case r e s _ t y p e _ t r x _ o f d m : cfg_pck = r v m _ t r x _ o f d m _ b u i l d _ c f g _ p c k ( 9 ( t _ u i n t 3 2 ) l u a _ t o n u m b e r ( L, 2 ), / b y p a s s _ f f t / ( t _ u i n t 3 2 ) l u a _ t o n u m b e r ( L, 3 ), / f f t _ t y p e / 11 ( t _ u i n t 3 2 ) l u a _ t o n u m b e r ( L, 4 ), / l o g 2 _ s i z e _ f f t / ( t _ u i n t 3 2 ) l u a _ t o n u m b e r ( L, 5 ), / norm_power / 13 ( t _ u i n t 3 2 ) l u a _ t o n u m b e r ( L, 6 ), / g i _ i n s e r t i o n / ( t _ u i n t 3 2 ) l u a _ t o n u m b e r ( L, 7 ), / g i _ s i z e / 15 ( t _ u i n t 3 2 ) l u a _ t o n u m b e r ( L, 8 ), / s h i f t _ c a r r i e r / ( t _ u i n t 3 2 ) l u a _ t o n u m b e r ( L, 9 ), / s h i f t _ p a r i t y / ) ; 17 19... l u a _ p u s h l i g h t u s e r d a t a ( L, ( v o i d ) cfg_pck ) ; 21 r e t u r n 1 ; } Dans le cas ou une primitive Lua est censée retourner une ou plusieurs valeurs de retour, la fonction C qui l implémente empile dans la pile d exécution associée au contexte global de l application (Lua_State) ces valeurs. La valeur de retour sert à indiquer à la VM le nombre de valeurs retournées par la fonction. Dans l exemple précédent, la fonction de configuration retourne une seule valeur de retour qui est la référence du binaire de configuration d une unité TRX_OFDM. Une autre alternative pour l intégration de la RVM API à la VM serait de définir un bytecode spécifique. Dans ce cas, il faut expliciter dans le noyau de la VM le décodage et la liste des opérations à réaliser pour chaque instruction radio. Il faut modifier le compilateur Lua (lexeur, parseur et générateur de code) pour qu il prenne en considération les nouvelles instructions. D une part, ces modifications sont très complexes à mettre en œuvre. D autre part, Ce genre de modifications n est pas adapté aux concepts fondamentaux de la VM Lua (l extensibilité se fait à travers une API sans modifier le noyau de VM). 79

4.4 Réalisation du dispositif «Programmable Pipe» (PP) 4.4 Réalisation du dispositif «Programmable Pipe» (PP) Nous avons décrit le dispositif «Programmable Pipe» (PP) dans le chapitre précédent comme un moyen pratique de définition de composants radios spécifiques en logiciel. Le PP permet l extension des fonctions radios supportées par la plateforme d exécution. Il est surtout utile lorsque la fonctionnalité désirée n est pas fournie par la plateforme hôte de radio logicielle (aucune IP, ni binaire exécutable pour un DSP réalisant la fonctionnalité). Dans cette partie, nous détaillons notre implémentation du PP sur le SoC MAGALI. 4.4.1 L association ARM-SME Lors de la conception du SoC MAGALI, le cas d usage où le processeur central de contrôle accède au flot de données pour réaliser des traitements spécifiques a été considéré. En effet, comme l illustre la figure FIG.4.10, l unité matérielle qui contient le processeur ARM intègre aussi un bloc SME. Le processeur et le SME partage le même espace mémoire, de la sorte que le processeur a un accès aux données en provenance du flot de données. La synchronisation avec la disponibilité des données se fait par un mécanisme d interruption. SME subsystem ARM1176 JZF-S 8k I$ + 8k D$ I$/D$ 64bit AXI L2 Periph 32bit AXI L2 Memory Arbiters AXI mux 2 Mem AXI 2 APB bridge UART Timer RAM 0 RAM 1 RAM 2 RAM 3 AXI-SME R+W 2*32 bit req AXI-SME Controller Periph 32bit APB Write-packet controller Dump controller Bridge NoC IT Dump + IT NoC Interrupt Controller IT Timer NoC Interrupt Network Interface FIG. 4.10: Association ARM1176 - SME La réalisation d un traitement spécifique (non fourni par la plateforme) nécessite une synchronisation entre deux programmes de types différents : i/ le programme de traitement réalisé par le processeur ARM. ii/ le programme de gestion de flot de données réalisé par le SME. Le SME est un gestionnaire de mémoire micro-programmable capable de gérer différents flux de données en entrées pour les aiguiller vers différents ports de sorties selon un schéma bien déterminé. La micro architecture du SME est illustrée dans la figure FIG. 4.11 : il contient quatre mémoires tampons liées à un port d entrée par l intermédiaire d un contrôleur d écriture de données appelé PROCESS WRITE (PW). À chaque mémoire tampon est associé un contrôleur de lecture appelé PROCESS READ (PR). Chaque mémoire tampon du SME implémente un buffer circulaire géré par trois types de pointeurs : 80

4.4 Réalisation du dispositif «Programmable Pipe» (PP) Memory Arbiters SME CORE RAM 0 RAM 1 RAM 2 RAM 3 CH 0 OCC 0 ICC PW FWL PR 0 PR 1 CH 1 OCC 1 SZC PR 2 PR 3 CH 2 OCC 2 CH 3 OCC 3 Network Interface FIG. 4.11: Micro-architecture du SME pointeur d écriture (wr_ptr) : contient l adresse de la prochaine donnée à écrire, pointeur de lecture (rd_ptr) : contient l adresse de la donnée la plus ancienne écrite, pointeur de travail wk_ptr : permet de pointer la donnée à lire parmi ceux qui sont disponibles dans la mémoire tampon. Ces pointeurs sont gérés par un contrôleur appelé SZC (Size Controller). Celui ci calcule l espace disponible dans la mémoire tampon. Il calcule aussi les adresses d écriture pour le PW et celles de lecture pour le PR. Chaque PR réalise ses opérations de lecture selon son propre micro-programme, qui lui indique : le nombre de données à lire, l adresse de lecture (adresse relative à assigner au pointeur de travail), le canal destination vers lequel les données doivent être envoyées. Dans la figure FIG. 4.11, les blocs CH0, CH1, CH2 et CH3, représentent des canaux (channels). Un canal est un composant qui une fois configuré permet d acheminer les données vers un des différents ports OCC du SME. le type de lecture (avec ou sans destruction des données lues). La destruction des données se fait par la manipulation du pointeur de lecture. Exemple : avancer le pointeur de lecture d une unité revient à libérer une case mémoire. Les micro-programmes sont stockés dans une zone réservée de la mémoire globale du SME. Le bloc FWL (Firmware Loader) permet de charger les micro-instructions à exécuter par les PR. Le contrôleur ICC envoie des crédits vers les unités depuis lesquelles il est configuré pour recevoir des données. Le nombre de ces crédits est généralement calculé à partir de l état de sa FIFO d entrée. Dans le cas du SME, l ICC calcule le nombre de crédits à envoyer en utilisant des informations en provenance du contrôleur SZC. L usage du bloc SME nécessite la micro-programmation des PR associées aux mémoires tampons. Un compilateur associé aux SME permet de générer les micro-instructions nécessaires à partir d un programme écrit en un langage de haut niveau (pseudo-c). De plus, il faut avoir préalablement configuré : les canaux du SME pour définir les chemins de données depuis chaque mémoire tampon vers les ports destinations. En effet, deux mémoires tampons peuvent avoir le même port destination. Dans ce cas, chacun des deux PR sera micro-programmé pour envoyer les données vers le même canal associé au 81

4.4 Réalisation du dispositif «Programmable Pipe» (PP) port OCC destination. Un mécanisme de jetons (token) gérés dans les micro-programmes, permet de synchroniser l envoie des données depuis les deux PR. le contrôleur SZC pour initialiser les différents pointeurs associés aux différentes mémoires tampons. On voit que, la réalisation d un traitement spécifique en logiciel par le processeur ARM nécessite une programmation et une configuration spécifique d un bloc SME fortement couplées avec le programme de traitement. 4.4.2 Réalisation du PP et de ses primitives Le PP est un dispositif logiciel qui offre une abstraction commune permettant à la fois d exprimer la gestion des flots de données et le traitement à réaliser sur celles-ci. L unité matérielle hôte du PP sur le SoC MAGALI est l unité ARM-SME : le bloc ARM permet de réaliser des algorithmes de traitement de signal (le processeur ARM1176 inclut dans son jeu d instructions des instructions SIMD de type DSP). Le bloc SME sert à gérer les flots de données en entrées et il est contrôlé par le processeur ARM. L_main ARM 1176 CORE pp_hdle = rvm.allocate(type_pp) 1. Alloacation du SME associé à l ARM 2. Création d un contexte Lua L_pp = lua_open() rvm.configure(pp_hdle, pp_program) 1. charger le bytecode Lua correspondant au programme du PP dans L_pp rvm.start(pp_hdle) 1. Lancer l écriture (lancer le PW) sur le SME 2. Créer un thread qui exécute L_pp L_pp Flux de données en entrées Données en provenance de PP SEND_DATA IT... DELETE_DATA IT SME Flux de données en sorties FIG. 4.12: Exécution d un processus de «programmable pipe» (L_pp) par le processeur ARM Le PP est vu comme tout composant radio dans le contexte de MVR : Pour pouvoir l utiliser, il faudrait d abord allouer une instance de composant de type PP en utilisant la primitive rvm.allocate ; La MVR peut configurer une instance de PP par l usage de la primitive rvm.configure. Sa configuration consiste à lui passer un programme qui utilise les primitives du PP ; La primitive rvm.connect peut être appliquée à une instance de PP pour l interconnecter avec d autres IP du flot de données. 82

4.4 Réalisation du dispositif «Programmable Pipe» (PP) Une instance de PP commence son exécution lorsqu elle reçoit un message déclencheur (Enable Task) depuis la MVR ; Il est possible de configurer une instance de PP pour envoyer une notification de fin de traitement lorsque celle ci termine son exécution. La figure 4.12 illustre notre conception pour la réalisation du PP : un processus principal Lua (L_main) exécute le bytecode de l application radio. Allouer un composant de type PP revient d abord à allouer l unité SME associé au processeur ARM. Ceci consiste dans l envoie de micro-programmes d ordonnancement des configurations (contextes) pour les contrôleurs ICC et OCC du SME (voir section 4.2.2). Le SME a la particularité de ne pas considérer de configurations de type cœur de traitement. En effet, les micro-programmes exécutés par les PR associés aux mémoires tampons du SME occupent le même rôle que celles-ci. L étape suivante consiste à créer un second processus Lua qu on appellera L_pp par la méthode lua_open(). On charge dans celui ci, la librairie de base du langage Lua (lbaselib) et une librairie qui contient les fonctions de gestion de flots de données définit par le concept de PP (WAIT_DATA, SEND_DATA, DE- LETE_DATA, INSERT_DATA, etc) qu on a appelé dfmgtlib (Dataflow Management Library). La plupart des fonctions de la librairie dfmgtlib reposent sur des micro-programmes paramétrables qu on a conçu pour réaliser les fonctionnalités élémentaires nécessaires à la gestion de flux de données par le SME. Pour des raisons de simplification on a implémenté un PP ayant une seule zone mémoire tampon pour l écriture des données depuis un port d entrée et qui gère quatre ports de sorties. Chaque primitive de dfmgtlib consiste à configurer le SME pour exécuter un micro-programme stocké en mémoire (assigner l adresse en mémoire du micro-programme à exécuter au compteur de micro-programme du SME). Chaque PR admet un ensemble de registres utilisés par le micro-programme correspondant. On utilise ces registres pour paramétrer les micro-programmes. Par exemple : La primitive SEND_DATA N est réalisée par l envoie des N unités de données les plus anciennes à être entrées dans la mémoire tampon vers un port destination. Le micro-programme correspondant lit la valeur de N depuis un registre particulier (R 0 ) puis il commence à lire en boucle les valeurs des données pour les écrire sur le port indiqué en paramètre. Lors de l exécution d un micro-programme les pointeurs du SME (wr_ptr,rd_ptr et wk_ptr) sont gérés par le circuit. Pour connaître l espace mémoire correspondant aux données valides, nous avons conçu une structure de données qui sauvegarde les adresses de la zone valide de travail (voir 3.3.2) associée à chaque instance de PP. Celle ci est mise à jour après l exécution de chaque micro-programme. Elle est utilisée principalement lors des opérations d écriture et de lecture réalisées par le PP. La fonction de configuration rvm.configure appliquée au PP prend en paramètre la fonction Lua qui constitue le programme du PP. La configuration du PP consiste en le chargement du bytecode correspondant au programme du PP dans le contexte Lua L_pp. Lancer le traitement d un PP consiste à d abord lancer l exécution du contrôleur d écriture PW pour écrire les données en provenance du port d entrée. Ensuite, lancer la lecture des données par l exécution du programme du PP. Ce programme est exécuté par une seconde instance de VM qui elle même exécutée par un processus léger crée par la primitive rvm.start. On pourrait prévoir parmi les paramètres de configuration d une instance de PP les paramètres d ordonnancement du thread du PP. Par exemple : sa politique d ordonnancement, sa priorité d exécution, la taille de la pile d exécution à lui réserver, etc. Ces paramètres sont pris en considération par les fonctions de la librairie Pthread (POSIX thread) (voir les fonctions : pthread_setschedparam, pthread_setschedpolicy, et pthread_attr_setstacksize dans [83]). Le PP est réalisé dans notre implémentation par un processus Lua. Celui ci est capable de communiquer des paramètres au processus principal L_main dont la tache principale est la configuration et le contrôle des ressources de la plateforme d exécution. Pour cela on a définit des canaux virtuels de communications 83

4.4 Réalisation du dispositif «Programmable Pipe» (PP) associés au PP : ce sont de zones de mémoires partagées réservées pour l échange de données entre les processus L_pp et L_main auxquelles sont associés des mécanismes de synchronisation (Mutex). Enfin, nous rappelons que dans cette partie on décrit notre choix d implémentation du PP sur le processeur ARM du circuit MAGALI. D autres alternatives pour l implémentation du PP existent, on pourrait utiliser par exemple un DSP qui pilotera la gestion du flot de données et réalisera les opérations de traitement de signal efficacement. Une autre solution d implémentation à investiguer est l utilisation des processeurs multicœurs pour réaliser à la fois les fonctions de la MVR et les processus de plusieurs instances de PP (un PP par cœur de traitement). Conclusion L implémentation de la MVR sur la plateforme MAGALI a été présentée dans ce chapitre. Cette implémentation a nécessité, préalablement, une bonne compréhension des mécanismes du circuit et de ces concepts fondamentaux. Nous avons aussi décrit les environnements logiciels de développement et de simulation existants qui nous ont servi à réaliser et tester notre implémentation. On a montré comment on a réalisé les primitives de la MVR sur le SoC MAGALI. Cette couche d abstraction a pour but de cacher la complexité d implémentation d applications radios logicielles par les primitives de bas niveau d abstraction fournit par l infrastructure logicielle existante (HAL et drivers). Nous avons aussi présenté les aspects techniques liés au choix et au portage de la VM Lua sur le processeur ARM176JZF-S du circuit MAGALI. L intégration des primitives radios à la VM Lua a été réalisée sous la forme d une extension par librairies. Enfin Nous avons expliqué notre implémentation du dispositif PP. Sa réalisation a nécessité la programmation et la configuration d un bloc logiciel (ARM) et d un bloc matériel (SME). L architecture du SME n est pas totalement adaptée pour la réalisation du PP. Sa réalisation nous a posé un réel défi technique et elle nous a amené à contourner l utilisation classique du SME. En résumé, ce chapitre montre une manière d implémenter la MVR sur une plateforme existante de radio logicielle. D autre part, à travers cette expérience d implémentation, on comprend mieux les difficultés de réalisation d une application radio en utilisant une approche classique qui utilise des primitives de bas niveau d abstraction. Dans la suite du manuscrit nous allons utiliser le démonstrateur logiciel de la MVR réalisé pour effectuer nos expérimentations et étudier le surcoût du concept. 84

5 CHAPITRE Expérimentations Sommaire Introduction........................................... 87 5.1 1 re expérimentation : Un seul opérateur fonctionnel (FFT)............... 87 5.1.1 Protocole d expérimentation............................ 87 5.1.2 Résultats expérimentaux.............................. 90 5.1.3 Analyse des résultats................................ 91 5.2 2 e expérimentation : Estimation du CFO IEEE802.11a................. 94 5.2.1 Protocole d expérimentation............................ 94 5.2.2 Résultats expérimentaux.............................. 96 5.2.3 Analyse des résultats................................ 98 5.3 Proposition de techniques d optimisation........................ 99 5.3.1 Compilation à la volée............................... 99 5.3.2 Traduction de code................................. 100 5.3.3 Accélération matérielle............................... 102 Conclusion............................................ 102 86

5.1 1 re expérimentation : Un seul opérateur fonctionnel (FFT) Introduction La MVR est une abstraction qui fournit la portabilité des applications radios et la reconfigurabilité des plateformes d exécution. La réalisation de la MVR sur le circuit MAGALI telle qu on l a conçue rajoute deux couches logicielles supplémentaires au dessus de l infrastructure logicielle existante : La librairie RVM API : implémente les primitives radios de haut niveau d abstraction du modèle de programmation proposé (rkpn). La machine virtuelle (VM) : exécute le bytecode radio en faisant appel aux primitives de la RVM API. Le concept de MVR introduit ainsi un coût supplémentaire par rapport à des applications radios programmées pour être exécutées sur une plateforme matérielle spécifique. Ce surcoût se traduit principalement en termes de puissance de calcul et d espace mémoire requis. Dans ce chapitre, nous présentons les expérimentations que nous avons réalisées sur le démonstrateur logiciel de la MVR implémenté sur le SoC MAGALI. Ces expérimentations ont pour objectif d évaluer les surcoûts associés à la machine virtuelle et au modèle de programmation. Nous analysons en profondeur les causes principales de ces surcoûts et confirmons nos résultats analytiques par les résultats d expérimentations. Enfin nous proposons des optimisations qui permettraient de réduire le surcoût de la MVR et décrivons leurs mises en œuvre. Le chapitre est organisé en trois sections. D abord, dans la section 5.1, on présente une première expérimentation ayant pour objectif d évaluer le surcoût de reconfiguration d un opérateur fonctionnel de traitement de signal. Nous décrivons alors son protocole d expérimentation. Puis nous présentons les résultats obtenus qui feront l objet d une analyse critique. On présente ensuite dans la section 5.2, une deuxième expérimentation ayant pour objectif d évaluer le surcoût introduit lorsque le contrôleur central de la plateforme d exécution est utilisé pour réaliser des traitements spécifiques. De la même façon que dans 5.1, nous détaillerons son protocole d expérimentation et fournirons une analyse des résultats obtenus. Enfin, dans la section 5.3, nous proposons trois techniques d optimisation. On expliquera pour chacune de ces techniques sa mise en œuvre dans un contexte d usage général et puis dans le contexte de notre implémentation de MVR sur le circuit MAGALI. 5.1 1 re expérimentation : Un seul opérateur fonctionnel (FFT) Le but de la première expérimentation est d évaluer les surcoûts principalement en temps d exécution du modèle de programmation et celui de la VM pour un cas d usage simple : un opérateur fonctionnel de traitement de signal (dans notre cas on considère l opérateur FFT) est appliqué sur un nombre variable de données en entrée. Les résultats de cette expérimentation nous permettent de comprendre comment chacun des surcoûts évolue par rapport au nombre des données traitées. Pour la 1 re expérimentation, la VM ne réalise pas de traitements directement sur les données en provenance du flot de données. Elle fait appel à une unité matérielle dédiée à la réalisation de la fonction FFT : le but est d évaluer le surcoût de la VM pour l appel des primitives de la RVM API. 5.1.1 Protocole d expérimentation La transformée de Fourier rapide appelée aussi «FFT» est une opération très utile en traitement du signal. Elle constitue l élément central de l unité de traitement TRX-OFDM du circuit MAGALI. Pour réaliser une 87

5.1 1 re expérimentation : Un seul opérateur fonctionnel (FFT) FFT, le cœur de traitement de l unité TRX-OFDM devrait être fourni avec une configuration binaire correspondante. Pour quantifier chacun des surcoûts (de la couche RVM API et de la VM) nous avons réalisé trois implémentations de l application «opérateur FFT appliqué à un nombre variable de données» (voir figure FIG.5.1) : Firmware (F2 API) ARM RVM API Firmware (F2 API) ARM VM RVM API Firmware (F2 API) ARM FFT FFT FFT i/ Implementation native ii/ Selon le modèle de programmation (RVM API) iii/ Avec la MVR Config Control IT flot de données FIG. 5.1: Exécution de la FFT sur un nombre variable de données : les 3 implémentations de la 1 re expérimentation Implémentation native (optimisée) Ce mode d implémentation fait usage des mécanismes spécifiques du circuit MAGALI. Selon le modèle de programmation native du circuit MAGALI, le contrôleur CCC est utilisé pour réitérer l exécution de la même configuration de type cœur de traitement afin de réaliser plusieurs FFT. Dans ce cas, le processeur central a besoin seulement de configurer l unité TRX-OFDM une seule fois, indépendamment du nombre total de données à traiter. Une configuration de type cœur de traitement pour l unité TRX-OFDM consiste à indiquer la fonctionnalité à réaliser qui est la FFT dans notre cas et ses différents paramètres (taille de la FFT, paramètre de normalisation, activation/désactivation de l intervalle de garde, taille de l intervalle de garde, ect). Pour le mode natif d implémentation, le micro-programme d ordonnancement des configurations de type cœur de traitement est le suivant : RCL 0 0 / / Demande l e x é c u t i o n de l a c o n f i g u r a t i o n 0 s t o c k é e au s l o t 0 2 / / e t s a u v e g a r d e l a d r e s s e de l a micro i n s t r u c t i o n c o u r a n t e LL 0 N / / R é i t è r e N f o i s l a micro i n s t r u c t i o n à l a d r e s s e s a u v e g a r d é e 4 STOP 0 0 / / f i n du micro programme où N est le nombre de boucles de configuration à réaliser par le contrôleur CTM (context manager) du CCC. Les configurations des contrôleurs de gestion des flux de données appelés ICC et OCC sont simples et consistent principalement à indiquer le nombre total de données à recevoir et à transmettre pour toute l application. Pour le mode d implémentation native les configurations sont statiques (connues à l avance de l exécution). Elles ont alors été construites par l outil CORECFGC puis chargées avec le code de l application. Le processeur central envoie directement ces configurations à l unité en question. 88

5.1 1 re expérimentation : Un seul opérateur fonctionnel (FFT) Une fois ces configurations déployées conjointement avec leurs micro-programmes d ordonnancement, le processeur ARM de la plateforme envoie un message de contrôle de type «Enable task» pour activer l IP TRX-OFDM et attend une seule interruption de fin de traitement à la fin de l exécution de l application. Implémentation selon le modèle de programmation (utilisation de la RVM API) Dans ce mode d implémentation, l application fait usage seulement des primitives de la couche logicielle RVM API décrite dans le chapitre précédent. Lors de la phase d allocation d une ressource de type TRX_OFDM le processeur central envoie le microprogramme trivial suivant pour l ordonnancement des configurations de type cœur de traitement : RC 0 0 / / Demande l e x é c u t i o n de l a c o n f i g u r a t i o n 0 s t o c k é e au s l o t 0 2 STOP 0 0 / / f i n du micro programme Il consiste à exécuter une seule fois la configuration stockée en mémoire. Les configurations (des ICC, des OCC et du cœur de traitement) sont construites pendant l exécution par les primitives rvm.build_core_cfg et rvm.build_com_cfg. L unité TRX_OFDM est configurée comme suit : Une configuration de type cœur de traitement équivalente à celle utilisée dans le cas d implémentation native. La fonctionnalité à réaliser est une FFT classique à 1024 points en entrée. Une configuration de type communication qui consiste à définir les nombres de données à recevoir et les nombres de données à envoyer, associés à chaque port d entrée et de sortie. Dans ce cas d implémentation, la ressource TRX_OFDM utilise exactement un port d entrée et un port de sortie. Ces deux ports sont configurés pour recevoir et envoyer le même nombre de donnée égale à 1024 unités de données. En effet, la ressource TRX_OFDM telle qu elle est configurée (configuration cœur) consomme les données par fenêtre de 1024 unités de données et produit à chaque fois le même nombre de données. Une configuration d interruption qui consiste à envoyer une interruption de type «End of Task» à la fin de l exécution de ses propres micro-programmes d ordonnancement des configurations. Une fois les configurations déployées, le contrôleur central a la tache d ordonner l exécution et d attendre une interruption de fin de traitement depuis l unité TRX-OFDM à chaque itération de FFT (voir figure FIG. 5.1/ii). Cela revient à réitérer, autant que de données à traiter, les deux primitives suivantes : rvm.start : demande l exécution de l unité TRX_OFDM. rvm.wait : attend une interruption de fin de traitement. Implémentation avec la MVR complète Cette implémentation (voir figure FIG. 5.1/iii) fait appel aux primitives de la RVM API à travers la couche machine virtuelle. Le programme de l application est fourni en bytecode Lua. La VM charge le bytecode et réalise les mêmes étapes de l implémentation décrite dans le paragraphe précédent (selon le modèle de programmation proposé). 89

5.1 1 re expérimentation : Un seul opérateur fonctionnel (FFT) 5.1.2 Résultats expérimentaux L exécution de chacun des programmes correspondants aux trois implémentations de l application de la 1 re expérimentation ont été effectuées sur la plateforme de simulation du circuit MAGALI qui inclut un modèle VHDL, précis au cycle prêt, du processeur ARM1176JZF-S. L horloge du processeur a été configurée pour le cadencer à 362.31MHz. D abord nous avons mesuré le temps d exécution total pour chacune des implémentations décrites dans la section 5.1.1. La figure FIG. 5.2 montre que pour chaque implémentation le temps d exécution dépend linéairement du nombre de données à traiter. 15 14 13 Native RVM API Full RVM Temps d exécution total de l opérateur FFT Temps total d exécution simulé (ms) 12 11 10 9 8 7 6 5 4 3 2 1024 16384 32768 65536 131072 Nombre de flits de données FIG. 5.2: Temps total d exécution simulés des trois configurations d implémentation En utilisant l algorithme de régression linéaire on peut modéliser les trois courbes par une fonction linéaire y = ax + b où x est le nombre d unités de données à traiter et y est le temps d exécution simulé. Les couples de paramètres (a, b) sont listés dans le tableau suivant : Mode d implémentation a(ms.flit 1 ) b(ms) Natif 2.50e 5 1.11 modèle de programmation (rvm api) 4.92e 5 1.63 mvr complète 6.98e 5 4.87 TAB. 5.1: Les paramètres de régression linéaire du temps d exécution total pour les trois configurations 90

5.1 1 re expérimentation : Un seul opérateur fonctionnel (FFT) Le tableau TAB.5.2 liste la taille de la mémoire occupée par chacune des implémentations de la 1 re expérimentation. Mode d implémentation Mémoire occupée (Ko) Natif 10 modèle de programmation (rvm api) 60 mvr complète 208 TAB. 5.2: Taille des programmes de la 1 re expérimentation pour les trois configurations 5.1.3 Analyse des résultats Malgré les comportements similaires des trois implémentations, elles correspondent à de très différentes répartitions du temps d exécution. Pour expliquer cela nous avons représenté dans la figure FIG. 5.3 les chronogrammes de charges de travail du processeur et de l IP FFT pour chaque configuration d implémentation. FIG. 5.3: Chronogrammes pour le processeur et l IP FFT pour les trois configurations : native (a), RVM API (b), RVM complète (c). Pour la 1 re configuration (mode natif, (a) dans la figure FIG. 5.3), les micro-programmes d ordonnancement des configurations sont utilisés efficacement. Ceux ci permettent d avoir une seule interruption, indépendamment du nombre de données à traiter. Ceci permet aussi l exécution en parallèle des taches de communications et de calcul au sein de l IP FFT. Une fois l initialisation du processeur terminé, le temps restant d exécution est passé dans le calcul des FFT, nous avons ainsi : a native a FFT, où a FFT est le temps d exécution par unité de données pour la FFT. 91

5.1 1 re expérimentation : Un seul opérateur fonctionnel (FFT) Si nous vérifions notre modèle analytique avec les résultats d expérimentations on a : Le temps de calcul d une FFT figure au niveau du modèle SystemC de l unité TRX_OFDM comme suit : t FFT = clk_period fft_size log(fft_size)/log(4), où fft_size est la taille de la FFT et clk_period est la période d horloge qui cadence l exécution de l unité TRX_OFDM. Dans notre expérimentation nous avons configuré une FFT avec une taille de 1024, points. La période d horloge de l unité TRX_OFDM est de 5ns 200M Hz. D après cette formule t FFT = 25 1024ns, soit le temps d exécution par unité de données pour la FFT est égale 25ns. D après le tableau TAB.5.1, a native = 25ns, ce qui prouve l exactitude de notre modèle analytique. En considérant la 2 e configuration (RVM API, (b) dans la figure FIG. 5.3), une interruption doit être envoyée à chaque fin d exécution d une FFT, cela implique que les taches de communications et celles de calcul ne peuvent pas être exécutées en parallèle, ce qui mène à un temps total d exécution de T rvm_model = N (t load + t FFT + t send + t restart ) pour N FFT. où t load, resp. t send, est le temps nécessaire pour que les données rentrent, resp. quittent, l unité TRX_OFDM, et t restart est le temps requis pour redémarrer le calcul quand une interruption est reçu par le processeur. Nous en déduisons ainsi : a rvm_api t load + t send + t restart size FFT + a FFT, Le temps t_load et t_send sont modélisés au niveau SystemC de la sorte que chaque unité de donnée qui entre ou sort de l IP prend exactement une période d horloge soit 5ns. Si nous considérons les résultats d expérimentations du tableau TAB.5.1 on en déduit que le temps t_restart est approximativement égale à 14µs. En vérifiant les traces d exécution, on trouve que ce temps est variable (entre 9µs et 18µs), ce non déterminisme est du au mécanisme de gestion des interruptions du système d exploitation ecos (les DSR sont exécutés lorsque l ordonnanceur de OS est appelé). On conclut que l ordonnancement de l exécution de la FFT par le processeur central introduit un surcoût qui d une part, est du au temps de synchronisation en utilisant les interruptions (quelques centaines de cycles). D autre part il est du à l insertion de commandes d exécution (envoi de messages «enable task») chaque fois que l IP FFT termine son calcul sur une fenêtre de 1024 données. Dans la 3 e configuration (MVR complète, (c) dans la figure FIG. 5.3), le temps passé dans l interprétation d une primitive de la RVM API est plus important que le temps passé pour l exécution d une FFT. Ainsi la pente a full_rvm de la droite de la figure FIG. 5.2 dépend seulement du temps passé dans l exécution des primitives de la RVM API par la VM. Nous avons ainsi : a full_rvm t wait_it + t restart size FFT, où t wait_it est le temps requis par la VM pour passer à l état d attente d interruption. Ce cas illustre clairement le coût d interprétation dans le contexte de la VM. En analysant les traces d exécution des applications implémentées avec la MVR complète, on a trouvé que le temps qui sépare l appel d une fonction native de son appel en langage de la VM Lua dure à lui seul en moyenne 10 µs. L interprétation et le passage de paramètres de Lua vers l implémentation native est le facteur de surcoût principal pour cette configuration. La partie fixe du surcoût (le paramètre b dans les équations linéaires du temps global d exécution de 92

5.1 1 re expérimentation : Un seul opérateur fonctionnel (FFT) chacune des configurations d implémentation de la 1 re expérimentation) correspond au temps nécessaire à l initialisation du processeur lors du démarrage (mise à zéro des valeurs des variables statiques dans la section BSS (Block Started by Symbol). Pour le cas de la MVR complète, un surcoût supplémentaire est du à l initialisation de la VM et au chargement du bytecode. La figure FIG. 5.4 montre le temps passé par le processeur dans les différentes phases du programme (initialisation, configuration de l IP, état d attente d interruption, etc.) et ceci pour les trois configurations. Cette figure confirme notre analyse : dans la configuration d implémentation avec le concept de MVR complète, le processeur n est jamais en attente, ce qui montre que dans notre implémentation, la performance de la VM est un facteur pénalisant pour la performance globale du système. Temps total d exécution simulé (ms) 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 CPU Init CPU Ctrl CPU Idle CPU Init CPU Ctrl CPU Idle CPU Init RVM Init RVM Ctrl 8192 4096 2048 1024 131072 65536 32768 16384 8192 4096 2048 1024 131072 65536 32768 16384 Native 8192 4096 2048 1024 131072 65536 32768 16384 RVM API Nombre de flits de données Full RVM FIG. 5.4: Décomposition du temps d exécution de la 1 re expérimentation pour les trois configurations d implémentation En ce qui concerne les surcoûts en espace mémoire requis pour les programmes à exécuter (selon le modèle de programmation et selon la MVR complète) par rapport à un programme implémenté selon le mode natif, on peut les en déduire à partir du tableau TAB. 5.2. On remarque que le programme selon le modèle de programmation RVM API nécessite 50 Ko de mémoire supplémentaire. En effet cette configuration d implémentation rajoute une couche logicielle supplémentaire (la RVM API). De plus les configurations des unités de traitement sont définies par le programme exécutable. La configuration avec la MVR complète nécessite 150 Ko de mémoire supplémentaire par rapport à la configuration selon le modèle de programmation. Cet espace mémoire sert au stockage du code du moteur d exécution de la machine virtuelle ainsi que le bytecode de l application. 93

5.2 2 e expérimentation : Estimation du CFO IEEE802.11a 5.2 2 e expérimentation : Estimation du CFO IEEE802.11a Dans les systèmes de télécommunication, l erreur CFO (Carrier Frequency Offset) représente le décalage de phase entre les horloges d émission et de réception du aux imperfections du matériel. Ce phénomène est bien connu et est souvent corrigé par les algorithmes classiques d estimation et de correction. Ces algorithmes font usage intensif des fonctions trigonométriques sin(), cos() et arctan(). Les implémentations matérielles utilise souvent l IP CORDIC pour calculer efficacement ces opérations trigonométriques. La deuxième expérimentation implémente en logiciel l algorithme d estimation de l erreur CFO (Carrier Frequency Offset) pour le standard IEEE802.11a. Dans ce standard, une séquence d échantillons temporels, connue à l avance par le récepteur, est émise par l émetteur. Cette séquence est composée de deux types de symboles d apprentissage : i/ symboles courts ou STS (Short Training Sequence), ii/ symboles longs ou LTS (Long Training Sequence). Le récepteur commence d abord par une estimation grossière de l erreur CFO en comparant les symboles courts reçus avec leurs valeurs théoriques. Ensuite il corrige les valeurs des échantillons temporels des symboles LTS et procède avec une seconde estimation fine, plus précise, de l erreur CFO restante. 5.2.1 Protocole d expérimentation Comme pour la première expérimentation nous avons réalisé trois configurations d implémentation de l algorithme d estimation de l erreur CFO afin de calculer les surcôuts introduit par notre modèle de programmation et de la VM. La 2 e expérimentation étudie le cas spécifique où le contrôleur central de la plateforme est utilisé pour réaliser un calcul spécifique de traitement du signal. Implémentation native (optimisée) (2) Notification de la disponibilité des données (3): Accès aux données (lecture / écriture) (4): commande de reprise du transfert de données ARM (1) Un seul microprogramme (3) (4) (5) configurer avec paramètre de déphasasge SME ROTOR FFT Implémentation native Config Microprogramme IT Flux de données Accès aux données FIG. 5.5: CFO Implémentation de l estimation CFO selon la configuration native Notre implémentation native de l algorithme d estimation de l erreur CFO sur le circuit MAGALI utilise principalement l unité SME (Smart Memory Engine) configurée avec un micro-programme qui est à la fois complexe et spécifique à cette application. Ce micro-programme permet de synchroniser le processeur ARM avec la disponibilité des données en provenance du flot de données. D une part, le SME envoie une interruption au processeur quand les données requises au calcul sont disponibles dans sa mémoire tampon. D autre 94

5.2 2 e expérimentation : Estimation du CFO IEEE802.11a part, le processeur réveille le SME quand les données ont bien été traitées pour qu il continue le transfert des données au bloc suivant de la chaîne de traitement (voir figure FIG. 5.5). L algorithme de l estimation de l erreur CFO que nous avons implémenté est celui proposé par Sourour et al. dans [63]. Il consiste principalement à calculer la moyenne du déphasage entre chaque deux échantillons temporels correspondants à la même position dans deux symboles d apprentissage consécutifs. 16 échantillons N= 64 échantillons t t t t t t t t 0 1 2 3 4 5 6 7 t t 8 9 GI T 0 T 1 GI Signal GI Data - - - 0 GI Data 1 10 x STS (Short Training Sequence) 2 x LTS (Long Training Sequence) temps FIG. 5.6: Structure d une trame IEEE802.11a Les 5 premiers symboles STS (t 0, t 1,...,t 4 dans la figure FIG.5.6) servent à la détection du début de la trame au niveau du récepteur, ceci par le calcul d une fonction d autocorréllation (le quatrième pics de cette fonction correspond au début de la trame). Pour calculer une estimation du déphasage du à l erreur de CFO nous avons besoin seulement des deux derniers symboles STS et les deux symboles LTS. Pour cela nous avons écrit un micro-programme spécifique qui ignore les données en provenance du flot de données (correspondants à la trame) jusqu à atteindre le début du 9 e symbole STS (t 8 dans FIG.5.6). Une fois les données correspondants à la partie qui nous intéresse sont dans la mémoire tampon du SME, celui ci envoie une interruption au processeur ARM et se bloque en attendant une notification pour continuer l exécution du micro-programme. Le processeur ARM accède alors aux données, calcul le déphasage,configure l IP ROTOR pour corriger la suite de la trame et notifie le SME. Enfin, le SME continue l exécution du micro-programme pour envoyer le reste de la trame vers le bloc suivant (ROTOR). La configuration d implémentation native utilise un seul micro-programme conçu dés le départ pour réaliser toutes les opérations nécessaires à l application. Le programme de contrôle exécuté par le processeur ARM est un programme séquentiel (le traitement réalisé pour calculer l erreur CFO se fait après l occurrence de l interruption depuis le SME). Implémentation selon le modèle de programmation (utilisation de la RVM API) Cette configuration d implémentation utilise les mêmes unités de traitement du circuit MAGALI que ceux utilisées dans la 1 re configuration. Selon notre modèle de programmation, pour réaliser un traitement spécifique, nous faisons usage du dispositif «programmable pipe» (PP). Ce dispositif permet de définir un cœur de traitement virtuel qui présente les mêmes interfaces des composants radios fournis avec l environnement d exécution (les opérateurs fonctionnels de traitement du signal qui sont implémentés par des IP matérielles ou des DSP de la plateforme matérielle d exécution). Le programme exécuté par le contrôleur central, à savoir le processeur ARM dans notre cas, consiste alors à réaliser les étapes suivantes : 1. Instantiation des ressources, en particulier : Instantiation d une unité de type GEN qui a le rôle de source de données pour envoyer les données de la trame (simulation de la partie RF). Instantiation d une unité de type «programmable pipe» (PP) (voir section 4.4). Elle consiste dans le cas de cette configuration, à d abord créer un second thread qui exécutera l algorithme d estimation de l erreur CFO et d initialiser l unité SME rattachée au bloc ARM, qui réalisera les opérations de gestion de flux de données. 95

5.2 2 e expérimentation : Estimation du CFO IEEE802.11a 2. Configuration des ressources : Configuration des unités de traitement comme il est décrit dans la section 3.2. L unité PP devra envoyer une interruption à la fin du traitement. 3. Lancement de l exécution et attente de la notification de fin de traitement : Les unités configurées attendent un message de type «enable task» pour commencer leurs traitements. La particularité de cette configuration d implémentation est que les interactions du processeur central avec le SME, qui est l entité gestionnaire du flot de données, ne se font pas par un seul micro-programme spécifique à l application, comme c est le cas avec la configuration native. En effet, on a défini un ensemble d opérations élémentaires que le SME est capable de réaliser. Puis nous avons associé à celles ci des microprogrammes paramétrables qui sont chargés avec le programme de l application. Le thread responsable de l exécution du PP configure à chaque fois le SME pour réaliser une opération élémentaire (envoie, réception, suppression ou notification de la disponibilité de données) et a possibilité d accéder en lecture ou en écriture aux données en provenance du flot de données. Cette abstraction de la configuration du SME a certainement un surcoût par rapport à une implémentation native. Implémentation avec la MVR complète La configuration d implémentation avec la MVR complète consiste à utiliser l unité logicielle PP pour la réalisation de l algorithme d estimation de l erreur CFO comme il est expliqué dans la configuration avec le modèle de programmation avec la particularité d utiliser la machine virtuelle pour réaliser les traitements. Dans ce cas, le code de l application est fourni en un seul bytecode de la VM qui inclut à la fois les primitives de configuration, de contrôle et aussi l algorithme d estimation de l erreur CFO. 5.2.2 Résultats expérimentaux Nous avons réalisé la 2 e expérimentation selon les trois configurations décrites dans le paragraphe précédent, sur la plateforme de simulation du circuit MAGALI. Nous utilisons comme pour la première expérimentation le modèle VHDL du processeur ARM. Dans un premier temps, nous avons utilisé le processeur ARM avec sa configuration par défaut, sans activer son unité de calcul en virgule flottante, appelée FPU, ni ses mécanismes avancés de gestion de la mémoire (MMU et cache de données désactivés). Les temps d exécutions étaient ainsi très importants. En effet, dans un contexte d application radio avec des contraintes temps réel dures, il est essentiel de configurer le processeur afin de mettre en œuvre tous ses dispositifs matériels pour tirer profit entièrement de toutes ses capacités de calcul. Le tableau suivant résume les temps d exécution globaux de l application d estimation de l erreur CFO implémentée avec la RVM complète selon les trois configurations du processeur (par défaut, avec FPU, avec FPU et cache de données). Configuration processeur Temps (ms) Config. par défaut 155.87 Config. avec fpu 60.88 Config. avec fpu et caches activés 17.45 TAB. 5.3: Les temps d exécutions globaux de l application d estimation de l erreur CFO selon les différentes configurations du processeur 96

5.2 2 e expérimentation : Estimation du CFO IEEE802.11a Activation de l unité de calcul en virgule flottante La 2 e expérimentation utilise le processeur pour réaliser des calculs de traitement de signal. Dans notre cas d étude, nous utilisons la représentation en virgule flottante pour les valeurs non entières. Par conséquent, l activation de l unité de calcul en virgule flottante (FPU) est une étape cruciale, qui comme le montre le tableau TAB.5.3 permet d améliorer considérablement les performances du système. D abord nous avons construit une chaîne de compilation croisée spécifique pour générer un code exécutable qui prend en compte le jeu d instruction de l unité FPU de notre processeur (arm_gcc4.2.2). Ensuite on rajouté à la couche d abstraction matérielle notée HAL le code d activation du coprocesseur correspondant à l unité FPU (voir «chapitre 18. Introduction to the VFP coprocessor» dans [68]). La recompilation du code des applications de la 2 e expérimentation a nécessité la réalisation de retouches (patch) appliquées surtout au code du système d exploitation «ecos». En effet, cet OS est prévu pour être compilé avec le compilateur gcc3.2.1 qui ne gère pas les instructions FPU. Activation du cache de données Le processeur ARM tel qu il est intégré dans le circuit MAGALI nécessite de passer par un contrôleur de bus et un arbitre de mémoire chaque fois qu il doit accéder à une adresse mémoire (voir figure FIG.4.10). Ces accès mémoires sont très pénalisants en terme de performance lorsque le cache de donnée n est pas activé. Pour activer le cache de données nous avons rajouté à la couche HAL de l OS un code spécifique et nous avons configuré l unité de gestion de la mémoire notée MMU qui elle gère la correspondance des adresses virtuelles en adresses physiques (celles du cache). Les concepts théoriques et techniques liés à la configuration du cache et de la MMU des processeurs ARM sont expliqués d une façon détaillée dans [84]. Nous considérons dans la suite la configuration du processeur qui fournit les meilleures performances. La figure FIG. 5.7 illustre le temps total d exécution pour les trois configurations d implémentation. Surcoût en espace mémoire La taille des programmes exécutables correspondants aux trois configurations d implémentation (native, avec modèle de programmation et avec VM complète) sont illustrés dans le tableau TAB. 5.4. Mode d implémentation Mémoire occupée (Ko) Natif 96 modèle de programmation (rvm api) 100 mvr complète 212 TAB. 5.4: Taille des programmes de la 2 e expérimentation pour les trois configurations 97

5.2 2 e expérimentation : Estimation du CFO IEEE802.11a Temps total d exécution simulé (ms) 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 Temps total d exécution simulé pour différentes configurations d implémentation INIT CFO computation CPU CTRL NATIVE PRG MODEL FULL RVM Configurations d implémentation FIG. 5.7: Les phases d exécution de l application CFO selon les 3 configurations d implémentation 5.2.3 Analyse des résultats L étude de la figure FIG. 5.7 montre que si nous ne considérons pas le temps d initialisation (chargement du programme, initialisation du processeur pour l exécution appelé aussi la phase de «boot», initialisation du système d exploitation, etc.) nous trouvons que l implémentation selon la configuration avec le modèle de programmation (RVM API) a approximativement un surcoût en temps d exécution de 25% comparé à l implémentation native. La machine virtuelle complète introduit un facteur de 6.5 fois en temps d exécution par rapport à une implémentation avec le modèle de programmation. Il est important de comprendre avec précision l origine du surcoût introduit par les implémentations avec le modèle de programmation et celui avec la MVR complète, lorsqu il s agit d utiliser le contrôleur central pour réaliser des opérations spécifiques de traitements du signal. On distingue deux types de surcoût qui tout deux résultent en l augmentation du temps d exécution global et de la taille de la mémoire requise par le programme à exécuter : 1. Le coût d interprétation par la VM Lua, il consiste en : i) L appel de fonctions natives : l intitulé des fonctions appelées est hash-codé lors de la compilation, et il est utilisé pour retrouver la fonction native correspondante lors de l appel. ii) Le transtypage des données de leur format natif (en provenance du flot de données) vers le format Lua et vice versa, chaque fois que la machine virtuelle a besoin de réaliser des calculs sur le flot de données. L algorithme de l estimation de l erreur CFO est particulièrement un pire cas en terme de surcoût d in- 98

5.3 Proposition de techniques d optimisation terprétation, puisque d une part la MVR réalise des appels répétitives aux fonctions trigonométriques implémentés en code natif, et d autre part, les données à traiter proviennent du flot de données et doivent par suite être transtypées vers le format Lua avant chaque appel de fonction. 2. Le coût d adaptation au modèle de programmation : Notre implémentation selon le modèle de programmation ne profite pas complètement des mécanismes matériels fournis par le SME. Ce dernier peut exécuter un micro-programme permettant de réaliser une suite d opérations complexes sur les données. Alors qu avec notre modèle de programmation on est obligé de notifier le processeur de la fin de chaque opération élémentaire de traitement de données et attendre la fin de la prochaine opération à exécuter. Il est évident que dans les cas d implémentation selon la configuration avec le modèle de programmation ou avec la MVR complète sur le circuit MAGALI, la taille mémoire requise pour le programme exécutable sera toujours supérieure à celle requise par une implémentation native. Ceci est du au code supplémentaire correspondant à la machine virtuelle et à la librairie RVM API. Néanmoins, des solutions comme le chargement dynamique de librairie (importer à la demande les librairies logicielles requises) peuvent être expérimentées pour réduire la taille de la mémoire requise. 5.3 Proposition de techniques d optimisation Dans cette section, nous proposons des techniques d optimisation permettant de réduire le temps d exécution des applications radios implémentées selon notre modèle de programmation et plus particulièrement avec la machine virtuelle radio. Ces techniques d optimisation sont des méthodes existantes issues du domaine informatique appliquées dans les environnements PC. Nous expliquons comment ces techniques peuvent être utilisées dans le cadre de notre implémentation de la MVR et analysons leurs perspectives d améliorations. 5.3.1 Compilation à la volée Ils existent principalement deux alternatives pour l exécution d un langage interprété : i) Le moteur d exécution de la VM est un interpréteur qui traduit chaque instruction du langage directement sur la machine cible en manipulant les structures de données associées à la VM. ii) La première fois qu un bloc de code est interprété, il est aussi compilé en code natif du processeur hôte de la VM. Il sera exécuté directement lors d une prochaine exécution dans un autre processus séparé de celui de la VM directement par le processeur physique. Dans notre cas d implémentation la VM Lua exécute le bytecode radio selon la méthode classique i). La deuxième configuration d exécution est appelée compilation à la volée, appelée aussi JIT (Just In Time). Cette technique est utilisée conjointement avec l interprétation, pour profiter des avantages des langages compilés à savoir la rapidité d exécution. Aycock explique dans [85] que la compilation à la volée n est pas très récente, historiquement il y a eu plusieurs tentatives de faire de la compilation dynamique : Une étude empirique pendant les années 70 par Knuth et al. [86] a montré que la plus part des programmes passent la majorité de leurs temps dans l exécution d une minorité de code (90% du temps dans 10% du code). Dakin et Poole (1973) dans [87], ainsi que Dawson en 1973 dans [88] ont proposé une technique d implémentation appelée «Mixed code» : les parties les plus fréquemment utilisées par le programme devront être écrits en langage natif et ceux qui sont le moins devront être écrits en langage interprété. Par cette technique on garantie un temps d exécution semblable à celui des langages compilés. Cette idée n a pas été retenue parce qu elle suppose la cohabitation 99

5.3 Proposition de techniques d optimisation d un interpréteur et d un compilateur ce qui est très lourd pour les systèmes de l époque. De plus, cette technique demande une combinaison de fine granularité de code natif et de code interprété : le fait d écrire le programme en langage interprété et les bibliothèques en natif comme il est cas dans notre implémentation de la MVR n est pas considéré comme du «Mixed code». La première version du langage Java était totalement interprétée et ses performances étaient catastrophiques par rapport à un langage compilé. Tyma explique dans [89] que Java est un langage très lent, il affirme : «Java isn t just slow, it s really slow, surprisingly slow». Les ingénieurs de Sun Microsystems ont fait l observation que l interprétation à elle seule occupait 68% du temps d exécution. Les solutions proposés étaient d utiliser un compilateur à la volée et cela n est pas suffisant parce qu il faudrait aussi considérer les optimisations de code. On s est aperçu que les techniques classiques d optimisation étaient très lourdes pour être considérées pendant l exécution. Une des solutions qui ont été proposées est de décaler le processus d optimisation de code le plus tard avant l exécution, cela en ajoutant au bytecode les informations requises pour une compilation JIT plus efficace sous la forme d annotations. Dans le cadre de l amélioration des performances, l idée «continious compilation» a été proposé par Plezbert and Cytron en 1997 dans [90], qui suggèrent d utiliser en parallèle un compilateur et un interpréteur et de préférence sur deux processeurs physiques différents afin d obtenir les meilleures performances en temps d exécution. Aujourd hui la compilation JIT a atteint un niveau élevé de maturité de la sorte qu on atteint des temps d exécution semblables à ceux des langages compilés. Comme exemple, on cite les machines virtuelles Java actuelles qui utilisent une compilation adaptative (compilateur JIT HotSpot [91]) : pendant l exécution du programme la VM rassemble des informations liées au comportement du programme, cette phase est appelée «profiling». Elle permet de déterminer les parties qui seront fréquemment appelées dans le programme. Ces informations permettent au compilateur JIT de faire des optimisations agressives sur le code natif généré. Ce code est ensuite mis en cache pour d ultérieures utilisations. Le surcoût de l interprétation peut être réduit en utilisant les techniques de compilation à la volée. On affirme dans [92] qu avec un JIT sur une architecture PC x86, les programmes Lua sont cinq fois plus rapide. Nous estimons avoir les mêmes performances avec un processeur ARM. 5.3.2 Traduction de code La traduction de code appelée aussi «binary translation» est une technique qui permet de traduire un jeu d instruction destiné pour être exécuter sur une architecture donnée, vers un autre jeu d instruction, sémantiquement équivalent, pour une autre architecture. Cifuentes et al expliquent dans [93] les trois types de traduction de code : 1) traduction statique de code : est réalisée avant l exécution du programme exécutable. Le traducteur de code procède d abord par une étape de désassemblage du code objet. Ensuite le code résultant est traduit selon une représentation intermédiaire (généralement vers un code à trois adresse). Puis ce code subit une phase d optimisation indépendamment de l architecture cible. Enfin, on utilise un générateur de code classique pour l architecture cible qui générer le binaire selon le nouveau jeu d instruction. Les performances du code généré sont quasiment équivalentes à celles d un programme compilé directement pour cette architecture. 2) traduction dynamique de code : se base sur les techniques de compilation dynamique pour réaliser la traduction de code pendant l exécution. Dans ce cas, le programme exécutable est dynamiquement analysé et traduit vers l architecture cible. La traduction dynamique de code peut surpasser les limitations de la traduction statique puisque cette technique dispose de plus d informations liées à l exécution (contenu des adresses mémoires ou des registres). La traduction dynamique de code est réalisée selon les étapes suivantes : la face avant du traducteur est d abord alimentée par le programme objet. Elle 100

5.3 Proposition de techniques d optimisation découpe le code, à fur et à mesure, en bloc de bases (bloc de code autonome ne contenant pas d instruction de branchement) et génère pour chaque bloc une représentation intermédiaire. Celle ci alimentera le générateur de code correspondant à la plateforme physique. Les optimisations sont faites chaque fois qu un bloc de base est exécuté un certain nombre de fois. Le temps d exécution d un programme qui est traduit dynamiquement est généralement deux à quatre fois plus lent qu un programme natif. La technique de compilation à la volée JIT peut être considérée comme un cas particulier de traduction dynamique de code où le jeu d instruction de départ est le bytecode. 3) traduction de code reciblable (en anglais, «retargetable») : ce procédé est proposé dans [93]. La face avant du traducteur binaire est toujours implémenté par un désassembleur que ce soit en traduction statique ou dynamique. L idée est au lieu d avoir un désassembleur spécifique à chaque jeu d instruction, remplacer celui ci par un désassembleur générique reconfigurable. La configuration consiste à fournir deux spécifications : i) spécification de la machine, par exemple, définir le type de «endianness» et ii) les règles de correspondance appelées aussi «matching statements». Dans notre contexte de MVR, nous proposons d adapter la technique de compilation à la volée, JIT, expliquée précédemment, comme le montre la figure FIG. 5.8(b) : en faisant usage d une traduction de code statique. Cette traduction binaire nécessite une analyse statique du code avant son exécution pour générer des programmes natifs. De cette façon, le fait de traduire le code d accès au données par la MVR et son transtypage depuis son format natif vers le format de la VM et vice versa, pourrait être évité. La séquence d appels de fonctions sera ainsi réalisée nativement. Avec de telles optimisations on pourrait réduire le surcoût d interprétation jusqu à atteindre les performances de la configuration native. Appel de primitives RVM Traitements Radio (lua_cos, lua_atan, lua_mathlib) Bytecode Lua exécuté par la VM Lua (1) (2) (1) (2) (1) (2) (1) (2) Implémentation des primitives RVM cos atan... Code C natif exécuté par le processeur physique (1) Correspondance entre appel de fonction et implémentation native + transtypage de données (de Lua vers le natif) (2) retour des fonction natives + transtypage de données (du natif vers Lua) a) Schéma d exécution de la RVM Appel de primitives RVM Traitements Radio (lua_cos, lua_atan, lua_mathlib) Bytecode Lua exécuté par la VM Lua Compilation à l avance / traduction binaire Implémentation des primitives RVM cos atan... Code C natif exécuté par le processeur physique b) Schéma d exécution de la RVM avec traduction binaire FIG. 5.8: Traduction de code appliquée à un programme radio Le programme du PP (voir section 3.3 dans le chapitre 3) est constitué d une combinaison de de macroinstuctions de gestion du flot de données et d instructions de calcul. Ce programme est fournit en bytecode 101

5.3 Proposition de techniques d optimisation avec le programme de l application de la MVR. Une analyse statique de ce code devrait permettre de déduire le code de gestion de flot de données à exprimer en un seul micro-programme pour le SME. L analyseur de bytecode devrait aussi fournir le code de calcul du PP avec les primitives adéquates de synchronisation, qui sera exécuté par le processeur natif. De la même manière, une phase d analyse statique du code de l application permettrait d extraire l ordonnancement de l exécution des configurations pour chaque ressource de la plateforme. Dans notre cas d étude, les programmes d ordonnancement de configuration correspondants à chaque ressource utilisée du circuit MAGALI seront ensuite générés afin de configurer les contrôleurs CCC associés aux ressources considérées. On obtient ainsi des performances équivalentes à celles d une implémentation native. 5.3.3 Accélération matérielle Les causes principales de surcoûts pour le concept de MVR sont : le processus d interprétation du bytecode et le processus d adaptation de notre modèle de programmation générique au modèle d exécution de la plateforme physique. L accélération matérielle est une solution qui permet de réduire le temps d exécution de ces traitements supplémentaires afin d atteindre les performances d une configuration d implémentation native. Dans la littérature, on trouve que quasiment toutes les approches d optimisation de l interprétation ont ciblé la machine virtuelle Java. On explique ceci par la popularité du langage Java et les intérêts économiques que représente son utilisation sur des équipements mobiles à ressources limitées. Schoeberl montre dans [94] que la spécification de Java n est pas adapté pour les systèmes embarqués pour différentes raisons, par exemple, un thread Java de moindre priorité peut préempter un thread de plus haute priorité ; les stratégies de ramasse-miettes (garbage collector) ne sont pas adaptées pour les systèmes à temps réels dur ; les bibliothèques standards du langages Java occupent à elles seules 15 Mo de mémoire ; etc. Il propose une VM Java optimisée pour les systèmes embarqués qu il appelle JOP[94]. Les accélérateurs matériels pour la VM Java sont répartis en deux classes : i) Les coprocesseurs qui réalisent soit la traduction binaire vers un jeu d instruction d un processeur natif, par exemple, Hard-Int[95] ; soit l exécution partielle du bytecode java comme le coprocesseur Jazelle [79] intégré dans certains processeurs ARM. ii) Des machines à piles matérielles qui réalisent le bytecode Java en entier. Par exemple, picojava[96], ajile [97], etc. Ou réalise une partie du bytecode comme FemtoJava [98]. L accélération matérielle pour l exécution du bytecode permet d obtenir des performances similaires à celles d exécution d un code natif. Dans le contexte de la MVR, l accélération matérielle peut être réalisée sous la forme d un processeur qui réalise entièrement le bytecode radio (RVM API). L envoie de messages de configuration pour les contrôleurs incorporés dans les ressources du circuit MAGALI se fait alors en quelques cycles d horloge et ne nécessitent que quelques accès mémoires. Une autre alternative logicielle / matérielle consiste à réaliser un coprocesseur qui analyse le bytecode radio et le traduit d une façon optimisée vers le code natif du processeur principal. Conclusion Afin de qualifier et quantifier le surcoût introduit par le concept de MVR, nous avons réalisé des expérimentations sur la plateforme de simulation du circuit MAGALI. Dans ce chapitre, on a analysé les causes principales du surcoût. On aussi formalisé son évolution avec le nombre de données à traiter (voir la 1 re expérimentation). Nous avons ensuite évalué le surcoût d interprétation dans le cas ou la MVR réalise des 102

5.3 Proposition de techniques d optimisation calculs nécessaires à un algorithme de traitement de signal (voir 2 e expérimentation). En résumé le surcoût est du d abord à l adaptation de notre modèle de programmation (rkpn) aux caractéristiques de l environnent d exécution (le circuit MAGALI). Ce surcoût résulte en un temps d exécution jusqu à deux fois plus lent que celui d un programme optimisé pour le circuit. D autre part le surcoût est du aux traitements supplémentaires d interprétation du bytecode sur le processeur natif qui résulte en l augmentation du temps d exécution de deux à six fois par rapport à celui passé pour un programme optimisé sans VM. Bien que ces facteurs de surcoût semble très importants pour le contexte radio de la MVR, nous avons proposé des solutions techniques issues du domaine logiciel qui sont spécifiques aux VM comme la compilation à la volée (JIT), la traduction de code ou l accélération matérielle. Enfin, nous décrivons comment ces techniques peuvent être adaptées au contexte de notre modèle de programmation sur la plateforme MAGALI afin d annuler les surcoûts précédemment décris. 103

6 CHAPITRE Démonstrateur 3GPP/LTE Sommaire Introduction........................................... 105 6.1 Le standard 3GPP LTE.................................. 105 6.1.1 Aperçu du standard 3GPP/LTE........................... 106 6.1.2 La couche physique 3GPP/LTE........................... 108 6.2 Implémentation d un récepteur 3GPP/LTE sur MAGALI................ 110 6.2.1 Partitionnement de l application sur MAGALI.................. 111 6.2.2 Schémas de configuration et de contrôle...................... 113 6.3 Implémentation par la machine virtuelle radio..................... 115 6.3.1 Conception de l application récepteur LTE (mode (5))............... 115 6.3.2 Résultats et Analyse................................ 119 Conclusion............................................ 121 104

6.1 Le standard 3GPP LTE Introduction Le traitement en bande de base des protocoles récents de télécommunication nécessite de plus en plus de flexibilité. En effet, ces protocoles réalisent des communications en mode paquet et utilisent dans la plupart des techniques radios communes (modulation OFDM, décodage MIMO, etc). Pour cela, un ensemble d opérateurs communs de traitement du signal ont été identifiés dans la littérature. L implémentation d un protocole consiste alors en une configuration dynamique de ces opérateurs et un contrôle fin d exécution qui nécessite souvent un accès aux données. Dans cette optique, le circuit MAGALI a été conçu de manière à intégrer un ensemble d unités de traitement à haut débit, reconfigurables et interconnectées par un réseau sur puce permettant de supporter les applications de télécommunication de quatrième génération et plus particulièrement la famille de protocoles basés sur la technique de modulation OFDMA. Au laboratoire LETI du CEA on a réalisé un des premiers démonstrateur d un récepteur conforme au standard 3GPP/LTE 8R sur le circuit MAGALI. Ce démonstrateur est une preuve de concept qui valide les fondements de l architecture du circuit et valide aussi le modèle de programmation associé. Dans ce chapitre, nous proposons une étude de cas d implémentation d un protocole de couche physique du standard 3GPP/LTE en faisant usage du concept de MVR. Nous analysons l influence des facteurs de surcoût étudiés dans le chapitre précédents sur l exécution de l application radio dans un contexte réaliste. Ce chapitre est organisé en trois sections : Dans la section 6.1, nous présentons d abord les principes fondamentaux et les caractéristiques du standard 3GPP/LTE ensuite nous nous focalisons sur les détails de sa couche physique dont l implémentation sera décrite dans le reste de ce chapitre. Nous décrivons ensuite dans la section 6.2, l implémentation du récepteur 3GPP/LTE réalisée par le CEA/- LETI sur le circuit MAGALI : Nous présentons les détails de partitionnement de l application sur les ressources de la plateforme d exécution et nous analysons les schémas de configuration utilisés lors de chaque phases d exécution. Enfin, nous vérifions cette implémentations par rapport aux contraintes temps réel de l application. Dans la section 6.3, on explique notre réalisation du récepteur 3GPP/LTE implémenté en un bytecode à exécuter par la MVR. Nous analysons les différences avec l implémentation native et comment celles ci influent sur les performances globales du système. 6.1 Le standard 3GPP LTE 3GPP/LTE [99, 100] est un standard de communication cellulaire qui vient remplacer UMTS. Il été défini par 3GPP (Third Generation Partnership Project) qui est un groupement d organisations de standardisation régionaux en télécommunication, comme par exemple, l ETSI en europe, ATSI aux états unis, ARIB/TTC au Japon, etc. 3GPP/LTE repose principalement sur les techniques radios OFDMA et MIMO. Celles ci lui permettent de répondre aux nouveaux besoins en haut débit, mobilité et latence. Ce nouveau standard offre ainsi de nouvelles opportunités aux opérateurs de télécommunication leurs permettant de proposer de nouveaux services comme la visioconférence en haute définition, la voix sur IP de haute qualité, etc. Dans ce qui suit nous présentons un aperçu du standard 3GPP/LTE puis nous détaillerons sa couche physique. 105

6.1 Le standard 3GPP LTE 6.1.1 Aperçu du standard 3GPP/LTE Historique et statut du 3GPP/LTE La naissance du protocole LTE remonte à 2004, lorsque le 3GPP a lancé un projet pour définir l évolution à long terme du standard UMTS. Les premières spécifications sont connues sous l appellation E-UTRA (Evolved UMTS Terrestrial Radio Access) ou aussi E-UTRAN (Evolved UMTS Terrestrial Radio Access Network). La première version du standard LTE est documenté dans la révision 8 des spécifications du 3GPP. Les premiers terminaux mobiles conformes à la norme LTE sont prévus pour 2012. Aujourd hui beaucoup d entreprises sont en train de mettre en place des démonstrateurs d équipements conformes à la spécification. Les objectifs du 3GPP/LTE Les objectifs du standard 3GPP/LTE se résument dans les points suivants : Hautes performances : 3GPP/LTE permet un débit théorique maximal de 100 Mbit/s pour les transmissions descendantes et jusqu à 50 Mbit/s pour les transmissions ascendantes. Le 3GPP/LTE permet entre autres de réduire les latences de transmission de paquets : la latence pour un paquet et égale à 10 ms (comparé au 40-50 ms du standard HSPA). Ceci améliore la réactivité des applications communicantes et offre de nouvelles possibilités de services à contraintes temps réel. Compatibilité avec les protocoles existants : 3GPP/LTE est compatible avec les standards actuels déployés par les opérateurs de télécommunication comme le GPRS/EDGE/UMTS. Il permet de réaliser le transfert intercellulaire (handover) aux réseaux existants. Il utilise la même bande de transmission des standards existants 2G et 3G et d autres bandes spectrales. Mobilité accrue : 3GPP/LTE devra supporter la mobilité jusqu à 350 Km/h. Support de deux modes de duplexage (pour les communications ascendantes et descendantes) : au moyen de division de fréquence appelée aussi FDD (Frequency Division Duplex) ou division de temps appelée TDD (Time Division Duplex). Ceci permet de s adapter aux régulations concernant l allocation spectrale de chaque région. L architecture de l interface radio 3GPP/LTE Nous nous intéressons dans cette partie à la pile protocolaire déployée au niveau des stations de bases appelés aussi enb (Evolved NodeB) et sur les équipements mobiles utilisateurs ou UE (User Equipment). La figure FIG. 6.1 représente l architecture de l interface radio LTE des enb et des UE. Les couches protocolaires de LTE incluent un plan de contrôle et un plan de données. Les données à émettre à partir du réseau d infrastructure appelé aussi CN (Core Network) rentrent dans l un des services supports appelés RAB (Radio Access Bearers) sous la forme de paquet IP (Internet Protocol). Chaque RAB représente un service garantissant une qualité de service (QoS) adaptée à une classe particulière d applications multimédia mobiles. Un paquet à transmettre passe différentes entités protocolaires : PDCP (Packet Data Convergence Protocol) : chaque entête IP est compressé par ROHC (Robust Header Compression) [101, 102] pour une transmission efficace sur le réseau. Ensuite le paquet subit des algorithmes de sécurité. Les données à transmettre seront ainsi chiffrées et leur intégrité est protégée. RLC (Radio Link Control) : cette entité s occupe de la segmentation / concaténation des données. La gestion des retransmissions et l ordonnancement des paquets pour les couches supérieures. MAC (Medium Access Control) : est la couche de contrôle d accès au medium, elle ordonnance les 106

6.1 Le standard 3GPP LTE Radio Bearers PDCP ROHC ROHC Security Security BCCH PCCH RLC Segm. ARQ Segm. ARQ Logical Channels Scheduling and Priority Handling MAC Multiplexing UE N HARQ Transport Channels FIG. 6.1: Architecture de l interface radio LTE transmissions ascendantes et descendantes des utilisateurs au niveau des enb et aussi gère les retransmissions par l algorithme HARQ [103]. Couche physique (PHY) : est l entité qui réalise le codage / décodage, modulation /démodulation, la répartitions des symboles sur les différentes antennes, etc. La couche MAC offre ses services à la couche RLC sous forme de canaux logiques. Un canal logique est défini par le type d information qu il peut transmettre. Généralement, les canaux logiques sont classés comme : i/ des canaux de contrôle dédiés à la transmission des paquets de contrôle et de configuration nécessaires aux mécanismes du système LTE. ii/ des canaux de données, dédiés à la transmission des données des utilisateurs. Par exemple, dans la figure FIG. 6.1, BCCH (Broadcast Control Channel) et PCCH (Paging Control Channel) sont deux canaux logiques de contrôle. La couche physique offre ses services à la couche MAC sous forme de canaux de transport. Un canal de transport définit comment et avec quelles caractéristiques les données sont transmises à travers l interface réseau. Les données à transmettre à travers les canaux de transport sont organisées en bloc de transport. A chaque intervalle de temps de transmission appelé aussi TTI (Transmission Time Interval), un bloc de transport est transmis. A chaque bloc de transmission est associé un format de transport qui spécifie la taille du bloc, le schéma de modulation utilisé et la répartition des symboles sur les antennes. En variant le format 107

6.1 Le standard 3GPP LTE de transport, la couche MAC réalise différents débits de transmission. Le contrôle du débit est ainsi connu comme la sélection de format de transmission. 6.1.2 La couche physique 3GPP/LTE La couche physique 3GPP/LTE se base sur la technique d accès multiple OFDMA (Orthogonal Frequency Division Multiple Access) pour les communications descendantes et la technique SC-FDMA (Single Carrier Frequency Division Multiple Access) pour les communications ascendantes, tout deux avec des préfixes cycliques pour éviter les interférences inter-symboles. Une trame 3GPP/LTE a une longueur de 10 ms. Deux types de trames ont été définis pour la couche physique 3GPP/LTE : i/ Type-1 pour les transmissions qui utilisent le duplexage FDD. ii/ Type-2 pour pour les transmissions qui utilisent le duplexage TDD. Dans la suite de ce chapitre on considère que la partie de transmission descendante d un système LTE du coté du récepteur. On s intéressera au mode opératoire en duplexage fréquentiel. Pour cela on considère les trames de type-1. Trames de type 1 Une trame de type-1 contient 20 slots dont chacun dure 0.5 ms. Chaque deux slots adjacents constituent une sous-trame de longueur 1 ms (voir figure FIG. 6.2). Une sous-trame correspond exactement à un TTI. 1 slot Longueur d une trame LTE = 10 ms #0 #1 #2 #3 #4 #17 #18 #19 Sous trame = TTI (1 ms) FIG. 6.2: Structure de la trame de niveau physique LTE type-1 Chaque slot est constitué de 7 symboles OFDM dont chacun est précédé par un préfixe cyclique pour éviter les interférences inter-symboles (voir figure FIG. 6.3). 1 slot = 7 OFDM symboles = 0.5 ms CP 0 CP 1 CP 2 CP 3 CP 4 CP 5 CP 6 FIG. 6.3: Structure d un slot de trame type-1 LTE Chaque symbole est réparti dans un ensemble de blocs de ressources appelés aussi PRB (Physical Resource Block). En fait, le spectre correspondant à un slot (7 symboles OFDM) est subdivisé en plusieurs 108

6.1 Le standard 3GPP LTE blocs de 12 sous porteuses dont chacun est appelé PRB. À chaque TTI, la station de base (enb) alloue à chaque utilisateur un ensemble de PRB pour la transmission des données. Le PRB constitue le plus petit élément allouable par la station de base. La figure FIG. 6.4 illustre la décomposition d un slot en PRB. La bande passante disponible pour les transmissions descendantes selon la spécification 3GPP/LTE varie selon le mode opératoire de 1.25MHz à 20MHz. Chaque sous porteuse occupe 15Hz de bande passante et le nombre total de sous porteuses N BW dépend directement de la largeur de la bande passante du mode utilisé. Fréquence 7 symboles OFDM PRB = 7 symboles x 12 sous porteuses N BW 12 sous porteuses sous-porteuses élément de ressource Temps FIG. 6.4: Décomposition d un slot de trame LTE en blocs de ressources On appelle élément de ressource toute case de la grille d un PRB. Elle est identifiée par le couple (temps, sous-porteuse). Dans les réseaux orientés paquets, une trame commence souvent par un préambule (une suite de symboles de référence) qui sert pour l estimation de l erreur CFO, la synchronisation, l estimation de canal, etc. 3GPP/LTE a la particularité de ne pas utiliser de préambule. Il utilise plutôt des signaux de référence spéciaux qui sont disséminés dans les PRB. Les signaux de référence sont transmis dans le premier et le cinquième symbole OFDM de chaque slot. 3GPP/LTE peut optionnellement exploiter plusieurs antennes pour l émission et plusieurs antennes pour la réception afin d améliorer la robustesse des liens et et d augmenter les débits. Cette technique est appelée MIMO (Multiple Input Multiple Output). La réception d une transmission MIMO nécessite de calculer la réponse impulsionnelle du canal depuis toutes les combinaisons d antennes émettrices avec les antennes réceptrices. Pour cela l émetteur envoie préalablement, d une façon séquentielle, des signaux de référence permettant de calculer les coefficients de correction pour chaque antenne. Ensuite, les données peuvent être transmises simultanément à partir des antennes disponibles de l émetteur. Les données envoyées par chacune des antennes peuvent être retrouvées en résolvant un système d équations linéaires. Un système MIMO est défini en terme de N emetteur x N recepteur. 3GPP/LTE définit quatre configurations de systèmes MIMO : 1 x 1, 2 x 2, 3 x 2 et 4 x 2. Deux multiplexages spatiaux est le maximum possible pour un système LTE. Dans le cas de quatre antennes émettrices, elles sont utilisées deux par deux (redondance du même flux de données sur deux antennes) afin de renforcer le signal transmis. 109

6.2 Implémentation d un récepteur 3GPP/LTE sur MAGALI 6.2 Implémentation d un récepteur 3GPP/LTE sur MAGALI Dans cette section, nous présentons une implémentation d un récepteur 3GPP/LTE sur le circuit MAGALI. Le système conçu utilise la technique MIMO avec une transmission sur quatre antennes et une réception sur deux antennes. Ceci permet de profiter de la diversité spectrale et des avantages du multiplexage spatial. Les caractéristiques du système LTE que nous considérons sont résumées dans le tableau suivant : Bande passante B C 10 MHz Fréquence d échantillonage f S = 1/T S 15.36 MHz période d échantillonage T S 65.1 ns Taille de la fft N FFT 1024 Nombre d échantillons du préfixe cyclique N CP 72 Nombre d échantillons dans un symbole N 0 1096 Durée d un symbole ofdm T 66.66 µs Durée d un intervalle de garde T CP 4.69 µs Durée totale d un symbole ofdm T 0 71.35 µs Espacement inter-porteuses 1/T 15 KHz TAB. 6.1: Les paramètres principaux du prototype de système LTE Dans cette implémentation, chaque TTI incorpore quatre symboles OFDM de référence (voir figure FIG. 6.5) dédiés pour embarquer les signaux pilotes. Ceux-ci permettent au récepteur de calculer les coefficients d estimation de canal à partir de chaque antenne. Ces symboles de référence incluent aussi des PRB de signalisation et de contrôle pour la couche physique et la couche MAC. Bande de garde 212 sous porteuses Bande de garde 212 sous porteuses Z Z Z Z... Z R1 R2 R3 R4 S S R1 R2 R3 R4 S S... R1 R2 R3 R4 S S R1 R2 R3 R4 S S Z... Z Z Z Z R1 Symbole pilote pour l antenne 1 R2 Symbole pilote pour l antenne 2 R3 Symbole pilote pour l antenne 3 R4 Symbole pilote pour l antenne 4 S symbole de signalisation L1/L2 Z Porteuse nulle FIG. 6.5: Structure d un symbole OFDM de référence LTE Enfin, la structure de la trame à démoduler pour le démonstrateur LTE est la suivante : les symboles OFDM numéro 0 et numéro 4 (voir figure FIG.6.3), de chaque slot de la trame contiennent exactement 400 symboles pilotes pour l estimation de canal répartis orthogonalement en fréquence et 200 symboles de signalisation DL-MAP (informations concernant les blocs alloués par utilisateur, la technique de modulation utilisée, le codage, etc). Les symboles restants incorporent exactement 600 symboles de données suivant un codage «double Alamouti 4 x 2» en temps [104]. Dans la suite de cette section nous allons d abord expliquer le partitionnement de l application récepteur LTE pour son exécution sur l architecture du circuit MAGALI. Ensuite nous présentons sa mise en œuvre sur le circuit et les schémas de configurations réalisés par l équipe de recherche du LISAN. 110

6.2 Implémentation d un récepteur 3GPP/LTE sur MAGALI 6.2.1 Partitionnement de l application sur MAGALI Y RF Frontend 1 RF Frontend 2 Y AGC + Synchronisation Démodulation OFDM (FFT) Démodulation OFDM (FFT) Décadrage OFDM (deframing) Décadrage OFDM (deframing) estimation CFO Correction CFO (Rotor) Correction CFO (Rotor) Estimation de canal MIMO Estimation de canal MIMO Démultiplexage des coeffs estimés Data DL map Data DL map (2x1) et (4x2) Décodeur MIMO Egalisation Démodulation M-aire Dé-entralacement (Dé-interleaving) H-ARQ-Rx Dé-embrouillage (de-scrambling) MAC FIG. 6.6: Découpage en modules fonctionnels du récepteur LTE réalisé par le laboratoire LISAN du CEA- LETI 111

6.2 Implémentation d un récepteur 3GPP/LTE sur MAGALI La première étape pour la réalisation du démonstrateur LTE consiste dans le découpage de l application en différents modules fonctionnels. La figure FIG. 6.6 représente le schéma fonctionnel du récepteur réalisé. Le processus de réception LTE peut être décrit comme suit : 1- Deux signaux analogiques sont reçus à partir des deux antennes du système. L amplitude des signaux reçus est contrôlée par un bloc AGC (Automatic Gain Control). 2- Les deux signaux sont ensuite échantillonnés et quantifiés. Le résultat de cette étape est la production de deux flux numériques complexes (I,Q). 3- Un bloc de synchronisation permet de détecter la cellule radio à laquelle l équipement appartient, détecter le début de trame et de réguler la fréquence d échantillonage par rapport à celle de la station de base. 4- Les deux signaux numériques complexes sont démodulés (application de l opérateur FFT). Les données et les symboles de références sont ensuite séparés pour chaque flux en provenance de chaque antenne. Cette opération est appelé décadrage ou «deframing». 5- L étape suivante consiste à corriger l erreur CFO résiduelle (différence de fréquence entre l horloge de l équipement utilisateur et l horloge de la station de base). L estimation du déphasage se base sur un algorithme de corrélation de réplicas d un même symbole pilote en provenance des deux antennes de réception. Les données et les symboles de références sont ensuite compensés en fréquence. 6- Le système exécute ensuite la phase d estimation de canal. Celle ci utilise les symboles pilotes en provenance des deux antennes de réception et réalise une corrélation avec les séquences de références. Le bloc estimation de canal calcule les coefficients de caractéristiques des canaux liant chaque paires Tx/Rx. 7- Les deux flux de symboles d informations et les coefficients de correction qui leurs correspondent alimentent ensuite le décodeur MIMO. A la sortie de ce bloc, on aura deux flux de données qui correspondent à ceux envoyés par chacun des deux couples d antennes. 8- Le reste de la chaîne de traitement correspond aux fonctions inverses d un émetteur. Celles-ci se résument en les étapes suivantes : 8.a- La démodulation m-aire qui convertit chaque point de la constellation en sa représentation binaire. 8.b- Dé-entrelacement binaire qui réordonne les données binaire codées. 8.c- Le bloc H-ARQ (Hybrid - Automatic Repeat Request) vérifie l occurrence d erreur dans le paquet reçu. Dans le cas ou il y a des erreurs, ce module demande une retransmission avec plus d informations (redondance par FEC). Si le paquet échoue encore, alors le bloc H-ARQ combine les informations reçues lors des deux transmissions (Soft combining). 8.d- Les flux binaires résultants de l étape précédentes sont décodés par un turbo-décodeur. 8.e- La dernière étape de la couche physique consiste à dé-embrouiller (de-scrambling) les flux binaires pour remettre le PSDU (PHY Service Data Unit) à la couche MAC. 3GPP/LTE supporte différents schémas de modulation et de codage. Les débits de transmission correspondants aux modes opératoires du récepteur LTE du CEA/LETI sont illustrés dans le tableau suivant : Mode opératoire Débit par UE Débit maximale (1) qpsk, 1/2, 1 prb, B info =120 bits 0.24 Mbit/s 12 Mbit/s (2) qpsk, 1/2, 2 prb, B info =240 bits 0.48 Mbit/s 12 Mbit/s (3) 16qam, 2/3, 2 prb, B info =640 bits 1.28 Mbit/s 32 Mbit/s (4) 16qam, 2/3, 10 prb, B info =3200 bits 6.4 Mbit/s 32 Mbit/s (5) 64qam, 3/4, 10 prb, B info =5400 bits 10.8 Mbit/s 54 Mbit/s TAB. 6.2: Les débits des transmissions descendantes du prototype de système LTE 112

6.2 Implémentation d un récepteur 3GPP/LTE sur MAGALI Dans le tableau TAB. 6.2, un mode opératoire est défini par une technique de modulation (QPSK, 16 QAM, 64 QAM, etc), un taux de codage, le nombre de PRB par slot qui sont affectés à chaque utilisateur, et B info est la taille de l information utile à transmettre par slot. Les modes du 3GPP/LTE ont différentes contraintes temps réel. Les modules fonctionnels présentés dans la figure 6.6 sont communs aux différents modes opératoires de LTE. Ils sont implémentés par les unités de traitement présentes sur le circuit MAGALI qui permettent d être reconfigurées pour supporter les différents modes opératoires. 6.2.2 Schémas de configuration et de contrôle L application considérée correspond au traitement d un seul TTI. Nous rappelons qu une trame physique LTE est constituée de dix sous-trames (TTI). Le traitement d une trame entière consiste ainsi à rejouer dix fois le scénario de configuration réalisé pour un TTI. Le traitement d un TTI correspond à la démodulation et au décodage de deux flux de 14 symboles OFDM en provenance des deux antennes du récepteur. Chaque symbole OFDM contient 1024 sous porteuses. La correspondance entre la description fonctionnelle du récepteur de la figure FIG. 6.6 et sa réalisation sur les ressources matérielles du circuit MAGALI nécessite la gestion de multiples configurations et de flots de traitement de données complexes. La figure FIG. 6.7 représente les flots de données à configurer qui correspondent à quatre phases d exécution de l application. (a) I/O NoC OFDM 1 SME 1 Mephisto 1 SME 3 OFDM 2 SME 2 Mephisto 2 (b) (c) Mephisto 1 0 1 2 3 0 1 SME 1 Mephisto 1 2 3 SME 1 Mephisto 3 SME 3 SME 2 Mephisto 2 SME 2 Mephisto 4 Mephisto 2 (d) SME 3 Rx BIT CHAN DEC I/O NoC FIG. 6.7: Les flots de traitement de données nécessaires aux quatre phases d exécution d un récepteur LTE (figure extraite de [66]) Dans le démonstrateur LTE du LETI les premières fonctions de la chaîne de réception à savoir la synchronisation de trame et le bloc AGC sont réalisés sur un FPGA qui est lié au réseau sur puce du circuit MAGALI. 113

6.2 Implémentation d un récepteur 3GPP/LTE sur MAGALI La première phase d exécution (a) dans figure FIG. 6.7, consiste à la démodulation OFDM des symboles reçu à partir de chaque antenne et le décadrage des sous poreuses (tri des sous porteuses de données et des sous porteuses pilotes de référence). Les résultats de l étage de démodulation sont rangés en mémoire des SME 1 et SME 2. Les deux DSP VLIW MEPHISTO 1 et MEPHISTO 2 réalisent l estimation de CFO à partir des symboles pilotes stockés dans SME 1 et SME 2. Cette opération est réalisée en pipeline : les SME transfèrent une copie des symboles pilotes aux MEPHISTO au fur et à mesure que ceux ci sont écrits sur leurs mémoires. Le MEPHISTO 1 a aussi le rôle de calculer la moyenne des coefficients d estimation de CFO à partir des deux antennes de réception. Ces résultats sont enfin stockés dans le SME 3. Durant toute la phase d exécution (a) le processeur ARM ne fait aucun traitement. En effet, lors du démarrage du système les configurations nécessaires sont déployés par un hôte extérieur (ordinateur lié à la carte du démonstrateur à travers une interface ETHERNET). Le processeur ARM lance le traitement en envoyant des messages de contrôle de type «enable task» à toutes les ressources en question et attend une notification par interruption depuis le SME 3 lorsque celui ci termine de recevoir les coefficients d estimation de CFO. Avant le passage à la deuxième phase d exécution, le processeur ARM de la plateforme accède en lecture aux données d estimation CFO stockées dans la mémoire du SME 3. Il calcul ensuite les coefficients de correction CFO pour les symboles en provenance de chaque couple d antennes d émission. Enfin, il configure avec ces paramètres les quatre MEPHISTO (1,2,3 et 4) pour les phases d exécution ultérieures (b) et (c). La seconde phase d exécution (b) dans FIG. 6.7 consiste à la correction CFO des symboles pilotes puis l estimation de canal. Ces opérations sont réalisées par les MEPHISTO 1 et MEPHISTO 2 sur les symboles pilotes en provenance des SME 1 et SME 2. La phase d exécution suivante (phase (c) dans FIG. 6.7) consiste à démultiplexer les PRB de données en provenance de SME 1 et SME 2 entre les MEPHISTO 3 et MEPHISTO 4. Ces deux MEPHISTO sont configurés pour réaliser la fonction de décodage MIMO. Les MEPHISTO 1 et MEPHISTO 2 sont configurés pour réaliser la correction de canal en amont des blocs de décodage MIMO. Enfin la dernière phase est notée (d) dans FIG. 6.7, elle consiste d abord en la démodulation m-aire et le dé-entrelacement des données. Ceux ci sont réalisés par l IP dédiée RX_BIT. Ensuite, le turbo-décodage est réalisé par l IP CHAN DEC configurée avec le taux de codage correspondant au mode opératoire choisi. Il est à noter qu avant chaque phase d exécution, les configurations des ressources et des flots de données sont réalisées par l ordinateur externe. Lors de chaque phase d exécution, les ressources ordonnancent d une façon autonome leurs configurations. Ceci est du à l usage de leurs dispositifs CCC (voir section 4.1.1). 1 TTI = 998.9 µs 1 TTI = 998.9 µs a (a) b Phase (b) c+d Phase (c) Phase (d) OFDM 1 - OFDM 2 OFDM Mephisto 1 - Mephisto 2 CFO Chan Est. Coef. Interpol. Mephisto 3 - Mephisto 4 MIMO Decod. RX BIT CHAN DEC 100µs 240µs 300µs Demap, De-Interleav, HARQ Turbo decoding 660µs Temps de reconfiguration entre deux phases Temps (µs) FIG. 6.8: Chronogramme des phases d exécution de l application LTE (figure extraite de [66]) 114

6.3 Implémentation par la machine virtuelle radio La figure FIG. 6.8 illustre le partitionnement des fonctionnalités du récepteur sur les ressources matérielles de la plateforme pour chaque phase d exécution. On remarque un temps supplémentaire entre la fin de la phase (b) et le début de phase (c). Ceci est du à des calculs réalisés à partir des symboles de signalisation L1/L2, par le processeur ARM pour déterminer les paramètres de configuration des ressources nécessaires lors des phases (c) et (d). Les résultats expérimentaux du démonstrateur ont montré que le temps total de traitement dépasse le temps de réception d un TTI. Cependant en réalisant un traitement en pipeline de l ensemble des TTI, on arrive à respecter les contraintes temps réel d une trame. En effet la phase (d) utilise des ressources qui ne sont pas partagées et donc le traitement du deuxième TTI peut commencer avec le début de la phase (d). 6.3 Implémentation par la machine virtuelle radio Dans cette section, nous présentons notre implémentation d un récepteur LTE avec le concept de machine virtuelle radio (MVR). L implémentation a été réalisée sur la plateforme de simulation du circuit MAGALI. L application LTE d expérimentation est selon le mode opératoire (5) dont les paramètres sont décrits dans le tableau TAB. 6.2, p112. 6.3.1 Conception de l application récepteur LTE (mode (5)) Pour notre implémentation du récepteur LTE nous avons réutilisé le même partitionnement en bloc fonctionnel décrit dans la section 6.2. Les flots de traitement de données conçus pour une exécution dirigée par la MVR sont différents de ceux conçus pour une application implémentée directement sur le circuit MAGALI. En effet, notre modèle de programmation utilise un contrôleur central (le processeur ARM dans notre cas d étude) qui à chaque phase d exécution : Alloue les ressources matérielles et/ou logicielles nécessaires. Crée dynamiquement les configurations à déployer sur les ressources de traitement alloués. Interconnecte les modules fonctionnels de traitement avec des liens point à point. Par exemple, une ressource ne peut pas recevoir des données à partir d un seul port d entrée depuis plusieurs ressources. Cependant ce cas est possible à programmer dans le cas spécifique de la plateforme MAGALI. Contrôle et ordonnance des micro-phases d exécution élémentaires de fine granularité. Par exemple, la MVR doit relancer l opérateur FFT autant de fois que le nombre désiré de FFT à réaliser sur les données. Dans ce qui suit nous expliquons les flots de traitement et leurs contrôles réalisés par la MVR pour chacune des macro-phases d exécution suivante : (a) démodulation et estimation CFO. (b rvm ) calcul des paramètres de configuration pour les blocs de correction CFO et de décodage MIMO. (b) correction CFO et estimation de canal. (c) interpolation des coefficients de canal et décodage MIMO. (d) démodulation m-aire, dé-entrelacement, turbo-décodage et dé-embrouillage. Phase (a) : démodulation OFDM et estimation du CFO Cette phase d exécution est décrite dans la figure FIG. 6.7 par le flot de traitement (a) pour une implémentation native. Dans ce schéma, le bloc MEPHISTO 1 a une double configuration qui consiste à : (i) Réaliser l estimation de l erreur CFO à partir des symboles pilotes en provenance du bloc OFDM 1. (ii) Calculer la moyenne des coefficients d estimation de CFO à partir des deux antennes de réception. 115

6.3 Implémentation par la machine virtuelle radio Cette double configuration est exécutée en une seule fois par le le cœur de traitement du bloc MEPHISTO 1. Par conséquence, il faut configurer le seule port d entrée du bloc MEPHISTO 1 pour alterner la lecture depuis le bloc OFDM 1 lors de l exécution de la configuration (i). Ensuite, à partir du bloc MEPHISTO 2 pour réaliser la configuration (ii). Pour cela, dans l implémentation native, le contrôleur d entrée du bloc mephisto est fourni avec un micro-programme d ordonnancement des configurations (contexte au sens MAGALI) qui enchaîne les deux opérations de lecture. Notre modèle de programmation gère uniquement les connexions point à point entre les blocs de calcul. Pour contourner cette problématique nous intercalons le bloc SME 1 entre les deux blocs sources OFDM 1 et MEPHISTO 2 d un coté et le bloc destination MEPHISTO 1 de l autre coté. Le bloc SME 1 aura ainsi la tache de séquencer les flux de données en entrée vers le bloc MEPHISTO 1 (voir figure FIG. 6.9). Une unité de type SME est une unité micro-programmable qui permet de réordonner les données en provenance de ses tampons de mémoires internes. Pour des raisons de performances nous avons réalisé un micro-programme spécifique qui réalise cette opération de lecture particulière. Pour garder la portabilité du code exécuté par la MVR, on peut utiliser un bloc de traitement de type PP (programmable pipe) programmé de façon à transférer d abord les données en provenance de son port 0 vers le bloc MEPHISTO 1 puis passer au transfert des données en provenance de son port 1. I/O NoC 1 OFDM 1 SME 1 Mephisto 1 0 2 3 SME 3 OFDM 2 SME 2 Mephisto 2 FIG. 6.9: Flot de traitement de données correspondant à la phase (a) (avec MVR) Les deux blocs OFDM 1 et OFDM 2 sont utilisés pour la démodulation. Chacun de ces blocs doit réaliser 14 opérations de types FFT. Les opérations réalisées par les unités de type MEPHISTO sont élémentaires : ces blocs sont exécutés une seule fois et ne nécessitent pas d être relancés. Le contrôle réalisé par la MVR comme le montre la figure FIG. 6.10 consiste à : d abord lancer l exécution de toutes les unités de traitement à exécution élémentaire. Les unités de type OFDM sont ensuite configurées pour envoyer une interruption à la fin de l exécution de chaque opération FFT. La MVR attend ainsi l occurrence de deux interruptions (en provenance de OFDM 1 et de OFDM 2) pour relancer leurs traitements. Enfin, une interruption de l unité SME 3 permet de détecter la fin de la phase (a) et de se synchroniser pour configurer la suite de l exécution. MVR OFDM 1 OFDM 2 SME 1 SME 2 MEPHISTO 1 MEPHISTO 2 SME 3... Interruption (End of Task) Activation (Enable Task) FIG. 6.10: Diagramme de séquence de la phase d exécution (a) (avec MVR) 116

6.3 Implémentation par la machine virtuelle radio Phase (b rvm ) : calcul des paramètres de configuration pour les blocs de correction CFO et de décodage MIMO La première phase d exécution (a) produit comme résultat 14 coefficients de correction de l erreur CFO qui sont stockés en mémoire du bloc SME 3. Dans la phase (b rvm ) nous utilisons le concept de «programmable pipe» pour réaliser un calcul simple, qui à partir de ces 14 coefficients, permet de calculer les coefficients de correction des symboles pilotes en provenance de chacun des couples d antennes de transmission (1,3) et (2,4) et aussi les coefficients nécessaires pour la correction des symboles de données utiles. Le bloc SME 3 dans la figure FIG. 6.9 fait partie du dispositif PP. Le processus du PP est implémenté dans notre cas par un thread qui est exécuté par le processeur ARM. Celui-ci accède en lecture à la mémoire tampon du SME 3 et réalise le calcul des coefficients de corrections. Ces paramètres sont transmis aussitôt à la MVR qui les utilise, comme le montre la figure FIG. 6.11, pour configurer les quatre blocs MEPHISTO nécessaires lors des phases (b) et (c). Mephisto 1 (Correction CFO Ant 1,3) MVR paramétres de config PP Mephisto 2 (Correction CFO Ant 2,4) Mephisto 3 (Décodage MIMO) Configuration Flot de données Mephisto 4 (Décodage MIMO) FIG. 6.11: Scénario de calcul des paramètres de configuration par le PP ère 1 étape ème 2 étape SME 1 Mephisto 1 SME 1 Mephisto 1 SME 1 Mephisto 1 SME 2 Mephisto 2 SME 2 Mephisto 2 SME 2 Mephisto 2 Phase (b) sans RVM Phase (b) avec RVM FIG. 6.12: Flot de traitement de données correspondant à la phase (c) (avec MVR) Phase (b) : correction CFO et estimation de canal La phase d exécution (b) réalise exactement le même flot de traitement de données que celui de l implémentation native. Dans la figure FIG. 6.7(b), le bloc MEPHISTO 1 reçoit sur son port d entrée des données depuis l unité SME 1 et aussi depuis l unité SME 2. Cependant, chacune de ces connexions correspond à une micro-phase d exécution indépendante de l autre : les configurations du cœur de traitement pour chaque configuration de connexion sont décorrélées. Comme le montre la figure FIG. 6.12, nous avons réalisé ainsi ces deux configurations d une façon séquentielle. L ordonnancement des micro-phases d exécution est réalisé par la MVR. L opération d estimation de canal nécessite 16 micro-phases d exécution. Le séquencement de celles-ci est réalisé par la MVR en se synchronisant avec les interruptions en provenance des deux unités 117

6.3 Implémentation par la machine virtuelle radio de traitement MEPHISTO 1 et MEPHISTO 2. Celles sont configurées pour envoyer des interruptions à la fin de l exécution de chaque configuration élémentaire (micro-phase). Phase (c) : interpolation des coefficients de canal et décodage MIMO En étudiant le flot de traitement de données décrit dans la figure FIG. 6.7(c) pour une implémentation native, on retrouve la même problématique d interconnexions multi-points, rencontrée dans la réalisation de la phase (a). En effet, pour le bloc MEPHISTO 3, une configuration de type cœur de traitement nécessite un bloc de données élémentaire constitué de données en provenance de SME 1, SME 2 et MEPHISTO 1. La solution que nous avons réalisé consiste à intercaler une ressource de type SME (SME 4 dans FIG. 6.13) entre ces trois blocs sources et le bloc MEPHISTO 3 (utilisé pour le décodage MIMO). Le même problème existe aussi entre les connexions des blocs SME 1 et MEPHISTO 1. En effet deux flux de données en provenance des deux ports de sortie (2 et 3) du SME 1 alimentent le bloc MEPHISTO 1. celui-ci alterne la lecture depuis les deux sources en exécutant un micro-programme complexe d ordonnancement de configuration (contexte au sens MAGALI). Notre solution pour ce cas consiste à changer le micro-programme du SME pour que celui-ci gèrent l alternance des données depuis ses deux mémoires tampons et les écrivent sur un seul port de sortie qui sera connecté à l unité MEPHISTO 1. Enfin, le flot de traitement de données pour la phase (c) est celui représenté dans la figure FIG. 6.13 Mephisto 1 0 1 2 SME 1 0 1 2 Mephisto 3 3 3 SME 4 SME 3 SME 2 Mephisto 4 Mephisto 2 FIG. 6.13: Flot de traitement de données correspondant à la phase (c) (avec MVR) La phase d exécution (c) nécessite aussi 10 opérations de synchronisation par le mécanisme d interruptions décrit précédemment pour répéter autant de fois que nécessaire l exécution de la configuration décrite. Phase (d) : démodulation m-aire, dé-entrelacement, turbo-décodage et dé-embrouillage Cette phase d exécution est simple : les interconnexions sont de type point à point et les phases d exécutions sont élémentaires. La MVR configure les unités de traitement nécessaires au flot de traitement et attend la fin de l application à la réception d une interruption du dernier bloc de la chaîne qui est dans notre cas le turbo-décodeur. 118

6.3 Implémentation par la machine virtuelle radio 6.3.2 Résultats et Analyse Dans cette partie, nous présentons les résultats de performance de notre implémentation de l application LTE présentée dans la partie précédente et réalisée avec le concept de MVR. L expérimentation a été réalisée sur l environnement de co-simulation (SystemC-VHDL) du circuit MAGALI précis au cycle près. Le démonstrateur de la MVR utilisé est celui que nous avons implémenté et qui est décrit dans le chapitre 4. Nous analysons ensuite les facteurs de surcoût et expliquons qu en faisant usage des techniques d optimisation expliquées dans le chapitre 5 il serait possible d atteindre les performances de l application native et répondre ainsi aux contraintes temps réel du standard. Résultats de l expérimentation Le temps d exécution est un critère de performance important pour les applications de télécommunication. Celles ci ont généralement des contraintes temps réel dures à respecter. Dans le diagramme suivant nous montrons le temps passé dans chacune des phases d exécution expliquées précédemment. OFDM 1 - OFDM 2 1 TTI = 998.9 µs Phase (a) Phase (b rvm ) Phase (b) Phase (c) Phase (d) OFDM 1 - OFDM 2 Programmable Pipe (PP) OFDM Config. of Chan est & MIMO dec Mephisto 1 - Mephisto 2 CFO Chan. est Coef. Interpol. Mephisto 3 - Mephisto 4 MIMO Decod. RX BIT Demap, De-Interleav, HARQ CHAN DEC Turbo decoding... Load + runtime Initialisation (~15ms) 1,2 ms 3.8ms 2.7ms 3ms ~11.5ms 1.4ms Temps (ms) FIG. 6.14: Chronogramme des phases d exécution de l application LTE implémenté avec le concept de MVR Le tableau TAB. 6.3 détaille la composition et les tailles mémoire associées aux différentes parties constituant le code de application LTE. Code Mémoire occupée (Ko) OS (ecos) + drivers (F2 api) 67 VM + librairies radios 150 Bytecode LTE 13 Total : 230 TAB. 6.3: Composition du code exécutable de l application récepteur LTE et tailles mémoire associées En termes de productivité, l usage du concept de MVR nous a permis de réaliser l application récepteur LTE en quelques semaines ( 20 jours-homme). Ce temps de développement est relativement court. En effet, 119

6.3 Implémentation par la machine virtuelle radio le concept de MVR réalise une séparation entre la description fonctionnelle de haut niveau de l application radio et les détails techniques de son implémentation sur la plateforme matérielle d exécution. Analyse des résultats L étude des temps passés dans chaque phase d exécution de l application LTE montre que le coût en temps d exécution de la MVR se traduit globalement par un facteur moyen 7 par rapport à une implémentation optimisée sans VM faisant usage des dispositifs matériels de contrôle et de configuration distribués. En effet, l application optimisée nécessite globalement 1.5ms pour le traitement d un TTI alors que notre application implémentée avec le concept de MVR nécessite 11.5ms. Voici une analyse des différentes phases d exécution : La phase (a) consiste à la démodulation OFDM et l estimation CFO, elle nécessite 1.2ms avec la MVR comparé aux 100µs dans la version optimisée. Cette phase comme elle est décrite dans la section 6.3.1 réalise 28 synchronisations supplémentaires par rapport à l implémentation native pour séquencer les micro-phases d exécution de chaque bloc de démodulation OFDM (14 symbole OFDM x 2 antennes). Le surcoût de la MVR pour le cas de reconfiguration de l opérateur FFT d après le tableau TAB. 5.1 dans le chapitre précédent, est de 4.5e 5 ms.flit 1. On retrouve que le surcoût globale pour la phase (a) est 1.2ms = 4.5e 5 1024 flits 14 symboles 2 antennes. La phase (b rvm ) consiste à calculer à partir des coefficients moyens de CFO résultats de la phase (a), les paramètres de configuration pour les blocs de correction de l erreur CFO et pour le décodeur MIMO. Cette phase a été réalisée entièrement en logiciel, utilisant le concept de «programmable pipe». La phase (b rvm ) a duré 3.8ms, ceci est du principalement aux problématiques d accès au flot de données qui se traduisent par des synchronisations coûteuses avec des conversions récurrentes de formats de données (natif vers VM et inversement). Dans l implémentation native réalisée au LISAN, cette étape a été réalisée par simulation avec une estimation à environ 400µs pour le temps nécessaire à son exécution. La phase (b) est celle de l estimation de canal. Elle nécessite 2.7ms avec la MVR comparé aux 240µs en implémentation native. Ce surcoût est du principalement aux synchronisations supplémentaires nécessaires à l ordonnancement des 16 micro-phases d exécution qui correspondent aux configurations élémentaires des blocs d estimation de canal. La phase (c) est la phase qui consiste au décodage MIMO. Le temps passé dans cette phase avec l implémentation avec la MVR est de 3ms alors que dans l implémentation native cette phase dure 300µs. Comme dans la plus part des cas précédents, le mécanisme de synchronisation par la réception d interruptions est à l origine de ce surcoût (la phase (c) nécessite 10 synchronisations). La phase (d) a la particularité d avoir des temps d exécution proches pour les deux implémentations native et celle avec la MVR qui sont respectivement 0.66ms et 1.4ms. En effet, dans cette phase les configurations sont élémentaires et par suite il n y a pas de synchronisation supplémentaire à réaliser par la MVR. Dans ce cas, le surcoût provient principalement de l interprétation des primitives de la MVR lors des contrôles et des configurations initiaux. En utilisant les techniques proposées dans le chapitre précédent et plus particulièrement la traduction binaire réalisée à l avance de l exécution qui permet de générer les micro-programmes de séquencement des configurations à déployer sur les unités de traitement du circuit MAGALI, on pourrait éviter les multiples synchronisations coûteuses et aussi les allers / retours en terme de conversion de format de données entre la VM et les librairies native qui pilotent le circuit. Nous estimons qu il est possible avec ces optimisations de réaliser la chaîne de réception LTE tout en respectant ses contraintes de temps réel. 120

6.3 Implémentation par la machine virtuelle radio Conclusion Dans ce chapitre nous avons d abord présenté un aperçu du standard de quatrième génération de communication cellulaire 3GPP/LTE : ce standard a des caractéristiques lui permettant d atteindre des débits de transmissions élevés et des latences réduites. La réalisation d un protocole de couche physique de ce standard nécessite ainsi des ressources matérielles de traitement à haut débit et qui soient fortement optimisées pour répondre surtout aux contraintes temporelles de celui-ci. Le standard 3GPP/LTE inclut différents modes opératoires et nécessite beaucoup de flexibilité pour sa réalisation. La radio logicielle est donc quasiment indispensable pour son implémentation. Au laboratoire LISAN un démonstrateur de récepteur 3GPP/LTE a été réalisé conformément à la spécification (3GPP révision 8) sur le système sur puce MAGALI. Un aperçu des étapes de réalisation du démonstrateur a été présenté dans ce chapitre ainsi que les résultats en terme de performance de l implémentation qui ont été évalué pour chacune des phases d exécution du récepteur. Notre objectif étant d évaluer d abord la capacité du concept de MVR à exprimer des protocoles de couches physiques existants. Ensuite évaluer sa capacité à prendre en compte les contraintes temporelles du protocole. Les résultats de cette étude de cas, valide le modèle de programmation que l on a proposé en terme de capacité à exprimer fonctionnellement d autres protocoles de couches physiques (autres que le 802.11a développé précédemment). On a vérifié aussi qu avec ce concept on réduit considérablement le temps de développement. Cependant, l abstraction fournie par la couche MVR a un coût supplémentaire qui tel qu elle est implémentée aujourd hui ne permet pas de répondre aux contraintes temporelles de l application. Nous avons étudié les facteurs de surcoût pour ce cas d implémentation et nous avons en déduit qu on faisant usage des techniques d optimisations proposées dans le chapitre précédent, il serait fortement possible d atteindre des performances proches à celles de l implémentation optimisée permettant ainsi de respecter les contraintes temps réel du standard. 121

7 CHAPITRE Conclusion Sommaire 7.1 Synthèse.......................................... 123 7.2 Perspectives........................................ 124 7.2.1 Utilisation des processeurs mutlicœurs pour la radio logicielle.......... 124 7.2.2 Ingénierie de bytecode pour optimiser l adéquation algorithme-architecture... 125 7.2.3 Support de l exécution simultanée de multiple applications radios........ 125 122

7.1 Synthèse 7.1 Synthèse L objectif de cette thèse est d explorer l approche machine virtuelle pour la programmation des radios logicielles. Cette idée est intéressante pour les avantages qui peuvent en découler comme par exemple, la portabilité, la facilité de développement de nouvelles radios, la création de nouveaux services par les opérateurs de télécommunication, l animation du marché des équipements et logiciels radios, etc. La machine virtuelle radio comme toute couche d abstraction a certainement un coût supplémentaire surtout en terme de puissance de calcul. À travers cette thèse, on a étudié cette alternative d implémentation. Nous avons analysé les facteurs de surcoûts qui lui sont associés et avons proposé des solutions qui permettraient de les surpasser. Dans la littérature on affirme que les traitements radios peuvent être factorisés en un ensemble d opérateurs fonctionnels paramétrables qui sont communs aux protocoles de couches physiques des standards radios existants. Plusieurs laboratoires de recherche commencent alors à réaliser les premiers démonstrateurs de radio logicielle. Ceux-ci sont généralement des plateformes matérielles qui incluent un ensemble d IP reconfigurables dédiées à des fonctionnalités spécifiques aux chaînes de traitements radios. La reconfiguration est réalisée en général par paramétrisation d ASIC, configuration de FPGA et aussi par le chargement de code ou micro-code exécutable en mémoire des unités logicielles (DSP, GPP et micro-contrôleurs). Par conséquence la programmation d une chaîne radio consiste à la configuration d unités logicielles et/ou matérielles réalisant un ensemble de fonctionnalités et ayant des interfaces standardisés. Dans une moindre mesure, des traitements spécifiques à un standard de couche physique doivent être implémentés en logiciel. Ceci nous a motivé à investiguer l idée de MVR [7] initiée par Gudaitis et Mitola en 2000, présentée dans l atelier international de radio logicielle SDRForum. Nous avons alors étudié les techniques utilisées pour la spécification de la radio logicielle et nous nous sommes intéressés surtout à comprendre comment est réalisé le passage de la spécification à l implémentation. Les approches proposées [31, 24, 36] sont dans la plus part orientées compilation. Nous nous sommes ensuite inspirés des principes fondamentaux pour l abstraction des formes d ondes afin de définir un modèle de programmation que l on a appelé rkpn. Selon rkpn une application radio est modélisée comme un enchaînement d opérations alternées de configurations et de calculs. L ordonnancement de ces configurations est souvent assez complexe surtout dans certains cas où les paramètres et/ou les décisions de configuration nécessitent des informations en provenance du flot de données. rkpn suppose l existence d un nœud central responsable du contrôle et de l ordonnancement des configurations : c est la machine virtuelle radio (MVR). Le modèle d exécution associé à rkpn est l abstraction du matériel d exécution idéale pour celui-ci. Il consiste en un ensemble d unités logicielles / matérielles reconfigurables qui peuvent communiquer des flux de données entre elles dans n importe quelle séquence. La machine virtuelle est un contrôleur central implémenté sur la même architecture par un processeur ou une IP dédiée et a des moyens pour accéder au flot de données (par exemple à travers une mémoire partagée). Le modèle proposé est une abstraction proche de la définition même d un système de radio logicielle. Il ne restreint en aucun cas l architecture d exécution cible à une classe particulière de plateformes. Nous avons ensuite proposé dans cette thèse le concept de «programmable pipe» qui est un dispositif permettant de réaliser les traitements radios spécifiques en logiciel. La définition des algorithmes de ces traitements utilise le langage de la machine virtuelle. Celui-ci inclut des méthodes permettant au programmeur d éviter les contraintes d apprentissage des mécanismes de synchronisation propres à l architecture d exécution. Cette proposition a fait l objet d un brevet industriel. L étape suivante est la mise en œuvre de tous ces concepts en pratique par une implémentation d une MVR sur le circuit MAGALI. Les primitives de haut niveau d abstraction du modèle de programmation rkpn ont 123

7.2 Perspectives été d abord implémentées sur l infrastructure logicielle existante (drivers et système d exploitation). Cette étape a nécessité la maîtrise des principes fondamentaux du démonstrateur MAGALI et aussi une expertise technique pour manipuler son environnement de simulation. Le choix de la machine virtuelle à étendre en MVR est le résultat d une large étude comparative de machines virtuelles existantes. La VM Lua correspond le mieux à nos critères de choix et par suite a été choisie pour implémenter la MVR. Nous avons réalisé aussi des expérimentations simples sur le démonstrateur de MVR pour pouvoir analyser les facteurs de surcoûts liés essentiellement à l interprétation par la VM et aussi à l adaptation de notre modèle rkpn à l architecture d exécution. Ces expérimentations ont montré que les surcoûts sont d un ordre raisonnable : les traitements avec la MVR sont de 2 à 7 fois plus lents qu avec une réalisation native optimisée. Nous proposons à travers cette thèse des techniques d optimisation qui permettraient de réduire considérablement ce surcoût. Enfin, pour mettre à l épreuve le concept de MVR dans un cas d étude réaliste, nous avons réalisé une application qui correspond à un récepteur 3GPP/LTE selon un mode opératoire particulier. Le flot de conception de notre implémentation avec la MVR diffère de celui d une implémentation native. Ceci est du à quelques particularités comme par exemple : les interconnexions entre modules fonctionnels selon notre modèle de programmation sont obligatoirement de type point à point qui n est pas le cas pour une implémentation native sur le circuit MAGALI. On a montré que le concept de MVR réduit considérablement le cycle de développement. Cependant, les performances de notre implémentation actuelle ne sont pas en mesure de répondre aux contraintes temporelles de l application considérée. Malgré ceci, nous sommes convaincus que des travaux en perspective de cette thèse pour réaliser les optimisations proposés rendraient la MVR exploitable pour la réalisation des applications radios existantes. 7.2 Perspectives Les travaux réalisés durant cette thèse ont abouti à des contributions concernant la conception et la mise en œuvre du concept de MVR. Ces contributions ouvrent à leur tour d autres perspectives de recherche. Dans les parties suivantes on présente quelques-unes qui sont liées aux travaux présentés dans ce manuscrit. 7.2.1 Utilisation des processeurs mutlicœurs pour la radio logicielle Les processeurs mutlicœurs sont la réponse à la fin prochaine de la loi de Moore concernant le doublement périodique de la puissance de calcul et qui est due aux limites physiques de la miniaturisation. En effet Intel le leader mondial des microprocesseurs prétend dans [105] que la prochaine génération de processeurs (au alentours de 2015) contiendra des douzaines voire une centaine de cœurs de traitement. Ces processeurs favorisent les applications fortement parallèles. On pourrait utiliser ces processeurs dans un contexte radio, chaque cœur de traitement réalisera ainsi un opérateur fonctionnel de traitement de signal. Ces processeurs incorporent aussi des extensions SIMD permettant ainsi de réaliser efficacement des traitements exécutés aujourd hui sur des DSP. L architecture des processeurs multiœurs est une architecture intéressante pour la réalisation de notre concept de MVR : les processus de traitements virtuels de plusieurs dispositifs «programmable pipe» s exécuteront alors en parallèle sur différents cœurs de traitement. L approche qui consiste à utiliser les processeurs mutlicœurs pour la réalisation de la radio logicielle commence à intéresser les laboratoires de recherche de Microsoft qui ont réussi en 2009 à réaliser les traitements du 802.11a/b/g totalement en logiciel [12]. 124

7.2 Perspectives 7.2.2 Ingénierie de bytecode pour optimiser l adéquation algorithme-architecture Les expérimentations réalisées au cours de cette thèse montrent qu un surcoût d exécution est du principalement à l adaptation de notre modèle de programmation à l architecture d exécution de la plateforme MAGALI. En effet, notre modèle repose sur un contrôle centralisé réalisé par la MVR alors que les unités de traitement présentes sur le circuit MAGALI incorporent des moyens matériels (contrôleurs CCC) pour séquencer leurs configurations d une façon autonome. Une phase d ingénierie de bytecode permettrait de profiter des mécanismes propres à certaines architectures sans compromettre la généricité et la portabilité du langage de description de couches physiques proposé. Un cas d utilisation de la MVR est illustré dans la figure FIG. 7.1 ou l opérateur de télécommunication envoie à l équipement mobile un bytecode avec des paramètres spécifiques afin de l adapter à l architecture cible. FIG. 7.1: Cas d utilisation de la MVR avec une ingénierie de bytecode préalable adaptée à l architecture cible au niveau de l opérateur 7.2.3 Support de l exécution simultanée de multiple applications radios Supporter différents protocoles de communications par un équipement radio permet à celui ci de s adapter aux différents besoins en connectivité de l utilisateur. Notre solution actuelle de MVR consiste à changer de bytecode pour modifier le protocole supporté par l équipement. Un scénario classique de cas d utilisation pour changer d un protocole de couche physique à un autre consiste à télécharger le bytecode de la radio voulue et l exécuter par la MVR. Ce cas est appelé souvent reconfiguration OTA (Over The Air). Toutefois, dans certains cas d usage de l équipement radio il est indispensable d avoir la coexistence même pendant un intervalle de temps court de plusieurs protocoles sur le même équipement. On cite par exemple le cas de transfert intercellulaire appelé aussi «handover», ou aussi le cas où un utilisateur d un équipement radio mobile qui voudrait continuer à recevoir des appels pendant qu il est entrain de télécharger des photos par le protocole «Bluetooth» ou entrain de naviguer sur internet par le protocole WIFI. L exécution simultanée de plusieurs standards radio fait ainsi partie des études en perspective pour développer le langage de la MVR. On pourrait prévoir un langage de description de couche physique qui soit parallèle multi-protocolaires. Une autre idée consiste à ordonnancer d une façon astucieuse l exécution de 125

7.2 Perspectives multiple applications radios définies par plusieurs bytecodes séparés. Dans ce cas il faudra que la plateforme d exécution dispose d assez de ressources matérielles afin de gérer la concurrence d exécution des protocoles et respecter leurs contraintes de temps réel. Des réflexions concernant l exécution simultanée de deux protocoles ont été réalisées au laboratoire LISAN : celle-ci ont eu comme résultat qu un partitionnement fin, temporel et spatial très complexe est nécessaire pour atteindre cet objectif. On remarque aussi que dans la littérature peu de travaux de recherche s adressent à l exécution simultanée de multiple standards par un même matériel de radio logicielle. 126

Liste des publications Conférences et workshops internationaux : 1. "Virtual Machine for Software Defined Radio : Evaluating the Software VM Approach", Riadh Ben Abdallah, Tanguy Risset, Antoine Fraboulet, Jérôme Martin, In proceedings of 2010 IEEE International Conference on Embedded Software and Systems, ICESS 2010, Bradford, UK, 29 June - 01 July, 2010. 3. "Implementing the Radio Virtual Machine on the MAGALI chip", Riadh Ben Abdallah, Tanguy Risset, Antoine Fraboulet, Jérôme Martin, In proceedings of SDR Forum 2010 European Reconfigurable Radio Technologies Workshop and Product Exposition, ERRT 2010, Mainz, Germany, June 23-25, 2010. 3. "The Radio Virtual Machine : A solution for SDR portability and platform reconfigurability", Riadh Ben Abdallah, Tanguy Risset, Antoine Fraboulet, Yves Durand, In proceedings of 2009 IEEE International Symposium on Parallel&Distributed Processing, IPDPS 2009, Rome, Italy, May 23-29, 2009. Séminaires, présentations, exposés : 1. "Evaluation du concept de machine virtuelle sur le circuit MAGALI", Riadh Ben Abdallah, Tanguy Risset, Antoine Fraboulet et Jérôme Martin, Journées des Thèses CSEM-LETI, le 18 Novembre 2009 au Centre Suisse d Electronique et de Microtechnique, Archamps. 2. "Radio Virtual Machine : concept and challenges", Riadh Ben Abdallah, Tanguy Risset, Antoine Fraboulet et Jérôme Martin, Premières journées du projet SEmba Les 22 et 23 Octobre 2009 aux Balcons du Lac d Annecy 1487 rte de Cessenaz 74320 Sevrier. 3. "Machine Virtuelle Radio", Riadh Ben Abdallah, Tanguy Risset et Antoine Fraboulet, Séminaire TheCITI, Laboratoire CITI, INSA de Lyon, Villeurbanne, France, 20 Mars 2008. Brevet : 1. "Dispositif, chaîne et procédé de traitement de données, et programme d ordinateur correspondant", Jérôme Martin, Riadh Ben Abdallah, Tanguy Risset et Antoine Fraboulet. Chapitre de livre : 1. "Programming Models and Implementation Platforms for Software Defined Radio Configuration", Riadh Ben Abdallah, Tanguy Risset, Antoine Fraboulet et Jérôme Martin. 128

Bibliographie [1] Dr. Joseph Mitola III. Software radios : Survey, critical evaluation and future directions. Aerospace and Electronic Systems Magazine, IEEE, 8(4) :25 36, Apr 1993. [2] Dr. Joseph Mitola III. Technical challenges in the globalization of software radio. IEEE Communications Magazine, 37(2) :84 89, 1999. [3] JTRS Standards Joint Program Executive Office (JPEO) Joint Tactical Radio System (JTRS), 2006. version 2.2.2. [4] J.M. Geib and P. MERLE. CORBA : des concepts à la pratique. Techniques de l ingénieur. Informatique, (H2758) :H2758, 2000. [5] T. Lindholm and F. Yellin. Java virtual machine specification. Addison-Wesley Longman Publishing Co., Inc. Boston, MA, USA, 1999. [6] A. Feickert. The Joint Tactical Radio System (JTRS) and the Army s Future Combat System (FCS) : Issues for Congress, 2005. [7] M. Gudaitis and Dr. Joseph Mitola III. The Radio Virtual Machine. SDR Forum 21st General Meeting. 14-16 Novembrer, Mesa, AZ, 2000. [8] Ronan Farrell, Magdalena Sanchez, and Gerry Corley. Software-defined radio demonstrators : An example and future trends. International Journal of Digital Multimedia Broadcasting, page 12 pages, 2009. [9] A. Duller, D. Towner, G. Panesar, A. Gray, and W. Robbins. picoarray technology : the tool s story. In Design, Automation and Test in Europe, 2005. Proceedings, pages 106 111 Vol. 3, March 2005. [10] Kees van Berkel, Frank Heinle, Patrick P. E. Meuwissen, Kees Moerman, and Matthias Weiss. Vector processing as an enabler for software-defined radio in handheld devices. EURASIP J. Appl. Signal Process., 2005 :2613 2625, 2005. [11] Y. Lin, H. Lee, M. Woh, Y. Harel, S. Mahlke, T. Mudge, C. Chakrabarti, and K. Flautner. SODA : A high-performance DSP architecture for software-defined radio. IEEE Micro, 27(1) :114 123, 2007. [12] K. Tan, J. Zhang, J. Fang, H. Liu, Y. Ye, S. Wang, Y. Zhang, H. Wu, W. Wang, and G.M. Voelker. Sora : High performance software radio using general purpose multi-core processors. NSDI 2009. [13] D.C. Tucker and G.A. Tagliarini. Prototyping with gnu radio and the usrp - where to begin. In Southeastcon, 2009. SOUTHEASTCON 09. IEEE, pages 50 54, March 2009. [14] G.J. Minden, J.B. Evans, L. Searl, D. DePardo, V.R. Petty, R. Rajbanshi, T. Newman, Q. Chen, F. Weidling, J. Guffey, D. Datla, B. Barker, M. Peck, B. Cordill, A.M. Wyglinski, and A. Agah. Kuar : A flexible software-defined radio development platform. In New Frontiers in Dynamic Spectrum Access Networks, 2007. DySPAN 2007. 2nd IEEE International Symposium on, pages 428 439, April 2007. [15] M. Ahmadian, ZJ Nazari, N. Nakhaee, Z. Kostic, and S.M.T. Ltd. Model based design and SDR. In DSPenabledRadio, 2005. The 2nd IEE/EURASIP Conference on (Ref. No. 2005/11086), page 8, 2005. 130

BIBLIOGRAPHIE [16] The MathWorks, Inc.,Simulink Documentation, URL : http ://www.mathworks.com/access/helpdesk/ help/toolbox/simulink. [17] En ligne. url : http ://www.sundance.com/. [18] The MathWorks, Inc. Real-Time Workshop user s manual, 2002. [19] D. Haessig, J. Hwang, S. Gallagher, and M. Uhm. Case-study of a Xilinx system generator design flow for rapid development of SDR waveforms. In SDR technical conference, pages 14 18, 2005. [20] J. Glossner, T. Raja, E. Hokenek, and M. Moudgill. A multithreaded processor architecture for SDR. The Proceedings of the Korean Institute of Communication Sciences, 19(11) :70 84, 2002. [21] John Hogg and Francis Bordeleau. Optimizing portable sdr software. In Proceeding of the SDR 07 Technical Conference and Product Exposition. SDRForum 2007. [22] Cyprian Grassmann, Mirko Sauermann, Hans-Martin Bluethgen, and Ulrich Ramacher. System level hardware abstraction for software defined radios. In Proceeding of the SDR 04 Technical Conference and Product Exposition. SDRForum 2004. [23] T. Kempf, M. Adrat, EM Witte, O. Schliebusch, M. Antweiler, and G. Ascheid. A Concept for Waveform Description based SDR Implementation. In 4th Karlsruhe Workshop on Software Radios (WSR 06). [24] ED Willink. The waveform description language : moving from implementation to specification. In IEEE Military Communications Conference, 2001. MILCOM 2001. Communications for Network- Centric Operations : Creating the Information Force, volume 1, 2001. [25] S. Yoo and A. Jerraya. Introduction to hardware abstraction layers for SoC. Embedded Software for SoC, pages 179 186. [26] C. Moy, J. Palicot, V. Rodriguez, and D. Giri. Optimal determination of common operators for multistandards software-defined radio. In Proc. of 4th Karlsruhe Workshop on Software Radios,(Karlsruhe, Germany), 2006. [27] J. Palicot and C. Roland. FFT : a basic function for a reconfigurable receiver. In 2003. ICT 2003. 10th International Conference on Telecommunications, volume 1. [28] R. Rasheed, A. Menouni, and R. Pacalet. Reconfigurable Viterbi Decoder for Mobile Platform. URL : http ://www. ctr. kcl. ac. uk/mwcn2005/paper/ C, 200540. [29] B. Heyne and J. Gotze. Cordic based algorithms for software defined radio (SDR) baseband processing. In workshop on Advances in Radio Science, 2006. [30] P. Muralidhar and C.B.R. Rao. Implementation of Cordic Based Architecture for WCDMA/OFDM Receiver. European Journal of Scientific Research, 36(1) :65 78, 2009. [31] R. Hossain, M. Wesseling, and C. Leopold. Application description concept with system level hardware abstraction. In Signal Processing Systems Design and Implementation, 2005. IEEE Workshop on, pages 36 41, Nov. 2005. [32] J. Chapin, V. Lum, and S. Muir. Experiences Implementing GSM in RDL (The Vanu Radio Description Language TM ). In IEEE Military Communications Conference, 2001. MILCOM 2001. Communications for Network-Centric Operations : Creating the Information Force, volume 1, 2001. [33] J. Chapin and V. Bose. The vanu software radio system. In 2002 Software Defined Radio Technical Conference, San Diego, 2002. [34] R. Burgess and S. Mende. Configuration languages-theory and implementation. E2R Project Whitepaper : http ://e2r. motlabs. com/whitepapers. 131

BIBLIOGRAPHIE [35] S. Zhong, C. Dolwin, K. Strohmenger, and B. Steinke. Performance Evaluation of the Functional Description Language in a SDR Environment. In Proc. SDR Forum Technical Conference 2007. [36] Y. Lin, R. Mullenix, M. Woh, S. Mahlke, T. Mudge, A. Reid, and K. Flautner. SPEX : A programming language for software defined radio. In Software Defined Radio Technical Conference and Product Exposition, Orlando, 2006. [37] J. Bard and V.J. Kovarik. Software defined radio : the software communications architecture. Wiley, 2007. [38] JTRS NED Test & Evaluation. http :// sca. jpeojtrs. mil / portabilityguidelines. asp. [39] En ligne. URL : http ://www. wirelessinnovation. org. ou aussi http ://www. sdrforum. org. [40] En ligne. URL : http ://www. prismtech. com. [41] En ligne. URL : http ://www. zeligsoft. com. [42] En ligne. URL : http ://www. ois. com. [43] Jeff Smith, David Murotake, and Antonio Martin. Software communication architecture : Evolution and status update. Military Embedded Systems. October 2005. [44] Antoni Gelonch, Xavier Revès, Vuk Marojevik, and Ramon Frrús. P-HAL : a middleware for SDR applications. In SDR Forum Technical Conference, 2005. [45] Ismael Gomez, Vuk Marojevic, Jose Salazar, and Antoni Gelonch. A lightweight operating environment for next generation cognitive radios. Digital Systems Design, Euromicro Symposium on, 0 :47 52, 2008. [46] M. Robert, S. Sayed, C. Aguayo, R. Menon, K. Channak, C. Vander Valk, C. Neely, T. Tsou, J. Mandeville, and J.H. Reed. OSSIE : Open Source SCA for Researchers. In SDR Forum Techical Conference, 2004. [47] G.R. Ferris. Digital wireless basestation, July 24 2002. US Patent App. 10/182,043. [48] R. Burgess. Configuration method, September 28 2004. US Patent App. 10/950,562. [49] C. et al. Moy. Telecommunication device with software components, May 1 2007. US Patent App. 10/913,368. [50] G. Kahn. The semantics of a simple language for parallel programming. Information processing, 74 :471 475, 1974. [51] E.A. Lee and D.G. Messerschmitt. Static scheduling of synchronous data flow programs for digital signal processing. IEEE Transactions on computers, 36(1) :24 35, 1987. [52] EA Lee and DG Messerschmitt. Synchronous data flow. Proceedings of the IEEE, 75(9) :1235 1245, 1987. [53] J. Buck, S. Ha, E.A. Lee, and D.G. Messerschmitt. Ptolemy : A framework for simulating and prototyping heterogeneous systems. International Journal of Computer Simulation, 4(2) :155 182, 1994. [54] P. Dumont. Spécification Multidimensionnelle pour le traitement du signal systématique. These de doctorat (PhD Thesis), Laboratoire d informatique fondamentale de Lille, Université des sciences et technologies de Lille, 2005. [55] G. Bilsen, M. Engels, R. Lauwereins, and JA Peperstraete. Cyclo-static data flow. In Acoustics, Speech, and Signal Processing, 1995. ICASSP-95., 1995 International Conference on, volume 5, 1995. [56] J.T. Buck. Scheduling dynamic dataflow graphs with bounded memory using the token flow model. PhD thesis, 1993. 132

BIBLIOGRAPHIE [57] R. Alur, S. Kannan, and M. Yannakakis. Communicating hierarchical state machines. Automata, Languages and Programming, pages 703 703. [58] IEEE 802.11 WG, Part 11a, Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications, High-speed Physical Layer in the 5 GHz Band, ieee standard edition, 1999. [59] En ligne. url : http ://luarvm.gforge.inria.fr/index-project.php. [60] En ligne. url : http ://sourceforge.net/projects/miffiesphy/. [61] R. Ierusalimschy, L.H. De Figueiredo, and W. Celes. The implementation of Lua 5.0. Journal of Universal Computer Science, 11(7) :1159 1176, 2005. [62] R. Ierusalimschy, L.H. de Figueiredo, and W. Celes. The evolution of an extension language : A history of Lua. V Simpósio Brasileiro de Linguagens de Programaç ao, pages B 14 B 28, Curitiba, 2001. [63] E. Sourour, H. El-Ghoroury, and D. McNeill. Frequency offset estimation and correction in the ieee 802.11a wlan. In Vehicular Technology Conference, 2004. VTC2004-Fall. 2004 IEEE 60th, volume 7, pages 4923 4927 Vol. 7, Sept. 2004. [64] M. Serra, P. Martí, and J. Carrabina. Implementation of a channel equalizer for OFDM wireless LANs. In 15th IEEE International Workshop on Rapid System Prototyping, 2004. Proceedings, pages 232 238, 2004. [65] P. Gumming. The TI OMAP platform approach to SoC. Winning the SoC revolution : experiences in real design, page 97, 2003. [66] F. Clermidy, R. Lemaire, Y. Thonnart, X. Popon, and D. Knetas. An open and reconfigurable platform for 4g telecommunication : concepts and application. In 12 th Euromicro Conference on Digital System Design, Architectures, Methods and Tools (DSD 2009), pages 449 456, 2009. [67] J. Martin, C. Bernard, F. Clermidy, and Y. Durand. A microprogrammable memory controller for high-performance dataflow application. In 35 th European Solid-State Circuit Conference (ES- SIRC 2009), pages 348 351, 2009. [68] ARM Ltd. ARM1176JZF-S Technical Reference Manual, 2006. [69] F. Clermidy, Y. Thonnart, R. Lemaire, and P. Vivet. A communication and configuration controller for noc based reconfigurable data flow architecture. In 3 rd IEEE International Symposium on Networkson-Chip (NoCs 2009), pages 153 162, May 2009. [70] Y. Durand, C. Bernard, and D. Lattard. FAUST : On-chip distributed architecture for a 4g baseband modem SoC. In Design & Reuse IP-SoC, Grenoble, France, Grenoble, France, December 2005. IEEE Computer Society. [71] F. Bellard. QEMU, a fast and portable dynamic translator. USENIX, 2005. [72] O.S.C. Initiative. SystemC Version 2.0 User s Guide. Update for SystemC 2.0, 1, 2002. [73] O.S.C. Initiative. Functional Specification for SystemC 2.0. Update for SystemC, 2(1). [74] M. Graphics. ModelSim. Available a t http ://www. model. com. [75] N. Calazans, E. Moreno, F. Hessel, V. Rosa, F. Moraes, and E. Carara. From VHDL register transfer level to SystemC transaction level modeling : a comparative case study. 2003. [76] Anthony Massa. Embedded Software Development with ecos. Prentice Hall Professional Technical Reference, 2002. [77] Lionel M. Ni and Philip K. McKinley. A survey of wormhole routing techniques in direct networks. Computer, 26(2) :62 76, 1993. 133

BIBLIOGRAPHIE [78] D. Simon, C. Cifuentes, D. Cleal, J. Daniels, and D. White. Java TM on the bare metal of wireless sensor devices : the squawk Java virtual machine. In Proceedings of the 2nd international Conference on Virtual Execution Environments, page 88. ACM, 2006. [79] C. Porthouse. Jazelle for execution environments. ARM Whitepaper, available online, 2005. [80] R. Ierusalimschy, L.H. De Figueiredo, and W.C. Filho. Lua-an extensible extension language. Software Practice and Experience, 26(6) :635 652, 1996. [81] M.S. Glasberg and J. Bresler. The Lua Architecture. [82] M. Cornea-Hasegan and B. Norin. IA-64 floating point operations and the IEEE standard for binary floating-point arithmetic. Intel Technology Journal, 4 :1 16, 1999. [83] B. Lewis, D.J. Berg, et al. Multithreaded programming with Pthreads. Sun Microsystems Press, 1998. [84] A.N. Sloss, D. Symes, and C. Wright. ARM system developer s guide : designing and optimizing system software. Morgan Kaufmann Pub, 2004. [85] J. Aycock. A brief history of just-in-time. ACM Computing Surveys (CSUR), 35(2) :113, 2003. [86] D.E. Knuth. An Empirical Study of FORTRAN Programsf. Software-Practice and Experience, 1 :105 133, 1971. [87] RJ Dakin and PC Poole. A mixed code approach. The Computer Journal, 16(3) :219, 1973. [88] JL Dawson. Combining interpretive code with machine code. The Computer Journal, 16(3) :216 219, 1973. [89] Paul Tyma. Why are we using java again? Commun. ACM, 41(6) :38 42, 1998. [90] Michael P. Plezbert and Ron K. Cytron. Does just in time = better late than never? In POPL 97 : Proceedings of the 24th ACM SIGPLAN-SIGACT symposium on Principles of programming languages, pages 120 131, New York, NY, USA, 1997. ACM. [91] S. Meloan. The Java HotSpot (tm) Perfomance Engine : An In-Depth Look. Article on Sun s Java Developer Connection site, 1999. [92] Waldemar Celes Luiz Henrique de Figueiredo and Roberto Ierusalimschy. Lua Programming Gems. Lua.org, December 2008. [93] C. Cifuentes and V. Malhotra. Binary translation : static, dynamic, retargetable? In Proceedings of the 1996 International Conference on Software Maintenance, pages 340 349. Citeseer, 1996. [94] M. Schoeberl. Jop : A java optimized processor for embedded real-time systems. Technischen Universität Wien, Fakultät für Informatik, 2005. [95] R. Radhakrishnan and L.K. John. Microarchitectural techniques to enable efficient Java execution. Academic Dissertation. University of Texas at Austin, 2000. [96] W. Puffitsch and M. Schoeberl. picojava-ii in an FPGA. In Proceedings of the 5th international workshop on Java technologies for real-time and embedded systems, page 221. ACM, 2007. [97] D.S. Hardin. ajile Systems : Low-Power Direct-Execution JavaTM Microprocessors for Real- Time and Networked Embedded Applications. White paper available in http ://www. ajile. com/downloads/ajile-white-paper. pdf. [98] SA Ito, L. Carro, and RP Jacobi. Making Java work for microcontroller applications. IEEE Design & Test of Computers, 18(5) :100 110, 2001. [99] D. Astély, E. Dahlman, A. Furuskär, Y. Jading, M. Lindström, and S. Parkvall. LTE : The evolution of mobile broadband. IEEE Communications Magazine, 47(4) :44 51, 2009. 134

BIBLIOGRAPHIE [100] S. Sesia, I. Toufik, and M. Baker. LTE, The UMTS Long Term Evolution : From Theory to Practice. John Wiley & Sons Inc, 2009. [101] AB Effnet. The concept of robust header compression, ROHC. White Paper, Febbraio, 2004. [102] C. Bormann, C. Burmeister, M. Degermark, et al. Robust header compression (ROHC). 2001. [103] K.C. Beh, A. Doufexi, and SMD Armour. Performance evaluation of hybrid ARQ schemes of 3GPP LTE OFDMA system. In IEEE 18th International Symposium on Personal, Indoor and Mobile Radio Communications, 2007 (PIMRC 2007). Institute of Electrical and Electronics Engineers (IEEE), 2007. [104] S.M. Alamouti. A simple transmit diversity technique for wireless communications. The best of the best : fifty years of communications and networking research, page 17, 2007. [105] S. Borkar, P. Dubey, K. Kahn, D. Kuck, H. Mulder, S. Pawlowski, and J. Rattner. Platform 2015 : Intel processor and platform evolution for the next decade. Intel Technology, page 1, 2005. 135

Annexes 136

Annexe A Programmes de l émetteur / récepeteur IEEE802.11a 137

A.1 Programme de l émetteur IEEE802.11a A.1 Programme de l émetteur IEEE802.11a ------------------------------------------------------------------ 2 -- 802.11a Transmitter -- Riadh BEN ABDALLAH (C)2008 -- ------------------------------------------------------------------ 4 require "initparam802_11a" 6 require "constants" --contains 802.11a modulation parameters 8 ------------------------------------------------------------------- -- The modules we need to implement 802.11a transmitter: -- 10 ------------------------------------------------------------------- -- rf : emulate an rf front end. Initially configured in TX mode 12 -- with an empty buffer. -- dma : manage an initial buffer containing the ppdu to send. 14 -- scrambler : scramble input bits. -- convolution : a convolution encoder module. 16 -- interleaver : an interleaving module. -- mapper : a mapper module (BPSQ, QPSK, QAM16, QAM64 are supported) 18 -- fft : a fft(fast fourier tranformation) module. -- gi_adder : adds a guard interval for the OFDM symbols. 20 -- shaper: performs the symbol shaping. -------------------------------------------------------------------- 22 ------------------------------------------------ 24 -- Transmit a 802.11a ppdu @ rate ------------------------------------------------ 26 function Transmit_802_11a(ppdu,rate,nsym,length) symbol_size = 64 28 ext_symbol_size = 80 -- 64 + 16 for GI 30 ----------------------------------------- -- I PREAMBLE 32 ----------------------------------------- print("\n--------------\npreamble FIELD PROCESSING \n------------\n") 34 ----------------------------------- 36 -- (1) Create required instances -- ----------------------------------- 38 dma1 = dma_engine.allocate() sha1 = shaper.allocate() 40 rf1 = rf.allocate() 42 ----------------------------- -- (2) Connect the modules -- 44 ----------------------------- rvm.connect( dma1, 1, sha1, 1, complex_type ) 46 rvm.connect( sha1, 1, rf1, 1, complex_type ) 48 ------------------------------- -- (3) Configure the modules -- 50 ------------------------------- -- preamb is a buffer containing the PREAMBLE 321 samples 52 preamb = rom.load("preamble") param0 = 321 54 dma_engine.configure( dma1, "microcode1", complex_type, preamb, NO_IT, param0 ) 56 -- microcode1 = BEGIN { SEND 321 LOSSY; } END. buffer.release(preamb) 138

A.1 Programme de l émetteur IEEE802.11a 58 last = 0 60 shaper.configure( sha1, 320, last, 321, SIGTER ) -- send 320 samples to the RF front end and save the 321st sample 62 -- to overlap it with first sample of the next symbol. 64 -- Total number of Symbols = nsym (Number of data symbols) -- + 1 SIGNAL symbol 66 -- + 4 training sequence symbols size = ( ( nsym + 5 ) * ext_symbol_size ) 68 -- creating buffer for temporal samples temp_samples = buffer.allocate( complex_type, size+1 ) 70 72 rf.configure( rf1, temp_samples, TX_mode, SIGTER ) ------------------------ 74 -- (4) Launch modules -- ------------------------ 76 rvm.start( dma1 ) rvm.start( sha1 ) 78 rvm.start( rf1 ) 80 ------------------------- -- (5) Wait for result -- 82 ------------------------- print("\nwaiting...") 84 rvm.wait( SIGTER ) print("\nprocess terminated. RVM wake up.") 86 --------------------------------- 88 -- (6) Free useless ressources -- --------------------------------- 90 dma_engine.reset( dma1 ) 92 ----------------------------------------- -- II SIGNAL FIELD MODULATION 94 ----------------------------------------- print("\n-----------\nsignal FIELD MODULATION \n-------------\n") 96 ------------------------ 98 -- (0) Initialization -- ------------------------ 100 --parameters initialization for DATA demodulation Ndbps, Ncbps, Nbpsc, coding_rate, modulation = initparam802_11a(6) 102 ----------------------------------- 104 -- (1) Create required instances -- ----------------------------------- 106 conv1 = convolution.allocate() inte1 = interleaver.allocate() 108 mapp1 = mapper.allocate() fft1 = fft.allocate() 110 gi1 = giadder.allocate() 112 ----------------------------- -- (2) Connect the modules -- 114 ----------------------------- rvm.connect( dma1, 1, conv1, 1, binary_type ) 116 rvm.connect( conv1, 1, inte1, 1, binary_type ) 139

A.1 Programme de l émetteur IEEE802.11a rvm.connect( inte1, 1, mapp1, 1, binary_type ) 118 rvm.connect( mapp1, 1, fft1, 1, complex_type ) rvm.connect( fft1, 1, gi1, 1, complex_type ) 120 rvm.connect( gi1, 1, sha1, 1, complex_type ) 122 ------------------------------- -- (3) Configure the modules -- 124 ------------------------------- param0 = Ndbps 126 --microcode1 = BEGIN { SEND Ndbps LOSSY } END. dma_engine.configure( dma1, "microcode1", binary_type, 128 ppdu, NO_IT, param0 ) buffer.release( ppdu ) 130 convolution.configure( conv1, coding_rate, Ndbps, NO_IT ) 132 interleaver.configure( inte1, Ncbps, Nbpsc, Ncbps, NO_IT ) 134 pilot_shifter = 0x7f mapper.configure( mapp1, Ncbps, Nbpsc, pilot_shifter, 136 Ncbps, NO_IT ) mode_ifft = 0 138 fft_size = 64 fft.configure( fft1, mode_ifft, fft_size, 64, NO_IT ) 140 giadder.configure( gi1, symbol_size, symbol_size, SIGTER ) 142 shaper.configure( sha1, ext_symbol_size, last, 81, SIGTER ) 144 ------------------------ -- (4) Launch modules -- 146 ------------------------ --launch all the modules 148 rvm.start( dma1 ) rvm.start( conv1 ) 150 rvm.start( inte1 ) rvm.start( mapp1 ) 152 rvm.start( fft1 ) rvm.start( gi1 ) 154 rvm.start( sha1 ) 156 ------------------------- -- (5) Wait for result -- 158 ------------------------- print("\nwaiting...") 160 rvm.wait( SIGTER ) rvm.wait( SIGTER ) 162 print("\nprocess terminated. RVM wake up.") 164 ----------------------------------------- 166 -- II DATA FIELD MODULATION ----------------------------------------- 168 print("\n----------\ndata FIELD MODULATION \n----------\n") 170 ------------------------ -- (0) Initialization -- 172 ------------------------ --parameters initialization for DATA demodulation 174 Ndbps, Ncbps, Nbpsc, coding_rate, modulation = initparam802_11a(rate) 140

A.1 Programme de l émetteur IEEE802.11a 176 ----------------------------------- -- (1) Create required instances -- 178 ----------------------------------- scr1 = scrambler.allocate() 180 ----------------------------- 182 -- (2) Connect the modules -- ----------------------------- 184 rvm.connect( dma1, 1, scr1, 1, binary_type ) rvm.connect( scr1, 1, conv1, 1, binary_type ) 186 ------------------------------- 188 -- (3) Configure the modules -- ------------------------------- 190 param0 = nsym*ndbps dma_engine.configure( dma1, "microcode1", binary_type, 192 nil, NO_IT, param0 ) -- configure the dma_engine, dma uses the already allocated buffer. 194 -- microcode1 = BEGIN { SEND (nsym*ndbps) LOSSY } END. 196 seed = 0x5d 198 tail_offset = 16 + length*8 tail_size = 6 200 --TAIL field bits must be zeroed scrambler.configure( scr1, seed, tail_offset, tail_size, 202 nsym * Ndbps, NO_IT ) convolution.configure( conv1, coding_rate, nsym * Ndbps, NO_IT ) 204 interleaver.configure( inte1, Ncbps, Nbpsc, nsym * Ncbps, NO_IT ) pilot_shifter = 0xfe 206 mapper.configure( mapp1, Ncbps, Nbpsc, pilot_shifter, nsym * Ncbps, NO_IT ) 208 mode_ifft = 0 fft_size = 64 210 fft.configure( fft1, mode_ifft, fft_size, nsym * 64, NO_IT ) giadder.configure( gi1, symbol_size, nsym * symbol_size, NO_IT ) 212 last = 1 shaper.configure( sha1, ext_symbol_size, last, 214 nsym*(ext_symbol_size+1), NO_IT ) 216 ------------------------ -- (4) Launch modules -- 218 ------------------------ rvm.start( dma1 ) 220 rvm.start( scr1 ) rvm.start( conv1 ) 222 rvm.start( inte1 ) rvm.start( mapp1 ) 224 rvm.start( fft1 ) rvm.start( gi1 ) 226 rvm.start( sha1 ) 228 ------------------------- -- (5) Wait for result -- 230 ------------------------- print("\nwaiting...") 232 rvm.wait( SIGTER ) print("\nprocess terminated. RVM wake up.\n") 234 141

A.2 Programme du récepteur IEEE802.11a --------------------------------- 236 -- (6) Free useless ressources -- --------------------------------- 238 dma_engine.free( dma1 ) scrambler.free( scr1 ) 240 convolution.free( conv1 ) interleaver.free( inte1 ) 242 mapper.free( mapp1 ) fft.free( fft1 ) 244 giadder.free( gi1 ) shaper.free( sha1 ) 246 rf.free( rf1 ) 248 print("\n----------\npacket SENT \n-------------\n") return temp_samples 250 end A.2 Programme du récepteur IEEE802.11a 252 -------------------------------------------------------------------- ---- 802.11a Receiver -- Riadh BEN ABDALLAH (C)2008 -- 254 -------------------------------------------------------------------- 256 require "initparam802_11a" require "constants" 258 -------------------------------- 260 -- Modules implemented in lua -- -------------------------------- 262 require "lua_phaseestimator" require "lua_rotor" 264 ------------------------------------------------------------- 266 -- Receive temporal samples of a 802.11a ppdu from RF stage ------------------------------------------------------------- 268 270 function Receiver_802_11a(temporal_samples) symbol_size = 64 272 ext_symbol_size = 80 -- 64 + 16 for GI 274 --------------------------------------------- -- I Phase error estimation (coarse & fine) 276 --------------------------------------------- print("\n--------\nphase ERROR ESTIMATION\n------------\n") 278 --------------------------------------- 280 --- I.1 Coarse phase drift estimation --------------------------------------- 282 ----------------------------------- -- (1) Create required instances -- 284 ----------------------------------- rf1 = rf.allocate() 286 dma1 = dma_engine.allocate() 288 ----------------------------- -- (2) Connect the modules -- 142

A.2 Programme du récepteur IEEE802.11a 290 ----------------------------- rvm.connect( rf1, 1, dma1, 1, complex_type ) 292 ------------------------------- 294 -- (3) Configure the modules -- ------------------------------- 296 rf.configure( rf1, temporal_samples, RX_mode, NO_IT ) param0 = 160 298 param1 = 128 dma_engine.configure(dma1, "microcode2", complex_type, nil, 300 SIGTER, param0, param1 ) -- microcode2 = BEGIN { RECEIVE 160; DESTROY 128; } END. 302 304 ------------------------ -- (4) Launch modules -- 306 ------------------------ rvm.start( rf1 ) 308 rvm.start( dma1 ) 310 ------------------------- -- (5) Wait for result -- 312 ------------------------- print("\nwaiting...") 314 rvm.wait( SIGTER ) print("\nprocess terminated. RVM wake up.") 316 ------------------------------------------------------------ 318 -- (6) Compute the drift amount (coarse drift estimation) -- ------------------------------------------------------------ 320 -- creating buffer for the 2 last STS symbols -- (each symbol has a length of 16 temporal samples) 322 STS = buffer.allocate( complex_type, 32 ) 324 -- copy the dma_engine buffer to the previously allocated buffer dma_engine.buffer_cpy(dma1, STS) 326 -- The following functions are performed by the rvm : 328 RVM_STS = rvm.read(sts, 0, 32) buffer.release( STS ) 330 coarse_drift = lua_phaseestimator( RVM_STS, 16, 16 ) 332 print("\ncoarse phase drift computed = ", coarse_drift) 334 ----------------------------------- -- (7) Reset useless dma-engine -- 336 ----------------------------------- dma_engine.reset( dma1 ) 338 340 ------------------------------------- --- I.2 Fine phase drift estimation 342 ------------------------------------- ----------------------------------- 344 -- (1) Create required instances -- ----------------------------------- 346 -- no required module 348 ----------------------------- 143

A.2 Programme du récepteur IEEE802.11a -- (2) Connect the modules -- 350 ----------------------------- -- no connections to perform 352 ------------------------------- 354 -- (3) Configure the modules -- ------------------------------- 356 param0 = 160 dma_engine.configure( dma1, "microcode3", complex_type, nil, 358 SIGTER, param0 ) -- microcode3 = BEGIN { RECEIVE 160; } END. 360 ------------------------ 362 -- (4) Launch modules -- ------------------------ 364 rvm.start(dma1 ) 366 ------------------------- -- (5) Wait for result -- 368 ------------------------- print("\nwaiting...") 370 rvm.wait( SIGTER ) print("\nprocess terminated. RVM wake up.") 372 ------------------------------------------------------------ 374 -- (6) Compute the drift amount (coarse drift estimation) -- ------------------------------------------------------------ 376 -- creating buffer for the 2 LTS symbols + their GI -- (each symbol has a length of 64 temporal samples) 378 LTS = buffer.allocate( complex_type, 160 ) 380 -- copy the dma_engine buffer to the previously allocated buffer dma_engine.buffer_cpy(dma1, LTS) 382 -- The following functions are performed by the rvm : 384 RVM_LTS = rvm.read(lts, 0, 160) buffer.release(lts) 386 -- drift the 2 LTS symbols according to the coarse drift estimation 388 phase_drift = 0 RVM_LTS_rot = lua_rotor( RVM_LTS, phase_drift, coarse_drift, 160 ) 390 i=1 RVM_LTS = {} 392 while (i <= 128) do RVM_LTS[i] = RVM_LTS_rot[i+32] 394 i = i + 1 end 396 fine_drift = lua_phaseestimator( RVM_LTS, 64, 64 ) 398 print("\nfine phase drift computed = ", fine_drift) 400 --drift characteristics phase_drift = coarse_drift * 160 402 phase_amount = coarse_drift + fine_drift 404 print("phase_drift = ",phase_drift) print("phase_amount =",phase_amount) 406 ----------------------------------- 144

A.2 Programme du récepteur IEEE802.11a 408 -- (7) Reset useless dma-engine -- ----------------------------------- 410 dma_engine.reset( dma1 ) 412 ------------------------------------------- 414 -- II CIR estimation ------------------------------------------- 416 print("\n----------------------\ncir ESTIMATION\n----------------------\n") 418 ----------------------- -- II.2 CIR computing 420 ----------------------- ----------------------------------- 422 -- (1) Create required instances -- ----------------------------------- 424 dma2 = dma_engine.allocate() fft1 = fft.allocate() 426 fft2 = fft.allocate() roto1 = rotor.allocate() 428 mean1 = mean.allocate() mult1 = multiplier.allocate() 430 dma3 = dma_engine.allocate() dma4 = dma_engine.allocate() 432 ----------------------------- 434 -- (2) Connect the modules -- ----------------------------- 436 rvm.connect( dma1, 1, fft1, 1, complex_type ) rvm.connect( fft1, 1, roto1, 1, complex_type ) 438 rvm.connect( roto1, 1, mean1, 1, complex_type ) rvm.connect( dma2, 1, fft2, 1, complex_type ) 440 rvm.connect( fft2, 1, mean1, 2, complex_type ) rvm.connect( mean1, 1, mult1, 1, complex_type ) 442 rvm.connect( dma3, 1, mult1, 2, complex_type ) rvm.connect( mult1, 1, dma4, 1, complex_type ) 444 ------------------------------- 446 -- (3) Configure the modules -- ------------------------------- 448 --extract 2 lts symbols: i = 1 450 LTS1 = {} LTS2 = {} 452 while (i <= 64) do LTS1[i] = RVM_LTS_rot[i + 16] 454 LTS2[i] = RVM_LTS_rot[i + 96] i = i + 1 456 end 458 lts1 = buffer.allocate( complex_type, 64 ) lts2 = buffer.allocate( complex_type, 64 ) 460 rvm.write( "LTS1", 1, 64, lts1 ) 462 rvm.write( "LTS2", 1, 64, lts2 ) 464 dma_engine.configure( dma1, "microcode1", complex_type, lts1, NO_IT, 64 ) 466 -- microcode1 = BEGIN { SEND 64 LOSSY; } END. 145

A.2 Programme du récepteur IEEE802.11a dma_engine.configure( dma2, "microcode1", complex_type, lts2, 468 NO_IT, 64 ) 470 buffer.release(lts1) buffer.release(lts2) 472 474 rotor.configure(roto1, 0, pi/2, 64, NO_IT ) mode_fft = 1 476 fft.configure( fft1, mode_fft, fft_size, 64, NO_IT ) fft.configure( fft2, mode_fft, fft_size, 64, NO_IT ) 478 mean.configure( mean1, 64, NO_IT ) multiplier.configure( mult1, 64, NO_IT ) 480 ltsref = rom.load("lts") 482 dma_engine.configure( dma3, "microcode1", complex_type, ltsref, NO_IT, 64 ) 484 dma_engine.configure( dma4, "microcode3", complex_type, nil, SIGTER, 64 ) 486 --microcode3 = BEGIN { RECEIVE 64; } END. 488 ------------------------ -- (4) Launch modules -- 490 ------------------------ rvm.start(dma1) 492 rvm.start(dma2) rvm.start(fft1) 494 rvm.start(roto1) rvm.start(fft2) 496 rvm.start(mean1) rvm.start(dma3) 498 rvm.start(mult1) rvm.start(dma4) 500 ------------------------- 502 -- (5) Wait for result -- ------------------------- 504 print("\nwaiting...") rvm.wait( SIGTER ) 506 print("\nprocess terminated. RVM wake up.") 508 print("\ncir computed\n") 510 -- creating buffer for the CIR coefs coef = buffer.allocate( complex_type, 64 ) 512 -- copy the dma_engine buffer to the previously allocated buffer 514 dma_engine.buffer_cpy(dma4, coef) 516 ----------------------------------- -- (6) Reset useless dma-engine -- 518 ----------------------------------- dma_engine.reset(dma1) 520 dma_engine.reset(dma2) dma_engine.reset(dma3) 522 dma_engine.reset(dma4) 524 --------------------------------- -- (7) Free useless ressources -- 146

A.2 Programme du récepteur IEEE802.11a 526 --------------------------------- dma_engine.free(dma3) 528 dma_engine.free(dma4) fft.free(fft2) 530 mean.free(mean1) multiplier.free(mult1) 532 534 ----------------------------------------- -- III SIGNAL FIELD DEMODULATION 536 ----------------------------------------- print("\n------------\nsignal FIELD DEMODULATION\n-------------\n") 538 ------------------------ 540 -- (0) Initialization -- ------------------------ 542 --parameters initialization for SIGNAL demodulation Ndbps, Ncbps, Nbpsc, coding_rate, modulation = initparam802_11a(6) 544 ----------------------------------- 546 -- (1) Create required instances -- ----------------------------------- 548 --dma1, fft1 and roto1 are already allocated. equa1 = equalizer.allocate() 550 cons1 = constellation.allocate() dein1 = deinterleaver.allocate() 552 depu1 = depuncturer.allocate() vite1 = viterbi.allocate() 554 ----------------------------- 556 -- (2) Connect the modules -- ----------------------------- 558 --dma1 is already connected to the rf block rvm.connect( dma1, 1, roto1, 1, complex_type ) 560 rvm.connect( roto1, 1, fft1, 1, complex_type ) rvm.connect( fft1, 1, equa1, 1, complex_type ) 562 rvm.connect( equa1, 1, cons1, 1, complex_type ) rvm.connect( cons1, 1, dein1, 1, binary_type ) 564 rvm.connect( dein1, 1, depu1, 1, binary_type ) rvm.connect( depu1, 1, vite1, 1, binary_type ) 566 rvm.connect( vite1, 1, dma2, 1, binary_type ) 568 ------------------------------- -- (3) Configure the modules -- 570 ------------------------------- param0 = ext_symbol_size 572 param1 = 16 param2 = symbol_size 574 dma_engine.configure( dma1, "microcode4", complex_type, nil, NO_IT, param0, param1, param2) 576 -- microcode4 = BEGIN { RECEIVE ext_symbol_size; DESTROY 16; -- SEND symbol_size LOSSY } END 578 phase_drift = phase_drift + 16*phase_amount 580 rotor.configure( roto1, phase_drift, phase_amount, symbol_size, NO_IT) 582 -- fft already configured. equalizer.configure( equa1, coef, symbol_size, NO_IT ) 584 constellation.configure( cons1, Ncbps, Nbpsc, symbol_size, NO_IT ) 147

A.2 Programme du récepteur IEEE802.11a deinterleaver.configure( dein1, Ncbps, Nbpsc, Ncbps, NO_IT ) 586 depuncturer.configure( depu1, coding_rate, Ncbps, NO_IT ) viterbi.configure( vite1, Ndbps, NO_IT ) 588 param0 = 24 590 dma_engine.configure( dma2, "microcode3", binary_type, nil, IT, param0) 592 ------------------------ -- (4) Launch modules -- 594 ------------------------ rvm.start( dma1 ) 596 rvm.start( roto1 ) rvm.start( fft1 ) 598 rvm.start( equa1 ) rvm.start( cons1 ) 600 rvm.start( dein1 ) rvm.start( depu1 ) 602 rvm.start( vite1 ) rvm.start( dma2 ) 604 ------------------------- 606 -- (5) Wait for result -- ------------------------- 608 print("\nwaiting...") rvm.wait( SIGTER ) 610 print("\nprocess terminated. RVM wake up.") 612 --allocate a buffer for the SIGNAL field SIGNAL_FIELD = buffer.allocate( binary_type, 24 ) 614 -- read dma2 content dma_engine.buffer_cpy(dma2, SIGNAL_FIELD) 616 ---------------------------------------------- 618 -- (6) Use data & reset useless dma-enfgine -- ---------------------------------------------- 620 --decode SIGNAL frame length, rate, nsym = buffer.signal_decode(signal_field) 622 print("\nlength:",length,"; rate:",rate,"; nsym:",nsym) 624 buffer.release(signal_field) dma_engine.reset(dma1) 626 dma_engine.reset(dma2) 628 ----------------------------------------- -- IV DATA FIELD DEMODULATION 630 ----------------------------------------- 632 print("\n----------\ndata FIELD DEMODULATION\n----------\n") 634 ------------------------ -- (0) Initialization -- 636 ------------------------ --parameters initialization for DATA demodulation 638 Ndbps, Ncbps, Nbpsc, coding_rate, modulation = initparam802_11a(rate) 640 ----------------------------------- -- (1) Create required instances -- 642 ----------------------------------- scra1 = scrambler.allocate() 148

A.2 Programme du récepteur IEEE802.11a 644 ----------------------------- 646 -- (2) Connect the modules -- ----------------------------- 648 rvm.connect( vite1, 1, scra1, 1, binary_type ) rvm.connect( scra1, 1, dma2, 1, binary_type ) 650 ------------------------------- 652 -- (3) Configure the modules -- ------------------------------- 654 param0 = ext_symbol_size param1 = 16 656 param2 = symbol_size param3 = nsym 658 dma_engine.configure( dma1, "microcode5", complex_type, nil, NO_IT, param0, param1, param2, param3 ) 660 -- microcode5 = BEGIN { i=0; -- WHILE(i<nsym) 662 -- { RECEIVE ext_symbol_size; DESTROY 16; -- SEND symbol_size LOSSY; i++; } } END 664 phase_drift = phase_drift + 64*phase_amount 666 rotor.configure(roto1, phase_drift, phase_amount, nsym*symbol_size, NO_IT) 668 fft.configure(fft1, mode_fft, fft_size, nsym*symbol_size, NO_IT) equalizer.configure(equa1, coef, nsym*symbol_size, NO_IT) 670 constellation.configure(cons1, Ncbps, Nbpsc, nsym*symbol_size, NO_IT) deinterleaver.configure(dein1, Ncbps, Nbpsc, nsym*ncbps, NO_IT) 672 depuncturer.configure(depu1, coding_rate, nsym*ncbps, NO_IT) viterbi.configure(vite1, nsym*ndbps, NO_IT) 674 tail_offset = 16 + length*8 676 tail_size = 6 seed = 0x5d 678 --TAIL field bits must be zeroed scrambler.configure(scra1, seed, tail_offset, tail_size, 680 nsym*ncbps, NO_IT) param0 = 16 + length*8 --# SERVICE 16bits + length*8 PSDU 682 dma_engine.configure(dma2, "microcode3", binary_type, nil, IT, param0) ------------------------ 684 -- (4) Launch modules -- ------------------------ 686 rvm.start( dma1 ) rvm.start( roto1 ) 688 rvm.start( fft1 ) rvm.start( equa1 ) 690 rvm.start( cons1 ) rvm.start( dein1 ) 692 rvm.start( depu1 ) rvm.start( vite1 ) 694 rvm.start( scra1 ) rvm.start( dma2 ) 696 ------------------------- 698 -- (5) Wait for result -- ------------------------- 700 print("\nwaiting...") rvm.wait( SIGTER ) 702 print("\nprocess terminated. RVM wake up.\n") 149

A.2 Programme du récepteur IEEE802.11a 704 --allocate a buffer for the DATA field DATA_FIELD = buffer.allocate( binary_type, 16 + length*8 ) 706 -- read dma2 content dma_engine.buffer_cpy(dma2, DATA_FIELD) 708 ---------------------------------------------- 710 -- (6) Use data & reset useless dma-enfgine -- ---------------------------------------------- 712 PSDU = buffer.extract( DATA_FIELD, 16, length*8 ) 714 buffer.release(data_field) dma_engine.reset(dma1) 716 dma_engine.reset(dma2) 718 --------------------------------- -- (7) Free unused ressources -- 720 --------------------------------- rf.free(rf1) 722 dma_engine.free(dma1) dma_engine.free(dma2) 724 rotor.free(roto1) fft.free(fft1) 726 equalizer.free(equa1) constellation.free(cons1) 728 deinterleaver.free(dein1) depuncturer.free(depu1) 730 viterbi.free(vite1) scrambler.free(scra1) 732 return PSDU 734 end 150

Annexe B Liste non exhaustive des machines virtuelles existantes 151

B.1 Liste des machines virtuelles libres B.1 Liste des machines virtuelles libres 152

B.2 Liste des machines virtuelles Java B.2 Liste des machines virtuelles Java 153