Anda di halaman 1dari 162

No dordre : D06-16

Thse
prsente devant lINSTITUT NATIONALE DES SCIENCES APPLIQUES DE RENNES pour obtenir le titre de

Docteur
spcialit : lectronique

Spider Environnement de Conception de Rseau sur Puce


par

Samuel Evain

Soutenue le 24 Novembre 2006 devant la commission dExamen Composition du jury Rapporteurs M. Ahmed Amine JERRAYA M. Tanguy RISSET Examinateurs M. Frderic ROBERT M. Philippe MARTIN Codirecteurs M. Dominique HOUZET M. Jean-Philippe DIGUET Directeur de recherche CNRS, TIMA, Grenoble Professeur, LIP, INSA, Lyon

Professeur, BEAMS, Universit Libre de Bruxelles Docteur, ARTERIS, Guyancourt

Professeur, LIS, ENSERG, Grenoble Charg de recherche CNRS, LESTER, Universit de Bretagne Sud, Lorient
Institut dlectronique et de tlcommunications de Rennes Institut nationale des sciences appliques de Rennes

Rsum
Ce travail de thse porte sur la conception de linterconnexion entre les nombreux composants IP (Intellectual Property) dun systme lectronique sur puce (SoC pour System on Chip). Notre tude repose sur une solution mergente qui est celle des rseaux sur puce (NoC pour Network-on-chip), celle-ci est inspire des rseaux de communication entre ordinateurs. Un NoC ore de nombreuses possibilits et un large espace de conception. La matrise des choix des paramtres dun NoC vis vis des contraintes dune application nest pas triviale et ncessite de la mthode. Cette thse propose un ot de conception an de dterminer ces paramtres automatiquement. Le problme de lhorloge dans les circuits de grande taille, ainsi que laspect scurit sont galement traits. Ce travail a conduit au dveloppement de loutil Spider, qui est un environnement de conception compos doutils de dcisions et dun gnrateur de code (VHDL synthtisable). Ce travail a t valid avec des applications dans les domaines du traitement du signal, de limage et des tlcommunications. Mots cls : Systme sur puce, conception de circuit, synthse darchitecture, communication, rseau sur puce, NoC, routeur, interface, outil daide la conception, allocation de chemins, GALS, scurit.

iii

Abstract
This PhD thesis deals with interconnection design between IP cores (Intellectual Property) in a System on Chip. This work is based on an emerging infrastructure solution called Network on Chip. The design space is wide and methodologies are required to help designer to obtain ad hoc NoC matching application requirements. This work presents a design ow to design automatically ad hoc NoC parameters. Clock synchronicity subject in wide chip and security concerns in NoC are also addressed. We have developed a design tool called Spider. This tool is able to make choices and to congure NoC parameters according to applications constraints and needs. Moreover, it generates the VHDL RTL code of the specied NoC. This work has been validated on three real-life applications, a smart camera application, a telecom MC-CDMA application and a multiprocessor turbo-decoder application. Keywords : System-On-Chip, architecture design, high-level synthesis, communication, Network-on-Chip, NoC, router, interface, computer aided design, path decision, security.

Remerciements
Je tiens tout dabord remercier Monsieur Jean-Philippe Diguet, Charg de Recherche CNRS au laboratoire LESTER, pour avoir accept dtre le codirecteur de cette thse. Je tiens lui exprimer ma reconnaissance pour sa disponibilit, ses conseils et sa gentillesse. Je remercie Monsieur Dominique Houzet, Matre de Confrence lIETR durant ma thse et maintenant Professeur au LIS de Grenoble, pour mavoir propos cette thse, dirig et soutenu durant ces quatre annes. Je remercie Monsieur Ahmed Amine Jerraya et Monsieur Tanguy Risset pour mavoir fait lhonneur dtre les rapporteurs de cette thse. Je remercie galement Monsieur Frderic Robert et Monsieur Philippe Martin pour avoir accept dexaminer ces travaux de recherche. Je remercie les Directeurs successifs du laboratoire LESTER pour mavoir accueilli, Monsieur ric Martin, aujourdhui Prsident de lUniversit de Bretagne Sud, et Monsieur Emmanuel Boutillon, Professeur lUniversit de Bretagne Sud et Directeur du LESTER. Merci tous mes collgues des Laboratoires LESTER et IETR avec qui jai eu le plaisir de travailler. Je remercie tout particulirement Samuel Rouxel et Bertrand Le Gal pour leur amiti et leur soutien prcieux. Je tiens galement remercier les membres du projet R-PUCE avec lesquelles il a t trs enrichissant de travailler. Je remercie le CEA-LETI pour les donnes concernant lapplication MC-CDMA du projet 4MORE. Enn, je remercie ma famille et mes amis pour leur soutien et leurs encouragements.

vii

Avant propos
Ces travaux ont dbut dans le cadre dune Equipe Projet Multi-Laboratoire (EPML) appele Mthode de conception des SoC pour la radio logicielle (Sep 02 - Sep 05). Cette quipe projet regroupait des membres du laboratoire IETR (1) de lINSA (2) de Rennes, et du laboratoire LESTER (3) de lUBS. (4) . Ce projet portait sur la dnition des moyens et mthodes mettre en uvre pour obtenir un ot de conception de SoC adapt aux applications de radio logicielle. Il traitait dirents aspects dont ltude des rseaux intgrs. Ces travaux traitent de cet aspect prcis. Pour apporter plus de cohsion cette quipe Multi-Laboratoire, cette thse, a t mene au sein de lquipe Codesign du LESTER tout en tant dirige conjointement par lquipe Communications Propagation Radar de lIETR. Au dbut de cette thse, le domaine des NoCs constituait une nouvelle thmatique pour ces deux laboratoires. Le laboratoire IETR disposait dune exprience en prototypage et en modlisation dans le domaine des applications de tlcommunications. Le laboratoire LESTER disposait dune exprience en reconguration, partitionnement et synthse architecturale. Dans ce cadre, les contraintes de communication de lapplication 4G MIMO MC-CDMA du projet 4MORE [1] nous ont t fournies pour nos exprimentations. Durant la dernire anne de thse, ces travaux se sont intgrs dans le projet R-PUCE (Rseau embarqu sur puce) compos des dpartements dlectronique et RSM (5) de lENST (6) Bretagne, du dpartement RST(7) de lINT (8) dvry, et du LESTER de lUBS. Ce projet porte lui aussi sur le problme de linterconnexion dans les futures puces lectroniques. Il vise une application du domaine des communications numriques, le turbo-dcodage. Lobjectif est de tirer parti de la pluridisciplinarit des quipes partenaires de ce projet pour adapter les modles, les techniques et les outils du domaine des rseaux dordinateurs, au contexte dintgration sur silicium. Nous avons abouti des solutions qui sont prsentes dans le chapitre exprimentations.

Institut dElectronique et de Tlcommunications de Rennes Institut National des Sciences Appliques (3) Laboratoire dlectronique des Systmes TEmps Rel (4) Universit de Bretagne-Sud (5) Rseaux, Scurit et Multimdia (6) cole Nationale Suprieure des Tlcommunications (7) Rseaux et Services des Tlcommunications (8) Institut National des Tlcommunications
(2)

(1)

ix

Table des matires


1 Introduction 1.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Objectifs et contributions . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Organisation du mmoire . . . . . . . . . . . . . . . . . . . . . . . . . 2 tat de lart 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Prsentation de direntes interconnexions . . . . . . . . . 2.1.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . 2.1.1.2 La communication point point . . . . . . . . . . 2.1.1.3 La connexion complte . . . . . . . . . . . . . . . 2.1.1.4 Le crossbar . . . . . . . . . . . . . . . . . . . . . . 2.1.1.5 Le bus unique partag . . . . . . . . . . . . . . . . 2.1.1.6 Le bus hirarchique . . . . . . . . . . . . . . . . . 2.1.1.7 Le rseau distribu sur puce . . . . . . . . . . . . 2.2 Les notions fondamentales dans les NoCs . . . . . . . . . . . . . . 2.2.1 Les lments de base dun NoC . . . . . . . . . . . . . . . . 2.2.2 La topologie . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.3 Les couches rseau . . . . . . . . . . . . . . . . . . . . . . . 2.2.4 Le paquet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.5 Le contrle de ux par crdits dmission . . . . . . . . . . 2.2.6 Le protocole . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.6.1 La technique de commutation . . . . . . . . . . . 2.2.6.2 La stratgie de routage dterministe ou adaptative 2.2.6.3 Routage minimal ou non-minimal . . . . . . . . . 2.2.6.4 Le modle avec retard ou perte . . . . . . . . . . . 2.2.6.5 La politique de mmorisation . . . . . . . . . . . . 2.2.6.6 Le risque dinterblocage . . . . . . . . . . . . . . . 2.2.6.7 Le codage des instructions et la rgle de routage . 2.2.7 Les canaux virtuels . . . . . . . . . . . . . . . . . . . . . . . 2.2.8 La qualit de service . . . . . . . . . . . . . . . . . . . . . . 2.2.9 La synchronisation du NoC . . . . . . . . . . . . . . . . . . 2.3 Historique des NoCs . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Exemple de NoCs et doutils pour les NoCs . . . . . . . . . . . . . 2.4.1 SPIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.2 thereal . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 3 4 5 5 5 5 5 6 6 6 6 7 7 7 8 8 10 10 11 11 11 11 12 12 12 13 13 14 15 15 16 16 17

xii 2.4.3 QNoC . . . . . . . . 2.4.4 Arteris . . . . . . . . 2.4.5 Spidergon . . . . . . 2.4.6 CHAIN . . . . . . . 2.4.7 MANGO . . . . . . 2.4.8 ANoC-FAUST . . . 2.4.9 xPIPES . . . . . . . Les solutions technologiques Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . long terme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

table des matires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 19 20 20 20 21 21 22 22 25 25 25 25 26 27 28 28 28 29 30 32 32 33 33 36 37 38 39 40 40 40 41 41 41 43 44 44 45 45 47 48 48 50 50 51

2.5 2.6

3 Spider : Architecture du NoC, ot de conception et outil 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Architecture du NoC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Prsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Le routeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2.1 Les canaux virtuels . . . . . . . . . . . . . . . . . . . 3.2.2.2 La politique de contrle de ux au niveau lien . . . . 3.2.2.3 La politique de routage et la topologie . . . . . . . . . 3.2.2.4 La politique darbitrage . . . . . . . . . . . . . . . . . 3.2.3 La structure du paquet . . . . . . . . . . . . . . . . . . . . . . 3.2.4 Linterface rseau . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.4.1 Les rservations des slots de temps dans les NIs . . . 3.2.4.2 La table de conguration des ExtraNIchannels . . . . 3.2.5 Adaptateur de protocole NoC-OPB . . . . . . . . . . . . . . . . 3.2.5.1 Prsentation . . . . . . . . . . . . . . . . . . . . . . . 3.2.5.2 Avertir le microprocesseur . . . . . . . . . . . . . . . . 3.2.5.3 Chronogrammes . . . . . . . . . . . . . . . . . . . . . 3.2.5.4 Couche Logicielle . . . . . . . . . . . . . . . . . . . . 3.2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Le ot de conception du NoC . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2 Considration de la taille des FIFOs . . . . . . . . . . . . . . . 3.3.3 Les communications mutuellement exclusives . . . . . . . . . . 3.3.3.1 Dnition de lexclusion mutuelle et de ses rgles . . . 3.3.3.2 La gestion particulire des crdits dmission dans le cas des exclusions mutuelles . . . . . . . . . . . . . . 3.3.4 Prsentation de notre ot de conception . . . . . . . . . . . . . 3.4 Loutil de CAO Spider . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.2 Caractristiques, performances . . . . . . . . . . . . . . . . . . 3.4.3 Modlisation dans Spider . . . . . . . . . . . . . . . . . . . . . 3.4.4 Reprsentation du ot de conception dans Spider . . . . . . . 3.4.5 tapes du ot de loutil Spider . . . . . . . . . . . . . . . . . 3.4.6 Les commandes de loutil Spider . . . . . . . . . . . . . . . . . 3.4.7 Linterface graphique de Spider . . . . . . . . . . . . . . . . . 3.4.8 Spider en chires . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

table des matires 4 Mise en uvre de la qualit de service 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Pralable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Drivation des contraintes applicatives en contraintes de communications 4.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.2 Problmatique . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.3 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.3.1 Temps ncessaire pour quune quantit de donnes accde au rseau et le traverse . . . . . . . . . . . . . . 4.3.3.2 Algorithme . . . . . . . . . . . . . . . . . . . . . . . . 4.3.4 Les rgles respecter . . . . . . . . . . . . . . . . . . . . . . . 4.3.4.1 La rgle dinitialisation . . . . . . . . . . . . . . . . . 4.3.4.2 La rgle de cadence . . . . . . . . . . . . . . . . . . . 4.3.5 Dimensionnement de la table TDMA . . . . . . . . . . . . . . . 4.3.5.1 Prsentation . . . . . . . . . . . . . . . . . . . . . . . 4.3.5.2 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.6 Algorithme de calcul de la taille de la table TDMA . . . . . . . 4.3.7 Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.7.1 Cas dtude et rsultats . . . . . . . . . . . . . . . . . 4.3.7.2 Rsultats . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Routage spatio-temporel . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1 Lallocation des chemins dans lespace et le temps . . . . . . . 4.4.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 4.4.1.2 Topologie avec une exploration sur les dimensions espace et temps . . . . . . . . . . . . . . . . . . . . . . 4.4.1.3 Technique dallocation des chemins . . . . . . . . . . 4.4.1.4 Vue dtaille de lalgorithme de dcision des chemins 4.4.2 Comparaisons des dirents facteurs de cot de ltape de slection du chemin . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.2.1 valuation sur un exemple simple . . . . . . . . . . . 4.4.2.2 tude plus large . . . . . . . . . . . . . . . . . . . . . 4.4.2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 4.4.3 Complexit de lalgorithme et heuristiques possibles . . . . . . 4.4.3.1 Complexit . . . . . . . . . . . . . . . . . . . . . . . . 4.4.3.2 Amliorations et heuristiques . . . . . . . . . . . . . . 4.4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Technique de codage des chemins pour la scurit et la tion 5.1 Introduction la scurit . . . . . . . . . . . . . . . . . . 5.2 Analyse des attaques sur un NoC et points faibles actuels 5.2.1 La scurit . . . . . . . . . . . . . . . . . . . . . . 5.2.2 Les scnarios dattaque . . . . . . . . . . . . . . . 5.2.2.1 Le dni de service . . . . . . . . . . . . . 5.2.2.2 Lextraction dinformations secrtes . . . 5.2.2.3 Laltration du comportement . . . . . . recongura. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

xiii 53 53 53 55 55 55 55 56 57 58 58 60 60 60 61 61 62 62 62 62 63 63 63 63 64 65 68 68 68 69 70 70 70 71 73 73 73 74 75 75 76 76

xiv 5.2.2.4

table des matires La rtro-ingnierie et lextraction dinformations secrtes par accs de proximit . . . . . . . . . . . . . . Les stratgies de protection . . . . . . . . . . . . . . . . . . . . . . . . 5.3.1 Garantir le trac contre le dni de service . . . . . . . . . . . . 5.3.2 Filtre multi-frontires . . . . . . . . . . . . . . . . . . . . . . . 5.3.2.1 Frontire 1 . . . . . . . . . . . . . . . . . . . . . . . . 5.3.2.2 Frontire 2 . . . . . . . . . . . . . . . . . . . . . . . . 5.3.2.3 Frontire 3 . . . . . . . . . . . . . . . . . . . . . . . . Les techniques classiques de codage des instructions de routage . . . . 5.4.1 Codage pour le routage ordonn par dimensions X-Y . . . . . . 5.4.2 Codage street-sign . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.3 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exploitation de linformation de routage . . . . . . . . . . . . . . . . . 5.5.1 Principe du codage relatif pour lauthentication . . . . . . . . 5.5.2 Le complment automatique du chemin (SCP) . . . . . . . . . 5.5.3 Utilisation pour la reconguration . . . . . . . . . . . . . . . . 5.5.4 Le rarrangement binaire automatique des instructions de routage 5.5.5 Encryptage du bitstream . . . . . . . . . . . . . . . . . . . . . . Contre-attaque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6.1 Raction face un routage erron . . . . . . . . . . . . . . . . 5.6.2 Rtro-ingnierie et extraction dinformations secrtes par analyse direntielle de puissance . . . . . . . . . . . . . . . . . . . 5.6.3 Supervision de bande passante et de consommation . . . . . . . Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.3

5.4

5.5

5.6

76 76 76 77 77 78 79 80 80 81 81 81 81 82 84 85 85 85 85 86 87 87

5.7

6 NoC avec trac garanti dans une approche de type GALS 89 6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 6.2 La synchronisation et la QoS . . . . . . . . . . . . . . . . . . . . . . . 89 6.2.1 Problmatique . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 6.2.2 Synchroniser un systme . . . . . . . . . . . . . . . . . . . . . . 90 6.2.3 tat de lart de la gestion de la QoS et des horloges dans les NoCs 90 6.2.4 Contexte dans lequel nous nous plaons . . . . . . . . . . . . . 91 6.2.5 Rsum de lapproche dveloppe . . . . . . . . . . . . . . . . . 91 6.3 Le routage temporel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 6.3.1 Problmatique . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 6.3.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 6.3.3 Calcul de la taille de la FIFO . . . . . . . . . . . . . . . . . . . 93 6.4 Synchroniseur de TDMAs . . . . . . . . . . . . . . . . . . . . . . . . . 95 6.4.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 6.4.2 Le contrle de ux de bout-en-bout . . . . . . . . . . . . . . . 97 6.4.2.1 Le contrle de ux global, niveau NoC . . . . . . . . . 97 6.4.2.2 Le contrle de ux au niveau local, niveau sub-NoC . 98 6.4.2.3 Comparaison entre les contrles de ux global et local 99 6.4.3 Instructions de routage . . . . . . . . . . . . . . . . . . . . . . 99 6.4.4 Redimensionnement de la taille des paquets dans le cas du contrle de ux global . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 6.4.4.1 Formulation du problme . . . . . . . . . . . . . . . . 100

table des matires 6.4.4.2 Solutions . . . . . Application et rsultats . . . . . . 6.5.1 Contexte de lapplication . 6.5.2 Description des cas dtudes 6.5.3 Analyse des rsultats . . . . Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

xv 101 103 103 104 104 105 107 107 107 107 107 107 109 110 110 111 111 111 112 113 113 115 116 116 116 118 118 119 119 120 121 121 121 122 123 123

6.5

6.6

7 Exprimentations et rsultats 7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Intgration sur FPGA . . . . . . . . . . . . . . . . . . . 7.2.1 Conditions du test . . . . . . . . . . . . . . . . . 7.2.1.1 Environnement . . . . . . . . . . . . . . 7.2.1.2 Prsentation . . . . . . . . . . . . . . . 7.2.2 Rsultats de synthse . . . . . . . . . . . . . . . 7.2.3 Rsultats du test sur la plate-forme . . . . . . . 7.2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . 7.3 Traitement dimage . . . . . . . . . . . . . . . . . . . . . 7.3.1 Prsentation . . . . . . . . . . . . . . . . . . . . 7.3.2 Rsultats . . . . . . . . . . . . . . . . . . . . . . 7.3.3 Conclusion . . . . . . . . . . . . . . . . . . . . . 7.4 Chane MC-CDMA MC-SS-MA . . . . . . . . . . . . . . 7.4.1 Prsentation . . . . . . . . . . . . . . . . . . . . 7.4.2 Rsultats . . . . . . . . . . . . . . . . . . . . . . 7.4.3 Conclusion . . . . . . . . . . . . . . . . . . . . . 7.5 Turbo dcodeur . . . . . . . . . . . . . . . . . . . . . . . 7.5.1 Prsentation . . . . . . . . . . . . . . . . . . . . 7.5.2 Analyse . . . . . . . . . . . . . . . . . . . . . . . 7.5.3 Une premire solution utilisant le best eort . . . 7.5.4 Une solution utilisant le pr-ordonnancement par 7.5.5 Rsultats . . . . . . . . . . . . . . . . . . . . . . 7.5.6 Conclusion . . . . . . . . . . . . . . . . . . . . . 7.6 Combinaisons des applications . . . . . . . . . . . . . . 7.6.1 Prsentation . . . . . . . . . . . . . . . . . . . . 7.6.2 Rsultats . . . . . . . . . . . . . . . . . . . . . . 7.6.3 Analyse . . . . . . . . . . . . . . . . . . . . . . . 7.6.4 Conclusion . . . . . . . . . . . . . . . . . . . . . 7.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TDMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8 Conclusion et Perspectives 125 8.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 8.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Annexe
Publications personnelles

129
131

xvi Table des gures Liste des tableaux Bibliographie Acronymes et Abrviations

table des matires 133 135 137 144

Chapitre 1

Introduction
1.1 Contexte

Nous assistons la convergence de plusieurs produits vers un seul appareil multifonctions, avec des appareils tels que les set-top boxes (TV, dcodeurs, DVD, enregistreur numrique, accs rseaux) domicile [2], les PC multimdias, les consoles de jeux vido, les tlphones portables, etc. Ceux sont des systmes dont la pluralit des fonctionnalits ncessite lutilisation darchitectures lectroniques orant de hautes performances et une grande exibilit pour leurs permettre de sadapter aux besoins de lutilisateur, lenvironnement et aux volutions des normes futures. Cette multiplicit des fonctions ncessite dimportants moyens de communication au sein du systme. Cette augmentation des fonctionnalits des appareils est rendue possible grce aux progrs continus des mthodes de conception et des capacits dintgration dans les puces lectroniques. Le concepteur dispose de composants matriels appels IP(s) (Intellectual Property) qui, comme des cellules de bibliothque peuvent tre utiliss comme lments de base pour concevoir de nouveaux circuits. Ceci permet la rutilisation de ce qui a dj t conu et ainsi dacclrer le dveloppement. De plus, la densit dintgration des transistors augmentant de faon continue, il est aujourdhui possible de construire des circuits contenant plusieurs centaines de millions de transistors. Il est ainsi concevable de dvelopper un systme complet sur une seule puce de silicium, nous parlons alors de systme mono-puce (SoC pour System on Chip). Un SoC intgre en gnral des composants IPs varis, tels que des processeurs gnralistes et spcialiss, de la mmoire, des interfaces pour des priphriques, des moyens de communication, des circuits ddis/spcialiss pour acclrer le traitement de certaines fonctions (codec video, moteur graphique, cryptographie). Lvolution montre que de nouveaux types de composants peuvent galement tre intgrs, tels que des dispositifs mcaniques (MeMS(1) ), opto-lectroniques, chimiques ou biologiques ou des circuits radio (antennes) [3]. Cependant, la conception de systmes sur puces entrane un certain nombre de ds relever pour concevoir les circuits de demain. En eet, les mthodes de conception et les outils dont disposent les concepteurs voluent moins vite que la capacit dintgration. Les concepteurs ne sont alors plus en mesure de tirer rellement prot
(1)

Micro-electro-mechanical system

introduction

des capacits dintgration oertes par la technologie. Un SoC intgrera bientt plusieurs dizaines, voir centaines dIPs interconnectes [4]. La dicult majeure lors de la conception de systmes sur des puces de grande taille est la communication entre les dirents composants du systme. En 2008, il est estim que la traverse dun circuit prendra 16 cycles dhorloge [5]. Le dlai dans les ls domine le dlai des portes partir de la technologie 0,25m pour laluminium, et 0,18m pour le cuivre [6]. Les communications sont ainsi devenues dominantes du point de vue des dlais, de la consommation en nergie et de la surface de silicium ; Nous avons donc besoin de rendre ces communications explicites pour quelles puissent tre prises en charge et optimises durant le ot de conception du SoC. De plus, se pose le problme de la scalabilit. La scalabilit est la capacit dun systme voluer (augmenter ses performances) en permettant dexploiter lamlioration apporte par son extension au niveau matriel. Or, les solutions dinterconnexions classiques ne sont pas adaptes lextension des SoC. Une solution performante et conomique consiste tirer prot dune infrastructure de communication congurable prtablie, savoir un rseau sur puce (NoC pour Network on Chip) [7, 8]. Les composants communiquent alors entre eux en changeant des paquets au travers dun rseau dinterconnexions, fournissant une structure de communication rutilisable. Le recours un NoC simpose pour les circuits de grande dimension, aussi bien du point de vue technologique (longs dlais entre les parties loignes dune mme puce), que du point de vue fonctionnel (facilit de connexion des composants IPs et donc de leur rutilisation). La matrise des caractristiques du NoC est un atout majeur car la consommation et la performance dun SoC seront de plus en plus domines par les ressources de communication. Les contraintes imposes aux systmes lectroniques an de satisfaire les exigences des applications et du march sont diverses. Celles-ci sont un faible cot en surface de silicium, une faible consommation lectrique, le respect des exigences de performances de bande passante, de latence et de abilit. La recongurabilit du systme impose aussi comme qualits requises la exibilit pour manipuler des tracs varis et la facilit dinterfaage pour permettre de potentielles recongurations des interfaces. ces critres, nous pouvons encore ajouter des aspects plus architecturaux tels que la testabilit, la tolrance aux incertitudes temporelles de limplmentation et la tolrance aux dfauts de fabrication. Tous ces critres doivent guider le choix de larchitecture de communication mettre en uvre. De plus, il est ncessaire de disposer de mthodes et doutils qui permettent de rduire le temps de mise sur le march (time to market) des produits dvelopps. Le NoC peut lui mme tre vu comme une IP rendant des services aux IPs qui lui sont connectes. Il doit permettre dorir un niveau dabstraction permettant de sparer le traitement et le transport des donnes. Comme tout composant IP, il doit tre optimis en performances, surface et consommation dnergie. Seulement, le NoC ore beaucoup de paramtres (topologie, frquence, chemins, taille des tampons de mmorisation, stratgie de mmorisation, routage, arbitrage, contrle de ux, etc.). De plus, ces choix sont trs dpendants de lapplication et des services attendus. Lespace de conception tant extrmement large, il est illusoire de vouloir explorer toutes les solutions en fonction des dirents compromis possibles. Il est donc ncessaire de

1.2 objectifs et contributions

disposer de mthodologies et doutils pour assister le concepteur an de le guider dans ces choix et laider concevoir le NoC adapt ses besoins. Enn, dans la logique de lvolution des architectures, le NoC, de part son rle central dans le systme, doit permettre les recongurations du systme, pour orir la exibilit et lvolution. Il doit de plus garantir la scurit des donnes et des IPs raccordes. Il faudra ainsi dterminer le compromis entre le cot de mise en oeuvre et la exibilit dsire. Enn, il apparat que le NoC a un lien de plus en plus fort avec les services du systme dexploitation pour contrler et adapter la qualit de service de lapplication celui-ci et vis et versa.

1.2

Objectifs et contributions

Le but de cette thse tait dtudier le domaine mergeant des NoCs et de proposer un outil de CAO (conception assiste par ordinateur) intgrant le concept du NoC dans le ot de conception dun SoC. En 2002, il existait peu de ralisations de NoC et il nexistait pas doutil consacr au NoC. Le NoC tait un concept qui commenait tout juste montrer son intrt. Ce sujet tant nouveau pour les quipes des laboratoires LESTER et IETR, nous navions pas de NoC notre disposition. Nous avons dcid de concevoir un routeur gnrique en langage VHDL au niveau RTL. Cette ralisation a eu pour intrt de permettre de mener des simulations prcises ainsi que des valuations concrtes des caractristiques dun rseau. Le concept semblait assez simple au premier abord, mais il est rapidement apparu que nous avions besoin dun moyen pour contrler le trac an de garantir les contraintes temps-rel. Nous avons alors dcid dintgrer les canaux virtuels dans les routeurs an de crer des classes de trac dirents. Avec des paramtres de plus en plus nombreux, il devenait dicile dcrire le code VHDL gnrique et il est alors devenu ncessaire de crer un outil de gnration du code VHDL du NoC. Nous avons alors opt pour le langage de description XML et une conception de loutil oriente objet pour nous permettre de modier plus facilement les paramtres du NoC (topologie et paramtres divers). Ensuite nous avons opt pour lutilisation de tables TDMAs (Time Division Multiple Access) pour permettre de garantir les tracs dans le NoC. Nous avons alors dvelopp une interface rseau capable de contrler ce type daccs. Celle-ci est venue enrichir loutil de synthse. Il est alors devenu ncessaire de renseigner ces tables de faon approprie. Nous avons labor un ot de conception complet et des mthodes de dcision, an dorganiser et dautomatiser ces choix partir de contraintes applicatives renseignes par le concepteur. Nous avons ralis un outil de dcision capable de dterminer la taille de la table TDMA approprie et de slectionner, pour chaque communication, les slots quelle doit utiliser dans la table de TDMA, ainsi que le chemin quelle doit emprunter dans le rseau, an de garantir quelle ne rencontrera aucune collision avec les autres communications durant son transport dans le rseau. De plus, loutil dtermine la taille des FIFOs ncessaires dans les interfaces du rseau.

introduction

Dans le cadre du projet R-PUCE, nous avions besoins de connecter des processeurs au NoC. Nous avons alors dvelopp un adaptateur de protocole permettant de connecter les interfaces du NoC avec le bus OPB utilis par le processeur MicroBlaze. Paralllement cela, nous nous sommes penchs sur la question de la scurit dans les NoCs et avons trouv une solution qui sappuie sur les instructions de routage pour orir un service dauthentication de lmetteur dun paquet dans le rseau. Enn, nous nous sommes confronts au problme de la distribution de lhorloge dans les circuits de grande taille dans le contexte de lutilisation dun TDMA qui ncessite une notion dhorloge commune. Nous avons galement propos des solutions ce problme.

1.3

Organisation du mmoire

Ce mmoire de thse comporte 7 autres chapitres. Le chapitre 2 prsente un tat de lart des interconnexions et des NoCs existants ainsi que les pistes de recherches que nous nous sommes xes au fur et mesure de lavancement de cette thse. Le chapitre 3 prsente larchitecture de notre NoC, le ot de conception que nous proposons et loutil que nous avons dvelopp pour aider le concepteur raliser un NoC. Le chapitre 4 dtaille la mise en uvre des tapes de notre ot. Il dcrit comment driver les donnes extraites de lapplication, en donnes utilisables au niveau du NoC. Il prsente galement notre technique dexploration et daectation des chemins ddis aux communications garantir dans le NoC. Le chapitre 5 prsente des techniques de codage des instructions de routage des ns de scurit, ou de exibilit. Le chapitre 6 prsente des solutions pour faire face aux problmes dhorloges dans les futures circuits de grande taille. Nous proposons de diviser le NoC en plusieurs sub-NoCs synchrones qui garantissent le service. Des interfaces permettent de relier ces sub-NoCs. Le chapitre 7 prsente les rsultats de synthse du NoC sur FPGA, ainsi que les rsultats obtenus pour des applications des domaines du traitement du signal, de limage et des tlcommunications. Enn, le chapitre 8 conclue sur les travaux raliss durant cette thse et propose des perspectives.

Chapitre 2

tat de lart
2.1 Introduction

Le domaine des NoC est un sujet de recherche rcent. Ltat de lart, sest to de faon importante durant cette thse. Le sujet est de plus pass rapidement de la recherche universitaire la recherche industrielle (Philips research) pour arriver une solution industrielle avec la socit Arteris qui commercialise sa solution. Ceci montre lintrt des industriels pour obtenir des solutions de communications base de NoCs. Pour prsenter le NoC, dans un premier temps, nous expliquons en quoi les moyens de communication classiques ne rpondent plus aux contraintes futures des systmes sur puce et ce que le rseau sur puce apporte comme solution. Dans un second temps, nous expliquons un certain nombre de notions fondamentales relatives aux NoCs. Puis, nous dressons un historique de lvolution de la recherche dans le domaine des NoCs. Nous prsentons les caractristiques des NoCs et outils existants les plus reprsentatifs et prsentons quelques solutions technologiques long terme. Enn, nous expliquons les objectifs que nous nous sommes xs et le contexte dans lequel nous nous sommes placs.

2.1.1
2.1.1.1

Prsentation de direntes interconnexions


Introduction

Nous prsentons ici les moyens dinterconnexion classiques et valuons leur capacit satisfaire les besoins des applications futures et les contraintes des circuits complexes de grande taille. 2.1.1.2 La communication point point

La premire communication que lon peut considrer est la communication point point entre les IPs. Cette solution nore pas de exibilit, or, les IPs auront besoin de communiquer avec des IPs direntes en fonction des volutions des besoins de lapplication. Cette solution ne peut donc pas tre retenue.

6 2.1.1.3 La connexion complte

tat de lart

Dans le cas de la connexion complte (full connected), toutes les IPs sont relies les unes aux autres. Cest donc dans le principe un bon moyen de communication. Mais, le taux dutilisation moyen des ls est gnralement trs faible, les ls sont sous exploits. Cest aussi le moyen de communication le plus coteux en nombre de ls et en nombre dinterfaces par IP connect. De plus, cette solution nest pas extensible un grand nombre dIPs communicantes. Nous avons donc besoin dun moyen de communication pouvant tre partag. 2.1.1.4 Le crossbar

Toutes les IPs sont relies les unes aux autres par un crossbar. Celui-ci permet des communications parallles ainsi que dobtenir une grande bande passante. Cependant, la complexit de cblage est trs grande dans une telle architecture. Elle augmente avec le carr du nombre dlments communicants : O(n2 ). 2.1.1.5 Le bus unique partag

Le bus unique partag possde plusieurs avantages. Tout dabord, il est simple matriser par les concepteurs car les oprations se font de faon squentielle. De plus, la topologie du bus supporte directement le modle de communication par adressage mmoire des IP microprocesseurs. Enn, il a gnralement une smantique darbitrage simple du type arbitrage par priorit. Cependant, il a aussi ses limites, puisquil sagit dune ressource partage. Larbitrage central du bus est un goulot qui implique un dlai non ngligeable lorsquil doit lire un matre parmi plusieurs. Le nombre de composants raccords est donc limit. Le bus ne permet pas le paralllisme des communications (un seul transfert la fois). Il nest donc pas scalable (la bande passante naugmente pas lorsque le nombre de composants augmente). De plus, le bus est sujet un problme lectrique. En eet, les lignes du bus sont longues et le temps de charge augmente avec le nombre dlments raccords du fait des capacits parasites de ces derniers. Sa frquence de fonctionnement sen trouve donc rduite et sa consommation lectrique augmente. Enn, le temps de propagations des signaux sur les longs ls cause la drive des horloges et ainsi des problmes de synchronisation. 2.1.1.6 Le bus hirarchique

Le bus hirarchique consiste en linterconnexion de plusieurs bus, gnralement de performances direntes, relis par un pont. Comme exemples de bus hirarchiques, nous pouvons citer : AMBA de ARM [9] et CoreConnect de IBM [10]. Le Bus hirarchique possde plusieurs avantages sur le bus partag. Les dirents segments du bus hirarchique ont des liaisons courtes et peu de composants IPs connects, ce qui implique une faible capacit sur chacun de ces segments et donc une plus faible consommation, ainsi que la possibilit dutiliser une frquence plus leve. Des transactions peuvent se faire en parallle sur les dirents segments de bus. Lors dun transfert entre deux bus dun bus hirarchique, un pont permet la mise en communication entre ces bus. Lun

2.2 les notions fondamentales dans les nocs

des bus asservit alors lautre. Cependant, laccs dun bus un autre au travers dun pont, implique un cot en latence ; Cest pourquoi il est important de bien rpartir les direntes IPs communicantes pour limiter lutilisation du pont et ainsi favoriser le fonctionnement parallle des bus. Ce dcoupage en segment est un premier pas qui tend vers lapproche rseau. 2.1.1.7 Le rseau distribu sur puce

Nous trouvons depuis dj longtemps les rseaux distribus dans les architectures multiprocesseurs [11]. Le NoC sinspire du modle des rseaux dordinateurs et a t adapt au contexte du SoC. Cependant, toutes les fonctionnalits que lon connat dans les rseaux dordinateurs ne sont pas ncessaires dans les NoCs et auraient de plus un cot prohibitif en surface et en temps. Lutilisation dun rseau sur puce a pour premier intrt de structurer les communications [8]. Les liens sont point point, ainsi les proprits lectriques peuvent tre optimises et bien contrles ce qui peut permettre de rduire la consommation de puissance. Le partage des ressources de communication entre plusieurs ots de communication permet une meilleure utilisation des ls. De mme que les bus, il facilite la modularit en dnissant une interface standard. Mais vis vis des bus, les rseaux ont gnralement une plus grande bande passante et surtout supportent les communications concurrentes multiples. De plus, il est exible et extensible [12, 13].

2.2
2.2.1

Les notions fondamentales dans les NoCs


Les lments de base dun NoC

La gure 2.1 montre un exemple de NoC en grille 2D de taille 2x2. Elle montre galement les lments qui composent un NoC et son environnement.

Fig. 2.1 Les lments dun NoC Les composants de base du NoC sont : Les adaptateurs rseau (NA) : Ils ralisent linterface entre le protocole du NoC et celui des blocs IPs qui composent le systme. Leur rle est de sparer

tat de lart le traitement (eectu dans les IPs) des communications (achemines par le rseau). Un adaptateur rseau peut tre spar en deux parties, linterface rseau (NI) et ladaptateur de protocole ou wrapper. Les nuds routeurs : Ils dirigent les donnes dans le rseau en accord avec le protocole choisi et intgrent la stratgie de routage. Les liens : Ils connectent les nuds deux deux, ce sont eux qui orent la bande passante. Un lien peut consister en plusieurs canaux virtuels et peut tre monodirectionnel ou bidirectionnel.

2.2.2

La topologie

La topologie dsigne le graphe des liens entre les dirents lments du rseau. Une topologie rgulire peut se caractriser par son nombre de dimensions (1D, 2D, 3D, etc.) Les topologies en 3D et suprieures peuvent poser un problme lors du routage sur silicium. Une topologie se caractrise galement par sa forme (linaire, grille, arbre, tore, multigrille, hypercube, etc.) et sa rgularit ou non. Les NoCs de la littrature utilisent trs gnralement des topologies rgulires. La topologie standard est la topologie en grille 2D (2D mesh). Elle est adapte la technologie 2D des circuits intgrs et est scalable. Elle permet dutiliser des stratgies de routage simple et donc peu coteuses. Une topologie en arbre largi (Fat-tree) a pour intrt dtre scalable et dorir une latence pouvant tre plus faible que la topologie en grille 2D. Une topologie en anneau, telle que celle de loctogone utilise par [14], permet de rduire la latence. Une structure rgulire prsente lintrt dtre une topologie de structure mathmatique simple, ce qui permet dutiliser des rgles de routage simples. Cependant, en pratique, le placement et la taille des composants IP du SoC permettent rarement dintgrer une topologie rgulire. Une topologie irrgulire permet plus de libert et ainsi de tailler prcisment le rseau requis. Elle peut tre issue dune topologie rgulire qui a t retaille au plus juste de faon enlever les lments non utiliss [15]. Une topologie irrgulire ncessite en revanche une plus grande attention pour le routage car les rgles appliquer ne sont plus triviales. Ainsi, dans la mesure du possible nous privilgions lutilisation dune topologie rgulire, mais nous devons disposer dune solution qui permette lutilisation plus gnrale dune topologie quelconque.

2.2.3

Les couches rseau

Le modle OSI (Open Systems Interconnection) dcrit le processus de fonctionnement dun rseau sous forme de 7 parties appeles couches OSI. Or, cette reprsentation nest pas adapte la description dun NoC car celui-ci nintgre pas toutes ces divisions en couches. Il nexiste pas de modle standardis pour reprsenter les couches rseau dun NoC. Nous pouvons utiliser le modle reprsent par la gure 2.2 qui est adapt de [16]. Cette gure nous montre le ot dune donne depuis une IP source vers une IP destination au travers des lments dun NoC. Elle indique de plus la correspondance avec les domaines de recherches et les couches rseau du modle OSI. Nous distinguons les domaines suivants : Le systme : il reprsente lapplication et larchitecture (IP et rseau entier) ;

2.2 les notions fondamentales dans les nocs

Fig. 2.2 Les lments du NoC et les couches rseau Ladaptateur-rseau : il adapte les protocoles de lIP et du NoC (rle du wrapper). Il dcoupe les messages en paquets, leur ajoute linformation indiquant leur destination et contrle le ux des communications de bout-en-bout (rle de la NI). Le contrle de ux de bout-en-bout a pour but dviter que des donnes ne soient envoyes vers une destination alors quelle na plus de place disponible pour les recevoir. Le rseau : il dnit la technique de routage employe pour lacheminement des paquets travers le rseau et la topologie ; La liaison : elle dnit le protocole dchange des bits sur les liens entre les routeurs (poigne de mains, crdit dmission) ainsi que la technique de dtection et correction derreur de transmission (bit de parit) ; Le niveau physique : cest la couche de plus bas niveau dun NoC, elle dnit le moyen physique par lequel seront transports les paquets, la nature de linterconnexion (ls de cuivre), ainsi que la faon dont les donnes sont transportes (largeur des mots transports en nombre de bits). Un it (FLow control unIT ) correspond la plus petite unit de contrle de ux sur un lien. Un phit (PHysical unIT ) correspond la quantit de bits qui peut tre transporte en une seule fois sur le lien (largeur du mot transport). Le contrle peut tre ralis avec une granularit de un ou plusieurs mots. Le contrle se fait donc la frquence des its, alors que les donnes circulent la frquence des phits. Si le contrle est lent, un it de plusieurs phits peut permettre dchanger des donnes une plus grande frquence. En revanche, cela rduit le taux de commutation et ncessite un mcanisme pour signaler les its qui ne sont que partiellement remplis [17]. Dans la majorit des NoCs, un it contient un seul phit, cest galement le choix que nous avons fait pour notre NoC.

10

tat de lart

2.2.4

Le paquet

Les IPs doivent pouvoir communiquer en schangent des messages au travers du rseau. La taille des messages peut varier en fonction des applications. Pour une utilisation ecace et quitable des ressources du rseau, un message est souvent divis en paquets avant dtre transmis. Un paquet est la plus petite unit de communication qui contienne des informations de routage et de squenage. Sur la gure 2.3 nous pouvons voir comment est compos un paquet. Un paquet est compos de its eux mme forms de phits (sur lexemple de la gure un it contient deux phits). Le paquet dbute par un entte (ou header), celui-ci transporte notamment des informations relatives au routage de ce paquet an quil puisse tre achemin vers sa destination. Le paquet possde galement une queue. Celle-ci contient une information qui indique la n du paquet. Le corps du paquet peut transporter une charge utile, qui est le message transmettre.

Fig. 2.3 La structure dun paquet

2.2.5

Le contrle de ux par crdits dmission

Nous distinguons un contrle de ux sur deux niveaux des couches rseau, lun de bout-en-bout du rseau et lautre aux extrmits dun lien. La technique la plus largement utilise est le contrle de ux par crdit dmission [12]. Cette technique ore une indpendance vis vis de la latence. Le lien peut tre ainsi pipelin sans que cela ninue sur le mcanisme. Les crdits indiquent lmetteur la quantit de places libres dans la mmoire du destinataire. linitialisation lmetteur dispose de la totalit des crdits. Lmetteur peut uniquement envoyer des donnes au rcepteur dans la limite des crdits dont il dispose. De plus, lmetteur dcrmente son nombre de crdits chaque fois quil envoie une donnes vers ce destinataire. Lorsque le destinataire consomme les donnes, il lindique lmetteur en lui renvoyant le nombre de crdits correspondant lespace nouvellement libr dans sa mmoire. Lutilisation dune technique de contrle de ux nest pas systmatique, le ux peut tre garanti, il nest alors pas ncessaire de raliser son contrle. Labsence de contrle de ux peut

2.2 les notions fondamentales dans les nocs

11

aussi tre un choix du concepteur en fonction des caractristiques de son application, comme nous le verrons dans la section 7.5.

2.2.6

Le protocole

Le protocole, est le mcanisme par lequel les messages vont transiter dans le rseau. Le chemin (ou path) est le parcours quutilise le message pour aller dune source une destination dans le rseau. Il existe de nombreuses techniques de routage en fonction de la topologie vise et des compromis entre exibilit et complexit [18]. Nous distinguons plusieurs aspects. 2.2.6.1 La technique de commutation

Nous distinguons deux types principaux de techniques de commutation (ou switching), la commutation de circuit et la commutation de paquets. La commutation de circuit consiste en des interconnexions qui commutent sur le circuit. Un chemin x est mis en place pour chaque paire source-destination pour la dure de la communication. Le message est ainsi transmis entirement par ce chemin. Tous les composants du rseau le long du chemin sont engags simultanment pour la dure de la communication. Lorsque la communication est termine, le chemin est dissout ; La commutation de paquets, quant elle, consiste diviser la communication en plusieurs morceaux (paquets) et envoyer chacun dentre eux sur un lien de faon dirente. Les dlais de communications sont non-dterministes, du fait des contentions des ressources de communications. Ce type de commutation ncessite un contrle de ux et de congestion. La commutation de circuit est sre, alors que la commutation de paquets est exible. Nous avons fait le choix de la commutation de paquets et nous verrons dans la section 2.2.8 quelle bncie de moyens qui lui permettent dtre galement dterministe. 2.2.6.2 La stratgie de routage dterministe ou adaptative

Dans le cas dune stratgie de routage dterministe, le chemin est dtermin uniquement par la source et la destination. Avec le routage par la source, la source spcie le chemin emprunter pour atteindre la destination. Dans le cas du routage adaptatif, le chemin est dcid au fur et mesure du parcours de proche en proche [19]. Cela implique un mcanisme darbitrage, celui-ci peut tre bas sur la congestion des liens. Le routage adaptatif a une implantation plus coteuse dans les routeurs, mais permet une rgulation dynamique de la charge dans le rseau. Cependant, cet aspect dynamique va lencontre de la prdictibilit du comportement du NoC. Comme nous visons des applications temps-rel, nous prfrons un routage dterministe. Il est cependant envisageable dutiliser un routage adaptatif, pour les tracs sans contrainte particulire. 2.2.6.3 Routage minimal ou non-minimal

Un algorithme de routage est minimal sil ore toujours le chemin le plus court entre la source et la destination.

12 2.2.6.4 Le modle avec retard ou perte

tat de lart

Dans le cas dun conit entre deux paquets pour accder une ressource du rseau (contentions), il existe deux possibilits, lun des deux paquets est soit retard, soit supprim. Dans le premier cas, il est ncessaire de disposer de tampons de mmorisation dans les routeurs pour viter que le corps du paquet en attente ne cre de nouveaux conits. Dans le second cas, si lon veut viter que des paquets soient perdus, le paquet supprim devra tre retransmis. Il faut alors que des mcanismes soit mis en jeu pour signaler les paquets devant tre retransmis. Ce mcanisme et la retransmission implique un cot. De plus, il faut quune sauvegarde de la donne existe la source. Nous verrons dans la section 7.5 quun choix dlibr de ne pas retransmettre les donnes peut se justier si les donnes perdues peuvent tre ngliges. 2.2.6.5 La politique de mmorisation

La commutation de paquets prsente 3 politiques de mmorisation : store-and-forward : Chaque routeur attend davoir reu la n du paquet et le stocke entirement avant de le faire suivre. cut-through : Chaque routeur fait suivre les paquets au plus vite, mais il peut stocker tout le paquet sil y a une contention. wormhole (ou trou-de-ver) : Cette politique consiste acheminer les paquets sous forme de its, ce qui permet de raliser dans les routeurs une conomie de mmoire et donc de surface en silicium. De plus, cette solution ore une faible latence pour la traverse dun routeur puisque ce dernier ne mmorise pas le paquet en entier. Le paquet est ainsi achemin en pipeline sur plusieurs routeurs. Linconvnient du wormhole est que cet acheminement des paquets en pipeline peut conduire, en cas de contention dun des paquets dans le rseau, une contention en cascade de tout le rseau, voir a un interblocage (deadlock) [18]. La technique wormhole est la plus populaire, pour son faible cot en mmoire dans les routeurs et sa faible latence dacheminement, ceci en dpit du risque de contention quelle fait courir et du contrle de ux quil est ncessaire de mettre en uvre. Dans la suite du document, nous ne nous intresserons qu cette dernire. 2.2.6.6 Le risque dinterblocage

Un interblocage ou deadlock est la situation dans laquelle un ou plusieurs paquets peuvent rester bloqus indniment dans le rseau. Elle peut apparatre si des paquets sont autoriss dtenir des ressources alors quils en requirent dautres [18]. Dans le cas du routage wormhole, les canaux sont les ressources critiques. Une faon de rsoudre le problme de deadlock, est de faire de lanticipation des paquets impliqus dans un potentiel deadlock. Les paquets concerns peuvent alors tre re-routs ou supprims. Dans le premier cas, cela ncessite des techniques de routage adaptatives. Dans le second cas, cela ncessite que les paquets puissent tre retrouvs la source et retransmis. Du fait des exigences de faible latence et de abilit, lanticipation de paquet nest pas utilise dans la plupart des architectures de rseau direct.

2.2 les notions fondamentales dans les nocs

13

Labsence de deadlock est gnralement garantie par lalgorithme de routage. Un graphe de dpendance de canaux peut tre utilis pour dvelopper un algorithme de routage sans interblocage (ou deadlock-free). En mettant les ressources du rseau dans un ordre et en exigeant que les paquets demandent et utilisent ces ressources dans un ordre strictement monotonique, lattente circulaire (qui est une condition ncessaire lapparition dun deadlock) est vite. 2.2.6.7 Le codage des instructions et la rgle de routage

Il faut distinguer la technique dadressage et les rgles de routage. La technique dadressage dnit comment sont codes les instructions de routage. Les rgles de routage dnissent la faon dont le paquet peut se dplacer dans le rseau. Le Routage ordonn par dimensions X-Y : Il est trs utilis pour le routage dterministe sur les topologies en grille 2D car il est simple raliser. Il impose que les routeurs acheminent le paquet sur la dimension X puis sur la dimension Y. Ainsi, dans lentte du paquet, le champ des instructions de chemin du paquet peut consister simplement en deux valeurs, X et Y. Ces valeurs sont exprimes soit en relatif aux coordonnes de lmetteur (le nombre de sauts de routeur en routeur raliser dans chaque dimension pour arriver au destinataire), soit en absolu (les coordonnes de la destination). Dans le cas du routage relatif, chaque saut, les routeurs dcrmentent la valeur correspondant cette dimension. Ainsi, arrive destination, ces valeurs sont nulles dans le cas du routage relatif et valent les coordonnes de la destination dans le cas du routage absolu. Cette technique de routage exclue le risque de deadlock. Le codage street-sign : Le codage street-sign utilise une liste dinstructions du type Nord, Sud, Est, Ouest et descendre, indiquant la direction prendre chaque routeur, ou des routeurs identis. Une fois excute, linstruction courante est supprime et les instructions restantes sont dcales pour que la suivante prenne sa place en tte de liste. Il est galement possible dutiliser un identiant pour signaler quel routeur doit tre excute chaque instruction. Une direction par dfaut est alors dtermine pour les routeurs pour lesquelles aucune instruction nest donne. La direction par dfaut est gnralement le port situ en face de celui par lequel le paquet est entr. Cette technique permet de rduire le nombre dinstructions ncessaires. Le codage street-sign permet de mette en uvre nimporte quelle technique de routage. Il ne garantit daucune manire labsence des deadlocks. Celle-ci doit donc tre rsolue par la technique de routage ou par un ordonnancement. Nous verrons que cet aspect est rsolu dans la section 4.4.

2.2.7

Les canaux virtuels

Les canaux virtuels (VCs) sont des canaux qui se rpartissent entre eux un canal physique en utilisant des tampons de mmorisation dirents. Le cot supplmentaire quils impliquent en mmorisation et contrle rsulte en une augmentation de la surface et de la latence. Cependant ils prsentent de nombreux avantages : viter les interblocages. Les canaux virtuels sont indpendants, ainsi en les utilisant avec des techniques de routage appropries, ils permettent de briser des

14

tat de lart

cycles du graphe des dpendances de ressources [19, 18]. Les VCs facilitent notamment lutilisation des algorithmes de routage adaptatifs. Optimiser lutilisation des liens. Le partage du lien physique par plusieurs canaux virtuels peut permettre de faire une meilleure utilisation du lien. Ceci ore aussi une rduction du nombre de liens ncessaires. Augmenter les performances. Dally montre que les performances de linterconnexion peuvent tre amliores en divisant la taille dun tampon sur plusieurs canaux virtuels [20]. Fournir des services spars. Les canaux virtuels peuvent tre utiliss pour sparer des tracs et leurs orir des niveaux de priorit dirents. Nous verrons que le surcot induit par lutilisation de canaux virtuels peut tre compens par les avantages quelle apporte.

2.2.8

La qualit de service

Pour quune application puisse assurer des contraintes de bon fonctionnement et de temps-rel, il faut que les communications bncient dune qualit de service. La qualit de service (QoS) comprend plusieurs notions. Les services attendus sont que la communication doit tre correcte, complte et respecter les contraintes de performances. Les contraintes de performances de la communication sont la bande passante, la latence ou la variation de linstant darrive (jitter). Nous identions deux classes de services, le trac au mieux (BE pour best-eort) et le trac garanti (GS pour guaranteed services). Le BE dsigne un trac qui nore pas de garantie sur les performances, mais gnralement, il garantit tout de mme que les donnes seront correctement et compltement transmises. Cest pourquoi, on utilise aussi le sigle GT (guaranteed throughput) au lieu de GS pour montrer que le trac se direntie du BE par sa capacit garantir la bande passante du trac. Les NoCs qui orent un trac GT utilisent gnralement des variantes du TDMA (Time Division Multiple Access) pour construire une connexion [21, 22]. Le TDMA consiste discrtiser le temps en priodes appeles slots de temps. Durant un slot de temps, la bande passante dun lien est rserve pour une communication. Les ressources du rseau sont ainsi partages temporellement entre les communications. La table de TDMA pour allouer les accs peut tre soit dans les routeurs, soit dans les NIs. En eet, le slot de temps durant lequel le paquet est entr dans le rseau, ainsi que son chemin, dterminent les slots de temps des liens que ce paquet va utiliser. Les slots de temps non utiliss par le trac GT peuvent tre mis disposition dun trac BE voluant sur un autre canal virtuel. Ceci permet de faire une meilleure utilisation des ressources et de bncier la fois du dterminisme dune commutation de circuit et de la exibilit dune commutation de paquets. Pour garantir le service, les auteurs de [23] proposent une alternative au TDMA qui consiste allouer individuellement les ls dun lien des connections direntes. Cette approche est appele SDM (Spatial Division Multiplexing). Les donnes sont srialises sur un nombre de ls proportionnel la bande passante alloue la communication. Cette approche est intressante et pourrait tre combine avec lapproche TDMA.

2.3 historique des nocs

15

2.2.9

La synchronisation du NoC

La distribution dun arbre dhorloge sur une puce de grande taille pose des problmes de synchronisation. De plus, lhorloge reprsente une part importante du routage et de la consommation. Il existe dirents types dapproches concernant la synchronisation dans les NoCs. Le NoC entirement synchrone a besoin dune horloge commune sur chacun des lments du NoC [22] [21]. Le NoC peut aussi fonctionner avec des lments synchrones qui schangent les donnes sur les liens de faon asynchrone ; Le NoC peut encore utiliser lapproche GALS (Globally Asynchronous Locally Synchronous) avec des lots synchrones qui schangent des donnes de faon asynchrone. Et enn, il existe le NoC entirement sans horloge [24]. La consommation de larbre dhorloge dun NoC synchrone peut reprsenter 54% de la consommation de puissance du NoC [25]. Un NoC sans horloge peut priori rduire sa consommation, cependant, la mise en uvre de lasynchronisme ncessite des mcanismes qui peuvent tre coteux en surface. lheure o la consommation statique croit par rapport la consommation dynamique, lintrt dun systme sans horloge nest pas vident et reste dmontrer. Dans le chapitre 6 nous nous intresserons cet aspect et prsenterons notre approche pour surmonter les problmes de synchronisation en proposant une approche intermdiaire.

2.3

Historique des NoCs

Nous prsentons lhistoire encore jeune des NoCs. Celle-ci permet de situer dans le temps larrive des dirents rseaux et travaux lis ce domaine [26]. Le NoC a pour origine les rseaux de multi-processeurs. Des rseaux comme le TRANSPUTER (TRANSistor + comPUTER) permettaient dj en 1983 de faire communiquer des processeurs pour raliser des machines parallles [27]. Les processeurs taient galement les routeurs, un processeur complet possdant quatre canaux dEntres/Sorties permettant de le relier aux autres. (2000) Pour parler de rseau sur puce, lun des pionniers a t le rseau SPIN du LIP6 qui tait nettement en avance sur son temps [12]. On a alors dmontr lintrt des NoCs dans les architectures SoCs de demain [8, 28, 7]. Les travaux portaient essentiellement sur des simulations (systemC, outil NS2 (Network Simulator) [29, 30]), bases sur des gnrateurs de tracs qui au mieux simulaient des traces de trac obtenues par simulation. Lattention tait essentiellement porte sur les topologies et les routeurs [31]. (2002) Ensuite les statistiques de bande passante et latence en fonction de la charge de communication ont laiss place des travaux visant trouver le moyen de garantir le trac [32, 22, 33] et dinterconnecter des ports dIPs au rseau. Ceci a donn lieu des travaux sur les interfaces rseau et les wrappers [34]. Le problme des horloges dans les circuits de grande taille a ensuite t considr [24, 35]. (2004) Des mthodes et outils daide la dcision (topologie, taille des FIFOs, ordonnancement des TDMAs) ont fait leur apparition pour permettre dalimenter

16

tat de lart

loutil ddi jusqualors qu la gnration du code VHDL du NoC [13, 36, 37, 38, 39, 40]. Le ot de conception du NoC a ainsi vu son niveau dabstraction slever. Nous voyons que les recherches sur les NoCs ont gravi les couches rseaux pour orir un niveau dabstraction de plus en plus haut. Lavenir soriente vers une interaction croissante entre le systme dexploitation et le NoC, avec des adaptations mutuelles du NoC et de la QoS de lapplication. Ceci suppose des aspects surveillance et reconguration du systme.

2.4

Exemple de NoCs et doutils pour les NoCs

Il existe un grand nombre de NoCs et il est impossible de tous les dtailler. Ils ont volu dans le mme temps o nous travaillions sur notre NoC. Dans cette section, nous dcrivons les NoCs qui nous semblent les plus reprsentatifs.

2.4.1

SPIN

Dvelopp par le laboratoire LIP6 en 2000 [41, 12], le rseau SPIN (pour Scalable Programmable Integrated Network) et son routeur RSPIN ont constitu la premire intgration complte dun rseau sur puce commutation de paquets. De plus, ce rseau a une topologie originale puisquil utilise une topologie en arbre largi quaternaire. Cette structure hirarchique permet de tirer parti de la localit et est scalable. Le routage des paquets dans le rseau peut tre dynamique ou statique dans le sens montant de larbre, et il est obligatoirement statique dans le sens descendant. Le routage dynamique permet de disposer de chemins alternatifs et ainsi de contourner des points de congestion, cependant, pour reconstituer le message, il est ncessaire de rordonnancer les paquets au niveau de la rception, du fait que les paquets nutilisent pas tous le mme chemin. Les interfaces rseau ralisent le contrle de ux de bout-en-bout par le passage de crdits dmission et le rordonnancement des paquets la rception dans le cas du routage dynamique. Ce dernier est ralis laide dun tampon circulaire et dun pointeur dcriture qui permettent de rorganiser les paquets dans le bon ordre. Le pointeur de lecture sarrte si le paquet requis nest pas arriv. Les paquets qui ne peuvent pas tre stocks dans le tampon circulaire par faute de place (le pointeur dcriture ayant atteint le pointeur de lecture) sont rexpdis temporairement dans le rseau en attendant que de la place soit faite. La taille du tampon circulaire de rception est un problme critique, car elle doit tre minimise pour des raisons de surface et de consommation, mais nanmoins susante pour limiter les dbordements. Enn, le SPIN dispose de wrappers VCI entre le rseau et les IPs qui permettent les conversions entre les deux protocoles de communication VCI et SPIN [34]. Le rseau SPIN est un rseau qui fait rfrence par son antriorit, cependant, ce rseau ne fournit pas de garantie en termes de latence et de bande passante pour lacheminement des paquets. En eet, sous une grande charge de communication, le rseau soure alors dune grande latence [42]. Il nest pas fait tat doutils destins aider le concepteur du rseau dans le cas de SPIN, cependant un modle systemC du rseau est disponible pour permettre des simulations rapides.

2.4 exemple de nocs et doutils pour les nocs

17

Le LIP6 travaille actuellement sur des drivs du SPIN, appels DSPIN [43] et ASPIN. Le DSPIN utilise une topologie non plus en arbre largi comme SPIN mais une grille 2D. Le routage est dtermin par la source et utilise la technique X-Y. Le ASPIN est un DSPIN avec des ports rseau asynchrones.

2.4.2

thereal

Philips Research a dvelopp un ot de conception complet autour de son rseau thereal. Leurs travaux ont volu en parallle des ntres et nous verrons que nous avons de nombreux points en commun. Ce rseau utilise le routage wormhole, la technique de routage street-sign et le routage par la source. Il utilise une horloge unique qui doit orir une notion de temps commune lensemble des lments du NoC. Le rseau thereal permet de garantir la bande passante dun trac [22, 33, 44]. Il utilise deux canaux virtuels, lun pour la classe de tracs garantie GT Guaranteed troughput, et lautre pour la classe BE (Best eort). Le trac GT est mis en uvre par lutilisation de tables TDMA dans les interfaces rseau (NI) pour autoriser lentre des paquets dans le rseau selon un squencement pr-ordonnanc an de garantir leur traverse sans se rencontrer (absence de contention dans le rseau). Le BE utilise le reste de la bande passante. Lquipe de recherche de Philips avait initialement mis ses tables TDMA dans les routeurs [22] au lieu de les mettre dans les NIs (il sagissait donc dune commutation de circuit), mais cette ide avait d tre abandonne car cette solution ncessitait trop de surface. thereal permet dutiliser des connexions paramtres (rservation de bande passante, latence borne) entre les IPs qui dsirent communiquer ensemble. lintrieur de cette connexion, la communication est faite par des transactions contenant des messages prdnis (Commande (lecture/criture), Donnes, etc.). De plus, ces connexions permettent des missions vers des rcepteurs multiples (multicast). Enn, des adaptateurs shell permettent la conversion du protocole de ce rseau vers les protocoles DTL et AXI. Rcemment, le groupe de recherche de Philips a dvelopp des mthodes et outils pour automatiser les tapes de son ot de conception [36]. Il ore ainsi un ot prenant comme contrainte la bande passante et la latence des communications et gnre la connexion des IPs au NoC, le routage (aectation des chemins aux communications) et laectation des slots de temps, ainsi que le dimensionnement des tailles des tampons. Enn, il gnre le code VHDL du NoC, ainsi que les chiers de conguration de celui-ci. Le ot de conception de thereal [45] est celui montr dans la gure 2.4. Pour faire concider les objectifs des phases de placement des IPs (mapping), de slection du chemin et dallocation des slots, les auteurs dans [45] proposent dunier ces phases de recherches par leur algorithme appel UMARS (Unied MApping,Routing and Slot allocation). Ils utilisent une topologie de NoC calcule priori. Leur originalit est de considrer lexistence de canaux de mapping virtuels reliant aux NIs du rseau, les IPs non encore places. Ainsi, lexploration de chemin slectionne non seulement le chemin dans le rseau, mais aussi le canal de mapping virtuel qui relie lIP une NI. Aprs cette slection, lassociation de lIP cette NI devient alors dnitive et les canaux de mapping virtuels reliant lIP considre aux autres NIs sont supprims.

18

tat de lart

Fig. 2.4 Le ot de conception de NoC de thereal Le mapping ralis ainsi suppose que les IPs sont interchangeables (compatibles en terme de tailles et de formes), or cest rarement compatible avec la ralit. De plus, des stratgies ont t dveloppes an de permettre dutiliser plusieurs cas dutilisation de lapplication sur un mme NoC [46]. Le ot de conception thereal a t appliqu avec succs sur un SoC pour la tlvision numrique [25]. Nous notons que la exibilit a un cot puisque larchitecture utilisant le NoC a une surface 4% plus importante et une consommation 12% suprieure la ralisation initiale qui utilise des liens ddis et quelques multiplexeurs.

2.4.3

QNoC

Le rseau QNoC (Electrical Engineering Department, Technion - Israel Institute of Technology) a pour caractristique de sparer les tracs en quatre classes et de les rpartir sur des canaux virtuels dirents avec un ordre de priorit [32, 47]. Ces classes de tracs sont ordonnes en fonction de leur nature : Signalisation : les messages urgents et les paquets courts qui sont de type contrle ou interruption. La plus haute priorit leur est donne pour leur garantir une courte latence ; Temps-rel : les communications ncessitant une garantie en bande passante et latence, tels que les ux audio ou vido. Cette classe de trac bncie dune grande bande passante ; Lecture/criture : les communications de smantique bus et les accs courts de la mmoire ou des registres ;

2.4 exemple de nocs et doutils pour les nocs

19

Transfert de gros bloc de donnes : les transferts du type DMA. Cette classe de trac a la plus faible priorit. Un ordonnancement premptif permet aux paquets appartenant un trac plus prioritaire dutiliser les ressources utilises jusque l par un trac moins prioritaire. De plus, QNoC autorise lutilisation de topologies en grille 2D retailles et contenant donc des irrgularits [15]. Le routage est dtermin par la source et utilise une technique X-Y amliore pour permettre le routage dans une grille 2D non rgulire. Enn, il peut fonctionner avec des changes synchrones ou asynchrones [48].

2.4.4

Arteris

Arteris est une jeune socit franaise. Elle propose depuis 2005 la premire solution commerciale pour concevoir des NoCs [49]. Son NoC est extrmement paramtrable et tire partie de la sparation des couches rseaux pour faciliter loptimisation de chacune dentre elles de faon indpendante. Il ny a priori pas de garantie de service en dehors de celle oerte par la simulation, il est cependant possible de favoriser une communication par rapport une autre selon une technique de priorit au sujet de laquelle nous navons pas dinformation. Le NoC peut tre synchrone ou bien utiliser une approche GALS avec des horloges msochrones. Il utilise le wormhole dans le domaine synchrone pour minimiser la latence et le store-and-forward quand il change de domaine dhorloge. Arteris utilise un protocole de transport propritaire appel NTTP (NoC Transaction and Transport Protocol) qui permet dutiliser les transactions requte/rponse et dintgrer les fonctionnalits traditionnelles des bus (adresse, transaction load/store, burst, bit de parit). Ceci lui permet dtre compatible avec un grand nombre dinterfaces standards (AMBA AHB, AMBA AXI, OCP 2.0). De plus, il permet de mixer sur un mme NoC des composants qui utilisent des interfaces direntes [50] Il est aussi possible dutiliser une unit de translation pour connecter des NoCs ayant des paquets de formats dirents. Lore dArteris consiste en la librairie Danube qui contient les IPs congurables de son NoC, ainsi que deux outils complmentaires, NoCExporer et NoCCompiler. NoCexplorer est un environnement capable de capturer les besoins en communications entre les blocs IP et permet au concepteur danalyser direntes topologies qui satisfassent les performances et le placement. Cette analyse repose uniquement sur la bande passante requise et nest pas prcise au niveau cycle. Loutil NoCcompiler utilise la topologie et les autres donnes gnres par NoCexplorer pour crer une base de donnes qui dcrit le NoC. Il permet au concepteur de slectionner les options voulues dont le format du paquet, les caractristiques des communications des blocs IP (types de burst) et les paramtres de chacun des lments du NoCs. Enn, il est capable de gnrer un modle systemC simulable prcis au niveau cycle, ou des descriptions Verilog, VHDL, au niveau RTL. La gure 2.5 montre loutil NoCCompiler. Enn, le Noc de Arteris sera intgr dans la plate-forme de dveloppement de CoWare [51]. La force dArteris est de proposer un produit adaptable et qui se fond parfaitement avec les outils de conception existants.

20

tat de lart

Fig. 2.5 Loutil NoCcompiler de Arteris Lengouement que Arteris rencontre avec bon nombre des leaders des outils de conception en lectronique montre lintrt que suscitent les NoCs.

2.4.5

Spidergon

STMicroelectronics a galement dvelopp un NoC appel STNoC utilisant une topologie baptise Spidergon qui consiste en une topologie en anneau dans laquelle sont ajouts des liens qui traversent lanneau en diagonale [52, 53]. Ce type de topologie rappelle la topologie en octogone de Octagon [31]. Ce NoC ne prsente pas dinnovation particulire, sinon sa topologie originale. Notons quen dbut danne 2006, STMicroelectronics a slectionn Arteris pour raliser les communications dans les SoCs de ses infrastructures sans l [54].

2.4.6

CHAIN

Le rseau CHAIN (Computer Science Department, The University of Manchester, UK ) possde une architecture entirement asynchrone [24]. Il utilise des liens insensibles la latence et un protocole double rails quatre phases. Il utilise la commutation de paquet et le routage par la source. Il manipule un trac BE. Labsence dhorloge lui permet de rduire sa consommation.

2.4.7

MANGO

Le rseau MANGO (Technical University of Denmark) est un NoC sans horloge[55]. Son architecture est donc entirement asynchrone, cependant, elle permet de satisfaire le trac GT en plus du classique BE. MANGO utilise un ordonnancement appel ALG (Asynchronous Latency Guarantee). La garantie est obtenue sous certaines conditions. Il faut en eet que le dlai maximum de transmission dun it soit connu et que lintervalle inter-its soit born. Cette approche est intressante, cependant, limplantation dun grand nombre de tracs garantir, se traduit par lajout de nombreux canaux

2.4 exemple de nocs et doutils pour les nocs

21

virtuels ce qui implique une augmentation importante du cot en surface au niveau des routeurs.

2.4.8

ANoC-FAUST

Le CEA-LETI propose un rseau appel ANoC (Asynchronous Network-on-Chip) qui sintgre sur une architecture appele FAUST (Flexible Architecture of Unied System for Telecom) dans le cadre du projet 4MORE [56, 57, 58]. Ce projet a pour but dorir une plate-forme ouverte pour les applications multimdia des terminaux mobiles de quatrime gnration (4-G). Le rseau est ici partag sur plusieurs circuits de la plate-forme de prototypage. Il se rpartit sur 2 FPGAs et deux circuits FAUST en technologie ASIC de 0.13m. Lapplication vise par le projet 4More est un dmonstrateur de modem MC-CDMA. Nous utiliserons cette application dans le chapitre 7.4 consacr aux exprimentations. Larchitecture de ANoC est base sur une topologie en grille 2-D. Elle utilise la commutation de paquet, la stratgie wormhole et le routage par la source (Adaptative Turn Model). Pour les communications, ANoC utilise une logique asynchrone QuasiDelay-Insensitive (QDI) 4 phases et un multi-rail. Il utilise deux canaux virtuels pour sparer les tracs. Ces tracs norent pas de garantie. Le bon fonctionnement est vri par les simulations. ANoC dispose dadaptateurs pour se connecter un bus AHB. Les modles de ce NoC sont en SystemC au niveau TLM (Transaction level modeling) et VHDL RTL.

2.4.9

xPIPES

Le rseau xPIPES [35] (Stanford University, USA et University of Bologna, Italy) est un rseau commutation de paquets utilisant la technique wormhole, avec un routage par la source (codage street-sign). La gure 2.6 montre le ot de conception dans lequel sintgrent ses outils [37].

Fig. 2.6 Les outils SUNMAP et xpipesCompiler du ot de conception de xPIPES partir dune simulation initiale, lapplication est dcrite au moyen dun graphe de tches. Ce graphe indique la bande passante requise par chaque communication entre les paires de tches. Chaque tche est assigne une IP. Les bandes passantes sont alors utilises par loutil SUNMAP [38, 39] pour gnrer une topologie pour le NoC. Il prend en considration la taille et le placement physique des IPs, pour placer

22

tat de lart

les liens, les routeurs et les NIs du NoC. Il teste plusieurs topologies et ralise une analyse de la surface et de la consommation du NoC. Il ajuste ses choix par une boucle itrative. Il supprime les liens et ports de routeurs non utiliss. Enn, il calcule les tailles de FIFOs ncessaires. partir de la bibliothque de composants et des paramtres choisis, loutil xpipesCompiler [40] ralise la gnration du code SystemC pour la simulation, ainsi que le code pour la synthse. Cest une approche intressante qui permet de crer une topologie de rseau qui considre le placement des lments sur le circuit.

2.5

Les solutions technologiques long terme

Pour satisfaire les besoins de performance futurs, de nouveaux moyens de communication sont envisags dans les SoCs. Ces moyens consistent utiliser lintgration verticale, les interconnexions optiques, les liaisons radio (RF), ou lutilisation de guides dondes [3]. La forme du circuit silicium est essentiellement 2D. Lutilisation de la troisime dimension dans le silicium permettrait en eet de rduire la distance des communications. Ctait un point fort du workshop NoC de DATE06 [59]. Les interconnexions optiques [60] sont une option possible pour raliser les communications globales sur les puces, alors que les communications locales continueraient utiliser linterconnexion mtallique classique. La dicult est dintgrer cette solution optique sur le circuit silicium. Les capacits dintgration rendent possible lutilisation de petits transmetteurrcepteur radio sur puce. Cette technologie sappelle RoC (Radio-on-Chip). Elle pourrait permettre de simplier le problme des communications entre des points loigns du circuit. De plus, les communications radio sont prometteuses pour raliser le test des circuits avant leur mise en botier. Les usines de fabrication de circuits lectroniques ralisent des tests sur les circuits avant leur mise en botier. Or, les connections physiques au circuit sur les plates formes de test ncessitent du temps et peuvent causer la destruction du circuit. Il est ainsi propos par [61] dutiliser des communications par liaisons sans l sur les SoCs pour envoyer les squences de tests et recevoir les rsultats. Enn, une alternative au RoC consiste transmettre les signaux RF en utilisant un guide dondes mtallique au lieu des antennes.

2.6

Conclusion

Le domaine de recherche des NoC est extrmement large [16]. Nous avons volu en mme temps que les autres NoCs de ltat de lart. Nous avons fait des choix qui se sont parfois rvls tre ceux adopts par lquipe de recherche de Philips qui a conu le NoC thereal. Notamment sur lutilisation dun TDMA. Nous nous direncions nanmoins deux par de nombreux aspects, par notre technique dallocation des rservations des slots TDMA (section 4.4), ainsi que par notre utilisation de multirservations pour les communications appartenant une mme clique dexclusion mutuelle (section 3.3.3). De plus, nous dbutons notre ot de conception un niveau

2.6 conclusion

23

dabstraction plus lev par notre technique de drivation des contraintes applicatives (section 4.3). Enn, nous proposons une technique dans le cadre de la scurit (chapitre 5), ainsi que des solutions permettant de saccommoder des problmes dhorloges (chapitre 6). Nous prsentons tous ces aspects dans les chapitres suivants.

Chapitre 3

Spider : Architecture du NoC, ot de conception et outil


3.1 Introduction

Un NoC performant et adaptable est ncessaire pour prendre en charge les dirents types de tracs, notamment le trac GT. Une des principales dicults est la matrise des paramtres permettant dobtenir le NoC appropri aux besoins de lapplication. En raison de la taille de lespace de conception (topologie, chemins, ordonnancement, etc.), il est illusoire de vouloir explorer toutes les solutions en fonction des dirents compromis possibles. Il est donc ncessaire de disposer de mthodologies et doutils pour assister le concepteur an de le guider dans ses choix et de laider concevoir le NoC adapt ses besoins. Ce chapitre prsente, dans un premier temps, larchitecture gnrale de notre NoC. Nous prsentons ses fonctionnalits, ainsi que ses composants de base, le routeur, linterface rseau et ladaptateur de protocole pour la connexion avec les bus des curs de processeurs ou IPs. Dans un second temps, ce chapitre prsente notre ot de conception. Enn, loutil de conception, Spider qui automatise ce ot, est prsent.

3.2
3.2.1

Architecture du NoC
Prsentation

Notre NoC utilise la commutation par paquets pour la exibilit quelle ore. De plus, il repose sur la stratgie de mmorisation wormhole pour son faible temps de traverse des routeurs et le faible cot en mmorisation dans ces derniers. Par dfaut, il est sans perte, en eet les paquets qui rencontrent une contention ne sont pas dtruits, mais attendent dans le rseau avant de pouvoir progresser. De plus, il permet lutilisation du contrle de ux de bout-en-bout pour sassurer, avant dmettre, quil y a de la place disponible dans la FIFO de destination. Enn, il est capable dassurer le service aux communications ayant une contrainte de temps rel (trac GT) grce lutilisation de la technique de rservation de bande passante par TDMA (Time Division Multiple Access).

25

26

spider : architecture du noc, flot de conception et outil

Un it contient 1 phit (un mot), et un slot de temps du TDMA contient 2 its ou phits.

3.2.2

Le routeur

Le nombre de ports de chaque routeur est paramtrable. Un routeur possde au minimum trois ports rseau, sinon il na pas lieu dtre. La mmorisation se fait par des FIFOs sur les ports dentre, avant le dcodage. La gure 3.1 nous montre la structure dun routeur qui possde 3 ports. Nous distinguons les dirents modules qui appliquent les direntes politiques. Le contrle de ux au niveau lien est ralis en entre et en sortie du routeur. La politique utilise est le crdit dmission [12]. Le module de routage dcode les instructions de routage de lentte du paquet et demande laccs larbitre du canal de sortie appropri. Les politiques de routage supportes sont le routage ordonn par dimensions X-Y, ainsi que le codage street-sign qui ore plus de libert. Le module arbitre dcide quel canal dentre obtiendra laccs au canal de sortie auquel cet arbitre appartient. Le switch ralise la commutation qui permet la connexion physique dun port dentre un port de sortie. En pratique, nous avons ralis le switch par des multiplexeurs. Nous avons jug inutile de permettre un paquet de ressortir par le mme canal que celui par lequel il est entr. Ainsi, nous simplions les arbitres et le switch.

Fig. 3.1 Architecture dun routeur Nous utilisons le terme canal au lieu de port, car ce routeur est capable de manipuler plusieurs canaux virtuels (VCs). Les tapes de dcodage de lentte, darbitrage et de commande du switch sont pipelines. De plus, nous utilisons les fronts montants et descendants de lhorloge. Nous obtenons ainsi une latence de travers de deux cycles et une cadence dun cycle.

3.2 architecture du noc

27

Nous avons tout de mme une limitation. Comme un entte ncessite deux cycles pour tre trait, alors que les mots du corps du paquet ncessitent un seul cycle, deux enttes qui se suivent un cycle dintervalle rompent le pipeline. Cest pour cette raison que pour le trac GT, nous avons choisi une taille de slot de temps dune largeur de deux cycles et que nous imposons aux NIs de nmettre les enttes des paquets que durant le premier cycle du slot de temps. Ainsi, la rupture de pipeline ne se produit jamais dans le cas du GT et le comportement des its des slots reste facilement prdictible. 3.2.2.1 Les canaux virtuels

Notre NoC supporte les canaux virtuels (VCs). La exibilit de larchitecture permet den spcier le nombre. Cependant il est prfrable dutiliser un nombre limit de canaux virtuels car ils ont un cot en surface et en vitesse [62]. Les canaux virtuels ont un ordre de priorit correspondant leur numro. Le premier canal virtuel est le plus prioritaire pour obtenir laccs au lien. Un canal virtuel nest candidat laccs dun port de sortie que sil a au minimum un it envoyer et quil possde des crdits pour mettre sur le lien. Le plus prioritaire des canaux virtuels candidats obtient laccs ce port. Un signal est alors envoy aux arbitres des canaux virtuels de priorit infrieure pour les geler. Un canal bncie soit dune classe de trac GT ou BE. Seul le premier canal peut bncier de la classe de trac GT car celle-ci ncessite le niveau le plus prioritaire. La bande passante est assure par la rservation de slots de temps (TDMA). Ainsi, nous pouvons proposer par exemple la rpartition suivante pour les tracs. Un trac de classe GT qui garantit le trac temps rel prdictible (bncie de la garantie de service par TDMA) ; Un trac de classe BE prioritaire pour les communications urgentes et courtes ; Un trac BE qui utilise les slots non utiliss pour le trac sans garantie de bande passante et de latence. Le tableau 3.1 nous montre le numro de canal virtuel, la classe de trac et la rgle applique pour chaque type de trac. Notons que le trac GT ncessite pour fonctionner une cohrence dans la rservation des slots le long de son chemin ; Le fait que le trac GT soit prioritaire sur les tracs qui voluent sur les autres canaux virtuels ne sut pas. En eet, il faut viter que les communications du type trac GT ne puissent se perturber entre elles. Ainsi, il est ncessaire de raliser de manire cohrente les rservations des slots le long des chemins des communications GT. La recherche de la solution ce problme fera lobjet de la section 4.4.
Trac Temps rel Message court et urgent Message sans garantie Priorit (numro du VC) 1 2 3 Classe GT BE prioritaire BE Rservation Rservation cohrente des slots conscutifs sur lensemble de son chemin Au minimum 1 slot libre sur chaque lien de son chemin Pas de rservation

Tab. 3.1 Rpartition des tracs sur les canaux virtuels

28

spider : architecture du noc, flot de conception et outil

Plus gnralement, nous utilisons seulement 2 VCs pour transporter les tracs GT et le BE. Le trac BE permet de tirer parti de la bande passante laisse libre par les slots non utiliss du trac GT. Le trac BE prioritaire peut tre envisag pour transporter des signaux de surveillance du rseau ou les paramtres de congurations du NoC. Cela vite de transporter ces informations sur dautres NoCs comme cela est fait dans [63], o trois NoCs sont requis pour transporter les messages, les contrles et les congurations. 3.2.2.2 La politique de contrle de ux au niveau lien

Nous utilisons une paire de liens unidirectionnels en sens opposs. Il sagit dune mthode classique qui vite de raliser un contrle daccs par jetons pour accder un lien bidirectionnel [64]. La gure 3.2 indique comment un paquet est transmis sur un lien unidirectionnel. Le signal valid permet de signaler que le mot du paquet prsent sur le lien est valide. Le contrle de ux au niveau lien (entre les routeurs ainsi quentre les NIs et les routeurs) se fait par crdit dmission. Lenvoi dun crdit est cod sur un seul bit. Comme nous utilisons plusieurs canaux virtuels, les bits ack_credit indiquent les crdits retourns pour chaque canal virtuel. Il y a un bit ack_credit daect chaque canal virtuel. Un niveau 1 sur un bit indique que la FIFO de ce canal virtuel dans le port du rcepteur sest vid dun mot. Lmetteur possde un compteur pour chacun des canaux virtuels qui lui permet de savoir combien de places sont disponibles dans la FIFO de ce canal virtuel dans le rcepteur. Il est initialis avec la valeur de la profondeur de la FIFO du rcepteur. Lmetteur dcrmente ce compteur de 1 quand il envoie un mot et lincrmente de 1 lorsquil reoit un crdit. Il ne peut plus mettre si le compteur atteint 0. Lintrt de cette technique est quelle permet de pipeliner par des registres lenvoi des mots sur le lien si ce dernier est long. Le trac GT ne ncessite pas de contrle de ux particulier, car grce au prordonnancement des rservations de slots de temps dans le cadre de la technique TDMA, il ne peut pas rencontrer de conit par construction. 3.2.2.3 La politique de routage et la topologie

Pour chaque canal virtuel, nous pouvons spcier la politique de routage. Notre NoC peut utiliser deux techniques de codage des instructions de routage, le routage ordonn par dimensions X-Y et le street-sign. Le protocole de routage ordonne par dimensions X-Y est couramment utilis dans la littrature. Il est adapt uniquement la topologie en grille 2D. La technique de codage des instructions Street-Sign nous permet dutiliser nimporte quel routage et dtre compatible avec les topologies irrgulires. 3.2.2.4 La politique darbitrage

Pour chaque canal virtuel, nous pouvons spcier la politique darbitrage. Notre NoC autorise dirents modles : Sans arbitrage, utilis dans le cas du trac GT uniquement puisque les conits sont rsolus en amont par le prordonnancement ; Avec priorit xe, ce qui est peu coteux ;

3.2 architecture du noc

29

priorit tournante (tourniquet ou round-robin) qui permet dviter les famines ; Selon une priorit xe dans un champ de lentte du paquet. En cas dgalit entre plusieurs paquets larbitrage priorit tournante est mis en uvre. Cette dernire politique darbitrage permet daecter un paquet un niveau de priorit qui peut tre fonction de limportance ou de lurgence des donnes quil transporte. Cette priorit est limite puisquelle ne permet pas un paquet plus prioritaire dinterrompre un paquet moins prioritaire qui est dj engag. Chaque technique darbitrage a une complexit dirente et donc un cot dirent en surface et en vitesse.

3.2.3

La structure du paquet

Fig. 3.2 La transmission dun paquet sur un lien unidirectionnel La gure 3.2 montre comment est cod un paquet. Il est compos de its. Chaque it contient plusieurs champs. Le champ VC indique sur quel canal virtuel ce paquet est transport. Cette information est prsente dans chaque it du paquet car le paquet peut se faire interrompre par un autre circulant sur un canal virtuel plus prioritaire. Lorsque sa communication reprend, ses its indiquent alors sur quel canal virtuel elle doit avoir lieu. En pratique, comme les paquets appartenant des canaux virtuels dirents sont stocks dans des FIFOs direntes dans les routeurs, le champ VC nest pas mmoris lors de lentre du paquet dans la FIFO et est recr lors de la sortie du paquet. Cela nous permet de raliser une conomie sur la largeur des FIFOs. Le champ tiquette est cod sur deux bits, comme prcis dans le tableau 3.2. Il permet dindiquer le dbut du paquet pour que le dcodeur du port dentre du routeur dcode lentte. Il indique aussi la n du paquet pour que larbitre du port de sortie du routeur libre laccs la n du passage de ce paquet.

30

spider : architecture du noc, flot de conception et outil tiquette Dbut Fin 1 0 0 0 0 1 1 1 Commentaire Entte de paquet Corps du paquet Queue de paquet Paquet de 1 it (entte et queue la fois)

Tab. 3.2 Le champ tiquette du it dun paquet Lentte du paquet contient des informations de routage destines aux routeurs, ainsi que des informations pour la NI de destination que nous verrons dans la section suivante. La gure 3.3 montre la manire dont les informations sont codes dans lentte du paquet. Les informations dans lentte du paquet sont : Crdit : Dans le cadre du contrle de ux de bout-en-bout, ce champ permet un consommateur de retourner des crdits dmission vers son producteur. ID du ExtraNiChannel de destination : Indique quel ExtraNiChannel de la NI adresse le paquet est destin (ceci sera expliqu dans la section suivante) ; Instructions de chemin : Contient les instructions de chemin qui sont utilises par les routeurs pour guider le paquet vers la NI de destination ; La largeur de bits consacre chacun de ces champs est paramtrable. Les champs crdits et ID du ExtraNiChannel de destination ncessitent quelques bits. La largeur du champ Instructions de chemin dpend de la technique de routage et de la longueur des chemins dans le rseau.

Fig. 3.3 Les champs dans lentte du paquet

3.2.4

Linterface rseau

Linterface rseau (NI) permet de relever le niveau dans les couches rseau pour passer au niveau adaptation rseau. Elle gre les messages. Nous utilisons des connections pour raliser les communications. Notre NI se distingue par sa capacit permettre la rservation dun slot par plusieurs communications. Ceci permet dexploiter ce que nous appelons les communications mutuellement exclusives. Ce point sera expliqu dans la section 3.3.3. De plus, notre NI nest pas limite deux canaux virtuels. Elle possde un seul port rseau dans notre implantation et possde un ou plusieurs ports supplmentaires appels NIports. Un NIport est destin connecter la NI avec un wrapper ou une IP. La gure 3.4 montre lexemple dune NI qui a deux ports NIports pour permettre la connexion avec deux wrappers ou deux IPs. Nous voyons quelle dispose de deux

3.2 architecture du noc

31

types de canaux (chanel) que nous appelons ExtraNIchannel et IntraNiChannels. Une connexion entre deux NIs se ralise par lassociation dun ExtraNIchannel de lune avec un lExtraNIchannel de lautre. Les IntraNIchannels permettent deux NIports dune mme NI de communiquer directement entre eux sans passer par le rseau. Le nombre dExtraNiChannels et de IntraNiChannels de chaque NIport de la NI est paramtrable avant sa synthse VHDL. Le NIport utilise un simple protocole du type FIFO (vide, pleine, lecture, criture) et une commande pour indiquer quelle FIFO est adresse. Lordonnanceur contrle le droulement des rservations dans le cas du trac GT et arbitre laccs des ExtraNiChannels au rseau en fonction de leur canal virtuel.

Fig. 3.4 Une NI avec deux ports NIports Notre NI peut manipuler un nombre gnrique de canaux virtuels. De plus, elle prend en charge le trac GT par TDMA. Rappelons que la taille dun slot de temps est de deux phits. Nous avons choisi cette valeur car elle correspond au temps de traverse de lentte dun paquet dans notre routeur. De plus, lentte dun paquet de trac GT ne peut tre envoy que pendant le premier phit dun slot rserv. Cest une taille plus petite que celle des slots de temps de thereal qui utilise des slots de 3 phits. Notre taille de slot plus petite nous permet davoir un dcoupage en slot plus n et donc moins de slot sous utiliss (certains paquets peuvent ne pas occuper tous les mots du slot). De plus, cela permet davoir des tables dont la rotation est plus rapide, ce qui rduit le dlai pour obtenir un slot rserv.

32 3.2.4.1

spider : architecture du noc, flot de conception et outil Les rservations des slots de temps dans les NIs

La technique de codage des slots rservs est la suivante. Nous disposons dune table des rservations de slots, ainsi que dune table des congurations des ExtraNIchannels. Le nombre dsir de rservations dans la table des rservations de slots est paramtrable et peut aller jusquau nombre de slots de la table TDMA. Nous avons fait le choix quune zone de rservation soit insquable dans la mesure du possible. En eet, il est plus ecace de crer un grand paquet plutt que plusieurs petits, car un paquet implique chaque fois un entte qui occupe de la bande passante. De plus, les zones de rservations sont contigues. Pour dnir la zone de rservation, seul le numro du dernier slot inclus dans la zone rserve est indiqu. Ainsi, la zone dbute juste aprs la n de la zone de rservation prcdente. Le champ ExtraNIchannel ID indique les ExtraNIchannels qui ont le droit dmettre durant ces slots (le droit dmission est cod par un bit 1). Un bit est associ chaque ExtraNIchannel (l ExtraNIchannel numro 0 correspond au bit de poids faible). Le tableau 3.3 montre un exemple de table de rservations. La table est de 16 slots. Il y a 8 zones de rservations. Ainsi, nous voyons sur lexemple que la premire rservation (0) inclut les slots 2 3 et autorise le ExtraNIchannel 0 mettre. La seconde rservation (1) va des slots 4 6 et autorise les ExtraNIchannel 0 ou 1 mettre. On note que la quatrime rservation (3) nautorise aucune mission (tous les bits sont 0). Rservation 0 1 2 3 4 5 6 7 Numro du dernier slot rserv 3 6 8 11 12 14 15 1 ExtraNIchannel ID 000001 000011 000010 000000 000100 100001 010001 001000

Tab. 3.3 Les rservations des slots de temps dans la table TDMA

3.2.4.2

La table de conguration des ExtraNIchannels

Chaque ExtraNIchannel peut tre congur indpendamment. Le tableau 3.4 nous montre un exemple de table de conguration des ExtraNIchannels. Chaque ExtraNIchannel possde les paramtres suivants : Le crdit dmission initial dont il dispose pour le contrle de ux de bout-enbout (il indique la place disponible dans la FIFO de rception de lExtraNIchannel de la NI distante vers laquelle ce ExtraNIchannel envoie des donnes) ; Le seuil denvoi des donnes. Il permet de ne pas envoyer les donnes si elles sont trop peu nombreuses pour justier lenvoi dun paquet. Au dessus de ce seuil elles peuvent tre envoyes. Le seuil denvoi des crdits. Au dessus de cette quantit de crdits il est justi de transmettre ce crdit.

3.2 architecture du noc

33

Le numro de canal virtuel sur lequel ses communications voluent. Les Instructions de chemin pour le routage au travers du NoC. LID du ExtraNiChannel de destination indique lExtraNIchannel de la NI distante auquel il sadresse.
ID du ExtraNIchannel 0 1 2 3 4 5 Crdit dmission initial 0 0 0 0 0 0 Seuil denvoi des donnes 0 0 0 0 0 0 Seuil denvoi des crdits 5 5 5 3 3 3 Numro de canal virtuel 0 1 0 2 2 0 Instructions de chemin 00101111110 00101010110 00101000010 00000101010 00101111110 10111010110 ID du ExtraNiChannel de destination 1 0 1 2 1 3

Tab. 3.4 La conguration des ExtraNIchannels

3.2.5
3.2.5.1

Adaptateur de protocole NoC-OPB


Prsentation

An de pouvoir connecter au NoC des lments qui utilisent un protocole dirent de celui oert par les NIports de la NI, il est ncessaire de disposer dun adaptateur de protocole appel aussi wrapper. Pour les besoins de nos exprimentations et la validation de nos concepts, nous avons mis en uvre des wrappers pour permettre des microprocesseurs MicroBlaze de communiquer au travers du NoC. Le MicroBlaze est un microprocesseur RISC que lon peut synthtiser sur les FPGAs Xilinx laide de loutil EDK. Ce microprocesseur utilise pour communiquer le bus OPB et des interfaces FSL (Fast Simplex Link). Une interface FSL est une interface point point dune largeur de 32 bits. Elle utilise un protocole du type FIFO. Le Microblaze possde 8 ports FSL matres et 8 ports FSL esclaves. Ces interfaces extrmement simples et rapides ont t utilises par les auteurs de [65, 66] pour raliser des communications entre plusieurs coprocesseurs et un Microblaze. Ce serait une faon simple de connecter le Microblaze au NIport de la NI, cependant, cest une solution particulire, elle nest pas gnrique. Nous avons prfr utiliser le bus OPB pour son mcanisme de type bus classique qui nous permet de connecter dautres composants que le Microblaze, tels que des contrleurs de RAM par exemple. Le bus OPB (On-chip Peripheral Bus) est lun des bus CoreConnect [10] conu par IBM pour ses microprocesseurs PowerPC. Il permet de lier plusieurs matres plusieurs esclaves. Ainsi, pour pouvoir raliser linterface entre un NIport de la NI et le bus OPB nous avons ralis deux wrappers, un wrapper matre et un wrapper esclave. Ceux-ci intgrent des lments appels IPIF qui sont fournis par loutil EDK de Xilinx et aident la connexion au bus OPB. Sur la gure 3.5, nous pouvons voir deux processeurs MicroBlazes connects chacun un bus OPB dirent. Un NoC ralise la communication entre les deux bus OPB au moyen de wrappers. La liaisons entre une NI et un wrapper est appele pap (pour point point).

34

spider : architecture du noc, flot de conception et outil

Le wrapper Matre (WRM) est un matre sur le bus OPB auquel il est connect et peut donc communiquer avec des composants esclaves (RAM, ROM) relis ce bus. Sur la gure 3.6, nous pouvons voir larchitecture dun wrapper Matre. Il possde deux FIFOs qui lui permettent de stocker le burst le plus long admissible entrant ou sortant. Ainsi, il nenvoie les donnes sur le bus OPB que lorsquil possde lintgralit du burst. De la mme faon, il ne fait la requte de lecture sur le bus OPB que quand il dispose de lespace susant pour le recevoir. Ceci permet dviter de conserver longtemps le bus. Le wrapper Esclave (WRS) est un esclave sur le bus OPB auquel il est connect et peut donc tre utilis par un microprocesseur pour communiquer avec le rseau. Sur la gure 3.7 nous pouvons voir larchitecture dun wrapper Esclave. Le wrapper Esclave possde des registres de statut qui permettent un composant matre sur le bus OPB de consulter le statut des FIFOs des channels (ExtraNIchannel ou IntraNIchannel) de la NI pour savoir si des donnes sont disponibles pour tre lues ou sil est possible dcrire. La partie basse de ladresse spcie par le composant matre sur le bus OPB permet de slectionner le channel sur lequel doit se raliser une lecture ou une criture.

Fig. 3.5 Deux microprocesseurs MicroBlaze et un contrleur de RAM connects par le NoC au travers de leurs bus OPB Il existe deux faons de concevoir ladressage des composants du systme (mapping mmoire), soit un adressage mmoire global, soit un adressage local chaque bus OPB. Nous avons choisi de raliser des adressages locaux. Cela nous permet davoir une solution plus exible. Ladressage sur chaque bus est ainsi indpendant. Notre mise en uvre permet dutiliser deux types distincts de transmissions, le simple envoi de message et les transactions de lecture/criture. Lenvoi de message

3.2 architecture du noc

35

Fig. 3.6 Le wrapper matre est utilis pour faire communiquer ensemble deux composants matres. Ce systme fonctionne comme une boite aux lettres, les messages sont dposs dans les wrappers esclaves. Les transactions sont elles inities par un composant matre qui envoie une requte un composant esclave. Pour raliser une transaction de lecture ou dcriture au travers du NoC, le MicroBlaze ralise une criture dans le wrapper esclave. La partie basse de ladresse slectionne le channel utiliser. Le contenu de lcriture consiste en une requte de lecture ou dcriture. Celle-ci sera transporte en tant que message dans un ou plusieurs paquets pour que le wrapper matre puisse raliser cette requte sur le bus auquel il est connect. Le format de codage de ces informations pour une requte de lecture ou dcriture est spci dans les tableaux 3.5 et 3.6 Le wrapper matre a ainsi besoin de savoir sil doit raliser une requte de lecture ou dcriture, le nombre de mots lire ou crire et ladresse laquelle cette requte doit tre adresse sur le bus OPB. Ladresse indique ladresse o se trouve lesclave sur le bus distant et ladresse locale vise dans ce composant.
W/R = 0 adresse sur le bus OPB nombre de mots du burst

Tab. 3.5 Requte de lecture


W/R = 1 adresse sur le bus OPB donne sur 32 bits donne sur 32 bits nombre de mots du burst

Tab. 3.6 Requte dcriture

36

spider : architecture du noc, flot de conception et outil

Fig. 3.7 Le wrapper esclave Il est ncessaire dempcher le MicroBlaze denvoyer des donnes sur le wrapper esclaves lorsque la FIFO du channel dmission slectionne dans la NI est pleine. De la mme manire, il ne faut pas que le MicroBlaze puisse faire des demandes de lecture alors que celles-ci ne peuvent pas tre satisfaite. De plus, nous voulons permettre au MicroBlaze de raliser des critures ou des lectures en continu sans avoir vrier continuellement le statut des FIFOs dans le wrapper esclave, pour savoir si la FIFO dmission est pleine ou si la FIFO de rception quil utilise est vide. Pour ce faire, les registres de statuts de lesclave indiquent galement si les FIFOs dmissions sont presque pleines et si les FIFOs de rceptions sont presque vides. Ainsi, la valeur qui xe le presque permet au MicroBlaze de raliser une srie de lecture/criture dun nombre gal cette valeur sans vrier continuellement sil a atteint la limite de la FIFO (vide ou pleine). Il doit cependant faire cette vrication lorsque la FIFO est entre presque vide et vide ou presque pleine et pleine. Nous travaillons actuellement sur une nouvelle version du wrapper qui au lieu dindiquer vide, presque vide, pleine et presque pleine, indiquera la valeur de la capacit libre/occupe dans les FIFOs dont le MicroBlaze dsire connatre le contenu. Ceci rduira au maximum la consultation du statut des FIFOs. Les interruptions misent par le wrapper esclave vers le MicroBlaze signaleront uniquement le passage dune FIFO de rception de vide non vide, et le passage dune FIFO dmission de pleine non pleine. 3.2.5.2 Avertir le microprocesseur

Il y a deux solutions pour avertir le processeur dun changement de statut des FIFOs dans le wrapper esclave, le polling et linterruption. Dans le cas du polling, le microprocesseur doit aller interroger priodiquement les registres de statut dans le wrapper esclave. Cette solution est coteuse en temps et en consommation pour le microprocesseur et le bus. Dans le cas de linterruption, le microprocesseur reoit une

3.2 architecture du noc

37

interruption uniquement lorsque le statut a chang sur le wrapper esclave. La routine dinterruption lui fait alors raliser une lecture du nouveau statut sur lesclave. Nous avons choisi cette dernire solution, plus simple. 3.2.5.3 Chronogrammes

Nous montrons les trois types de transmissions sur trois chronogrammes. Deux mots d1 et d2 sont transports. Nous utilisons les notations suivantes pour dcrire les changes : (Rc+S) : Le MicroBlaze ralise une lecture sur le bus ladresse du registre de statut des FIFOs dans le wrapper esclave. (Rc+D) : Le MicroBlaze ralise une lecture sur le bus ladresse dun channel du wrapper esclave lire une ou des donne(s). (Wc+D) : Le MicroBlaze ralise une criture sur le bus ladresse dun channel du wrapper esclave pour transmettre une ou des donnes. (Wc+rqL) : Le MicroBlaze ralise une criture sur le bus ladresse dun channel du wrapper esclave pour transmettre une requte dcriture. (Wc+rqE) : Le MicroBlaze ralise une criture sur le bus ladresse dun channel du wrapper esclave pour transmettre une requte de lecture. (R+D) : Le wrapper matre applique la requte de lecture sur le bus OPB2. (W+D) : Le wrapper matre applique la requte dcriture sur le bus OPB2. La gure 3.8 montre une transaction dcriture depuis le MicroBlaze1 situ sur le bus OPB1 destination dun contrleur de RAM situ sur le bus OPB2.

Fig. 3.8 criture au travers du NoC et des deux bus OPB La gure 3.9 montre une transaction de lecture faite par le MicroBlaze1 situ sur le bus OPB1 destination dun contrleur de RAM situ sur le bus OPB2. La gure 3.10 montre un change de message dun MicroBlaze1 situ sur le bus OPB1 destination dun MicroBlaze2 situ sur le bus OPB2.

38

spider : architecture du noc, flot de conception et outil

Fig. 3.9 Lecture au travers du NoC et des deux bus OPB 3.2.5.4 Couche Logicielle

Nous avons dvelopp des routines spciques en C qui permettent au MicroBlaze de dialoguer avec son wrapper esclave et de transmettre des requtes au wrapper matre distant. Le MicroBlaze peut ainsi : Consulter les registres de statuts du wrapper esclave (Rc+S). Raliser au travers du NoC une requte de lecture ou dcriture sur un composant situ sur un autre bus OPB (Wc+rqL) ou (Wc+rqE). Raliser une lecture/criture sur lun des channels (ExtraNIchannel ou IntraNIchannel) du wrapper esclave (Rc+D) ou (Wc+D). Les commandes sont : (Rc+S) : Lecture du registre de statut qui indique ltat vide ou presque vide des FIFOs de lecture et ltat plein ou presque plein des FIFOs dcriture du wrapper esclave : extern int WRAPPER_S_Read_Statut(BaseAddress) ; (Wc+rqL) : Requte de lecture au travers du NoC : extern void Wrapper_S_Read_(int BaseAddress, int channel, int remoteAddress, int *Data, int n) ;

3.2 architecture du noc

39

Fig. 3.10 Envoi dun message au travers du NoC et des deux bus OPB (Wc+rqE) : Requte dcriture au travers du NoC : extern void Wrapper_S_Write_BRAM(int BaseAddress, int channel, int remoteAddress, int *Data, int n) ; (Rc+D) : Lecture de donnes dans lun des canaux (EXtraNIchannel ou IntraNIchannel) du wrapper esclave : extern void Wrapper_S_Recvn(int BaseAddress, int channel, int *Data, int n) ; (Wc+D) : criture de donnes dans lun des canaux (EXtraNIchannel ou IntraNIchannel) du wrapper esclave : extern void Wrapper_S_Sendn(int BaseAddress, int channel, int *Data, int n) ; Les attributs de ces commandes sont les suivants : BaseAddress est ladresse du wrapper que le MicroBlaze adresse sur son bus OPB. channel est le numro du channel (EXtraNIchannel ou IntraNIchannel) que le MicroBlaze adresse dans la NI de ce wrapper. remoteAddress est ladresse que devra utiliser le wrapper matre pour raliser la transaction sur le bus auquel il est connect. Data est la donne transporte. n est le nombre de mots de donnes changs.

3.2.6

Conclusion

Nous disposons dune architecture complte, avec des routeurs, des interfaces et des wrappers OPB. De plus, cette architecture ore de nombreux paramtres :

40

spider : architecture du noc, flot de conception et outil

nombre de canaux virtuels ; technique darbitrage de routage et de garantie de service sur chaque canal virtuel ; largeur des donnes en nombre de bits ; nombre de ports de chaque routeur, ce qui permet de dcrire toutes les topologies ; nombre de NIports de chaque NI ainsi que le nombre dExtraNIchannels ; choix des chemins ; choix des slots de temps pour les communications du trac GT ; profondeur de chaque FIFO dans les routeurs et les NIs. utilisation ou pas du contrle de ux de bout-en-bout. Nous voyons quil est ncessaire de procder avec mthode pour raliser ces choix. Cest lobjet de la section suivante que dexpliquer le ot de conception associ.

3.3
3.3.1

Le ot de conception du NoC
Introduction

Un NoC doit tre adapt aux besoins requis. Or, un NoC ore beaucoup de paramtres (topologie, frquence dhorloge, mmorisation, stratgies de routage, arbitrage, contrle de ux, etc.). De plus, il faut dterminer les chemins que les paquets doivent emprunter. Le choix des paramtres dun NoC est un problme trs complexe. La mthode retenue est donc une heuristique et sappuie sur un ordre de choix avec un impact minimum. Les choix sont raliss des moins contraignants aux plus contraignants. Lordre des dcisions dans le ot est donc important. Nous allons dtailler les solutions que nous proposons ainsi que le ot que nous avons mis en uvre. Nous nous intresserons principalement au trac GT car cest celui qui prsente la plus grande dicult puisquil doit permettre de respecter des contraintes de temps rel.

3.3.2

Considration de la taille des FIFOs

Le cot du NoC est principalement domin par la taille des FIFOs, si bien que leur minimisation doit tre une priorit chacune des tapes de la conception du NoC. Le cot en FIFO dans les NIs est particulirement important lorsque des techniques visant garantir le service sont intgres. Cependant, cette observation ncessite dtre pese car nous observons que lutilisation du TDMA pour obtenir un trac GT permet dune part de rduire au minimum la profondeur des FIFO dans les routeurs puisquaucun conit ne peut avoir lieu entre les paquets ; mais dautre part, il implique un cot important en FIFO dans les NIs. Les FIFOs dans les NIs ont deux rles. Le premier est un rle de dcouplage entre le NoC et lIP connecte (productrice ou consommatrice). Le second est de cacher le voyage de retour du crdit dmission. La profondeur de FIFO requise pour le dcouplage est gale au nombre de mots rservs pour cette communication dans un tour de table de TDMA. La FIFO charge de masquer le voyage de retour du crdit dmission (round trip buer) doit avoir une profondeur gale ou suprieure au nombre de mots maximum que le producteur a besoin denvoyer avant de rcuprer des crdits, de sorte que

3.3 le flot de conception du noc

41

la contrainte de bande passante soit garantie. Cela dpend du temps de travers du rseau dans les deux sens entre le producteur et le consommateur. Ainsi, la taille de la table TDMA et la longueur des chemins sont des facteurs qui impactent le cot en FIFO et par consquent la surface et la consommation dnergie. Le problme du dimensionnement de la taille des FIFOs des NIs dans le contexte dun TDMA a t trait par les auteurs de [67, 68]. Les tailles de FIFOs ncessaires sont calcules automatiquement par notre outil la n du ot de conception, juste avant la gnration du code VHDL.

3.3.3
3.3.3.1

Les communications mutuellement exclusives


Dnition de lexclusion mutuelle et de ses rgles

Lexclusion mutuelle (ME pour Mutual Exclusion) de certaines communications permet de mutualiser les ressources quelles utilisent et donc daugmenter les chances de trouver une solution dallocation des chemins dans le rseau. Nous dnissons deux types dexclusions mutuelles dans le contexte des NoCs : Fortes : Les communications Ci et Cj sont fortement exclusives si les donnes de Ci (respectivement Cj ) sont entirement consommes avant lmission des donnes de Cj (respectivement Ci ). Au niveau du NoC, cela signie que les crdits dmissions sont totalement retourns et que la FIFO de rception est disponible. Faibles : Les communications Ci et Cj sont faiblement exclusives si elles ne peuvent pas se chevaucher dans le temps, cependant, cela ne garantie pas que les donnes de Ci (respectivement Cj ) soient entirement consommes avant lmission des donnes de Cj (respectivement Ci ). Dans les deux cas, ces communications ME peuvent rserver les mmes ressources de communication des slots de temps identiques et ainsi faire une meilleure utilisation des liens, conduisant une meilleure utilisation du NoC (gure 3.11). Les communications ayant des exclusions mutuelles sont spcies par le concepteur durant la premire tape du ot de conception et automatiquement organises en cliques durant la seconde tape, avant le dimensionnement de la table TDMA. Une mme communication peut appartenir plusieurs cliques. Durant lallocation des chemins, la rgle suivante est applique : Plusieurs communications ne peuvent rserver un mme lien durant un mme slot de temps que si elles appartiennent au moins une clique de ME commune. 3.3.3.2 La gestion particulire des crdits dmission dans le cas des exclusions mutuelles

Le contrle de ux de bout-en-bout se fait par la technique des crdits dmission. En prsence de communications mutuellement exclusives, la FIFO round trip buer [68] dans la NI de destination peut tre partage par les communications mutuellement exclusives. Cependant, des compteurs de crdits distincts doivent tre utiliss quand des exclusions mutuelles faibles sont considres. La gure 3.12 nous montre le partage de lutilisation de la FIFO de rception par deux producteurs dont les communications sont mutuellement exclusives.

42

spider : architecture du noc, flot de conception et outil

Fig. 3.11 Rservations multiples de slots de temps sur les liens par des communications mutuellement exclusives

Fig. 3.12 Partage de la FIFO de rception et utilisation de compteurs de crdits distincts pour des communications faiblement mutuellement exclusives Lutilisation des exclusions mutuelles permet de mieux utiliser les ressources. Par exemple, si nous considrons des communications mutuellement exclusives entre un processeur et trois mmoires, RAM1, RAM2 et RAM3 avec des contraintes de bande passante BW1, BW2, BW3 respectivement. Avec lapproche dthereal [22], la bande passante requise pour satisfaire ces trois communications serait la somme de ces trois bandes passantes (BW1 + BW2 + BW3). De plus, des fentres denvoi distinctes seraient ncessaires dans la table de slots du TDMA. Lutilisation de cas dutilisation [69, 25] permettrait dutiliser des congurations distinctes pour chaque communication, mais la transition dun cas dutilisation un autre impliquerait une perte de temps pour recongurer les tables TDMA des NIs. Avec une approche considrant les exclusions mutuelles entre les communications, la bande passante requise est infrieure leur somme. Elle peut en eet tre rduite pour atteindre la valeur de la plus grande bande passante des trois. De plus, nous pouvons utiliser des slots en commun pour ces communications, ce qui permet de rduire la taille de la table de TDMA. La dnition de communications fortement mutuellement exclusives peut tre considre comme une alternative lapproche par cas dutilisation. Avec notre ap-

3.3 le flot de conception du noc

43

proche, les communications des dirents cas dutilisations peuvent tre vues comme mutuellement exclusives et places simultanment.

3.3.4

Prsentation de notre ot de conception

Fig. 3.13 Le ot Notre ot de conception est illustr sur la gure 3.13. Il se compose des tapes suivantes : 1) tape de spcication La premire tape est une tape de spcication. Le concepteur doit alors dcrire les spcications de lapplication quil dsire implanter et faire un certain nombre de choix pour les paramtres du NoC. Ainsi, le concepteur renseigne un graphe reprsentant les tches et les communications de son application. Il indique la contrainte de bande passante (contrainte temps rel) que le systme devra satisfaire. Ce point sera dtaill dans le chapitre 4. Le concepteur signale de plus les cliques de communications mutuellement exclusives. De plus, il indique ses choix en terme de canaux virtuels, de service GT ou BE, de politique de routage, darbitrage et de contrle de ux. Il xe

44

spider : architecture du noc, flot de conception et outil

la topologie du NoC et lallocation des ports des IPs avec les NIs (mapping). Cette tape nest pas automatise car nous considrons que la connexion des IPs au NoC et donc leur placement ne peut pas tre faite sans la connaissance de leurs formes et de leurs tailles. Trop souvent, les outils qui ralisent le placement des IPs dans le NoC, considrent les IPs comme tant interchangeables en dpit des dirences de tailles de celles-ci et des contraintes physiques des interfaces du SoC [70]. Nous notons tout de mme que les auteurs de [38, 39] proposent une solution qui prend en compte ces aspects. 2) Drivation automatique des contraintes de communication Cette tape automatise permet dextraire les contraintes des communications partir de la description de lapplication. Elle vrie des rgles pour dterminer les contraintes des communications. Cette tape sera dtaille dans la section 4.3. 3) Dimensionnement automatique de la taille de la table TDMA Nous cherchons minimiser la taille de la table TDMA tout en respectant les contraintes de bande passante des communications. Cette tape permet dobtenir pour chaque communication, le nombre de slots de temps rserver et la contrainte sur la longueur du chemin. Ce point sera dtaill dans le chapitre 4. 4) Exploration et allocation automatique des chemins spatio-temporels dans le TDMA Cette tape explore les chemins dans la topologie en tenant compte de la notion de slots propre lutilisation du TDMA. Elle vise trouver pour chaque communication GT une solution de routage respectant ses contraintes de latence et de bande passante (rgle de cadence). Ce point sera galement dtaill dans le chapitre 4. Nous obtenons alors la spcication fonctionnelle complte du NoC pour laquelle les communications GT ont un chemin rserv pour des slots de temps donns. De plus, la profondeur de chacune des FIFOs est dtermine. 5) Gnration automatique du code VHDL du NoC Enn, le code VHDL RTL pour la synthse logique du NoC (NIs, Routeurs, Table dinstruction de chemin) est gnr. De plus, notons que dans le cas de lutilisation du MicroBlaze, nous fournissons galement le code C qui permet dutiliser des routines daccs avec le NoC.

3.4
3.4.1

Loutil de CAO Spider


Motivation

Loutil Spider rassemble et met en uvre les concepts exposs dans ce mmoire. Il nous a permis dautomatiser les tches fastidieuses et ainsi de gagner en productivit en terme de conception de NoC. De plus, cet outil est un environnement ouvert pour lexploration de nouvelles pistes. Enn, celui-ci nous permet de disposer dun dmonstrateur, ce qui est un lment indispensable du point de vue dissmination. La ralisation dun tel outil ncessite de formaliser les lments du problme et require de la mthode. Sa conception a constitu une part importante du temps consacr cette thse. En eet, il a t ncessaire de formaliser le modle du NoC, coder le VHDL des composants de celui-ci de faon ce quil soit exible, coder le gnrateur de code VHDL, coder loutil qui ralise les dcisions et les transformations

3.4 loutil de cao spider

45

qui alimentent ce dernier, et enn, valider le bon fonctionnement de lensemble sur une plate-forme FPGA.

3.4.2

Caractristiques, performances

Une premire version en langage PHP [71, 62] a t ralise en 2004, elle ne traitait que la gnration du code VHDL du NoC avec ses routeurs, mais sans les Network Interfaces et sans les adaptateurs de protocole. Loutil a ensuite t dvelopp en Java pour disposer de tous les lments et toutes les fonctionnalits qui seront dcrites ciaprs. Lutilisation dune approche objet est cruciale car elle est particulirement adapte la modlisation de notre outil qui doit tre volutif. Le langage Java a t choisi pour sa simplicit programmer, pour sa capacit dvolution et le fait quil soit portable (multi-plate-formes). Le format dchange choisi est le XML (eXtensible Markup Language). Cest un format dchange standard et facile comprendre car humainement lisible. Il peut tre dit par un simple diteur ou dans des environnements XML. De plus, pour chacun des modles de description XML que nous manipulons, nous avons dni un document type appel DTD (Document Type Denition). Celui-ci permet de dnir la grammaire permettant de vrier la validit du document XML. Nous vrions ainsi que nos chiers XML sont non seulement conformes (respect exact des rgles de base de la norme XML), mais galement valides (conforme la grammaire que nous avons dnie).

3.4.3

Modlisation dans Spider

Fig. 3.14 Relations entre les objets qui modlisent le systme

46

spider : architecture du noc, flot de conception et outil

La gure 3.14 montre de faon simplie les relations entre les objets principaux qui modlisent le systme. Ce modle sinspire de UML. Les attributs des objets ne sont pas prciss, seules les relations sont indiques. Le systme se compose dune application et dune architecture. Lobjectif est de satisfaire les contraintes de lapplication sur larchitecture. Une application peut possder plusieurs cas dutilisation ou modes de fonctionnement. Un cas dutilisation dnit les communications qui lui sont propres. Deux ports dIP (IPports) sont associs chaque communication. Notre reprsentation permet de dcrire plusieurs cas dutilisation pour une application, mais pour le moment, nous nen manipulons quun seul. Une architecture est compose dun ou plusieurs NoCs. Chaque NoC est compos de composants qui sont soit des routeurs soit des NIs. Chaque composant a des ports rseau NetworkPort. Le NoC est galement compos de liens qui connectent une paire de NetworkPort. Le cluster associe des IPports avec les NIports dune NI. La gure 3.15 montre la faon dont les contraintes de bande passante et de latence des communications dun cas dutilisation peuvent tre importes dans loutil sous la forme dun chier Excel. De plus, il est possible de spcier le canal virtuel sur lequel chacune de ces communications voluera. Si une communication spcie un canal virtuel qui assure le trac GT, alors la communication bnciera de ce service.

Fig. 3.15 La spcication des communications dans le chier Excel La gure 3.16 montre un exemple de chier XML qui dcrit prcisment une architecture. Nous retrouvons la reprsentation de la gure 3.14. Cest une description hirarchique. Ainsi, elle permet de distribuer facilement les paramtres gnriques du NoC tous ses composants. Pour chaque NoC, ses canaux virtuels sont dcrits et ordonns selon leur ordre de priorit. Pour chacun de ces canaux virtuels sont prciss les politiques darbitrage, de routage et de contrle de ux ainsi que le type de trac GT ou BE. Un minimum dun canal virtuel est requis. Les composants (qui sont soit des routeurs soit des NIs) ainsi que leurs ports rseau, sont galement dcrient. Enn, sont dnis les liens qui par leurs extrmits relient les ports rseaux des composants. Il est possible dassocier plusieurs ports dIPs (IPport) avec une mme NI. Un chier au format XML du type cluster permet de dnir ces associations entre les IPports et les NIs. De plus, il existe des chiers XML qui dcrivent les cliques des communications mutuellement exclusives, ainsi que des niveaux intermdiaires de la description du NoC.

3.4 loutil de cao spider

47

Fig. 3.16 La description de larchitecture du NoC

3.4.4

Reprsentation du ot de conception dans Spider

Le programme de cet outil possde des modles qui dcrivent ce que sont un NoC, un routeur, une NI, une communication, etc. Il possde aussi des modules. Ces modules

48

spider : architecture du noc, flot de conception et outil

sont de trois types : importation, exportation et transformation. Ils permettent lutilisateur de rentrer ses spcications architecturales et applicatives, de raliser les transformations qui vont raliser des dcisions selon des paramtres, et enn de sauvegarder les rsultats de ces transformations (conguration, architecture du NoC enrichie, code VHDL du NoC) De plus, il est possible dajouter facilement de nouveaux modules.

3.4.5

tapes du ot de loutil Spider

Les principales tapes sont les suivantes : saisie/importation des contraintes de lapplication ; gnration ou importation dune architecture de NoC ; connexion des IPs avec les NIs (mapping) dnie par des clusters ; dimensionnement de la table TDMA ; aectation du nombre de slots chaque communication ; exploration et aection des chemins et des fentres denvoi (routage spatiotemporel) ; dimensionnement des FIFOs ; gnration des congurations ; gnration du code VHDL. De plus, lintgration du NoC dans lenvironnement EDK est facilit. En eet, les chiers VHDL ainsi que des chiers spciques sont crs de manire permettre lutilisateur dajouter le NoC en tant que simple bus par un simple copier-coller de ces chiers dans la bibliothque approprie.

3.4.6

Les commandes de loutil Spider

Les commandes de loutil Spider sont entres sous forme darguments. Il est ainsi facile dutiliser ces commandes sous forme de script, de les sauvegarder et de les rutiliser. Ceci permet de gagner du temps pour entrer les paramtres. Linterface utilisateur pour spcier les paramtres du NoC se fait laide dun diteur XML. Il est possible de gnrer une topologie rgulire de NoC, dexporter cette topologie en format XML, de la personnaliser et de la rimporter. Loutil propose la gnration automatique de topologies en grille 2D avec des paramtres tels que le nombre maximum de ports des routeurs, nombre de lignes, nombre de colonnes, avec ou sans utilisation des bords extrieurs de la grille. Des NIs sont connectes aux ports locaux des routeurs et sur les bords extrieurs du NoC si cela est spci. La gure 3.17 montre un exemple de script pour excuter le ot. Ces commandes ralisent les actions suivantes : -I_RWEXCEL leName : Importe au format Excel les contraintes de lecture et criture des communications de lapplication ; -I_HW leName : Importe au forme XML la description matrielle du NoC ; -T_RWFR Yes/No : Transformation des communications lecture et criture en connections Forward et Reverse. Yes/No pour activer/dsactiver le contrle de ux de bout-en-bout ; -T_CIPPORT : Cre la liste des IpPorts depuis la liste des communications lecture et criture

3.4 loutil de cao spider -I_RWEXCEL .\project\tracking\tracking03.xls -I_HW .\project\tracking\trackingTopology.xml -T_RWFR Yes -T_CIPPORT -I_CLUSTCONST .\project\tracking\IpPortClusterConstraint.xml -T_CLUST_B -T_SLOTPART_A Yes 1 -T_UCOMM -O_CLUST .\project\tracking\exportCluster.xml -T_CARC -T_PALLOC 7 3 1 1 0 0 0 -T\_BUFF Yes -O_USLOT .\project\tracking\unidirComm.xml -O_HW .\project\tracking\exportTopology.xml -O_VHDL .\project\tracking\ x -help Fig. 3.17 Exemple de script

49

-I_CLUSTCONST leName : Impose des IpPorts des contraintes de regroupement en clusters et association une NI. -T_CLUST_B : Avant le partitionnement en slots. Regroupement des IpPorts dans un Cluster. Chaque IpPort sera associ une NI dans le NoC. -T_SLOTPART_A Yes/No initialSlotTableSize : Aprs le regroupement en clusters. Le partitionnement en slots calcule en nombre de slots les contraintes des communications unidirectionnelles entre les IpPorts situs dans des clusters dirents. Yes/No pour activer/dsactiver le contrle de ux de bout-en-bout. initialSlotTableSize = taille initiale de la table de slot pour dbuter la recherche de la taille de la table TDMA adapte ; -T_UCOMM : Transformation des connections Forward et Reverse en communications unidirectionnelles -O_CLUST leName : Sauvegarde les clusters dIpPort ; -T_CARC : Cre un graphe orient de la topologie spatio-temporelle, avec les arcs unidirectionnels correspondants aux liens entre les composants dans le rseau et les nuds correspondants aux composants ; -T_PALLOC schedulingStrategy : Dcide les chemins des communications dans la topologie spatio-temporelle ; -T_BUFF Yes/No : Dimensionne la profondeur des FIFOs dans les NIs. Yes/No pour activer/dsactiver le contrle de ux de bout-en-bout ; -O_USLOT leName : Sauvegarde au format XML les bandes passantes et latences des communications unidirectionnelles en unit de slots ; -O_HW leName : Sauvegarde au format XML la conguration matrielle du NoC ;

50

spider : architecture du noc, flot de conception et outil -O_VHDL leName directory libraryName : Gnre le code VHDL RTL. Si libraryName = x alors le nom de la librairie utilis est celui du NoC suivi de son numro de version ; -help : Ache laide de loutil. La commande -help ache toutes les commandes et laide relative chacune. Il existe dautres commandes et il est possible den rajouter de nouvelles.

3.4.7

Linterface graphique de Spider

An de rendre plus facile lutilisation de loutil Spider, une interface graphique a t dveloppe. Celle-ci guide lutilisateur dans le ot de conception en lui orant une meilleure visibilit des actions possibles. Elle permet dviter des erreurs dans ldition des commandes. De plus, une aide est disponible. Enn, elle permet de sauvegarder des squences de commandes pour pouvoir les rejouer. La gure 3.18 montre une capture dcran de linterface graphique de Spider.

Fig. 3.18 Linterface graphique de Spider

3.4.8

Spider

en chires

A titre indicatif, le programme java de Spider comporte environs 20.000 lignes de codes. Il gnre du code XML et VHDL. Par exemple, la gnration dun simple NoC congur avec un seul canal virtuel et compos dun routeur de trois ports et de trois NIs, se traduit par la production de 9432 lignes de code VHDL.

3.4 loutil de cao spider

51

3.4.9

Conclusion

Dans ce chapitre nous avons prsenter notre outil. Il est capable de modliser le NoC, de raliser des dcisions pour le paramtrer et de gnrer son code VHDL synthtisable. Cet outil est facilement volutif. Il pourra galement tre utilis pour gnrer du code systemC, ou encore raliser des prdictions de surface et de consommation du NoC considr.

Chapitre 4

Mise en uvre de la qualit de service


4.1 Introduction

Ce chapitre dtaille la mise en uvre des tapes les plus complexes de notre ot. Il dcrit comment driver les donnes extraites de lapplication, en donnes utilisables au niveau du NoC. Il prsente notre technique dexploration et daectation des chemins ddis aux communications garantir dans le NoC.

4.2

Pralable

Avec le principe du TDMA, un nombre de slots de temps doit tre rserv pour satisfaire la bande passante de la charge utile de chaque communication. Nous dnissons les termes suivants : Lp : Largeur dun phit ou mot (en bits). Ls : Largeur dun slot de temps(en mots). Lh : Largeur de lentte dun paquet (en mots). FN oC : Frquence du NoC et de ses liens (en Hz). Bl : Bande passante dun lien (en bits/s) Bl = FN oC Lp |S| : Dimension de la table de slots (table TDMA) (en slots). Bs : Bande passante associe un slot rserv (en bits/s) Bs = Bl |S| (4.2) (4.1)

Bw : Bande passante associe un mot rserv (en bits/s) Bw = Bs Ls (4.3)

53

54

mise en uvre de la qualit de service

Un mot est utilis soit pour transporter un entte soit pour transporter de la charge utile. Bp,i : Bande passante requise par la charge utile pour la communication Ci (en bits/s). Hi : Nombre denttes dans une itration de la table de slots pour le ou les paquet(s) de la communication Ci (enttes). Nous considrons quil ny a gnralement quun paquet et donc quun entte par itration de la table de slots pour chaque Ci . Ceci rduit la perte de bande passante. Wh,i : Nombre de mots rservs dans une itration de la table de slots pour transporter les enttes des paquets de la communication Ci (en mots). Wh,i = Lh Hi (4.4)

Wp,i : Nombre de mots rservs dans une itration de la table de slots pour la charge utile de la communication Ci (en mots). Wp,i = Wp,i = Bp,i Bp,i Bw LS (Lp fN oC ) (4.5)

Si : Nombre de slots rservs dans une itration de la table de slots pour la communication Ci (en slots). |Si | = |Si | = Wp,i + Wh,i Ls (4.6)

H i Lh Wp,i |S| + fN oC Ls

Wreelp,i : Le nombre de mots obtenu par la rservation dans le TDMA pour pour la charge utile de la communication Ci (en mots). Wreelp,i = |Si | LS Hi Lh (4.7)

Du fait de larrondi suprieur pour dterminer un nombre entier de slots rserver, nous avons : Wreelp,i Wp,i Breelp,i : La bande passante obtenue pour transporter la charge utile de la communication Ci (en bits/s). Breelp,i = Wreelp,i Bw (4.8) La bande passante obtenue peut donc tre suprieure celle requise. Breelp,i Bp,i (4.9)

4.3 drivation des contraintes applicatives en contraintes de communications55

4.3
4.3.1

Drivation des contraintes applicatives en contraintes de communications


Introduction

Dans les outils traditionnels de conception de NoC, les contraintes de bande passante et de latence des communications sont gnralement considres comme connues et constituent le point dentre de leurs ots [45]. Or, la confrontation aux applications relles nous montre quil savre trs dicile de fournir de telles contraintes. La ncessit de les spcier conduit souvent le concepteur surestimer les exigences des communications, ce qui a pour consquence un surdimensionnement de larchitecture mise en uvre, ou bien au contraire, cela peut conduire de mauvaises valuations des besoins de communication et ainsi des applications qui ne respectent pas leurs contraintes de fonctionnement. Nous proposons une technique de drivation des contraintes applicatives en contraintes de communications pour les NoCs. En eet, nous montrons que les contraintes des communications peuvent tre extraites partir des spcications de lapplication et de ses tches.

4.3.2

Problmatique

Dune part, les applications des domaines du traitement dimage et des tlcommunications sont gnralement spcies comme un ensemble de tches avec des contraintes temporelles globales aux entres et sorties. Dautre part, il est ncessaire dexprimer les contraintes de bande passante et de latence de chacune des communications an que le NoC puisse les garantir. Ainsi, des contraintes locales relatives aux communications doivent tre extraites des contraintes globales de lapplication. Cependant, cette extraction nest pas triviale car les dcisions de conception sont fortement dpendantes. Pour rsoudre le problme du dimensionnement de la taille de la table TDMA, il est ncessaire de connatre les contraintes de bande passante et de latence de chaque communication, cependant ces dernires dpendent de la taille de cette mme table TDMA. Nous sommes face au problme du choix de lordre des dcisions prendre. Ce type de problme est classique dans le contexte des outils de CAO. Notre approche repose sur des hypothses de dpart qui visent rduire le cot en FIFOs, car cest un facteur de cot dterminant du NoC.

4.3.3

Principe

Les applications orientes ot de donnes peuvent tre spcies par un graphe de tches schangeant des donnes au travers du NoC. La gure 4.1 montre lexemple simple dune chane de quatre tches (1-4) qui doivent tre excutes en moins dune priode pour respecter la contrainte de temps de lapplication. Ti est une tche de traitement. Ci j reprsente une communication entre deux tches Ti et Tj . En pratique, une application peut tre spcie comme un ensemble de chanes de tches ayant des priodes spciques, mais pour plus de clart, nous illustrerons ici le calcul des contraintes dans le cas dune seule chane.

56

mise en uvre de la qualit de service

Fig. 4.1 Une chane de tches 4.3.3.1 Temps ncessaire pour quune quantit de donnes accde au rseau et le traverse

Fig. 4.2 La rservation de slots dans une table TDMA La gure 4.2, nous montre les slots rservs par une communication Ci dans une table TDMA. Six slots sont rservs. Les slots ont ici une capacit de deux mots. Ces rservation permettent dmettre un entte (H) et 5 mots de charge utile (P). N est le nombre de mots dans la table de TDMA. (N = LS |S|) ; ni est le nombre de mots de donnes qui doivent tre transmis pour la communication Ci . si est le temps pour parcourir la longueur du chemin (en cycles) emprunt par Ci . Nous pouvons dduire de la gure 4.2 le temps maximum ncessaire pour quune communication obtienne laccs un nombre de slots susant pour tre entirement expdie dans le rseau. delaiM axEmission = ni Wreelp,i (N Wreelp,i )

cela sajoute le temps pour acheminer ces donnes dans le NoC. Ce temps est fonction du nombre de mots de donnes transmettre et de la longueur du chemin. delaiDeT ransport = ni + si

4.3 drivation des contraintes applicatives en contraintes de communications57 Ainsi, le dlai total maximum ncessaire pour acheminer les donnes est F Ti (ni , Wreelp,i , si ) = ni Wreelp,i (N Wreelp,i ) + ni + si (4.10)

Pour dterminer ce temps, il nous faut non seulement connatre la quantit de mots de donnes qui doit tre transporte, mais aussi : la taille de la table TDMA, le nombre de slots rservs dans cette table pour la charge utile, la longueur du chemin. Or nous ne possdons pas encore ces informations. 4.3.3.2 Algorithme

An de rsoudre le problme des dcisions croises, nous avons opt pour une approche itrative favorisant la minimisation des FIFOs et une convergence au plus tt. Notre approche consiste en les tapes suivantes (celles-ci seront dtailles ci-aprs) :
- ok = faux ; - Tant que ( !ok et !limite) - Aecter une portion de la bande passante au trac BE en accord avec les choix du concepteur - Considrer la longueur du chemin le plus court de la source la destination pour chaque Ci : smini pour dterminer la latence Li . Cest un choix optimiste, cette hypothse nest faite que pour la premire itration. - Calculer la bande passante requise Bp,i pour chaque communication Ci du trac GT avec lq. 4.16 ; - Calculer la taille de la table TDMA |S| et le nombre de slots rserver (|Si |) pour chaque communication Ci (voir la section 4.3.6). On en dduit la bande passante rellement obtenue (Breelp,i ) pour chacune des communications. Les bandes passantes obtenues sont gales ou suprieures celles requises en raison de larrondi suprieur pour dterminer un nombre entier de slots ; - Vrier le respect de la rgle 1 (initialisation) ; - Vrier le respect de la rgle 2 (cadence) ; - Si succs alors ok = vrai - Sinon les contraintes de latence Li sont mises jour avec les valeurs courante Si sur la base de lquation 4.16 dans laquelle Bminp,i est remplace par la bande passante rellement obtenue Breelp,i . - Fournir ltape dallocation de chemin (routage spatio-temporel) la taille de la table TDMA et les contraintes de bande passante et de latence de transport (N ,Wp,i ,Li ).

La gure 4.3 montre lvolution de la contrainte sur la longueur du chemin vis vis de la bande passante durant le processus de drivation. Nous dbutons par lhypothse que les chemins obtenus seront de longueur minimale. Nous dterminons les bandes passantes requises. Le calcul de la table TDMA conduit lobtention de bandes passantes suprieures celles requises, ce qui permet de relcher la contrainte sur la longueur des chemins (nous pourrons alors nous satisfaire de chemins qui seront plus long que ceux minimums). Nanmoins, la latence daccs dans le TDMA rduit quelque peu cette marge.

58

mise en uvre de la qualit de service

Fig. 4.3 Contrainte sur la longueur du chemin et bande passante durant le processus de drivation des contraintes

4.3.4

Les rgles respecter

Notre tude nous conduit une formalisation du problme selon deux rgles, la rgle dinitialisation et la rgle de cadence (contraintes en rgime continu). 4.3.4.1 La rgle dinitialisation

La rgle dinitialisation traite du dlai ncessaire pour lire la quantit minimale de donnes requises avant que la tche Ti ne puisse commencer sexcuter. Cette initialisation est calcule en additionnant les dlais dinitialisation (qui incluent traitement et communication) de toutes les tches squentielles depuis lentre jusqu la sortie de la chane. La gure 4.4 nous montre une IPi qui ralise une tche Ti , et ses communications avec deux mmoires. La tche Ti peut ncessiter 3 types de communications comme illustr. CF Ri est la communication relative la requte de lecture faite par la tche Ti ; CBRi est la communication qui achemine les donnes que la tche Ti consomme ; CF Wi est la communication pour crire les donnes produites par Ti ; Nous dnissons les sigles suivants : T : la priode de lapplication ; nF Ri : le nombre de mots ncessaires CF Ri ; nBRi : le nombre de mots ncessaires CBRi ; nF Wi : le nombre de mots ncessaires CF Wi ; Pi : le nombre ditrations de Ti durant T ; Ii : le nombre de lectures avant que lexcution de la tche Ti ne puisse dbuter ; memR, memW : temps accs la mmoire en lecture et criture respectivement ;

4.3 drivation des contraintes applicatives en contraintes de communications59

Fig. 4.4 Chronogramme des communications autour dune tche sRi : le nombre de sauts pour une opration de lecture ; sWi : le nombre de sauts pour une opration dcriture ; Texe(i) : Dure dexcution de Ti pour une itration ; Oi : le nombre ncessaire ditration de la tche pour produire le nombre requis de mots pour permettre linitialisation des tches qui la suivent. Pour chacune des tches Tj consommant des donnes produites par la tche Ti : Oi = Ij nBRj nF Wi (4.11)

Ainsi, pour une tche Ti , nous pouvons dnir son dlai dinitialisation pour quelle puisse dbuter. Nous noterons ce dlai Tinit(i). Tinit (i) = M axpP rev(i) (Tinit (p)) +FT (nF Ri , KF Ri , sRi ) +memR +FT (Ii nBRi , KBRi , sRi ) +Texe + max{T exe(i) FT (nF Wi , KF W i , sWi ); 0}(Oi 1) +FT (Oi nF Wi , KF W i , sWi ) +memW (i) La rgle 1 doit tre vrie pour toutes les chanes de lapplication. Rgle 1 Tinit (j) + FT (nF Wj , (Pj 1)nF Wj , SWj ) < T (4.12)

(4.13)

Prev(i) est lensemble des tches qui prcdent Ti . FT est le dlai de communication dans le NoC. FT dpend de la taille de la table TDMA, de la longueur du chemin et du nombre de mots de donnes transmettre. Il a t dni par lquation 4.10.

60

mise en uvre de la qualit de service

La rgle 1 exprime la dpendance entre les tches. Elle se traduit sur les tches de sortie de lapplication par une contrainte de retard pour dbuter qui est due linitialisation des tches prcdentes. Ce modle est gnrique et peut tre appliqu dirents modles de communication tels que les mmoires partages ou les communications directes entre les registres des IPs. Dans ce dernier cas, nF Ri est nul. La respect de la Rgle 1 relative linitialisation est ncessaire, mais non susante pour garantir la contrainte de temps rel car la cadence doit tre galement vrie pour sassurer que les donnes peuvent tre produites dans les temps chaque itration. 4.3.4.2 La rgle de cadence

La vrication de la rgle sur la cadence montre lhabilet du systme consommer et produire les donnes en accord avec la cadence de lapplication pour toutes les communications. Cela signie que la bande passante qui permet chaque tche de se raliser doit tre en accord avec ses besoins de communication. Nous faisons lhypothse que dans un ot de donnes rgulier, la latence des requtes est masque puisquune requte de lecture (respectivement criture) peut tre mise avant que la prcdente ait t traite par celui qui la reue. Dirents cas doivent tre considrs, ils dpendent du modle darchitecture de lIP. Les communications transportant les lectures-critures et lexcution des tches peuvent tre ralises squentiellement ou simultanment. Pour des raisons de simplicit, nous prsentons une seule rgle, compatible avec le modle compltement squentiel. En pratique, une application pourra tre compose de cas mixtes, certaines IPs pouvant fonctionner suivant un fonctionnement squentiel et dautres selon un fonctionnement parallle. Nous notons : Tread (i) = memR + FT (nBRi , KBRi , sRi ) Twrite (i) = memw + FT (nF Wi , KF W i , sWi ) Nous en tirons la rgle suivante pour le cas squentiel (pire cas). Rgle 2 T (4.14) Tread (i) + Twrite (i) + Texec (i) < Pi La rgle 2 exprime la contrainte de cadence individuellement pour chaque tche.

4.3.5
4.3.5.1

Dimensionnement de la table TDMA


Prsentation

La table TDMA est construite pour permettre une subdivision de la bande passante des liens sous forme de slots. Elle doit permettre de respecter les contraintes de latence (Li en cycles) et de bande passante (BWi en mots par cycle) des communications du type trac GT. De plus, nous cherchons minimiser sa taille. La taille de la table TDMA est exprime en nombre de slots et notre ot a t conu de sorte que nous devons la dnir avant lallocation des chemins.

4.3 drivation des contraintes applicatives en contraintes de communications61 4.3.5.2 Principe

La taille de la table TDMA doit tre dnie avant lallocation des chemins et des slots aux communications du trac GT. Sans la connaissance de la taille de cette table, les contraintes dune communication Ci peuvent tre spcies par les quations 4.15 et 4.16. Pi ni 1 < T m Pi Texe (i) Bp,i Pi ni 1 > T m Pi Texe (i) Li Pi ni 1 T m Pi Texe (i) Si

Li + Bp,i Bminp,i

(4.15)

(4.16)

ni est le nombre de mots transmis durant chaque itration de Ci , i vaut 1 (respectivement 0) si les traitements et communications sont raliss squentiellement (respectivement simultanment), Si est le plus court chemin. Les applications dans les domaines des tlcommunications ou du traitement dimage sont gnralement domines par les communications et manipulent donc des communications priodiques (Pi 1) et de grandes quantits de donnes (ni 1). De plus, le temps dattente pour accder aux slots rservs dans la table de TDMA est masqu par les FIFOs de dcouplage. Cela signie que Li pourrait tre nglig en comparaison du terme relatif la bande passante, cependant par scurit nous considrons Li = smini , qui est le dlai dacheminement de la communication Ci par le plus court chemin. Ainsi, grce lquation 4.16, nous pouvons obtenir une contrainte BWi min pour initialiser ltape de conception du TDMA indpendamment de la valeur Li qui est inconnue. Cette hypothse est renforce par le fait que les valeurs de bandes passantes BWi obtenues seront suprieures celles demandes puisque les communications obtiendront un nombre entier (arrondi suprieur) de slots dans la table TDMA, pour satisfaire la bande passante requise.

4.3.6

Algorithme de calcul de la taille de la table TDMA

Comme mentionn prcdemment, le dimensionnement de la table TDMA est une tape importante de notre mthode, son algorithme est bas sur un algorithme itratif rapide dcrit ci-dessous :
Notication des communications Ci ayant des exclusions mutuelles ; La taille de la table |S| est initialis 0 ; Rpter incrmentation de 1 de la taille de la table TDMA ; La recherche commence donc avec une latence minimum pour toute les communications ; calcul du nombre de slots requis (et du nombre de mots Wp,i ) pour satisfaire chaque communication Ci avec lquation 4.6 ; Tant que (la somme des slots entrants/sortants dans une NI > taille de la table TDMA & taille de la table TDMA < taille maximale admissible). Fin du rpter ;

62

mise en uvre de la qualit de service


La taille de la table est dtermine, les slots rservs pour contenir les Wp,i mots pour chaque communications Ci sont calculs, ce qui permet le calcul de la longueur de chemin maximale permise Si max avec la bande passante oerte (quation 4.16).

4.3.7
4.3.7.1

Validation
Cas dtude et rsultats

Une application de dtection dobjets en mouvement est tudie dans la section 7.3. Cest un exemple typique o les contraintes dinitialisation doivent tre prises en compte. La plupart des tches ncessitent de disposer dune quantit minimum de donnes produites par les tches qui les prcdent pour pouvoir commencer sexcuter pour la premire fois. Par exemple, la tche drosion require 2 lignes (640 pixels) et 3 pixels de la ligne suivante avant de pouvoir raliser sa premire itration. Un autre point est la longue chane de dpendances entre les tches, qui implique des calculs rcursifs des dlais dinitialisation qui simbriquent. Cette vrication repose principalement sur la rgle 1. 4.3.7.2 Rsultats

Grce notre approche, les contraintes des communications ont t extraites et une solution satisfaisant ces contraintes a t trouve. Cette solution est dtaille dans la section 7.3. partir des contraintes applicatives (cadence de 25 images par secondes) et du graphe des tches de lapplication ainsi que des caractristiques des IPs (temps daccs des mmoires), nous avons appliqu notre mthode pour extraire les contraintes de bande passante et de latence de chacune des communications et vri les rgles dinitialisation et de cadence de lapplication.

4.3.8

Conclusion

La conception dun NoC optimis require la spcication des contraintes de bande passante et de latence pour chacune des communications de lapplication. En pratique, ces informations sont gnralement inconnues, car les communications appartiennent un ot complexe avec de nombreuses dpendances et seules les contraintes applicatives de haut niveau sont gnralement disponibles. Ce type de problme ncessite la dnition de rgles permettant de vrier le respect des contraintes dinitialisation et de cadence de lapplication. Ces rgles sont vries durant le ot de conception an de relcher de faon approprie les contraintes qui peuvent ltre. Lutilisation de cette mthode sur une application de traitement dimage a permis de montrer son intrt et de la valider. A lheure actuelle, cette partie du ot est encore partiellement manuelle. Du travail dingnierie reste ncessaire pour linclure dans notre outil, cependant, la mthode a t valide.

4.4 routage spatio-temporel

63

4.4
4.4.1
4.4.1.1

Routage spatio-temporel
Lallocation des chemins dans lespace et le temps
Introduction

Pour chacune des communications du trac GT qui doivent traverser le NoC selon le principe de TDMA, nous dsirons trouver un chemin et un instant denvoi qui permettent de satisfaire les contraintes de latence et de bande passante. Lchec dans lallocation dune communication est attribu soit une allocation sous-optimale des prcdentes communications, soit une insusance des ressources mises disposition. Les ressources en lespce sont les liens et les slots de temps de la table TDMA. Or quand aucun chemin na t trouv, il est ncessaire daugmenter la taille du TDMA de faon crer de nouvelles opportunits sur la dimension temporelle. Cependant, le redimensionnement du TDMA peut se traduire par une augmentation importante de celui-ci pour satisfaire une distribution de bande passante correcte, car le nombre de slots allous est un nombre entier. Enn, laugmentation de la taille de la table TDMA implique une augmentation de la taille des FIFOs et donc un cot supplmentaire. Ainsi, il est crucial de disposer dun algorithme dallocation des chemins qui soit performant an de trouver une solution avec une taille de table TDMA minimale. Les auteurs dans [45] prsentent une approche pour allouer le placement des IPs et les chemins des communications. Leur approche favorise lutilisation des liens ayant le moins de slots rservs, notamment, les liens qui la fois rduisent minima la fentre temporelle relative la communication placer et ore une courte longueur de chemin. Cest une approche gloutonne. Dans celle-ci, contrairement la notre, il ny a pas de pr-rservation pour guider vers des choix qui faciliteront la suite de la rsolution du problme. Notre technique utilisant les pr-rservations est explique dans les sections suivantes. 4.4.1.2 Topologie avec une exploration sur les dimensions espace et temps

Nous utilisons une technique TDMA. Nous avons vu que dans ce cas le trac GT est pr-ordonnanc grce ce TDMA pour viter la moindre contention entre ses paquets. Grce cette absence de contention du trac GT, aucun deadlock ne peut intervenir et donc aucune rgle particulire de routage (technique de routage sans interblocage ou deadlock-free) nest ncessaire pour les viter, contrairement au trac BE. Cependant, la technique TDMA ajoute une dimension temporelle en plus des classiques dimensions spatiales. Celle-ci doit tre considre lors de lallocation des chemins. Ainsi, nous passons par exemple dun espace 2D (X,Y) une reprsentation espace-temps (X,Y,t). La gure 4.5 montre une simple topologie en grille 2D avec ses liens entre les routeurs et la version duale de cette reprsentation avec lajout de la dimension temporelle en unit de slots. Nous appellerons ce dernier, le graphe spatio-temporel. La taille de la table TDMA est ici de 3 slots. Un arc de la vue spatiotemporelle correspond un lien unidirectionnel de la vue topologique durant un slot de temps donn. Les arcs sont orients en accord avec lvolution squentielle de la table TDMA, du premier au dernier slot, modulo la taille de la table.

64

mise en uvre de la qualit de service

Pour des raisons de visibilit et comprhension, les arcs fermant la boucle en allant du dernier au premier slot ne sont pas tous reprsents sur la gure 4.5. De plus, seuls les arcs correspondant aux ches en gras de la vue topologique sont reprsents sur le graphe spatio-temporel. Le trac GT suit la rgle de transport suivante : Il ny a pas darcs verticaux car un paquet de type GT ne peut jamais attendre dans un routeur (contrairement au BE), un paquet GT eectue un saut dans une dimension spatiale chaque nouveau slot de la dimension temporelle. De plus, un paquet ne peut pas ressortir dun routeur par le lien par lequel il est entr.

Fig. 4.5 Topologie spatiale et vue spatio-temporelle 4.4.1.3 Technique dallocation des chemins

Dans le graphe spatio-temporel, nous parlons de chemins spatio-temporels. Ils disposent dun chemin spatial, dun instant de dpart et dune dure. partir de maintenant le terme chemin dsignera le chemin spatio-temporel. Notre technique dallocation des chemins manipule des communications ayant des contraintes de bande passante et de latence. La latence est exprime en nombre de sauts et la bande passante en nombre de slots rservs. De plus, les cliques des communications mutuellement exclusives sont considres et permettent la multi-rservation des slots de temps par ces communications. Lobjectif est de trouver une solution permettant de satisfaire toutes les communications GT spcies et de rduire le cot en FIFOs. Pour rduire le cot en FIFOs, nous favorisons les plus courts chemins tout en respectant les contraintes. La base de notre technique est la rservation des chemins et donc des arcs du graphe spatio-temporel en fonction des poids de pr-rservation faites par les communications non encore places. Lobjectif est de faire dans la mesure du possible des choix qui restreignent le moins possible les solutions pour les choix qui restent faire. Notre algorithme est organis en cinq tapes principales.

4.4 routage spatio-temporel Lalgorithme est le suivant :

65

Tant que les communications nont pas toutes un chemin rserv (elles ne sont pas satisfaites) 1. Extraction des chemins candidats pour chacune des communications non satisfaites. 2. Pr-rservation des arcs sur les chemins candidats pour chacune des communications non encore satisfaites. 3. Slection de la communication Ci satisfaire parmi toutes les communications non satisfaites. 4. Slection dun chemin Pi pour la communication Ci parmi les chemins candidats. 5. Rservation des arcs du chemin Pi par la communication Ci . Ci est marque comme satisfaite. 6. Annulation de toutes les pr-rservations devenues obsoltes.

Chacune de ces tapes est dtaille dans les sections suivantes. 4.4.1.4 Vue dtaille de lalgorithme de dcision des chemins

Lextraction des chemins candidats : Nous avons adapt lalgorithme de Dkstra pour dterminer les chemins minimums dans notre graphe spatio-temporel. Pour chaque communication non encore place et pour chaque slot de dpart possible dans la table TDMA, le graphe spatio-temporel est explor par une version modie de lalgorithme de Dkstra. Les arcs ont un poids de 1. Un arc est disponible sil nest pas encore rserv ou sil nest rserv que par des communications appartenant toutes des cliques de mutuelle exclusion dont fait galement partie la communication considre. De plus, le nombre de slots libres suivants doit tre susant sur un lien pour permettre toute la taille du paquet de passer sans tre scind. Enn, il ne retient pas un chemin minimal, mais tous les chemins minimaux entre une source et une destination. Pour chacun des slots de temps valus comme instant de dpart la source, les distances les plus courtes de la source la destination qui ont t trouves peuvent tre direntes. Pour la communication considre, si la plus courte distance trouve de sa source sa destination respecte sa contrainte de latence, alors les plus courts chemins minimaux sont extraits de ce graphe an dtre ajouts la liste des chemins candidats de cette communication. Notons que nous liminons les chemins qui sortent dun routeur par le mme port par lequel ils sont rentrs car nous avons fait le choix de ne pas traiter ce cas rare pour simplier larchitecture des routeurs. La phase de pr-rservation : Cette tape a pour objectif de quantier la probabilit dutilisation de chacun des slots des arcs (cest dire de chacun des slots temporels de chacun des liens unidirectionnels du NoC) par les communications non encore places. Le poids dune pr-rservation est de (1 / nombre de chemins candidats). Une pr-reservation est faite par une communication pour chacun des slots de temps que son paquet peut occuper sur chacun des arcs de chacun de ses chemins candidats. Sur la gure 4.6, nous observons les poids des pr-rservations faites pour un paquet dune communication qui ncessite deux slots. Ce paquet peut saccommoder de trois positions direntes. Nous voyons que les slots libres au centre se voient aects un poids de prservation plus important que ceux situs sur les extrmits.

66

mise en uvre de la qualit de service

En eet, ceux du centre orent plus de mobilit au paquet de deux slots que lon dsire placer. Si une autre communication venait se rserver les deux slots du centre, elle priverait cette communication de toute possibilit dutiliser ce lien. Il est donc tout a fait judicieux de faire cette pondration des pr-rservations. Elle signalera aux autres communications qui seront places avant celle-ci dutiliser les slots les moins pr-rservs dans la mesure du possible.

Fig. 4.6 Rpartition des Pr-rservations des slots Pour chaque communication non alloue, une pr-rservation est faite pour tous les arcs, de tous ses chemins candidats, en accord avec la taille du paquet. Les prrservations sadditionnent lorsquelles sont eectues sur un mme arc. La slection de la communication Ci satisfaire : Parmi toutes les communications pour lesquelles aucun chemin na encore t rserv, il nous faut dcider laquelle il est le plus judicieux de satisfaire en premire. Ce choix doit tre fait de faon judicieuse. En eet, la rservation des arcs appartenant son chemin spatio-temporel rduira la libert dexploration pour laectation des chemins des communications qui restent placer. Pour cette politique de slection de la communication placer en priorit, nous avions tudi un facteur que nous qualions de gne ou de contention. Nous avions initialement imagin deux stratgies trs opposes qui sont les suivantes : Satisfaire en premier les communications qui ont un chemin candidat qui rencontre le moins de pr-rservations des autres communications (gne le moins les autres) Placer en premier celui qui rencontre le plus de conits avec les autres, ainsi, pour lui sa rservation est faite ds le dbut plutt que dattendre que les possibilits ne se rduisent encore. Ces solutions nont pas montr de rsultats signicatifs. Nous avons dcid dordonner les communications selon le critre de priorit suivant : BandepassanterequiseCi latencecouranteCi latencerequiseCi Ainsi, la priorit est donne la communication ncessitant la plus grosse bande passante et ayant la laxit la plus faible (la plus petite marge pour satisfaire sa contrainte de latence). P riorCi =

4.4 routage spatio-temporel

67

La slection dun chemin : Une fois que lon a slectionn la communication satisfaire, il reste choisir parmi les chemins candidats retenus, le chemin Pi qui va nalement tre celui qui sera allou (rserv) la communication Ci . Pour cela nous pouvons utiliser un facteur de cot qui pourra notamment tre la gne quentranerait lutilisation dun chemin plutt quun autre pour lallocation des communications qui restent placer. Cette gne est ici reprsente par les pr-rservations faites par ces dernires. Direntes fonctions de cot ont t values : 1. Le choix naf : Le choix du chemin parmi ceux candidats est ralis par un tirage alatoire. 2. Le plus court chemin : La pr-rservation nest pas utilise, le plus court chemin est slectionn. Cest en quelque sorte un choix goste, sans concertation. Le facteur de cot est la taille du chemin. 3. Le chemin ayant la plus faible somme des pr-rservations sur ses arcs : Le facteur de cot est la somme des pr-rservations sur chacun des arcs du chemin. Les pr-rservations faites par Ci , ainsi que les communications appartenant lune de ses cliques dexclusion mutuelle, ne sont pas considres car elles ne reprsentent pas un conit. Notons ici que la pr-rservation dun chemin par une communication Cj en conit avec Ci nest comptabilise quune seule fois. En eet, que lutilisation du chemin Pi condamne une ou plusieurs fois lun des chemins de la communication Cj , la gne entrane est la mme. 4. Le chemin ayant la plus faible pr-rservation maximale : Le facteur de cot est la pr-rservation maximale faite sur lun des arcs du chemin. Pour chaque chemin candidat, nous faisons la somme des pr-rservations sur chacun de ses arcs, puis nous retenons la plus grande valeur. Cette valeur est la somme des pr-rservations sur larc le plus pr-rserv de ce chemin. Le chemin slectionn sera celui qui a la plus faible plus grande pr-rservation . Beaucoup dautres fonctions de cot peuvent tre imagines, mais nous nous limiterons celles-ci dans le cas de cette tude, car elles se sont montres les plus reprsentatives. Quand des chemins candidats ont un facteur de cot identique, des critres supplmentaires peuvent tre utiliss pour les dpartager, notamment, le nombre darcs dj rservs par des communications appartenant une clique dexclusion mutuelle avec la communication Ci . Ceci permet de favoriser la multi-rservation des arcs par les communications appartenant une mme clique et donc de laisser plus darcs libres aux autres communications nappartenant pas cette clique. La phase de rservation : Le chemin slectionn est allou la communication slectionne. Les arcs (slots temporels des liens unidirectionnels du NoC) sont rservs en accord avec linstant de dpart, le chemin et la taille du paquet. Le chemin est marqu comme ayant t satisfait. Lannulation de toutes les pr-rservations devenues obsoltes : Enn, toutes les pr-rservations de toutes les communications sont eaces car certaines des rservations faites par la communication prcdemment place rendent certains chemins indisponibles.

68

mise en uvre de la qualit de service

4.4.2

Comparaisons des dirents facteurs de cot de ltape de slection du chemin

Les techniques values sont : 1. le choix naif ; 2. le plus court chemin ; 3. le chemin ayant la plus faible somme des pr-rservations sur ses arcs ; 4. le chemin ayant la plus faible pr-rservation maximale . Toutes ces techniques sont des heuristiques. 4.4.2.1 valuation sur un exemple simple

La gure 4.7 montre un exemple dune topologie en grille 4x4. Huit communications (de C0 C8) doivent tre satisfaites. Nous pouvons voire que la communication C0 est celle qui dispose du plus grand nombre de chemins minimum. Si, par ltape de slection de la communication placer, C0 est la premire communication pour laquelle un chemin va tre rserv, alors les techniques prsents ci-dessus peuvent obtenir des rsultats dirents. En eet les expriences nous montre que les technique 3 et 4 trouvent le chemin idal pour C0 (celui indiqu sur la gure) , ce qui permet de satisfaire toutes les communications par les chemins les plus courts. Les deux premires techniques conduisent soit des chemins plus longs, soit des checs pour satisfaire toutes les communications ce qui conduit augmenter la taille de la table TDMA pour disposer dun graphe dexploration plus large sur la dimension temporelle an daboutir un succs. Les techniques 3 et 4 sont donc meilleures.

Fig. 4.7 Rpartition des communications sur une topologie 4.4.2.2 tude plus large

Pour les direntes techniques de slection des chemins prsentes dans la section prcdente, la gure 4.8 montre la longueur moyenne des chemins (en nombre de sauts)

4.4 routage spatio-temporel

69

trouv pour 3 applications direntes. An de pouvoir comparer ces techniques, elles doivent trouver la solution avec la taille de la table TDMA minimum.

Fig. 4.8 Longueur moyenne des chemins en fonction de la technique daectation des chemins Le choix naif slectionne arbitrairement un chemin qui satisfait les contraintes de la communication place. Ce choix qui est non optimum pour la communication place et pour la libert quil laisse aux communications qui restent placer, conduit des chemins globalement plus longs que ceux obtenus par les autres techniques. De plus, il choue pour trouver une solution pour les applications 2 et 3. Le facteur de cot 2 ne ncessite pas ltape de pr-rservation et peut rapidement produire un rsultat. Sil trouve une solution, il obtient paradoxalement parfois la solution qui ore les plus courts chemins et rduit le plus la taille des FIFOs. En eet chaque communication fait le choix goste de prendre le plus court chemin et si nalement tout le monde trouve une solution, cette technique est susante. Si ce facteur de cot ne permet pas de satisfaire les contraintes, les facteurs de cot 3 et 4 sont intressant utiliser car ils trouvent plus facilement une solution, mais celle-ci est moins optimise, car chaque communication lors de son placement prend soin de ne pas dranger les communications restantes placer et se contentait de satisfaire sa contrainte. Cest nalement le facteur de cot 4 qui se rvle trouver le plus souvent une solution respectant les contraintes. Il est ainsi plus prjudiciable dutiliser un arc qui tait fortement pr-rserv par une communication, que dutiliser un chemin qui occupe des arcs sur lesquels plusieurs communications ont chacune fait une faible pr-rservation. 4.4.2.3 Conclusion

Pour obtenir un rsultat rapide, nous prconisons dutiliser le facteur de cot du plus court chemin la premire fois, pour la taille de la table minimale qui satisfait les bandes passantes. Si cette technique choue satisfaire toutes les communications, alors ensuite nous utilisons le facteur de slection du chemin ayant la plus faible prrservation maximale , ceci jusqu ce que toutes les communications soient satisfaites ou que lon dpasse la taille maximale admissible pour la taille de la table TDMA.

70

mise en uvre de la qualit de service

4.4.3
4.4.3.1

Complexit de lalgorithme et heuristiques possibles


Complexit

Nous considrons les grandeurs suivantes : C : le nombre de communications R : le nombre de routeurs S : le nombre de slots de la table TDMA (cest aussi la taille maximale dun paquet en nombre de slots) A : le nombre darcs partant dun routeur Cl : le nombre de cliques auxquelles peut appartenir une communication Ainsi, le nombre de nuds du graphe spatio-temporel est R S La complexit de lalgorithme Dkstra modi est O(S R A S C Cl) La complexit de lalgorithme de routage est O(C 2 S(complexit de lalgorithme Dkstra modi)) = O(C 3 S 2 R A Cl) Le nombre darcs partant dun routeur est faible, il vaut 5 au maximum dans une grille 2D (liens nord, sud, est, ouest et local). En pratique, le nombre S se situe entre 4 et 128. En eet, pour que les communications aient un temps dattente court pour accder aux slots qui leurs sont rservs, il faut que la table de TDMA ait un temps de rotation susamment court et donc une taille raisonnable. Ce calcul de la complexit donne une estimation pessimiste. En eet, nous ne pouvons pas avoir la fois beaucoup de paquets dans une table de slots et ces paquets occupant tous les slots de la table. De plus, lalgorithme dispose de conditions dchappement dans ses boucles, an de ne pas poursuivre leurs excutions lorsque cela est rendu inutile. Enn, au fur et mesure de lexcution, le nombre de communications non alloues dcrot, acclrant ainsi la vitesse dexcution. A titre indicatif, nous avons excut notre algorithme de recherche de chemin sur une machine quipe dun processeur Intel Pentium III 3GHz et de 1 Giga de RAM. Il trouve gnralement la solution en quelques minutes, voir en quelques secondes. Dans un cas complexe tel que lapplication du cas 6 de la section 7.6, qui utilise une topologie en grille 5x5 pour connecter 25 NIs, utilise les exclusions mutuelles, ainsi que le contrle de ux de bout-en-bout (il implique ici 96 communications unidirectionnelles), une solution avec une table de 16 slots a t trouve en un temps dexcution de 8643 secondes soit 2h24. Ceci sexplique par la complexit de ce cas. Cet algorithme est cod en java, langage qui ne tire pas partie de toute la vitesse de la machine. Notre algorithme na pas t prvu initialement pour tre embarqu et excut pour trouver de nouvelles solutions durant le fonctionnement du systme. Ce temps nest donc pas prjudiciable. 4.4.3.2 Amliorations et heuristiques

Dans le cadre dun systme recongurable ou adaptatif, il peut savrer ncessaire dexcuter en ligne lalgorithme de recherche de chemin pour quil trouve une nouvelle solution. Dans ce cas cette excution doit tre rapide.

4.4 routage spatio-temporel

71

Nous pouvons noter quil est possible de rduire le temps dexcution de notre algorithme en faisant appel quelques amliorations et heuristiques : Le nombre de chemins candidats retenu peut tre limit. Les N premiers sont retenus, car en eet des centaines de chemins peuvent tre trouvs avec la version actuelle. Lalgorithme peut ne recalculer que les chemins candidats des communications dont tous les chemins candidats pr-rservs ont perdu un arc par la rservation du chemin faite par la communication qui vient dtre satisfaite. Ces amliorations nont pas t introduites, mais sintgrent dans des travaux en cours traitant notamment de la surveillance et du contrle du NoC. Enn, seule lallocation du trac GT a t dtaille ici, puisque seul celui-ci doit bncier de garantie et fonctionner sur le principe du TDMA. Prcisons que le trac BE qui na pas t abord ici, peut se voir aecter les chemins utilisant les liens qui ont t les plus dlaisss par les rservations des communications GT, ceci an, de sourir au minimum des conits avec le trac GT qui a une priorit plus leve. Lauteur dans [72] prsente une approche dans ce sens. Pour le trac BE, il faut en revanche veiller utiliser des chemins qui empcheront lapparition dun deadlock.

4.4.4

Conclusion

Nous avons prsent une technique de recherche de chemin pour les communications de type trac garanti dans le contexte dutilisation de tables de TDMA. Lalgorithme que nous proposons tire partie de la connaissance des potentielles exclusions mutuelles entre les communications. De plus, une technique de pr-rservation des chemins permet lalgorithme dobtenir des solutions avec des topologies et des tables de TDMA les plus petites possibles, ceci an de rduire le cot en FIFO et donc en surface du NoC. De plus, cet algorithme a t programm en java et valid sur des applications.

Chapitre 5

Technique de codage des chemins pour la scurit et la reconguration


5.1 Introduction la scurit

Un SoC est constitu dun ensemble dlments IP, tels que, processeurs, mmoires et matriels ddis. Ainsi, le SoC sera amen faire cohabiter un ensemble dapplications dont certaines pourront avoir des exigences en termes de scurit. Les NoCs fournissent aux concepteurs de SoCs un moyen exible pour contrler les communications entre un grand nombre de blocs IP, ainsi que des capacits de reconguration. Cependant, cette exibilit introduit de nouveaux points faibles dans le systme et ore des opportunits de potentielles attaques. De plus, la complexit des applications, lhtrognit de larchitecture et les besoins en reconguration, qui peuvent justier lutilisation dun NoC au sein dun SoC augmentent la gravit de ces attaques potentielles. Il est donc ncessaire de prendre en compte la scurit du NoC. Ce sujet a jusqu prsent t nglig, mais deviendra certainement une proccupation importante dans lavenir compte tenu de limportance grandissante que prend la scurit dans les systmes embarqus. Enn, nous verrons que la technique de codage que nous proposons ore des proprits intressantes pour dautres aspects que la scurit, notamment, la reconguration [73].

5.2

Analyse des attaques sur un NoC et points faibles actuels

Nous dissocions la scurit et la abilit. Nous nous attachons ici plus particulirement laspect scurit mme si les solutions prsentes pourrait tre utilise pour dtecter un comportement anormal. La tolrance aux fautes dans les NoCs est traite dans [74]. Une solution de scurit des changes base de cl prive / cl publique est propose par les auteurs de [75].

73

74technique de codage des chemins pour la scurit et la reconfiguration Nous dnissons ici un lment qui contrle le NoC, le CCM (pour central conguration module). Il est unique dans le rseau et est en charge de linitialisation, la conguration et la reconguration du NoC. Le NoC de Philips, thereal, utilise un module similaire [76] dans le but de congurer les tables TDMA des NIs uniquement. Des fonctionnalits telles que la supervision et la dfense peuvent tre ajoutes au CCM, dans une optique de scurit. Ces points seront discuts dans les sections suivantes.

5.2.1

La scurit

Il peut tre ncessaire de faire cohabiter des donnes scurises avec des composants IP et des interfaces non scurises. Par exemple, la lecture dans une mmoire peut tre autorise toutes les IPs, mais lopration dcriture peut tre restreinte une IP donne. Nous dnissons deux zones dans un systme, la zone scurise ou sre et la zone non scurise ou non sre. La zone scurise stocke, calcule ou transporte des informations critiques. La zone non scurise est relativement ouverte et vulnrable. Typiquement, la zone non sre peut tre un FPGA qui est facilement reprogrammable, alors que la zone scurise peut tre un ASIC (gure 5.1). En pratique, une solution entirement base sur un ASIC ne peut pas toujours tre slectionne. Pour des raisons de exibilit, de consommation dnergie et de performances, la reconguration devient un point cl pour les applications futures telle que la radio logiciel par exemple [77]. Dans ce type de domaine, les zones scurises et non scurises peuvent tre associes aux zones noire et rouge respectivement.

Fig. 5.1 Un rseau distribu sur un ASIC et un FPGA Nous pouvons ainsi distinguer trois types dintgrations du rseau. Intgration entirement sur un ASIC. Le NoC bncie de la protection intrinsque de la puce. Les potentiels points faibles sont les interfaces du systme, notamment les accs de lecture et dcriture depuis ces interfaces. Le NoC est un moyen de contrler les entres/sorties, mais aussi dtendre la vulnrabilit du SoC. Intgration entirement sur un FPGA. En plus des aspects prcdents, la capacit de reconguration du FPGA ore de nouveaux points faibles. Cependant,

5.2 analyse des attaques sur un noc et points faibles actuels

75

deux sous-classes peuvent tre distingues puisque lencryptage du bitstream peut tre partiellement ou pleinement utilis. Intgration partielle sur ASIC et FPGA. Il faut tre capable de contrler les accs entre lASIC et le FPGA

5.2.2

Les scnarios dattaque

Lagresseur peut avoir dirents objectifs et donc dirents scnarios. Dirents types dattaques peuvent tre identis et sont classs dans la table 5.1. Ces types dattaques sont expliqus ci-aprs.
Attaque Distante Type dattaque Dni de service Scnario dattaque Sur-utilisation du rseau Chemin incorrect Deadlock Livelock Lecture non autorise criture non autorise ou reconguration Extraction dinformations de conception Observation en fonctionnement

De proximit

Extraction dinformations secrtes Altration du comportement Rtro-ingnierie Extraction dinformation secrtes

Tab. 5.1 Types et scnarios dattaques

5.2.2.1

Le dni de service

Ce type dattaque a pour but daltrer les performances du systme. Une sur-utilisation du rseau peut dgrader la disponibilit et les performances du systme. Des requtes frquentes peuvent tre utilises pour gaspiller de la bande passante et causer une augmentation de la latence des transferts dans le systme, ce qui peut conduire dpasser les dlais admissibles. Les trois scnarios dattaque suivants sont plus pnalisants car ils ont pour but dobstruer les canaux du NoC. Ils consistent introduire dans le rseau un paquet dont les instructions de chemin sont incorrectes. Chemin incorrect Le paquet est pig dans un chemin qui ne dbouche pas, ceci dans le but de le piger dans le rseau. Le corps de ce paquet occupe ainsi quelques canaux et les rend indisponibles pour les autres paquets. Deadlock Le paquet introduit ne respecte pas les rgles qui garantissent labsence de deadlock, ceci dans le but de crer un interblocage. Ceci conduit la contention des canaux et par consquent, condamne une partie, voir tout le rseau. Livelock Le paquet introduit natteint aucune destination et reste tourner indniment dans le rseau, causant un gaspillage de bande passante, latence et consommation dnergie.

76technique de codage des chemins pour la scurit et la reconfiguration 5.2.2.2 Lextraction dinformations secrtes

Elle a pour but de lire des informations protges dans une cible scurise et non autorise. Les information drobes peuvent tre des donnes sensibles, des instructions dun programme critique, des registres de conguration et bien dautres. 5.2.2.3 Laltration du comportement

Elle consiste en une criture dans le but de modier le comportement ou la conguration du systme. Cette pratique est appele Hacking. Elle peut avoir des ns malveillantes, tel que lespionnage ou la dtrioration du systme. 5.2.2.4 La rtro-ingnierie et lextraction dinformations secrtes par accs de proximit

La rtro-ingnierie (ou Reverse engineering) est lactivit qui consiste tudier un systme pour en dterminer le fonctionnement. Par un accs physique au circuit, lattaquant peut tenter de drober des informations de proprit intellectuelle par des lectures non autorises, pour obtenir des parties du rmware. Lextraction dinformations secrtes par accs de proximit peut aussi tre ralise par des analyses direntielles de puissance (DPA pour Dierential power analysis) dans le cas dextraction de cl crypte [78].

5.3

Les stratgies de protection

Les techniques classiques de codage et dauthentication ont un cot en surface, temps et consommation dnergie qui ne sont pas compatibles avec le domaine des NoCs. Nous proposons ici des techniques originales.

5.3.1

Garantir le trac contre le dni de service

Une simple solution contre lattaque de dni de bande passante consiste utiliser des canaux virtuels (VCs)[20] pour sparer les communications sres et non-sres. Les canaux virtuels permettent de multiplexer plusieurs tracs sur un mme canal physique. Chaque canal virtuel peut se voir aecter un niveau de priorit, ce qui permet davoir plusieurs classes de priorits de tracs. Nous pouvons utiliser 2 canaux virtuels, un premier de haut niveau de priorit pour assurer les changes scuriss dans la zone sre et un second canal virtuel de faible niveau de priorit et de classe de trac de faible scurit. La zone scurise est donc traverse par deux types de canaux virtuels et donne la priorit aux paquets voluant sur le canal virtuel prioritaire (gure 5.2). Si aucune technique TDMA (Time division multiplexing access) nest disponible pour allouer des slots au trac non sre alors une intgration simple consiste nassigner que le VC de faible priorit la zone non sre. Les communications entre les deux zones nutilisent alors que le VC de faible priorit. Ainsi, les communications scurises de la zone sre sont isoles des potentielles attaques de dni de service. Cependant cette solution ne protge que du dni de bande passante et ne traite pas les droits daccs.

5.3 les stratgies de protection

77

Fig. 5.2 Sparation des tracs sur des canaux virtuels dirents

5.3.2

Filtre multi-frontires

Trois frontires de scurit peuvent tre considres entre les zones sre et non sre. Chacune peut tre quipe dune protection spcique (gure 5.3). La premire protection est une vrication dautorisation laccs aux interfaces du NoC. La seconde est un ltre de chemin insr dans le rseau. La troisime protection est une vrication par la NI destinataire de lidentit de lmetteur qui lui adresse un paquet. Ces trois frontires de scurit sont expliques dans les sections suivantes.

Fig. 5.3 Trois frontires de scurit 5.3.2.1 Frontire 1

Tout le NoC est dans la zone scurise. Certaines IPs sont aussi dans la zone scurise parce quelles sont critiques, mais dautres IPs sont elles dans la zone non sre et doivent pouvoir naccder qu certaines informations dans des fentres de temps limites. La gure 5.4 prsente un exemple. Les dtails de notre NI sont montrs sur la gure 5.5. Les NIs contiennent de nombreux paramtres de conguration. Ces paramtres sont congurables au travers du NoC lui mme. Nous distinguons les lments suivants dans la NI : Un adaptateur de protocole pour communiquer de faon approprie avec le protocole du port de la NI connecte. Une table despace dadressage mmoire qui spcie les droit daccs. De plus, elle permet de convertir ladresse logique demande en lidentit de lIP cible.

78technique de codage des chemins pour la scurit et la reconfiguration Une table de chemins, fournissant les instructions de chemin ncessaires pour atteindre une destination atteignable (autorise). Une table des slots de temps allous pour le GT. Une instruction spciant la bande passante maximale pouvant tre alloue au BE. Ceci permet de maintenir la bande passante dune communication dans une limite spcie.

Fig. 5.4 Exemple de NoC entirement dans la zone sre

Fig. 5.5 Network Interface Le CCM dlivre aux NIs des autorisations daccs mmoire. Les NIs sont limites par ces droits. Une NI doit solliciter le CCM pour demander une nouvelle autorisation. Le CCM peut retirer une autorisation. Ceci nous prmunit des attaques de type dni de service, grce la limitation de la bande passante et nous permet de contrler les droits daccs. 5.3.2.2 Frontire 2

Seule une partie du NoC est dans la zone scurise. Dans ce cas, nous ne pouvons pas avoir conance dans les NIs se trouvant dans la zone non sre. Ainsi, ici, linformation

5.3 les stratgies de protection

79

qui sera vrie ne sera non pas ladresse mmoire logique comme prcdemment, mais le contenu du paquet. En eet, le champ dinstruction de chemin dans lentte du paquet indique comment atteindre la destination, ce qui permet de dduire la destination et correspond donc ladresse logique globale prcdente. Des ltres appels path lter sont insrs dans la zone sre la frontire avec la zone non sre (gure 5.6).

Fig. 5.6 Noc dans la zone sre et non sre Dans ce cas, le CCM dlivre des autorisations relatives des chemins (et non des espaces mmoires logiques comme prcdemment) aux path lters. Un path lter reoit des paquets de la zone non sre et nautorise pntrer dans la zone scurise que ceux qui ont des instructions de chemin autorises. Cette solution empche un metteur de la zone non sre daccder un destinataire auquel il nest pas autoris. De plus, cette vrication par les instructions de chemin nous prmuni des deadlock et livelock. Un path lter ressemble une NI, except quil nest pas connect une IP et na donc pas dadaptateur de protocole, et quil possde une table de chemins la place de la table despace dadressage mmoire (gure 5.7) En pratique, pour viter de perdre du temps, le path lter peut tre intgr dans le port du routeur de la zone sre. Cela permet de procder simultanment la vrication du chemin et ltape de dcodage. 5.3.2.3 Frontire 3

Hypothse de cette tude : Nous proposons ici de faire les vrications sur les informations de la couche rseau. Ainsi, on ne scurise pas une application vis vis dune autre mais assurons lauthentication dun composant connect au NoC an de lui attribuer des droits daccs avec les autres. Pour cela nous nous servons des instructions de chemin comme des marques indiquant au rcepteur le chemin emprunt par le paquet. Lintrt de se servir des instructions, plutt que de marques qui seraient ajoutes par les routeurs traverss, est que nous conomisons de lespace dans lentte du paquet.

80technique de codage des chemins pour la scurit et la reconfiguration

Fig. 5.7 Le path lter De cette faon, un composant destinataire peut vrier lidentit de lmetteur. Ainsi, laccs une mmoire sera autoris depuis certains processeurs et certaines interfaces mais pas depuis dautres. Cette authentication du composant source pourrait tre ralise par un identiant qui serait plac dans lun des champs de lentte du paquet lors de sa cration dans la NI. Cet identiant serait alors consult la rception an de vrier lidentit de lmetteur. Seulement, cet identiant pourrait tre usurp, pour permettre un composant de se faire passer pour un autre. Nous proposons ici de nous appuyer sur la couche transport pour plus de scurit. Ainsi, nous utilisons une technique de codage des instructions de routage qui permet un destinataire de remonter vers lidentit de lmetteur. En eet, la seule information qui ne puisse tre corrompue pour tenter dusurper une identit est linformation de chemin pour atteindre la destination, condition que celle-ci soit unique et dans lhypothse que lintgrit du NoC est garantie bien entendu. Nous appelons cette technique SPA (pour Source Path Authentication)

5.4
5.4.1

Les techniques classiques de codage des instructions de routage


Codage pour le routage ordonn par dimensions X-Y

Le champ des instructions de chemin du paquet contient deux valeurs, X et Y. Ces valeurs sont exprimes soit en relatif la coordonne de lmetteur (le nombre de sauts raliser dans chaque dimension pour arriver au destinataire), soit en absolu (les coordonnes de la destination). Les routeurs acheminent le paquet sur la dimension X puis sur la dimension Y (dans le cas du routage relatif, chaque saut, ils dcrmentent la valeur correspondant cette dimension). Ainsi arrive destination, ces valeurs sont nulles dans le cas du routage relatif et valent les coordonnes de la destination dans le cas du routage absolu.

5.5 exploitation de linformation de routage

81

5.4.2

Codage street-sign

Le codage street-sign utilise une liste dinstructions du type Nord, Sud, Est, Ouest et descendre, indiquant la direction prendre chaque routeur, ou des routeurs identis. Une fois excute, linstruction courante est supprime et les instructions restantes sont dcales pour que la suivante prenne sa place en tte de liste. Ainsi, la rception, les instructions ont toutes t supprimes. Conserver ces instructions ne serait pas susant pour identier lmetteur car ce type dinstruction ne permet de connatre que le port de sortie du routeur et pas le port par lequel le paquet est entr.

5.4.3

Analyse

Ces codages ne permettent pas au destinataire dauthentier la provenance du paquet. Nous proposons donc lapproche suivante.

5.5
5.5.1

Exploitation de linformation de routage


Principe du codage relatif pour lauthentication

Nous expliquons ici comment nous pouvons utiliser linformation de routage pour son utilisation au niveau de la destination. Nous avons vu quavec les techniques classiques, les informations de routage ne sont pas conserves ou sont inexploitables au niveau de la destination. Notre technique de codage des instructions de chemin doit orir une clef unique destination permettant didentier lmetteur. Nous proposons une technique de codage avec des perfectionnements qui permettent de tirer parti de cette information pour deux objectifs, la scurit et la reconguration. Notre codage fonctionne sur le modle du codage street-sign, mais de manire relative. Le port de sortie dun routeur est indiqu relativement au port par lequel le paquet est entr. Ainsi, dans le routeur, comme cela peut se faire dans le cas dun rond point, la sortie est indique par son occurrence partir de lentre par laquelle le paquet est arrive. Comme le montre la gure 5.8, nous avons choisi arbitrairement de compter le numro des sorties dans le sens inverse des aiguilles dune montre dans le ` cas dune topologie 2D. Le paquet sortira par la neme sortie. De plus, les instructions doivent tre prserves. Ainsi, les instructions ne sont plus supprimes aprs avoir t excutes, mais dcales de faon circulaire. Le champ des instructions de chemin du paquet indique ainsi de faon unique lidentit de lmetteur. Lmetteur ne peut se faire passer pour un autre auprs dun destinataire car en mentant sur ses instructions de chemin, il narriverait pas ce destinataire. Aucun champ supplmentaire nest utilis. Cest donc une faon simple et sans surcot de disposer dune trace indiquant la provenance dun paquet, une sorte de passeport ou certicat didentit. Proprit 1 : Le champ des instructions de chemin du paquet constitue un certicat permettant au destinataire de vrier lidentit de la NI met-

82technique de codage des chemins pour la scurit et la reconfiguration

Fig. 5.8 Le codage des instructions de chemin selon un codage relatif la source trice.

5.5.2

Le complment automatique du chemin (SCP)

Notre technique de codage peut aussi permettre de construire le chemin inverse de faon automatique. Nous appelons cela le codage SCP (Self Complemented Path). En eet, le chemin retour peut tre dduit du chemin aller et de larit (nombre de ports) de chacun des routeurs traverss. Le nombre de ports de chaque routeur nest pas connu du rcepteur, en revanche chaque routeur est bien plac pour connatre son nombre de ports. Ainsi, le remplacement des instructions aller par les instructions retour est fait au l de la traverse des routeurs (gure 5.9).

Fig. 5.9 Les instructions de chemin aller et retour Proprit 2 : chaque routeur, la somme de linstruction courante dans le sens aller et de linstruction correspondante dans le sens retour est gale larit du routeur. Quand le manager (CCM) cre une connexion entre deux NIs, NIa et NIb, il ne leur

5.5 exploitation de linformation de routage

83

donne que les instructions aller. Lorsquils schangent des paquets, chaque routeur travers excute linstruction de chemin courante et la complmente en fonction de son arit et dcale les instructions de faon circulaire comme expliqu dans la gure 5.9. La restriction que nous nous xons ici est que les paquets aller et retour empruntent exactement les mmes chemins mais dans des directions opposes. Proprit 3 : Les instructions dun chemin, une fois complmentes et organises dans lordre inverse, sont identiques aux instructions de chemin dans le sens oppos. Nous notons ceci de la faon suivante : R(AtoB) = BtoA Ainsi, chaque NI vrie la proprit 3, pour authentier lidentit de lmetteur. Si nous voulons nous prmunir des livelocks, il existe deux solutions. Un champ supplmentaire dans lentte du paquet ralise un comptage du nombre de sauts eectus (nombre de liens traverss) et permet aux routeurs de supprimer ce paquet quand ce nombre dpasse une limite xe. Une instruction de n de chemin peut tre utilise (gale 0 dans la gure 5.9). Proprit 4 : Dans la liste des instructions de chemin, une instruction de n de chemin signale que le paquet est arriv destination. Dans le cas dun transfert correct, linstruction de n de chemin ne devient linstruction courante que lorsque le paquet arrive la NI destinatrice. Cette dernire vrie alors que cela est bien le cas. Si ce nest pas le cas le paquet est considr incorrect et est supprim. De plus, chaque routeur vrie deux choses. Premirement il vrie que linstruction courante nest pas linstruction de n de chemin. Deuximement, il vrie que linstruction n de chemin est bien prsente parmi les instructions. Si lune de ces deux conditions nest pas respecte, alors le routeur supprime le paquet. La gure 5.10 montre un exemple. B autorise uniquement A lui mettre des paquets. C tente denvoyer un paquet B. Lorsque la NI de B reoit le paquet, elle vrie le champ des instructions de chemin et le compare ceux autoriss, elle dtecte ainsi lmission non autorise. De plus, le champ des instructions de chemin du paquet reu est celui ncessaire pour rpondre par le mme chemin except le fait que lordre des instructions est invers. Le cot mineur d lopration de complment dans les routeurs est contre balanc par lconomie en mmoire et communication, car le CCM ne fournit que les instructions de chemin pour mettre et un bit de statut par chemin pour indiquer si le sens rception est autoris. Notons que dans le contexte de la scurit lopration de complment nest pas obligatoire. Cependant, elle est intressante puisquelle rend lauthentication dpendante du chemin emprunt et de larit des routeurs traverss. Cette technique est ecace en termes de dlai et dintgration puisque linstruction complmente est code en parallle de ltape de dcodage de linstruction et que la soustraction optimise pour larit du routeur peut tre facilement cble. Le champ dinstructions de chemin pour rpondre au CCM est stock dans toutes les NIs, de sorte quelles puissent lidentier et que lon ne puisse usurper son identit.

84technique de codage des chemins pour la scurit et la reconfiguration

Fig. 5.10 Exemple dauthentication par le chemin

5.5.3

Utilisation pour la reconguration

Notons que la proprit 2 a un autre grand intrt que nous appelons Trusted Boomerang Path (TBP). Si la scurit nest pas le but recherch, la proprit de transformer le chemin aller en chemin retour est utile pour permettre un bloc IP esclave de rpondre une requte de lecture mise depuis nimporte quel bloc IP matre. Ainsi, aucune table de chemin nest ncessaire pour indiquer le chemin des esclaves vers les matres, ce qui revt un intrt majeure en termes de conguration et dconomie de taille mmoire. Le paquet reu par lesclave fournit directement les instructions de chemin ncessaires pour rpondre au matre en question. Ainsi, le grand avantage de cette technique est que lesclave peut ignorer la localisation du matre, ce qui permet la mobilit des IPs dans un systme recongurable [79]. Une transaction entre un matre et un esclave est dcrite sur la gure 5.11. Le matre NIa utilise lauthentication SPA alors que lesclave NIb utilise le TBP pour rpondre. La technique SCP ralise le complment des instructions de chemin.

Fig. 5.11 Boomrang

5.6 contre-attaque

85

5.5.4

Le rarrangement binaire automatique des instructions de routage

Le nombre de ports de chaque routeur varie et le nombre de bits ncessaires au codage des instructions peut donc varier aussi. Pour rduire le codage du champ dinstructions, il est donc souhaitable de ne pas utiliser un codage de largeur xe car cela conduirait utiliser la largeur la plus grande et donc un champ de grande taille dans lentte. Si les instructions nont pas la mme largeur, un problme se pose pour inverser lordre des instructions au niveau du destinataire, car celui-ci ne connat pas la taille de chacune et ne voit quun champ de bits. Nous proposons alors la solution suivante. Elle consiste ce que le routeur, en plus de complmenter linstruction courante, inverse le poids des bits de linstruction. Linstruction se retrouve ainsi retourne. Le destinataire na alors plus qu retourner lensemble du champ des instructions de chemin, pour que lordre des instructions soit invers. Cest donc une faon simple dinverser lordre des instructions indpendamment du fait quelles aient des codages de largeurs varies (en nombre de bits) et inconnues du destinataire. Ce principe, conjugu aux SPA, TBP et SCP a fait lobjet dun brevet en 2005. La gure 5.12 montre un exemple. Une source et une destination sont spares par 4 routeurs (R1 R4). Les ports des routeurs ne sont pas tous reprsents. La source dispose des instructions aller destines aux routeurs R1 R4. Au cours du cheminement du paquet les routeurs traverss remplacent linstruction aller par linstruction retour et inversent lordre des bits (poids fort - poids faible). Le destinataire qui na pas connaissance de la taille de chaque instruction retourne lordre des bits de tout le champ dinstruction. Il obtient ainsi le chemin de retour, avec les bonnes instructions de retour et dans le bon ordre.

5.5.5

Encryptage du bitstream

La conguration du CCM doit tre sre, car cest le point cl de la scurit du NoC. Pour empcher un accs mal intentionn au CCM, une technique dencodage standard peut tre utilise. La conguration du CCM nest gnralement pas frquente, donc lencryptage et le dcryptage ne constitueront pas une perte de temps signicative. Quand une zone non sre est intgre dans un FPGA, une authentication classique peut tre utilise pour vrier lidentit dune IP et viter le remplacement de lIP autorise par un usurpateur. Lauthentication de lIP peut tre protge avec une technique telle que lencryptage du bitstream [80].

5.6
5.6.1

Contre-attaque
Raction face un routage erron

Quand une NI de la zone scurise reoit un paquet dun metteur non autoris, elle avertit le CCM. De multiples raisons peuvent tre lorigine de ce rsultat, si bien que le CCM peut ragir de direntes faons :

86technique de codage des chemins pour la scurit et la reconfiguration

Fig. 5.12 Double inversion pour inverser lordre des instructions Premirement, le problme peut tre caus par une erreur de transmission entre lmetteur et le rcepteur. Le CCM demande lmetteur suspect de rmettre la donne perdue. Le problme peut aussi tre le rsultat dune erreur de conguration. Le CCM procde alors la reconguration de lmetteur et du rcepteur. Si lerreur persiste et quun compteur derreurs dans le CCM atteint un seuil spci, le CCM identie cela comme une attaque et rduit zro la bande passante de la NI de lIP en faute.

5.6.2

Rtro-ingnierie et extraction dinformations secrtes par analyse direntielle de puissance

Le NoC peut aussi tre utilis dans lintention daugmenter la scurit du systme. En changeant alternativement les chemins utiliss, lobservation des changes devient plus dicile. De plus, ceci peut tre complt par le changement de place des IPs matres avec la technique TBP prsente. Ceci peut prserver le systme contre des extractions de cls par DPA [78].

5.7 conclusion

87

5.6.3

Supervision de bande passante et de consommation

Le contrle de la consommation dnergie peut tre ralis par le CCM pour contrler le systme en fonction de son esprance de vie. Si la consommation de puissance augmente au dessus dun seuil, le trac BE est rduit pour prvenir le risque dune attaque ayant pour but de vider les batteries [81]. Le CCM est en charge de la conguration, de la surveillance et du contrle des NIs. Cela suppose de la part du CCM une certaine connaissance priori du comportement attendu de lapplication. Ainsi, un prol doit tre ralis et certains seuils doivent tre identis pour permettre au CCM de dtecter un comportement irrgulier du NoC et pour lui permettre par consquent de lancer des ractions en ajustant des paramtres dans les NIs an que le systme retrouve un comportement rgulier. Cet aspect nest pas trait ici et fait lobjet dun nouveau thme de recherche au laboratoire LESTER.

5.7

Conclusion

Nous avons vu les direntes attaques que peut subir un NoC. Nous avons galement vu comment un NoC peut tre protg au moyen de path lter, ou NI scurise. Une technique de codage des instructions de chemin appele SCP permet un destinataire dauthentier lidentit de lmetteur du paquet. Dans lhypothse ou lintgrit de la topologie du NoC est assure cette technique est able. Et surtout elle ne comporte pas de cot supplmentaire en terme de contenu dans lentte du paquet contrairement un identiant qui serait ajout. Nous avons vu comment cette technique peut permettre dorir de la mobilit aux IPs matres. Le tableau 5.2 montre les direntes attaques et indique par un X les protections adaptes.

88technique de codage des chemins pour la scurit et la reconfiguration

Scnario dattaque

Stratgies de protection Surveillance et contrle des bandes passantes X

NIs dans la zone sre

Dni de bande passante Chemin incorrect Deadlock Livelock Lecture non autorise Ecriture non autorise Extraction dinformation Observation en fonctionnement

X X X X X X X X X X X X X X X X

Bitstream encod

path lter

VCs

X X X

Tab. 5.2 Les stratgies de protection aux attaques

Mobilit des IP avec TBP X X

SPA

Chapitre 6

NoC avec trac garanti dans une approche de type GALS


6.1 Introduction

Les futurs systmes sur puce ne permettront plus la distribution dune horloge globale sur lensemble du circuit. Le rseau doit donc prendre cette contrainte en compte. Nous proposons ici une solution qui vise conserver la garantie de service oerte par les TDMAs, tout en tant compatible avec des dcalages dhorloges et des horloges htrognes du circuit [82].

6.2
6.2.1

La synchronisation et la QoS
Problmatique

Pour sintgrer avec les rgles de conception des systmes synchrones, lintgration traditionnelle du NoC repose gnralement sur une horloge systme globale avec des dphasages ngligeables (skew). Cette hypothse de conception nest pas compatible avec les futurs SoCs dans lesquels il faudra plusieurs cycles dhorloge pour transporter un signal au travers de la puce [7]. Dans le cas idal, un dlai de 100 pico secondes est ncessaire pour traverser en diagonale une puce de 22mm de cot avec une technologie 50nm. En pratique, avec une horloge 10GHz, il est estim quil faut entre 6 et 10 cycles dhorloge pour traverser le circuit. Ceci pause un problme de synchronisation. De plus, la conception dun arbre dhorloge distribuant celle-ci de faon uniforme sur lensemble du circuit deviendra trs dicile [5]. On ne pourra donc plus assurer une synchronisation totale de lhorloge sur lensemble de la puce. Un autre dfaut de lintgration des NoCs traditionnels, est celui de lutilisation dun domaine dhorloge unique, alors que les larges SoCs tendent se rpartir en plusieurs domaines dhorloge, notamment pour des raisons de consommation. Enn, des circuit multi-curs (multi-core) ou bien systme multi-puce, impliquent intrinsquement des horloges distinctes. Tous ces cas compliquent la conception et impliquent des challenges au concepteur de NoC qui devra raliser des circuits de grande taille o les besoins sont grandissants

89

90

noc avec trafic garanti dans une approche de type gals

en terme de exibilit, de capacit stendre, de QoS et de gestion des communications.

6.2.2

Synchroniser un systme

Il existe plusieurs mthodes pour synchroniser un systme : Lapproche traditionnelle est celle du systme synchrone, qui consiste utiliser une horloge globale sur tout le systme avec un dcalage de phase pouvant tre nglig. La seconde approche est la ralisation dun systme totalement asynchrone. Les communications se font alors par un protocole de poigne de mains, ou bien par des mcanismes spciaux au niveau logique (2 ou 4 phases). Lasynchrone a pour avantage de rduire la consommation dynamique. La troisime mthode consiste utiliser des blocs synchrones qui communiquent entre eux de faon asynchrone. Ce concept est appel GALS (Globally asynchronous, locally synchronous). Il a pour avantage de permettre dintgrer ensemble des domaines dhorloges dirents. Une autre approche consiste en la distribution dhorloges mesochrones [83]. Une horloge commune est distribue sur tout le systme. Les direntes parties du systme ont une horloge de mme frquence, mais des phases direntes. Ainsi, chaque partie peut fonctionner comme un systmes synchrone. Les communications entre ces parties ncessitent une adaptation pour saccommoder du dcalage de phase. Enn, il existe les systmes plesiochrones (1) . Les systmes sont presque parfaitement synchroniss, mais dirent lgrement en fonction de leurs horloges qui sont locales. La dirence est maintenue dans une limite spcie.

6.2.3

tat de lart de la gestion de la QoS et des horloges dans les NoCs

Les NoC peuvent tre classs par catgories en fonction de leur utilisation de lhorloge et de la qualit de service quils assurent leurs communications. Lapproche traditionnelle considre un NoC synchrone avec un domaine dhorloge unique. Elle a pour avantage de permettre dobtenir un systme parfaitement dterministe. Ainsi, elle permet lutilisation dun TDMA au travers du circuit pipelin pour assurer un fonctionnement qui a t pr-ordonnanc pour satisfaire la QoS [22] [21]. Cela signie que tous les lments routeurs et NIs ont une horloge commune. De plus, le dlai dacheminement sur un lien du rseau doit se faire en moins dun cycle dhorloge an que le pipeline des routeurs traverss soit respect. Notons quil y a gnralement tout de mme une frontire de synchronisation entre les NIs et IPs, ralise laide de FIFOs double horloge. Une autre approche consiste utiliser des communications asynchrones entre des composants synchrones (GALS). Dans [84], les auteurs proposent un crossbar asynchrone, seulement la contrainte de temps rel nest pas considre. Lapproche de type GALS est utilise par la solution industrielle fournie par Arteris [13]. Des IPs sont regroups en clusters. Les changes dans les clusters sont synchrones
(1)

Le terme plesiochrone est driv du Grec plesio (proche) et chronos (temps)

6.2 la synchronisation et la qos

91

et garantis. Un rseau dinterconnexion asynchrone permet de transporter des paquets entre des groupes ou ensembles (clusters) dIPs synchrones. Les changes inter-clusters raliss par des changes asynchrones norent eux pas de garantie stricte . La conception dun systme sans aucune horloge est la version ultime de lasynchrone, cest la solution intgre par [85] et [86]. Dans le premier cas, des canaux virtuels et des routeurs avec de faibles latences sont utiliss, cependant larchitecture du NoC nore pas de garantie de bande passante. Dans le second cas, un ordonnancement appel ALG (Asynchronous Latency Guarantee) est utilis. La garantie est obtenue sous certaines conditions. Il faut en eet que le dlai maximum de transmission dun it soit connu et que lintervalle inter-its soit born. Cette approche est intressante, cependant, lintgration dun grand nombre de tracs garantir, se traduit par lajout de nombreux canaux virtuels ce qui implique une augmentation importante du cot en surface au niveau des routeurs. Les avantages principaux des solutions sans horloge sont linsensibilit la latence et la rduction de la consommation car il ny a pas de transition quand le systme est inactif. Cependant, ces solutions requirent une implantation spcique utilisant gnralement un protocole double rail quatre phases, o chaque bit est cod sur quatre ls. Cest le cas des solutions [85] et [86], o les exemples dimplantations ne sont donns que pour un seul routeur. La consommation dynamique est rduite avec un NoC asynchrone, mais la surface ncessaire pour son implantation peut augmenter sa consommation statique.

6.2.4

Contexte dans lequel nous nous plaons

Du point de vue de la qualit de service : La technique par TDMA est une technique ecace et simple pour assurer la qualit de service, mais ncessite une notion de synchronisation pour que le comportement pr-ordonnanc soit respect. Du point de vue des horloges : La rutilisation de ce qui a dj t conu impose dtre compatible avec les architecture synchrones et les outils de conceptions construits autour des protocoles de communication standards. De plus, les larges SoCs tendent se rpartir en plusieurs domaines dhorloges. Le concept de GALS semble donc tre la solution la plus adapte. Enn, il est possible davoir des parties du circuit qui ont une horloge de mme frquence mais pas de mme phase. On doit aussi faire face a des liens qui ont un temps de traverse suprieur un cycle dhorloge. Il est donc aussi ncessaire de traiter laspect des parties msochrones. Nous cherchons donc la fois conserver la QoS par lutilisation de TDMAs tout en se mettant dans le contexte de domaines dhorloges dirents et de sous parties msochrones.

6.2.5

Rsum de lapproche dveloppe

Notre objectif a t de conserver la QoS laide du TDMA, mais dans un contexte de GALS qui rpond mieux aux futures contraintes dimplantation de la distribution de lhorloge dans les SoCs. La gure 6.1 illustre notre approche. Cette solution consiste en le dcoupage du rseau global du circuit en zones de mme horloge appeles sous-rseaux ou sub-NoCs. Chacun des sub-NoCs fonctionne de

92

noc avec trafic garanti dans une approche de type gals

manire synchrone (ou vu comme synchrone), ainsi son comportement est prdictible et permet dutiliser un TDMA pour lordonnancer et garantir le trac qui le parcoure. De plus, un sub-NoC peut tre lui mme divis en sous parties msochrones.

Fig. 6.1 NoC GALS avec QoS Il y a donc deux dicults surmonter : ` A lintrieur dun sub-NoC, il faut pouvoir masquer le problme de liens qui ont un dlai de traverse trop long pour permettre le pipeline de la communication au travers du sub-NoC. De plus, il faut pouvoir saccommoder des parties msochones. Pour cela, on introduit le concept de routage temporel (TR pour time-routing) qui ralisera linterface. De plus, il faut pouvoir garantir le trac au niveau global, cest dire sur tout le circuit. Nous proposons des interfaces de synchronisation qui vont permettre de faire tampon entre les dirents sub-NoCs qui sont ordonnancs individuellement avec leur propre table TDMA. ` laide de nos deux types dinterfaces, la QoS du trac est assure sur toute la A puce malgr lhtrognit des horloges.

6.3
6.3.1

Le routage temporel
Problmatique

Pour que lordonnancement des communications par le TDMA soit correct, il est impratif que les its des paquets arrivent un moment bien dtermin. Le routage temporel rpond au problme pos par les liens avec des dlais suprieures la dure

6.3 le routage temporel

93

dune priode dhorloge, ainsi quau problme du dcalage de phase (skew) des horloges entre deux parties dun sub-NoC (parties msochrones) (gure 6.2).

Fig. 6.2 Le skew entre les horloges Le bon verrouillage des donnes lextrmit de rception du lien dpend du dlai de transmission qui est lui-mme fonction des caractristiques du lien physique sur lequel les donnes circulent et du dcalage (skew) entre les horloges chaque extrmit du lien. Un mauvais verrouillage rompt le pipeline instaur par le TDMA pour le cheminement des paquets dans le sub-NoC et par l mme la garantie de service. La solution classique utilisant des stations relais [87] o le pipeline sur le lien ncessite la connaissance priori du dlai sur le lien et dajouter des lments le long de ce lien pour le pipeliner. Le problme est que cet ajout peut remettre en cause le placement et le routage et ainsi dplacer le problme. De plus, dans le cas extrme ou le sub-NoC se trouverait rparti sur deux puces distinctes, ces solutions ne pourraient pas sintgrer sur le lien entre les deux circuits du silicium.

6.3.2

Architecture

Pour se prmunir des variations de skew et des dlais des liens, ces deux valeurs sont bornes par des valeurs maximales. Pour pouvoir garantir le pr-ordonnancement, le dlai considr est le pire cas, de sorte que ce dlai soit toujours le mme (ni infrieur, ni suprieur) quelles que soient les variations de ces deux valeurs dans les limites xes. Ce contrle est ralis en intgrant deux lments, le codeur temporel (TC pour Time Coder) et le routeur temporel (TR pour Time Router) dans le port de sortie du routeur metteur et dans le port dentre du routeur rcepteur respectivement (gure 6.3).

6.3.3

Calcul de la taille de la FIFO

Pour raliser linterface entre les deux domaines temporels, nous utilisons une FIFO double horloge et transportons le signal dhorloge du TC vers le port dcriture de la FIFO dans le TR. Larchitecture de la FIFO double horloge nest pas dtaille ici. Le TC ajoute une instruction de numro de slot temporel dans lentte des paquets qui le traversent. Linstruction de numro de slot temporel indique au TR le slot temporel durant lequel il devra mettre ce paquet. Le TR na pas de table TDMA,

94

noc avec trafic garanti dans une approche de type gals

Fig. 6.3 Le Routage temporel cependant il est conscient du slot temporel courant grce un simple compteur qui incrmente les slots qui scoulent (dans son domaine temporel propre). Le paquet reu par le TR est stock dans une FIFO et expdi uniquement quand le slot temporel courant et le slot temporel de linstruction sont identiques. La gure 6.3 montre larchitecture du codeur temporel et du routeur temporel, de chaque cot dun lien unidirectionnel dont le dlai est incertain. Notons que lexcution des TC et TR se fait en parallle avec lexcution des routeurs, ainsi, il ny a pas de dlai supplmentaire introduit sinon celui spci. Nous allons dterminer la dirence maximale des slots de temps an de spcier linstruction de slot de temps et de calculer au plus juste la profondeur de FIFO requise. Rappel : nous notons Ls la largeur dun slot en nombre de phits (ou mots) et |S| la taille de la table TDMA en nombre de slots. De plus, nous dnissons les sigles suivants : CT Sx : le slot de temps courant dans le routeur metteur x. CT Sy : le slot de temps courant dans le routeur rcepteur y. T SIx,y : linstruction de slot de temps fournie par le domaine dhorloge x et excuter dans le domaine dhorloge y : 0 T SIx,y < |S|. SkewU px,y : limite suprieure du dcalage (skew) en nombre de cycles entre les horloges du routeur metteur x et du routeur rcepteur y. SkewLowx,y : limite infrieure du dcalage (skew) en nombre de cycles entre les horloges du routeur metteur x et du routeur rcepteur y. T U px,y : temps maximum pour un phit pour traverser le lien (en nombre de cycles).

6.4 synchroniseur de tdmas

95

T Lowx,y : temps minimum pour un phit pour traverser le lien (en nombre de cycles). Si cette valeur est inconnue, nous prenons la valeur 1. Le nombre de cycles maximum de dcalage entre les deux routeurs est la somme des temps maximum pour traverser le lien et leur skew : CU px,y = T U px,y + SkewU px,y Le nombre de cycles minimum de dcalage entre les deux routeurs : CLowx,y = T Lowx,y + SkewLowx,y Le nombre de slots de temps de dirence entre les deux routeurs : Deltax,y = CU px,y Ls (6.3) (6.2) (6.1)

Linstruction de slot de temps pour le rcepteur y est la somme du slot de temps courant du domaine x et du nombre de slot de dirence entre les deux domaines : T SIx,y = (CT Sx + Deltax,y )%|S| La profondeur de la FIFO : si (CLow < 0) alors F DEP T H = |S| Ls sinon F DEP T H = min(Deltax,y Ls , |S| Ls ) (6.6) (6.5) (6.4)

La valeur de Deltax,y peut aussi bien tre ajoute dans le TR que dans le TC. De plus, cette valeur peut tre statique et prcongure.

6.4
6.4.1

Synchroniseur de TDMAs
Principe

Le synchroniseur de TDMAs sadresse aux liens entre les sub-NoCs. Il tend le concept de NI celui dinterface de sub-NoC, en permettant dinterconnecter deux sub-NoCs par un lien, tout en respectant leurs TDMAs respectifs. Lobjectif est de garantir la bande passante et la latence globale en traversant dirents sub-NoCs. Pour illustrer notre concept, nous considrons le NoC de la gure 6.4. Le sous rseau 2 ore une garantie de trac aux communications qui le traversent. Pour garantir la bande passante et la latence pour la communication entre A et B, il faut que la bande passante rserve dans chacun des sub-NoCs soit susante. De plus, la latence maximale tient compte de lattente maximale pour accder aux slots rservs dans la table TDMA de chaque sub-NoC. Une paire de synchroniseurs, dtaille gure 6.5, est introduite entre les sub-NoCs tel un pont entre les deux domaines dhorloge et de TDMA. Chaque synchroniseur a

96

noc avec trafic garanti dans une approche de type gals

Fig. 6.4 Un NoC form de trois sub-NoCs interconnects

Fig. 6.5 Une paire de synchroniseurs avec le dtail de larchitecture du second deux parties, la premire synchronise le trac (trac synchronizer) alors que la seconde fait suivre le trac dans le sens oppos (trac forwarder). Les synchroniseurs sont connects ttes bches. La partie trac forwarder du synchroniseur 1 est connecte au trac synchronizer du synchroniseur 2 et vice versa. Seule larchitecture du synchroniseur 2 est dtaille sur la gure 6.5. Un synchroniseur appartient au sub-NoC vers lequel son module trac synchronizer envoie les communications. Il est vu comme une NI de ce sub-NoC. De mme quune NI classique, la table de TDMA contenue dans le synchroniseur a t prcalcule pour tre en accord avec lordonnancement de ce sub-NoC. Ainsi, chaque sub-NoC voit un sub-NoC voisin comme une NI classique. Un paquet quitte un sub-NoC en traversant le module trac forwarder de son synchroniseur. Quand il arrive au synchroniseur distant, il est stock dans la FIFO double horloge. Le dcodeur dentte utilise lidentiant de FIFO de lentte du paquet pour dterminer la FIFO dans laquelle il doit stocker le paquet. Le nombre de FIFOs

6.4 synchroniseur de tdmas

97

et larchitecture du synchroniseur dpend des paramtres du problme et des choix du concepteur qui seront dcrits dans les paragraphes suivants. Lordonnanceur du TDMA slectionne la FIFO lire en fonction des rservations de slots dans la table de TDMA. De plus, en fonction de lidentiant de la FIFO qui avait t slectionne, le champ relatif aux instructions de routage de lentte du paquet reoit les instructions de routage appropries pour traverser le prochain sub-NoC. La garantie de service de ce trac est possible si et seulement si la bande passante oerte par les slots rservs pour cette communication dans ce sub-NoC permet de faire passer la fois le dbit de ses donnes et les enttes de ses paquets. Nous prciserons ce point dans la section 6.4.4.2.

6.4.2

Le contrle de ux de bout-en-bout

Pour sassurer quaucun dpassement de capacit ne puisse avoir lieu dans linterface de rception, un contrle de ux de bout-en-bout est utilis. Il repose sur un systme de crdit dmission. Les crdits reprsentent la quantit de places libres dans la FIFO de rception. linitialisation de la connexion entre un metteur et un rcepteur, la totalit de la profondeur de la FIFO de destination est alloue lmetteur. Cette FIFO est appele round trip buer, elle a pour rle de cacher le dlai dacheminement des donnes et le dlai de retour des crdits. Lmetteur peut uniquement envoyer des donnes au rcepteur dans la limite des crdits dont il dispose. De plus, lmetteur dcrmente cette valeur chaque fois quil envoie une donne vers cette destination. Le rcepteur retourne des crdits dmission lmetteur lorsquun nombre susant de donnes a t consomm et donc quun nouvel espace libre est disponible dans sa FIFO de rception. La politique de contrle de ux peut tre introduite dirents niveaux hirarchiques, soit au niveau global soit au niveau sub-NoC. Le contrle de ux entre les NIs au travers du NoC complet est appel global. Le contrle de ux indpendant dans chaque sub-NoC est local. Le choix entre ces deux politiques dpend de conditions expliques dans les paragraphe suivants. 6.4.2.1 Le contrle de ux global, niveau NoC

Au niveau global, le contrle de ux se fait rellement entre les NIs qui ont instaur une communication, ceci au travers de tout le rseau. Ainsi, plusieurs sub-NoCs peuvent tre traverss par cette communication. Cela signie que des communications qui partagent un mme chemin de part en part dun sub-NoC sont considres comme une seule communication du point de vu de ce sub-NoC comme le montre le sub-NoC2 de la gure 6.6. De plus, les modules relatifs au contrle de ux par crdit dmission (gure 6.5) sont ts des synchroniseurs. Dans un trac synchroniseur, une seule FIFO est associe chaque (sous)destination dans ce sub-NoC, indpendamment de lmetteur originel de cette communication. Ainsi, le sub-NoC2 de la gure 6.6 regroupe les communications provenant de A et B car elles vont toutes les deux au mme synchroniseur. En revanche, le sub-NoC3 place ces deux communications dans des FIFOs direntes car elles vont des destinations direntes.

98

noc avec trafic garanti dans une approche de type gals

Fig. 6.6 Contrle de ux de bout-en-bout au niveau global, niveau NoC Le contrle de ux au niveau global, cest dire au travers de tout le NoC, peut ncessiter des FIFOs (round trip buer) de grandes profondeurs dans les NIs de destination pour pouvoir masquer le temps daller des donnes et de retour des crdits. Ceci est particulirement vrai si la distance parcourue par une communication au travers du NoC est longue et parseme de nombreux sub-NoCs. Un aspect qui peut tre intressant est celui de la cohrence entre les tables TDMA des sub-NoCs interconnects. Les tables TDMAs de deux sub-NoCs sont dites cohrentes si les paquets traversant de lun vers lautre sont entirement mis et consomms dans le mme ordre. Dans ce cas, une seule FIFO est ncessaire pour stocker les paquets dans la partie trac syncronizer des synchroniseurs au lieu dune FIFO par destination. 6.4.2.2 Le contrle de ux au niveau local, niveau sub-NoC

Au niveau sub-NoC, le contrle de ux se fait localement, lintrieur de chacun des sub-NoCs traverss. Les synchroniseurs sont alors considrs comme des NIs parts entires. Dans un trac synchroniseur, une FIFO est assigne non pas chaque destination de ce sub-NoC comme dans le cas prcdent, mais chaque paire metteur-destinataire (au niveau du NoC) de cette communication. Les messages sont dpaquets quand ils quittent un sub-NoC et rempaquets pour entrer dans un autre sub-NoC. Le contrle de ux local chaque sub-NoC se traduit par une multitude de petits contrles de ux (gure 6.7). Les aller-retours des donnes et crdits sont courts mais nombreux. Le cot en FIFO induit par le contrle de ux par crdit est distribu sur lensemble des TDMAs synchroniseurs traverss, au lieu dtre uniquement dans les NIs de destination. De plus, chaque sub-NoC se sut lui mme en taille de FIFO, indpendamment de ses voisins. Ainsi, un sub-NoC peut tre vu comme une seule et mme IP.

6.4 synchroniseur de tdmas

99

Fig. 6.7 Contrle de ux de bout-en-bout au niveau local 6.4.2.3 Comparaison entre les contrles de ux global et local

Le choix entre les deux types de contrle de ux dpend de la nature des contraintes. Pour une application donne, la somme des profondeurs des FIFOs requisent par le contrle de ux local est gale ou lgrement suprieure celle du contrle de ux globale. Cette lgre dirence peut tre cause par la sub-division de la FIFO (round trip buer) dans le cas du contrle de ux local car la profondeur dune FIFO tant un nombre entier, par arrondi, cela peut conduire une lgre dirence. Le contrle de ux local utilise donc des FIFOs plus petites mais plus nombreuses, cela implique donc aussi plus de contrles (incluant les compteurs de crdits), de plus un problme de la distribution des profondeurs des FIFOs apparat (une FIFO par paire metteur-destinataire au lieu dune seule par destinataire). Lavantage du contrle de ux local rside dans la subdivision quil implique, facilitant la rutilisation et la reconguration indpendante des sub-NoCs. Dans le cas o il y a de nombreuses communications direntes entre deux subNoCs, le contrle de ux global est prfrable. Si un faible nombre de communications est spci, alors le contrle de ux local est plus appropri puisque le nombre de FIFOs reste raisonnable. De plus, la ncessit de redimensionner la taille du paquet nexiste que dans le cas du contrle de ux global comme nous le verrons dans la section 6.4.4.

6.4.3

Instructions de routage

Les instructions de routage indiquent le chemin que le paquet doit suivre pour atteindre sa destination au travers des lments du NoC. Nous nous plaons dans le cas dun routage par la source. Les instructions sont codes dans un des champs de lentte du paquet. Le paquet est ici amen traverser plusieurs sub-NoCs et donc avoir une longue liste dinstructions, cependant, le champ instruction de lentte du paquet doit conserver une taille raisonnable. De plus, il est prfrable que les chemins au travers de chaque

100

noc avec trafic garanti dans une approche de type gals

sub-NoC soient les plus indpendants possible de sorte que lon puisse opter pour des chemins alternatifs sans en rfrer au reste du NoC. Pour toutes ces raisons, nous codons le chemin du paquet sous la forme didentiants qui indiquent un synchroniseur la destination atteindre dans le prochain sub-NoC traverser (gure 6.8). Le synchroniseur consulte alors une table de chemin et remplace lidentiant par les instructions de chemin suivre pour traverser ce subNoC et atteindre soit un autre synchroniseur amenant sur un autre sub-NoC, soit vers la NI destinatrice nale. De plus, notons que lorsquun paquet quitte un sub-NoC, les instructions prcdemment utilises pour le traverser sont eaces, ce qui ore de la place pour insrer les instructions relatives la traverse du sub-NoC suivant. Cette distribution de la connaissance du chemin rduit donc la taille du champ dinstruction de routage, permet une plus grande souplesse pour la reconguration et permet lextension, ce qui est donc dans lesprit du concept de NoC.

Fig. 6.8 Les instructions de routage dans lentte du paquet au travers des sub-NoCs

6.4.4
6.4.4.1

Redimensionnement de la taille des paquets dans le cas du contrle de ux global


Formulation du problme

Dans le contexte de lutilisation dune technique TDMA, le nombre de slots conscutifs rservs (fentre denvoi) pour une communication peut ne pas tre le mme dans les dirents sous-NoCs traverss. Ceci est d aux tailles direntes des tables de TDMA des sub-NoCs ou encore la dirence des dbits de ces sub-NoCs. Nous considrerons ici quune communication ne dispose que dune fentre denvoi par tour de table, ce qui a du sens car cela rduit le cot de lentte et de plus simpliera lexplication. Ceci nous conduit au problme du redimensionnement des paquets, avec des oprations de division et de fusion. En eet, il peut tre ncessaire de diviser, voir linverse de fusionner des paquets pour que leurs tailles soient appropries la taille des fentres denvoi. Ceci suppose un cot en contrle pour rorganiser les paquets.

6.4 synchroniseur de tdmas

101

Quand un paquet doit tre divis en deux parties, son entte est copi pour servir dentte la seconde partie. Cette duplication de lentte occupe de la bande passante. Il faut donc veiller ce que la bande passante des donnes transportes soit toujours assure. La bande passante occupe par les enttes est dautant plus importante que les paquet sont petits. La reconstruction ou fusion de paquets appartenant une mme transaction, implique, elle, de supprimer un entte. Cependant les paquets intercals avec dautres paquets nappartenant pas la mme transaction ne peuvent pas tre fusionns, except si des FIFOs distinctes sont utilises pour sparer les paquets appartenant une mme transaction. Ceci parait extrmement complexe. Notons que si on est dans le contexte dun contrle de ux global, le transport de crdit dans les enttes implique quelques amnagements. Lors de la division de paquet, linformation de crdit ne doit pas tre duplique lors de la duplication de lentte. De mme, lors de la fusion, si lentte supprimer transporte des crdits, il faut videmment les sauvegarder et les attribuer au prochain entte. De plus, le dimensionnent de la FIFO (round trip buer) doit avoir pris cet aspect en considration. Le redimensionnement des paquets peut introduire une dgradation de la bande passante, cela peut tre acceptable dans certain cas, cependant le mieux est de pouvoir viter dy recourir. 6.4.4.2 Solutions

Considrant une communication allant du sub-NoCi vers le sub-NoCj , nous comparons dans le tableau 6.1 les tailles des fentres denvois entre ces deux sub-NoC voisins et donnons les rgles respecter. taille de la fentre denvoi du sub-NoCi compare celle du sub-NoCj > Rgles

=1

La bande passante oerte par le sub-N oCj doit tre susamment grande pour supporter la bande passante oerte par le sub-N oCi et pour pouvoir transporter le ou les enttes supplmentaires introduits par la division du paquet La bande passante oerte par le sub-NoCj doit tre au moins gale la bande passante oerte par le sub-NoCi Le paquet ne peut dbuter son mission que durant le premier slot de la fentre denvoi. On sassure ainsi quil ne sera pas divis. La bande passante oerte par le sub-NoCj doit tre au moins gale la bande passante oerte par le sub-NoCi

Tab. 6.1 Taille des fentres denvoi et rgles Une solution simple pour obtenir le mme nombre de slots rservs et la mme bande passante pour les communications dans chaque sub-NoC consiste conserver le mme rapport frquence (fN oCi ) sur taille de table TDMA (SN oCi ). La gure 6.9

102

noc avec trafic garanti dans une approche de type gals

montre un exemple avec deux sub-NoCs de tailles de tables TDMAs direntes et fonctionnant des frquences direntes. En eet la bande passante du lien est BL = Lp fN oC et la bande passante dun slot est BS = BL |S| (6.8) (6.7)

ainsi, la bande passante dun slot rserv dans un N oCi est BSNoCi = Lp fN oCi |SN oCi | (6.9)

et la bande passante dun slot rserv dans un N oCj est BSNoCj = donc, BSNoCi = BSNoCj si fN oCj fN oCi = |SN oCi | |SN oCj | (6.11) Lp fN oCj |SN oCj | (6.10)

ainsi, les bandes passantes dun slot dans chacun de ces deux sub-NoCs sont gales si ces sub-NoCs ont le mme rapport frquence sur taille de table TDMA.

Fig. 6.9 Le rapport frquence sur taille de la table TDMA

6.5 application et rsultats

103

6.5
6.5.1

Application et rsultats
Contexte de lapplication

` Nous considrons une application de tlcommunication de 4eme gnration. Il sagit dun codeur/dcodeur intgrant une technique de communication MC-CDMA et MCSS-MA en bande de base. La contrainte de lapplication est une cadence de 665,6s pour traiter une frame compose de 32 symboles. Le codeur MC-SS-MA require 18 Ports dIP et le dcodeur MC-CD-MA ncessite lui 32 ports dIP. Les ports dIP sont regroups en 22 clusters. Chacun de ces clusters est connect une NI du rseau. Cette application require 29 transactions sous forme de communications unidirectionnelles entre les lments matriels. Nous utilisons un contrle de ux de bout-enbout, le retour des crdits dmission rend donc les communications bidirectionnelles. Les bandes passantes requises sont trs htrognes. En eet, les communications proches de lantenne dans le graphe de lapplication, qui sont donc les donnes encodes, ncessitent une bande passante trs suprieure la bande passante requise pour les donnes dcodes ou pas encore codes. Cette application est architecture sur une topologie compose de deux parties que nous appellerons zone 1 et zone 2. Cette division est faite de telle sorte que les communications ncessitant une faible bande passante sont regroupes dans la zone 1 alors que celles ncessitant une plus grande bande passante sont regroupes dans la zone 2. Trois communications sont changes entre les zones 1 et 2, elles seront appeles communications inter-zones. Celles-ci reprsentent donc 10% des communications totales. Cette proportion semble reprsentative des communications que nous pouvons esprer dans les futures systmes sur puce dans la mesure o nous devrions avoir une grosse proportion de communications locales, si le placement des ports des IPs est bien ralis. Sur la gure 6.10, nous pouvons voir la topologie de notre exemple. Les zones 1 et 2 seront considres comme formant un NoC unique ou bien comme deux subNoC selon les cas dtudes prsents ci-aprs. Pour des raisons de clart, seules les communications inter-zones sont reprsentes.

Fig. 6.10 Topologie et communications inter-zones de lapplication

104

noc avec trafic garanti dans une approche de type gals

Les caractristiques gnrales du NoC sont ici : un lien ou phit a un largeur de 32 bits, la taille dun it est de un phit, et la taille dun slot est de deux phits, enn, lentte du paquet a une largeur dun phit.

6.5.2

Description des cas dtudes

Nous allons tudier plusieurs cas retant direntes contraintes. Cas 1 : limplantation est celle dun NoC unique classique, sans aucun problme de lien long, ni de dcalage dhorloge. Ce cas correspond un NoC classique, il nous servira de rfrence pour nos comparaisons. Dans les cas suivants (de 2 5), nous supposons avoir un dlai maximum de 50ns entre les deux zones. Cas 2 : un NoC unique utilisant une interface de type routage temporel pour faire face au problme du lien long entre les deux zones. Pour les 3 cas qui suivent, les zones 1 et 2 ont des domaines dhorloge dirents (9 et 100 MHz respectivement). Ils sont intgrs en tant que sub-NoC1 et sub-NoC2. La taille de la table de TDMA du sub-NoC1 nest plus de 6 slots mais de 4 slots ; les autres paramtres restent inchangs. Deux synchroniseurs sont introduits sur le lien entre les deux sub-NoCs. Ces trois cas correspondent aux direntes solutions dimplmentation prsentes prcdemment : Cas 3 : deux sub-NoCs avec des horloges htrognes ; On utilise le contrle de ux de bout-en-bout global. De plus, les TDMAs sont cohrents. Cas 4 : deux sub-NoCs avec des horloges htrognes ; On utilise le contrle de ux de bout-en-bout global. Les TDMAs ne sont pas cohrents. Cas 5 : deux sub-NoCs avec des horloges htrognes ; On utilise le contrle de ux de bout-en-bout local. Les cas considrs sont rsums dans la table 6.2.
Cas 1 2 3 Zone 1 F MHz |S| 100 6 100 9 6 4 Zone 2 F MHz |S| 100 6 100 100 6 6 Commentaires Les tailles des tables TDMAs sont identiques. Le dlai sur le lien est de moins dun cycle. Les tailles des tables TDMAs sont identiques. Le dlai sur le lien est de 5 cycles. Les tailles des tables TDMAs sont direntes. Le dlai sur le lien est de 5 cycles. Les tailles des tables TDMAs sont direntes. Le dlai sur le lien est de 5 cycles. Les tailles des tables TDMAs sont direntes. Le dlai sur le lien est de 5 cycles. Solutions Classique Interfaces de routage temporel Synchroniseurs avec contrle de ux global et TDMAs cohrents Synchroniseurs avec contrle de ux global Synchroniseurs avec contrle de ux local

4 5

9 9

4 4

100 100

6 6

Tab. 6.2 Les cas dtude

6.5.3

Analyse des rsultats

Le tableau 6.3 montre les cots relatifs aux dirents cas tudis. Dans le cas 1, la somme des profondeurs des FIFOs est due la somme des FIFO de dcouplage et de round trip buer dans les NIs. La latence pour la communication C de la gure 6.10 est de 200ns. Le dlai introduit sur le lien dans le cas 2 augmente la latence de 2 slots. En eet la dure normale aurait t de 1 slot, seulement ici comme il faut 5 cycles au lieu dun

6.6 conclusion
cas 1 0 323 0 200 cas 2 2 335 12 240 cas 3 2 348 18 1938 cas 4 3 348 18 1938 cas 5 3 348 18 1938

105

Nombre de FIFOs dans les interfaces Somme des profondeurs des FIFOs Augmentation de la taille des FIFOs pour les 3 communications inter-zones Latence pour la communication note C (ns)

Tab. 6.3 Rsultats de latence et cot en taille de FIFO pour traverser le lien, 3 slots sont alors ncessaires. Laugmentation de la taille des FIFOs a deux raisons : La FIFO dans les TRs (12 mots) : deux routeurs temporels sont ajouts (un dans chaque sens). Chacun dentre eux possde une FIFO. Et la profondeur de cette FIFO est constante (6 mots) et ne dpend pas des communications interzones. Remarque : le cot en FIFO entre deux routeurs tait dj de 2 mots pour chaque sens. La profondeur des FIFOs de round trip buer dans les NIs dpend de la longueur des chemins des communications inter-zones (2 mots). Dans les cas 3 5, la rduction de frquence dans le sub-NoC1 implique une augmentation de latence des communications qui le traversent (+1578ns). Laugmentation de la latence est aussi due la traverse des synchroniseurs pour les communications inter-zones. Le cas 3 bncie de TDMAs cohrents entre les deux sub-NoCs, ainsi le synchroniseur utilise une FIFO unique. Le cas 4 met en uvre des TDMAs non cohrents, avec un contrle de ux au niveau global. Il ncessite plus de FIFO (une FIFO par destination), cependant, la somme des profondeurs des FIFOs reste inchange. Le cas 5 est similaire au prcdant si ce nest quil utilise un contrle de ux au niveau local. Pour conclure, nous observons que la mise en uvre de ces solutions a un cot acceptable dans ces quatre cas, compar au cas de rfrence. De plus, nous observons que la rduction de frquence implique une augmentation de la surface du fait de laugmentation des tailles des FIFOs pour sadapter laugmentation de la latence des communications. Une tude prcise est donc ncessaire pour voir si la diminution de la consommation dynamique est vraiment intressante compare laugmentation de la consommation statique due laugmentation de la surface.

6.6

Conclusion

Nous avons prsent des solutions originales pour garantir la QoS dans le contexte dun NoCs constitu dhorloges avec des dphasages, ou des horloges de frquence diffrentes (ou TDMA dirents). Nous avons propos une solution pour chacun de ces deux problmes (le routage temporel et le synchroniseur de TDMA), incluant dans le dernier cas le concept de composition de sub-NoCs. Cette approche va dans le sens de la productivit pour la conception puisquelle est compatible avec la mthodologie

106

noc avec trafic garanti dans une approche de type gals

des NoCs synchrones classiques et peut tre facilement intgre dans le ot de conception. Lexprimentation nous montre que le cot de ces solutions est acceptable. De plus, nous avons prsent une technique pour traiter les instructions de routage au travers de plusieurs sous rseaux. Cette solution favorise la reconguration et permet lextensibilit. Enn, lutilisation de sub-NoCs , avec des TDMA disjoints et indpendants, rend lintgration du contrleur de NoC plus facile pour introduire un contrle dynamique des tensions et frquences dans le but de rduire la consommation ainsi que pour grer des aspects scurit.

Chapitre 7

Exprimentations et rsultats
7.1 Introduction

Ce chapitre prsente premirement une mise en uvre relle du NoC sur une plateforme FPGA pour connecter 3 microprocesseurs MicroBlazes et leurs RAMs. Ensuite, nous exposons les rsultats obtenus pour plusieurs applications. Le choix des applications a t guid par lexprience des quipes des dirents projets auquels nous avons particip et permet de valider nos mthodes dans les domaines varis que sont les domaines du traitement du signal, de limage et des tlcommunications. Nous verrons que les contraintes en terme de communication ne sont pas les mmes pour ces direntes applications. Enn, nous avons ralis des intgrations comportant des combinaisons de ces applications an de montrer lintrt de traiter les exclusions mutuelles.

7.2
7.2.1

Intgration sur FPGA


Conditions du test

An de vrier le bon fonctionnement du NoC sur une plate-forme matrielle, nous avons ralis un exemple mettant en uvre des communications entre 3 MicroBlazes et 3 mmoires. Cest un exemple susamment petit pour tre intgr sur le FPGA dont nous disposons. Il nous permet dobserver les caractristiques et les performances du NoC. 7.2.1.1 Environnement

Nous disposons du matriel et des logiciels suivants an de raliser cette exprience : Une plate-forme de prototypage Xilinx Virtex-II Pro FF1152 PROTO BOARD quipe dun FPGA Xilinx Virtex-II Pro FF1152 VP50-5. Les logiciels Xilinx ISE 6.3 SP3 et Xilinx EDK 6.3 SP2. 7.2.1.2 Prsentation

Le NoC que nous utilisons se compose des lments suivants : 2 routeurs avec 3 ports rseau (R3ports) ; 107

108

exprimentations et rsultats

2 routeurs avec 4 ports rseau (R4ports) ; 3 NIs avec 1 port et 2 ExtraNiChannels (NI2Ch) ; 3 NIs avec 1 port et 4 ExtraNiChannels (NI4Ch). De plus, 3 wrappers matres et 3 wrappers esclaves sont utiliss pour connecter les trois bus OPB. La gure 7.1 montre le NoC connect aux trois bus OPB et les connections crer entre les NIs. Nous testons la fois des transactions entre composants matres et esclaves, mais aussi les changes de messages entre des composants matres.

Fig. 7.1 Le NoC et les connections crer entre les NIs Nous excutons des programmes sur chacun des 3 MicroBlazes dans le but de les faire schanger des donnes au travers du NoC an de vrier son bon fonctionnement. De plus, ces programmes vrient des rgles de cohrence qui permettent de dtecter lordre, la validit et la perte dun message. Un seul MicroBlaze peut communiquer via la liaison srie de la plate-forme qui nous permet dobtenir un achage lcran. Ce processeur ache lcran les informations concernant le fonctionnement des changes. Nous testons les cinq cas suivants : BE : Un canal virtuel congur pour transporter du trac best eort ; GT : Un canal virtuel congur pour transporter du trac garanti, il utilise une table TDMA de 16 slots ; GT&BE : Deux canaux virtuels. Le premier est un BE le second un GT ;

7.2 intgration sur fpga

109

BE&BE : Deux canaux virtuels BE. Le trac sur le premier est plus prioritaire que sur le second ; BE8 : Un canal virtuel congur pour transporter du trac best eort. La taille des FIFOs dans les ports rseaux des routeurs et des NIs est de 8 au lieu de 2. Nous utilisons une largeur de donnes de 32 bits, un routage street-sign, un arbitrage round-robin et un contrle de ux de bout-en-bout entre les NIs. La taille des FIFOs dans les ExtraNIchannels est de 8. La taille des FIFOs dans les ports rseaux des routeurs et des NIs est de 2 mots, sauf dans le dernier cas ou elle est de 8.

7.2.2

Rsultats de synthse

Notre modle de description en XML permet de spcier le NoC voulu facilement et rapidement. Les codes VHDL des NoCs correspondants aux cinq cas prsents prcdemment ont t automatiquement gnrs par notre outil en moins de 2 secondes. De plus, lintgration dun NoC dans lenvironnement EDK est facilit. En eet, les chiers VHDL ainsi que des chiers spciques sont crs de manire permettre lutilisateur dajouter le NoC en tant que simple bus par un simple copier-coller de ces chiers dans la bibliothque approprie. Ceci met en vidence le gain en productivit obtenu par lutilisation de notre outil de conception. La synthse du NoC complet et de ses composants considrs indpendamment nous donne la rpartition en slices de lutilisation du FPGA. La capacit totale du FPGA est de 23616 slices. Le tableau 7.1 nous montre cette rpartition en slices, ainsi que la frquence maximale en MHz. Les wrappers conservent les mmes caractristiques dans ces dirents cas. La taille du NoC est donne sans les wrappers. Pour le wrapper matre WS , la surface occupe est 1064 slices et la frquence est de 105MHz. Pour le wrapper esclave WS , la surface occupe est 90 slices et la frquence est de 144MHz. Cas 1 BE Cas 2 GT Cas 3 BE & GT Cas 4 BE & BE Cas 5 BE8 Slices Freq. Slices Freq. Slices Freq. Slices Freq. Slices Freq. NoC 7204 94 7226 84 9251 85 9205 84 7488 100 NI2Ch 607 120 624 120 630 93 621 93 622 120 NI4Ch 1167 118 1195 118 1181 90 1170 90 1203 114 R3ports 430 136 430 136 851 118 851 118 443 132 R4ports 645 136 643 136 1317 118 1317 118 662 132

Tab. 7.1 Synthse du NoC et de ses composants Nous pouvons voir que le NoC occupe entre 30 et 40 % de la surface du FPGA. Un routeur occupe entre 1 et 5% des slices du FPGA. Une NI occupe entre 2 et 4% des slices du FPGA. La surface occupe par le NoC reste donc raisonnable.

110

exprimentations et rsultats

La frquence du NoC dpasse les 80 MHz. Ce qui permet sur un lien une bande passante thorique de 32 80.106 = 2560.106 bits/s soit 320Mo/s. A taille gale des FIFOs, nous pouvons voir que les NIs occupent une plus grande surface lorsquelles intgrent un VC GT quun VC BE. Cela est d la table des slots TDMA et au mcanisme dordonnancement. Dans les cas 3 et 4, lutilisation de deux canaux virtuels un cot important en surface dans les routeurs, ils doublent presque de surface. En revanche les NIs ne voient leur surface augmenter que lgrement. Dans le cas 5, laugmentation lgre (de 2 8) de la taille des FIFOs dans les ports rseau des routeurs et des NIs cause une augmentation de surface du NoC de 4%.

7.2.3

Rsultats du test sur la plate-forme

Les tests sur la plate-forme ont t raliss avec une horloge dune frquence de 50MHz. Les placements routages des NoCs prsents prcdemment se sont bien drouls dans quatre des cas, en revanche nous avons rencontr un problme pour raliser un NoC utilisant simultanment un canal virtuel GT et un canal virtuel BE. La synthse se passe normalement avec ISE, mais lors de la phase de placement routage, loutil indique un message derreur. Il sagit dune erreur interne de loutil de placement routage dont Xilinx nous dit quelle sera corrige dans les versions futures. Ce genre dala est hlas courant et connu des concepteurs. En considrent les lments du NoC sparment, nous avons constat que ce problme intervient uniquement dans les NIs et que lorsquelles utilisent des canaux virtuels GT et BE simultanment. Nous navons pas pu mener lexprience sur la plate-forme pour le cas 3. Des simulations sous ModelSim nous ont tout de mme montrs que notre code VHDL et le comportement obtenu sont corrects. Pour les quatre autres cas, les tests des NoCs ont t eectus sur la plate-forme avec les 3 MicroBlazes et nous ont montrs que les donnes sont bien transmises et que le contrle de ux de bout-en-bout fonctionne puisquaucune donne nest perdue. Lutilisation du canal virtuel par un trac garanti utilisant le TDMA a galement t valide. Nous avons vri que la priorit entre les canaux virtuels fonctionne dans le cas 4 qui utilise simultanment deux canaux virtuels BE. En eet le trac transport sur le premier canal virtuel est bien transmis en priorit par rapport au trac transport sur le second canal virtuel.

7.2.4

Conclusion

Ce test a permis de valider notre approche de faon complte, cest dire en intgrant le NoC en tant que IP, les wrappers pour le connecter des bus OPB et la couche logicielle dans les MicroBlazes. Nous avons observ que la surface du NoC est raisonnable (30 40% des slices du FPGA). De plus, dans cet exemple, nous avons mis en uvre tous les types de communications (passage de message, transaction de lecture et dcriture). Le NoC pourrait tre rduit pour nutiliser que le passage de message (pas de wrapper matre), ou au contraire que les transactions (wrapper esclave avec moiti moins de connections).

7.3 traitement dimage

111

7.3
7.3.1

Traitement dimage
Prsentation

Lapplication que nous considrons a t dveloppe dans le cadre du projet Epicure [88] dans lequel lquipe Codesign du laboratoire LESTER intervenait pour raliser lexploration de lespace de conception avec loutil Design Trotter. Cette application est un systme embarqu de camra intelligente. Ce dispositif ralise la dtection dobjets en mouvement dans des images captures par une camera. Ainsi, cette application intgre direntes tches de traitement, incluant lacquisition vido, le ltrage dimage, lextraction des objets et du fond, le dplacement des objets et dirents contrles lis lachage (gure 7.2). Pour notre NoC, nous avons choisi dutiliser une topologie en grille 2D de 3x4. Nous utilisons les ports situs sur les bords extrieurs de la grille. La gure 7.3 montre la topologie et le placement des composants avec les NIs. Les wrappers ne sont pas reprsents. Lapplication require 19 transactions de lecture/critures. La rsolution de limage est de 320x240 pixels et la contrainte applicative respecter est une cadence de 25 images par secondes. Par la technique de drivation des contraintes, nous avons extrait depuis les contraintes de lapplication, les contraintes de bande passante et de latence des communications (gure 7.4). Certaines des communications nont jamais lieu en mme temps. Ainsi, nous avons dni des communications mutuellement exclusives. Notre objectif est ici de dterminer la conguration pour raliser ces communications par un trac GT. Nous dsirons valuer direntes congurations an dobserver limpact du contrle de ux de bout-en-bout et de la prise en compte des exclusions mutuelles sur la taille de la table TDMA et le cot en FIFOs dans larchitecture.

7.3.2

Rsultats

Ce problme complexe a t rsolu laide de notre outil de dcision. Les rsultats obtenus sont reprsents dans le tableau 7.2.
Options choisies Avec Avec Avec Sans Sans Sans Sans Avec contrle de ux de bout-en-bout, prise en compte des exclusions mutuelles contrle de ux de bout-en-bout, prise en compte des exclusions mutuelles contrle de ux de bout-en-bout, prise en compte des exclusions mutuelles contrle de ux de bout-en-bout, prise en compte des exclusions mutuelles Nombre de slots de la table TDMA 5 11 8 5 Somme de la profondeur des FIFOs dans les NIs 60 65 50 50

Tab. 7.2 Rsultats Nous observons quen fonction des options choisies, loutil est parvenu des solutions avec des tailles de tables TDMA direntes. Nous observons que lutilisation du contrle de ux de bout-en-bout implique un cot supplmentaire en profondeur de

112

exprimentations et rsultats

Fig. 7.2 Lapplication camra intelligente FIFO. Lutilisation des exclusions mutuelles permet dobtenir une solution avec une taille de table de TDMA rduite ce qui peut permettre de rduire le cot en FIFO.

7.3.3

Conclusion

Nous voyons quun NoC peut tre utilis pour satisfaire les besoins de communication de lapplication. De plus, nous voyons que notre outil de conception automatique est parvenu trouver des solutions pour les direntes congurations. Ces solutions orent des tailles de tables de TDMA petites et des cots en FIFO raisonnables.

7.4 chane mc-cdma mc-ss-ma

113

Fig. 7.3 La topologie de lapplication de traitement dimage

Fig. 7.4 Les contraintes de bande passante et de latence des communications Dans le cadre du projet RaaR [89] au LESTER, cette application de traitement dimage est utilise pour eectuer un partitionnement logiciel/matriel dynamique contrl par un RTOS. Lide est de rguler automatiquement lutilisation des ressources en fonction des caractristiques de limage (nombre dobjets, bruit, etc) sous contraintes de QoS et dnergie. Dans ce contexte, nous voyons quun NoC programmable est utile an dadapter les communications aux choix eectus en termes dimplantation logicielle/matrielle des direntes tches et des paramtres de ces tches.

7.4
7.4.1

Chane MC-CDMA MC-SS-MA


Prsentation

Cette application est une chane MC-CDMA (Multi-Carrier Code Division Multiple Access)[90] dun terminal mobile dans le cadre du futur standard de radio tlcommunications de quatrime gnration (4G). Son tude constitue une part du projet

114

exprimentations et rsultats

europen 4MORE [1] dans lequel le laboratoire IETR est impliqu. La 4G ncessitera un systme exible et capable de supporter dirents standards pour permettre lvolution et la mise jour du SoC. Ces contraintes font du NoC un bon candidat. La contrainte de cadence est de 1 symbole OFDM toutes les 20.8s. Une trame est compose de 32 symboles. La contrainte applicative est donc de tenir la cadence dune trame tous les 665,6s. Les gures 7.5 et 7.6 issues de [91], nous montrent les diagrammes du transmetteur (TX) et du rcepteur (RX). Les contraintes des communications relatives la partie transmission et rception nous ont t donnes et sont reprsentes dans les tableaux 7.3 et 7.4.

Fig. 7.5 Diagramme du transmeteur MC-SS DMA

Fig. 7.6 Diagramme du rcepteur MC-CDMA 29 communications unidirectionnelles sont mises en jeu entre les dirents lments du systme. Nous pouvons voir que les bandes passantes requises sont varies. Le trac est prdictible, il est donc tout fait adapt lutilisation du trac garanti par TDMA. Cependant le ot de donnes est relativement point point et orient. Nous avons donc utilis un placement des composants permettant de tirer prot des liens dans chaque direction an dutiliser le NoC au mieux. Le port dentre et le port de sortie

7.4 chane mc-cdma mc-ss-ma

115

de chaque composant ont t regroups en cluster sur une mme NI. Nous avons ainsi 28 clusters. Nous navons pas cherch le placement optimal des composants, mais valider notre ot dans le contexte dune application de tlcommunication qui prsente des caractristiques direntes de celles de lapplication de traitement dimage.
Initiator port RAM 1 RAM 1 Channel coder Bit interleaving Mapping Spreading(CDMA) MIMO encoder MIMO encoder FFT 1 FFT 2 Target port Channel coder MIMO encoder Bit interleaving Mapping Spreading(CDMA) MIMO encoder FFT 1 FFT 2 BB to RF 1 BB to RF 2 BW(Bytes/s) 288462 865385 576923 576923 3461538 3461538 4326923 4326923 230769231 230769231 Latency (nano sec) 665600 665600 665600 665600 665600 665600 665600 665600 665600 665600

Tab. 7.3 Les communications du transmetteur (TX)


Initiator port RAM 2 (RF to Baseband) RAM 3 (RF to Baseband) iFFT 1 iFFT 2 iFFT 1 iFFT 2 CFO 1 CFO 2 ROTOR 1 ROTOR 2 ROTOR 1 ROTOR 2 MIMO channel estimation 1 MIMO channel estimation 2 MIMO decoder 1 De-Spreading(CDMA) Soft De-Mapping Bit De-interleaving Channel Decoder Target port iFFT 1 iFFT 2 CFO 1 CFO 2 ROTOR 1 ROTOR 2 ROTOR 1 ROTOR 2 MIMO channel estimation 1 MIMO channel estimation 2 MIMO decoder 1 MIMO decoder 1 MIMO decoder 2 MIMO decoder 3 De-Spreading(CDMA) Soft De-Mapping Bit De-interleaving Channel Decoder RAM 2 BW(Bytes/s) 230769231 230769231 4146635 4146635 121153846 121153846 180288 180288 24230769 24230769 96923077 96923077 193846154 193846154 121153846 12115385 12115385 12115385 1514423 Latency (nano sec) 665600 665600 665600 665600 665600 665600 665600 665600 665600 665600 665600 665600 665600 665600 665600 665600 665600 665600 665600

Tab. 7.4 Les communications du rcepteur (RX)

7.4.2

Rsultats

Nous avons choisi dutiliser le trac de classe GT et le contrle de ux de bout-enbout. Nous nutilisons pas ici les mutuelles exclusions qui feront lobjet de la section 7.6. La topologie du NoC choisie est une grille 4x4 avec une connexion locale et nous utilisons galement les bords extrieurs. Nous utilisons ainsi 16 routeurs et connectons 28 NIs. La largeur des mots sur les liens est de 32 bits et la frquence est de 100MHz. Loutil Spider a trouv une solution avec un taille de table TDMA de 6 slots de temps. La profondeur cumule des FIFOs ncessaires est de 238 mots.

116

exprimentations et rsultats

7.4.3

Conclusion

Notre solution utilise des TDMAs pour garantir les caractristiques de bande passante et de latence des communications. Cette solution a un faible cot puisque les routeurs ne ncessitent pas de grandes tailles de FIFO pour traiter les conits daccs puisque les communications sont prordonnances par le TDMA. De plus, cette solution est moins sensible aux variations de comportement des lments de traitement quune solution construite sur mesure qui sappuierait uniquement sur des simulations pour sassurer que les communications sagencent correctement. Dans le cadre de 4MORE, le NoC ANoC de larchitecture FAUST a t utilis pour raliser une conception extrmement statique, sans TDMA, qui est base sur les simulations et ne supporte donc aucun ala. Nous pensons que notre approche est beaucoup plus sre et exible et surtout notre outil nous a permis dobtenir une solution trs rapidement compare lapproche manuelle par simulation de FAUST.

7.5
7.5.1

Turbo dcodeur
Prsentation

Les contraintes de cette application nous ont t fourni par lENST Bretagne dans le cadre du groupe R-PUCE. Cest une application de turbo-dcodage utilisant une architecture multi-ASIP originale dcrite dans [92]. Le turbo dcodage permet de rduire le taux derreurs dans les transmissions mme avec un faible rapport signal sur bruit. Le turbo code utilis est le DVB RCS. Le turbo dcodeur est constitu de deux dcodeurs qui schangent des informations (appele extrinsques) pour faire converger leurs dcisions. Ces communications dpendent du schma dentrelacement retenu. Le turbo dcodeur utilis ici est mis en uvre sur une plate-forme multiprocesseur pour atteindre de hauts dbits. Notre objectif est de concevoir un turbo dcodeur dont il est possible de changer le schma dentrelacement. Pour transporter les communications entre les processeurs, nous avons choisi dutiliser un NoC pour ces capacits de reconguration. Dans notre cas dtude, une information extrinsque est constitue de 72 bits (9 octets), de plus, chacun des dcodeurs est intgr sur quatre processeurs, et chaque processeur a deux ports dentre et deux ports de sortie. La gure 7.7 montre notre architecture. Ainsi, larchitecture se compose de 8 processeurs et 16 ports dentre et 16 ports de sortie. Les donnes du problme : Une trame = 1000 symboles = 2000 bits ; Frquence des dcodeurs (processeurs)= 100MHz ; Une information extrinsque est constitue de : 64bits + 1bit de contrle dinversion + 6 bits dadresse = 71 bits = environ 9 octets (72 bits) ; Il y a 4 processeurs dans chaque dcodeur, soit un total de 8 processeurs. Chaque Processeur a 2 voies en entres ia et ib et deux voies en sorties oa et ob ; Lentrelassement est form de 64 priodes dmissions. Nous notons la dure dune priode dmission :Temiss. Temiss=10 cycles.

7.5 turbo dcodeur

117

Fig. 7.7 Architecture de la plate-forme pour le turbo dcodage Durant chaque Temiss, les 16 voies dmission (voies oa et ob des 8 processeurs) produisent une information extrinsque et celle-ci doit tre envoye vers lune des voies (ia ou ib) de lun des 4 processeurs appartenant lautre dcodeur. La destination de chaque information extrinsque est dnie pour chaque Temiss selon lordonnancement de lentrelasseur ; 6 La frquence de production des informations extrinsques par voie = 100.10 = 10 10MHz ; La contrainte maximale de temps pour acheminer 1 information extrinsque est de 3 Temiss, soit 30ns ; Nos premires observations : Le dbit par voie dmission est de 90Mo/s ; 128 communications peuvent tre identies. Alors que seulement 16 informations extrinsques sont cres tous les Temiss ; Le dbit total des changes est de 16*90Mo/s=1,4Go/s. Une solution base de bus est donc exclue ; Une entre i peut recevoir jusqu 8 informations extrinsques la fois (ceci est trs rare, la probabilit est de 1/88 = 1/16777216 = 59.109 ). Cela reprsente alors un dbit de 8*90= 720Mo/s. En moyenne, une entre reoit une seule information extrinsque par cycle dmission, soit un dbit de 90Mo/s. Une entre peut aussi ne rien recevoir.

118

exprimentations et rsultats

Nos premiers choix : les ports dentres et de sorties Oj sont regroups en un seul port bidirectionnel ; Nous choisissons de ne pas faire de contrle de ux de bout-en-bout. lmission, nous supposerons quil y a de la place la rception pour recevoir les donnes. Cette application prsente des dicults pour satisfaire sa communication. Cest probablement lun des pires cas. La bande passante pire cas pouvant aboutir une voie de rception est importante ; La latence maximale dacheminement est faible ; La taille des messages changs est faible, ce qui implique des petits paquets et donc un gaspillage important de la bande passante pour transmettre les nombreux enttes de paquets ; 128 communications peuvent tre identies, alors que seulement 16 communications ncessitent dtre transportes tous les Temiss. Il est donc dicile de pr-ordonnancer les communications.

7.5.2

Analyse

Lquipe du projet R-PUCE est compose de personnes de domaines dirents. Cette pluridisciplinarit a t mise prot durant ce projet. Les personnes travaillant dans le domaine des rseaux dordinateurs ont apport des solutions pour quelles puissent tre transposes au domaine des NoCs. Les comptences des personnes matrisant lapplication ont permis dimaginer des modes dgrads de lapplication, ou des restrictions an de rduire le cot de mise en uvre de la solution. Enn, nos comptences dans les NoCs ont permis de mettre en uvre des solutions adaptes. Nous avons ainsi propos deux solutions faible cot, lune utilisant le trac BE avec un mode dgrad des performances de lapplication et lautre un trac GT avec des restrictions sur lentrelasseur utilisable.

7.5.3

Une premire solution utilisant le best eort

Le trac tant trs vari et le nombre de communications ayant eectivement lieu tant faible par rapport toutes les combinaisons possibles, il est dicile dutiliser un pr-ordonnancement. Nous pouvons dans un premier temps voir quelle solution pourrait permettre lutilisation dune classe de trac best eort. Les dcodeurs schangent des informations leur permettant de converger vers le dcodage des donnes. Nous notons que certaines informations apportent une correction importante et dautres une correction insigniante. Labsence de la transmission des communications apportant une faible correction peut, dans une certaine mesure, ne pas entraner de dgradation signicative sur les performances du turbo dcodeur et seulement ralentir la convergence de ses dcodeurs. De part cette connaissance de lapplication, nous pouvons faire le choix de transmettre en priorit les informations les plus pertinentes et en second lieu les informations qui peuvent tre ngliges. Nous pouvons alors utiliser un champ supplmentaire dans lentte du paquet pour indiquer le niveau dimportance des donnes transportes et donc le niveau de priorit des paquets qui les transportent vis a vis des autres

7.5 turbo dcodeur

119

paquets. Ainsi, dans les routeurs, nous intgrons des arbitres qui utilisent ce niveau de priorit pour allouer laccs aux liens aux paquets les plus prioritaires. La validation de cette solution ncessiterait des simulations qui nont pas t mises en uvres. Nous notons que le niveau des priorits des paquets serait important au dbut, lorsque les deux dcodeurs prsente beaucoup de dsaccord et se rduirait progressivement mesure que les dcodeurs convergent. Ce travail continue, notamment pour la ralisation de la politique daectation des priorits.

7.5.4

Une solution utilisant le pr-ordonnancement par TDMA

La dicult est de tirer parti de la connaissance des communications de lapplication compte tenu de son schma dentrelacement pour pouvoir les pr-ordonnancer. Bien que le schma dentrelassement soit connu cela reste dicile car il contient 64 itrations (squences). De plus, nous devons dans une certaine mesure rester gnriques an de pouvoir intgrer dirents schmas dentralassement. Ainsi, an de ne pas surdimensionner larchitecture de communication du systme, nous avons dni la restriction suivante : Un port dentre ne pourra pas recevoir plus de cinq informations extrinsques durant une priode de 3 itrations conscutives. Ainsi, nous rendons les communications mutuellement exclusives sauf celles qui ont lieu en mme temps ou durant des itrations voisines dans lentrelasseur. La gure 7.8 image ces propos. Par exemple P5b ne pourra pas recevoir plus de 5 informations extrinsques durant les priodes denvoi I-1, I et I+1. Il en va de mme pour tous les autres. Cette restriction est compatible avec un grand nombre dentrelasseur. Ce nest pas une solution ad hoc pour un entrelasseur considr. Une solution conue spcialement pour un entrelasseur serait videment moins coteuse, mais noffrirait pas la exibilit que nous recherchons. Nous choisissons dutiliser une topologie est une grille 2D de 4x4, avec des routeurs de 4 ports et une frquence de 200MHz. La largeur dun mot est de 24 bits.

7.5.5

Rsultats

Notre outil a trouv une solution avec une taille de la table de TDMA de 10 slots de temps. Il a dtermin un chemin pour chacune des communications. La latence la plus grande pour acheminer une information extrinsque est de 0,20s et est donc en accord avec la contrainte de temps spcie qui est de 0,30s. Le cot en mots dans les FIFOs est dun total de 416 mots. 2 slots de temps ont t rservs pour chaque communication. Comme un slot contient 2 mots et que la largeur de lentte dun paquet est de 1 mot, chaque communication bncie dune portion de la bande passante du lien qui est de 1,5 slots sur les 10 slots de la table. La bande passante est donc de 24*200 000 * 1,5/10= 720Mbits/s, soit 90Mo/s. Ce qui est exactement la bande passante ncessaire. Un rcepteur peut donc au plus recevoir 5 communications. La latence est de 0,20s, ainsi une communication peut se retrouver en collision avec un communication

120

exprimentations et rsultats

Fig. 7.8 Lhypothse permettant lexclusions entre des communications mise juste avant elle ou pendant ou juste aprs elle. Cest pourquoi nous limitons la possibilit denvoi de 5 communications non mutuellement exclusive 3 envois conscutif de lentrelasseur. Une largeur de 24 bits pour la largeur du mot transport sur un lien est susante grce lutilisation de notre hypothse qui nous a permis dutiliser les exclusions mutuelles, alors quune largeur de 72 bits aurait t ncessaire sans cette hypothse.

7.5.6

Conclusion

La conception du NoC dpend des spcicits de lapplication et de la nature mme des donnes transportes. Un NoC totalement gnrique aurait conduit un surdimensionnement injusti. Par une bonne connaissance de lapplication, nous avons dtermin deux types de compromis. Le premier est un compromis entre la complexit et la Qos de lapplication. Le second est un compromis entre complexit et la gnricit. Nous avons ainsi propos deux solutions, lune utilisant le trac BE et un mode dgrad des performances de lapplication et lautre un trac GT avec des restrictions sur lentrelasseur utilisable. Nous avons donc su mener la conception du NoC en tirant partie de la connaissance des spcicits de lapplication et en dterminant les compromis possible. Ceci est un exemple typique qui montre comment un outil de CAO peut avec des spcications formelles des contraintes, aider le concepteur trouver une solution faible cot en lui permettant dvaluer rapidement dirents compromis. Ceci ouvre de nouvelles perspectives pour gnraliser cette approche.

7.6 combinaisons des applications

121

7.6
7.6.1

Combinaisons des applications


Prsentation

Nous cherchons valider la technique de recherche de chemin spatio-temporel et lintrt de lexclusion mutuelle des communications. Nous utilisons ici lapplication traitement dimage et lapplication de tlcommunication avec ses deux parties, transmission (TX) et rception (RX). Toutes les communications utilisent la classe de trac GT. Quand les deux applications sont connectes simultanment, un total de 63 ports dIPs, celles-ci sont regroups en 25 clusters. Les IPs connectes des NIports dune mme NI forme un cluster. Chaque cluster est connect une NI. Il y a donc 25 NIs. Le NoC spci une topologie en grille 5x5. Les routeurs ont 5 ports avec des mots de 32 bits de large. la technique de routage est le street-sign. La frquence du NoC est de 100MHz. Nous tudions plusieurs cas, et pour chacun nous considrons limpact de lutilisation du contrle de ux de bout-en-bout. Le contrle de ux de bout-en-bout empche que les donnes ne soient perdues la rception par faute de place. Notons que le choix de ne pas utiliser ce contrle de ux est envisageable dans les domaines des tlcommunications et du traitement dimage en fonction du compromis qui est fait entre le cot et la QoS dsire.

7.6.2

Rsultats

Le tableau 7.5 montre nos dirents cas dtude, qui correspondent un NoC ddi lune ou les deux applications la fois. Dans chaque cas nous observons la taille de la table TDMA (en slots), la latence moyenne de transport sur chaque chemin (nombre de routeurs traverss) et la somme de la profondeur de toutes les FIFOs dans les NIs (en nombre de mots). Les rsultats sont dtaills dans le tableau 7.6. Le terme ET signie que les applications fonctionnent en mme temps, le OU indique quelles sont fortement exclusives et quelles ne fonctionnent donc pas en mme temps, et le terme LME (pour Light Mutual Exclusion) signies quelles sont faiblement exclusives.
Cas 0 1 2 3 4 5 6 7 8 9 10 spcications applicatives TX OU RX TX ET RX (TX ET RX) avec LME traitement dimage traitement dimage avec LME traitement dimage ET TX ET RX (traitement dimage ET TX ET RX)) avec LME traitement dimage OU (TX ET RX) (traitement dimage OU (TX AND RX)) avec LME traitement dimage OU TX OU RX (traitement dimage OU TX OU RX) avec LME

Tab. 7.5 Les cas expriments

122
Avec contrle de ux de Taille de la Latence table TDMA moyenne 5 3,3 6 4,59 5 3,3 10 4,33 5 4,33 21 4,4 16 4,5 10 4,34 5 4,16 10 4,34 5 4,16 bout-en-bout Somme de la taille des FIFOs 203 247 242 65 60 927 490 314 275 307 257

exprimentations et rsultats
Sans contrle de ux de Taille de la Latence table TDMA moyenne 2 4,14 2 4 2 4,14 8 4,36 5 4,28 13 4,5 6 4,16 8 4,2 6 4,2 8 4,2 5 4,12 bout-en-bout Somme de la taille des FIFOs 50 58 58 50 50 280 160 182 146 168 136

Cas 0 1 2 3 4 5 6 7 8 9 10

Tab. 7.6 Les rsultats

7.6.3

Analyse

Notre analyse est organise en 5 points. Premirement, nous observons que notre algorithme de recherche des chemins parvient trouver une solution, mme avec des applications complexes. Le second point concerne le cot du contrle de ux de bout-en-bout. Le contrle de ux de bout-en-bout ncessite le renvoi des crdits des consommateurs vers les producteurs. Dans le cas des transactions de lecture, le retour de crdit peut tre intgr dans lentte du paquet des requtes suivantes. En revanche, dans le cas dune transaction dcriture, cela require lajout dune communication dans le sens oppos. De plus, ces communications occupent des slots de temps supplmentaires pour tre transmis, ce qui provoque une augmentation de la taille de la table TDMA, et donc des FIFOs de dcouplage. De plus, des FIFOs sont ncessaires pour masquer le temps entre lenvoi des donnes depuis le producteur et le retour des crdits. Ceci cause une augmentation de la taille des FIFOs et donc du cot en surface. Nous observons que laugmentation du cot en FIFO caus par lutilisation du contrle de ux de bout-enbout est beaucoup plus forte pour lapplication de tlcommunication. Ceci sexplique par le fait que cette application nutilise que des transactions dcriture. Le retour de crdit utilis dans le contrle de ux de bout-en-bout ajoute une communication de retour qui double le nombre des communications. De plus, ces communications ncessitent des slots de temps pour tre transmis, ce qui cause une augmentation de la taille de la table TDMA. Le rsultat est donc une augmentation de la taille de la table TDMA et de la profondeur des FIFOs. Lapplication de traitement dimage quant elle ne soure pas trop de lutilisation du contrle de ux de bout-en-bout car une large part de ses transactions sont des lectures. Le troisime point est le dcoupage de la table TDMA en slots. Dans le cas 8, qui permet de faire fonctionner soit lune ou lautre des applications (ME), nous pouvons voir que la taille de la table est suprieure aux tailles de celles des cas ou les applications fonctionnent seules (cas 2 et 4). La raison est que cette taille de la table doit orir toutes les communications un nombre entier de slots. La subdivision de la table qui accommode les deux applications peut donc tre plus grande que chacune individuellement.

7.7 conclusion

123

Le quatrime point est celui de lamlioration apporte par lexploitation des exclusions mutuelles. Les rservations des slots de temps peuvent tre partages par les communications mutuellement exclusives, ainsi la table de TDMA requise est plus petite et nous obtenons une rduction de la taille des FIFOs de dcouplage. Enn, cette rservation multiple des slots permet daugmenter le nombre de slots laisss disponibles ce qui favorise la dcouverte et lutilisation de chemins plus courts, ce qui permet de plus la rduction des profondeurs des FIFOs qui masquent le temps de retour des crdits. Enn, nous pouvons voir que dans le cas 1 (avec contrle de ux de bout-enbout) qui met en uvre lapplication MC-CDMA, le cot en mots dans les FIFOs est suprieur au rsultat obtenu dans la section 7.4. Ceci sexplique par le fait que la topologie est ici plus large (une grille 5x5 au lieu de 4x4). Les paquets parcourent donc un chemin plus long et les FIFOs qui masquent le temps de retour des crdits peuvent donc tre plus profondes.

7.6.4

Conclusion

Lutilisation du contrle de ux de bout-en-bout a un cot plus important dans le cas des transactions dcriture que dans le cas des transaction de lecture. Son utilisation peut ne pas tre justie dans le cas de certaines applications qui, soit acceptent des pertes de donnes, soit orent la garantie que les donnes seront consommes avant larrive des suivantes. Notre technique dallocation des chemins pour la classe de trac garanti en bande passante trouve une solution, y compris dans le cas dapplications extrmement complexes et htrognes. Elle tire avantageusement partie de lexploitation de la connaissance des exclusions mutuelles entre les communications pour rduire la taille de la table TDMA et rduire la profondeur des FIFOs dans les interfaces rseau. Cette exprience nous montre que la classe de trac GT peut tre utilise avec un cot raisonnable en FIFOs. De plus, nous prenons en considration le fait que le GT ne require que des FIFOs de taille minimale (2 mots) dans les routeurs puisquil ne peut pas y avoir de contention entre les paquets contrairement la classe de trac best eort et que les tailles des FIFOs dans les NIs peuvent tre dnies prcisment. Nous pouvons conclure que le trac GT par TDMA est une solution raliste. Cette capacit satisfaire plusieurs applications sur un mme NoC nous amne la rexion quun systme dexploitation pourrait surveiller et contrler ces direntes applications an dadapter le NoC aux variations des besoins.

7.7

Conclusion

Ces exprimentations ont montr que larchitecture de NoC que nous proposons fonctionne, ce qui est bien sr un pralable. Dautre part, nous avons vu que notre ot de conception permet de dterminer ecacement les paramtres du NoC. La technique dallocation des chemins que nous proposons parvient trouver des solutions dans le cas dapplications complexes. La dnition des communications mutuellement exclusives permet la rutilisation des slots du TDMA et ainsi de trouver des solutions avec des tables de TDMA de taille minimale, ce qui peut permettre de rduire le cot en FIFO dans larchitecture.

124

exprimentations et rsultats

Nous avons montr quil y a une grande complexit dterminer les paramtres dun NoC pour une application. Un outil de CAO est ncessaire pour aider le concepteur concevoir un NoC. Il est ainsi possible dexplorer rapidement direntes solutions. Nous avons rsolu des cas trs dirents, issus des domaines du traitement du signal, de limage et des tlcommunications, ce qui prouve que nous disposons dun outil gnraliste.

Chapitre 8

Conclusion et Perspectives
8.1 Conclusion

Nous avons propos dans ce mmoire une architecture de NoC et un ot de conception pour les rseaux sur puce dans le cadre dapplications possdant des contraintes de temps rel. Nous avons propos un modle de NoC comportant de nombreux paramtres gnriques pour nous orir une grande libert de mise en uvre et ainsi disposer des aptitudes requises pour satisfaire le plus grand nombre dexigences. Il est ainsi capable de manipuler dirents types de trac, dont un trac garanti par TDMA. Lespace de conception des NoCs est vaste et il est ncessaire de disposer de mthodes pour raliser un NoC adapt aux besoins de lapplication. Le premier point consiste prendre connaissance et dcrire les besoins en communication dune application. Or, les contraintes de lapplication sont exprimes de faon globale, et les contraintes satisfaire individuellement par chaque communication ne sont pas exprimes. Ainsi, nous avons propos une mthode pour extraire les contraintes de communication depuis une description des tches de lapplication. Celle-ci repose sur le respect de rgles qui assurent la bonne initialisation et le bon fonctionnement en cadence de lapplication. Ces rgles permettent dextraire les contraintes de bande passante et de latence que les communications devront satisfaire. Pour obtenir un ordonnancement TDMA correcte, il faut allouer des chemins chacune des communications en respectant leur contrainte de bande passante et de latence, et en assurant quelles ne peuvent jamais se rencontrer. Ce problme est complexe et ncessite une approche heuristique. Nous avons propos de reprsenter lespace dexploration par la topologie laquelle nous ajoutons une dimension temporelle reboucle que nous appelons topologie spatio-temporelle. Nous avons propos une mthode heuristique an de raliser cette exploration. Celle-ci repose sur une technique dallocation des chemins de faon concerte entre les communications qui doivent tre places an dorir le plus de chance de succs pour permettre chacune de trouver une solution qui lui convienne. De plus, nous avons propos didentier les communications qui ne peuvent pas se produire en mme temps (mutuellement exclusives) de faon permettre de mutualiser leurs rservations de slots de temps dans la topologie spatio-temporelle.

125

126

conclusion et perspectives

Cette mthodologie a t intgre dans un outil an de permettre dautomatiser et de valider son fonctionnement. Cet outil nous a permis de confronter notre mthodologie des applications des domaines du traitement du signal, de limage et des tlcommunications. Nous avons prsent un ensemble de rsultats obtenus avec ces applications, qui montrent lintrt de tirer prot des communications mutuellement exclusives. Ainsi, la taille de la table TDMA ncessaire peut tre rduite et nous pouvons limiter la profondeur de FIFO ncessaire. Ces exprimentations ont permis de dmontrer laptitude de notre outil trouver une solution. Nous avons vu par les exprimentations quil peut tre intressant, voir ncessaire, de tenir compte des spcicits de lapplication pour choisir la politique de transport des communications. Ainsi, nous nous sommes aperus dans les cas de lapplication turbo dcodeur, que les messages navaient pas tous la mme criticit en fonction de lapport quils ralisent et que certaines communications pouvaient tre plus facilement ngliges que dautres en cas de conit daccs. En marge de ce ot de conception, nous nous sommes intresss deux sujets qui sont laspect scurisation du NoC et le problme des horloges dans les circuits de grande taille. Nous avons prsent une solution pour vrier destination la provenance dun paquet. Cette vrication ne se fait pas selon un identiant ou une clef, mais selon les instructions de chemin que le paquet a utilis pour atteindre cette destination. Cette clef est unique et sre dans lhypothse que lintgrit du NoC est garantie. Lintrt de cette technique rside dans la simplicit de sa mise en uvre. De plus, nous avons montr quil est galement possible dutiliser les instructions aller pour obtenir les instructions retour rorganises dans le bon ordre (sans que ces instructions ncessitent davoir la mme largeur en bits). Pour pallier le problme de lhorloge qui ne peut plus tre considre comme synchrone sur lensemble dun circuit de grande taille, nous avons propos une division du NoC en sous parties (sub-NoC) fonctionnant chacune de faon synchrone mais ayant entre elles des horloges qui sont msochrones (mme horloges mais dphases). Nous avons propos une adaptation appele routeur temporel pour permettre un sous NoC qui utilise un TDMA (qui ncessite une notion commune dhorloge), dintgrer un routeur se trouvant dans un autre domaine dhorloge. De plus, nous avons propos des synchroniseurs qui permettent dinterconnecter des sub-NoCs possdant des TDMA distincts. Nous avons montr quil existait deux faons de mettre en uvre ces derniers, soit en conservant le contrle de ux au niveau du NoC global, soit en dpaquetant et rempaquetant les messages entre les sub-NoCs et en ralisant donc un contrle de ux local chaque sub-NoC. Nous avons montr les avantages de chacune de ces approches.

8.2

Perspectives

Bien que la mthodologie propose conduise des rsultats de bonne qualit sur les exemples traits, plusieurs amliorations et extensions peuvent tre apportes comme nous lavons mentionn plusieurs reprises dans ce document.

8.2 perspectives

127

Dun point de vu dveloppement et gnricit, il serait intressant de dvelopper de nouveaux wrappers pour permettre de connecter au NoC des composants utilisant dautres protocoles que celui du bus OPB. Il serait intressant dlaborer un modle pour permettre de donner au concepteur des indications sur le NoC spci (surface, consommation), sans quune synthse soit ncessaire. Si nous dsirons intgrer notre algorithme de recherche des chemins an de raliser des recongurations en ligne, il est ncessaire dacclrer son temps dexcution en ralisant certaines approximations. Nous avons dj spci les heuristiques possibles. La recherche de chemin est ralis uniquement dans un NoC ou sub-NoC synchrone. Des travaux pourraient tre mens pour tendre la recherche des chemins dans le cadre dun NoC constitu de plusieurs sub-NoCs fonctionnant chacun avec leur domaine TDMA. Il faudrait alors choisir par quels sub-NoCs intermdiaires il est le plus intressant de traverser pour atteindre un autre sub-NoC. Laspect scurit dans les NoCs nest pas encore un sujet de recherche trs tudi. La scurit deviendra cependant un aspect important dans les systmes multifonctions qui intgrerons un NoC. En plus de dtecter des attaques ou des erreurs, il sera ncessaire dorir des contre-ractions au NoC. Il est galement ncessaire de permettre la convergence entre le systme dexploitation et la gestion du NoC an de tirer parti de toutes les capacits de reconguration et dadaptation du systme. Enn, lajout de la synthse de code SystemC en complment du code VHDL RTL actuellement gnr est en cours de dveloppement. Il permettra une simulation plus facile pour linteraction entre le NoC et des programmes destins fonctionner sur des processeurs connects celui-ci. Cela permettra dexplorer plus facilement les aspects raction de contre-attaque et convergence avec lOS cits prcdemment.

128

conclusion et perspectives

Annexe

Publications personnelles
Publication dans une revue internationale
S. Evain, J-Ph. Diguet and D. Houzet, NoC Design Flow for TDMA and QoS Management in a GALS Context, EURASIP Journal on Embedded Systems, Volume 2006, Hindawi Publishing Corporation, 2006, accept.

Publications dans des confrences internationales


S. Evain, J-Ph. Diguet, Milad El Khodary and D. Houzet, Automated derivation of NoC Communication Specications from Application Constraints, IEEE SIPS 2006, Workshop on Signal Processing Systems, Ban, AB, Canada, October 2-4, 2006. S. Evain, J-Ph. Diguet and D. Houzet, Spider NoC Road Map, DATE 06 Workshops, Future Interconnects and Networks on Chip Workshops, March 10, 2006. S. Evain and J-Ph. Diguet, From NoC Security Analysis To Design Solutions, IEEE SIPS 2005, Workshop on Signal Processing Systems, Athens, Greece, November 2-4, 2005. S. Evain, J-Ph. Diguet and D. Houzet, Spider : a CAD Tool for ecient NoC design, IEEE NORCHIP 2004, Oslo, NORWAY, November 8-9, 2004. S. Evain, J-Ph. Diguet and D. Houzet, A CAD Tool for ecient NoC design, IEEE ISPACS 2004, International Symposium on Intelligent Signal Processing and Communication Systems, Seoul, Korea, November 18-19, 2004.

Brevet
Inventeurs : S. Evain et J-Ph. Diguet, Routeur et rseau de routage. Titulaire : Centre National de la Recherche Scientique. Brevet FR 05/53280, dpos le 28 octobre 2005.

131

Table des gures


2.1 2.2 2.3 2.4 2.5 2.6 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15 3.16 3.17 3.18 4.1 4.2 4.3 4.4 4.5 4.6 Les lments dun NoC . . . . . . . . . . . . . . . . . . . . . . . . . . Les lments du NoC et les couches rseau . . . . . . . . . . . . . . . La structure dun paquet . . . . . . . . . . . . . . . . . . . . . . . . . Le ot de conception de NoC de thereal . . . . . . . . . . . . . . . . Loutil NoCcompiler de Arteris . . . . . . . . . . . . . . . . . . . . . . Les outils SUNMAP et xpipesCompiler du ot de conception de xPIPES Architecture dun routeur . . . . . . . . . . . . . . . . . . . . . . . . . La transmission dun paquet sur un lien unidirectionnel . . . . . . . . Les champs dans lentte du paquet . . . . . . . . . . . . . . . . . . . Une NI avec deux ports NIports . . . . . . . . . . . . . . . . . . . . . Deux microprocesseurs MicroBlaze et un contrleur de RAM connects par le NoC au travers de leurs bus OPB . . . . . . . . . . . . . . . . . Le wrapper matre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Le wrapper esclave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . criture au travers du NoC et des deux bus OPB . . . . . . . . . . . Lecture au travers du NoC et des deux bus OPB . . . . . . . . . . . . Envoi dun message au travers du NoC et des deux bus OPB . . . . . Rservations multiples de slots de temps sur les liens par des communications mutuellement exclusives . . . . . . . . . . . . . . . . . . . . Partage de la FIFO de rception et utilisation de compteurs de crdits distincts pour des communications faiblement mutuellement exclusives Le ot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Relations entre les objets qui modlisent le systme . . . . . . . . . . La spcication des communications dans le chier Excel . . . . . . . La description de larchitecture du NoC . . . . . . . . . . . . . . . . . Exemple de script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Linterface graphique de Spider . . . . . . . . . . . . . . . . . . . . . Une chane de tches . . . . . . . . . . . . . . . . . . . . . La rservation de slots dans une table TDMA . . . . . . . Contrainte sur la longueur du chemin et bande passante processus de drivation des contraintes . . . . . . . . . . . Chronogramme des communications autour dune tche . . Topologie spatiale et vue spatio-temporelle . . . . . . . . . Rpartition des Pr-rservations des slots . . . . . . . . . . 133 . . . . . . . . . . . . durant le . . . . . . . . . . . . . . . . . . . . . . . . 7 9 10 18 20 21 26 29 30 31 34 35 36 37 38 39 42 42 43 45 46 47 49 50 56 56 58 59 64 66

134 4.7 4.8 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8

table des figures Rpartition des communications sur une topologie . . . . . . . . . . . Longueur moyenne des chemins en fonction de la technique daectation des chemins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Un rseau distribu sur un ASIC et un FPGA . . . . . . . . . . Sparation des tracs sur des canaux virtuels dirents . . . . . Trois frontires de scurit . . . . . . . . . . . . . . . . . . . . . Exemple de NoC entirement dans la zone sre . . . . . . . . . . Network Interface . . . . . . . . . . . . . . . . . . . . . . . . . . Noc dans la zone sre et non sre . . . . . . . . . . . . . . . . . Le path lter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Le codage des instructions de chemin selon un codage relatif la Les instructions de chemin aller et retour . . . . . . . . . . . . . Exemple dauthentication par le chemin . . . . . . . . . . . . . Boomrang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Double inversion pour inverser lordre des instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . source . . . . . . . . . . . . 68 69 74 77 77 78 78 79 80 82 82 84 84 86

NoC GALS avec QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Le skew entre les horloges . . . . . . . . . . . . . . . . . . . . . . . . . 93 Le Routage temporel . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Un NoC form de trois sub-NoCs interconnects . . . . . . . . . . . . 96 Une paire de synchroniseurs avec le dtail de larchitecture du second 96 Contrle de ux de bout-en-bout au niveau global, niveau NoC . . . . 98 Contrle de ux de bout-en-bout au niveau local . . . . . . . . . . . . 99 Les instructions de routage dans lentte du paquet au travers des subNoCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 6.9 Le rapport frquence sur taille de la table TDMA . . . . . . . . . . . 102 6.10 Topologie et communications inter-zones de lapplication . . . . . . . 103 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 Le NoC et les connections crer entre les NIs . . . . . . . . . . . . Lapplication camra intelligente . . . . . . . . . . . . . . . . . . . . La topologie de lapplication de traitement dimage . . . . . . . . . Les contraintes de bande passante et de latence des communications Diagramme du transmeteur MC-SS DMA . . . . . . . . . . . . . . . Diagramme du rcepteur MC-CDMA . . . . . . . . . . . . . . . . . Architecture de la plate-forme pour le turbo dcodage . . . . . . . . Lhypothse permettant lexclusions entre des communications . . . . . . . . . . . 108 112 113 113 114 114 117 120

Liste des tableaux


3.1 3.2 3.3 3.4 3.5 3.6 5.1 5.2 6.1 6.2 6.3 7.1 7.2 7.3 7.4 7.5 7.6 Rpartition des tracs sur les canaux virtuels . . . . . . . Le champ tiquette du it dun paquet . . . . . . . . Les rservations des slots de temps dans la table TDMA La conguration des ExtraNIchannels . . . . . . . . . . . Requte de lecture . . . . . . . . . . . . . . . . . . . . . . Requte dcriture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 30 32 33 35 35 75 88

Types et scnarios dattaques . . . . . . . . . . . . . . . . . . . . . . . Les stratgies de protection aux attaques . . . . . . . . . . . . . . . .

Taille des fentres denvoi et rgles . . . . . . . . . . . . . . . . . . . . 101 Les cas dtude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Rsultats de latence et cot en taille de FIFO . . . . . . . . . . . . . 105 Synthse du NoC et de ses composants . . Rsultats . . . . . . . . . . . . . . . . . . . Les communications du transmetteur (TX) Les communications du rcepteur (RX) . . Les cas expriments . . . . . . . . . . . . Les rsultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 111 115 115 121 122

135

Bibliographie
[1] IST 4MORE project . European project 2004-2007, http ://4more.av.it.pt/. [2] S. Dutta, R. Jensen et A. Rieckmann, Viper : A Multiprocessor SOC for Advanced Set-Top Box and Digital TV Systems . IEEE Design and Test of Computers, vol. 18, pages 2131, Sept-Oct 2001. [3] INTERCONNECT . Rapport, The International Technology Roadmap for Semiconductors :2005, 2005. [4] L. Benini et G. De Micheli, Networks on Chip : A New Paradigm for Systems on Chip Design . In Proceedings of the conference on Design, automation and test in Europe, page 418, IEEE Computer Society, 2002. [5] W. J. Dally, Interconnect limited VLSI architecture . In International Interconnect Technology Conference Proceedings, pages 1517, 1999. [6] SIA. 1997. National technology roadmap for semiconductors . Rapport, Semiconductor Industry Association, 1997. [7] L. Benini et G. De Micheli, Networks on Chips : A New SoC Paradigm . Computer, vol. 35, no 1, pages 7078, 2002. [8] W. J. Dally et B. Towles, Route Packets, Not Wires : On-Chip Interconnection Networks . In Design Automation Conference, pages 684689, Jun 2001. [9] ARM - AMBA . http ://www.arm.com/armtech/AMBA/. [10] IBM - CoreConnect . http ://www.chips.ibm.com/products/coreconnect/. [11] H. Dubois, Analyse des systmes multiprocesseurs : Application la mise en oeuvre sous contraintes dalgorithmes de traitement dimages. Thse de Doctorat, Universit de Rennes I, ENSSAT LASTI, Lannion, 1991. [12] P. Guerrier et A. Greiner, A generic architecture for on-chip packet-switched interconnections . In Proceedings of the conference on Design, automation and test in Europe, pages 250256, ACM Press, 2000. [13] Arteris, A comparison http ://www.arteris.com, 2005. of Network-on-Chip and Busses .

[14] V. Bangalore et N. Nayak Sujir, Performance Enhancement of On-Chip communication Architecture using Multicast . On-chip communication Networks Research paper ,Spring 2002, 2002. [15] E. Bolotin, A. Morgenshtein, I. Cidon, R. Ginosar et A. Kolodny, Automatic Hardware-Ecient SoC Integration by QoS Network on Chip . In ICECS2004., 2004. 137

138

bibliographie

[16] T. Bjerregaard et S. Mahadevan, A Survey of Research and Practices of Network-on-Chip . ACM Computing Surveys (CSUR), vol. 38, page 1, 2006. [17] E. Rpkema, K.G.W. Goossens et A. Radulescu, Trade Os in the Design of a Router with Both Guaranteed and Best-Eort Services for Networks on Chip . In Design, Automation and Test in Europe Conference and Exhibition (DATE03), (Munich, Germany), March 03 - 07 2003. [18] L. M. Ni et P. K. McKinley, A Survey of Wormhole Routing Techniques in Direct Networks . Computer, vol. 26, no 2, pages 6276, 1993. [19] W. J. Dally et H. Aoki, Deadlock-Free Adaptive Routing in Multicomputer Networks Using Virtual Channels . IEEE Trans. Parallel Distrib. Syst., vol. 4, no 4, pages 466475, 1993. [20] W. J. Dally, Virtual-channel ow control . In Proceedings of the 17th annual international symposium on Computer Architecture, pages 6068, ACM Press, 1990. [21] M. Millberg, E. Nilsson, R. Thid et A. Jantsch, Guaranteed Bandwidth Using Looped Containers in Temporally Disjoint Networks within the Nostrum Network on Chip . In Design, Automation and Test in Europe Conference and Exhibition Volume II (DATE04), vol. 2, (Paris, France), page 20890, February 16 - 20 2004. [22] K. Goossens, J. Dielissen, J. van Meerbergen, P. Poplavkoy, A. Radulescu, E. Rpkema, E. Waterlander et P. Wielage, Guaranteeing the quality of services in networks on chip . Networks on chip, vol. Chapter 4, pages 6182, 2003. [23] A. Leroy, P. Marchal, A. Shickova, F. Catthoor, F. Robert et D. Verkest, Spatial division multiplexing : a novel approach for guaranteed throughput on NoCs . In CODES+ISSS 05 : Proceedings of the 3rd IEEE/ACM/IFIP international conference on Hardware/software codesign and system synthesis, (New York, NY, USA), pages 8186, ACM Press, 2005. [24] J. Bainbridge et S. Furber, Chain : A Delay-Insensitive Chip Area Interconnect . IEEE Micro, vol. 22, no 5, pages 1623, 2002. [25] F. Steenhof, H. Duque, B. Nilsson, K. Goossens et R. P. Llopis Peset Llopis, Networks on Chips for High-End Consumer-Electronics TV System Architectures . In Proc. Design, Automation and Test in Europe Conference and Exhibition (DATE), mar 2006. [26] S. Evain, J-Ph. Diguet et D .Houzet, Spider NoC Road Map . In Work. Future Interconnects and Networks on Chip Workshops (DATE06), (Munich, Germany), mar 2006. [27] J-P. Sansonnet, Le Transputer dInmos. Architecture des Machines Parallles . [28] L. Benini et G. De Micheli, Powering networks on chips : energy-ecient and reliable interconnect design for SoCs . In Proceedings of the 14th international symposium on Systems synthesis, pages 3338, ACM Press, 2001. [29] The network simulator - ns-2 . http ://nsnam.isi.edu/nsnam/index.php.

bibliographie

139

[30] Y.R. Sun, S. Kumar et A. Jantsch, Simulation and Evaluation for a Network on Chip Architecture using NS-2 . In Proc. NORCHIP 2002, Copenhagen., 2002. [31] F. Karim, A. Nguyen et S. Dey, An Interconnect Architecture for Networking Systems on Chips . Computer, vol. 22, no 5, pages 3645, 2002. [32] E. Bolotin, I. Cidon, R. Ginosar et A. Kolodny, QNoC : QoS architecture and design process for network on chip . Journal of Systems Architecture, 2003. [33] J. Dielissen, A. Radulescu, K. Goossens et E. Rpkema, Concepts and Implementation of the Philips Network-on-Chip . In IP-Based SOC Design, (Grenoble France), nov 2003. [34] H. Charlery et A. Greiner, Systmes intgrs : Un micro-rseau dinterconnexion commutation de paquets respectant la norme VCI . Troisime Colloque CAO de circuits et systmes intgrs, mai 2002. [35] M. DallOsso, G. Biccari, L. Giovannini, D. Bertozzi et L. Benini, Xpipes : a Latency Insensitive Parameterized Network-on-Chip Architecture for Multi-Processor SoCs . In IEEE International Conference on Computer Design (ICCD03), pages 536539, 2003. [36] K. Goossens, J. Dielissen, O. P. Gangwal, S. Gonzalez Pestana, A. Radulescu et E. Rpkema, A Design Flow for Application-Specic Networks on Chip with Guaranteed Performance to Accelerate SOC Design and Verication . In Proc. Design, Automation and Test in Europe Conference and Exhibition (DATE), march 2005. [37] D. Bertozzi, A. Jalabert, S. Murali, R. Tamhankar, S. Stergiou, L. Benini et G. De Micheli, NoC Synthesis Flow for Customized Domain Specic Multiprocessor Systems-on-Chip . IEEE Trans. Parallel Distrib. Syst., vol. 16, no 2, pages 113129, 2005. [38] S. Murali et G. De Micheli, SUNMAP : a tool for automatic topology selection and generation for NoCs . In DAC 04 : Proceedings of the 41st annual conference on Design automation, pages 914919, ACM Press, 2004. [39] S. Murali, L. Benini et G. De Micheli, Mapping and Physical Planning of Networks-on-Chip Architectures with Quality-of-Service Guarantees . In Design Automation Conference, 2005, vol. 1, (Shangai), pages 2732, Januray 2005. [40] A. Jalabert, S. Murali, L. Benini et G. De Micheli, xpipesCompiler : A Tool for Instantiating Application Specic Networks on Chip . In Proceedings of the Design, Automation and Test in Europe Conference and Exhibition Volume II (DATE04), page 20884, IEEE Computer Society, 2004. [41] P. Guerrier, Un rseau dinterconnexion pour systmes intgrs. Thse de Doctorat, Universit Pierre et Marie Curie LIP6, 2000. [42] A. Andriahantenaina, H. Charlery, A. Greiner, L. Mortiez et C. Albenes Zeferino, SPIN : A Scalable, Packet Switched, On-Chip MicroNetwork . In Design, Automation and Test in Europe Conference and Exhibition (DATE03 Designers Forum), page 20070, 2003. [43] A. Greiner, The SPIN & DSPIN networks on chip . Journe Informatique Embarque : Du matriel au Logiciel, 2005.

140

bibliographie

[44] A. Radulescu, J. Dielissen, K. Goossens, E. Rpkema et Paul Wielage, An Ecient On-Chip NI Oering Guaranteed Services, Shared-Memory Abstraction, and Flexible Network Conguration . In TCAD, 2004. [45] A. Hansson, K. Goossens et A. Rdulescu, A Unied Approach to Constrained Mapping and Routing on Network-on-Chip Architectures . In CODES+ISSS 05 : Proceedings of the 3rd IEEE/ACM/IFIP international conference on Hardware/software codesign and system synthesis, (New York, NY, USA), pages 7580, ACM Press, september 2005. [46] S. Murali, M. Coenen, A. Radulescu, K. Goossens et G. De Micheli, A Methodology for Mapping Multiple Use-Cases on to Networks on Chip . In Design, Automation and Test in Europe Conference and Exhibition (DATE), page 118, mar 2006. [47] E. Bolotin, I. Cidon, R. Ginosar et A. Kolodny, Cost considerations in Network on Chip . In Special issue on Networks on Chip, Integration - The VLSI Journal, 2003, 2003. [48] D. Rostislav, V. Vishnyakov, E. Friedman et R.Ginosar, An Asynchronous Router for Multiple Service Levels Networks on Chip . In ASYNC 05 11th IEEE International Symposium on Asynchronous Circuits and Systems (ASYNC05), vol. 0, pages 4453, 2005. [49] Arteris, Networks on Chip for Managing On-Chip Communications . SOCcentral, May 8 2006. [50] P. Martin, Design of a Virtual Component Neutral Network-on-Chip Transaction Layer . In DATE 05 : Proceedings of the conference on Design, Automation and Test in Europe, (Washington, DC, USA), pages 336337, IEEE Computer Society, 2005. [51] Arteris, Arteris and CoWare Announce Integration of Arteris Network on Chip (NoC) Technology into CoWare Platform Architect ESL Design Environment . http ://www.arteris.com, July 17 2006. [52] STNoC : Building a New System-on-Chip Paradigm . http ://www.st.com/stonline/press/news/back2005/b9014t.htm, December 2005. [53] L. Bononi et N. Concer, Simulation and analysis of network on chip architectures : ring, spidergon and 2D mesh . In DATE 06 : Proceedings of the conference on Design, automation and test in Europe, (3001 Leuven, Belgium, Belgium), pages 154159, European Design and Automation Association, 2006. [54] Arteris Announces STMicroelectronics Use of NoC for Next Generation Wireless Infrastructure Platform . http ://www.arteris.com, March 15 2006. [55] T. Bjerregaard, The MANGO Clockless Network-on-Chip : Concepts and Implementation. Thse de Doctorat, Technical University of Denmark, 2005. [56] E. Beign, F. Clermidy, P. Vivet, A. Clouard et M. Renaudin, An Asynchronous NOC Architecture Providing Low Latency Service and its Multi-level Design Framework . In ASYNC 05 11th IEEE International Symposium on Asynchronous Circuits and Systems (ASYNC05), pages 5463, 2005.

bibliographie

141

[57] Y. Durand, C. Bernard et D. Lattard, FAUST : On-chip distributed architecture for a 4G baseband modem SoC . In Design & Reuse IP-SoC, (Grenoble, France), Dec. 2005. [58] F. Clermidy, D. Varreau et D. Lattard, A NoC-based communication framework for seamless IP integration in complex systems . In Design & Reuse IP-SoC, Grenoble, France, dcembre 2005. [59] S. Fujita, K. Abe1, K. Nomura1 et T. Lee, Novel Performance of Threedimensional (3D) On-chip Crossbar Bus using non- Silicon Transistors . DATE 06 Workshop, Future Interconnects and Networks on Chip, Munich, Germany, 2006. [60] O. Connor et F. Gaffiot, Advanced Research in on-chip optical interconnects . Lower Power Electronics and Design, 2004. [61] D. Zhao, S. Upadhyaya et M. Margala, Design of a wireless test control network with radio-on-chip technology for nanometer system-on-a-chip . IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol. 25, pages 1411 1418, July 2006. [62] S. Evain, J-Ph. Diguet et D. Houzet, A Generic CAD Tool for Ecient NoC Design . In IEEE Int. Symp. on Intelligent Signal Processing and Communication Systems (ISPACS), (Seoul, Korea), pages 728733, nov 2004. [63] T. Marescaux, J-Y. Mignolet, A. Bartic, W. Moffat, D. Verkest, S. Vernalde et R. Lauwereins, Networks on Chip as Hardware Components of an OS for Recongurable Systems . In Intl. Conf. on Field Programmable Logic and Applications (FPL), (Lisbon, Portugal), pages 595605, September 2003. [64] Y. W. Lu, G. K. Yeh et J. B. Burr Spa, A 15mW 1.6Gb/s Wormhole Data Router for 2-D Meshes . Symp. on VLSI Circuits, 1996., 1996. [65] J. A. Williams, N. W. Bergmann et X. Xie, FIFO Communication Models in Operating Systems for Recongurable Computing . In FCCM 05 : Proceedings of the 13th Annual IEEE Symposium on Field-Programmable Custom Computing Machines (FCCM05), (Washington, DC, USA), pages 277278, IEEE Computer Society, 2005. [66] J. A. Williams et N. W. Bergmann, Programmable parallel coprocessor architectures for recongurable system-on-chip . In Field-Programmable Technology, pages 193 200, 6-8 Dec 2004. [67] M. Coenen, S. Murali, A. Rdulescu, K. Goossens et G. De Micheli, A buer-sizing Algorithm for Networks on Chip using TDMA and credit-based endto-end Flow Control . In Intl Conference on Hardware/Software Codesign and System Synthesis (CODES+ISSS), (Seoul, Korea), octobre 2006. [68] O. P. Gangwal, A. Radulescu, K. Goossens, S. Gonzalez Pestana et E. Rijpkema, Building Predictable Systems on Chip : An Analysis of Guaranteed Communication in the thereal Network on Chip . In Dynamic and Robust Streaming In And Between Connected Consumer-Electronics Devices (Peter van der Stok (ed.)), 1 ., Kluwer, 2005. [69] S. Murali, M. Coenen, A. Rdulescu, K. Goossens et G De Micheli, Mapping and Conguration Methods for Multi-Use-Case Networks on Chips . In

142

bibliographie Proc. Design Automation Conference. Asia and South Pacic (ASP-DAC), jan 2006.

[70] C. Marcon, M. Kreutz, N. Calazans et A. Susin, Models for Embedded Application Mapping onto NoCs : Timing Analysis . In RSP2005 International Workshop on Rapid System Prototyping, vol. 00, (Montreal, Canada), pages 17 23, June 8-10, 2005 2005. [71] S. Evain, J-Ph. Diguet et D .Houzet, Spider : a CAD Tool for ecient NoC design . In IEEE NORCHIP, (Oslo, NORWAY), pages 218221, nov 2004. [72] D. Andreasson et S. Kumar, Slack-time aware routing in NoC systems . In International Symposium Circuits and Systems (ISCAS), pages 23532356, 2005. [73] S. Evain et J-Ph. Diguet, From NoC Security Analysis To Design Solutions . In IEEE Work. on Signal Processing Systems (SIPS), (Athens, Greece), pages 166171, oct 2005. [74] D. Park, C. Nicopoulos, J. Kim, N. Vaykrishnan et C. R. Das, Exploring Fault-Tolerant Network-on-Chip Architectures . In Proceedings of the 2006 International Conference on Dependable Systems and Networks (DSN06), pages 93104, June 2006. [75] C. H. Gebotys et R. J. Gebotys, A framework for security on NoC technologies . In VLSI, 2003. Proceedings. IEEE Computer Society Annual Symposium, pages 113 117, 20-21 Feb. 2003. [76] K. Goossens, P. Wielage, A. Peeters et J. van Meerbergen, Networks on Silicon : Combining Best-eort and Guaranteed Services . In Proceedings of Design Automation and Test Conference in Europe, pages 423425, March 2002. [77] J. Mitola., The software radio architecture . IEEE Communications Magazine, vol. 33, pages 2638, May 1995. [78] F-X. Standaert, L van Oldeneel tot Oldenzeel, D. Samyde et J-J. Quisquater, Power Analysis of FPGAs : How Practical is the Attack ? . In FPL, pages 701711, 2003. [79] T. Marescaux, A. Bartic, D. Verkest, S. Vernalde et R. Lauwereins, Interconnection Networks Enable Fine-Grain Dynamic Multi-Tasking on FPGAs . In FPL02, pages 795805, Sep 2002. [80] L. Bossuet, W. Burleson et G. Gogniat, Dynamically Congurable Security for SRAM FPGA Bitstreams . In IEEE Recongurable Architectures Workshop, RAW, Workshop of IEEE IPDPS,, (Santa F, New Mexico, USA), april 2004. [81] T. Martin, M. Hsiao, D. Ha et J. Krishnaswami, Denial-of-Service Attacks on Battery-powered Mobile Computers . In IEEE Pervasive Computing Conference, (Orlando, Florida), pages 309318, March 2004. [82] S. Evain, J-Ph. Diguet et D .Houzet, NoC design ow for TDMA and QoS Management in a GALS context . EURASIP Journal on Embedded Systems, vol. 2006, 2006. [83] D. Wiklund, Mesochronous clocking and communication in on-chip networks . In Proc. Swedish system-on-chip conference (SSoCC03), (Eskilstuna), April 8-9 2003.

bibliographie

143

[84] A. Lines, Nexus : an asynchronous crossbar interconnect for synchronous system-on-chip designs . In Proc. 11th Symposium on High Performance Interconnects, pages 29, 20-22 Aug 2003. [85] T. Bjerregaard et J. Spars, A Scheduling Discipline for Latency and Bandwidth Guarantees in Asynchronous Network-on-Chip . In ASYNC 05 11th IEEE International Symposium on Asynchronous Circuits and Systems, pages 3443, 2005. [86] D. Hillman, Using Mobilize Power Management IP for Dynamic and Static Power Reduction in SoC at 130 nm . In Design, Automation and Test in Europe, 2005. Proceedings, September 30 2005. [87] L. P. Carloni et A. L. Sangiovanni-Vincentelli, Coping with Latency in SOC Design . computer IEEE Micro, vol. 22, no 5, pages 2435, 2002. [88] J-Ph. Diguet, G. Gogniat, J. L. Philippe, Y. Le Moullec, S. Bilavarn, C. Gamrat, K. Ben Chehida, M. Auguin, X. Fornari et P. Kajfasz, EPICURE : A partitioning and co-design framework for recongurable computing . Journal of Microprocessors and Microsystems, vol. 30, pages 367387, 2006. [89] Y. Eustache, J-Ph. Diguet et M. Elkhodary, RTOS-based Hardware Software Communications and Conguration Management in the context of a Smart Camera . In Engineering of Recongurable Systems and Algorithms (ERSA06), 2006. [90] A. Chouly, A. Brajal et S. Jourdan, Orthogonal multicarrier techniques applied to direct sequence spread spectrum CDMA systems . In GLOBECOM93, pages 17231728, 1993. [91] J. Delorme, D. Houzet, R. Lemaire, et D. Lattard, Proposition of a benchmark for evaluation of cores mapping onto noc architectures . In ReCoSoC05 conference, (Montpellier, France), June 2005. [92] O. Muller, A. Baghdadi et M. Jezequel, ASIP-Based Multiprocessor SoC Design for Simple and Double Binary Turbo Decoding . In IEEE/ACM Design, Automation and Test in europe, (Munich, Germany), March 6-10 2006.

Acronymes et Abrviations
AHB Advanced High-speed Bus ALG Asynchronous Latency Guarantee ANoC Asynchronous Network-on-Chip ASIC Application Specic Integrated Circuit AXI BE Advanced eXtensible Interface Best-Eort

CAO Conception assiste par ordinateur CCM Central Conguration Module DMA Direct Memory Access DPA Dierential power analysis DTD Document Type Denition FAUST Flexible Architecture of Unied System for Telecom FIFO First In First Out FLIT FLow control unIT FPGA Field Programmable Gate Array FSL GS GT IPs Fast Simplex Link Guaranteed Services Guaranteed Throughput Intellectual Property GALS Globally asynchronous, locally synchronous

LME Light Mutual Exclusion MC-CDMA Multi-Carrier Code Division Multiple Access MC-SS-MA Multi-Carrier Spread Spectrum Multiple Access ME Mutual Exclusion MIMO Multiple-Input Multiple-Output 145

146 NA NI NoC NS2 Network Adapter Network Interface Network on Chip Network Simulator

bibliographie

NTTP NoC Transaction and Transport Protocol OCP Open Core Protocol OPB On-chip Peripheral Bus OS OSI QDI QoS RoC RTL SCP SoC SPA TC Operating System Open Systems Interconnection Quasi-Delay-Insensitive Quality of Service Radio-on-Chip Register Transfer Level Self Complemented Path System on Chip Source Path Authentication Time Coder

PHIT PHysical unIT

R-PUCE Rseau embarqu sur PUCE

RTOS Real-time operating system SDM Spatial Division Multiplexing

TBP Trusted Boomerang Path TDMA Time Division Multiple Access TLM Transaction level modeling TR VC VCI Time-routing Virtual Channel Virtual Component Interface UMARS Unied MApping, Routing and Slot allocation

VHDL Very High Speed Integrated Circuit Hardware Description Language XML eXtensible Markup Language