}}}
[[PageOutline]]
= 1 Objectifs =
L'objectif de ce TP est d'analyser en détail le modèle SystemC CABA d'un ''vrai'' composant matériel complexe.
On va analyser le composant '''!VciXcacheWrapper''', dont l'architecture interne a été présentée dans le
cours MPSOC. Ce composant contient quatre automates fonctionnant en parallèle (DCACHE_FSM, ICACHE_FSM,
CMD_FSM et RSP_FSM). Ces automates communiquent entre eux par des registres protégés par des bascules de type SET/RESET.
Il contient de plus un tampon d'écriture postées, qui ne permet qu'une seule transaction d'écriture VCI à la fois.
Ce tampon est accédé par les trois automates DCACHE_FSM, CMD_FSM et RSP_FSM.
On souhaite modifier le composant '''!VciXcacheWrapper''' pour qu'il utilise un tampon d'écritures postées
plus évolué, supportant plusieurs transactions VCI simultanées, et on veut évaluer le gain en performance obtenu.
= 2 Analyse du composant !VciXcacheWrapper =
Créez un répertoire de travail TP6, et décompressez l'archive [attachment:soclib_tp6.tgz soclib_tp6.tgz].
Cette archive contient en particulier les deux fichiers '''tp6_top.cpp''' et '''tp6_top.desc''', qui définissent une architecture
monoprocesseur presque identique à celle du TP4. Elle contient une ROM, une RAM, un TIMER, un contrôleur TTY,
un contrôleur de disque IOC, un contrôleur d'écran graphique FBF, un coprocesseur GCD, un contrôleur DMA et
un concentrateur d'interruptions ICU.
La seule différence par rapport au TP4 est qu'on utilise un micro-réseau (composant '''!VciVgmn''') au lieu d'un bus
(composant '''!VciVgsb'''). Le micro-réseau supporte plusieurs transactions simultanées, mais possède une latence
importante: 20 cycles minimum pour acheminer la commande VCI, et autant pour acheminer la réponse VCI.
L'application logicielle qui se trouve dans le répertoire '''soft''' est l'application d'affichage d'images sur le terminal
graphique du TP4. Vous devez donc re-utiliser le fichier '''images.raw''' que vous avez utilisé dans le TP4.
Compilez l'application logicielle dans le répertoire '''soft''' . Générez le simulateur du prototype virtuel en utilisant
le Makefile qui vous est fourni. Lancez l'éxécution de l'application logicielle sur le prototype virtuel:
{{{
$ ./simulator.x -IOCFILE path_to_images.raw
}}}
'''Question''' : Combien de cycles faut-il pour lire sur disque et afficher une image? Combien cela représente-t-il de cycles par pixel?
Vous pouvez consulter le code du composant !VciXcacheWrapper [https://www.soclib.fr/trac/dev/wiki/Component/VciXcacheWrapper ici], en cliquant sur les liens définis dans la
section 2 (CABA implementation).
Ce composant utilise deux objets C++ pour représenter le tampon d'écritures postées
([https://www.soclib.fr/trac/dev/browser/trunk/soclib/soclib/lib/write_buffer write_buffer] et les deux caches
([https://www.soclib.fr/trac/dev/browser/trunk/soclib/soclib/lib/generic_cache generic_cache].
Il faut vraiment aller regarder dans le code pour répondre aux questions suivantes:
'''Question''' : Comment est implémenté l'interface entre le cache et le processeur?
'''Question''' : En analysant le code de la fonction de transition (et en vous appuyant sur le cours MPSOC, représenter graphiquement les graphes de transition des 4 automates ICACHE_FSM, DCACHE_FSM, CMD_FSM, RSP_FSM.
'''Question''' : Quelles sont les 5 types de transactions VCI qui peuvent être émises par ce contrôleur de cache ?
Puisque ce contrôleur de cache possède un seul port VCI initiateur, l'automate CMD_FSM doit respecter une priorité en cas de requêtes simultanées. Quelle est la politique de priorité implémentée par ce contrôleur ?
'''Question''' : En consultant le code de l'objet write_buffer, expliquez le fonctionnement du tampon d'écritures postées.
A quelle condition une transaction d'écriture VCI aura-t-elle une longueur supérieure à un flit?
'''Question''' : Donner l'expression de la condition ''irsp.valid'' (réponse valide à une requête de lecture instruction en provenance du processeu)?
'''Question''' : Donner l'expression de la condition ''drsp.valid'' (réponse valide à une requête de lecture ou d'écriture de donnée en provenance du processeu)?
Le composant !VciXcacheWrapper contient un certains nombres de compteurs d'activité permettant d'afficher des statistiques sur le comportement du processeur et du cache. Ces compteurs sont les variables membre de la
classe !VciXcacheWrapper qui sont préfixées par '''m_'''. Ces compteurs d'instrumentation se comportent
comme des registres: ils sont donc initialisés lors du reset et sont incrémentés dans la fonction de transition.
'''Question''' : Comment est calculé le nombre moyen de cycles par instruction (CPI) ?
'''Question''' : Comment sont calculés le ''miss_rate'' (taux de miss) et le ''miss_cost'' (coût moyen du miss) pour chacun des deux caches ?
'''Question''' : A quoi correspond le ''write_cost" (cout moyen d'écriture) pour le tampon d'écritures postées ? comment est-il calculé?
Relancez la simulation en activant la génération des statistiques (avec une période de 100000 cycles) avec la commande suivante:
{{{
$ ./simulator.x -IOCFILE path_to_images.raw -STATS 100000
}}}
'''Question''' : Qelles valeurs obtenez-vous à la fin de l'affichage de la première image pour le CPI, pour les différentes caractéristiques définies ci-dessus ? Comment interprêtez-vous ces résultats ?
= 3 Modification du composant !VciXcacheWrapper =
L'archive '''soclib_tp6.tgz''' qui vous est fournie comporte