TP6 : Modélisation d'un contrôleur de cache L1

1 Objectifs

L'objectif de ce TP est d'analyser en détail le modèle du 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), qui communiquent entre eux par des registres protégés par des bascules de type SET/RESET.

Il contient 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.

Après avoir analysé en détail le comportement du composant VciXcacheWrapper, on souhaite le modifier pour qu'il utilise un tampon d'écritures postées plus évolué, supportant plusieurs transactions VCI simultanées, et on évaluera expérimentalement le gain en performance obtenu.

2 Analyse du composant VciXcacheWrapper

Créez un répertoire de travail TP6, et décompressez l'archive 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 n(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 ​ici, en cliquant sur les liens définis dans la section 2 (CABA implementation).

Ce composant utilise deux classes C++ pour représenter d'une part le tampon d'écritures postées (​write_buffer), et d'autre part les deux caches instructions et données (​generic_cache).

Il faut lire le code du contrôleur de cache pour répondre aux questions suivantes:

Question : Comment est implémenté l'interface entre le contrôleur de cache et l'ISS (Instruction Set Simulator) représentant le processeur?

Question : Quels sont les deux conditions de sortie de l'état IDLE de l'automate ICACHE_FSM ?

Question : Si la réponse VCI à une lecture d'instruction signale une erreur d'adressage, comment cette erreur est-elle signalée au processeur?

Question : Quelles sont les six conditions de sortie de l'état IDLE de l'automate DCACHE_FSM ? Quelles sont les deux requêtes spéciales (autres que des lectures ou des écritures en mémoire) qui sont acceptées par ce composant ?

Question : Si la réponse VCI à une lecture de donnée signale une erreur d'adressage, comment cette erreur est-elle sinalée au processeur? Comment est signalée une erreur d'adressage suite une écriture ?

Question : 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 les différentes caractéristiques définies ci-dessus ? Comment interprêtez-vous ces résultats ?

3 Modification du composant VciXcacheWrapper

On a vu dans la section précédente que - lorsque la latence des transactions est importante - le processeur est souvent gelé en raison de requêtes d'écriture qui ne peuvent être satisfaites car le tampon d'écritures est plein. On souhaite donc modifier le contrôleur de cache pour qu'il utilise un tampon d'écritures plus évolués, permettant de ne pas attendre la réponse à une transaction d'écriture (n) pour envoyer la commande de la transaction (n+1). On souhaite également que les transactions de lecture - qui entraînent un gel du processeur - soient prioritaires par rapport aux transactions d'écriture (si les adresses sont différentes).

L'objet C++ ​multi_write_buffer modélise un tampon d'écritures postées plus évolué, permettant de stocker plusieurs requêtes d'écriture indépendantes. Chacune de ces requêtes peut avoir une longueur supérieure à un flit.

Il faut commencer par analyser le code du multi_write_buffer pour répondre aux questions suivantes:

Question : Quelle est la signification des 4 arguments du constructeur de cet objet ?

Question : Quels sont les quatre états possibles d'une ligne du multi_write_buffer ? Question : Qelles sont la ou les méthodes qui peuvent être utilisées par l'automate DCACHE_FSM pour modifier l'état interne du multi_write_buffer ?

Question : Qelles sont la ou les méthodes qui peuvent être utilisées par l'automate CMD_FSM pour modifier l'état interne du multi_write_buffer ?

Question : Quelles sont la ou les méthodes qui peuvent être utilisées par l'automate RSP_FSM pour modifier l'état interne du multi_write_buffer ?

Question : A quoi sert la méthode update() ? Pourquoi doit-elle être appelée à chaque cycle ?

L'archive soclib_tp6.tgz qui vous est fournie contient un répertoire vci_xcache_wrapper_new, qui contient lui_même les 3 fichiers vci_xcache_wrapper_new.h, vci_xcache_wrapper_new.cpp, et vci_xcache_wrapper_new.sd, décrivant une version modifiée du contrôleur de cache L1. Certains fichiers sont incomplets, et vous devez les compléter.

Question : En comparant les fichiers d'interface vci_xcache_wrapper.h et vci_xcache_wrapper_new.h, identifiez les modifications qui ont été introduites.

Question : Complêtez le fichier d'implémentation vci_xcache_wrapper_new.cpp pour que ce composant supporte plusieurs transactions VCI simultanées, avec les priorités suivantes : IMISS > DMISS > WRITE > DUNC > IUNC. Attention: les requêtes DMISS et IMISS ne peuvent passer avant les requêtes de type WRITE enregistrées dans le tampon d'écritures que si elles portent sur des adresses différentes ! Question : Pourquoi les requêtes correspondant à des accès non cachés (en lecture ou en écriture) ne sont-elles traitées qu'après les requêtes d'écriture ?

Question : Complêtez le fichier de description vci_xcache_wrapper_new.sd.

Question : Modifiez les fichier tp6_top.cpp et tp6_top.desc décrivant l'architecture globale, pour instancier le composant VciXcacheWrapperNew à la place du composant VciXcacheWrapper, et renommez ces fichiers tp6_top_new.cpp et tp6_top_new.desc.

Générez le prototype virtuel pour l'architecture ainsi modifiée avec la commande ci-dessous. L'argument ( -I vci_xcache_wrappe_new ) indique à l'outil de compilation soclib-cc qu'il doit utiliser le répertoire local vci_xcache_wrapper_new.

$ soclib-cc -P -p tp6_top_new.desc -o simulator_new.x -I vci_xcache_wrapper_new

Lancez l'exécution, en définissant sur la ligne de commande les paramètres du tampon d'écritures. On choisira pour commencer un gros tampon contenant 8 lignes de 4 mots de 32 bits, et on activera l'affichage des statistiques :

$ ./simulator_new.x -IOCFILE path_to_images.raw -WBUFW 4 -WBUFL 8 -STATS 100000

Question : Combien faut_il de cycles pour afficher une image? Quel est le gain en performance apporté par l'utilisation du composant multi_write_buffer? Comment interprêtez-vous ce résultat ?

Question : Est-il possible de diminuer la taille du tampon d'écriture postées sans dégrader trop fortement les performances ?

4 Compte-Rendu

Il ne vous est pas demandé de compte-rendu pour ce TP, mais on vous demandera une démonstration de votre simulateur au début du TP de la semaine suivante...