Pour s’intégrer avec les règles de conception des systèmes synchrones, l’intégration traditionnelle du NoC repose généralement sur une horloge système globale avec des déphasages négligeables (skew). Cette hypothèse de conception n’est pas compatible avec les futurs SoCs dans lesquels il faudra plusieurs cycles d’horloge pour transporter un signal au travers de la puce [7]. Dans le cas idéal, un délai de 100 pico secondes est nécessaire pour traverser en diagonale une puce de 22mm de coté avec une technologie à 50nm. En pratique, avec une horloge à 10GHz, il est estimé qu’il faut entre 6 et 10 cycles d’horloge pour traverser le circuit. Ceci pause un problème de synchronisation. De plus, la conception d’un arbre d’horloge distribuant celle-ci de façon uniforme sur l’ensemble du circuit deviendra très difficile [5]. On ne pourra donc plus assurer une synchronisation totale de l’horloge sur l’ensemble de la puce.
Un autre défaut de l’intégration des NoCs traditionnels, est celui de l’utilisation d’un domaine d’horloge unique, alors que les larges SoCs tendent à se répartir en plu-sieurs domaines d’horloge, notamment pour des raisons de consommation. Enfin, des circuit multi-cœurs (multi-core) ou bien système multi-puce, impliquent intrinsèque-ment des horloges distinctes.
Tous ces cas compliquent la conception et impliquent des challenges au concepteur de NoC qui devra réaliser des circuits de grande taille où les besoins sont grandissants
90 noc avec trafic garanti dans une approche de type gals en terme de flexibilité, de capacité à s’étendre, de QoS et de gestion des communica-tions.
6.2.2 Synchroniser un système
Il existe plusieurs méthodes pour synchroniser un système :
– L’approche traditionnelle est celle du système synchrone, qui consiste à utiliser une horloge globale sur tout le système avec un décalage de phase pouvant être négligé.
– La seconde approche est la réalisation d’un système totalement asynchrone. Les communications se font alors par un protocole de poignée de mains, ou bien par des mécanismes spéciaux au niveau logique (2 ou 4 phases). L’asynchrone a pour avantage de réduire la consommation dynamique.
– La troisième méthode consiste à utiliser des blocs synchrones qui communiquent entre eux de façon asynchrone. Ce concept est appelé GALS (Globally
asynchro-nous, locally synchronous). Il a pour avantage de permettre d’intégrer ensemble
des domaines d’horloges différents.
– Une autre approche consiste en la distribution d’horloges mesochrones [83]. Une horloge commune est distribuée sur tout le système. Les différentes parties du système ont une horloge de même fréquence, mais des phases différentes. Ainsi, chaque partie peut fonctionner comme un systèmes synchrone. Les communica-tions entre ces parties nécessitent une adaptation pour s’accommoder du déca-lage de phase.
– Enfin, il existe les systèmes plesiochrones (1). Les systèmes sont presque parfai-tement synchronisés, mais diffèrent légèrement en fonction de leurs horloges qui sont locales. La différence est maintenue dans une limite spécifiée.
6.2.3 État de l’art de la gestion de la QoS et des horloges dans les NoCs
Les NoC peuvent être classés par catégories en fonction de leur utilisation de l’horloge et de la qualité de service qu’ils assurent à leurs communications.
L’approche traditionnelle considère un NoC synchrone avec un domaine d’horloge unique. Elle a pour avantage de permettre d’obtenir un système parfaitement dé-terministe. Ainsi, elle permet l’utilisation d’un TDMA au travers du circuit pipeliné pour assurer un fonctionnement qui a été pré-ordonnancé pour satisfaire la QoS [22] [21]. Cela signifie que tous les éléments routeurs et NIs ont une horloge commune. De plus, le délai d’acheminement sur un lien du réseau doit se faire en moins d’un cycle d’horloge afin que le pipeline des routeurs traversés soit respecté. Notons qu’il y a généralement tout de même une frontière de synchronisation entre les NIs et IPs, réalisée à l’aide de FIFOs double horloge.
Une autre approche consiste à utiliser des communications asynchrones entre des composants synchrones (GALS). Dans [84], les auteurs proposent un crossbar asyn-chrone, seulement la contrainte de temps réel n’est pas considérée.
L’approche de type GALS est utilisée par la solution industrielle fournie par Arteris [13]. Des IPs sont regroupés en clusters. Les échanges dans les clusters sont synchrones
6.2 la synchronisation et la qos 91 et garantis. Un réseau d’interconnexion asynchrone permet de transporter des paquets entre des groupes ou ensembles (clusters) d’IPs synchrones. Les échanges inter-clusters réalisés par des échanges asynchrones n’offrent eux pas de garantie « stricte ».
La conception d’un système sans aucune horloge est la version ultime de l’asyn-chrone, c’est la solution intégrée par [85] et [86]. Dans le premier cas, des canaux virtuels et des routeurs avec de faibles latences sont utilisés, cependant l’architecture du NoC n’offre pas de garantie de bande passante. Dans le second cas, un ordonnan-cement appelé ALG (Asynchronous Latency Guarantee) est utilisé. La garantie est obtenue sous certaines conditions. Il faut en effet que le délai maximum de trans-mission d’un flit soit connu et que l’intervalle inter-flits soit borné. Cette approche est intéressante, cependant, l’intégration d’un grand nombre de trafics à garantir, se traduit par l’ajout de nombreux canaux virtuels ce qui implique une augmentation importante du coût en surface au niveau des routeurs.
Les avantages principaux des solutions sans horloge sont l’insensibilité à la latence et la réduction de la consommation car il n’y a pas de transition quand le système est inactif. Cependant, ces solutions requièrent une implantation spécifique utilisant généralement un protocole double rail à quatre phases, où chaque bit est codé sur quatre fils. C’est le cas des solutions [85] et [86], où les exemples d’implantations ne sont donnés que pour un seul routeur. La consommation dynamique est réduite avec un NoC asynchrone, mais la surface nécessaire pour son implantation peut augmenter sa consommation statique.
6.2.4 Contexte dans lequel nous nous plaçons
Du point de vue de la qualité de service : La technique par TDMA est une technique efficace et simple pour assurer la qualité de service, mais nécessite une notion de synchronisation pour que le comportement pré-ordonnancé soit respecté.
Du point de vue des horloges : La réutilisation de ce qui a déjà été conçu im-pose d’être compatible avec les architecture synchrones et les outils de conceptions construits autour des protocoles de communication standards. De plus, les larges SoCs tendent à se répartir en plusieurs domaines d’horloges. Le concept de GALS semble donc être la solution la plus adaptée.
Enfin, il est possible d’avoir des parties du circuit qui ont une horloge de même fréquence mais pas de même phase. On doit aussi faire face a des liens qui ont un temps de traversée supérieur à un cycle d’horloge. Il est donc aussi nécessaire de traiter l’aspect des parties mésochrones.
Nous cherchons donc à la fois à conserver la QoS par l’utilisation de TDMAs tout en se mettant dans le contexte de domaines d’horloges différents et de sous parties mésochrones.
6.2.5 Résumé de l’approche développée
Notre objectif a été de conserver la QoS à l’aide du TDMA, mais dans un contexte de GALS qui répond mieux aux futures contraintes d’implantation de la distribution de l’horloge dans les SoCs. La figure 6.1 illustre notre approche.
Cette solution consiste en le découpage du réseau global du circuit en zones de même horloge appelées sous-réseaux ou sub-NoCs. Chacun des sub-NoCs fonctionne de
92 noc avec trafic garanti dans une approche de type gals manière synchrone (ou vu comme synchrone), ainsi son comportement est prédictible et permet d’utiliser un TDMA pour l’ordonnancer et garantir le trafic qui le parcoure. De plus, un sub-NoC peut être lui même divisé en sous parties mésochrones.
Fig. 6.1 – NoC GALS avec QoS Il y a donc deux difficultés à surmonter :
– `A l’intérieur d’un sub-NoC, il faut pouvoir masquer le problème de liens qui ont un délai de traversée trop long pour permettre le pipeline de la communica-tion au travers du sub-NoC. De plus, il faut pouvoir s’accommoder des parties mésochones. Pour cela, on introduit le concept de routage temporel (TR pour
time-routing) qui réalisera l’interface.
– De plus, il faut pouvoir garantir le trafic au niveau global, c’est à dire sur tout le circuit. Nous proposons des interfaces de synchronisation qui vont permettre de faire tampon entre les différents sub-NoCs qui sont ordonnancés individuellement avec leur propre table TDMA.
`
A l’aide de nos deux types d’interfaces, la QoS du trafic est assurée sur toute la puce malgré l’hétérogénéité des horloges.