FR 2951342 A1 20110415 FR 0957137 A 20091013 - 1 - 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ériques (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 réalise les communications au niveau système de la topologie particulière. Les cœurs IP sont typi- quement 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 transaction". A titre d'exemple de protocole de transaction, 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 topographies complexes et de grandes tailles pouvant contenir des centaines de cœurs IP. La première génération de technologie d'interconnexion de coeurs IP consistait en un ensemble hiérarchique de bus et de 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 système de communication. Une approche hiérarchique est utilisée pour séparer les - 2 - 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 commune 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 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 réside dans le fait que la réutilisation des coeurs IP est li- mitée. Les interfaces de tous les coeurs IP se connectant à la même interconnexion doivent identiques. Il peut en résulter une nécessité de reconcevoir l'inter-face d'un coeur IP ou de concevoir une logique 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. Cette première génération de technologie d'interconnexion de coeurs IP peut être décrite sous la forme d'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 modification de toutes les interfaces. La deuxième génération d'interconnexion IP est une mise en oeuvre partiellement découplée des topologies de bus et de crossbar décrites ci-dessus. Dans ces solutions, le protocole de communication interne du système de communication, ou protocole de transport, est découplé du protocole d'interface IP, ou protocole de transac- tion. Ces solutions sont plus flexibles du point de vue de la réutilisation des coeurs IP du fait que, dans ces solutions, l'intégrateur de systèmes à 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'interconnexion 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 couche de transport et couche physique. L'innovation clé permettant cette solution est le conditionnement des informations de la couche de transaction sous la forme de paquets. Les informations de commande 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épendant de la couche physique. Dans les solutions de type NoC existantes, des salves d'informations au niveau de la couche de transaction sont converties en paquets, qui sont transportés sur les liaisons physiques. Un paquet NoC est constitué de deux parties un en-tête et une charge utile. La charge utile comprend habituellement, mais sans y être limitée, des données, avec éventuellement d'autres in-formations associées aux données, telles que des infor- mations d'activation d'octets ("byte-enable") et/ou de protection ou de sécurité. L'en-tête contient deux types d'informations : premièrement, des informations de niveau protocole de transaction qui sont transférées de bout en bout sans être modifiées par l'interconnexion, et deuxièmement, des informations de niveau protocole de transport nécessaires à l'interconnexion et utilisées par cette dernière pour le transport correct de la charge utile d'un coeur IP à un autre via l'intercon- - 4 - nexion. Le terme "correct" ne s'applique pas uniquement à l'acheminement, mais implique également la satisfaction d'autres spécifications au niveau système, telles que les spécifications de latence, de qualité de ser- vice, de bande passante, etc. Dans de nombreux protocoles de couche de transaction, les informations de commande et les données de la transaction contenues dans une salve sont présentées dans le même cycle d'horloge. Dans le processus de conver- Sion de la couche de transaction à la couche de transport, l'en-tête est créé et utilisé en tant que premier des différents mots du paquet. Cette mise sous forme de paquets peut insérer une latence d'un ou plusieurs cycles du fait que l'en-tête est transporté sur les liai- sons physiques pendant un ou plusieurs cycles d'horloge avant que les données soient transportées. Bien qu'un cœur IP puisse être réutilisé d'une topographie à une autre, la réalisation d'un NoC est quant à elle susceptible de changer car le NoC met en œuvre les communications au niveau système, qui sont spécifiques de la topographie. Le nombre de cœurs IP, la latence, la bande passante, la puissance et la cadence d'horloge sont quelques-unes des variables qui influent sur les spécifications du NoC. Des mécanismes ont donc été dé- veloppés pour automatiser la conception d'un NoC particulier afin de construire rapidement une instance de NoC. Pendant l'instanciation d'un NoC, l'utilisateur a la capacité de configurer la largeur de la liaison, et donc la largeur du paquet, et cette capacité de confi- guration permet à l'utilisateur de réaliser un compromis optimal entre le nombre de fils du système d'inter-connexion, la latence et la bande passante. Dans les solutions de type NoC existantes, les possibi- lités de configuration offertes lors de la construction d'un paquet sont limitées à la sélection d'une valeur d'un seul paramètre. Cet unique paramètre permet de sélectionner une largeur pour le paquet. Les valeurs de largeur du paquet et de pénalité de latence due à l'en-tête du paquet sont intrinsèquement liées. Par consé- quent, une modification de la valeur du paramètre largeur du paquet peut conduire à l'insertion d'une latence supplémentaire. Les formes de réalisation décrites comprennent des for-mats de paquets à utiliser dans des solutions d'inter- connexion de type NoC. Dans certaines formes de réalisation, la capacité de configurer le format de paquets transportés sur les liaisons physiques d'une interconnexion de cœurs IP est étendue par l'utilisation d'au moins deux paramètres indépendants : un paramètre gou- vernant la largeur des données et un paramètre gouvernant la pénalité de latence ; ces au moins deux paramètres indépendants permettant la création de paquets de protocole de transport sans insertion de latence supplémentaire, ce qui est utile pour les applications à faible latence, et permettant également la création de paquets étroits ayant une latence additionnelle de plu-sieurs cycles, ce qui est utile pour les applications sensibles à l'espace occupé, qui tolèrent une latence. 0 Plus précisément, l'invention vise un procédé de trans- mission d'un paquet d'informations sur une liaison phy- sique dans un réseau d'interconnexion de cœurs de Pro- priété Intellectuelle, le paquet comprenant un en-tête et une séquence d'un ou plusieurs mots de charge utile. Le procédé comprend : la transmission de l'en-tête et d'un premier mot de charge utile sur la liaison physi- que dans un premier cycle d'horloge ; et, si la charge utile comprend un deuxième mot de charge utile, la transmission du deuxième mot de charge utile sur la liaison physique dans un deuxième cycle d'horloge, la liaison physique comprenant plusieurs fils de transmission de données physiques, le nombre de fils de trans- mission de données physiques étant égal à au moins une somme de la largeur d'un en-tête et de la largeur d'un mot de charge utile. Selon un autre aspect, l'invention vise un procédé de définition d'un format de paquet pour la transmission sur une liaison physique d'un réseau d'interconnexion de coeurs de Propriété Intellectuelle, le procédé comprenant : la définition d'un paquet comprenant un en-tête et une charge utile ayant un ou plusieurs mots de charge utile ; et la définition d'au moins deux paramè- tres indépendants, où la combinaison des paramètres in-dépendants commande la largeur de la liaison physique et la latence pour le transport de l'en-tête sur la liaison physique, la latence de l'en-tête venant s'ajouter à une latence minimale pour le transport de la charge utile sur la liaison physique. Selon diverses caractéristiques subsidiaires - l'un des au moins deux paramètres indépendants est la largeur de la charge utile et l'autre des au moins deux paramètres indépendants est la latence de l'en- tête ; le paramètre indépendant déterminant la latence de l'en-tête peut recevoir une valeur qui spécifie la largeur du paquet de façon qu'elle soit identique à la largeur de la charge utile ; - le format de paquet est tel que la latence de l'en-tête est égale à zéro ou à plus de zéro cycles d'horloge ; - le réseau d'interconnexion de coeurs IP contient une ou plusieurs liaisons physiques connectant les élé-35 ments IP du réseau, et dans lequel le format de pa- quet est défini pour chaque liaison physique indépendamment de la définition du format de paquet pour les autres liaisons, le format de paquet étant défini pour chaque liaison par une sélection indépendante des deux paramètres indépendants pour chaque liai-son ; - la sélection des valeurs des deux paramètres indépendants est effectuée par l'intermédiaire d'une Inter-face Graphique Utilisateur. Selon un autre aspect, l'invention vise un procédé de définition d'un format de paquet pour la transmission sur une liaison physique d'un réseau d'interconnexion de coeurs de Propriété Intellectuelle, le procédé comprenant : la définition d'un paquet comprenant un en- tête et une charge utile ayant un ou plusieurs mots de charge utile ; et la définition d'au moins deux paramètres indépendants, où la combinaison des paramètres in-dépendants commande la largeur de la liaison physique et la latence pour le transport de l'en-tête sur la liaison physique, la latence de l'en-tête venant s'ajouter à une latence minimale pour le transport de la charge utile sur la liaison physique. Selon diverses caractéristiques subsidiaires : - l'un des au moins deux paramètres indépendants spéci-25 fie la largeur de la charge utile et l'autre des au moins deux paramètres indépendants spécifie la la- tence de l'en-tête ; - l'un des au moins deux paramètres indépendants com- prend une valeur servant à spécifier la latence de 30 l'en-tête qui peut être définie de façon à être égale à zéro ou plus de zéro cycles d'horloge ; - le réseau d'interconnexion de coeurs IP contient une ou plusieurs liaisons physiques connectant les élé- ments IP du réseau, et dans lequel le format de pa-35 quet est défini pour chaque liaison physique indépen- damment de la définition du format de paquet pour les autres liaisons, le format de paquet étant défini pour chaque liaison par une sélection indépendante des deux paramètres indépendants pour chaque liai- son ; Selon un autre aspect, l'invention vise un réseau d'interconnexion de cœurs de Propriété Intellectuelle exploitable pour la transmission d'un paquet comprenant un en-tête et une charge utile ayant un ou plusieurs mots de charge utile, le réseau comprenant : une liai-son physique comprenant plusieurs fils de transmission de données physiques, le nombre de fils de transmission de données physiques étant égal à au moins une somme de la largeur d'un en-tête et de la largeur d'un mot de charge utile ; un émetteur couplé à la liaison physique, l'émetteur étant configuré pour transmettre l'en-tête et un premier mot de charge utile sur la liaison physique pendant un premier cycle d'horloge, et, si la charge utile comprend un deuxième mot de charge utile, transmettre le deuxième mot de charge utile sur la liaison physique dans un deuxième cycle d'horloge ; et un récepteur couplé à la liaison physique, le récepteur étant configuré pour recevoir l'en-tête et la charge utile Selon diverses caractéristiques subsidiaires la liaison physique supporte une interface de connexion de protocole de transport qui comprend des signaux de contrôle de flux, des signaux de tramage et des signaux d'informations ; l'interface de connexion offre une interface synchrone travaillant sur les fronts montants ou sur les fronts descendants d'un signal d'horloge ; - le réseau supporte des paquets sans charge utile ; - l'un des deux paramètres indépendants peut spécifier 35 que l'en-tête est automatiquement divisé pour être transmis sur la liaison physique en plus d'un cycle d'horloge ; - la charge utile ou l'en-tête est soumis à un bourrage de zéros. Selon un autre aspect, l'invention vise un réseau d'interconnexion de cœurs de Propriété Intellectuelle exploitable pour la transmission d'un format de paquet comprenant un en-tête et une charge utile ayant un ou plusieurs mots de charge utile, le réseau comprenant : une liaison physique comprenant plusieurs fils de transmission de données physiques ; un émetteur couplé à la liaison physique, l'émetteur étant configuré pour transmettre un paquet ayant le format de paquet ; et un récepteur couplé à la liaison physique et configuré pour recevoir le paquet transmis, le paquet étant transmis en fonction d'une combinaison de paramètres indépendants disponibles pour le réseau pour commander la largeur de la liaison physique et la latence pour le transport de l'en-tête sur la liaison physique, la la- tence de l'en-tête venant s'ajouter à une latence minimale pour le transport de la charge utile sur la liai-son physique. Selon diverses caractéristiques subsidiaires : - l'un des au moins deux paramètres indépendants est la largeur de la charge utile et l'autre des au moins deux paramètres indépendants est la latence de l'en-tête ; - l'un des paramètres indépendants détermine la latence de l'en-tête et spécifie la largeur du paquet de fa-30 çon qu'elle soit identique à la largeur de la charge utile ; - le réseau d'interconnexion de cœurs IP contient une ou plusieurs liaisons physiques connectant les élé- ments IP du réseau, et dans lequel le format de pa-35 quet est défini pour chaque liaison physique indépen- - 10 - damment de la définition du format de paquet pour les autres liaisons, le format de paquet étant défini pour chaque liaison par une sélection indépendante des deux paramètres indépendants pour chaque liai- son ; - la sélection des valeurs des deux paramètres indépendants est effectuée par l'intermédiaire d'une Inter-face Graphique Utilisateur ; - le réseau supporte des paquets sans charge utile ; 10 - l'un des deux paramètres indépendants spécifie que l'en-tête est automatiquement divisé pour être trans- mis sur la liaison physique en plus d'un cycle d'hor- loge ; - la charge utile ou l'en-tête est soumis à un bourrage 15 de zéros. Selon un autre aspect, l'invention vise un réseau d'interconnexion de coeurs de Propriété Intellectuelle exploitable pour la transmission d'un paquet ayant un format de paquet comprenant un en-tête et une séquence 20 d'un ou plusieurs mots de charge utile, le réseau comprenant une liaison physique comprenant plusieurs fils de transmission de données physiques ; un émetteur couplé à la liaison physique, l'émetteur étant configuré pour transmettre un paquet ayant le format de pa- 25 quet ; et un récepteur couplé à la liaison physique et configuré pour recevoir le paquet, le paquet étant transmis en fonction d'une combinaison de paramètres indépendants disponibles pour le réseau pour commander la largeur de la charge utile et la latence pour le 30 transport de l'en-tête sur la liaison physique, la latence de l'en-tête venant s'ajouter à une latence minimale pour le transport de la charge utile sur la liai-son physique. - 11 - Selon diverses caractéristiques subsidiaires : - l'un des au moins deux paramètres indépendants spéci- fie la largeur de la charge utile et l'autre des au moins deux paramètres indépendants spécifie la la-5 tence de l'en-tête ; - le format du paquet comprend une valeur servant à spécifier la latence de l'en-tête qui peut être défi-nie de façon à être égale à zéro ou plus de zéro cycles d'horloge ; 10 - le réseau supporte des paquets sans charge utile ; - l'un des deux paramètres indépendants peut recevoir une valeur spécifiant que l'en-tête est automatique-ment divisé pour être transmis sur la liaison physique en plus d'un cycle d'horloge ; 15 - la charge utile ou l'en-tête est soumis à un bourrage de zéros ; Selon un autre aspect, l'invention vise un système pour la définition d'un format de paquet pour un réseau d'interconnexion de coeurs de Propriété Intellectuelle, 20 le système comprenant : une interface ; et un processeur couplé à l'interface, le processeur pouvant être exploité pour la définition d'un paquet comprenant un en-tête et une charge utile ayant un ou plusieurs mots de charge utile, et pour la réception, via l'interface, 25 de valeurs pour au moins deux paramètres indépendants destinés à commander la largeur d'une liaison physique du réseau et la latence pour le transport de l'en-tête sur la liaison physique, la latence de l'en-tête venant s'ajouter à une latence minimale pour le transport de 30 la charge utile sur la liaison physique. L'interface peut notamment être une Interface Graphique Utilisateur. Selon un autre aspect, l'invention vise un système pour la définition d'un format de paquet pour un réseau 35 d'interconnexion de coeurs de Propriété Intellectuelle, - 12 - le système comprenant : une interface ; et un processeur couplé à l'interface, le processeur pouvant être exploité pour la définition d'un paquet comprenant un en-tête et une charge utile ayant un ou plusieurs mots de charge utile, et pour la réception, via l'interface, de valeurs pour au moins deux paramètres indépendants destinés à commander la largeur de la charge utile et la latence pour le transport de l'en-tête sur la liai-son physique, la latence de l'en-tête venant s'ajouter à une latence minimale pour le transport de la charge utile sur la liaison physique. L'interface peut notamment être une Interface Graphique Utilisateur. 0 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, sur lesquels : - la figure 1 présente un schéma fonctionnel d'un exemple de NoC ; - la Figure 2 présente un schéma fonctionnel d'un exemple de liaison physique connectant un émetteur et un récepteur du NoC de la Figure 1 ; - la Figure 3 présente est un exemple de séquence de transport d'un paquet sur la liaison exemple représentée sur la figure 2 ; - la Figure 4 présente un exemple de paquet à utiliser avec le NoC de la Figure 1 ; - la Figure 5 présente des exemples de formats de paquets à utiliser avec le NoC de la Figure 1 ; - la Figure 6 présente un exemple de mécanisme de bourrage des bits non utilisés dans les formats de paquets de la Figure 5 ; et - 13 - - la Figure 7 présente un exemple de procédé pour la transmission d'informations sur la liaison de la Figure 2 à l'aide des formats de paquets représentés sur la Figure 5. 0 Exemple de NoC La Figure 1 présente un schéma fonctionnel d'un exemple de NoC 100. 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. Des exemples d'éléments IP 102 comprennent, mais sans y être limités : les commutateurs 102a, les convertisseurs d'horloge 102b, les régulateurs de bande passante 102c, les FIFO (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. Dans certaines formes de réalisation, au niveau des bords du NoC 100, des Unités d'Interface de Réseau (NIU) 104 réalisent une conversion entre le protocole de transaction et le protocole de transport (entrée) et vice versa (sortie). Certains exemples de NIU pour les protocoles de transaction comprennent, mais sans y être limités : le NIU OCP 104a, le NIU AXI° 104b, le NIU AHB® 104c, l'ordonnanceur de mémoire 104d et un NIU propriétaire 104e. Les NIU 104 sont couplés à différents coeurs IP 110. Certains exemples de cœurs IP sont le DSP 110a, la CPU 110b, le module DMA (Accès Direct à la Mémoire) 110c, le sous-système OCP 110d, le contrôleur de DRAM 110e, les SRAM 110f et d'autres types de cœurs 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 - 14 - stockage d'un ou plusieurs mots de données qui sont convertis en paquets pour la transmission sur les liai-sons 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 port de transport utilisé par le NoC 100 en nous référant à 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 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), des signaux de tramage (Head, Tait) 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 ni-veau 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, rail 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, Tait, 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 - 15 - peut être de 1, mais d'autres largeurs peuvent égale-ment ê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, Tail 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 égale-ment ê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. - Tait . 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 de 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 se produire lorsque les signaux Vld et Rdy sont tous les deux à l'état "vrai". La largeur du signal Data peut être configurable. Exemple de séquence de transport de paquet La Figure 3 est 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 sont actifs et se termine lorsque les signaux Vld et Tail sont actifs. Dans un paquet d'un seul cycle, les deux signaux Head et Tail 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 - 16 - 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 for-mats 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). Exemple de paquet La Figure 4 est un exemple de paquet à utiliser avec le NoC 100 de la Figure 1. Plus particulièrement, la Figure 4 illustre un exemple de format de paquet 400 comprenant un en-tête 402 et une charge utile 404. L'exemple de format de paquet 400 peut être défini par une largeur de charge utile de quatre octets (ayant des fonctionnalités "byte-enables" ("activation d'octets")) et une pénalité d'en-tête d'un seul cycle. Dans certaines formes de réalisation du format de paquet 400, certains champs peuvent être facultatifs. La largeur totale de l'en-tête 402 peut être désignée "wHeader". Dans certaines formes de réalisation, l'en-tête 402 comprend un champ d'en-tête contenant un champ RoutelD, un champ Adresse (Addr) et plusieurs champs de Contrôle. Les champs de Contrôle de l'en-tête 402 peuvent transporter des informations additionnelles de bout en bout ou de protocole de transport. L'utilisation et la signification particulières des champs de Contrôle de l'en-tête 402 ne sont pas pertinentes pour la discussion des formes de réalisation décrites ici. Les significations des autres champs de l'en-tête 402 sont les suivantes . - Addr : 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. - 17 - - 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 "Byte-Enable" (BE) 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é. La largeur du champ Byte est définie par wByte. La manière dont les paquets sont transmis sur les signaux Data peut être définie par les deux paramètres indépendants suivants : - nBytePerWord ("n octets par mot") . ce paramètre indique un nombre d'octets de charge utile transféré par cycle d'horloge. Des valeurs admissibles sont, par exemple, 0, 1, 2, 4, 8, 16, 32, 64 et 128 octets. - hdrPenalty ("Pénalité de l'en-tête") : ce paramètre indique comment un en-tête est transmis sur les signaux Data. Dans certaines formes de réalisation, le paramètre hdrPenalty peut avoir les valeurs suivantes : 1. NONE (Aucun) : un en-tête est envoyé simultanément à une première charge utile, le cas échéant. La lar-5 Beur effective des signaux Data (wData) est égale à (wByte+1)*nBytePerWord + wHeader. - 18 - 2. ONE (UN) un en-tête occupe exactement un cycle d'horloge. La largeur effective des signaux Data est égale à max((wByte+l)*nBytePerWord, wHeader). 3. TWO (DEUX) : un en-tête occupe exactement deux cy- oies d'horloge, même lorsque l'en-tête est plus pe- tit que (wByte+1)*nBytePerWord. La largeur effective des signaux Data est égale à max((wByte+l)*nBytePerWord, ceil(wHeader/2)). 4. AUTO : un en-tête est automatiquement divisé de fa- gon à être transmis sur les (wByte+l)*nBytePerWord bits des signaux Data. Le nombre de cycles pour l'en-tête est égal à ceil(wHeader/((wByte+1)*nBytePerWord)). Exemples de formats de paquets La Figure 5 illustre des exemples de formats de paquets à utiliser avec le NoC 100 de la Figure 1. Plus particulièrement, la Figure 5 présente des exemples de différentes combinaisons de formats de paquets en fonction des valeurs des paramètres indépendants hdrPenalty et nBytePerWord. Dans certaines formes de réalisation, un en-tête peut être divisé à chaque fois que wHeader est supérieure à wData. Les bits les plus significatifs peuvent être envoyés en premier ("big-endian") et les bits les moins significatifs d'un dernier mot de don-nées peuvent être soumis à un bourrage de zéros lorsque nécessaire. Une charge utile peut être soumise à un bourrage de zéros lorsque (wByte+l)*nBytePerWord + wC Exemple de mécanisme de bourrage La Figure 6 illustre un exemple de mécanisme de bourrage des bits non utilisés. Les abréviations "wH" et - 19 - "wP" y sont respectivement utilisées pour représenter wHeader et (wByte+1)*nBytePerWord. La flexibilité des formats de paquets de la Figure 5 offre des avantages considérables pour la réalisation d'un NoC ou d'une structure d'interconnexion de coeurs IP. La flexibilité supplémentaire offerte aux concepteurs de NoC leur permet de réaliser une solution simple tout en satisfaisant aux spécifications de latence et de bande passante de l'interconnexion. Les économies d'espace occupé qui en résultent peuvent se traduire directement par une réduction de coût d'un circuit intégré ou d'un FPGA. L'option hdrPenalty = NONE peut être utilisée quand une faible latence et/ou une bande passante élevée sont souhaitées. Cette solution peut être onéreuse en termes d'utilisation de fils, mais dans une topographie moderne du type Système sur Puce (SoC), le nombre de liaisons nécessitant ces spécifications strictes est limité. L'option hdrPenalty = ONE est une option qui peut être utilisée par une interconnexion principale dans un SoC. Cette solution peut être économe en fils tout en offrant encore une bande passante élevée et une latence acceptable. L'option hdrPenalty = TWO est une option qui peut être utilisée par des structures d'interconnexion de commandes et de périphériques. Cette solution peut offrir une grande économie en fils, combinée à des performances légèrement réduites. L'option hdrPenalty = AUTO est une option qui peut être utilisée par des structures d'interconnexion de servi-ces dans lesquelles l'économie en fils est un paramètre de conception important. Dans une forme de réalisation, la sélection d'un format de paquet peut être effectuée individuellement pour chaque liaison. Par exemple, les valeurs choisies pour - 20 - les deux paramètres indépendants (hdrPenalty et nByte-PerWord) définissant le format de paquet peuvent être différentes pour chaque liaison, ce qui permet une meilleure optimisation du NoC 100. Du fait que les liaisons physiques d'un NoC peuvent avoir des spécifications de performances différentes, un format de paquet peut être choisi de façon optimale pour chaque liaison afin de réduire l'espace occupé et la consommation d'énergie. Du fait qu'un NoC pour un SoC complexe, tel qu'un pro- cesseur pour application de téléphonie cellulaire ou une puce de traitement vidéo, peut contenir un grand nombre de liaisons, de nombreuses décisions de configu- ration doivent être prises. Dans une forme de réalisa- tion, la sélection des paramètres peut être effectuée par l'intermédiaire d'une Interface Graphique Utilisa- teur (GUI), qui permet une configuration rapide et effi- cace des formats des paquets et des liaisons associées. Exemple de procédé pour la transmission d'informations sur la liaison La figure 7 est un exemple de procédé 700 pour la transmission d'informations sur la liaison physique de la Figure 2 à l'aide du format de paquet représenté sur la Figure 5. Dans certaines implémentations, le procédé 700 comprend les étapes de configuration d'un paquet pour le transport sur une liaison physique, la configu- ration comprenant la spécification de valeurs pour au moins deux paramètres indépendants (702), et de trans- mission d'au moins une partie de l'en-tête et de la charge utile sur la liaison physique pendant un ou plu- sieurs cycles d'horloge en fonction des valeurs des pa- ramètres (702). Dans certaines formes de réalisation, un premier paramètre indique une largeur de la liaison physique ou une largeur de la charge utile, et un - 21 - deuxième paramètre spécifie une latence minimale pour le transport de l'en-tête sur la liaison physique, qui vient s'ajouter à une latence minimale pour le transport de la charge utile sur la liaison physique. 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 combinaison 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 manière similaire, bien que les opérations mises en œuvre 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 illustré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éalisation décrites ci-dessus ne doit pas être considéré comme une obliga- tion 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. Revendications1. Procédé de transmission d'un paquet d'informations (400) sur une liaison physique (200) dans un réseau (100) d'interconnexion de coeurs de Propriété Intellectuelle (IP), le paquet comprenant un en-tête (402) et une séquence d'un ou plusieurs mots de charge utile (404), le procédé comprenant : la transmission de l'en-tête et d'un premier mot de 10 charge utile sur la liaison physique dans un premier cycle d'horloge ; et si la charge utile comprend un deuxième mot de charge utile, la transmission du deuxième mot de charge utile sur la liaison physique dans un deuxième cycle d'hor- 15 loge, la liaison physique comprenant plusieurs fils de transmission de données physiques, le nombre de fils de transmission de données physiques étant égal à au moins une somme de la largeur d'un en-tête et de la largeur 20 d'un mot de charge utile. 2. Réseau (100) d'interconnexion de coeurs de Propriété Intellectuelle (IP) exploitable pour la transmission d'un paquet (400) comprenant un en-tête (402) et une 25 charge utile (404) ayant un ou plusieurs mots de charge utile, le réseau comprenant : une liaison physique (200) comprenant plusieurs fils de transmission de données physiques, le nombre de fils de transmission de données physiques étant égal à au moins 30 une somme de la largeur d'un en-tête et de la largeur d'un mot de charge utile ; un émetteur (202) couplé à la liaison physique, l'émet- teur étant configuré pour transmettre l'en-tête et un premier mot de charge utile sur la liaison physique 35 pendant un premier cycle d'horloge, et, si la charge- 23 - utile comprend un deuxième mot de charge utile, transmettre le deuxième mot de charge utile sur la liaison physique dans un deuxième cycle d'horloge ; et un récepteur (204) couplé à la liaison physique, le ré-5 cepteur étant configuré pour recevoir l'en-tête et la charge utile. 3. Réseau selon la revendication 2, dans lequel la liaison physique supporte une interface de connexion de 10 protocole de transport qui comprend des signaux de contrôle de flux, des signaux de tramage et des signaux d'informations. 4. Réseau selon la revendication 3, dans lequel l'interface de connexion offre une interface synchrone travaillant sur les fronts montants ou sur les fronts descendants d'un signal d'horloge. 5. Réseau selon la revendication 2, dans lequel le ré-20 seau supporte des paquets sans charge utile. 6. Réseau selon la revendication 2, dans lequel l'un des deux paramètres indépendants peut spécifier que l'en-tête est automatiquement divisé pour être transmis 25 sur la liaison physique en plus d'un cycle d'horloge. 7. Réseau selon la revendication 2, dans lequel la charge utile ou l'en-tête est soumis à un bourrage de zéros. :30 8. Réseau (100) d'interconnexion de cœurs de Propriété Intellectuelle (IP) exploitable pour la transmission d'un paquet (400) ayant un format de paquet comprenant un en-tête (402) et une séquence d'un ou plusieurs mots 35 de charge utile (404), le réseau comprenant- 24 - une liaison physique (200) comprenant plusieurs fils de transmission de données physiques ; un émetteur (202) couplé à la liaison physique, l'émetteur étant configuré pour transmettre un paquet ayant_ 5 le format de paquet ; et un récepteur (204) couplé à la liaison physique et configuré pour recevoir le paquet, le paquet étant transmis en fonction d'une combinaison de paramètres indépendants disponibles pour le réseau 10 pour commander la largeur de la charge utile ou la largeur de la liaison physique, et la latence, pour le transport de l'en-tête sur la liaison physique, la latence de l'en-tête venant s'ajouter à une latence minimale pour le transport de la charge utile sur la liai- 15 son physique. 9. Réseau selon la revendication 8, dans lequel l'un des au moins deux paramètres indépendants spécifie la largeur de la charge utile et l'autre des au moins deux 20 paramètres indépendants spécifie la latence de l'en-tête. 10. Réseau selon la revendication 8, dans lequel le format du paquet comprend une valeur servant à spéci- 25 fier la latence de l'en-tête qui peut être définie de facon à être égale à zéro ou plus de zéro cycles d'horloge. 11. Réseau selon la revendication 8, dans lequel le ré-30 seau supporte des paquets sans charge utile. 12. Réseau selon la revendication 8, dans lequel l'un des deux paramètres indépendants peut recevoir une va-leur spécifiant que l'en-tête est automatiquement divi-- 25 - sé pour être transmis sur la liaison physique en plus d'un cycle d'horloge. 13. Réseau selon la revendication 8, dans lequel la 5 charge utile ou l'en-tête est soumis à un bourrage de zéros. 14. Système pour la définition d'un format de paquet (400) pour un réseau (100) d'interconnexion de cœurs de ï0 Propriété Intellectuelle (IP), le système comprenant : une interface ; et un processeur couplé à l'interface, le processeur pouvant être exploité pour la définition d'un paquet (400) comprenant un en-tête (402) et une charge utile (404) 15 ayant un ou plusieurs mots de charge utile, et pour la réception, via l'interface, de valeurs pour au moins deux paramètres indépendants destinés à commander la largeur d'une liaison physique (200) du réseau ou la largeur de la charge utile (404), et la latence, pour 20 le transport de l'en-tête (402) sur la liaison physique, la latence de l'en-tête venant s'ajouter à une latence minimale pour le transport de la charge utile sur la liaison physique. 25 15. Système selon la revendication 14, dans lequel l'interface est une Interface Graphique Utilisateur (GUI). 16. Procédé selon la revendication 14, dans lequel l'un 30 des au moins deux paramètres indépendants spécifie la largeur de la charge utile et l'autre des au moins deux paramètres indépendants spécifie la latence de l'en-tête.- 26 - 17. Procédé selon la revendication 14, dans lequel l'un des au moins deux paramètres indépendants comprend une valeur servant à spécifier la latence de l'enùtête qui peut être définie de façon à être égale à zéro ou plus de zéro cycles d'horloge. 18. Procédé selon la revendication 14, dans lequel le réseau d'interconnexion de coeurs IP contient une ou plusieurs liaisons physiques connectant les éléments IP du réseau, et dans lequel le format de paquet est défi-ni pour chaque liaison physique indépendamment de la définition du format de paquet pour les autres liai-sons, le format de paquet étant défini pour chaque liaison par une sélection indépendante des deux paramè- tres indépendants pour chaque liaison.