Implémentation du protocole de cohérence de cache AMBA ACE sur une architecture générique et extensible

Implémentation du protocole de cohérence de cache AMBA ACE sur une architecture générique et extensible

Dans ce chapitre, nous présentons l’architecture générique et extensible proposée et détaillons la micro-architecture de l’interconnexion CCN-xx. Nous décrivons ensuite la modélisation de chaque objet la composant et l’implémentation du protocole AMBA ACE sur cette architecture. En dernier point, nous expliquons le processus d’exécution de 3 types de requêtes sur notre architecture.

Architecture générique

Il s’agit d’une architecture de systèmes à mémoire partagée. Les principaux composants de cette architecture sont les processeurs, les coprocesseurs, le réseau d’interconnexion et la mémoire partagée.Dans cette étude, l’interconnexion CoreLink CCN-xx regroupe dans un seul et même mo- dule la fonction d’interconnexion des composants et celle de la gestion des accès concur- rents à la mémoire en utilisant le protocole AMBA ACE. Les 2 types d’interfaces spécifiées dans le protocole, à savoir ACE master et ACE-lite master sont implémentées.Afin d’implémenter le protocole AMBA ACE sur une architecture à base d’interconnexion CCN étendue, nous avons modélisé des composants équivalents à chaque composant de l’architecture de base : les processeurs connectés aux L2, les coprocesseurs avec l’interface ACE-Lite master, la mémoire, les caches locaux aux processeurs avec l’interface ACE master et le réseau d’interconnexion CoreLink CCN-xx. La figure 4.1 décrit l’architecture générique modélisée.

Modélisation des processeurs et coprocesseurs

La vérification dynamique exige des transacteurs servant à générer des patterns de testqui doivent suivre le protocole de cohérence. Pour ce faire, nous avons implémenté deux types de composants : proc pour modéliser les processeurs et coproc pour modéliser les coprocesseurs n’ayant pas de cache local (GPU, DSP, etc.). Afin de tester les transactionsACE sur l’architecture générique, une fonction de génération aléatoire de requêtes est implémentée dans chacun de ces composants : le type de la requête et l’adresse mémoire sont générés aléatoirement.A chaque génération, une nouvelle transaction identifiée par un identificateur unique T ID est créée. Elle contient comme principales informations l’identificateur ID du processeur ou coprocesseur l’ayant générée, le type de la requête et l’adresse d’accès à la mémoire. Cette requête d’accès est envoyée au cache local, sous forme de paquet, dans le cas d’un proc et directement envoyée au réseau d’interconnexion dans le cas d’un coproc. Le tran- sacteur terminera la transaction en cours après réception de la réponse et pourra ensuite initier une nouvelle transaction. Si la requête n’a pas été traitée, il recevra une requête de renvoi après un délai d. Si la réponse n’est pas reçue après maxReqT ick secondes, celle-ci sera ignorée.La figure 4.2 illustre les groupes de requêtes pour chaque type de master (processeur ou coprocesseur).

Modélisation des caches

Afin de modéliser un cache local aux composants proc de niveau 2, nous avons im- plémenté le composant L2. Cette structure est composée de lignes de cache stockées sous forme d’une liste de blocs de données. A chaque ligne de cache est associé un état parmi les suivants : Invalid (I), U niqueClean (U C), U niqueDirty (U D), SharedClean (SC) et SharedDirty (SD). Ces états sont décrits dans la section Dans le but d’injecter des requêtes suivant le protocole de cohérence AMBA ACE, une fonction preChecking est implémentée, afin de rejeter les requêtes incompatibles suivant l’état initial de la ligne de cache concernée par la requête (exemple : une requête write-back ne peut pas être générée sur une ligne de cache invalide).

— Requête de lecture : Dans le cas d’un hit (succès), la donnée de la ligne de cache est fournie au processeur (proc) si son état actuel le permet (tous les cas possibles seront détaillés dans la section 4.3.2), sinon, la requête est envoyée au port en entrée du réseau d’interconnexion. Une fois la réponse à cette requête reçue, une copie est stockée localement et une réponse au processeur ayant initié la requête est envoyée ;— Requête d’écriture : Dans le cas d’un hit en état unique et Clean, l’état de la ligne de cache est mis à jour sinon, une copie exclusive de la donnée est demandée. La requête générée dépend de la requête initiale (comme définie dans la spécification ACE que nous détaillerons dans la section 4.3.2). Une fois la réponse reçue, la nouvelle donnée est stockée localement si le protocole de cohérence le permet et la réponse est envoyée au processeur initiateur de la requête ;— Requête de snooping : A la réception d’une requête du CCN-xx, le cache envoie une réponse suivant le protocole ACE. Pour une requête de lecture par exemple, la donnée est envoyée et l’état de la ligne de cache est mis à jour. Nous n’étudions pas le cas d’un miss. Le composant snoopF ilter permet de snooper seulement les caches détenant la ligne de cache.