Remarque 3. La forme de la règle d’application des nœuds, due à la nécessité de conserver l’état interne de l’instance d’un nœud appliqué d’un instant à l’autre, rend nécessaire le fait que les noms de variables soient différents deux à deux au sein d’un même environnement de réaction. Dans le cas contraire, des problèmes de capture de noms peuvent apparaître :
node f(x) = y where y = x + 1; node g(x) = y where y = f(x); node h(x) = y where
f = x - 1 and y = g(f)
Le corps de h serait évalué dans un environnement de réaction de la forme :
λx.y where y=x+ 1/f, λx.y where y=f(x)/g, . . .
L’application de la règle App de la sémantique réécrit le corps de h (après
α−renommage de x en x’ et y et y’) en :
f = x - 1
and let x’ = f and y’ = f(x’) in y = y’
Cette réécriture modifie le sens du programme. La sémantique impose donc de renommer f dans h, afin d’éviter le masquage de f (cette contrainte étant assurée par typage) :
node h(x) = y where f’ = x - 1 and y = g(f’)
Le corps de h est alors réécrit en :
f’ = x - 1
and let x’ = f’ and y’ = f(x’) in y = y’
Cette réécriture conserve le sens du programme.
2.5 La radio logicielle
L’exemple de motivation introduit ici servira de fil conducteur tout au long de l’exposé de ces travaux. Il s’agit d’un exemple de programmation d’un canal de réception multiple d’une radio logicielle. Une radio logicielle est une radio dont les composants (décodage du signal radio, conversion analogique/numérique,...), plutôt que d’être implantés au moyen de composants matériels spécifiques, sont
des logiciels exécutés sur des plateformes matérielles composées de composants matériels non spécifiques (processeurs, circuits reconfigurables) [65]. Cette concep-tion logicielle sur une architecture non spécifique permet de réutiliser cette archi-tecture pour la conception d’autres radios, et la reconfiguration, éventuellement dynamique, de la radio implantée. Cette technologie est donc adaptée et utilisée pour la conception de systèmes radio embarqués tels que les stations relais et les terminaux de téléphonie mobile [52].
Un canal de réception est usuellement composé de trois traitements : un filtre passe-bande permettant de sélectionner le signal porteur parmi un ensemble de fréquences, un composant de démodulation permettant d’extraire l’information reçue du signal porteur, et un traitement ultérieur de cette information (décodage, correction d’erreur, etc.). Pour simplifier, ne seront ici considérés que les deux premiers traitements.
Pour des raisons de performances, chacun de ces traitements est effectué sur un composant matériel spécialisé : le filtre passe-bande sur un FPGA2, et le composant de démodulation sur un processeur spécialisé dans le traitement du signal3.
La conception d’un tel système par des méthodes usuelles (langages de descrip-tion d’architectures, et concepdescrip-tion séparée des éléments d’architecture) aboutirait à la programmation séparée de ces deux traitements. Or, l’enjeu de la radio logicielle est de pouvoir, de manière plus simple que par conception matérielle, implanter sur un système plusieurs standards radio, ou de manière générale plusieurs fonctionna-lités [53]. Ces fonctionnafonctionna-lités sont ensuite destinées à être utilisées en parallèle, ou activées ou chargées dynamiquement. En d’autres termes, la motivation principale du principe de radio logicielle est lecontrôle dynamique.
L’exemple étudié ici sera un système logiciel de réception radio à canaux mul-tiples supportant les standards de téléphonie mobile GSM et UMTS.
– Le standard GSM est implanté par un filtre passe-bande de fréquences de 1800 MHz et un démodulateur GMSK ;
– le standard UMTS par un filtre de fréquences de 2 GHz et un démodulateur QPSK.
La figure 2.9 montre l’implémentation de cette radio logicielle sur un système composé de deux composants matériels : un FPGA pour l’exécution des deux filtres passe-bandes, et un processeur de traitement du signal (DSP) pour les fonctions de démodulation. Ce système a une entrée x, le signal radio non filtré et modulé provenant de l’antenne. La sortiey est le signal filtré et démodulé. Les transitions d’un canal à l’autre expriment le contrôle déterminant à chaque instant lequel de ces deux canaux est utilisé. Ce contrôle prend ici la forme d’une fonction g, qui détermine le canal à utiliser en fonction de la valeur du signal démodulé. La
2
Field Programmable Gate Array, circuit programmable.
3
2.5. LA RADIO LOGICIELLE 49 localisation de cette dernière fonction n’est pas déterminée a priori.
filter_2000 dem_QPSK filter_1800 dem_GMSK DSP FPGA g(y) g(y) MU X y x
Fig. 2.9 – Modèle fonctionnel d’un système de réception radio logicielle à canaux multiples.
De manière usuelle, la conception de cette radio logicielle impliquerait la concep-tion séparée de ces deux composants matériels. Cette concepconcep-tion séparée amènerait deux problèmes majeurs.
1. Le premier problème provient de la nécessité de contrôle dynamique. Du fait de la conception séparée, il n’y a aucune garantie que les composants interagissent comme spécifié : c’est-à-dire, que le filtre 1800 MHz soit exécuté en même temps que le démodulateur GMSK. Pour cela, il est nécessaire de dupliquer la fonction de contrôle (matérialisée par le multiplexeur MUX sur la figure) sur les deux composants matériels. Cette duplication compromet la modularité fonctionnelle du système.
2. Le deuxième problème relève de la cohérence imposée par la modularité fonc-tionnelle. Concevoir les deux composants matériels de manière indépendante mène à la programmation séparée de composants logiciels fonctionnellement proches (par exemple, les fonctions de filtre et de démodulation d’un même canal de réception).
La modularité fonctionnelle impose donc de concevoir (puis vérifier, tester et simuler) indépendamment chaque canal de réception, plutôt que de concevoir indé-pendamment chaque composant matériel. Cette situation montre clairement l’in-térêt d’une approche orientée langage, permettant d’exprimer conjointement, au sein d’un même programme, des aspects fonctionnels et des aspects de répartition. Cette approche orientée langage implique d’ajouter dans un langage existant des primitives permettant, d’une part, de décrire l’architecture ou son modèle visé par le système, et d’autre part, la localisation de parties du programme séparément de la description de cette architecture.
Une telle approche intégrée permet ainsi d’effectuer les tests, simulations et vé-rifications sur le programme global. La répartition automatique permet de garantir la sûreté de fonctionnement du programme réparti, en garantissant l’équivalence
entre la sémantique centralisée du programme global, c’est-à-dire sans tenir compte des directives de répartition, et sa sémantique répartie. Par exemple, la cohérence des types de données communiquées entre les sites est assurée par le fait que la vérification de cohérence des données du programme par typage est faite de ma-nière globale. Les incohérences dues, par exemple, à la sérialisation des données peuvent ainsi être détectées à la compilation.
La figure 2.10 donne l’implémentation centralisée de ce canal de réception mul-tiple. L’extension du langage aura ici pour but de déclarer l’existence de deux ressources (le FPGA et le DSP), l’implémentation du canal de réception channel
supposant l’exécution de la fonction filter sur le FPGA, et demodsur le DSP.
node filter_1800 = ... node filter_2000 = ... node demod_gmsk = ... node demod_qpsk = ...
node channel(filter,demod,x) = y where f = filter(x)
and y = demod(f)
node multichannel_sdr(x) = y where c = g(y)
and match (true fby c) with
| true -> do y = channel(filter_1800,demod_gmsk,x) done | false -> do y = channel(filter_2000,demod_qpsk,x) done end
Fig.2.10 – Implémentation du système de canal de réception multiple d’une radio logicielle.