Soutenance - D1 - 03/06/2002 Etude du bloc de réception dans un terminal UMTS-FDD et développement...

Soutenance - D1 - 03/06/2002

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 BATUTThèse encadrée par Geneviève JOURDAIN (LIS/INPG) et

Marylin ARNDT (FTRD/DIH/OCF)

Soutenance - D2 - 03/06/2002France Télécom R&D

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-FDDSpécificités de l’interface radio UMTS-FDD : le WCDMACaractère critique de l’estimation de canalImplémentation sur cible ST120

Codesign en vue du prototypage rapideQuelle architecture pour l’embarqué ?Méthodologie de codesign au niveau systèmeAdé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-type2G : Voix (principalement)2.5G : Voix + Données à des débits utiles pouvant atteindre 384 kb/s3G : 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 partitionnementA plus long terme, des architectures matérielles et logicielles innovantes ?

Grande variété des briques de baseProcesseurs (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.



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

QI+jQ

Demi-Nyquist

Demi-Nyquist

Re

Im

-sin (t

cos (t




Codes utilisés :Etalement : codes OVSF

Séquences binaires de Walsh-Hadamard, Orthogonalité des transmissions, même en cas de débits différents

S/P

I

QI+jQ

Demi-Nyquist

Demi-Nyquist

Re

Im

-sin (t

cos (t

Etalement

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

Embrouillage : codes de Gold complexes, Sommes logiques de séquences de longueur maximaleAtténuation de l’interférence inter-cellule sur le lien descendant

S/P

I

QI+jQ

Demi-Nyquist

Demi-Nyquist

Re

Im

-sin (t

cos (t

Etalement

EtalementEmbrouillage


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)

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.

Avant Après (1 trajet)


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ésDésétaler séparément les trajets resynchronisésSommer 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 situationsEmbarquabilité à 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éceptionCritè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 ?


Paramètres :Ncp, le nombre de chips pilotesOSF, le facteur de suréchantillonnageDS, 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.

Evaluation de complexité

Calcul de l’intercorrélation : > 98%

2 4 832 0,05 0,19 0,7464 0,09 0,37 1,48

128 0,19 0,74 2,96256 0,37 1,48 5,92512 0,75 2,97 11,83

1024 1,49 5,93 23,66

OSF

Ncp

MOP


Optimisation (1)

Modification du mode de calcul de l’intercorrélation

t

Point 1

Point 2

Point 3

Calcul effectué avec 1 point par échantillon, un point de corrélation par échantillon


Optimisation (1)

Modification du mode de calcul de l’intercorrélation

t

Point 1

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

Point 2

Point 3

Calcul effectué avec 1 point par chip, un point de corrélation par échantillon


Optimisation (2) Rappel du processus de génération du signal émis :

Symboles pilotes : +1, -1Codes d’étalement réels : +1, -1Chips pilotes réels : +1, -1

S/P

Etalement

Etalement

I

QI+jQ

Embrouillage



Symboles pilotes : +1, -1Codes d’étalement réels : +1, -1Chips pilotes réels : +1, -1Chips pilotes complexes avant embrouillage : (±1, ±1) = ±1 ±j

S/P

Etalement

Etalement

I

QI+jQ

Embrouillage



Symboles pilotes : +1, -1Codes d’étalement réels : +1, -1Chips pilotes réels : +1, -1Chips pilotes complexes avant embrouillage : (±1, ±1) = ±1 ±jCodes d’embrouillage complexes : (±1, ±1) = ±1 ±j

S/P

Etalement

Etalement

I

QI+jQ

Embrouillage



Symboles pilotes : +1, -1Codes d’étalement réels : +1, -1Chips pilotes réels : +1, -1Chips pilotes complexes avant embrouillage : (±1, ±1) = ±1 ±jCodes d’embrouillage complexes : (±1, ±1) = ±1 ±jChips pilotes complexes après embrouillage : ±1 ou ±j, à l’amplitude près

S/P

Etalement

Etalement

I

QI+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 à traiter2 additions / soustractions réelles




Nouvelle complexité, par itération :

2 4 832 0,01 0,02 0,0364 0,02 0,03 0,07

128 0,03 0,07 0,13256 0,07 0,13 0,26512 0,13 0,26 0,53

1024 0,26 0,53 1,05~ 18 % ~ 9 % ~ 4,5 %

Ncp

MOPOSF

0,00

0,50

1,00

1,50

2,00

2,50

3,00

Complexité(MOP)

64 128 256 512

Ncp

Complexités comparées d'une itération de l'algorithme original et de l'algorithme optimisé en millions d'opérations

réelles équivalentes, OSF=4, DS=60 chips

Alg. original

Alg. optim isé




Nouvelle complexité, par itération :

Pas d’impact évident sur les performances (étude poussée à mener ultérieurement)

2 4 832 0,01 0,02 0,0364 0,02 0,03 0,07

128 0,03 0,07 0,13256 0,07 0,13 0,26512 0,13 0,26 0,53

1024 0,26 0,53 1,05~ 18 % ~ 9 % ~ 4,5 %

Ncp

MOPOSF

0,00

0,50

1,00

1,50

2,00

2,50

3,00

Complexité(MOP)

64 128 256 512

Ncp

Complexités comparées d'une itération de l'algorithme original et de l'algorithme optimisé en millions d'opérations

réelles équivalentes, OSF=4, DS=60 chips

Alg. original

Alg. optim isé


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 GP32Absence de génération de code SLIW !

LAO (Linear Assembly Optimizer), développé par STOutil à intercaler au milieu de la chaîne GHSPossibilité 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)

512 256 128 64 32

0

0,2

0,4

0,6

0,8

1

1,2

1,4

1,6

Temps d'exécution

(méga-cycles)

Ncp

Temps d'exécution (en millions de cycles) de la phase de corrélation/recherche du trajet le plus puissant

Ass. Linéaire + LAO

GHS + LAO

GHS optim.


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.



Activité du laboratoire DIH/OCF1998 : impact de l’UMTS sur les futurs terminaux mobiles ?Quelles méthodologies pour la conception de ces terminaux ?





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 ?

1980 1990 2000 2010 2020

1G

2G

3G

Complexité

Année

Performances intrinsèques de la

technologie

Besoin en puissance de calcul imposés par les

normes


Quelle architecture pour l’embarqué ?

Compromis à trouver entre :la flexibilitéla facilité de développementla consommationles performances intrinsèques

des différentes briques

Flexibilité

HW

Mémoire

HW

HW

HW

HW

RISC

DSPHW

Mémoire

Consommation

RISC

FPGA

Mémoire


Défis méthodologiques Points durs à lever :

Découper le système en blocs communicantsDéterminer les partitionnements possibles entre le matériel et le logicielEvaluer la pertinence de ces partitionnementsDé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èmeExploitation 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érencePas 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 transferttype de la valeur éventuellement échangée

Génération automatique par l’outil N2C :des routines d’interruptionde 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éesle 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 ST120Cœur de ST120Compteurs / timers, ports sériesMémoires Flash et SRAMPort d’expansion pour y connecter des

périphériques spécifiquesPort de prise de contrôle de l’espace

adressable

Partie matérielle : émulateur AptixSystème de prototypage d’ASICTechnologie d’émulation : FPGAConnections à 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 algorithmiquesProposition 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élationOptimisation apparemment inoffensive (à confirmer)

Implémentation en précision finie sur cible ST120Bonne 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éthodologiquesProposition 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’interfaceCosimulation multi-niveaux d’abstraction, multi-langages et éventuellement

multi-cœursProblè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 :

Valider la méthodologie proposée sur l’application choisiePartie cosimulation, complètement fonctionnelle depuis peuMigration 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

Soutenance - D1 - 03/06/2002 Etude du bloc de réception dans un terminal UMTS-FDD et développement...

Documents

Transcript of Soutenance - D1 - 03/06/2002 Etude du bloc de réception dans un terminal UMTS-FDD et développement...