I



TP VHDL

SYNTHESE LOGIQUE VHDL

-

Minuteur Programmable

AUBRY Aliénor

BENEULT Christophe

GOMES Gabriel

3BE - ISE

Sommaire

Sommaire 2

I. Description du TP 3

1. Objectifs du TP 3

2. Composants programmables utilisés 4

3. Logiciels utilisés 5

II. Travail préparatoire 6

1. Généralités 6

2. Description fonctionnelle 7

3. Diagrammes de connexion 13

III. Etude pratique 14

1. Synthèse logique de l’EPLD n°1 (M4A5-64/32) 14

2. Synthèse logique de l’EPLD n°2 (M4A5-32/32) 29

Annexe 1 : Schéma global 36

Annexe 2 : Programme horloge.vhd 37

Annexe 3 : Programme horloge_tb.vhd 38

Annexe 4 : Programme compteur.vhd 39

Annexe 5 : Programme compteur_tb.vhd 41

Annexe 6 : Programme horloge_2.vhd 43

Annexe 7 : Schéma bloc du système complet 44

I. Description du TP

1. Objectifs du TP 

L’objectif de ce TP est d’étudier la phase finale de mise au point de composant de logique programmable et d’en effectuer les tests.

Dans le TP précédent nous avons effectué toutes les étapes de la simulation d’un minuteur. Cette simulation étant validée, nous allons maintenant nous intéresser à la partie synthèse et l’incorporation d’une partie des programmes dans les composants programmables.

L’intégralité de l’incorporation du minuteur dans les composants fera l’objet d’un troisième TP.

Le schéma bloc du système complet de ce TP se trouve en Annexe 7.

2. Composants programmables utilisés

Nous utiliserons dans ce TP deux CPLD LATTICE de la famille ispMACH4A5 :

- EPLD n°1 [M4A5-64/32] : on y retrouvera l’horloge.

Le but du troisième TP sera d’y incorporer l’horloge, la partie génération des secondes, minutes et l’usage des boutons.

- EPLD n°2 [M4A5-32/32] : on y retrouvera le compteur des secondes, la conversion BCD/7segments, l’affichage des secondes et l’interface de liaison avec l’EPLD n°1.

Le but du troisième TP sera d’y incorporer la commande buzzer, le driver et l’interface de liaison avec l’EPLD n°1.

[pic]

Les caractéristiques des branchements entre les deux EPLD se trouvent en Annexe 1. On peut également y voir les caractéristiques des boutons (pull-up), de l’afficheur et du buzzer.

3. Logiciels utilisés

 

Au cours de ce TP nous utiliserons trois logiciels :

- ModelSim qui permet la simulation des programmes

- ispLever (LATTICE) qui permet l’écriture, la compilation, la simulation (à l’aide de ModelSim) et la synthèse des codes sources.

- ispVM System (LATTICE) qui permet la programmation des composants de logique programmable.

II. Travail préparatoire

1. Généralités

La famille ispMACH4A de Lattice offre une architecture flexible. Les composants qui la composent sont faciles d’usage, ce sont des solutions fiables et prédictibles pour les utilisateurs.

Cette famille offre une densité de macro-cellules entre 32 et 152. Elle nous donne également le choix entre deux tensions d’alimentation : 3,3Volt et 5Volt. Dans notre TP les composants utilisés sont de type 5Volt, d’où leur nom : M4A5xx/32.

Un des grands avantages de cette famille est qu’elle est compatible avec le standard JTAG norme 1149.1. Ce standard permet à l’utilisateur une programmation aisée du composant et un débugage facilité grâce à l’interface JTAG (Boundary Scan Test).

Caractéristiques principales des composants 5Volt de la famille ispMACH4 :

[pic]

Nous utiliserons donc des composants ayant au maximum 64 macro-cellules, 32 I/O et usant du JTAG Compliant.

2. Description fonctionnelle

L’architecture fondamentale des ispMACH4A est constituée de multiples PAL interconnectés par une matrice centrale. Cette matrice permet la communication entre les blocs PAL et les routes conduisant les entrées aux blocs PAL. Ensemble, les blocs de PAL et la matrice de commutation centrale permettent à l’utilisateur de créer une large gamme de design dans un dispositif simple au lieu de devoir utiliser des dispositifs multiples.

On a ainsi le diagramme suivant le M4A5-64/32 :

[pic]

Et le diagramme suivant le M4A5-32/32 :

[pic]

Les blocs PAL sont constitués ainsi :

Pour le M4A5-64/32 :

[pic]

Pour le M4A5-32/32 :

[pic]

Plus en détail, un bloc PAL est constitué de :

- Tableau product-term

Ou product-term array, est constitué d’un certain nombre de termes produit qui forment la base de l’implémentation logique.

Les entrées viennent de la matrice centrale et fournissent une implémentation logique. En utilisant des portes AND on arrive à l’allocateur logique (logic allocator).

- Allocateur logique (encadré en noir)

Ou logic allocator, est l’étape entre les portes AND et les macro-cellules. Ainsi les product terms sont alloués aux macro-cellules grâce à un commutateur. Chaque commutateur product term est associé à une macro-cellule.

Ce bloc peut fournir la logique XOR pour la comparaison de données. Mais il peut également travailler avec les bascules D et T pour fournir des opérations de registre S-R et J-K.

Configuration en mode synchrone (4 product terms pour un commutateur):

[pic]

Configuration en mode asynchrone (2 product terms pour un commutateur):

[pic]

- Macro-cellules (encadrées en rose)

Ou macrocells, sont composées d’éléments de stockage, de ressources de routages, d’un multiplexeur d’horloge et d’un contrôle d’initialisation.

Une macro-cellule a deux modes fondamentaux : synchrone et asynchrone. Le mode choisi affect l’horloge et l’initialisation de la macro-cellule.

Grâce aux macro-cellules, les composants de la famille M4A peuvent réaliser toutes les opérations de logique séquentielle, en offrant par exemple la possibilité de réaliser des bascules D et T synchrone ou asynchrone.

Ainsi grâce au bloc [product term – allocateur] logique et à la macro-cellule, chaque bloc PAL peut réaliser toutes les fonctions combinatoires et séquentielles.

- Matrice de multiplexage de sortie (encadrée en noir)

Ou Output Switch Matrix, permet de connecter les macro-cellules aux cellules I/O. Cela permet une grande flexibilité dans la détermination des pinout et permet également des changements de design.

[pic][pic]

- Cellules d’I/O

Ou I/O cells sont constituée différemment pour les deux EPLD utilisés.

[pic]

La différence entre les deux est la présence pour le M4A5-64/32 d’un registre flip-flop qui donne la possibilité de garder en mémoire des données d’entrée.

- Matrice de multiplexage d’entrée (encadrée en vert)

Ou Input Switch Matrix, optimise le routage des entrées vers la matrice centrale. Cela permet d’avoir plus de un seul chemin pour entrer dans la matrice générale.

- Génératrice d’horloge (encadrée en rouge)

Ou PAL Block Clock Generation.

Sur nos deux composants, nous avons 2 pins d’horloge, qui peuvent également être utilisées comme des entrées. Ces pins conduisent un signal horloge dans chaque bloc PAL. La génératrice d’horloge fournit 2 signaux d’horloge qui peuvent être utilisés n’importe où dans le bloc PAL

Cela donne une grande flexibilité, par exemple dans le partitionnement des machines d’état.

3. Diagrammes de connexion

Diagramme de connexion de nos composants de type 44-PIN PLCC.

[pic]

Avec :

CLK/I ( Horloge ou entrée

GND ( Masse

I/O ( Entrée/Sortie

Vcc ( Tension d’alimentation

TDI ( Test donnée entrante

TCK ( Test horloge

TMS ( Test Mode Select

TDO ( Test donnée sortante

III. Etude pratique

1. Synthèse logique de l’EPLD n°1 (M4A5-64/32)

Tout d’abord créons notre projet : horloge.syn dans le logiciel ispLever.

Caractéristiques de notre composant M4A5-64/32 :

[pic]

1ère Etape : La simulation du programme fournissant une horloge de 1s à partir d’un oscillateur de fréquence 32768Hz.

Cette simulation a déjà été faite dans le TP précédent. Il existe cependant un changement par rapport à cette dernière simulation qui se porte sur le signal reset.

En effet sur le sujet il est demandé par la suite de connecter le signal reset au bouton des minutes. Or sur le schéma général en annexe du sujet de TP (voir également Annexe 1), on voit que le bouton des minutes est actif à l’état bas (présence d’un résistance de pull-up). Il faut donc modifier la condition sur le reset ( voir Annexe 2 pour le programme et Annexe 3 pour le testbench.

Résultats de cette nouvelle simulation :

[pic]

On obtient bien un signal d’horloge de période 1s. De plus lors de la remise à zéro (reset à l’état bas) notre horloge de sortie passe à zéro.

2ème Etape : Synthèse avec l’option AREA

- Connexions des I/O :

La connexion des signaux avec les broches du composant M4A5-64/32 est la suivante :

Oscil connecté à la broche n° 11

Reset connecté à la broche n° 7 (bouton des minutes)

Clk_out connecté à la broche n° 37 (REFRESH)

- Synthèse et fitter report obtenu :

➢ Tout d’abord paramétrons les contraintes d’optimisation en choisissant l’option AREA :

[pic]

Le mode AREA : il utilise un minimum de place en modifiant le routage si nécessaire. L’espace est optimisé.

➢ Ensuite plaçons nos signaux sur les broches demandées :

Pour cela nous allons modifier le Constraint Editor en plaçant nos signaux sur les broches.

[pic]

➢ Lançons ensuit le fit design afin d’obtenir le fitter report de la synthèse.

Cette action permet également d’obtenir le fichier horloge.jed, qui sera le fichier à implanter lors de la mise du programme dans le composant avec le logiciel ispVM System.

Le fitter report complet étant trop long à inclure, nous allons commenter les éléments importants.

Commentaires associés à ce rapport :

Dans le paragraphe : Design_Summary

On peut voir le nombre d’I/O ainsi que le nombre de bascules utilisées :

Total Input Pins : 2

Total Output Pins : 1

Total Bidir I/O Pins : 0

Total Flip-Flops : 15

Total Product Terms : 34

Total Reserved Pins : 0

Total Reserved Blocks : 0

Dans le paragraphe : Device_Resource_Summary

On peut voir le nombre de macro-cellules utilisées, le nombre d’entrées d’horloge et de pins utilisées :

Total

Available Used Available Utilization

Dedicated Pins

Input-Only Pins .. .. .. --> ..

Clock/Input Pins 2 1 1 --> 50%

I/O Pins 32 2 30 --> 6%

Logic Macrocells 64 17 47 --> 26%

Input Registers 32 0 32 --> 0%

Unusable Macrocells .. 0 ..

CSM Outputs/Total Block Inputs 132 42 90 --> 31%

Logical Product Terms 320 36 284 --> 11%

Product Term Clusters 64 11 53 --> 17%

( Le quart des macro-cellules est utilisé. Ce qui est raisonnable.

( Le nombre de product terms utilisé est faible (11% de ceux disponible)

( L’implantation de l’horloge en mode AREA utilise 15 bascules.

Dans le paragraphe : Pinout_Listing

On peut les broches auxquelles sont raccordés nos signaux :

| Pin |Blk |Assigned|

Pin No| Type |Pad |Pin | Signal name

-------------------------------------------------------------

1 | GND | | |

2 | I_O | A7 | |

3 | I_O | A6 | |

4 | I_O | A5 | |

5 | I_O | A4 | |

6 | I_O | A3 | |

7 | I_O | A2 | * |reset

8 | I_O | A1 | |

9 | I_O | A0 | |

10 | JTAG | | |

11 | CkIn | | * |oscil

12 | GND | | |

13 | JTAG | | |

14 | I_O | B0 | |

15 | I_O | B1 | |

16 | I_O | B2 | |

17 | I_O | B3 | |

18 | I_O | B4 | |

19 | I_O | B5 | |

20 | I_O | B6 | |

21 | I_O | B7 | |

22 | Vcc | | |

23 | GND | | |

24 | I_O | C7 | |

25 | I_O | C6 | |

26 | I_O | C5 | |

27 | I_O | C4 | |

28 | I_O | C3 | |

29 | I_O | C2 | |

30 | I_O | C1 | |

31 | I_O | C0 | |

32 | JTAG | | |

33 | CkIn | | |

34 | GND | | |

35 | JTAG | | |

36 | I_O | D0 | |

37 | I_O | D1 | * |clk_out

38 | I_O | D2 | |

39 | I_O | D3 | |

40 | I_O | D4 | |

41 | I_O | D5 | |

42 | I_O | D6 | |

43 | I_O | D7 | |

44 | Vcc | | |

--------------------------------------------------------

- Post simulation temporelle de la synthèse obtenue :

Afin d’obtenir le fichier horloge.vho, lançons les Generate Timing Simulation Files

Une fois les fichiers de la simulation temporelle générés, on utilise le fichier horloge.vho pour faire une simulation sous ModelSim.

Nous avons également obtenus un fichier horloge.sdf contenant les contraintes à apporter lors de la simulation.

Simulation sous ModelSim

Après avoir compilé nos fichiers :

le fichier horloge.vho renommé horloge_area.vhd

le testbench horloge_tb.vhd,

lançons la simulation.

Pour cette simulation, nous rajoutons un fichier SDF à la simulation afin de créer une simulation réelle tel que cela se passerait dans le composant.

La région à indiquer pour l’ajout de ce fichier .sdf correspond à l’étiquette du fichier testbench.

Résultats obtenus après simulation :

[pic]

Observation précise :

[pic]

Lorsque l’on zoom, on observe un temps de retard (6ns) du front montant du signal de sortie par rapport au front montant du signal de l’oscillateur. Ceci est du au timing du composant. Il ne faut en effet pas oublier que nous sommes dans une simulation pour un composant réel et non plus en simulation simple. Il y a apparition de retard du aux éléments physiques et au temps de calcul du composant.

3ème Etape : Synthèse avec l’option SPEED

- Connexions des I/O :

La connexion des signaux avec les broches du composant M4A5-64/32 est la même que précédemment :

Oscil connecté à la broche n° 11

Reset connecté à la broche n° 7 (bouton des minutes)

Clk_out connecté à la broche n° 37 (REFRESH)

- Synthèse et fitter rapport obtenu :

➢ Tout d’abord paramétrons les contraintes d’optimisation en choisissant l’option SPEED:

[pic]

Le mode SPEED : il prend le chemin critique et le fixe. Ce chemin ne pourra pas changer par la suite.

➢ Ensuite plaçons nos signaux sur les broches demandées : ce qui a déjà été fait avec l’autre option.

➢ Lançons ensuit le fit design afin d’obtenir le fitter report de la synthèse.

Cette action permet également d’obtenir le fichier horloge.jed, qui sera le fichier à implanter lors de la mise du programme dans le composant avec le logiciel ispVM System.

Le fitter report complet étant trop long à inclure, nous allons commenter les éléments importants.

Commentaires associés à ce rapport :

Dans le paragraphe : Design_Summary

On peut voir le nombre d’I/O ainsi que le nombre de bascules utilisées :

Total Input Pins : 2

Total Output Pins : 1

Total Bidir I/O Pins : 0

Total Flip-Flops : 15

Total Product Terms : 21

Total Reserved Pins : 0

Total Reserved Blocks : 0

Dans le paragraphe : Device_Resource_Summary

On peut voir le nombre de macro-cellules utilisées, le nombre d’entrées d’horloge et de pins utilisées :

Total

Available Used Available Utilization

Dedicated Pins

Input-Only Pins .. .. .. --> ..

Clock/Input Pins 2 1 1 --> 50%

I/O Pins 32 2 30 --> 6%

Logic Macrocells 64 15 49 --> 23%

Input Registers 32 0 32 --> 0%

Unusable Macrocells .. 0 ..

CSM Outputs/Total Block Inputs 132 48 84 --> 36%

Logical Product Terms 320 22 298 --> 6%

Product Term Clusters 64 4 60 --> 6%

( Moins du quart des macro-cellules est utilisé. Ce qui est raisonnable.

( Le nombre de product terms utilisé est faible (6% de ceux disponible)

( L’implantation de l’horloge en mode AREA utilise 15 bascules.

Dans le paragraphe : Pinout_Listing

On peut les broches auxquelles sont raccordés nos signaux :

| Pin |Blk |Assigned|

Pin No| Type |Pad |Pin | Signal name

---------------------------------------------------------------

1 | GND | | |

2 | I_O | A7 | |

3 | I_O | A6 | |

4 | I_O | A5 | |

5 | I_O | A4 | |

6 | I_O | A3 | |

7 | I_O | A2 | * |reset

8 | I_O | A1 | |

9 | I_O | A0 | |

10 | JTAG | | |

11 | CkIn | | * |oscil

12 | GND | | |

13 | JTAG | | |

14 | I_O | B0 | |

15 | I_O | B1 | |

16 | I_O | B2 | |

17 | I_O | B3 | |

18 | I_O | B4 | |

19 | I_O | B5 | |

20 | I_O | B6 | |

21 | I_O | B7 | |

22 | Vcc | | |

23 | GND | | |

24 | I_O | C7 | |

25 | I_O | C6 | |

26 | I_O | C5 | |

27 | I_O | C4 | |

28 | I_O | C3 | |

29 | I_O | C2 | |

30 | I_O | C1 | |

31 | I_O | C0 | |

32 | JTAG | | |

33 | CkIn | | |

34 | GND | | |

35 | JTAG | | |

36 | I_O | D0 | |

37 | I_O | D1 | * |clk_out

38 | I_O | D2 | |

39 | I_O | D3 | |

40 | I_O | D4 | |

41 | I_O | D5 | |

42 | I_O | D6 | |

43 | I_O | D7 | |

44 | Vcc | | |

--------------------------------------------------------------

- Post simulation temporelle de la synthèse obtenue :

Afin d’obtenir le fichier horloge.vho, lançons les Generate Timing Simulation Files

De même que précédemment on obtiendra un fichier .vho et un fichier .sdf qui nous permettront de faire une simulation « réelle » car elle simulera également les contraintes apportées par le composant.

Simulation sous ModelSim

Après avoir compilé nos fichiers :

le fichier horloge.vho renommé horloge_speed.vhd

le testbench horloge_tb.vhd,

lançons la simulation.

De même pour cette simulation, nous rajoutons un fichier SDF à la simulation afin de créer une simulation réelle tel que cela se passerait dans le composant.

La région à indiquer pour l’ajout de ce fichier .sdf correspond à l’étiquette du fichier testbench.

Résultats obtenus après simulation :

[pic]

Observation précise :

[pic]

Avec l’option SPEED tout comme avec l’option AREA, on observe un temps de retard de 6ns entre les fronts montants de nos deux signaux. Ce retard tout comme précédemment est du au temps de calcul du composant.

4ème Etape : Comparaison entre les deux options

La comparaison entre les deux options se fera sur les fitter reports.

| |AREA |SPEED |

|Compilation Times |Fitter (secondes) |2 |1 |

|Design Summary |Total Input Pins |2 |2 |

| |Total Output Pins |1 |1 |

| |Total Flip-Flops |15 |15 |

| |Total Product Terms |34 |21 |

|Device Resource Summary |Clock/Input Pins |1 |1 |

| |I/O Pins |2 |2 |

| |Logic Macrocells (/64 dispo) |17 |15 |

| |CSM Outputs/Total Block Inputs(/132) |42 |48 |

| |Logical Product Terms (/320) |36 |22 |

| |Product Term Clusters (/64) |11 |4 |

D’après ce tableau et les rapports, on peut dire que l’option SPEED permet pour ce simple programme d’utiliser moins de ressources.

En effet son but est d’utiliser les chemins critiques et de les fixer, ce qui est donc plus utile pour un petit programme car le temps de calcul de compilation est inferieur à celui de l’option AREA, car l’option AREA recalcule toujours pour simplifier.

Dans le cas de ce programme horloge l’option SPEED est donc plus avantageuse : utilisation des ressources moindre et temps de calcul de compilation plus rapide.

Le programme .jed utilisé pour le chargement dans le composant sera donc celui obtenu avec l’option SPEED (bien que pour ce petit programme la différence entre les deux options soit vraiment faible).

5ème Etape : Chargement du programme dans l’EPLD n°1

Pour le chargement du programme on utilise le logiciel ispVM System.

On y implémentera le programme avec l’option la plus optimisée.

Première chose à faire, chercher les composant sur la carte en la connectant à l’ordinateur et en utilisant l’icône scan [pic].

Ensuite effaçons les programmes déjà incorporés dans les deux composants EPLD n°1 et n°2, et implantons horloge.jed dans l’EPLD n°1.

[pic]

Une fois le programme implanté dans l’EPLD n°1, on vérifie, à l’aide d’un oscilloscope, sur la broche REFRESH, que l’on a bien un signal carré de période 1 seconde.

[pic]

Sur l’oscilloscope on observe bien un signal carré de période 1 seconde sur la broche REFRESH. Ce signal passe à zéro lorsque l’on presse le bouton des minutes, simulant le reset.

2. Synthèse logique de l’EPLD n°2 (M4A5-32/32)

Créons le projet compteur.syn dans le logiciel ispLever.

Caractéristiques de notre composant M4A5-32/32 :

[pic]

1ère Etape : La simulation du programme affichant les chiffres de 0 à 9 (période ½ seconde) sur le digit des secondes en émettant un bip à chaque nouvelle valeur.

L’horloge d’entrée sera le signal REFRESH, sortie de l’EPLD n°1. Ce signal sera une horloge de période ½ seconde, que l’on obtiendra en modifiant légèrement le programme de l’EPLD n°1 (Utilisation du bit cpt(13) à la place du cpt(14) pour obtenir clk_out).

( voir Annexe 4 pour le programme compteur.vhd et l’Annexe 5 pour le testbench associé.

Résultats de la simulation :

[pic]

Sur cette simulation on peut voir que :

- Le compteur s’incrémente à chaque front montant de l’horloge de période ½ seconde.

- Un signal reset est implanté afin de réinitialiser le compteur.

- Le signal sonore est simulé de telle façon qu’il prenne la valeur de l’horloge, pour ainsi passer à 1 pendant ¼ de seconde toutes les ½ seconde.

En simulation, l’horloge d’entrée est un signal de période ½ seconde qui ne passe pas à zéro lorsque le reset passe à zéro. Donc le bip ne passera jamais à zéro en simulation.

Mais nous savons qu’en synthèse, l’horloge de l’EPLD n°2 passe à zéro quand le reset est à zéro. Ainsi en synthèse, le bip suivra l’horloge et passera à zéro lorsque le reset sera à zéro. Le signal sonore retentira seulement à chaque changement de valeur comme cela était demandé.

- Le signal display est à 1 car l’afficheur est tout le temps allumé.

- Le signal boit_sec_uni est à 1, car c’est l’afficheur des unités des secondes que l’on a choisi pour afficher notre compteur. Les autres boitiers ne fonctionnant pas, les signaux boit_sec_diz, boit_min_uni et boit_min_diz sont à l’état bas.

[pic]

Sur cette simulation on voit que :

- La valeur affichée sur 7 segments (val_aff) est celle à afficher (cpt). Cette conversion est faite à l’aide de la fonction BDC/7 segments (appelée conv, voir Annexe 4 pour plus de détails). Sans oublier que les segments de l’afficheur sont actifs à l’état bas.

- 2ème Etape : Synthèse avec l’option AREA

- Connexions des I/O :

Clk connecté à la broche n°11 (REFRESH)

Reset connecté à la broche n°7 (Read 0)

Val_aff (6) connecté à la broche n°39 (segment a)

Val_aff (5) connecté à la broche n°38 (segment b)

Val_aff (4) connecté à la broche n°37 (segment c)

Val_aff (3) connecté à la broche n°36 (segment d)

Val_aff (2) connecté à la broche n°31 (segment e)

Val_aff (1) connecté à la broche n°30 (segment f)

Val_aff (0) connecté à la broche n°29 (segment g)

Bip connecté à la broche n°27 (buzzer)

Boit_sec_uni connecté à la broche n°40

Boit_sec_diz connecté à la broche n°41

Boit_min_uni connecté à la broche n°42

Boit_min_diz connecté à la broche n°43

Display connecté à la broche n°28

- Synthèse :

Contraintes d’optimisation : on choisi le mode AREA

Après comparaison des fitter reports on voit que la différence entre les deux modes n’est pas flagrante (pour l’utilisation des ressources), on utilisera pour la suite le mode AREA.

| |AREA |SPEED |

|Compilation Times |Fitter (secondes) |0 |0 |

|Design Summary |Total Input Pins |2 |2 |

| |Total Output Pins |10 |10 |

| |Total Flip-Flops |4 |4 |

| |Total Product Terms |36 |36 |

|Device Resource Summary |Clock/Input Pins (/2 dispo) |1 |1 |

| |I/O Pins (/32 dispo) |11 |11 |

| |Logic Macrocells (/32 dispo) |14 |14 |

| |CSM Outputs/Total Block Inputs(/66) |10 |10 |

| |Logical Product Terms (/160) |37 |37 |

| |Product Term Clusters (/32) |11 |11 |

Plaçons nos signaux sur les broches appropriées :

[pic]

- Post simulation temporelle :

Afin d’obtenir le fichier compteur.vho, lançons les Generate Timing Simulation Files

De même que précédemment on obtiendra un fichier .vho et un fichier .sdf qui nous permettront de faire une simulation « réelle » car elle simulera également les contraintes apportées par le composant.

Simulation sous ModelSim

Après avoir compilé nos fichiers :

le fichier compteur.vho renommé compteur_area.vhd

le testbench compteur_tb.vhd,

lançons la simulation.

De même pour cette simulation, nous rajoutons un fichier SDF à la simulation afin de créer une simulation réelle tel que cela se passerait dans le composant.

La région à indiquer pour l’ajout de ce fichier .sdf correspond à l’étiquette du fichier testbench.

Résultats obtenus après simulation :

[pic]

Sur cette simulation on voit bien que :

- Lorsque le reset est à zéro l ‘afficheur des unités des secondes affiche zéro.

- La remarque pour le signal bip est la même que pour la simulation précédente : le défaut de cette simulation est que le signal bip continu de retentir même si le reset est à zéro. Ce défaut n’aura pas lieu en synthèse car le signal clk sera généré par l’EPLD n°1.

- Les afficheurs sont en mode marche (diplay à 1).

- L’affichage se fait sur le boitier des secondes (boit_sec_uni à 1).

Plus précisément :

[pic]

Sur cette simulation on voit bien que :

- Il existe des retards.

En effet tout d’abord le bip (signal bip) devrait prendre la valeur de l’horloge (signal clk), mais cela se fait avec un retard de 10 ns.

Ensuite le changement de valeur à afficher (signal val_aff) devrait se faire au front montant de l’horloge (signal clk), mais cela se fait avec un retard de 13 ns).

( Ces retards sont dus au temps de propagation des signaux au sein des bascules.

3ème Etape : Chargement du programme dans l’EPLD n°2 et fonctionnement des 2 EPLD

Changements apportés à l’EPLD n°1 (Annexe 6)

- Changement de la période de l’horloge de sortie.

En effet à la sortie de l’EPLD n°1 on aura une période de ½ seconde, ce qui facilitera l’affichage des chiffres toutes les ½ secondes.

Ainsi dans le programme horloge.vhd, on utilisera clk_out ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download