Changes between Version 46 and Version 47 of SoclibCourseTp5

Timestamp:

Dec 26, 2010, 2:19:00 PM (14 years ago)

Author:

alain

Comment:

--

SoclibCourseTp5

@@ -8 +8 @@
 
 Ce cinquième TP a un double objectif : D'une part, on présente l'outil '''GDB Server''' qui est le principal outil permettant de déverminer une application logicielle s'exécutant sur une architecture matérielle prototypée avec SoCLib.
-D'autre part, on présente les outils permettant de décrire des architectures clusterisées utilisant deux niveaux d'interconnexion et donc deux niveaux d'indexation.   
+D'autre part, on introduit les architectures clusterisées utilisant deux niveaux d'interconnexion et donc deux niveaux d'indexation pour les composants matériels.   
 
 = 2 Outil GDB Server =
 
-L'outil GDB est un outil de debug très utilisé, qui fait partie de la même famille d'outils logiciels libres que le
+L'outil GDB est un outil debug très utilisé, qui fait partie de la même famille d'outils logiciels libres que le
 compilateur GCC que vous connaissez déjà (voir [http://www.gnu.org/software/gdb/ Gnu GDB]).
 
-Le '''GDB Server''' est un composant matériel qui vient s'interfacer entre le processeur et le contrôleur de cache. Dans cette position stratégique, il peut surveiller et contrôler toutes les communications entre le
-processeur et le reste de la plate-forme matérielle (principalement la mémoire).
+Le '''GDB Server''' est un composant matériel qui s'interface entre le processeur et le contrôleur de cache. Dans cette position stratégique, il peut surveiller et contrôler toutes les communications entre le processeur et le reste de la plate-forme matérielle (principalement la mémoire).
 
 [[Image(soclib_tp5_gdb_server.png)]]
@@ -22 +21 @@
 Le comportement du composant matériel '''GDB server''' est lui-même contrôlé par une application logicielle interactive, appelée '''GDB client''', qui peut s'exécuter sur  une autre station de travail que celle qui simule l'exécution de la plate-forme  modélisée avec SoCLib. 
 
-En prenant le contrôle du GDB Server (par l'intermédiaire du client GDB), on peut donc faire deux choses :
+En agissant sur le GDB Server (par l'intermédiaire du client GDB), on peut donc faire deux choses :
  * contrôler le processeur (pour le faire fonctionnner en pas à pas par exemple), 
  * contrôler le reste du système (en effectuant directement des commandes de lecture ou d'écriture vers la mémoire).
@@ -294 +293 @@
 Recommandation : on utilisera les 4 bits A[31:28] pour le champs GADR, en considérant que seuls les 2 bits A[29:28] sont réellement discriminants pour désigner le cluster visé.   On utilisera les 4 bits A[27:24] pour le champs LADR.
 
-'''Question''' : Modifiez le fichier '''ldscript''' pour définir ces adresses de bases, ainsi que le nombre de processeurs.
 
 '''Question''' : Complétez les deux fichiers '''tp5_top_cluster.cpp''' et '''tp5_top_cluster.desc''' correspondant à cette architecture.
 n'oubliez pas de donner des valeurs croissantes (de 0 à 3) à l'argument ''processor-id'' des 4 processeurs.
 
-== 3.3 Logiciel embarqué ==
+== 3.3 application '"hello world" ==
 
 On va commencer par exécuter le même programme d'affichage du messge ''hello world'' sur chacun des 4 processeurs.
  
-Comme dans le cas de l'architecture multi-processeur du TP4, les 4 processeurs exécutent le même code de boot (puisqu'ils se branchent à la même adresse 0xBFC00000), mais les actions réalisées peuvent dépendre du processor_id. En particulier, les pointeur de pile des quatre processeurs doivent être initialisés à des valeurs différentes puisque chaque processeur travaille dans son propre segment de pile.
-
-Question''' : lancez la simulation. Les quatre processeurs doivent exécuter le même programme interactif, chacun sur son propre terminal TTY. 
+Comme dans le cas de l'architecture multi-processeur du TP4, les 4 processeurs exécutent le même code de boot (puisqu'ils se branchent à la même adresse 0xBFC00000), mais les actions réalisées peuvent dépendre du processor_id : 
+ * les pointeur de pile des quatre processeurs doivent être initialisés à des valeurs différentes puisque chaque processeur travaille dans son propre segment de pile.
+ * chaque processeur doit configurere son propre composant concentrateur d'interruption ICU.
+ * chaque processeur se branche à une adresse de base différente, définie dans le tableau
+
+'''Question''': Complétez le code de boot dans le fichier '''reset.s''' du répertoire '''soft_cluster'''.
+
+'''Question''' : Modifiez le fichier '''ldscript''' pour définir les adresses de bases des 25 segments, ainsi que le nombre de processeurs.
+
+'''Question''' : lancez la simulation. Les quatre processeurs doivent exécuter le même programme interactif, chacun sur son propre terminal TTY. 
 
 Si ce n'est pas le cas, il vous reste le '''GDB Server'''...