1 / 53

Eric BATUT Thèse encadrée par Geneviève JOURDAIN (LIS/INPG) et Marylin ARNDT (FTRD/DIH/OCF)

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 :

okalani
Download Presentation

Eric BATUT Thèse encadrée par Geneviève JOURDAIN (LIS/INPG) et Marylin ARNDT (FTRD/DIH/OCF)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 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éelLundi 3 Juin 2002 Eric BATUT Thèse encadrée par Geneviève JOURDAIN (LIS/INPG) et Marylin ARNDT (FTRD/DIH/OCF)

  2. 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

  3. 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)

  4. 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 ?

  5. 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.

  6. 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

  7. 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.

  8. 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

  9. 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 :

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

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

  12. cos (wt ) I Re Demi-Nyquist Etalement Embrouillage S/P I+jQ Q Im Demi-Nyquist -sin (wt ) Etalement Le CDMA large-bande (2) • Représentation fonctionnelle du processus de génération du signal émis • 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

  13. 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.

  14. 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.

  15. 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

  16. 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 !

  17. 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) ...

  18. 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)

  19. 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)

  20. 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 ?

  21. 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%

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

  23. Point 1 Point 2 Point 3 Optimisation (1) • Modification du mode de calcul de l’intercorrélation t • Calcul effectué avec 1 point par chip, un point de corrélation par échantillon • 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

  24. Etalement Embrouillage I S/P I+jQ Q Etalement 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

  25. Etalement Embrouillage I S/P I+jQ Q Etalement 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

  26. Etalement Embrouillage I S/P I+jQ Q Etalement 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

  27. Etalement Embrouillage I S/P I+jQ Q Etalement 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 • Les chips pilotes intervenant lors du calcul de l’intercorrélation valent +1, -1, +j ou -j.

  28. 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

  29. 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 :

  30. 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)

  31. 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

  32. 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é

  33. 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

  34. 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)

  35. 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.

  36. 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

  37. 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

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

  39. 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

  40. 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

  41. 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

  42. 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

  43. 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

  44. 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.

  45. 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

  46. 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

  47. 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

  48. 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

  49. 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).

  50. 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.

More Related