FR 2842922 A1 20040130 FR 0209419 A 20020725 DISPOSITIF DE BUS MATRICIEL MULTI-MAITRES, MULTI-ESCLAVES, ET PROCEDE MIS EN OEUVRE DANS UN TEL DISPOSITIF." La présente invention se rapporte à un dispositif de bus matriciel entre une pluralité de modules maîtres et une pluralité de modules esclaves, ces modules maîtres et esclaves étant également dénommés "IP" ("Intellectual Property" en langue anglaise). Elle concerne également un procédé mis en oeuvre dans un tel dispositif. L'invention s'applique en particulier, mais non exclusivement, au domaine des circuits intégrés, et peut être comparée à un bus Soc ("System on Chip") programmable. Les bus SoC (en anglais System on Chip) doivent supporter une organisation à maîtres et esclaves multiples compte tenu de la diversité des périphériques mis en òuvre dans les SoC. Les protocoles définis pour ces bus sont proches de ceux des processeurs pour en faciliter l'interfaçage. Ils sont généralement constitués d'un bus de données, d'un bus d'adresses et de signaux de contrôles. Les solutions techniques conventionnelles font appel à une architecture de bus partagé conformément à la figure 6. La bande passante du bus est donc partagée temporellement entre les périphériques. Un problème majeur de cette architecture est qu'à chaque instant, il ne peut y avoir qu'un seul échange sur le bus. Cette approche n'est donc optimale que lorsqu'un seul maître est présent sur le bus. C'est la solution retenue par exemple pour les bus AMBA ou CORE CONNECT. Cependant, lorsque plusieurs périphériques sont maîtres du bus simultanément, cela provoque un étranglement des échanges de données. Un autre problème associé à un tel système SoC est que l'arbitrage et le contrôle du bus sont centralisés. Ils sont donc définis pour un nombre prédéterminé de périphériques. L'ajout de périphériques implique donc la modification d'une fonction commune à l'ensemble des périphériques. Une limitation est que sur un tel bus SoC, les échanges entre un maître et un esclave sont basés sur une procédure dite d'acquittement (ou "handshake"): l'échange est établi exclusivement entre les deux coupleurs. Les mêmes données ne -2 peuvent donc pas être transmises simultanément à d'autres esclaves. Par acquittement, on entend un signal dédié transmis, au cours d'un cycle de communication, d'un module esclave vers un module maître. Il y a acquittement lorsque le module maître réagit au signal transmis. Tant que cet acquittement n'est pas effectif il y a communication entre les deux modules. Dans une approche différente du bus partagé, il existe des bus constitués d'une matrice d'interconnexion (Crossbar Switch Matrix), tels que les bus utilisés dans des microcalculateurs (exemple: BUS RACEway, SKY Channel ou Myrinet). Cette solution permet des échanges en parallèle. Il est en effet possible d'avoir un cycle entre un maître A et un esclave B simultanément à des transferts entre un maître B et un esclave A, voir figure 7. On connaît le document US6138185 dans lequel est décrit un bus matriciel permettant d'interconnecter tout élément relié à ce bus. Les fonctions d'arbitrage sont centralisées au sein d'un élément de gestion. On connaît également le document US4754451 décrivant un bus matriciel pour la transmission de données par paquets. Un module de contrôle, comprenant des zones tampons "buffer", est disposé pour chaque port de sortie. La transmission est unidirectionnelle et les fonctions d'arbitrage sont gérées par des modules de contrôle externe à la matrice. Ce mécanisme permet donc à plusieurs maîtres et plusieurs esclaves de communiquer simultanément entre eux. Plusieurs connexions peuvent se faire en parallèle. Cela offre l'avantage d'augmenter la vitesse de communication, en effet, par exemple, si deux échanges à 100Moctet/s sont en cours nous avons une bande passante potentielle de 200Moctet/s. Un problème majeur de cette architecture de bus est que le volume de portes nécessaire pour un nombre de périphériques donné est bien plus important que dans la solution conventionnelle et que l'ajout de périphériques fait croître cette complexité de façon exponentielle. Comme sur le bus partagé, une limitation est que les échanges entre un maître et un esclave sont contrôlés par un protocole dit d'acquittement (ou "handshake"): l'échange est établi exclusivement entre les deux coupleurs. Les mêmes données -3 ne peuvent donc pas être transmises simultanément à d'autres esclaves. Il existe des matrices d'interconnexion qui permettent de transmettre des données de un point vers n points. Cependant, ces matrices ne sont pas capables d'établir également un acquittement entre chaque coupleur. En conséquence, la présente invention a pour but un bus dont les échanges entre coupleurs sont contrôlés par un protocole d'acquittement mais dont l'architecture de bus soit une matrice d'interconnexion, permettant des échanges multi-maîtres / esclaves aussi bien en point à point qu'en diffusion. Un autre but de l'invention est d'obtenir un bus multitâches, flexible, dans lequel la vitesse et l'encombrement des composants électroniques sont optimisés. La présente invention a encore pour but de limiter l'intervention des modules maîtres et esclaves dans la gestion de la matrice. On atteint au moins l'un de ces objectifs avec un nouveau dispositif de bus matriciel entre une pluralité de modules maîtres et une pluralité de modules esclaves. Selon l'invention, ce dispositif comprend une pluralité de modules d'arbitrage répartis dans la matrice, à l'intersection entre chaque module maître et chaque module esclave. Avec le dispositif selon l'invention, on obtient un bus matriciel permettant, à la fois, des communications point à point et des communications de type diffusion. On crée ainsi une structure capable de réaliser des applications multitâches, multi-processeurs, notamment dans un circuit intégré de type SoC. Cette répartition permet également de faciliter le placement des portes électroniques dans une structure matricielle de type FPGA (Field Programmable Gate Array). Selon une caractéristique avantageuse de l'invention, chaque module d'arbitrage est intercalé entre un module maître et un module esclave entre lesquels une communication est prévue. Chaque module maître peut être associé à un contrôleur intercalé entre ce module maître et les modules d'arbitrage, de façon à gérer les flux de données provenant d'autres contrôleurs. De la même manière, chaque module esclave peut être associé à un contrôleur intercalé entre ce module esclave et les modules - 4 d'arbitrage, de façon à gérer les flux de données provenant d'autres contrôleurs. De préférence, les contrôleurs sont répartis dans la matrice. Dans le bus selon l'invention, les fonctions d'arbitrage et de contrôle sont répartis dans la matrice de façon à améliorer la flexibilité et optimiser la vitesse et la surface prise par les portes électroniques. En effet, seuls les points d'interconnexion utiles sont synthétisés suivant des flux prédéfinis entre modules maîtres et esclaves. A titre d'exemple, les connexions du bus peuvent être décrites sous un langage de haut niveau. Et on peut paramétrer le nombre de modules maîtres et esclaves au moment de la synthèse du bus. Chaque contrôleur maître peut comprendre des moyens pour gérer un signal de refus de connexion provenant des modules d'arbitrage. Avantageusement, chaque module maître et/ou chaque module esclave peut s'interfacer de manière asynchrone. De même chaque contrôleur et/ou chaque module d'arbitrage peut fonctionner de manière asynchrone. Ainsi le temps de cycle de chaque transfert est imposé entre chaque couple maître esclave par le module esclave. Cela permet de faire fonctionner simultanément une pluralité de modules dont les performances sont différentes donc de faciliter l'intégration de ces modules et de limiter la dissipation d'énergie au stricte nécessaire. Chaque contrôleur peut également comprendre des moyens pour gérer le flux de données sortant en fonction des résultats d'arbitrage et du mode de communication dans le bus. On peut alors distinguer deux mode de communication, un premier mode normal dans lequel on transmet des données entre un module maître et un module esclave, le bon fonctionnement et le temps de cycle de la transmission étant validé par un système d'acquittement. Un second mode dit de diffusion dans lequel on transmet simultanément des données entre un module maître et plusieurs modules esclaves. Selon un mode de mise en oeuvre de l'invention, lorsque plusieurs modules maîtres tentent d'initier une communication avec un module esclave donné, les modules d'arbitrage concernés se concertent de façon à établir un ordre de priorité entre les modules maîtres. -5 D'une façon générale, chaque arbitre peut comprendre des moyens pour autoriser ou non une communication entre un contrôleur maître et un contrôleur esclave. C'est au sein de chaque contrôleur maître ou esclave que l'on sélectionne les données qui doivent être transmises vers le module associé (maître ou esclave) en réponse à une consigne émise par le module d'arbitrage correspondant. Suivant un autre aspect de l'invention, un procédé de communication dans un bus matriciel entre une pluralité de modules maîtres et une pluralité de modules esclaves. Le procédé selon l'invention comprend les étapes suivantes: - un module maître initie une communication en transmettant un signal d'initiation vers une pluralité de modules d'arbitrage répartis dans la matrice à l'intersection entre ce module maître et plusieurs modules esclaves prédéterminés, - chaque module d'arbitrage interprète le signal d'initiation de façon à déterminer le module esclave concerné par la communication, - le module d'arbitrage correspondant au module esclave concerné vérifie la disponibilité de ce module esclave de façon à autorise ou non la communication entre le module maître et le module esclave concerné. D'autres avantages et caractéristiques de l'invention apparaîtront à l'examen de la description détaillée d'un mode de mise en oeuvre nullement limitatif, et des dessins annexés sur lesquels: la figure 1 est un schéma bloc de l'architecture générale du système de gestion du bus matriciel selon l'invention; - la figure 2 est un schéma structurel détaillé d'une matrice selon l'invention dans une configuration de deux maîtres interconnectés à deux esclaves; - la figure 3 est un schéma simplifié d'un contrôleur maître selon l'invention; - la figure 4 est un schéma simplifié d'un contrôleur esclave selon l'invention; - la figure 5 est un schéma simplifié d'un arbitre élémentaire d'interconnexion selon l'invention; - 6 - la figure 6 est un schéma d'un bus partagé selon l'art antérieur, et - la figure 7 est un schéma d'un bus matriciel selon l'art antérieur. Sur la figure 1 est illustré un schéma bloc de l'architecture générale du système de gestion du bus constitué en matrice d'interconnexion selon l'invention. Ce bus est basé sur une architecture de type SOC (Système on chip) programmable. Les modules maître et esclave correspondent à des modules électroniques réutilisables, que l'on peut aussi qualifier de "IP" (Intellectual Property). Le terme "maître" concerne plus particulièrement des modules divers tel que processeur, contrôleur de communication, fonction de traitement de signal..., qui sont capables de lire ou écrire dans un module esclave et donc d'initialiser un cycle de communication. Il est entendu que deux maîtres ou plus peuvent simultanément émettre des requêtes d'écriture ou de lecture dans la matrice. Par extension, le terme "esclave" concerne des modules qui n'ont pas la capacité d'initialiser un cycle de communication, tels que les interfaces avec des mémoires ou des capteurs. La structure générale de la matrice selon l'invention est distribuée: chaque module maître 1,2,3 est interfacé avec un contrôleur maître 4,5,6; chaque module esclave 10,11,12 est interfacé avec un contrôleur esclave respectivement 7,8,9; les arbitres 13 à 18 sont disposés à l'intersection d'un maître et d'un esclave entre lesquels il est prévu une communication. En effet, la présence de l'arbitre 15 interconnecté entre le contrôleur maître 5 et le contrôleur esclave 8, signifie qu'une communication est possible entre le module maître 2 et le module esclave 11. Le dispositif selon l'invention élimine toute porte électronique et interconnexion de bus non nécessaire à l'application. De ce point de vue, on obtient ainsi une solution optimisée. Les contrôleurs maîtres 4 à 6, les contrôleurs esclaves 7 à 9, et les arbitres 13 à 18 sont répartis au sein de la matrice 19 de telle sorte que les fonctions d'arbitrage et de contrôle ne sont plus concentrées au sein d'un même module. La matrice est donc dotée d'éléments intelligents aptes à gérer la communication entre plusieurs modules maîtres et plusieurs modules esclaves. Il - 7 est possible avec ce dispositif selon l'invention de réaliser des communications parallèles, point à point, point à multipoints. On peut définir notamment deux types de communication: - le mode normal: il y a transmission de données entre un contrôleur maître et un contrôleur esclave. Le bon fonctionnement de la transmission est validé par un système d'acquittement et la communication peut être établie en écriture comme en lecture, - le mode diffusion: il y a transmission de données entre un contrôleur maître et plusieurs contrôleurs esclaves. Le bon fonctionnement de la transmission n'est plus validé par acquittement, et la communication ne peut être établie qu'en écriture. Cependant un même flot de données peut être traité simultanément par plusieurs processeurs. On peut utiliser ce mécanisme pour faire du traitement du signal, par exemple un système de traitement d'images dans lequel chaque image est transmise à plusieurs opérateurs de traitement. Sur la figure 2 est illustrée une structure détaillée de la matrice selon l'invention dans une configuration simple de deux maîtres interconnectés à deux esclaves. Par rapport à la figure 1 on retrouve les deux contrôleurs maîtres 4 et 6 interconnectés aux deux contrôleurs esclaves 7 et 9, les fonctions d'arbitrage étant réparties dans quatre modules d'arbitrage 13,14,16 et 18. Pour le contrôleur esclave 7, les niveaux de priorité entre les contrôleurs maîtres 4 et 6 sont fixés par le routage d'un signal spécifique 26 entre les modules d'arbitrage associé 13 et 14. Dans le cas présent, par exemple, le contrôleur maître 4 est prioritaire sur le contrôleur maître 6. De même, pour le contrôleur esclave 9, les niveaux de priorité entre les maîtres 4 et 6 sont fixés par le routage d'un signal spécifique 27 entre les modules d'arbitrage 16 et 18. Les contrôleurs maîtres 4 et 6 communiquent avec les modules d'arbitrage 13,14,16 et 18 en transmettant des signaux d'initiation 20 et 22. Les contrôleurs esclaves 7 et 9 communiquent avec les modules d'arbitrage en transmettant des signaux de disponibilité 21 et 23. Les modules d'arbitrage 13,14, 16 et 18 sont aptes à transmettre des signaux de validation 28 à vers les contrôleurs maîtres est esclaves. Les flots de données 36 et 37 provenant des contrôleurs maîtres et ceux 24 et provenant des contrôleurs esclaves ne transitent pas par les - 8 modules d'arbitrage. Les données sont donc transférées directement entre les modules maîtres 4,5 et les modules esclaves 7,9. D'une façon générale, la communication entre le contrôleur maître 4 et le contrôleur esclave 9 peut débuter par la transmission d'un signal d'initiation 20 de la part du contrôleur maître 4 vers le module d'arbitrage 16. Ce dernier communique avec le contrôleur esclave 9 au moyen du signal de validation 31 et du signal de disponibilité 23 de façon à vérifier si le module esclave 12, associé au contrôleur esclave 9, est disponible. Si tel est le cas, le module d'arbitrage 16 transmet un signal de validation 30 vers le contrôleur maître 4. Ce signal de validation 30 a pour conséquence d'autoriser le contrôleur maître 4 à transmettre des données 37 vers le contrôleur esclave 9. Le module d'arbitrage 16 peut également indiquer au contrôleur esclave 9, au moyen du signal de validation 31 que les données à prendre en compte sont les données 37 provenant du contrôleur maître 4. Lorsque les deux contrôleurs maîtres 4 et 6 tentent d'atteindre simultanément le contrôleur esclave 9, ce sont les modules d'arbitrage 16 et 18 au moyen du signal de priorité 27 qui déterminent lequel des deux contrôleurs maîtres 4 et 6 peut communiquer avec le contrôleur esclave 9. Sur la figure 3 est représentée une structure interne simplifiée du contrôleur maître 4 selon l'invention. Ce contrôleur maître a pour rôle de gérer les différents flux de données provenant des différents contrôleurs esclaves 7 et 9 auxquels il est relié par des modules d'arbitrage 13 et 16. Chaque contrôleur maître fonctionne de manière asynchrone. La sélection du flux de données en sortie, notamment en direction du module maître 1 de la figure 1 se fait en fonction: - des résultats des différents arbitrages (28,30) fournis par les modules d'arbitrage auxquels ce contrôleur maître 4 est lié; - du mode de communication choisit (diffusion ou normal), ce choix étant fourni par le module maître 1 au moyen du signal 42. Le contrôleur maître comprend des moyens 44 pour gérer le signal RTY 45 correspondant à un refus de connexion en fonction de l'état de la connexion, cet état de connexion étant communiqué par les modules d'arbitrage au moyen des signaux 28 et 30. Le contrôleur maître comprend également deux moyens de multiplexage 39 et 43 permettant respectivement de sélectionner le flux de données 24,25 et le signal d'acquittement 46 provenant d'un contrôleur esclave, en fonction des signaux de validation 28 et 30 émis par les modules d'arbitrage. Le flux de données 38 émis par le multiplexeur 39 est transmis vers le module maître 1. La sortie du multiplexeur 43 alimente un module de contrôle de l'acquittement 40 apte à transmettre un signal d'acquittement 41 vers le module maître 1 en fonction du signal de mode de communication 42 qu'il reçoit. Le contrôleur maître 4 comprend également des moyens (non représentés) pour transmettre des signaux de données et d'adresses, en provenance du module maître 1, vers les contrôleurs esclaves, ainsi que des signaux d'initiation 20 vers les modules d'arbitrages. Le contrôleur esclave 7 tel que schématiquement décrit sur la figure 4 est une interface d'entrée de la matrice 19 en relation avec le module maître 10. Ce contrôleur esclave 7 comprend un multiplexeur 47 recevant un flux de données 36,37 de la part de l'ensemble des contrôleurs maîtres avec lesquels une communication est possible. Ce multiplexeur 47 transmet à sa sortie les signaux provenant d'un contrôleur maître donné en fonction d'un signal de sélection compris dans les signaux de validation 29,33 issus des modules d'arbitrage. Le signal de sortie du multiplexeur 47, passe par un filtre 48 de façon à générer un signal 50 vers le module esclave 10. Le filtre 48 est paramétré par un module de gestion des modes de communication 49 alimenté par une partie des signaux de validation 29, 33 et par un signal de détermination de mode de communication 55 provenant des contrôleurs maîtres. Dans les signaux de validation 29,33 alimentant le module de gestion des modes de communication 49, on distingue le signal de sélection, deux signaux SET-MODE et RSTMODE pour établir et annuler le mode de communication. Ce contrôleur esclave 7 comprend également une porte logique 51 pour recevoir un ensemble de signaux de disponibilité 54 provenant de l'ensemble des modules d'arbitrage, et générer le signal de disponibilité 21 vers les modules d'arbitrage 13 et 14 associés à ce contrôleur esclave 7. - 10 Chaque contrôleur esclave gère donc le flux de données provenant des différents contrôleurs maîtres auxquels il est relié par des modules d'arbitrage. Chaque contrôleur fonctionne de manière asynchrone. La sélection du flux de données en sortie se fait en fonction: - des résultats des différents arbitrages fourni par les modules d'arbitrage auxquels il est lié, - du résultat de la fonction de la gestion du mode de communication 49. Cette fonction utilise pour cela les signaux de communication 53 fourni par les modules d'arbitrage, le mode de communication 55 choisi par chaque module maître et un mode de communication interne (variable gérée en interne par le module de gestion des modes de communication 49). Le signal 21 a notamment pour but de renseigner le module d'arbitrage 13 tel que schématisé sur la figure 5, de la disponibilité du contrôleur esclave 7. Le module d'arbitrage 13 comprend un système d'arbitrage 60 recevant le signal de disponibilité 21, un signal de communication CYC et un signal d'annulation RST intégré dans les signaux d'initiation 20 en provenance du contrôleur maître 4, et éventuellement un signal de priorité 56 en provenance d'un module d'arbitrage précédent. Le système 60 met en oeuvre une fonction d'arbitrage permettant de générer le signal de disponibilité 28 vers le contrôleur maître 4, un signal de sélection 57 vers le contrôleur maître 4 et le contrôleur esclave 7, le signal de priorité 26 vers le module d'arbitrage 14, et le signal de disponibilité (occupation 29) vers le contrôleur esclave 7. Les signaux d'initiation 20 comprennent également un signal d'adressage reçu par un décodeur 58 au sein du module d'arbitrage 13. Ce décodeur 58 a pour rôle d'élaborer des signaux 29 SETMODE et RST-MODE à transmettre vers le contrôleur esclave 7. Pour ce faire, on compare l'adresse transmise dans les signaux 20 avec l'adresse du module esclave 10 stockée dans un moyen de mémoire 59. On prend en compte également le signal de disponibilité 21 provenant du contrôleur esclave 7 ainsi qu'un rebouclage avec le système d'arbitrage 60 au moyen d'un signal de validation 61 émis et d'un signal de disponibilité 62 reçu. Chaque module d'arbitrage a pour rôle d'autoriser ou non l'établissement d'une communication entre un contrôleur maître et - 11 un contrôleur esclave. Ce module fonctionne de manière asynchrone. D'une manière générale, l'arbitrage est déterminé par un ensemble de règles décrites cidessous: 1. Règle d'adressage: le champ correspondant à l'adresse du contrôleur esclave ciblé est décodé: - S'il est identique à l'adresse définie en paramètre pour cet arbitre, une connexion en mode normale est autorisée. - S'il s'agit d'un code réservé correspondant à un type de connexion diffusion, une connexion de type diffusion est autorisée. 2. Règle de priorité: si plusieurs contrôleurs maîtres tentent simultanément d'établir une connexion avec un contrôleur esclave donné, la connexion n'est autorisée que pour celui qui possède le niveau de priorité le plus élevé. 3. Règle de disponibilité: Si une communication est déjà établie entre le contrôleur esclave ciblé et un autre contrôleur maître, la demande de connexion est refusée sinon elle est acceptée. Si les trois règles précédentes autorisent une connexion, une communication est établie entre les deux contrôleurs soit en mode normal soit en mode diffusion selon le résultat de la règle 1 et le contrôleur esclave correspondant est signalé comme étant en communication. Sinon la communication est refusée. Pour l'implémentation du dispositif selon l'invention, on utilise à titre d'exemple non limitatif, un ensemble de fichiers écrit dans un langage de description de matériel tel que VHDL (VHSIC Hardware Description Language) ou Verilog. Cet ensemble se décompose ainsi: - Un fichier (nommé fichier "top") décrivant une unité de conception incluant l'entité et l'architecture correspondant à l'ensemble du bus (arbitres + contrôleurs) et faisant référence à des unités de conception définies dans des fichiers de plus bas niveau. C'est dans ce fichier que les paramètres des différents éléments du bus sont fixés. - Un fichier décrivant une unité de conception incluant l'entité et l'architecture correspondant à l'élément contrôleur s'interfaçant avec un module maître compatible avec la norme - 12 WISHBONE. Le paramètre de cet élément correspond au nombre de contrôleurs esclaves auxquels il est relié. - Un fichier décrivant une unité de conception incluant l'entité et l'architecture correspondant à l'élément contrôleur s'interfaçant avec un module esclave compatible avec la norme WISHBONE. Le paramètre de cet élément correspond au nombre de contrôleurs maîtres auxquels il est relié. - Un fichier décrivant une unité de conception incluant l'entité et l'architecture correspondant à l'élément arbitre et faisant référence à deux entités définies dans des fichiers unité de conception décrivant respectivement le décodage partiel d'adresse et l'arbitrage. Le paramètre de cet élément correspond à l'adresse du contrôleur esclave auquel il est associé. Le bus dans son ensemble fonctionne de manière asynchrone afin de minimiser les pertes de temps internes au bus. Le protocole WISHBONE étant pour sa part synchrone l'utilisation du bus ne dégrade pas les performances générales des communications si le temps de propagation maximum des signaux dans le bus est inférieur à la période de l'horloge de référence du système. L'homme du métier comprendra aisément que la déclaration exhaustive des fichiers utilisés, faite ci-dessus, n'est là que pour illustrer l'invention et que les revendications associées au présent brevet s'appliquent à toute variante de fichiers écrits en langage de description matériel fonctionnant selon les principes décrits dans le présent document. Pour adapter le bus à un design donné, il suffit de modifier à la fois l'architecture et l'entité décrite dans le fichier "top" afin qu'il reflète la matrice d'interconnexions souhaitée, cette entité étant ensuite reprise dans une architecture de plus haut niveau afin de l'intégrer au design. C'est durant cette phase d'adaptation que sont fixés définitivement les caractéristiques de la matrice (nombre des contrôleurs maîtres et esclaves, nombres d'interconnexions possibles, niveau de priorité des différents contrôleurs entre eux). Ces caractéristiques ne pourront plus être modifiés sans la génération d'une nouvelle implémentation. L'ensemble des fichiers est ensuite inclus dans le "design flow" fourni à une chaîne de développement FPGA (outil de synthèse + outil d'implémentation). L'utilisation de ces outils - 13 permet d'optimiser les fonctions d'arbitrage, de contrôle et de routage des bus de la matrice par prédétermination des flux d'échanges entre modules IP. Il existe deux niveaux d'implémentation du bus 1. Implémentation classique uniquement basée sur les fichiers précédemment définis. Le bus étant décrit dans un langage de haut niveau, son implémentation est totalement indépendante de la cible, c'est-à-dire par exemple du type de FPGA utilisé (sous réserve que cette cible contienne les ressources matérielles nécessaires au fonctionnement du bus). Dans ce cas de figure, on ne maîtrise que l'implémentation "logique" du bus, c'est-à-dire que le bus crée un comportement logique similaire au bus décrit mais que l'on ne maîtrise pas sa localisation physique dans la cible. 2. Implémentation "contrainte" pour laquelle un fichier supplémentaire est nécessaire. Ce fichier de contrainte de placement (par exemple au format UCF "User Constraint File" en langue anglaise) est spécifique à un type de FPGA donné et il sera interprété au cours de la phase d'implémentation par l'outil approprié. Dans ce cas de figure on maîtrise à la fois l'implémentation "logique" et l'implémentation physique ce qui permet d'utiliser les possibilités de reconfiguration dynamique de certains FPGA et de garantir la maîtrise de l'ensemble des temps de propagation au sein du bus. A titre d'exemple non limitatif, nous listons ci-dessous un ensemble de chronologies de modes de fonctionnement. A/ Chronologie d'un accès en mode normal 1. Déclenchement d'un cycle d'accès dans un module maître et transmission de signaux au contrôleur maître correspondant. 2. L'ensemble des modules d'arbitrage ou arbitres d'interconnexions reliés au contrôleur maître effectue un décodage partiel de l'adresse émise afin de déterminer quel est le module esclave sollicité. 3. Au sein de l'arbitre d'interconnexion correspondant au couple maître esclave sélectionné, le module de décodage - 14 partiel signifie au module d'arbitrage qu'une demande de connexion a eu lieu. 4. Le module d'arbitrage autorise la connexion en fonction des attributs des contrôleurs maîtres (niveau de priorité) et esclaves(disponibilité du module esclave) et transmet cette information aux contrôleurs. 5. Le contrôleur esclave autorise la transmission des données provenant du module maître vers le module esclave. Le contrôleur maître autorise la transmission des données provenant du module esclave vers le module maître. 6. Fin du cycle d'accès dans le module maître et transmission des signaux au contrôleur maître. 7. L'ensemble des arbitres d'interconnexions reliés au contrôleur maître constate qu'il n'y a plus de connexion et transmet l'information aux contrôleurs. 8. Le contrôleur esclave invalide la transmission des données provenant du module maître vers le module esclave. Le contrôleur maître invalide la transmission des données provenant du module esclave vers le module maître. B/ Chronologie d'un accès en mode diffusion ("broadcast") 1. Création du groupe de diffusion: 1.1. Déclenchement d'un cycle d'accès spécifique (définition d'un groupe de diffusion) dans le module maître et transmission des signaux au contrôleur maître correspondant. 1.2. L'ensemble des arbitres d'interconnexions reliés au contrôleur maître effectue un décodage partiel de l'adresse émise afin de déterminer quel est le module esclave sollicité. 1.3. Au sein de l'arbitre d'interconnexion correspondant au couple maître - esclave sélectionné, le module de décodage partiel signifie au module d'arbitrage qu'une demande de connexion a eu lieu. 1.4. Le module d'arbitrage autorise la connexion spécifique ("intégration à un groupe ") en fonction des attributs des contrôleurs maîtres (niveau de priorité) et esclaves(disponibilité du module esclave) et transmet cette information aux contrôleurs. - 15 1.5. Le contrôleur esclave reconnaît qu'il s'agit d'une requête d'intégration dans un groupe de diffusion et modifie les données internes du contrôleur. La transmission des données provenant du module maître vers le module esclave est désactivée. }.6. Fin du cycle d'accès spécifique dans le module maître et transmission des signaux au contrôleur maître. 1.7. L'ensemble des arbitres d'interconnexions reliés au contrôleur maître détermine qu'il n'y a plus de connexion et transmettent l'information aux contrôleurs. 1.8. Le contrôleur esclave invalide la transmission des données provenant du maître vers le module esclave. Le contrôleur maître invalide la transmission des données provenant de l'esclave vers le module maître. 2. Diffusion des données 2.1. Déclenchement d'un cycle d'accès spécifique (diffusion) dans le module maître et transmission des signaux au contrôleur maître correspondant. 2.2. L'ensemble des arbitres d'interconnexions reliés au contrôleur maître effectue un décodage partiel de l'adresse émise et détermine qu'il s'agit d'une diffusion. 2.3. Au sein de chaque arbitre, le module de décodage partiel signifie au module d'arbitrage qu'une demande de connexion a eu lieu. 2.4. Le module d'arbitrage autorise la connexion spécifique ("diffusion ") en fonction des attributs des contrôleurs maîtres (niveau de priorité) et esclaves(disponibilité du module esclave) et transmet cette information aux contrôleurs. 2.5. Les contrôleurs esclaves reconnaissent qu'il s'agit d'une diffusion, et si les données internes au contrôleur correspondent, autorisent la transmissions des données provenant du maître vers le module esclave. Le contrôleur maître bloque la transmission de l'acquittement. 2.6. Fin du cycle d'accès spécifique dans le module maître et transmission des signaux au contrôleur maître. 2.7. L'ensemble des arbitres d'interconnexions reliés au contrôleur maître détermine qu'il n'y a plus de connexion et transmet l'information aux contrôleurs. - 16 2.8. Les contrôleurs esclaves invalident la transmission des données provenant du module maître vers le module esclave. 3. Suppression du groupe: 3.1. Déclenchement d'un cycle d'accès spécifique (suppression d'un groupe) dans le module maître et transmission des signaux au contrôleur maître correspondant. 3.2. L'ensemble des arbitres d'interconnexions reliés au contrôleur maître effectue un décodage partiel de l'adresse émise et détermine qu'il s'agit d'une suppression de groupe. 3.3. Au sein de chaque arbitre, le module de décodage partiel signifie au module d'arbitrage qu'une demande de connexion a eu lieu. 3.4. Le module d'arbitrage autorise la connexion spécifique ("suppression d'un groupe ") en fonction des attributs des contrôleurs maîtres (niveau de priorité) et esclaves(disponibilité de l'IP) et transmet cette information aux contrôleurs. 3.5. Les contrôleurs esclaves reconnaissent qu'il s'agit d'une suppression de groupe et si les données internes au contrôleur correspondent, modifient les données internes du contrôleur. La transmission des données provenant du maître vers le module esclave est désactivée. Le contrôleur maître bloque la transmission de l'acquittement. 3.6. Fin du cycle d'accès spécifique dans le module maître et transmission des signaux au contrôleur maître. 3.7. L'ensemble des arbitres d'interconnexions reliés au contrôleur maître détermine qu'il n'y a plus de connexion et transmettent l'information aux contrôleurs. 3.8. Les contrôleurs esclaves invalident la transmission des données provenant du module maître vers le module esclave. C/ Chronologie d'un double accès simultané d'un esclave donné Considérons deux modules maîtres 1 et 3 de la figure 2 reliés à un module esclave 10 commun. Le maître 1 a un degré de priorité supérieur au maître 3. Le module esclave 10 est considérée inactif. - 17 1. Déclenchement d'un cycle d'accès dans les modules maîtres 1 et 3 et transmission des signaux aux contrôleurs maîtres 4 et 6 correspondants. 2. L'ensemble des arbitres d'interconnexions 13, 14, 16, 18 reliés aux contrôleurs maîtres 1 et 3 effectue un décodage partiel de l'adresse émise afin de déterminer quel est l'esclave sollicité. 3. Au sein de l'arbitre d'interconnexion correspondant au couple maître - esclave sélectionné, le module de décodage partiel signifie au module d'arbitrage qu'une demande de connexion a eu lieu. 4. Le module d'arbitrage 13 correspondant au maître 1 autorise la connexion en fonction des attributs des contrôleurs maîtres (niveau de priorité) et esclaves(disponibilité du module esclave) et transmet cette information aux contrôleurs. Pour le module maître 3 la connexion est refusée. 5. Le contrôleur esclave 7 autorise la transmission des données provenant du module maître 1 vers le module esclave 10. Le contrôleur maître 4 autorise la transmission des données provenant du module esclave vers le module maître. Le contrôleur maître 6 signale le refus de connexion au module maître 3. 6. Fin du cycle d'accès dans le module maître 1 et transmission des signaux au contrôleur maître 4. 7. L'ensemble des arbitres d'interconnexions reliés au contrôleur maître détermine qu'il n'y a plus de connexion et transmettent l'information aux contrôleurs. 8. Le contrôleur esclave 7 invalide la transmission des données provenant du module maître 1 vers le module esclave. Le contrôleur maître 4 invalide la transmission des données provenant du module esclave vers le module maître 1. D/ Chronologie d'un accès à un esclave déjà en communication: Considérons deux modules maîtres 1 et 3 reliés à un module esclave 10 commun. Le maître 1 a déjà établi une communication avec le module esclave et la transmission est en cours. Le module maître 3 tente d'établir une connexion avec le module esclave 10. - 18 1. Déclenchement d'un cycle d'accès dans le module maître 3 et transmission des signaux au contrôleur maître 6 correspondant. 2. L'ensemble des arbitres d'interconnexions reliés au contrôleur maître 6 effectue un décodage partiel de l'adresse émise afin de déterminer quel est l'esclave sollicité. 3. Au sein de l'arbitre d'interconnexion 14 correspondant au couple maître - esclave sélectionné, le module de décodage partiel signifie au module d'arbitrage qu'une demande de connexion a eu lieu. 4. Le module d'arbitrage 14 correspondant refuse la connexion et transmet cette information aux contrôleurs. Le contrôleur maître 6 signale le refus de connexion au module maître 3. En synthèse, la présente invention peut être basée sur une architecture de type SoC. Elle concerne un nouveau bus matriciel et une méthode de gestion, à la fois des cycles d'accès standard et d'un mode de diffusion, entre plusieurs modules également dénommés IP (Intellectual Property). Le bus SoC de la présente invention inclus une architecture matricielle, des arbitres et des contrôleurs distribués, des fonctions de routage des données entre un module maître et un ou plusieurs modules esclaves. L'invention est aussi une méthode de partitionnement d'un design électronique entre les IP et le bus permettant de tirer partie, à l'échelle des IP, des capacités de reconfiguration dynamique partielle de certaines familles de FPGA). Bien sr, l'invention n'est pas limitée aux exemples qui viennent d'être décrits et de nombreux aménagements peuvent être apportés à ces exemples sans sortir du cadre de l'invention. - 19 REVENDICATIONS 1. Dispositif de bus matriciel entre une pluralité de modules maîtres et une pluralité de modules esclaves, caractérisé en ce qu'il comprend une pluralité de modules d'arbitrage répartis dans la matrice, à l'intersection entre chaque module maître et chaque module esclave. 2. Dispositif selon la revendication 1, caractérisé en ce que chaque module d'arbitrage est intercalé entre un module maître et un module esclave entre lesquels une communication est prévue. 3. Dispositif selon l'une quelconque des revendications précédentes, caractérisé en ce que chaque module maître est associé à un contrôleur intercalé entre ce module maître et les modules d'arbitrage, de façon à gérer les flux de données provenant d'autres contrôleurs. 4. Dispositif selon l'une quelconque des revendications précédentes, caractérisé en ce que chaque module esclave est associé à un contrôleur intercalé entre ce module esclave et les modules d'arbitrage, de façon à gérer les flux de données provenant d'autres contrôleurs. 5. Dispositif selon la revendication 3 ou 4, caractérisé en ce que les contrôleurs sont répartis dans la matrice. 6. Dispositif selon l'une quelconque des revendications 3 à , caractérisé en ce que chaque contrôleur maître comprend des moyens pour gérer un signal de refus de connexion provenant des modules d'arbitrage. 7. Dispositif selon l'une quelconque des revendications précédentes, caractérisé en ce que chaque module maître s'interface selon un cycle asynchrone. - 20 8. Dispositif selon l'une quelconque des revendications précédentes, caractérisé en ce que chaque module esclave s'interface selon un cycle asynchrone. 9. Dispositif selon l'une quelconque des revendications 3 à 8, caractérisé en ce que chaque contrôleur fonctionne de manière asynchrone. 10. Dispositif selon l'une quelconque des revendications précédentes, caractérisé en ce que chaque module d'arbitrage fonctionne de manière asynchrone. 11. Dispositif selon l'une quelconque des revendications 3 à 10, caractérisé en ce que chaque contrôleur comprend des moyens pour gérer le flux de données sortant en fonction des résultats d'arbitrage et du mode de communication dans le bus. 12. Dispositif selon l'une quelconque des revendications précédentes, caractérisé en ce que chaque arbitre comprend des moyens pour autoriser ou non une communication entre un contrôleur maître et un contrôleur esclave. 13. Procédé de communication dans un bus matriciel entre une pluralité de modules maîtres et une pluralité de modules esclaves selon l'une quelconque des revendications précédentes, caractérisé en ce que: - un module maître initie une communication en transmettant un signal d'initiation vers une pluralité de modules d'arbitrage répartis dans la matrice à l'intersection entre ce module maître et plusieurs modules esclaves prédéterminés, - chaque module d'arbitrage interprète le signal d'initiation de façon à déterminer le module esclave concerné par la communication, - le module d'arbitrage correspondant au module esclave concerné vérifie la disponibilité de ce module esclave de façon à autorise ou non la communication entre le module maître et le module esclave concerné. - 21 14. Procédé selon la revendication 13, caractérisé en ce que chaque module maître et chaque module esclave étant associé à un contrôleur, chaque contrôleur sélectionne les données qui doivent être transmises vers le module associé en réponse à une consigne émise par le module d'arbitrage correspondant. 15. Procédé selon la revendication 13 ou 14, caractérisé en ce qu'il comprend un mode de communication dit normal dans lequel on transmet des données entre un module maître et un module esclave, le bon fonctionnement de la transmission et le temps de cycle étant validés par un système d'acquittement. 16. Procédé selon la revendication 13 ou 14, caractérisé en ce qu'il comprend un mode de communication dit de diffusion dans lequel on transmet simultanément des données entre un module maître et plusieurs modules esclaves. 17. Procédé selon l'une quelconque des revendications 13 à 16, caractérisé en ce que, lorsque plusieurs modules maîtres tentent d'initier une communication avec un module esclave donné, les modules d'arbitrage concernés se concertent de façon à établir un ordre de priorité entre les modules maîtres. 18. Procédé selon l'une quelconque des revendications 13 à 17, caractérisé en ce que les connexions du bus sont décrites sous un langage de haut niveau. 19. Procédé selon l'une quelconque des revendications 13 à 18, caractérisé en ce qu'on paramètre le nombre de modules maîtres et esclaves au moment de la synthèse du bus.