Changes between Version 18 and Version 19 of SoclibCourseTp2

Timestamp:

Sep 9, 2009, 3:39:00 PM (16 years ago)

Author:

nipo

Comment:

--

SoclibCourseTp2

@@ -18 +18 @@
 L'architecture matérielle qu'on souhaite prototyper dans ce second TP instancie 7 composants matériels de 
 trois types différents :
-Les deux composants ''!VciLcdCoprocessor'' et ''!VciLcdMaster'' sont instanciés trois fois chacun. Ils ont des fonctionnalités identiques à celles des composants utilisés dans le premier TP, mais ces composants possèdent maintenant des ports de communication qui respectent le protocole VCI/OCP. Le composant ''!VciLcdMaster'' se comporte comme un initiateur, et le composant ''!VciLcdCoprocesseur'' se comporte come une cible. Le troisième composant ''!VciVgbs'' (Virtual Generic System Bus) est un composant matériel modélisant un bus multi-maîtres, multi-cibles respectant le protocole VCI/OCP.  
+Les deux composants ''!VciLcdCoprocessor'' et ''!VciLcdMaster'' sont instanciés trois fois chacun. Ils ont des fonctionnalités identiques à celles des composants utilisés dans le premier TP, mais ces composants possèdent maintenant des ports de communication qui respectent le protocole VCI/OCP. Le composant ''!VciLcdMaster'' se comporte comme un initiateur, et le composant ''!VciLcdCoprocesseur'' se comporte come une cible. Le troisième composant ''!VciVgsb'' (Virtual Generic System Bus) est un composant matériel modélisant un bus multi-maîtres, multi-cibles respectant le protocole VCI/OCP.  
 
 [[Image(soclib_tp2_archi.png)]]
@@ -39 +39 @@
 Dans la spécification VCI "advanced", il y a principalement deux types de commandes :
  * transaction CMD_WRITE : le paquet commande contient un ou plusieurs mots VCI (à des adresses constantes ou consécutives) Le paquet réponse contient un seul mot VCI pour acquitter la transaction.
- * transaction CMD_READ : le paquet commande contient un seul mot VCI (à l'adresse du premier mot VCIde la rafale) et le nombre de mots à lire est défini par le champs PLEN. Le paquet réponse contient un ou plusieurs mots VCI suivant la
-longueur de la rafale.
+ * transaction CMD_READ : le paquet commande contient un seul mot VCI (à l'adresse du premier mot VCI de la rafale) et le nombre d'octets à lire est défini par le champs PLEN. Le paquet réponse contient un ou plusieurs mots VCI suivant la longueur de la rafale.
 
 '''Question''' : à quoi sert le paquet réponse dans le cas d'une transaction d'écriture ?
@@ -47 +46 @@
 La cible est désignée par les bits de poids fort de l'adresse. Le champs VCI ADDRESS doit donc être décodé
 par le (ou les) composant(s) matériel(s) qui réalise(nt) le sous-sytème d'interconnexion, pour aiguiller
-le paquet commande vers sa destination. De façon symètrique, le sous-système d'interconnexion doit 
+le paquet commande vers sa destination. De façon symétrique, le sous-système d'interconnexion doit 
 décoder le champs VCI RSRCID pour aiguiller le paquet réponse vers l'initiateur concerné.
 
@@ -65 +64 @@
 
 La plupart des champs VCI on des largeurs paramètrables (en nombre de bits) :
- * le paramètre X définit le nombre de bits du champs ADDRESS. Les adresses VCI sont des adresses octets, mais elles doivent  être alignées sur des frontières de mot.
+ * le paramètre '''X''' définit le nombre de bits du champs ADDRESS. Les adresses VCI sont des adresses octets, mais elles doivent  être alignées sur des frontières de mot.
  * le paramètre '''B''' définit le nombre d'octets d'un mot de donnée VCI. Ce paramètre définit le largeur des trois champs WDATA, RDATA et BE.
- * le paramètre '''K''' définit le nombres de bits termettant de coder la longueur PLEN d'un paquet (en nombre d'octets). La valeur PLEN  doit également être un multiple du paramètre B.
+ * le paramètre '''K''' définit le nombres de bits termettant de coder la longueur PLEN d'un paquet (en nombre d'octets). Nous n'utiliserons que des valeurs de PLEN multiples du paramètre '''B'''.
  * le paramètre '''S''' définit le nombre de bits du champs SRCID, qui permet de coder le numéro de l'initiateur VCI qui a démarré la transaction. Ce paramètre définit donc le nombre maximum d'initiateurs dans le système.
- * Le paramètre '''E''' définit le nombre de bits permettant de coder le type d'erreur dans le champs RERROR du paquet commande. La valeur 0 signifie "pas d'erreur". 
+ * Le paramètre '''E''' définit le nombre de bits permettant de coder le type d'erreur dans le champs RERROR du paquet commande. `RERROR = 0` signifie "pas d'erreur". 
  * Les deux paramètres '''T''' et '''P''' définissent le nombre de bits des deux champs TRDID et PKTID. Ces deux champs permettent d'étiqueter une commande VCI par une numéro de thread et/ou par un numéro de transaction. Ils peuvent être utilisés par un initiateur pour envoyer une commande (n+1) sans attendre d'avoir reçu la réponse à la commande (n).
 
@@ -80 +79 @@
 Mais elle crée une difficulté pour la modélisation des composants matériels, puisqu'il faut écrire des modèles de
 simulation génériques, capable de s'adapter à différentes largeurs des champs adresse ou donnée. 
-On utilise pour cela la techique des ''templates'' du langage C++ : on regroupe toutes les valeurs de ces paramêtres dans un oblet C++ de type ''VciParams'', qui est utilisé comme paramètre ''template'' par tous les composants matériels qui possèdent des ports de communication VCI.
+On utilise pour cela la techique des ''templates'' du langage C++ : on regroupe toutes les valeurs de ces paramêtres dans un oblet C++ de type `VciParams`, qui est utilisé comme paramètre ''template'' par tous les composants matériels qui possèdent des ports de communication VCI.
 (voir fichier ''vci_param.h'').
 
 Comme on l'a fait pour le canal de communication FIFO, on définit trois objets, qui facilitent l'écriture des modèles de simulation CABA :
- * l'objet ''VciSignals'' regroupe tous les signaux (commande et réponse) d'un canal VCI. (voir fichier ''vci_signals.h'')
- * l'objet ''VciInitiator'' regroupe tous les ports utilisés par un initiateur VCI pour émettre une commande, et recevoir la réponse. (voir fichier ''vci_initiator.h'')
- * l'objet ''VciTarget'' regroupe tous les ports utilisés par une cible VCI pour émettre une réponse, et recevoir une commande. (voir fichier ''vci_target.h'')
-Ces trois objets possèdent évidemment un paramètre template de type ''VciParams''. 
+ * l'objet `VciSignals` regroupe tous les signaux (commande et réponse) d'un canal VCI. (voir fichier ''vci_signals.h'')
+ * l'objet `VciInitiator` regroupe tous les ports utilisés par un initiateur VCI pour émettre une commande, et recevoir la réponse. (voir fichier ''vci_initiator.h'')
+ * l'objet `VciTarget` regroupe tous les ports utilisés par une cible VCI pour émettre une réponse, et recevoir une commande. (voir fichier ''vci_target.h'')
+Ces trois objets possèdent évidemment un paramètre template de type `VciParams`. 
 
 = 4 Outillage logiciel =
@@ -96 +95 @@
 == 4.1 Indexation des composants VCI ==
 
-On assigne à tout composant matérielpossédant un port VCI  (composant ''cible ou composant ''initiateur'') un index permettant de l'identifier de façon unique. Cet index peut être éventuellement structuré (on parle d'index composite) si l'architecture est structurée ''clusters''.  Un index composite est la concaténation d'un index global (le numéro de cluster) et d'un index local (à l'intérieur d'un cluster). 
+On assigne à tout composant matériel possédant un port VCI  (composant ''cible'' ou composant ''initiateur'') un index permettant de l'identifier de façon unique. Cet index peut être éventuellement structuré (on parle d'index composite) si l'architecture est structurée ''clusters''.  Un index composite est la concaténation d'un index global (le numéro de cluster) et d'un index local (à l'intérieur d'un cluster). 
 
 La plate-forme SoCLib définit la classe C++ ''!IntTab'' pour représenter ces index composites. (voir fichier ''int_tab.h''). 
@@ -104 +103 @@
 
 Dans une architecture à mémoire partagée, on assigne à tout composant ''cible'' un (ou plusieurs) segment(s) dans l'espace adressable.
-Un segment est une ''tranche" de l'espace adressable. Il possède donc une adresse de base, et une taille (en nombre d'octets). La taille d'un 
+Un segment est une ''tranche'' de l'espace adressable. Il possède donc une adresse de base, et une taille (en nombre d'octets). La taille d'un 
 segment peut être très variable : de quelques d'octets pour un périphériques adressable, à quelques Moctets pour un contrôleur mémoire.
 C'est en analysant les bits de poids fort de l'adresse que le sous-système d'interconnexion détermine à quel segment appartient l'adresse, 
@@ -145 +144 @@
 
 Cette archive contient les fichiers généraux suivants, extraits de la plate-forme SoCLib :
- * ''vci_param.h'' : definition des paramètres VCI.
- * ''vci_signals.h'' : definition d'un canal VCI.
- * ''vci_initiator.h'' : définition d'un port VCI initiateur.
- * ''vci_target.h'' : définition d'un port VCI cible.
- * ''int_tab.h'' : définition des index composites.
- * ''segment.h'' : définition d'un segment de l'espace adressable.
- * ''segment.cpp'' : implémentation des méthodes du segment.
- * ''mapping_table.h'' : définition de la mapping table.
- * ''mapping_table.cpp'' : implémentation des méthodes de la mapping table.
- * ''address_decoding_table.h'' : table indexée par une partie de l'adresse.
- * ''address_decoding_table.cpp'' : implémentation des méthodes de la table indexée.
- * ''alloc_elems.h" : allocation de tableaux d'objets complexes
+ * `vci_param.h` : definition des paramètres VCI.
+ * `vci_signals.h` : definition d'un canal VCI.
+ * `vci_initiator.h` : définition d'un port VCI initiateur.
+ * `vci_target.h` : définition d'un port VCI cible.
+ * `int_tab.h` : définition des index composites.
+ * `segment.h` : définition d'un segment de l'espace adressable.
+ * `segment.cpp` : implémentation des méthodes du segment.
+ * `mapping_table.h` : définition de la mapping table.
+ * `mapping_table.cpp` : implémentation des méthodes de la mapping table.
+ * `address_decoding_table.h` : table indexée par une partie de l'adresse.
+ * `address_decoding_table.cpp` : implémentation des méthodes de la table indexée.
+ * `alloc_elems.h` : allocation de tableaux d'objets complexes
 L'archive contient également les fichiers suivants :
- * ''vci_lcd_master.h'' : définition du composant ''!VciLcdMaster'' (fichier complet)
- * ''vci_lcd_master.cpp'' : méthodes associées (fichier incomplet)
- * ''vci_lcd_coprocessor.h'' : définition du composant ''!VciLcdCoprocessor''. (fichier complet)
- * ''vci_lcd_coprocessor.cpp'' : méthodes associées (fichier incomplet)
- * ''vci_gsb.h'' : définition du composant ''!VciGsb''. (fichier complet)
- * ''vci_gsb.cpp'' : méthodes associées (fichier complet)
- * ''tp2_simple_top.cpp'' : top-cell d'une architecture simple à deux composants (fichier incomplet)
-
-== 5.1 Composant ''!VciLcdCoprocessor ==
+ * `vci_lcd_master.h` : définition du composant `VciLcdMaster` (fichier complet)
+ * `vci_lcd_master.cpp` : méthodes associées (fichier incomplet)
+ * `vci_lcd_coprocessor.h` : définition du composant `VciLcdCoprocessor`. (fichier complet)
+ * `vci_lcd_coprocessor.cpp` : méthodes associées (fichier incomplet)
+ * `vci_vgsb.h` : définition du composant `VciVgsb`. (fichier complet)
+ * `vci_vgsb.cpp` : méthodes associées (fichier complet)
+ * `tp2_simple_top.cpp` : top-cell d'une architecture simple à deux composants (fichier incomplet)
+
+== 5.1 Composant ''!VciLcdCoprocessor'' ==
 
 Le composant ''!VciLcdCoprocessor'' se comporte comme un périphérique adressable, et doit donc être
@@ -172 +171 @@
 (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 = 16octets.
+Par conséquent, le segment occupé par ce périphérique dans l'espace adressable a une taille de `4*4` = 16 octets.
 
 Pour simplifier le décodage des adresses, on impose la contrainte que l'adresse de base de ce segment est
@@ -195 +194 @@
 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 ''!VciLcdCoprocessor''.
+La figure ci-dessous décrit la structure de l'automate de contrôle du composant `VciLcdCoprocessor`.
 
 [[Image(soclib_tp2_coprocessor.png)]]
 
-Le fichier ''vci_lcd_coprocessor.h'' contient une définition complête du composant ''!VciLcdCoprocessor''.
+Le fichier `vci_lcd_coprocessor.h` contient une définition complête du composant `VciLcdCoprocessor`.
 Il n'a pas besoin d'être modifié, mais vous aurez besoin de le lire attentivement pour modifier 
-le fichier ''vci_lcd_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()''.
+le fichier `vci_lcd_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()`.
 
 == 5.2 Composant ''!VciLcdMaster'' ==
 
-Le composant ''!VciLcdMaster'' est un initiateur VCI, qui exécute une boucle infinie dans laquelle il exécute
+Le composant `VciLcdMaster` est un initiateur VCI, qui exécute une boucle infinie dans laquelle il exécute
 successivement les 6 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 LCD. 
- 1. écriture de l'opérande OPB dans le registre ''r_opb'' du coprocesseur LCD.
- 1. écriture dans le pseudo-registre ''r_start'' du coprocesseur LCD.
- 1. lecture du résultat dans le registre ''r_res'' du coprocesseur LCD.
+ 1. écriture de l'opérande OPA dans le registre `r_opa` du coprocesseur LCD. 
+ 1. écriture de l'opérande OPB dans le registre `r_opb` du coprocesseur LCD.
+ 1. écriture dans le pseudo-registre `r_start` du coprocesseur LCD.
+ 1. lecture du résultat dans le registre `r_res` du coprocesseur LCD.
  1. affichage des résultats.
 
@@ -218 +217 @@
 segment de l'espace adressable aui a été assigné au coprocesseur LCD.
 Le composant ''!VciLcdMaster'' étant un automate cablé (non programmable), on considère
-que cette adresse est également "cablée". Elle est donc définie comme un paramètre du constructeur.
+que cette adresse est également "câblée". Elle est donc définie comme un paramètre du constructeur.
  
 La figure ci-dessous décrit la structure de l'automate de contrôle du composant ''!VciLcdMaster''.
@@ -228 +227 @@
 dans lequel on attend la réponse (on reste dans cet état tant qu'on a pas reçu une réponse valide).
 
-Le fichier ''vci_lcd_coprocessor.h'' contient une description complête du composant ''!VciLcdMaster''.
+Le fichier `vci_lcd_coprocessor.h` contient une description complète du composant `!VciLcdMaster`.
 Il n'a pas besoin d'être modifié, mais vous devez le lire attentivement pour modifier
-le fichier ''vci_lcd_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()''.
+le fichier `vci_lcd_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()`.
 
 == 5.3 Architecture minimale ==
 
-Pour valider les modèles de simulation des composants ''!VciLcdMaster'' et ''!VciLcdCoprocessor'', 
+Pour valider les modèles de simulation des composants `VciLcdMaster` et `VciLcdCoprocessor`, 
 on construit une architecture minimale ne contenant que deux composants matériels, conformément au schéma ci-dessous :
 
@@ -243 +242 @@
 en précisant :
  * les caractéristiques du segment mémoire associé au coprocesseur LCD.
- * les valeurs des paramètres VCI (largeurs des champs) dans l'objet vci_param.
+ * les valeurs des paramètres VCI (largeurs des champs) dans l'objet `vci_param`.
  * les valeurs des arguments des constructeurs des deux composants.
 On prendra pour valeurs des paramètres VCI les valeurs définies en commentaire dans le fichier ''tp2_simple_top.cpp''.
@@ -251 +250 @@
 Il faut ensuite 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''!VciLcdMaster'', ''!VciLcdCoprocessor''. 
+du paramètre template `vci_param` des composants `VciLcdMaster`, `VciLcdCoprocessor`. 
 Dans un contexte de compilation séparée, il est nécessaire de définir explicitement la valeur de ce paramètre
 dans chacun des fichiers source avant de lancer la génération du fichier objet associé. 
-Pour cela, il faut rajouter la ligne suivante à la fin du fichier ''vci_lcd_master.cpp'' :
+Pour cela, il faut rajouter la ligne suivante à la fin des fichiers `vci_lcd_master.cpp` et `vci_lcd_coprocessor.cpp` :
 {{{
 template class VciLcdMaster<soclib::caba::VciParams<4, 8, 32, 1, 1, 1, 12, 1, 1, 1> >;
 }}}
-Il faut évidemment modifier également le fichier ''vci_lcd_coprocessor.cpp''.
-
-Ceci étant fait, écrivez le Makefile permettant la génération du fichier exécutable ''simple_simulator.x''.
-N'oubliez pas d'inclure dans la liste des fichiers objets les fichiers ''mapping_table.o'', ''segment.o'', ''address_decoding_table.o'',
-''address_masking_table.o'' (en plus des fichiers objet correspondant aux deux composants matériels
+(pensez à changer le nom de la classe pour `vci_lcd_coprocessor.cpp`.
+
+Ceci étant fait, écrivez le Makefile permettant la génération du fichier exécutable `simple_simulator.x`.
+N'oubliez pas d'inclure dans la liste des fichiers objets les fichiers `mapping_table.o`, `segment.o`, `address_decoding_table.o`,
+`address_masking_table.o` (en plus des fichiers objet correspondant aux deux composants matériels
 
 Le lancement du simulateur doit vous fournir la même trace d'exécution que celle que obtenue dans le TP1, puisque 
@@ -269 +268 @@
 == 5.5 Architecture multi-maitres ==
 
-L' architecture interne du composant ''!VciVgsb'' est décrite dans la figure ci-dessous.
-Le ''bus'' des commandes VCI, et le ''bus'' des réponses VCI sont modélisés par des multiplexeurs. Ces multiplexeurs sont
+L' architecture interne du composant `VciVgsb` est décrite dans la figure ci-dessous.
+Le `bus` des commandes VCI, et le `bus` des réponses VCI sont modélisés par des multiplexeurs. Ces multiplexeurs sont
 commandés par un automate à trois états qui réalise une priorité tournante entre les initiateurs.
 Comme vous pouvez le constater sur le schéma, ce composant se comporte comme un automate de Mealy,
@@ -279 +278 @@
 [[Image(soclib_tp2_bus.png)]]
 
-En vous inspirant du fichier ''tp2_simple_top.cpp'' de la question précédente, écrivez le fichier ''tp2_multi_top.cpp'', 
+En vous inspirant du fichier `tp2_simple_top.cpp` de la question précédente, écrivez le fichier `tp2_multi_top.cpp`, 
 qui décrit l'architecture à 7 composants décrite au début de ce TP. Vous ferez en sorte que le maitre (i) communique 
 avec le coprocesseur (i). N'oubliez pas de définir 3 segments différents pour les trois coprocesseurs.
 
-Il faut également ajouter à la fin du fichier ''vci_vgsb.cpp'' la ligne permettant de définir la valeur du paramètre template
-''vci_param'' :
+Il faut également ajouter à la fin du fichier `vci_vgsb.cpp` la ligne permettant de définir la valeur du paramètre template
+`vci_param` :
 {{{
 template class VciVgsb<soclib::caba::VciParams<4, 8, 32, 1, 1, 1, 12, 1, 1, 1> >;
 }}}
 
-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''
+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