Rapport PFE

Ecole Polytechnique de Tunisie
Rapport de Projet de n d'études

Option: Signaux et Systèmes (SISY)
Conception et implémentation d'une

architecture recongurable pour le
codage canal
Du février à aout, 2008
Organisme d'accueil: Département Communication et Electronqique ENST-Paris

Laboratoire System On Chip (LabSoc Eurécom)
Elève ingénieur: Tarek GARA
Encadreur: Renaud PACALET
Année universitaire: 2007-2008

12 juin 2008
Remerciment
Au terme de ce travail de n d'étude, je tiens à éxprimer toute ma gratitude
à mon encadreur, monsieur Renaud Pacalet responsable du laboratoire System on
Chip de l'ENST à Eurécom.
J'adresse un remerciment tout particulier à monsieur Adel Benzina pour ses
conseils et sa disponibilité.
Un grand merci aux membres du laboratoire LabSoc et en particulier à Carina
et Daniel.
1
Résumé
Si beaucoups d'architectures existent pour le codage canal, la plupart d'entre
elles visent une norme particulière et diérent d'un standard à un autre. Nous
présentons dans ce travail une architecture capable de fonctionner dans n'importe
quel standard de communication sans l comme le 3GPP UMTS, WLAN 802.11a,
WIMAX 802.16 etc. Cette architecture englobe à la fois ; un codeur convolutif, un
codeur cyclique et générateur de m-séquences pour l'étalement des spectres dans la
technologie WCDMA. Notre implémentation se caractérise essentiellement par sa
exibilté ; elle est capable de s'adapter au standard choisit grace aux découpages
et découplages de ses diérents éléments.
Abstract
The nal year project aims at studying and implementing a recongurable
channel encoder. Despite the diversity of channel coding architectures, most of
them aim at a particular standard and dier from the other. In this work, we
present an architecture which is capable of working in any standard of wireless
communication such as 3GPP UMTS, WLAN 802.11a, WIMAX 802.16 etc. The
architecture developed consists of a convolutional encoder, a cyclic encoder and a
linear feed back shift registre (LFSR) for the spreading spectrum in the WCDMA
technology. The main feature of our implementation is its exibility : it is capable
of adapting itself to the chosen standard due to the divisions and the decoupling
of its various elements.
2
Table des matières
1 Introduction générale 9
2 Les codes correcteurs d'erreurs 12
2.1 Les codes cycliques . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.1 Les codes en blocs linéaires . . . . . . . . . . . . . . . . . . 13
2.1.2 Dénition et représentation des codes cycliques . . . . . . . 14
2.1.3 Dénition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.4 Code cyclique sous forme systématique . . . . . . . . . . . . 16
2.1.5 Mise en oeuvre du codeur . . . . . . . . . . . . . . . . . . . 16
2.2 Les codes convolutifs . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.1 Principe du codage convolutif . . . . . . . . . . . . . . . . . 17
2.2.2 Polynôme générateur d'un code convolutif . . . . . . . . . . 18
2.2.3 Représentations graphiques des codes convolutifs . . . . . . 18
2.2.4 Choix de l'architecture du codeur . . . . . . . . . . . . . . . 22
2.3 Génération de M-séquences(LFSR) . . . . . . . . . . . . . . . . . . 23
2.3.1 Représentation de Fibonnacci . . . . . . . . . . . . . . . . . 24
2.3.2 Représentation de Galois . . . . . . . . . . . . . . . . . . . . 24
2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3 Architecture recongurable pour le Codage canal 26

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2 Architecture générique . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.1 Architecture du premier bloc . . . . . . . . . . . . . . . . . . 28
3.2.2 Architecture du deuxième, troisième et quatrième bloc . . . 28
3.3 Codage convolutif . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.1 Mise en oeuvre du codeur convolutif . . . . . . . . . . . . . 30
3.4 Codage cyclique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4.1 Mise en oeuvre du codeur cyclique . . . . . . . . . . . . . . 32
3.4.2 les trois modes de fonctionnement du codeur cyclique . . . . 34
3.5 Générateur de m-séquences . . . . . . . . . . . . . . . . . . . . . . . 42
3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3
4 Implémentation hardware 43
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2 Modélisation en VHDL . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3 Flux de conception hardware . . . . . . . . . . . . . . . . . . . . . . 44
4.4 Composant top_coder . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.4.1 Eléments du top_coder . . . . . . . . . . . . . . . . . . . . 45
4.4.2 Signaux de commandes et d'entrée/ sortie du top_coder . . 46
4.5 Composant Preprocess . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.5.1 les entées/sorties de Preprocess . . . . . . . . . . . . . . . . 47
4.5.2 Principe de fonctionnement du Preprocess . . . . . . . . . . 47
4.6 Composant Bloc_coder . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.6.1 Signaux de commandes et d'entrée/sortie du Bloc_coder . . 48
4.7 Composant logic_control . . . . . . . . . . . . . . . . . . . . . . . . 50
4.7.1 Signaux d'entrée/sortie du logic_control . . . . . . . . . . . 50
4.7.2 Eléments du logic_control . . . . . . . . . . . . . . . . . . . 51
4.8 Composant FSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.8.1 Les entrées/sorties de l'FSM . . . . . . . . . . . . . . . . . . 54
4.8.2 Éléments de l'FSM . . . . . . . . . . . . . . . . . . . . . . . 54
4.9 Composant regs_sup_64 . . . . . . . . . . . . . . . . . . . . . . . . 60
4.9.1 Les entrées/sorties du regs_sup_64 . . . . . . . . . . . . . . 60
4.9.2 Éléments de regs_sup_64 . . . . . . . . . . . . . . . . . . . 61
4.10 W_ram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.11 Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.11.1 Codeur cyclique . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.11.2 codeur convolutif . . . . . . . . . . . . . . . . . . . . . . . . 65
4.11.3 générateur de m-séquences . . . . . . . . . . . . . . . . . . . 67
4.12 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5 Conclusion 69
Annexes 70
A le projet Idromel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
A.1 Résumé du projet . . . . . . . . . . . . . . . . . . . . . . . . 70
A.2 Architecture matérielle d'IDROMEL . . . . . . . . . . . . . 71
A.3 Réalisations . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
A.4 Gestion du handover vertical . . . . . . . . . . . . . . . . . . 72
A.5 Caractéristiques . . . . . . . . . . . . . . . . . . . . . . . . . 73
B Technologie FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
B.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
B.2 Eléments constituant un FPGA . . . . . . . . . . . . . . . . 74
B.3 Programmation des FPGA . . . . . . . . . . . . . . . . . . . 76
4
C Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
C.1 Logic_control . . . . . . . . . . . . . . . . . . . . . . . . . . 78
C.2 FSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
C.3 Regs_sup_64 . . . . . . . . . . . . . . . . . . . . . . . . . . 81
D Diagrammes d'activité . . . . . . . . . . . . . . . . . . . . . . . . . 83
Glossaire 85
Bibliographie 86
5
Table des gures
2.1 Canal de transmission pour la théorie du codage . . . . . . . . . . . 13
2.2 Schéma de principe d'un circuit diviseur par g(x) . . . . . . . . . . 17
2.3 Schéma de principe d'un codeur cyclique . . . . . . . . . . . . . . . 17
2.4 Principe d'un codeur convolutif . . . . . . . . . . . . . . . . . . . . 18
2.5 Codeur convolutif (7,5) . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6 Représentation en arbre du code C(7,5) . . . . . . . . . . . . . . . . 19
2.7 Diagramme d'états du codeur convolutif(7,5) . . . . . . . . . . . . . 20
2.8 Diagramme en treillis du codeur convolutif(7,5) . . . . . . . . . . . 21
2.9 Schéma de principe de la forme canonique de control convolutive . . 22
2.10 Schéma de principe de la forme canonique observatrice convolutive . 23
2.11 Schéma d'un LFSR dans la représentation de Fibonnacci . . . . . . 24
2.12 Schéma d'un LFSR dans la représentation de Galois . . . . . . . . . 24
3.1 forme générique du codeur . . . . . . . . . . . . . . . . . . . . . . . 27

3.2 Les quatre blocs en cascade . . . . . . . . . . . . . . . . . . . . . . 27
3.3 architecture du premier bloc . . . . . . . . . . . . . . . . . . . . . . 28
3.4 Architecture du deuxième, troisième et quatrième bloc . . . . . . . 29
3.5 Forme générique du codeur convolutif . . . . . . . . . . . . . . . . . 30
3.6 Forme générique du codeur cyclique . . . . . . . . . . . . . . . . . . 32
3.7 Architecture du codeur dans le premier mode . . . . . . . . . . . . 34
3.8 Nouvelle architecture du premier bloc . . . . . . . . . . . . . . . . 35
3.9 Nouvelle architecture du deuxième, troisième et quatrième bloc . . . 36
3.10 Architecture du bloc codeur dans le deuxième mode . . . . . . . . . 36
3.11 Le codeur devisé en deux blocs . . . . . . . . . . . . . . . . . . . . 37
3.12 Première sous-étape du codage . . . . . . . . . . . . . . . . . . . . . 37
3.13 Deuxième sous-étape du codage . . . . . . . . . . . . . . . . . . . . 37
3.16 Début du codage(4,94) . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.17 Le codeur devisé en trois blocs . . . . . . . . . . . . . . . . . . . . . 39
6
3.20 Troisième sous-étape du codage . . . . . . . . . . . . . . . . . . . . 40
3.22 Début du codage(4,144) . . . . . . . . . . . . . . . . . . . . . . . . 41
4.1 Etapes d'implémentation d'un circuit logique sur FPGA . . . . . . 44

4.2 Shéma de l'architecture globale . . . . . . . . . . . . . . . . . . . . 45
4.3 Diagramme d'activité du Preprocess . . . . . . . . . . . . . . . . . . 48
4.4 Architecture du bloc_coder . . . . . . . . . . . . . . . . . . . . . . 49
4.5 Architecture du logic_control . . . . . . . . . . . . . . . . . . . . . 50
4.6 Diagramme d'activité du premier processus du logic_control . . . . 51
4.7 Diagramme d'activité du deuxième processus du logic_control . . . 52
4.8 Diagramme d'activité du troisième processus du logic_control . . . 53
4.9 Diagramme d'activité du quatrième processus du logic_control . . . 53
4.10 Architecture de l'FSM . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.11 Machine d'états nis du bloc FSM . . . . . . . . . . . . . . . . . . . 55
4.12 Diagramme d'activité de l'état First_step . . . . . . . . . . . . . . 56
4.13 Diagramme d'activité de l'état Second_step . . . . . . . . . . . . . 56
4.14 Diagramme d'activité de l'état Convolutif . . . . . . . . . . . . . . 57
4.15 Diagramme d'activité de l'état First_step_LFSR . . . . . . . . . . 57
4.16 Diagramme d'activité de l'état Second_step_LFSR . . . . . . . . . 58
4.17 Diagramme d'activité du Proc_reg . . . . . . . . . . . . . . . . . . 59
4.18 Architecture du regs-sup-64 . . . . . . . . . . . . . . . . . . . . . . 60
4.19 Diagramme d'activité du premier processus du regs_sup_64 . . . . 61
4.20 Diagramme d'activité du deuxième processus du regs_sup_64 . . . 62
4.21 Diagramme d'activité du troisième processus du regs_sup_64 . . . 63
4.22 Architecture interne de W_ram . . . . . . . . . . . . . . . . . . . . 63
4.23 Chronogramme du mode READ_FIRST . . . . . . . . . . . . . . . 64
4.24 Simulation avec Modelsim de CRC(7,4) . . . . . . . . . . . . . . . . 65
4.25 Simulation avec Modelsim de C(1,2,3) . . . . . . . . . . . . . . . . . 65
4.26 codeur convolutif C(1,2,3) . . . . . . . . . . . . . . . . . . . . . . . 66
4.27 Simulation avec Modelsim d'un générateur de m-séquences(m=3) . 67
4.28 Générateur de m-séquences(m=3) . . . . . . . . . . . . . . . . . . . 67
5.1 Architecture matérielle d'IDROMEL . . . . . . . . . . . . . . . . . 71

5.2 Gestion du handover vertical . . . . . . . . . . . . . . . . . . . . . . 73
5.3 Caractéristiques du matériel . . . . . . . . . . . . . . . . . . . . . . 73
5.4 Vue générale d'une slice . . . . . . . . . . . . . . . . . . . . . . . . 74
5.5 Détails de la partie supérieure d'une slice . . . . . . . . . . . . . . . 75
5.6 Congurable Logic Block . . . . . . . . . . . . . . . . . . . . . . . . 76
5.7 Programmation d'un FPGA . . . . . . . . . . . . . . . . . . . . . . 77
5.8 Fonctionnement du logic_control dans CRC(100,10) . . . . . . . . . 78
7
5.9 Fonctionnement du logic_control dans CRC(150,10) . . . . . . . . . 78
5.10 Fonctionnement du logic_control dans Convolutif(13,10,3) . . . . . 79
5.11 Fonctionnement du FSM dans CRC(100,10) . . . . . . . . . . . . . 79
5.12 Fonctionnement du FSM dans CRC(150,10) . . . . . . . . . . . . . 80
5.13 Fonctionnement du FSM dans Convolutif(13,10,3) . . . . . . . . . . 81
5.14 Fonctionnement du Regs_sup_64 dans CRC(100,10) . . . . . . . . 81
5.15 Fonctionnement du Regs_sup_64 dans CRC(150,10) . . . . . . . . 82
5.16 Fonctionnement du Regs_sup_64 dans Convolutif(13,10,3) . . . . . 82
5.17 Diagramme d'activité séquentiel . . . . . . . . . . . . . . . . . . . . 83
5.18 architecture séquentielle . . . . . . . . . . . . . . . . . . . . . . . . 83
5.19 Diagramme d'activité combinatoire . . . . . . . . . . . . . . . . . . 84
5.20 architecture combinatoire . . . . . . . . . . . . . . . . . . . . . . . . 84
8
Chapitre 1
Introduction générale
Motivation
Les diérents types de demandes et d'applications dans le domaine de com-
munication sans l ont contribué à une diversité de normes et de standards. Les
technologies d'accès et les protocoles varient énormément d'un réseau à un autre.
Cette diversité provoque le besoin d'une conception globale d'un système qui peut
traiter la plupart des dispositifs de communication existants. La solution doit avoir
une architecture matérielle exible et recongurable qui couvrira les structures
existantes pour chaque standard.
Dans le cadre d'introduire la reconguration au sein de systèmes sur silicium

(SOC), diérents solutions ont été imaginées. Ceux-ci peuvent être classés en trois
catégories. La première et la plus exible est l'utilisation de processeurs embar-
qués (ARM, Tensilica, ) qui sont adaptés à des applications orientées contrôle mais
dont le surcoût en contrôle est prohibitif d'un point de vue énergétique. La seconde
catégorie est celle constituée par les diérentes familles de FPGA à grain n (Al-
tera, Xilinx, Lattice, Atmel). Ce type de composant est particulièrement ecace
du point de vue des performances pour l'implantation de fonctions travaillant au
niveau bit (machines d'états, cryptage, ), par contre le contrôle de reconguration
(mémoire, routage) induit une consommation, notamment statique, importante.
Enn, la troisième catégorie est celle des architectures congurables dites à gros
grain disposant d'un degré de reconguration au niveau mot. Les architectures
telles que XPP de PACT [1], Moustique [2], DRP de NEC disposent de chemins
de données et d'unités de traitements congurables adaptées au traitement du si-
gnal. An de disposer d'un compromis entre ces diérentes caractéristiques, des
architectures hétérogènes ont été conçues notamment par des fabricants de FPGAs
tels que Xilinx [3] et Altera [4] qui proposent diérentes familles de circuits inté-
grant plus ou moins de blocs spécialisés (DSP, mémoire, transceiver, processeurs).
9
Traditionnellement l'architecture de systèmes embarqués est décidée à l'aide de
techniques de co-conception logicielle/matérielle utilisées notamment pour déter-
miner le meilleur compromis entre performances, surface et consommation. Cette
approche se traduit par une surestimation importante des ressources lorsque les
applications traitées possèdent une charge qui varie sensiblement en fonction des
données et de l'environnement du système. Une alternative à cet écueil est la re-
conguration dynamique qui permet de modier une architecture en fonction des
besoins de l'application. L'architecture de FPGA Virtex V [6]de Xilinx a rendu
accessible les techniques et outils permettant de mettre en oeuvre la recongura-
tion dynamique.
C'est dans ce cadre que le projet Idromel [7] a été lancé pour répondre au besoin
de mettre en place un système recongurable et exible englobant les diérents
standards pour la communication sans l. Les réalisations concrètes du projet
IDROMel seront à la fois matérielles et logicielles. Le projet vise en particulier à
réaliser :
une carte Radio Fréquence capable de fonctionner dans au moins deux bandes
de fréquences très diérentes (les bandes 2 GHz et 5 GHz sont pressenties).
En outre cette carte sera équipée de deux chaînes de transmission et de ré-
ception, qui pourront être utilisées soit pour communiquer dans un standard
(en utilisant des techniques MIMO, Multiple Inputs Multiple Outputs), soit
pour pouvoir communiquer en utilisant deux standards diérents
une interface numérique/analogique et une partie bande de base intégrée
dans une architecture de type système sur puce (SoC).
Objectif
L'objectif de ce stage est d'élaborer un IP d'un codeur canal recongurable
pour le projet Idromel englobant à la fois le codage cyclique, le codage convolutif
et un générateur de m-séquences. Cet IP doit être conçu d'une manière à garantir
un ensemble de propriétés :
Généricité : les diérents éléments du codeur doivent être susamment géné-

riques pour que chaque standard puisse les utiliser.
Modularité : les diérents éléments du codeur doivent être susamment bien

découpés et découplés pour que, si une technologie ou application le souhaite, elle
puisse utiliser seulement certains de ces éléments.
10
Adaptabilité : les diérents éléments du codeur doivent pouvoir être adaptés
de manière à assurer leurs fonctionnalités selon la technologie souhaitée.
Ecacité : les environnements mobiles étant fortement contraints par le maté-

riel, l'introduction de la généricité, de la modularité et de l'adaptabilité ne doit
pas se faire au détriment de l'ecacité du temps d'exécution de l'application du
codage ainsi que la consommation énergétique.
Organisation du document
Dans le deuxième chapitre nous aborderons les notions théoriques de chaque
modèle du codage convolutif, cyclique ainsi que le générateur des m-séquences.
Dans le troisième chapitre nous proposerons une architecture uniée et nous ex-
pliquerons les adaptations nécessaires au fonctionnement de ces trois systèmes.
Dans le quatrième chapitre nous détaillerons l'implémentation hardware de notre
modèle recongurable et nous exposerons quelques simulations réalisées.
11
Chapitre 2
Les codes correcteurs d'erreurs
L'opération du codage consiste à ajouter au message numérique à transmettre
des éléments binaires, dits de redondance suivant une loi donnée. La nécessité d'in-
troduire de la redondance dans le message, pour se protéger contre les erreurs de
transmission, est démontrée par la théorie de l'information. Intuitivement, on peut
concevoir que pour un message dépourvu de redondance, chaque élément binaire
est essentiel et ainsi toute erreur de transmission conduit à une perte d'informa-
tion irréversible. Au contraire des éléments de redondance introduits astucieuse-
ment vont corréler les éléments binaires du message codé. Ainsi, sous certaines
conditions, un ou plusieurs éléments binaires erronés au cours de la transmission
pourront être détectés, voire corrigés. Le décodeur vient donc tester si la loi de co-
dage utilisée à l'émission (codeur) est respectée en réception ; si c'est le cas, aucune
erreur n'est détectée, tandis que dans le cas contraire, des erreurs sont présentes
dans le message codé. Les codes peuvent être classés en deux grandes familles : les
codes en blocs d'une part, les codes convolutifs ou récurrents d'autre part. Avant
d'aborder la présentation des codes, nous allons d'abord préciser la notion de canal
de transmission qui n'a pas exactement le même sens en théorie du codage qu'en
théorie des communications.
Canal de transmission
En théorie du codage, le canal de transmission inclut toutes les fonctions si-
tuées entre la sortie du codeur et l'entrée du décodeur, soit : l'émetteur, le milieu
de transmission, le bruit et le récepteur 2.1. En considérant des messages numé-
riques codés constitués d'éléments binaires, l'entrée du canal de transmission est
discrète et binaire, mais sa sortie peut être discrète ou continue.
12
Figure 2.1 Canal de transmission pour la théorie du codage
2.1 Les codes cycliques
Les codes cycliques [8] forment une sous-classe importante des codes linéaires.
Ces codes sont attractifs pour deux raisons : d'abord, le codage et le calcul de syn-
drome peuvent être mis en oeuvre facilement en employant des registres à décalage
avec des connexions de rétroaction. Ensuite, parce qu'ils ont une structure algé-
brique considérablement inhérente, il est possible donc d'employer des diérentes
méthodes pour le décodage.
2.1.1 Les codes en blocs linéaires

Le codage en blocs [8] consiste à associer à chaque bloc de k éléments binaires
d'information issu de la source, un bloc de n éléments binaires au nombre avec n>k
pour satisfaire à la condition de redondance. Les blocs de n éléments binaires au
nombre de 2k sont appelés les mots du code ; ils appartiennent à un sous-ensemble,
souvent très réduit, de l'ensemble F2n , constitué par tous les n-uplets binaires pos-
sibles. Le rapport k/n est appelé le rendement du code ou le taux de codage et la
diérence (n-k) représente le nombre d'éléments binaires de redondance introduits
par le code. Dans la suite, nous désignerons un code en blocs par C(n,k). Pour
les codes en blocs, les opérations de codage et de décodage sont réalisées à partir
d'additions et de multiplications entre des éléments binaires. L'ensemble F2 muni
de ces deux opérations (addition et multiplication)constitue un corps.
Dans le corps F2 l'addition et la multiplication correspondent respectivement
aux opérations logiques " OU exclusif " et " ET logique ". Notons également que
l'addition et la soustraction peuvent être confondues dans le corps F2 . Le signe "-"
13
est donc équivalent au signe " + " et ainsi aucune erreur de signe n'est possible
dans le corps F2 .
2.1.2 Dénition et représentation des codes cycliques

Les codes cycliques [8] représentent la classe la plus importante des codes en
blocs linéaires. Leur mise en oeuvre relativement aisée, à partir de registres à
décalages et d'opérateurs logiques combinatoires simples, en a fait des codes très
attractifs et très utiles dans les systèmes de transmission.
2.1.3 Dénition
Un code en blocs linéaire C(n, k) est cyclique si, c = [c0 ...cj ...cn−1 ] étant un
mot du code, alors c1 = [c1 ...cj ...cn−1 c0 ] , obtenu par permutation circulaire à
gauche d'un élément binaire de c est aussi un mot du code. Cette dénition des
codes cycliques entraine que toute permutation circulaire à gauche de j éléments
binaires d'un mot du code, redonne un mot du code. Ainsi au mot c on associe le
polynôme de degré n − 1
c(x) = c0 + c1 x + ...cj xj + ...cn−1 xn−1 (2.1)
Où x est une variable formelle. Multiplions le polynôme par la variable :
x−1 c(x) = c0 x−1 + c1 x + ...cj xj−1 + ...cn−1 xn−2 (2.2)
En introduisant le mot obtenu par permutation circulaire à gauche d'un élément

binaire du mot :
c1 (x) = c1 + c2 x + ...cj xj−1 + ...c0 xn−2 (2.3)
Le polynôme peut s'écrire sous la forme suivante :
x−1 c(x) = c0 x−1 (xn + 1) + c1 (x) (2.4)
Ainsi le résultat de la multiplication d'un mot c(x) par la variable x−1 est encore
un mot du code modulo(xn + 1) :
x−1 c(x) = c1 (x)modulol(xn + 1) (2.5)
14
Ce résultat peut être étendu à la multiplication d'un mot du code par x−i , qui
redonne encore un mot du code modulo(xn + 1).
x−1 c(x) = qi (x)(xn + 1) + ci (x) ⇔ x−i c(x) = ci (x) (2.6)
Où ci (x) est le polynôme associé au mot ci obtenu par permutation circulaire à

gauche de i éléments binaires du mot c.
Considérons maintenant un polynôme normalisé de degré (n − k) et diviseur
de xn + 1 :
g(x) = g0 + g1 x + ... + gj xj + ... + xn−k (2.7)
Et soit h(x) le quotient de xn + 1 par g(x). On a donc :

g(x)h(x) = xn + 1 (2.8)
Où h(x) est un polynôme de degré k .

A tout bloc de de k éléments binaires d'information, on peut associer un poly-
nôme m(x) de degré k − 1 :
m(x) = m0 + m1 x + ... + mj xj + ... + mk−1 xk−1 (2.9)
Nous allons montrer maintenant que les mots d'un code cyclique peuvent être
obtenus à partir du produit d'un polynôme d'information par g(x). En eet en
partant de 2.1.3 et en tenant compte de la relation 2.1.3, le mot ci (x) est égale à :
ci (x) = x−i c(x) + qi (x)h(x)g(x) (2.10)
Ainsi si c(x) est multiple du polynôme g(x), alors tout mot ci (x) est aussi un
multiple de g(x). On peut alors écrire :
ci (x) = mi (x)g(x) (2.11)
Où mi (x) est un polynôme de degré au plus égal à (k − 1), représentant un bloc

de k éléments binaires d'information. Chaque mot d'un code cyclique peut donc
être obtenu en multipliant un polynôme d'information mi (x) par le polynôme g(x)
de degré (n − k) et diviseur de xn + 1. Le polynôme g(x) est appelé polynôme
générateur du code cyclique. Compte tenu de l'expression 2.1.3, le polynôme h(x)
de degré k est appelé le polynôme de contrôle de parité du code.
15
2.1.4 Code cyclique sous forme systématique
Lorsque le code est sous forme systématique, les éléments binaires d'information
sont séparés des éléments binaires de redondance, et ainsi, le mot c(x) associé au
polynôme m(x) est de la forme :
c( x) = v(x) + xn−k m(x) (2.12)
Où v(x) est le polynôme de degré au plus égal à n − k − 1, associé aux éléments bi-
naires de redondance. En tenant compte du fait que c(x) est multiple du polynôme
générateur, et que les opérations sont eectuées dans le corps F2 , l'expression 2.1.4
peut encore s'écrire :
xn−k m(x) = k(x)g(x) + v(x) (2.13)
v(x) est donc le reste de la division de xn−k m(x) par le polynôme générateur.
Ainsi le mot du code associé à m(x) est égale à xn−k m(x) augmenté du reste de la
division de xn−k m(x) par le polynôme générateur g(x).
2.1.5 Mise en oeuvre du codeur

Nous venons de voir que le codeur doit eectuer la division de xn−k m(x) par
le polynôme générateur g(x) puis ajouter le reste de cette division à v(x). Cette
opération peut être réalisée en utilisant uniquement des registres à décalage et des
additionneurs dans le corps F2 . L'opération la plus dicile à réaliser étant la di-
vision de xn−k m(x) par g(x). Nous allons d'abord examiner le schéma de principe
d'un diviseur par g(x), représenté sur la gure 2.2. Le circuit diviseur est réalisé à
partir d'un registre à décalage à (n − k) mémoires et autant d'additionneurs. Le
registre à décalage est initialisé à zéro et les k coecients binaires du polynôme
xn−k m(x) sont introduits dans le circuit diviseur au rythme d'une horloge. Après
k impulsions d'horloge, on peut vérier, ainsi que le reste v(x) qui se trouve dans
les mémoires du registre à décalage.
Le schéma de principe du codeur représenté sur la gure 2.3, utilise le circuit

diviseur de la gure 2.2. La multiplication de m(x) par xn−k , correspondant à un
simple décalage, est réalisée en introduisant le polynôme m(x) en sortie du registre
à décalage du diviseur. Les k éléments binaires d'informations sont introduits au
rythme d'une horloge dans le codeur (interrupteur I en position 1) qui réalise la
division de xn−k m(x) par g(x). Simultanément, les k éléments binaires d'informa-
tion sont aussi émis en ligne. Cette opération terminée, le reste de la division se
16
Figure 2.2 Schéma de principe d'un circuit diviseur par g(x)
trouve dans les (n − k) mémoires du registre à décalage. L'interrupteur I passe

alors en position 2, et les (n − k) éléments binaires de redondance sont envoyés
vers la sortie du codeur.
Figure 2.3 Schéma de principe d'un codeur cyclique
2.2 Les codes convolutifs
2.2.1 Principe du codage convolutif

Les codes convolutifs [8] ou récurrents constituent une seconde famille de codes
correcteurs d'erreurs au moins aussi importante que les codes en blocs cycliques.
Pour les codes convolutifs, chaque bloc de n éléments binaires en sortie du codeur
dépend non seulement du bloc de k éléments binaires présent à son entrée mais
aussi des m blocs présents précédemment. Les codes convolutifs introduisent par
conséquent un eet de mémoire d'ordre m. La quantité (m + 1) s'appelle la lon-
gueur de contrainte du code. Le principe du codage convolutif est illustré par le
schéma de la gure 2.4.
Un codeur est constitué d'un registre à (m + 1)k étages qui mémorise les (m + 1)
blocs de k éléments binaires d'information, d'une logique combinatoire qui calcule
17
Figure 2.4 Principe d'un codeur convolutif
les blocs de n éléments binaires fournis par le codeur et d'un convertisseur pa-
rallèle série. La quantité R = k/n est appelée, comme pour les codes cycliques,
le rendement du code. Si les k éléments binaires d'information présents à l'entrée
du codeur sont eectivement émis, c'est-à-dire se retrouvent explicitement dans le
bloc de n éléments binaires en sortie du codeur, le code est dit systématique.
2.2.2 Polynôme générateur d'un code convolutif

Le polynôme générateur (ou séquences génératrices) d'un code convolutif repré-
sente les diérentes manières dont le code en question est construit ; il traduit les
relations qui lient le contenu des diérents étages du registre à décalage. Chaque
séquence du code est déterminée par le produit de convolution (d'où le qualicatif
de " convolutif ") entre la suite binaire présente à l'entrée du codeur et la réponse
du codeur, dénie par ses séquences génératrices.
2.2.3 Représentations graphiques des codes convolutifs

L'idée d'une représentation graphique d'un code convolutif provient des carac-
téristiques de la sortie du codeur. En eet, la sortie du codeur dépend de son entrée
et de ses états. Les graphes équivalents à la représentation polynomiale sont sou-
vent plus faciles à manipuler et permettent de dériver des résultats plus puissants.
Tout code convolutif est représenté par trois graphes équivalents mais diérents :
Diagramme en arbre, en treillis et d'états.
Diagramme en arbre
Pour mieux comprendre cette notion, on considère le cas du codeur convolutif
(7,5) représenté par la gure 2.5.
18
Figure 2.5 Codeur convolutif (7,5)
Le diagramme en arbre associé à ce codeur convolutif est représenté sur la
gure 2.6. Sur ce diagramme, les conventions suivantes ont été adoptées :
Le temps s'écoule de gauche à droite.
Lorsque l'élément binaire à l'entrée du codeur est égal à 0 (respectivement à
1), le couple binaire en sortie du codeur (mentionné sur chaque branche) est
porté par une branche montante (respectivement descendante) du digramme
en arbre.
Figure 2.6 Représentation en arbre du code C(7,5)

Pour une séquence binaire donnée à l'entrée du codeur, la séquence correspondante
en sortie du codeur est représentée par un chemin dans l'arbre, constitué par une
suite de branches. Chaque bloc de n = 2 éléments binaire en sortie du codeur
19
dépend du bloc de k = 1 élément binaire présent à son entrée mais aussi des
m = 2 blocs de k éléments binaires contenus dans sa mémoire. Ces m.k = 2
éléments binaires dénissent l'état du codeur. On note qu'il y a 2.m.k = 4 états
possibles de ce codeur :
a=00, b= 01, c=10, d=11.
Remarque
Quel que soit l'état initial du codeur, après (m+1)=3 décalages à l'entrée du
codeur, tous les états peuvent être atteints dans l'arbre.
Diagramme d'états
Le diagramme d'état est une autre représentation d'un codeur convolutif, ne
faisant pas apparaître explicitement le temps. Ce digramme ne retient que les
diérents états du codeur et la façon dont ils communiquent. La gure 2.7 donne
le diagramme d'état associé au codeur convolutif de la gure 2.5.
Figure 2.7 Diagramme d'états du codeur convolutif(7,5)

Sur ce diagramme, les conventions suivantes ont été adoptées :
Le contenu des cercles représente l'état du registre
Les èches pointillées représente le bit d'entrée 0 et les èches en continu le
bit d'entrée 1
La valeur de sortie est inscrite sur ces èches
Diagramme en treillis
La sortie du codeur dépendant uniquement de son entrée et de son état, il est
donc possible d'utiliser une représentation plus concise que l'arbre, appelé dia-
gramme en treillis. Dans ce diagramme sont pris en compte les diérents états
20
du codeur et la façon dont ils communiquent en fonction du temps. La gure 2.8
donne la représentation en treillis associée au codeur convolutif de la gure 2.5.
Sur ce diagramme, les conventions suivantes ont été adoptées :
Les branches en traits pointillées correspondent à la présence d'un élément
binaire d'information égal à 0 à l'entrée du codeur et les branches en trait
plein, à un élément binaire égal à 1
La valeur du couple binaire disponible en sortie du codeur est inscrite sur
chaque branche
Remarques
Après (m + 1) décalages (ici 3), quelque soit l'état initial du codeur, le motif
du treillis se répète. De chaque nud partent 2k branches (ici 2), et en chaque
noeud convergent 2k branches
Généralement on préfère commencer et terminer le treillis par l'état 00 (cas
du codeur de la gure 2.5). C'est pourquoi, pour une séquence de longueur
L, il faut ajouter m (ici 2) bits égaux à 0 an d'engendrer les m décalages
supplémentaires qui permettent au codeur de revenir à son état initial.
Figure 2.8 Diagramme en treillis du codeur convolutif(7,5)

Le codage convolutif va permettre de retrouver la valeur la plus probable d'un bit
en observant les bits précédemment reçus.
21
2.2.4 Choix de l'architecture du codeur
La sortie du codeur convolutif [9]à la kième itération est déni par :
m
X
vk = fi .Wk−i (2.14)
i=0
Où m
X
Wk = Uk + gi .Wk−i (2.15)
i=0
Les coecients fi , gi , i ∈ 0; 1 déterminent, respectivement, les polynômes généra-

teurs d'action et de rétroaction.
La façon la plus commune de décrire un code convolutif est représenté dans la
Figure 2.9 et est appelée forme canonique de control du codeur convolutif.
Figure 2.9 Schéma de principe de la forme canonique de control convolutive

De point de vu implémentation, il devient évident que le chemin critique qui dé-
pend du nombre de circuits combinatoires en série, est une fonction du polynôme
générateur utilisé. Plus les coecients du polynôme est grande plus la latence de
cette architecture est grande.
Une autre façon de décrire le même comportement du système peut être trouvée
en transformant le graphique de ux de la gure 2.9 en inversant Les directions de
tous les chemins d'entrés et de sortis. Ainsi, la sortie peut être écrite comme :
m
X
Vk = f0 Uk + (fi Uk−i − gi Vk−i ) (2.16)
i=0
22
Figure 2.10 Schéma de principe de la forme canonique observatrice convolutive
La réalisation d'un tel codeur est représentée dans la Figure 2.10 et est appelé forme
observatrice. Dans ce cas, les mémoires ne forment plus un registre à décalage puis-
qu'ils sont séparés par additionneur modulo 2 (en d'autre terme l'operateur XOR).
Contrairement à la forme canonique de control précédente, le chemin critique

de la forme observatrice ne dépend plus du polynôme générateur. De ce fait, cette
forme garantit un chemin critique meilleur que la forme canonique de control qui
est indépendant des polynômes générateurs.
2.3 Génération de M-séquences(LFSR)
Un registre à décalage à rétroaction linéaire(LFSR) générateur de m-séquences

[10] est un type de registre à décalage pour lesquels la fonction de rétroaction
(comme pour le codeur cyclique) est linéaire. Pour un registre de longueur L, il
existe des coecients (g1 , , gL ) tels que la sortie Sn du registre vérie
L
X
S= (gi Sn−i ) (2.17)
i=1
Les coecients (g1, , gL) sont caractéristiques d'un générateur de m-séquences et

dénissent le polynôme de rétroaction. Pour le LFSR dont la fonction de rétroac-
tion linéaire est donnée par la relation 2.3, on dénit le polynôme de rétroaction
par
fX = 1 + g1 X + g2 X 2 + ... + gL X L (2.18)
23
2.3.1 Représentation de Fibonnacci
Un LFSR fonctionne donc sur le principe illustré par la gure 2.11.
Figure 2.11 Schéma d'un LFSR dans la représentation de Fibonnacci

À chaque itération, tous les bits du registre sont décalés d'une position vers
la droite. Le bit de poids faible Sn − L constitue alors la sortie du registre. Le
nouveau bit de poids fort du registre SL est la somme modulo2 des (gi Sn+L−i )1 .
Cette implémentation du LFSR est dite de Fibonnacci. Comme nous allons le voir
dans la prochaine section, cette représentation n'est pas la seule possible.
2.3.2 Représentation de Galois

Il existe une autre façon d'implémenter un LFSR que celle schématisée sur
la gure 2.11. Il s'agit de la représentation de Galois. Elle est schématisée sur la
gure 2.12.
Figure 2.12 Schéma d'un LFSR dans la représentation de Galois
24
Dans la représentation de Galois, le bit sortant du LFSR est directement réinjecté
dans chacune des cellules, après avoir été multiplié par un coecient et ajouté au
contenu de la cellule précédente.
2.4 Conclusion
Dans ce chapitre, nous avons vu les principes théoriques de chaque type du

codage cyclique et convolutif ainsi que le générateur de m-séquences. Les diérentes
architectures de ces trois systèmes présentent des similarités qui vont être exploités
pour concevoir une architecture générique recongurable capable d'exécuter les
trois opérations selon les congurations du matériel.
25
Chapitre 3
Architecture recongurable pour le
Codage canal
3.1 Introduction
Dans ce chapitre, nous présenterons l'architecture recongurable du codage

canal que nous avons décidé de réaliser. Dans un premier temps, nous exposerons
cette architecture inspirée directement des trois fonctionnalités mentionnées avant.
Ensuite, nous dénirons les adaptations adéquates des diérents paramètres et les
modes de réglage nécessaires pour chaque type du codage canal.
3.2 Architecture générique
Présentée par la gure 3.1, notre architecture générique est capable d'accomplir
selon le choix de l'utilisateur :
• le codage cyclique
• le codage convolutif
• la génération de m-séquence
Pour implémenter le codeur, quatre blocs sont utilisés en cascade représentés
dans la gure 3.2 pour fournir la fonctionnalité du codage adéquat. La raison pour
laquelle nous allons utiliser exactement quatre blocs est la suivante : Premièrement,
dans la spécication du codeur convolutif, nous avons fait le choix de quatre sorties
en maximum. Deuxièmement, la taille de la mémoire pour le même code varie de
1 à 10. Nous avons décidé, ensuite, d'utiliser 16 registres par bloc et 64 en total
qui correspondent à la taille d'un mot binaire dans la mémoire. Cette structure
fournit les diérents états dans lesquels chacun des blocs, pendant l'exécution de
l'opération de codage, peut être :
26
Figure 3.1 forme générique du codeur
Etat 1. Premier bloc à utiliser. Il est entièrement utilisé (c'est-à-dire m >

16).
Etat 2. Le dernier bloc à utiliser. Le nombre des registres nécessaires s'étend
de 1 à 16.
Etat 3. Bloc intermédiaire, entièrement utilisé.
Etat 4. Le premier et le dernier bloc. Le nombre des registres nécessaires
s'étend de 1 à 16 (c'est-à-dire 1<m<16).
Figure 3.2 Les quatre blocs en cascade

En conséquence de ces diérents états, deux sortes de bloc sont conçus. Le
premier bloc peut être dans tous ces états. Les trois autres peuvent être dans le
deuxième, le troisième ou le quatrième état.
27
3.2.1 Architecture du premier bloc
L'architecture du premier bloc représenté dans la gure 3.3 est composé de :
U correspond au bit d'entrée d'information.
X est un bit d'entrée. Il permet la liaison entre ce bloc et le bloc utilisé juste
avant.
F16, F15...,F1 et F0 représentent dix-sept coecients du polynôme F.
G16, G15...,G1 et G0 représentent dix-sept coecients du polynôme G.
S est un bit de sortie.
FB, un signal de rétroactions.
INT est un signal de contrôle.
CONV contrôle le multiplexeur de sortie.
Figure 3.3 architecture du premier bloc
3.2.2 Architecture du deuxième, troisième et quatrième bloc

Les trois derniers blocs présentent la même architecture et peuvent être dans
deux états. Chacun de ces blocs peut être le dernier bloc dans l'opération du codage
ou un bloc intermédiaire.
L'architecture de ces trois blocs représenté dans la gure 3.4 est composé de :
U correspond au bit d'entrée d'information.
28
X est un bit d'entrée. Il permet la liaison entre ce bloc et le bloc utilisé juste
avant.
SZ16, SZ15..., SZ1 et SZ0 représentent dix-sept entrées.
G16, G15..., G1 et G0 représentent dix-sept coecients du polynôme G.
S est un bit de sortie.
FB-I, un signal de réactions. Il est nécessaire si le bloc est intermédiaire.
FB-O, un signal de réactions. Il est nécessaire si le bloc est un dernier.
INT est un signal de contrôle. Quand le bloc est intermédiaire, INT prend
un.
CONV-O contrôle le multiplexeur de sortie.
CONV-I contrôle le multiplexeur de sortie.
Figure 3.4 Architecture du deuxième, troisième et quatrième bloc

Nous allons expliquer, dans ce qui suit de ce rapport, le rôle des diérents
paramètres de nôtre architecture an eectuer l'opération du codage adéquate.
29
3.3 Codage convolutif
Les codes convolutifs sont généralement spéciés par trois paramètres : (n, k,
m)
n = nombre de bits de sortie
k = nombre de bits d'entrée
m = nombre des registres
Dans notre implémentation, nous sommes intéressés par le cas où k égal à 1,
n entre 1 et 4 et le nombre maximal des registres est 16. Comme indiqué dans la
gure 3.5 , m est l'ordre des registres dans le codeur. Pour ce type de codage, Le
coecient F0 est toujours égal à un pour fournir l'entrée au codeur. Le coecient
G0 indique l'existence d'une éventuelle rétroaction (feedback). G0 et F0 sont aussi
les coecients du plus bas degré des polynômes F et G. Nous allons utiliser pour
le codage convolutif la forme canonique observatrice . Particulièrement, la forme
observatrice du codeur convolutif est utilisée pour permettre l'implémentation du
codeur cyclique et le générateur de m-séquences.
Figure 3.5 Forme générique du codeur convolutif
3.3.1 Mise en oeuvre du codeur convolutif

Tous les blocs du codeur sont à l'état 4. Chaque bloc sera le premier et le
dernier bloc à utiliser. L'initialisation des blocs est la suivante :
• Le premier bloc
Les coecients Fm,..., F0 sont les m coecients du polynôme générateur
F.
F16..., Fm+1 sont à zéro.
30
Les coecients Gm..., G0 sont les m coecients du polynôme générateur
G.
G16..., Gm+1 sont à zéro.
Tous les registres à zéro.
INT et CONV sont à zéro.
• Les trois autres blocs
Les coecients SZm..., SZ0 sont les m coecients du polynôme générateur
F.
SZ16..., SZm+1 sont à zéro.
Les coecients Gm..., G0 sont les m coecients du polynôme générateur
G.
G16..., Gm+1 sont à zéro.
Tous les registres à zéro.
INT, CONV-I et CONV-O sont à zéro.
Le circuit peut exécuter l'opération de codage continuellement et sans changement
d'état.
3.4 Codage cyclique
Comme les codes convolutifs, les codes cycliques sont aussi spéciés par les trois
paramètres n,k et m. n désigne la longueur du mot code, k désigne la longueur de
la trame d'entrée et m qui est la diérence entre n et k désigne le nombre des
registres à utiliser. Pour obtenir du schéma du codeur générique de la gure 3.1
le codeur cyclique représenté par la gure 3.6, nous devons ajuster ses diérents
paramètres :
Fm, Fm-1..., F1=0
Gm=1
Gm, Gm-1..., G1, G0 correspond aux coecients du polynôme générateur
G. G0 est le coecient du plus haut degré et Gm est le coecient du plus
bas degré.
G0 représente le gate. Il est activé quand le codeur décale les bits d'informa-
tion dans les registres. Et il est désactivé quand le codeur décharge les bits
de contrôle de parité.
Le commutateur est nécessaire pour fournir d'abord les bits d'information et en-
suite les bits de contrôle de parité. Il y a deux étapes pour eectuer le codage
cyclique :
Etape 1.Les bits d'information sont injectés dans le circuit et simultanément
dans le canal de communication. Pour cette étape, la sortie du commutateur
est directement les bits d'information. (G0=1 et F0=1).
Etape 2.La boucle de rétroaction est férmée en mettant G0=0 et F0=0 pour
31
Figure 3.6 Forme générique du codeur cyclique
décaler les bits de parité dans les registres. Dans cette étape, la sortie du
commutateur est V.
La gure 3.6 représente l'architecture de la forme générique de tous les codeurs
cycliques possibles.
3.4.1 Mise en oeuvre du codeur cyclique

Le codeur cyclique est amené à produire des mots codes avec une partie de
redondance qui peut dépasser les 64 bits (m> 64). Le fait d'être limité par 64
registres, nous oblige d'ajuster l'architecture des quatre blocs de manière à pou-
voir utiliser la mémoire du FPGA. Nous serons, dans ce cas, capable de produire
des mots codes dont les bits redondants peuvent atteindre les 1024x64. Compte
tenu des cette contrainte, trois modes de fonctionnements du codeur seront adop-
tés pour xer les diérents paramètres. Le premier mode dans le cas où m<64.
Le deuxième mode où 64<m<128. Et le dernier dans le cas où m>128. Le cas
intermédiaire (64<m<128) est imposé par la latence de la mémoire du matériel où
le piplining requis au déroulement du codage impose un adressage spécique : la
mémoire sera en mode " lecture avant écriture ", c'est-à-dire que pour extraire les
données stockées dans une adresse, il faut écrire dans la même adresse pour obtenir
ces données. Ce mode nécessite, donc, 2 cycles entre le stockage et l'extraction des
mêmes données et il est impossible, par suite, avec 64<m<128 de faire recours à la
mémoire. D'où l'obligation d'introduire deux blocs supplémentaires de 64 registres.
Dans chacun de ces trois modes, l'adaptation est la même des quatre blocs est
s'eectue selon les quatre états mentionnés dans 3.2.
32
Le premier bloc
Le polynôme F n'existe pas dans le codage cyclique. Par suite tous les coe-
cients F16 F15... et F1 sont égaux à zéro. Par contre, le dernier coecient F0 est
égal à 1 ,pendant la première étape, quand les bits de donnés sont injecté dans le
circuit. Et il est égal à zéro, dans la deuxième étape, pour permettre de générer
les bits de redondance à partir du décalage des registres .
• État 1.bloc en est entièrement utilisé et c'est le premier bloc dans l'opération.
Dans ce cas, le fonctionnement de ce bloc nécessite le signal FB.
G16, G15... et G1 représentent les coecients des 16 premiers monômes
des degrés inférieurs du polynôme générateur.
G0, F0 et CONV sont égaux à zéro pour permettre l'entrée du contenu du
registre numéro 0 au bloc suivant.
INT est égal à un et X est égal à zéro.
• État 3.Le bloc est un bloc intermédiaire et il est entièrement utilisé.
G16, G15... et G1 sont les seize coecients du polynôme générateur.
G0, F0 et CONV sont égaux à zéro pour la même raison que l'état 1.
INT est égal à un.
X représente la valeur du dernier registre utilisé par le dernier bloc.
• État 4. Le bloc est le premier et le dernier bloque en même temps.
Gm, Gm-1... et G0 sont les m coecients du polynôme générateur.
G16, G15... et Gm + 1 sont égaux à zéro.
F0 et G0 prennent la même valeur. Dans la première étape, quand les
bits de données sont injectés dans le circuit, F0 et G0 prennent 1 pour
introduire ces bits dans les registres. Dans la deuxième étape, F0 et G0
prennent zéro pour annuler l'eet de la boucle de rétroaction. G0 repré-
sentent le coecient du polynôme du plus haut degré. La valeur du signal
CONV suit la même valeur que G0 pour permettre au commutateur d'être
dans les deux étapes nécessaires.
INT égal à zéro.
Le deuxième, troisième et quatrième bloc

Les coecients SZ16, SZ15..., SZ1 représentent la position de X relative aux
registres quand il est injecté dans le circuit. Seulement un coecient est égal à 1 et
c'est juste derrière le registre visé. SZ0, G0 et CONV-O prennent la même valeur
selon les deux étapes du codage. CONV-I prend 1 pour fournir la valeur de X. Les
autres paramètres dépendent de l'état du bloc :
• État 2. Le bloc est le dernier à utiliser. Dans ce cas :
Gi... et G0 correspondent aux coecients inférieurs du polynôme généra-
teur, i est la position où X doit être injectée.
33
G16... et Gi + 1 sont égaux à zéro.
SZi est égal à un. Les autres SZj, j diérent de i, sont égaux à zéro.
SZ0, G0 et CONV-O prennent dans la première étape la valeur un et, dans
la deuxième étape la valeur zéro.
INT est égal à zéro pour permettre le calcul du signal FB-O de retour.
• État 3. Le bloc est un bloc intermédiaire. Et il est entièrement utilisé.
G16... et G1 correspond aux seize coecients du polynôme G.
SZ16 est égal à un pour injecter X, les autres SZi sont égales à zéro.
SZ0, G0 et CONV-O sont égaux à zéro pour permettre l'entrée de S au
bloc suivant.
INT est égal à un.
3.4.2 les trois modes de fonctionnement du codeur cyclique

Premier mode
Cette conguration requiert seulement les registres internes. L'architecture du
codeur dans ce cas est présentée dans la gure 3.7. Le nombre des blocs en cascade
Figure 3.7 Architecture du codeur dans le premier mode

varie selon la valeur de m :
Si m<16 : seulement le premier bloc sera fonctionnel suivant l'état 4.
Si 16<m<32 : les deux premiers blocs seront fonctionnels et la sortie du
deuxième bloc constituera le mot code. Le premier bloc sera à l'état 1 et le
deuxième à l'état 2.
Si 32<m<48 : les trois premiers blocs seront fonctionnels et la sortie du
troisième bloc constituera le mot code. Le premier bloc sera à l'état 1, le
34
deuxième à l'état 3 et le troisième à l'état 2.
Si 48<m<64 : les quatre blocs de l'architecture seront fonctionnels et la sortie
du quatrième bloc constituera le mot code. Le premier bloc sera à l'état 1,
le deuxième et le troisième seront à l'état 3 et le quatrième à l'état 2.
Deuxième mode
Ce mode de fonctionnement requiert l'utilisation de deux registres externes
pour remplacer les registres de l'architecture générique an de parvenir à produire
des mots codes dont les bits de parité sont supérieurs à 64 et inferieurs à 128 bits.
Notre architecture sera donc constituée seulement par la partie combinatoire qui
se présente dans les opérations XOR et AND. Il est nécessaire aussi d'introduire
deux registres pour le maintient des signaux X et FB-O.
L'architecture du premier bloc est présentée par la gure 3.8.
Figure 3.8 Nouvelle architecture du premier bloc

L'architecture des deuxième, troisième et quatrième blocs est présentée par la
gure 3.9.
Les quatre blocs de ce deuxième mode constitueront un seul bloc avec deux
entrées et deux sorties.
les entrées : un bit de donné et un bus de 64 bits provenant de la ram.
Les sorties : un bit de sortie pour le mot code et un bus de 64 bits à la
direction de la ram.
Le Bloc codeur sera représenté par la gure 3.10.
35
Figure 3.9 Nouvelle architecture du deuxième, troisième et quatrième bloc
Figure 3.10 Architecture du bloc codeur dans le deuxième mode
Déroulement du codage Pour produire un mot code, il est impératif d'uti-

liser deux Blocs de la gure 3.10. La procédure de fonctionnement est similaire
au fonctionnement de deux Blocs en alternance. Ce bloc va être commandé pour
fonctionner dans deux étapes successives pendant 2xn coups d'horloge.
Exemple : codeur à 90 registres Pour obtenir un mot code(4,94), il nous

faut un codeur comportant 90 registres. Notre architecture ne présente que 64
registres. Nous sommes amenés,donc, à diviser les 90 registres sur un bloc de 64
et un autre de 26 registres (gure 3.11).
36
Figure 3.11 Le codeur devisé en deux blocs
Notre bloc de la gure 3.10 va prendre, dans chaque itération (valeur du compteur
à T(i)) deux états pendant t(i).
• A T(1)
A t(1), on utilise le premier bloc, dans lequel, on injecte l'entrée U(0) et
on stocke sa sortie x(0) dans le registre reg-x. Ce bloc génère 64 bits à la
direction des premiers registres reg_1 (gure 3.12).
Figure 3.12 Première sous-étape du codage

A t(2), le deuxième bloc est en marche, ce bloc génère 26 bits à la direction
des deuxièmes registres. Il prend comme entées le bit de donnée U(0) et
x(0) et produit -dans cette étape- le premier bit du mot code et le bit
du feedback fb(0) nécessaire au fonctionnement du bloc 1 dans les étapes
suivantes(gure 3.13).
Figure 3.13 Deuxième sous-étape du codage
37
• A T(2)
A t(1), le premier bloc va prendre comme entrées les 64 bits stockés regs-1,
les utiliser avec le bit du feedback pour générer les nouveaux 64 bits à la
direction de reg-1 et x(1)(gure 3.14).

A t(2), x(1) est injecté dans reg-x, les sorties de regs-2 arrivent dans le bloc
2 qui va produire le deuxième bit du mot code, le signal fb(1) et D1(1) à
la direction de regs-2 (gure 3.15).

Et ainsi, les étapes s'enchainent pour produire après 188 (2x94) coups d'horloge le
mot code.
Chronogramme associé Le chronogramme de la gure 3.16 présente le

début de l'opération du codage(4,94).
U : l'entrée = 0101.
Cpt : l'étape T.
Cpt-sup (sub-cpt) : la sous-étape t.
M : le nombre des registres dans chaque t.
State-reg : les deux étapes du codage cyclique.
Sorties-bloc (regs-out) : les sorties D0 ou D1.
38
Entrées-bloc (regs-in) : les entrées D0 ou D1.
Figure 3.16 Début du codage(4,94)
Troisième mode de fonctionnement

Le même bloc de la gure 3.10 va être employé dans ce troisième mode en
tant que bloc de base pour l'opération de codage. L'utilisation da la mémoire est
impérative.
Déroulement de l'opération du codage : Pour mieux comprendre le pro-

cessus du codage dans ce troisième mode, voici un exemple illustratif.
Exemple : m = 140 Le codeur idéal pour cette opération sera un codeur avec
140 registres. Comme dans l'exemple précédent, nous allons partager le codeur de
140 registres sur 3 sous blocs, deux avec 64 registres et un avec 12 registres. (gure
3.17).
Figure 3.17 Le codeur devisé en trois blocs

Le nombre d'itérations pour produire le mot code va être multiplié par 3. La
période d'un bit de donné t va s'étalonner sur une période T=3xt.
39
• A T(1)
A t(1), on utilise le premier bloc, dans lequel, on injecte l'entrée U(0) et
on stocke sa sortie x(0) dans le registre reg-x(gure 3.18).

À t(2), on utilise le bloc du milieu, dans lequel, on injecte l'entrée U(0) et
x(0) et on stocke sa sortie x(1)(gure 3.19).

A t(3), le troisième bloc est en marche, ce bloc génère 12 bits à la direction
de ram. Il prend comme entées le bit de donné U(0) et x(1) et produit -dans
cette étape- le premier bit du mot code et le bit du feedback nécessaire au
fonctionnement des blocs 1 et 2 dans les étapes suivantes. (gure 3.20).
Figure 3.20 Troisième sous-étape du codage
40
• A T(2)
A t(1), le premier bloc va prendre comme entrées les 64 bits stockés dans
la mémoire, les utiliser avec le bit du feedback pour générer les nouveaux
64 bits à la direction de la mémoire et x(0)(gure 3.21).

Ainsi de suite, les étapes s'enchainent pour produire à la n de chaque T(i) un bit
de sortie du mot code.
Chronogramme associé Le chronogramme de la gure 3.22 présente le

début de l'opération du codage(4,144).
U : l'entrée = 0101.
Cpt : l'étape T.
Cpt-sup (sub-cpt) : la sous-étape t.
M : le nombre des registres dans chaque t.
State-reg : les deux étapes du codage cyclique.
Sram-data-out : la sorties de ram interne.
Sram-data-in : l'entrée de ram interne.
Figure 3.22 Début du codage(4,144)
41
3.5 Générateur de m-séquences
Pour obtenir le générateur de m-séquences, les mêmes étapes que le codeur

cyclique sont adoptés avec quelques modications :
Etape 1. Initialiser les diérents registres par une séquence aléatoire. G0=0
et F0=0
Etape 2. Décaler les bits dans les registres. Dans cette étape, la sortie du
commutateur est V et c'est la même étape que pour le codage cyclique à la
diérence de G0 prend 1.
Tous les modes de fonctionnement ainsi que les réglages des paramètres décrits
dans la partie codage cyclique seront adoptés pour le générateur de m-séquences.
3.6 Conclusion
Nous avons présenté dans ce chapitre une solution recongurable pour adapter
en ligne l'implantation d'un codeur convolutif, un codeur cyclique ou un générateur
de m-séquences.
En plus de sa exibilité, cette architecture présente des caractéristiques très in-
téressantes sur le plan surface et latence. Composée de 64 registres seulement, notre
conception et capable de produire des mots codes cycliques ou des m-séquences
avec une partie de redondance qui peut atteindre les 1024x64 bits. La disposi-
tion des portes XOR entre les registres ore une meilleure latence pour le codeur
convolutif et réduit considérablement le chemin critique de notre architecture.
Nous allons dans le chapitre suivant présenter l'implémentation hardware en
dénissant les diérents objets de notre codeur canal.
42
Chapitre 4
Implémentation hardware
4.1 Introduction
Dans les sous-chapitres qui suivent, nous allons discuter et expliquer l'implé-
mentation hardware choisie. Nous implémenterons une architecture top-coder qui
permet, comme vu dans le chapitre 3, d'eectuer un codage cyclique, un codage
convolutif ou générer des m-séquences avec une fréquence de 200 Mhz et un dé-
bit de 20 Mb/s . Avant de détailler notre codeur, nous allons présenter quelques
notions sur la programmation en VHDL.
4.2 Modélisation en VHDL
Un système VHDL [11] est constitué d'objets élémentaires décrits par deux
parties principales : l'entité (mot clé ENTITY) qui correspond à la vue externe du
modèle et l'architecture de l'entité (mot clé ARCHITECTURE), la vue interne du
modèle.
La spécication de l'entité permet d'appeler les bibliothèques utiles, de dé-
nir les paramètres génériques (constantes qu'il est possible de modier avant la
compilation) et les ports (mot clé PORT) qui servent à échanger l'information
avec l'environnement extérieur. Les diérents types d'information pouvant être
échangée sont transmis par les ports de classe SIGNAL (information à évènement
discrets).
L'architecture de l'entité permet de dénir le fonctionnement du modèle par
l'intermédiaire d'instanciations de composants (assemblage d'objets), d'instruc-
tions concurrents pour manipuler l'information numérique et d'instructions simul-
tanées pour les valeurs analogiques. L'architecture manipule l'information dispo-
nible sur les ports.
43
Outre l'entité et l'architecture, il existe 3 autres unités de conception : La spé-
cication de paquetage, Le corps de paquetage et La conguration. Le paquetage
permet de rassembler des objets en vue de l'exportation par les commandes LI-
BRARY/USE. La spécication regroupe les déclarations exportables alors que le
corps rassemble les unités non exportables qui décrivent les objets.La congura-
tion permet d'associer l'instanciation d'un composant et sa base de données (entité
et architecture) au moment de l'élaboration sans avoir à recompiler le modèle. Il
existe deux méthodes de conguration : l'un se fait embarquée dans l'architecture
et oblige donc à la recompiler si on change de conguration. L'autre se fait dans
une unité de conception indépendante qui peut être compilée indépendamment.
4.3 Flux de conception hardware
Les principales étapes pour la conception hardware d'un circuit logique sur
FPGA ou CPLD sont présentées par la gure 4.1.
Figure 4.1 Etapes d'implémentation d'un circuit logique sur FPGA

Le chier .vhdl contient la description du circuit traité
La simulation permet d'essayer le chier décrit en .vhdl, an de contrôler le
résultat temporellement
La synthèse permet de faire la traduction du chier .vhdl en chier logic. Le
chier crée sera un chier .edif
Le placement/routage permet de placer les interconnexions crées avec le -
chier edif de synthèse pour une technologie donnée. Le placement et routage
fournira selon la technologie choisie un chier .paf ou sof
Le programmeur permettra de programmer un FPGA ou un CPLD avec le
chier .paf ou .sof
44
4.4 Composant top_coder
4.4.1 Eléments du top_coder

A présent que nos principaux choix d'implémentations ont été expliqués, nous
présentons un schéma de l'architecture globale de notre système (gure 4.2). Dans
ce schéma, le composant bloc_coder constitue le noyau central détaillés dans le
chapitre 3, section 3.2. Ce bloc est commandé par l'FSM qui forme avec le logic-
control la partie control des diérentes opérations. Le Preprocess établit l'interfa-
çage avec la ram d'entrée. Regs_sup_64 et W_ram interviennent dans le cas ou
la partie de redondance est supérieure à 64.
La partie numérique du l'architecture global top_coder est constituée d'un seul
objet qui ne comporte que l'instanciation de sous objets reliés entre eux par des
signaux déclarés en début d'architecture. Les entités et architectures de ces sous
objets sont regroupées dans un paquage exporté au début du chier de l'objet
top_coder. Le paquage est situé dans un chier à part (top_coder_package.vhd).
Figure 4.2 Shéma de l'architecture globale
45
4.4.2 Signaux de commandes et d'entrée/ sortie du top_coder
Les signaux utilisés par le top_coder se divisent en deux catégories diérentes :
Les signaux de commandes
Les signaux d'entée/sortie
Les signaux de commande représentent tous les signaux permettant au codeur de
fonctionner correctement. Ces signaux sont :
Clk : signal d'horloge (std_ulogic)
Start : signal qui permet d'activer le top_coder. Ce signal est activé quand
les bits à coder arrivent et reste actif jusqu'à ce que le dernier bit codé soit
sorti du top_coder (std_ulogic)
Rst : signal permettant la remise à zéro du top_coder (std_ulogic)
Code_select : signal qui permet d'ordonner le type du codage (std_ulogic_vector
(1 downto 0))
Data_in_size : signal qui permet au top_coder de connaitre le nombre de
bits de données à l'entrée (std_ulogic_vector (31 downto 0))
Poly_gen_deg : signal qui permet au top_coder de connaitre le degré du
polynôme générateur (std_ulogic_vector (31 downto 0))
Poly_g, poly_f : signaux qui correspondent aux diérents coecients des
polynômes générateur F et G (std_ulogic_vector (64 downto 0))
Les signaux d'entrée/sortie constituent tous les signaux que le système doit
traiter. Ces signaux sont :
u : signal d'entré des symboles à coder. Cette entrée est sur un bit (std_ulogic)
S : signal de sortie des symboles codés. Cette sortie est sur 4 bits (std_ulogic_vector
(3 downto 0))
46
Détaillons, maintenant, les diérents objets qui constituent le top_coder.
4.5 Composant Preprocess
Le Preprocess est un processus séquentiel commandé par le logic_control. Il

assure l'interfaçage entre la ram d'entrée ram_in et le bloc_coder.
4.5.1 les entées/sorties de Preprocess

Les signaux d'entrée sont :
Reset : (soft reset) signal permettant la remise à zéro des reg_un, reg_g et
reg_f (std_ulogic)
Rst : (hard reste) signal permettant la remise à zéro des reg_un, reg_g et
reg_f (std_ulogic)
K : signal indiquant le nombre de bits de données à l'entrée (integer)
M : signal indiquant le nombre des registres à utiliser pour le codage (integer)
Cpt : compteur pour le codage cyclique et m_séquence (integer)
Cpt_rst : compteur pour la préparation initial des adresses addr_u,addr_g
et addr_f (integer)
Sub_cpt : compteur dans le cas ou m>64 (integer)
Les signaux de sorties sont :
addr_u : signal d'adresse pour mem_u (integer)
addr_g : signal d'adresse pour mem_g (integer)
addr_f : signal d'adresse pour mem_f (integer)
Poly_g, poly_f : signaux qui correspondent aux diérents coecients des
polynômes générateur F et G (std_ulogic_vector (64 downto 0))
4.5.2 Principe de fonctionnement du Preprocess

Ce processus reçoit de chacune des trois mémoires mem_u, mem_g et mem_f
une séquence de 64 bits (selon le type d'opération et la longueur de la trame de
donnée) et opère de façon à permettre l'injection de U dans le bloc_coder bit-par-
bit (streaming). Il garantit, aussi, l'arrangement des coecients du polynôme G
selon l'enchainement du codage et le nombre de sous-blocs du bloc_coder utilisés.
Pour les coecients du polynôme F, Preprocess les stocke une seule fois dans reg_f
puis il les envoie à l'FSM sans aucune enchainement (F est utilisé seulement pour
le codage convolutif qui n'opère que pendant un seul état sans changement de
coecients). On peut schématiser le principe de fonctionnement de Preprocess par
le diagramme d'activité (annexe D) de la gure 4.3
47
Figure 4.3 Diagramme d'activité du Preprocess
4.6 Composant Bloc_coder
Le Bloc_coder constitue le noyau central de notre conception dans lequel l'opé-

ration du codage s'eectuera. Il a été décrit en détail dans la section 3.2 . Ce bloc
est constitué de plusieurs registres, des ports logiques (AND et XOR) qui calculent
les bits de parité à partir des informations et du polynôme générateur. La gure
4.4 représente l'architecture du bloc_coder.
4.6.1 Signaux de commandes et d'entrée/sortie du Bloc_coder

Les signaux de commande du Bloc-coder sont :
Reset : (soft reset) signal permettant la remise à zéro du Bloc_coder (std_ulogic)
Rst : (hard reste) signal permettant la remise à zéro du Bloc_coder (std_ulogic)
int_i, i= [|1,4|] : signaux de commande pour les multiplexeurs de rétroaction
de chaque sous-bloc
Conv_i, i= [|1,4|] : signaux de commande pour les multiplexeurs de sorties
de chaque sous-bloc
Fct_normal : signal qui permet au bloc_coder de fonctionner en mode syn-
chrone ou asynchrone
Les signaux d'entée/sortie du bloc_coder sont :
Reg_in_i, i= [|1,4|] : signaux de sortie du bloc_coder, ils seront stockés dans
48
la ram interne ou les registres externes et réutilisés dans l'itération suivante
(std_ulogic vector (15 downto 0)
Reg_out_i, i= [|1,4|] : signaux d'entée, provenant de la ram ou des re-
gistres externes, ils sont les valeurs de Reg_in_i dans l'itération antérieure
(std_ulogic vector (15 downto 0)
f_i, g_i, i= [|1,4|] : signaux d'entrée, ils présentent les coecients des poly-
nômes générateurs (std_ulogic vector (16 downto 0)
s_i, i= [|1,4|] : signaux de sorties des symboles codés. (std_ulogic)
Figure 4.4 Architecture du bloc_coder
49
4.7 Composant logic_control
Le logic_control commande la machine d'états nis et gère le bon fonction-

nement des diérents autres sous-blocs à travers les valeurs des compteurs qu'il
produit ainsi que les coecients nécessaires au codage. Ce bloc est constitué de
quatre processus et d'un sous-bloc combinatoire. L'architecture du logic_control
est représenté dans la gure 4.5.
Figure 4.5 Architecture du logic_control
4.7.1 Signaux d'entrée/sortie du logic_control

Start : signal qui permet d'activer le logic_control. Ce signal est activé quand
les bits à coder arrivent et reste actif jusqu'à ce que le dernier bit codé soit
sorti du top_coder (std_ulogic)
Rst : signal permettant la remise à zéro du logic_control (std_ulogic)
Reset : (soft reset) signal permettant la remise à zéro du logic_control
(std_ulogic)
Code_select : signal qui permet d'ordonner le type du codage (std_ulogic
vector (1 downto 0)
Data_in_size : signal qui permet au logic_control de connaitre le nombre
de bits de données à l'entrée.
Poly_g_deg,Poly_f_deg : signaux qui permettent au logic_control de connaitre
le degré du polynôme générateur (std_ulogic vector (31 downto 0))
nb_conv_out : signal qui permet d'ordonner le nombre de sorties en parallèle
du codage convolutif(std ulogic)
50
Les signaux de sortie sont :
Enable : signal permettant d'activer l'opération du codage (std_ulogic)
M : signal indiquant le nombre des registres à utiliser pour le codage (integer)
Cpt : compteur pour le codage cyclique et m-séquence (integer)
Cpt_rst : compteur pour la préparation initial de la machine à états nis
(integer)
Cpt_conv : compteur pour le codage convolutif
Fct_normal : signal qui indique si m>64 ou non (std_ulogic)
W_addr : adresses de la W_ram (integer)
4.7.2 Eléments du logic_control

Premier processus
Ce processus est combinatoire, il calcule les diérents coecients des codeurs ;
n, k, n_conv, m_conv et m et produit les signaux enable_cyc,enable_conv et
enable_mseq qui indiquent quel type d'opération de codage est appelée. Son dia-
gramme d'activité est représenté dans la gure 4.6.
Figure 4.6 Diagramme d'activité du premier processus du logic_control
Deuxième processus
Ce processus est aussi combinatoire, il permet, dans le cas d'un codage cyclique
ou m-séquence, de prendre une décision sur la longueur de la partie redondante (m)
à travers le signal fct_normal. Il produit, de plus, s'il s'agit bien d'un m>64 une
valeur limit_sub_cpt qui contrôle le compteur sub_cpt. Son diagramme d'activité
est représenté dans la gure 4.7.
51
Figure 4.7 Diagramme d'activité du deuxième processus du logic_control
Troisième processus
Ce processus est séquentiel, il produit les signaux enable, w_addr et select_m
ainsi que les diérents compteurs correspondant à l'opération adéquate :
Cpt_rst : ce compteur gère le premier état (prepar_iram) de la machine à
états nis et permet d'enclencher le signal enable responsable du fonction-
nement des autres compteurs et du fsm.
Cpt : c'est un compteur pour le codage cyclique ainsi que le m-séquence.
Son incrémentation dépend du signal fct_normal et il commande le passage
entre les deux états du codage.
Sub_cpt : ce compteur gère les sous-états du codeur cyclique ou m-séquence
dans le cas où m>64, il est inactif dans le cas échéant.
Cpt_conv : ce compteur dirige le déroulement du codage convolutif.
Son diagramme d'activité est présenté dans la gure 4.8.
Quatrième processus
Ce processus est aussi séquentiel, il ordonne l'enclenchement et le déclenche-
ment des diérents compteurs à travers les signaux enable_cpt et enable_cpt_conv.
La commande des ces deux signaux se fait suivant la valeur des compteurs rst_cpt,
cpt et cpt_conv. Son diagramme d'activité est présenté dans la gure 4.9.
En plus de ces processus, le logic_control produit le nombre des registres né-

cessaires dans chaque étape du codage à travers une instanciation combinatoire.
52
Figure 4.8 Diagramme d'activité du troisième processus du logic_control
Figure 4.9 Diagramme d'activité du quatrième processus du logic_control
53
4.8 Composant FSM
Ce composant représente la machine d'états nis, il gère le déroulement des

étapes du codage à travers les signaux de commande du bloc_coder qu'il produit.
Son architecture est représenté dans la gure 4.10
Figure 4.10 Architecture de l'FSM
4.8.1 Les entrées/sorties de l'FSM

L'FSM est un bloc intermédiaire entre le logic_control et le bloc_coder. Ses
entrées sont les diérents compteurs et les polynômes F et G. Ses sorties sont les
diérents commandes des multiplieurs du Bloc_coder et les coecients de F et G
correspondants à chaque sous-bloc du Bloc_coder.
4.8.2 Éléments de l'FSM

L'FSM se compose de quatre processus, un séquentiel et trois combinatoires. Le
processus séquentiel permet le passage de l'état actuel (stat_reg) à l'état suivant
(next_state), le deuxième processus dénit les conditions de passage de chaque
état , le troisième eectue les opérations adéquates dans chaque état et le qua-
trième produit les signaux nécessaires dans les modes où m>64.
54
Proc_machine(deuxième processus)
Ce processus présente la machine d'états nis, gure 4.11.
Figure 4.11 Machine d'états nis du bloc FSM
Proc_EXE(troisième processus)
Ce process eectue le réglage des diérents signaux de commande du Bloc_coder
relatif à chaque état.
Idle : c'est le premier état, le codeur est en état d'attente du signal start.
Tous les signaux sont à zéro.
Prepar_iram : à l'activation du signal start, l'état courant idle passe à

l'état suivant prepar_iram. Dans cet état, le composant Preprocess et en
marche.Cet état reste actif tant que rst_cpt<4.
First_step_cyc : si enable_cyc est enclenché, l'état courant prepar_iram

passe à l'état rst_step_cyc. C'est la première étape du codage cyclique
où les bits d'information sont injectés dans le circuit et simultanément dans
le canal de communication. Pour cette étape, la sortie du commutateur est
directement les bits d'information. Cet état reste actif tant que cpt<k.
Les opérations eectuées dans cet état sont représentées dans le diagramme
d'activité de la gure 4.12(r=16).
55
Figure 4.12 Diagramme d'activité de l'état First_step
Second_step_cyc : si cpt=k, l'état actuel devient second_step_cyc. C'est
la deuxième étape du codage cyclique, la boucle de rétroaction est fermé en
mettant G0=0 et F0=0 pour décaler les bits de parité dans les registres. Elle
reste active tant que cpt<n sinon si cpt=n elle passe à l'état idle.
Figure 4.13 Diagramme d'activité de l'état Second_step
56
Convolutif : si enable_conv est enclenché, l'état actuel prepar_iram passe à
l'état suivant convolutif. L'opération du codage convolutif va être exécutée
dans cette étape. Cet état reste actif si cpt-conv < n_conv sinon l'état passe
à idle.
d'activité de la gure 4.14
Figure 4.14 Diagramme d'activité de l'état Convolutif
First_step_LFSR : si enable_mseq est activé, state_next prend rst_step_LFSR

comme état actuel. Cet état s'eectue sur les premiers k valeurs de cpt dans
lequels on initialise tous les registres par la séquence de bits appropriée.
Figure 4.15 Diagramme d'activité de l'état First_step_LFSR
57
second_step_LFSR : le passage à cet état s'eectue directement si cpt=k.c'est
l'étape principale du générateur des m-séquences et presque similaire au
deuxième état du codage cyclique.
Figure 4.16 Diagramme d'activité de l'état Second_step_LFSR
Proc_reg(quatrième processus)
Ce processus est utilisé dans le cas où m>64.Il permet de controler les signaux
de commande du bloc_4 du bloc_coder et aecter les registres reg_k et reg_x.
Sont diagramme d'activité est représenté dans la gure 4.17
58
Figure 4.17 Diagramme d'activité du Proc_reg
59
4.9 Composant regs_sup_64
Ce composant sera actif seulement si le mot code cyclique ou les m-séquence ont
une partie redondante supérieur à 64. Dans ce cas, cet objet regs_sup_64 eectue
le stockage des s_i dans les registres reg_x et reg_k et le stockage des regs_in
dans la mémoire interne w_ram ou dans des registres. Il comporte trois proces-
sus, deux séquentiels pour les registres et un combinatoire pour le contrôle des
entrées/sorties de la mémoire. Son architecture est présentée dans la gure 4.18.
Figure 4.18 Architecture du regs-sup-64
4.9.1 Les entrées/sorties du regs_sup_64

Rst : signal permettant la remise à zéro du regs_sup_64 (std_ulogic)
Reset : (soft reset) signal permettant la remise à zéro du regs_sup_64
(std_ulogic)
Cpt : compteur pour le codage cyclique et m-séquence (integer)
Fct_normal : signal qui indique si m>64 ou non (std_ulogic)
s_i, i= [|1,4|] : signaux de sorties des symboles codés. (std_ulogic)
limit_sub_cpt : signal qui indique la valeur limite du sub_cpt (integer)
60
cas_m : signal qui indique dans quel cas de m est l'état du codage (std_ulogic_vector
(1 downto 0))
Reg_out_i, i= [|1,4|] : signaux d'entée du bloc_coder (std_ulogic_vector
(15 downto 0)
Sram_data_out : signal de sortie de la w_ram (std_ulogic_vector (63
downto 0))
Les signaux de sortie sont :
Sram_data_in : signal d'entrée de la w_ram (std_ulogic_vector (63 downto
0))
Reg_in_i, i= [|1,4|] : signaux de sortie du bloc_coder (std_ulogic_vector
(15 downto 0)
Reg_k : signal de stockage (std_ulogic)
Reg_x : signal de stockage (std_ulogic)
4.9.2 Éléments de regs_sup_64

Premier processus
Ce premier processus est séquentiel et fonctionne si m>64. Les signaux s_i sont
stockés dans les registres reg_k et reg_x selon la valeur du compteur sub_cpt et
selon cas-m. Le diagramme d'activité du premier processus est présenté dans la
gure 4.19.
Figure 4.19 Diagramme d'activité du premier processus du regs_sup_64
61
Deuxième processus
La contrainte de la latence imposée par la mémoire nous a obligé d'ajouter deux
registres dans le cas où limit_sub_cpt=2. Ces registres sont dénis dans ce pro-
cessus séquentiel qui eectue le stockage des reg_out_i provenant du bloc_coder.
Le diagramme d'activité de ce processus est présenté dans la gure 4.20.
Figure 4.20 Diagramme d'activité du deuxième processus du regs_sup_64
Troisième processus
C'est un processus combinatoire. Il permet l'interfaçage entre la ram interne
w_ram et le bloc_coder dans le cas ou m>128. Si limit_sub_cpt = 2 (64<m<128),
les valeurs du compteur cpt vont s'étalonner sur deux coups d'horloge ordonnés
suivant sub_cpt. Dans ce cas, on initialise les reg_in_i puis suivant sub_cpt on
aect à reg_in_i reg_1 ou reg_2. Dans le cas ou limit_sub_cpt>2, on procède
à l'interfaçage entre la w_ram et le bloc_coder. Le diagramme d'activité de ce
processus est présenté dans la gure 4.21.
62
Figure 4.21 Diagramme d'activité du troisième processus du regs_sup_64
4.10 W_ram
Le bloc w_ram est une sram interne [12] du top_coder avec une capacité de
stockage de 1Ko x 64 bits. Elle était conçue suivant la spécication du FPGA
VIRTEX 5 et implémentée de façon à permettre le piplining qui aura lieu dans
le codage cyclique ou la génération des m-séquence. Son architecture interne se
présente dans la gure 4.22.
Figure 4.22 Architecture interne de W_ram

L'écriture dans la sram du VIRTEX 5 peut être adaptée suivant trois modes de
fonctionnement :
WRITE_FIRST
READ_FIRST
NO_CHANGE
Nous avons opté pour le deuxième mode READ_FIRST ; les données stockés
antérieurement dans l'adresse se présentent à la sortie après un coup d'horloge de
l'écriture dans la même adresse (lecture avant écriture). Le chronogramme de la -
gure 4.23 correspond à ce mode de fonctionnement sans utiliser le registre de sortie.
63
Figure 4.23 Chronogramme du mode READ_FIRST
4.11 Simulations
Le système a été simulé dans l'environnement Modelsim. Il faut noter que le

travail de la conception avec VHDL n'est pas achevé vu que l'interfaçage avec
la ram de sortie n'est pas encore conçu. Il est impossible, donc, de visualiser les
mots codes produits dans le cas ou 64<m<128 et m>128 pour le codage cyclique
comme pour le générateur des m-séquences. La simulation consistait à vérier
les fonctionnements des diérents paramètres du Bloc_codeur, les compteurs du
logic_control et les registres de regs_sup_64 (annexe C). Par contre dans le cas
ou m<64, le résultat était visible.
Pour le codage convolutif, les résultats était consultables vu que m ne dépasse
jamais 16.
4.11.1 Codeur cyclique

- N=7, k=4
Avec une entrée u=1010 et un polynôme générateur g= 1011, on peut vérier
que après 7 coups d'horloge l'architecture génère le mot code correspondant La
simulation du codage est représentée dans la gure 4.24
La sortie out_cyclic = 0101110
Ce résultat correspond au modèle de référence mis au point avec Matlab :

clear ;
clc ;
nk= input('Enter Length of code [n,k] :') ;
n=nk(1)
k=nk(2)
p=n-k
g=input('Enter generator polynomial co-e : ') ;
64
d=input('Enter Data stream :') ;
code = encode(d,n,k,'cyclic',g)
**OUTPUT
Enter Length of code [n,k] :[7,4]
Enter generator polynomial co-e : [1 0 1 1]
Enter Data stream :[1 0 1 0]
code = 0 1 1 1 0 1 0

Figure 4.24 Simulation avec Modelsim de CRC(7,4)
4.11.2 codeur convolutif

Pour ce type de codage, on a utilisé encore les mêmes entrées (1010) pour un
code (k=1,n=2,m=3) Les polynômes générateurs sont f_1=1101 et f_2=1001 La
simulation est représentée dans la gure 4.25
Figure 4.25 Simulation avec Modelsim de C(1,2,3)
65
Les sorties du codeur convolutif sont :
Sout_1=1001110
Sout_2=1011010
La vérication de ce modèle est simple et correspond exactement aux sorties du
codeur représenté par la gure 4.26
Figure 4.26 codeur convolutif C(1,2,3)
Vous pouvez consulter l'annexe [C] pour vérier le fonctionnement des trois
blocs : logic_control, FSM et regs_sup_64 dans les cas de CRC(100,10),CRC(150,10)
et convolutif(13,10,3).
66
4.11.3 générateur de m-séquences
Comme vous l'avez déjà remarqué, notre générateur ne produit qu'une sé-
quences de longueur m (le degré du polynôme générateur), nous nous limiterons
dans notre simulation à ce cas, en sachant que nous devons dans notre futur travail
ajouter une entée qui indique le nombre des séquences nécessaire. nous avons tester
le modèle LFSR pour un cas très simple pour m=3, g=1011 et u (pour l'initiali-
sation des registres =1010)et la simulation a donné le chronogramme représenté
dans la gure 4.27
Figure 4.27 Simulation avec Modelsim d'un générateur de m-séquences(m=3)

La sortie Sout_1=110 correspond au modèle représenté dans la gure 4.28
Figure 4.28 Générateur de m-séquences(m=3)
67
4.12 Conclusion
Nous avons présenté dans ce chapitre l'architecture globale du codage canal

(top_coder) et les diérents sous-objets qui le composent. Nous avons vu comment
Le bloc_coder, organe principale du codeur, va être commandé selon les diérentes
étapes mentionnées dans le chapitre 3. Cette commande est assurée par trois blocs
qui sont : logic_control, FSM, regs_sup ainsi que la W_ram.
La simulation du codeur convolutif était parfaite et génère des bons résultats.
Aussi pour le codeur cyclique et m-séquences dans le cas de m 6 64. Cependant,
pour les autres cas où 64 < m 6 128 et 128<m, la simulation consistait juste à
vérier les signaux produits par logic_control, FSM et regs_sup_64 vu qu'il reste
à achever la partie interfaçage avec la mémoire.
68
Chapitre 5
Conclusion
Dans le cadre du projet Idromel, nous avons présenté, dans ce rapport, la
conception et l'implémentation d'une architecture exible pour le codage canal.
Dans le deuxième chapitre, une étude théorique a été amenée du codeur cy-
clique, convolutif et du générateur des m-séquences. Nous avons exploité leurs
architectures an de mettre en place une architecture uniée.
Dans le troisième chapitre, nous avons présenté cette architecture et les dié-
rents blocs qui la constituent. Ensuite, nous avons détaillé les réglages nécessaires
des paramètres pour fournir le codeur convolutif, le codeur cyclique et le généra-
teur des m-séquences. La partie la plus importante du travail était consacrée au
codeur cyclique, son implémentation était un peu délicate et sensible au degré du
polynôme générateur. Pour le générateur des m-séquence, nous avons vu que son
implémentation est similaire à celle du codeur cyclique avec le réglage des para-
mètres et les diérents états et les modes de fonctionnement. L'implémentation du
codeur convolutif était la plus simple et la plus rapide à mettre en place.
Dans le quatrième chapitre, nous avons exposé l'implémentation matérielle de
cette architecture générique en présentant les diérentes entités qui composent le
bloc global. D'abord, nous avons cité les interconnexions, les entrées/sorties et
l'architecture de chaque composant. Ensuite, nous avons fait quelques simulations
avec Modelsim pour valider cette architecture.
Dans les deux mois à venir, nous allons améliorer le fonctionnement du géné-
rateur des m-séquence. Nous allons régler l'interfaçage avec la ram de sortie pour
pouvoir récupérer les diérents mots codes. Il nous reste encore à implémenter un
modèle de référence avec SystemC qui servira aussi à une simulation plus rapide
dans la chaine complète.
69
Annexes
A le projet Idromel
IDROMEL [7]est un projet de plateforme ANR 2005, ayant pour thème prin-
cipale la radio logicielle. Le projet IDROMEL a débuté en 2006 et se terminera au
début de l'année 2009. Il regroupe Eurecom (Chef de File), THALES, TELECOM,
ParisTech, le CEA, SIRADEL et Supéléc.
A.1 Résumé du projet

Les deux objectifs principaux du projet IDROMEL sont, par l'intermédiaire
d'une collaboration étroite entre académiques et industriels :
d'étudier la faisabilité du déploiement d'équipements recongurables et de
leur utilisation dans les futurs réseaux mobiles
de proposer à la communauté de RD française et internationale une plate-
forme ouverte d'expérimentation d'équipements recongurables.
Pour atteindre ces objectifs, les aspects suivants sont développés :
étude de la faisabilité de la gestion agile du spectre, en incluant les aspects
de propagation, de gestion des ressources radio
étude et mise en oeuvre des scénarios de radio logicielle les plus prometteurs
(scénarios de handover par exemple)
développement d'un équipement (station de base + mobile) recongurable
(partie Radio Fréquence, et partie bande de base basée sur la technologie
système sur puce, SoC)
développement d'un ensemble logiciel permettant la reconguration du mo-
bile ou de la station de base.
Les réalisations concrètes du projet IDROMEL seront à la fois matérielles et logi-
cielles. Le projet vise en particulier à réaliser :
une carte Radio Fréquence capable de fonctionner dans au moins deux bandes
de fréquences très diérentes (les bandes 2 GHz et 5 GHz sont pressenties).
En outre cette carte sera équipée de deux chaînes de transmission et de ré-
ception, qui pourront être utilisées soit pour communiquer dans un standard
70
(en utilisant des techniques MIMO, Multiple Inputs Multiple Outputs), soit
pour pouvoir communiquer en utilisant deux standards diérents
une interface numérique/analogique et une partie bande de base intégrée
dans une architecture de type système sur puce (SoC).
Toutes les parties matérielles et logicielles seront intégrées dans un démonstrateur
qui présentera les principales caractéristiques d'un réseau d'accès recongurable.
Le fonctionnement de ce réseau sera validé par des expérimentations en vraie
grandeur à Sophia-Antipolis.
A.2 Architecture matérielle d'IDROMEL

L'architecture matérielle est présentée de manière très simpliée dans la gure
ci-dessous.
Figure 5.1 Architecture matérielle d'IDROMEL

Cette architecture comprend :
une partie Radio Fréquence (dite "agile RF") dont les spécications générales
sont : Emission/Réception, excursion en fréquence de 200 MHz à 7.5 GHz,
largeur de bande paramétrable, de 20 MHz maximum.
une carte " Mother board " bande de base, intégrant a partie conversion
A/D et D/A, carte appelée également "ExpressMIMO"
un PC intégrant un operating system temps réel et l'essentiel des piles pro-
tocolaires
un accélérateur matériel de type" Network on Chip " (NoC FAUST 2).
71
A.3 Réalisations
Gestion des ressources radio et propagation
cette activité comprend :
des études théoriques sur la propagation électromagnétique
des études sur la gestion des ressources radio.
Développement couche physique

Cette tâche consiste principalement à adapter les couches physiques déjà déve-
loppées par les partenaires du projet (dans le cadre d'autres projets comme RHO-
DOS ou du projet IST Widens), et ce pour les besoins d'IDROMel. La couche
physique ainsi obtenue est réalisée en langage C et est implémentée en temps réel,
à priori sur un processeur générique du type Pentium. Cette implémentation com-
plète les développements réalisés sur FPGA et ASIC dans le cadre du SP4. Les fonc-
tionnalités visées sont un fonctionnement en temps réel d'une couche physique en
transmission et en réception, avec la possibilité de changer tout ou partie des trai-
tements (modulation, codage canal). L'objectif est ici de pouvoir commuter d'une
couche physique de type UMTS vers une couche physique IEEE802.11/802.16.
Communication temps réel

Cette tâche consiste essentiellement à adapter des couches protocolaires (MAC,
Radio Ressource Control, Radio Link Control) réalisées dans le cadre des projets
RHODOS et IST WIDENS pour les besoins d'IDROMel. En particulier, l'ensemble
développé devra réaliser les fonctionnalités suivantes :
communication en temps réel entre un mobile et une station de base
possibilité d'implémenter des applications IP (voice over ip, video streaming)
possibilités de recongurer tout ou partie des traitements.
A.4 Gestion du handover vertical

Le handover vertical (inter technologies) utilise comme point de départ le soft
handover basé sur les mécanismes de mobile IPV6, logiciel qui a été développé
dans le cadre du projet RNRT RHODOS. Cette fonctionnalité a pour but de four-
nir une continuité du service de transmission lors d'un handover nécessitant une
reconguration d'une pile protocolaire ou non. Le développement de cette fonc-
tionnalité nécessite une analyse et la spécication d'une architecture permettant
la synchronisation du handover et des processus de reconguration couplés aux
modules de gestion des ressources radio.
72
Figure 5.2 Gestion du handover vertical
A.5 Caractéristiques
Figure 5.3 Caractéristiques du matériel
73
B Technologie FPGA
B.1 Introduction
Les FPGA [6](Field Programmable Gate Arrays ou "réseaux logiques program-
mables") sont des composants VLSI entièrement recongurables. Les énormes pro-
grès réalisés dans ces technologies permettent de réaliser des composants toujours
plus rapides, à plus haute intégration, comportant toujours plus de fonctions em-
barquées et orant la possibilité de programmer des applications de plus en plus
importantes. Aujourd'hui, il est de plus en plus courant de concevoir une première
réalisation de son algorithme sur FPGA, qui est rapide et peu coûteuse, avant de
passer à la conception sur un ASIC. Ce type de circuit possède un prix de pro-
duction relativement bas lorsqu'il est produit en grande quantité mais exige un
passage chez le fondeur, ce qui implique des frais de développement élevés. Une
première réalisation sur FPGA évite donc les surcoûts dus aux modications.
En comparaison avec d'autres types de circuits, les FPGA orent un délai
de conception relativement court et permettent de tester facilement une réalisa-
tion. Parmi les désavantages des FPGA, nous pouvons citer un prix unitaire élevé,
des performances électriques inférieures aux puces spécialisées (notamment en fré-
quence) et un taux d'utilisation du circuit en général assez faible.
B.2 Eléments constituant un FPGA

Nous considérons ici le FPGA sur lequel nous avons implémenté notre décodeur,
à savoir le Virtex-V de Xilinx.
Figure 5.4 Vue générale d'une slice

La plus petite entité de ce FPGA est la Look-Up Table (table de référence). Ce
composant possède quatre entrées et est capable d'implémenter n'importe quelle
74
fonction booléenne sur ces entrées. Comme l'indique la gure 5.4, il y a deux look-
up table dans une slice et un certain nombre de multiplexeurs qui, combinés aux
look-up table, permettent de générer des fonctions booléennes allant jusqu'à huit
entrées. La slice possède également d'autres portes logiques et des registres. La
moitié supérieure d'une slice est représentée à la gure 5.5, la moitie inférieure
étant semblable.
Figure 5.5 Détails de la partie supérieure d'une slice

Une caractéristique très intéressante de la look-up table est qu'elle peut éga-
lement être utilisée comme une RAM contenant 16 cellules de 1 bit, ou encore
comme shift register (SRL16 sur la gure A.29). Un agencement intelligent des
slices permet d'implémenter facilement des opérations d'addition et de soustrac-
tion, de créer de grands multiplexeurs ou encore de mettre des shift register en
cascade. Lorsque l'on remonte encore dans la hiérarchie d'un Virtex-V, on arrive
aux CLB (congurable logic blocks). Ceux-ci comprennent chacun quatre slices
semblables, qui sont interconnectées entre elles. Les CLB sont connectés entre eux
grâce à une matrice de routage 5.6.
75
Figure 5.6 Congurable Logic Block
B.3 Programmation des FPGA

Pour programmer un FPGA, il faut commencer par décrire le design en uti-
lisant un langage de description matériel (tel que VHDL, Verilog, ABEL,...). Le
synthétiseur va ensuite générer la liste d'interconnexion (netlist) qui permettra
de simuler le placement de tous les composants au sein du FPGA, d'eectuer le
routage entre les diérentes cellules logiques et de calculer le délai des diérents
signaux. Si le routage a pu être correctement eectué, le bit Stream qui sera prêt à
être envoyé vers le FPGA est alors généré. Ce processus est illustré à la gure 5.7.
La fréquence à laquelle tourne une implémentation dépend de la complexité des
opérations à réaliser entre deux coups d'horloge. Le chemin critique d'une implé-
mentation est le chemin qui provoque le plus long délai entre deux registres, c'est
à dire entre deux coups d'horloge. Pour certaines opérations, ce délai est très court
(pour une simple opération booléenne implémentée en une LUT, par exemple) et
pour d'autres, il peut devenir beaucoup plus long (lorsqu'il faut comparer un grand
nombre de bits, par exemple, ce qui nécessite la succession de plusieurs LUT). Il est
important de veiller à ce que tous les délais soient semblables, an d'éviter qu'une
seule opération possédant un grand chemin critique ne diminue la fréquence de
toute l'implémentation.
76
Figure 5.7 Programmation d'un FPGA
77
C Simulations
Dans cette section nous présentons les simulations des trois blocs : logic_control,
FSM et regs_sup_64 dans les cas de CRC(100,10),CRC(150,10) et convolutif(13,10,3).
C.1 Logic_control
CRC(100,10)
Figure 5.8 Fonctionnement du logic_control dans CRC(100,10)
CRC(150,10)
Figure 5.9 Fonctionnement du logic_control dans CRC(150,10)
Convolutif(13,10,3)
78
Figure 5.10 Fonctionnement du logic_control dans Convolutif(13,10,3)
C.2 FSM
CRC(100,10)
Figure 5.11 Fonctionnement du FSM dans CRC(100,10)
79
CRC(150,10)
Figure 5.12 Fonctionnement du FSM dans CRC(150,10)
Convolutif(13,10,3)
80
Figure 5.13 Fonctionnement du FSM dans Convolutif(13,10,3)
C.3 Regs_sup_64
CRC(100,10)
Figure 5.14 Fonctionnement du Regs_sup_64 dans CRC(100,10)
81
CRC(150,10)
Figure 5.15 Fonctionnement du Regs_sup_64 dans CRC(150,10)
Convolutif(13,10,3)
Figure 5.16 Fonctionnement du Regs_sup_64 dans Convolutif(13,10,3)
82
D Diagrammes d'activité
On a utilisé dans le quatrième chapitre des diagrammes d'activités décrivant

le fonctionnement de chaque processus. On a pris le soin de détailler ces dia-
grammes qui ne sont qu'une représentation simpliée. Pour comprendre le mieux
ces diagrammes, il faut savoir qu'il y a deux types de diagrammes ; séquentiel et
combinatoire selon le processus décrit.
Pour un processus séquentiel décrit par les lignes VHDL suivantes :
Process(clk)
Begin
if(clk'event and clk='1') then
if (A=B) then
C<= D ;
else
C<=E ;
end if ;
end if;
end process ;
Est représenté par le diagramme d'activité gure 5.17 :
Figure 5.17 Diagramme d'activité séquentiel
et reéte le schéma électronique gure 5.18 :
Figure 5.18 architecture séquentielle
83
Pour un processus combinatoire décrit par les lignes suivantes :
Process(A,B,D,E)
Begin
if (A=B) then
C<= D ;
else
C<=E ;
end if ;
end process ;
Est représenté par le diagramme d'activité gure 5.19 :
Figure 5.19 Diagramme d'activité combinatoire
et reéte le schéma électronique gure 5.20 :
Figure 5.20 architecture combinatoire
84
Glossaire
SOC : "System on Chip", système sur puce,désigne un système complet emb-
arqué sur une puce, pouvant comprendre de la mémoire(data/code),un
ou plusieurs microprocesseurs,des périphériques d'interface,ou tout
autre composant à la réalisation de la fonction attendue.
IP : "Intellectual Propriety".
CRC : Contrôle de redondance cyclique (Cyclic Redundancy Check)
LFSR : "Linear Feedback Shift Registre", Registre à décalege
à rétroaction linéaire.
FSM : "Finite State Machine", machine à états nis
ASIC : "Application-Specic Integrated Circuit", un circuit
intégré spécialisé.
FPGA : "Field-Programmable gate array" réseau de portes programmables.
VLSI : "Very-Large-Scale Integration", un technologie de circuit intégré
dont la densité d'intégration permet de supporter plusde 100 000
composants électroniques sur une même puce.
LUT : "Look-Up Table", une table de correspondance, qui permet d'associer
des valeurs. Elle se comporte un peu comme une table de vérité,
et désigne sa sortie en fonction des ses entrées et du contenu de
la table.
SRAM "Static Random Access Memory", un type de mémoire vive utilisant
des bascules pour mémoriser les données.
VHDL : "Very High Speed Integrated Circuit Hardware Description Language",
un langage de description matériel destiné à décrire le comportement
et/ou l'architecture d'un système électronique numérique.
85
Bibliographie
[1] XPP PACT, http ://www.pactcorp.com, consulté le 10/06/2008
[2] HIVE, http ://www.siliconhive.com, consulté le 10/06/2008
[3] Xilinx, http ://www.xilinx.com, consulté le 10/06/2008
[4] Altera, http ://www.altera.com, consulté le 10/06/2008
[5] Shu Lin, Daniel J.Costello,JR., "Error control coding :
Fundamentals and Applications", Illinois institute of
Technology.
[6] Virtex-5, http ://www.xilinx.com, consulté le 10/06/2008
products/silicon_solution/fpgas/virtex/virtex5/index.htm,
consulté le 10/06/2008
[7] IDROMEL, http ://www.openairinterface.org/
page1007/page1021.fr.htm, consulté le 10/06/2008
[8] Alain Glavieux, Michal Joint, "Communications numériques :
Introduction",Collection : Sciences Sup,Parution : 16/08/2007
[9] Matthias Kamuf, John B.Anderson, and Viktor Owall,
"Providing exibility in a convolutional encoder"Lund
University,SE-221 00 lund, Sweden
[10] A. Klapper and M. Goresky. "Fibonacci and galois represen-
tations of feedback-with-carry shift registers".IEEE Tran-
sactions of Information Theory,48(11) : 2826-2836, Nov 2002
[11] Pong P.Chu, "RTL hardware design using VHDL,coding eci-
ency,portability,and scalability".Clevland State University
[12] http ://www.xilinx.com/products/silicon_solutions/fpgas/virtex
/virtex5/capabilities/block_ram.htm, consulté le 10/06/2008
86

Rapport PFE

Transféré par

Droits d'auteur :

Formats disponibles

Rapport PFE

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport PFE

Transféré par

Droits d'auteur :

Formats disponibles

Ecole Polytechnique de Tunisie

Rapport de Projet de n d'études

Conception et implémentation d'une

Organisme d'accueil: Département Communication et Electronqique ENST-Paris

Elève ingénieur: Tarek GARA

Encadreur: Renaud PACALET

Année universitaire: 2007-2008

3 Architecture recongurable pour le Codage canal 26

3.1 forme générique du codeur . . . . . . . . . . . . . . . . . . . . . . . 27

4.1 Etapes d'implémentation d'un circuit logique sur FPGA . . . . . . 44

5.1 Architecture matérielle d'IDROMEL . . . . . . . . . . . . . . . . . 71

Dans le cadre d'introduire la reconguration au sein de systèmes sur silicium

Généricité : les diérents éléments du codeur doivent être susamment géné-

Modularité : les diérents éléments du codeur doivent être susamment bien

Ecacité : les environnements mobiles étant fortement contraints par le maté-

2.1 Les codes cycliques

2.1.1 Les codes en blocs linéaires

2.1.2 Dénition et représentation des codes cycliques

c(x) = c0 + c1 x + ...cj xj + ...cn−1 xn−1 (2.1)

Où x est une variable formelle. Multiplions le polynôme par la variable :

x−1 c(x) = c0 x−1 + c1 x + ...cj xj−1 + ...cn−1 xn−2 (2.2)

En introduisant le mot obtenu par permutation circulaire à gauche d'un élément

Le polynôme peut s'écrire sous la forme suivante :

x−1 c(x) = c0 x−1 (xn + 1) + c1 (x) (2.4)

x−1 c(x) = c1 (x)modulol(xn + 1) (2.5)

Où ci (x) est le polynôme associé au mot ci obtenu par permutation circulaire à

Et soit h(x) le quotient de xn + 1 par g(x). On a donc :

Où h(x) est un polynôme de degré k .

Où mi (x) est un polynôme de degré au plus égal à (k − 1), représentant un bloc

c( x) = v(x) + xn−k m(x) (2.12)

2.1.5 Mise en oeuvre du codeur

Le schéma de principe du codeur représenté sur la gure 2.3, utilise le circuit

trouve dans les (n − k) mémoires du registre à décalage. L'interrupteur I passe

Figure 2.3  Schéma de principe d'un codeur cyclique

2.2 Les codes convolutifs

2.2.1 Principe du codage convolutif

2.2.2 Polynôme générateur d'un code convolutif

2.2.3 Représentations graphiques des codes convolutifs

Figure 2.6  Représentation en arbre du code C(7,5)

a=00, b= 01, c=10, d=11.

Figure 2.7  Diagramme d'états du codeur convolutif(7,5)

Figure 2.8  Diagramme en treillis du codeur convolutif(7,5)

Les coecients fi , gi , i ∈ 0; 1 déterminent, respectivement, les polynômes généra-

Figure 2.9  Schéma de principe de la forme canonique de control convolutive

Contrairement à la forme canonique de control précédente, le chemin critique

2.3 Génération de M-séquences(LFSR)

Un registre à décalage à rétroaction linéaire(LFSR) générateur de m-séquences

Les coecients (g1, , gL) sont caractéristiques d'un générateur de m-séquences et

Figure 2.11  Schéma d'un LFSR dans la représentation de Fibonnacci

2.3.2 Représentation de Galois

Figure 2.12  Schéma d'un LFSR dans la représentation de Galois

Dans ce chapitre, nous avons vu les principes théoriques de chaque type du

Dans ce chapitre, nous présenterons l'architecture recongurable du codage

3.2 Architecture générique

 Etat 1. Premier bloc à utiliser. Il est entièrement utilisé (c'est-à-dire m >

Figure 3.2  Les quatre blocs en cascade

Figure 3.3  architecture du premier bloc

3.2.2 Architecture du deuxième, troisième et quatrième bloc

Figure 3.4  Architecture du deuxième, troisième et quatrième bloc

Rapport de Projet de n d'études

3 Architecture recongurable pour le Codage canal 26

Dans le cadre d'introduire la reconguration au sein de systèmes sur silicium

Généricité : les diérents éléments du codeur doivent être susamment géné-

Modularité : les diérents éléments du codeur doivent être susamment bien

Ecacité : les environnements mobiles étant fortement contraints par le maté-

2.1.2 Dénition et représentation des codes cycliques

Le schéma de principe du codeur représenté sur la gure 2.3, utilise le circuit

Figure 2.3 Schéma de principe d'un codeur cyclique

Figure 2.6 Représentation en arbre du code C(7,5)

Figure 2.7 Diagramme d'états du codeur convolutif(7,5)

Figure 2.8 Diagramme en treillis du codeur convolutif(7,5)

Les coecients fi , gi , i ∈ 0; 1 déterminent, respectivement, les polynômes généra-

Figure 2.9 Schéma de principe de la forme canonique de control convolutive

Les coecients (g1, , gL) sont caractéristiques d'un générateur de m-séquences et

Figure 2.11 Schéma d'un LFSR dans la représentation de Fibonnacci

Figure 2.12 Schéma d'un LFSR dans la représentation de Galois

Dans ce chapitre, nous présenterons l'architecture recongurable du codage

Etat 1. Premier bloc à utiliser. Il est entièrement utilisé (c'est-à-dire m >

Figure 3.2 Les quatre blocs en cascade

Figure 3.3 architecture du premier bloc

Figure 3.4 Architecture du deuxième, troisième et quatrième bloc

Figure 3.5 Forme générique du codeur convolutif

Figure 3.7 Architecture du codeur dans le premier mode

L'architecture du premier bloc est présentée par la gure 3.8.

Figure 3.8 Nouvelle architecture du premier bloc

Figure 3.10 Architecture du bloc codeur dans le deuxième mode

Figure 3.12 Première sous-étape du codage

Figure 3.13 Deuxième sous-étape du codage

Figure 3.14 Première sous-étape du codage

Figure 3.15 Deuxième sous-étape du codage

Chronogramme associé Le chronogramme de la gure 3.16 présente le

Figure 3.16 Début du codage(4,94)

Figure 3.17 Le codeur devisé en trois blocs

Figure 3.18 Première sous-étape du codage

Figure 3.19 Deuxième sous-étape du codage

Figure 3.20 Troisième sous-étape du codage

Figure 3.21 Première sous-étape du codage

Chronogramme associé Le chronogramme de la gure 3.22 présente le

Figure 3.22 Début du codage(4,144)

Figure 4.1 Etapes d'implémentation d'un circuit logique sur FPGA

Figure 4.2 Shéma de l'architecture globale

Figure 4.4 Architecture du bloc_coder

Le logic_control commande la machine d'états nis et gère le bon fonction-

Figure 4.5 Architecture du logic_control

Figure 4.6 Diagramme d'activité du premier processus du logic_control

Figure 4.9 Diagramme d'activité du quatrième processus du logic_control

Ce composant représente la machine d'états nis, il gère le déroulement des

Figure 4.10 Architecture de l'FSM

Figure 4.11 Machine d'états nis du bloc FSM

Prepar_iram : à l'activation du signal start, l'état courant idle passe à

First_step_cyc : si enable_cyc est enclenché, l'état courant prepar_iram

Figure 4.13 Diagramme d'activité de l'état Second_step

Figure 4.14 Diagramme d'activité de l'état Convolutif

First_step_LFSR : si enable_mseq est activé, state_next prend rst_step_LFSR

Figure 4.15 Diagramme d'activité de l'état First_step_LFSR

Figure 4.16 Diagramme d'activité de l'état Second_step_LFSR

Figure 4.18 Architecture du regs-sup-64

Figure 4.19 Diagramme d'activité du premier processus du regs_sup_64

Figure 4.20 Diagramme d'activité du deuxième processus du regs_sup_64

Figure 4.22 Architecture interne de W_ram

Figure 4.24 Simulation avec Modelsim de CRC(7,4)