Comparaison des approches NS-2 et SystemC

Approche NS-2 Approche SystemC

Temps de développement V X

Rapidité de simulation X V

Interface utilisateur V X

Précision du modèle X V

Exploration d’architecture V X

Intégration dans un flot de conception X V

3.6

Conclusion

Dans ce chapitre, nous venons de présenter les résultats de nos travaux sur la modé- lisation des réseaux sur puce dans le cadre de l’architecture FAUST. Notre but était de générer un trafic de données correspondant à une chaîne de modulation et démodulation de type MC-CDMA et de simuler ce trafic sur une architecture NoC en respectant le protocole de communication. Deux environnements de modélisation ont été utilisés, l’un fonctionnant avec l’outil NS-2, le second étant basé sur un modèle SystemC au niveau TLM.

Conclusion 105 Les deux environnements nous donnent des résultats comparables et permettent de valider les performances du réseau en ce qui concerne sa capacité à supporter le trafic spécifique à l’implémentation d’un système de télécommunication.

Cette étude nous permet de conclure que l’outil NS-2 est utile pour une exploration rapide du réseau : topologie, placement des ressources, paramètres des communication. Une fois cette étape validée, le modèle SystemC apporte plus de précision au niveau des mécanismes de communication. Nous verrons ainsi au Chapitre 4 comment le mo- dèle SystemC a été exploité pour modéliser une nouvelle architecture de contrôle et de configuration pour les ressources de traitement distribuées sur le réseau.

Chapitre 4

Conception d’un système de

contrôle et de configuration pour un

réseau sur puce

Une architecture de réseau sur puce crée une structure de communication perfor- mante pour échanger une grande quantité d’information entre différentes ressources de traitement. Cependant un réseau sur puce est, par construction, un système distribué. Il n’y a pas de connexions directes entre les ressources. Ceci apporte une grande flexi- bilité au niveau de l’organisation des communications et permet d’avoir des systèmes reconfigurables. Pourtant lorsque l’on cherche à implémenter une application sur un tel système, il faut faire face à de nouvelles problématiques : comment faire fonction- ner et contrôler une application distribuée sur un réseau ? comment assurer la gestion des communications ? comment piloter des unités reconfigurables ? Nous avons identifié deux problématiques en particulier au chapitre 1 : la gestion des flots de données (cf. paragraphe 1.4.2) et le contrôle global de l’exécution de l’application (cf. paragraphe 1.4.3).

Dans ce chapitre, nous allons tout d’abord exposer comment nous nous positionnons pour aborder ces problématiques. Nous présenterons ensuite notre approche pour le contrôle d’un NoC et nous détaillerons une architecture d’interface réseau. Ensuite, nous nous intéresserons à la modélisation VHDL de cette interface et aux résultats de synthèse auxquels nous avons aboutis. Pour finir, nous évaluerons notre approche dans sa globalité grâce à une modélisation complète du système basée sur un environnement de cosimulation SystemC et VHDL.

4.1

Contrôle d’une application sur un NoC et gestion des

communications associées

Cette section a pour objectif de présenter comment nous abordons les probléma- tiques de gestion des communications et du contrôle des traitements pour des ressources distribuées sur un réseau d’interconnexion sur puce. Tout d’abord nous présentons une architecture de ressource généralisant la structure utilisée dans le circuit FAUST. A partir de cette architecture, nous détaillons des notions liées au déroulement temporel d’une application avant de nous intéresser à certaines contraintes de fonctionnement dans le cadre d’applications précises.

4.1.1 Positionnement du problème

Nous travaillons sur des applications de type flot de données dans lesquelles diffé- rentes unités de traitement s’échangent des données. Une unité de traitement reçoit des données par différents canaux d’entrée. Elle envoie des données par des canaux de sortie. Son fonctionnement est géré par l’intermédiaire de signaux de contrôle. En ayant recours à une structure de réseau sur puce, nous avons fait le choix d’une architecture distribuée. Le réseau de communication est utilisé pour échanger l’ensemble des informations, que ce soit des données à traiter ou des données pour le contrôle des unités.

unité de traitement Système de contrôle Interface réseau Contrôleurs de communication d’entrée Contrôleurs de communication de sortie Port d’entrée Port de sortie Contrôle Donnée

Fig. 4.1 – Architecture générique d’une ressource

Pour communiquer avec le réseau, les unités de traitement sont associées à une in- terface réseau. Cette interface a pour objectif d’abstraire le réseau du point de vue de l’unité de traitement (cf. paragraphe 1.4.2). Dans notre architecture NoC, uneressource

Contrôle d’une application sur un NoC et gestion des communications associées 109 correspond au couple formé par l’unité de traitement et l’interface réseau. La Figure 4.1 présente une architecture générique d’une ressource. Les canaux d’entrée et de sortie de l’unité de traitement sont connectés au réseau par le biais de contrôleurs de communi- cation qui prennent en charge la gestion du protocole. Un système de contrôle gère les signaux de contrôle de l’unité de traitement. Des ports d’entrée et de sortie orientent les différents flux entrants et sortants.

L’interface réseau du circuit FAUST est construite sur ce principe. Nous avons intro- duit aux paragraphes 2.4.2 et 2.4.3 certains points que nous souhaitons faire progresser au niveau de la gestion des flux de données et du contrôle des traitement.

4.1.2 Déroulement temporel d’une application

T â che 1 T â che 1 T â che 1 T â che 2 T â che 2 T â che 3 T â che 3 T â che 2 Ressource 1 Ressource 2 Ressource 3

temps Config. 1 Config. 1 Config. 2 Config. 2 Config. 1 Config. 3 Config. 2 Contrôleur 1 Contrôleur 2 Contrôleur 3

Config. 2 Config. 3 Config. 4 Config. 1 temps Configuration T â che

Fig. 4.2 – Déroulement temporel d’une application

Nous allons définir certaines notions que nous utilisons pour décrire le déroulement temporel d’une application. Le terme application correspond à la fonction globale du circuit. Dans une architecture de NoC, cette fonction est réalisée par différents sous- systèmes de traitement que nous appelons ressources. Ces ressources sont distribuées et communiquent grâce au réseau. Au cours du déroulement de l’application, chaque

ressource va avoir à réaliser différentes tâches de traitement. La Figure 4.2 donne un exemple de ce fonctionnement pour un réseau composé de trois ressources.

Au niveau d’une ressource, une tâche correspond à une série de calculs au niveau de l’unité de traitement et/ou à des transferts de données au niveau de l’interface ré- seau. Ces opérations sont pilotées par différents contrôleurs que nous avons décrit avec l’architecture générique de ressource (Figure 4.1) présentée précédemment. Plus préci- sément, une tâche correspond donc à l’exécution d’un certain nombre deconfigurations pour chaque élément de contrôle de l’interface. Une configuration est constituée de pa- ramètres qui permettent l’exécution d’un calcul (pour l’unité de traitement) ou d’un transfert de données (pour un contrôleur de communication). Dans la suite le terme contrôleurs sera également utilisé pour faire référence à la partie contrôle de l’unité de traitement. La Figure 4.2 détaille pour la Ressource 3 les différentes configurations de ses trois contrôleurs pour la tâche 2.

Le découpage en tâches est assez arbitraire. Il peut être fait de manière à permettre un découpage dans le temps à un moment où tous les contrôleurs d’une ressource ont terminé d’exécuter leurs configurations. Il est maintenant possible de distinguer deux niveaux de séquencement dans le déroulement d’une application :

– Leséquencement global : gestion de l’enchaînement des tâches au niveau de chaque ressource.

– Leséquencement local : gestion de l’enchaînement des configurations pour chaque contrôleur au sein d’une tâche.

4.1.3 Analyse des contraintes de fonctionnement dans le cadre d’ap- plications précises

Pour préparer la nouvelle approche que nous présentons dans la section suivante (4.2), nous avons analysé les modes de fonctionnements des applications liées aux projets MATRICE [MATR06] et 4MORE [4MOR06] étudiées dans le cadre du projet FAUST (cf. chapitre 2). Ces applications nous ont servies de support de réflexion. Elles viennent en complément de ce qui a été présenté sur l’évolution des systèmes de télécommunica- tions sans-fil et sur les techniques de modulation (cf. section 2.1). Le but est de pouvoir anticiper les besoins futurs des architectures de contrôle de tels circuits.

Contrôle d’une application sur un NoC et gestion des communications associées 111 4.1.3.1 Configurations des flux d’entrée et de sortie

Les flux d’entrée et de sortie, gérés par les contrôleurs de communication des inter- faces réseau (nommés ICC et OCC, cf. paragraphe 2.3.3.1) correspondent à une certaine quantité de données à transférer (bloc de données). En fonction de nombreux paramètres comme le choix de la modulation (choix de la constellation1 et du rapport de codage2) ou du nombre de codes d’étalement de spectre utilisés, la taille des blocs de données varient.

Nous avons évalué le nombre de modes de fonctionnement possibles, en terme de taille de données, pour les deux applications de télécommunication étudiées dans le cadre du projet FAUST (cf. section 2.2). Ce nombre de mode est directement lié au nombre de configurations des contrôleurs même si des possibilités de séquencement permettent de réutiliser des configurations. Par exemple, si une ressource doit transférer des blocs de 8 flits ou de 24 flits en fonction de la modulation. La configuration permettant de transférer 8 flits peut être utilisée 3 fois de suite pour transférer 24 flits. On peut ainsi limiter le nombre de configuration à condition de reconfigurer le séquencement.