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

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 module la fonction d’interconnexion des composants et celle de la gestion des accès concurrents à 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 test qui 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 transactions 38 Implémentation du protocole de cohérence de cache AMBA ACE sur une architecture générique et extensible Figure 4.1 – L’architecture générique proposée. ACE 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 transacteur 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). Ces composants sont reliés aux caches locaux dans le cas de proc et au réseau d’interconnexion dans le cas de coproc, comme illustrée dans la figure 4.1. Fonctions de proc et coproc Les procédures d’envoi d’une requête, de réception d’un retry (pour un renvoi de requête), de renvoi d’une requête, de réception d’une réponse et de fin d’une transaction sont résumées algorithmiquement dans les algorithmes 4.1, 4.2 et 4.3 . 

Modélisation des caches

Afin de modéliser un cache local aux composants proc de niveau 2, nous avons implé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), UniqueClean (UC), UniqueDirty (UD), SharedClean (SC) et SharedDirty (SD). Ces états sont décrits dans la section 3.3. 39 Figure 4.2 – Les groupes de transactions selon le protocole AMBA ACE . Algorithme 4.1 tick() Générer aléatoirement un type de requête et une adresse. if requête d’écriture then Générer aléatoirement une donnée. end if Composer un paquet pkt contenant les informations sur la requête. Envoyer pkt sur le port en sortie. Algorithme 4.2 recvRetry(pkt) Renvoyer pkt sur le port en sortie après un délai d. Algorithme 4.3 recvResp(pkt) if requête de lecture then Lire la donnée reçue. end if Supprimer le paquet. Générer une nouvelle requête. 40 A la réception d’une requête, le cache réagit suivant l’état initial de la ligne de cache correspondant à l’adresse d’accès. Des fonctions d’allocation et de dés-allocation des lignes du cache sont implémentées. 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). Une fonction d’accès est implémentée pour vérifier la validité de la ligne de cache. Les 3 scénarii possibles sont : — 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. Le remplacement des lignes de cache lors de l’allocation de nouveaux blocs suit un algorithme LRU (Least Recently Used) [Puzak, 1985b]. Fonctions de L2 Les algorithmes 4.4, 4.5, 4.6 et 4.7 résument les fonctions suivantes : envoi d’une réponse à proc, réception d’une requête de proc, accès à un bloc d’adresse x, réception d’une réponse à une requête envoyée au CCN-xx, allocation d’un bloc et envoi d’une requête au CCN-xx. Le déroulement de ces fonctions est détaillé dans la section 4.3.1. 

Modélisation de la mémoire partagée

Le composant mem modélise la mémoire principale partagée dont la taille est paramétrisable. Le tampon du port en entrée de la mémoire contient les requêtes envoyées pour traitement par le CCN-xx. Si la requête nécessite une réponse, elle sera envoyée sur le port de sortie. 41 Algorithme 4.4 L2 : recvReq(pkt) accéder au bloc d’adresse x. if Bloc est invalide then envoyer la requête correspondante au CCN-xx sur le port en sortie. else if requête de snooping en cours sur l’adresse x then envoyer un retry à proc. else switch type de la requête do case ReadShared répondre en envoyant la donnée à proc et mettre à jour l’état de ligne de cache. case ReadUnique if l’état initial de la ligne de cache est UC ou UD then répondre en envoyant la donnée à proc et mettre à jour l’état de ligne de cache. else envoyer une requête au CCN-xx sur le port en sortie. end if case ReadNotSharedDirty if l’état initial de la ligne de cache est UC, UD ou SC then envoyer la donnée à proc et mettre à jour l’état de ligne de cache. else envoyer une requête CleanShared au CCN-xx sur le port en sortie. end if case ReadClean répondre en envoyant la donnée à proc et mettre à jour l’état de ligne de cache. case W riteUnique ou W riteLineUnique if l’état de la ligne de cache est UD then envoyer une requête WriteClean au CCN-xx. else if W riteUnique then envoyer une requête CleanInvalid au CCN-xx. else envoyer une requête M akeInvalid au CCN-xx. end if end if case CleanUnique if l’état de la ligne de cache est SC ou SD then envoyer une requête M akeInvalid au CCN-xx. end if 42 case CleanInvalid if la donnée est Dirty then envoyer la requête CleanInvalid au CCN-xx avec la donnée en lui passant la responsabilité de mise à jour de la mémoire. else envoyer une requête CleanInvalid au CCN-xx. end if case MakeUnique if l’état de la ligne de cache est UC ou UD then effectuer l’écriture localement, mettre à jour l’état de la ligne de cache et envoyer une réponse à proc. else envoyer une requête MakeUnique au CCN-xx. end if end if end if fonctions de mem L’algorithme général de la réception d’une requête et des actions engendrées est décrit dans l’algorithme 4.8. Le déroulement des fonctions de réception d’une requête, d’accès à un emplacement mémoire, d’envoi d’une réponse au CCN est détaillé dans la section 4.3.1.