Changes between Version 22 and Version 23 of SoclibCourseTp2

Timestamp:

Sep 27, 2009, 8:12:01 PM (16 years ago)

Author:

alain

Comment:

--

SoclibCourseTp2

@@ -174 +174 @@
 (ou pseudo-registres) implantés dans l'espace addressable, qui peuvent donc - en principe - être
 lus ou écrits par n'importe quel initiateur du sytème. Chacun de ces registres a une largeur de 4 octets. 
-Par conséquent, le segment occupé par ce périphérique dans l'espace adressable a une taille de `4*4` = 16 octets.
+Par conséquent, le segment occupé par ce périphérique dans l'espace adressable a une taille de `4*` = 16 octets.
 
 Pour simplifier le décodage des adresses, on impose la contrainte que l'adresse de base de ce segment est
@@ -180 +180 @@
 La carte d'implantation des registres est définit comme suit :
 
-|| '''Nom du registre''' || '''Offset''' || '''Mode'''    ||
-|| r_opa                         || 0x0          || Write Only ||
-|| r_opb                         || 0x4          || Write Only ||
-|| r_start                        || 0x8          || Write Only ||
-|| r_res                           || 0xc          || Read Only  ||
-
-Attention : Il n'existe pas réellement de registre ''r_start'' dans le composant matériel.
-Lorsque le composant ''!VciGcdCoprocessor'' reçoit une commande d'écriture à l'adresse
-correspondant à l'adresse de ''r_start'', la donnée WDATA correspondante n'est écrite nulle part,
-mais la commande est interprêtée par le coprocesseur comme un ordre de démarrage du calcul.
+|| '''Nom du registre''' || '''Offset''' || '''Mode'''      ||
+|| GCD_OPA                || 0x0          || Read/Write ||
+|| GCD_OPB                 || 0x4          || Write Only  ||
+|| GCD_START             || 0x8          || Write Only  ||
+|| GCD_STATUS           || 0xc          || Read Only   ||
 
 Comme pour tout composant contenant des registres addressables, on définit dans un fichier
-séparé les mnémoniques  correspondant aux numéros des registres, car cette information
+séparé ''gcd.h'' les mnémoniques  correspondant aux numéros des registres, car cette information
 est utilisée non seulement  par le composant ''!VciGcdCoprocesseur'' (pour décoder les adresses), 
 mais également par le composant ''!VciGcdMaster'' (pour générer les adresses).
 
-Une erreur est signalée si le coprocesseur reçoit une commande de longueur supérieure à un mot,
+ * Une commande d'écriture vers le registres GCD_OPA (resp. GCD_OPB) permet d'écrire l'opérande A (resp. opérande B).
+ * Une commande de lecture du registre GCD_OPB retourne la valeur du résultat si le coprocesseur a fini son calcul.
+ * Une commande de lecture du registre GCD_STATUS retourne la valeur 0 lorsque le coprocesseur est dans l'état
+''IDLE", et retourne une valeur différente de 0 si le coprocesseur n'a pas fini de calculer.
+ * Une commande d'écriture vers le pseudo-registre GCD_START déclenche le calcul du PGCD portant sur les valeurs présentes dans les registres GCD_OPA et GCD_OPB. La donnée correspondant à cette écriture (champs VCI WDATA) n'est écrite nulle part.
+
+Comme vous pouvez le constater dans la figure ci-dessous, le coprocesseur GCD contient deux automates
+fonctionnant en parallèle : 
+ * l'automate ''vci_fsm'' contrôle l'interface VCI : il répond aux commandes qu'il reçoit, en écrivant dans le registre concerné s'il sagit d'une écriture, ou en renvoyant la valeur demandée s'il s'agit d'une lecture.
+ * l'automate ''exe_fsm'' contrôle l'exécution de la boucle de calcul du PGCD.
+
+[[Image(soclib_tp2_coprocessor.png)]]
+
+'''Question''' : Pourquoi faut-t-il deux automates séparés pour contrôler l'interface VCI et pour contrôler le calcul
+du PGCD proprement dit ?
+
+'''Question''' Dans la fonction de transition, on a écrit le code définissant les transitions de l'automate ''vci_fsm'' après
+le code définissant les transitions de l'automate ''exe_fsm'', bien que les transitions de l'automate ''exe_fsm'' dépendent
+de l'état de l'automate ''vci_fsm''. On aurait aussi bien pu décrire ces deux automates dans l'ordre inverse.
+Quelle mécanisme du langage SystemC utilise-t-on pour rendre l'ordre de description des automates indifférent?
+ 
+Une erreur est signalée si le coprocesseur GCD reçoit une commande de longueur supérieure à un mot,
 ou si l'adresse reçue n'appartient pas au segment qui a été défini pour le coprocesseur,
-ou si le mode d'accès (Read ou Write) ne respecte pas les contraintes ci-dessus.
-
-Question : comment sont traitées les erreurs dans ce modèle de simulation? à quoi servent ces vérifications ?
-
-La figure ci-dessous décrit la structure de l'automate de contrôle du composant `VciGcdCoprocessor`.
-
-[[Image(soclib_tp2_coprocessor.png)]]
+ou si le mode d'accès (Read ou Write) ne respecte pas les contraintes définies dans la carte des registres.
+
+'''Question''' : comment sont traitées les erreurs dans ce modèle de simulation? à quoi servent ces vérifications ?
 
 Le fichier `vci_gcd_coprocessor.h` contient une définition complête du composant `VciGcdCoprocessor`.
@@ -214 +226 @@
 
 Le composant `VciGcdMaster` est un initiateur VCI, qui exécute une boucle infinie dans laquelle il exécute
-successivement les 6 actions suivantes:
+successivement les actions suivantes:
  1. calcul de deux valeurs aléatoires (entiers positifs codés sur 32 bits)
- 1. écriture de l'opérande OPA dans le registre `r_opa` du coprocesseur GCD. 
- 1. écriture de l'opérande OPB dans le registre `r_opb` du coprocesseur GCD.
- 1. écriture dans le pseudo-registre `r_start` du coprocesseur GCD.
- 1. lecture du résultat dans le registre `r_res` du coprocesseur GCD.
+ 1. écriture de l'opérande OPA dans le registre GCD_OPA du coprocesseur GCD. 
+ 1. écriture de l'opérande OPB dans le registre GCD_OPB du coprocesseur GCD.
+ 1. écriture dans le pseudo-registre GCD_START du coprocesseur GCD.
+ 1. lecture du registre GCD_STATUS du coprocesseur GCD, jusqu'à obtenir une valeur nulle (calcul terminé)..
+ 1. lecture du résultat dans le registre GCD_OPA du coprocesseur GCD.
  1. affichage des résultats.
 
 Pour accéder au coprocesseur GCD, le composant a besoin de l'adresse de base du 
-segment de l'espace adressable aui a été assigné au coprocesseur GCD.
+segment de l'espace adressable qui a été assigné au coprocesseur GCD.
 Le composant ''!VciGcdMaster'' étant un automate cablé (non programmable), on considère
 que cette adresse est également "câblée". Elle est donc définie comme un paramètre du constructeur.
@@ -236 +249 @@
 
 Le fichier `vci_gcd_coprocessor.h` contient une description complète du composant `!VciGcdMaster`.
-Il n'a pas besoin d'être modifié, mais vous devez le lire attentivement pour modifier
+Il n'a pas besoin d'être modifié, mais vous d'êtreevez le lire attentivement pour modifier
 le fichier `vci_gcd_coprocessor.cpp`, qui contient une description incomplète des méthodes associées à ce composant.
 Complétez le code des méthodes `transition()` et `genMoore()`.
@@ -256 +269 @@
 == 5.4 Compilation et génération du simulateur ==
 
-Il faut ensuite compiler les différents fichiers pour générer le simulateur.
+Il faut maintenant compiler les différents fichiers pour générer le simulateur.
 On va utiliser la même méthode que dans le TP1, mais il y a une difficulté supplémentaire, à cause
 du paramètre template `vci_param` des composants `VciGcdMaster`, `VciGcdCoprocessor`. 
@@ -274 +287 @@
 les calculs effectués sont les mêmes (seul le protocole de communication a changé.
 
+En cas de difficulté, vous pouvez obtenir une trace détaillée (cycle par cycle) des valeurs contenues dans les registres.
+Il faut relancer la compilation en ajoutant le flag ''-DSOCLIB_MODULE_DEBUG'' dans les options de  compilation.
+
 == 5.5 Architecture multi-maitres ==
 
@@ -296 +312 @@
 }}}
 
-Modifiez le Makefile pour générer le fichier exécutable `multi_simulator.x`, en n'oubliant pas d'inclure le fichier `vci_vgsb.o`
-dans l'ensemble des fichiers objet.
+Modifiez le Makefile pour générer le fichier exécutable `multi_simulator.x`, en n'oubliant pas d'inclure le fichier `vci_vgsb.o` dans l'ensemble des fichiers objet.
 Le lancement du simulateur doit vous fournir une trace d'exécution qui entrelace les compte-rendus des trois initiateurs
 qui s'exécutent en parallèle. Chaque initiateur commande un seul coprocesseur, et la seule ressource partagée est le