Changes between Version 42 and Version 43 of SoclibCourseTp5

Timestamp:

Dec 25, 2010, 11:16:36 PM (14 years ago)

Author:

alain

Comment:

--

SoclibCourseTp5

@@ -233 +233 @@
  * D'un point de vue électrique, le découpage en clusters permet de résoudre en partie les problèmes d'horlogerie, puisque chaque cluster peut être implanté dans un domaine d'horloge séparé (approche GALS : Globally Asynchronous / Locally Synchronous). Le franchissement des frontières d'horlogre est alors la responsabilité du micro-réseau assurant les communications inter-clusters.
 
-Remarquez cependant quela capacité de stockage de la mémoire embarquée n'est jamais suffisante, et que l'accès à la mémoire externe reste un goulot d'étranglement.
+Remarquez cependant que la capacité de stockage de la mémoire embarquée n'est jamais suffisante, et que l'accès à la mémoire externe reste un goulot d'étranglement.
 
 == 3.1 structuration des adresses et des identifiants ==
@@ -254 +254 @@
 
 On souhaite modéliser une architecture structurée en quatre clusters presque identiques, 
-Chaque cluster contiendra un processeur MIPS32, un composant ICU, un contrôleur TTY, un TIMER et une mémoire RAM. 
+Chaque cluster contiendra un processeur MIPS32 (avec son contrôleur de cache), un composant ICU, un contrôleur TTY, un TIMER et une mémoire RAM. 
  * On se dispensera d'instancier le coprocesseur GCD dans cette architecture.
  * On placera le contrôleur de disque IOC dans le cluster 0.
@@ -287 +287 @@
 
 '''Question''' : Proposez des adresses de base pour ces 25 segments, en tenant compte du fait que le crossbar local ne doit décoder que les bits (LADR) de l'adresse, et que le réseau global ne doit décoder que les bits (GADR) de l'adresse. Tenez compte du fait que dans chaque cluster, il existe au moins un segment appartenant à l'espace ''utilisteur'' (le segment de pile), et trois segments appartenant à l' espace superviseur (les segments associés au TTY, au TIMER et à l'ICU).
-Recommandation : on peut utiliser 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é.   
+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, et pour préciser le nombre de processeurs.
@@ -296 +296 @@
 == 3.3 Logiciel embarqué ==
 
-Le logiciel doit être assez profondément modifié : 
- * '''code de boot''' (fichier '''reset.s''') : Lors du démarrage, les quatre processeurs vont  exécuter le même code (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.
- * '''code des ISR''' (fichier '''isr.s''') : Les deux ISR ''_isr_timer'' et ''_isr_tty_get'' doivent être modifiées pour tenir compte du processor_id : chaque processeur doit adresser le TIMER et le terminal TTY qui lui appartient.
- * '''code du GIET''' (fichier '''giet.s''') : Le gestionnaire d'interrutions lui aussi doit être modifié, puisqu'il doit maintenant utiliser le processor_id pour interroger le bon contrôleur ICU.
- * '''code des appels systèmes''' (fichier '''syscalls.c''') : Les deux fonctions système _icu_write() et _icu_read() doivent être modifiées pour tenir compte du processor_id lors des accès aux registres du composant ICU.
- * '''segmentation''' (fichier '''ldscript''') : Il ne faut pas oublier de modifier le fichier ldscript pour que les adresses de base des segments soient cohérentes avec ce qui a été défini dans le fichier '''tp5_top.cpp'''.
-
-En sortie de la séquence de boot, les quatre processeurs se branchent à la même fonction '''main()''', qui doit elle aussi être modifiée pour tenir compte du processor_id, puisque le numéro du timer
-est un argument des fonctions ''timer_set_period()'' et ''timer_set_mode()''. 
+On va commencer par exécuter le même programme interactif 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.
+
 
 Si tout se passe normalement, les quatre processeurs doivent exécuter le même programme interactif ''Hello World'' (avec affichage des interruptions générées par les timers), chacun
@@ -311 +306 @@
 Si ce n'est pas le cas, il vous reste le '''GDB Server'''...
 
+== 3.4 Appliction multi_tâches coppératives ==
+
 = 4 Compte_rendu =