Apport de la modélisation et de la synthèse haut niveau dans la

Transcription

N
o
d'ordre : 2007TELB0029
Thèse
présentée à
l'École Nationale Supérieure de
Télécommunications de Bretagne
en habilitation conjointe avec l'Université de Bretagne Sud
pour obtenir le grade de :
Docteur de l'ENST Bretagne
Mention :
Sciences pour l’Ingénieur
par
Erwan Piriou
Apport de la modélisation et de la synthèse haut
niveau dans la conception d'architecture exible
dédiée aux turbocodes en blocs
Soutenue le 31 janvier 2007 devant la commission d'Examen :
Composition du Jury :
E. MARTIN, Professeur des Universités à l'UBS, président
E. CASSEAU, Professeur des Universités à l'ENSSAT, rapporteur
J.L. DANGER, Directeur d'études à l'ENST, rapporteur
M. JEZEQUEL, Directeur d'études à l'ENST-Bretagne, directeur de thèse
J.F. HELARD, Professeur des Universités à l'INSA de Rennes, examinateur
C. JEGO, Maître de conférence à l'ENST-Bretagne, examinateur
P. ADDE, Directeur d'études à l'ENST-Bretagne, invité
Remerciements
Ce travail de thèse a été réalisé à l’ENST-Bretagne au sein du département électronique et effectué
dans le cadre du projet régional PALMYRE.
Je tiens à exprimer, en premier lieu, toute ma reconnaissance et ma sympathie à Monsieur Michel Jézéquel, directeur d’étude et responsable scientifique du département électronique de l’ENSTBretagne, pour m’avoir accueilli au sein du département et pour avoir accepté d’être mon directeur
de thèse. Je le remercie également pour les conseils qu’il m’a prodigués.
Je tiens à remercier Monsieur Christophe Jégo, Maı̂tre de conférence à l’ENST-Bretagne, pour la
qualité de son encadrement et sa disponibilité. Ce fut un plaisir de travailler avec lui et d’échanger
différents points de vue tout au long de ces trois années. D’ailleurs, ce travail de thèse n’aurait pu
voir le jour sans son soutien exemplaire et ses conseils éclairés. J’espère que de futures collaborations
seront envisageables.
Je tiens également à remercier Monsieur Patrick Adde, directeur d’étude à l’ENST-Bretagne, pour
son aide, ses remarques pertinentes et m’avoir fait bénéficier de son expérience dans la conception de
circuit.
Je voudrais également exprimer ma gratitude à toutes les personnes qui m’ont fait l’honneur de
participer à ce jury de thèse :
– M. Emmanuel Casseau, professeur à l’École Nationale Supérieure de Sciences Appliquées et
de Technologie et M. Jean-Luc Danger, directeur d’étude à l’École Nationale Supérieure des
Télécommunications, pour l’attention qu’ils ont accordée à la lecture de ce mémoire et pour
avoir bien voulu en être les rapporteurs.
– M. Eric Martin , professeur à l’Université de Bretagne-Sud, et M. Jean-François Hélard, professeur à l’Institut National des Sciences Appliquées de Rennes, pour l’intérêt qu’ils ont porté
à ce travail en tant que membres du jury.
J’adresse mes remerciements aux collègues du département électronique de l’ENST-Bretagne avec
qui j’ai partagé de bons moments et pour l’aide qu’ils ont su m’apporter.
J’ai également une pensée émue pour Gérard et Patrice.
Merci aux camarades thésards pour l’aide précieuse qu’ils m’ont fournie chaque fois que cela était
nécessaire. Ils ont su créer une ambiance chaleureuse et amicale dans le département électronique. Je
remercie : Laura, Horacio, Raul, Javier, Jérôme, Matthieu, Makram, Irène, Daoud, Hazem, Jorge, Yi,
Emeric et les ex-membres du bureau c-223 Olivier, Camille et Charbel. Pardon à ceux que j’oublie et
qui se reconnaı̂tront.
Un grand merci à Charbel pour son amitié.
Enfin, je remercie ma famille ainsi qu’Eunice qui ont fait preuve de patience et m’ont soutenu
durant cette période.
Table des matières
Sommaire
ii
Introduction
1
1 Etat de l’Art
7
1.1
Espace de conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.1.1
Les besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.1.2
Les solutions d’intégration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
1.1.2.1
Les architectures dédiées . . . . . . . . . . . . . . . . . . . . . . . . .
9
1.1.2.2
Les processeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
1.1.2.3
Les architectures hétérogènes . . . . . . . . . . . . . . . . . . . . . . .
22
Les méthodologies de conception . . . . . . . . . . . . . . . . . . . . . . . . . .
24
1.1.3.1
Les niveaux d’abstraction . . . . . . . . . . . . . . . . . . . . . . . . .
24
1.1.3.2
La conception conjointe logicielle-matérielle . . . . . . . . . . . . . . .
27
La synthèse architecturale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
1.2.1
Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
1.2.2
Les techniques de synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
1.2.3
Les outils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
1.2.4
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
La reconfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
1.3.1
Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
1.3.2
Les architectures hétérogènes reconfigurables . . . . . . . . . . . . . . . . . . .
41
1.3.3
Les tendances dans le domaine des télécommunications
. . . . . . . . . . . . .
45
Notre positionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
1.1.3
1.2
1.3
1.4
2 Les codes correcteurs d’erreurs - Turbocodes
2.1
49
Généralités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
2.1.1
Le codage/décodage de source . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
2.1.2
Le codage/décodage de canal . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
2.1.3
Le modulation/démodulation . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
2.1.4
Le canal de transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
2.1.5
Performances d’un système de transmission : gain de codage
53
. . . . . . . . . .
iv
TABLE DES MATIÈRES
2.2
2.3
2.4
Les codes en blocs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
2.2.1
Les codes en blocs linéaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
2.2.2
Les codes cycliques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
2.2.2.1
Les codes BCH binaires . . . . . . . . . . . . . . . . . . . . . . . . . .
57
2.2.2.2
Les codes Reed-Solomon . . . . . . . . . . . . . . . . . . . . . . . . .
63
Les codes produits et le turbo décodage . . . . . . . . . . . . . . . . . . . . . . . . . .
67
2.3.1
Code produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
2.3.2
Décodage pondéré des codes produits . . . . . . . . . . . . . . . . . . . . . . .
69
2.3.3
Décodage itératif des codes produits . . . . . . . . . . . . . . . . . . . . . . . .
70
2.3.4
Performances du turbo décodage des codes produits . . . . . . . . . . . . . . .
75
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
3 Étude et implantation d’un turbocode en blocs flexible
81
3.1
Etat de l’art sur les turbo décodeurs reconfigurables . . . . . . . . . . . . . . . . . . .
81
3.2
Aspect flexiblité pour le décodeur élémentaire . . . . . . . . . . . . . . . . . . . . . . .
88
3.2.1
Etude de la complexité algorithmique . . . . . . . . . . . . . . . . . . . . . . .
88
3.2.2
Amélioration du traitement lié au processus de turbo décodage . . . . . . . . .
96
3.2.3
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
3.3
Conception du codeur flexible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
3.4
Conception du turbo décodeur flexible . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
3.4.1
3.4.2
3.5
Architecture générale du décodeur élémentaire . . . . . . . . . . . . . . . . . . 102
3.4.1.1
Partie réception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
3.4.1.2
Partie traitement
3.4.1.3
Partie émission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
3.4.1.4
Mémoire interne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
L’unité de contrôle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
3.4.2.1
la gestion de la communication entre le processeur et des périphériques : le bus système Avalon . . . . . . . . . . . . . . . . . . . . . . 113
3.4.2.2
la communication dans notre architecture . . . . . . . . . . . . . . . . 114
3.4.2.3
Evolution de la communication dans notre architecture . . . . . . . . 117
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
4 De la description algorithmique jusqu’au prototypage
4.1
4.2
121
Flot de conception expérimenté . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
4.1.1
Description du flot de conception expérimenté . . . . . . . . . . . . . . . . . . . 122
4.1.2
Modélisation d’un décodeur élémentaire générique pour le turbo décodage de
codes produits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
4.1.3
Synthèse logique d’un turbo décodeur BCH à longueur variable . . . . . . . . . 125
Synthèse logique et placement/routage de l’ensemble codeur/turbo décodeur flexible . 127
4.2.1
Synthèse logique et placement/routage des différents blocs du codeur . . . . . . 127
4.2.2
Synthèse logique et placement/routage des différents blocs du décodeur élémentaire flexible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
4.2.3
Synthèse logique et placement/routage du turbo décodeur flexible . . . . . . . 130
TABLE DES MATIÈRES
4.3
Synthèse architecturale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
4.3.1
Les opérations dans le corps de Galois . . . . . . . . . . . . . . . . . . . . . . . 132
4.3.2
Exploration des solutions architecturales . . . . . . . . . . . . . . . . . . . . . . 133
4.3.3
4.4
4.5
v
4.3.2.1
Les blocs de la partie réception . . . . . . . . . . . . . . . . . . . . . . 135
4.3.2.2
Les blocs de la partie de traitement . . . . . . . . . . . . . . . . . . . 139
4.3.2.3
Les blocs de la partie émission . . . . . . . . . . . . . . . . . . . . . . 141
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Prototypage du turbo décodeur flexible
. . . . . . . . . . . . . . . . . . . . . . . . . . 143
4.4.1
Les différentes étapes aboutissant au prototypage . . . . . . . . . . . . . . . . . 144
4.4.2
La plate-forme de validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
4.4.3
Les caractéristiques du prototype . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
5 Conclusion et perspectives
149
c
A Le langage SystemC 153
B La plate-forme Palmyre
157
Glossaire
159
Liste des figures
. . . . . . . . . . . . . . . . . . . . . . . . . . .
2
. . . . . . . . . . . . . . . . . . . . . . . . . .
2
3
Les différentes normes en fonction du débit et de la distance de fonctionnement . . . .
3
1.1
Les solutions d’intégration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
1.2
Bloc diagramme d’un FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
1.3
Architecture ı̂lots de calcul pour un FPGA . . . . . . . . . . . . . . . . . . . . . . . .
13
1.4
Architecture hiérarchique pour un FPGA . . . . . . . . . . . . . . . . . . . . . . . . .
13
1.5
Elément configurable des FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
1.6
Bloc diagramme d’un CLB de Virtex 5
. . . . . . . . . . . . . . . . . . . . . . . . . .
16
1.7
Slice d’un Virtex 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
1.8
Caractéristiques des composants Stratix . . . . . . . . . . . . . . . . . . . . . . . . . .
17
1.9
Structure en LAB du Stratix II
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
1.10 Bloc diagramme d’un ALM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
1.11 Architecture Von Neumann . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
1.12 Architecture Harvard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
1.13 Pipeline d’instructions d’un processeur RISC sur 5 niveaux . . . . . . . . . . . . . . .
20
1.14 Pipeline d’un DSP VLIW à 5 étages . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
1.15 Pipeline d’un DSP superscalaire à 5 étages
. . . . . . . . . . . . . . . . . . . . . . . .
22
1.16 SoC : une structure hétérogène . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
1.17 SoC sur une cible ASIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
1.18 SoPC sur un circuit FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
1.19 Flot de conception ASIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
1.20 Les étapes constituant le flot de codesign . . . . . . . . . . . . . . . . . . . . . . . . .
28
1.21 Différentes étapes constituant la synthèse de haut-niveau . . . . . . . . . . . . . . . . .
32
1.22 Positionnement des solutions d’intégration les unes par rapport aux autres selon différents critères . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
1.23 L’architecture DART
42
1
Le « Cell » de Sony, IBM et Toshiba
2
Situation des fonctions sur la puce Cell
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.24 Structure d’un cluster de l’architecture DART
. . . . . . . . . . . . . . . . . . . . . .
42
1.25 L’architecture MorphoSys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
1.26 Structure d’une Reconfigurable Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
1.27 L’architecture Systolic Ring
44
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
viii
LISTE DES FIGURES
1.28 Structure d’un Dnode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
2.1
Modélisation d’une chaı̂ne de transmission numérique
. . . . . . . . . . . . . . . . . .
50
2.2
Graphe de transition du canal binaire symétrique . . . . . . . . . . . . . . . . . . . . .
52
2.3
Peb en fonction du SNR pour un code Golay (23,12) avec décision ferme pour une
modulation de type BPSK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
2.4
Représentation d’un mot de code pour un code systématique . . . . . . . . . . . . . .
55
2.5
Constitution de la matrice associée à un code produit . . . . . . . . . . . . . . . . . .
68
2.6
Illustration du décodage de Chase . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
2.7
Principe du décodage de la matrice Rp à la p-ième itération
. . . . . . . . . . . . . .
74
2.8
Performances des TCB-BCH (t=1) pour une modulation BPSK sur un canal BBAG .
76
2.9
Performances des TCB-BCH (t=2) pour une modulation BPSK sur un canal BBAG .
76
2.10 Performances des TCB-RS (t=1, t=2) pour une modulation BPSK sur un canal BBAG 77
2.11 Performances du turbo décodage de codes produits . . . . . . . . . . . . . . . . . . . .
78
3.1
Le treillis et les métriques associées . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
3.2
L’architecture de Virturbo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
3.3
Architecture du décodeur implantant l’ASOVA . . . . . . . . . . . . . . . . . . . . . .
87
3.4
Gestion des différentes configurations envisagées
. . . . . . . . . . . . . . . . . . . . .
96
3.5
Aspect itératif du processus de turbo décodage . . . . . . . . . . . . . . . . . . . . . .
97
3.6
TEB en fonction du rapport signal à bruit pour différentes itérations . . . . . . . . . .
99
3.7
Bloc diagramme du codeur dédié aux codes produits . . . . . . . . . . . . . . . . . . . 100
3.8
Schéma du codeur élémentaire
3.9
Schéma-bloc du décodeur élémentaire RS/BCH
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
. . . . . . . . . . . . . . . . . . . . . 103
3.10 Structure temporelle pour le décodage de mot de code de 32 symboles . . . . . . . . . 104
3.11 Bloc de calcul du syndrome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
3.12 Bloc élémentaire du syndrome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
3.13 Schéma du bloc des symboles les moins fiables . . . . . . . . . . . . . . . . . . . . . . . 106
3.14 Schéma du bloc de construction des vecteurs de test . . . . . . . . . . . . . . . . . . . 107
3.15 Décodeur algébrique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
3.16 Schéma du bloc de calcul des métriques . . . . . . . . . . . . . . . . . . . . . . . . . . 109
3.17 Schéma du bloc de calcul de l’information extrinsèque . . . . . . . . . . . . . . . . . . 111
3.18 Schéma du bloc de calcul du nouveau R” . . . . . . . . . . . . . . . . . . . . . . . . . . 112
3.19 Schéma bloc de la mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
3.20 Fonctionnement des mémoires RAM au cours du temps . . . . . . . . . . . . . . . . . 113
3.21 Architecture hétérogène retenue pour l’implantation . . . . . . . . . . . . . . . . . . . 115
3.22 Algorithme du programme exécuté sur le processeur NIOS
. . . . . . . . . . . . . . . 116
3.23 Utilisation des mémoires lors du décodage itératif . . . . . . . . . . . . . . . . . . . . . 117
3.24 Architecture de l’application intégrant des DMA . . . . . . . . . . . . . . . . . . . . . 118
4.1
Le flot de conception expérimenté . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
4.2
Modélisation de la chaı̂ne de communications numériques sous System Studio . . . . . 124
LISTE DES FIGURES
ix
4.3
Modélisation du turbo décodeur sous System Studio . . . . . . . . . . . . . . . . . . . 125
4.4
Schéma-bloc du décodeur élémentaire RS/BCH
4.5
Schéma de l’architecture du turbo décodeur flexible
4.6
Modèle architectural ciblé par l’outil GAUT . . . . . . . . . . . . . . . . . . . . . . . . 134
4.7
Graphe flot de données
4.8
Architecture générée sans pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Architecture (a)
. . . . . . . . . . . . . . . . . . . . . 128
. . . . . . . . . . . . . . . . . . . 130
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Architecture (b) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
4.9
Graphe flot de données obtenu avec GAUT pour les solutions architecturales (a) et (b) 137
4.10 Les différentes étapes aboutissant au prototypage . . . . . . . . . . . . . . . . . . . . . 144
4.11 La carte de développement NIOS II Development Kit . . . . . . . . . . . . . . . . . . 145
4.12 Les phases de fonctionnement du prototype . . . . . . . . . . . . . . . . . . . . . . . . 146
A.1 Architecture hiérarchique d’un module décrit en langage SystemC . . . . . . . . . . . 155
Liste des tableaux
1.1
Les caractéristiques des différentes techniques de programmation . . . . . . . . . . . .
12
1.2
Comparatif des caractéristiques des processeurs NIOS II et Microblaze
. . . . . . . .
21
1.3
Comparatif des caractéristiques des outils de synthèse architecturale . . . . . . . . . .
37
2.1
Récapitulatif des caractéristiques des différents codes produits considérés
. . . . . . .
77
2.2
Limite de Shannon et gain asymptotique des différents codes produits considérés . . .
79
3.1
Récapitulatif des implantations existantes de turbo décodeurs flexibles . . . . . . . . .
87
3.2
Complexité en nombre d’opérations de l’algorithme de Berlekamp-Massey . . . . . . .
90
3.3
Opérations effectuées par l’algorithme PGZ . . . . . . . . . . . . . . . . . . . . . . . .
91
3.4
Récapitulatif de la complexité des différentes parties constituant le décodage élémentaire
pour des codes BCH/RS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
3.5
Coefficients des polynômes générateurs g(x) des codes traités . . . . . . . . . . . . . . 101
3.6
Les motifs d’erreurs considérés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
4.1
Complexité en nombre de portes logiques du décodeur élémentaire pour différentes
longueurs de code N . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
4.2
Caractéristiques de chaque codeur correspondant à chacune des configurations considérées127
4.3
Surface occupée par les blocs de la partie réception du décodeur élémentaire . . . . . . 129
4.4
Surface occupée par les blocs de la partie traitement du décodeur élémentaire . . . . . 129
4.5
Surface occupée par les blocs de la partie émission du décodeur élémentaire . . . . . . 129
4.6
Occupation de la mémoire interne du décodeur élémentaire en nombre d’éléments logiques (LE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
4.7
Résultats de la synthèse logique du processeur NIOS II . . . . . . . . . . . . . . . . . . 131
4.8
Caractéristiques des opérateurs obtenus après synthèse logique sous Quartus II en ciblant un Stratix 1s40 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
4.9
Résultats de la synthèse architecturale pour le bloc de parité avec l’outil GAUT . . . . 136
4.10 Résultats de la synthèse architecturale pour le bloc de parité avec l’outil Agility Compiler136
4.11 Résultats de la synthèse architecturale pour le bloc syndrome avec l’outil GAUT . . . 138
4.12 Résultats de la synthèse architecturale pour le syndrome (sol.(a)) avec l’outil Agility
Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
4.13 Résultats de la synthèse architecturale pour le syndrome (sol.(b)) avec l’outil Agility
Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
xii
LISTE DES TABLEAUX
4.14 Résultats de la synthèse architecturale pour le bloc des moins fiables avec l’outil Agility
Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
4.15 Résultats de la synthèse architecturale pour le bloc PGZ avec l’outil GAUT . . . . . . 140
4.16 Résultats de la synthèse architecturale pour le bloc de correction avec l’outil GAUT . 141
4.17 Résultats de synthèse architecturale pour le bloc de calcul de l’information extrinsèque
et d’élaboration du mot corrigé avec l’outil GAUT . . . . . . . . . . . . . . . . . . . . 142
4.18 Résultats de synthèse architecturale pour le bloc de calcul de l’information extrinsèque
avec l’outil Agility Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
A.1 Les caractéristiques des différents processus du langage SystemC . . . . . . . . . . . . 154
A.2 Les caractéristiques des différents types de données du langage SystemC
. . . . . . . 155
Introduction
Contexte
L’électronique est relativement jeune par rapport à d’autres disciplines comme l’astronomie par
exemple. En effet, elle est âgée seulement d’un siècle. Un léger retour sur son histoire permet de mieux
comprendre l’engouement que suscite aujourd’hui son utilisation dans tous les domaines d’application. A partir du début du XXème siècle, l’électricité fait son apparition dans les habitations urbaines
laissant le champ libre au développement de biens utilisant l’électronique. Ainsi, l’invention du premier composant électronique intervient en 1904, il s’agit du tube à diode de Fleming qui permet le
redressement du courant alternatif. Il faut toutefois attendre une quarantaine d’années et beaucoup
d’innovations techniques pour que les transistors (plus exactement les semi-conducteurs) soient utilisés.
Ils sont moins coûteux, plus fiables et plus facile à mettre en oeuvre. Dès lors, l’électronique envahit
les appareils de consommation grand public (radio, télévision, ordinateurs personnels). Elle change de
nom en devenant la microélectronique, du fait de l’utilisation de technologies microniques. En effet,
la miniaturisation et les progrès constants dans l’intégration sur silicium permettent aux systèmes
électroniques d’intégrer sur une même puce des applications de plus en plus complexes. Aujourd’hui,
par exemple, la console de jeux PS3 de Sony est construite autour d’une puce dédiée (fig. 1) contenant
pas moins de 234 millions de transistors pour une surface de 221 mm2 gravé avec une technologie en 90
nm. Il s’agit d’une architecture multiprocesseur intégrant de nombreuses fonctionnalités et favorisant
le parallélisme pour les calculs intensifs (fig. 2).
Cependant, la mise au point de ces systèmes complexes impose des contraintes à la fois d’ordre
techniques mais aussi d’ordre économiques. En effet, le temps s’écoulant entre le début de la conception
et la mise sur le marché doit être réduit au maximum (le fameux « time to market »). Réduire le
temps de développement d’un projet devient crucial. Ainsi, de nombreuses sociétés envisagent une
élévation du niveau d’abstraction lors de la conception et proposent des méthodologies et des outils de
conception, de simulation et de validation de plus en plus performants. En parallèle, de nombreuses
2
INTRODUCTION
Figure 1 — Le « Cell » de Sony, IBM et Toshiba
Figure 2 — Situation des fonctions sur la puce Cell
plate-formes de prototypage sont également proposées pour effectuer les validations après implantation
avant la longue et coûteuse étape d’intégration sur puce.
D’autre part, le monde des télécommunications est en perpétuelle évolution. Au fur et à mesure
des avancées technologiques, les besoins en terme de performances sont devenus de plus en plus élevés. Ainsi, les normes (ou les standards en anglais) se multiplient et se déclinent. Elles intègrent des
algorithmes de plus en plus complexes tout en conservant des parties de traitement identiques. Par
exemple, dans le domaine des communications sans fils, les normes sont classées suivant leur débit et
le degré de mobilité des terminaux associés comme le montre la figure 3. Les tendances en terme de
normalisation concernent surtout les réseaux de télécommunication 3GPP et les réseaux IP. D’ailleurs,
les normes pour chacun de ces réseaux sont en concurrence pour des distances et des débits donnés.
Le cas de l’UMTS et du WiMAX en est le parfait exemple. De plus, la tendance est à la mobilité et à
l’augmentation des débits de fonctionnement (liaison montante et descendante). De même, les notions
d’interactivité et d’inter-communication deviennent primordiales. C’est donc dans cette optique que
l’inter-opérabilité des terminaux mobiles prend tout son sens. Concrètement, cette évolution correspond à la capacité d’exécuter des applications utilisant des normes différentes sur un même terminal.
En effet, elle devient particulièrement intéressante pour assurer l’échange de données entre différents
appareils ou pour adapter la communication en fonction des conditions extérieures.
INTRODUCTION
3
distance
10 km
W
I
M
GPRS
W-CDMA HSDPA A
EDGE
X
UMTS
GSM
1 km
100 m
DECT
Bluetooth
WiFi
WiFi
MIMO
WUSB
10 m
10 kbit/s.
500 kbit/s.
2 Mb/s.
100 Mb/s.
débit
Figure 3 — Les différentes normes en fonction du débit et de la distance de fonctionnement
Objectifs
La rapide évolution des technologies CMOS vers le submicronique, puis vers le submicronique
profond, offre des perspectives d’intégration toujours plus importantes. Il est désormais possible d’intégrer un système complexe dans un circuit intégré SoC (System on Chip) voire même dans un circuit
reconfigurable SoPC (System on a Programmable Chip). Parallèlement, la diversité et la complexité
des applications de communications numériques, sous contrainte d’exécution temps réel et dédiées à
des systèmes embarqués, ne cessent de croı̂tre avec l’évolution du marché des télécommunications.
L’évolution constante des caractéristiques de ces applications implique la définition d’architectures
systèmes devant s’adapter dynamiquement aux nouvelles fonctionnalités (standards, services...). C’est
pourquoi, de nouvelles méthodologies reposant à la fois sur l’élévation du niveau d’abstraction à travers la synthèse d’architecture et le développement de composants virtuels génériques (IPs de niveau
comportemental) sont mises en oeuvre. Ainsi, le développement de langages de description système
tel que SystemC permettent une transition plus naturelle entre l’étude algorithmique d’un système
et la définition de l’architecture associée. En effet, le flot de conception traditionnel est discontinu
pour une implémentation matérielle. Cette discontinuité implique la réécriture de l’application validée
au niveau algorithmique dans un langage de description matériel (VHDL, Verilog). Actuellement, les
fournisseurs de CAO mettent en place des flots de conception reposant sur ces langages de description
système. Par exemple, Synopsys a proposé dès 2002 à la fois un environnement de conception système System Studio et un outil de synthèse de haut niveau SystemC Compiler qui utilisent le langage
SystemC.
La définition de nouveaux algorithmes et la recherche d’architectures originales pour les applications de communications numériques dans les domaines du codage canal (turbocodes) et des traite-
4
INTRODUCTION
ments itératifs dans les récepteurs (turbo communications) représentent la plus grande part de l’activité
de recherche du département électronique de l’ENST-Bretagne. Ainsi, des architectures originales de
circuits spécifiques (ASIC/FPGA) ont été obtenues pour les turbocodes. Cependant, les études ont été
menées au niveau RTL (Register Transfer Level) qui est généralement le niveau de modélisation dans la
conception de circuit. Or, à ce niveau de description, les possibilités (généricité, souplesse d’utilisation
et espace des solutions) sont bien moins importantes qu’au niveau comportemental. Dans ce contexte,
l’étude menée dans le cadre de cette thèse consiste à expérimenter l’apport de la modélisation et de
la conception de haut niveau pour la définition d’architectures flexibles dédiées au turbo décodage
de codes produits. L’objectif principal de cette thèse devient alors le développement d’architectures
flexibles originales favorisant l’intégration de systèmes dits turbo sur une même puce.
Plan du mémoire
Ce manuscrit se compose de quatre chapitres.
Le premier chapitre aborde les domaines nécessaires à la bonne compréhension des travaux effectués dans le cadre de cette thèse. Ainsi, il dresse un état de l’art :
– de l’espace de conception (les besoins des concepteurs, les solutions d’intégration et les méthodologies de conception associées).
– de la synthèse architecturale.
– des systèmes dits « reconfigurables ».
Puis, un paragraphe récapitulatif situe notre positionnement par rapport à ces trois domaines.
Le deuxième chapitre présente le domaine de l’application retenue dans le cadre de ce travail à
savoir les codes correcteurs d’erreurs. Dans un premier temps, quelques généralités sur les communications numériques sont données. Dans un deuxième temps, les codes en blocs sont décrits. Cette partie
se focalise sur le codage et le décodage des codes BCH et Reed Solomon qui servent de base aux codes
produits. Enfin, la construction des codes produits et l’adaptation du décodage pour des processus de
type « turbo » sont explicitées. Des courbes de performances sont également données.
L’étude et l’implantation d’un turbocode en blocs flexible sont détaillées dans le chapitre trois. Un
état de l’art sur les turbo décodeurs reconfigurables est présenté. Puis, le caractère flexible de notre
architecture est explicité à travers une étude de complexité et une étude sur les caractéristiques de
l’application. Par la suite, l’implémentation d’une structure capable de coder et décoder des turbocodes
produits est détaillée. Dans notre cas, les architectures flexibles du codeur et de la structure de turbo
décodage permettent de considérer à la fois des codes BCH de longueur n = 32 et des codes RS
de longueur n = 31 pour des pouvoirs de correction t = 1 et t = 2. Enfin, le fonctionnement de
l’architecture hétérogène du décodeur est donné.
Le quatrième chapitre présente le flot de conception expérimenté et les différents résultats de
INTRODUCTION
5
synthèse obtenus. Dans un premier temps, une modélisation d’une structure de décodage générique
a été réalisée dans l’environnement System Studio. Ensuite, les résultats des synthèses logiques et le
placement/routage sur les éléments déjà considérés sont présentés. Puis, une exploration de l’espace de
conception a été effectuée grâce à des synthèses architecturales sur différents modules. La description
du prototypage est abordée à travers la présentation de la plate-forme (NIOS II Stratix development
Kit) et du processus de mise en oeuvre.
Enfin, le dernier chapitre conclut le manuscrit en récapitulant les apports et les limites de nos
expérimentations. Des perspectives sont également données pour la poursuite de ces travaux de recherche.
CHAPITRE
1
Etat de l’Art
Depuis la mise sur la marché du premier ASIC, il y a seulement 50 ans, la complexité des circuits intégrés n’a pas cessé de croı̂tre. L’intégration progressive des composants électroniques dans
les appareils de consommation grand public a permis le développement de solutions architecturales de
plus en plus souples et performantes. Les méthodologies de conception et les outils ont évolué dans le
même sens permettant progressivement de s’abstraire de la couche purement physique et d’atteindre
des niveaux de développement plus élevés. Ainsi, des structures hétérogènes sont apparues combinant
à la fois éléments logiciels et matériels. Parallèlement à ces considérations, les applications de traitement du signal et de l’image (TDSI) mais aussi les systèmes de communication s’appuient sur des
algorithmes en perpétuelle évolution. Afin de préserver, la compatibilité descendante et par conséquent
la bonne marche des standards de télécommunications (UMTS, GPRS, EDGE ), une faculté d’adaptation de tous les terminaux est impérative. De plus, des contraintes en terme de qualité de service,
de consommation et de débit nécessitent désormais un caractère reconfigurable des systèmes.
1.1
Espace de conception
L’espace de conception en électronique concerne l’ensemble des architectures qui peuvent être
théoriquement construites. Cet espace est défini par les technologies disponibles pour concevoir un
circuit et limité par l’imagination des concepteurs. L’espace de conception est, a priori, vaste mais les
contraintes techniques et les limites des méthodologies et des outils restreignent le champ d’exploration des concepteurs. Actuellement, les conditions semblent réunies pour favoriser le développement
de nouvelles méthodologies et l’élévation du niveau d’abstraction.
1.1.1
Les besoins
Sur le plan matériel, le concepteur doit pouvoir estimer les contraintes liées au choix d’un cahier des
charges (type de cible, temps de réponse, vitesse, surface, consommation...). Sur le plan logiciel, il doit
être à même d’estimer l’impact du développement algorithmique sur son application (E/S, échange de
8
CHAPITRE 1. ETAT DE L’ART
données, gestion des ressources). Du fait de la multiplicité et des particularités propres à chacune des
solutions architecturales, l’exploration de l’ensemble des architectures hétérogènes devient de plus en
plus ardue pour le concepteur. Parallèlement, les contraintes du marché (Time to market) réduisent
le temps accordé au concepteur pour la fabrication de nouveaux circuits. En effet, le renouvellement
des gammes impose un temps de développement des produits de plus en plus court. De plus, la
multiplication des standards impose aux systèmes de supporter l’ensemble des normes déjà existantes
(GSM, UMTS, EDGE, ...) d’autant plus que nous entrons dans l’ère du « tout communicant » dans
un monde sans fils.
L’ensemble de ces facteurs, a priori inconciliables, entraı̂ne la nécessité de développer des méthodologies
et des outils associés mêlant aspects logiciels et matériels et fournissant des estimations en terme de
performances et de complexité aussi précises que possible. L’intégration de telles solutions hétérogènes
implique donc l’utilisation d’outils permettant la conception conjointe logicielle-matérielle que nous
appelons aussi codesign.
1.1.2
Les solutions d’intégration
Au moment de la conception d’un circuit électronique, un ingénieur de développement doit
effectuer des choix sur le ou les types de composants, leurs interactions éventuelles et leur mode de
fonctionnement. Parfois, le cahier des charges impose d’emblée la solution à envisager mais le plus
souvent une exploration de l’espace de conception permet de situer les goulots d’étranglements des
applications. Dans un souci de précision et de cohérence pour la suite, il convient de définir tout
d’abord certaines notions qui seront employées dans la suite du document :
Architecture « n. f. Art de construire, de disposer et d’orner les édifices. Il désigne aussi la
disposition et l’ordonnance d’un bâtiment. »[dic]
En se référant à la définition littérale d’une architecture, il est possible de la transposer aisément au
domaine de la conception de circuit électronique. Une architecture décrit la disposition des composants
sur le circuit de manière topologique.
Structure « n. f. Manière dont un édifice est bâti. Il se dit figurément de la disposition des parties
d’un tout, constituant une sorte d’architecture, de construction. »
Ce terme est souvent employé pour désigner une architecture et intégrera, dans notre cas, la notion
d’échange de données.
Cible : Par abus de langage, ce terme désigne le(s) type(s) de composant(s) choisi(s) par le
concepteur pour implanter son application. Également appelée cible architecturale, elle peut donc être
par définition homogène (un seul composant) ou hétérogène (plusieurs composants).
La figure 1.1 établit un panorama des cibles se présentant au concepteur. Elles ont toutes des
1.1. ESPACE DE CONCEPTION
9
particularités qu’il convient d’expliciter pour explorer l’espace de conception. Ce document s’attarde
néanmoins plus largement sur les composants de types microprocesseurs et les circuits logiques reconfigurables de type FPGA puisqu’ils ont été utilisés pour l’implantation réalisée dans le cadre de
cette étude. De haut en bas, la figure donne une dénomination générale des familles pour aller vers
les différents composants qui les constituent. De gauche à droite, les solutions vont des approches les
plus flexibles aux plus figées.
Circuits logiques
programmables
Microprocesseur
DSP
Processeurs
généralistes
RISC
ASIC
Semi Custom
Microcontroleur
Custom
Circuits
pré diffusés
Processeurs
multimedia
VLIW
Circuits sur
Circuits
mesure
pré caractérisés
FPGA
CPLD
PAL
Figure 1.1 — Les solutions d’intégration
1.1.2.1
Les architectures dédiées
Les ASIC (Application Specific Integrated Circuit en anglais) et les circuits logiques programmables (ou FPGA pour Field-Programmable Gate Array) peuvent être regroupés sous le vocable
d’architectures dédiées. Par définition, un ASIC est un circuit intégré spécifique à une application.
Autrement dit, il s’agit d’une puce conçue sur mesure pour une application spécifique contrairement
à un microprocesseur pouvant exécuter tous les types d’applications. Un composant logique programmable désigne, quant à lui, un circuit intégré logique qui peut être programmé après sa fabrication.
En raison du coût élevé de la conception d’une solution de type ASIC, les FPGA servaient dans
un premier temps à valider les applications conçues pour une telle cible. Le prototypage était donc
effectué à moindre frais. Depuis quelques années, les circuits programmables de type FPGA ont
fortement évolué et proposent une alternative entre l’ASIC et le microprocesseur.
L’utilisation d’un ASIC améliore de façon importante les performances par rapport aux autres
types de cible puisque la description des applications ASIC est « câblée » (reliée de manière physique)
plutôt que programmée. Historiquement, la complexité est caractérisée par le nombre de transistors
10
ou de portes logiques intégrés sur le composant. Classiquement, la porte logique est une porte « non
ET » à deux entrées constituée à partir de quatre transistors. Bien entendu, la contre-partie d’une
telle efficacité réside dans la conception scrupuleuse du circuit et le passage en fonderie qui sont des
étapes longues et coûteuses pour les cibles les plus personnalisées. Les ASIC peuvent être classés en
plusieurs catégories en fonction du degré de personnalisation disponible pour le concepteur.
Tout d’abord, le concepteur d’un circuit « sur-mesure » « ou ciselé » (full-custom en anglais) décrit
le placement de chaque transistor avec un degré de liberté total en regard de la technologie utilisée (tous
les masques sont dédiés au client). Le circuit résultant est performant en terme de surface et de vitesse
mais pas en temps de développement. De plus, une erreur de conception entraı̂ne une modification
pouvant aller dans le pire des cas à la modification de l’intégralité du circuit, ce qui rend la correction
longue et coûteuse et les modifications ultérieures impossibles sans la fonte d’une nouvelle puce. La
validation nécessitent des simulations analogiques. De plus, il est à noter que l’utilisation de kits de
conception récents peut poser problème puisque les modèles dont disposent les fondeurs ne sont pas
forcément précis dans certaines régions de fonctionnement. Ainsi, il est parfois nécessaire de fondre
plusieurs circuits avant d’avoir le résultat souhaité [PCLSJ06].
Apparus dans les années 80, les ASIC pré-caractérisés (Standard Cell) se présentent comme un
intermédiaire, en terme de coût, entre le circuit sur mesure et le pré-diffusé. Le fondeur propose une
bibliothèque de modules évolués (CPU, RAM, ...) et optimisés en surface dans laquelle le concepteur
va puiser pour réaliser son système et y rajouter les interconnexions. Il s’agit du placement puis du
routage des modules. Du fait de l’utilisation de modules optimisés, ce type d’ASIC se rapproche du
circuit sur mesure tout en nécessitant un temps de développement moindre.
La dénomination « semi-custom » est associée aux circuits pré-diffusés dont seule la partie interconnexions du circuit est personnalisable par le client. Il existe deux types de circuits :
– Gate-Array (MPGA) : il s’agit en fait de matrice de portes avec des plots d’ E/S. Des colonnes
de portes alternent avec des canaux de routage. Un ou plusieurs niveaux d’interconnexion permettent de dédier le circuit à l’application.
– Sea of Gates (Mer de portes) : le circuit est composé de blocs contigus de transistors. Les
connexions passent par dessus les blocs.
Il est possible d’utiliser des bibliothèques de modules pour ce type de circuit. Les transistors ont une
taille fixe et une position donnée. Par conséquent, le routage est déjà plus ou moins contraint. Les
circuits pré-diffusés sont destinés aux circuits de faible ou moyenne complexité et aux petites séries. Le
temps de développement est moins important que pour l’ASIC sur mesure puisque le circuit pré-diffusé
est disponible d’emblée.
Actuellement, la tendance est aux ASIC structurés [WT04] qui semblent être une technique prometteuse. Auparavant, pour concevoir un circuit performant, les ingénieurs avaient le choix entre :
11
– les ASIC pré-caractérisés avec un prix unitaire faible pour de grands volumes mais un développement long et coûteux.
– les FPGA (voir section suivante) avec un temps de développement rapide mais des prix
unitaires élevés. Toutefois, les coûts induits par l’adaptation de l’usine afin de produire l’ASIC
élaboré sont faibles, il s’agit des coûts dits « NRE » (Non-Recurring Engineering).
L’idée est de conserver les performances et la réduction des coûts des circuits pré-caractérisés tout en
faisant baisser le coût des charges NRE et le temps de développement. Un circuit structuré intègre
des modules prédéfinis mais plus élaborés qu’auparavant. Typiquement, on trouve des bascules,
des registres, des inverseurs, des DLL... La différence avec une implantation sur FPGA réside dans
le fait que le concepteur choisit lui-même les interconnexions à établir dans les couches de métal
restantes. Les fabricants de FPGA proposent également leurs propres ASIC structurés qui permettent
la validation sur FPGA avant l’envoi du circuit en fonderie[Sem05][eAS05][ele05]. Ainsi, chez Altera,
le famille Hardcopy II propose deux couches de métal personnalisable pour une technologie 90 nm et
des fréquences de fonctionnement allant jusqu’à 350 Mhz [Alt05].
L’apparition des ASIC structurés est à mettre en relation avec l’évolution importante des circuits
logiques programmables. Les FPGA de nouvelle génération proposent en effet de nouveaux modules (arithmétiques, de mémorisation...) qui poussent les concepteurs à utiliser ce type de composant.
Dans la classification proposée précédemment (fig. 1.1), la famille des circuits logiques programmables se subdivise en trois sous catégories allant, par ordre de complexité croissante, du PAL au
FPGA en passant par le CPLD. Les circuits logiques programmables diffèrent de la technique de type
ASIC par plusieurs aspects. En effet, ils sont directement disponibles chez le fournisseur, la programmation et le développement d’application sont rapides et enfin il n’est pas nécessaire de fondre un
circuit. Ces composants sont donc idéaux pour le prototypage des applications.
Les circuits logiques programmables de type PAL se composent d’un ensemble d’opérateurs « ET »
sur lesquels sont connectées les entrées ou leur complément, d’un ensemble d’opérateurs « OU » sur
lesquels sont connectées les sorties des opérateurs « ET » et d’éléments de sortie (registre 3 états,
inverseurs...). Au total, ce type de composant compte 100 à 200 portes. Les interconnexions entre les
différents éléments sont programmables.
Les CPLD bénéficient des fortes densité d’intégration. Ainsi, leurs structures intègrent des cellules
(« macrocells ») interconnectées entre elles par des ressources de routage. Les E/S sont limitées pour
avoir une consommation plus faible.
La dénomination des sous-familles peut être fonction de la complexité, mais il est également possible de classer ces cibles selon les techniques de programmation. Le tableau 1.1 illustre les différentes
12
caractéristiques de chaque solution :
– les cellules à fusible ou antifusible (fonction ET câblée). Des fusibles (technologie bipôlaire) ou
antifusibles (technologie CMOS ) permettent de fixer les interconnexions du composant.
– les mémoires effaçables électriquement (EEPROM et Flash EPROM). Reprogrammables à volonté, certains FPGA peuvent également être reprogrammés en cours de fonctionnement.
– les mémoires SRAM. La configuration des ressources du FPGA est contenu dans des mémoires
statiques de type RAM. Ils sont reprogrammables à volonté et en cours de fonctionnement.
hhh
hhh
Technique
hhhh de prog. Antifusible EPROM
hhhh
Caract.
h
Famille de circuits
FPGA
PAL CPLD
Facilité de programmation
faible
très élevé
Densité d’intégration induite
faible
élevée
Reprogrammable
non
oui
SRAM
CPLD FPGA
élevé
très élevée
oui
Tableau 1.1 — Les caractéristiques des différentes techniques de programmation
Les solutions de type PAL et CPLD deviennent rapidement limitées pour l’implantation d’applications complexes, au contraire des FPGA actuels qui intègrent des dizaines de millions de portes.
Conçus pour vérifier le bon comportement des applications destinées à l’intégration sur ASIC, le
rôle des FPGA a depuis beaucoup évolué. Ceux basés sur une technologie SRAM deviennent même
reprogrammables à volonté.
De manière générale, un circuit programmable de type FPGA se compose de blocs logiques reliés
entre eux via un réseau d’interconnexion (fig 1.2). Il est dit reconfigurable si les ressources d’interconnexion le sont.
Figure 1.2 — Bloc diagramme d’un FPGA
13
Un FPGA se caractérise par son réseau de routage, la topologie de ce dernier est représentative
du type d’architecture employée. Ainsi, l’architecture de type « ı̂lots de calcul » regroupe les différents
éléments fonctionnels sous la forme d’une matrice (fig. 1.3). Les éléments configurables contiennent
des E/S, des modules logiques (LUT, multiplexeur...), des mémoires (RAM simple ou double port) et
depuis peu des modules arithmétiques plus complexes (Multiplieur, additionneur/soustracteur...). Des
blocs programmables assurent la connexion entre les éléments configurables tandis que les matrices
relient ces blocs entre eux. Cette approche en ı̂lots se retrouve notamment chez les fabricants Atmel et
Xilinx. Il existe également une architecture dite hiérarchique (Altera). A chaque niveau de hiérarchie
correspond des ressources de routage et des éléments associés (fig. 1.4).
Figure 1.3 — Architecture ı̂lots de calcul pour un FPGA
Figure 1.4 — Architecture hiérarchique pour un FPGA
14
Basée sur une unité logique configurable (fig. 1.5), un FPGA (utilisant la technologie SRAM) est
une matrice composée d’un grand nombre d’éléments configurables qui interagissent via des ressources
de routage également reconfigurables. Ce bloc élémentaire se compose de LUT (2 à 4), d’une chaı̂ne
de propagation de la retenue et de bascules D. Un LUT est en fait une table de scrutation qui décrit
la fonction à réaliser, il s’agit d’un arbre de transistor connecté à des points mémoires SRAM et
commandé par des entrées binaires.
Figure 1.5 — Elément configurable des FPGA
La flexibilité des ressources de routage d’un FPGA est la fois son point fort et son point faible.
Capable de recevoir toutes les applications, le réseau doit être optimisé pour acheminer les signaux. Un
ensemble de lignes de routage de différentes longueurs est disponible. Elles sont disposées verticalement
et horizontalement sur la matrice. En ce qui concerne les mémoires, elles peuvent être distribuées sur
les LUT du composant. Devant les besoins croissants en terme de mémoire, des éléments de mémorisation dédiés ont rapidement trouvé leur place sur le FPGA. Ces blocs configurables peuvent recevoir
des données de différentes largeurs et sont agencés au mieux afin de rendre disponibles les informations aux éléments logiques. Les temps d’accès sont diminués par rapport à un accès à des mémoires
externes. Dans tous les systèmes électroniques, les horloges sont capitales pour le bon fonctionnement
de l’ensemble. Les FPGAs sont prévus pour recevoir une ou plusieurs horloges. Des entrées sont dédiées à ce type de signaux, ainsi que des ressources de routage adaptées au transport d’horloges sur
de longues distances (bufferisation des lignes). Aussi, la synchronisation des horloges sur le circuit est
assurée à travers des mécanismes d’asservissement (des PLLs ou des DLLs) qui permettent de créer
des horloges à des fréquences multiples de celle de référence.
Les ressources d’E/S permettent au FPGA de communiquer avec les autres composants d’un circuit électronique. Différentes normes électriques (LVTTL, LVCMOS, SSTL...) sont supportées pour
assurer une compatibilité maximale avec l’environnement. Des E/S de type différentielles permettent
15
également d’obtenir une bande passante élevée entre deux points de communication (LVDS, Hypertransport...).
Depuis le début des années 2000, l’adjonction de fonctions pré-câblées et d’unités arithmétiques
rend le FPGA très attractif et le place même comme une alternative sérieuse au processeur de traitement de signal. En effet, en plus des mémoires embarquées, des multiplieurs/accumulateurs câblés
(MAC) et des additionneurs/soustracteurs sont répartis entre des rangées de blocs logiques configurable. Des sociétés comme Lattice ou Quicklogic ont choisi cette orientation (avec un nombre raisonnable d’unités dédiées pour conserver une consommation raisonnable) pour leur FPGA. D’autres
comme Actel et Atmel privilégient la granularité fine qui permet d’implanter efficacement tous types
de circuits et font l’impasse sur de telles unités.
Les deux principaux fabriquants de FPGA (à base de technologie SRAM), Xilinx et Altera,
se livrent une lutte féroce dans le domaine des circuits logiques reprogrammables en proposant
des innovations notables à chaque nouvelle génération de composants [AC05] [Xil05]. Si l’approche
générale diffère chez les deux constructeurs, certains choix architecturaux récents les rapprochent et
l’émulation qui en résulte est bénéfique au domaine.
Xilinx
Les composants produits par Xilinx apportent des innovations dans de nombreux domaines au gré
des avancées technologiques. Les FPGA sont basés sur une architecture ı̂lot de calcul. L’évolution est
illustrée à travers trois familles de composants.
Pour la famille Virtex-II, un CLB est constitué de 4 tranches (slice) elles mêmes composées de
deux éléments logiques configurables tels que décrits sur la figure 1.5. Les slices sont reliés entre eux via
des connexions locales. Compte tenu de la difficulté à placer des fonctionnalités complexes uniquement
sur les LUT, des blocs dédiés ont été intégrés pour le traitement de signal (jusqu’à 444 multiplieurs
18x18 bits). Il y a deux types de mémoires : les mémoires distribuées (jusqu’à 1.7Mb en configurant
les LUT en mode RAM/ROM double port) et les mémoires embarquées (plus de 10 Mbit dans les
Blocks RAM). Les composants les plus complexes intègrent des coeurs de processeurs PowerPC d’IBM
(plus de 600 DMIPS), des E/S de type Rocket IO permettant des transmissions entre 600 Mbit/s. et
3 Gbit/s et des mécanismes de gestion d’horloge complexes.
La famille Virtex-4 est gravé en 90 nm et possède un coeur alimenté par 1,2 V. L’architecture est
basée sur la structure colonne ASMBL qui répartit les ressources à travers le composant. Les CLB
sont identiques à ceux des Virtex II. Le choix de composant est grand, les plus complexes intègrent
des coeurs de PowerPC (jusqu’à 700 DMIPS), des E/S avec transmission série de 622 Mbit/s jusqu’à
10 Gbit/s, des blocs de traitement de signal dédiés, des mécanismes de gestion d’horloge complexes.
L’orientation traitement de signal est également fortement présente grâce à des modules tels que : les
16
multiplieurs 18x18 bits, les accumulateurs (48 bits) et les additionneurs/soustracteurs intégrés. Au
niveau des ressources mémoires, le Virtex 4 intègre les mêmes types de mémoires que le Virtex II.
Le Virtex 5 est le dernier né de chez Xilinx, pour le passage à la technologie 65 nm, des progrès
importants sont intervenus. Une nouvelle structure est proposée pour les modules logiques élémentaires (fig 1.6) appelés maintenant ExpressFabric. En effet, la LUT à 4 entrées, disponible sur les
familles précédentes, est remplacée par une véritable LUT à 6 entrées. Les CLB se décomposent maintenant en deux slices possédant chacun quatre LUT à 6 entrées et 4 bascules (fig 1.7). Globalement,
Xilinx annonce une consommation dynamique en retrait de 35%, une surface en baisse de 45% et
des performances en augmentation de 30%. Ce circuit contient plus d’un milliard de transistors. Les
ressources de routage ont été repensées pour minimiser le nombre d’interconnexions entre les CLB.
Les mémoires distribuées bénéficient également de ce nouvel apport. Les mémoires embarquées (14.5
Mbit) fonctionnent à 550 MHz contre 500 Mhz pour le Virtex 4. De plus, les multiplieurs embarqués
25 × 18 bits qui fournissent des résultats sur 48 bits peuvent être mis en cascade et supportent même
des opérations SIMD. Le Virtex 5 intègre également un bloc de gestion des horloges complexe afin de
répartir au mieux les signaux sur le composant. Enfin, les E/S sont au nombre de 1200 et bénéficient
de mécanismes de synchronisation performants. Elles supportent des débits pouvant aller jusqu’à 1.25
Gbit/s.
Figure 1.6 — Bloc diagramme d’un CLB de Virtex 5
Figure 1.7 — Slice d’un Virtex 5
Conscient de l’enjeu que représente l’intégrité de la configuration, ces FPGA sont capable de
décrypter le bitstream via un module de décryptage reposant sur l’algorithme AES et l’utilisation
d’une clef de 256 bits. Celle-ci est sauvegardée dans une mémoire RAM dédiée, elle est écrite via le
port JTAG mais ne peut en aucun cas être lue de l’extérieur.
Altera
Les cibles d’Altera bénéficient également des avancées technologiques, le Stratix (fig. 1.8) est
17
comparable au Virtex II tandis que le Stratix II se rapproche plutôt du Virtex 4 (gravé en 90 nm).
L’élément logique configurable s’appelle ici LE (resp. ALM) pour le Stratix (resp. Stratix II). Dans les
deux cas, il s’agit du module décrit à la figure 1.5. Un ALM peut combiner les LUT entre elles pour
remplir au mieux les ressources disponibles (fig. 1.10).
Figure 1.8 — Caractéristiques des composants Stratix
Un Stratix II comporte jusqu’à 180 000 éléments logiques (LE) (ou 71 760 ALM). Le composant
compte jusqu’à 9 Mbits de mémoire embarquée et 96 blocs de type traitement de signal. Ces blocs
peuvent être utilisés pour câbler jusqu’à 384 multiplieurs 18x18 bits. Ainsi, la structure comporte 2
niveaux hiérarchiques avec une matrice de LAB (fig. 1.9) constitué eux-même de 8 ALM (fig. 1.10).
Le FPGA peut être interfacé avec tous les types de RAM ( DDR, DDR2 SDRAM, QDR II RAM...).
Doté d’E/S haut débit (jusqu’à 1 Gbit/s), le Stratix II offre également un mécanisme de gestion
d’horloge élaboré (jusqu’à 550 MHz) et plus de 12 PLL. Le FPGA est capable de décrypter le train
binaire de configuration via un module de décryptage reposant sur l’algorithme AES et une clef de
128 bits.
La consommation d’énergie d’un FPGA, bien plus élevée que celle d’un ASIC, reste cependant plus
faible que celle d’un DSP à performance égale. Toutefois, l’avantage non négligeable du DSP demeure
son caractère reprogrammable de manière logicielle et le support de nombreuses applications.
1.1.2.2
Les processeurs
Avec la densité d’intégration croissante, le processeur peut être intégré sur une puce. Il est appelé
microprocesseur car il bénéficie des technologies submicroniques. Cette solution apparaı̂t comme la
plus flexible puisque cette cible est capable d’exécuter tout type d’application à condition que celle-ci
18
Figure 1.9 — Structure en LAB du Stratix II
Figure 1.10 — Bloc diagramme d’un ALM
soit décrite dans un langage de programmation. Un outil de compilation se charge de transformer la
description en code C (ou autre) en une description en langage machine associé. Puis, le processeur
prend en charge les instructions décrites dans un langage machine (assembleur) et les interprète afin
d’effectuer une tâche donnée (calcul et/ou transfert de registre...). Cette approche est parfois qualifiée
de « logicielle » en référence au langage de programmation haut niveau. Toutefois, il est évident qu’une
architecture se cache derrière cette approche. Elle peut être adaptée à des traitements généralistes
et/ou spécifiques.
Les architectures communément utilisées pour décrire les composants de type microprocesseurs
se basent historiquement sur l’architecture Von Neuman (fig. 1.11). Celle-ci est constituée de quatre
unités de base :
– l’unité de contrôle chargée du séquencemment des opérations,
– l’unité de traitement qui réalise les opérations élémentaires (ou UAL),
– l’unité responsable des E/S qui gère l’échange de données avec les ports et les mémoires externes,
– la zone mémoire qui contient les instructions et les données.
Une première évolution de l’architecture Von Neumann est l’architecture Harvard (fig. 1.12). Les
mémoires d’instructions et de données sont séparées. L’accès à chacune des deux mémoires se fait via
des bus de communication distincts. Cette organisation permet de transférer des instructions et des
données simultanément, ce qui améliore les performances. Il est également possible de dupliquer les
bus d’adresse et de données pour accélérer le traitement.
Dans le modèle d’architecture Von Neumann, il apparaı̂t que l’adressage et/ou le transfert d’instructions prend la majeure partie du temps d’exécution [MP96]. L’idée de l’approche CISC (processeur
à jeu d’instructions complexe) est donc d’augmenter le rendement des instructions en créant un jeu
19
Figure 1.11 — Architecture Von Neumann
Figure 1.12 — Architecture Harvard
d’instructions plus complexe. Une instruction de type CISC prendra moins de temps d’exécution qu’un
équivalent en nombre d’instructions simples. L’approche RISC, quant à elle, consiste à paralléliser à
la fois l’exécution des opérations concernant les instructions et celles concernant les données. En plus
du parallélisme spatial apporté par l’architecture Harvard, le parallélisme de type temporel est également exploité grâce à la notion de pipeline (figure 1.13). En effet, l’ajout de registres à l’intérieur du
contrôleur permet une exécution concurrente à différents étages du pipeline (sur les instructions et/ou
sur les adresses). Prenons l’exemple d’une instruction de calcul nécessitant 5 étapes : tout d’abord,
il faut charger l’instruction à partir de la mémoire (Li), puis la décoder et sélectionner les opérandes
dans des registres internes (Di), ensuite les opérandes doivent être rapatriés de la mémoire vers les
20
registres internes (Ld), le calcul est alors réalisé dans l’UAL (Ex) et enfin le résultat est renvoyé en
mémoire (E). Chaque étape nécessite un temps de cycle machine. Ainsi, en théorie, une instruction
peut être exécutée à chaque temps de cycle (à ne pas confondre avec le temps de cycle de l’horloge) ce
qui explique la dénomination processeur à jeu d’instructions réduit (chacune d’elles ayant un format
identique).
t
Ci
Di
Ld
Ex
E
Ci
Di
Ld
Ex
E
Ci
Di
Ld
Ex
E
Ci
Di
Ld
Ex
E
Ci
Di
Ld
Ex
E
Instructions
Ci: Chargement d’une instruction en mémoire
Di: Décodage d’une instruction
Ld: Transfert de la mémoire vers les registres internes
Ex: Exécution de l’instruction sur l’UAL
E: Ecriture d’une donnée en mémoire
Figure 1.13 — Pipeline d’instructions d’un processeur RISC sur 5 niveaux
Par ailleurs, la complexité relativement faible d’un processeur RISC autorise l’intégration sur la
puce de ressources supplémentaires (registre, mémoires tampons...). Ces processeurs sont très présents
dans les systèmes embarqués. Aujourd’hui, les fabricants de FPGA vont jusqu’à proposer leurs propres
processeurs RISC embarqués. En effet, les deux principaux acteurs du marché, Xilinx et Altera, fournissent des processeurs dits logiciels entièrement paramétrables. L’avantage de telles solutions réside
dans un prototypage de cible hétérogène sur un FPGA avant le passage sur une cible de type ASIC.
Des sociétés telles que ARC et Tensilica, fournissent des modèles de processeurs plus puissants et plus
flexibles mais ces modèles ne sont pas optimisés pour des cibles FPGA.
Le tableau 1.2 fournit une comparaison entre les solutions de Xilinx et d’Altera, le microblaze et le
NIOS II. Les critères de choix ne sont pas seulement d’ordre économique, en effet la qualité des outils de
développement est primordiale. D’un point de vue purement architectural, le microblaze possède une
unité de calcul flottant optionnelle et voit son jeu d’instructions étendu pour différentes opérations
complexes normalement gourmandes en temps de cycles. Les performances en termes d’opérations
par Mhz sont quasi-identiques : 0.92 DMIPS pour le microblaze contre 1.16 pour le NIOS II. En
revanche, ce dernier possède un avantage non négligeable qui est la possibilité de personnaliser le jeu
d’instructions. Ainsi, le concepteur peut créer des instructions spécifiques à son application. Dans les
deux cas, des blocs fonctionnels peuvent être désactivés suivant les besoins. Xilinx propose également
des processeurs matériels de type PowerPC directement intégrés sur leur FPGA. Cette approche
```
``` Processeur
```
```
Caract.
DMIPS/MHz
Long. Instructions
Fréq. max
Surface
Pipeline
ALU
21
NIOS II
Microblaze 4.00a
1.16
32 bits
185 MHz
1800 LEs
900 ALMs
6 étages
Multiplieur (1 cycle)
Diviseur (optionel)
Barrel Shifter (1 cycle)
-
0.92
32 bits
180 Mhz
1,269 LUTs
3 étages
Multiplieur (optionel)
Diviseur (optionel)
Barrel Shifter (optionel)
FPU (optionel + 1300LUTs)
Tableau 1.2 — Comparatif des caractéristiques des processeurs NIOS II et Microblaze
semble, quant à elle, abandonnée par Altera qui proposa en 2001 un FPGA Excalibur basé sur une
cible APEX et contenant un processeur ARM.
Face à la complexité croissante des applications de traitement de signal, ces architectures ont évolué
afin de pouvoir effectuer des calculs intensifs. D’une part, les instructions les plus complexes doivent
être réalisées en un seul cycle grâce à l’utilisation d’unités spécialisées et d’autre part, il est nécessaire de
paralléliser les traitements en augmentant le nombre d’unités de calculs. Ainsi, les processeurs de type
DSP (processeur de traitement de signal) sont, comme leur nom l’indique, orienté pour le traitement
de signal au sens large. La majorité des DSP conventionnels sont basés sur la structure Harvard
séparant bus d’instructions et bus de données, sur des opérateurs dédiés (par exemple MAC), sur des
registres distribués et sur des générateurs d’adresses efficaces (chargement optimal des données en
mémoires). Dans un premier temps, le DSP était uniquement utilisé pour réaliser de simples additions
et multiplications, programmé grâce à un langage assembleur et destiné à un éventail d’applications
réduit. Très rapidement, l’utilisation massive d’applications de traitement de signal ont entraı̂né une
mutation de l’architecture interne des DSP. La notion de parallélisme est apparue par l’intermédiaire :
– des DSP SWP/SIMD (Sub Word Parallelism/Single Instruction Multiple Data ), le nombre
des unités d’exécution augmente, il y a plus d’opérations par cycle mais la difficulté est dans
l’alimentation des unités par des données.
– des DSP VLIW (Very Long Instruction Word)(fig.1.14) et superscalaire (fig.1.15).
Le but des deux approches est de bénéficier du parallélisme au niveau instruction de l’application.
Dans le premier cas, les instructions élémentaires sont réorganisées par le compilateur afin de créer
une « super instruction ». L’objectif est de remplir au mieux toutes les unités fonctionnelles. Dans le
second cas , le principe est identique, toutefois l’ordonnancement des instructions est réalisé de manière
dynamique par le DSP grâce aux techniques classiquement utilisées par les processeurs généraux
(prédiction de branchement, cache dynamique).
Cette parallélisation a cependant un coût non négligeable en terme de bande passante vers la
22
mémoire, de consommation, de mise en place du séquencemment, de taille de code et du temps
d’exécution difficilement prédictible.
Figure 1.14 — Pipeline d’un DSP VLIW à 5 étages
Figure 1.15 — Pipeline d’un DSP superscalaire à 5 étages
Le besoin de composants performants dans le domaine des applications temps réel est tel que le
DSP est présent partout : les asservissements de moteur, les traitements audio et vidéo, les applications
médicales...[Ins06][Inc06][Sem06].
1.1.2.3
Les architectures hétérogènes
L’évolution rapide des applications et la nécessité d’intégrer des solutions flexibles, performantes
et évolutives ont poussé les concepteurs à développer une nouvelle approche. Dans l’optique de la
réduction des coûts de production des systèmes complexes destinés au grand public, les architectures
hétérogènes se retrouvent maintenant sur une seule et même puce.
Un système sur puce, ou en anglais System-on-Chip (SoC), est le résultat de la juxtaposition de structures hétérogènes matérielles et logicielles afin de concevoir un système complet. Ainsi,
un SoC peut comporter à la fois de la mémoire embarquée (RAM et ROM), un micro-processeur, des
DSP, des blocs dédiés, des interfaces de périphériques, de la logique d’entrées/sorties, des convertisseurs de données, des bus des communications (voir fig 1.16)... Parallèlement à la construction de la
partie matérielle du SoC, il faut développer la couche logicielle nécessaire à l’application (Système
d’exploitation, fonctions...).
Le but est d’optimiser le système en adaptant les ressources matérielles et logicielles aux besoins
spécifiques. Le regroupement de cibles hétérogènes doit permettre d’adresser au mieux les problèmes
de rapidité, de surface et de temps de latence.
Compte tenu du coût de la réalisation d’un système sur puce, la validation du fonctionnement
du système nécessite l’utilisation d’une plate-forme. Cette structure permet le prototypage à moindre
frais d’applications complexes avant le passage obligé en fonderie. Elles sont généralement construites
23
IP
RAM
E/S
CPU
ROM
microprocesseur
CNA/CAN
IP
DSP
Figure 1.16 — SoC : une structure hétérogène
autour d’un processeur généraliste.
L’exemple de la plate-forme Sundance témoigne de la volonté des fournisseurs de proposer un
ensemble de cartes permettant le développement de systèmes modulaires. En effet, cette solution
s’intègre au coeur d’un ordinateur grâce à une carte de type PCI. Cette carte mère peut recevoir
différents modules, à base de FPGA, DSP, convertisseurs A/N ou N/A , de mémoires embarquées
et encore bien d’autres ressources qui bénéficient de liaisons rapides. Il est possible d’envisager de
multiples systèmes et de valider un développement simplement. Cette plate-forme a été utilisée dans
le cadre du projet PALMYRE pour l’implantation d’une chaı̂ne de communications numériques et une
transmission dans un domaine hyperfréquence sur différents types de canaux. Un descriptif du projet
est disponible en annexe B. De plus, l’adaptation aux techniques avancées telles que la mise en oeuvre
de la modulation MC-CDMA, une transmission MIMO et l’intégration de codes correcteurs d’erreurs
ont fait l’objet de nombreuses publications [RDV+ 05][MBG+ 05][RDM+ 06][NM05].
Même si l’approche SoC répond aux besoins en terme de performances et d’intégration, il en reste
qu’elle n’est pas adaptée à l’évolutivité des systèmes. De plus, compte tenu des coûts de fabrication,
elle ne peut être utilisée que pour des productions en grande série (fig. 1.17). Les étapes de conception
et de test sont également longues et coûteuses. Une alternative est apparue autour de 2002 à travers
le système sur puce reprogrammable, ou en anglais System on Programmable Chip (SoPC). Cette
approche repose sur le principe des FPGA. Le prototypage et le développement sont donc rapides,
la reconfiguration est effective en quelques ms et sur demande. En contrepartie, l’intégration est
moins dense, la consommation plus élevée et les performances moindres. Ainsi, Xilinx et Altera
proposent chacun leur processeur propriétaire qui peut être intégré sur la matrice FPGA (voir
section précédente). Les deux solutions intègrent également des librairies de composants virtuels et
24
FPGA
ASIC
Microprocesseur
E/S
Microprocesseur
IP
Mémoire
DSP
Mémoire
DSP
Mémoire
DSP
DSP
Logique
Logique
E/S
Mémoire
IP
E/S
IP
E/S
E/S
Figure 1.17 — SoC sur une cible ASIC
Figure 1.18 — SoPC sur un circuit FPGA
de périphériques annexes. Des systèmes complexes reconfigurables s’implantent simplement sur un
FPGA (fig. 1.18). Le concepteur peut ajouter des blocs matériels jouant le rôle d’accélérateurs. Cette
approche utilisée dans le cadre de ce travail sera détaillée ultérieurement.
Les solutions d’intégration SoC et SoPC ne sont pas concurrentes. En effet, dans le cas d’une
large diffusion des systèmes, l’approche SoC est la plus appropriée. En revanche, si une plus grande
flexibilité est souhaitée et dans le cas d’une petite série, le SoPC semble plus adapté. Ces architectures hétérogènes nécessitent des outils de conception évolués pour gérer la cohabitation de toutes les
ressources.
1.1.3
Les méthodologies de conception
1.1.3.1
Les niveaux d’abstraction
Les flots de conception se basent historiquement sur le flot de conception d’un ASIC. L’idée
est d’élever le niveau d’abstraction lors de la conception afin de permettre la synthèse de systèmes
complexes sur des architectures flexibles et performantes. En l’occurence ici, un système complexe est
typiquement un SoC intégrant à la fois des parties logicielles et matérielles. L’évolution récente des
technologies d’intégration encourage le développement d’approches dites de haut niveau, c’est à dire,
une élévation des niveaux d’abstractions.
Le flot de conception ASIC
Les ASIC peuvent apporter des solutions à contraintes fortes en termes de performances, consommation
et de surface. Le flot de conception associé permet également de répondre à ces contraintes. Il est ainsi
constitué de plusieurs étapes bien définies permettant de multiples optimisations.
25
A partir d’une spécification fonctionnelle, des raffinements successifs sont effectués afin de produire
une description complète au niveau circuit (fig. 1.19). A chaque étape, des bibliothèques d’éléments
associés sont disponibles pour raffiner la conception. Bien évidemment, ce flot est maintenant en
grande partie automatisé pour faciliter la conception de circuit.
Au niveau fonctionnel, des spécifications sont élaborées sous la forme de bloc diagramme et de
cahiers des charges. L’utilisation de l’étape de synthèse architecturale peut permettre de transformer
ces spécifications en une description matérielle associée. Elle est abordée plus en détails dans la section suivante 1.2. Au niveau architectural (ou transfert de registre, RTL en anglais ), le concepteur
décrit la nature des ressources (RAM, additionneurs...) et les transferts de données dans un langage
de description matériel (VHDL ou Verilog). A la suite d’une synthèse logique, la description RTL est
transformée en une description d’éléments logiques (netlist) composée d’un réseau de portes logiques.
De plus, le raffinement est accompagné d’optimisations en vitesse, en surface et en consommation
suivant les technologies visées. Puis, la synthèse physique permet de convertir la description matérielle
en description électrique (layout) décrivant l’agencement des transistors élémentaires et leur interconnexion. Enfin, la dernière étape produit les fichiers décrivant l’ensemble des interconnexions nécessaires
à la fabrication tout en respectant des contraintes géométriques strictes
LIBRAIRIE ASSOCIEE
Niveau fonctionnel
Synthèse architecturale
composants
Niveau architectural
Synthèse logique
portes
Niveau logique
Synthèse physique
transistors
Niveau physique
Synthèse des masques
masques
Niveau topologique
Figure 1.19 — Flot de conception ASIC
Dans le cas de la conception de système complexe tel qu’un SoC, différents éléments décrits
au niveau transfert de registre sont considérés. Ainsi la provenance de ces éléments constituant
le système est multiple et ceux-ci doivent s’intégrer parfaitement. Cependant, un système ne
peut être considéré comme fonctionnel que lorsque l’ensemble a été validé. Environ 90% des pro-
26
blèmes potentiels sont identifiés lors de la vérification de chaque bloc. Les 10% restants correspondent :
– soit aux erreurs de fonctionnement simultanés des modules,
– soit au dysfonctionnement des interactions entre modules,
– soit aux erreurs dans la conception architecturale.
Bien que moins nombreux, ces problèmes sont les plus difficiles à situer. De plus, la simulation
d’un ensemble de composants décrits dans un langage matériel au niveau RTL se révèle souvent
longue. Enfin, d’un point de vue économique, les problèmes non identifiés avant la gravure des
masques peuvent devenir extrêmement pénalisants. C’est pourquoi, les systèmes disposant de blocs à
la fois matériels et logiciels nécessitent l’adaptation des parties matérielles en vue de la co-simulation
à un niveau d’abstraction plus élevé.
Les différents niveaux à un haut niveau d’abstraction
Compte tenu de l’évolution dans le domaine des systèmes embarqués, des coûts et des délais de
mise au point, un consensus est apparu pour définir des niveaux d’abstraction plus élevés que le
niveau transfert de registre [htta]. Ainsi, les différents niveaux identifiés par Gajski et Cai [CG03]
sont les suivants :
– UTF (UnTimed Functional) : ce niveau d’abstraction définit l’interface et la fonctionnalité du
modèle. Il ne comporte aucune notion de durée d’exécution mais éventuellement un enchaı̂nement des événements.
– TF (Time Functional) : ce niveau d’abstraction définit l’interface et la fonctionnalité du modèle.
Il comporte des notion de durée (temps d’exécution, latence, temps de propagation...).
– BCA (Bus Cycle Accurate) : ce niveau d’abstraction définit l’interface d’un composant et sa
réactivité au niveau cycle. La modélisation des transactions sur l’interface est précise, au cycle
près. Le temps de développement réclamé est bien plus important, mais ce niveau autorise une
vérification par simulation des composants en permettant l’écriture de bancs de test précis.
Les erreurs d’architecture de bas-niveau sont détectées à cette étape puisque l’implantation est
proche du niveau transfert de registre.
– CABA (Cycle Accurate and Bit Accurate) : ce niveau d’abstraction définit la sensibilité complète
d’un composant au niveau cycle. La modélisation des transactions sur l’interface est précise au
cycle près et décrit au bit près. Des erreurs dues au blocage interne des composants peuvent se
détecter uniquement à ce niveau. Ces modèles reflètent la micro architecture niveau transfert
de registre du composant implanté.
– RTL (Register Transfert Level) : ce niveau d’abstraction définit l’interface et la fonctionnalité
d’un modèle matériel. A partir de ce niveau, la suite de l’implantation s’appuie sur le flot
27
classique de conception d’un ASIC.
Afin de respecter les contraintes de développement, les concepteurs souhaitent donc établir des
modèles transactionnels simples à mettre en oeuvre et rapides à simuler. Il est nécessaire d’associer les
différents modules le plus tôt possible dans le flot de conception. Quelques modèles, décrits au cycle
et au bit près, sont disponibles sur le marché, notamment des processeurs (ARM7, MIPS, SPARC),
des caches, des contrôleurs mémoires... Ainsi, les descriptions TLM (Transaction Level Modeling)
englobent l’ensemble de ces niveaux pour une gestion simplifiée de la complexité. La place centrale des
techniques de vérification devient prépondérante compte tenu de l’hétérogénéité des systèmes. C’est
pourquoi, un cadre de référence commun pour les parties matérielles et logicielles est indispensable à
la modélisation, la vérification et l’implémentation.
Les approches actuelles de la conception et validation des architectures matérielles/logicielles des
SoC bénéficient de l’élévation des niveaux d’abstraction. Les outils associés doivent aider le concepteur
à choisir les meilleurs compromis en termes de performances et de consommation.
1.1.3.2
La conception conjointe logicielle-matérielle
L’intégration de structures hétérogènes telles que les systèmes sur puce (SoC) ou les systèmes reconfigurables sur puce (RSoC), l’accroissement de la complexité des applications et le partitionnement
des solutions architecturales nécessitent l’utilisation de nouveaux flots de conception.
De tels flots doivent favoriser l’exploration des solutions architecturales, à savoir le choix des
composants pour l’exécution des différentes applications et le choix des structures pour l’échange de
données. Au-delà de la simple mise-au-point de l’architecture matérielle, la disponibilité d’un modèle
de haut niveau fonctionnel facilite l’intégration d’applications complexes dans les systèmes hétérogènes. Le développement logiciel de l’application doit nécessairement être conjoint au développement
de la plate-forme matérielle. En effet, il est impératif d’exécuter et de vérifier le plus tôt possible
dans la chaı̂ne de développement le comportement du logiciel sur une plate-forme matérielle. De plus,
la plate-forme matérielle ne peut être validée qu’en prenant en compte le comportement du logiciel
qu’elle est censée exécuter. On parle alors de codesign ou conception conjointe logicielle-matérielle.
Un flot classique de codesign est illustré sur la figure 1.20. Quatre étapes sont nécessaires avant
de procéder à l’implantation proprement dite. Après chaque étape, le concepteur est susceptible de
revenir en arrière si les contraintes ne sont pas respectées.
La spécification consiste à modéliser le système au niveau fonctionnel. Dans cette optique, les
concepteurs disposent de méthodes, de modèles et de langages associés. Les méthodes peuvent s’appuyer sur un ou plusieurs modèles pour expliciter le comportement du système dans son ensemble
28
SPECIFICATIONS
ESTIMATIONS
PARTITIONNEMENT HW/SW
SYNTHESE HW
SYNTHESE
COMMUNICATIONS
SYNTHESE SW
CIRCUIT
Figure 1.20 — Les étapes constituant le flot de codesign
(SADT, MCSE [CPIJ94]...). Dans ce cas, les approches peuvent être de deux natures :
– « langage », chaque partie constituante est développée, optimisée et validée indépendamment
dans son propre langage puis l’ensemble est regroupé en définissant le protocole de communication.
– « système », chaque partie est modélisée, optimisée puis l’ensemble est regroupé dans un environnement commun pour validation sans expliciter les processus de communication [LXL01].
Cette seconde voie a le mérite d’être plus souple, notamment en ce qui concerne les optimisations
globales et locales et de permettre l’exploration de l’espace de conception.
Le principal intérêt des langages systèmes est de rendre possible le développement rapide par
des ingénieurs systèmes d’une description hiérarchique et architecturale. Des langages sont également
associés à ces modèles et intégrés dans les outils commerciaux. Ainsi chez Cadence [Cad], le C/C++
et ECL sont utilisés dans l’outil VCC. Chez Synopsys [Syn] et CoWare [Cow], le choix de SystemC
semble d’autant plus pertinent qu’il vient d’être normalisé IEEE 1666 [Soc05]. Celoxica propose le
langage Handel-C [SB], cependant leurs outils supportent également le SystemC.
En ce qui concerne les estimations des systèmes en terme de surface, rapidité et consommation, elles demeurent peu précises au niveau algorithmique. Cependant, comme ce type d’approche
se place avant le choix d’une plate forme matérielle, l’intérêt réside dans la possibilité de réaliser une
exploration de l’espace de conception à un très haut niveau d’abstraction dans le flot de conception.
29
Ainsi, l’analyse du code de l’application explicite son parallélisme et dévoile son orientation (contrôle,
mémoire, traitement). Il est alors possible d’en extraire un modèle architectural abstrait. Par exemple,
un outil tel que ATOMIUM [BCM97] permet une optimisation de la mémoire a priori. D’autres outils
comme Design Trotter [MDP02] donnent les orientations du code de l’application à l’aide de métriques
de caractérisation. Ces premières estimations au niveau système révèlent les points critiques de l’application, il est possible d’adjoindre des résultats d’estimations plus fins en choisissant, par exemple,
l’implantation virtuelle sur un type de cible donné.
Des méthodes d’estimation de l’exécution d’applications sur des parties logicielles fournissent des
temps d’exécution en nombres de cycle et des tailles de code relativement précis [PEG99] [LMW95]. Des
outils donnent également une estimation de la consommation au niveau fonctionnel grâce à des modèles
pour les processeurs [LJSM04] mais elles doivent également fournir la consommation engendrée par le
transfert de données et le stockage en mémoire [BCM97]. L’outil commercial ESL Power technology
de Sequence Design fournit également des estimations en consommation de l’ensemble d’un SoC avec
30% de précision par rapport à une estimation au niveau logique. Enfin, les travaux de Gajski [GVN94]
permettent d’avoir des estimations en terme de surface et en vitesse pour des cibles FPGA ou ASIC.
En résumé, ces méthodes d’estimations sont plus ou moins précises mais elles sont un passage obligé
pour le concepteur afin d’évaluer a priori les caractéristiques de son système.
L’étape de partitionnement est délicate. Elle consiste à répartir les différentes tâches de l’application sur des parties matérielles ou logicielles suivant leur caractéristique. Elle peut être automatique
ou manuelle, fonction des contraintes (en termes de vitesse et/ou surface) et de la granularité des applications. Les types d’architectures pouvant répondre aux demandes du concepteur sont multiples :
– Processeur simple avec système d’exploitation temps réel embarqué
– Processeur simple avec Coprocesseur et/ou accélérateur
– Processeur simple et accélérateur de type dédié
– Processeurs multiples
Les méthodes de résolution se basent sur des heuristiques d’optimisation connues (Exclusions
mutuelles, Glouton, clustering...) et des modèles de représentation multiples de type graphe. Ainsi,
des outils tels que POLIS [Ba97], ConvergenSC [Inc] (Spinoff de l’IMEC) , Cosimate [Sof04] ont été
proposés ces dernières années.
Le processus de synthèse consiste à passer de la description de modèles à l’ensemble de l’architecture globale, il se décompose en trois étapes fondamentales :
– la synthèse logicielle.
– la synthèse matérielle.
– la synthèse des communications.
30
La synthèse logicielle nécessite une couche applicative permettant la programmation de haut
niveau du processeur contenu dans le SoC. Les tâches les moins critiques de l’application sont
décrites dans un langage de développement de type code C/C++. Une compilation permet de
répartir le traitement sur les ressources matérielles de la cible « logicielle » choisie par l’utilisateur.
En effet, un processeur est décrit à la fois de manière matérielle pour spécifier l’architecture choisie
et de manière logicielle pour donner le comportement des périphériques. Dans le même temps,
une synthèse logique est réalisée pour la partie matérielle, elle consiste à compiler la description
fonctionnelle des blocs à l’aide d’un outil de synthèse et d’une librairie de cellules logiques. Finalement, une « cross-compilation » permet au concepteur d’exécuter son programme sur la cible logicielle.
La synthèse matérielle consiste à effectuer une synthèse logique des ressources nécessaires à l’application pour l’implantation sur un circuit dédié de type FPGA ou ASIC. Dans le cas d’un FPGA,
cette étape est suivi d’une opération de placement routage sur le composant.
Les ressources de communication représentent également le point critique du système. En effet,
le bus système est la colonne vertébrale de l’architecture. Pour le décrire de manière optimale, le
concepteur bénéficie de librairies de protocoles et des interfaces correspondantes (bus AMBA, FIFO,
arbitre de bus...) décrites de manière plus ou moins fine (TLM, RTL, netlist). Il doit alors choisir des
modes de transfert adaptés à sa problématique. Une synthèse est réalisée pendant le partitionnement
tandis que la synthèse complète intervient après celui-ci [GABP98] [CAE00]. Il est à noter que cette
étape devient délicate dans le cas des réseaux sur puce (NoC) puisqu’il faut garantir l’utilisation
optimale de la bande passante, de la latence et de la disponibilité des ressources. Cependant, des
travaux comme ceux autour de l’outil µSpider [EDH04] ou encore [MM04] permettent la synthèse
sous contraintes et la génération d’un code RTL associé.
1.2
La synthèse architecturale
Les besoins en terme de productivité ont favorisé l’émergence de méthodologies comme la synthèse
d’architecture qui permet d’élever le niveau d’abstraction lors de la conception de circuits numériques.
La synthèse architecturale, également appelée synthèse de haut niveau ou synthèse comportementale, consiste à fournir, à partir de spécifications au niveau comportemental, une description matérielle
de l’entité qui l’exécute. Un bref historique sur la synthèse architecturale est tout d’abord exposé. Les
différentes techniques de synthèse et quelques outils de synthèse employés (universitaires et commerciaux), dont ceux utilisés dans le cadre de l’étude, sont ensuite présentés. Enfin, les tendances actuelles
sont évoquées.
1.2. LA SYNTHÈSE ARCHITECTURALE
1.2.1
31
Historique
Un retour en arrière permet de mieux comprendre l’évolution du domaine et son état actuel
[MJ03]. Il faut remonter à la fin des années 70 pour voir apparaı̂tre la notion de synthèse de
micro-architecture [PTS+ 79][Zim79]. Elle consistait à produire un chemin de données et une machine
d’états finis, c’est à dire, une unité de traitement effectuant des manipulations de données et
d’opérations redondantes dans le temps [MRSC86] et une unité contrôlant le déroulement des tâches.
Les bases de la synthèse haut niveau ont ainsi été posées grâce à une représentation interne sous la
forme d’un graphe de données et de contrôle (CDFG). Toutes les techniques d’optimisation actuelles
(voir 1.2.2) étaient déjà utilisées mais étaient destinées à produire l’architecture d’un processeur à
partir de son jeu d’instructions. Puis, les processeurs de traitement de signal de type DSP ont été
ciblés. Le principal point faible de la synthèse haut niveau des années 80 résidait dans le langage de
description comportementale de l’architecture, car il n’y avait pas de standard. Même si des travaux
ont été menés en ce sens [Bar80][Pa82], jusqu’a l’apparition du VHDL en 1987, les concepteurs
restaient étrangers à ces spécifications.
C’est seulement à partir de 1985 que les activités de recherche débutent sur la synthèse haut niveau
telle que l’on entend aujourd’hui. Des travaux prévoient même l’intégration de micro-contrôleur et de
blocs dédiés sur des ASIC [JPS85] [LSB85]. Les principaux travaux se concentrent alors sur les techniques d’ordonnancements, d’allocation et d’assignements. Bien sûr, les techniques d’ordonnancement
des compilateurs étaient différentes pour chacune des méthodes [Cam91] [La97] et [GVLM92].
Dans le milieu des années 1990, le développement d’outil de synthèse haut niveau est en vogue
et suscite beaucoup d’intérêt de la part des concepteurs de systèmes. Les descriptions sont moins
complexes ce qui facilite l’exploration architecturale et l’évaluation de solution. Malheureusement,
les points d’entrée (description VHDL ou Verilog) de ces outils n’étaient pas conçues pour de telles
tâches et les résultats d’implantation ne remplissaient pas les contraintes en terme de vitesse et de
surface.
Depuis, les travaux dans le domaine ont permis d’affiner les outils. La convergence vers un langage
haut niveau commun tel que le langage SystemC (notion d’horloge, exécution concurrente, précision
niveau bit, hiérarchie...) laisse présager d’un futur prometteur.
1.2.2
Les techniques de synthèse
Le but de la synthèse architecturale est de fournir une description structurelle de l’architecture
proposée à partir de la représentation algorithmique établie par le concepteur. L’intérêt d’une telle
approche est d’automatiser les tâches permettant d’aboutir au circuit en exploitant les caractéristiques
de l’algorithme de l’application (parallélisme, contrôle). L’architecture générée respecte le squelette
d’un modèle d’architecture générique. Il se compose classiquement de quatre unités fonctionnelles : une
32
unité de traitement, une unité de contrôle, une unité de mémorisation et une unité de communication.
Cette modélisation sous forme d’unités permet de spécifier l’utilisation et la structure ainsi que le
contrôle propre à chacune. Des bibliothèques de ressources sont de plus disponibles pour évaluer la
complexité lors de la synthèse.
Description
comportementale
Contraintes
Compilation
Sélection
Transformation
CDFG
Allocation
Ordonnancement
Assignation et
Optimisation
LIBRAIRIE
Description RTL
Figure 1.21 — Différentes étapes constituant la synthèse de haut-niveau
Les techniques permettant le passage du niveau algorithmique vers l’implantation matérielle sont
les suivantes (fig 1.21)[Ga92] :
– La compilation : l’analyse de la spécification algorithmique par le compilateur permet
d’obtenir une représentation interne plus exploitable. Différentes techniques [Gal05] (déroulage
de boucles, propagation des constantes, élimination des invariants de boucles...) vont mener
à une description d’un graphe de données (DFG) ou d’un graphe de données et de contrôle
(CDFG ) opérationnel.
– La sélection et l’allocation des ressources : à partir d’une bibliothèque complète d’opérateurs, un choix tenant compte des contraintes de l’application est réalisé. L’allocation consiste
à attribuer à la fois le nombre d’opérateurs nécessaires et à vérifier leur disponibilité dans le
domaine temporel.
– L’ordonnancement des ressources : des dates d’exécution sont attribuées pour chaque
opération. Le déroulement de ces étapes forme le graphe d’états du contrôleur. L’ordonnancement peut se faire sous contraintes : de dépendance de données, temporelles (minimisation du
nombre de ressources nécessaires) ou matérielles (minimisation de la latence). Des algorithmes
33
permettent de traiter ces problèmes, par exemple, l’ordonnancement au plus tôt ou au plus
tard (ASAP/ALAP), à temps contraint (précédent l’allocation) ou à surface donnée (suivant
l’allocation).
– L’assignation : Cette étape consiste à affecter une opération ordonnancée à chaque opérateur
alloué en essayant de minimiser le nombre de ressources et les connexions internes à l’unité
de traitement liées à l’échange de données. La principale contrainte réside dans le fait que
l’utilisation des ressources (opérateurs, registres, bus) ne peut pas être simultanée.
– Affectations des opérations aux opérateurs
– Affectations des variables aux ressources
– Affectations des transferts de données aux bus
Ainsi, les opérateurs arithmétiques sont concernés mais également les registres/file d’attente
et enfin les bus. De plus, il est nécessaire d’optimiser les composants d’interconnexion (multiplexeur, démultiplexeur, portes trois états). L’idée générale, pour tous ces composants, est que
deux entités peuvent partager la même ressource seulement à des instants différents dans le
temps. Des méthodes globales et incrémentales permettent d’adresser ces problèmes.
Le résultat de la synthèse architecturale est une description des unités fonctionnelles nécessaires
au niveau transfert de registre et ciblant soit un composant de type FPGA ou ASIC.
Afin que l’architecture générée par un processus de synthèse haut niveau puisse être intégrée
au sein d’un circuit plus complexe, elle doit vérifier un certain nombre de contraintes. Celle-ci sont
majoritairement temporelles ou matérielles mais elles peuvent être aussi d’autres natures (par exemple
la consommation).
Tout d’abord, l’obtention de l’architecture peut se faire sous contraintes temporelles comme dans
tout système temps réels. Elle doit respecter des critères de fonctionnement (comme un échantillonnage
par exemple) et fournir les données traitées à des débits fixés. Deux critères sont primordiaux :
– la latence : il s’agit du délai entre l’entrée des données à traiter et la fin du traitement associé
(disponibilité des résultats).
– la cadence : il s’agit du temps qui s’écoule entre l’arrivée d’une donnée et l’instant où une autre
donnée est présentée à l’entrée.
Il faut noter que si la latence imposée est supérieure à la cadence alors l’architecture est pipelinée.
Mais le concepteur ne dispose pas d’une surface illimitée sur silicium en raison du coût de la
réalisation d’un circuit. La surface et donc les ressources disponibles peuvent être fixées. Ainsi, l’outil
de synthèse doit fournir une architecture tenant dans la place impartie.
Enfin, la consommation d’énergie peut être réduites grâce à certaines techniques une fois les
34
contraintes temporelles et matérielles respectées. Des contraintes au niveau des placements de données
en mémoire [Cor05] ou des longueurs d’interconnexions [Jég00] peuvent aussi être envisagées.
1.2.3
Les outils
Cette section présente une liste non exhaustive des outils de synthèse architecturale universitaires
ou commerciaux. Bien que certains aient disparus, ils ont, semble-t-il, laissé la place à d’autres outils
intégrant les dernières innovations dans le domaine. CATHEDRALII [MJJ+ 88] est le premier outil
de synthèse architecturale à prendre en considération le traitement intensif de flux de données. Il
est d’ailleurs à la base d’outils commerciaux. Par la suite, de nombreux outils universitaires ont été
proposés : HERCULE [BCM+ 88], HYPER [CPTR89], AMICAL [POJ93], DEFACTO [BDD+ 99],
MMAlpha [Gui03], SPARK [GGDN04]. Behavioral Compiler [Kna96] fut le premier outil commercial
suivi de quelques autres encore : MONET [Ell00], Pico [httc]. Les outils les plus récents, dont ceux
utilisés, pendant les travaux de thèse sont maintenant présentés.
Gaut :
GAUT [PMS93] est un environnement de synthèse d’architecture matérielle, dédié aux applications
de traitement de signal et de l’image. Il permet d’obtenir une description structurelle VHDL à partir
d’une description en langage C ou en langage VHDL comportemental sous contrainte de cadence. La
description optimisée en surface résultante au niveau RTL est le point d’entrée des outils de synthèse
logique du marché (comme Design Compiler de Synopsys). De plus, il permet de cibler des FPGA de
chez Xilinx et Altera. L’architecture cible proposée par GAUT est constituée de 3 parties possédant
chacune leur propre unité de contrôle :
– Une unité de traitement : il s’agit de la partie combinatoire constituée de cellules élémentaires
(opérateurs arithmétiques, registres et opérateurs de connexion)[Cor05][Gal05].
– Une unité de communication : il s’agit de l’ensemble des unités de mémorisation (files d’attente,
registres) et du contrôle associés en fonction des lecture/écriture sur les ports d’E/S [Cou03].
Une machine d’états finis est associée à chaque port d’E/S en fonction des protocoles de communication.
– Une unité de mémorisation : il s’agit de l’ensemble des bancs mémoires et d’une partie de
contrôle, notamment les générateurs d’adresses. Une machine d’états finis globale contrôle l’ensemble des mémoires en fonction de l’ordonnancement [Cor05][Gal05].
L’ensemble est contrôlé par une machine d’états finis résultant de l’ordonnancement pour la synchronisation de ces trois unités [Bom04]. L’architecture cible peut être soumise à différentes contraintes :
temporelles, d’E/S, de mémorisation, de surface et de consommation.
35
SystemC compiler [Kna96]
Il s’agit en fait de la suite logicielle Behavioral compiler d’aide à la conception de circuits intégrés.
Grâce à l’outil SystemC compiler de Synopsys, il est possible de passer d’une description en langage
SystemC à une description au niveau logique. On peut distinguer 2 flots de conceptions et donc mener
deux synthèses selon le point d’entrée choisi :
– à partir d’un modèle écrit en SystemC comportemental [Syn01], une synthèse architecturale est
possible et suivie d’une synthèse logique classique.
– à partir d’un modèle écrit en SystemC [Syn02], il faut raffiner le code de manière à obtenir une
description au niveau RTL et effectuer une synthèse logique.
Dans le premier cas, l’architecture élaborée se compose d’un chemin de données, d’une mémoire
et d’une partie de contrôle supervisant la partie de traitement. Le chemin de données est une
succession de multiplexeur/registre/multiplexeur/opérateur dont les sorties sont toutes mémorisées.
Une machine d’états commande chaque chemin de données. L’outil élabore la synthèse logique des
composants nécessaires à la synthèse d’architecture obtenant ainsi des caractéristiques exactes par
rapport à la bibliothèque de ressources. Les estimations de l’outil sont donc d’autant plus fiables mais
le temps de synthèse est plus important. Le flot de conception prend pour entrée une description
comportementale (SystemC, VHDL) de l’application. L’utilisateur fournit un temps d’horloge et
le type d’optimisation qu’il souhaite (surface, vitesse, latence). Les étapes d’ordonnancement des
opérations et d’allocations des ressources et des registres, de même que la génération de la partie
contrôle, sont menées automatiquement par l’outil. Le point de sortie est un format propriétaire
Synopsys qui peut être synthétisé en une netlist de type edif, vhdl ou verilog.
Agility Compiler
Agility Compiler, de chez Celoxica [httb], est un outil de synthèse haut niveau pour des projets
développés à l’aide du langage SystemC. Le point d’entrée du logiciel est donc une description comportementale en SystemC. Le processus de synthèse permet de conserver la hiérarchie décrite dans le
SystemC . Le point de sortie de l’outil Agility Compiler peut être :
– une description au niveau RTL (VHDL ou Verilog).
– une netlist au format EDIF pour les FPGA.
– une description structurelle en langage SystemC permettant de vérifier la fonctionnalité du bloc.
L’utilisateur peut explorer l’espace de conception et repérer les points critiques en fournissant une
approximation de la logique utilisée pour chaque ligne de code. L’outil fournit une estimation en terme
de surface, de latence et de chemin critique.
La modification des contraintes temporelles est possible sur les signaux d’E/S puisque l’outil peut
modifier le nombre de délais (tampons qui permettent de mémoriser des valeurs en vue d’utilisations
ultérieures) à certains endroits afin de minimiser le temps de parcours du chemin d’exécution critique.
36
Agility Compiler intègre également des librairies permettant de cibler des FPGA. C’est pourquoi
il est possible d’implanter la description en utilisant les ALU embarquées de chez Altera, de chez
Xilinx (DSP blocks du Stratix et multiplieurs 18-bit du Virtex-II) ou des mémoires RAM de chez
Actel, Altera et Xilinx.
CatapultC
Catapult-C est un outil de synthèse haut niveau mis au point par Mentor Graphics [Gra04]. L’outil
synthétise des descriptions en langage C++ ANSI sans notion temporelle et d’extensions propriétaires.
Il supporte également le langage SystemC. Le format de sortie est une description au niveau RTL en
VHDL ou Verilog, compatible avec les principaux outils de synthèse. Il est possible de prendre pour
cible soit un FPGA soit un ASIC.
Les protocoles de communication n’ont pas besoin d’être décrits dans le code C++, le logiciel intègre
une gestion de la synthèse d’interface, à savoir pour l’envoi de flux de données, RAM simple et double
port, échange de donnée via le protocole requête/acquittement (handshake), FIFO, AMBA. Il est
également possible d’utiliser son propre protocole via l’outil Catapult Library Builder. Catapult C
permet également une exploration de l’espace de conception en proposant des architectures différentes
suivant le choix des interfaces de communication.
1.2.4
Conclusion
Le tableau 1.3 récapitule les différentes caractéristiques des outils décrits précédemment.
Les outils de synthèse architecturale permettent donc de passer d’un langage de description comportementale à une description matérielle complète d’un système. Les différentes étapes lors d’une synthèse bénéficient de techniques éprouvées mais encore perfectibles. Les outils de haut niveau manquent
également d’estimateurs très précis en terme de performances (consommation, vitesse et surface), mais
les travaux entrepris présagent de futurs résultats intéressants. En effet, même si ces outils n’ont pas
encore atteint leur plénitude, la normalisation d’un langage de développement conjoint tel que SystemC
mais aussi et surtout l’apparition d’un consensus général pour bénéficier d’un modèle d’abstraction
haut niveau comme le TLM laisse augurer d’une montée en puissance de tels outils. SystemC est
d’autant plus intéressant que les descriptions de modèles au niveau RTL dans ce langage présentent
des résultats post-synthèse identiques aux modèles décrits en VHDL [CHR+ 03]. Enfin, l’apparition
d’outils commerciaux performants renforce cette tendance.
1.3. LA RECONFIGURATION
Cible
Point d’entrée
Représentation
interne
Point de sortie
Contraintes
Visualisation
Techniques
Gaut
FPGA
ASIC
C
VHDL comp.
DFG
SystemC compiler
FPGA
ASIC
SystemC
VHDL comp.
CDFG
Agility
FPGA
ASIC
C++
SystemC
CDFG
Catapult C
FPGA
ASIC
C++
SystemC
CDFG
VHDL RTL
niveau RTL
Netlist
Surface
Cadence
Latence
aucun
niveau RTL
Netlist (FPGA)
Mapping
Mémoire
Cadence/Latence
uniquement
rapport
niveau RTL
-Déroulage
de boucle
-Mémoire
distribuée
-Fusion de
ressources
oui
-Déroulage
de boucle
-Mapping
mémoire
-Fusion de
ressources
oui
E/S
Cadence
Latence
Gantt
-Déroulage
de boucle
-Mapping
mémoire
Largeur variable des
chemins de données
37
non
Cadence
Latence
Gantt
Graphique X-Y
Graphe Bar
-Déroulage
de boucle
-Mapping
mémoire
-Fusion de
ressources
oui
Tableau 1.3 — Comparatif des caractéristiques des outils de synthèse architecturale
1.3
La reconfiguration
L’adjectif « reconfigurable » apparaı̂t en 1985 avec la naissance du FPGA (Field Programmable
Gate Array) notamment le FPGA Xilinx XC2000 qui comportait à l’époque près de 1500 portes. Dans
un premier temps, il est uniquement utilisé pour la validation à moindre frais des applications visant un
ASIC (Application Specified Integrated Circuit). En effet, par son caractère réutilisable, le prototypage
sur une cible de type FPGA est plus simple et moins coûteux. Cependant, il est important de définir
ce qui est aujourd’hui désigné par le terme d’architecture reconfigurable de même que les différentes
cibles matérielles concernées. Les travaux de recherche en cours et les architectures proposées dans le
domaine universitaire sont détaillés par la suite. Enfin, après avoir évoqué les domaines d’applications
et la granularité requise, les tendances et les différentes orientations actuelles sont présentées.
1.3.1
Définition
Grâce à l’amélioration des techniques d’intégration et les multiples travaux de recherche dans
le domaine, la notion d’architecture reconfigurable a dépassé le cadre unique des circuits de type
FPGA et correspond maintenant à un ensemble de cibles hétérogènes. L’intérêt des architectures
reconfigurables est de bénéficier des atouts à la fois des circuits de type FPGA et des processeurs. Ces
derniers apportent leur flexibilité en terme de programmation tandis qu’un FPGA ajoute sa flexibilité
38
en terme d’utilisation des ressources. Ainsi, il est possible d’optimiser le traitement des tâches tout
en conservant une certaine part de flexibilité pour l’ensemble de l’architecture.
La notion de reconfigurable se prête à des définitions multiples qui varient d’un article à l’autre.
Ainsi, chez [Dav03] les circuits sont dits programmables et leur flexibilité est mesurée par leur potentiel
de reconfiguration, c’est à dire la capacité à adapter les ressources à un traitement donné. Chez [Bos04],
l’approche est légèrement différente, en effet, la distinction est faite entre architecture reconfigurable
et système programmable (processeur, DSP...). La différence réside dans le caractère astable ou multistable de l’architecture. Ainsi, une architecture programmable se configure à chaque cycle d’horloge à
la différence d’une architecture reconfigurable qui conserve le circuit plus longtemps dans le domaine
temporel avant d’être reconfiguré. Dans le cadre de l’étude, seule la première approche [Dav03] et donc
la notion de flexibilité est considérée. Cependant, ce critère seul ne permet pas d’évaluer objectivement
les avantages et les inconvénients de telle ou telle architecture. Il faut y ajouter des critères en termes
de coût, performances, consommation... (fig 1.22)
Flexibilité
Processeur
DSP
ASIP
Coûts
FPGA
ASIC
Performances
Figure 1.22 — Positionnement des solutions d’intégration les unes par rapport aux autres selon
différents critères
La reconfiguration concerne à la fois les ressources de traitement de données mais aussi les ressources de communication des architectures. Il est possible de la caractériser selon différents aspects.
Le taux de reconfiguration d’une architecture est défini par [Bos04] :
γ = Mec /Tec ≤ 1
(1.3.1)
39
où Mec est le nombre minimum d’éléments configurables à chaque reconfiguration, Tec est le nombre
total d’éléments configurables.
si γ = 1 alors l’ensemble de l’architecture est reconfiguré à chaque processus de reconfiguration, il
s’agit d’une reconfiguration totale. En revanche, plus la valeur de γ est faible, plus l’architecture peut
être modifiée partiellement de manière fine. Par exemple, chez Xilinx, seules les colonnes d’éléments
sont configurables limitant ainsi la finesse de reconfiguration.
Les besoins en terme de reconfiguration dépendent du domaine d’application, cela peut aller d’une
simple mise à jour occasionnelle, en passant par des changements plus fréquents pour une application
réseau, jusqu’à une nécessité de traitement temps réel pour les applications de télécommunications.
Si la modification de l’architecture intervient en dehors de l’exécution de l’application en vue d’une
amélioration ou d’une restauration de la configuration alors il s’agit d’une reconfiguration statique.
En revanche, si l’architecture doit être modifiée en cours de traitement afin de réaliser des tâches
particulières ponctuellement dans le temps, la reconfiguration est qualifiée de dynamique. Le but
peut être de déplacer spatialement certaines parties de l’architecture, de réaliser un traitement plus
rapidement en utilisant toutes les ressources disponibles ou bien encore de modifier des portions
de l’architecture. Dans tous les cas, le procédé vise une forte flexibilité et une optimisation en
surface sur la cible. Un moyen est de stocker en mémoire les configurations à effectuer (si elles sont
planifiées) sur le composant, ce type de reconfiguration est dite multicontexte. Il faut alors prévoir des
mécanismes de gestion [GBA03]. En cas d’autoconfiguration, l’initiation et la gestion du processus
peut être conduite par un processeur embarqué fonctionnant avec un système d’exploitation [WB04].
De manière générale, le processus de reconfiguration se déroule en deux étapes. Le chargement de la
configuration initiale s’effectue via un composant externe de type EEPROM ou un microcontrôleur.
La reconfiguration dynamique partielle s’effectue en interne en modifiant soit des blocs matériels
ou logiciels à partir d’un processeur embarqué. Les architectures présentées dans la section 1.1.2.3
abordent le problème en intégrant un processeur externe qui prend en charge le contrôle et la reconfiguration ou au contraire dissémine les parties de contrôles dans les différents niveaux hiérarchiques. A
priori, les architectures gros grain (c’est à dire travaillant sur des données arithmétiques) hétérogènes
sont avantageuses en termes de consommation de puissance et plus rapides lors d’une reconfiguration
dynamique. Elles sont particulièrement adaptées au traitement de tous les standards et normes de
télécommunications.
Les cibles architecturales existantes possèdent des ressources de calcul et d’interconnexions
permettant ces reconfigurations multiples. Il est possible de les répartir en 3 grandes familles : les
architectures programmables, les architectures reconfigurables et enfin les architectures hétérogènes.
Dans la littérature, le terme « Reconfigurable Computing » [Har01] est employé pour l’ensemble de
ces familles. La suite décrit rapidement les particularités, les performances et les nouvelles orientations
40
de chacune de ces architectures.
La particularité d’une architecture programmable est d’être configurable à chaque cycle car le
fait de lire une instruction entraı̂ne un comportement particulier à instant donné. Dans le cadre d’un
processeur généraliste de type RISC, la manipulation de données se fait de registre à registre tandis
que pour un DSP, le transfert se fera de mémoire à mémoire. L’aiguillage des données est également
géré par le programme. La gestion dynamique des unités fonctionnelles permet ainsi d’exécuter des
applications différentes bien que l’architecture reste identique. Ce type de cible suit une exécution
séquentielle qui pose un problème pour le traitement intensif de données. Malgré tout, les concepteurs
cherchent des moyens pour augmenter le taux de parallélisation des architectures via des solutions de
type VLIW[ISEF], voire ULIW[Avispa-IM2] ou encore superscalaire. Grâce à des extensions du jeu
d’instructions [ISEF], il est possible de définir de nouvelles instructions en utilisant la flexibilité de la
logique du processeur. Bien sûr, ce qui fait la force des microprocesseurs fait également leur faiblesse
puisque que les lecture/écriture des instructions ajoutées à la gestion de larges bancs mémoire
engendrent une consommation d’énergie importante.
Les cibles reconfigurables de type FPGA présentent un attrait certain de par leur caractère grain
fin. La forte densité d’intégration des dernières générations de composants favorise des traitements
massivement parallèles au niveau bit. En théorie, il est possible de reconfigurer dynamiquement les
bascules ou les LUTs mais en général les tailles des blocs reconfigurables sont plus conséquentes. Un
autre point important est le maintien des ressources de routage qui devient critique dans la gestion
des trames de configuration [refXilinxxapp290]. Dans le marché duopole des FPGA, Xilinx propose
actuellement des solutions plus abouties que son concurrent Altera. Xilinx [Not04] a été le premier
à fournir les outils pour reconfigurer dynamiquement ses composants Virtex 2 de manière totale ou
partielle. Dans ce cas, les informations concernant les éléments modifiés sont contenus dans des trames
de configuration de la matrice (une par colonne). Des travaux sur ces cibles tels que ceux de [HSKB06]
ont permis de définir des blocs modulaires, avec les ressources d’interconnexions associées, qui peuvent
être placés sur l’intégralité de la matrice (Virtex II). Un processeur est chargé du contrôle et de
la configuration dynamique (via le module matériel ICAP de Xilinx). Aujourd’hui, des composants
comme le Virtex 4 de chez Xilinx permettent de définir des modules reconfigurables de forme
rectangulaires ainsi que des ports d’E/S permettant d’utiliser des mécanismes de communications
avec les blocs élémentaires du FPGA . De plus, il est possible de modifier les parties du programme
et de la zone de données d’un processeur logiciel (Microblaze) en utilisant un processeur embarqué
(cas typique système multiprocesseur avec un processeur qui joue le rôle de contrôleur). L’intégralité
du code de l’application doit tenir dans le cache pour une vitesse d’exécution optimale.
41
Les architectures hétérogènes reconfigurables sont destinées à un traitement optimum de certains
types d’applications ou a contrario peuvent être suffisamment flexibles pour traiter un maximum
d’applications. L’intérêt est de conserver le caractère programmable des processeurs tout en ajoutant la modification du chemin de données pour, par exemple, effectuer un traitement intensif. Il
faut séparer la partie contrôle de la partie traitement pour entrevoir la possibilité d’une reconfiguration dynamique. L’agencement des ressources se fait autour d’une matrice d’interconnexions intégrant
des composants d’interconnexions (« switch box ») et des unités fonctionnelles diverses (ALU, mémoire, générateurs d’adresse). Typiquement, il est possible de classer ces architectures suivant leur
hétérogénéité, c’est à dire les architectures processeur-coprocesseur gros grain [BMN+ 01] ou grain fin
[HW97][Alt] conçue pour les applications de traitement multimédia d’une part et les architectures
dites « tuiles », résultant de l’association de nombreux modules permettant de supporter des applications multigrain [LST00] d’autre part. Un autre moyen de les caractériser, est d’identifier le réseau
d’interconnexions qui peut être soit linéaire et favoriser les traitements pipelinés [CFF+ 99] (ressources
de calculs voisines communiquent entre elles) ou alors hiérarchique et ainsi permettre des traitements
arithmétiques [TAJ00][Dav03][AR96]. Reste que les critères sont multiples et que chaque architecture
a ses particularités. Ainsi, tout dépend des besoins en terme de granularité des opérateurs, des réseaux d’interconnexions (topologie, souplesse), du potentiel de reconfiguration et de l’interaction avec
un processeur. Dans la suite, nous présentons quelques-unes des nombreuses architectures hétérogènes
reconfigurables illustrant ces choix.
1.3.2
Les architectures hétérogènes reconfigurables
Cette section vise à présenter une partie non exhaustive des travaux réalisés dans le monde académique sur les architectures hétérogènes reconfigurables. Les approches sont différentes selon le domaine
d’application et les choix effectués par les concepteurs (topologie du réseau, répartition du contrôle...).
Les architectures présentées sont :
– DART : Architecture reconfigurable dynamiquement pour applications de télécommunications
mobiles [Dav03].
– MorphoSys : Morphoing System [LSL+ 99].
– Systolic Ring [SCGT01].
DART : Architecture reconfigurable dynamiquement pour applications de télécommunications mobiles [Dav03]
L’approche de l’architecture DART (fig 1.23) conçue par l’équipe mixte R2D2 (IRISA à Rennes et
ENSSAT à Lannion) consiste à proposer un système flexible tenant compte à la fois des contraintes
algorithmiques et de la consommation d’énergie inhérentes aux différentes normes.
42
CONTROLEUR DES TACHES
Data Path Reconf.
CLUSTER 1
CLUSTER 2
CTRL
E/S
CLUSTER 3
CLUSTER 4
DMA
Ctrl
MEMOIRE
D’INSTRUCT°
C
O
N
T
R
O
L
E
U
R
MEMOIRE
CONFIG.
MEMOIRE DE DONNEES
Figure 1.23 — L’architecture DART
Data Path Reconf.
Data Path Reconf.
Data Path Reconf.
Data Path Reconf.
Config.
Mem.
FPGA
Data Path Reconf.
C
O
N
T
R
O
L
E
U
R
M
E
M
O
I
R
E
M
E
M
O
I
R
E
D
O
N
N
E
E
S
D
E
Figure 1.24 — Structure d’un cluster de l’architecture DART
Au niveau système, DART est composé de 4 clusters limitant ainsi la complexité du contrôleur
supervisant la répartition des tâches sur le circuit. En effet, ce contrôleur distribue les différentes
tâches sur les clusters dans le temps et selon la disponibilité des ressources. Pour chaque tâche, le
contrôle est partagé à la fois entre les clusters qui possèdent leur propre contrôleur interne et l’unité
de contrôle globale. De plus, l’architecture DART offre le moyen de répartir les unités de traitement
sans être pénalisée grâce à l’utilisation d’un réseau d’interconnexions hiérarchique. Ainsi, les unités
bas niveau restent connectées entre elles et ces sous-ensembles communiquent également entre eux.
Le principal avantage de cette découpe architecturale est l’exploitation potentielle du parallélisme.
Ce choix permet de fragmenter l’application en traitement plus simple et de mettre en évidence les
coeurs de boucle. Un cluster se compose : d’un coeur de FPGA et de 6 DPR (DataPath reconfigurable
fig. 1.24). Ainsi, deux niveaux de granularité (niveau arithmétique et logique) sont disponibles ce
qui est idéal pour les applications de traitement de signal. Le FPGA et les DPR accèdent au même
espace mémoire et leur reconfiguration est gérée par le contrôleur interne. Pour le premier, un
chargement de la configuration appropriée est effectué via le contrôleur DMA. Pour le second, la
reconfiguration est gérée par des instructions. Toutefois, la lecture de la mémoire d’instructions ne
se déroule pas à chaque cycle d’horloge mais uniquement à chaque changement de configuration.
Ceci entraı̂ne une économie importante de la consommation d’énergie. Les DPR sont donc des
structures gros grain organisées autour d’un réseau multi-bus, d’unités fonctionnelles, de registres
et de mémoires locales. Le « tout » est bien sûr flexible et reconfigurable suivant le traitement. Les
unités fonctionnelles sont des multiplieurs/additionneurs ou des ALU reconfigurables dynamiquement.
MorphoSys : Morphoing System [LSL+ 99]
Il s’agit d’une architecture hétérogène reconfigurable (fig. 1.25) de traitement visant les applications de
calcul intensif et de traitement parallèle de données. Développée au sein de l’université de Californie,
cette approche repose sur le concept du modèle hybride se situant entre processeur généraliste et
ASIC. Elle se compose d’une structure constituée de cellules reconfigurables, d’un processeur de
43
contrôle RISC et d’une interface mémoire à large bande passante (fig. 1.25). En ce qui concerne
la structure matérielle reconfigurable, il s’agit d’un ensemble d’éléments d’interconnexions et de
cellules configurables. Le fonctionnement des éléments et de leurs interconnexions est déterminé par
le contexte.
Figure 1.25 — L’architecture MorphoSys
Figure 1.26 — Structure d’une Reconfigurable Cell
TinyRISC est un processeur 32-bit personnalisé afin d’assurer la flexiblité pour MorphoSys.
Les cellules reconfigurables (RC pour reconfigurable Cell) (fig. 1.26) constituent en quelque sorte le
Data Path d’un processeur généraliste. Elles supportent des applications gros-grains et se composent
d’un ALU/multiplieur (MAC en un cycle), d’une file de 4 registres, d’un registre à décalage et de
2 multiplexeurs en entrée. La configuration de chaque RC est stockée dans la mémoire de contexte
et détermine l’orientation des données soit vers les bus et/ou vers les registres. Les structures
d’interconnexions sont de trois types : connexions entre RC, connexions entre lignes et colonnes,
connexions de lignes (express lanes) entre les 4 quadrants. Le tampon de trame est une mémoire
interne pour l’ensemble des cellules reconfigurables. Le contrôleur DMA est commandé par le
processeur TinyRISC et brasse les échanges de données entre la mémoire de contexte/tampon de
trame et la mémoire externe. Les étapes nécessaires à la reconfiguration sont les suivantes :
1. TinyRISC demande le chargement d’une configuration de la mémoire principale vers la mémoire
de contexte.
2. Le processeur demande le chargement des données de la mémoire principale vers le tampon de
trame.
3. Exécution d’un contexte sur la structure des RC.
4. Calcul et chargement des données futures à traiter.
5. Le processeur contrôle le mode de diffusion des contextes et fournit également des signaux de
44
contrôle au contrôleur DMA, à la mémoire de contexte et au tampon de trame.
Systolic Ring [SCGT01]
Conçue au laboratoire LIRMM de l’université de Montpellier 2, l’architecture du Systolic Ring
(fig. 1.27) est clairement orientée pour une reconfiguration à partir d’éléments gros grains en vue
de l’implémentation d’applications de traitement de signal. Ainsi, d’un point de vue architectural, le
Systolic Ring se compose de :
– une couche opérative constituée de noeuds de données (Dnode fig.1.28). Il s’agit d’éléments
DataPath composés d’un ALU et de registres et configuré grâce à des micro-instructions.
– une couche de configuration basée sur une RAM donnant la description des connexions des
Dnodes et des interconnexions de la couche opérative.
– un coeur de processeur RISC avec un jeu d’instructions adapté jouant le rôle du contrôleur
de configuration. Ainsi, il doit gérer non seulement la reconfiguration dynamique du réseau
de routage mais également l’échange des données entre un processeur externe et la partie
reconfigurable.
Figure 1.27 — L’architecture Systolic Ring
Figure 1.28 — Structure d’un Dnode
Cette architecture s’intègre sur un SoC et est à considérer comme un coeur d’IP orienté pour le
traitement intensif de données multimédia. L’avantage par rapport à un FPGA est une fréquence de
fonctionnement plus élevée et la mise à disposition d’opérateurs gros grain. L’architecture favorise les
applications traitement de signal et possède des chemins de données adaptés.
D’un point de vue fonctionnel, le système d’exploitation du processeur externe charge l’application donnée spécialement conçue pour la co-exécution. Un programme exécutable fonctionne sur
ce processeur et un code exécutable est chargée sur le contrôleur de configuration du Systolic Ring.
45
Le processeur charge d’abord le code destiné à la mémoire du contrôleur de configuration (gestion
dynamique de la configuration du réseau d’interconnexions à chaque cycle d’horloge). Puis il envoie
les données à la partie opérative et les récupère une fois le traitement accompli.
1.3.3
Les tendances dans le domaine des télécommunications
La multiplication des normes de communications (WIFI, WIMAX, téléphonie 3G, 4G, DVB 2...)
nécessite d’avoir des plate-formes suffisamment flexibles. En effet, la configuration matérielle doit
évoluer à chaque changement de standard et ainsi assurer la compatibilité avec les normes les plus
anciennes.
Le paradigme de la radio logicielle [Mit] se propose d’associer les fonctions des couches 1 et 2 des
protocoles de communication radioélectriques au moyen de développements logiciels en lieu et place
de composants classiques. Grâce à ce procédé, les stations de base et les terminaux peuvent dialoguer
ensemble à des prix de revient inférieurs de 20 % par rapport aux solutions classiques. Historiquement,
le système de la radio-logicielle se compose d’une alimentation, d’une antenne, un convertisseur de
radio fréquence multi-bandes et une puce contenant des convertisseurs (A/N et N/A), un processeur
généraliste réalisant les fonctions radio et des interfaces associées. L’intérêt de la radio logicielle est de
reconfigurer le système de télécommunication tout en conservant les éléments matériels déjà en place.
La reconfiguration est dynamique plus ou moins temps réel en fonction des variations des conditions
extérieures. Les équipements peuvent plus facilement assurer les fonctions de communication propres
à chaque norme (UMTS et cdma2000, par exemple). Les paramètres tels que la bande de fréquence,
la technique d’accès multiple, la modulation ou le codage peuvent être modifiés dynamiquement.
Ainsi, la manipulation des trains binaires de configuration des cibles FPGA fait l’objet de travaux
afin de préserver le fonctionnement et la reconfiguration de certains modules en cours de traitement
[DGR04][HSKB06]. Des flots de conception ont également été proposés pour répartir les tâches matérielles et logicielles pour les applications radio sur des plate-formes reconfigurables dynamiquement
[BNH06][DPL05].
D’autres travaux [PRR+ 03] sur la reconfiguration proposent la description d’un modem radio
flexible en intérieur, adaptatif et reconfigurable (FAR). Un système est dit adaptatif s’il est capable
de changer correctement les valeurs numériques d’un jeu de paramètres en fonction de l’application
demandée. Il est dit reconfigurable s’il peut être restructuré au niveau structurel et/ou architectural
par un changement non quantifiable (c’est à dire qui n’est pas caractérisé par des changements de
valeur numérique). Bien sûr, il est possible d’avoir les deux caractéristiques à la fois notamment lors
d’un changement de paramètre induisant une réorganisation architecturale.
La tendance est donc au développement de terminaux intelligents, autonomes, auto-reconfigurables
46
qui s’adaptent aux variations de l’environnement extérieur. Même si les deux approches diffèrent
sur la position des structures de contrôle (unités dédiées ou téléchargement logiciels hertziens), les
orientations de minimisation de la consommation de puissance, des fonctionnalités de traitement de
signal intelligentes pour réduire les coûts et de reconfiguration en temps réels se retrouvent dans les
deux cas.
Au niveau circuit, les méthodes de conception traditionnelles cherchant le compromis entre consommation/vitesse/surface sont mises à mal pour des terminaux devant supporter des traitements multiples et variés tels que les mobiles de nouvelle génération. Ainsi, les circuits permettant la reconfiguration dynamique de l’architecture en fonction des besoins semblent d’autant plus attractifs. Toutes
les architectures décrites précédemment apportent des réponses aux différents problèmes rencontrés.
1.4
Notre positionnement
La diversité et la complexité des applications de communications numériques, sous contrainte
d’exécution temps réel, dédiées à des systèmes embarqués ne cessent de croı̂tre avec l’évolution du
marché des télécommunications. L’évolution constante des caractéristiques de ces applications implique
la définition d’architectures systèmes devant s’adapter dynamiquement aux nouvelles fonctionnalités
(standards, services...). Notre positionnement tient compte du domaine de l’application choisie à savoir
le décodage des codes correcteurs d’erreurs. L’idée est de pouvoir choisir son type de code, la taille et
le pouvoir de correction. Il s’agit typiquement d’applications grain fin avec des entrées binaires ou qaires suivant le code. Les chemins de données sont donc dimensionnés en fonction des besoins. Sachant
que les traitements utilisent les mêmes implantations d’algorithme selon les codes choisis, l’idée est
de disposer d’une unité de contrôle « intelligente » fixant la configuration à utiliser. Nous avons donc
décidé d’utiliser les outils et l’approche d’Altera. En effet, au début de ces travaux, la société Altera
proposait des solutions plus matures que le concurrent Xilinx (expérience de la plateforme excalibur et
processeur logiciel plus évolué), c’est ce qui a principalement motivé notre choix. Ainsi, le système est
constitué d’un bloc matériel réalisant le traitement des données tandis que le contrôle est pris en charge
par une structure de type processeur gérant à la fois les échanges de données entre blocs et mémoires.
Le processeur RISC 32 bits logiciel embarqué est de type NIOS II, il est fourni par la société Altera
(tableau 1.2). L’accent est mis sur l’aspect flexibilité plus que sur l’aspect reconfigurable. Ainsi, même
si le processeur embarqué peut commander une reconfiguration totale du FPGA (y compris lui même),
dans notre cas, il doit seulement produire les signaux de contrôle déterminant le comportement du
bloc matériel qui prendra alors l’aspect souhaité. L’astuce repose sur les similitudes dans le traitement
des applications. L’unité de contrôle est donc chargée de faire commuter le circuit d’un mode de
fonctionnement à l’autre. On peut comparer cette approche à celle de [Kri05] qui après avoir repéré
les traitements identiques lors de la réception du WCDMA passe d’un mode à l’autre suivant les
contraintes d’utilisation. Le côté flexible et paramétrable a clairement été choisi dans notre approche
1.4. NOTRE POSITIONNEMENT
47
afin de bénéficier de plus de souplesse suivant les contraintes extérieures. Nous détaillons nos choix
plus en détail dans le chapitre 3.
L’intégration de structures hétérogènes reconfigurables, la forte complexité des applications et le
partitionnement des solutions architecturales nécessitent l’utilisation de nouveaux flots de conception.
En effet, il est désormais possible d’intégrer un système complexe dans un circuit reconfigurable SoPC
(System on a Programmable Chip). L’évolution des caractéristiques de notre application au cours du
temps implique la définition d’une architecture système devant s’adapter dynamiquement au décodage
approprié. C’est pourquoi, un flot de conception reposant sur l’élévation du niveau d’abstraction à
travers l’utilisation d’un langage haut niveau et de la synthèse d’architecture a été expérimenté. Le
développement de langage de description système tel que SystemC permet une transition plus naturelle
entre l’étude algorithmique d’un système et la définition de l’architecture associée. En effet, le flot
de conception traditionnel est discontinu pour une implémentation matérielle. Cette discontinuité
implique la réécriture de l’application validée au niveau algorithmique dans un langage de description
matériel (VHDL, Verilog). Notre idée consiste donc à utiliser un flot de conception de haut niveau
pour valider notre système constitué d’un processeur d’une part et un bloc matériel dédié d’autre
part. Ainsi, l’environnement de conception système System Studio de Synopsys a été utilisé. Dans un
premier temps, l’outil de synthèse de haut niveau SystemC Compiler, qui utilisait le langage SystemC,
a été employé puis dans un second temps les outils Agility Compiler de Celoxica et GAUT du LESTER.
Le but est de déterminer les apports d’une conception de haut niveau dans la mise au point d’une
architecture flexible de turbo décodage de codes produits.
Nous allons, dans le prochain chapitre, expliciter le domaine de l’application retenue c’est à dire
le décodage des codes correcteurs d’erreurs. Après un rappel sur les codes correcteurs d’erreurs et leur
rôle dans une chaı̂ne de communications numériques, les turbocodes en blocs sont détaillés. Puis, des
résultats en terme de performances sont fournis pour les codes produits pouvant être traités par une
architecture flexible.
CHAPITRE
2
Les codes correcteurs
d’erreurs - Turbocodes
Ce chapitre vise à expliciter le domaine de l’application considérée dans le cadre de cette thèse.
Ainsi, l’étude des turbocodes en blocs et leur implantation sur une puce silicium sont replacées dans
le cadre de la théorie du traitement de l’information et plus spécifiquement dans le cadre des codes
correcteurs d’erreurs. Dans un premier temps, la place de l’application dans une chaı̂ne de transmission numérique est précisée. Puis, les codes en blocs et plus particulièrement les codes utilisés dans
cette étude, c’est à dire les codes BCH binaires et Reed-Solomon q-aires, sont exposés. Les méthodes
de codage et de décodage sont décrites dans les deux cas. Enfin, la dernière partie présente les codes
produits et le décodage pondéré et itératif employé. Ce décodage constitue le turbo décodage. Les performances liées à la mise en oeuvre des ensembles codeurs/décodeurs considérés sont également données,
de même que l’intérêt et l’apport du système résultant.
2.1
Généralités
De nos jours, la transmission de l’information d’un émetteur à un destinataire se base principalement sur des techniques de transmission numérique. Il est en effet aisé de manipuler un signal
numérique et de lui appliquer les traitements souhaités. Un exemple de modélisation de chaı̂ne de
transmission numérique est donné sur la figure 2.1.
La source du message émet l’information sous la forme de symboles binaires.
2.1.1
Le codage/décodage de source
Le codage de source intervient pour compresser la quantité d’information émise. Les symboles émis
par la source sont convertis à partir d’un alphabet de symboles (ordinairement des bits) afin que ceux-ci
puissent être récupérés au cours de la réception sans modification à partir des données binaires (codage
50
CHAPITRE 2. LES CODES CORRECTEURS D’ERREURS - TURBOCODES
Source
Codage de
source
Codage canal
Modulateur
Canal de transmission
Destinataire
Décodage de
source
Décodage de
canal
Démodulateur
Figure 2.1 — Modélisation d’une chaı̂ne de transmission numérique
sans perte) ou alors avec une distorsion (codage avec perte). Le codeur de source réduit la redondance
contenue dans le message et minimise ainsi la quantité d’information utile à sa représentation. Le
décodage de source réalise l’opération duale, le message d’information est décompressé afin de retrouver
son équivalent avant la transmission.
2.1.2
Le codage/décodage de canal
Le codage de canal permet de réduire les erreurs liées à la transmission de l’information sur le
canal. Le principe consiste à rajouter des symboles de redondance aux symboles (binaires ou q-aires)
d’information suivant une loi fixée a priori et connue de la partie de réception. Ainsi, il devient
possible de détecter voir de corriger les éventuelles erreurs intervenues au cours de la transmission.
Malgré la complexité relative introduite par un tel dispositif, il est aujourd’hui présent dans beaucoup
de systèmes de télécommunications. Les codes correcteurs d’erreurs peuvent être repartis en deux
familles : les codes en blocs et les codes convolutifs.
Pour un code en blocs, la trame d’entrée de k symboles d’information est convertie en une séquence
de sortie sur n symboles (avec k < n). Le bloc de sortie sur n symboles dépend uniquement des k
symboles de la trame d’entrée. Les paramètres usuels du code sont k, n, R=k/n et la distance minimale
dmin. Ils seront explicités par la suite.
Pour un code convolutif, le codeur a un effet mémoire et prend pour entrée un symbole de m bits
et fournit en sortie un symbole de n bits. Chaque symbole de sortie est déterminé par l’entrée courante
et une partie de ν symboles mémorisés. Le rendement de ce code est R=m/n.
La notion de linéarité est fondamentale puisque un code linéaire forme un espace vectoriel linéaire.
2.1. GÉNÉRALITÉS
51
Dans ce cas, il est possible d’additionner deux mots de codes pour produire un troisième mot de code.
Le mot de code est en fait le mot élaboré à partir du message d’information et du code considéré.
Le processus de codage et décodage est simplifié puisqu’il est possible de définir n’importe quel mot
de code comme une combinaison linéaire des mots de code de référence (les vecteurs de base). Ainsi,
l’analyse des propriétés associées au mot de code « tout zéro » peut être généralisée à l’ensemble
des mots de code. C’est pourquoi, caractériser la performance d’un code linéaire revient à considérer
les effets de la transmission sur le mot de code tout à zéro. La distance de Hamming (ou poids
de Hamming) est alors équivalente au nombre d’éléments non nuls dans le mot. En pratique, la
plupart des techniques de codage utilise des codes linéaires. Le décodeur effectue l’opération inverse
du codeur. Pour un code en blocs, des méthodes algébriques sont utilisées pour la résolution de système
d’équations. Pour un code convolutif, les méthodes de résolutions se basent sur le parcours d’un treillis
(par exemple un décodage avec le maximum de vraisemblance pour l’algorithme de Viterbi).
2.1.3
Le modulation/démodulation
Le modulateur génère un signal porteur afin de transmettre les données codées. Dans le cas de la
modulation numérique, le message codé est transformé à partir d’un alphabet dont l’entrée correspond
à une partie du signal à transmettre (i.e. un symbole). Le signal porteur est une sinusoı̈de dont
on peut faire varier l’amplitude, la fréquence ou la phase indépendamment (ASK, FSK, PSK...) ou
simultanément (QAM) en fonction de l’information à émettre. Le démodulateur joue le rôle dual
du modulateur et transforme donc le signal reçu en un train binaire. La probabilité d’obtenir une
transmission sans erreurs dépend du rapport signal à bruit, des effets de distorsion et du processus de
détection. D’autre part, le démodulateur fournit une fiabilité de détection pour chaque symbole. Dans
ces travaux, la modulation considérée est une conversion binaire/q-aire de type BPSK (une modulation
de phase binaire), c’est à dire, que les éléments binaires transmis sont soit 1 (phase à 0˚) soit -1 (phase
à 180˚).
2.1.4
Le canal de transmission
Le canal représente le support de propagation du signal transmis. Le concept peut être élargi au
stockage de l’information (CD, DVD, disques durs, ...). Dans le cas d’un canal gaussien, la sortie est
le résultat de l’addition entre l’entrée du canal et un bruit blanc gaussien. D’autres perturbations
peuvent intervenir comme par exemple des interférences liées à d’autres transmissions, multi-trajets
qui nécessitent des modèles de canaux plus adaptés. Le canal est caractérisé par une probabilité de
transition P r(Xi /Yi ) avec Xi l’entrée binaire et Yi le symbole reçu. L’étude se limite dans notre cas
à un canal binaire symétrique et au canal à Bruit Blanc Additif Gaussien (BBAG).
– Le canal BBAG : il s’agit d’un canal à entrée binaire et sortie analogique. La sortie se représente
par une variable aléatoire continue y [Proakis89] :
52
y=x+b
où x est le symbole binaire émis et b est une variable aléatoire gaussienne centrée de variance σ 2
correspondant au bruit du canal. Les densités de probabilité de transition du canal s’écrivent :
1
−(y − xi )2
P (y/x = xi ) = ( √ ) × exp
2σ 2
σ 2π
(2.1.1)
La variance est fonction du rapport signal à bruit
σ2 =
1 Eb −1
( )
2 N0
(2.1.2)
où Eb est l’énergie moyenne utilisée pour transmettre un symbole binaire et N0 est la densité
spectrale de puissance monolatérale du bruit additif.
Les échantillons transmis au décodeur de canal sont, en général, numériques, quantifiés sur Q
bits. Ils résultent d’une conversion analogique/numérique.
– Le canal binaire symétrique : la valeur Q définie précédemment prend deux valeurs dans le
cas d’un canal binaire symétrique (CBS) sans mémoire et stationnaire. C’est le modèle le plus
simple utilisé dans la théorie des codes correcteurs d’erreurs. Il sert de point de comparaison
avec d’autres modèles. La décision en sortie du canal est ferme et non plus pondérée sur les
échantillons reçus. Les entrées et les sorties de ce canal discret sont binaires. Les erreurs de
transmission sont mutuellement indépendantes et apparaissent sur les entrées avec une probabilité p identique et invariante dans le temps. Les probabilités de transition du CBS sont
présentées sur la figure 2.2.
Figure 2.2 — Graphe de transition du canal binaire symétrique
La prise en considération du CBS est à la base du développement d’algorithme de décodage
algébrique basé sur le modèle mathématique des codes en blocs [Ber68][Mas65]. Pour des sorties
2.2. LES CODES EN BLOCS
53
de canal analogique, les algorithmes employés sont de type probabiliste. Ils sont dédiés à des
codes convolutifs [Vit67] et à des codes en blocs [Cha72][For66].
2.1.5
Performances d’un système de transmission : gain de codage
La qualité d’une transmission numérique se caractérise par la probabilité d’erreur par élément
binaire transmis, elle est notée PEb (ou PEs dans le cas de symboles q-aires). Cette probabilité est
fonction du rapport signal à bruit
Eb
N0
(ou SNR en anglais). Le tracé de la courbe reliant les points de
la PEb (à rapport signal/bruit donné) reflète directement la qualité de la transmission. L’obtention
de ces points nécessitent des simulations complexes qui permettent de mesurer le PEb à travers le
taux d’erreur binaire (TEB ). L’estimation du TEB est obtenue par simulation de la transmission de
N symboles binaires et l’évaluation après décodage du rapport
ne
N
où ne est le nombre de symboles
erronés après décodage en réception. La pratique a montré que l’obtention d’au moins une centaine
d’erreurs est nécessaire pour avoir une estimation correcte de la PEb .
En l’absence de codage sur un canal BBAG et pour une modulation BPSK, la probabilité d’erreurs
par élément binaire transmis s’écrit :
PEb
r
1
Eb
= erf c[
]
2
N0
(2.1.3)
où erfc(x) est la fonction d’erreur complémentaire définie par :
2
erf c(x) = √
π
Z
x
2
exp−t
(2.1.4)
+∞
L’efficacité du code correcteur d’erreur est déterminée en effectuant la comparaison des courbes en
sortie du décodeur de canal et en sortie du canal (en l’absence de codage). La distance entre les deux
tracés donne le gain de codage G (fig. 2.3), il s’exprime en décibel dB. G représente l’économie d’énergie
induite par l’utilisation d’un codage canal. Il est également possible de le voir comme l’amélioration
de la qualité de transmission.
2.2
Les codes en blocs
Les codes en blocs linéaires (ou codes de groupe) constituent un faible pourcentage de l’ensemble
des codes en blocs. Cependant, il s’agit des codes en blocs les plus utilisés en pratique. Une seconde
subdivision majeure permet de mettre en évidence les codes à polynôme générateurs et plus particulièrement les codes cycliques (codes BCH, codes Reed Solomon...). Pour certaines valeurs de longueur
de code n, un code à polynôme générateur présente une propriété de circularité, c’est-à-dire, qu’une
54
Figure 2.3 — Peb en fonction du SNR pour un code Golay (23,12) avec décision ferme pour une
modulation de type BPSK
permutation circulaire des symboles d’un mot de code génère un autre mot de code. Après la présentation de quelques définitions et propriétés des codes en blocs linéaires, cette partie se focalise sur les
codes cycliques et plus particulièrement sur les codes binaires BCH et q-aires Reed-Solomon.
2.2.1
Les codes en blocs linéaires
Un mot de code d’un code en blocs linéaire C(n, k) (avec k < n) construit sur un corps de Galois
(CG ou GF pour Galois Field en anglais) se compose de :
– k symboles composés de la séquence d’information à transmettre répartis dans l’ensemble du
message.
– n-k symboles calculés à partir d’une combinaison linéaire d’une partie prédéterminée des symboles d’information et eux aussi répartis dans le message. Il s’agit des symboles de parité ou de
redondance
C(n, k) est un sous espace vectoriel de dimension k de l’espace engendré par (CG)n , n correspond
à la longueur du code, k à sa dimension et k/n au rendement du code.
Le code est dit systématique si les k symboles représentant le message sont transmis. Les n − k
symboles restants sont les symboles de parité (fig. 2.4).
55
k symboles d’information
C0 C1 C2 C3
n-k symboles de redondance
Ck-3 Ck-2 Ck-1 Ck Ck+1
Cn-3 Cn-2 Cn-1
n symboles du mot de code
Figure 2.4 — Représentation d’un mot de code pour un code systématique
L’addition et la soustraction sont deux opérations identiques puisque le corps CG(2m ) est obtenu
à partir du corps CG(2) (={0,1}).
Le formalisme matriciel est utilisé pour expliciter la fonction de codage, la matrice génératrice [G]
du code C(n, k) se compose de k lignes et de n colonnes telle que [MS78] :
C = M. [G]
(2.2.1)
où M est le message d’information de dimension k et C est le mot de code de longueur n généré.
Une matrice de contrôle (ou de parité) H peut également être associée au code telle que :
t
t
[H] . [G] = [G] . [H] = [0]
(2.2.2)
donc pour tout mot de code de C :
t
t
S(C) = C. [H] = M. [G] . [H] = [0]
(2.2.3)
Cette dernière équation est importante puisqu’elle pose les bases de la détection et de la correction
des erreurs de transmission. Le vecteur S(C) est appelé syndrome de C. Un syndrome nul indique que
le mot reçu est un mot de code mais il ne garantit pas qu’il s’agit du mot de code émis. En effet,
un mot de code peut très bien se substituer à un autre en fonction du motif d’erreurs (ME ). Par
exemple, si R est le mot reçu, E le motif d’erreurs et C le mot de code émis, alors R = C ⊕ E et
t
t
t
S(R) = R. [H] = (C ⊕ E). [H] = E. [H] . Le syndrome dépend donc uniquement du motif d’erreurs.
56
Une autre caractéristique importante des codes en blocs linéaires est la distance de minimale de
Hamming (dmin ) qui désigne le plus petit nombre de bits différents entre deux mots de codes distincts.
Ainsi un code en blocs de distance (dmin ) est capable de détecter les motifs de (dmin -1) erreurs dans
un bloc de dimension n et de corriger tous les motifs de t erreurs :
(dmin ) − 1
t=
2
(2.2.4)
où le symbole b c représente la partie entière.
t est appelé le pouvoir de correction du code.
2.2.2
Les codes cycliques
Les codes cycliques bénéficient de toutes les propriétés des codes en blocs linéaires en plus de la
propriété de circularité. Pour rappel, pour tout décalage circulaire d’un mot de code, le mot généré
est aussi un mot de code. Si c = (c0 , c1 , . . . , cn−2 , cn−1 ) est un mot de code alors le décalage circulaire
de i produit c = (cn−i , cn−i+1 , . . . , c0 , . . . , cn−i−1 ) qui est aussi un mot de code.
Chaque mot de code c = (c0 , c1 , . . . , cn−1 ) du code C(n,k) est associé à un polynôme
c(x) = c0 + c1 x + . . . + cn−1 xn−1 .
Le polynôme générateur d’un code cyclique C est le mot de code de degré le plus bas g(x) =
g0 + g1 x + . . . + gr xr . Ce polynôme est unique et son degré est r = n − k. Tout mot de code c(x) peut
donc s’écrire sous la forme :
c(x) = m(x)g(x)
où m(x) = m0 + m1 x + . . . + mk−1 xk−1 est le message d’information à coder. g(x) est également un
facteur de xn + 1.
Un message m(x) peut être codé sous forme systématique à partir du polynôme générateur g(x)
de la manière suivante :
– multiplication de xn−k par m(x).
– division de xn−k m(x) par g(x) : xn−k m(x) = a(x)g(x) + b(x) avec b(x) reste de la division.
– addition de xn−k m(x) et b(x) :
c(x) = xn−k m(x) + b(x)
(2.2.5)
c(x) = xn−k m(x) + xn−k m(x)(mod(g(x))
(2.2.6)
ou
L’équation 2.2.5 donne le mot de code sous forme systématique et les composantes de b(x) sont
57
les symboles de redondance (ou de parité).
La matrice G du polynôme générateur peut s’écrire sous la forme :

g0
g1
···
gn−1
0
···
0




G=



0
..
.
g0
g1
···
gn−k
···
0
..
.
0
···
0
g0
g1
···







gn−k
Chaque mot de code peut donc s’écrire : c(x) = [m0 m1 · · · mk−1 ]G
Cette matrice peut être mise sous une forme systématique en effectuant des opérations linéaires
sur les lignes. La matrice de parité h(x) est obtenu à partir de g(x) de la manière suivante :
h(x) =
xn + 1
g(x)
(2.2.7)
h(x) est de degré k, elle se présente ainsi :

hk
hk−1
···
h0
0
···
0




H=



0
..
.
hk
hk−1
···
h0
···
0
..
.
0
···
0
hk
hk−1
···







h0
et nous avons donc c(x)H t = 0, ∀c ∈ C
Enfin, dans le cas des codes cycliques, le syndrome S(x) associé à un polynôme R(x) = C(x)+
E(x), de degré inférieur ou égal à n − 1, est le reste de la division de R(x) par g(x). Alors S(x) = R(x)
mod(g(x)) = s1 + s2 x + . . . + sn−k xn−k .
2.2.2.1
Les codes BCH binaires
Les codes BCH sont des codes cycliques, ils portent les noms de leurs inventeurs Bose, RayChaudhuri et Hocquenghem [BRC60][Hoc59]. Il s’agit de codes relativement performants, simples
à mettre en oeuvre et pour lesquels il existe un ensemble d’algorithme de décodage algébrique de
faible complexité. L’ensemble codeur/décodeur permet de construire un code cyclique et de corriger
un nombre de t erreurs dans un bloc de n symboles codés transmis. Les notions d’algèbre dans le corps
de Galois nécessaires à une compréhension plus approfondie des codes BCH ne sont pas présentées
dans cette étude. Le lecteur intéressé pourra se référer à [CC81] pour de plus amples informations.
Seuls les codes BCH binaires primitifs sont évoqués dans cette section. Leur longueur de codage n
peut s’écrire n = 2m − 1 (pour n ≥ 3).
58
Pour un code C(n,k) BCH binaire primitif de distance construite δ ≤ dmin , le polynôme générateur
g(x) admet δ-1 racines (αj , αj+1 , · · · , αj+δ−2 ) et s’écrit sous la forme :
g(x) = P P CM {mj (x), mj+1 (x), · · · , mj+δ−2 (x)}
(2.2.8)
où PPCM est le plus petit commun multiple.
* α est un élément primitif de CG(2m ) donc tous les éléments non nuls de CG(2m ) sont des
puissances successives de α (CG(2m )= {0, α0 , α1 , · · · , α2
m
−2
}) avec α2
m
−2
= α0 = 1 et α racine
n-ième de l’unité.
* j est un entier. Lorsque j = 1, le code BCH est primitif au sens strict. La distance δ construite
du code est impaire et sa distance minimale vérifie dmin ≤ δ = 2t − 1.
Le polynôme générateur d’un BCH primitif au sens strict s’écrit :
g(x) = P P CM {m1 (x), m2 (x), · · · , m2t−1 (x)}
(2.2.9)
Les caractéristiques d’un code BCH binaire primitif ayant un pouvoir de correction t sont donc
les suivantes :
– n = 2m − 1 (m ≥ 3).
– k ≥ 2m − 1 − mt et n − k ≤ k.
– dmin ≤ 2t + 1.
Afin d’obtenir des codes ayant une distance de Hamming plus importante, une méthode classique
consiste à ajouter un bit de parité globale (la somme modulo 2 de tous les autres bits). Il s’agit alors
d’un code BCH étendu de paramètre (n + 1, k, d + 1 = 2t + 2) obtenu à partir d’un code BCH primitif.
La distance du code étendu est augmenté de 1 et devient paire. Le bit de parité généré n’augmente
pas le pouvoir de correction du code mais facilite la détection des motifs d’erreurs non corrigibles.
Le rendement associé est légèrement inférieur à celui du code primitif mais le comportement à fort
rapport signal à bruit est meilleur.
Les symboles de redondance permettent le décodage des messages d’information reçus du canal. S
est le vecteur associé aux composantes du syndrome : S=(s1 , s2 , . . . , sn−k ) et S(x) est son polynôme.
Les valeurs des composantes du syndrome peuvent s’exprimer à partir des symboles du mot reçu R et
du corps de Galois considéré :
Si = R(αi ) =
n−1
X
rj (αi )j avec 1 ≤ i ≤ 2t
(2.2.10)
j=0
La fonction de décodage consiste à détecter et à corriger les erreurs en fonction du code BCH qui
a été construit dans la partie émettrice.
59
Le principe de décodage le plus simple à imaginer consiste à comparer le mot reçu Y avec les 2k
mots de codes possibles. La sélection de la distance de Hamming minimale entre le mot de code et Y
fournit alors le mot décodé. Ce critère est le maximum de vraisemblance a posteriori (MAP) et permet
de minimiser la probabilité d’erreur par mot de code. Cette approche est toutefois très complexe
pour des codes de longueurs importantes et des rendements élevés car le nombre de comparaisons
nécessaires devient prohibitif. Il convient alors d’employer des algorithmes plus appropriés.
Décodage dur des codes BCH
Le décodage dur consiste à exploiter les données binaires issues du canal obtenues par seuillage. Les
algorithmes de décodage utilisent les mots reçus du canal et en particulier les symboles binaires de
redondance pour estimer le mot émis. Les algorithmes utilisés varient en fonction du pouvoir de
correction t du code choisi. En fait, plus le pouvoir de correction augmente plus les algorithmes de
décodage correspondants sont complexes.
Un décodage ayant une complexité raisonnable est le décodage par syndrome. Il s’agit d’une
version simplifiée d’un décodage optimal. En effet, l’exploitation des symboles de redondance permet
de réaliser seulement 2n−k comparaisons par rapport aux 2k nécessaires classiquement. Ce type de
décodage est particulièrement intéressant pour des codes à rendement élevé. Le syndrome est constitué
de n − k composantes non-nulles en présence d’erreurs. Le mot reçu s’écrit :
R(x) = C(x) + E(x)
(2.2.11)
Comme indiqué précédemment (section 2.2.1), le syndrome dépend uniquement du motif d’erreurs.
C’est pourquoi il est donc envisageable de concevoir une correspondance entre la valeur du syndrome
e Le processus de décodage se fait alors en trois étapes :
et l’erreur estimée E.
– le calcul du syndrome S du mot reçu R ;
e;
– la détermination de l’erreur estimée E
e
– le décodage du mot R à l’aide de l’addition R+ E.
Ce processus s’applique à des codes ayant un pouvoir de correction de t=1.
Pour des pouvoirs de correction supérieurs à 1 (t>1), des méthodes de décodage dites algébriques
ont été proposées [For][Mas][Pet60]. Ces algorithmes ne permettent pas de corriger plus de t erreurs
dans un mot, il s’agit de décodage dit à distance bornée. Pour toutes ces méthodes, le processus de
décodage vise à résoudre l’équation-clef [Ber68] :
S(x)σ(x) = Ω(x)mod(xn−k )
(2.2.12)
60
où S(x) est le syndrome sous forme polynomiale, σ(x) est le polynôme localisateur d’erreurs de degré
≤ t et Ω(x) est le polynôme évaluateur d’erreurs.
La résolution de cette équation nécessite trois étapes élémentaires :
– le calcul des composantes du syndrome S ;
– le calcul du polynôme localisateur d’erreurs σ(x) et du polynôme évaluateur d’erreur Ω(x) ;
– la détermination des positions des erreurs.
Deux types de méthodes existent pour déterminer le polynôme localisateur d’erreurs. La méthode
directe utilise l’algorithme de Peterson [Pet60] et peut corriger jusqu’à trois erreurs par mot reçu
avec une complexité raisonnable (o(t2 )). Au delà (t > 3), des méthodes itératives plus complexes sont
nécessaires. Elles reposent sur l’algorithme de Berlekamp [Ber68]. Dans le cas d’un code BCH binaire,
la détermination des coefficients du polynôme évaluateur d’erreurs n’est pas nécessaire.
Dans un premier temps, l’algorithme de Berlekamp-Massey est présenté dans le cadre du décodage
des codes BCH. Il faut y adjoindre un algorithme de Chien pour déterminer les racines (c’est à dire les
positions des erreurs) et une vérification du mot de code élaboré. Dans un second temps, une version
modifiée et plus légère de l’algorithme de Peterson [Pet60][GZ61], dite PGZ, est abordée. Il est destiné
à des pouvoirs de correction plus faible typiquement t=1 et t=2. Cet algorithme a été étudié avec
l’aide de Mr Le Bidan du département Signal et Communication de l’ENST-Bretagne [Bid]. Une étude
similaire a également été menée dans [WHW01].
– L’algorithme de Berlekamp-Massey vise à résoudre l’équation clé (2.2.12) à partir des composantes d’un syndrome de manière à identifier les coefficients du polynôme localisateur d’erreurs
d’un des vecteurs tests. Dans cette étape, une version sans inversion de matrice [Bur71], moins
coûteuse en temps d’exécution et en ressources, est utilisée.
∆(i) correspond aux coefficients du monôme xi dans le produit S(x).σ (i) (x) à la i-ème itération
de l’algorithme :
∆(i) = Si +
t−1
X
(i)
Si−k .σk
k=0
Une étape préliminaire permet d’initialiser les variables :
– σ (−1) (x) = 1 et ∆(−1) = S1 .
– les variables internes d(−1) = 0 et β = 1
Pour (i allant de 0 à 2t − 1)
– σ (i) (x) = β.σ (i−1) (x) − ∆(i) .e
σ (i−1) (x)
P
(i)
t−1
– ∆(i) = Si + k=0 Si−k .σk
Si ∆(i) 6= 0 et d(0) ≥ 0 alors σ
e(i) (x) = σ (i−1) (x), β = ∆(i) , d(i) = −d(i−1) − 1
Sinon σ
e(i) (x) = σ
e(i−1) (x), d(i) = d(i−1) + 1
fin si
(2.2.13)
61
fin pour
Les 2t coefficients de σ(x) sont disponibles à la fin du traitement. Dans le cas particulier du
code BCH, l’égalité Si2 = S2i implique deux fois moins d’itérations de l’algorithme.
Le calcul des racines du polynôme localisateur d’erreurs correspond physiquement à l’évaluation
des positions des erreurs dans le bloc des N bits transmis. Ce calcul revient à rechercher les
racines de σ(x) parmi les 2m premiers éléments du corps de Galois GF(2m ). Dans ce cas, un
algorithme itératif appelé algorithme de Chien est retenu. Il est basé sur l’évaluation d’un
polynôme ayant les mêmes racines que le polynôme localisateur d’erreur σ(x). La condition à
satisfaire pour que αn−i soit racine du polynôme est :
t
X
σk .αik = σt
(2.2.14)
k=1
où i ∈ [0 ;t]
Lorsqu’une erreur est détectée au cours d’une itération i alors la position de l’erreur est i et
l’élément Xk = αn−i est la racine du polynôme localisateur d’erreur. αn−i est utilisé pour le
calcul de la valeur de l’erreur.
Pour la vérification de la parité, il s’agit simplement d’utiliser un opérateur XOR au fur et à
mesure de l’arrivée des symboles. Le mot doit également être un mot de code.
– L’algorithme PGZ pour un code binaire BCH vise résoudre le système suivant :

S1
S2
···
Sν







S2
..
.
S3
..
.
···
..
.
Sν+1
..
.
Sν
Sν+1
···
S2ν−1


σν


  σν−1

  ..
 .

σ1

Sν+1

 
 
  Sν+2
=
  ..
  .
 
S2ν







En prenant :

S1
S2
···
Sν




Mν = 



S2
..
.
S3
..
.
···
..
.
Sν+1
..
.
Sν
Sν+1
···







S2ν−1
Il peut être montré que Mt [Bla03] est une matrice non singulière si et seulement si la dimension
ν est égale au nombre d’erreurs ν introduites par le canal. Le décodage s’effectue alors de la
manière suivante :
– calculs successifs des déterminants de Mt , Mt−1... jusqu’à l’obtention d’un déterminant nul.
Ce résultat fournit le nombre d’erreurs ν ;
62
– résolution du système linéaire (identité de Newton, pivot de Gauss...) afin de déterminer les
coefficients de σ(x) ;
– identification des racines de σ(x) et par conséquent des positions d’erreurs.
Le décodeur doit également reconnaı̂tre son incapacité à détecter et corriger des erreurs. Malgré
tout, il existe des dysfonctionnements de l’algorithme qui annoncent un décodage valide lorsque
le mot décodé n’est pas un mot de code. Certaines précautions doivent donc être prises [SS94].
En résumé, les solutions adoptées dans notre étude pour le décodage des codes BCH binaires
primitifs de faible pouvoir de correction sont :
1. l’utilisation des composantes du syndrome pour corriger t = 1 erreur.
2. l’algorithme PGZ pour déterminer la position de t = 2 erreurs dans le mot reçu. Le déroulement de l’algorithme est le suivant :
Dans la suite, S1 , S2 , S3 , S4 désignent les quatre composantes du syndrome calculé. Le
polynôme σ(x) s’écrit simplement sous la forme d’un polynôme de degré 2 :
σ(x) = (x + X1 )(x + X2 ) = x2 + σ1 x + σ2
(2.2.15)
σ1 et σ2 sont alors les solutions du système :


S1
S2
S2
S3


σ2
σ1


=
S3
S4


Le déterminant du système est ∆2 = det(M2 ) = S1 S3 + S22 .
Plusieurs cas sont possibles :
– ∆2 = 0, le décodeur considère qu’une seule erreur est commise comme pour le cas t=1.
Le critère 2.2.16 permet de vérifier qu’il ne s’agit pas d’un échec de décodage :
σ 1 S3 + S4 = 0
(2.2.16)
– ∆2 6= 0, il y a deux erreurs dans le mot reçu, σ1 et σ2 valent :
σ1 =
S1 S4 + S 2 S3
S2 S4 + S32
, σ2 =
∆2
∆2
(2.2.17)
Si la racine est solution double alors un échec de décodage est déclaré.
Il reste à déterminer les racines X1 et X2 de σ(x). La recherche des racines de σ(x) s’effectue généralement en testant chaque élément non nul du corps de Galois, tel que dans
l’algorithme de Chien [Chi94]. Cela est très coûteux en nombre de calculs pour des corps de
Galois d’ordre élevé. Cependant, Berlekamp [Ber68] et Gill [Gil05] ont décrit une technique
simple utilisant une table précalculée à 2m entrées, de taille m.2m bits pour un code défini
63
dans CG(2m ). Le but est donc de déterminer les deux solutions distinctes existantes X1 et
X2 de l’équation de second degré :
σ(x) = x2 + σ1 x + σ2 = 0
(2.2.18)
un changement de variable x = σ1 donne alors :
σ12 (u2 + u + c) = 0, avec c = σ2 /σ12
(2.2.19)
Alors résoudre σ(x) = 0 est équivalent à résoudre u2 + u + c = 0, de plus les solutions sont
du type U1 et U2 = U1 + 1 alors :
(U1 + 1)2 + (U1 + 1) + c = (U12 + U1 + c) + (1 + 1) = U12 + U1 + c = 0
(2.2.20)
Il suffit donc de trouver une seule solution pour avoir les deux racines de σ(x) ce qui donne :
X1 = σ1 U et X2 = σ1 (U + 1) = X1 + 1
(2.2.21)
Décodage pondéré des codes BCH
Le décodage dur des codes BCH présente une faible complexité mais les performances sont sous
optimales. En effet, le décodeur n’exploite que les entrées binaires obtenues par un seuillage des
données pondérées fournies par le canal de transmission. Cela correspond à un décodage dur. L’idée
est donc de conserver l’information pondérée fournie par le canal et de l’exploiter lors du décodage
afin d’obtenir de meilleures performances. Ainsi, le décodage MVP permet de sélectionner le mot
de code parmi les 2k possibles qui minimise le carré de la distance euclidienne avec le vecteur reçu.
Si R = {r0 , r1 , ..., rn−1 } est le mot reçu alors le mot de code recherché C j = {cj0 , cj1 , ..., cjn−1 } doit
2
2 Pn−1 minimiser la quantité R − Cj = k=0 rk − cjk .
Les méthodes classiques de décodage algébrique ne peuvent pas exploiter des données pondérées.
D’autres algorithmes tentent d’approcher le décodage de type MVP [HR76][Wel71][BM78]. Toutefois,
du fait de leur complexité, peu de ces algorithmes ont été utilisés. L’algorithme de Chase [Cha72]
demeure à ce jour le plus approprié pour le décodage pondéré des codes BCH. Il est explicité dans la
section 2.3.2.
2.2.2.2
Les codes Reed-Solomon
Les codes Reed-Solomon (RS ) sont des codes cycliques et plus précisément des codes BCH non
binaires, ils portent le nom de leurs inventeurs Irving Reed et Gustave Solomon. Il s’agit de codes
64
adaptés à la correction de paquets d’erreurs [RR72]. L’ensemble codeur/décodeur permet de construire
un code cyclique et de corriger un nombre de t symboles q-aire erronés, fixé par l’algorithme de
décodage, dans un bloc de n symboles q-aire codés transmis. Les codes RS font partie de la famille des
codes séparables à distance maximale, ils sont optimaux au sens du critère de la distance minimale
(MDS).
Les codes RS sont constitués de symboles q-aire (avec q = pm ). Généralement des éléments binaires
sont considérés c’est à dire p = 2 et par conséquent q = 2m . Chaque symbole q-aire d’un code RS est
représenté par un m-uplet d’éléments binaires. Le code est défini par son polynôme générateur g(x)
dont les coefficients sont exprimés dans CG(q) (={0,1,α, α2 , · · · , αq−2 }).
Les caractéristiques d’un code Reed-Solomon ayant un pouvoir de correction de t symboles q-aires
sont les suivantes :
– n= q - 1 (m≥3) est la longueur du code.
– k = n -2t est la dimension du code.
– δ = 2t + 1 est la distance de Hamming.
– δ = n - k + 1.
Les codes RS ont une meilleure distance minimale à rendement de codage fixé par rapport à des
codes BCH binaires où δ ≤ (n − k + 1).
Décodage dur des codes RS
Comme pour le décodage des codes BCH binaires, le décodage revient à résoudre l’équation-clef
(2.2.12).
Dans ce cas, la résolution de cette équation nécessite quatre étapes élémentaires :
– le calcul des composantes du syndrome S ;
– le calcul du polynôme localisateur d’erreur σ(x) et du polynôme évaluateur d’erreur Ω(x) ;
– la détermination des positions des erreurs ;
– le calcul des amplitudes de ou des erreurs. La valeur de l’erreur est fournie sur q bits, il s’agit
de la correction à apporter au symbole erroné.
Classiquement, la correction des codes RS intervient sur un ou plusieurs octets (t = 8 et CG(28 )).
Les processus de décodage utilisent des algorithmes complexes tels que celui de Berlekamp pour calculer
le polynôme localisateur d’erreurs et de Chien pour déterminer les racines. L’algorithme PGZ est le
plus adapté pour ces faibles pouvoirs de correction (un ou deux symboles). Les symboles d’un code
Reed-Solomon étant q-aires, la localisation des erreurs n’est pas suffisante comme dans le cas des codes
BCH. Il est nécessaire de pouvoir estimer également leurs amplitudes afin d’effectuer les corrections
associées. Seul la détermination du polynôme évaluateur d’erreurs et le calcul des valeurs des erreurs
sont abordés puisque les autres étapes ont été définies dans la section précédente.
65
– Pour l’algorithme de Berlekamp-Massey, le calcul des coefficients du polynôme ω(x) s’effectue
de manière itérative comme pour la détermination des coefficients de σ(x). Les deux calculs
peuvent être réalisés parallèlement pour diminuer la latence de décodage.
L’évaluation des amplitudes de l’erreur Ei nécessite l’utilisation de l’algorithme de Forney. La
valeur de chaque erreur est donnée par :
Ei = Ω(αN −i )/σ 0 (αN −i )
(2.2.22)
avec
– σ 0 (x) : dérivée du polynôme localisateur d’erreurs,
– Ω(x) : polynôme évaluateur d’erreurs,
– αN −i : racine de σ(x).
σ(x) est égal à :
σ(x) = σ0 + σ1 .x + ... + σt .xt
(2.2.23)
σ 0 (x) = σ1 + 2.σ2 .x + 3.σ2 .x2 + ... + t.σt .xt−1
(2.2.24)
σ 0 (x) = σ1 + σ3 .(αN −i )2 + σ5 .(αN −i )4 + ... + σt−1 .(αN −i )t−2
(2.2.25)
soit :
donc pour x = αN −i :
D’autre part, Ω(αN −i ) est égal à :
Ω(αN −i ) = Ω0 + Ω1 .(αN −i ) + Ω2 .(αN −i )2 + ... + Ωt .(αN −i )t
(2.2.26)
– A la différence du décodage BCH binaire, l’algorithme de décodage RS q-aire PGZ est utilisé à
la fois pour corriger t = 1 et t = 2 erreurs. Une étape supplémentaire est nécessaire, elle consiste
à résoudre complètement l’équation-clef pour obtenir les coefficients du polynôme évaluateur
d’erreurs et obtenir les valeurs de ces erreurs (E1 , E2 , . . . , Eν ). Elles sont solutions du système
suivant :

X1
X2
···
Xν

E1


S1


 2
 X1

 ..
 .

X1ν
X22
..
.
···
..
.
Xν2
..
.
E2
..
.
···
 
 
 
=
 
 
 
S2
..
.
X2ν














X2ν−1
Eν
Sν
Les méthodes de décodage pour une erreur et deux erreurs dans un mot reçu sont explicitées
dans la suite :
1. Processus de décodage du PGZ pour t=1
66
Soit S1 , S2 les deux composantes du syndrome calculé, le polynôme σ(x) s’écrit alors :
σ(x) = x + X1 = x + σ1
(2.2.27)
alors X1 = σ1 , l’inconnue σ1 est solution du système :
[S1 ] [σ1 ] = [S2 ]
(2.2.28)
Ce système a une solution si et seulement si ∆1 = det(M1 ) = S1 6= 0, alors :
X1 = σ(x) = S2 /S1
(2.2.29)
Si X1 = 0 et donc S2 = 0, il s’agit d’un échec de décodage. La valeur de l’erreur, notée E1 ,
est la solution du système :
[X1 ] [E1 ] = [S1 ]
(2.2.30)
E1 = S12 /S2
(2.2.31)
E1 a pour valeur :
Il faut noter que cette solution n’est valable que si S1 6= 0 et S2 6= 0.
2. Processus de décodage du PGZ pour t=2
La première partie est identique au cas du BCH pour la détermination du polynôme localisateur d’erreurs(voir 2.2.2.1). Les coefficients de σ(x) sont donc de la forme :
σ1 =
S1 S4 + S2 S3
S2 S4 + S32
, σ2 =
∆2
∆2
(2.2.32)
et les positions des erreurs sont données par :
X1 = σ1 U et X2 = σ1 (U + 1) = X1 + 1
(2.2.33)
Si la racine est solution double, un échec de décodage est déclaré. Il reste à déterminer les
valeurs des erreurs. Elles sont les solutions du système :


X1
X2
X12
X22


E2
E1


=
S1
S2


soit :
E1 =
S1 X 1 + S2
S1 X 2 + S 2
et E2 =
X1 (X1 + X2 )
X1 (X1 + X2 )
(2.2.34)
Ces deux solutions sont exploitables si et seulement si E1 6= 0 et E2 6= 0. De plus, il faut
X1 6= S2 /S1 et X2 6= S2 /S1 .
2.3. LES CODES PRODUITS ET LE TURBO DÉCODAGE
67
Décodage pondéré des codes RS
Comme pour le décodage dur des codes BCH, le décodage dur des codes RS a une faible complexité
pour des performances sous optimales. L’idée est de conserver l’information pondérée fournie par le
canal et de l’exploiter lors du décodage afin d’obtenir de meilleures performances. Le décodage MVP
permet de sélectionner le mot de code parmi les q k possible qui minimise le carré la distance euclidienne
avec le vecteur reçu. Ici, les notations sont R pour le mot reçu et C le mot de code émis (cij = +1 ou
−1) tel que :
r11
r12
···
r1n



 r21
R=
 ..
 .

rm1
r22
..
.
···
..
.
r2n
..
.
rm2
···







rmn
c11
c12
···
c1n



 c21
C=
 ..
 .

cνm1
c22
..
.
···
..
.
c2n
..
.
cm2
···







cmn


2
2 Pn Pm Le but est de déterminer le mot de code minimisant la quantité : R − Cj = k=1 l=1 rkl − cjkl .
En pratique, l’algorithme de Chase [Cha72] reste, avec l’algorithme de Suda [McE03], un des
algorithmes les mieux adaptés au décodage pondéré des codes RS pour une complexité réduite. Il est
explicité dans la section 2.3.2.
2.3
Les codes produits et le turbo décodage
Après une présentation générale sur les codes produits, les méthodes de décodage sont exposées.
Dans un premier temps, le décodage pondéré et notamment l’algorithme de Chase correspondant sont
décrits. Puis, l’adaptation pour le décodage à entrées et sorties pondérées et le rebouclage pour un
processus itératif sont explicités.
2.3.1
Code produit
Inventés par Elias en 1954 [Eli54], les codes produits aussi appelés codes en blocs sont des codes
correcteurs d’erreurs performants avec des rendements et des distances minimales élevées. Ils sont
construits par concaténation série de deux ou plusieurs codes en blocs linéaires.
Soit C1 (n1 , k1 , δ1 ) et C2 (n2 , k2 , δ2 ) deux codes en blocs linéaires systématiques, les bits d’information peuvent être placés dans une matrice de taille (k1 × k2 ). Les lignes sont codées par le code C1 ,
68
il résulte alors une matrice de dimension (n1 × k2 ) éléments. Les colonnes de cette nouvelle matrice
sont alors codées par le code C2 ce qui produit une matrice de dimension (n1 × n2 ). Il s’agit donc
d’une concaténation série de deux codes en blocs avec un entrelaceur régulier agissant sur les lignes et
les colonnes. La figure 2.5 représente la matrice d’un code produit. Si le code constituant est un code
BCH binaire, alors la valeur q est égale à 1. En revanche, si le code est un Reed Solomon, alors q est
égal à m. L’intersection d’une ligne avec une colonne de la matrice est un élément binaire (resp. un
symbole q-aire). La matrice d’information est constituée de k1 × k2 × q bits de données.
q bits
Redondance ligne
k1
n2
Matrice M
k2 des symboles
d’information
Redondance
colonnes
Redondance
de la redondance
n1
Figure 2.5 — Constitution de la matrice associée à un code produit
Toutes les lignes de la matrice globale M (n1 ×n2 ) sont des mots de code de C1 et toutes les colonnes
sont des mots de code de C2 . Les caractéristiques du code produit C est fonction des caractéristiques
des codes C1 et C2 :
– n = n1 × n2 , la longueur du code.
– k = k1 × k2 , la dimension du code
– δ = δ1 × δ2 , la distance associée.
Les caractéristiques du code produit sont le produit des caractéristiques des codes composants. Le
rendement R de codage du code C résultant est R = R1 × R2 avec Ri = ki /ni . La construction
particulière du code rend possible le décodage de toutes les lignes et toutes les colonnes. Au lieu
d’envisager un décodage global de l’ensemble du message, il est possible d’utiliser deux décodeurs
pour respectivement les codes C1 et C2 . Dans notre étude, les codes composants C1 et C2 constituant
le code produit sont identiques. Ce choix permet d’utiliser le même décodeur élémentaire pour décoder
les lignes et les colonnes de la matrice considérée. Deux familles de codes cycliques sont utilisées : BCH
et Reed-Solomon. Ces deux familles doivent être adaptées à un traitement à entrées pondérées et sorties
pondérées (EPSP). Si le codage est relativement simple, le décodage le reste également dans le cas
69
d’un décodage ferme. En revanche, une adaptation est nécessaire dans le cas d’un décodage à entrées
et sorties souples.
2.3.2
Décodage pondéré des codes produits
Le choix en terme d’algorithme de décodage est large (Chase, Viterbi, Hartman et Rudolph), cependant, il convient de respecter un compromis performance/complexité pour bénéficier d’une solution
avantageuse.
L’algorithme de Chase est un algorithme permettant d’approcher les performances d’un estimateur de type MVP pour une séquence donnée tout en conservant une complexité raisonnable. A
l’origine, cet algorithme n’est prévu que pour les codes binaires, il a donc été adapté pour traiter
les codes Reed-Solomon s’appliquant à des codes q-aires[Aı̈t98]. Les notations sont les suivantes : C
désigne le mot de code émis, R le mot reçu du canal et Y le mot binaire obtenu après seuillage des
éléments de R (yj = signe(rj )).
Au lieu de vérifier tous les mots de codes possibles lors du décodage en utilisant le critère du
MVP, l’algorithme de Chase retient seulement les mots de code les plus probables avant d’appliquer
une décision. Ces mots de code candidats se situent à l’intérieur d’une sphère de rayon δ −1 centrée sur
Y, elle est notée B(Y, δ −1). Pour atteindre les mots de code C l se trouvant à l’intérieur de B(Y, δ −1),
il faut construire des séquences de test à partir de Y tel que Yl = Y ⊕ Tl où les Tl sont les séquences
de test dont le poids de Hamming est inférieur ou égal à bδ/2c (fig 2.6).
C4
R
C1
Y
2(į-1)1/2
2(t)1/2
C2
C3
Figure 2.6 — Illustration du décodage de Chase
Chase a proposé trois variantes pour son algorithme [Cha72]. La deuxième version est celle que
nous avons considérée comme offrant le meilleur compromis performances/complexité. Pour construire
les séquences de test, la procédure consiste à repérer les positions des p (=bδ/2c) composantes les moins
70
fiables de Y à partir du message reçu R. La mesure de la fiabilité est donnée par le logarithme du
rapport de vraisemblance (LRV)
λj = ln
P r {cj = +1/rj }
P r {cj = −1/rj }
(2.3.1)
Il a été montré que l’utilisation des LRV permet d’avoir des performances optimales quelque soit
le canal et la modulation employée [For66]. Pour un canal gaussien et une modulation MDP-2, le LRV
est égal à :
λj =
2
rj
σ2
(2.3.2)
Pour un canal de transmission stationnaire, la valeur absolue du λj normalisé, rj0 donne la mesure
de la fiabilité yj :
rj0 =
σ2
|rj |
2
(2.3.3)
Plus la valeur de rj0 est grande, plus la distance par rapport au seuil de décision sur yj et la fiabilité
sont grandes.
L’algorithme de Chase se déroule de la manière suivante :
1. Localisation des p composantes les moins fiables.
2. Détermination de la première séquence de test Y0 en effectuant une décision ferme à partir de
R. Puis la construction des séquences de test est réalisée à partir des combinaisons d’erreurs en
fonction des composantes les moins fiables.
3. Décodage algébrique des 2p vecteurs de test Yl donnant le sous-ensemble des mots Cl nécessaires
au décodage pondéré.
Les variantes de l’algorithme de Chase concernent l’élaboration des motifs de test.
2.3.3
Décodage itératif des codes produits
Le principe des turbocodes en blocs repose sur le décodage itératif des codes en blocs concaténés.
Le code retenu pour les turbocodes en blocs (TCB ) est le code produit proposé par Elias en 1954,
c’est à dire une concaténation série de code en blocs avec un entrelacement uniforme. Il se prête
idéalement au décodage itératif consistant à décoder successivement les lignes puis les colonnes. De
plus, le décodage pondéré permet un gain de codage asymptotique par rapport à un décodage dur entre
1,5 et 2 dB. Ainsi, l’algorithme de Chase est un bon compromis performance/complexité. Toutefois,
une adaptation est nécessaire pour qu’il puisse fournir des sorties pondérées et fonctionner de manière
itérative. Cette adaptation porte le nom de l’algorithme de Chase-Pyndiah [PGPJ94]. La suite de
cette section explicite la modification de l’algorithme.
En sortie du décodeur, chaque symbole dj de la décision D est associé à une fiabilité. Elle peut
être obtenue à partir du rapport de vraisemblance (plus exactement son logarithme noté LRV) donnée
71
par :
λj = ln
P r {ej = +1/R}
P r {ej = −1/R}
(2.3.4)
La suite du calcul correspond au cas de la pondération des décisions à la sortie d’un décodeur
binaire BCH. Cette propriété est extensible aux décodeurs durs RS [Aı̈t98].
Le code utilisé pour coder les lignes des mots des codes produits est noté C(n, k, δ). C i =
i i
c0 , c1 , . . . , cin−1 (avec i = 1, 2, ..., 2k ) sont les mots de code de C.
En prenant cji ∈ {−1, 1} au lieu de cji ∈ {0, 1} (notation équivalente) pour simplifier les notations,
alors le numérateur s’écrit :
X
P r ej = +1, E = Ci /R
(2.3.5)
P r ej = +1/E = Ci , R P r E = Ci /R
(2.3.6)
P r {ej = +1/R} =
Ci ∈C
D’après la formule de Bayes :
P r {ej = +1/R} =
X
Ci ∈C
De plus P r ej = +1/E = Ci , R = P r ej = +1/ej = cij =


1
si cij = +1

0
si cij = −1
alors (2.3.6) s’écrit :
X
P r {ej = +1/R} =
Ci ∈C
P r E = Ci /R
(2.3.7)
cij =+1
En notant S +1(j) l’ensemble des mots de code Ci de C vérifiant cij = +1, alors l’équation (2.3.7)
devient :
P r {ej = +1/R} =
X
P r E = Ci /R
(2.3.8)
Ci ∈S +1(j)
et le dénominateur de l’expression 2.3.4 a pour expression :
P r {ej = −1/R} =
X
P r E = Ci /R
(2.3.9)
Ci ∈S −1(j)
En appliquant à nouveau la formule de Bayes :
f (R/E = Ci ).P r(E = Ci )
P r E = Ci /R =
f (R)
(2.3.10)
Les mots de code sont équiprobables P r E = Ci = 1/2k et pour un bruit blanc gaussien d’écart
72
type σ :
f (R/Ci ) =
1
1
√
exp− 2σ2
n
(σ 2π)
X
P r {ej = +1/R} =
Ci ∈S +1(j)
1
2k f (R)
Pn
i 2
l=0 (rl −cl )
(2.3.11)
i 2
1
1
√
exp− 2σ2 kR−C k
n
(σ 2π)
(2.3.12)
i 2
1
1
√
exp− 2σ2 kR−C k
n
(σ 2π)
(2.3.13)
et
X
P r {ej = −1/R} =
Ci ∈S −1(j)
1
2k f (R)
alors, le LRV du j-ième élément binaire de D s’écrit :


2
− 2σ12 kR−Ci k 
P i
+1(j) exp
λj = ln PC ∈S
− 2σ12 kR−Ci k2 

Ci ∈S −1(j) exp
(2.3.14)
Soit C+1(j) le mot de code appartenant à S+1(j) à distance euclidienne minimale de R et C−1(j) le
mot de code appartenant à S−1(j) à distance euclidienne minimale de R, il est alors possible de mettre
le LRV sous la forme :
λj =
P
2 2
1 −1(j) +1(j) i Ai
P
(
−
C
)
−
−
C
)
+
ln(
R
R
2σ 2
i Bi
où
Ai = exp(
Bi = exp(
2 2
R − C+1(j) − R − Ci 2σ 2
2 2
R − C−1(j) − R − Ci 2σ 2
(2.3.15)
) ≤ 1, avec C i ∈ S +1(j)
(2.3.16)
) ≤ 1 , avec C i ∈ S −1(j)
(2.3.17)
En supposant que les mots de code soient répartis de manière uniforme dans l’espace des mots de
P
P
code, alors il est montré que i Ai = i Bi et donc que le rapport tend vers 1. L’équation (2.3.15)
devient :
λj =
2 2
1 −1(j) +1(j) (
−
C
−
−
C
R
R
)
2σ 2
(2.3.18)
n
X
2
+1(j)
(r
+
rl cl
pl )
j
σ2
(2.3.19)
soit :
λj =
l=0;l6=j
avec pl =


0
si cl

1
si cl
−1(j)
+1(j)
= cl
+1(j)
6= cl
−1(j)
Dans le cas d’un canal gaussien et en normalisant par rapport à 2/σ 2 , l’expression (2.3.19) devient :
73
σ2
λj = rj + wj
2
rj0 =
(2.3.20)
avec :
wj =
n
X
+1(j)
rl cl
pl
(2.3.21)
l=0;l6=j
Le terme r0 j correspond à la sortie pondérée du décodeur mais également à la somme de l’entrée
pondérée et d’une quantité wj . Cette quantité est l’information extrinsèque qui joue un rôle prépondérant dans le processus de turbo décodage. wj est une combinaison linéaire des données pondérées
en entrée et dépend des deux mots de code à distance euclidienne minimale de R avec +1 et -1 en
position j. Le terme wj ne dépend pas de rj , il permet de transmettre au décodeur l’information sur
le signe du bit ej contenue dans les autres éléments binaires du mot décodé. Bien sûr, la corrélation
entre éléments binaires est introduite par le codage.
Il s’agit maintenant de mettre en oeuvre le décodeur EPSP à partir de l’algorithme de Chase.
Pour cela, un ensemble de mots de code à distance euclidienne minimale du mot reçu R est généré.
R représente en fait le vecteur des LRV normalisés pour les éléments binaires du mot de code émis à
l’entrée du décodeur. Le vecteur D correspond au mot de code décodé D donné par l’algorithme de
Chase. Il faut déterminer la pondération de ses composantes dj à partir des deux mots de code C +1(j)
et C −1(j) et de l’expression 2.3.18. D est forcément l’un des deux mots de code. Soit C le mot de code
à distance euclidienne minimale de R vérifiant cj 6= dj , il est donc le second mot de code concerné.
L’équation en sortie du décodeur peut alors s’écrire :
2
λj =
2
kR − Ck − kR − Dk
× dj
4
(2.3.22)
Le signe de la sortie pondérée, fournie par l’algorithme de Chase, est donné par dj et l’amplitude
2
2
est égale à la différence entre les deux métriques kR − Ck et kR − Dk . Ainsi, si la différence est
nulle alors C et D sont équiprobables, la fiabilité de la décision est nulle. En revanche, si la probabilité
de D tend vers un et celle de C est nulle alors la décision dj est de plus en plus fiable et l’amplitude
tend vers l’infini. Il n’est pas toujours possible de trouver un mot de code concurrent D puisque la
génération d’un grand nombre de mots de code est prohibitive en terme de complexité. Dans ce cas,
une solution consiste à générer un nombre raisonnable de séquences de test. Si malgré tout, aucun
mot de code concurrent n’existe, alors une relation empirique est appliquée :
λj = β × d j
(2.3.23)
La décision optimale (dj ) est connue contrairement à sa fiabilité qui dépend de C. Si C se trouve à
74
l’extérieur de la zone de recherche définie par l’algorithme de Chase et ses séquences de test alors C est
relativement éloigné de R (en terme de distance euclidienne). La décision est relativement fiable donc
la valeur de β est élevée. Malgré tout, afin de ne pas donner des fiabilités trop fortes aux décisions
erronées, la fiabilité est fonction de la probabilité d’erreurs en sortie du décodeur. Le beta se calcule
à partir de la relation [Pyn98] :
β ∝ ln
P r {dj = ej}
P r {dj 6= ej}
(2.3.24)
Le décodage EPSP des codes en blocs proposé par Pyndiah a été explicité, il faut maintenant
décrire le principe du décodage itératif des codes produits induit par cet algorithme. Un code produit
C est représenté par la matrice d’information [R] décrite sur la figure 2.5. Chaque matrice est donc
un mot de code. Le premier décodage des lignes permet de produire une matrice de données [Λ] de
laquelle est extraite l’information extrinsèque [W0 ]=[Λ]-[R]. Le processus de décodage se poursuit
avec le décodage des colonnes de la matrice :
[R1 ] = [R] + α0 [W0 ]
(2.3.25)
où α0 est une constante destinée à réduire l’impact de l’information extrinsèque dont la variance est
supérieure à celle du bruit au cours des premières itérations de décodage. A la suite du décodage des
colonnes, une nouvelle information extrinsèque est disponible et sera réinjectée au prochain décodage
de lignes. De manière générale, en itérant le processus p fois, le décodage suivant les lignes et les
colonnes s’exprime sous la forme d’une [Rp ] :
[Rp ] = [R] + αp [Wp ] avec [R0 ] = [R]
(2.3.26)
où [Wp ] est l’information extrinsèque à l’itération p.
Le principe du décodeur élémentaire utilisé pour le décodage itératif des lignes et des colonnes (à
l’itération p) est représenté sur la figure 2.7.
Figure 2.7 — Principe du décodage de la matrice Rp à la p-ième itération
Comme vu précédemment, s’il n’est pas possible de trouver deux mots de code alors les éléments de
75
la matrice [Wp ] sont donnés par la relation (2.3.23), où β varie en fonction de l’itération p considérée.
Comme la fiabilité du décodage croı̂t au fil des itérations, les coefficients α et β croissent également.
Dans notre cas, pour des codes Reed Solomon, la transmission s’effectue à l’aide d’une modulation
BPSK. Les bits constituant un symbole du mot de code sont reçus successivement du canal contrairement à l’utilisation d’une constellation d’ordre supérieure (MAQ 16, MAQ 32, PSK...) où plusieurs
bits sont groupés en un seul symbole de modulation. Ce choix nécessite une adaptation du principe
de décodage. Le processus de décodage s’effectue alors en trois phases :
– une phase de réception au cours de laquelle, les bits les moins fiables sont identifiés (position
dans le mot et dans le symbole) et les symboles du mot reçu sont reconstitués pour déterminer
le syndrome ;
– une phase de traitement correspondant au décodage dur de chaque vecteur de test (VT ) élaboré
à partir des syndromes, des bits les moins fiables et des symboles du mot ;
– une phase d’émission nécessaire à l’adaptation des sorties dures en sorties souples. Ces dernières
sont les estimations pondérées des bits reçus et sont exploitées à la demi-itération suivante.
2.3.4
Performances du turbo décodage des codes produits
Les performances du processus de turbo décodage en terme de TEB sont présentées dans cette
partie. Tout d’abord, les premières courbes données concernent le turbo décodage des codes produits
à base de code BCH de longueurs différentes et pour des pouvoirs de correction de t = 1 et t = 2.
Ensuite, les résultats similaires sont présentés lorsque des codes RS sont employés comme codes
composants. Enfin, les codes retenus dans le cadre de cette étude sont explicités et commentés.
Les performances des turbocodes en blocs ont été étudiées par simulation de la transmission
par BPSK sur un canal à bruit blanc additif gaussien (à différents rapports signal à bruit). Elles
ont été menées avec l’aide de Mr Adde du département électronique. Pour l’algorithme de Chase, la
construction des vecteurs de test a été effectuée à l’aide des 5 bits les moins fiables (voir section 3.4.1.2)
de chaque mot reçu (ligne ou colonne). Le paramètre α dépend de la demi-itération en cours. Le
paramètre β est élaboré à partir des fiabilités des 5 bits les moins fiables. Le nombre d’itérations de
décodage utilisé est de 8.
Les codes produits construits à partir de codes BCH primitifs binaires étendus (un bit de parité
supplémentaire) sont considérés dans un premier temps. Les longueurs de codes n sont égales à 32,
64, 128 et 256 et les distances minimales de Hamming à d=4 et d=6 (pouvoir de correction t=1 et
t=2). Les performances sont présentées sur les figures 2.8 et 2.9.
Les codes produits construits à partir de codes RS sont considérés dans un second temps. Les
longueurs de codes n sont égales à 31 et 63 et les distances minimales de Hamming à d=3 et d=5
76
10-1
10-2
10-3
10-4
10-5
TEB
10-6
10-7
BCH(32,26)²
BCH(64,57)²
BCH(128,120)²
BCH(256,247)²
10-8
10-9
10-10
1
2
3
4
5
Eb/No en dB
Figure 2.8 — Performances des TCB-BCH (t=1) pour une modulation BPSK sur un canal BBAG
1.00e-1
1.00e-2
1.00e-3
1.00e-4
TEB
1.00e-5
1.00e-6
BCH(32,21)²
BCH(64,51)²
BCH(128,113)²
BCH(256,239)²
1.00e-7
1.00e-8
1.00e-9
1.0
1.5
2.0
2.5
3.0
3.5
4.0
Eb/No en dB
Figure 2.9 — Performances des TCB-BCH (t=2) pour une modulation BPSK sur un canal BBAG
(pouvoir de correction t=1 et t=2). Les performances sont présentées sur la figure 2.10.
L’effet « turbo » est illustré par la chute de la courbe du TEB en fonction du Eb /N0 . Il est
77
1.00e-1
1.00e-2
1.00e-3
1.00e-4
1.00e-5
TEB
1.00e-6
RS(31,29)²
RS(31,27)²
RS(63,61)²
RS(63,59)²
1.00e-7
1.00e-8
1
2
3
4
5
Eb/No
Figure 2.10 — Performances des TCB-RS (t=1, t=2) pour une modulation BPSK sur un canal
BBAG
lié au fait que l’algorithme de décodage utilise l’information extrinsèque, calculée à la demi-itération
précédente, à chaque nouvelle demi-itération. De plus, cette pente est d’autant plus forte que le produit
de la distance minimale par le rendement est élevé [Jac96]. Le tableau 2.1 récapitule l’ensemble des
caractéristiques des codes présentés en terme de rendement et de distance minimale de Hamming.
Turbocodes en blocs
BCH t=1
(32, 26, 4)2
(64, 57, 4)2
(128, 120, 4)2
(256, 247, 4)2
BCH t=2
(32, 21, 6)2
(64, 51, 6)2
(128, 113, 6)2
(256, 239, 6)2
RS t=1
(31, 29, 3)2
(63, 61, 3)2
RS t=2
(31, 27, 5)2
(63, 59, 5)2
N (bits)
1024
4096
16384
65536
1024
4096
16384
65536
4805
19845
4805
19845
K (bits)
676
3249
14400
61009
441
2601
12769
57121
4205
18605
3645
17405
Rendement R
0.66
0.793
0.879
0.931
0.43
0.635
0.78
0.871
0.875
0.938
0.758
0.877
Distance de Hamming
16
16
16
16
36
36
36
36
9
9
25
25
Tableau 2.1 — Récapitulatif des caractéristiques des différents codes produits considérés
Les critères de choix parmi l’ensemble de ces codes sont la faible complexité induite et la possibilité
de traiter différents rendements de codes. De plus, il est à rappeler que le décodage de codes BCH
78
et RS nécessitent des traitements algorithmiques proches. Les choix effectués sont expliqués dans le
chapitre 3. Ainsi, quatre codes ont été retenus pour l’implantation de notre application. Les codes
produits sont donc construits à partir :
– des codes BCH primitifs étendus de distance de Hamming resp. 4 et 6 et de longueur de code
32.
– des codes Reed-Solomon de distance de Hamming resp. 3 et 5 et de longueur de code 31.
Si le rendement souhaité est d’environ 0.5, un TCB ayant pour code composant un code BCH au
pouvoir de correction de 1 ou 2 représente le meilleur compromis entre performance et complexité. Le
principal avantage des TCB à base de codes Reed Solomon ayant des pouvoirs de correction de 1 ou 2
réside dans leur fort rendement. En effet, pour des rendements élevés (0,8-0,9), un TCB-RS nécessite
une longueur de mot de code plus faible qu’un équivalent TCB-BCH. Par exemple, l’utilisation des
codes TCB-RS(31,29) et (31,27) permet de réduire la longueur du code d’un facteur 3 à 4 par rapport
à l’emploi de TCB-BCH (128,120) et (128,113). D’un point de vue architectural, cette caractéristique
permet de réduire la complexité de la mémoire RAM et du décodeur élémentaire [PJAJ06b]. Les
courbes de performances de ces codes sont données en figure 2.11.
1.00e0
1.00e-1
1.00e-2
1.00e-3
ΔLs corrigée
= 0.93 dB
1.00e-4
TEP
Limite de
Shannon
corrigée
1.00e-5
1.00e-6
BCH(32,26)²
RS(31,27)²
BCH(32,21)²
RS(31,29)²
1.00e-7
1.00e-8
1
2
3
4
5
Eb/No
Figure 2.11 — Performances du turbo décodage de codes produits
La limite de Shannon LS est le rapport signal à bruit minimum au dessous duquel il est impossible de rendre le taux d’erreur binaire nul. Ce critère permet de mesurer l’optimalité de l’ensemble
2.4. CONCLUSION
79
codeur/décodeur. Une comparaison avec la limite de Shannon corrigée peut être effectuée. Cette limite
prend en compte la taille des blocs du code correcteur d’erreurs. En effet, l’utilisation d’un outil en
ligne (disponible sur http ://www-elec.enst-bretagne.fr/turbo/) permet d’évaluer l’écart entre limite
théorique et limite corrigée. Cet écart est donné pour le code BCH(32,21)2 sur la figure 2.11. Les
valeurs de LS , LS corrigée et l’écart entre la courbe et LS corrigée pour les autres codes sont données
dans le tableau 2.2.
Turbo codes en blocs
BCH
(32, 26, 4)2
(32, 21, 6)2
RS
(31, 29, 3)2
(31, 27, 5)2
Ls FER de 10−4 (dB)
1.004
-0.130
2.879
1.691
Ls corrigée
2.239
1.320
3.439
2.279
∆Ls corrigée
0.95
0.93
0.8
1.5
Tableau 2.2 — Limite de Shannon et gain asymptotique des différents codes produits considérés
Dans trois des quatre codes considérés, les courbes de performances se trouvent à moins de 1 dB
de la limite de Shannon corrigée ce qui garantit un décodage efficace.
2.4
Conclusion
Dans ce chapitre, nous avons introduit le domaine de l’application considérée lors de notre étude.
Ainsi, les turbocodes en blocs ont été replacés dans le cadre de la théorie du traitement de l’information
et plus spécifiquement dans le domaine des codes correcteurs d’erreurs. Puis, les codes en blocs linéaires
et plus particulièrement les codes BCH binaires et Reed-Solomon q-aires ont été exposés. Les méthodes
de codage et de décodage ont été données pour les deux types de codes. Enfin, les codes produits
et le processus de turbo décodage ont été précisés. Les performances liées à la mise en oeuvre des
ensembles codeur/décodeur considérés ont également été données. Les critères que nous avons retenus
pour l’ensemble des codes évoqués sont la faible complexité induite et la possibilité de traiter différents
rendements de codes. Au final, nous avons conservé quatre configurations d’ensemble codeur/décodeur
de codes produits. Les codes composants retenus sont capables de corriger une ou deux erreurs, il s’agit
des codes :
– BCH primitifs étendus de distance de Hamming respectivement 4 et 6 et de longueur de code
32.
– Reed-Solomon de distance de Hamming respectivement 3 et 5 et de longueur de code 31.
Ces codes ont des rendements faibles (#0.5) et des rendements élevés (#0.9). Pour des rendements élevés, un TCB-RS nécessite une longueur de mot de code plus petite que celle d’un équivalent TCB-BCH.
Cette caractéristique permet alors de réduire la complexité architecturale du décodeur élémentaire et
de la mémoire. De plus, pour trois des quatre codes considérés, les courbes de performances se trouvent
à moins de 1 dB de la limite de Shannon corrigée ce qui garantit un décodage efficace.
80
Le chapitre suivant 3 présente dans un premier temps une étude de complexité des différents
algorithmes susceptibles d’être implémentés. Dans un deuxième temps, la description de la solution
architecturale pour le codeur flexible et pour le décodeur flexible nécessaires aux turbocodes en blocs
est donnée. Enfin, la gestion du processus itératif et les critères de flexibilité sont détaillés.
CHAPITRE
3
Étude et implantation
d’un turbocode en blocs
flexible
Ce chapitre est consacré à l’étude du codeur flexible et du décodeur flexible nécessaires aux turbocodes en blocs. Dans un premier temps, un état de l’art rappelle les travaux effectués dans le domaine
des turbo décodeurs reconfigurables. Dans notre cas, une analyse de la complexité algorithmique est
effectuée pour déterminer les paramètres propres à l’application choisie. Notre approche consiste à
faire apparaı̂tre les points de flexibilité exploitables lors de la mise en oeuvre d’une architecture dédiée.
Ensuite, l’architecture générique du codeur est présentée. Elle peut supporter l’ensemble des configurations souhaitées à savoir les codes BCH (32,26) et (32,21) et les codes Reed-Solomon (31,29) et
(31,27). Puis, l’architecture de l’ensemble du turbo décodeur est explicitée. La structure du décodeur
élémentaire se compose de trois parties : réception, traitement et émission. De plus, une unité de
contrôle se charge de la configuration de l’ensemble de la partie de décodage. Enfin, la gestion des
aspects itératifs est explicitée. Cette fonction est assurée par un processeur logiciel de type NIOS II.
Ainsi, l’échange des données avec la mémoire et la configuration du décodeur élémentaire sont entièrement gérés par ce composant. Les solutions architecturales envisagées sont données dans cette dernière
partie.
3.1
Etat de l’art sur les turbo décodeurs reconfigurables
Actuellement, les technologies reconfigurables sont « pensées » pour répondre à un compromis
entre performances, qualité de service (QoS) et consommation d’énergie. Cette approche allie la flexibilité des processeurs avec la puissance de calcul des architectures « matérielles » traditionnelles. De
plus, la reconfiguration dynamique, permettant de configurer des parties de l’architecture globale,
82
CHAPITRE 3. ÉTUDE ET IMPLANTATION D’UN TURBOCODE EN BLOCS FLEXIBLE
améliore les performances et réduit la consommation.
Récemment, des équipes de recherche se sont intéressées aux architectures reconfigurables dédiées
au décodage de codes correcteurs d’erreurs [RLP05][CV03][AA04][LTG04]. Bien que concernant les
turbocodes convolutifs, tous ces travaux s’appuient sur des approches diverses suscitant notre intérêt.
En effet, ils présentent plusieurs aspects importants :
– le choix de critères de flexibilité.
– le choix d’une cible architecturale.
– le type de configuration employé.
Dans l’optique de l’implantation de notre architecture, ces trois points sont également à prendre
en considération. Tout d’abord, une étude des algorithmes mis en oeuvre dans l’application peut
permettre d’isoler les paramètres. La variation de ces paramètres agit directement sur la complexité en
terme d’opérations. De plus, une réduction de la consommation et une amélioration des performances
sont envisageables. Ensuite, la mise en place d’une architecture adaptée au type de traitement est
cruciale. Les solutions présentées sont de plusieurs natures, cela s’étend de l’architecture dédiée sur une
cible ASIC à une association processeur/FPGA. Enfin, le type de reconfiguration (statique/dynamique
et partielle/totale) doit être en adéquation avec les contraintes de fonctionnement de l’application en
terme de qualité de service. La solution architecturale retenue fixe la manière dont elle sera réalisée.
Pour toutes ces raisons, dans le cadre du décodage des turbocodes en blocs, les démarches entreprises dans l’ensemble de ces travaux sont à étudier de près puisqu’elles relèvent du même domaine
d’application à savoir le décodage des codes correcteurs d’erreurs.
Afin de mieux appréhender les algorithmes implantés et de comprendre les mécanismes employés,
les différentes approches sont décrites dans la suite. Pour des explications supplémentaires sur le
principe de décodage, il est possible de consulter des ouvrages dédiés à ce type de code [BG96]. Il
est à retenir que le décodage d’un code convolutif se base sur le parcours du treillis du code choisi
et la génération de métriques de branches et de noeuds (fig. 3.1). Plusieurs algorithmes peuvent être
utilisés :
– le MAP (ou BCJR pour Bahl-Cocke-Jelinek-Raviv)[BCJR74] est optimal au sens du critère du
maximum de vraisemblance puisque tous les chemins du treillis sont explorés. Il nécessite deux
parcours du treillis, un aller et un retour. Il est toutefois trop complexe pour être implanté dans
un système réel.
– le Log-MAP [RVH95] est l’adaptation du MAP par un passage à la fonction logarithme. Les
performances sont identiques car la modification résulte uniquement d’un changement de base.
Sa complexité moyenne autorise son implantation.
– le Max Log-MAP est une version simplifiée du Log-MAP. Les pertes en TEB sont de l’ordre de
0.3 à 0.5 dB. Cet algorithme représente un bon compromis pour une implantation raisonnable
3.1. ETAT DE L’ART SUR LES TURBO DÉCODEURS RECONFIGURABLES
83
en terme de complexité.
– le SOVA (Soft Output Viterbi Algorithm) [BAAF93] [HH94] est un algorithme plus facilement
intégrable que le MAP. Il s’agit d’une adaptation de l’algorithme de Viterbi classique (décodage
ferme) afin de prendre en compte l’apport des décisions souples. L’utilisation de l’algorithme
SOVA présente une dégradation en performance de l’ordre de 0.2 dB par rapport à l’algorithme
Max-Log-MAP. Cependant, sa complexité en nombre d’opérations est pratiquement deux fois
plus faible.
Métrique
α ( xk )
= p ( xk , y
−
k
)
Métrique
γ ( xk )
Probabilité de transition sur le canal
Métrique
β ( xk )
= p ( y +k | xk )
Figure 3.1 — Le treillis et les métriques associées
Dans [RLP05], le modèle de programmation logicielle est étendu au flot de conception pour un
processeur reconfigurable appelé XiRisc. Ce dernier se compose d’un coeur Risc (orienté traitement
de signal) associé à un composant reconfigurable en cours d’exécution (appelé un PiCoGA : une
matrice de portes configurable pipeliné) effectuant des calculs spécifiques aux applications considérées.
Ce dernier élément joue typiquement le rôle d’accélérateur matériel. Cette approche permet à un
ingénieur logiciel d’évaluer le coût et le gain de l’exécution d’une partie de code C au sein d’un bloc
logique. Cette architecture est plus exactement reconfigurable par reprogrammation. L’implantation
d’un turbo décodeur UMTS a été réalisée. Chaque itération du processus de turbo décodage se compose
de plusieurs parties critiques nécessitant des calculs intensifs :
– le calcul des métriques de branches γ du treillis ;
84
– le calcul des métriques de noeuds α lors du parcours aller du treillis ;
– le calcul des métriques de noeuds β lors du parcours retour du treillis ;
– le calcul du rapport du maximum de vraisemblance LLR.
L’opération dite « papillon » est le coeur de l’algorithme qui détermine les α et les β. Pour chaque
section du treillis, les métriques de noeud α (et β) sont calculées de manière récursive, en utilisant
les métriques de la section précédente et les métriques de branches γ préalablement calculées. Une
itération de calcul nécessite quatre opérations papillon. Du fait des choix architecturaux, il faut
deux instructions picoGA pour effectuer l’ensemble. La dernière partie du traitement détermine le
rapport des maximums de vraisemblance, c’est à dire la probabilité que le bit transmis soit 1 ou
0. Dans un premier temps, une instruction pGA réalise l’addition de trois opérandes. Puis, une
seconde instruction réalise une approximation de la fonction ln(ex + ey ). Pour chaque instruction
exécutée par le picoGA, l’architecture limite l’échange à la lecture de quatre registres et l’écriture
dans deux registres. Cette limitation impose des contraintes dans la génération du graphe flot de
données et de contrôle à partir du code source. En effet, le graphe flot de données et de contrôle
(CDFG) sert de point de départ à l’élaboration du bitstream (train binaire) destiné à configurer
le pGA. Chaque cellule élémentaire du pGA peut recevoir jusqu’à quatre configurations différentes.
Les opérations concurrentes permettent de réduire la latence d’une instruction. Quand l’exécution
d’une opération nécessite plusieurs cycles alors une implantation pipeline augmente les performances
à condition que l’instruction soit exécutée plusieurs fois sur des données différentes. Dans cette étude,
le traitement est accéléré d’un facteur douze par rapport à une implantation conventionnelle tandis
que la consommation est réduite d’un facteur quatre.
Virturbo [CV03] est une architecture flexible implantée sur un FPGA. Elle est destinée au décodage
de codes convolutifs et de turbocodes convolutifs. Pour ce faire, l’algorithme retenu est l’algorithme de
Viterbi dans le premier cas et l’algorithme SOVA dans le second. Dans cette approche, la reconfiguration dépend de la longueur de contrainte k et du rendement R requis. Pour un code convolutif avec
k donné, il y a 2k−1 états et 2k−2 opérations de type papillon à effectuer. Cette dernière opération
est réalisée à l’aide d’une unité ACS (Add Compare and Select) ayant pour entrée les métriques de
branches et de noeuds. Elle fournit en sortie les métriques de noeuds survivants, les décisions binaires
et la différence entre les métriques de noeuds pour un SOVA. Ces unités ACS sont parallélisées pour
K=9 (128 unités).
Le fonctionnement global de Viturbo est illustré par l’architecture représentée sur la figure 3.2. En
amont, les unités de calcul (MB) des métriques de branches γ alimentent les unités ACS concernées par
la configuration. En sortie des ACS, des routeurs configurables de données orientent les métriques de
noeuds réinjectées, les bits de décision et éventuellement les différences entre les métriques de noeuds
(pour un SOVA). En aval, un module de gestion des métriques survivantes évalue les bits décodés et
désactive les éléments non concernés par le calcul en fonction de la configuration.
85
Les débits atteints sont de 60 Mb/s (avec longueur de contrainte de 3 à 9) pour le décodage d’un
code convolutif et de 3.54 Mb/s avec un algorithme SOVA avec 4 itérations pour un turbocode convolutif. La configuration s’effectue en un seul cycle d’horloge et ne nécessite pas la reprogrammation
complète du FPGA. La flexibilité est obtenue grâce à l’utilisation d’un banc de multiplexeurs. Ces
derniers contrôlent le routage des métriques. Cette architecture propose également une gestion automatique de la consommation et de la puissance. En effet, pour chaque configuration de l’application,
les ressources non utilisées sont désactivées par l’intermédiaire de l’arbre d’horloge. Viturbo occupe
une surface totale de 181560 portes logiques et nécessite 262146 bits pour la mémoire.
MBmux(0)
ACS(0)
MBmux(1)
ACS(1)
M
é
m
o
i
r
e
Entrées
Calcul
MB
MBmux(127)
Routeurs
de
données
Sortie
Mem1
S
M
U
Mux
Mem2
ACS(127)
Ȇ-1 Ȇ
Seuillage
Mémoire décision souple
SMU: Unité des métriques survivantes
Mux
MB: métriques de branches
ACS: Unité Additionneur Comparateur et Sélection
Figure 3.2 — L’architecture de Virturbo
Une autre approche [AA04] propose un turbo décodeur reconfigurable permettant de sélectionner l’algorithme approprié en fonction des contraintes de fonctionnement. En effet, les deux algorithmes typiquement employés pour le turbo décodage convolutif sont l’algorithme SOVA et l’algorithme Log-MAP. Les auteurs proposent une alternative à l’utilisation du Log-MAP conventionnel
utilisant conjointement un SOVA ou un Log-MAP faible consommation favorisant ainsi un compromis
consommation/surface.
Les critères de reconfiguration des deux algorithmes sont multiples. Le taux d’erreurs binaires
(TEB) est tout d’abord considéré. Ainsi, pour un faible TEB, le SOVA est utilisé. Les performances
du Log-MAP sont équivalentes mais sa complexité est deux fois plus importante. En revanche, à un
fort TEB, le Log-MAP fournit de meilleures performances. La complexité du traitement est un autre
critère envisagé. Pour un faible débit de données en entrée, l’algorithme Log-MAP est préféré au SOVA
et vice et versa.
Comme précédemment, les principaux modules constituant le décodeur sont les suivants
[CSKPN00] :
– Le bloc de calcul des métriques de branches γ : il est utilisé pour tous les décodeurs (à base de
86
Log-MAP, SOVA et Log-MAP modifié). Ce module évalue les métriques de branches à l’aide
d’un ensemble d’additionneurs reconfigurables.
– Le bloc de calcul des métriques de noeuds α et β : il fournit les métriques associées au parcours
du treillis de décodage. Le SOVA ne nécessite qu’un parcours aller du treillis tandis le log-MAP
(version traditionnelle et modifiée) a besoin d’un aller et d’un retour. Ce module est constitué
de deux sous blocs :
– Le bloc de calcul des métriques de noeuds : il détermine la métrique de noeuds suivants en
additionnant les métriques de branches et les métriques de noeuds précédentes et ceci pour
chaque section du treillis. Ces opérations d’additions sont reconfigurables.
– Le bloc de calcul des chemins survivants et le bloc FEC : les métriques de noeuds sont
comparées et les valeurs absolues des différences sont calculées. Dans le cas du SOVA, le bloc
0
1
FEC n’est pas nécessaire. Il permet d’évaluer l’expression ( e−|SMk −SMk | ) indispensable au
calcul du log-MAP. En résumé :
– Pour le SOVA, les deux métriques maximales sont conservées : M ax(SMk0 , SMk1 ).
0
1
– Pour le Log-MAP, l’opération est M in(SM 0 , SM 1 ) − ln(1 + e−|SMk −SMk | ).
k
k
– Pour le Log-MAP modifié, il faut calculer M in(SMk0 , SMk1 ) − ln(1 − e−|SMk −SMk | )
0
1
– Le bloc de calcul des rapports des logarithmes de vraisemblance : il est dédié à l’algorithme
Log-MAP et utilise des unités ACS et une mémoire.
Les deux versions des turbo décodeurs, c’est à dire l’algorithme original Log-MAP et la version
modifiée, ont été implantés sur une cible ASIC à base de technologie UMC 0.18 µm à l’aide des
outils de Synopsys. La baisse de consommation dans le second cas est de 35% tandis que le taux
d’occupation en surface est réduit de 45%.
Enfin, les travaux de [LTG04] concernent un turbo décodeur dynamiquement reconfigurable et
optimisé pour la consommation de puissance. L’idée est de reconfigurer l’algorithme de décodage
SOVA à la base du turbo décodage (qui devient ici ASOVA pour Adaptative SOVA) en fonction des
conditions extérieures. Comme dans les articles précédents, le nombre total de métriques de noeuds est
proportionnel à 2k−1 (k longueur de contrainte). L’adaptation du SOVA vise à éliminer les chemins les
moins vraisemblables, c’est à dire ceux qui ont le moins de chances de conduire à un mot décodé. Nmax
chemins sont conservés. Des simulations ont été menées pour différentes longueurs de contraintes k
et différents Nmax en fonction du SNR. Ainsi, les combinaisons de paramètres conduisant à une
implantation matérielle la plus simple possible ont été retenues pour satisfaire à un TEB faible. Les
performances observées se rapprochent de celles du Log-MAP. Le décodeur est l’élément clef du turbo
décodage, son architecture est représentée sur la figure 3.3. Elle se compose de quatre modules : le bloc
de calcul de métrique de branches γ (MB), l’unité ACS, une mémoire pour les métriques survivantes
(SMU) et le module de contrôle. Ce dernier se compose d’une machine d’états finis et gère l’échange
de données entre les trois unités. Le fait de pouvoir réduire la valeur du paramètre Nmax à un k donné
87
entraı̂ne une baisse significative de la consommation, une hausse du débit et une augmentation de
la fréquence de fonctionnement. En terme de reconfiguration dynamique, le fait de pouvoir modifier
le circuit en fonction du SNR requis présente également une économie de la consommation. Chaque
reconfiguration est stockée dans une mémoire SDRAM. En s’appuyant sur le fait que le rapport signal
à bruit peut être échantillonné tous les 250 000 bits, le FPGA est périodiquement reconfiguré durant
la phase de transmission. Le circuit initie la reconfiguration (le changement des paramètres N max et
k) en fonction du SNR observé, on peut parler d’auto-reconfiguration.
Machine
d’états
Contrôle
Sorties
Entrées
MB
ACS
SMU
souples
Figure 3.3 — Architecture du décodeur implantant l’ASOVA
En conclusion, bien que tous ces travaux concernent les turbo codes convolutifs, les études menées
apportent des éléments de réflexion dans le cadre de notre travail. La détermination des particularités
algorithmiques de l’application permet d’avoir une certaine marge de manoeuvre pour envisager la
reconfiguration. De plus, différentes architectures et mécanismes de reconfiguration sont utilisés dans
chacune des approches. Tous les aspects décrits nous offrent ainsi des voies de prospection dans la mise
en oeuvre de notre architecture. Le tableau 3.1 récapitule les caractéristiques des différentes solutions.
XXX
XXXCaract.
Architecture
XXX
Cible
X
XiRisc [RLP05]
RISC + FPGA
Algorithme
Flexibilité
Max-Log-MAP
Reconfiguration partielle
du FPGA
Banc de multiplexeur
Unité de contrôle
dédiée
Reconfiguration totale
du FPGA
Viturbo [CV03]
Atluri [AA04]
FPGA
ASIC
Viterbi + SOVA
SOVA+Log-MAP
Liang [LTG04]
NIOS + FPGA
Log-MAP + SOVA
Tableau 3.1 — Récapitulatif des implantations existantes de turbo décodeurs flexibles
Notre approche concerne le turbo décodage de codes en blocs. A l’instar des études sur les turbo
décodeurs convolutifs, il s’agit d’exploiter les similarités algorithmiques du décodage algébrique d’un
code BCH et d’un code Reed-Solomon. Ainsi, une étude de complexité peut nous permettre d’appré-
88
hender l’aspect flexibilité de notre application avant de décrire une architecture.
3.2
Aspect flexiblité pour le décodeur élémentaire
Dans un premier temps, une étude de complexité sur le principe de décodage est menée afin de
caractériser les paramètres propres aux algorithmes considérés. Ensuite, différents critères d’arrêt sont
mis en oeuvre afin de réduire la durée de traitement de l’application. Le but est de déterminer le critère
le plus simple à mettre en oeuvre sans dégrader les performances. Enfin, un récapitulatif expose les
paramètres de flexibilité retenus pour l’implantation.
3.2.1
Etude de la complexité algorithmique
La flexibilité de l’ensemble codeur/décodeur peut apparaı̂tre à travers une étude algorithmique
sur les traitements mis en oeuvre. L’objectif est de caractériser les paramètres et plus exactement
leur impact sur la complexité en terme d’opérations. Cette étude dessine les traits d’une première
architecture liée uniquement à l’analyse des algorithmes utilisés. Ainsi, il est possible d’isoler les
paramètres sur lesquels un contrôleur de configuration pourrait agir pour rendre l’architecture flexible.
Les notations employées pour les paramètres sont les suivantes :
– N : le nombre de symboles ou de bits d’un mot de code.
– M F : le nombre de symboles les moins fiables.
– m : la taille du corps de Galois (2m ) correspondant au nombre de bits du symbole q-aire.
– Q : le nombre de bits de quantification des données.
– L : le nombre de bits de quantification des métriques.
– t : le pouvoir de correction du code.
– N b v : le nombre de vecteurs de test employés pour le décodage algébrique.
– N b M C : le nombre de métriques concurrentes considérées parmi l’ensemble des métriques des
N b v vecteurs de test .
Dans la suite, tous les algorithmes détaillés dans la section 2.2 sont caractérisés en terme
d’opérations en fonction des paramètres. Toutes les opérations effectuées dans le corps de Galois se
font sur m bits. En revanche, il s’agit d’opérations sur des entiers signés ou non signés quantifiées sur
Q bits. Il faut noter que la modulation considérée est une BPSK, c’est a dire que les symboles reçus
correspondent à une information binaire. C’est pourquoi, un mot de code BCH est reçu en m fois
moins de temps qu’un mot de code RS.
Détermination des bits les moins fiables
Cette étape a pour objectif de classer les bits les moins fiables reçus par la partie de décodage. Les
3.2. ASPECT FLEXIBLITÉ POUR LE DÉCODEUR ÉLÉMENTAIRE
89
opérations sont essentiellement des comparaisons entre les quantifications associées au bit transmis issu du canal. En considérant la réception d’un mot de code, le nombre de comparaison sur Q
bits est de (M F −1).(N −1) (m.(M F −1).(N −1) pour les codes RS) et 2.(M F −1).(N −1) décalages.
Calcul des composantes du syndrome initial (S=(s1 , s2 , . . . , sn−k ))
Le syndrome est obtenu par une division polynomiale du mot reçu dans le corps de Galois CG(2m ).
Le nombre de composantes utiles est de 2t, où t est le pouvoir de correction du code. Le calcul de
chaque composante nécessite le traitement de l’ensemble des N symboles reçus :
Pn−1
Si = R(αi ) = j=0 rj (αi )j avec 1 ≤ i ≤ 2t
Ce calcul permet de déterminer une composante du syndrome, il faut donc réitérer le calcul pour
les t − 1 composantes restantes. En résumé, il faut N.t additions pour un code BCH et un code RS.
De plus, N.t multiplications supplémentaires sont nécessaires dans le corps de Galois pour un code RS.
Calcul des composantes du syndrome des N b v VT
Les vecteurs de test sont élaborés à partir d’une ou de plusieurs inversions des bits les moins fiables
dans la séquence reçue. A partir des composantes du syndrome initial, il est possible de retrouver les
composantes du vecteur de test. De manière empirique, il a été montré que conserver 16 vecteurs de
test permettait d’effectuer un décodage efficace [KAP01]. Cela revient à réaliser 3 inversions parmi 5
bits les moins fiables en conservant les combinaisons les plus probables.
– Pour construire les syndromes des vecteurs de test S1 à S5 un seul bit est inversé. Les opérations
à réaliser sont :
– Si = S + αj1 dans le cas d’un code BCH avec j1 la position inversée.
– Si = S + αj1 × rj1 dans le cas d’un code RS avec rj1 le symbole à inverser.
Pour chaque composante de chaque syndrome, il faut donc 2t additions et 2t multiplications
supplémentaires pour un code RS.
– Ensuite, pour les syndromes des vecteurs de test S6 à S9, en procédant de la même manière
pour 2 inversions, il faut 4t additions et 4t multiplications.
– Enfin, pour les syndromes des vecteurs de test S10 à S15 : Cette fois-ci, 6t additions et 6t
multiplications sont nécessaires pour 3 inversions.
En résumé, dans le cas d’un code BCH, il faut au total 6 × 6t + 4 × 4t + 5 × 2t = 72t
additions. Dans le cas d’un code RS, un symbole est constitué de m bits, 72t opérations de multiplications supplémentaires sont nécessaires pour déterminer les composantes des 16 vecteurs de test choisis.
90
Décodage algébrique
Un décodage algébrique doit être effectué pour chacun des vecteurs de test construits précédemment.
Ce processus consiste à calculer les polynômes localisateur d’erreurs σ(x) et évaluateur d’erreurs ω(x).
Il convient donc de multiplier l’ensemble des opérations présentées par un facteur N b v. Dans un
premier temps, l’association des algorithmes de Berlekamp-Massey, Chien, Forney et de vérification
du mot décrits dans le chapitre 2 est considéré. Dans un second temps, la complexité de l’algorithme
du PGZ est donnée.
1. Comme précédemment, l’algorithme de Berlekamp-Massey vise à résoudre une équation clé à
partir des composantes d’un syndrome de manière à identifier les coefficients des polynômes
localisateur d’erreurs et évaluateur d’erreurs des vecteurs de test. Puis, des algorithmes supplémentaires permettent de déterminer les racines du premier polynôme et de vérifier le mot de code
élaboré. Dans ce dernier cas, les syndromes sont recalculés à partir des corrections effectuées.
Toutes les opérations sont effectuées dans le corps de Galois. Le tableau 3.2 récapitule l’ensemble
des opérations effectuées lors du décodage d’un vecteur de test pour des codes BCH ou RS.
Berlekamp-Massey
σ(x)
Add GF
(m bits)
BCH
Mult GF
(m bits)
t −1
t −1
i=1
i=1
Ω(x)
∑i+∑(i+1)
t
t −1
i=1
i=1
Chien
Forney
(t-1).N
Vérif.
mots de
code
t
t.N
∑i+2.∑(i+1)
MAC GF
(m bits)
t.N
Comp
3t
Add
t
XOR
RS
t
t −1
t −1
i=1
i=1
t −1
t −1
Add GF
(m bits)
∑i+∑(i+1) ∑i+∑(i+1)
i=1
i=1
Mult GF
(m bits)
∑i+2.∑(i+1) ∑i+2.∑(i+1)
t
t −1
t
t −1
i=1
i=1
i=1
i=1
MAC GF
Comp
3t
3t
Add
t
t
Mem
Parité
(t-1).N
t
t.N
3t+3
t.N
3t-1
2m
t
t.2m
Tableau 3.2 — Complexité en nombre d’opérations de l’algorithme de Berlekamp-Massey
Une opération de division occupe une place importante lors de l’implantation. En pratique, elle est
91
remplacée par une table d’inversion dans le corps de Galois et d’une opération de multiplication.
2. Pour l’algorithme PGZ, les coefficients du polynôme σ(x) sont déterminés à partir des syndromes
des 16 vecteurs de test. La complexité varie fortement selon le pouvoir de correction souhaité et le
nombre d’erreurs à corriger. Le tableau 3.3 récapitule les opérations à réaliser pour l’algorithme
PGZ.
t=1
t=2
σ(x)
σ1 = S2 /S1
S1 S4 +S2 S3
S1 S3 +S22
S S +S 2
σ2 = S12 S34 +S32
2
σ1 =
ω(x)
E1 = S12 /S2
E1 =
E2 =
S1 X2 +S2
X1 (X1 +X2 )
S1 X1 +S2
X1 (X1 +X2 )
Tableau 3.3 — Opérations effectuées par l’algorithme PGZ
Pour un pouvoir de correction de t = 1, les opérations lors du calcul des deux polynômes pour
un vecteur de test sont les suivantes :
– 2 divisions dans le corps de Galois.
– 1 multiplication dans le corps de Galois.
Pour un pouvoir de correction de t = 2, les opérations nécessaires au calcul des deux polynômes
pour un vecteur de test sont les suivantes :
– 5 divisions dans le corps de Galois.
– 13 multiplications dans le corps de Galois.
– 7 additions dans le corps de Galois.
De plus, une mémoire de 2m bits est alors nécessaire.
Il est à rappeler que dans chacun des cas un coefficient multiplicateur N b v, correspondant au
nombre de vecteurs de test, doit être appliqué à l’ensemble des opérations considérées.
Calcul du carré de la distance euclidienne
Le calcul des métriques se fait par la différence entre le mot reçu du canal et le vecteur de test corrigé au
niveau binaire. Autrement dit, l’opération consiste à comparer un à un l’ensemble des bits constituant
le mot reçu :
n−1
2 n−1
X
X
R − Cj 2 =
rk0 − cjk =
rk0 × cjk
k=0
(3.2.1)
k=0
Bien que relativement simple d’un point de vue algorithmique, la complexité de cet élément est
élevée. En effet, il faut procéder à N b v.(N − 1) additions d’entiers non signés et à N b v.N multiplications d’entiers signés pour un code BCH. De plus, pour un code RS, un facteur multiplicateur m
doit être appliqué aux opérations additions et multiplications.
Sélection du mot décidé et des mots concurrents
Les N b M C métriques les plus faibles doivent être déterminées parmi les N b v métriques calculées lors
du décodage algébrique des vecteurs de test. Les N b M C métriques les plus faibles sont conservées
92
par comparaison successive de chaque élément préalablement mémorisé avec la métrique du vecteur
de test en cours.
Comme la comparaison des métriques s’effectue deux à deux, N b M C comparaisons sont nécessaires pour classer une métrique. Ainsi, la profondeur de l’arbre d’exploration dépend directement du
nombre de métriques concurrentes à conserver. Cette opération doit être répétée pour chaque vecteur
de test.
La complexité, en nombre de comparaison et pour N b M C < N b v, est égale à N b M C × N b v.
Calcul de la nouvelle fiabilité
Pour obtenir l’information extrinsèque, il faut calculer les nouvelles fiabilités de chacun des bits composant les symboles. Pour cela, les bits des symboles du mot décidé D (de métrique MD ) et des
(N b M C − 1) mots concurrents Ci (de métrique MC(i) ) sont utilisés de la manière suivante :
– si bit SymboleD = bit SymboleC(1) = bit SymboleC(2) = ... = bit SymboleC(N b M C−1) alors
F=β.
– si bit SymboleD = bit SymboleC(1) = ... = bit SymboleC(N b M C−3) = bit SymboleC(N b M C−1)
alors F = MC(N b M C−2) − MD .
– ...
– si bit SymboleD = bit SymboleC(1) = bit SymboleC(3) ... = bit SymboleC(N b M C−1) alors F =
MC2 − MD .
– si bit SymboleD = bit SymboleC(2) = bit SymboleC(3) ... = bit SymboleC(N b M C−1) alors F =
MC1 − MD .
– si le mot reçu est un mot de code F = β 0 .
où β = |R0 k| + F iabiliteM F 2 + F iabiliteM F 3 + F iabiliteM F 4 − MD et β 0 = β + 2
Le paramètre N b M Futilisés est ajouté, il représente le nombre de moins fiables utilisé pour le
calcul de la fiabilité ( N b M Futilisés < M F ). En récapitulant les opérations considérées pour un code
BCH, le bilan est le suivant :
– Nombre d’additions non-signées : N.[(N b M Futilisés − 1) + 1].
– Nombre de soustractions non-signées : 2N .
– Nombre de comparaisons : (N b M C).N .
Là encore, la complexité est à multiplier par m dans le cas d’un code RS.
Calcul de l’information extrinsèque
Il s’agit de la soustraction de la fiabilité (dont le signe dépend du décodage dur) avec le symbole
quantifié du mot reçu. W k représente l’information extrinsèque.
W k = sgn(Dk)F k − Rk 0
(3.2.2)
93
Le nombre de soustractions est égal à N pour un code BCH ou m.N pour un code RS.
Addition avec le mot reçu du canal
L’information extrinsèque est tout d’abord pondérée en entrée du bloc ce qui implique l’utilisation
d’une table de taille N et de profondeur m. Ensuite, une addition avec le symbole initial est effectuée.
Rk 0 = Rk + α.W k
(3.2.3)
L’utilisation d’une mémoire de taille N.m bits et N (resp. N.m) additions sont nécessaires pour un
code BCH (resp. RS).
Le tableau 3.4 récapitule l’ensemble des opérations nécessaires (S : signés, NS : non signés, CG :
Corps de Galois) aux différents algorithmes pour le décodage d’un code BCH/RS. En dehors du
décodage algébrique où les opérations relatives aux deux codes ont été explicitées (blocs 4 et 5), il
convient de multiplier la complexité des entités 1,8,9 et 10 par m pour obtenir la complexité d’un code
RS.
L’ensemble des paramètres intervenant lors du décodage élémentaire ont été définis. A présent,
nous devons déterminer ceux qui peuvent être modifiés pour apporter de la flexibilité et maintenir une
complexité globale raisonnable.
Une première analyse permet de constater que les paramètres du code N et t influent directement
sur la complexité de l’application. En effet, N est prépondérant puisqu’il détermine à la fois le nombre
et la taille des opérations effectuées dans le corps de Galois (N = 2m − 1 ). De plus, l’utilisation
de l’algorithme de Chase-Pyndiah impose un traitement binaire. C’est pourquoi, pour un code RS,
m opérations supplémentaires sont nécessaires pour les opérations sur les bits issus du canal. Le
pouvoir de correction t agit, quant à lui, sur le nombre de composantes du syndrome à calculer et par
conséquent sur les algorithmes de décodage associés. Par conséquent, les valeurs de N et de t retenues
sont les suivantes :
– N : la complexité est proportionnelle à la longueur du mot de code N . Dans cette étude, la
longueur de code retenue est de 32 symboles.
– t : plus le pouvoir de correction est élevé, plus l’algorithme de décodage associé est complexe.
Dans l’optique de l’implantation d’un décodeur élémentaire à faible pouvoir de correction
(t = 1 et t = 2), l’algorithme de Peterson modifié (PGZ) a été retenu. Pour un pouvoir de
correction t < 3, il est particulièrement approprié comme il est possible de le constater sur le
tableau 3.4. En effet, la complexité du PGZ modifié reste raisonnable par rapport à l’utilisation
du Berlekamp-Massey et des traitements supplémentaires induits (algorithme de Chien et de
Forney).
a
9
8
7
6
4.Nb_v
3.Nb_v
Nb_v.(N-1)
(Nb_MC1).N
Tableau 3.4 — Récapitulatif de la complexité des différentes parties constituant le décodage élémentaire pour des codes BCH/RS
4: Détermination du polynôme σ(x)
6: Calcul du carré de la distance euclidienne
b. PGZ
3: Construction des vecteurs de test
5: Détermination du polynôme ω(x)
N
2.N
Nb_MC. Nb_v
a. Berlekamp-Massey + Chien + (Forney)…
N
N[(Nb_MFutilisés
-1) + 1]
9.Nb_v
Nb_v.N
S(Q bits)
N.m
2.2m
2m
2t. 2m
bits
mem
10: Addition avec le mot reçu du canal
9: Calcul de l'information extrinsèque
8: Calcul de la nouvelle fiabilité
7: Sélection du mot D et des mots C
12.Nb_v
Voir tableau 3.2 spécifique pour les détails BCH/RS
2: Calcul du syndrome
1: Détermination des bits MF
b
a
b
Voir tableau 3.2 spécifique pour les détails BCH/RS
72t
CG(m bits)
72.t
(L bits)
3
MF.(N-1)
(Q bits)
Multiplications
N.t
NS
Comparaisons
N.t
10
5
4
CG (Q bits)
Sous.
2
1
CG(m bits)
Additions
94
95
Un second constat est que les choix du concepteur sur les paramètres M F , N b v, L, N b M C,
N b M Futilisés et Q permettent d’affiner les performances de l’application en terme de TEB. Cependant, ils ne sont pas sans impact sur la complexité. Tous ces paramètres sont tous liés et découlent
de l’utilisation de l’algorithme de Chase-Pyndiah pour le décodage. Ainsi, le nombre de bits les moins
fiables M F et le nombre de vecteurs de test N b v sont à mettre en relation car les vecteurs de test sont
construits à partir d’une combinaison de ces bits. Le nombre de vecteurs de test N b v agit également
sur la latence de l’application car l’algorithme de décodage algébrique doit être réitéré. D’autre part,
le tri des métriques se fait sur les N b v métriques produites pour en conserver un nombre N b M C qui
a une largeur de L bits. Un autre aspect porte sur la quantification des bits reçus, ils sont quantifiés
sur Q bits. Toutes les opérations se font donc sur les fiabilités associées. Des simulations ont été effectuées au sein du département électronique de l’ENST-Bretagne afin de quantifier les dégradations
en terme de performances introduites lors de la modification de l’ensemble des paramètres. Le but est
d’effectuer un décodage efficace tout en conservant une complexité raisonnable. En conséquence, les
choix concernant les valeurs des paramètres sont :
– M F : le nombre de symboles moins fiables conservés est de 5. Ce paramètre intervient dans la
construction des vecteurs de test.
– N b v : le nombre de vecteurs de test considérés est de 16. Ils sont construits à partir des symboles
MF. Il s’agit d’un bon compromis performance/complexité [KAP01].
– L : la métrique est quantifiée sur 6 bits.
– N b M C : la complexité de l’algorithme de tri est fonction du nombre total de métriques N b v,
de leur largeur L et du nombre de métriques retenues N b M C. Ce paramètre intervient aussi
dans le calcul de la fiabilité. Il est fixé à 4.
– N b M Futilises : l’utilisation des fiabilités des trois symboles les moins fiables est suffisante.
– Q : ce paramètre a un impact sur la largeur des chemins de données associés à la fiabilité. Les
bits issus du canal sont quantifiés sur 4 bits.
Les critères de choix de notre application parmi l’ensemble des codes envisageables sont la faible
complexité induite et la possibilité de traiter différents rendements de codes. De plus, il est à rappeler
que le décodage de codes BCH et RS nécessite des traitements algorithmiques proches. Ainsi, quatre
codes ont été retenus pour l’implantation de notre application. Les codes produits sont donc construits
à partir :
– des codes BCH primitifs étendus de distance de Hamming respective 4 et 6 et de longueur de
code 32.
– des codes Reed-Solomon de distance de Hamming respective 3 et 5 et de longueur de code 31.
Dans notre cas, les deux codes composant le code produit sont identiques. L’extension des codes
BCH permet d’augmenter la distance minimale des codes produits au prix d’un faible accroissement
de la complexité (ajout d’un bloc de calcul de parité) et d’une légère diminution du rendement. En
96
revanche, il n’y a aucun avantage à utiliser les versions étendues des codes constituants RS [Zho05].
Si le rendement souhaité est d’environ 0.5, un TCB ayant pour code composant un code BCH au
pouvoir de correction de 1 ou 2 représente le meilleur compromis entre performance et complexité.
Le principal avantage des TCB à base de codes Reed Solomon ayant des pouvoirs de correction de
1 ou 2 réside dans leur fort rendement. En effet, pour des rendements élevés (0,8-0,9), un TCBRS nécessite une longueur de mot de code plus faible qu’un équivalent TCB-BCH. Par exemple,
l’utilisation des codes TCB-RS(31,29) et (31,27) permettent de réduire la longueur du code d’un facteur
3 à 4 par rapport à l’emploi de TCB-BCH (128,120) et (128,113). D’un point de vue architectural, cette
caractéristique permet de réduire la complexité de la mémoire RAM et celle du décodeur élémentaire
[PJAJ06b].
BCH
(32,26,4)
t=1 élément binaire
Reed-Solomon
(31,29,2)
t=1 symbole q-aire
Unité de contrôle
BCH
(32,21,6)
t=2 éléments binaires
Reed-Solomon
(31,27,4)
t=2 symboles q-aires
Figure 3.4 — Gestion des différentes configurations envisagées
La figure 3.4 illustre la structure à mettre en oeuvre pour gérer le passage d’une configuration
à l’autre. Une unité de contrôle permet de choisir les caractéristiques souhaitées en fonction des
contraintes de l’utilisateur. Ainsi, le pouvoir de correction t et le type de code composant sont modifiables. Le décodeur élémentaire est conservé au cours du temps mais l’architecture interne doit être
reconfigurée. La flexibilité est introduite par l’utilisation d’un ensemble de multiplexeurs permettant
de passer d’une configuration à l’autre.
3.2.2
Amélioration du traitement lié au processus de turbo décodage
Le processus de turbo décodage est itératif. Une itération de décodage s’effectue en deux étapes
(deux demi-itérations). Dans un premier temps, les données reçues (sous la forme d’une matrice, voir
chapitre 2) sont envoyées au décodeur élémentaire pour un décodage des lignes. La matrice des données
décodées est alors reconstruite. Dans un second temps, les colonnes de cette matrice sont soumises à
97
un autre décodage. De manière générale, le nombre d’itérations est fixé par l’utilisateur. Le principe
itératif est illustré par la figure 3.5.
Réception
Des
données
Décodage
des lignes
1 demi-itération
Réorganisation
de la
matrice
Décodage
des colonnes
1 demi-itération
Réorganisation
de la
matrice
Décodage
des lignes
1 demi-itération
Figure 3.5 — Aspect itératif du processus de turbo décodage
Le décodeur élémentaire est donc l’élément de base du processus de turbo décodage. D’un point
de vue architectural, deux approches sont envisageables :
– Soit le même décodeur élémentaire est utilisé pour réaliser séquentiellement les opérations sur
toutes les lignes puis sur toutes les colonnes. Une unité de contrôle gère la reconstruction des
matrices de données entre chaque étape du processus et l’envoi de chaque mot (ligne ou colonne)
au décodeur élémentaire.
– Soit le décodeur élémentaire est dupliqué de manière à décoder le maximum de lignes et le
maximum de colonnes à chaque demi-itération. Dans ce cas, la gestion des données est plus
complexe pour alimenter chaque module car il faut éviter les conflits de mémoire.
Nous avons retenu la première approche dans notre étude. Dans les deux cas, il est possible de
réduire le temps de traitement des décodeurs. En effet, le critère de performance d’un code correcteur
d’erreur est le taux d’erreur binaire (TEB) à la sortie du décodeur pour un rapport signal à bruit
donné. Ainsi, un critère déclenchant la reconfiguration d’une architecture peut être le rapport signal
à bruit (SNR). Une étude [JD06], en collaboration avec le laboratoire du LESTER, a été menée afin
de déterminer un critère d’arrêt au processus de turbo décodage. Ce critère aurait pour objectif de
98
stopper les itérations du décodeur élémentaire lorsque le gain en taux d’erreur binaire à rapport
signal/bruit donné devient négligeable voire nul. Le but est donc de diminuer la durée du traitement
en fonction du rapport signal/bruit et d’éviter des échanges de données superflus.
Des simulations de type Monte-Carlo du turbo décodage d’un code BCH(32,26)2 pour des rapports
de signal à bruit (Eb /N0 ) variant entre 2 dB et 4dB par pas de 0.5 dB ont été réalisées. Le but est de
vérifier la pertinence des différents critères d’arrêts suivant :
– Référence : pas d’utilisation de critère d’arrêt, il s’agit de la référence pour les autres propositions.
– Critère 1 : un contrôle sur les colonnes après une demi-itération est effectué. Il s’agit de savoir
si les colonnes sont des mots de code. Ce critère est utilisé jusqu’à présent dans les simulations
en langage C.
– Critère 2 : un contrôle sur les deux mots constitués respectivement par la parité des lignes et
des colonnes. Le critère d’arrêt consiste uniquement à vérifier que les deux vecteurs de parité
sont des mots de code.
– Critère 3 : le critère d’arrêt est identique au précédent mais seulement mis en oeuvre à partir de
l’itération 4. Cependant, il est extrêmement rare que 4 itérations de décodage soient nécessaires
à fort rapport signal/bruit.
– Critère 4 : un double critère d’arrêt est appliqué de manière hiérarchique. Ces deux critères
sont :
1. un test sur les vecteurs de parité afin de vérifier qu’ils sont tous les deux des mots de code.
2. si le premier test est validé, un second test est effectué. Ce test est appliqué sur toutes les
lignes afin de vérifier qu’elles sont toutes des mots de code après le décodage colonne (une
itération).
Les simulations sont réalisées sur le même ensemble de matrices afin d’effectuer des comparaisons
valides. Les taux d’erreurs binaires sont obtenus pour un minimum de 100 paquets erronés et pour 1
et 8 itérations de décodage.
Ce travail a permis de vérifier la pertinence du critère 1 utilisé jusqu’à présent (mots de code
suivant toutes les colonnes) puisque les courbes de performances atteintes se calquent sur la référence.
Les simulations (fig. 3.6) montrent que le critère 2 sur les vecteurs de parité est nécessaire mais pas
suffisant. Le critère 3 se révèle suffisant pour des SNR élevés, en revanche les performances restent en
retrait à faible SNR. Une variante est proposée : le critère hiérarchique (4). Les simulations avec un
critère hiérarchique donnent des résultats similaires à la référence et au critère 1.
Nous travaillons dans un contexte où le critère d’arrêt serait effectué par un processeur et non
par le décodeur élémentaire. Dans ce cas, l’intérêt du critère hiérarchique est qu’il nécessite moins de
calculs que le critère vérifiant que toutes les colonnes sont des mots de code à chaque demi-itération.
99
1.00e-2
1.00e-3
1.00e-4
TEB
1.00e-5
Réf. et critère 1: it. 1
Réf. et critère 1: it. 8
critère 2: it. 1
critère 2: it. 8
critère 3: it. 1
critère 3: it. 8
critère 4: it. 1
critère 4: it. 8
1.00e-6
1.00e-7
2.0
2.5
3.0
3.5
4.0
SNR en dB
Figure 3.6 — TEB en fonction du rapport signal à bruit pour différentes itérations
Nous conserverons donc ce critère d’arrêt dans la suite de l’étude.
3.2.3
Conclusion
Une étude de complexité a permis de déterminer les paramètres de l’application et leurs impacts
sur la complexité. Deux points de flexibilité ont été conservés : le type de code BCH ou RS et le
pouvoir de correction t. De plus, la modification des autres paramètres évoqués autorise une certaine
marge de manœuvre sur la complexité totale du décodeur. Il est à noter que l’intégration d’un turbo
décodeur dédié à des codes produits à base de code Reed Solomon est une innovation à elle seule. En
effet, il s’agit, à notre connaissance, de la première solution architecturale proposée pour le décodage
de tels codes [PJA+ 06]. D’autre part, le temps de traitement a été réduit par l’adoption d’un nouveau
critère d’arrêt. Cette étude permet d’ajouter un rôle supplémentaire à une unité de contrôle déjà
chargée de la configuration du décodeur élémentaire par ailleurs. La suite de ce chapitre s’intéresse
aux descriptions architecturales retenues pour les processus de codage et de turbo-décodage. Pour ce
dernier, la découpe réalisée s’appuie sur l’étude de complexité présentée.
100
3.3
Conception du codeur flexible
La structure du codeur demeure relativement classique au vu des architectures existantes. Toutefois, il a subi des modifications afin de bénéficier de la flexibilité souhaitée. En effet, il supporte
l’ensemble des codes traités par la partie de décodage. D’un point de vue architectural, il est constitué
de deux codeurs élémentaires, d’une mémoire RAM et d’une unité de contrôle (fig. 3.7).
Figure 3.7 — Bloc diagramme du codeur dédié aux codes produits
Bien sûr, il aurait été possible de n’utiliser qu’un seul codeur puisque que le parallélisme n’est
pas exploité ici. Cependant, il faudrait alors considérer une mémoire double port autorisant à la fois
la lecture et l’écriture simultanées des données. Le gain de surface engendré par l’utilisation d’un
seul codeur est alors estompé par l’augmentation de l’occupation de la mémoire car la complexité du
codeur est faible.
Au niveau temporel, deux phases sont nécessaires pour construire la matrice de données Mc du
code produit. Tout d’abord, un premier codeur élémentaire traite les lignes de la matrice d’information
Mi . L’ensemble des mots de code générés est stocké dans une mémoire RAM lors d’une phase d’écriture. Puis une phase de lecture permet de récupérer les colonnes de Mi qui sont alors traitées par le
second codeur élémentaire. Les temps de traitement sont différents pour les deux étapes. Par exemple,
dans le cas du code BCH(32,26), la latence du premier codeur est de 26 × 32 temps de cycle, tandis
que pour le second, elle est de 32 × 32. Une unité de contrôle se charge à la fois de la configuration,
de l’adressage de la mémoire et des signaux de contrôle de l’ensemble du codeur. Classiquement, l’implantation du codeur utilise des registres à décalage à rétroaction linéaire plus communément appelé
LFSR (Linear Feedback Shift Register) pour définir la division polynomiale d’un corps fini. Le codeur
se compose de n − k parties identiques formées chacunes d’un multiplieur, d’un additionneur et d’un
registre (fig. 3.8). Notre codeur élémentaire doit être capable de supporter le processus de codage des
4 configurations retenues. L’idée est donc de prévoir la mise en place de toutes les ressources nécessaires aux configurations les moins favorables, c’est à dire typiquement le code BCH(32,21) pour le
3.3. CONCEPTION DU CODEUR FLEXIBLE
101
nombre de registre à décalage et les codes Reed-Solomon pour la largeur des chemins de données m.
De plus, un bit de parité est calculé dans le cas d’un code BCH. Le polynôme générateur du code,
g(x) = g0 + g1 x + . . . + gr xr où r est le nombre de symboles redondants, est paramétrable de manière
à produire les symboles de redondance associés aux données. Les coefficients gi des polynômes générateurs associés à chaque code peuvent être trouvés dans la littérature [Pet60][CC81]. Ceux concernant
notre étude sont donnés dans le tableau 3.5 sous les formes binaire pour le BCH et décimale pour le
RS. Dans tous les cas, le mot de code élaboré se présente sous la forme systématique.
Code
BCH(32,26)
BCH(32,21)
RS(31,29)
RS(31,27)
Coefficients binaire ou Q-aire du polynôme générateur
1,0,1,0,0,1
1,1,0,1,0,1,1,0,1,1,0,0
8,6
17,9,6,30
Tableau 3.5 — Coefficients des polynômes générateurs g(x) des codes traités
Figure 3.8 — Schéma du codeur élémentaire
La mémoire RAM stocke les données codées après un premier codage des lignes. Comme pour
le codeur élémentaire, ses dimensions dépendent des configurations les moins favorables caractérisées
par :
– la largeur m (=5) des données des codes Reed-Solomon (31,27) ou (31,29).
– la longueur des codes BCH(32,26) ou (32,21).
– la dimension du code Reed-Solomon (31,29).
Au total, la taille de la mémoire utilisée est de 5 × 32 × 32 soit 5120 bits.
Une structure de contrôle supervise l’ensemble du codeur. La configuration est donnée par deux
entrées binaires qui définissent le type de code et le pouvoir de correction choisis. Les polynômes
générateurs et les compteurs nécessaires aux codeurs élémentaires sont donc fonction de ces entrées.
102
L’unité reçoit les données à coder de manière synchrone. Elle est aussi chargée de la lecture/écriture
et de l’adressage mémoire.
3.4
Conception du turbo décodeur flexible
Cette section présente l’architecture hétérogène conçue pour le turbo décodage des codes en blocs
de type BCH et Reed-Solomon. Elle tient compte de la flexibilité introduite auparavant. Il faut distinguer deux niveaux de hiérarchie dans l’architecture présentée. Le premier niveau concerne le décodeur
élémentaire chargé du traitement des lignes et des colonnes de la matrice à décoder. Pour cela, une
mémoire interne est nécessaire au stockage des lignes (ou des colonnes) en cours d’utilisation. Sa taille
dépend directement de la profondeur du pipeline employé. Le second niveau correspond à la gestion
des données reçues pour le processus turbo, c’est à dire à la fois l’injection des données initiales dans le
décodeur élémentaire puis la réinjection des données décodées à chaque demi-itération. Les matrices à
traiter sont stockées dans des plans mémoires externes adressés par le processeur. Ainsi, un processeur
NIOS II est chargé des opérations de contrôle et de gestion de configuration. En résumé, l’architecture se compose d’une unité de contrôle associée à une mémoire externe et d’une unité de traitement
(décodeur élémentaire) munie d’une mémoire interne. L’architecture globale est décrite sous la forme
d’un schéma bloc (fig. 3.9).
3.4.1
Architecture générale du décodeur élémentaire
L’architecture du décodeur élémentaire pour des codes BCH a fait l’objet de nombreux travaux
au sein du département électronique de l’ENST Bretagne [Rao97][KAP01][CAKP02]. Ainsi, des architectures innovantes ont été proposées pour permettre le développement d’implémentations les plus
performantes possibles. Des études algorithmiques ont parallèlement été menées au sein du département Signal et Communications pour l’adaptation du turbo décodage des codes produits à base de
codes Reed-solomon [Aı̈t98][Zho05]. Le but de notre étude est d’implanter les modules nécessaires au
décodage de ces derniers en conservant l’architecture de base déjà élaborée.
Ce décodeur élémentaire est constitué de 3 parties : réception, traitement et émission. La gestion
des quatre configurations nécessite une décomposition temporelle adaptée. Ainsi, chaque étage réalise
sa fonction en un temps mot, c’est à dire qu’il faut 32 périodes d’horloge dans le cas d’un code binaire
BCH de longueur n = 32 et 31×5 périodes d’horloge dans le cas d’un code q-aire RS de longueur n = 31.
La latence est donc de trois temps mot pour l’ensemble d’un mot de code, cependant le délai entre
la réception du dernier symbole et la production du premier symbole décodé est seulement de deux
temps mot. Les opérations dans les blocs de réception et d’émission se font de manière séquentielle,
en revanche la partie de traitement est plus critique. En se donnant un temps mot pour le traitement,
la découpe temporelle proposée sur la figure 3.10 implique l’utilisation de deux horloges, l’une Ha
5
Rinit
αi
5
6 RAMs
32x5x5
Syndrome
Parité
Bloc des
moins fiables
Processeur
NIOS II
R’
R’init
4x5
Si
Métriques
8
ROM
Galois
32x5
8
D
Bloc d’émission
Cp_Md&Mc
Mdp Calcul des
Par&Cw
Mémoire
Ri+
βi
R’
5
R’init
Information
Décodage
5 extrinsèque
Tri des mots M_Md&Mc
algébrique Lr P
concurrents
W 8
et
Fiabilité 5
5x8
décidés
Ci&Ei
Lr_p_Md&Mc
Correction du
4x5
R’ mot de code
Signaux
Compteur
Type de code
Construction
8
des
Vecteurs
Lr P
de test
5x8
1
Mdp
Bloc de traitement
Par
Légende:
4x5
Si
1
Par
5x8
Lr Pi
Unité de
contrôle
Bloc de réception
5
R
3.4. CONCEPTION DU TURBO DÉCODEUR FLEXIBLE
103
Figure 3.9 — Schéma-bloc du décodeur élémentaire RS/BCH
est relative aux parties réception et émission, l’autre Ht à la partie de traitement. L’objectif est de
respecter un délai de décodage pour l’ensemble des 16 vecteurs de test égal à 32.r.Ha (avec r = 1 pour
un code BCH et r = 5 pour un code RS). Ainsi, par exemple, il faut huit périodes d’horloge pour
104
effectuer le décodage algébrique d’un vecteur de test dans le cas d’un code BCH ayant un pouvoir de
correction t = 2. La fréquence de l’horloge de traitement Ht est alors quatre fois plus élevée que celle
de Ha . Pour chaque configuration, ce rapport est différent.
Bloc
de réception
Reception
block
32 r Ha
Bloc de traitement
Processive
block
16*2 r Ha
Bloc
d’émission
Emission
block
32 r Ha
2 r Ha
16
algébriques
16 décodages
algebrai c decoding
BCH t=1
Ha=Ht, r=1
22 périodes
clock periods
d’horloge
BCH t=2
Ha=4Ht, r=1
clock periods
88périodes
d’horloge
RS t=1
RS t=2
Ha=2Ht, r=5
Ha=Ht, r=5
20
clock periods
10
clock periods
10 périodes
d’horloge 20 périodes
d’horloge
Figure 3.10 — Structure temporelle pour le décodage de mot de code de 32 symboles
Dans la suite, les blocs associés aux trois parties et le fonctionnement de la mémoire interne sont
décrits. Tout d’abord, les modules constituant la partie de réception sont explicités. Ensuite, la partie
de traitement réalisant notamment la fonction de décodage algébrique est abordée. Puis la partie
émission est donnée. Enfin, la dernière sous-section explique le choix et les modes de fonctionnement
pour la mémoire interne.
3.4.1.1
Partie réception
Le bloc de réception travaille séquentiellement en fonction de l’arrivée des symboles binaires.
L’entrée reçoit la valeur pondérée associée au bit entrant. Chacun des blocs de la partie réception
fonctionne de manière indépendante. Ils réalisent le calcul du syndrome (1 à 2t composantes suivant
le pouvoir de correction t et le code), le calcul éventuel de la parité (t = 1) et la détermination des
bits les moins fiables. Enfin, une ROM contient la table du corps de Galois nécessaire au traitement.
Les signaux de contrôle fournissent le type de code et la synchronisation des traitements en fonction
de l’arrivée des données.
Le calcul du syndrome
Ce bloc doit gérer à la fois les symboles binaires et q-aires. Par conséquent, un registre tampon
105
permet de reconstituer un symbole q-aires pour le calcul des composantes du syndrome pour un code
Reed-Solomon tandis que seul le bit de signe est nécessaire pour l’élaboration du syndrome dans le cas
d’un code BCH. Le coeur du bloc syndrome (fig. 3.11) est composé de blocs élémentaires (fig. 3.12)
permettant de calculer chaque composante du syndrome. L’élément du corps de Galois nécessaire au
calcul de chaque composante est stocké dans un registre. Le bloc syndrome est modulable suivant le
nombre d’erreurs t à corriger et le type de code. En effet, le nombre de blocs élémentaires utilisés
varie entre 1 et 2t en fonction de la configuration requise. Une fois le mot reçu, les composantes du
syndrome sont produites en sortie.
Figure 3.11 — Bloc de calcul du syndrome
Figure 3.12 — Bloc élémentaire du syndrome
Le calcul de la parité
Ce bloc est uniquement utilisé pour des codes BCH étendus. Il calcule la parité du mot reçu R à
partir du signe de tous les symboles. Il mémorise également la fiabilité du symbole de parité qui est
utilisée dans le bloc de traitement.
La localisation des bits les moins fiables
Sur les cinq bits définissant l’échantillon en entrée, le bit de poids fort représente le bit de signe et
les quatre autres correspondent à la fiabilité associée. A la réception d’un nouveau symbole du mot
reçu, la fiabilité est comparée aux fiabilités des symboles précédents. Si elle est inférieure à l’une des
fiabilités conservées alors la position et la valeur de la nouvelle fiabilité sont triées et mémorisées. Pour
le code BCH, seulement cinq bits sont nécessaires pour situer le symbole dans le mot. En revanche,
dans le cas d’un code RS, il faut à la fois la position du symbole dans le mot et la position du bit dans
le symbole. Huit bits sont donc utilisés pour stocker la position d’un bit le moins fiable. Le schéma de
ce bloc est représenté sur la figure 3.13.
106
Type de code
1
Positions des
moins fiables
Symbole du
mot reçu R
5
Bloc des symboles
les moins fiables
8x5
Fiabilités des
moins fiables
4x5
8
Position du compteur
Figure 3.13 — Schéma du bloc des symboles les moins fiables
3.4.1.2
Partie traitement
Le bloc de traitement est la partie critique du décodeur élémentaire qui permet à la fois :
– la génération de 16 vecteurs de test et de leur syndrome respectif.
– le décodage algébrique de chacun des vecteurs de test.
– la production et le tri des métriques associées.
La construction des vecteurs de test
La construction des vecteurs de test est une étape importante de l’algorithme de Chase [Cha72]. La
complexité du circuit et les performances du décodeur dépendent fortement du choix effectué pour
leur élaboration. Pour cinq bits moins fiables considérés, il est possible d’élaborer 25 vecteurs de test.
Les performances du décodeur sont meilleures avec une sélection de 32 vecteurs de test (VT) que
pour 16 ou encore même que 8. Une étude a montré qu’une sélection rigoureuse des vecteurs de test
permet de réduire la complexité et l’efficacité du décodage [KAP01]. Un compromis de 16 vecteurs de
test permet de conserver des performances acceptables tout en réduisant le temps de traitement pour
l’ensemble des séquences.
De plus, afin de réduire le temps et la complexité de la construction des vecteurs test, [HHM01]
propose de les générer de manière ordonnée. Le calcul des syndromes et des métriques engendrées
est alors plus simple. Les blocs de construction des vecteurs de test fonctionnent de paire avec le
bloc d’élaboration des métriques. Une autre approche [AM04] propose d’améliorer la démarche en
s’affranchissant du ré-ordonnancement des motifs d’erreurs à l’aide d’un code de Gray et en permettant
l’adaptation du nombre p de symboles moins fiables en fonction du nombre d’itérations. En considérant
uniquement la première approche, si les motifs d’erreurs sont ordonnés de façon à ce qu’un seul bit
diffère d’un vecteur de test à l’autre, alors des opérations simples donnent le syndrome et le nouveau
motif d’erreurs à partir du précédent.
107
Les composantes du syndrome initial et les bits les moins fiables ont été calculés dans le bloc
de réception. Des tables sont utilisées pour les motifs d’erreurs. Une information sur l’addition ou la
soustraction (AS) de la métrique est également nécessaire. Dans le cas de l’utilisation de 16 vecteurs
de test, 3 inversions au maximum sont réalisées parmi les 5 bits les moins fiables. Un code de Gray
est obtenu avec les vecteurs de test choisis préalablement dans [CAKP02] avec la combinaison choisie
(tab. 3.6), cependant l’un d’eux doit être changé parmi ceux pris habituellement.
ME0
ME1
ME2
ME3
ME4
ME5
ME6
ME7
ME8
ME9
ME10
ME11
ME12
ME13
ME14
ME15
MF4/MF3/MF2/MF1/MF0
00100
10100
10000
11000
01000
01010
01011
01001
01101
00101
00111
00110
00010
00011
00001
00000
AS
0
0
1
0
1
0
0
1
0
1
0
1
1
0
1
1
Tableau 3.6 — Les motifs d’erreurs considérés
Les composantes du vecteur de test en cours (4 au maximum) sont obtenues en effectuant une
multiplication et une addition dans le corps de Galois(CG(25 )). Ceci implique que les éléments du
corps de Galois soient également disponibles dans une RAM embarquée de taille 4 × 5 × 32 bits.
TP
Start
ValidPos Poids Hamming
3
Positions des MF
Syndrome du VT
5x8
4x5
Fiabilités des MF
5x4
Syndrome initial
Position du MFmo
Construction des
vecteurs de test
4x5
8
Fiabilité du MFmod
4
Compteur GF
Motif d’erreurs
8
3
Code
Figure 3.14 — Schéma du bloc de construction des vecteurs de test
108
En plus du signal d’ajout ou retrait de la métrique, la position du bit le moins fiable modifié et
un signal de début de traitement sont transmis au bloc de calcul des métriques. Le schéma bloc de ce
module est donné sur la figure 3.14.
Le décodeur algébrique
Le bloc décodage algébrique permet de décoder successivement les 16 vecteurs de test élaborés. Les
données sont aiguillées en fonction de la configuration choisie. Un jeu de multiplexeurs gère alors le
chemin de donnée. Le schéma bloc est donné sur la figure 3.15.
Par
Md_p
Lr_p
BCH t=1
Si
autres
Algorithme
PGZ
Parité
Xi=Si
C(x)
LUT des
σ(x)
Par
Xi
Xi
BCH t=2
RS t=1,2
Calcul de
la valeur Ei
Xi de l’erreur
Vérification
du mot de
Xi
code
Si
BCH t=1
Ei
Xi
autres
Décodage des vecteurs de test
Figure 3.15 — Décodeur algébrique
Le bloc de l’algorithme PGZ détermine les coefficients du polynôme localisateur d’erreurs du vecteur de test en cours de traitement. Les valeurs de ces coefficients sont déterminées grâce à l’algorithme
décrit aux sections 2.2.2.2 et 2.2.2.1. Dans ce cas, des multiplieurs dans CG(25 ), des diviseurs et des
comparateurs sont nécessaires. Cependant, deux étapes successives permettent de remplacer l’opération complexe de division. Concrètement, une table (32 × 5 bits) jouant le rôle de l’inversion et une
multiplication par le numérateur se substituent à l’opération de division. Enfin, des signaux supplémentaires indiquent si un échec de décodage est intervenu lors du décodage algébrique ou si le mot
corrigé est un mot de code.
La détermination des racines du polynôme localisateur d’erreurs σ(x) s’effectue par l’intermédiaire
d’une table pré-calculée ayant pour entrées les coefficients σ1 et σ2 . La sortie fournit les racines solutions
Xi si elles existent ou indique un échec de décodage dans le cas contraire.
109
Le bloc de correction constitue la deuxième partie de l’algorithme PGZ. En effet, seul le décodage
d’un code Reed-Solomon nécessite la détermination de la valeur des erreurs. Les racines X1 et X2 du
polynôme localisateur d’erreurs et les composantes S1 et S2 sont les entrées de ce bloc. Des calculs
dans le corps de Galois associé fournissent l’amplitude des erreurs. Une table d’inversion est également
employée.
Enfin, le bloc de vérification permet de savoir si le mot corrigé est un mot de code et si la correction
a été efficace. Ainsi, les composantes du syndrome sont recalculées en fonction de la correction proposée
et du syndrome déterminé initialement. Si elles sont nulles alors il s’agit bien d’un mot de code. Une
mémoire est utilisée pour les éléments du corps de Galois (α2i ,α3i ,α4i ).
Parallèlement à tous ces blocs, un module calcule la parité de chaque vecteur de test. Seul le
décodage des codes BCH nécessite l’utilisation de ce bloc.
Le calcul des métriques
Ce module (figure 3.16) fonctionne de manière conjointe avec le bloc de construction des vecteurs de
test. A ce niveau, le traitement repasse au niveau binaire puisque le calcul des métriques s’effectue
avec la fiabilité des bits erronés. Le signal d’initialisation start indique qu’un nouveau mot est traité.
La métrique et les positions des 3 bits les moins fiables sont remis à zéro. On rappelle qu’il y trois
inversions au maximum parmi les 5 bits les moins fiables. Les positions des trois bits les moins fiables
sont rangées par comparaison avec celles enregistrées précédemment et identifiées pour savoir si elles
sont à prendre en considération.
TP
ValidPos
Start
Poids Hamming
3
Positions des MF
Métriques
8
4x5
Fiabilités des MF
4
Mot de code
Position du MFmo
Bloc de calcul
des métriques
4x5
3x8
Fiabilité du MFmod
3x4
Valeur des erreurs
Erreurs
8
3
Fiabilités des bits corrigés
2x5x4
Code
Figure 3.16 — Schéma du bloc de calcul des métriques
Dans le cas du décodage d’un code BCH, la correction se fait sur un ou deux bits donc au
maximum deux fiabilités sont nécessaires. Une comparaison avec les bits inversés permet de vérifier
110
que les fiabilités ne sont pas prises en compte deux fois. Il faut également utiliser la fiabilité de la
parité dans le cas d’une parité erronée. Ainsi, la métrique est égale à :
M etrique = M Finv1 + M Finv2 + M Finv3 + f iabparite + f iabbitcorrige1 + f iabbitcorrige2
(3.4.1)
où M Finvi sont les fiabilités des bits inversés parmi les 5 bits les moins fiables.
En revanche, dans le cas du RS, la correction s’effectue sur des symboles. C’est pourquoi, la
totalité des fiabilités des bits composant le symbole corrigé est exploitée. La métrique se calcule par
la sommation suivante après vérification que la correction ne se fait pas sur des bits inversés :
M etrique = M Finv1 + M Finv2 + M Finv3 + f iabsymbolecorrige1 + f iabsymbolecorrige2
(3.4.2)
où f iabsymbolecorrige1 est la somme des fiabilités des bits composant le/les symboles corrigés.
Le bloc de tri des métriques
Ce bloc trie les vecteurs de tests sortant du décodeur binaire suivant leur métrique, en ayant préalablement vérifié qu’il s’agit de mots de code. Le mot décidé Md est celui ayant la métrique la plus faible.
Puis, les trois vecteurs de test ayant les plus faibles métriques, après le mot décidé, sont conservés
comme mots concurrents (Mc ). Deux vecteurs de test identiques ne sont pas tous les deux retenus.
3.4.1.3
Partie émission
Le bloc d’émission récupère les données issues du tri des métriques. La fiabilité est élaborée à
partir du mot courant, du mot décidé Md et des mots concurrents Mc . L’information extrinsèque est
générée à partir de la fiabilité pondérée d’un coefficient alpha et ajoutée à chaque symbole du mot
présenté à l’entrée du décodeur élémentaire.
Le calcul de la fiabilité
Ce bloc calcule la nouvelle fiabilité de chaque bit à partir du mot décidé et des mots concurrents.
La valeur de cette fiabilité est égale à la différence entre le mot décidé et le mot concurrent retenu
Mc − Md . S’il n’existe pas de mot concurrent parmi les vecteurs de test alors une valeur β est affectée.
Dans notre cas, elle est égale à :
β = Rk + M F2 + M F3 + M F4 − Md
(3.4.3)
où M Fi sont les fiabilités des bits les moins fiables.
Si le mot produit lors du décodage algébrique n’est pas un mot de code alors la fiabilité est égale
à :
f iabilité = β + 2
(3.4.4)
111
Ce paramètre β croit donc au fur et à mesure des itérations puisque les bits deviennent de plus
en plus fiables.
Le calcul de l’information extrinsèque
Ce bloc (figure 3.17) calcule l’information extrinsèque W qui est la différence entre l’information
disponible après le décodage et l’information connue avant le décodage. Elle constitue l’apport
du processus de décodage permettant de déterminer l’information émise. Le détail du calcul a été
explicité dans la section 2.3.3.
IE
Fiabilité
6
Inversion signe
R’’ Fiabilité
6
Bloc de calcul de
l’information
extrinsèque
Signe IE
Décision ferme
5
Figure 3.17 — Schéma du bloc de calcul de l’information extrinsèque
Correction du mot de code
Ce bloc (figure 3.18) réalise à la fois la pondération de l’information extrinsèque et la sommation avec
le mot reçu initialement R.
R0 = R + α.IE
(3.4.5)
Le coefficient de pondération α dépend de l’itération en cours. Ce nombre est d’autant plus élevé
que le nombre d’itération croı̂t. En effet, au fur et à mesure du processus de décodage, l’apport
du décodeur devient pertinent. L’information extrinsèque pondérée est ensuite sommée. Le signe est
important puisqu’il peut s’agir soit d’une soustraction ou d’une addition.
3.4.1.4
Mémoire interne
Des mémoires sont nécessaires pour les trois parties précédentes : réception, traitement et émission
[CAKP02]. En effet, un mot doit être disponible pour chaque partie du décodeur élémentaire. De plus,
112
Į
4
IE
R’’suivant
Calcul du nouveau
R’
6
6
5
R Fiabilité
Figure 3.18 — Schéma du bloc de calcul du nouveau R”
il faut mémoriser à la fois le mot à traiter R” et le mot initial reçu R. Au total, il faut donc 6 (2 × 3)
mémoires RAM. La taille par défaut de chacune de ces mémoires est de 32x5x5 bits. La configuration
la moins favorable est considérée de manière à conserver la même structure quelque soit le code choisi.
Une machine d’états finis gère l’ensemble des mémoires afin de fournir les mots corrects aux différents
partie du décodeur élémentaire (fig. 3.19).
Mémoire R
R
RAM 1
RAM 2
RAM 3
R’_fiab
5
Adresse
R’’
5
Data
5
R’_metr
Machine d’états finis
Adr_CG
2x4x5
Adresse
3+5
Data
R_fiab
Pos_Cor
3+5
RAM 1
RAM 2
RAM 3
5
Mémoire R’’
Figure 3.19 — Schéma bloc de la mémoire
Le fonctionnement des mémoires est circulaire, c’est à dire que leur rôle passe successivement d’un
mode à l’autre pour reprendre leur état initial. La figure 3.20 illustre l’évolution du rôle des RAM
au cours du temps. Lors de la réception, les données sont écrites en mémoire tandis que lors d’un
traitement ou de l’émission, elles sont lues. L’ensemble des configuration mémoire est réalisé par une
113
machine d’états. Elle gère également leur adressage à travers l’utilisation de l’entrée du signal du corps
de Galois sur 5 bits pour les phases de réception (écriture) et d’émission (lecture). L’exploitation des
données R” et R est différente pour le traitement. En effet, la correction du vecteur de test fournit
la position du ou des bits à corriger pour d’abord élaborer la métrique puis récupérer les fiabilités
associées.
Temps
Réception
RAM 1
RAM 3
RAM 2
RAM 1
RAM 3
RAM 2
Traitement
RAM 2
RAM 1
RAM 3
RAM 2
RAM 1
RAM 3
Réception
RAM 3
RAM 2
RAM 1
RAM 3
RAM 2
RAM 1
Modules concernés
Figure 3.20 — Fonctionnement des mémoires RAM au cours du temps
3.4.2
L’unité de contrôle
Un processeur de type NIOS joue le rôle de l’unité de contrôle dans notre étude. La mise en place
d’un processus de communication entre les entités est nécessaire. Ainsi, le bus système Avalon est utilisé
dans la solution SoPC d’Altera. L’interface de la partie processeur avec le bus de communication est
pré-définie, cependant une interface est à mettre en place pour le décodeur élémentaire. Le processeur
doit également gérer le processus itératif de turbo décodage. Ainsi, la manipulation des données
stockées en mémoire externe est réalisée par le NIOS. Cette mémoire contient à la fois les données
reçues issues du canal de transmission, les données obtenues lors d’un premier traitement suivant les
colonnes et enfin les données décodées résultant de la demi-itération courante. Trois plans mémoires
de la taille d’une matrice (32*32*5=5120 bits) constituent la mémoire externe.
3.4.2.1
la gestion de la communication entre le processeur et des périphériques : le bus
système Avalon
Le bus utilisé pour la communication entre le processeur et les différents périphériques est un bus
système Avalon. Il s’agit d’un bus développé par la société Altera qui est destiné à être implémenté
sur des composants programmables de type FPGA. Ses principaux atouts sont la simplicité de son
114
architecture favorisant l’utilisation des ressources matérielles et un support multi-maı̂tre. Un port
Avalon est un ensemble de signaux utilisés comme une simple interface. Il peut être configuré en mode
maı̂tre ou esclave. Ainsi, un port esclave répond à une requête de transfert de données tandis qu’un
port maı̂tre initie ce transfert. Ils ne sont pas connectés directement les uns aux autres. Les ports sont
connectés à un bus qui se charge de retranscrire les signaux entre eux. Les modes de fonctionnement
des deux types de ports étant différents, il est nécessaire de les distinguer. Un port est disponible au
cycle suivant la fin d’un transfert. Un cycle correspond à une période de l’horloge associée avec le port
concerné.
Dans notre étude, seul le processeur dispose d’un port maı̂tre. Il commande l’échange de données
et est prioritaire du fait de son unicité. Les périphériques tels que les mémoires externes ou le décodeur
élémentaire utilisent, quant à eux, un port esclave. Les signaux composant l’architecture du bus Avalon
sont :
– clk : l’horloge synchrone avec toutes les interfaces Avalon (maı̂tre ou esclave) et donc avec tous
les signaux du bus.
– chipselect : la validation de ce signal (1 bit) permet l’utilisation du bloc logique associé.
– address : ce signal sert de compteur pour l’ensemble des symboles de la trame. La largeur de
l’adresse est de 5 bits.
– read n : ce signal (1 bit) est positionné à zéro lorsque le mot reçu issu du canal est écrit sur le
bus de communication.
– write n : ce signal (1 bit) indique que des données sont lues sur le bus Avalon. A chaque
récupération de la séquence décodée, write n est positionné à zéro.
– writedata : il s’agit du bus contenant les données et les signaux de configuration destinés au
décodeur élémentaire. Ainsi, la partie haute de ce champ contient les données R et R’ qui sont
quantifiées sur 5 bits (1 bit de signe et 4 bits de quantification). Le type de code employé et
le pouvoir de correction souhaité sont fournis à l’aide de deux bits. De plus, un bit est utilisé
pour signaler le début d’un mot de code. Enfin, le numéro de l’itération en cours est précisé sur
3 bits.
– readdata : Ce bus de 5 bits permet d’envoyer les nouveaux symboles du mot décodé au processeur NIOS.
Il faut noter que la largeur des champs readdata et writedata sont identiques, c’est à dire sur 32
bits, puisque les deux sont utilisés conjointement.
3.4.2.2
la communication dans notre architecture
Le processeur NIOS considéré est de type RISC et possède un chemin de données sur 32 bits.
Différentes interfaces peuvent être paramétrée au sein du coeur de processeur. Dans notre cas, ce
dernier dispose de l’ensemble des interfaces lui permettant de communiquer avec les plans mémoires
115
et le décodeur élémentaire. La largeur du bus d’adresse (32 bits) fixe la profondeur de l’espace adressable disponible. De plus, chaque périphérique bénéficie d’une zone d’adressage définie. L’architecture
résultante de nos choix est donnée sur la figure 3.21.
Processeur NIOS
Port maître
Avalon
Mémoire On Chip
Décodeur
RAM
élémentaire
Port esclave
Avalon
Port esclave
Avalon
Bus Avalon
Port esclave
Avalon
Port esclave
Avalon
RAM
RAM
Mémoire On Chip
Mémoire On Chip
Tri-State
Avalon
Mémoire externe
de boot
FPGA
Figure 3.21 — Architecture hétérogène retenue pour l’implantation
Ainsi, les différents éléments composant le processeur sont :
– le coeur de processeur RISC NIOS. Il s’agit d’un processeur de type Harvard possédant 5 étages
de pipeline. Les bus d’instructions et de données sont des bus systèmes propriétaires Avalon de
chez Altera,
– une interface pour le décodeur élémentaire,
– une interface pour chacune des mémoires embarquées (On Chip) qui sont gérées à travers le bus
Avalon configuré en esclave. La mémoire est répartie sur des blocs de mémoires RAM dédiées
se trouvant sur le FPGA,
– une interface pour la mémoire de boot à partir de laquelle la configuration initiale est chargée,
– l’interface maı̂tre du bus Avalon.
la communication entre le processeur et le décodeur élémentaire
Le décodeur élémentaire utilise un port Avalon configuré en esclave. Une interface très simple est
mise en place pour s’adapter au bus de communication. Nous nous intéressons ici à l’aspect logiciel. Le
langage de développement utilisé est le langage C. Un compilateur se charge de transformer le code C
élaboré en langage assembleur puis en un fichier exécutable. En dehors de la définition du processeur
souhaité, le fonctionnement interne et la gestion des différentes ressources de la cible via le bus Avalon
sont donc quasi-transparentes pour le concepteur. L’algorithme s’exécutant sur le processeur est donné
en figure 3.22. En faisant abstraction du processus itératif que nous expliquons ensuite, le passage des
116
données dans le décodeur élémentaire correspond à une demi-itération, c’est à dire soit un décodage
des lignes ou des colonnes (Boucle 2 ou 4 sur la figure 3.22). A l’intérieur de ces boucles, une phase
d’initialisation est nécessaire. Les symboles de chaque mot sont ensuite envoyés séquentiellement et
les symboles décodés sont récupérés.
Boucle 1 itération début\\
Boucle 2 décodage ligne début\\
init début
Envoi des n symboles du 1er mot
Envoi des n symboles du 2ème mot
Envoi des n symboles du 3ème mot
Phase
d’initialisation
Récupération 1er mot traité
init fin\\
Boucle 3 des n lignes de mots restants début
Envoi des n symboles des mots restants
Récupération mots traités
Cœur du
traitement des
lignes
Boucle 3 des n lignes de mots restants fin
Boucle 2 décodage ligne fin
Boucle 4 décodage colonne début\\
...
Traitement des
colonnes
Boucle 4 décodage colonne fin\\
Boucle 1 itération fin\\
Figure 3.22 — Algorithme du programme exécuté sur le processeur NIOS
la communication entre le processeur et la mémoire
Le processeur NIOS possède un bus d’instruction et un bus de données. Dans un premier temps,
le bus d’instructions a une largeur de 16 bits. Ce bus, configuré en mode maı̂tre, est seulement utilisé
pour aller chercher les instructions en mémoire. Le processeur bénéficie de la technique de prédiction de
branchement pour spéculer sur les adresses suivantes. Ainsi, les pénalités sont dues exclusivement aux
erreurs de prédiction. Une mémoire cache peut être embarquée pour améliorer la vitesse de récupération
des instructions. Dans un second temps, le bus de données du NIOS, configuré en maı̂tre, manipule
des données sur 32 bits. Il est utilisé pour trois types d’opérations :
1. lire les données à partir de la mémoire externe. Le processeur exécute une instruction de chargement (LD, LDP, LDS).
2. écrire les données en mémoire externe. Le processeur exécute une instruction de stockage (ST,
STP, STS, ST8s, ST8d, ST16s, ST16d, STS8s, STS16s).
3. gérer les interruptions liées à l’utilisation des périphériques.
117
Les opérations de lecture/écriture sont effectuées en une seule période d’horloge lorsque le bus est
connecté à une mémoire disponible. Ceci implique qu’il n’y ait pas de conflit d’arbitrage avec le bus
d’instruction.
i-ème itération
Mem
RX
Mem
RX
Décodeur
élémentaire
Mem
lignes
Mem
RX
Décodeur
élémentaire
Mem
colonnes
Mem
lignes
Figure 3.23 — Utilisation des mémoires lors du décodage itératif
Pour notre application de turbo décodage de codes produits, trois plans mémoires sont utilisés. Le
premier M emRX est utilisé pour stocker la matrice d’information à décoder. Le second M em lignes
permet le stockage des données obtenues après une demi-itération, c’est à dire après un passage dans
le décodeur élémentaire. Enfin, le dernier M em colonnes contient les données décodées au bout
d’une itération soit après un deuxième passage pour le décodage des colonnes. La figure 3.23 illustre
l’utilisation des différents plans mémoires au cours du processus.
Gestion de l’aspect itératif du turbo décodage
L’aspect itératif du turbo décodage est entièrement défini dans le programme exécuté par le
processeur NIOS. En effet, en se référant à la figure 3.22, on note que les boucles réalisant les opérations
sur les lignes puis sur les colonnes se succèdent. La réitération de ces deux étapes constitue une itération
de décodage. Ainsi, l’application logicielle effectue le chargement des données, l’envoi au décodeur
élémentaire et la récupération des données décodées pour l’ensemble des demi-itérations. Comme nous
l’avons évoqué précédemment, l’adressage des parties mémoires externes est géré par le NIOS.
3.4.2.3
Evolution de la communication dans notre architecture
Suite à l’évolution des solutions proposées par le fabricant Altera, le processeur NIOS a été remplacé par un processeur de deuxième génération appelé NIOS II. Ainsi, l’architecture flexible (fig. 3.21)
de turbo décodage décrite précédemment, se composant à la fois d’une partie logicielle constituée d’un
processeur et d’un bloc matériel dédié réalisant le décodage élémentaire, a été modifiée. La gestion du
118
processus itératif propre aux turbocodes est également remplie par le processeur NIOS II. L’échange
de données entre les deux éléments réalisé par l’intermédiaire d’un bus système Avalon reliant l’ensemble des ressources est le point critique de l’architecture. En effet, cette solution présente un goulot
d’étranglement qui est le bus système de communication entre le processeur NIOS II et le décodeur
élémentaire. Ainsi, le simple fait d’instaurer un échange de données entre le NIOS II, les mémoires
externes et le décodeur élémentaire implique une baisse critique du débit de l’application.
Une solution architecturale est donc proposée sur la figure 3.24. Elle consiste à placer deux éléments de type DMA (Direct Access Memory) en entrée et en sortie du décodeur. Les DMA permettent
d’envoyer et de récupérer les données à partir des mémoires sans monopoliser le bus pour des accès
mémoires. Un arbitre gère alors la priorité entre le processeur et le DMA lors des échanges de données.
Ainsi, un DMA se charge de transférer les données au décodeur élémentaire tandis qu’un second récupère les données décodées pour les écrire en mémoire. Tous les transferts superflus vers le processeur
sont alors éliminés. Le gain en vitesse est alors au moins doublé.
Processeur
NIOS II
DMA
Décodeur
DMA
élémentaire
Port maître
Avalon
Bus Avalon
Arbitre
Arbitre
Mémoire
de données
Mémoire
de données
FPGA
Figure 3.24 — Architecture de l’application intégrant des DMA
3.5
Conclusion
Dans un premier temps, un état de l’art a rappelé les travaux effectués dans le domaine des turbo
décodeurs reconfigurables. Puis, nous avons proposé une étude sur les différents algorithmes mis en
œuvre dans le cadre du turbo décodage de codes produits constitués de codes BCH et RS. A travers
une étude de complexité fonctionnelle, les différents paramètres de flexibilité, notamment la longueur
de code N et le pouvoir de correction t, ont été caractérisés. Leur impact respectif sur le nombre
d’opérations nécessaires a été estimé. Sur la base de ce travail, nous avons retenu un algorithme de
3.5. CONCLUSION
119
décodage pour les codes BCH et RS. Il s’agit de l’algorithme Peterson-Gorensteiner-Zierler (PGZ) qui
est particulièrement adapté pour les faibles pouvoirs de correction. La longueur de code retenue est
égale à 32 pour les codes BCH et à 31 pour les codes RS. Ces choix nous assurent une complexité
raisonnable. Nous avons également bénéficié d’études antérieures pour attribuer une valeur aux autres
paramètres pour rendre l’implantation de l’algorithme de Chase-Pyndiah possible. Ainsi, les différentes
configurations de code évoquées dans le chapitre 2 ont été retenues pour l’implémentation d’un turbo
décodeur flexible dédié aux codes produits. Pour rappel, ce sont les turbocodes produits à base de codes
BCH (32,26) et (32,21) et de codes Reed-Solomon (31,29) et (31,27). D’autre part, des critères d’arrêt
ont été envisagés pour interrompre une exécution superflue du processus de décodage itératif pour le
décodage d’un code BCH ou d’un code RS. Pour cela, un critère d’arrêt hiérarchique a été proposé pour
conserver les performances d’un décodage sans critère d’arrêt. Ainsi, nous avons pu ajouter un rôle
supplémentaire à l’unité de contrôle chargée par ailleurs de la configuration du décodeur élémentaire .
Les solutions architecturales retenues ont ensuite été décrites pour les processus de codage et de
turbo-décodage. Pour ce dernier, la découpe réalisée s’appuie sur l’étude de complexité présentée.
Une architecture tenant compte de la flexibilité introduite a été développée pour assurer à la fois le
décodage des codes BCH et RS pour différents pouvoirs de correction. L’intégration d’un turbo décodeur dédié à des codes produits à base de codes Reed Solomon représente une innovation puisqu’il
s’agit, à notre connaissance, de la première solution architecturale proposée pour le décodage de tels
codes. L’architecture flexible de notre étude est hétérogène. Elle se compose d’une partie matérielle,
le décodeur élémentaire, et d’une partie logicielle, un processeur NIOS II. Ce dernier est chargé de la
configuration du décodeur élémentaire et des échanges de données avec la mémoire. Les échanges transitent par un bus système Avalon et concernent soit la mémoire externe soit le décodeur élémentaire.
Celui-ci se compose, quant à lui, de trois parties et d’une mémoire interne. Le pouvoir de correction t
et le type de code composant sont paramétrables. Le décodeur élémentaire est conservé au cours du
temps mais l’architecture interne doit être adaptée. La flexibilité est introduite par l’utilisation d’un
ensemble de multiplexeurs permettant de passer d’une configuration à l’autre. De plus, une découpe
temporelle du traitement global est adaptée pour chacune des configurations.
Nous allons dans le chapitre suivant décrire le flot de conception expérimenté dans le cadre de notre
étude. Notre but est de parvenir à proposer une implémentation sur une plate-forme de prototypage
à partir d’une description haut niveau de l’application.
CHAPITRE
4
De la description
algorithmique jusqu’au
prototypage
Le flot de conception expérimenté au cours de cette thèse est tout d’abord présenté. En effet, le
point de départ de ce travail a été l’expérimentation d’un flot de conception innovant, de la conception
algorithmique jusqu’à l’implantation. Le but est de parvenir à proposer une implémentation sur une
plate-forme de développement à partir d’une description de haut niveau de l’application. Le FPGA
Stratix EP1s40 de chez Altera est le circuit ciblé. Puis, une étude sur la synthèse de haut niveau
a été menée. Des solutions favorisant l’exploration architecturale pour certaines fonctionnalités de
notre application de turbo décodage de codes produits sont ainsi détaillées dans ce chapitre. Enfin,
le prototypage est abordée à travers la présentation de la plate-forme et du processus de mise en
œuvre. En effet, plusieurs étapes sont nécessaires pour implémenter l’architecture sur le FPGA et
lancer l’exécution du programme sur le processeur NIOS II. En conclusion, des pistes de réflexion
sont évoquées pour des implantations futures notamment la migration de certaines fonctionnalités
vers le processeur.
4.1
Flot de conception expérimenté
Cette première section se divise en deux sous parties. Dans un premier temps, le flot de conception
expérimenté dans le cadre de cette étude est présenté. Ainsi, le langage de description SystemC et
les outils associés pour l’implantation d’applications sur une cible FPGA sont explicités. Dans un
deuxième temps, la modélisation d’un décodeur élémentaire générique dans l’environnement System
Studio est détaillée. Enfin, la validation du flot considéré est réalisé à partir du modèle établi.
122
CHAPITRE 4. DE LA DESCRIPTION ALGORITHMIQUE JUSQU’AU PROTOTYPAGE
4.1.1
Description du flot de conception expérimenté
Ces dernières années, de nombreuses architectures de turbo décodeurs ont été proposées par le
département électronique de l’ENST-Bretagne. Dans tous ces travaux, les méthodologies de conception
étaient similaires. Le langage C est tout d’abord utilisé lors des simulations fonctionnelles pour évaluer
les performances. A l’issu d’une découpe architecturale, les descriptions en VHDL au niveau RTL sont
réalisées pour les différents modules constituant l’architecture. Ce flot est utilisé pour des circuits
dédiées de type ASIC ou des circuits reprogrammables de type FPGA. Cependant, comme il a été vu
dans le chapitre 1, la complexité croissante des applications et les contraintes de « time to market »
impliquent l’utilisation de nouvelles méthodologies de conception. Ainsi, nous avons décidé d’envisager
la conception au niveau système rendant possible une implémentation matérielle sans discontinuité
dans le flot de conception. En effet, l’utilisation du langage SystemC évite la réécriture de l’application
validée au niveau algorithmique en un langage de description matérielle. De plus, il s’agit d’un langage
d’aide à l’exploration architecturale car il facilite la simulation par rapport au langage de description
matérielle classique tel que le VHDL. Il permet d’envisager la conception de systèmes électroniques
intégrant à la fois des parties matérielles et logicielles. Il est possible d’implanter une description
abstraite sur la cible souhaitée grâce à des raffinements successifs des modèles. Des précisions sont
données sur ce langage dans l’annexe A.
Nous avons choisi, dans cette étude, l’outil System Studio de Synopsys qui fournit un environnement de développement complet au niveau système. Il est possible ainsi de réaliser à la fois une
modélisation fonctionnelle avec l’utilisation du langage C et/ou une modélisation comportementale
en SystemC. Ainsi, la première étape a été une modélisation de notre application en C dans cet
environnement. Une étape correspondant à la découpe architecturale basée sur le langage SystemC
nous a permis de concevoir des modules à différents niveaux d’abstraction et ainsi de modéliser plus
simplement les échanges au niveau TLM (Transactional Level Modeling). Le temps de simulation par
rapport à un équivalent RTL est alors significativement réduit. Ceci constitue l’un des intérêts majeurs
de l’utilisation du langage SystemC. A partir de 2001, un outil complémentaire SystemC compiler permettait d’effectuer une synthèse à partir d’un modèle décrit en SystemC au niveau comportemental
ou au niveau RTL. Malheureusement, le travail autour de cet outil et le support associé ont été arrêtés
au cours de l’année 2004 par la société Synopsys. Notre choix s’est alors orienté sur d’autres outils
de synthèse architecturale : d’une part Agility Compiler de Celoxica sur les conseils de Synopsys et
d’autre part l’outil académique GAUT mis au point au sein du laboratoire LESTER que nous avons
préalablement utilisé dans le cadre du projet RNRT ALIPTA .
En 2002, les fournisseurs de FPGA ont proposé une nouvelle déclinaison des circuits dits « programmables ». Il s’agit des systèmes sur puce programmable (SoPC) qui correspondent à l’implantation de
ressources logicielles et matérielles sur un même circuit FPGA. C’est pourquoi, dans le cadre de ce
travail, nous avons dès le départ tenté de bénéficier de cette nouvelle génération de circuit. Dans ce
4.1. FLOT DE CONCEPTION EXPÉRIMENTÉ
123
contexte, l’environnement de développement Quartus II de chez Altera a été intégré dans notre flot
de conception. Il autorise la conception, la configuration et l’exécution de programme logiciel sur un
ou plusieurs processeurs. De plus, les ressources internes d’un processeur sont personnalisables par le
concepteur grâce à l’utilisation de l’outil SOPC Builder. De même, des interfaces de communications
peuvent être ajoutées pour faciliter la gestion des communications avec les périphériques, les bus, les
mémoires... Des bancs de test sont générés automatiquement et simplifient la simulation sous l’outil
Modelsim. Enfin, les outils de compilation sont basés sur le format open source GNU.
Le flot de conception complet retenu est explicité sur la figure 4.1. Le point d’entrée est une description comportementale en SystemC de l’application. Après les étapes de synthèse, une description
netlist (de type EDIF) ou VHDL est obtenue. Le point de sortie est un train binaire (bitstream)
permettant de configurer le circuit FPGA.
C/C++
Simulation
fonctionnelle
SystemC
6\VWHP&70
&RFHQWULF 6WXGLR
Découpe architecturale
Synthèses
EDIF
Génération NIOSII
623&%XLOGHU
Place & Route
1LRV 6'.6KHOO
1LRV ,'(
Prototypage
Figure 4.1 — Le flot de conception expérimenté
Les différentes étapes considérées dans ce flot sont détaillées ci-dessous :
– la simulation fonctionnelle : elle est réalisée dans System Studio à partir du code C de l’application.
– la découpe architecturale : à l’aide du langage SystemC, l’algorithme de traitement est décomposé en fonctions qui sont, ensuite, réparties dans des modules indépendants. Des ports
d’entrées/sorties sont affectés à chacun des blocs. Des listes de sensibilité sont établies. Elles
déclenchent les processus et les fonctions associées pour traiter les données entrantes. Dans cette
étape, une exploration de l’espace de conception est réalisée pour expérimenter l’affectation des
fonctionnalités sur différentes cibles. Des simulations sont menées pour valider le comportement
124
de l’ensemble par rapports au modèle en langage C.
– les synthèses des parties matérielles et logicielles s’effectuent en parallèle :
– la synthèse de la partie matérielle est appliquée aux modules spécifiques qui seront implantés
sur le FPGA. Cette synthèse peut être de deux natures : soit une synthèse à partir d’une description en SystemC au niveau RTL soit une synthèse haut niveau à partir d’une description
comportementale en SystemC.
– La personnalisation du processeur constitue la première phase du processus de synthèse de la
partie logicielle. Une synthèse des ressources matérielles du processeur est ensuite effectuée.
Il s’agit de l’étape de génération du processeur logiciel (NIOS II par exemple chez Altera).
– L’ensemble processeur/bloc matériel est assemblé dans l’environnement Quartus II. Le placement/routage est effectué pour la structure complète. Les estimations fournies en amont peuvent
alors être comparées aux résultats obtenus.
– le prototypage : il s’agit de la programmation puis du test du circuit FPGA proprement dit.
Une expérimentation de ce flot a été menée sur un algorithme de turbo décodage de codes produits.
Nous allons détaillés ce travail dans les sections suivantes.
4.1.2
Modélisation d’un décodeur élémentaire générique pour le turbo décodage de codes produits
Dans notre étude, la modélisation a été effectuée dans l’environnement System Studio. Toute la
chaı̂ne de communications numériques a été implémentée dans cet environnement (figure 4.2).
Figure 4.2 — Modélisation de la chaı̂ne de communications numériques sous System Studio
Le passage du langage C au SystemC nous a permis d’effectuer une découpe architecturale de
notre décodeur élémentaire. L’architecture du décodeur élémentaire est constituée de blocs qui sont
décrits de manière générique avec le langage SystemC (figure 4.3). Ainsi, plusieurs paramètres peuvent
être modifiés dans le cadre de la simulation :
– la longueur de code N .
– la dimension du code K.
– le nombre de bits de quantification Q.
– la valeur du dernier élément du corps de Galois GF MAX.
– le polynôme générateur POLYGEN.
– le nombre d’éléments les moins fiables M F .
4.1. FLOT DE CONCEPTION EXPÉRIMENTÉ
125
– le nombre de mots concurrents conservés N b M C.
Des informations sur l’ensemble de ces paramètres peuvent être retrouvés dans la section 3.2.1 du
chapitre 3.
Figure 4.3 — Modélisation du turbo décodeur sous System Studio
Concernant l’unité de contrôle à savoir le processeur NIOS II, nous ne disposions pas de modèle en
langage SystemC. C’est pourquoi, un module dédié a été conçu pour gérer les échanges de données avec
le décodeur élémentaire. De plus, les critères d’arrêt évoqués dans la section 3.2.2 ont été implémentés
et testés sur notre modèle. Les autres fonctionnalités de la chaı̂ne de communication tels que la
génération de l’information binaire, le codage, le bruitage et la transmission des données sont décrites
en langage C. Toutefois, les communications entre ces différents modules sont assurées grâce à l’ajout
d’une couche en SystemC. Les performances de ce modèle ont été simulées et validées. Les résultats
obtenus sont exactement les mêmes que pour un modèle équivalent décrit uniquement en langage C.
4.1.3
Synthèse logique d’un turbo décodeur BCH à longueur variable
Les synthèses logiques des différents modules décrits en langage SystemC ont été réalisées pour le
turbo décodage d’un code BCH étendu. Les codes considérés sont capables de corriger un bit erroné
dans le mot reçu. Les synthèses ont été menées pour différentes longueurs de code N . Le tableau 4.1
présente les résultats obtenus pour l’implantation du décodeur élémentaire sur notre cible. Dans ce
cas, 16 vecteurs de test, une quantification sur 4 bits et 3 mots concurrents ont été considérés.
126
Longueur du code
Réception
Parité
Syndrome
Moins fiables
Traitement Vecteurs de test
Métriques
Tri des mots
Emission
Fiabilité
Inf. extrinsèque
Correction
Totaux
Nbre de
N = 128
54
138
936
984
225
3009
2528
341
95
8310
portes logiques
N = 64 N = 32
54
54
116
94
824
784
827
744
225
225
2602
2188
1376
1244
341
341
95
95
6460
5769
Tableau 4.1 — Complexité en nombre de portes logiques du décodeur élémentaire pour différentes
longueurs de code N
Nous observons que des blocs occupent la même surface quelque soit la longueur de code considérée.
En effet, les complexités des modules de calcul de la parité, de l’information extrinsèque et de correction
sont indépendants de N . Compte tenu du fait que les symboles sont traités séquentiellement et que la
largeur des données traitées est identique, la même architecture est employée à chaque cycle d’horloge.
De même, le bloc de calcul des métriques a une complexité constante puisque le nombre de mots
concurrents est identique dans les trois cas. Toutefois, plusieurs blocs voient leur complexité diminuer
lorsque la longueur de code diminue. Cette baisse est due à la taille du corps de Galois (2m avec
m = 7, 6, 5). En effet, la dimension des opérateurs associés et par conséquent la taille des chemins de
données dépendent directement de ce paramètre.
L’implantation d’un décodeur de code BCH (32,26) a déjà été effectuée au sein du département
électronique de l’ENST-Bretagne [CAKP02]. L’architecture et les algorithmes sont rigoureusement
identiques à ceux utilisés dans notre cas. Cependant, les blocs constituants sont décrits au niveau
RTL en langage VHDL. Cette étude sert donc de point de comparaison avec le travail effectué pour
une longueur de code N = 32. La comparaison s’effectue sur la surface occupée en terme de portes
logiques. La technologie utilisée est la technologie ASIC 0,18 µm de ST Microelectronics. Ainsi, dans
notre cas, nous avons obtenu une complexité en nombre de portes de 5769 contre 5336, soit un
écart d’un peu plus de 5%. Après une comparaison pour chacun des blocs, l’écart s’explique par les
résultats de synthèse obtenus pour le bloc de fiabilité qui nécessite beaucoup de contrôle. Il semble que
l’interprétation effectuée par le parser VHDL de l’outil de design compiler de Synopsys est meilleure
que celle réalisée par le parser SystemC de l’outil SystemC Compiler de Synopsys. Cependant, une
évolution programmée de l’outil aurait dû pallier à ce problème avant l’interruption de son support.
L’utilisation de ce flot de conception a également fait l’objet d’une publication sur une application de
turbo décodage de code produit basé sur un code BCH (128,120) dans une conférence internationale
[PJAJ04] et nationale [PJAJ05].
4.2. SYNTHÈSE LOGIQUE ET PLACEMENT/ROUTAGE DE L’ENSEMBLE
CODEUR/TURBO DÉCODEUR FLEXIBLE
4.2
127
Synthèse logique et placement/routage de l’ensemble codeur/turbo décodeur flexible
Nous allons nous focaliser sur le développement d’architecture flexible tout en conservant le flot
de conception décrit précédemment. Ainsi, les résultats obtenus lors des synthèses logiques et du
placement/routage à l’aide de l’outil Quartus II en ciblant un FPGA de type Stratix 1s40F780c5 sont
présentés successivement pour le codeur flexible, le décodeur élémentaire flexible et le turbo décodeur
flexible.
4.2.1
Synthèse logique et placement/routage des différents blocs du codeur
En considérant l’architecture du codeur mise en place (voir figure 3.3), il est possible d’élaborer
des mots de codes de type soit BCH étendu soit Reed-Solomon composés jusqu’à dix symboles de
redondance. En effet, ce codeur est conçu pour supporter la pire configuration en terme de complexité.
Ainsi, il fournit dix symboles de redondance pour un code BCH(32,21) et nécessite un chemin de
données de cinq bits pour un code RS de longueur de mot de code 31 bits.
Nous avons décrit les codeurs propres à nos quatre configurations en langage VHDL au niveau
RTL. Les résultats de synthèse sont données dans le tableau 4.2. Les premières lignes donnent les
caractéristiques, en terme de surface (éléments logiques et mémoire) et de fréquence de fonctionnement,
pour des codeurs de type BCH et RS. Entre parenthèse apparaı̂t le nombre d’éléments logiques (LE)
requis pour l’un des deux codeurs élémentaires constituant. Il faut noter qu’un module supplémentaire
élabore la parité dans le cas d’un code BCH.
codeur
BCH
Reed Solomon
Codeur flexible
BCH/RS
4 configurations
(n,k)
Logic Elements
Fréq.
Mem
(n,k)
LE
Fréq.
Mem
LE
Fréq.
Mem.
t=1
t=2
(32,26)
(32,21)
173 (34)
196 (60)
101 MHz 97 MHz
1024 bits 1024 bits
(31,29)
(31,27)
282 (23)
334 (31)
110 MHz 114 MHz
5120 bits 5120 bits
567 (169)
92 MHz
5120 bits
Tableau 4.2 — Caractéristiques de chaque codeur correspondant à chacune des configurations considérées
Le codeur flexible occupe 567 LEs. Si l’ensemble des codeurs avait été implanté, il eut fallu 985 LEs
au total soit une surface de 57% supérieure. Une alternative (semi-flexible) peut consister à conserver
les configurations de codeur les moins favorables, c’est à dire pour un code BCH (32,21) et un code
RS (31,27). Elles peuvent alors recevoir les deux autres configurations en modifiant uniquement les
128
coefficients du polynôme générateur. Ainsi, la surface occupée est équivalente. Toutefois, ici encore, la
solution flexible offre une économie en terme d’occupation mémoire de l’ordre de 17% par rapport à la
solution semi-flexible. Il est à noter que les fréquences de fonctionnement sont à peu près équivalentes
bien que celle du codeur flexible soit légèrement inférieure aux configurations simples.
4.2.2
Synthèse logique et placement/routage des différents blocs du décodeur élémentaire flexible
L’architecture du décodeur élémentaire se compose de trois parties : réception, traitement et
émission. Chacune de ces parties sont elles-mêmes constituées de blocs réalisant différentes fonctions
(figure 4.4).
Unité de
contrôle
R
5
Rinit
Ri+
Processeur
NIOS II
Mémoire
5
8
Bloc de réception
Bloc des
moins fiables
Lr Pi
Bloc de traitement
Par
5x8
Bloc d’émission
Par&Cw
Cp_Md&Mc
Mdp Calcul des
1
Mdp
Parité
Par
1
Si
Syndrome
Construction
8
des
Vecteurs
Lr P
de test
5x8
Si
4x5
4x5
Métriques
D
Information
Décodage
5 extrinsèque
Tri des mots M_Md&Mc
algébrique Lr P
concurrents
W 8
et
Fiabilité 5
5x8
décidés
Ci&Ei
Lr_p_Md&Mc
Correction du
4x5
R’ mot de code
8
R’
6 RAMs
32x5x5
αi
R’
R’init
ROM
Galois
32x5
βi
5
Légende:
5
R’init
Signaux
Compteur
Type de code
Figure 4.4 — Schéma-bloc du décodeur élémentaire RS/BCH
Les tableaux (4.3),(4.4),(4.5) et (4.6) récapitulent respectivement les résultats d’implantation pour
les blocs réception, traitement, émission et mémorisation.
Pour la partie réception (tableau 4.3), le bloc de détermination des éléments les moins fiables est
le module le plus coûteux en surface. Ceci est dû aux nombreuses opérations de contrôle réalisées. Le
bloc de calcul des syndromes dépend de la surface occupée pour le calcul d’une composante puisque
la même unité est dupliquée autant de fois qu’il le faut. Au total, le module occupe 136 LE. Enfin, la
4.2. SYNTHÈSE LOGIQUE ET PLACEMENT/ROUTAGE DE L’ENSEMBLE
CODEUR/TURBO DÉCODEUR FLEXIBLE
129
simplicité du bloc de calcul de parité lui permet d’être rapide tout en occupant peu de surface.
Bloc
Syndrome
Parité
Moins fiables
Surface en LE
136
8
344
Fréquence (MHz)
88
500
170
Tableau 4.3 — Surface occupée par les blocs de la partie réception du décodeur élémentaire
Pour la partie traitement (tableau 4.4), les deux modules les plus gourmands en surface sont les
blocs de construction des vecteurs de test et l’algorithme de décodage algébrique PGZ qui occupent
respectivement 640 et 551 LE. Le premier élabore chaque vecteur de test à partir des symboles les
moins fiables, de nombreuses manipulations dans le corps de Galois sont alors nécessaires. Il est à noter
que la complexité devient élevée par rapport à une construction de vecteur de test pour un simple code
BCH. Pour le deuxième bloc, il s’agit des mêmes contraintes en ajoutant l’utilisation d’une mémoire
distribuée simulant l’inversion dans le corps de Galois. D’ailleurs, la même fonctionnalité se retrouve
dans le bloc de correction des symboles erronés. Aucun détail d’implantation n’est donné pour la
détermination des racines (Chien) puisqu’une table placée sur un BlockRAM est utilisée. Enfin, le
bloc de tri occupe 322 LE en partie à cause de nombreuses comparaisons.
Bloc
Construction des VT
PGZ
Chien (Table mémoire)
Correction
Validation mots de code
Calcul des métriques
tri
Surface en LE
640
551
149
41
108
322
Fréquence (MHz)
200
87
107
124
93
88
Tableau 4.4 — Surface occupée par les blocs de la partie traitement du décodeur élémentaire
Pour la partie émission (tableau 4.5), les blocs de calcul de l’information extrinsèque et de correction du mot de code sont peu complexes. Les opérations se font sur les quantifications des éléments
binaires constituant le symbole. La détermination de la fiabilité nécessite 372 LE en partie du à la
présence d’opérations de comparaison entre les symboles des mots concurrents.
Bloc
Fiabilité
Calcul de l’information extrinsèque
Surface en LE
372
62
28
Fréquence (MHz)
248
137
106
Tableau 4.5 — Surface occupée par les blocs de la partie émission du décodeur élémentaire
Au niveau des ressources mémoires (tableau 4.6), elles peuvent soit être implantée sur des blocs
mémoires dédiés (BlockRAM) soit distribuée sur les LUT du FPGA. Le corps de Galois est mémorisé
130
pour avoir accès aux éléments à chaque instant du processus de décodage. La mémoire interne reçoit
les mots initiaux et décodés pour les trois étages du pipeline. D’autres unités mémoires sont également
contenues dans certains modules. Elles sont répartis sur des LUTs et apparaissent par conséquent dans
le nombre d’éléments logiques.
Bloc
Corps de Galois
Mémoire interne
Nombre de bits
32 × 5 × 2
6 × 32 × 5 × 5
Ressources
LUTs
BlockRAM
Tableau 4.6 — Occupation de la mémoire interne du décodeur élémentaire en nombre d’éléments
logiques (LE)
En résumé, les surfaces occupées par les parties réception, traitement et émission sont respectivement de 488, 1811 et 462 LE soit au total 2761 LE pour le décodeur élémentaire. Autrement dit, ces
parties occupent respectivement 1.2%, 4.4% et 1.1% du FPGA soit au total 6.7% du circuit. De plus,
les mémoires doivent stocker 5120 bits.
4.2.3
Synthèse logique et placement/routage du turbo décodeur flexible
L’architecture du turbo décodeur flexible est donné sur la figure 4.5, elle se compose du décodeur
élémentaire (dont la synthèse a été évoqué précédemment), des plans mémoires et du processeur NIOS
II. Les résultats de la synthèse logique du processeur et des mémoires associées sont détaillés dans
cette section.
B
U
S
Processeur
NIOS II
A
V
A
L
O
N
Plans mémoires
Décodeur
élémentaire
Figure 4.5 — Schéma de l’architecture du turbo décodeur flexible
Le processeur NIOS II joue ici le rôle de l’unité de contrôle. Nous avons tentés d’alléger au maximum la version standard fournie par défaut. Elle permet de gérer l’ensemble des périphériques présent
sur la carte de développement. Les résultats de la synthèse logique après placement/routage du coeur
4.3. SYNTHÈSE ARCHITECTURALE
131
de processeur et des interfaces périphériques sont donnés dans le tableau 4.7. Le processeur atteint
des performances de 37 DMIPS. Deux éléments mémoires de type M4K sont utilisés et peuvent contenir jusqu’à 4 koctets chacun. A cela, il faut ajouter les caches d’instructions et de données (resp. 4
et 2 Koctets). La communication du processeur avec l’extérieur est assurée via un port JTAG. En
effet, il nous est ainsi possible de télécharger notre programme sur le NIOS II et même d’effectuer un
debuggage logiciel.
```
`
Caractérist.
```
```
Module
``
Coeur NIOS II
Arbitre bus de données maı̂tre
Arbitre bus d’instruction maı̂tre
JTAG
Interface bloc matériel
On Chip Mem. Réception
On Chip Mem. Lignes
On Chip Mem. Colonnes
SDRAM
Boutons PIOs
Surface en LE
Mémoire (bits)
2060
369
193
19
2
58
65
62
667
25
857
131
131
131
-
k.
k.
k.
k.
Tableau 4.7 — Résultats de la synthèse logique du processeur NIOS II
Tous les résultats correspondent à une solution matérielle fonctionnant à 50 Mhz. Les surfaces
occupés par les différents plans mémoire tiennent compte des arbitres de chacun. Au total, 3540 LE
sont nécessaires pour l’ensemble soit 8.6% de notre circuit.
Les synthèses logiques des différents éléments constituant notre architecture flexible ont été effectuées. Ainsi, le codeur occupe 567 LE tandis que le turbo décodeur flexible occupe 6245 LE. Cela
correspond à un taux d’occupation du FPGA respectivement de 1.4% et de 15.1%. Notre flot de
conception nous permet d’incorporer la synthèse architecturale. C’est pourquoi, nous allons tentés de
mener des synthèses de haut niveau sur les différentes parties du décodeur élémentaire.
4.3
Synthèse architecturale
La synthèse architecturale permet une exploration des différentes solutions architecturales. Dans
notre cas, il faut remplacer la synthèse du code décrit en SystemC au niveau RTL par la synthèse
haut niveau du code décrit en SystemC comportemental. Cependant, si l’ensemble de l’architecture
du décodeur élémentaire est considéré alors elle se révèle trop complexe pour les outils de synthèse
architecturale GAUT et Agility Compiler. Ce constat est l’une des conclusions du projet de recherche
RNRT ALIPTA [ALI04] au cours duquel nous avons mené une étude sur un décodeur Reed Solomon
de complexité équivalente. Afin de limiter notamment les accès mémoires globaux, il est préférable de
diminuer la complexité de la description en considérant des blocs de traitement distincts.
132
L’objectif principal de cette section est d’évaluer l’apport de la synthèse de haut niveau lors de
la conception d’un turbo code en blocs. Nous nous focalisons sur les configurations BCH ((32,26)
et (32,21)) et RS ((31,29) et (31,27)) pour un turbo décodeur en blocs flexible qui est l’application
retenue dans ce travail. Toutes les observations effectuées sont extensibles à des codes ayant des
longueurs de code plus élevées mais pour le même pouvoir de correction. Les différentes solutions
architecturales proposées par les outils retenus peuvent être exploitées, en particulier, pour bénéficier
du parallélisme inhérent aux algorithmes considérés. L’outil SystemC compiler a été choisi dans un
premier temps, l’arrêt du support officiel nous a obligé à nous orienter vers d’autres outils. Ainsi,
l’outil commercial Agility Compiler et l’outil académique GAUT nous ont permis d’effectuer différentes
synthèses architecturales.
Une des différences entre les deux outils est le langage utilisé comme point d’entrée. Dans le cas
d’Agility Compiler, le choix du langage SystemC permet d’appréhender l’aspect matériel de l’application. GAUT prend, quant à lui, une description en langage C ou en VHDL comportemental. Il nous a
semblé plus judicieux de retenir le langage C dans notre étude. Les algorithmes en C nécessitent une
légère réécriture mais autorise plus de liberté. Pour rappel, les différents aspects relatifs à ces deux
outils ont été évoqués dans le chapitre 1. La suite de cette section aborde, dans un premier temps, la
spécificité des opérations liées à notre application. Dans un second temps, une expérimentation de la
synthèse architecturale est proposée.
4.3.1
Les opérations dans le corps de Galois
Dans notre application, une partie des traitements est effectuée dans le corps de Galois. Ainsi,
les opérateurs associés doivent être définis pour prendre place dans les descriptions architecturales
de chacun des blocs. Les opérations d’addition, de comparaison, de multiplication, de multiplicationaccumulation (MAC) et de division sont nécessaires à notre étude. Une définition de ces opérateurs
pour la synthèse architecturale est donc préalablement nécessaire. Comme nous considérons un code de
longueur N = 32 symboles, le travail s’effectue dans le corps de Galois (25 ) et la taille des opérateurs
est donc m = 5 bits. L’approche diffère selon les outils choisis :
Dans GAUT, le type de base est le type entier (int) représenté par le type word défini dans
la bibliothèque technologique. Actuellement, GAUT ne travaille que sur des chemins de données de
largeur fixe. Il est possible de redéfinir cette bibliothèque pour adapter les opérateurs à la largeur de
données nécessaire à l’application. Cependant, les variables internes ne peuvent pas être « taillées »
en fonction des besoins et posséderont toujours cette largeur par défaut. Ainsi, il n’est pas possible
de déclarer des booléens ou encore d’autres types. Pour notre application, il faut donc générer une
nouvelle bibliothèque pour des données de cinq bits en y ajoutant les opérateurs nécessaires. Les
synthèses logiques et le placement/routage de ces opérateurs ont été réalisés dans l’outil Quartus II à
partir des descriptions en langage VHDL au niveau RTL.
133
Dans Agility Compiler, le langage SystemC permet de dimensionner les entrées/sorties, les registres
internes et les chemins de données. La description répond entièrement aux besoins du concepteur en
terme de type de données (booléen, entiers, entiers non-signés...). Les opérateurs classiques (tels que
l’additionneur, le multiplieur...) sont définis par défaut dans l’outil. En revanche, les opérateurs dans
le corps de Galois ont été décrits sous la forme de fonctions en SystemC au niveau RTL. Ainsi, à
chaque utilisation de l’un d’eux, la fonction est appelée et un opérateur est implanté. Les descriptions
finales sous forme de netlist générées par l’outil ont ensuite été soumises à une synthèse dans Quartus
II.
Le tableau 4.8 récapitule les résultats de synthèse logique obtenus par les deux outils en ciblant
un Stratix 1s40.
XXX
XXX Outil
GAUT
Agility
Opérateur XXXX
Caract.
Surface (LE) Temps critique (ns) Surface Temps critique
Comparateur
11
3.229
14
2.369
Additionneur
5
2.369
5
2.369
Multiplieur
17
2.533
19
2.772
MAC
20
3.421
22
2.816
Diviseur
Utilisation d’une table et d’un multiplieur
Tableau 4.8 — Caractéristiques des opérateurs obtenus après synthèse logique sous Quartus II en
ciblant un Stratix 1s40
Les résultats d’implémentation à l’aide de l’outil Agility Compiler nous fournissent des solutions
moins performantes que ceux obtenus pour GAUT par la synthèse des mêmes descriptions en langage
VHDL. Une prise en compte du circuit FPGA est effectué dans Agility Compiler. C’est pourquoi,
l’interprétation du langage SystemC par l’outil fournit des solutions plus rapides mais occupant plus
de surface. Seul l’opérateur d’addition présente des caractéristiques équivalentes dans les deux cas
puisqu’il a été placé sur une seule et même LUT. L’écart est plus particulièrement marqué pour les
opérateurs complexes. Ainsi, le choix effectué lors de la conception de GAUT (ie la création de ses
propres opérateurs) est sans nul doute plus précise et performante mais elle est, par contre, plus
contraignante.
4.3.2
Exploration des solutions architecturales
Dans cette section, nous allons considérer l’ensemble des algorithmes évoqués pour le décodeur
élémentaire. L’objectif est de proposer des alternatives en terme d’architecture au concepteur en
fonction de la disponibilité des données à traiter. La synthèse architecturale est particulièrement
adaptée aux traitements massivement parallèles. Dans notre cas, nous n’avons pas utilisé d’outils de
synthèse architecturale pouvant travailler sur des modèles de graphes adaptés pour des opérations
de contrôle. Ainsi, tous les algorithmes, notamment ceux nécessitant beaucoup de contrôle, n’ont
134
pas pu bénéficier des avantages de la synthèse architecturale. Dans notre cas, les blocs des parties
de réception et d’émission du décodeur élémentaire peuvent bénéficier de la synthèse d’architecture.
Ainsi, nous proposons les solutions données par les deux outils GAUT et Agility Compiler lorsqu’il
nous est possible de le faire comme nous allons le voir.
Dans un souci pédagogique et afin de faciliter la compréhension des différents résultats de synthèse
obtenus, les processus de synthèse et les solutions architecturales fournis par les deux outils sont
préalablement explicités. Nous allons succinctement rappeler les modèles d’architectures ciblés par
chaque outil.
L’architecture générée par l’outil GAUT se compose d’une unité de traitement, d’une unité de
contrôle, d’une unité de mémorisation et d’une unité de communication (fig. 4.6). Les unités de mémoire et de communication possèdent leur propre contrôle. Dans notre cas, différentes cadences Tcad
peuvent être appliquées aux algorithmes décrits. Il est à rappeler que la cadence désigne le temps
s’écoulant entre l’arrivée des données en entrée et la production des données traitées. Le temps d’exécution de l’algorithme avant implémentation correspond au temps de latence Tlat . Ainsi, si Tcad > Tlat
le traitement de l’algorithme est effectué dans le temps imparti. En revanche, si Tcad < Tlat alors
l’unité de traitement produite aura un fonctionnement pipeline pour satisfaire les contraintes fixées
par le concepteur.
Horloge
Unité
de
contrôle
Unité de
communication
Unité de
traitement
Unité de
mémorisation
Figure 4.6 — Modèle architectural ciblé par l’outil GAUT
Pour l’outil Agility Compiler, le concepteur doit fixer les contraintes d’utilisation lors de la description comportementale en SystemC. Ces contraintes sont deux types :
1. matérielles : le concepteur définit à la fois les entrées et les sorties des modules et les ressources
135
matérielles disponibles. Il n’y a pas d’unité de communication dédié comme pour l’outil GAUT.
2. temporelles : il est possible d’imposer une fréquence d’horloge. Le processus fixe alors la cadence
de l’application en fonction de la fréquence d’horloge fixée.
L’exploration architecturale repose donc entièrement sur la description en SystemC donnée par le
concepteur. L’outil peut paralléliser le traitement en dupliquant les ressources utilisées en respectant
la cadence de fonctionnement. Au niveau de l’interprétation du code écrit en SystemC, l’outil assigne
des ensembles de multiplexeurs aux expressions conditionnelles. De plus, par défaut les constantes
sont définies sur 64 bits.
Les outils GAUT et Agility Compiler peuvent tous les deux cibler un composant prédéterminé
(ASIC ou FPGA). Des estimations sur l’occupation en terme de ressources sont alors données à l’issue
de la synthèse architecturale. Il est à noter que les résultats obtenus lors des synthèses architecturales
ne sont pas directement comparables puisque les modèles d’architectures ciblés ne sont pas équivalents.
Différentes synthèses architecturales ont été effectuées sur les blocs de réception, traitement et
émission. Des blocs ne se prêtant pas à ce type de synthèse ont été délibérément ignorés. Le module
de calcul de la parité va, tout d’abord, nous servir d’exemple pour expliciter les processus des deux
outils.
4.3.2.1
Les blocs de la partie réception
Le bloc de parité
Le bloc de parité (nécessaire pour un code BCH) constitue un bon exemple pour comprendre comment
vont procéder les outils lors d’une synthèse architecturale. Un exemple de graphe flot de données,
obtenu avec GAUT, pour le calcul d’une parité uniquement sur deux symboles est donné sur la figure
4.7. L’ensemble des opérations de l’algorithme apparaissent sur le graphe. Les données entrantes sont
représentées par la couleur verte, les opérations en bleu, les variables temporaires en orange et enfin
les données sortantes en jaune.
L’architecture correspondante (fig. 4.8) est réutilisée à chaque cycle d’horloge si Tcad > Tlat . Le
bus d’échange de données se situe sur la partie supérieure de la figure. Les registres, les bascules trois
états et l’opérateur (un « Ou Exclusif »ou XOR) utilisés apparaissent dans la partie inférieure.
Nous allons maintenant nous placer dans le cas du calcul de la parité pour 32 symboles. Différentes
cadences sont imposées aux graphes flot de données. La période de l’horloge de fonctionnement est
fixée à 10 ns. Le tableau 4.9 donne les résultats de la synthèse d’architecture en supposant que les
données en entrées sont accessibles à chaque instant. Cet exemple montre que le taux de parallélisme
engendré dépend de la cadence imposée par le concepteur. De plus, un taux de parallélisme maximum
n’est possible que lorsque l’ensemble de la trame est disponible. Le nombre de signaux de contrôle
augmente alors de façon linéaire.
136
Figure 4.7 — Graphe flot de données
Figure 4.8 — Architecture générée sans pipeline
Cadence
Non-pipe
Pipe.
Nombre
XOR
d’opérateurs
Reg.
Mux/Demux/Trist.
Contrôle
nbre états FSM
signaux
320
X
1
4
3
32
7
Optimisation
80
X
4
13
9
8
22
10
X
31
63
1
1
64
Tableau 4.9 — Résultats de la synthèse architecturale pour le bloc de parité avec l’outil GAUT
De la même manière, nous avons décrit ces fonctionnalités avec Agility Compiler et ciblé un FPGA.
Nous avons obtenu une estimation des ressources mises en œuvre et les fréquences de fonctionnement.
Ces ressources sont données après optimisation en nombre de portes logiques puis au niveau netlist à
l’issu du choix du FPGA. Les deux cas extrêmes, à savoir l’utilisation d’un seul ou de 32 opérateurs
« Ou exclusif », et une solution intermédiaire ont été considérés. Les résultats sont donnés dans le
tableau 4.10.
Opérateurs
Apr. optimisation (portes)
Mapping (LUT)
Horloge (ns)
1 XOR
42
6
2.54
16 XOR
544
51
4.079
32 XOR
864
78
4.087
Tableau 4.10 — Résultats de la synthèse architecturale pour le bloc de parité avec l’outil Agility
Compiler
Le bloc de calcul des syndromes
Cette expérimentation considère la configuration la plus complexe à savoir 32 symboles et 4 composantes pour le syndrome. Ce bloc reçoit en entrée les symboles constituant la trame. Puis les quatre
composants sont élaborées, le calcul à effectuer est le suivant :
Si = R(αi ) =
137
Pn−1
j=0
rj (αi )j avec 1 ≤ i ≤ 2t
Avec l’outil GAUT, nous proposons deux types d’architectures pour le calcul des syndromes. L’une
(a) est basée sur un ensemble contrôle et traitement, l’autre (b) considère l’ajout d’une unité mémoire
où sont stockés les éléments du corps de Galois. Dans le premier cas, des opérateurs de multiplicationaccumulation sont utilisés pour accumuler les produits ri .αi des quatre (2t) composantes. Dans le
second cas, nous considérons un opérateur multiplication, un opérateur addition et un plan mémoire
recevant les éléments du corps de Galois. Les graphes flot de données extraits des algorithmes sont
représentés sur la figure 4.9. Seul une portion de chaque graphe est donnée. Cependant, le parallélisme
de deux algorithmes apparaı̂t clairement. Toutes les ressources sont dupliquées en fonction du nombre
d’itérations nécessaires au calcul du syndrome.
Architecture (a)
Architecture (b)
Figure 4.9 — Graphe flot de données obtenu avec GAUT pour les solutions architecturales (a) et
(b)
Le tableau 4.11 donne les résultats obtenus pour quatre solutions architecturales (4 cadences
(i.e. 4 débits différents)). Seul l’ensemble contrôle/traitement produit est donné pour la solution (a)
puisqu’une unité mémoire n’est pas nécessaire. Dans le cas de la solution (b), l’ensemble contrôle/traitement/mémoire élaboré par GAUT est fourni en terme d’opérateurs et de ressources mémoires.
Différentes optimisations sont envisagées et les opérateurs dans le corps de Galois résultants sont
précisés. La complexité de l’unité de contrôle est exprimée à l’aide du nombre d’états de la machine
d’états (FSM) et du nombre de signaux utilisés.
Pour une cadence de 1280 ns, le débit associé est de 121 Mbit/s et une seule unité MAC est
nécessaire pour traiter l’ensemble de la trame dans le temps imparti. Le pipeline n’est pas nécessaire
au dessus d’une cadence de 320 ns. En deçà, il faut considérer plusieurs étages de pipeline et les
ressources supplémentaires nécessaires. Dans le cas (a), plus la cadence augmente, plus il faut disposer
d’opérateurs. Dans le cas (b), on note une explosion des besoins en terme de bancs mémoires. La
solution (a) apparaı̂t donc clairement plus intéressante.
138
Cadence
Optimisation
Non-pipe
Pipe.
Opérateurs
MAC
Mult.
Add
Reg
Mux-demux-trist.
Contrôle
nbre états FSM
signaux
Mem.
Bus
Nbre banc
1280
X
1
4
1
5
129
-
Archi. (a)
340 320 80
X
X
X
4
4
16
20
20
68
12
12
36
33
32
8
32
32 104
-
10
X
128
388
4
1
392
-
1280
X
1
1
11
9
-
Archi. (b)
350 160
90
X
X
X
4
8
15
4
8
15
39
76
116
31
56
75
34
16
9
70 200
348
12
32
Pb
16
64 mém.
Tableau 4.11 — Résultats de la synthèse architecturale pour le bloc syndrome avec l’outil GAUT
Les mêmes descriptions ont été soumises à Agility Compiler afin d’estimer l’implantation sur
un Stratix1s40. Cette fois-ci, les accès mémoires ont été entièrement définis afin de se placer dans
des conditions identiques. La trame est supposée entièrement connue et accessible avant le début du
traitement. Les tableaux 4.12 et 4.13 récapitulent les différentes caractéristiques pour les deux types
de solutions architecturales obtenues avec différentes contraintes. Il est à noter que dans le cas (a),
dans le cas d’une parallélisation totale (tableau 4.12), l’outil n’a pu nous fournir de résultats que
pour le calcul d’une et deux composantes, une estimation est donc fournie pour le calcul des quatre
composantes. Dans le cas (b), nous supposons des requêtes vers les bancs mémoires à chaque cycle
d’horloge.
Nbre de composantes
Opérateurs
MAC
Après compilation (portes)
Mapping (LUT)
Horloge (ns)
4
4
353706
1173
143
4.659
1
32
2832349
9686
1362
64
2
2x32
5659451
17728
2327
71.69
4
4x32
#11330000
#32000
#4000
#77
Tableau 4.12 — Résultats de la synthèse architecturale pour le syndrome (sol.(a)) avec l’outil Agility
Compiler
Opérateurs
Mémoires
Avt optimisation
Apr. optimisation
Mapping (LUT)
Horloge (ns)
4 mult.
4 XOR
4 bancs
4x5x32 bits
82204
4811
706
11.33
8 mult.
8 XOR
8 bancs
8x5x32 bits
128090
6521
904
12.04
16 mult.
16 XOR
16 bancs
16x5x32 bits
2555790
9944
1305
12.46
Tableau 4.13 — Résultats de la synthèse architecturale pour le syndrome (sol.(b)) avec l’outil Agility
Compiler
Les résultats obtenus dans la première colonne considèrent l’utilisation de quatre MAC et un
139
traitement séquentiel de chaque symbole reçue. Ainsi, le syndrome n’est fourni qu’après le passage du
mot. La fréquence de fonctionnement diminue en fonction du nombre d’unité MAC utilisées dans les
différentes solutions.
En parcourant le tableau 4.12 de la gauche vers la droite, chaque solution nécessite respectivement
32, 16 et 8 passages pour fournir les syndromes calculés, soit des latences respectives de 351, 256 et
99 ns. Ces résultats moyens associés à l’occupation en surface relativement élevée (en incluant les
mémoires) rendent cette solution inappropriée.
Le bloc de récupération des bits les moins fiables
La récupération des bits les moins fiables consiste à réaliser un tri par insertion. Les ressources nécessaires en terme de contrôle rendent difficile la synthèse architecturale de l’algorithme via l’outil
GAUT. C’est pourquoi, nous avons uniquement utilisé Agility Compiler dans ce cas. Les résultats obtenus après la synthèse architecturale dans le tableau 4.14 permettent de vérifier l’impact du nombre
de bits les moins fiables considérés sur la complexité matérielle et les performances. Dans notre cas,
un symbole est reçu à chaque cycle d’horloge.
Nbre de MF
Après compilations (portes)
Mapping (LUT)
Horloge (ns)
3
7433
2338
392
13.38
4
10830
3174
545
14.3
5
14779
4070
718
15.32
6
17685
4536
827
16.17
Tableau 4.14 — Résultats de la synthèse architecturale pour le bloc des moins fiables avec l’outil
Agility Compiler
Les solutions fournies par l’outil sont relativement complexes en nombre de LUT occupées à cause
des nombreuses opérations de comparaisons générées par le tri. La complexité est une fonction linéaire
du nombre de bits les moins fiables.
4.3.2.2
Les blocs de la partie de traitement
L’intérêt de l’exploration menée est d’exploiter le parallélisme dans les traitements. On rappelle
que le décodage algébrique est appliqué sur un ensemble de vecteurs de test. Leur génération n’est
pas abordée puisqu’il s’agit de la manipulation de données nécessitant de nombreux opérateurs de
comparaison (donc de contrôle). En revanche, le traitement en parallèle de chacun des vecteurs de test
semble intéressant pour une accélération du processus. Pour cela, en se référant à la figure 3.15, il est
possible d’envisager la duplication de l’ensemble PGZ/Chien/Correction en fonction du nombre de
vecteurs de test. Ainsi, nous proposons les résultats de synthèse architecturale pour 1, 8 et 16 vecteurs
de test.
L’algorithme PGZ
L’algorithme PGZ nécessite des opérations de division dans le corps de Galois. Celles-ci sont réalisées
140
par une mémoire et une opération de multiplication. Même si le principe est identique dans les deux
outils, la manipulation ne s’effectue pas de la même manière. Dans GAUT, un nouvel opérateur est
créé, il masque l’utilisation d’une RAM au niveau comportemental. Au contraire dans Agility, cette
transformation apparaı̂t dans le code SystemC élaboré par la présence d’un composant mémoire en
dehors du bloc PGZ. Dans ce cas, les contraintes de temps d’accès à la mémoire sont à prendre en
compte dans l’écriture du module.
Cadence
Optimisation
Opérateurs
Contrôle
Pipe.
Mult.
Add/Sous.
XOR
Ou
Inv.
Reg.
Mux/Demux/Trist.
nbre états FSM
signaux
Mem.
160
X
1
1
1
1
1
51
47
16
97
1
1 VT
80
40
X
X
2
5
1
1
1
3
1
1
1
1
62
92
58
83
8
4
118 171
1
1
160
X
8
1
4
2
2
376
372
16
739
2
8 VT
80
40
X
X
17
37
2
4
8
17
3
6
3
6
558
700
533
572
8
4
1065 1217
3
6
160
X
17
2
8
3
3
738
728
16
1446
3
16 VT
80
40
X
X
32
74
4
8
14
34
6
12
6
12
1049 1377
976 1111
8
4
1969 2380
6
12
Tableau 4.15 — Résultats de la synthèse architecturale pour le bloc PGZ avec l’outil GAUT
Toutes les solutions proposées (tableau 4.15) sont des architectures pipelines. La complexité est
fonction du nombre de vecteurs de test et de la cadence fixée par le concepteur. Le principal point
bloquant de la parallélisation massive est l’accès aux données stockées en mémoires (notamment pour
les opérations de division). En effet, ces dernières occupent une surface trop importante pour une
implantation raisonnable dans le cas de l’utilisation de 16 vecteurs de test pour une cadence de 20 ns.
L’outil Agility Compiler ne nous a pas permis de proposer différentes solutions architecturales
puisque au delà d’un bloc PGZ, la synthèse architecturale fournie une solution incomplète et le graphe
flot de données et de contrôle généré présente des erreurs. Cela montre les limites actuelles de cet
outil.
Le processus de correction est assez semblable à celui de l’algorithme PGZ. Toutes les opérations
sont réalisées dans le corps de Galois (addition, multiplication, division). Des opérations de contrôle
sont également indispensables pour fournir les erreurs et les échecs de décodage suivant la correction
requise t = 1 ou t = 2.
Les résultats de synthèse figurent dans le tableau 4.16. Les impacts liés aux choix de la cadence et
du nombre de vecteurs de test sont semblables à ceux observés dans le cas de l’algorithme PGZ. Une
solution entièrement parallèle n’est clairement pas envisageable pour une implantation raisonnable.
Un compromis avec l’utilisation conjointe de plusieurs blocs capable de décoder 8 vecteurs de test
semble plus adaptée.
Cadence
Optimisation
Pipe.
Nombre
Mult.
d’opérateurs
Ou X
Et
Inv.
Reg.
Mux/Demux/Tri.
Contrôle
nbre états FSM
signaux
Mem.
141
70
X
1
1
1
1
16
14
7
27
1
1 VT
40
X
2
1
1
1
22
16
4
37
1
20
X
3
2
1
1
24
17
2
37
1
70
X
8
4
2
3
113
108
7
216
3
8 VT
40
20
X
X
15
24
6
12
2
4
4
8
132 169
126 136
4
2
238 287
4
8
70
X
17
7
3
5
212
200
7
402
5
16 VT
40
X
30
12
4
8
259
226
4
467
8
20
X
48
24
8
16
330
258
2
554
16
Tableau 4.16 — Résultats de la synthèse architecturale pour le bloc de correction avec l’outil GAUT
Calcul des métriques et tri
Ce bloc est déjà complexe dans le cas d’une synthèse logique à partir d’une description au niveau RTL.
En effet, il contient beaucoup d’opérations de contrôle. C’est pourquoi, nous n’avons pas jugé utile de
le considérer ici puisque les outils de synthèse d’architecture envisagés ne sont pas appropriés.
4.3.2.3
Les blocs de la partie émission
Les blocs concernés par cette partie sont respectivement les blocs de calcul de la fiabilité, l’élaboration de l’information extrinsèque et la production des données décodées. Le bloc de calcul de
la fiabilité n’a pas été soumis à la synthèse architecturale. En effet, il ne se prête pas à ce type de
processus et nécessiterait sa réécriture complète pour l’adapter aux compilateurs. En revanche, nous
avons considérés les blocs de calcul de l’information extrinsèque et de calcul des données décodées.
De la même manière que dans la partie de réception, les traitements dépendent de la disponibilité
des données entrantes. Nous retrouvons donc des résultats similaires en terme de parallélisme à ceux
obtenus pour un simple calcul de parité par exemple. Cependant, les ressources matérielles utilisées
sont différentes. Les tableaux (4.17) et (4.18) précisent les résultats de synthèse obtenus.
Le calcul de l’information extrinsèque consiste à soustraire l’information sur chaque symbole avant
décodage à l’information obtenu après décodage (i.e. la fiabilité). L’élaboration du mot de code consiste
à pondérer l’information extrinsèque puis à l’ajouter au mot reçu.
Dans Agility Compiler, contrairement aux synthèses précédentes, les données entrantes ne sont
plus stockées avant le traitement. La description des modules intègre autant de ports d’entrées/sorties
que de données à traiter. Les surfaces occupées et les fréquences de fonctionnement figurent dans le
tableau 4.18.
Les ressources de calcul sont bien dupliquées puisque les fréquences de fonctionnement sont les
mêmes pour toutes les architectures des deux blocs. Le principal problème d’une telle description
réside dans la description en SystemC qui devient fastidieuse (notamment pour les entrées/sorties).
142
Cadence
Optimisation
Non-pipe
Pipe.
Nombre
mult.
d’opérateurs
Add/Sous
reg.
Mux/Demux/Tris.
Contrôle
nbre états FSM
signaux
Info. extrins.
350 80 10
X
X
X
1
4
32
1
4
32
1
20 160
1
4
32
34 10
1
6
24 192
350
X
1
1
1
1
34
6
Correction
110 80
X
X
4
4
4
4
20 20
4
4
10
8
24 24
10
X
32
32
160
32
1
192
Tableau 4.17 — Résultats de synthèse architecturale pour le bloc de calcul de l’information extrinsèque et d’élaboration du mot corrigé avec l’outil GAUT
Nbre d’unité
Mapping (LUT)
Horloge (ns)
Info. extrins.
1
2
4
224 414 1300
24
41
73
9.17 9.17 9.17
Correction
1
2
4
116 208 388
11
16
24
7.71 7.71 7.71
Tableau 4.18 — Résultats de synthèse architecturale pour le bloc de calcul de l’information extrinsèque avec l’outil Agility Compiler
De plus, l’utilisation du parallélisme repose alors sur le concepteur ce qui n’est pas le but d’un tel
outil.
4.3.3
Conclusion
L’expérimentation conjointe des deux outils Agility Compiler et GAUT nous a permis de proposer
différentes solutions architecturales pour les blocs retenus. Un parallélisme total peut être obtenu à
condition de disposer des données nécessaires au calcul. Ainsi, l’augmentation de la cadence implique,
dans le cas d’un fonctionnement pipeline, une multiplication des bancs de mémoires pour alimenter
les opérateurs. L’objectif dans le cadre de notre application est donc de pouvoir utiliser et de mettre
en œuvre le parallélisme. Le point de départ de ce travail est l’architecture élaborée au chapitre 3
et rappelée sur la figure 4.4. L’exploration a été menée sur cette base. Tout d’abord, en considérant
la partie réception, il n’est pas possible, dans son organisation actuelle, de disposer du mot complet
à décoder. Cependant, la parité et les syndromes pourrait être calculés plus rapidement si le mot
entier était disponible. La partie de traitement des vecteurs de test se prête, quant à elle, à ce type de
synthèse. Au lieu de manipuler chacun des vecteurs de test séquentiellement, nous pouvons envisager
un décodage parallèle de l’ensemble des vecteurs de test. Les outils nous fournissent ainsi une première
estimation en terme de surface pour 4,8,16 ou 32 vecteurs de test. La découpe temporelle réalisée
préalablement (fig.3.10) s’en trouve tout de même modifiée. Ainsi, la cadence de fonctionnement est
augmentée et la latence de l’application est réduite d’environ un temps mot. Enfin, la partie émission
peut également bénéficier de la duplication des ressources de calcul. De manière analogue à la partie
4.4. PROTOTYPAGE DU TURBO DÉCODEUR FLEXIBLE
143
réception, cela repose sur la disponibilité des données en sortie du bloc de traitement. En effet, les
opérations s’effectuent sur les bits lors de l’utilisation de l’algorithme de Chase-Pyndiah. Pour un
code RS, une adaptation algorithmique est à prévoir pour passer du niveau bit au niveau symbole et
profiter du parallélisme ainsi généré.
Au niveau des outils, plusieurs remarques peuvent être formulées pour suggérer des pistes de
développement. En effet, les choix effectués lors de leur élaboration leur confèrent de facto certains
avantages et certains défauts. GAUT se situe à un niveau d’abstraction plus élevé qu’Agility Compiler. De nombreux opérateurs sont présents dans la bibliothèque de composant dans le cas contraire,
ils peuvent être définis. Ce choix présente des avantages puisque les possibilités d’exploration pour
le concepteur sont vastes. Il faudra toutefois veiller à optimiser ces opérateurs lors de la synthèse
logique. Malgré tout, il subsiste des inconvénients liés principalement aux algorithmes d’exploration
des graphes. L’orientation pour des applications de traitements massivement parallèle est clairement
affichée. Cependant, d’autres aspects comme la largeur des chemins de données fixes peuvent empêcher
l’indexation d’une mémoire. De plus, la valeur d’un index ou d’un registre doit être connue tout au
long du déroulement d’un algorithme sinon l’outil ne peut pas proposer d’architectures. La mise en
mémoire systématique des constantes dans la version en langage C est également pénalisante.
Agility Compiler a été conçu pour proposer des solutions d’implantation aux concepteurs. Il nécessite une description initiale des algorithmes en langage SystemC. A la différence de GAUT, les
opérateurs complexes peuvent être définis sous la forme de fonctions et sont dupliqués si nécessaire.
Ce positionnement un peu plus « bas niveau » aboutit à une implémentation relativement efficace.
Toutefois, le compilateur de l’outil est assez directif et impose des réécritures du code pour proposer
des solutions architecturales. Il en résulte que l’outil est assez restrictif dans l’exploration de l’espace de conception. D’autre part, le mapping mémoire n’est pas automatique et reste à la charge du
concepteur. Il est à noter que cette phase est laborieuse manuellement. Enfin, la principale limitation
de l’outil est la mauvaise gestion des indices de boucles. En effet, ils ne doivent pas être trop élevés
en cas de déroulage des boucles. Dans le cas contraire, la description ne peut pas être exploitée par
l’outil.
4.4
Prototypage du turbo décodeur flexible
L’architecture considérée a été évoquée dans le chapitre précédent et le flot de conception employé
a été décrit dans la première partie de ce chapitre. Nous allons dans cette section décrire la plate-forme
et le processus de mise en œuvre de notre application de turbo décodage de codes produits. Puis, les
caractéristiques du prototype sont données.
144
Instance Pµ 1
Logiciel
1
S1.asm
E1.asm
Com1.asm
Timer.asm
…
Pµ .h
Programme externe
Architecture piloté par le Pµ
Architecture
Fichiers fonctionnels
.HDL (SystemC ou VHDL)
S1.hdl
E1.hdl
Com1.hdl
Timer.hdl
…
Pµ .hdl
3
Environnement
Synthèse logique
Platine virtuel
Synthèse logique
Rx
Pµ
Archi
Tx
4
2
Cross-compilation
6
Compilation
placement/routage
Platine physique
Prog. architecture
Prog. exécutable
5
Prog. de boot
7
Fichier bit
Prog. de la platine
…
Copie en mémoire
et exécution
Figure 4.10 — Les différentes étapes aboutissant au prototypage
4.4.1
Les différentes étapes aboutissant au prototypage
Plusieurs étapes sont nécessaires pour mettre en place l’architecture sur le FPGA et lancer l’exécution du programme sur le processeur NIOS II. Le processus de prototypage se déroule en 7 étapes,
elles apparaissant sur la figure 4.10 et sont numérotées de manière chronologique :
1. la description du processeur : les ressources retenues sont spécifiées. Une partie matérielle correspond à l’implantation des interfaces des périphériques. Une partie logicielle contient les routines
nécessaires au pilotage des périphériques.
2. la synthèse logique du processeur : seules les ressources matérielles sont synthétisées.
3. la description de l’architecture pilotée par le processeur : il s’agit de la description de notre
décodeur élémentaire flexible en langage SystemC.
4. la synthèse logique du décodeur élémentaire.
5. le transfert sur la plate-forme de prototypage : après une opération de placement/routage avec
l’outil Quartus II, un fichier binaire est généré pour configurer le FPGA.
6. la compilation croisée entre le programme s’exécutant sur la cible logicielle et les ressources
matérielles utilisées : cette opération lie les aspects matériels/logiciels des ressources.
7. le téléchargement du programme en code machine sur la plate-forme : elle s’effectue via le connecteur JTAG et le module dédié sur le processeur.
Toutes ces étapes aboutissant au prototypage nécessitent l’utilisation d’une plate-forme de validation qui est détaillée dans la suite.
4.4. PROTOTYPAGE DU TURBO DÉCODEUR FLEXIBLE
4.4.2
145
La plate-forme de validation
La plate-forme de validation Nios II Development Kit a été retenue dans le cadre de cette étude
pour le prototypage (figure 4.11). Elle permet d’implanter des systèmes électroniques embarqués relativement complexes. Elle se compose principalement d’un FPGA Stratix Ep1s40f780 et de plusieurs
périphériques : des afficheurs LED, des mémoires (SRAM, flash, CompactFlash...), des boutons poussoirs et des ports d’entrées/sorties divers (ethernet, série, JTAG...). Comme vu précédemment, la
Figure 4.11 — La carte de développement NIOS II Development Kit
configuration s’effectue en deux phases (matérielle/logicielle). Dans un premier temps, le fichier de
configuration binaire est téléchargé du PC vers la plate-forme avec l’outil Quartus II. Dans un second
temps, le programme est envoyé vers le processeur implanté sur le FPGA. La procédure à suivre
pour la configuration de la plate-forme a évoluée au cours de l’année 2006 puisque les outils mis à
disposition par Altera sont devenus plus mature. Auparavant, le développement logiciel était dissocié
du processus de communication avec la cible. En effet, la communication entre le processeur NIOS et
les périphériques se faisait via une invite de commande. Dorénavant, un environnement de conception
logiciel IDE est fourni pour développer les aspects logiciels. Il est désormais possible d’effectuer dans
le même flot de conception l’ensemble des étapes allant de la description de l’algorithme en C jusqu’au
debuggage par émulation ou directement sur la cible. Dans ce cas, le processeur NIOS II doit contenir
un module spécifique dédié à cette tâche. De plus, une couche d’abstraction a été ajoutée pour masquer
les ressources matérielles au concepteur logiciel.
146
4.4.3
Les caractéristiques du prototype
Notre but est de valider le fonctionnement de notre architecture flexible sur la plate-forme. Dans
cette optique, l’objectif est de réaliser le décodage itératif d’un bloc via un programme s’exécutant sur
le processeur NIOS II. Ce dernier n’exploite pas toutes ses possibilités en terme de calcul notamment.
Il remplit seulement le rôle d’une unité de contrôle. En revanche, cette solution présente des avantages
puisqu’elle va permettre d’envisager une évolution future en terme de fonctionnalité.
Trois phases successives sont nécessaires pour vérifier le bon fonctionnement de notre application
(figure 4.12) :
– un bloc d’information à décoder (codé et bruité) est chargé dans l’une des mémoires embarquées
sur le Stratix via le processeur NIOS II.
– le programme de décodage gérant à la fois le décodeur élémentaire et les périphériques mémoires
est ensuite envoyé sur le processeur. L’appui sur un bouton poussoir lance alors le processus de
turbo décodage.
– le bloc décodé est récupéré via une procédure de lecture en zone mémoire.
Mem.
R
Mem.
R’
Mem.
R’’
1
2
Processeur
NIOS II
3
Décodeur
Élémentaire
BCH/RS
Stratix 1s40
Boutons poussoirs
Nios Development Kit
Figure 4.12 — Les phases de fonctionnement du prototype
La comparaison des blocs avant et après décodage nous permet donc d’évaluer le nombre de
symboles corrigés. La validation est effectuée par comparaison avec les résultats obtenus lors des
simulations fonctionnelles.
Dans notre cas, le processeur NIOS II a une fréquence de fonctionnement de 50 MHz. Le bus
système Avalon fonctionne également à la fréquence de 50 MHz car son horloge provient du processeur
NIOS II. Le décodeur élémentaire,quant à lui, peut également fonctionner à une fréquence de 50 MHz.
Les transmissions de données s’effectuent vecteur par vecteur. A chaque début de vecteur, un signal
de synchronisation indique au décodeur qu’un nouveau vecteur est disponible et initialise les blocs. A
4.5. CONCLUSION
147
chaque fois qu’une écriture sur le bus a lieu, elle est suivie d’une lecture pour récupérer les données
décodées. C’est pourquoi, dans cette solution architecturale, le décodeur élémentaire ne fonctionne
qu’à 25 MHz. Seul, le décodeur élémentaire peut a priori fonctionner à plus de 50 MHz. Même si le
critère d’arrêt évoqué précédemment a été implanté, huit itérations ont été effectuées pour le turbo
décodage ce qui signifie que le décodeur élémentaire atteint un débit fixe de 1,5 MSymbole/s. En fait,
le goulot d’étranglement est la fréquence de fonctionnement du processeur. En effet, il restreint les
échanges. Deux solutions peuvent être envisagées pour améliorer les performances de notre prototype.
La solution architecturale évoquée dans le chapitre 3 suggère l’utilisation de DMA pour accélérer
le traitement. Une autre piste pourrait être de déplacer des fonctionnalités du décodeur élémentaire
vers le processeur. Ainsi, le processeur ne jouerait plus simplement le rôle d’unité de contrôle mais
élaborerait également des calculs tels que les syndromes ou la parité.
L’ensemble des travaux évoqués a fait l’objet d’une publication à ReCoSoC en 2006 [PJAJ06a].
Cela concerne à la fois la conception, l’implémentation et le prototypage de notre architecture flexible
de turbo décodage de codes produits.
4.5
Conclusion
Nous avons expérimenté dans ce chapitre un flot de conception original permettant à partir d’une
description algorithmique d’aller jusqu’à l’implantation sur un circuit ASIC ou FPGA. Un environnement de développement haut niveau et le langage de description système SystemC nous ont permis de
modéliser notre application. Ainsi, nous avons pu valider très tôt le fonctionnement des applications
considérées dans la chaı̂ne de développement. Des synthèses soit d’une description SystemC au niveau
RTL soit d’une description SystemC au niveau comportemental ont pu être réalisées.
Tout d’abord, nous avons expérimenté ce flot de conception à travers l’implantation du décodeur
élémentaire BCH d’un turbo décodeur de codes produits de pouvoir de correction t = 1, pour différentes longueurs de code. L’implantation de descriptions en SystemC au niveau RTL s’est révélée
aussi efficace que pour une description en VHDL au niveau RTL sur une cible ASIC.
Puis, les synthèses logiques de chaque bloc constituant l’ensemble codeur/turbo décodeur flexible
ont été effectuées à partir des descriptions au niveau RTL pour l’implantation sur un circuit FPGA
ep1s40. Les architectures flexibles évoquées dans le chapitre 3 ont été considérées. Le codeur flexible
occupe une surface de 567 LE. Le décodeur élémentaire, quant à lui, occupe 2761 LE tandis que le
processeur NIOS II occupe 3540 LE. La surface occupée par ce dernier peut paraı̂tre importante mais il
s’agit d’une version standard du processeur intégrant les interfaces nécessaires au debuggage. De plus,
il pourra intégrer d’autres fonctionnalités dans le futur. Au total, le turbo décodeur flexible occupe
15.3% du circuit FPGA.
A la suite de ce travail, nous avons décidé d’insérer des outils de synthèse architecturale dans
148
le flot de conception. Les différents résultats obtenus nous ont notamment permis d’envisager une
exploitation du parallélisme dans la partie traitement du décodeur élémentaire. En effet, la duplication
de l’ensemble PGZ/Chien/Correction permet de traiter 16 vecteurs de test en parallèle et de réduire
la latence. D’autre part, en imaginant que les parties réception et émission ne travaillent plus au
niveau symbole, comme actuellement, mais au niveau vecteur il serait également possible d’exploiter
le parallélisme. Enfin, nos expérimentation des outils GAUT et Agility Compiler aboutissent au fait
que des évolutions sont encore nécessaires.
Enfin, le prototypage a été réalisé sur une plate-forme NIOS II development kit. Au cours de notre
phase de développement, nous sommes passés d’un processeur NIOS à un processeur NIOS II. Dans le
même temps, les outils ont également évolué. Nous avons pu aboutir à une solution nous fournissant
un débit de 1,5 Mb/s. Des pistes ont été données afin d’augmenter ce débit. C’est dans cette optique
que l’utilisation de DMA est suggérée.
CHAPITRE
5
Conclusion et
perspectives
Conclusion
La rapide évolution des technologies CMOS offre aujourd’hui des perspectives d’intégration importante. Désormais, des systèmes complexes peuvent être intégrés sur un même circuit SoC ou SoPC.
D’autre part, les applications de communications numériques sous contrainte d’exécution temps réel
présentent des complexités de plus en plus élevées. C’est pourquoi, les architectures implémentant ces
applications doivent être capables de supporter plusieurs fonctionnalités et de les mettre en œuvre
dynamiquement. Dans ce contexte, les méthodologies de conception doivent évoluer pour faciliter
le développement, la validation et le prototypage de ces systèmes complexes. L’élévation du niveau
d’abstraction, l’utilisation de langage de description système tel que SystemC et la mise à disposition
d’outils de synthèses adaptés favorisent cette évolution.
Notre étude tient compte du domaine de l’application choisie à savoir les codes correcteurs d’erreurs
et en particulier le turbo décodage des codes produits de type BCH ou Reed-Solomon. En effet, la
définition de nouveaux algorithmes et la recherche d’architectures originales pour les applications
de communications numériques dans les domaines du codage canal (turbocodes) et des traitements
itératifs dans les récepteurs (turbo communications) représentent la plus grande part de l’activité
de recherche du département électronique de l’ENST-Bretagne. L’objectif général a alors consisté
au développement d’architectures originales favorisant l’intégration de systèmes turbo sur une même
puce à l’aide d’un flot de conception innovant. Ainsi, l’originalité de notre démarche réside autant
dans l’utilisation d’un flot de conception de haut niveau et l’exploration architecturale des solutions
possibles que dans la mise au point d’une architecture flexible dédiée au turbo décodage de codes
produits.
Nous avons tout d’abord proposé une étude sur les différents algorithmes mis en œuvre dans le
cadre du décodage des codes en blocs BCH et RS utilisés pour le turbo décodage des codes produits.
A travers une étude de complexité fonctionnelle, les différents paramètres de flexibilité, notamment
150
CHAPITRE 5. CONCLUSION ET PERSPECTIVES
la longueur de code N et le pouvoir de correction t, ont été caractérisés. Leur impact respectif sur
le nombre d’opérations nécessaires a été estimé afin de leur attribuer une valeur pour rendre l’implantation possible. Ainsi, différentes configurations de code ont été retenues pour l’implémentation
d’un turbo décodeur flexible dédié aux codes produits : les codes BCH (32,26) et (32,21) et les codes
Reed-Solomon (31,29) et (31,27). D’autre part, des critères d’arrêt ont été envisagés pour interrompre
une exécution superflue du processus de décodage itératif pour le décodage d’un code BCH ou d’un
code RS. Pour cela, un critère d’arrêt hiérarchique a été proposé pour conserver les performances
d’un décodage sans critère d’arrêt. Une architecture tenant compte de la flexibilité introduite a été
développée pour assurer à la fois le décodage des codes BCH et RS pour différents pouvoirs de correction. Il est à noter que l’intégration d’un turbo décodeur dédié à des codes produits à base de codes
Reed Solomon est une innovation à elle seule. En effet, il s’agit, à notre connaissance, de la première
solution architecturale proposée pour le décodage de tels codes. L’architecture flexible se compose,
quant à elle, d’une partie matérielle, le décodeur élémentaire, et d’une partie logicielle, un processeur
NIOS II. La première possède une structure en trois parties et une mémoire interne. La seconde joue
le rôle de l’unité de contrôle et de gestion des données entrantes et sortantes via des plans mémoires
externes. Lors de cette étude, une découpe temporelle a été détaillée pour chacune des configurations
envisagées.
Parallèlement, nous avons expérimenté un flot de conception original permettant à partir d’une
description algorithmique d’aller jusqu’à l’implantation sur un circuit ASIC ou FPGA. Un environnement de développement haut niveau et l’utilisation du langage de description système SystemC ont
ainsi facilité la modélisation de notre application. L’avantage de ce choix est de pouvoir valider très
tôt dans la chaı̂ne de développement le fonctionnement des applications considérées et de bénéficier de
temps de simulation réduits. De plus, l’exploration d’architecture est simplifiée. Puis, il est possible
d’effectuer les synthèses soit d’une description SystemC au niveau RTL soit d’une description SystemC
au niveau comportemental. Tout d’abord, le flot a été expérimenté à travers l’implantation d’un code
produit BCH(32,26)2 décrit en SystemC au niveau RTL. Les résultats d’implantations sont équivalents à ceux obtenus dans le cas d’une description en VHDL au niveau RTL sur une cible ASIC. Ce
travail nous a permis d’acquérir des nouvelles connaissances à la fois au niveau langage et au niveau
environnement de modélisation. Puis, les synthèses logiques de chaque bloc constituant l’ensemble
codeur/turbo décodeur flexible ont été faites à partir des descriptions au niveau RTL pour l’implantation sur un circuit FPGA ep1s40. Le codeur flexible occupe une surface de 587 LE soit 1.4% de la
surface totale du FPGA. Les trois parties du décodeur élémentaire (réception, traitement, émission)
occupent respectivement 488, 1811, 462 soit au total 2761 LE soit 6.7% du circuit. Le processeur
NIOS II occupe 3540 LE soit 8.6% de la surface totale du FPGA. L’insertion de la synthèse architecturale dans le flot de conception nous a ensuite permis d’explorer différentes solutions architecturales.
L’objectif dans le cadre de notre application était de pouvoir utiliser et de mettre en évidence le parallélisme inhérent aux algorithmes. Ainsi, plusieurs explorations architecturales ont été effectuées à
151
l’aide des outils GAUT et Agility Compiler. Une phase préliminaire de familiarisation avec les outils
et les méthodologies associées s’est avérée nécessaire.
Le dernier aspect de notre travail a consisté à réaliser un prototype. Il est à souligner que ce
travail a été mené dans un environnement de conception en constante évolution. C’est pourquoi, nous
avons dû tenir compte des changements dans le flot de conception et des améliorations technologiques.
L’étape de prototypage, longue et fastidieuse, a permis de valider le fonctionnement de notre solution
architecturale. La plate-forme NIOS II Development Kit construite autour d’un circuit FPGA Altera
ep1s40 a été retenue. L’ensemble de l’architecture de turbo décodage de codes produits a été implanté
sur le circuit. Un programme a ensuite été téléchargé sur le processeur de manière à gérer à la fois
les mémoires et le décodeur élémentaire. Le « monitoring » et la récupération des données décodées
sont effectués via l’interface JTAG. Huit itérations de décodage sont réalisées par l’application. Le
décodeur élémentaire atteint alors un débit de 1,5 MSymbole/s. Le goulot d’étranglement est le bus
système Avalon utilisé entre le décodeur élémentaire et le processeur NIOS II.
Perspectives
Cette étude a été effectuée selon des axes de recherche qui sont en constante évolution. Ainsi, il
est possible d’évoquer des perspectives sous forme d’améliorations et de modifications de la démarche
effectuée. Elles portent sur deux aspects :
– les flots de conception et les outils.
– les applications de communications numériques susceptibles de bénéficier de cette approche.
Tout d’abord, nous avons voulu vérifier qu’il était possible d’utiliser un flot de conception continu
à partir d’une description algorithmique jusqu’à l’implantation matérielle. Il se révèle que la synthèse
architecturale d’une description en SystemC au niveau comportemental avec les deux outils considérés
est appropriée lorsqu’elle est appliquée sur un module dominé par un traitement intensif de données. Il
aurait été intéressant d’envisager d’autres outils pour les applications dominées par des opérations de
contrôle. Dans notre cas, seule la synthèse logique d’une description SystemC au niveau RTL fournit
un résultat d’implantation exploitable. La prise en compte des avantages des deux outils considérés
(GAUT et Agility Compiler) pourrait faciliter le passage d’un niveau d’abstraction à l’autre notamment en ce qui concerne les aspects mémoires. En effet, d’une part, une description sous la forme
d’un algorithme dans GAUT est pour l’instant trop abstraite pour envisager une gestion efficace des
plans mémoires. D’autre part, une description en SystemC, dans Agility Compiler, fige les entrées/sorties d’un module mais rend l’indexation de plan mémoire possible. Un compromis entre les deux
approches permettrait à la fois d’envisager un « mapping » mémoire performant et une exploration
d’architecture plus grande. De plus, les deux outils ont des modèles d’architectures cibles figés qui ne
sont pas appropriés pour tous les types d’application. L’idéal serait d’introduire un peu de flexibilité
au niveau de l’architecture cible de manière à ce que le concepteur ait la main mise sur la description
152
CHAPITRE 5. CONCLUSION ET PERSPECTIVES
au niveau RTL obtenue. Par exemple, cette amélioration serait particulièrement bénéfique au niveau
de la gestion des communications. Un autre point important peut être l’introduction dans les outils
de développement de la gestion de la reconfiguration. En effet, une analyse croisée des algorithmes
employés pourrait permettre de repérer les traitements communs. Ainsi, une répartition temporelle
des ressources favoriserait la réutilisation des mêmes fonctionnalités.
Notre application concerne uniquement le turbo décodage des codes produits à base de codes
BCH et RS. Nous avons constaté que le débit proposé par notre solution architecturale était limité.
Cependant, il est envisageable d’améliorer facilement ce dernier en implémentant des DMA pouvant
accéder aux mémoires de données sans interrompre l’exécution du programme sur le processeur NIOS
II. Dans la même optique, il est également possible de déporter des fonctionnalités de calcul sur la cible
logicielle ce qui permettrait de limiter les échanges sur le bus système. Plus largement, l’architecture
mise en oeuvre peut également bénéficier à toutes les applications de turbo communications et/ou
turbo réception. En effet, nous considérons dans tous les cas que le processeur est chargé de la gestion
de l’aspect « turbo » et de l’échange des données avec la ou les parties matérielles. Prenons l’exemple
de l’implantation d’un récepteur itératif pour une transmission de type ST-BICM (MIMO), dans
ce cas la phase de détection nécessite par exemple l’utilisation d’un détecteur MMSE. Ce détecteur
reçoit à la fois les données modulées issues du canal et les données issues du décodage de canal.
Le processeur NIOS II pourrait tout à fait remplir ce rôle tandis qu’une partie matérielle réaliserait
le décodage de canal. Le dernier point concerne la reconfiguration dynamique qui très intéressante
dans le cadre d’applications itératives. L’architecture est alors modifiée en cours de traitement afin de
réaliser des tâches particulières ponctuellement dans le temps. Ainsi, l’intégration de critères d’arrêts
en fonction du rapport signal à bruit sur le processeur permettrait de configurer l’architecture élaborée
en fonction des besoins en termes de performances. Dans ce cas, il est alors possible de parler d’autoreconfiguration qui serait initiée par le NIOS II pour une reconfiguration partielle ou totale du circuit.
Cependant, ceci implique l’implantation d’un estimateur de canal sur le circuit FPGA.
ANNEXE
A
c
Le langage SystemC L’utilisation d’un langage de conception au niveau système devient indispensable pour plusieurs
raisons :
– Les systèmes sont une combinaison de blocs matériel(s) et logiciel(s). Cependant, les langages
de conception sont dédiés à la partie matérielle uniquement.
– Les systèmes comprennent des blocs IPs provenant de sources différentes. Ces blocs d’origines
diverses doivent avoir un langage de description système commun pour modéliser l’ensemble de
l’application.
– La simulation au niveau RTL devient trop complexe. Une simulation a un haut niveau d’abstraction pour des systèmes complexes permet un gain de temps important.
– La modélisation au niveau système doit être exploitable lors des phases de synthèses logicielles
et matérielles. Ainsi, un prototype virtuel de la partie matérielle doit être disponible pour le
développement de la partie logicielle.
SystemC est un sous-ensemble du langage ANSI-C++ combiné à un ensemble de librairies favorisant la spécification, la simulation et la synthèse de systèmes numériques complexes. Initialement, le
langage SystemC était dédié à la simulation au niveau architectural mais ce langage s’enrichit de bibliothèques pour pouvoir répondre à toutes les caractéristiques d’un langage système. En 1989, Synopsys
transmet son outil commercial Scenic au domaine du libre. La version 0.9 de SystemC est proposée.
La société Frontier Design produit la version 1.0 tandis que CoWare aboutit en 2000 à la version 1.1.
Il s’agit de la première version officielle de SystemC. L’OSCI (Open SystemC Initiative) est alors créé,
rassemblant de nombreuses sociétés et laboratoires de recherche. Cette organisation est en charge de
diffuser, de promouvoir et de rédiger les spécifications du langage SystemC. En 2001, SystemC permet la modélisation de systèmes abstraits (avant partitionnement matériel/logiciel), aboutissant à la
version 2.0. En décembre 2005, le langage SystemC est normalisé IEEE [Soc05] et la version 2.2 est
disponible depuis juin 2006.
La structure du langage SystemC repose sur différents éléments :
– le module : un modèle SystemC est construit à partir d’une hiérarchie de modules qui peuvent
c
ANNEXE A. LE LANGAGE SYSTEMC 154
eux-mêmes contenir des modules et des processus (similaire au langage VHDL et Verilog).
Les modules et les processus communiquent à travers des signaux par l’intermédiaire de ports
(entrée, sorties, E/S) associés aux modules.
– le processus : il en existe trois types :
1. SC METHOD : il s’exécute directement (pas d’attente ou de boucle infinie). Il est appelé
par le scheduler à chaque notification d’événements dans une liste de sensibilité. Il est
considéré comme une fonction.
2. SC THREAD : ce processus est exécuté une seule fois de manière séquentielle grâce à
l’instruction Wait (ex : FSM). Il est activé à chaque notification d’une liste de sensibilité.
3. SC CTHREAD : il s’agit d’un cas particulier du précédent, une horloge est associée a ce
type de processus. Les signaux de sortie sont alors disponibles sur des fronts de l’horloge.
Ce dernier processus a été abandonné lors de la normalisation mais est disponible dans les
librairies pour la compatibilité des versions.
Les caractéristiques de chacun de ces processus sont rappelées dans le tableau A.1.
– la synchronisation :
– l’attente (« waiting ») : fin du cycle ou événement
– l’observation (« watching ») : globale ou locale
– le canal :ensemble de variables et de fonctions définissant le protocole de communication
– l’interface : ensemble de fonctions de communication spécifiées au sein du canal.
La figure A.1 illustre l’utilisation des différents éléments décrit précédemment. Il s’agit de l’architecture d’un module décrit en SystemC. Un autre point atout du langage est le type des données
correspondant aux variables et aux signaux (voir fig A.2). De plus, il est possible de définir ses propres
structures de données.
Déclenchement
Arrêt d’exécution
Fonction d’arrêt
Constructeur
et sensibilité
Exemple de
modélisation
(matériel)
SC METHOD
notification
d’événements
non
-
SC THREAD
notification
d’événements
oui
wait()
SC METHOD(p)
SC THREAD(p)
sensitive(s)
sensitive pos(s)
sensitive neg(s)
Logique
combinatoire
sensitive(s)
sensitive pos(s)
sensitive neg(s)
Logique séquentiel
au niveau RTL
SC CTHREAD
horloge
oui
wait()
wait until()
SC CTHREAD
(p,clock.pos())
SC CTHREAD
(p,clock.neg())
Logique séquentiel
à un niveau de
conception élevé
Tableau A.1 — Les caractéristiques des différents processus du langage SystemC
155
Canal
Module
Processus
Canal
Processus
Canal
Module
Module hiérarchique
interface
signaux
port
Figure A.1 — Architecture hiérarchique d’un module décrit en langage SystemC
```
``` Description
```
```
Type
sc bit
sc logic
sc int
sc uint
sc bigint
sc biguint
sc
sc
sc
sc
sc
bv
lv
fixed
ufixed
fix
sc ufix
SystemC
bit à 2 valeurs ’0’ et ’1’
bit à 4 valeurs ’0’,’1’,’X’ et ’Z’
entier signé 1 à 64 bit
entier non signé 1 à 64 bit
entier signé
largeur variable à l’exécution
entier non signé
vecteurs de bit à 2 valeurs
vecteurs de bit à 4 valeurs
Nombre en virgule fixe signé
Nombre en virgule fixe non signé
Nombre en virgule fixe signé
Nombre en virgule fixe non signé
Tableau A.2 — Les caractéristiques des différents types de données du langage SystemC
ANNEXE
B
La plate-forme Palmyre
Le projet CPER (Contrat de Plan Etat Région) PALMYRE vise à réaliser une plate-forme de
développement et d’évaluation de systèmes radioélectriques. Il s’agit d’une plate-forme d’intégration
composée de sous-ensembles matériels et logiciels. L’exploitation du canal de transmission radioélectrique constitue le principal domaine d’application du projet. Celui-ci doit être étendu car l’ambition
de la plate-forme est d’être ouverte à un grand nombre d’applications.
Le projet regroupe quatre partenaires académiques bretons (Université de Bretagne Sud, ENSTBretagne, INSA, Université de Rennes 1). Il constitue un groupe d’environ 40 chercheurs et doctorants,
répartis sur quatre laboratoires CNRS : MO-LEST et TAMCIC (ENST Bretagne), IETR (Université
de Rennes 1 et l’INSA de Rennes) et LESTER (Université de Bretagne Sud). D’autre part, des
partenaires privés sont évidemment concernés, il s’agit, en particulier, des sociétés : Thomson, France
Telecom, Elektrobit, CNES, Turbo-concept, COMSIS, SACET, WOLT, Rubisoft, Siradel et bien sûr
Sundance.
Le projet est structuré en 6 sous-projets correspondant chacun à l’un des aspects de la plate-forme :
1. Fonctions et algorithmes en bande de base.
2. Fonctions et sous-ensembles analogiques.
3. Caractérisation et modélisation du canal de propagation.
4. Nouvelles techniques en radiocommunications.
5. Optimisation d’architectures et spécifications algorithmiques.
6. Analyse et développement de techniques MIMO.
Le premier sous-projet dépend du département électronique de l’ENST-Bretagne. L’objectif est de
développer un système de transmission numérique ”robuste” pour valider les fonctions radiofréquences,
conversion analogique/numérique et traitement numérique en bande de base de la plate-forme. Actuellement, un système de transmission numérique SISO (Single Input Single Output) est opérationnel.
Il fonctionne à une fréquence porteuse de 5,1 GHz avec une modulation QPSK. Le débit brut obtenu
est de 18 Mbit/s.
Les résultats obtenus sont de plusieurs natures :
158
ANNEXE B. LA PLATE-FORME PALMYRE
– Validation des concepts de prototypage rapide proposés dans le sous-projet 5 (Émetteur et
récepteur implantés sur un FPGA).
– Modulation tout numérique, algorithme de récupération de rythme et de porteuse de type
aveugle.
– Validation par transmission en conditions LOS.
– Valorisation pédagogique de la chaı̂ne (projets d’élèves).
Les perspectives sont nombreuses. Dans un premier temps, il faudrait gagner en robustesse pour
aborder le contexte des transmissions mobiles (codage de canal pour traiter les trajets multiples,
améliorer l’algorithme de récupération rythme aux faibles S/B). Dans un second temps, un gain en
flexibilité pourrait être obtenu en décomposant l’architecture en blocs élémentaires réutilisables et en
assurant l’interopérabilité avec les développements des autres sous-projets.
La vocation du projet PALMYRE est de développer une compétence forte dans le grand Ouest
sur les nouvelles techniques de transmissions numériques et sur la conception de chaı̂nes de traitement
du signal sur des plates-formes matérielles hétérogènes. Des projets d’accompagnement de cette plateforme sont en cours depuis 3 ans (EPAR3D, RITMO, MC-CDMA).
L’objectif est d’ouvrir le plus largement possible la plate-forme à des partenaires académiques ou
industriels. Ces derniers devront jouer un rôle essentiel dans la valorisation de cette plate-forme. Son
utilisation sera donc, à terme, proposée à des tiers appartenant ou non à la région Bretagne.
Glossaire
A/N
Analogique/Numérique, 19
AES
Advanced Encryption Standard, 12
ALM
Adaptive Logic Module, 12
ASIC
Application Specific Integrated Circuit, 4
ASK
Amplitude Shift Keying, 51
ASMBL
Advanced Silicon Modular BLock, 11
BCJR
Bahl-Cocke-Jelinek-Raviv, 85
BPSK
Binary Phase Shift Keying, 51
CDFG
Control Data Flow Graph, 30
CISC
Complexe Instruction Set Computer, 14
CLB
Configurable Logic Block, 8
CMOS
Complementary Metal Oxide Semi-conductor, 7
CPLD
Complex Programmable Logic Device, 6
CPU
Central Process Unit, 5
DDR
Double Data Rate, 12
DLL
Delay-Locked Loop, 6
DMIPS
Dhrystone MIPS, 11
DSP
Digital Signal Processor, 13
E/S
Entrée/Sortie, 1
EDGE
Enhanced Data Rates for Global Evolution, 1
FPGA
Field-Programmable Gate Array, 3
FSK
Frequency Shift Keying, 51
160
Glossaire
GPRS
General Packet Radio Service, 1
GSM
Global System for Mobile communications, 1
LAB
Logic Array Block, 12
LE
Logic Element, 12
LFSR
Linear Feedback Shift Register, 104
LUT
Look-Up-Table, 8
MAC
Multiply And Accumulate, 10
MAP
Maximum A-Posteriori, 60
ME
Motifs d’Erreurs, 57
MIP
Millions of Instructions Per Second, 11
MPGA
Matrix-Programmable Gate Array, 5
N/A
Numérique/Analogique, 19
NRE
Non-Recurring Engineering, 5
PAL
Programmable Array Logic, 6
PCI
Peripheral Component Interconnect, 19
PLD
Programmable Logic Device, 6
PLL
Phase-Locked Loop, 9
PSK
Phase Shift Keying, 51
QAM
Quadrature Amplitude Modulation, 51
QDR
Quad Data Rate, 12
RISC
Reduced Instruction Set Computer, 14
RS
Reed-Solomon, 66
RTL
Register Transfer Level, 21
SDRAM
Synchronous Dynamic Random Access Memory,
12
SIMD
Single Instruction on Multiple Data, 18
SNR
Signal to Noise Ratio, 54
SoC
System on Chip, 19
Glossaire
161
SOPC
System On Programmable Chip, 20
SOVA
Soft Ouput Viterbi Algorithm, 85
SRAM
Static Random Access Memory, 7
SWP
Sub Word Parallelism, 18
TCB
TurboCodes en Blocs, 74
TDSI
Traitement Du Signal et de l’Image, 1
TEB
Taux d’Erreurs binaires, 54
TTL
Transistor-Transistor Logic, 10
UAL
Unité Arithmétique et Logique, 14
UMTS
Universal Mobile Telecommunications System,
1
VLIW
Very Long Instruction Word, 18
VT
Vecteur de Test, 79, 92
WCDMA
Wideband-Code Division Multiple Access, 47
Bibliographie
[AA04]
I. Atluri and T. Arslan. Reconfigurability-power trade-offs in turbo decoder design and
implementation. In IEEE ISVLSI’04, fevrier 2004.
[AC05]
White Paper Altera Corporation. Fpgas for high-performance dsp applications. Technical
report, 2005.
[ALI04]
Rapport d’avancement 2.4 synthèse du développement des blocs ip. Technical report,
RNRT ALIPTA, 2004.
[Alt]
Altera. http ://www.altera.com/products/devices/excalibur/exc-index.html. Technical
report.
[Alt05]
Altera. Hardcopy series handbook, volume 1. Technical report, 2005.
[AM04]
C. Argon and S.W. McLaughlin. An efficient chase decoder for turbo product codes.
IEEE Trans. Comm., 52(6), June 2004.
[AR96]
A. Abnous and J. Rabaey. Ultra low-power specific multimedia processors. In VLSI
Signal Processing IX, 1996.
[Aı̈t98]
O. Aı̈tSab. Turbo codes et codage conjoint source-canal : apllication à la transmission
d’images. PhD thesis, ENST Bretagne, Université de Bretagne Occidentale, 1998.
[Ba97]
F. Balarin and al. Hardware-Software Co-Design for embedded systems - The POLIS
approach. Kluwer Academic, 1997.
[BAAF93]
C. Berrou, P. Adde, E. Angui, and S. Faudeil. A low complexity soft-output viterbi
decoder architecture. In Communications, 1993. ICC 93. Geneva. Technical Program,
Conference Record, IEEE International Conference on, volume 2, pages 737–740vol.2,
23-26 May 1993.
[Bar80]
M.R. Barbacci. The symbolic manipulation of computer descriptions : an introduction to
isps. Technical report, Dpt of Computer Science, Carnegie-Mellon University, Pittsburgh,
March 1980.
[BCJR74]
L. Bahl, J. Cocke, F. Jelinek, and J. Raviv. Optimal decoding of linear codes for minimizing symbol error rate (corresp.). Information Theory, IEEE Transactions on, 20(2) :284–
287, Mar 1974.
164
BIBLIOGRAPHIE
[BCM+ 88] R.K. Brayton, R. Camposano, G.D. Micheli, R. Otten, and J. Van Eijndhoven. The
Yorktown Silicon Compiler System. Number pp. 204–310. 1988.
[BCM97]
F. Balasa, F. Catthoor, and H. De Man. Practical solutions for counting scalars and
dependences in atomium - a memory management system for multi-dimensional signal
processing. In Computer Aided Design, février 1997.
[BDD+ 99]
K. Bondalapati, P.C. Diniz, P. Duncan, J. Granacki, M.W. Hall, R. Jain, and H. Ziegler.
Defacto : A design environment for adaptive computing technology. In IPPS/SPDP,
1999.
[Ber68]
E. R. Berlekamp. Algebraic Coding Theorie. Aegean Park Press, 1968.
[BG96]
C. Berrou and A. Glavieux. Near optimum error correcting coding and decoding : turbocodes. IEEE Trans., 44 :1261 – 1271, 1996.
[Bid]
R. Le Bidan.
Décodage ferme des codes reed-solomon par l’algorithme peterson-
gorenstein-zierler. Juillet 2005.
[Bla03]
R.E. Blahut. Algebraic Codes for data transmission. Cambridge university press, 2003.
[BM78]
L.D. Baumert and R.J. MacEliece. Soft decision decoding of block codes. Technical
report, JetPropulsion Laboratory, California Institute of Technology, Juillet-Aout 1978.
[BMN+ 01] V. Baumgarte, F. May, A. Nükel, M. Vorback, and M. Weinhardt. Pact xpp - a selfreconfigurable data processing architecture. In ERSA, 2001.
[BNH06]
F. Berthelot, F. Nouvel, and D. Houzet. Partial and dynamic reconfiguration of fpgas :
a top down design methodology for an automatic implementation. In IPDPS, 2006.
[Bom04]
P. Bomel. Plate-forme de prototypage rapide fondée sur la synthèse de haut niveau pour
applications de radiocommunications numériques. PhD thesis, Université de Bretagne
Sud, Décembre 2004.
[Bos04]
L. Bossuet. Exploration de l’espace de conception des architectures reconfigurables. PhD
thesis, Université de Bretagne Sud, Décembre 2004.
[BRC60]
R.C. Bose and D.K. Ray-Chaudhuri. On a class of error correcting binary group codes.
Inf. and Control, 3 :68–79, Mars 1960.
[Bur71]
H. Burton. Inversionless decoding of binary bch codes. Information Theory, IEEE Transactions on, 17(4) :464–466, Jul 1971.
[Cad]
Cadence. Vcc user guide. Technical report.
[CAE00]
F. Cuesta, M. Auguin, and E.Gresset. System level communication synthesis for embedded signal processing application. ICSPAT, 2000.
[CAKP02]
J. Cuevas, P. Adde, S. Kerouédan, and R. Pyndiah. New architecture for high data rate
turbo decoding of product codes. In GLOBECOM, pages 139–143, Novembre 2002.
BIBLIOGRAPHIE
[Cam91]
165
R. Camposano. Path-based scheduling for synthesis. In IEEE Trans. Computer-Aided
Design, volume Vol. 10, pages pp..85–93, janvier 1991.
[CC81]
G.C Clark and J.B Cain. Error-Correction Coding for Digital Communications. Plenum
Press, 1981.
[CFF+ 99]
D.C. Cronquist, C. Fisher, M. Figueroa, P. Franklin, and C. Ebeling. Architecture design
of reconfigurable pipelined datapath. In Advanced research in VLSI, 1999.
[CG03]
L. Cai and D. Gajski. Transaction level modeling : An overview. In CODES+ISSS’03,
2003.
[Cha72]
D. Chase. A class of algorithms for decoding block codes with channel measurement
information. IEEE Trans. Inform. Theory, IT-18 :170–182, janvier 1972.
[Chi94]
R.T. Chien. Cyclic decoding procedures for bose-chaudhuri-hocquenghem codes. IEEE
Trans. Inform. Theory, 10 :357–363, Oct. 1994.
[CHR+ 03]
N. Calazans, E. Moreno F. Hessel, V. Rosa, F. Moraes, and E. Carara. From vhdl register
transfer level to systemc transaction level modeling : a comparative case study. SBCCI,
2003.
[Cor05]
G. Corre. Gestion des unités de mémorisation pour la synthèse d’architecture. PhD thesis,
Université de Bretagne Sud, Juin 2005.
[Cou03]
P. Coussy. Synthèse d’interface de communication pour les composants virtuels. PhD
thesis, Université de Bretagne Sud, 2003.
[Cow]
Coware. User guide. Technical report.
[CPIJ94]
J.P. Calvez, 0. Pasquier, D. Isidoro, and D. Jeuland. Codesign with the mcse methodology.
In EUROMICRO System Architecture and Integration, 1994.
[CPTR89]
C.M. Chu, M. Potkonjak, M. Thaler, and J. Rabaey. Hyper : an interactive synthesis
environment for real time application. In International Conference on Computer Design,
pages 432–435, 1989.
[CSKPN00] C. Chaikalis, M. Salimi-Khaligh, N. Panayotopoulos, and J.M. Noras. Reconfiguration
between soft output viterbi and log maximum a posteriori decoding algorithms. 3G Mobile
Communication Technologies, 2000.
[CV03]
J. R. Cavallaro and M. Vaya. Viturbo : A reconfigurable architecture for viterbi and
turbo decoding. In IEEE ICASSP2003, pages 497–500, avril 2003.
[Dav03]
R. David. Architecture reconfigurable dynamiquement pour applications mobiles. PhD
thesis, Université de Rennes 1, 2003.
[DGR04]
J.P. Delahaye, G. Gogniat, and C. Roland. Software radio and dynamic reconfiguration
on a dsp/fpga platform. Frequenz, Journal of Telecommunications, pages 152–159, 2004.
[dic]
Dictionnaire de l’Académie française. 9ème édition.
166
[DPL05]
BIBLIOGRAPHIE
J.P. Delahaye, J. Palicot, and P. Leray. A hierarchical modeling approach in software
defined radio system design. In SIPS, 2005.
[eAS05]
eASIC. Configurable programmable asic. Technical report, 2005.
[EDH04]
S. Evain, J.P. Diguet, and D. Houzet. A generic cad tool for efficient noc design. ISPACS,
2004.
[ele05]
NEC electronic. Structured asic, easy, fast, low-cost. Technical report, 2005.
[Eli54]
P. Elias. Error-free coding. IRE Trans. Inform. Theory, IT-4 :29–37, septembre 1954.
[Ell00]
J.P. Elliott. Understanding High-Level Synthesis. A practical Guide to High-Level Design.
Kluwer Academic Publishers, 2000.
[For]
Forney.
[For66]
G.D. Forney. Concatenated codes. Cambridge M.A., 1966.
[Ga92]
D. Gajski and al. High-Level Synthesis : Introduction to Chip and System Design. Kluwer
Academic Publishers, 1992.
[GABP98]
G. Gogniat, M. Auguin, L. Bianco, and A. Pegatoquet. Communication synthesis and
hw/sw integration for embedded system design. Hardware/Software Codesign (CODES/CASHE ), 1998.
[Gal05]
B. Le Gal. Contribution à la prise en compte des contraintes des applications TDSI. PhD
thesis, Université de Bretagne Sud, LESTER, 2005.
[GBA03]
F. Ghaffari, M. Benjemaa, and M. Auguin. Algorithms for the partitioning of applications
containing variable duration tasks on reconfigurable architectures. Computer Systems and
Application, 2003.
[GGDN04] S. Gupta, R. Gupta, N. Dutt, and A. Nicolau. SPARK : a parallelizing approach to the
hgh-level synthesis of digital circuits. 2004.
[Gil05]
J. Gill. Error-correcting codes. Technical report, Stanford University, 2004-2005.
[Gra04]
Mentor Graphics. Catapult C Synthesis User’s Manual and Reference Manual, 2004.
[Gui03]
A.C. Guillou. Synthèse architecturale basée sur le modèle polyèdrique : validation et
extensions de la méthodologie MMAlpha. PhD thesis, Université de Rennnes I, 2003.
[GVLM92] G. Goosens, P. Vanbekbergen, B. Lin, and H. De Man. A generalized state assignment
theory for transformation on signal transition graphs. In ICCAD, pages pp. 112–117,
novembre 1992.
[GVN94]
D. Gajski, F. Vahid, and S. Narayan. A system-design methodology : executable specifcation refinement. In EUROCAD, 1994.
[GZ61]
D. Gorenstein and N. Zierler. A class of error correcting codes in pm symbols. JSIAM,
9 :207–214, 1961.
BIBLIOGRAPHIE
[Har01]
167
R. Hartenstein. A decade of reconfigurable computing : a visionnary retrospective. DATE,
2001.
[HH94]
J. Hagenauer and P. Hoeher. A viterbi algorithm with soft-decision outputs and its
applications. GLOBECOM, pages 1680–1686, 1994.
[HHM01]
S.A. Hirst, B. Honary, and G. Markarian. Fast chase algorithm with an application in
turbo decoding. IEEE Trans. Comm., 49 :1693–1699, Oct. 2001.
[Hoc59]
A. Hocquengehm. Codes correcteurs d’erreurs. 2 :147–156, 1959.
[HR76]
C.R.P. Hartman and L.D. Rudolph. An optimum symbol-by-symbol decoding rule for
linear codes. IEEE Trans. Inform. Theory, 22 :514–517, Sept. 1976.
[HSKB06]
M. Hübner, C. Schuck, M. Kühnle, and J. Becker. New 2-dimensional partial dynamic
reconfiguration techniques for real-time adaptive microelectonics circuits. In ISVLSI,
Mars 2006.
[htta]
http ://public.itrs.net/. International technology roadmap for semiconductors.
[httb]
http ://www.celoxica.com/.
[httc]
http ://www.synfora.com. Synfora.
[HW97]
J.R. Hauser and J. Wawrzynek. Garp : a mips processor with a reconfigurable coprocessor.
In FCCM, 1997.
[Inc]
CoWare Inc. http ://www.coware.com/.
[Inc06]
Renesas Inc. Mpu and mcu general catalog. Technical report, 2006.
[Ins06]
Texas Instruments. Dsp selection guide. Technical report, 2006.
[Jac96]
S. Jacq. Décodage itératif des codes produits : turbocodes en blocs, et évaluations de leurs
performances pour des modulations MDP et MAQ sur canal de Gauss et de Rayleigh.
PhD thesis, Université de Limoges, 1996.
[JD06]
C. Jégo and J.P. Diguet. Architectures autoconfigurables pour le contrôle dynamique du
compromis qos/snr/débit de turbo décodeurs de code produit. Journées scientifiques du
CNFRS : Vers des radiocommunications reconfigurables et cognitives, mars 2006.
[Jég00]
C. Jégo. Synthèse architecturale d’applications de traitement du signal sous contraintes
temps réel, dédiée aux technologies submicroniques. PhD thesis, Université de Rennes 1,
2000.
[JPS85]
B.W. Jinks, D.L. Pulfrey, and W.S. Snyder. Automated generation of microcontrollers.
In ICCAD, page pp.335, 1985.
[KAP01]
S. Kerouedan, P. Adde, and R. Pyndiah. How we implemented block turbo codes. In
Annals of Telecommunication, volume Vol. 56, pages 447–454. Juillet-Août 2001.
[Kna96]
D.W. Knapp. Behavioral Synthesis. Digital Systems using the Synopsys Behavioral Compiler. Prenctice Hall, 1996.
168
[Kri05]
BIBLIOGRAPHIE
I. Krikidis. Approche multicouches pour la reconfigurabilité de systèmes de communications de 3ème génération. PhD thesis, Télécom Paris, 2005.
[La97]
G. Lakshminarayana and al. Wavesched : A novel scheduling technique for control-flow
intensive behavioral descriptions. In ICCAD, pages pp.245–251, novembre 1997.
[LJSM04]
J. Laurent, N. Julien, E. Senn, and E. Martin. Softexplorer functional level power analysis : an efficient approach for modeling the power consumption of complex processors. In
Design, Automation and Test in Europe Conference and Exhibition, volume 1, pages 666
– 667, Fevrier 2004.
[LMW95]
Y. S. Li, S. Malik, and A. Wolfe. Performance estimation of embedded software with
instruction cache modeling. ICCAD, pages 380–387, 1995.
[LSB85]
L. Loeffler, R. Schmid, and U.G. Baitinger. Processor control part synthesis yields short
turnaround times by higl level description. In ICCAD, page pp. 266, 1985.
[LSL+ 99]
G. Lu, H. Singh, M.H. Lee, N. Bagherzadeh, F. Kurdahi, and E. Filho. Tne morphosys
parallel reconfigurable system. In European Conference on Parallel Processing, 1999.
[LST00]
J. Liang, S. Swaminathan, and R. Tessier. Asoc : a scalable single chip communications
architecture. In PACT, 2000.
[LTG04]
J. Liang, R. Tessier, and D. Goeckel. A dynamically reconfigurable, power-efficient turbo
decoder. In IEEE Symposium on Field-Programmable Custom Computing Machines, avril
2004.
[LXL01]
X. Liu, Y. Xiong, and E.A. Lee. The ptolemy ii framework for visual languages. In
Human-Centric Computing Languages and Environments, pages 50–51, Sept. 2001.
[Mas]
Massey.
[Mas65]
J.L. Massey. Step-by-step decoding of the decoding bch codes. IEEE Trans. Inform
Theory, IT-11 :580–585, Oct. 1965.
[MBG+ 05] J. MENARD, D. BOURREAU, G. GRATON, C. LANGLAIS, E. DANIEL Emmanuel,
and Y. LE ROUX. Palmyre serial transmission system for radio channels. 51ème Conférence Européenne Propagation et Systèmes, 2005.
[McE03]
R. McEliece. The guruswami-sudan decoding algorithm for reed-solomon codes. 2003.
[MDP02]
Y. Le Moullec, J.P. Diguet, and J.L. Philippe. Design trotter : a multimedia embedded systems design space exploration tool. In IEEE Workshop on Multimedia Signal
Processing, 2002.
[Mit]
J. Mitola. The software radio architecture. IEEE Comms. Mag, 41 :1995.
[MJ03]
H.De Man and J.Rabaey. The Best of ICCAD, 20 Years of Excellence in Computer-Aided
Design, chapter System Design and Analysis Overview, pages 93–106. Kluwer Academic,
2003.
BIBLIOGRAPHIE
[MJJ+ 88]
H.De Man, J.Rabaey, J.Vanhoof, G.Goossens, P.Six, and L.Claesen.
169
Cathedral-ii-a
computer-aided synthesis system for digital signal processing vlsi systems. ComputerAided Engineering Journal, 5 :55–66, 1988.
[MM04]
S. Murali and G. De Micheli. Sunmap : a tool for automatic topology selection and
generation for nocs. DAC, 2004.
[MP96]
E. Martin and J.L. Philippe. Ingénierie des systèmes à microprocesseurs : Application
au traitement de signal. Masson, 1996.
[MRSC86]
H. De Man, J. Rabaey, P. Six, and L. Claesen. Cathedral-ii : A silicon compiler for digital
signal processing. In Design and Test, decembre 1986.
[MS78]
F.J. MacWilliams and N.J.A. Sloane. The Theory of error correcting codes. North Holland
Publishing Company, 1978.
[NM05]
F. Nouvel and A. Massiany. Conception de modems mono-porteuse et mccdma à 5,4ghz
sur une plate-forme unique de prototypage numérique et analogique. TAISA, 2005.
[Not04]
Application Note. Two flows for partial reconfiguration : Module based or difference
based. Technical report, Xilinx, 2004.
[Pa82]
R. Piloty and al. The conlan project : Status and future plans. In Design Automation
Conference, page pp. 202, June 1982.
[PCLSJ06] J. Perez-Chamorro, C. Lahuec, F. Seguin, and M. Jézéquel. Designing subthreshold
mosfet analog decoders. In Analog decoding Workshop, June 2006.
[PEG99]
A. Pegatoquet and M. Auguin et L. Bianco E. Gresset. Rapid development of optimized dsp code from a high level description through software estimations. In Design
Automation Conference, pages pp. 823–826, June 1999.
[Pet60]
W. W. Peterson. Encoding and error correcting procedures for the bose-chaudhuri codes.
IRE Transf. Theory, IT-6 :459–470, septembre 1960.
[PGPJ94]
R. Pyndiah, A. Glavieux, A. Picart, and S. Jacq. Near optimum decoding of product
codes. In GLOBECOM94, novembre 1994.
[PJA+ 06]
E. Piriou, C. Jego, P. Adde, R. Le Bidan, and M. Jezequel. Efficient architecture for reed
solomon block turbo code. ISCAS, pages 3682–3685, Mai 2006.
[PJAJ04]
E. Piriou, C. Jego, P. Adde, and M. Jezequel. System level design using systemc : a case
study of block turbo decoder. DCIS, 2004.
[PJAJ05]
E. Piriou, C. Jego, P. Adde, and M. Jezequel. Utilisation d’un environnement de conception reposant sur le langage systemc pour l’intégration d’un turbo décodeur de code
produit. JFAAA05, Journées francophones sur l’adéquation Algorithme Architecture,
2005.
170
[PJAJ06a]
BIBLIOGRAPHIE
E. Piriou, C. Jego, P. Adde, and M. Jezequel. Design, implementation and prototyping of
a flexible architecture dedicated to block turbo decoding. Reconfigurable Communicationcentric SoCs, 2006.
[PJAJ06b] E. Piriou, C. Jego, P. Adde, and M. Jezequel. A flexible architecture for block turbo
decoders using bch or reed-solomon components codes. ISVLSI, Mars 2006.
[PMS93]
J.L. Philippe, E. Martin, and O. Sentieys. Gaut, an architecture synthesis tool for dedicated signal processors. In IEEE European Design Automation Conference, 1993.
[POJ93]
I. Park, K. O’Brien, and A.A. Jerraya. Amical : architectural synthesis based on vhdl.
In IFIP - Transactions on computer science and technology, 1993.
[PRR+ 03]
A. Polydoros, J. Rautio, G. Razzano, H. Bogucka, D. Ragazzi, P.I. Dallas, A. Mämmelä,
M. Benedix, M. Lobeira, and L. Aragossi. Wind-flex : Developing a novel testbed for
exploring flexible radio concepts in an indoor environment. IEEE Comms. Mag, 2003.
[PTS+ 79]
A.C. Parker, D.E. Thomas, D.P. Siewiorek, M. Barbacci, L. Hafer, G. Leive, and J. Kim.
The cmu design automation system : An example of automated data path design. In
Design Automation Conference, June 1979.
[Pyn98]
R. Pyndiah. Near optimum decoding of product codes : Block turbo codes. IEEE Trans.
Inform. Theory, 46 :1003–1010, 1998.
[Rao97]
O. Raoul. Conception et performances d’un circuit intégré turbo décodeur de codes produits. PhD thesis, ENST Bretagne, Université de Bretagne Occidentale, 1997.
[RDM+ 06] Y. LE ROUX, P. LASSUDRIE DUCHESNE, J. MENARD, D. BOURREAU, E. DANIEL
Emmanuel, and G. LANDRAC. Palmyre : a mimo reconfigurable transmission platform
for its applications. 6th International Conference on ITS Telecommunications, 2006.
[RDV+ 05]
Y. LE ROUX, P. LASSUDRIE DUCHESNE, R. VAUZELLE, Y. CHARTOIS, G. EL
ZEIN, and C. BROUSSEAU. Propagation and system modeling for the palmyre mimo
platform. 51ème Conférence Européenne Propagation et Systèmes, 2005.
[RLP05]
A. La Rosa, L. Lavagno, and C. Passerone. Implementation of a umts turbo decoder on
a dynamically reconfigurable platform. In Computer-Aided Design of Integrated Circuits
and Systems, volume 24. IEEE Transactions on, janvier 2005.
[RR72]
S.M. Reddy and J.P. Robinson. Random error and burst correction by iterated codes.
IEEE Trans. Inform. Theory, 18 :182–185, 1972.
[RVH95]
P. Robertson, E. Villebrun, and P. Hoeher. A comparison of optimal and sub-optimal
map decoding algorithms operating in the log domain. ICC, pages 1009–1013, 1995.
[SB]
T. Stöcklein and J. Bäsig. Handel-c : An effective method for designing fpgas (and asics).
Technical report.
[SCGT01]
G. Sassatelli, G. Cambon, J.J. Galy, and L. Torres. A dynamically reconfigurable architecture for embedded systems. In Rapid System Prototyping, 2001.
BIBLIOGRAPHIE
171
[Sem05]
AMI Semiconductor. Xpressarray-ii 0.15mm structured asic. Technical report, 2005.
[Sem06]
Freescale Semiconductor. Digital signal processors and controllers. Technical report,
2006.
[Soc05]
R Language Reference Manual. 1666IEEE Computer Society. IEEE Standard SystemC
2005.pdf, 2005.
[Sof04]
TNI Software. Cosimate product overview : Cosimate, an innovative software solution
for mechatronics network co-simulations. Technical report, 2004.
[SS94]
M. Srinivasan and D.V. Sarwate. Malfunction in the peterson-gorenstein-zierler decoder.
IEEE Trans. Inform .Theory, 40 :1649–1653, Sept. 1994.
[Syn]
Synopsys. Systemc - early hardware/software integration using systemc 2.0. Technical
report.
[Syn01]
Synopsys. Describing Synthesizable Behavioral SystemC, Aout 2001.
[Syn02]
Synopsys. Describing Synthetizable RTL in SystemC, novembre 2002. version 1.2.
[TAJ00]
X. Tang, M. Aalsma, and R. Jou. A compiler directed approach to hiding configuration
latency in chamaleon processors. In FPL, 2000.
[Vit67]
A.J. Viterbi. Error bounds for convolutionnal codes and an asymptotically optimum
decoding algorithm. IEEE Trans. Inform. Theory, 13 :260–269, 1967.
[WB04]
J. Williams and N. Bergmann. Embedded linux as a platform for dynamically selfreconfiguring systems-on-chip. ERSA, 2004.
[Wel71]
E.J. Weldon. Decoding binary blocks codes on q-ary output channels. IEEE Trans.
Inform. Theory, 17 :713–718, Nov. 1971.
[WHW01]
S.F. Wang, H.Hsu, and A. Wu. A very low-cost multi-mode reed solomon decoder based
on peterson-gorenstein-ziekler algorithm. Signal Processing Systems, pages 37–48, Sept.
2001.
[WT04]
K.C. Wu and Y.W. Tsai. Structured asic, evolution or revolution ? In ISPD, April 2004.
[Xil05]
Hitesh Patel Xilinx. Synthesis and implementation strategies to accelerate design performance. Technical report, 2005.
[Zho05]
R. Zhou. Etude des turbo codes en blocs Reed-Solomon et leurs applications. PhD thesis,
ENST Bretagne, Université de Rennes 1, 2005.
[Zim79]
G. Zimmermann. The mimola design system : A computer aided digital processor design
method. In Design Automation Conference, pages pp. 53–58, 1979.
Apport de la modélisation et de la synthèse haut niveau dans la conception
d’architecture flexible dédiée aux turbocodes en blocs
Cette thèse s’inscrit dans la continuité des travaux menés au sein du département électronique de l’ENST-Bretagne sur l’implantation des turbo-décodeurs de codes produits. Le premier axe de recherche de l’étude concerne l’implantation d’une architecture
flexible d’un turbo-décodeur. Le second axe s’intéresse à l’évolution des flots de conception, des langages de description et de
leurs applications. L’ensemble est validé par la mise en oeuvre d’un prototype.
L’architecture que nous proposons se compose à la fois d’une partie matérielle réalisant la fonction de décodage et d’une
partie logicielle remplissant le rôle de contrôleur. Une étude de complexité en amont a permis de caractériser les paramètres de
l’application. L’innovation de notre architecture repose sur le caractère flexible permettant de choisir le code composant (BCH
ou Reed Solomon) et le pouvoir de correction pour des longueurs de code variables. Il est à noter qu’il s’agit de la première
intégration d’un turbo-décodeur à base de code Reed Solomon. Ce travail a en particulier bénéficié de l’expertise algorithmique
de l’ENST Bretagne sur les turbocodes.
Dans le cadre de cette thèse, un flot de conception dit de haut niveau a été expérimenté. Dans un premier temps, le
développement de la chaı̂ne de transmission numérique a été effectué à l’aide du langage système de description SystemC sous
l’environnement System Studio de Synopsys. Puis, les synthèses logiques avec l’outil SystemC Compiler de Synopsys ont permis
d’obtenir des descriptions au niveau netlist. De plus, des synthèses de haut niveau ont ensuite été effectuées à travers l’utilisation
d’outils tels que GAUT et Agility Compiler. Elles ont été menées sur les différents éléments de l’architecture afin d’évaluer les
apports de cette approche.
Le prototypage de l’architecture novatrice a été effectué sur un FPGA Altera Stratix sur une carte de développement
NIOS II. En effet, au début de ces travaux, en 2003, la société Altera proposait des solutions matures par rapport à celles du
concurrent Xilinx pour les processeurs soft embarqués, c’est ce qui a principalement motivé notre choix. Ce travail s’inscrit
donc dans une forte évolution des cibles matérielles et des outils durant ces trois dernières années. Sur notre plate-forme, un
processeur logiciel NIOS II sert de structure de contrôle et est relié à la partie matérielle de décodage via un bus système dédié
de type Avalon. Le processus de turbo décodage met en oeuvre des codes BCH(32,26) (resp. (32,21)) et des codes Reed Solomon
(31,29) (resp. (31,27)) d’un pouvoir de correction t=1 (resp. t=2).
Les applications potentielles, pouvant bénéficier de cette architecture flexible, sont nombreuses notamment dans le
domaine des télécommunications mobiles, des transmissions optiques, du stockage en masse ou du xDSL.
Contribution of high level design and synthesis to develop a flexible architecture
dedicated to block turbo codes
This thesis’ work continues previous research undertaken at the electronics department of the ENST-Bretagne on the implementation of a turbo decoding architecture for product codes. The first research area studies the implementation of a flexible
turbo decoding architecture. The second concerns the evolution of design flow, description languages and their applications.
The results are validated by prototyping a platform.
The proposed architecture includes two main design blocks. The first is a hardware module performing the decoding
process. The second is a software based control unit. A study of system complexity was carried out to identify the various
parameters of the application. The innovative aspect of our architecture is the flexibility in the choice of a component code
(BCH or Reed Solomon) and its error correcting power. This is the first architecture known to date implementing Reed-Solomon
block turbo codes. This work benefited from the knowledge of ENST Bretagne on turbocodes.
Within the context of this thesis, a high level design flow was used, and the method was divided into two steps. First, a
digital communication chain was developped with the help of the SystemC description language and System Studio design tool.
Then, netlist descriptions were obtained by performing logic synthesis with SystemC compiler tool from Synopsys. The usage
of a high level synthesis on sub-modules of the architecture allows us to quantify the benefits of this approach.
The architecture was mapped to an Altera Stratix FPGA on a NIOS II development board. In fact, our choice of solutions
from Altera was motivated by the fact that at the beginning of this work, Altera offered the best solution concerning software
processors when compared to Xilinx. In our design, the control task is achieved by the NIOS II embedded processor. An avalon
system bus binds the hardware decoding part and the processor. The turbo decoding process concerns BCH(32,26) (resp.
(32,21)) and Reed Solomon (31,29) (resp. (31,27)) codes with t=1 (resp. t=2) as error correcting power.
Many potential applications such as mobile communications, optical transmission, data storage and xDSL can benefit from
flexible architectures dedicated to block turbo codes.

Apport de la modélisation et de la synthèse haut niveau dans la

Transcription

Documents pareils

BANQUE CONGOLAISE DE L`HABITAT (BCH) Code

BG-Turbo Turbo Seat Ibiza FR 130

BG-Turbo Turbo Renault Mégane DTI

BG-Turbo Turbo Chrysler Voyager 2,5D

MP4, H264, AVC, HEVC, AVCHD, c`est quoi ce

Asservissement de vitesse d`un moteur à courant continu

Diapositive 1

SEMAINE 2 - SERIE 2 OPERATEURS DIFFERENTIELS CORRIGES

DP13MI10 : Boitier relais tarifaire TEMPO Application : Le

télécharger - L`Etudiant