RÉPUBLIQUE DU BÉNIN
************
UNIVERSITÉ D’ABOMEY CALAVI
***********
ÉCOLE POLYTECHNIQUE D ’ABOMEY-CALAVI
************
DÉPARTEMENT DE GÉNIE INFORMATIQUE ET TÉLÉCOMMUNICATIONS
(GIT)
Simulation des Circuits
Logiques Programmables
avec WinCUPL et Proteus
ECUE : Circuits Logiques Programmables
Présentation de (Groupe3) : Sous la supervision de
1- ADJANOHUN Mathys Dr. CHEDE Steaven
2- ADIMI Prince
3- AHOKPOSSI Eugène-Marie
4- WANVOESSO Will
Année académique : 2025-2026
PLAN
INTRODUCTION
I- Les Circuits Logiques Programmables
1. Du matériel figé au matériel reconfigurable
2. Structure interne : matrices ET/OU et fusibles
3. Les familles de PLD
II- Outils de simulation des circuits logiques
1. WinCUPL : présentation et rôle dans le cycle de conception
2. Le langage CUPL : structure d'un fichier source
3. Proteus ISIS : simulation matérielle et temporelle
4. Articulation WinCUPL → fichier JEDEC → Proteus
III- Applications de la simulation le GAL16V8
1. Portes logiques PLD sur GAL16V8
2. Décodeur BCD vers 7 segments pour PLD
3. Simulateur de compteur PLD GAL16V8
CONCLUSION
2
INTRODUCTION
L'électronique numérique moderne repose sur une exigence fondamentale :
concevoir des systèmes logiques à la fois performants, flexibles et économiques.
Pendant longtemps, cette exigence s'est heurtée à une contrainte incontournable :
celle du matériel câblé, dont la fonction est définitivement figée dès la fabrication.
Modifier un circuit signifiait le reconcevoir entièrement, avec les coûts et les délais que
cela implique. C'est pour répondre à cette limite que sont apparus les circuits logiques
programmables, ou PLD. Mais programmer un circuit logique ne s'improvise pas. Cela
nécessite des outils adaptés permettant de décrire le comportement souhaité, de le
compiler en un format exploitable par le composant, et de le valider avant toute
réalisation physique. C'est précisément ce que propose la chaîne d'outils que nous
étudions dans cet exposé : WinCUPL pour la description et la compilation du
comportement logique en langage CUPL, et Proteus ISIS pour la simulation
électronique temporelle dans un environnement de circuit complet.
3
I. Les Circuits Logiques Programmables
1. Du matériel figé au matériel reconfigurable
En électronique numérique, la réalisation d'une fonction logique a longtemps opposé
deux approches fondamentales. D'un côté, le matériel câblé (circuits intégrés à fonctions fixes
comme les portes logiques TTL ou CMOS) offre des performances élevées mais impose une
fonction définitivement gravée dans le silicium dès la fabrication. Toute modification exige de
reconcevoir et de refabriquer le circuit, ce qui représente un coût et un délai considérables. De
l'autre côté, le logiciel embarqué sur microprocesseur offre une flexibilité totale mais introduit
une latence d'exécution incompatible avec certaines applications temps réel.
Les PLD (Programmable Logic Devices) sont nés de la nécessité de concilier ces deux
exigences. Ce sont des circuits intégrés fabriqués de manière générique, dont la fonction
logique n'est pas déterminée à la fabrication mais définie par l'utilisateur après coup, par un
processus de programmation électrique. Le composant physique reste le même ; c'est la
configuration interne de ses connexions qui change selon l'application visée. Cette
caractéristique confère aux PLD une double nature : la rapidité du matériel câblé et la souplesse
d'une solution programmable.
Dans le cadre de ce travail, cette reconfigurabilité est mise en œuvre via WinCUPL, qui permet
de décrire la fonction logique souhaitée en langage CUPL, puis de générer le fichier de
configuration qui sera chargé dans le composant ou dans son modèle de simulation sous
Proteus.
2. Structure interne : matrices ET/OU et fusibles
Comprendre le fonctionnement d'un PLD nécessite d'examiner son architecture interne, qui
repose sur un principe commun à toute la famille : une organisation en deux plans de portes
logiques superposés.
4
Le plan ET — génération des termes produits
Le premier plan est constitué d'une matrice de portes ET. Chaque entrée du composant y est
introduite sous deux formes : sa valeur directe et sa valeur complémentée. La matrice ET
permet de former des termes produits (minterms), c'est-à-dire des combinaisons de plusieurs
entrées reliées par des ET logiques. Par exemple, pour trois entrées A, B et C, un terme produit
possible est A·B̄·C. La richesse du plan ET détermine le nombre de combinaisons d'entrées que
le circuit peut distinguer.
Le plan OU — combinaison des termes produits
Le second plan est constitué d'une matrice de portes OU. Il reçoit les termes produits issus du
plan ET et les combine pour produire les sorties du composant. Chaque sortie est donc
exprimée sous la forme d'une somme de produits (SOP), qui est la forme standard de l'algèbre
de Boole. C'est précisément cette représentation que le langage CUPL utilise pour décrire les
équations logiques dans WinCUPL.
5
Le rôle des fusibles
La programmabilité du circuit repose sur des éléments de connexion placés aux intersections
des matrices. Dans les technologies les plus anciennes (PAL, GAL), ces éléments sont des
fusibles — des liaisons conductrices pouvant être coupées de manière permanente par
passage d'un courant suffisant. Un PLD vierge présente tous ses fusibles intacts, ce qui
correspond à un état initial défini. Programmer un PLD consiste à griller sélectivement les
fusibles correspondant aux connexions à supprimer, de façon à ne conserver que celles qui
réalisent les équations logiques souhaitées.
Le fichier JEDEC généré par WinCUPL encode précisément cette carte de fusion ( fuse map) :
pour chaque fusible de la matrice, il indique s'il doit rester intact ou être coupé. C'est ce fichier
que Proteus charge pour configurer le modèle interne du composant et en simuler le
comportement.
Dans les technologies plus récentes (GAL, CPLD), les fusibles sont remplacés par des cellules
EEPROM ou SRAM effaçables et reprogrammables, mais le principe de fonctionnement par
matrice ET/OU reste identique.
3. Les familles de PLD
Les circuits logiques programmables se déclinent en plusieurs familles, dont la complexité et
les capacités ont évolué progressivement au fil des décennies.
Le PAL — premier PLD commercial
Le PAL (Programmable Array Logic), introduit par AMD en 1978, est le premier PLD
commercialement répandu. Sa matrice ET est programmable tandis que sa matrice OU est
câblée et fixe. Cette asymétrie simplifie la fabrication mais limite la flexibilité. De plus, la
programmation par fusion de fusibles est irréversible : un PAL mal programmé est inutilisable.
6
Le GAL — évolution reprogrammable
Le GAL (Generic Array Logic), développé par Lattice Semiconductor, conserve l'architecture du
PAL mais y apporte deux améliorations majeures. D'abord, la technologie EEPROM remplace les
fusibles : le composant est effaçable électriquement et reprogrammable des milliers de fois.
Ensuite, chaque sortie est équipée d'une cellule OLMC (Output Logic Macro Cell) configurable,
permettant de choisir entre mode combinatoire et mode registre, et de régler la polarité de la
sortie. Le GAL16V8 — composant cible de nos projets — est le représentant le plus répandu de
cette famille, avec 8 entrées dédiées et 8 sorties reconfigurables.
Le CPLD — montée en complexité
Le CPLD (Complex PLD) est en réalité un assemblage de plusieurs blocs de type PAL/GAL
interconnectés par une matrice de routage programmable centrale. Cette architecture
permet d'implémenter des fonctions logiques bien plus complexes, impliquant de nombreuses
entrées/sorties et des interactions entre plusieurs blocs. Les délais de propagation dans un
CPLD sont prévisibles et constants, ce qui en fait un choix apprécié pour les applications
nécessitant un comportement temporel déterministe.
Le FPGA — l'état de l'art actuel
Le FPGA (Field Programmable Gate Array) représente le niveau de complexité le plus élevé de
la famille des circuits programmables. Son architecture repose non plus sur des matrices
ET/OU mais sur des LUT (Look-Up Tables) — des petites mémoires configurables pouvant
implémenter n'importe quelle fonction logique à N entrées — associées à des bascules, des
blocs de RAM embarquée et des ressources d'entrées/sorties avancées. Les FPGA modernes
7
contiennent des millions de cellules logiques et permettent d'implémenter des systèmes
complets, incluant des processeurs, des interfaces de communication haute vitesse ou des
accélérateurs de traitement numérique du signal. Ils constituent aujourd'hui l'outil de référence
dans l'industrie de la conception numérique avancée, programmés via des langages HDL
comme VHDL ou Verilog.
Famille Architecture Programmabilité Complexité
PAL Matrice ET programmable, OU fixe Une seule fois (fusibles) Faible — quelques
équations
GAL Matrice ET programmable, OU fixe, Effaçable et Faible à moyenne
cellules OLMC reprogrammable (EEPROM)
CPLD Plusieurs blocs PAL/GAL Reprogrammable Moyenne — dizaines
interconnectés via matrice de d'équations
routage
FPGA Blocs logiques configurables (LUT Reprogrammable (SRAM) Très élevée —
+ bascules) + RAM + I/O millions de portes
II. Outils de simulation des circuits logiques
1. WinCUPL : présentation et rôle dans le cycle de conception
Face à la nécessité de décrire, compiler et valider le comportement d'un circuit logique
programmable avant toute réalisation physique, les concepteurs disposent d'environnements
de développement spécialisés. WinCUPL est l'un d'eux, et c'est celui que nous utilisons dans le
cadre de ce projet.
8
WinCUPL — pour Windows CUPL — est un environnement de développement intégré conçu
exclusivement pour la programmation des circuits logiques programmables de type PLD et
CPLD. Développé initialement par Logical Devices Inc. et repris par Atmel, aujourd'hui intégré au
portefeuille de Microchip Technology, il est distribué gratuitement et reste une référence
pédagogique pour l'apprentissage de la conception logique programmable. Son ancienneté
ne diminue pas sa pertinence dans un contexte d'enseignement : au contraire, sa simplicité
d'accès et la lisibilité directe du lien entre le code écrit et l'architecture matérielle du composant
cible en font un outil particulièrement adapté à la compréhension des principes
fondamentaux.
L'environnement de travail
L'interface de WinCUPL s'organise autour de trois espaces principaux :
L'éditeur de code source constitue l'espace de travail principal, dans lequel le concepteur
rédige le fichier source en langage CUPL.
La console de compilation affiche en temps réel les messages du compilateur : erreurs
syntaxiques, avertissements, équations minimisées et rapport d'utilisation des ressources du
composant.
9
Enfin, le simulateur WinSIM intégré permet de définir des vecteurs de test et d'exécuter une
simulation fonctionnelle du circuit sans quitter l'environnement.
Cette organisation reflète le rôle central de WinCUPL dans le cycle de conception : il couvre les
phases de description, de compilation et de validation fonctionnelle, avant le passage vers
Proteus pour la simulation temporelle complète.
Le rôle dans le cycle de conception
WinCUPL intervient comme premier maillon du flux de conception que nous mettons en œuvre
dans ce projet. Son rôle est triple :
Il permet d'abord de décrire le comportement souhaité du circuit sous forme textuelle, en
exprimant les équations logiques qui relient les entrées aux sorties. Dans notre projet de
compteur BCD, c'est dans WinCUPL que sont décrites aussi bien la logique séquentielle du
compteur que les équations de décodage vers l'afficheur 7 segments.
Il assure ensuite la compilation de cette description vers un fichier de configuration exploitable
par le composant programmable. Ce processus transforme des équations booléennes lisibles
par un humain en une carte de fusion binaire directement interprétable par le matériel.
Il offre enfin une première validation via WinSIM, permettant de détecter les erreurs logiques
fondamentales avant d'engager la simulation temporelle plus détaillée dans Proteus. C'est une
étape d'autant plus précieuse qu'elle évite de transférer dans Proteus un circuit logiquement
incorrect, ce qui compliquerait inutilement le débogage.
2. Le langage CUPL : structure d'un fichier source
WinCUPL s'appuie sur un langage de description matérielle qui lui est propre : le CUPL,
acronyme de Compiler for Universal Programmable Logic. Contrairement aux langages HDL
professionnels comme VHDL ou Verilog, qui décrivent le comportement d'un circuit à un niveau
d'abstraction élevé, CUPL opère à un niveau très proche de l'architecture physique du PLD. Ses
équations booléennes sont directement mappées sur les matrices ET/OU du composant cible,
ce qui en fait un langage particulièrement adapté à la compréhension du lien entre la
description logicielle et la réalité matérielle.
10
Un fichier source CUPL, d'extension .PLD, s'organise en trois sections distinctes et obligatoires,
que l'on retrouve dans le fichier de notre projet.
Section 1 — L'en-tête
L'en-tête regroupe les métadonnées du projet. Il identifie le fichier, précise le composant cible
et documente le contexte de conception. Sa présence est obligatoire car c'est dans cette
section que WinCUPL détermine vers quel composant il doit compiler les équations — et donc
quelles contraintes de ressources appliquer.
Name MonProjet;
PartNo 00;
Date 01/01/2026;
Revision 01;
Designer Concepteur;
Company Etablissement;
Assembly None;
Location None;
Device g16v8;
La ligne Device g16v8 est la plus critique : elle indique au compilateur que le composant cible
est un GAL16V8, ce qui détermine le nombre de broches disponibles, le nombre maximum de
termes produits par équation (8 pour le GAL16V8) et le format du fichier JEDEC généré.
Section 2 — La déclaration des broches (PIN)
Cette section établit la correspondance entre les noms logiques utilisés dans les équations et
les broches physiques du composant. C'est ici que le concepteur définit quels signaux sont
des entrées et quels signaux sont des sorties, en associant chaque nom à un numéro de
broche.
/* Entrees */
PIN 1 = CLK;
PIN 2 = RST;
PIN 3 = DIR;
PIN 4 = EN;
11
/* Sorties registres */
PIN 19 = Q0;
PIN 18 = Q1;
PIN 17 = Q2;
PIN 16 = Q3;
/* Sorties combinatoires */
PIN 15 = a;
PIN 14 = b;
PIN 13 = c;
PIN 12 = d;
Deux points méritent attention. D'abord, le préfixe ! placé devant un nom de sortie indique que
cette sortie est active à l'état bas — c'est la polarité inversée. Ensuite, le suffixe .D utilisé dans
les équations désigne le contenu de la bascule D associée à une sortie registre, ce qui permet
d'implémenter de la logique séquentielle directement dans le PLD.
Section 3 — Les équations logiques
C'est le cœur du fichier CUPL. Cette section exprime, pour chaque sortie, la relation booléenne
qui la lie aux entrées et aux autres signaux du circuit. Le langage CUPL utilise quatre opérateurs
fondamentaux :
Opérateur Signification
& ET logique (AND)
# OU logique (OR)
! NON logique (NOT)
$ OU exclusif (XOR)
Les équations sont exprimées en forme SOP (Somme de Produits), qui correspond exactement
à la structure physique des matrices ET/OU du PLD. Une équation typique se lit ainsi :
S = (!A & B) # (A & !B);
Cette équation exprime que la sortie S est active si A=0 et B=1, ou si A=1 et B=0 — c'est un XOR
obtenu par équations explicites.
12
Logique combinatoire : FIELD et TABLE
Pour les applications impliquant un grand nombre d'entrées/sorties à traiter sous forme de
table de vérité — comme le décodage d'un code binaire vers un afficheur 7 segments — écrire
les équations SOP une par une serait fastidieux et source d'erreurs. CUPL propose pour cela
deux constructions de plus haut niveau.
La directive FIELD permet de regrouper plusieurs signaux sous un nom commun, formant un
bus logique. Plutôt que de manipuler des signaux individuels, on les traite comme un mot
binaire :
FIELD ENTREE = [in3, in2, in1, in0];
FIELD SORTIE = [a, b, c, d, e, f, g];
La directive TABLE définit ensuite une table de vérité directe, associant chaque valeur du champ
source à une valeur du champ destination. Le préfixe 'b' désigne un littéral en base binaire ('h'
pour hexadécimal, 'd' pour décimal) :
TABLE ENTREE => SORTIE {
'b'0000 => 'b'1111110; /* 0 */
'b'0001 => 'b'0110000; /* 1 */
'b'0010 => 'b'1101101; /* 2 */
/* ... */
'b'1111 => 'b'1000111; /* F */
Le compilateur dérive automatiquement les équations SOP minimisées à partir de cette table,
ce qui évite au concepteur de calculer manuellement les minterms pour chaque sortie. Il s'agit
d'un gain de lisibilité et de fiabilité considérable pour les fonctions de décodage.
Logique séquentielle : les sorties registre et le suffixe .D
L'un des atouts distinctifs du GAL par rapport au PAL réside dans ses cellules OLMC, qui
permettent de configurer une sortie non plus comme une sortie combinatoire pure, mais
comme la sortie d'une bascule D synchronisée sur l'horloge globale (broche PIN 1). Cette
configuration, dite mode registre, est activée automatiquement par le compilateur dès qu'il
détecte l'utilisation du suffixe .D dans les équations.
Le suffixe .D désigne l'entrée de cette bascule : l'équation associée décrit non pas la valeur
actuelle de la sortie, mais sa valeur au prochain coup d'horloge. À chaque front montant du
CLK, la bascule capture la valeur calculée par l'équation et la présente en sortie.
/* Sortie Q0 configurée en mode registre */
PIN 19 = Q0;
13
/* Q0 s'inverse à chaque coup d'horloge */
Q0.D = !Q0;
Le feedback est possible : la valeur actuelle de Q0 est réinjectée dans la matrice AND du GAL,
ce qui permet de l'utiliser dans les équations du next state. C'est ce mécanisme qui permet
d'implémenter des compteurs, des registres à décalage ou des machines d'état directement
dans un seul GAL.
Un exemple de compteur binaire 2 bits illustre le principe :
PIN 1 = CLK;
PIN 19 = Q0;
PIN 18 = Q1;
Q0.D = !Q0;
Q1.D = Q1 $ Q0; /* Q1 bascule quand Q0 = 1 */
Une contrainte matérielle directement visible dans le code
La structure du langage CUPL rend immédiatement visible une contrainte physique
fondamentale : sur un GAL16V8, chaque sortie ne peut être pilotée que par 8 termes produits
maximum, et le composant ne dispose que de 8 OLMCs (broches 12 à 19). Toute conception
dépassant ces limites sera rejetée à la compilation. Cette contrainte illustre concrètement
pourquoi la connaissance de l'architecture interne du PLD est indispensable avant d'écrire le
code CUPL.
3. Proteus ISIS : simulation matérielle et temporelle
Après avoir décrit le comportement du circuit en langage CUPL et obtenu le fichier de
configuration via WinCUPL, il devient nécessaire de valider ce comportement dans un
environnement électronique réaliste. C'est précisément le rôle de Proteus ISIS (Intelligent
Schematic Input System), développé par Labcenter Electronics.
Proteus ISIS est un environnement de conception et de simulation de circuits électroniques qui
va bien au-delà d'une simple vérification fonctionnelle. Là où WinCUPL se contente de
confirmer que les équations logiques produisent les bonnes sorties pour des entrées données,
Proteus place le circuit dans un contexte électronique complet et l'observe se comporter dans
le temps, avec des signaux qui évoluent, des composants qui réagissent et des délais de
propagation qui s'accumulent.
14
L'environnement ISIS
L'interface de Proteus ISIS met à disposition du concepteur une zone de travail dans laquelle on
place et interconnecte des composants issus d'une bibliothèque extrêmement riche. Cette
bibliothèque contient des composants passifs, des circuits intégrés classiques, des
microcontrôleurs, mais aussi — et c'est ce qui nous intéresse ici — des PLDs comme le GAL16V8,
composant cible de notre projet.
Autour du schéma, Proteus propose un ensemble d'instruments virtuels indispensables à la
simulation :
15
• Un générateur d'horloge configurable (fréquence, rapport cyclique)
• Des interrupteurs logiques pour piloter manuellement les entrées
• Un afficheur 7 segments qui rendra visible en temps réel les sorties
• Un analyseur logique permettant d'observer simultanément l'évolution de tous les
signaux sous forme de chronogrammes.
Tout composant simulable dans ISIS peut être trouvé dans la bibliothèque de devices de
Proteus.
16
La simulation temporelle
L'apport décisif de Proteus par rapport à WinSIM — le simulateur fonctionnel intégré à WinCUPL
— est sa capacité à simuler le circuit dans le temps réel. WinSIM ne modélise aucun délai : les
signaux changent instantanément, il n'y a ni horloge réelle ni propagation. C'est une vérification
purement logique.
Proteus, en revanche, calcule à chaque instant l'évolution de tous les signaux en tenant compte
des délais de propagation caractéristiques de chaque composant. Cela permet d'observer des
phénomènes impossibles à détecter en simulation fonctionnelle : l'apparition de glitches sur
les sorties combinatoires lors des transitions d'état, les métastabilités potentielles aux fronts
d'horloge, ou le comportement réel du circuit lors d'un reset asynchrone intervenant en pleine
séquence.
C'est cette profondeur d'analyse qui distingue fondamentalement Proteus : on ne vérifie plus
seulement ce que fait le circuit, mais comment et quand il le fait.
4. Articulation WinCUPL → fichier JEDEC → Proteus
Comprendre le lien entre WinCUPL et Proteus, c'est comprendre comment une description
textuelle abstraite du comportement logique se transforme en un circuit simulé qui s'anime à
l'écran. Ce lien est assuré par un fichier pivot central : le fichier JEDEC.
Le fichier JEDEC, pont entre les deux outils
Lorsque WinCUPL compile avec succès le fichier source .PLD décrivant notre compteur, il génère
un fichier d'extension .JED. Ce fichier, dont le format est standardisé par la norme JEDEC JESD3,
ne contient pas du code ou des équations lisibles : il contient la carte de fusion (fuse map) du
composant programmable.
Concrètement, un PLD comme le GAL16V8 est organisé en une matrice de connexions internes,
chacune pouvant être soit intacte (fusible présent) soit coupée (fusible grillé). C'est la
configuration précise de ces milliers de fusibles qui détermine le comportement logique du
composant. Le fichier JEDEC encode exactement cet état bit par bit : il dit au composant — ou
ici à son modèle de simulation — quelles connexions établir pour reproduire les équations que
le concepteur a décrites en CUPL.
Dans notre projet, ce fichier encode à la fois la logique séquentielle du compteur (les équations
de next state des bascules D internes) et la logique combinatoire de décodage vers les 7
segments — tout ce qui a été rédigé dans le fichier .PLD.
Chargement dans Proteus et configuration
Une fois le fichier JEDEC généré, son intégration dans Proteus est directe. Après avoir placé le
composant GAL16V8 sur le schéma ISIS, on accède à ses propriétés et on renseigne le champ
Program File avec le chemin vers le fichier .JED. Proteus charge alors la fuse map et configure
17
son modèle interne du composant pour qu'il se comporte exactement comme défini dans le
code CUPL.
Il est impératif que le type de composant déclaré dans l'en-tête du fichier CUPL corresponde
exactement à celui sélectionné dans Proteus. Toute discordance se traduirait par des
incompatibilités de brochage rendant la simulation invalide.
Un flux de travail itératif
L'articulation entre les deux outils n'est pas un chemin à sens unique. Dans la pratique, le flux
est itératif : si l'analyse des chronogrammes dans Proteus révèle un comportement inattendu
— une transition incorrecte, des sorties qui se stabilisent trop tard, ou un glitch sur une sortie
combinatoire — le concepteur retourne dans WinCUPL, corrige les équations, recompile pour
obtenir un nouveau fichier JEDEC, puis recharge ce fichier dans Proteus pour observer l'effet
des corrections.
C'est cette boucle Description → Compilation → Simulation → Débogage qui constitue le cœur
de la méthodologie de conception sur PLD avec ces deux outils.
18
III. Applications de la simulation le GAL16V8
1. Portes logiques PLD sur GAL16V8
La première application consiste à implémenter des fonctions logiques élémentaires
directement dans un GAL16V8, en remplacement de circuits intégrés TTL ou CMOS dédiés. Le
fichier CUPL décrit les équations booléennes correspondant aux portes souhaitées — AND, OR,
NOT, XOR — et les associe aux broches de sortie du composant.
2. Décodeur BCD vers 7 segments pour PLD
La deuxième application met en œuvre une fonction de décodage : le GAL16V8 reçoit en entrée
un code binaire 4 bits (BCD étendu, de 0 à F) et produit en sortie les 7 signaux de commande
d'un afficheur à segments. Le fichier CUPL exploite les directives FIELD et TABLE pour décrire la
correspondance complète entre les 16 codes d'entrée et les patterns de segments associés,
sans avoir à rédiger manuellement les équations SOP pour chacune des 7 sorties. Le
compilateur se charge de la minimisation.
19
3. Simulateur de compteur PLD GAL16V8
La troisième application combine un circuit compteur externe avec le GAL16V8 pour réaliser
un affichage hexadécimal animé. Le compteur CD4520 — compteur BCD 4 bits — est
cadencé par une horloge et incrémente automatiquement sa valeur à chaque front montant,
de 0000 à 1111 (0 à F en hexadécimal), puis repart à zéro de manière cyclique. Ses quatre
sorties Q0–Q3 sont connectées aux entrées du GAL16V8, qui joue exclusivement le rôle de
décodeur combinatoire : à chaque nouvel état du compteur, il recalcule instantanément les 7
signaux de commande de l'afficheur 7 segments correspondant au chiffre courant. Le rôle du
4520 et du GAL sont ainsi clairement séparés — l'un compte, l'autre traduit — ce qui illustre
une conception modulaire typique des systèmes logiques combinant séquentiel et
combinatoire.
20
CONCLUSION
Ce travail nous a permis d'étudier de manière approfondie le cycle complet de
conception et de simulation d'un circuit logique programmable, depuis la description
textuelle des équations booléennes jusqu'à l'observation du comportement temporel
en environnement simulé. À travers la mise en œuvre du projet de compteur BCD
bidirectionnel, nous avons parcouru chaque étape du flux WinCUPL-Proteus et vérifié
concrètement la concordance entre le comportement décrit en langage CUPL et celui
observé sur les chronogrammes de simulation. Les difficultés rencontrées lors de la
compilation (caractères non conformes, dépassement du nombre de termes produits,
broches invalides) ont également mis en évidence l'importance d'une connaissance
précise des caractéristiques physiques du composant cible avant même d'écrire la
première ligne de code. Ces contraintes, loin d'être de simples obstacles techniques,
reflètent la réalité fondamentale de la conception numérique : programmer du
matériel, c'est toujours composer avec ses limites physiques.
21