Conception d’un récepteur RS-232

Tronc Commun 1A PET

Sylvain Huet, Dominique Houzet, Laurent Aubard, Mathias Voisin-Fradin
PHELMA
8 novembre 2020

1 Objectif du TP
Lors de ces deux séances de travaux pratiques, vous vous intéresserez à la conception d’un récepteur de données
série asynchrone RS-232 et à son implantation sur un FPGA. Cet exemple permet d’illustrer le cours de logique
dans son ensemble et de mettre en application la démarche de conception par séparation de la partie opérative et de
la partie commande.
Etant donné le nombre d’heures consacré au TP, vous n’aurez pas à réaliser la totalité de la conception. La
spécification du circuit à l’aide d’une machine à états qui manipule des variables vous est donnée. L’interface entre
les parties commande et opérative vous est imposée et vous aurez à compléter ces deux parties. Pour faciliter la
réalisation, nous vous fournissons un projet Quartus à compléter et des bancs de test (testbench), permettant de
valider le système.
En travail de préparation, nous vous demandons de définir les éléments de la partie opérative permettant
d’implanter certaines variables (sections 4.1.3 et 4.1.4) et de compléter et synthétiser la machine à état de la
partie commande (section 4.2).
La suite du document est organisée comme suit. La section 2 définit le cahier des charges du système à concevoir.
La section 3 présente les spécifications de ce système. La section 4 s’intéresse à l’implantation de la fonction de
réception par séparation de la partie opérative et partie commande. Enfin, avant de conclure la section 5 donne la
démarche que vous allez suivre pour implanter ce récepteur série asynchrone sur notre cible FPGA.

2 Cahier des charges

L’objectif est de concevoir un système de réception de données transmises en série sans synchronisation qui
respecte la norme RS-232 (des informations complémentaires sur ce type de transmission sont données en annexe).
La valeur des données reçues, sans erreur, sont à afficher en hexadécimal sur deux afficheurs 7 segments. Une led
est allumée en cas d’erreur de transmission, c’est-à-dire une erreur de start de parité ou de stop.
Les données sont transmises au circuit au travers de trames qui sont composées :
— d’un bit de start,
— de 8 bits de données,
— d’un bit de parité, la parité paire est utilisée, i.e. l’émetteur positionne le bit de parité de manière à ce que
le nombre de 1 contenu dans les 8 bits de donnée et le bit de parité soit pair, ce qui permet de détecter un
nombre impair d’erreur de transmission,
— d’un bit de stop.
Le chronogramme présenté sur la figure 2.1 présente la structure d’une telle trame pour l’envoi de l’octet 0x39 1 .
1. Similairement au langage C, nous utilisons le préfixe 0x désigner un nombre en notation hexadécimale

1
 F IGURE 2.1 – Exemple de trame

La vitesse de réception sera 9600 bauds. La transmission se fait sans contrôle de flux (cf. annexe), aussi bien
logiciel (Xon/Xoff) que matériel (CTS/RTS).
La validation finale du circuit est faite en connectant le système conçu à la liaison RS-232 du pc de développement.
Un programme appelé terminal, exécuté sur le PC, sera utilisé pour transmettre par la liaison série du PC le code
ascii 8 bits des caractères tapés au clavier. La valeur hexadécimale des codes ascii reçus sera affichée sur 2 afficheurs
7 segments et les erreurs détectées seront signalées par l’allumage de la led d’erreur. Des erreurs pourront être
provoquées en jouant sur le paramétrage de la transmission avec le programme terminal.
Ce système est à implanter dans le FPGA de la carte DE1 d’Altera. La figure 2.2 montre l’environnement du circuit
à concevoir. L’entrée série, rxd proviendra du connecteur DB9 de la carte. En outre, un circuit d’adaptation de
niveau MAX232 est câblé sur ce connecteur. Ce circuit réalise une adaptation de niveaux -12V, +12V, utilisés
par la liaison série, vers des niveaux logiques compatibles avec le FPGA. Ce signal est transmis au circuit via la
broche PIN_F14 du FPGA. Le fonctionnement du circuit serra cadencé par une horloge 24 Mhz qui arrive sur la
broche PIN_A12. Nous avons opté pour l’utilisation du bouton poussoir KEY0, câblé sur la broche PIN_R22,
pour l’initialisation du système (le reset). La led LEDR9, broche PIN_R17, est utilisée pour signaler une erreur.
L’afficheur 7 segments HEX0 est utilisé pour afficher les poids faibles de l’octet reçu, HEX1 pour ses poids forts.

3 Spécifications du système à concevoir

La figure 3.1 présente l’architecture du système à concevoir. Elle fait apparaître deux parties distinctes :
1. le circuit de réception,
2. un circuit d’interface qui permet d’afficher la valeur des 8 bits de data_mem, dernière valeur reçue valide,
en hexadécimal sur deux afficheurs 7 segments.

F IGURE 2.2 – Le système à concevoir au sein de la carte DE1

2
 F IGURE 3.1 – Architecture du système à concevoir

Intéressons nous maintenant au circuit de réception qui constitue le coeur du système. Celui-ci réalise la
réception série asynchrone selon une technique classique qui consiste à détecter le bit de start, pour nous un front
descendant sur la ligne de transmission, puis à enclencher un dispositif qui échantillonne la ligne de transmission au
milieu de chacun des bits, cf figure 3.2. Des vérifications sur la validité de la trame sont faites en cours de réception
(validité du bit de start, du bit de parité et du bit de stop).

F IGURE 3.2 – Illustration du principe de réception

La machine à état finis présentée figure 3.3 formalise ce comportement. La nature, les noms et types de données
utilisés pour la définition de cette machine sont présentés dans le tableau 1.

nature nom type commentaire

variable d’entrée rxd boolean ligne de transmission
variable de sortie data_mem array[0..7] of boolean valeur affichée sur les aff. 7 seg.
variable de sortie err boolean bit d’erreur, pilote la led d’err.
variable t time compteur de temps
variable err_parite boolean indique s’il y a une erreur de parité
variable i integer range 0..7 compteur des bits reçus
variable data array[0..7] of boolean tampon des bits recus
constante DB time := 1/9600 durée d’un bit

TABLE 1 – Définition des types de données utilisés pour la spécification du système à concevoir

3
 rxd = 1

Attente
start

rxd=0 t=DB/2 and rxd=1

t:=0 err:=1;

Attente
milieu t! = DB/2
start

t=DB and err _parite t=DB/2 and rxd=0

err:=1; t:=0;i:=0;

t! = DB

t=DB and rxd=1 Reception t=DB and rxd=0

err:=0;data_mem:=data; données err:=1;

t=DB and i<7

data[i]=rxd;i=i+1;t:=0;

t=DB and i=7

data[i]=rxd;t:=0;

Attente
t! = DB
parité

t=DB and not err _parite

t:=0;

Attente
stop

t! = DB

F IGURE 3.3 – Spécification du principe de la réception

4
4 Conception de la fonction de réception par séparation des parties opé-
rative et commande
Cette étape de conception consiste à déterminer une solution d’implantation sous la forme d’une partie opérative
et d’une partie commande de la fonction de réception exposée dans la section 3.

4.1 Définition de la partie opérative de la fonction réception

La partie opérative est le sous ensemble du système qui réalise les opérations sur les variables de la machine à
état qui manipule des variables, e.g. opérations arithmétiques, comparaison, initialisation, mémorisation . . . Elle
se construit en recherchant toutes les variables de la machine à états avec variables de la fonction réception, cf.
section 3 et en identifiant les opérations réalisées sur chacune. Cela permet d’en déduire une solution d’implantation.
Les différents signaux de contrôle de la partie opérative sont pilotés, testés par la partie commande. Les sections
suivantes présentent les différents éléments de la partie opérative.

4.1.1 Implantation de la variable de comptage t

La variable t est chargée de mesurer du temps. Elle est donc implantée à l’aide d’un compteur. Deux stratégies
sont envisageables, soit t est géré en comptage soit en décomptage.
En comptage, t est remis zéro à chaque début de bit et est comparé avec DB/2 pour l’échantillonnage du milieu
du bit de start et DB pour l’échantillonnage des autres bits de la trame. Cela nécessite la mise en oeuvre d’un
multiplexeur 2-> 1 et d’un comparateur d’une largeur égale au nombre de bits nécessaires à la représentation de
DB.
En décomptage, t est chargé soit avec la valeur DB/2 soit DB, ce qui nécessite l’emploi d’un multiplexeur 2->1
qui est connecté à l’entrée de chargement du compteur. L’échantillonnage du bit se fait lorsque le compteur sera à
zéro. Les compteurs ont classiquement des sorties qui donnent cette information. Nous allons implanter la solution
décomptage, elle permet d’économiser un comparateur.
L’horloge choisie pour le système est 24 Mhz donc DB = 24.106 /9600 = 2500 et DB/2 = 1250.
La figure 4.1 donne le schéma de principe du comptage du temps. Le tableau 2 précise l’interface de ce dispositif.

direction nom type commentaire

entrée clk boolean horloge du système
entrée rst boolean initialisation du système
entrée t_ld boolean commande du chargement du compteur
entrée db_sel boolean sélection de la durée présentée sur l’entrée
de chargement du compteur
sortie t_zero boolean indique le passage à zéro du compteur

TABLE 2 – Implantation de la variable de comptage t

F IGURE 4.1 – Implantation de la variable de comptage t

5
4.1.2 Implantation de la variable de comptage i
La variable i est implantée à l’aide d’un compteur. De la même manière que pour la variable t, il est possible
d’utiliser soit un compteur, soit un décompteur. Pour les mêmes raisons, nous utilisons un décompteur. i varie de 7
à 0, ce qui nécessite un compteur 3 bits avec une valeur de chargement égale à 7.
La figure 4.2 donne le schéma de principe du comptage du temps. Le tableau 3 précise l’interface de ce dispositif.

direction nom type commentaire

entrée clk boolean horloge du système
entrée rst boolean initialisation du système
entrée i_ld boolean commande du chargement du compteur
entrée i_dec boolean commande de décrémentation du compteur.
Cette entrée est nécessaire pour décrémen-
ter le compteur à chaque bit reçu et non sur
chaque front d’horloge
sortie i_zero boolean indique le passage à zéro du compteur

TABLE 3 – Implantation de la variable de comptage i

F IGURE 4.2 – Implantation de la variable de comptage i

4.1.3 Implantation des variables data et data_mem

Le tableau 4 précise l’interface de ce dispositif et la figure 4.3 sa structure. Complétez la colonne commentaire
du tableau 4 puis identifiez les 2 composants nécessaires à l’implantation des variables data et data_mem. La
variable data est utilisée pour mémoriser chacun des 8 bits d’information reçus qui arrivent en série (opération
data[i] = rxd de la figure 3.3). Ces 8 bits d’information sont mémorisés dans data_mem lorsqu’une trame
correcte a été reçue (opération data_mem := data de la figure 3.3), ce qui permet de n’afficher que les octets reçus
valides sur les 2 afficheurs 7 segments. Remarque : la variable data est une variable interne à la partie opérative.
data_sh rst clk data_ld rst clk

rxd data data_mem

8 8

? ?

F IGURE 4.3 – Implantation des variables data et data_mem

6
 direction nom type commentaire
entrée clk boolean
entrée rst boolean
entrée rxd boolean
entrée data_sh boolean
entrée data_ld boolean
sortie data_mem array[7..0] of boolean

TABLE 4 – Implantation de la variable donnée reçue data

4.1.4 Implantation des variables err_parite et err

Le tableau 5 précise l’interface de ce dispositif et la figure 4.4 donne la structure d’une solution d’implantation
de la variable err et de deux solutions d’implantation de la variable err_parite. Complétez la colonne
commentaire du tableau 5 puis identifiez les composants nécessaires à l’implantation des variables err_parite et err.
Vous remarquerez sur la figure 4.5 que le signal err_parite est une entrée de la partie commande. Son rôle
est de permettre à la partie commande de savoir, au moment où elle contrôle la validité du bit de parité, s’il y a
une erreur de parité ou non. Son calcul peut nécessiter l’utilisation d’informations internes à la partie opérative.
Quand à err_set et err_rst, ce sont deux signaux qui permettent à la partie commande de modifier la valeur
du signal err : err doit passer à 1 lorsque err_set est activée et passer à 0 lorsque err_rst est activée.

F IGURE 4.4 – Implantation des variables err et err_parite

7
 direction nom type commentaire
entrée clk boolean
entrée rst boolean
entrée rxd boolean
entrée err_set boolean
entrée err_rst boolean
sortie err boolean
sortie err_parite boolean

TABLE 5 – Implantation du calcul de la parité et de la variable err

4.1.5 Bilan sur les entrées/sorties de la partie opérative

La figure 4.5 dresse un bilan sur les entrées sorties de la partie opérative. Son interface avec la partie commande
est également représentée.

F IGURE 4.5 – Bilan sur les entrées/sorties de la partie opérative

4.2 Définition de la partie commande de la fonction réception

La partie commande pilote la partie opérative. Dans le cas présent, elle peut être spécifiée par un automate
à états finis synchrone à l’horloge clk. Cet automate est construit en remplaçant les opérations et tests sur les
variables de la machine à état présentée dans la section 3 par leurs équivalents sur la partie opérative. Par exemple
le test t=DB qui, rappelez-vous, a été optimisé en t=0, cf. section 4.1.1, est réalisé en testant la valeur du signal
t_zero. Cet automate est présenté dans la section 4.2.1 suivante. Il est à noter que, concernant les sorties, seules
celles devant passer à 1 sont spécifiées, les autres sont supposées à 0. D’autre part, les sorties de la machine sont
de type Mealy, elles sont fonction de l’état courant et d’une ou plusieurs entrées. Petit rappel sur la symbolique
graphique que nous utilisons pour spécifier ces sorties Mealy : sur chacun des arcs se trouve une équation de
transition en dessous de laquelle figure une barre horizontale qui elle même se trouve au dessus d’une liste d’une
ou plusieurs sorties. Cela signifie que, dès que l’équation de transition est vérifiée, les sorties qui se trouvent en
dessous de la barre passent à 1.
Vous ferez la synthèse de cette machine à états à la main. Celle-ci sera ensuite implantée avec Quartus à l’aide de
fonctions primitives, e.g. portes logiques de type et, ou . . ., bascules.

4.2.1 Machine à état

La partie commande a en charge le pilotage de la partie opérative. La machine à états présentée figure 4.6 donne
sa spécification. Elle est synchronisée sur l’horloge clk du système.

8
 rxd

Attente
start

rxd t_zero.rxd
t_ld db_sel ?

Attente
milieu t_zero
start

t_zero.err _parite t_zero.rxd

? ?

t_zero

t_zero.rxd Reception t_zero.rxd

? données ?

t_zero.i_zero
?

t_zero.i_zero
?

Attente
t_zero
parité

t_zero.err _parite
?

Attente
stop

t_zero

F IGURE 4.6 – Machine à état de la partie commande

9
4.2.2 Synthèse de la machine à état de la partie commande

L’état est codé en one-hot :

e0 <=> 00001 (Attente start)

e1 <=> 00010 (Attente milieu start)
e2 <=> 00100 (Reception données)
e3 <=> 01000 (Attente parité)
e4 <=> 10000 (Attente stop)

Sa mémorisation se fait avec des bascules d. Soient les suffixes _c (pour current) pour désigner les sorties q
des bascules et _n (pour next) pour désigner les entrées d des bascules. Les entrées de preset, préfixées par pre et
de clear, préfixées par clr des bascules sont supposées en logique positive. Attention lorsque vous ferez la saisie
avec Quartus, il faudra passer en logique négative.

Etablissez les équations de transition :

e_n0 =?
e_n1 = e_c1.t_zero + e_c0.rxd
e_n2 =?
e_n3 =?
e_n4 =?

Etablissez les équations d’initalisation :

clr_0 =? pre_0 =?
clr_1 =? pre_1 =?
clr_2 =? pre_2 =?
clr_3 =? pre_3 =?
clr_4 =? pre_4 =?

4.2.3 Equation des sorties

Etablissez les équations des sorties :

db_sel = e_c0.rxd
t_ld = e_c0.rxd + t_zero
i_ld =?
i_dec =?
data_sh =?
data_ld =?
err_rst =?
err_set =?

5 Réalisation
Dans le cas général de la conception d’un système numérique, la réalisation consiste tout d’abord à décrire le
système à concevoir soit avec un langage de description de matériel soit par saisie de schémas ou une combinaison
des deux. Après validation par simulation, cette description subira des étapes de raffinement et validation jusqu’à
pouvoir être implantée sur la cible technologique.
En ce qui nous concerne, le système sera décrit schématiquement et hiérarchiquement avec l’outil Quartus à
l’aide de fonctions primitives ou megafonctions. Cette solution sera validée par simulation à ce premier niveau de
description dit "fonctionnel". A cette fin, plusieurs bancs de test (testbench) vous sont donnés, un sera à compléter,
de manière à valider le système graduellement en partant de modules "feuille", puis en remontant vers le module de
plus haut niveau hiérarchique.

10
Une fois validée, cette description sera synthétisée et placée/routée. Idéalement, il serait intéressant de faire une
validation du système complet après placement/routage avec le banc de test qui a été utilisé pour faire la validation
fonctionnelle du système complet. La validation après placement/routage permet de prendre en compte les temps
de propagation dans le circuit et donc de s’assurer que le circuit a un comportement temporel correct et de vérifier
qu’il n’y a peu eu de problème d’interprétation de la description fonctionnelle par les différents outils mis en jeu
dans le flot.
Afin de pouvoir réaliser le travail dans le temps imparti, nous vous fournissons un projet Quartus dans lequel seuls
des sous-ensembles des parties opératives et commande de la fonction reception sont manquants.
Le projet Quartus suit la décomposition hiérarchique suivante établie dans les sections précédentes :
— top
— receiver
— po
— pc
— pc_trans
— pc_mem
— pc_outputs
— disp
— dec_7_seg (poids faibles)
— dec_7_seg (poids forts)
Le module top est le module de plus haut niveau hiérarchique. Il se décompose en deux parties, une fonction
réception receiver et une fonction d’interface afficheur disp.
L’interface afficheur disp est composée de deux instances de décodeurs 7 segments dec_7_seg.
La fonction de réception receiver est décomposée en une partie opérative po et une partie commande pc qui
est elle même décomposée en trois blocs pc_trans, pc_mem et pc_outputs correspondant aux 3 parties de
la machine de Mealy qui l’implante.
Vous aurez à intervenir sur les éléments apparaissant en gras. Les sous-sections suivantes vous donnent la démarche
à suivre pour réaliser cette implantation. Elle est similaire à celle que vous avez suivie dans le TD 3 - Logique
séquentielle - Initiation à Quartus et Modelsim.
Dans la suite, les commandes commençant par ModelSim> sont à saisir dans la fenêtre de transcript de ModelSim.
En outre, à chaque fois que vous faites une modification de votre description Quartus et que vous voulez qu’elle
soit prise en compte dans vos simulations ModelSim, il faudra mettre à jour les fichiers utilisés par ModelSim pour
faire la simulation avec la commande ModelSim> do rtl_sim_prepare.do

5.1 Préparation de l’environnement de travail

— télécharger le fichier tp_rs232.zip qui se trouve sur chamilo dans un répertoire de votre compte
réseau, ne pas travailler à un autre emplacement, eg. le bureau, sous peine de perdre vos fichiers
— décompresser le fichier tp_rs232.zip et aller dans le dossier tp_rs232
— ouvrir le projet Quartus en double cliquant sur le fichier tp_rs232.qpf
— lancer ModelSim
— dans ModelSim se positionner dans le répertoire simulation/modelsim du projet tp_rs232

5.2 Saisie et validation de la partie commande

5.2.1 Bloc de logique combinatoire pc_trans qui calcule l’état futur
Saisie du bloc de logique combinatoire pc_trans qui calcule l’état futur. A faire dans Quartus.
— éditer la feuille de schéma du composant pc_trans : aller dans Project Navigator onglet Files
et double cliquer sur pc_trans.bdf
— saisir les équations de transitions calculées en préparation
— passer le composant pc_trans en composant de plus haut niveau hiérarchique afin que l’analyse et
élaboration qui suit ne porte que sur celui-ci : aller dans Project Navigator onglet Files faire un
clic droit sur pc_trans.bdf et activer Set as Top-Level Entity
— faire une analyse et élaboration (Processing>Start>Start analysis & elaboration) afin
de vérifier qu’il n’y a pas d’erreur de saisie

11
Validation du bloc de logique combinatoire pc_trans qui calcule l’état futur par génération de sa table de
vérité, calculée par simulation. A faire dans ModelSim.
— lancer le script de compilation des fichiers du projet
ModelSim> do rtl_sim_prepare.do
s’il y a des erreurs identifiez les composants problématiques et revenez à leur description Quartus.
— lancer le script qui permet d’obtenir la table de vérité du composant pc_trans
ModelSim> do pc_trans_rtl_sim_launch.do
Remarques :
1. le banc de test pc_trans_vhd_tst.vhd
est utilisé à cet effet, il est intéressant de le regarder.
2. vous constaterez que l’analyse de la table de vérité est fastidieuse, il est possible d’automatiser la
vérification en utilisant des assertions, comme indiqué dans le commentaire qui se trouve dans le nid de
boucle du fichier pc_trans_vhd_tst.vhd. Si vous n’êtes pas en retard et que cela vous intéresse,
vous pouvez compléter ces assertions
— ouvrir le fichier pc_trans_truth_table.txt et vérifier que la table de vérité est bien celle attendue.
Si ce n’est pas le cas, il y a des erreurs dans les équations qui produisent les bits d’état futur erronés. Il faut
donc contrôler ces équations ainsi que leur saisie dans Quartus.

5.2.2 Bloc de logique combinatoire pc_outputs qui calcule les sorties de la partie commande
Remarque : la méthodologie est identique à celle utilisée pour pc_trans.

Saisie du bloc de logique combinatoire pc_outputs qui calcule les sorties. A faire dans Quartus.
— éditer la feuille de schéma du composant pc_outputs : aller dans Project Navigator onglet
Files et double cliquer sur pc_outputs.bdf
— saisir les équations des sorties calculées en préparation
— passer le composant pc_outputs en composant de plus haut niveau hiérarchique afin que l’analyse et
élaboration qui suit ne porte que sur celui-ci : aller dans Project Navigator onglet Files faire un
clic droit sur pc_outputs.bdf et activer Set as Top-Level Entity
— faire une analyse et élaboration (Processing>Start>Start analysis & elaboration) afin
de vérifier qu’il n’y a pas d’erreur de saisie

Validation du bloc de logique combinatoire pc_outputs qui calcule les sorties par génération de sa table de
vérité, calculée par simulation. A faire dans ModelSim
— lancer le script de compilation des fichiers du projet
ModelSim> do rtl_sim_prepare.do
s’il y a des erreurs identifiez les composants problématiques et revenez à leur description Quartus.
— lancer le script qui permet d’obtenir la table de vérité du composant pc_outputs
ModelSim> do pc_outputs_rtl_sim_launch.do
Remarque : le banc de test pc_outputs_vhd_tst.vhd
est utilisé à cet effet, il est intéressant de le regarder voire de le compléter avec des assertions (si vous n’êtes
pas en retard).
— ouvrir le fichier pc_outputs_truth_table.txt et vérifier que la table de vérité est bien celle
attendue. Si ce n’est pas le cas il y a des erreurs dans les équations qui produisent les sorties erronés. Il faut
donc contrôler ces équations ainsi que leur saisie dans Quartus.

5.2.3 Bloc de logique combinatoire pc_mem qui mémorise l’état

Saisie du bloc de logique séquentielle qui mémorise l’état futur pc_mem. A faire dans Quartus
— éditer la feuille de schéma du composant pc_mem : aller dans Project Navigator onglet Files et
double cliquer sur pc_mem.bdf
— ajouter les bascules manquantes dans le composant pc_mem en prenant soin de câbler les signaux d’initiali-
sation en logique négative

12
 — passer le composant pc_mem en composant de plus haut niveau hiérarchique afin que l’analyse et élaboration
qui suit ne porte que sur celui-ci : aller dans Project Navigator onglet Files faire un clic droit sur
pc_mem.bdf et activer Set as Top-Level Entity
— faire une analyse et élaboration (Processing>Start>Start analysis & elaboration) afin
de vérifier qu’il n’y a pas d’erreur de saisie

Validation du bloc de logique séquentielle qui mémorise l’état futur pc_mem. A faire dans ModelSim 2
choses sont à vérifier :
1. que les bascules sortent bien le vecteur d’état initial lorsque le signal d’initialisation rst vaut 1
2. que les bascules copient bien la valeur qui est sur leurs entrées lors d’un front montant d’horloge lorsque le
signal rst vaut 0
Pour cela :
— lancer le script de compilation des fichiers du projet
ModelSim> do rtl_sim_prepare.do
s’il y a des erreurs identifiez les composants problématiques et revenez à leur description Quartus.
— lancer le script qui permet de faire les vérifications énoncées si dessus.
ModelSim> do pc_mem_rtl_sim_launch.do
— vérifier que les sorties des bascules évoluent comme attendu
— remarque : pour quitter la simulation :
ModelSim> quit -sim
A ce stade vous avez validé les 3 blocs composant la partie commande, il aurait été possible de valider leur
assemblage, i.e. de la partie commande complète. Néanmoins, nous proposons de passer dès maintenant à la saisie
de la partie opérative puis à la validation du système complet.

5.3 Saisie de la partie opérative et validation du système complet

Compléter la partie opérative avec les éléments manquants pour l’implantation des variables data, data_mem,
err_parite et err. A faire dans Quartus
— éditer la feuille de schéma du composant po : aller dans Project Navigator onglet Files et double
cliquer sur po.bdf
— compléter le schéma avec les composants déterminés dans le travail de préparation
— passer le composant top en composant de plus haut niveau hiérarchique puisque vous travaillez maintenant
sur le système complet : aller dans Project Navigator onglet Files faire un clic droit sur top.bdf
et activer Set as Top-Level Entity
— faire une analyse et élaboration (Processing>Start>Start analysis & elaboration) afin
de vérifier qu’il n’y a pas d’erreur de saisie

Validation du système complet Une fois la partie opérative saisie, nous proposons de passer à la validation du
système complet, à l’aide du banc de test top_vhd_tst.vhd.
— compléter le fichier le fichier
top_vhd_tst.vhd afin de simuler l’envoi d’une trame correcte. Ce fichier peut être édité dans Quartus
ou dans ModelSim.
— dans Quartus, faire une analyse et élaboration (Processing>Start>Start analysis & elaboration)
afin de vérifier que vous n’avez pas introduit d’erreur de syntaxe dans le fichier top_vhd_tst.vhd.
Puis dans ModelSim :
— lancer le script de compilation des fichiers du projet
ModelSim> do rtl_sim_prepare.do
— lancer le script qui démarre la simulation du système complet et qui configure le chronogramme
ModelSim> do top_rtl_sim_launch.do
— vérifier que le système évolue correctement, i.e. vérifier que :
— les états de la machine à états de la partie commande évoluent comme attendu
— les bits sont bien échantillonnés en leur milieu (qu’est qui nous indique cela ?)
— le compteur de bits de donnée reçus évolue correctement
— la mémorisation des bits de donnée se fait correctement

13
 — le contrôle de parité se fait correctement
— les signaux d’erreur évoluent correctement
— la mémorisation de la donnée reçue se fait correctement
— le pilotage des afficheurs 7 segments est correct
Ensuite compléter le banc de test afin que la trame correcte soit suivie par des trames comportant des erreurs
de start, stop, parité puis vérifier par simulation que votre circuit est capable de détecter ces erreurs.

5.4 Validation du système sur carte

— relier le port RS232 de la carte DE1 au port COM du PC
— relier un port USB du PC au port USB de la carte et allumer celle-ci
Dans Quartus :
— faire une "compilation" qui enchaine les étapes de synthèse logique, projection technologique, place-
ment/routage, analyse de timing et génération du fichier de configuration (Processing>Start compilation)
— configurer la carte (Tools>Programmer)
— si dans le champ de texte à côté du bouton "Hardware Setup" il est marqué "No Hardware" appuyer sur le
bouton et dans le menu déroulant de la fenêtre qui s’affiche sélectionner USB-Blaster [...] puis faire close,
normalement, il devrait ensuite y avoir affiché "USB-Blaster [...]" à côté du bouton "Hardware Setup"
— appuyer sur le bouton start
Puis :
— télécharger et lancer le programme terminal qui se trouve sur chamilo.
— configurer le programme terminal pour envoyer des caractères sur la liaison série du PC en respectant le
format de trame pour lequel notre récepteur a été conçu. Le port com à utiliser est COM1, penser à se
connecter avec le bouton "connect". Il ne faut pas activer le contrôle de flux : Handshaking doit être mis à
"none". Dès lors, les caractères entrés dans le champs de texte grisé qui se trouve tout en bas de la fenêtre
sont envoyés sur la liaison série avec la configuration choisie. Il est possible d’afficher la table ascii en
appuyant sur le bouton "ASCII Table".
— vérifier que la valeur du code ascii des caractères frappés au clavier est bien affichée sur la carte DE1
— provoquer des erreurs (start, stop, partié) en jouant sur le réglage de la trame envoyée par le PC.

5.5 Compte-rendu
Un compte rendu est à rendre à la fin de la dernière séance de TP. Il doit introduire le problème puis détailler les
différentes étapes de la conception. Nous devons y trouver :
— votre travail de préparation :
— choix et justification des éléments de la partie opérative
— machine à état de la partie commande et sa synthèse
— des impressions des schémas des différents blocs sur lesquels vous êtes intervenus : pc_trans, pc_mem
pc_outputs, po
— une impression du banc de test vhdl sur lequel vous avez travaillé top_vhd_tst.vhd pour la validation
du système complet. Ajouter des commentaires qui expliquent vos modifications.
— les résultats de simulations, annotés de manière à ce que l’on puisse s’assurer que vous avez compris
comment les utiliser pour vérifier que le système se comporte comme attendu :
— table de vérité de pc_trans
— table de vérité de pc_outputs
— chronogramme obtenu pour la validation de pc_mem pour la validation de la partie commande
— chronogramme obtenu avec le banc de test top_vhd_tst pour la validation du système complet
— des informations sur la validation sur carte. Le cas échéant pensez à nous indiquer comment provoquer les
différents types d’erreurs à l’aide du programme terminal.
— il est également essentiel de conclure sur votre travail.

Pour construire votre compte-rendu vous aurez besoin de faire des impressions. Afin d’économiser du papier, sachez
que l’imprimante de la salle M373 permet de faire des impressions recto/verso. Voici quelques conseils pour bien
paramétrer vos impressions :

14
Impression de schémas depuis Quartus :
— menu Tools>Options>General>Headers & Footers Settings
— ajouter vos noms afin de pouvoir retrouver vos impressions
— menu File>Page Setup : choisir l’orientation la plus adaptée
— menu File>Print pour imprimer

Impression de chronogramme depuis ModelSim :

— activer la fenêtre de chronogramme
— pour personnaliser vos impressions nous avons inséré un divider "NOMS" au tout début de la liste des
signaux. En double cliquant dessus vous pourrez le modifier et y faire figurer vos noms
— File>Page Setup : sélectionner Color : Black puis valider
— File> Print Time Range : sélectionner Full range pour imprimer l’ensemble de la simulation
ou Current View pour imprimer la partie affichée à l’écran ou avec Custom il est possible d’indiquer
l’intervalle de temps que vous souhaitez imprimer.

6 Bilan
Ce projet, conséquent relativement au nombre d’heure imparti, permet d’appliquer les différentes notions vues
en cours de logique. La description du système a été faite graphiquement à l’aide d’un outil de schématique et de
fonctions primitives ou megafonctions. Vous verrez dans les enseignements d’électronique numérique de filière, par
exemple SEI, comment décrire un système matériel à l’aide de langages de description d’architectures matérielles
comme vhdl.

7 Annexes
Vous allez mettre en oeuvre un protocole de transmission de données point à point série asynchrone RS-232.
Vous pouvez trouvez sur Wikipedia un article détaillé sur ce principe de transmission et la norme RS-232. Toutefois,
vous trouverez ci-dessous les informations importantes sur ce sujet.
Point à point signifie qu’une liaison met en relation seulement deux entités. Série indique qu’un seul fil est utilisé
pour transmettre des données entre l’émetteur et le récepteur et asynchrone que la transmission se fait sans partage
de synchronisation (d’horloge de transmission) entre émetteur et récepteur.
RS-232 est une norme qui date de 1969. Cette norme définit les caractéristiques électriques (tensions utilisées, charge
maximale admissible sur les lignes,...) et mécaniques (types de connecteurs, brochages,...) pour la transmission des
données. Les niveaux de tensions usuellement employés pour transmettre des données selon cette norme sont -12V
pour NLB et +12V pour le NLH. La norme prévoit l’utilisation de deux types de connecteurs soit DE9 (également
appelés DB9) à 9 broches soit DB25 à 25 broches.
Toutefois, la norme RS-232 ne définit ni le protocole de transmission à utiliser (bit de start/stop, nombre de bits de
données, principe de détection/correction des erreurs de transmission), ni les vitesses de transmission utilisables.
Typiquement, les circuits appelés UART (Universal Asynchrosous Receiver Transmitter) mettant en oeuvre cette
norme, tels que ceux qui se trouvent dans les ordinateurs personnels sous le nom de port COM ou les systèmes
embarqués, peuvent généralement fonctionner à des vitesses supérieures à 115200 bauds 2 . En outre ces circuits
permettent de transmettre des données bidirectionnellement en mode full duplex, i.e. à un instant donné des
données peuvent transiter entre les deux entités dans les deux sens, deux fils sont utilisés pour transmettre les
données. Le protocole de transmission utilisé par les UART est généralement paramétrable. Au repos la ligne
est toujours au NLH. Un bit de start au NLB indique le début d’une trame. Suit un nombre de bits de données
généralement paramétrable de 5 à 8, puis un bit de détection d’erreur paramétrable : aucun, parité pair (le nombre
de bits constituant les données et le bit de détection d’erreur est pair), parité impair (ce nombre de bit est impair).
Suit ensuite un bit de stop généralement paramétrable de 1 à 2 bits au NLH.
Nous venons de voir que cette liaison permet de mettre en relation des émetteurs et des récepteurs. Il y a un problème
2. Le baud est une unité de mesure de la rapidité de modulation ; il indique le nombre de symboles transmis par seconde qui est directement
limité par la bande passante du support. Dans notre cas, nous transmettons des symboles à deux niveaux - ou binaires - donc 1 baud équivaut
à un débit de 1 bit par seconde. Il ne faut pas non plus confondre ce dernier qui est un débit brut avec le débit d ?informations utiles qui ne
comprend pas les symboles de contrôle : start, stop et parité. Dans ce TP la vitesse de transmission est de 9600 bauds pour une trame comprenant
1 bit de start, 8 bits de données, 1 bit de parité et 1 bit de stop, le débit d’information maximal utile est donc 9600/(11) = 873 octet/s ou Byte/s

15
dont nous n’avons pas discuté : un mécanisme de contrôle de flux est-il prévu ? i.e. un mécanisme permettant au
récepteur de signaler à l’émetteur qu’il est prêt ou non prêt à recevoir des données (permet de gérer le niveau de
remplissage des tampons de réception). Deux types de contrôle de flux sont envisageables. (1) Le contrôle de flux
matériel : deux broches Ready To Send (RTS) et Clear To Send (CTS) du connecteur RS 232 sont utilisés pour
mettre en oeuvre un protocole type poignée de main : le signal RTS est positionné par l’émetteur pour informer le
récepteur qu’il est prêt à émettre des données, le signal CTS permet au récepteur de signaler à l’émetteur qu’il est
prêt à recevoir des données. (2) Le contrôle de flux logiciel. Il utilise les deux canaux de transmission de la liaison :
un premier canal est utilisé pour transmettre les données entre l’émetteur et le récepteur, un second utilisé par le
récepteur pour envoyer des ordres d’arrêt ou de reprise d’émission de données : le caractère XOFF (0x13) est
émis par le récepteur pour demander à l’émetteur d’arrêter d’envoyer des données et le caractère XON (0x11) est
émis par le récepteur pour signaler à l’émetteur qu’il est prêt à recevoir des données. Dans le contexte de notre
projet aucun contrôle de flux, tant matériel que logiciel, ne sera mis en oeuvre.
Pour conclure, les interfaces série de type port COM ont tendance à disparaître sur les ordinateurs personnels au
profit de l’USB (il existe toutefois des adaptateurs USB port COM). L’USB offre des débits bien supérieurs ainsi
qu’une topologie de type bus, i.e. un lien peut être partagé. Toutefois, en raison de leurs simplicités et robustesse, les
liaisons séries asynchrones RS-232 sous toujours largement utilisées dans le monde industriel et dans les systèmes
embarqués.

16