wiki:Archi3TP1

Version 14 (modified by meunier, 6 years ago) (diff)

--

M2 SESI - Archi 3

TP1 : Machine d'états d'un cache L1 Write-Through cohérent

L'objectif de ce TP est de comprendre l'implémentation d'un protocole de cohérence de cache à un niveau de détail assez élevé (mais non caba).

Pour cela, on demande l'écriture des machines d'états d'un controlleur de cache L1 write-through et du controlleur mémoire associé.

1. Spécification

Dans cette première partie, il vous est demandé de dessiner sur une feuille (ou sur un logiciel adapté) les machines d'état du cache L1 write-through à invalidations et du contrôleur mémoire associé. La liste des états vous est donnée ci-dessous, il faut donc remplir chaque état avec les actions qui y sont associées et représenter les transitions entre états. Pour représenter les actions, vous pouvez utiliser du français ou du pseudo-code. Liste des états du contrôleur de cache :

IDLE,       // Traiter les requêtes en attente, répondre aux lectures qui font hit
INVAL,      // Traiter une invalidation reçue
MISS,       // Envoi d'un miss
SEND_WRITE, // Envoyer l'écriture d'un mot en mémoire et éventuellement mettre le cache à jour
MISS_WAIT   // Attendre la réponse à un miss et mettre à jour le cache lors de sa réception

Liste des états du contrôleur mémoire :

IDLE,       // Traiter les requêtes en attente
WRITE_WORD, // Écriture d'un mot
INVAL,      // Préparation de l'envoi d'une ou plusieurs invalidations
INVAL_SEND, // Envoi des invalidations
INVAL_WAIT, // Attente des réponses aux invalidations
DIR_UPDATE, // Mise à jour du répertoire
RSP_READ,   // Répondre à une lecture
RSP_WRITE   // Répondre à une écriture

Ce schéma fera partie du rendu, ne le négligez donc pas.

On s'intéresse pour ce TP uniquement à la partie données du cache : on suppose en effet que le processeur émet directement des requêtes de lecture et d'écritures, et non les adresses des instructions. De plus, on ne s'intéresse pas aux requêtes non cachées : on suppose donc que toutes les requêtes sont à des adresses cachées.

2. Prise en main des sources

Commencez par copier sur votre compte l'archive à l'emplacement ~meunier/Archi3CoherenceProtocol.tar.

Lancer eclipse. Suite à des problèmes récurrents de version du JRE ou du JDK, l'importation des sources est maintenant découplée de la création du projet. Il faut donc commencer par créer un nouveau projet (File > New > Project, puis onglet Java > Java Project, Next, donner un nom au projet, sélectionner Use default JRE et Create separate folders for sources and class files).

Il faut ensuite importer l'archive dans le dossier src. Il y a deux moyens pour cela (n'en faire qu'un des deux) :

  1. Cliquer droit sur le dossier src, Import, General, Archive File, Next, puis sélection de l'archive et Finish. Il faut ensuite renommer les packages pour enlever le src. qui se trouve en tête des noms (clic droit, refactor, rename).
  2. Supprimer le dossier src, cliquer droit sur le projet, Import, Archive File, Next, sélection et Finish, puis ajouter le nouveau dossier src à la liste des sources : clic droit sur le projet, Properties..., Java Build Path, Source, Add Folder, sélectionner le dossier, puis OK, OK.

Les classes du package view contiennent les éléments de l'interface graphique (sommaire), et celles du package controller les écouteurs associés. Il n'est pas nécessaire de les regarder dans le détail.

Les classes modélisant l'architecture sont dans le package model.

La figure ci-dessous présente un diagramme objet simplifié pour une architecture avec deux processeurs / caches L1 et un banc mémoire.

Commencer par regarder les méthodes du cache L1 (CacheL1.java). Pour le protocole write-through, vous aurez a priori besoin d'utiliser uniquement les méthodes read(), write() et inval(). Pour rester réaliste, il vous est demandé de ne faire qu'un seul accès au cache et à la mémoire par cycle, en lecture ou en écriture, à la partie données et/ou meta-données. De même, on impose comme contrainte de n'envoyer qu'une requête par canal par cycle.

Regardez également (au moins) le contenu des classes Request et LineState, ainsi que les méthodes de la classe CopiesList (Note : tous les types de requêtes ne sont pas à utiliser).

Remarques :

  • Les attributs m_req et m_iss_req du cache contiennent respectivement les dernières requêtes reçues en provenance de la mémoire (requête de cohérence) et du processeur. Ils sont écrits par les méthodes getRequest() et getIssRequest(), et peuvent donc être lus autant de fois que nécessaire jusqu'à la réception de la requête suivante.
  • Les méthodes getRequest() et getIssRequest() citées au-dessus ne doivent être appelées que lorsqu'il y a une requête présente sur le port correspondant.
  • Normalement, il n'est pas nécessaire d'ajouter des variables membre dans les classes des contrôleurs. Si vous souhaitez tout de même en ajouter, mettez clairement en évidence dans votre code ces ajouts (en distiguant leur déclaration des autres) et commentez-les.
  • La dernière partie de la méthode simulate1Cycle du cache L1 vous est donnée : elle effectue la consommation des réponses qui arrivent sur le port p_in_rsp.
  • Comme les canaux sont fifos et que des requêtes qui transitent entre un cache et une mémoire ne peuvent pas se doubler, le cache L1 n'est pas obligé de bloquer un miss sur une adresse où il y a une écriture en cours. Ainsi, les réponses aux écritures n'ont pas d'effet spécial dans le cache.

3. Écriture des machines d'état et simulation

Une fois les sources du package model à peu près maitrisées, il faut compléter les classes L1WtiController et MemWtiController à partir des machines d'état dessinées dans la partie 1.

Pour lancer une simulation, il faut faire un clic droit sur la classe Simul.java du package simulation, puis Run As > Java Application

Vous pouvez changer la topcell utilisée dans le fichier Simul.java, de même que modifier les fichiers des différentes topcells. En particulier, les processeurs peuvent initialement contenir une liste de requêtes de lecture et d'écriture, qui doit être créée dans la topcell. Si cette liste est vide, il faut ajouter des requêtes interactivement lors de la simulation ; à l'inverse, si cette liste n'est pas vide, les requêtes qui sont ajoutées interactivement lors de la simulation sont placées à la fin de la liste.

Remarques :

  • Lors de la simulation interactive, les requêtes n'apparaissent que lorsqu'elles ont été consommées. Une requête qui se trouve dans un canal n'est donc pas encore affichée.
  • Par défaut, le segment addressable est le segment <0x00000000-0x10000000>. Les accès aux adresses en dehors de cette plage provoqueront donc une erreur.
  • Il est fortement conseillé d'activer les vérifications d'assert lors des simulations. Pour ce faire, il faut faire un clic droit sur la classe Simul.java du package simulation, puis Run as... -> Run Configurations.... Dans la fenêtre qui s'ouvre, il faut aller dans l'onglet Arguments et écrire dans la fenêtre VM arguments : -ea (enable asserts)

Il faudra bien sûr tester votre code au travers d'entrelacements de requêtes bien choisis. Vous pouvez soit créer ces requêtes dans la classe de la Topcell, soit dynamiquement depuis l'interface en cours de simulation.

Si votre protocole est fonctionnel (et seulement dans ce cas), vous pouvez ajouter une instruction SYNC qui bloque le processeur tant que toutes les requêtes d'écriture en cours ne sont pas terminées. Vous aurez besoin pour cela d'ajouter un registre dans le contrôleur de cache.

4. Rendu

Vous devrez rendre un compte-rendu sommaire (papier ou électronique) comprenant le schéma, ainsi que les tests que vous avez effectués et leur justification (ce que vous avez voulu tester pour chaque test). De plus, si votre code n'est pas fonctionnel au moment du rendu, il faudra expliquer les fonctionnalités manquantes ou les tests qui ne marchent pas.

Le code à rendre l'est sous la forme d'une archive comprenant uniquement les 2 fichiers écrits et le rapport, à envoyer par email à votre encadrant (note : n'envoyez pas toute l'archive de votre projet).

Remarque sur la fraude : toute fraude (entre deux groupes cette année ou vis-à-vis d'un code d'une année précédente) sera sanctionnée par la note de 0.

Attachments (1)

Download all attachments as: .zip