La présente invention concerne de façon générale la technologie d'interconnexion de semi-conducteurs de Propriété Intellectuelle (IP, "Intellectual Property"). De nombreuses topographies de semi-conducteurs, tant pour les Circuits Intégrés (IC) que pour les Ré-seaux Prédiffusés Programmables (FPGA), sont construites d'une manière modulaire par combinaison d'un ensemble de coeurs IP, comme par exemple des Unités Centrales de Traitement (CPU), des Processeurs de Signaux Numéri- ques (DSP), des blocs de traitement vidéo et de gestion de réseaux, des contrôleurs de mémoires, et analogues, avec un système d'interconnexion. Le système d'inter-connexion met en ouvre les communications au niveau système de la topologie particulière. Les coeurs IP sont typiquement conçus à l'aide d'un protocole d'interface IP standard, soit publique soit propriétaire. Ces protocoles d'interface IP sont appelés "protocoles de transactions". A titre d'exemple de protocole de transactions, on peut citer le protocole OCP ("Open Core Protocol") d'OCP-IP, ainsi que l'interface extensible AXI° ("Advanced Extensible Interface") et le Bus Hautes Performances AHB® ("Advanced High-performance Bus") d'Arm Inc. Les technologies d'interconnexion de coeurs IP ont évolué avec les topographies de semi-conducteurs, qui sont passées de topographies simples et de relativement petite taille ayant peu de coeurs IP à des topo-graphies complexes et de grandes tailles pouvant contenir des centaines de coeurs IP. La première génération de technologie d'intercon- nexion de cours IP consistait en un ensemble hiérarchique de bus et de barres croisées, appelées "crossbars". L'interconnexion elle-même consiste principalement en un ensemble de fils, connectant les coeurs IP entre eux, et un ou plusieurs arbitres arbitrant l'accès au sys- tème de communication. Une approche hiérarchique est 2961048 - 2 utilisée pour séparer les communications à grande vitesse et hautes performances de sous-systèmes moins rapides et moins performants. Cette solution est appropriée pour les topographies simples. Une topologie corn- 5 mune utilisée pour ce type d'interconnexion est soit un bus soit un crossbar. Les avantages et inconvénients de ces deux topologies sont parfaitement connus. La topologie de type bus présente un plus petit nombre de fils, ce qui permet de réduire l'espace occupé et donc 10 le coût, mais elle est limitée en bande passante. L'approche crossbar, utilisant un grand nombre de fils, offre une bande passante de communication globale plus élevée. Un inconvénient majeur de l'approche ci-dessus 15 réside dans le fait que la réutilisation des coeurs IP est limitée. Les interfaces de tous les coeurs IP se connectant à la même interconnexion doivent être identiques. Il peut en résulter une nécessité de reconcevoir l'interface d'un coeur IP ou de concevoir une logi- 20 que de pontage lorsqu'un coeur IP particulier doit être utilisé dans un autre système. La première génération d'interconnexion met également en oeuvre une quantité limitée de fonctions au niveau système. On peut décrire cette première généra- 25 tion de technologie d'interconnexion de coeurs IP comme étant une solution couplée. Du fait que les interfaces IP ne sont logiquement et physiquement pas indépendantes les unes des autres, elles sont couplées de façon telle qu'une modification d'une interface nécessite la 30 modification de toutes les interfaces. La deuxième génération d'interconnexion IP est une mise en oeuvre partiellement découplée des topolo- gies de bus et de crossbar décrites ci-dessus. Dans ces solutions, le protocole de communication interne du 35 système de communication, ou protocole de transport, 2961048 - 3 est découplé du protocole d'interface IP, ou protocole de transaction. Ces solutions sont plus flexibles pour ce qui est de la réutilisation des coeurs IP du fait que, dans ces solutions, l'intégrateur de systèmes à 5 semi-conducteurs peut connecter des coeurs IP ayant des interfaces différentes au même système de communication, par l'intermédiaire de certains moyens permettant la configuration. La troisième génération de technologie d'inter- 10 connexion de coeurs IP est le Réseau sur puce (NoC, "Network-on-Chip"), qui met en oeuvre non seulement un découplage entre couche de transaction et couche de transport, mais également un découplage net entre cou- che de transport et couche physique. L'innovation clé à 15 la base de cette solution est le conditionnement des informations de la couche de transaction sous la forme de paquets. Les commandes et les données qui doivent être transportées sont encapsulées dans un paquet et le transport du paquet sur le support physique est indé- 20 pendant de la couche physique. Le format de paquet com- prend un en-tête et une charge utile. La charge utile contient les données et des qualificatifs associés aux données, tels que des signaux d'activation d'octets ("byte-enable"). L'en-tête contient des informations de 25 routage, des adresses au niveau système, des informa- tions de contrôle additionnelles, tels que des indica- teurs en rapport avec la sécurité. Dans cette architec- ture, le NoC est construit par le fait de connecter en- tre eux un ensemble d'éléments IP tels que des unités 30 d'interfaces de réseau, des commutateurs, des synchro- niseurs, des convertisseurs de largeur, via des liai- sons physiques. Les éléments sont sélectionnés et connectés de manière à satisfaire aux critères de pro- tocole, performances, qualité de service (QoS, "Quality 35 of Service"), et spécifications de superficie et de 2961048 - 4 synchronisation du Système sur Puce (SoC, "System-on-Chip") Une difficulté de conception liée aux technologies d'interconnexion sur puce et de NoC réside dans la 5 nécessité de satisfaire aux spécifications de QoS du circuit intégré (IC). Chaque flux de données échangé entre un initiateur et une cible a ses propres spécifications de bande passante et de latence, qui doivent être satisfaites par l'interconnexion sur puce. Un cer- 10 tain type de trafic, tel que le trafic envoyé par une CPU à un contrôleur de DRAM, présente une contrainte de faible latence. Un autre type de trafic, tel que le trafic provenant d'un bloc de traitement vidéo, a une contrainte en bande passante qui est pilotée par la na- 15 ture "temps réel" du flux de données. Un autre type de trafic peut présenter un comportement sporadique, c'est-à-dire que le trafic peut nécessiter de façon intermittente un accès à large bande passante à une ressource cible. 20 Nous allons maintenant décrire des formes de réalisation de systèmes et de procédés permettant la gestion des arbitrages de transferts dans un NoC. L'utilisation de ces systèmes et procédés permet l'exploitation de signaux d'interfaces supplémentaires au niveau 25 des interfaces des coeurs IP du NoC, et la mise en oeuvre dans le NoC de structures logiques tirant avantage des informations sur les signaux d'interface pour gérer les priorités de traitement des paquets de demande et de réponse à l'intérieur du NoC. 30 D'autres aspects et avantages de la présente invention seront mieux compris à la lecture de la description détaillée ci-après, prise conjointement avec les dessins ci-joints, dans lesquels : la figure 1 est un schéma fonctionnel d'un NoC 35 représentatif ; la figure 2 présente un exemple de liaison physique ; la figure 3 présente un exemple de séquence de transport d'un paquet ; la figure 4 présente un paquet représentatif ; la figure 5A présente un élément de commutation représentatif la figure 5B présente un paquet représentatif, comprenant un en-tête contenant un champ Urgence la figure 6 présente un exemple de liaison physique avec une signalisation hors-bande ; la figure 7 présente un exemple de structure d'arbitrage à plusieurs niveaux dans une interconnexion sur puce ; la figure 8 est un organigramme d'un processus représentatif pour la mise en oeuvre de fonctionnalités de QoS dans une structure d'arbitrage à plusieurs ni-veaux dans une interconnexion sur puce ; la figure 9 présente un exemple de routage à 20 l'intérieur d'une interconnexion sur puce. NoC représentatif La Figure 1 présente un schéma fonctionnel d'un NoC 100 représentatif. Dans certaines formes de réalisation, le NoC 100 peut être construit à partir d'un ensemble d'éléments IP 102 qui communiquent entre eux au moyen d'un protocole de transport à base de paquets. On peut citer comme exemples non limitatifs d'éléments IP 102 : les commutateurs 102a, les convertisseurs d'horloge 102b, les régulateurs de bande passante 102c, les FIFO ("First-In-First-Out", ou "Premier Entré- Premier Sorti") synchrones 102d, les convertisseurs de largeur 102e, les convertisseurs d'Endian (ordre des octets) 102f, les adaptateurs de débit 102g, les isolateurs de puissance 102h et d'autres éléments IP. - 6 Dans certaines formes de réalisation, au niveau des bords du NoC 100, des Unités d'Interface de Réseau (NIU, "Network Interface Unit") 104 réalisent une conversion entre le protocole de transaction et le protocole de transport (pour les informations entrantes) et inversement (pour les informations sortantes). On peut citer comme exemples non limitatifs de NIU pour les protocoles de transaction : la NIU OCP 104a, la NIU AXI° 104b, la NIU AHB° 104c, l'ordonnanceur de mémoire 104d et une NIU propriétaire 104e. Les NIU 104 sont couplées à différents coeurs IP 110. On peut citer comme exemples de coeurs IP : le DSP 110a, la CPU 110b, le module DMA (Accès Direct à la Mémoire) 110c, le sous-système OCP 110d, la DRAM 110e, la SRAM 110f et d'autres types de coeurs IP. Dans le NoC 100, le protocole de transport est à base de paquets. Les commandes de la couche de transaction peuvent comprendre des instructions de chargement et de stockage d'un ou plusieurs mots de données qui sont convertis en paquets pour la transmission sur les liaisons physiques. Les liaisons physiques forment des connexions entre les éléments IP. Nous allons maintenant décrire une forme de réalisation d'un protocole de transport utilisé par le NoC 100, en liaison avec la Figure 2. Exemple de liaison physique La Figure 2 est un schéma fonctionnel d'un exemple de liaison physique 200 connectant un émetteur (TX) 202 et un récepteur (RX) 204 dans le NoC 100 de la Figure 1. Une interface de connexion ("socket") au protocole de transport peut être utilisée pour le transfert d'un paquet de l'émetteur 202 au récepteur 204 sur la liaison physique 200. L'interface de connexion peut contenir des signaux de contrôle de flux (Vld, Rdy), 2961048 - 7 des signaux de gestion de trames (Head, Tail) et des signaux d'informations (Data). L'interface de connexion peut être une interface synchrone travaillant sur les fronts montants d'un signal d'horloge (Clk). Un signal de réinitialisation de niveau actif bas (RStN) peut également être inclus dans la couche physique 200. Les significations logiques des différents signaux utilisés dans cette forme de réalisation particulière sont les suivantes : - Vld : indique que l'émetteur 202 présente des informations valides (signaux Head, Tail et Data) dans un cycle d'horloge en cours. Lorsque le signal Vld est inactif, l'émetteur 202 envoie une valeur X sur les signaux Head, Tait et Data et le récepteur 204 supprime ces signaux. Une fois que l'émetteur 202 a activé le signal Vld, les signaux Head, Tail, Data et Vld restent constants jusqu'à ce que le signal Rdy soit activé par le récepteur 204. Dans cette forme de réalisation particulière, la largeur du signal Vld peut être de 1, mais d'autres largeurs peuvent également être utilisées. - Rdy : indique que le récepteur 204 est prêt à recevoir le signal Data dans un cycle d'horloge en cours. Le signal Rdy peut dépendre (en combinaison) des signaux Vld, Head, Tait et Data, ou peut ne dépendre que de l'état interne du récepteur 204. Dans cette forme de réalisation particulière, la largeur du signal Rdy peut être de 1, mais d'autres largeurs peuvent également être utilisées. - Head : indique un premier cycle d'horloge d'un paquet. Dans cette forme de réalisation particulière, la largeur du signal Head peut être de 1, mais d'autres largeurs peuvent également être utilisées. - Tail : indique un dernier cycle d'horloge d'un paquet. Dans cette forme de réalisation particulière, la largeur du signal Tail peut être de 1, mais d'autres largeurs peuvent également être utilisées. - Data : informations effectives transférées par l'émetteur 202 au récepteur 204. Le signal Data contient un en-tête et une charge utile. Un transfert de mot de données peut être effectué lorsque les signaux Vld et Rdy sont tous les deux actifs. La largeur du signal Da-ta peut être configurable. Exemple de séquence de transport de paquet La Figure 3 présente un exemple de séquence de transport de paquet sur la liaison de la Figure 2. Dans certaines formes de réalisation, un paquet démarre lorsque les signaux Vld et Head passent à l'état actif et se termine lorsque les signaux Vld et Tai]. passent à l'état actif. Dans un paquet d'un seul cycle, les deux signaux Head et Tait peuvent être actifs en même temps. A l'intérieur d'un paquet, le signal Head est inactif lorsque le signal Vld est actif et, à l'extérieur d'un paquet, le signal Head est actif en même temps que le signal Vld. Le contenu d'un paquet est transporté sur les signaux Data. Dans cette forme de réalisation particulière, il existe deux formats de paquets : les paquets avec charge utile (par exemple, demandes d'écriture, réponses de lecture) et les paquets sans charge utile (par exemple, tous les autres types de paquets). Paquet représentatif La Figure 4 présente un paquet représentatif à utiliser avec le NoC 100 de la Figure 1. Plus particulièrement, la Figure 4 illustre un paquet représentatif 400 comprenant un en-tête 402 et une charge utile 404. Le paquet représentatif 400 peut être défini par une largeur de charge utile de quatre octets (ayant des fonctionnalités d'activation d'octets ("byte-enable")) et une pénalité d'en-tête d'un cycle. Dans certaines - 9 formes de réalisation du paquet 400, certains champs peuvent être facultatifs. Dans certaines formes de réalisation, l'en-tête 402 comprend un champ d'en-tête contenant un champ de routage RoutelD, un champ Adresse et plusieurs champs Contrôle. Les champs Contrôle de l'en-tête 402 peuvent transporter des informations additionnelles de protocole de bout en bout ou de transport. L'utilisation de ce champ Contrôle pour la mise en oeuvre de fonctionnalités de QoS fait l'objet de la présente invention et sera décrite plus en détail ci-après. Les significations des autres champs de l'en-tête 402 sont les suivantes : - Adresse : ce champ d'en-tête indique l'adresse de départ d'une transaction, exprimée en octets, dans l'espace d'adresse cible. - RoutelD : ce champ d'en-tête identifie de manière univoque une paire "mappage initiateur/mappage cible". La paire peut être une information unique utilisée par des tables de routage pour diriger un paquet à l'intérieur du NoC 100. Les champs de la charge utile du paquet peuvent être un champ d'activation d'octet BE ("Byte-Enable") et un champ de données (Byte). Les significations de ces champs sont les suivantes : - BE : indique un bit unique d'activation d'octet ("Byte-Enable") par octet de charge utile. - Byte : ce champ contient la partie charge utile du paquet. La largeur de ce champ est configurable et, dans certaines formes de réalisation, contient au moins 8 bits de données. La largeur d'un champ Byte peut être étendue de façon à contenir des informations additionnelles telles que des informations de protection ou de sécurité. Arbitrage des commutations, Urgence et Pression La figure 5A présente un élément de commutation - représentatif 500. Dans cet exemple particulier, trois entrées 501a à 501c envoient des paquets à une unique sortie 504. Lorsque des paquets arrivent au niveau de l'élément de commutation 500 et sont adressés à l'uni-que sortie 504 du commutateur 500, un point d'arbitrage 502 est introduit. On connaît de nombreux mécanismes d'arbitrage, qui peuvent être utilisés pour un arbitrage au niveau du point d'arbitrage 502. Ces mécanismes comprennent, mais sans y être limités : la permutation circulaire, la considération Premier Entré-Premier Sorti (FIFO, "First-In-First-Out"), la considération de l'ancienneté (LRU, "Least-Recently Used"), la notion de Priorité Fixe, et tout autre mécanisme pouvant être utilisé pour un arbitrage. Ces mécanismes d'arbitrage statique opèrent sur les informations d'un point d'entrée (ou "port") sur lequel arrive un paquet particulier, et sur l'historique des arbitrages précédents. Cependant, dans de nombreux agencements, il est souhaitable d'utiliser un mécanisme d'établissement de priorités dynamique. Avant de décrire un mécanisme d'arbitrage dynamique, nous allons tout d'abord expliquer le concept d'"Urgence". Le champ Urgence est un indicateur de la priorité relative d'un paquet, qui est utilisé par les points d'arbitrage d'un NoC pour la mise en oeuvre d'un mécanisme d'arbitrage à plusieurs niveaux, dans lequel la sélection d'un transfert de sortie parmi une pluralité de transferts d'entrée disponibles est effectuée selon un arbitrage statique entre des transferts ayant des valeurs d'urgence égales. Dans certaines formes de réalisation, la priorité la plus élevée peut être élevée à la valeur d'urgence la plus élevée. Dans une autre forme de réalisation, des priorités différentes peuvent être allouées à des valeurs d'urgence différentes. - 11 - Le mécanisme décrit ci-dessus met en oeuvre un arbitrage dynamique. Des transferts ayant la priorité la plus élevée, telle que déterminée par exemple par leur valeur d'urgence, sont considérés en premier et sont arbitrés à l'aide d'un mécanisme d'arbitrage fixe. S'il n'y a aucun transfert au niveau de priorité le plus élevé, les transferts ayant le niveau de priorité suivant peuvent être considérés pour un transfert, etc. Dans une forme de réalisation, le même mécanisme d'arbitrage statique peut être utilisé pour les arbitrages de chaque niveau de priorité. Dans d'autres formes de réalisation, des niveaux de priorité différents peuvent avoir des mécanismes d'arbitrage statique différents. Dans certaines formes de réalisation, une valeur d'urgence est codée intrabande avec le transfert. Par exemple, dans une interconnexion basée sur le niveau transaction telle qu'un crossbar OCP, la valeur d'urgence peut être transmise avec les informations de commande. Selon un autre exemple, dans un NoC, l'urgence peut être transmise dans l'en-tête du paquet. Dans une forme de réalisation, le codage peut être binaire, de sorte que n bits (par exemple, 3 bits) permettent m = 2^n niveaux d'urgence (par exemple, m = 8 niveaux avec 3 bits). Dans une autre forme de réalisation, les informations d'urgence sont codées à l'aide d'un codage de type histogramme. Dans une forme de réalisation de codage de type histogramme, la valeur de l'urgence est indiquée par le bit de valeur "1" ayant la position la plus élevée dans un champ multi-bits, dont les bits des positions inférieures ont également la valeur "1". Dans cet exemple, un champ à 3 bits peut indiquer 4 niveaux d'urgence avec les quatre valeurs "000", "001", "011" et "111". Cette forme de réalisation ainsi que d'autres du codage de type histogramme sont particulièrement ef- - 12 - ficaces pour la combinaison des informations d'urgence de plusieurs sources en un résultat commun, du fait qu'une simple fonction OU peut être utilisée pour obtenir le résultat souhaité. Du fait que la valeur d'urgence est codée dans l'en-tête d'un paquet, ou est transmise avec les commandes ou les données, la valeur est considérée comme un signal intrabande. La figure 5B illustre une forme de réalisation d'un paquet 506 dans lequel le champ Urgence est un champ de 4 bits 510 transféré à l'intérieur de l'en-tête 508. Hormis l'inclusion du champ 510 dans l'en-tête 508, le paquet 506 est identique au paquet 400 représenté sur la figure 4. Dans une interconnexion sur puce, dans laquelle un chemin particulier entre un initiateur et une cible peut comprendre plusieurs points d'arbitrage en série, si l'urgence est codée dans l'en-tête ou envoyée intrabande avec une commande, un arbitre situé plus bas sur le chemin ne peut pas prendre en compte la priorité d'un paquet qui n'a pas encore atteint le point d'entrée de l'arbitre. Il peut en résulter un retard dans le traitement d'un paquet à priorité plus élevée. Pour tenter de résoudre ce problème de retard potentiel, l'invention, dans une forme de réalisation, introduit le concept de "pression". La pression est un signal hors-bande qui peut inclure un ou plusieurs bits per-mettant de transporter hors-bande à travers le NoC les informations d'urgence du champ Urgence. Dans une forme de réalisation, le signal de pression peut être un faisceau d'un ou plusieurs fils physiques faisant partie des liaisons physiques qui relient entre eux différents éléments IP sur un NoC. Le signal de pression peut transporter des informations hors-bande, d'une manière que nous décrirons plus en détail ci-après en relation avec la figure 6. Exemple de Liaison Physique avec Pression - 13 - La figure 6 présente un schéma fonctionnel d'un exemple de liaison physique 600 étendant la liaison physique 200 de la figure 2, pour incorporer un signal de pression ("Priority") hors-bande 604. Lorsqu'un paquet du réseau sur puce est transmis à travers le NoC et rencontre une contre-pression, c'est-à-dire que le signal RdY est passé à l'état inactif, ce qui empêche en fait le paquet de progresser à travers le réseau, le signal de pression hors-bande 604 sur la liaison physique 600 prend la valeur de l'urgence qui est codée dans l'en-tête de ce paquet particulier. Une contre-pression se produit normalement à un point auquel un arbitrage est effectué, du fait que la fonction de base de la logique d'arbitrage consiste à sélectionner parmi une pluralité de paquets un paquet à laisser passer tout en retenant les paquets non sélectionnés à l'aide d'une contre-pression. Ce mécanisme de pression décrit ci-dessus permet la propagation de la valeur d'urgence d'un paquet à l'avant du paquet, du fait que le signal de pression 604 est transmis hors-bande. Dans cette forme de réalisation particulière, les valeurs de pression hors-bande sont acheminées vers l'avant à partir du point d'origine, par tous les chemins qui sont soumis à une contre-pression. Avec la mise en oeuvre du mécanisme de pression, un arbitre, lors d'un arbitrage, peut considérer deux valeurs lorsqu'il décide quel paquet d'entrée sélectionner : la valeur d'urgence intrabande du paquet courant et la valeur de pression hors-bande du signal de pression 604 sur la liaison 600 associée au port d'entrée. Dans une forme de réalisation, la valeur de priorité peut être déterminée à partir du maximum entre la valeur d'urgence et la valeur de pression. La figure 7 illustre un exemple d'une structure d'arbitrage à plusieurs niveaux 700 dans une intercon- 2961048 - 14 - nexion sur puce. Des points d'arbitrage à deux entrées 701 et 702 effectuent une sélection entre trois liai-sons d'entrée 710, 711 et 712. Dans cette forme de réalisation, le point d'arbitrage 702 a un arbitrage fixe, donnant toujours la priorité la plus élevée à la liaison 712 pour des niveaux égaux d'urgence intrabande. Supposons qu'un paquet a commencé un transfert sur la liaison 711 et est maintenant présenté au point d'arbitrage 702 sur la liaison 713. Tant que de nouvel-les requêtes sont présentées sur la liaison 712, le paquet se trouvant sur la liaison 713 est soumis à une contre-pression et n'est pas sélectionné par le mécanisme d'arbitrage au point d'arbitrage 702. Si maintenant, un paquet à urgence élevée arrive sur la liaison 710, ce paquet ne peut pas être arbitré par le point 701 du fait que le paquet sur la liaison 711 est déjà sélectionné et "attend" sur la liaison 713. Grâce au mécanisme de pression, la valeur d'urgence du paquet sur la liaison 710 sera transférée via le signal de pression hors-bande sur la liaison 713. Si cette valeur de pression est supérieure à la valeur d'urgence des paquets présents sur la liaison 712, le point d'arbitrage 702 arbitrera les paquets se trouvant sur la liaison 713 en traitant en premier le paquet qui provenait de la liaison 711, et en traitant ensuite le paquet à urgence élevée provenant de la liaison 710. Signaux d'interface Trois signaux peuvent être définis au niveau de l'interface de niveau transaction du NoC (par exemple, une interface avec un coeur IP). Dans une forme de réalisation de l'invention, les signaux peuvent être appelés "IF Urgence", "IF Pression" et "IF Haute Urgence", où le préfixe "IF" fait référence au terme "Interface". Chacun de ces trois signaux peut être configuré de fa- 2961048 - 15
çon à faire un ou plusieurs bits de long, et un niveau de priorité peut être codé sur ces bits au moyen, par exemple, d'un codage binaire. Tous les signaux n'ont pas besoin d'être présentés ou utilisés au niveau de l'interface de niveau transaction. Dans une forme de réalisation, la sélection des signaux qui doivent être implémentés au niveau de l'interface peut être configurable par un utilisateur via une Interface Graphique Utilisateur (GUI), indépendamment pour chaque interface de niveau transaction de l'interconnexion sur puce. La GUI peut aussi servir à configurer la décision de traiter la réponse avec la priorité ou de la traiter en fonction du type de demande. Dans de la NIU de l'initiateur, lorsque les in- formations au niveau transaction sont mises en paquets, les informations du signal IF_Urgence sont utilisées pour définir le champ Urgence de l'en-tête du paquet. Dans une forme de réalisation, le champ Urgence est dé-terminé à partir du signal IF_Urgence au moyen d'un établissement de correspondance biunivoque, mais d'autres types d'établissement de correspondance peuvent également être utilisés. Ces autres types d'établissement de correspondance sont utiles pour traduire les valeurs du signal IF_Urgence de l'interface de niveau transaction locale en valeurs globales à l'échelle du système. La sélection de valeurs du signal IF_Urgence peut être définie par la topographie du coeur IP, et ces valeurs sont susceptibles de ne pas être cohérentes avec les besoins du système lorsque plusieurs coeurs IP conçus indépendamment sont interconnectés via un NoC. Dans une architecture de NoC, les chemins de de-mande et de réponse peuvent être configurés indépendamment. Dans une forme de réalisation, l'urgence d'un paquet de demande est transférée sur le paquet de réponse afin de créer une priorité de bout en bout. Dans une forme de réalisation, ce transfert de la valeur d'urgence peut être mis en oeuvre dans la NIU de la cible. De manière facultative, le NoC peut être configuré de façon à appliquer la priorité uniquement sur le chemin 2961048 - 16 - de demande, et pas sur le chemin de réponse. Dans encore une autre forme de réalisation, la décision de transférer ou non la valeur d'urgence du paquet de de-mande au paquet de réponse peut être établie en fonction du type de transfert. Par exemple, des demandes "LECTURE" ("READ") et "ECRITURE AVEC CONFIRMATION" ("NON-POSTED WRITE") transfèrent l'urgence de la de-mande sur le paquet de réponse, mais une commande "ECRITURE SANS CONFIRMATION" ("POSTED WRITE") ne le fait pas. Une commande "ECRITURE AVEC CONFIRMATION" nécessite un acquittement de l'achèvement de l'écriture. Une commande "ECRITURE SANS CONFIRMATION" envoyée à travers le NoC ne nécessite pas d'acquittement. Le champ IF_Pression de l'interface de niveau transaction peut être lié au champ Pression Hors-Bande décrit ci-dessus. Il est possible que la logique située dans un coeur IP soit déjà informée de demandes à haute priorité imminente avant que les demandes qui ont été émises ne soient reçues par le NoC. Dans cette forme de réalisation particulière, le champ IF_Pression au ni-veau de l'interface peut être utilisé pour indiquer une telle occurrence et la valeur du champ IF_Pression peut être transférée sur le champ Pression Hors-Bande décrit ci-dessus. De manière similaire au besoin potentiel d'effectuer un nouvel établissement de correspondance entre les valeurs du signal IF_Urgence et le champ Urgence, un nouvel établissement de correspondance entre les va-leurs du champ IF_Pression et la valeur présente sur les fils de pression peut être effectué. Le troisième champ IF Haute Urgence traite les circonstances suivantes. Un coeur IP peut avoir émis un ensemble de requêtes ayant une valeur d'urgence parti-culière et, à un certain moment, le coeur IP peut déci- 2961048 - 17 - der que ces demandes devraient être traitées avec une urgence plus élevée. Par exemple, un coeur IP peut avoir émis un ensemble de demandes "LECTURE", pour lesquelles les données de réponse sont stockées dans un module FIFO local, et le FIFO peut être en danger de soupasse-ment de capacité ; plus précisément, les données de lecture peuvent ne pas être renvoyées suffisamment rapidement. Dans un tel cas, le coeur IP peut alors activer une valeur de plus haute priorité sur le champ IF Haute Urgence. Lors d'un tel événement, la NIU peut envoyer un paquet spécial de demande "Haute Urgence" à toutes les cibles pour lesquelles la NIU a des transactions en attente. Ce paquet peut avoir dans son en-tête une valeur d'urgence définie par la valeur du champ IF Haute Urgence et être acheminé à travers le NoC comme les autres paquets de demande. Un paquet "Urgence" peut "pousser" toutes les transactions se trouvant devant lui sur n'importe quel chemin entre l'initiateur et la cible pour laquelle il y a des demandes en attente. Du fait que la valeur du champ IF _ Haute_ Urgence est codée dans le champ Urgence de l'en-tête, cette forme de réalisation offre des options de configuration similaires au transfert du champ Urgence d'un paquet de demande à un paquet de réponse tel que décrit ci-dessus. La valeur du champ Urgence du paquet "Urgence" peut facultativement être transférée ou non vers le paquet de réponse associé au paquet "Urgence". D'une manière similaire au besoin potentiel d'effectuer un nouvel établissement de correspondance entre les valeurs de IF Urgence et le champ Urgence, le besoin potentiel d'effectuer un nouvel établissement de correspondance entre les valeurs de IF' _ Haute_ Urgence et la valeur du champ Urgence dans l'en-tête du paquet "Urgence" peut exister. - 18 - Génération du paquet Urgence Dans certaines formes de réalisation, une NIU d'initiateur peut contenir une table. La table peut avoir une entrée pour chaque chemin qu'un paquet peut suivre à travers l'interconnexion. Pour chaque chemin représenté dans le tableau, une valeur peut être stockée, représentant le niveau de priorité de la demande de transaction la plus récente précédemment envoyée sur ce chemin. Un compte peut être entretenu pour chaque chemin représenté dans la table. Le compte peut être incrémenté à chaque fois qu'une demande de transaction est envoyée sur ce chemin, et être décrémenté à chaque fois qu'une réponse est reçue pour une transaction envoyée sur ce chemin. Quand un signal IF _ Haute_ Urgence est activé au niveau de l'interface de l'initiateur, un paquet "Urgence" peut être envoyé sur les seuls chemins pour lesquels le niveau de priorité IF _ Haute_ Urgence de la transaction générée est supérieur au niveau de priorité de la transaction la plus récente précédemment envoyée sur le chemin. La table peut ensuite être mise à jour avec le niveau de priorité du paquet Urgence. Si le paquet est bloqué par le contrôle de flux, alors le mécanisme de pression décrit ci-dessus peut être appliqué. Dans certaines formes de réalisation, le niveau de priorité d'une transaction peut être déterminé à l'intérieur du NoC. La détermination du niveau de priorité peut être effectuée par un mécanisme de qualité de service tel qu'un régulateur de bande passante. Dans certaines formes de réalisation, une NIU d'initiateur peut contenir une table. La table peut avoir une entrée pour chaque plage d'adresses à la-quelle une transaction peut être transmise. Pour chaque plage d'adresse de la table, une valeur peut être stocké, qui représente le niveau de priorité de la transac- - 19 - tion la plus récente précédemment envoyée à cette plage. Un compte peut être entretenu pour chaque plage d'adresses représentée dans la table. Le compte peut être incrémenté à chaque fois qu'une demande de transaction est envoyée à cette plage d'adresses, et être décrémenté à chaque fois qu'une réponse est reçue pour une transaction envoyée à cette plage d'adresses. Lors-qu'un signal IF _ Haute_ Urgence est activé au niveau de l'interface de l'initiateur, un paquet "Urgence" peut être envoyé sur le seul chemin correspondant à la plage d'adresses pour laquelle le niveau de priorité IF Haute Urgence de la transaction générée est supérieur au niveau de priorité de la transaction la plus récente précédemment envoyée sur le chemin. Si la transaction est bloquée par le contrôle de flux, alors le mécanisme de pression décrit ci-dessus peut être appliqué. Exemple de routage à l'intérieur de l'interconnexion sur puce La figure 9 illustre un exemple de routage 900 dans une interconnexion sur puce. Deux chemins 901 et 902 sont représentés. Un chemin entre l'interface 911 de l'initiateur et l'interface 912 d'une cible est congestionné au niveau du commutateur 913. Une table 921 stocke une entrée pour chaque chemin qui existe entre l'interface 911 de l'initiateur et des interfaces de cibles dans le système. Les entrées de la table 921 peuvent comprendre la priorité des transactions les plus récemment transmises et le nombre de transactions transmises n'ayant pas reçu de réponse. La priorité de routage pour les transactions initiées peut être déterminée en fonction du signal IF Haute Urgence. Le signal IF Haute Urgence peut être un signal de bande latérale au chemin de demande de transaction. La priorité des paquets Urgence peut être une fonction du signal 2961048 - 20 - IF Haute Urgence et du régulateur de bande passante 931. Lorsqu'une congestion au niveau du commutateur 913 provoque le retardement de réponses à des transactions, entraînant un risque de condition de surpassement ou soupassement dans l'initiateur IP, le commutateur 913 active le signal IF _ Haute_ Urgence. Si la priorité du signal IF _ Haute_ Urgence dépasse la priorité de l'entrée de la table 921 pour le chemin 901, et si le chemin 901 a une ou plusieurs demandes de transitions en cours pour lesquelles aucune réponse n'a été reçue, alors un paquet "Urgence" peut être généré et transmis sur le chemin 901. Si le régulateur de bande passage 931 indique que le chemin 901 nécessite une plus grande bande passante, alors un paquet "Urgence" peut être généré et transmis sur le chemin 901, et la priorité du paquet le plus récemment transmis dans l'entrée de la table 921 correspondant au chemin 901 peut être définie au niveau d'urgence du paquet "Urgence" transmis. Interface de NIU d'une cible Comme on l'a décrit ci-dessus, dans cette forme de réalisation, des mécanismes ont été mis en oeuvre pour le transfert et l'utilisation d'informations de priorité telles que présentées sur un nombre de champs allant jusqu'à trois au niveau de l'interface d'initiateur. Ces informations peuvent être éventuellement présentées à la cible au niveau de l'interface de NIU de la cible. La valeur du champ pression peut définir la valeur du champ IF Pression, la valeur du champ "Urgence Intrabande" dans l'en-tête peut définir la valeur du champ IF Urgence de la transaction, et la valeur du champ IF _ Haute_ Urgence peut être déterminée par la va-leur d'urgence dans le paquet de demande "Haute Urgence". D'une manière similaire au besoin potentiel d'un - 21 - nouvel établissement de correspondance des valeurs des signaux IF_Urgence, IF _ Haute_ Urgence et IF_Pression dans la NIU de l'initiateur entre les valeurs de l'interface "locale" et des valeurs globales, la NIU au sein de la cible peut éventuellement effectuer un nouvel établissement de correspondance entre les valeurs globales de pression et d'urgence et le valeurs requises par le coeur IP cible au niveau de l'interface de NIU de la cible. Du fait qu'une interconnexion sur puce ou un NoC pour un SoC complexe, tel qu'un processeur d'application de téléphonie cellulaire ou une puce de traitement vidéo, peut être assez complexe, de nombreuses décisions de configuration doivent être gérées. Concernant les formes de réalisation actuellement décrites, des exemples des décisions de configuration additionnelles sont les suivantes : la sélection des options de l'interface de niveau transaction, la sélection du codage des informations de priorité, la sélection du nouvel établissement de correspondance concernant les informations de priorité, et la décision de transférer ou non les informations de priorité de la demande sur la réponse. Dans une forme de réalisation, la sélection des paramètres peut être effectuée par l'intermédiaire d'une Interface Graphique Utilisateur (GUI), permettant une configuration rapide et efficace des formats de paquets et des liaisons associées. La figure 8 est un organigramme d'un processus représentatif 800 pour la mise en oeuvre de fonctionna-lités de QoS dans une structure d'arbitrage à plusieurs niveaux dans une interconnexion sur puce. Dans certaines formes de réalisation, le processus 800 peut commencer par la réception d'informations de priorité intrabande (802) et la réception d'information de priori-té hors-bande (804) au niveau d'une interface de niveau transaction d'une interconnexion sur puce. Le processus 2961048 - 22 - 800 traite les demandes de transactions soumises à une contre-pression, le traitement étant effectué avec une priorité basée sur la valeur du signal intrabande et la valeur du signal hors-bande, laquelle priorité n'étant pas inférieure à celle qui est indiquée par la valeur du signal hors-bande (806). Bien que la présente description présente de nombreux détails, ceux-ci ne doivent pas être considérés comme limitant le cadre de l'invention telle que revendiquée ou susceptible d'être revendiquée, mais plutôt comme décrivant des éléments caractéristiques spécifiques de formes de réalisation particulières. Certains éléments caractéristiques décrits dans la présente description dans le contexte de formes de réalisation distinctes peuvent également être mis en oeuvre en combi- naison dans une seule forme de réalisation. Inversement, différents éléments caractéristiques décrits dans le contexte d'une seule forme de réalisation peuvent également être mis en oeuvre dans plusieurs formes de réalisation, séparément ou selon toute combinaison appropriée. De plus, bien que des éléments caractéristiques puissent être décrits ci-dessus comme agissant selon certaines combinaisons et même être initialement revendiquées en tant que tels, un ou plu-sieurs éléments caractéristiques d'une combinaison revendiquée peuvent, dans certains cas, être extraits de la combinaison, et la combinaison revendiquée peut concerner une sous-combinaison ou une variante d'une sous-combinaison. De manière similaire, bien que les opérations mi- ses en oeuvre soient décrites dans un ordre particulier sur les dessins, il ne faut pas en conclure que, pour l'obtention des résultats souhaités, ces opérations doivent être effectuées dans cet ordre particulier ou de façon séquentielle, ni que toutes les opérations il- - 23 - lustrées doivent être exécutées. Dans certaines circonstances, un traitement multitâche ou parallèle peut être avantageux. De plus, le fait que divers composants du système soient séparés dans les formes de réalisa- tion décrites ci-dessus ne doit pas être considéré comme une obligation d'une telle séparation dans toutes les formes de réalisation, et il convient d'observer que les composants logiciels et les systèmes décrits peuvent être généralement intégrés dans un seul produit ou conditionnés sous la forme de plusieurs produits. On comprendra donc que le présent document décrit certaines formes de réalisation particulières et que d'autres formes de réalisation entrent dans le cadre de l'invention tel que défini par les revendications jointes.