Changes between Version 62 and Version 63 of SoclibCourseTp5
- Timestamp:
- Jan 1, 2011, 8:23:28 PM (14 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
SoclibCourseTp5
v62 v63 260 260 * On placera la ROM de boot dans le cluster 3. 261 261 262 On utilisera un composant '''vci_local_crossbar''' comme interconnect local ( voir documentation [https://www.soclib.fr/trac/dev/wiki/Component/VciXcacheWrapper ici]) , et on utilisera le composant '''vci_vgmn''' comme interconnect global (voir documentation [https://www.soclib.fr/trac/dev/wiki/Component/VciXcacheWrapper ici]) .262 On utilisera un composant '''vci_local_crossbar''' comme interconnect local (voir documentation [https://www.soclib.fr/trac/dev/wiki/Component/VciXcacheWrapper ici]) , et on utilisera le composant '''vci_vgmn''' comme interconnect global (voir documentation [https://www.soclib.fr/trac/dev/wiki/Component/VciXcacheWrapper ici]) . 263 263 264 264 [[Image(soclib_tp5_archi_clusters.png)]] … … 287 287 '''Question''' : Pourquoi faut-il des segments distincts pour les 4 piles d'exécution ? 288 288 289 '''Question''' : 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). Expliquer ourquoi ne peut-on pas utiliser directement (c'est à dire sans décodage) les 2 bits de poids fort de l'adresse pour désigner le cluster? 290 291 '''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. 292 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. 289 '''Question''' : Pourquoi ne peut-on pas utiliser directement (c'est à dire sans décodage) les 2 bits de poids fort de l'adresse pour désigner le cluster? Indication : 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). 290 291 '''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. 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. 293 292 294 293 '''Question''' : Complétez le fichier '''tp5_top_cluster.cpp''' décrivant cette architecture. Il faut préciser les valeurs des adresses de base et les longueurs des segments. Il faut définir les arguments des constructeurs des composants matériels, et il faut définir la net-list. … … 299 298 on va commencer par exécuter le programme d'affichage du message ''hello world'', en parallèle sur chacun des 4 processeurs. 300 299 301 Le code de boot, contenu dans le fichier '''reset.s''', doit supporter des applications logicielles où les 4 processeurs exécutent 4 programmes différents. 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 certaines actions dépendent du processor_id :300 Le code de boot, contenu dans le fichier '''reset.s''', doit supporter des applications logicielles où les 4 processeurs exécutent 4 programmes différents. Les 4 processeurs exécutent le même code de boot (puisqu'ils se branchent à la même adresse 0xBFC00000), mais certaines actions dépendent du processor_id : 302 301 * 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. 303 302 * chaque processeur doit configurere son propre composant concentrateur d'interruption ICU. 304 303 * En sortie du code de boot, chaque processeur se branche à une adresse de base différente, définie dans la table de sauts ''tab_main''. 305 304 306 '''Question''': Complétez le code de boot dans le fichier '''reset.s''' .305 '''Question''': Complétez le code de boot dans le fichier '''reset.s''' pour initialiser la table de sauts. 307 306 308 307 '''Question''' : Modifiez le fichier '''ldscript''' pour définir les adresses de bases des 25 segments, ainsi que le nombre de processeurs. 309 308 310 '''Question''' : lancez la simulation: Les quatre processeurs doivent exécuter le même programme interactif, chacun sur son propre terminal TTY. 311 312 Si ce n'est pas le cas, vous pouvez utiliser le '''GDB Server'''... 309 '''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, vous pouvez utiliser le '''GDB Server'''... 313 310 314 311 == 3.4 Application "transpose" == 315 312 316 313 On veut maintenant exécuter une application parallèle multi-tâches coopérative, pour exploiter le parallélisme de l'architecture matérielle. 317 On s'intéresse à une application de traitement d'image réalisant une transposition (X <-> Y) de l'image.318 On utilisera le même flux d'image que dans le TP4, c'est à dire le fichier '''images.raw''' contenant une vingtaine d'images de 128 lignes de 128 pixels codées en 256 niveaux de gris.319 320 L'application logicielle contenue dans le répertoire '''soft_transpose''' est découpée en trois tâches logicielles, qui peuvent s'exécuter en parallèle sur trois processeur différents, et communiquent entre elles à travers deux tampons de communication en mémoire '''buf_in''' et '''buf_out'''.314 On s'intéresse à une application de traitement d'image réalisant une transposition (X <-> Y) de chaque image d'un flux d'images chargées depuis le disque. 315 On utilisera le même flux d'image que dans le TP4, c'est à dire le fichier '''images.raw''', qui contiennt une vingtaine d'images de 128 lignes de 128 pixels codées en 256 niveaux de gris. 316 317 L'application logicielle contenue dans le fichier '''main.c''' du répertoire '''soft_transpose''' est découpée en trois tâches logicielles, qui doivvent s'exécuter en parallèle sur trois proceseurs différents. Elles communiquent entre elles à travers deux tampons de communication en mémoire appelés'''buf_in''' et '''buf_out'''. Chaque tampon peut stocker une image complête 321 318 322 319 [[Image(soclib_tp5_transpose.png)]] … … 324 321 * La tâche '''load''' lit une image sur le disque et copie cette image dans le tampon buf_in. 325 322 * La tâche '''transpose''' lit l'image présente dans le tampon buf_in, effectue la transposition et écrit l'image résultante dans le tampon buf_out. 326 * La tâche '''display''' lit l'image présente dans le tampon buf_out, et affiche cette image sur le frame buffer. 327 Les deux tampons de communication buf_in et buf_out sont protégés par les deux variables de synchronisation '''buf_in_empty''' et 328 '''buf_out_empty''', qui supportent un protocole de synchronisation de type SET/RESET en mode utilisateur: 323 * La tâche '''display''' lit l'image présente dans le tampon buf_out, et affiche cette image sur l'écran graphique. en l'écrivant dans le frame buffer. 324 Les deux tampons de communication buf_in et buf_out sont protégés par les deux variables de synchronisation '''buf_in_empty''' et '''buf_out_empty''', qui supportent un protocole de synchronisation de type SET/RESET en mode utilisateur: 329 325 * La tâche productrice attend que la variable de synchronisation passe à 0 avant d'écrire, et force cette variable à 1 quand elle a fini de remplir le tampon. 330 326 * La tâche consommatrice attend que la variable de synchronisation passe à 1 avant de lire, et force cette variable à 0 quand elle a fini de vider le tampon. … … 334 330 '''Question''' : Modifiez le fichier '''reset.s''' dans le répertoire '''soft_transpose''' pour que les tâches '''load''', '''transpose''', et '''display''' s'exécutent sur les processeurs 0, 1 et 2 respectivement. 335 331 336 '''Question''' : Lancez la simulation. Quelle est la téquence d'affichage? (inverse du nombre de cycles entre deux affichages). 337 338 '''Question''' : Expliquez pourquoi, dans le fichier '''tp5_cluster_top.cpp''' décrivant l'architecture matérielle, le segment '''seg_data''' a été défini comme non cachable.332 '''Question''' : Lancez la simulation. Quelle est la téquence d'affichage? (inverse du nombre de cycles entre deux affichages). Il faut évidemment définir sur la ligne de commande le nom du fichier contenant les images (paramètre -IOCFILE), ainsi que la taille du frame buffer (paramètre -FBFSIZE). 333 334 '''Question''' : Pourquoi, dans le fichier '''tp5_cluster_top.cpp''' décrivant l'architecture matérielle, le segment '''seg_data''' a-t-il été défini comme non cachable? 339 335 340 336 '''Question''' : L'inconvénient du mécanisme de synchronisation par bascule SET/RESET est que les deux tâches productrice et consommatrice ne peuvent s'exécuter en parallèle. Comment peut-on modifier l'application logicielle pour augmenter le parallélisme et augmenter ainsi la fréquence d'affichage des images?
