Caractéristiques communes des réseaux sur puces

Importance des réseaux sur puce dans le développement des SOC 

Plusieurs systèmes sur puce utilisent aujourd’hui le réseau comme support de communication entre les différents composants qu’ils gèrent, ceci n’impose pas que tous les SOC utilisent les NOC, mais la tendance actuelle est son utilisation systématique pour les applications futures. En effet une étude faite par Sonics en 2013 [84] montre que 47% des organismes concernés par la conception de SOC ont déjà utilisé des NOC ou ont l’intention d’évaluer des NOC commercialisés.

Cependant, on trouve plusieurs réseaux développés mais seuls quelques uns ont été commercialisés. Ceci est dû à la complexité du processus de conception et le coût qu’il présente. Par la suite, on montrera quelques exemples des réseaux commercialisés ou faisant partie des systèmes commercialisés.

♦ Epiphany IV : c’est un coprocesseur (comprenant 64 cœurs) développé par Adapteva implémenté autour d’un réseau Mesh à deux dimensions, on s’attend à ce que la future version contienne plus de 4096 cœurs [7]. Des solutions comme la maquette Parallella et la maquette ZED Board intègrent le composant Epiphany IV [8]
♦ Net speed orion : c’est un réseau dont l’architecture est définie par l’outil NOCSTUDIO, cet outil permet de déterminer la topologie, la structure du routeur et l’algorithme de routage permettant d’atteindre les performances les plus optimisés selon les exigences des applications à intégrer [9]
♦ NoC d’Arteris: est le premier réseau commercial. La plupart des paramètres de conception de NoC d’Arteris sont définis par l’utilisateur à savoir la topologie du réseau, l’algorithme de routage et le nombre de ports d’entrée et de sortie sur les commutateurs. Le contrôle de flux du réseau peut être optimisé pour les besoins des applications en combinant des différentes méthodes de contrôle. [10]
♦ STNoC est un réseau commercial fait par STMicroelectronics. C’est une application simple de mise en œuvre qui utilise le principe du wormhole pour l’acheminement des données avec un routage déterministe à la source et qui dispose d’une topologie Spidergon. [11]
♦ Processeur IBM Cell : L’architecture de processeur IBM cell adopte un algorithme de routage déterministe en raison de la simplicité de sa topologie ayant un petit nombre de nœuds. Il s’agit d’un ensemble de huit processeurs qui sont reliés dans une topologie en anneau avec une largeur de 4 connections (voir figure II.2), une fonction d’arbitrage est adoptée afin d’empêcher le parcours de plus que la moitié du diamètre du réseau (un parcours maximal est limité par un chemin à 4 sauts (hops)) [23].

♦ SonicsGNest un réseau de Sonics appelé aussi (SGN), est un réseau configurable avec une topologie flexible, ce réseau est compatible avec les interfaces OCP et AMBA , la configuration du réseau est faite à partir de l’outil de développement SonicsStudio®  Director qui permet au concepteur, à l’aide d’une méthodologie bien précise, de créer, optimiser, et vérifier le fonctionnement du réseau. [13]
♦ Intel TeraFLOPS : un prototype de processeur de recherche doté de 80 noyaux et qui dispose d’une stratégie de routage souple: en effet les algorithmes de routage déterministe et adaptatif sont pris en charge par ce système. Chaque nœud est présenté par un routeur à 5 ports [8], ces derniers sont interconnectés par un réseau maillé 2D de taille 8×10 [24].
♦ Tilera TILE64 Comme son nom l’indique, ce système utilise 64 unités de traitement (PE) qui sont reliés par une structure maillée à 2 dimensions, chaque nœud de réseau possède ses propres mémoires caches L1 et L2. Le routage est déterministe et le mécanisme de commutation adopté est la commutation de circuit [25].

Même si on pense que le réseau sur puce est une solution plus optimisée que celle du bus[12] et qu’elle est aussi acceptée par l’industrie, elle est toutefois encore en cours de développement et fait face à certains défis de conception, ces défis sont liés à la diversité des paramètres caractéristiques du réseau (ces paramètres doivent être justifiés par le concepteur), à savoir la topologie du réseau, le type de commutation choisi, l’algorithme de routage à appliquer, le protocole de communication (contrôle de flux), la structure du routeur, ainsi que la réponse de l’ensemble du réseau paramétré vis-à-vis des performances requises par les applications implémentées dans le SOC.

Caractéristiques communes 

Topologie 

La topologie du réseau est celle qui définit la manière suivant laquelle les différents cœurs d’IP sont connectés, en effet ces cœurs d’IP sont connectés au réseau par l’intermédiaire des nœuds des connections appelés routeurs. La topologie du réseau définit certains critères physiques à savoir
➤ Le nombre moyen d’interconnections entre les différents routeurs (ou ce qu’on appelle degré du routeur),
➤ Le diamètre du réseau qui est la distance maximale en nombre de sauts (liens parcourus) entre deux routeurs dans le réseau. Le diamètre fournit alors une indication sur la latence maximale quand il n’y a pas de conFLIT de ressources.
➤ La bande passante de bissection est le nombre minimal de liens qu’il faut neutraliser afin de diviser le réseau en deux sous-réseaux équivalents. Cette Métrique permet d’évaluer la bande passante maximale dans le cas d’un trafic uniformément distribué et la diversité des chemins de routage.

Ces critères physiques ont un impact sur les performances globales du réseau, en termes de latence moyenne et de bande passante du réseau.

Protocole de communication (contrôle de flux) 

Le protocole de communication définit l’ensemble des règles qui contrôlent la communication entre les différents entités au sein de réseau, il permet de valider et de synchroniser la circulation de données entre ces derniers, dans l’état de l’art on trouve quelques protocoles de communication dont les plus utilisés dans les NOC sont la poignée de main (handshaking) et le crédit d’émission (credit-based ) :

➤ Contrôle de flux par handshaking : pour ce type de communication l’envoi des données à partir de l’émetteur n’a lieu qu’après la réception d’un acquittement indiquant la liberté du récepteur, cet acquittement définit la réponse du récepteur à une requête présentée de la part de l’émetteur au début de chaque transmission des données. Dans le cas de la non disponibilité du récepteur (réception d’un acquittement de la non disponibilité ou absence d’acquittement), l’émetteur reste en attente pour un certain délai ou annule la transmission ; selon l’algorithme de routage adopté par ce dernier. Pour ce type de communication, l’émetteur et le récepteur doivent être synchronisés par le même signal d’horloge.
➤ Contrôle de flux par credit-based : différent du protocole handshaking l’envoi des données à partir de l’émetteur a lieu instantanément sans devoir attendre un acquittement de la part du récepteur. La disponibilité de ce dernier est détectée par un signal dit (credit), aussi la communication dans ce cas de protocole est asynchrone, en effet l’émission de données est synchronisée avec l’horloge de récepteur alors que l’écriture dans la mémoire tampon du routeur récepteur est synchronisée avec l’horloge de l’émetteur.

Le protocole de communication (credit-based) montre deux avantages par rapport à celui de handshaking ; le premier avantage c’est de pouvoir transmettre les données au bout d’un seul cycle, en effet pour le protocole handshaking on doit un cycle supplémentaire pour la réception d’acquittement, le deuxième avantage c’est l’aspect asynchrone de la communication ce qui facilite la mise en place d’un mode globalement asynchrone localement synchrone (GALS) au niveau du fonctionnement du réseau, le seul inconvénient présenté par le protocole credit-based est la difficulté de l’implémentation au niveau du routeur ceci est expliqué par le nombre supplémentaire des signaux mis en jeu.

Table des matières

Introduction
Chapitre 1
I. Introduction générale
I.1. Objectifs de la thèse
I.2. Contributions
I.3. Organisation du manuscrit
Chapitre 2
II. État de l’art sur les réseaux sur puce
II.1. Introduction
II.2. Caractéristiques communes des réseaux sur puces
II.2.1. Importance des réseaux sur puce dans le développement des SOC
II.2. Caractéristiques communes
II.2.1. Topologie
II.2.2. Protocole de communication (contrôle de flux)
II.2.3. Mécanismes de commutation
II.2.4 Algorithmes de routage
II.2.4.1 Classification des algorithmes de routage
II.2.4.2 Problèmes de routage
II.2.4.2.1 Situation de deadlock
II.2.4.2.2 Situation de livelock
II.2.4.2.3 Situation de starvation
II.2.5 Composition du routeur
II.2.5.1 Ports d’entrées sorties
II.2.5 .2 Tampons
II.2.5.3 Unité de contrôle
II.2.5.4. Crossbar
II.3. Service multicast
II.3.1 Importance du service multicast dans les systèmes à multiprocesseurs
II.3.2. Différents algorithmes utilisés pour l’implémentation du service multicast
II.3.2.1. Algorithmes de routage basés sur le chemin (path-based)
II.3.2.1.1. Routage multicast à deux chemins “ Dual-Path Multicast Routing (DP)”
II.3.2.1.2
II.3.2.1.3
II.3.2.2 L’algorithme de routage basé arbre (Virtual Circuit Tree Multicasting VCTM)
II.3.2.3 RPM
II.4.Réseau à 3 dimensions
II.4.1 Avantages du réseau à 3 dimensions par rapport aux réseaux à 2 dimensions
II.4.2.Limitations des réseaux sur puce à 3 dimensions
II.4.2.1Through-Silicon-Vias (TSVs)
II.4.2.1.1. Surface des TSV
II.4.2.1.2. Nombre des TSV
II.4.3 Réseau sur puce partiellement connecté verticalement « Vertically-PartiallyConnected 3D-NoC »
II.5. Conclusion
Chapitre 3
III. Réseau sur puce basé sur le principe des routeurs virtuels
III.1. Introduction
III.2. Architecture d’un routeur élémentaire et principe de fonctionnement
III.2.1 Composition et structure
III.2.2 Principe de fonctionnement de l’unité de routage
III.2.3 Type de commutation des paquets
III.2.4 Entête de paquet est routage instantané
III.2.5 Priorité des ports d’entrée et l’élimination du livelock
III.3. Architecture de réseau avec des routeurs virtuels
III.3.1 Réduction du nombre de TSV
III.3.2. Architecture de réseau avec des routeurs virtuels
III.3.3. Comparaison entre nos architectures avec celles à 2 dimensions
III.3.3.1. Nombre de liens d’interconnections
III.3.3.2. Complexité algorithmique
III.3.3.3. Latence
III.3.3.4. Principe du multiplexage temporel
III.3.5. Structure du port local pour un routeur Rg
III.3.6. Structure de l’interface réseau
III.3.7. Réduction de latence par rapport à un réseau 3D classique
III.4. Conclusion
Chapitre 4
IV. Implémentation du service multicast
IV.1. Introduction
IV.2. Limitations des solutions antérieures
IV.3. Principe de l’architecture proposée
IV.3.1. Sous réseau
IV.3.2. Structure du réseau
IV.3.3. Paramétrage du routeur suivant son SR
IV.3.3.1. Position du routeur selon les coordonnées XY
IV.3.3.2. Position du routeur par rapport à son SR (ID SR)
IV.3.3.3. Type de sous réseau
IV.4. Algorithmes de routage
IV.4.1. Routage d’un paquet ordinaire
IV.4.2. Routage d’un paquet de type multicast
IV.4.2.1. L’algorithme de routage « dernier routeur adressé »
IV.4.2.2. Routage d’un paquet de type multicast d’un routeur autre que LRM vers les routeurs voisins
IV.4.2.3. Routage d’un paquet de type multicast entre les différents LRM
IV.4.2.4. Routage d’un paquet de type multicast entre un LRM et les routeurs appartenant à un même SR
Conclusion

Télécharger le rapport complet