Complexité liée au réseau sur puce

Dans une architecture de réseau sur puce telle que FAUST, chaque ressource de traitement a un comportement qui lui est propre. Celui-ci peut paraître localement simple à appréhender. Cependant la complexité globale augmente rapidement avec le nombre de ressources du fait des interactions qui existent entre elles. L’analyse statique reste limitée. De plus, un certain nombre de paramètres dont dépendent les performances restent difficile à déterminer :

- De paramètres du réseau

Ce sont des paramètres qui interviennent au niveau de l’organisation structurelle (topologie) du réseau. Il s’agit de déterminer le nombre de noeuds et de liens ainsi que la position des différentes ressources. Le nombre de noeuds et de liens permet d’aug- menter la bande-passante. On peut par exemple doubler les liens pour supporter un débit plus important. La contrepartie est le coût matériel. Pour une topologie de réseau donnée, la position des ressources de traitement va aussi avoir une influence sur les

La modélisation des NoC 77 performances. Pour réduire la latence, on peut rapprocher les ressources qui commu- niquent fréquemment entre elles. Il faut aussi éviter de former des zones de congestion. Pour cela, une bonne répartition du trafic sur l’ensemble des liens de communication est souhaitable.

- De paramètres des ressources

Chaque unité de traitement communique grâce à une interface réseau (cf. paragraphe 1.2.2.3). Avec l’architecture FAUST, ces interfaces intègrent des mémoires FIFO qui rendent l’unité de traitement indépendante des mécanismes de transferts (cf. paragraphe 2.3.3). Tout se passe comme si la communication se faisait par une connexion directe entre les unités au travers d’une mémoire partagée. La façon d’organiser les transferts est directement liée au nombre de mémoire. Plusieurs mémoires permettent des transferts en parallèle, au contraire une unique mémoire en entrée ou en sortie de l’unité impose de séquencer les communications. Il faut également déterminer la taille de ces mémoires. Plus la taille est grande, plus les transferts sont fluides. Cet espace de stockage permet aussi d’anticiper les transferts ce qui a pour effet de masquer les latences. Cependant, que ce soit au niveau du nombre ou de leur taille, ces mémoires ont un coût matériel, il est donc impératif d’optimiser ces paramètres, pour chaque ressource, en fonction des contraintes du système que l’on va réaliser.

- De paramètres de communication

Le protocole de communication de FAUST offre des degrés de liberté pour la confi- guration des communications. Cela concerne en particulier la taille des paquets. Dans le cas d’une commutation de paquet de type wormhole, les paquets avec peu de flits sont préférables car ils occupent les noeuds sur une période plus courte ce qui réduit la congestion. Cependant, chaque paquet possède un flit d’en-tête. Multiplier le nombre de paquet en utilisant une granularité plus fine augmente donc le trafic sur le réseau. Le seuil d’envoi des crédit est un second paramètre qui intervient sur les performances des transferts (cf. paragraphe 2.3.3.2). Les crédits doivent être envoyés régulièrement pour fluidifier les transferts sans pour autant générer un trafic trop important. Enfin, il est également possible d’agir sur les chemins de routage ou le choix du canal virtuel utilisé. En tenant compte des contraintes des applications visées, il faut donc se donner des outils pour ajuster ces paramètres.

3.1.3 Nécessité d’un environnement de modélisation et synthèse des travaux antérieurs

Une analyse statique des flots de données permet d’évaluer l’état moyen du système mais entraîne un lissage des comportements dynamiques. Dans la section précédente, nous avons identifié des paramètres sur lesquels il est nécessaire de travailler pour que les unités de traitement exploitent au mieux le réseau de communication. Dans ce but, le recours à un environnement de modélisation apparaît comme nécessaire.

Dans la suite, nous allons présenter un aperçu de travaux antérieurs sur la mo- délisation des NoC. Il est possible de distinguer deux niveaux de modélisation dont les objectifs sont complémentaires. Le premier niveau consiste a modéliser la structure d’interconnexion. Le second prend en charge le trafic réseau.

3.1.3.1 Modélisation de la structure de communication

Il s’agit de modéliser le fonctionnement du réseau de communication indépendam- ment des unités de traitement qui vont exploiter ce réseau. Plusieurs approches sont possibles :

- Utiliser un environnement de modélisation haut-niveau

L’objectif est de développer rapidement un modèle fonctionnel sans avoir le niveau de détail nécessaire à une implémentation physique. Ces environnements fournissent un ensemble de primitives permettant de construire un système et de le simuler. On peut citer des travaux réaliser avec PtolemyII [PTOL06] comme [SSMK01],[ZhMa02] ou avec SDL [SpDL06] (Specification and Description Language) pour [HoHK03] et [AnKu04]. Globalement, ces environnements sont moins utilisés car ils sont peu connus dans le milieu de la conception.

- Utiliser un outil de modélisation de réseau

Une solution pour simuler une architecture de réseau sur puce est de reprendre des outils standards développés pour la modélisation de réseaux non-intégrés. Plusieurs si- mulateurs de réseaux existent et il est intéressant d’étudier comment ils peuvent être adaptés aux problématiques des NoC. Cette démarche a été mené avec l’outil OPNET [OPNE06] par [XWHC04] et [BCGK04]. OPNET fournit un environnement de simu- lation rapide, basé sur de la communication par paquet. Un autre simulateur utilisé pour la recherche sur les réseaux est NS-2 [NS206]. Nous présentons en détails cet outil en Annexe C. La première utilisation de NS-2 dans le cadre des NoC est publiée dans

La modélisation des NoC 79 [SuKJ02]. Par la suite, d’autres travaux ont été présentés [HEMK05] et [NgCh05]. Que ce soit avec OPNET ou NS-2, ces approches permettent une exploration rapide de dif- férentes topologies de réseau. Les modèles sont ajustés pour donner de bons ordres de grandeurs au niveau des latences et des débits.

- Développer un modèle spécifique

L’approche la plus souvent choisie pour simuler le fonctionnement d’un réseau sur puce est de développer un modèle spécifique de l’architecture que l’on vise à partir de langages de description ou de programmation standards dans le but d’avoir un modèle précis au niveau cycle ou même bit. Dans cet optique, il existe des propositions de mo- dèles VHDL haut-niveau comme [STNu02] et [BaVC04] qui ont l’avantage de pouvoir être aisément raffinés pour devenir synthétisables. Pour avoir une vitesse de simulation plus importante, certains NoC sont modélisés en langage C++ comme pour [WiSL04] et [HuMa04]. De plus en plus de travaux présentent des solutions basées sur le langage SystemC (cf. Annexe B). Des méthodologies complètes sont mises en place spécifique- ment pour l’étude des NoC comme [KDWG03] ou [PRRG04] pour le réseau Æthereal (cf. paragraphe 1.3.2) ou [CCGM04] avec OCCN (On-Chip Communication Network ).

3.1.3.2 Modélisation du trafic réseau

Données

(a) Traffic aléatoire

Contrôle Données

(b) Traffic local et contrôle Fig. 3.1 – Modélisation du trafic de donnée sur un NoC

Nous avons vu dans le paragraphe précédent différentes méthodes pour modéliser un réseau en tant que structure de communication. Il s’agit maintenant de simuler des échanges de données. Dans ce but, deux approches sont possibles :

- Évaluer les performances du NoC

Dans ce type d’étude, on cherche à caractériser le réseau. Les résultats sont pré- sentés de manière statistique. Il s’agit par exemple de la latence moyenne en fonction de la charge du réseau. Pour obtenir de ce type de résultat, les modèles font appel à des générateurs de trafics aléatoires. Différentes distributions statistiques sont possibles pour modifier la répartition temporelle des paquets, leurs tailles, leurs destinations. Le modèle le plus simple consiste en une equirépartition des paquets (Figure 3.1(a)), ce qui correspond à un réseau où les ressources ont toutes des fonctions équivalentes. Dans [SuKJ02], la répartition est biaisée de manière à ce que 75% du trafic reste local (proche voisin du point de vue de la topologie). Dans [WiSL04], on distingue un traffic de donnée fréquent et local, correspondant aux communications entre ressources dans un circuit de traitement, auquel on associe un trafic orienté vers certaines ressources spécifiques qui jouent le rôle de systèmes de contrôle (Figure 3.1(b)).

- Étudier le NoC dans un cadre applicatif

Les méthodes de génération de trafic aléatoire permettent de caractériser une archi- tecture de réseau mais ne valident pas une application. En fait, il existe encore assez peu d’architectures NoC qui ont été présentées dans un cadre applicatif précis (cf. pa- ragraphe 1.4.3). La solution [XWHC04] pour un système de traitement vidéo consiste à générer des traces de communication pour chacune des ressources en les faisant fonction- ner dans un réseau idéal . Ensuite ces traces sont réinjectées pour chacune des ressources lors de la simulation globale du réseau. Le réseau SoCBUS [WiLi05] a été simulé dans le cadre d’une application de télécommunication (station de base pour un système 3G). Les unités de traitement sont modélisées fidèlement au niveau des communications sans pour autant réaliser l’intégralité des calculs.

3.1.4 Proposition d’une nouvelle approche pour la modélisation des