Etude du bloc de réception dans un terminal UMTS-FDD et développement d’une méthodologie de codesign en vue du fonctionnement en temps réel Lundi 3 Juin 2002 Eric BATUT Thèse encadrée par Geneviève JOURDAIN (LIS/INPG) et Marylin ARNDT (FTRD/DIH/OCF)

Plan de l’exposé Contexte de la thèse : Activités du laboratoire DIH/OCF 1998 : impact de l’UMTS sur les futurs terminaux mobiles ? Quelles méthodologies pour la conception de ces terminaux ? Le bloc de réception dans un terminal UMTS-FDD Spécificités de l’interface radio UMTS-FDD : le WCDMA Caractère critique de l’estimation de canal Implémentation sur cible ST120 Codesign en vue du prototypage rapide Quelle architecture pour l’embarqué ? Méthodologie de codesign au niveau système Adéquation au prototypage rapide Conclusions Perspectives

Contexte de la thèse (1) DIH/OCF : Direction des Interactions Humaines / Objets Communicants et Faisabilité de Systèmes Objectif du laboratoire : Anticipation des ruptures technologiques influençant les terminaux : réseaux ad-hoc, software radio, transmissions ultra-large bande (UWB), nouvelles normes de codage vidéo, transmissions xDSL … Activités : Etudes de complexité/faisabilité appliquées aux équipements terminaux (fixes, mobiles, haut-débit …) Recours au prototypage afin d’étudier des chaînes complètes et de rassembler les informations pertinentes Démarche : La recherche de la performance pure n’est pas l’objectif principal ! L’accent est mis sur l’évaluation des complexités algorithmique (MOPS), d’implémentation logicielle (MIPS, quantité de mémoire), ou microélectronique (surface de silicium, fréquence de fonctionnement)

Contexte de la thèse (2) Evolution de l’application-type 2G : Voix (principalement) 2.5G : Voix + Données à des débits utiles pouvant atteindre 384 kb/s 3G : Données à des débits utiles pouvant atteindre 2 Mb/s Applications : Internet mobile (débit moyen, transmission asymétrique) Diffusion vidéo (débit élevé, transmission asymétrique) Visiophonie (débit élevé, transmission symétrique) Principales différences algorithmiques / architecturales avec les terminaux 2G ? Faisabilité de terminaux multi-modes ?

Contexte de la thèse (3) Quelle architecture pour les terminaux 3G ? Etude de diverses stratégies de partitionnement A plus long terme, des architectures matérielles et logicielles innovantes ? Grande variété des briques de base Processeurs (DSP, MCU, hybrides), opérateurs spécialisés (ASIC, FPGA), structures hybrides … Caractéristiques : flexibilité, temps de développement, consommation, fréquences de fonctionnement ? Il est nécessaire de se pencher sur les outils et les méthodologies de conception ainsi que sur les technologies sous-jacentes.

Plan de l’exposé Contexte de la thèse : Activité du laboratoire DIH/OCF 1998 : impact de l’UMTS sur les futurs terminaux mobiles ? Quelles méthodologies pour la conception de ces terminaux ? Le bloc de réception dans un terminal UMTS-FDD Spécificités de l’interface radio UMTS-FDD : le WCDMA Caractère critique de l’estimation de canal Implémentation sur cible ST120 Codesign en vue du prototypage rapide Quelle architecture pour l’embarqué ? Méthodologie de codesign au niveau système Adéquation au prototypage rapide Conclusions Perspectives

Le CDMA (1) En Europe, première adoption du CDMA Accès multiple à répartition par code (CDMA, Code Division Multiple Access) Tatouage des communications à l’aide de codes orthogonaux Les utilisateurs communiquent en même temps, à la même fréquence. L’accroissement de la capacité du réseau s’accompagne d’une augmentation importante de la complexité globale du système.

Le CDMA (2) Principe du CDMA Multiplication du train de symboles à transmettre par un code pseudo-aléatoire de débit plus rapide Conséquence de l’augmentation du débit : élargissement et aplatissement du spectre

Le CDMA large-bande (1) Les deux modes de l’UMTS : UMTS-FDD : large couverture, débits moyens même en cas de forte mobilité UMTS-TDD : couverture réduite, débit maximum atteignable en cas de faible mobilité Première version déployée : UMTS-FDD (Wideband CDMA) Largeur d’un canal fréquentiel : 5 MHz Structure du lien descendant :

Le CDMA large-bande (2) Représentation fonctionnelle du processus de génération du signal émis S/P I Q I+jQ Demi-Nyquist Re Im -sin (wt ) cos (wt )

Le CDMA large-bande (2) Représentation fonctionnelle du processus de génération du signal émis S/P I Q I+jQ Demi-Nyquist Re Im -sin (wt ) cos (wt ) Etalement Codes utilisés : Etalement : codes OVSF Séquences binaires de Walsh-Hadamard, Orthogonalité des transmissions, même en cas de débits différents

Le CDMA large-bande (2) Représentation fonctionnelle du processus de génération du signal émis S/P I Q I+jQ Demi-Nyquist Re Im -sin (wt ) cos (wt ) Etalement Embrouillage Codes utilisés : Etalement : codes OVSF Séquences binaires de Walsh-Hadamard, Orthogonalité des transmissions, même en cas de débits différents Embrouillage : codes de Gold complexes, Sommes logiques de séquences de longueur maximale Atténuation de l’interférence inter-cellule sur le lien descendant

Pourquoi le bloc de réception ? Répartition asymétrique de la complexité entre les chaînes d’émission et de réception Du fait de l’incertitude induite par le passage à travers le canal radiomobile, les traitements les plus complexes (égalisation et décodage canal) sont effectués au sein du bloc de réception.

Le canal radiomobile Perturbations induites par le passage dans le canal radiomobile : Trajets multiples (environnement géographique) Evanouissements temporels (variation des caractéristiques du canal) Effet Doppler (mobilité du récepteur) Bruit radioélectrique (ondes parasites) Avant Après (1 trajet) Le terminal reçoit une somme bruitée de copies retardées, atténuées et déphasées du signal émis par la station de base.

Dispositif de réception classique en CDMA Dispositif classique : le récepteur Rake, ou récepteur « en râteau » 3 étapes : Resynchroniser les différents trajets identifiés Désétaler séparément les trajets resynchronisés Sommer de manière cohérente (en phase) les symboles alors désétalés

Importance de l’estimation de canal : le Searcher Pour fonctionner de manière optimale, le récepteur Rake a besoin : du nombre de trajets présents à l’entrée du récepteur, des instants d’arrivée de chaque trajet, de leur atténuation complexe (surtout la phase) L’estimation, souvent entraînée en radiocommunications mobiles, est ici effectuée à partir des symboles pilotes émis par la station de base. Complexité de l’estimation de canal >> complexité du Rake ! Très peu de références bibliographiques pertinentes pour le terminal !

Recherche d’un algorithme embarquable Critères de choix : Correction fonctionnelle dans la majorité des situations Embarquabilité à faible coût (complexité réduite) La performance pure passe au second plan. Existant : Point commun : dépouillement plus ou moins sophistiqué de l’intercorrélation entre le signal reçu et le signal pilote régénéré à la réception Critères : seuil sur le module, double-seuil, recherche exhaustive (MV) ...

Le Searcher idéal Module carré de l’intercorrélation entre le signal reçu et le signal pilote régénéré Profil de canal utilisé (3 trajets)

Solution proposée Identification itérative des trajets par ordre de module décroissant Soustraction du trajet identifié au signal reçu de manière à faciliter l’identification du prochain trajet à l’aide du même critère Conjonction de plusieurs critères pour déclencher l’arrêt des itérations : seuil d’amplitude, nombre d’itérations, qualité du trajet en cours de validation (critère innovant)

Exemple de mise en œuvre 5 trajets de même puissance, suffisamment espacés, 128 chips pilotes La suppression du trajet i facilite l’estimation des paramètres du trajet i+1. Arrêt des itérations ?

Evaluation de complexité Paramètres : Ncp, le nombre de chips pilotes OSF, le facteur de suréchantillonnage DS, le delay spread, égal à la longueur en chips de la fenêtre de recherche Complexité par itération : Variation quadratique de la complexité avec OSF due au calcul de l’intercorrélation. La réduction de la complexité est indispensable à l’embarquement de l’algorithme. Calcul de l’intercorrélation : > 98%

Optimisation (1) Modification du mode de calcul de l’intercorrélation Point 1 Point 2 Calcul effectué avec 1 point par échantillon, un point de corrélation par échantillon Point 3

Optimisation (1) Modification du mode de calcul de l’intercorrélation Point 1 Point 2 Calcul effectué avec 1 point par chip, un point de corrélation par échantillon Point 3 Conséquences : Réduction du nombre de multiplications complexes à effectuer Pas de perte de précision quant à l’estimation des retards, erreurs comparables Estimateurs construits sur des populations réduites, et donc moins précis Atténuations complexes incluant les contributions des filtres de mise en forme

Optimisation (2) Rappel du processus de génération du signal émis : Symboles pilotes : +1, -1 Codes d’étalement réels : +1, -1 Chips pilotes réels : +1, -1 S/P Etalement I Q I+jQ Embrouillage

Optimisation (2) Rappel du processus de génération du signal émis : Symboles pilotes : +1, -1 Codes d’étalement réels : +1, -1 Chips pilotes réels : +1, -1 Chips pilotes complexes avant embrouillage : (±1, ±1) = ±1 ±j S/P Etalement I Q I+jQ Embrouillage

Optimisation (2) Rappel du processus de génération du signal émis : Symboles pilotes : +1, -1 Codes d’étalement réels : +1, -1 Chips pilotes réels : +1, -1 Chips pilotes complexes avant embrouillage : (±1, ±1) = ±1 ±j Codes d’embrouillage complexes : (±1, ±1) = ±1 ±j S/P Etalement I Q I+jQ Embrouillage

Optimisation (2) Rappel du processus de génération du signal émis : Symboles pilotes : +1, -1 Codes d’étalement réels : +1, -1 Chips pilotes réels : +1, -1 Chips pilotes complexes avant embrouillage : (±1, ±1) = ±1 ±j Codes d’embrouillage complexes : (±1, ±1) = ±1 ±j Chips pilotes complexes après embrouillage : ±1 ou ±j, à l’amplitude près S/P Etalement I Q I+jQ Embrouillage Les chips pilotes intervenant lors du calcul de l’intercorrélation valent +1, -1, +j ou -j.

Optimisation (3) Les multiplications complexes (6 op. réelles) de la phase de calcul de l’intercorrélation sont remplacées par : un éventuel échange des parties réelles et imaginaires du point à traiter 2 additions / soustractions réelles

Optimisation (3) Les multiplications complexes (6 op. réelles) de la phase de calcul de l’intercorrélation sont remplacées par : un éventuel échange des parties réelles et imaginaires du point à traiter 2 additions / soustractions réelles Nouvelle complexité, par itération :

Optimisation (3) Les multiplications complexes (6 op. réelles) de la phase de calcul de l’intercorrélation sont remplacées par : un éventuel échange des parties réelles et imaginaires du point à traiter 2 additions / soustractions réelles Nouvelle complexité, par itération : Pas d’impact évident sur les performances (étude poussée à mener ultérieurement)

Implémentation sur DSP Cible : DSP-MCU dual-MAC ST120, de la famille ST100, visant le marché des télécommunications mobiles 3 jeux d’instructions : GP32, jeu d’instructions par défaut, offrant l’accès à toutes les ressources de la machine GP16, jeu d’instructions compact (~Thumb, d’ARM) adapté au code de contrôle, n’exposant qu’une partie de la machine SLIW (Scoreboarded Long Instruction Word), pouvant exécuter 4 opérations GP32 en un cycle, adapté aux noyaux de traitement du signal

Outils de développement ST100 MULTI, environnement de développement commercial classique, de Green Hills Software Compilateurs également développés par GHS : Support de certaines particularités architecturales du ST100 (compteurs de boucles matériels, arithmétique fractionnaire à l’aide d’instructions intrinsèques) Génération de code GP16 et GP32 Absence de génération de code SLIW ! LAO (Linear Assembly Optimizer), développé par ST Outil à intercaler au milieu de la chaîne GHS Possibilité de développer directement en assembleur linéaire avant de faire appel au LAO Performances maximales Perte de la portabilité

Précision finie Format des signaux d’entrée : 2x16 bits Utilisation des accumulateurs de 40 bits du ST100 pour le calcul de la corrélation et la phase de pondération/soustraction : pas de débordement à gérer Coefficients du filtre de Nyquist utilisé pour la régénération du signal pilote au sein du récepteur : 14 bits, afin d’éviter d’éventuels débordements lors du filtrage Coefficients complexes des trajets en sortie : 2x16 bits Le passage à la précision finie n’induit aucune dégradation perceptible des performances Taille du chemin de données déterminée judicieusement en adéquation avec la machine cible, au détriment de la portabilité Etude plus poussée à mener ultérieurement

Profilage Le profilage sur simulateur exact au cycle près (cycle-accurate) prend beaucoup de temps. Profilage réalisé en matériel, une fois le code implanté sur la carte d’évaluation du ST120 (utilisation de compteurs présents sur la carte et pilotables par le logiciel pour compter les cycles)

Bilan Complexité majoritaire : calcul de l’intercorrélation, même optimisé au niveau algorithmique (calcul au rythme chip) au niveau implémentation (parallélisation du calcul) L’implémentation du calcul au rythme chip sous la forme d’accumulations de produits 16 bits x 1 bit n’est pas optimale en termes d’utilisation du DSP. Il existe une fonction majoritairement chronophage dont l’implémentation purement logicielle n’est pas efficace. L’adjonction d’un coprocesseur matériel au DSP peut constituer une alternative valable à la seule implémentation logicielle.

Plan de l’exposé Contexte de la thèse : Activité du laboratoire DIH/OCF 1998 : impact de l’UMTS sur les futurs terminaux mobiles ? Quelles méthodologies pour la conception de ces terminaux ? Le bloc de réception dans un terminal UMTS-FDD Spécificités de l’interface radio UMTS-FDD : le WCDMA Caractère critique de l’estimation de canal Implémentation sur cible ST120 Codesign en vue du prototypage rapide Quelle architecture pour l’embarqué ? Méthodologie de codesign au niveau système Adéquation au prototypage rapide Conclusions Perspectives

Pourquoi des architectures hétérogènes ? Le domaine des radiocommunications mobiles exige plus que ce que la technologie peut fournir. Les besoins en puissance de calcul embarquée croissent plus vite que les performances brutes des circuits. Aujourd’hui, une architecture hétérogène s’impose. Comment développer et prototyper des systèmes bâtis autour de telles architectures ? Besoin en puissance de calcul imposés par les normes Complexité 3G Performances intrinsèques de la technologie 2G 1G 1980 1990 2000 2010 2020 Année

Quelle architecture pour l’embarqué ? Flexibilité HW Mémoire RISC DSP Consommation FPGA Compromis à trouver entre : la flexibilité la facilité de développement la consommation les performances intrinsèques des différentes briques

Défis méthodologiques Points durs à lever : Découper le système en blocs communicants Déterminer les partitionnements possibles entre le matériel et le logiciel Evaluer la pertinence de ces partitionnements Définir et caractériser les communications entre les domaines matériel et logiciel (type, fréquence, signalisation …) Et ce rapidement et sans développer le système complet ! Nouvelles méthodologies de conception, dites au niveau système Caractéristiques de la méthodologie proposée : Description en langage de haut niveau (surensemble du C) Raffinement progressif des descriptions des différents blocs composant le système Exploitation de certaines fonctionnalités de l’outil N2C (conception de SoC), comme le moteur de cosimulation et la génération d’interface

Prérequis Simulation en précision finie de l’algorithme à implémenter Les (co-)simulations sont longues, et ne doivent pas servir à mettre au point l’algorithme lui-même. Adéquation algorithme-architecture Langage C de préférence Pas d’encapsulation à développer

Spécifications exécutables Point de départ : spécifications exécutables (C) non temporisées Système découpé en blocs communicants caractérisés par leur interface et leur comportement Interface : ports maîtres ou esclaves, d’entrée ou de sortie, véhiculant une donnée ou transmettant un signal non typé (contrôle) Comportement : tâches de fond (tâches tournant en boucle, dites autonomes) tâches activées en réaction à un accès (en lecture ou en écriture) sur un port esclave Aucune caractérisation temporelle du comportement du système

Première évaluation du système Métriques utilisées : le nombre et le type des opérations effectuées par chaque bloc, le taux d’activité des ports de communications Evaluation principalement qualitative du fait de la technique d’instrumentation employée Elimination des découpages possibles qui génèrent un surplus de communications Vérification transactionnelle de la correction fonctionnelle du système

Choix du partitionnement Instanciation du (des) cœur(s) de processeur Création des domaines logiciel et matériel Introduction des horloges cadençant le ou les cœurs instanciés Affectation de certains blocs au domaine logiciel, configuration éventuelle d’un OS, compilation (facilitée depuis peu) avec les outils du cœur Synthèse automatique des interfaces HW/SW

Synthèse d’interface Paramètres dont dépend l’interface générée : répartition maître / esclave direction du transfert type de la valeur éventuellement échangée Génération automatique par l’outil N2C : des routines d’interruption de la table d’adressage (memory map) des décodeurs d’adresse nécessaires aux transactions des convertisseurs entre les protocoles utilisés par le cœur et par les ports non temporisés des blocs matériels De nombreux partitionnements peuvent être générés avec un temps d’itération réduit.

Cosimulation semi-temporisée Les parties logicielles sont simulées par l’ISS concerné, qui tourne alors en cycle-accurate (fonction accessible depuis peu pour le ST100). Le matériel reste non-temporisé. Seuls les blocs affectés au logiciel et la partie logicielle des interfaces générées sont temporisés. Points validés par la cosimulation semi-temporisée : la portabilité du code écrit vers la chaîne de compilation des cibles envisagées le comportement temporel de la partie logicielle décrivant le comportement des blocs, le partitionnement

Raffinements Temporisation des parties matérielles et choix des protocoles de communication (nombre de broches, signalisation, acquittement …) Ecriture éventuelle en langage de type RTL, de manière à pouvoir synthétiser le code produit après traduction en VHDL Ecriture manuelle des machines d’état en charge des protocoles de communication Régénération automatique par l’outil N2C des convertisseurs de protocoles

Cosimulation de validation La totalité du système est alors temporisée. Simulation des parties matérielles en C de type RTL, éventuellement en VHDL, obtenu par traduction ou par incorporation de code existant Points validés : le niveau de perturbation du logiciel engendré par la temporisation du matériel, le comportement temporel définitif de l’application sur l’architecture développée

Environnement de prototypage Partie logicielle : carte d’évaluation EV2 du ST120 Cœur de ST120 Compteurs / timers, ports séries Mémoires Flash et SRAM Port d’expansion pour y connecter des périphériques spécifiques Port de prise de contrôle de l’espace adressable Partie matérielle : émulateur Aptix Système de prototypage d’ASIC Technologie d’émulation : FPGA Connections à l’extérieur possibles

Adéquation de la méthodologie proposée au prototypage rapide Les interfaces générées par N2C ne sont utiles que lors de la phase de conception du système. Les interfaces disponibles sur l’environnement de prototypage sont plus éloignées du cœur que celles prises en compte par l’outil N2C. Concentration des interfaces générées sur le (les) bus d’expansion présent(s) dans l’environnement de prototypage. L’outil N2C ne prend pas en compte la présence des périphériques et des mémoires de la carte EV2. La table d’adressage doit être modifiée. Pour être utilisées, les mémoires déjà présentes dans l’environnement de prototypage doivent être déclarées dans le système cosimulé, et leurs adresses fixées à la main. La vitesse de l’émulateur HW est limitée (40 MHz pour l’Aptix).

Bilan Méthodologie de prototypage procédant par raffinements successifs des descriptions des blocs Temporisation de la partie logicielle dans un premier temps, puis du reste du système Utilisation de la synthèse automatique d’interface pour évaluer rapidement plusieurs stratégies de partitionnement Il n’est pas encore possible de transférer directement les images logicielles et matérielles du domaine de la simulation au domaine du prototypage.

Conclusions algorithmiques Proposition d’un estimateur de canal Algorithme itératif d’estimation de canal à suppression de trajet Optimisation du rapport Performance / Complexité Complexité fortement réduite par la modification du mode de calcul de l’intercorrélation Optimisation apparemment inoffensive (à confirmer) Implémentation en précision finie sur cible ST120 Bonne exploitation des capacités de la machine au prix d’un effort de développement important La chaîne de compilation standard n’offre pas l’accès à un niveau de performances suffisant.

Conclusions méthodologiques Proposition d’une méthodologie de conception Méthodologie permettant l’exploration rapide de l’espace des partitionnements Temporisation progressive du système, en commençant par la partie logicielle. Exploitation des capacités des nouveaux outils : Synthèse automatique d’interface Cosimulation multi-niveaux d’abstraction, multi-langages et éventuellement multi-cœurs Problème évident de jeunesse des outils Dans une optique de prototypage rapide, les interfaces générées sont à retravailler pour permettre la migration de la simulation au prototype.

Perspectives A court terme : A plus long terme : Valider la méthodologie proposée sur l’application choisie Partie cosimulation, complètement fonctionnelle depuis peu Migration sur le prototype Effectuer à l’aide du prototype une étude de performances plus vraisemblable A plus long terme : Réduction plus poussée de la complexité (suppression des recalculs de l’intercorrélation) Etudier comment prendre en compte plus tôt dans le flot les spécificités de l’environnement de prototypage, lorsque celui-ci est connu au départ Travail en cours avec la société CoWare