TP 1 SystemC - Portes logiques - Uuu.enseirb.fr

TP‐1
de
SystemC
:
«
Portes
logiques
»
Bertrand
LE
GAL
bertrand.legal@ims‐bordeaux.fr
http://uuu.enseirb.fr/~legal/
Filière
Electronique
3ème
année
‐
Option
CSI
2008
/
2009
Laboratoire
IMS
–
UMR‐CNRS
5218
 
 
 
 ENSEIRB
‐
Université
de
Bordeaux
1
351,
cours
de
la
Libération
 
 
 
 
 33405
Talence
‐
France

2/6

1. INTRODUCTION
L’objectif de ce premier TP est de vous permettre de prendre en main le langage SystemC
ainsi que le flot des outils nécessaires. Les exemples que nous allons manipulé lors de cette
première séance sont volontairement simplistes mais vous permettront d’observer les
phénomènes dont la compréhension est nécessaire par la suite.
2. ECRITURES DES PORTES LOGIQUES ELEMENTAIRES
Dans un premier temps afin de vous faire la main, vous allez commencer par modéliser
l’ensemble des portes logiques suivantes : ET, OU, NON.
⇒ Ecrivez les modèles SystemC correspondants.
A
B
Porte_ET
S
A
B
Porte_OU
S
A
A
B
Porte_NON Porte_OU Porte_ET
S
Figure : Schéma des portes logiques que vous devez modéliser.
REMARQUE : Pour une plus grande simplicité d’écriture, ces portes seront décrites à l’aide de
processus de type SC_METHOD.
3. SIMULATION DES MODELES DE PORTE LOGIQUES
Dans un second temps nous allons utiliser le moteur de simulation inclus dans les
bibliothèques SystemC afin de vérifier le comportement de vos modèles.
Afin de tester vos composants de manière pseudo-automatique, développez (à l’aide des
exemples fournis dans le fascicule de cours) les composants générateurs et affichage
permettant de générer des stimulus aléatoires et afficher les résultats obtenus comme cela est
présenté ci-dessous.
Générateur
Générateur
S
S
A
B
Composant
S
E
Affichage
Figure : Schéma des portes logiques que vous devez modéliser.
⇒ Ecrivez les modèles « Générateur » et « Affichage ».
⇒ Créez un fichier contenant les modèles à simuler ainsi que les liens les unissant.
3/6

Remarque : les générateurs de données devront fournir dans votre modèle une nouvelle donnée
toutes les 10ns secondes.
⇒ Compilez le fichier à l’aide de g++ et exécutez le. Les résultats que vous observez sont ils
cohérents ?
Remarque : afin de générer des valeurs booléennes aléatoires uniformément réparties, vous pouvez
utiliser : “(bool)(rand()%2)” et non “(bool)rand()” qui produirait environ une seule valeur “0” tous les
2^32 tirages...
4. OBSERVATION DES SIGNAUX
Comme nous l’avons vu en cours, SystemC offre des possibilités afin de visualiser des signaux
manipulés dans le modèle sous forme de chronogrammes. Dans le cadre de l’exemple
présent, utiliser un tel affichage rendrait la vérification de vos composants plus facile…
⇒ Recherchez dans le cours comment faire pour stocker les données sous forme de
chronogrammes (dans un fichier). Modifiez vos fichiers en conséquence.
⇒ Recompilez vos fichiers source et lancez une simulation de la porte logique XOR par
exemple. Ouvrez le fichier VCD généré à l’aide de l’outil nommé GtkWave. et observer les
signaux produits, sont ils corrects ?
Remarque : Afin de lancer le visualisateur de signaux, il vous suffit de taper XXX dans un terminal.
5. MODELISATION COMPORTEMENTALE (PORTE XOR)
A partir de maintenant nous allons nous intéresser à l’impact du niveau de la description sur
le temps de simulation. Cette partie doit vous permettre de prendre conscience que ces
derniers augmentent de manière trop importante lorsque l’on rajoute des détails… Ce point
important vous permettra de comprendre pourquoi dans les TP suivants nous axerons nos
travaux (raffinement matériel) sur un composant et non sur l’ensemble d’un système.
Afin de commencer cette étude, vous allez développer un modèle de porte de type XOR de
manière similaire à celle déjà développées. Simulez ce nouveau modèle de composant à l’aide
d’un « grand nombre » de simulations (100 ms).
A
B
Porte_XOR
S
Figure : Schéma de la porte XOR que vous devez concevoir.
⇒ Ecrivez le modèle de la porte XOR. Compiler votre modèle et simulez là afin de vérifier son
fonctionnement.
Remarque : Supprimer la génération des chronogrammes, cela créerait des fichiers de plusieurs
centaines de Mo sur votre compte…
4/6

⇒ Maintenant afin de mesurer le temps nécessaire à la simulation vous allez supprimer
l’ensemble des sorties à l’écran (cout ou printf). Recompilez votre programme et lancez la
simulation.
Remarque : Pour mesurer le temps d'exécution de votre programme simulant le modèle vous pourrez
utiliser la commande Unix nommée “time”. Cette dernière doit précéder le nom de votre programme
dans un terminal : “time mon_programme”.
6. ETAPE V. DESCRIPTION STRUCTURELLE (XOR)
Vous allez maintenant développer une nouvelle description de la porte XOR (nommée
XOR_Struc) basée non plus sur le comportement de la porte mais sur sa structure interne.
Cette description structurelle sera basera sur les modèles de portes logiques que vous avez
mis au point précédemment.
La figure suivante vous rappelle la composition structurelle d’une porte XOR.
NOT
AND
OR
NOT
AND
Figure : Schéma de la porte XOR composée à l’aide des portes logiques de base.
⇒ Développez ce nouveau modèle et mesurez son temps de simulation (pour une durée de
simulation identique). Que pouvez vous en conclure ? Pourquoi ?
7. INSERTION DES CONTRAINTES TEMPORELLES
Maintenant nous allons modéliser le temps de traversé des différentes portes logiques que
vous avez mis modélisées afin d’observer le comportement plus précis du système.
Pour cela nous allons considérer que le temps de traversé des portes NON, ET et OU est de
1ns alors que la porte XOR “comportementale” possédera un temps de traversé de 3ns.
⇒ Transformez le code source de vos modèles afin d’intégrer ces délais.
délai = 1ns
délai = 1ns
délai = 1ns
A
B
Porte_ET
S
A
B
Porte_OU
S
A
Porte_NON
S
Figure : Schéma des portes logiques et du temps de traversé associé.
⇒ Simulez la porte XOR structurelle et vérifiez sont bon fonctionnement sur une trentaine de
5/6

stimuli, corrigez votre modèle au besoin.
⇒ Mesurez le temps nécessaire à la simulation. Comparez les résultats.
⇒ Observer les signaux post-simulation (à l’aide de gtkwave par exemple). Quelles sont les
différences observables ? Expliquez à quoi sont dues ces “différences” ?
8. CONCLUSION
Vous venez de terminer votre premier TP autour du langage SystemC. Vous devez
maintenant comprendre que le temps de simulation d’un système complexe est « trop
important » et qu’il est donc nécessaire de décrire précisément que certaines parties.
Dans le même temps vous avez pu vous rendre compte dans la dernière question que la
visualisation de signaux « non conformes » ne permet pas simplement d’identifier les causes
d’un problème potentiel.
Dans la prochaine séance nous étudierons les possibilités offertes par le langage afin de
définir l’architecture d’un composant en fonction des contraintes système.
6/6