UN RART pour UN FPGA

Implémentation d’un UART sur FPGA
pour des Applications en Systèmes Embarqués
H.Bessalah, M.Issad, L.Mahiddine, K.Messaoudi, N.Anane, M.Anane (*)
Centre de Développement des Technologies Avancées CDTA
Cite 20 Août, Baba Hassen Alger, Algérie
(*)
Institut National d’Informatique, Oued Smar, Alger
Fax:+213 21.35.10.39, email : [email protected]
Résumé -. Dans cet article, nous présentons
l’implémentation sur un circuit FPGA de Xilinx
d’une interface de communication de type RS232
qui permet le transfert bidirectionnel de données
avec une application externe. Cet UART
(Universal Asynchronous Receiver/ Transmitter),
est développé sur la carte de prototypage
V2MB1000 de Memec.
Les résultats de l’implémentation de cet UART
ont révélé un débit maximum qui peut atteindre
un débit de 5 Mbps et un taux d’occupation de
1%. Le fonctionnement réel de cet UART a été
vérifié par un test physique.
Mots clés : UART, Protocole RS232, FPGA,
Viretx-II.
I. INTRODUCTION
De nos jours, grâce aux spectaculaires
avancées qu’a connu la technologie de
fabrication des circuits intégrés, et notamment
celle des FPGAs, de nombreuses applications
complexes qui relèvent du domaine du traitement
de signal numérique ont pu voir le jour. Parmi
ces dernières, on peut citer : la téléphonie mobile,
la sécurisation des données, etc. Dans leur
majorité, ces applications sont développées soit à
base de microcontrôleurs, de microprocesseurs
ou encore de circuits logiques complexes.
Cependant, l’utilisation de ces composants dans
un système, quel qu’il soit, exige un protocole de
communication. Les protocoles développés à ce
jour sont divers et chacun est conçu pour une
application bien définie. A titre d’exemple, les
normes RS232 et I2C sont très recommandées
pour des applications qui ne nécessitent pas un
flot de données important, car ces dernières sont
des normes de type série.
Dans cet article, on s’intéresse en particulier à la
norme RS232 en vue d’établir une liaison de
communication pour l’échange des données entre
un processeur externe et la carte de
développement de Memec V2MB1000 qui
comporte un circuit FPGA de Xilinx, en
l’occurrence, le circuit XC2V1000-4FG456C.
L’utilisation d’un circuit FPGA sur cette carte, en
tant que cœur de traitement des données, exige la
présence de cet UART qui joue le rôle
d’interface entre le port RS232 et la logique
interne implémentée sur le circuit FPGA. En
effet, la carte V2MB1000 [1] est dédiée
originellement à la conception des systèmes on
chip (SoC) à base du microprocesseur
Microblaze [2]. Cependant, l’implémentation de
tels systèmes sur le circuit XC2V1000-4FG456C
donne lieu souvent à un taux d’occupation de
surface plus ou moins élevé. A titre d’exemple, si
l’on désire implémenter sur ce circuit une
application, le majeur parti de la surface est
consommé par le système pour les besoins de la
gestion des entrées/sorties de l’application. Ce
qui est insuffisant pour l’implémentation
d’applications complexes. En conséquence, nous
présentons dans cet article, la conception et la
réalisation d’un IP1 sous forme d’interface
UART destiné à résoudre le problème de
l’occupation de surface engendré par l’utilisation
du SoC. Un tel UART permet à l’application de
gérer ses entrées/sorties avec un processeur ou
une application externe à moindre coût en terme
de ressources, puisque ces dernières ne sont pas
utilisées par le SoC pour l’exécution de cette
tâche (transfert de données). A titre d’exemple,
une application d’addition de deux opérandes de
8 bits récupérés à partir d’un ordinateur sur le
port RS232 en utilisant notre UART consomme
seulement 1 % des ressources, alors que la même
application, utilisant le processeur Microblaze
qui gère l’environnement SoC du FPGA, occupe
23 % de la surface du circuit.
Cet UART est caractérisé par une indépendance
vis-à-vis de la taille des données et du débit de
transfert, c'est-à-dire, un IP générique et
reconfigurable. Des UARTs équivalents ont aussi
été développés par de grands fabricants de
circuits FPGA, en l’occurrence Xilinx [3] et
Altera [4].
1
Intellectual Property.
Cet article est organisé comme suit : dans la
section 2, un bref aperçu sur le protocole de
communication RS232 est donné. En section 3,
nous présentons la description de cet UART. La
section 4 présente le cycle de conception et les
résultats obtenus de l’implémentation.
II. LE PROTOCOLE RS232 ET LA LIAISON DE
COMMUNICATION FPGA-DB9
La liaison RS232 est de type série
asynchrone, c’est à dire qu’elle ne nécessite pas
de signal d’horloge pour la synchronisation de
deux systèmes en communication [5]. Il est donc
nécessaire que ces derniers soient configurés de
la même manière. Il est à noter que sur la carte de
prototypage V2MB1000, seulement trois pins du
port série sont utilisés. Les pins en question
sont [1]:
 La pin 2 : c’est la pin par laquelle la carte
envoie des données.
 La pin 3 : c’est la pin par laquelle la carte
reçoit des données.
 La pin 5 : masse commune.
Pour assurer une meilleure synchronisation entre
les deux systèmes, leurs configurations doivent
être identiques. Cette configuration est basée sur:
le débit du transfert, la taille de la donnée et
quelques bits de contrôle. Les débits de
transmission les plus courants sont : 300, 600,
1200, 4800, 9600,19200, 38400, 57600 et
115200 bps (bits par second). Le transfert de
l’extérieur vers la carte ou vice-versa se fait par
l’envoi d’un paquet de 5, 6, 7 ou 8 bits en série et
auxquels sont rajoutés quelques bits de contrôle.
La totalité de ces bits constituent une trame de
donnée. Au repos, la ligne de transmission est
mise à l’état haut. Lorsque l’un des deux
systèmes veut commencer à communiquer, il
prévient l’autre par un premier bit à zéro : c’est le
bit start. Viennent ensuite les bits de données. Un
second bit de contrôle peut être rajouté, il s’agit
du bit de parité. Après le bit de parité, suivent un
ou deux bits stop qui, à travers lesquels,
l’émetteur indique au récepteur que la trame est
terminée. Dans ce travail, le bit stop est
représenté avec
un seul bit. Un schéma
significatif d’une trame est montré sur la figure
1.
Fig.1 : Trame de donnée
III. DESCRIPTION DE L’UART
L’UART est constitué principalement de
deux modules, à savoir :
 Un émetteur de données qui reçoit ces
dernières en parallèle et les transmet en série
vers l’extérieur. L’émetteur est souvent
connecté au bus d’une architecture interne.
 Un
récepteur qui n’est autre qu’un
convertisseur série–parallèle.
L’émetteur et le récepteur partagent une même
horloge globale fclk, délivrée par un quartz de la
carte V2MB1000. Par ailleurs, pour atteindre un
des débits que nous avons cité auparavant et qui
va correspondre aux horloges de transmission et
de réception, nommées respectivement txclk et
rxclk, la fréquence fclk du quartz doit passer par
deux diviseurs de fréquence.
Le premier est caractérisé par une constante C ;
celle-ci nous permet de passer de la fréquence
fclk à une fréquence d’une horloge intermédiaire
nommée mxclk. Cette dernière, considérée
comme étant une horloge globale du système, est
introduite dans le but de concevoir un UART
normalisé [1], [2], [6]. Le second diviseur est
défini par une autre constante égale à 16. Cette
dernière correspond au passage de l’horloge
mxclk aux horloges rxclk et txclk. De ce fait,
l’expression correspondante au débit de l’UART
est donnée par la formule suivante [7]:
BR = fclk / (C x 16) bps.
Pour un débit de 115200 bps et pour une
fréquence du quartz de 100 Mhz, le calcul de la
constante C se fait comme suit :
C = fclk / (BR x 16) = 100 x 106/(115200 x 16) =
54,253.
Celle-ci peut être approximée à C= 54. D’après
la valeur finale de C, le débit de l’UART ne
correspond pas directement à la valeur du débit
réel, mais avec une certaine erreur. L’influence
de cette erreur sur le temps d’exécution d’une
trame peut être décrit comme suit :
Pour C=54, le débit de l’UART est de :
BR = 100 x 106/ (54 x 16)= 115740,74 bps.
Il en résulte une période de 8,64 s. Ainsi, le
délai d’une trame sera de : 11 bits x 8,64 = 95, 04
s (11 bits correspond à la taille d’une trame
avec un bit stop).
De ce fait, le délai des 11 bits associé au débit
réel est : 11 bits x 8,68 = 95, 48 s. Soit une
erreur de 0,44 s. Cette dernière n’affectera en
aucun cas les 8 bits de données puisque c’est le
bit stop qui sera perturbé.
La description des signaux d’entrées/sorties de
cet UART peut se résumer en les points
suivants :
GRS : signal d’initialisation système.
clk : l’horloge fournie par le quartz.
Rx : l’entrée série des données. Ce signal est
forcé à ‘1’ quand il n’y a pas de transmission.
Write : active à l’état bas, utilisé pour valider le
chargement parallèle d’une donnée dans le
module de transmission.
Din : bus de données, de taille 8 bits. Les
données provenant de l’architecture d’une
application sont transmises sur ce bus.
rxdone : ce signal par son état haut, permet de
valider la fin de la réception d’une donnée.
Dout : bus de données, de taille 8 bits. Ce bus
transmet les données en mode parallèle vers une
application.
Tx : signal de transmission série des données vers
la sortie de la carte. Ce signal est forcé à ‘1’
quand il n’y a pas de transmission.
Dout
Rx
8
module de réception
rxdone
Reset
Din
Tx
Reset
clk
GRS
module de
transmission
generateur
de mxclk
8
write
mxclk
Reset
Fig.2 : Architecture de l’UART
B. Module de réception :
Le schéma bloc de ce module est montré sur
la figure 3. Ce dernier est constitué d’un registre
à entrée série et sortie parallèle sensible au front
montant de l’horloge rxclk, d’un registre à entrée
et sortie parallèles qui permet de recevoir la
donnée une fois qu’elle est complètement reçue
dans le premier registre et d’une unité de
contrôle.
Ce module reçoit en entrée sur l’entrée Rx du
premier registre, les données en série et fournit
ces dernières en parallèle sur le bus Dout. Son
fonctionnement peut se résumer en les points
suivants :
 Initialisation: ce module est au repos quand
le signal GRS est à l’état bas.
 Détection du front descendant du bit start.
 Validation du bit start à son milieu après huit
tops de l’horloge mxclk et génération de
l’horloge rxclk.
 Décalage à droite des bits en entrée.
 Détection du bit de parité et transfert de la
donnée en parallèle vers le registre rh_registre.
 Détection du bit stop, remise du module au
mode d’initialisation et attente d’un prochain bit
start d’une nouvelle donnée. La transmission
interne sur le bus Dout d’une donnée est suivie
parallèlement par une impulsion sur la sortie
nommé rxdone.
Rx
N_rsr
rs_registre
8
Reset
CE
unité de
contrôle
mxclk
GSR
rxdone
stop_bit
rh_registre
A. Architecture de l’UART :
Le schéma synoptique de l’UART développé
dans ce travail est montré sur la figure 2. Celui-ci
est composé de :
i -Un module de réception qui fait la
conversion série-parallèle des données
provenant du port RS232.
ii -Un module de transmission dont la tâche est
de réaliser l’opération inverse, c'est-à-dire le
transfert série vers le port RS232 d’un résultat
issu d’une application en mode parallèle.
iii -Un diviseur de fréquence, qui assure la
génération de l’horloge mxclk à partir de la
fréquence fclk.
Dout
8
Reset
Fig.3 : Schéma bloc du module de réception
C. Unité de contrôle de la réception :
L’unité de contrôle permet de générer
l’horloge rxclk, la validation du transfert de la
donnée au registre rh_registre et la détection du
bit de parité et du bit stop. La circuiterie interne
de cette unité est montrée sur la figure 4. Cette
dernière est composée de :
Deux compteurs (1 et 2) de quatre bits
chacun, d’un registre de contrôle de taille 9 bits
et d’un troisième compteur sensible au front
montant de l’horloge mxclk. Le premier
compteur assure la détection du milieu du bit
start par la génération d’un signal nommé
detection. Ce signal est à l’état bas durant
l’initialisation et passe à l’état haut dès que le
milieu du bit start est détecté. Le second
compteur permet la génération de l’horloge rxclk
quand le signal detection bascule vers l’état haut.
Le registre de contrôle se comporte de la même
manière que le registre rs_registre sauf que
celui-ci, au repos, est initialisé par la valeur
'1'
registre de contôle
011111111
Reset
'1'
rxdone
rxclk
CE
mxclk
GSR
Reset
detectoin
compteur1
Rx
compteur2
compteur3
Reset
Reset
stop_bit
Fig.4: L’unité de contrôle de la réception
D. Module de transmission :
Ce module possède un bus d’entrée Din de
taille 8 bits, sur lequel le bus de donnée de
l’application est connecté et une sortie Tx qui
assure la transmission série des données. Le
module en question exige un certain contrôle de
la part de l’application pour indiquer la présence
d’un résultat. Pour ce faire, une impulsion doit
être générée par cette dernière à chaque fois
qu’une nouvelle donnée est délivrée sur sa sortie.
L’impulsion en question est envoyée vers ce
module sur un l’entrée write. Comme pour la
réception, la transmission doit respecter le
protocole de communication ; c’est à dire, avant
le transfert de la donnée en série la trame doit
commencer par un bit start et se terminer par un
bit de parité et un bit stop.
D’une manière générale, le fonctionnement du
module de transmission peut se résumer en les
points suivants :
 L’initialisation du module. Celui-ci est au
repos quand le signal write est à l’état bas.
 Chargement parallèle de la donnée dans le
transmetteur au front montant du signal write.
 Vérification interne du transfert de la donnée
de l’application vers le module de transmission.
 Génération de l’horloge de transmission
txclk.
 Chargement interne de la donnée.
 Sélection du bit start.
Décalage à gauche de la donnée et sélection
du bit de parité.
 Sélection du bit stop et initialisation interne.

Le schéma synoptique de ce module est montré
sur la figure 5. Ce dernier est composé d’une
unité de chargement, d’une unité de transmission
et d’une unité de contrôle qui assure la
synchronisation de ce module.
La première unité permet d’effectuer le
chargement parallèle d’une donnée issue d’une
application. Celle-ci est composée de deux
registres parallèles et d’un comparateur. Ces
registres sont sensibles au front montant de
l’horloge mxclk. Le premier reçoit la donnée sur
l’entrée Din du module. Ensuite, cette dernière
est transférée au second registre au prochain
front montant de l’horloge mxclk. Le transfert en
question est effectué dans le but de comparer le
contenu des deux registres pour une éventuelle
détection des bruits. Ainsi, à chaque fois qu’une
nouvelle donnée se présente sur l’entrée du
module de transmission, une impulsion est
générée sur la sortie du comparateur qui est
véhiculée sur un signal nommé txdatardy.
La tâche de l’unité de transmission est de
constituer une trame de donnée et sa transmission
série en sortie. Cette unité est constituée d’un
registre ts_registre à entrée parallèle et sortie
série et d’un multiplexeur. Ce dernier permet
grâce aux bits de sélection sel (3 :0), générés par
l’unité de contrôle, d’arranger une trame de
donnée. Le registre ts_registre est sensible au
front montant de l’horloge txclk. Le chargement
parallèle de la donnée dans ce registre est
commandé par un signal txdone actif à l’état
haut. Ce signal est généré aussi par l’unité de
contrôle. Ainsi, une fois le chargement de la
donnée dans ce registre est terminé, cette
dernière sera décalée vers la gauche à chaque
front montant de l’horloge txclk.
N_thr
8
Tx
unité de transmission
load
Reset
4
sel
txclk
txdone
unité de
contrôle
Reset
mxclk
txdatardy
unité de chargement
‘011111111’. Ainsi, pendant que le registre
rs_registre décale les bits de la donnée, le
registre de contrôle fait décaler des ‘1’ logiques.
Son rôle réside dans la génération du signal
rxdone qui passe à l’état haut quand le ‘0’
logique qui se trouve dans son bit du poids fort
arrive au poids faible. Il est à signaler que ce ’0’
est synchronisé avec le bit start. La détection en
question est effectuée par l’utilisation d’une porte
xor. Le compteur (3) de taille 8 bits permet
d’indiquer la présence du bit stop par la
génération d’une impulsion. Cette dernière est
obtenue sur un signal nommé stop_bit.
Din
8
mxclk
Reset
write
GRS
Fig.5: Schéma bloc du module de la transmission.
E. Unité de contrôle de la transmission :
Cette unité assure la génération de l’horloge
de transmission txclk, la synchronisation de la
trame et la sélection des bits qui la constituent.
En effet, les tâches en question sont effectuées
séparément par deux compteurs différents (1) et
(2). Cette unité reçoit sur ses entrées le signal
Write, dont la tâche est l’initialisation des deux
compteurs, et l’horloge mxclk.
Le schéma synoptique de cette unité est montré
sur la figure 6.
txclk
nécessitent un ensemble d’outils pour générer le
fichier de configuration (le bitstream).
Cependant, avant de parvenir à ce dernier, toute
implémentation sur ce type de circuit nécessite le
passage par un flot de conception complet. Ce
flot qui est montré sur la figure 7 incluant : la
description de l’architecture, la synthèse, le
placement et routage et
un ensemble de
simulations.
txdone
compteur
(1)
4
compteur
(2)
sel(3:0)
mxclk
Reset
write
Fig.6 : L’unité de contrôle de la transmission
Son fonctionnement peut être décrit comme suit :
Quand le signal Write est à l’état bas, cette unité
est mise au repos. Au front montant de ce signal,
le premier compteur devient actif et entame la
génération de l’horloge txclk (txclk= 16 mxclk).
Le second compteur, quant à lui, est sensible au
front montant de l’horloge txclk. Donc, grâce à
ses sorties sel(3 :0), le bit start, la donnée, le bit
de parité et le bit stop seront sélectionnés
respectivement en série sur le signal Tx. La
sélection des bits d’une trame en fonction des
sorties du compteur (2) est montrée sur le tableau
1.
Tab.1 : Table de vérité de la sélection des bits d’une trame
Sel (3:0)
0000
0001
0010
0011
0100
0101
0110
0111
1000
1001
1010
Tx = bit sélectionné
Bit stop
Bit start
D(0)
D(1)
D(2)
D(3)
D(4)
D(5)
D(6)
D(7)
Bit de parité
IV. CYCLE DE CONCEPTION ET RESULTATS
D’IMPLEMENTATION
L’UART développé dans ce travail a été
conçu d’une manière générique et paramétrable
afin qu’il soit réutilisable. Cette option a été
rendue possible grâce à l’utilisation du langage
VHDL qui offre l’avantage de la description
hardware. L’utilisation et l’exploitation du FPGA
Fig.7 : Flot de conception sur FPGA
L‘application de ce flot sur cet UART peut
être décrite comme suit : après une description
comportementale en VHDL de chaque unité et
module, une synthèse est exécutée sur
l’architecture globale. Cette étape n’est autre
qu’une transformation de l’UART pour chaque
cycle d’horloge en un ensemble d’équations
booléennes. On parle ainsi du niveau RTL
(Register Transfert Level). Le résultat obtenu de
la synthèse sous forme d’une netlist est optimisé
et transformé en une autre netlist de blocs
logiques qui sera placée/routée sur le circuit
utilisé : le XC2V1000-4FG456C.
Par ailleurs, vu l’emplacement précis de quelques
signaux d’entrée/sortie, en l’occurrence le reset
système, l’horloge et les signaux de
communication Tx et Rx, nous avons défini un
fichier de contrainte (*.ucf) qui porte leurs
emplacements conformément au datasheet de la
carte V2MB1000 [1].
Le développement de cet UART suivant ce flot
de conception a été réalisé sur l’environnement
ISE 7.1i de Xilinx. Ce dernier inclut l’outil XST
qui permet d’effectuer la synthèse, le placement
et le routage de l’architecture globale. Les
résultats concernant les surfaces occupées en
terme de slices de cette implémentation sont
donnés dans le tableau 2.
Le layout de notre UART sur le circuit
XC2V1000-4FG 456C est montrée sur la figure
8.
Tab.2 : Surface occupée
Récepteur
Emetteur
UART
Nombre de slices
33
28
62
Taux d’occupation
1%
1%
1%
Fig.8: Layout de l’UART sur FPGA
A la fin de l’implémentation, une analyse
temporelle a été effectuée afin de déterminer les
performances temporelles de cet UART. A cet
effet, l’outil timing analyser a révélé une horloge
mxclk d’utilisation minimum qui est de 11 ns. Ce
qui correspond à une fréquence fmxclk= 90 Mhz.
De ce fait, le débit maximum que peut atteindre
cet UART est limité à 5 Mbps. Pour compléter ce
flot de conception, le fonctionnement correct de
cet UART a été validé par des simulations à
différents niveaux d’abstraction. Cette opération
a été effectuée à partir d’un fichier de test que
l’on nommera test-bench et a été réalisée par
l’utilisation de l’outil de simulation Modelsim PE
6.0. Les résultats de simulation temporelle sont
montrés sur la figure 9.
start_bit de la
trame reçue
start_bit de la
trame reçue
mxclk
Rx
GRS
rxdone
write
Tx
txclk
start_bit de la
trame transmie
start_bit de la
trame transmie
Fig.9 : Simulation temporelle de l’UART
Un test physique de notre UART a été effectué
concernant le fonctionnement réel. C'est-à-dire
après l’avoir chargé sur carte. Ce test a donné des
résultats satisfaisants. L’application qui a servi
pour effectuer ce test est une addition modulaire
qui consiste à additionner deux opérandes de 64
bits. Ces opérandes sont récupérés d’un PC
externe via l’UART développé.
V. CONCLUSION
Dans cet article, nous avons présenté un
UART dédié à l’acquisition des données en
temps réel entre le port RS232 d’un ordinateur et
le circuit FPGA XC2V1000-4FG456C de la carte
V2MB1000. L’architecture développée et son
implémentation sur le circuit FPGA ont été
détaillées. Nous avons aussi présenté toute la
méthodologie utilisée pour l’implémentation de
ce composant et les différents résultats obtenus.
Afin de vérifier son fonctionnement, notre
UART été validé par des simulations
fonctionnelles et temporelles et par un test
physique. En terme de performance, l’analyse
temporelle a révélé que notre UART peut
fonctionner avec une fréquence maximum de 5
Mhz. L’application pour laquelle cet IP a été
développé
est
un
système
embarqué
d’authentification qui nécessite un transfert de
données sécurisé, sur un port RS232, d’une carte
à puce vers la carte V2MB1000 via un PC
embarqué. L’application associée à ce module
sur le circuit FPGA, renvoie des données de
calcul (cryptage, arithmétique modulaire) à
travers cet IP vers l’ordinateur externe.
BIBLIOGRAPHIE
[1] “Virtex-II, V2MB1000 Development board
user guide”, Memec Design, Version 3.0,
December 2002.
[2] Embedded magazine, “Configure and Build
the Embedded Nucleus PLUS RTOS Using
Xilinx EDK” P 27-28. March 2005.
[3] Xilinx Application Note: CoolRunner CPLD,
“IrDA and UART Design in a
CoolRunner
CPLD” ,XAPP345 (v1.3), December 23, 2003.
[4] Altera, “UART Core”, Quartus II Handbook,
Volume 5, October 2007.
[5]Http://www.tavernier-c.com/serie.htm.
[6] Thomas Oelsner, QAN20 “Digital UART
Design in HDL”, Quick Logic Europe.
[7] M.Delvai, U.Eisenmann, W.Elmenreich
“Intelligent UART Module for Real-Time
Applications”, First Workshop on Intelligent
Solutions in Embedded Systeme (WISES),
Vienna University of Technology, Austria, June
2003.