6
Implémentation d’un UART sur FPGA Pour des Applications en systèmes embarqués Hamad DAHOU 1 , Khalid MATEUR 1 ,Rachid EL GOURI 1,2 , Hlou LAAMARI 1 1 Laboratoire de Genie Electrique et Systèmes Energétiques Faculté des Sciences Kenitra , Email : [email protected] 2 Ecole 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

Implémentation d’un UART sur FPGA Pour des …science-conferences.net/wits2014/proceeding/POSTERS/24-H-DAHOU.… · Lutilisation dun circuit FPGA sur cette carte, en tant que cœur

  • Upload
    vuquynh

  • View
    213

  • Download
    0

Embed Size (px)

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 : [email protected] 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.