Experiment FindingsPDF Available

Analysis of vectored GPS receiver architecture.

Experiment Findings

Analysis of vectored GPS receiver architecture.

Algorithme de poursuite vectorielle en environnement dégradés
Impact des boucles vectorielles sur les architectures et
implantations matérielle / logiciel des récepteurs (NT2400)
ARNAUD DION, ISAE
24 mars 2014
1
TABLE DES MATIÈRES TABLE DES MATIÈRES
Table des matières
1 Introduction 3
2 Critères de spécification d’une architecture 3
2.1 Critèresliésàlalgorithme ........................................ 3
2.2 Critèresliésàlarchitecture........................................ 4
2.3 Critères liés à la méthodologie de conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Analyse 4
3.1 Analyseglobale.............................................. 4
3.2 Nombre de canaux de démodulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3 Corrélateurs................................................ 5
3.3.1 Chargeetlatencedecalcul.................................... 5
3.3.2 Communications et accès mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4 Discriminateursclassiques ........................................ 6
3.4.1 Chargeetlatencedecalcul.................................... 6
3.4.2 Communications et accès mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.5 DiscriminateursparFFT ......................................... 6
3.6 Estimateurslocaux ............................................ 6
3.6.1 Chargeetlatencedecalcul.................................... 6
3.6.2 Communications et accès mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.7 NCO.................................................... 6
3.8 Navigateur................................................. 7
3.8.1 Latence de calcul et accès mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4 Implémentation proposée 7
4.1 Architecture massivement logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.1 Analyse.............................................. 8
4.2 Architecturehybride ........................................... 10
5 Conclusion 12
Références 13
Glossaire 14
2
2 CRITÈRES DE SPÉCIFICATION D’UNE ARCHITECTURE
1 Introduction
Ce document décrit une analyse d’architecture pour l’implémentation d’un algorithme de poursuite vectoriel en
environnements dégradés. Cet algorithme est traité dans le document intitulé "D1000 : Spécification détaillée des al-
gorithmes", référence M3S/PR/NAV/CNES-PV/D1000.
Afin d’être en mesure de faire un choix raisonné d’architecture, le processus de conception doit s’appuyer sur des
simulations permettant d’extraire des métriques. L’algorithme peut être modélisé à l’aide d’un outil d’analyse d’archi-
tecture, en utilisant un langage indépendant de l’architecture matérielle ou logicielle, tel que SystemC [1]. Le modèle
est ensuite mappé sur une architecture en vue de simulation. Cette méthodologie de conception est dite en Y. Cette
étude ne porte pas sur la conception d’un récepteur vectoriel, mais sur sur la seule analyse d’architecture. Nous n’avons
alors pas besoin du résultats des opérations effectuées par l’algorithme. Nous n’avons besoin que du comportement gé-
néral de l’algorithme du point de vu de l’architecture. Nous avons donc modélisé le fonctionnement de chaque module
de l’algorithme du point de vue des interfaces. C’est-à-dire que nous avons modélisé les communications ainsi que
la latence des opérations. Les accès mémoires et les communications entre modules définissent la relation de chaque
module avec son environnement. La latence définit la charge de calcul de chaque module.
Nous présentons dans un premier paragraphe les principaux critères qui ont guidés la spécification de l’architecture.
Ce paragraphe permettra au lecteur de comprendre l’analyse faite dans le deuxième paragraphe. Pour une information
plus complète sur ces critères, le lecteur est invité à se référer à [2] et à [3]. Le troisième paragraphe présente ensuite
l’architecture proposée.
2 Critères de spécification d’une architecture
Dans ce chapitre, nous présenterons succinctement les critères pouvant orienter le choix d’une architecture support
d’un algorithme. Ces critères peuvent être divisés en 3 catégories :
Critères liés à l’algorithme ;
Critères liés à l’architecture ;
Critères liés à la méthodologie de conception.
En réalité, ces différents critères ne peuvent pas être classés strictement dans une catégorie ou une autre. Chacun de
ces critères a un impact sur plusieurs aspects de l’architecture ou de l’algorithme. Cela se nomme l’adéquation al-
gorithme/architecture. Il est difficile d’estimer directement l’impact de chaque critère sur l’architecture ou sur l’algo-
rithme. Le processus de conception est donc le plus souvent bouclé. Il est appelé exploration de l’espace de conception,
ou Design Space Exploration (DSE).
2.1 Critères liés à l’algorithme
Les deux critères les plus importants de l’algorithme sont la fréquence des données traitées, et la charge de cal-
cul. La fréquence est une des spécifications de l’application. La charge de calcul est le nombre de calcul nécessaires
pour une opération donnée. Ces deux paramètres sont indissociables lors d’une analyse d’architecture. Par exemple,
à fréquence fixe, une charge de calcul élevée nécessite une architecture parallèle ou une architecture rapide. Le type
de calcul est également important. Certains calculs peuvent être pipelinés. Cela veut dire que ces calculs peuvent être
exécutés sur plusieurs modules élémentaires différents. La fréquence des calculs peut ainsi être très élevée, au prix
d’une latence également élevée. La latence est le temps mis par l’architecture pour exécuter une opération donnée.
Selon la dynamique des données, certaines opérations peuvent être exécutées sur une architecture à virgule fixe. Les
différente opérandes d’une opération doivent avoir des dynamiques similaires. Les résultats des opérations intermé-
diaires d’un algorithme doivent également être relativement stationnaire. Si ces deux conditions ne sont pas respectées,
les erreurs d’arrondis lors des calculs intermédiaires vont générer un bruit de calcul qui va dégrader fortement la per-
formance de l’algorithme. Dans ce cas, l’utilisation d’une architecture de calcul à virgule flottante est impérative.
Certaines opérations d’un algorithme peuvent être identiques. Il est alors possible de factoriser ces opérations en un
seul module de calcul. La fréquence de calcul doit être suffisante pour absorber la charge. Un module de contrôle-
commande doit être implémenté afin d’ordonnancer les opérations pour les différentes parties de l’algorithme. La
granularité de factorisation est un paramètre important. Il faut en effet tenir compte des interfaces entre les différents
modules. Si la granularité est faible, le nombre de modules factorisables peut être important. Mais chaque module
nécessite une interface de communication. Si le nombre d’interfaces est trop important, cela va ralentir la fréquence
des calculs et augmenter la surface du composant.
3
2.2 Critères liés à l’architecture 3 ANALYSE
2.2 Critères liés à l’architecture
L’utilisation d’une Floating Point Unit (FPU) n’est pas neutre en terme d’implémentation d’architecture. En ef-
fet, une FPU est très complexe à réaliser, cela entraine donc la réutilisation de module déjà existant, appelés blocs
d’Intellectual Property (IP). Afin d’être générique, ces IP s’interfacent le plus souvent avec des bus standards du mar-
ché. Il faut donc prévoir d’implémenter ces bus. De plus, les calculs d’une FPU ont une certaine latence, qui dépend
du type de calcul et qui est plus importante que la latence d’un calcul en virgule fixe. Il faut ajouter à cela la latence
du bus de communication.
Actuellement, les goulots d’étranglement des performances des System On Chip (SOC) sont la communication et
l’accès à la mémoire [2]. Les modules implémentés en logiciel sont ralentis par les accès mémoire. L’augmentation de
la fréquence de fonctionnement n’est donc pas le meilleur remède pour l’optimisation des performances. Il faut porter
un soin tout particulier à l’architecture des bus et à l’architecture mémoire. Pour cela, les processeurs contiennent des
mémoires caches, plus proches du cœur. Mais l’utilisation de ces mémoires implique une gestion très complexe des
flux de données et de la synchronisation entre les données stockées dans différents espaces mémoires. Cette solution
n’est donc pas toujours adaptée pour certains types d’applications.
2.3 Critères liés à la méthodologie de conception
La méthodologie et les langages de conception peuvent également être des critères importants lors de la spéci-
fication d’une architecture. Les temps de conception et d’implémentation, ainsi que les compétences des personnes
doivent notamment être prises en compte. Nous traitons dans ce projet une étude amont, ces critères ne seront donc
pas pris en compte lors de l’analyse d’architecture.
3 Analyse
L’algorithme a été divisé en plusieurs modules cohérents. La granularité de cette première division est relativement
grossière. Elle correspond à des types de calculs différents, et à des fréquences différentes. Nous pouvons analyser
chacun des modules, le but n’étant pas ici de redévelopper les calculs, mais de les confronter aux critères exposés
précédemment.
3.1 Analyse globale
Il existe plusieurs possibilités d’architecture en mesure de supporter cet algorithme. Une analyse globale va per-
mettre de fixer certains choix avant de faire une analyse détaillée des différents modules. Cette analyse s’appuie
essentiellement sur les caractéristiques de communication inter-modules ainsi que sur l’architecture de la mémoire.
Ces deux critères étant les principaux goulots d’étranglement des performances des systèmes numériques actuels.
Nous pouvons observer que les modules corrélateurs, discriminateur et Numerically Controlled Oscillator (NCO)
échangent des données à la fréquence d’échantillonnage. Le volume de données échangé implique que ces modules
soient dans le même composant.
Nous analysons une architecture hybride matérielle-logicielle. Le logiciel doit être stocké dans une mémoire externe.
Une mémoire non-volatile, type mémoire Flash, doit être implantée afin de stocker le logiciel et les différentes données
telles que les codes d’étalement. Le logiciel doit être exécuté sur une mémoire type Double Data Rate (DDR) car les
temps d’accès des mémoires non-volatiles ne sont pas compatibles avec une application rapide.
Des modules différents ont besoin d’avoir un accès à la mémoire. Les codes d’étalement utilisés par les modules
corrélateurs doivent ainsi être stockés dans une mémoire (voir 3.3). Il ne parait pas judicieux d’envisager plusieurs
mémoires externes pour cette plateforme. La surface de la carte et le nombre de signaux nécessaires à l’interconnexion
de plusieurs mémoires limitent cette possibilité. De plus l’utilisation de plusieurs mémoires afin de stocker quelques
dizaines de kilo-octets de données ne parait pas appropriée. Nous proposons donc l’utilisation d’une seule mémoire
flash et d’une seule mémoire DDR. En tenant compte des échanges de données entre modules et avec les mémoires,
nous proposons l’utilisation d’un seul composant numérique programmable comme support des algorithmes.
Une analyse rapide des algorithmes fait ressortir le fait que des modules de contrôle/commande devront être implé-
mentés. Ils sont nécessaires lors de la phase de transition pour l’initialisation des paramètres de la démodulation, mais
également durant la phase de poursuite afin de contrôler l’état de santé des canaux. Ces modules sont essentiellement
des arbres décisionnels, ils peuvent donc être implémentés sous forme de machine à états. La fréquence de décision est
faible devant la fréquence de calcul. Il est donc possible de factoriser les modules de contrôle-commande de chaque
canal en un seul module. Nous proposons d’implémenter ce module sur un processeur, qui est par essence une machine
à état. L’utilisation d’un OS temps réel, type RTLinux, permettra de gérer l’ensemble des tâches sur ce processeur. La
4
3.2 Nombre de canaux de démodulation 3 ANALYSE
mémoire doit donc être suffisamment importante pour contenir l’empreinte de l’OS, des tâches ainsi que des données
nécessaires au traitement.
La plateforme proposée est donc un SOC matériel-logiciel. Elle doit pouvoir supporter un ou plusieurs processeurs.
Les familles récentes de Field Programmable Gate Array (FPGA) comporte un processeur hardcore performant. Nous
pouvons citer en exemple la famille Zynq du fabricant Xilinx qui comporte un processeur dual-core ARM CortexA9
[4].
3.2 Nombre de canaux de démodulation
Ce paramètre est important pour le choix d’une architecture car il est lié à la charge de calcul globale du système.
Pour une application terrestre, le nombre typique de satellites en visibilité est une dizaine. Nous ne tenons pas compte
ici d’éventuels blocages liés au terrain, tels que des bâtiments ou des montagnes. Du fait de l’évolution de la géométrie
du système satellite-récepteur, ponctuellement plus de satellites peuvent être visibles. C’est pourquoi il est nécessaire
de prévoir quelques canaux supplémentaires. Les récepteurs GPS commerciaux comportent typiquement douze ca-
naux. Le déploiement de nouvelles constellations telle que Galileo augmente le nombre de satellites en visibilité. De
plus, les nouveaux satellites offrent plus de services, et donc plus de signaux. L’open service de Galileo en bande E1
est ainsi diffusé sur deux voies, une voie pilote sans données mais avec un code secondaire, et une voie donnée. Cha-
cune de ces voies nécessite un canal de démodulation. Il n’est pas systématiquement nécessaire de démoduler toutes
les voies, mais en l’absence de contraintes à ce sujet, nous avons considéré que le système devait pouvoir le supporter.
Nous considérerons donc une plateforme comportant 40 canaux de démodulation.
3.3 Corrélateurs
3.3.1 Charge et latence de calcul
Les corrélateurs sont des modules de calculs simples mais fonctionnant à la fréquence des données. La charge de
calcul de chaque module de corrélation dépend de la fréquence des données, mais également du nombre de multi-
plieurs. Le signal étant complexe, chaque voie (réelle et imaginaire) doit être traitée indépendamment. Nous n’avons
pas d’information sur le nombre de corrélateurs nécessaire à l’algorithme. Nous utiliserons donc le nombre minimum
de corrélateurs du discriminateur Early Minus Late (EML). Les modules de corrélation utilisent alors 8 multiplieurs,
2 pour la multiplication par la réplique de la porteuse, et 6 pour les multiplications par les répliques du code.
Les modules corrélateurs comportent également un intégrateur. La durée d’intégration doit pouvoir être réglable en
fonction du signal démodulé.
3.3.2 Communications et accès mémoire
Les interfaces liées aux données apparaissent dans le document de spécification des algorithmes. Dans le cas du
signal GPS Coarse Acquisition (C/A), le début de l’intégration doit pouvoir être réglé en fonction du bit de donnée.
Ces modules doivent donc avoir une interface de communication vers un module de supervision pouvant spécifier le
type de signal poursuivi.
Les corrélateurs doivent également générer les répliques du code local. Les services des nouvelles constellations ne
permettent pas de créer le code d’étalement à partir d’une fonction logique [5]. L’ensemble des codes doit donc
être stocké dans une mémoire locale à la plateforme. Le volume de données et la reconfigurabilité des corrélateurs en
fonction du service à poursuivre entraine le fait que l’ensemble des codes doit être stocké dans une mémoire accessible
par tous les corrélateurs. Mais la lecture chip par chip par les corrélateurs des codes stockés en mémoire n’est pas
envisageable pour plusieurs raisons. La fréquence des données et le nombres de corrélateurs entraine une charge trop
importante sur le bus de communication et sur l’accès à la mémoire. Afin de réduire le nombre d’accès à la mémoire et
la place des codes dans cette mémoire, les chips seront stockés sous formes de mots, chaque mot contenant plusieurs
chips. Les mots devront être alignés sur la taille du bus mémoire afin de réduire les contrôles et les temps d’accès.
L’ensemble des modules corrélateurs ne peut pas avoir accès au bus. Les corrélateurs devraient être en mode Master
sur le bus. Mais leur nombre dépasse les capacité d’un arbitre de bus. Le nombre de transactions générées créerait
dans tous les cas un goulot d’étranglement. Nous préconisons donc que les codes puissent être stockés localement
dans chaque corrélateurs, mais qu’il n’y ait qu’une seule interface Master sur le bus pour tout les corrélateurs. Cela
implique d’implémenter un module de contrôle-commande qui charge la mémoire de chaque corrélateur avec le bon
code au début de la phase de poursuite.
5
3.4 Discriminateurs classiques 3 ANALYSE
3.4 Discriminateurs classiques
3.4.1 Charge et latence de calcul
Les calculs des discriminateurs proposés dans le document de référence sont relativement complexes, notamment
à cause des divisions et des fonctions trigonométriques. De plus la quantification des calculs est importante pour la
performance globale du récepteur. La meilleure solution pour la performance est donc ici d’utiliser une FPU. Les
discriminateurs sont identiques pour tous les canaux. La charge de calcul est peu élevée par rapport à la fréquence
de ces calculs. La latence de calcul n’est pas stricte, elle peut varier car la dynamique du système est peu élevée par
rapport à la fréquence des calculs. Nous pouvons donc factoriser ce module pour tous les canaux, et l’exécuter sur un
processeur qui possède une FPU native. Le nombre important de canaux, et le fait qu’ils ne soient pas synchronisés
entre eux, impose l’utilisation d’un OS temps réel.
3.4.2 Communications et accès mémoire
Les calculs nécessitent peu de variables intermédiaires. Il n’y a pas besoin d’avoir accès à de grande quantité de
données stockées en mémoire. L’algorithme peut tourner sur la mémoire cache. Il ne sera donc pas ralenti par les accès
mémoire.
3.5 Discriminateurs par FFT
Le document de spécification envisage l’utilisation de Fast Fourier Transform (FFT) dans certains cas.
Il s’agit de FFT dites glissantes, c’est-à-dire que les calculs vont être effectués sur un buffer de données circulaire. La
latence de calcul est donc ici un paramètre important. Contrairement aux idées reçues, la charge de calcul d’une FFT
est faible. La latence de calcul d’une FFT est due essentiellement aux accès mémoire. En effet, à chaque étage d’une
FFT, toutes les données sont accédées en lecture et en écriture. De plus, l’utilisation du mode burst est impossible à
cause de la nature même des calculs de la FFT. Le seul moyen de diminuer la latence de calcul d’une FFT est de stocker
les données dans une mémoire locale. Nous proposons donc d’implémenter ce module sous forme d’un accélérateur
matériel, avec sa propre mémoire. Seul les résultats seront partagés avec la partie contrôle/commande de ce module,
qui sera implémentée sur la même achitecture que les autres discriminateurs, c’est-à-dire sur un processeur.
3.6 Estimateurs locaux
Les estimateurs locaux traitent les données en provenance des discriminateurs pour chaque canal de démodulation.
3.6.1 Charge et latence de calcul
L’utilisation d’un filtre de Kalman à gain fixe entraine une charge de calcul accrue par rapport à un filtre de
boucle classique. De plus, un filtre de Kalman nécessite plus de variables afin de stocker l’ensemble des valeurs
internes. Les accès mémoires seront donc plus nombreux. Dans ce cas la latence de calcul peut donc devenir trop
importante par rapport à la période des données à traiter. Une analyse complémentaire est ici nécessaire afin faire le
choix d’implémentation de ce module. Les résultats de simulation permettront de guider ce choix.
L’utilisation de filtres classiques, par opposition aux filtres de Kalman, permet de limiter la charge de calcul. Si les
paramètres des filtres sont fixés, la charge de calcul est peu élevée par rapport à la latence. Cette latence dépend de la
dynamique du système, car nous sommes en présence d’un algorithme bouclé. La dynamique est faible par rapport à
la fréquence de calcul. La latence peut donc être de quelques milli-secondes. De plus cette latence n’est pas stricte,
elle peut varier sans avoir d’incidence notoire sur la performance. Cela permet d’absorber des pics éventuels sur la
charge de calcul.
3.6.2 Communications et accès mémoire
L’estimateur local utilise beaucoup de variables intermédiaires, que ce soit dans le cas d’un filtre de Kalman, ou
d’un filtre classique. En effet, toutes les valeurs internes des filtres doivent être stockées entre deux exécution du
process. Les accès mémoires risquent donc d’être ici le critère limitatif des performances de ce module.
3.7 NCO
Les NCO fonctionnent à la fréquence des échantillons. C’est un module calculatoire simple, mais faisant appel à
des fonctions trigonométriques. Afin d’être en mesure de suivre la fréquence de calcul, nous proposons l’implémen-
6
3.8 Navigateur 4 IMPLÉMENTATION PROPOSÉE
tation des fonctions trigonométrique dans une mémoire locale. Cela permettra de diminuer la latence de calcul, et de
réduire la charge sur le bus de communication.
Les NCO doivent être connectés à un bus afin de pouvoir recevoir les corrections de phases envoyées par les estima-
teurs locaux. Afin de ne pas multiplier les interfaces sur le bus, nous pouvons envisager une seule interface esclave qui
recevrait les corrections pour tous les NCO.
3.8 Navigateur
Le navigateur est en réalité constitué de plusieurs algorithmes de calculs bien distincts. Nous pouvons citer les
deux principaux en terme de charge de calcul : le calcul des positions des émetteurs et le calcul de la position du
récepteur. Les autres calculs représentent une charge très faible par rapport aux deux cités. Nous les négligerons donc
lors de cette analyse.
3.8.1 Latence de calcul et accès mémoire
La correction des NCO est effectuée par le navigateur. Dans un récepteur classique, cette correction dépend du
temps d’intégration. Nous prendrons ici une valeur typique de 10 ms. La fréquence de calcul du navigateur doit alors
être de 100 Hz. Cette valeur est compatible avec les contraintes posée par le document de référence. A titre de com-
paraison, une application terrestre typique a besoin d’une fréquence de 4 Hz. De plus les calculs sont plus complexes
dans le cas de cette application que pour un récepteur typique. Nos simulations ont montrées que ces algorithmes
faisaient massivement appel à la mémoire pour le stockage de valeurs intermédiaires. Le calcul des postions des sa-
tellites émetteurs utilise également de nombreuses fonctions trigonométriques. L’algorithme de calcul de la position
de l’émetteur est essentiellement basé sur une inversion de matrice. Cette matrice peut être de taille importante. Les
valeurs numériques des éléments de cette matrice entrainent des valeurs particulières lors de l’inversion. L’utilisation
d’un algorithme tel que le pivot de Gauss n’est ici pas possible. Ceci est dû aux arrondis effectués lors des calculs in-
termédiaires, même en utilisant une FPU. L’algorithme de Greville permet d’inverser une matrice dans tous les cas de
figures. Cet algorithme est constitué de plusieurs boucles de calculs imbriqués. La taille de la mémoire nécessaire et la
structure des calculs intermédiaires rend impossible l’utilisation de la seule mémoire locale, ou de la mémoire cache.
L’appel à la mémoire externe va par conséquent ralentir ces calculs. Afin de pouvoir tenir les performances, il faut
donc une mémoire DDR rapide, ainsi qu’un bus capable d’exploiter cette mémoire à son maximum de performance.
4 Implémentation proposée
4.1 Architecture massivement logicielle
D’après l’analyse du paragraphe précédent, seul les modules travaillant à la fréquence des données seront implé-
mentés en matériel. Les trois modules de calcul dit haut-niveau, c’est-à-dire les discriminateurs, les estimateurs et le
navigateur, seront implémentés sur un processeur.
Nous préconisons l’utilisation d’une plateforme FPGA afin d’assurer au maximum l’intégration des interconnexions
entre modules et de faciliter l’accès à la mémoire centrale. Un composant tel que le Zynq de Xilinx comporte un pro-
cesseur dual-core ARM CortexA9. L’interconnexion dans le composant peut se faire par un bus Advanced eXtensible
Interface (AXI), ou par un bus Peripheral Component Interconnect Express (PCIe). Afin d’ordonnancer les tâches, et
de les distribuer sur un ou autre des cœurs, nous avons utilisé l’OS Digilent Embedded Linux 3.6. La figure 1 montre
l’architecture proposée dans ce cas. La fréquence des processeurs et de la mémoire externe est ici de 500 MHz.
Cette architecture repose sur le principe de la méthodologie de conception Software Defined Radio (SDR). Cette
méthodologie propose d’implémenter tous les modules possibles sur processeur. En effet, cela permet d’utiliser un
langage de conception de haut niveau, tel que le C, ainsi que de nombreuses bibliothèques standard. Le temps de
réalisation est donc réduit.
7
4.1 Architecture massivement logicielle 4 IMPLÉMENTATION PROPOSÉE
FIGURE 1 – Architecure proposée
4.1.1 Analyse
Les figures 2 et 3 représentent le taux d’occupation des processeurs sous forme de camembert. Nous pouvons voir
que les processeurs sont très chargés. Les processeurs n’ont en fait pas le temps suffisant pour traiter les données en
provenance des intégrateurs. Nos simulations montrent que des données sont perdues dans ce cas. La latence de calcul
est plus importante que la période des données.
FIGURE 2 – Taux d’occupation du cœur 0, estimateurs
locaux utilisant des filtres de Kalman FIGURE 3 – Taux d’occupation du cœur 1
Les figures 4 et 5 montrent la distribution temporelle des tâches sur les processeurs. Nous pouvons observer que
l’estimateur occupe 100% d’un processeur dès le début de la simulation. En effet, il y a en réalité 40 estimateurs
locaux. Il s’agit de la même tâche logicielle, mais exécutée avec des données internes différentes à chaque instance. Il
n’est pas possible de stocker l’état interne de chaque estimateur en mémoire cache. Afin de protéger l’espace mémoire
de chaque estimateur, les données sont stockées à des adresses spécifiques de la mémoire centrale. Nos simulations ont
8
4.1 Architecture massivement logicielle 4 IMPLÉMENTATION PROPOSÉE
montrée que les tâches estimateur local sont ralenties par les accès mémoire. La gestion de la mémoire cache dégrade
les performances de l’architecture. Le taux d’occupation élevée des processeurs montre que les tâches exécutées n’ont
pas suffisamment de temps pour exécuter les différentes tâches. Il faut donc réduire la charge sur les processeurs, ou
réduire les accès mémoires. Les estimateurs locaux représentant la majeure partie de la charge des processeurs, nous
pouvons focaliser nos efforts sur ces modules.
FIGURE 4 – Utilisation du cœur 0 FIGURE 5 – Utilisation du cœur 1
L’utilisation d’un filtre classique au lieu d’un filtre de Kalman permet de réduire la charge de calcul et l’empreinte
mémoire des données interne, réduisant ainsi le nombre d’accès. Mais cela ne suffit pas pour réduire suffisamment le
taux d’occupation des processeurs. Nous pouvons observer, sur les figures 6 et 7, que la charge des processeurs reste
très élevée. Dans ce cas également des données sont perdues.
FIGURE 6 – Taux d’occupation du cœur 0, estimateurs
locaux utilisant des filtres classiques FIGURE 7 – Taux d’occupation du cœur 1
Une autre solution pour réduire la charge des processeurs est de réduire le nombre de canaux de démodulation. Les
informations de phase et de fréquence Doppler en sortie des discriminateurs sont corrélées pour tous les canaux traitant
les signaux en provenance d’un même satellite. Nous avons choisi pour cette simulation de conserver le nombre de
canaux et donc discriminateurs, mais de n’utiliser qu’un estimateur par satellite, et non pas un estimateur par canal.
Les figures 8 et 9 montrent les résultats de simulation de ce cas de figure. Nous pouvons voir que la charge des proces-
9
4.2 Architecture hybride 4 IMPLÉMENTATION PROPOSÉE
seurs a bien été réduite. Dans ce cas de figure, toutes les données sont traitées. Du fait du nombre important de tâches
à activer, l’OS prend un temps non négligeable sur le processeur.
FIGURE 8 – Taux d’occupation du cœur 0, estimateurs
locaux utilisant des filtres classiques FIGURE 9 – Taux d’occupation du cœur 1
Afin de résoudre un problème de performance, la première solution envisagée est souvent l’augmentation de la
fréquence de fonctionnement des processeurs et de la mémoire. Or le problème vient ici du nombres de tâches à traiter
et du temps d’accès à la mémoire. L’augmentation de la fréquence ne pourrait améliorer que de façon marginale les
performances de cette architecture. Nous préconisons plutôt de revoir l’implémentation de l’algorithme, et l’algorithme
lui-même, afin de pouvoir respecter les spécifications de l’application.
4.2 Architecture hybride
Nous pouvons observer dans les figures 2 et 3 que la tâche navigateur occupe peu de temps sur les processeurs.
Nous ne pourrons donc pas gagner suffisamment de temps en optimisant cette tâche.
Il serait possible de créer des accélérateurs matériels pour les calculs des estimateurs. Mais, dans ce cas, les calculs
seraient en virgule fixe. De plus la structure de ces calculs ne permet pas de les exporter en totalité sur du matériel.
Dans ce cas, le temps de latence de la communication entre les estimateurs et les accélérateurs annulerait le gain de
temps.
Les discriminateurs préconisés par le document de référence sont les plus complexes. Il existe des discriminateurs dont
les calculs, moins complexes, peuvent être implémentés en virgule fixe [6]. Ces discriminateurs évitent également le
recours à des diviseurs. Ces algorithmes seraient alors facilement implémentables dans un module matériel. L’expor-
tation des discriminateurs vers le matériel permet ainsi d’alléger la charge des processeurs. La figure 10 présente cette
architecture. Les discriminateurs sont ici entièrement implémentés en matériel.
10
4.2 Architecture hybride 4 IMPLÉMENTATION PROPOSÉE
FIGURE 10 – Architecure proposée
Les figures 11 et 12 montrent le taux d’utilisation des processeurs lorsque les discriminateurs sont implémentés
en matériel. Les estimateurs locaux sont implémenté sous forme de filtre de Kalman à gain fixe. Nous pouvons donc
comparer directement ces deux figures avec les figures 2 et 3. Nous pouvons observer que la tâche idle est plus impor-
tante dans ce cas. Cela signifie que les processeurs ont plus de temps disponible afin de traiter les tâches estimateurs
et navigateur.
FIGURE 11 – Utilisation du cœur 0 FIGURE 12 – Utilisation du cœur 1
Les figures 13 et 14 présentent la distribution des tâches dans le temps dans le cas d’une architecture hybride. Nous
pouvons voir qu’aucune tâche de l’application n’occupe les processeurs à 100% pendant une longue durée. Cela
confirme bien que le temps disponible pour traiter les tâches est suffisant. Nos simulations ont montrées que la latence
des calculs était bien inférieure à la période des données.
Le taux d’utilisation des processeurs permet d’envisager de porter certaines parties des discriminateurs en logiciel,
11
5 CONCLUSION
FIGURE 13 – Utilisation du cœur 0 FIGURE 14 – Utilisation du cœur 1
notamment afin de pouvoir bénéficier des calculs en virgule flottante. Nous proposons de retenir cette architecture
pour l’implémentation de l’algorithme de poursuite vectoriel.
5 Conclusion
L’analyse d’implémentation demandée se situe en amont de la phase de conception d’un récepteur. Nous n’avons
donc pas un modèle implémentable de l’algorithme. Afin de mener cette analyse, nous avons donc modélisé chaque
module du point de vue des interfaces. Nous avons ensuite pu faire des simulations qui permettent de mesurer différents
paramètres de l’architecture. Nous proposons ainsi une architecture basée sur des résultats analysés, et non pas sur la
seule estimation. Le modèle utilisé est un modèle d’exécution du point de vue des interfaces. Les paramètres de ce
modèle, tels que les latences, volumes de données échangées, sont approximés. De plus l’architecture proposée est
très complexe au niveau des mémoires et de la gestion de ces mémoires. Le fonctionnement des accès mémoires est
ainsi très dépendant des accès effectués par l’algorithme. Le nombre de variables internes, les accès à ces variables,
ont un impact important sur les accès mémoires. Nous avons modélisé approximativement ces comportements. Du fait
des approximations de modélisation, les résultats de simulations ne peuvent être considérés comme un reflet exact du
fonctionnement d’un récepteur.
Malgré ces limitations du modèle utilisé, nous avons pu en tirer des résultats qu’il aurait été difficile d’estimer
directement. Le processus de conception et d’implémentation de l’architecture peut donc s’appuyer sur les analyses
présentées dans ce document. Nous proposons une architecture basée sur la plus grande factorisation possible des
éléments de l’algorithme. Nous avons montré que cette architecture présentait des risques en terme de latence de
calcul. Nous proposons donc de changer certains modules de l’algorithme afin de pouvoir les implémenter en matériel.
Une autre solution possible serait de paralléliser totalement les modules, au lieu de les factoriser. Les possibilités
technologiques actuelles permettent d’envisager l’utilisation d’un micro-contrôleur par canal [7]. Les discriminateurs
et l’estimateur de chaque canal seraient donc exécuté sur un processeur dédié, doté d’une FPU. l’empreinte du code
et des données permettrait d’envisager l’utilisation d’une mémoire locale à chaque processeur. Le déterminisme accru
de cette solution, par rapport à la factorisation, permettrait de faciliter la phase de conception. La conséquence de
cette architecture est que la surface du composant serait bien plus importante que celle de la solution préconisée. La
consommation électrique et le prix du composant augmenteraient également dans des proportions non-négligeables
12
RÉFÉRENCES RÉFÉRENCES
Références
[1] IEEE Computer Society. SystemC langauage reference manual, IEEE 1666 standard, 2011.
[2] C. Rowen. Engineering the complex SOC. Prentice Hall, third edition, 2004.
[3] M. Keating and P. Bricaud. Reuse Methodology Manual for System-On-A-Chip designs. Kluwer Academic
Edition, third edition, 2002.
[4] Xilinx. Zynq-7000 All programmable SOC technical reference manual, 2014.
[5] European Union and European Space Agency. Galileo Open Service Signal in Space Interface Control Document,
OS SIS ICD, version 1.1. 2010.
[6] Kaplan Elliot D. Understanding GPS, Principles and applications. Artech House, 2nd edition, 2006.
[7] System drivers. Technical report, International Technology Roadmap for Semiconductor, 2011.
13
Glossaire Glossaire
Glossaire
AXI Advanced eXtensible Interface. 7
C/A Coarse Acquisition. 5
DDR Double Data Rate. 4, 7
DSE Design Space Exploration. 3
EML Early Minus Late. 5
FFT Fast Fourier Transform. 6
FPGA Field Programmable Gate Array. 5, 7
FPU Floating Point Unit. 4, 6, 7, 12
IP Intellectual Property. 4
NCO Numerically Controlled Oscillator. 4, 6, 7
PCIe Peripheral Component Interconnect Express. 7
SDR Software Defined Radio. 7
SOC System On Chip. 4, 5
14
ResearchGate has not been able to resolve any citations for this publication.
Book
This thoroughly updated second edition of an Artech House bestseller brings together a team of leading experts who provide a current and comprehensive treatment of the Global Positioning System (GPS). The book covers all the latest advances in technology, applications, and systems. The second edition includes new chapters that explore the integration of GPS with vehicles and cellular telephones, new classes of satellite broadcast signals, the emerging GALILEO system, and new developments in the GPS marketplace. This single-source reference provides a quick overview of GPS essentials, an in-depth examination of advanced technical topics, and a review of emerging trends in the GPS industry.
Book
Reuse Methodology Manual for System-on-a-Chip Designs, Third Edition outlines a set of best practices for creating reusable designs for use in an SoC design methodology. These practices are based on the authors' experience in developing reusable designs, as well as the experience of design teams in many companies around the world. Silicon and tool technologies move so quickly that many of the details of design-for-reuse will undoubtedly continue to evolve over time. But the fundamental aspects of the methodology described in this book have become widely adopted and are likely to form the foundation of chip design for some time to come. Development methodology necessarily differs between system designers and processor designers, as well as between DSP developers and chipset developers. However, there is a common set of problems facing everyone who is designing complex chips.In response to these problems, design teams have adopted a block-based design approach that emphasizes design reuse. Reusing macros (sometimes called "cores") that have already been designed and verified helps to address all of the problems above. However, in adopting reuse-based design, design teams have run into a significant problem. Reusing blocks that have not been explicitly designed for reuse has often provided little or no benefit to the team. The effort to integrate a pre-existing block into new designs can become prohibitively high, if the block does not provide the right views, the right documentation, and the right functionality. From this experience, design teams have realized that reuse-based design requires an explicit methodology for developing reusable macros that are easy to integrate into SoC designs. This manual focuses on describing these techniques. Features of the Third Edition: Up to date; State of the art; Reuse as a solution for circuit designers; A chronicle of"best practices"; All chapters updated and revised; Generic guidelines - non tool specific; Emphasis on hard IP and physical design.
SystemC langauage reference manual
IEEE Computer Society. SystemC langauage reference manual, IEEE 1666 standard, 2011.
Zynq-7000 All programmable SOC technical reference manual
  • Xilinx
Xilinx. Zynq-7000 All programmable SOC technical reference manual, 2014.