View
213
Download
0
Category
Preview:
Citation preview
Implémentation d’un UART sur FPGA
Pour des Applications en systèmes embarqués
Hamad DAHOU1, Khalid MATEUR
1,Rachid EL GOURI
1,2, Hlou LAAMARI
1
1Laboratoire de Genie Electrique et Systèmes Energétiques
Faculté des Sciences Kenitra , Email : hamad.dahou@gmail.com 2Ecole National des Sciences Appliquées,université ibn tofail kénitra
Résumé - Dans cet article, nous présentons
l’implémentation d’une interface de communication de
type RS232 sur un circuit FPGA de Xilinx, 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, comme dans les
réseaux capteurs, 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 SPARTAN3E-500
GF320. 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
SPARTAN3E-500 GF320 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].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é.
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.
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.
module de réception
RxDout
8
Reset
clk
GRSReset
generateur
de mxclk
mxclk
rxdone
module de
transmission
Tx8
Din
Resetwrite
rs_registre
Rx
N_rsr
8Reset
8
Dout
GSR
mxclk
rh_
reg
istr
e
stop_bit
rxdone
CE
Reset
unité de
contrôle
'1'
stop_bit
rxdone
Reset
compteur3
GSR
mxclk
Reset
Rx
Reset
CE
compteur1
de
tecto
in
compteur2
Reset
registre de contôle
011111111
'1'
rxclk
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.
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.
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 ‘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.
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.
unité de transmission
N_thr8
Reset 8
Din
sel
txclk unité de
contrôle
Reset
un
ité d
e c
ha
rge
me
nt
txdone
write
mxclk
Reset
GRS
Tx
mxclk
load
4
txdatardy
mxclk
Reset
write
co
mp
teu
r
(2)
co
mp
teu
r
(1)
txclk
sel(3:0)
4
txdone
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.
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.
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) Tx = bit sélectionné
0000 Bit stop
0001 Bit start
0010 D(0)
0011 D(1)
0100 D(2)
0101 D(3)
0110 D(4)
0111 D(5)
1000 D(6)
1001 D(7)
1010 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 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.
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é :
SPARTAN3E-500 GF320.
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
SPARTAN3E-500 GF320 est montrée sur la figure 8.
Tab.2 : Surface occupée
Nombre de slices Taux d’occupation
Récepteur 33 1%
Emetteur 28 1%
UART 62 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 transmie
start_bit de la
trame transmie
start_bit de la
trame reçue
GRS
mxclk
Tx
write
rxdone
Rx
txclk
start_bit de la
trame reçue
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
SPARTAN3E-500 GF320 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.
Recommended