FR 2855285 A1 20041126 FR 0405490 A 20040519 On connaît des mécanismes d'arbitrage pour améliorer une largeur de bande de bus entre au moins un maître et au moins un esclave cible. Le fonctionnement de base d'un tel arbitrage comprend une demande, un arbitrage, un accord et un transfert de données. Lorsqu'un arbitre accorde la possession d'un bus à un maître, qui a demandé l'accès à un esclave cible, mais que l'esclave est indisponible pour participer au transfert de données, le résultat est un accord de possession 10 gaspillé, du fait que le maître doit attendre jusqu'à ce que l'esclave cible soit disponible pour le transfert de données. Lorsque le maître accède à un esclave cible ayant une longue latence, la largeur de bande est également dégradée. La figure 1 illustre un diagramme temporel classique qui montre un temps d'attente T. Comme représenté sur cette figure 1, il est fourni un premier ensemble d'informations d'adresse ADDR1-4, suivi par un premier ensemble de données DATA D1-D4. Ensuite, il est fourni un 20 second ensemble d'information d'adresse ADDR5-8, suivi par un second ensemble de données DATA D5-D8. Comme représenté sur la figure 1, le temps d'attente T est un retard entre la disponibilité des données DATA D4 et D5. Ce retard est indésirable. La figure 2 illustre un diagramme temporel 25 souhaitable dans lequel le temps d'attente T est éliminé. L'entrelacement de bancs de mémoire a été utilisé comme une technique classique pour diviser une mémoire en plusieurs bancs, permettant ainsi des accès successifs à chaque banc. Dans l'entrelacement de bancs, des opérations 30 portant sur chacun des deux bancs sont en chevauchement; par exemple, l'accès à des données dans un banc et la précharge des données dans un autre banc sont effectués simultanément, afin d'améliorer la largeur de bande du bus. L'entrelacement de bancs a cependant des 35 inconvénients. En particulier, le maître ne peut établir l'adresse et l'information de commande valides qu'après avoir reçu la possession du bus basée sur un arbitrage. Par conséquent, cette information ne peut pas être utilisée pour l'arbitrage, du fait que l'information est générée après l'arbitrage. Il en résulte que des améliorations de 5 largeur de bande sont limitées. En outre, du fait que la demande adressée à l'esclave cible ne peut pas être envoyée à l'avance, un retard de temps d'attente, tel que T décrit ci-dessus, existe encore. D'autres dispositifs classiques comprennent ceux 10 dans lesquels un maître génère un signal de type de cycle en même temps qu'une demande. Le signal de type de cycle indique la ressource cible (esclave) spécifique à laquelle on doit accéder, et si la cible doit faire l'objet d'une opération de lecture ou d'écriture. Sur la base du signal 15 de type de cycle et de l'information de ressource cible associée, l'arbitre détermine la priorité de la possession du bus. De cette manière, un cycle de nouvelle tentative concernant un esclave cible est évité, et la largeur de bande de bus et les performances de système d'ensemble 20 peuvent être améliorées. Cependant, des broches supplémentaires sont exigées pour mettre en oeuvre le signal de type de cycle et, du fait que la demande adressée à l'esclave cible ne peut pas être envoyée à l'avance, le retard de temps d'attente, tel que T, existe encore. La figure 3 illustre une architecture de bus classique, incluant des maîtres 1 à 3, un arbitre 4, un contrôleur de mémoire vive SDRAM, et un banc de mémoire SDRAM 6. Chaque maître 1 à 3 demande l'accès au bus à l'arbitre 4, par l'intermédiaire d'un signal HBUSREQN. 30 L'arbitre 4, qui comprend une logique d'arbitrage pour sélectionner l'un des maîtres 1 à 3, effectue l'arbitrage et accorde l'accès au bus par l'intermédiaire d'un signal HGRANTN, qui est appliqué au maître sélectionné parmi les maîtres 1 à 3. Comme représenté sur la figure 3, les 35 signaux HADDRN, HWRITEN, HBURSTN, HSIZEN et HTRANN sont respectivement des signaux destinés à activer un esclave cible. Ces signaux sont fournis par les maîtres 1 à 3 au contrôleur de SDRAM 5 par l'intermédiaire d'un ou plusieurs multiplexeurs (MUX) 7-8. Les MUX 7-8 reçoivent un signal HMASTER provenant de l'arbitre 4 et dirigent le signal 5 HADDR, HWRITER, HBURSTR, HSIZER et/ou HTRANR sélectionné vers le contrôleur de SDRAM 5. Le MUX 7 reçoit un signal HWDATAN provenant de chacun des maîtres 1 à 3 et dirige vers le contrôleur de SDRAM 5 le signal sélectionné parmi les signaux HWDATAN, sous la forme d'un signal BIWDATA. 10 Lorsque le contrôleur de SDRAM 5 est prêt, il envoie un signal BIREADYD à chacun des maîtres 1 à 3. Le contrôleur de SDRAM 5 échange également des signaux et des données, dans les deux sens, avec la mémoire SDRAM 6. La figure 4 illustre un diagramme temporel d'une 15 architecture de bus classique. Comme indiqué sur la figure 4, un temps d'attente T existe entre le transfert des premières données BODO-BOD3 et celui des secondes données B1D0-BlD3. Ce temps d'attente T réduit l'efficacité d'utilisation de la largeur de bande de bus, et il est 20 occasionné par le fait que l'arbitre ne peut pas demander à l'esclave cible de se préparer pour l'accès de données avant de recevoir la possession du bus par arbitrage. Dans des exemples de modes de réalisation, la présente invention porte sur un arbitre dans un système 25 pour générer un signal de pseudo-accord dirigé vers tous les dispositifs maîtres demandeurs, et pour recevoir une information de transaction à partir de tous les dispositifs maîtres demandeurs, en réponse au signal de pseudo-accord. Dans des exemples de modes de réalisation, la 30 présente invention porte sur un système qui comprend au moins un dispositif maître pour générer une demande, un arbitre pour recevoir la demande provenant de l'au moins un dispositif maître et pour générer un signal de pseudoaccord en réponse à la demande provenant de l'au moins un 35 dispositif maître, l'au moins un dispositif maître fournissant une information de cible à l'arbitre en réponse au signal de pseudo-accord, et au moins un dispositif esclave se préparant pour le transfert de données en réponse à l'information de cible fournie par l'au moins un dispositif maître. Dans des exemples de modes de réalisation, la présente invention porte sur un procédé d'accomplissement d'arbitrage dans un système, qui comprend la génération d'un signal de pseudo-accord en réponse à une demande, et la réception d'une information de cible en réponse au 10 signal de pseudo-accord. Dans des exemples de modes de réalisation, la présente invention porte sur un procédé d'accomplissement d'arbitrage dans un système, qui comprend la génération d'une demande, la réception de la demande et la génération 15 d'un signal de pseudo-accord en réponse à la demande, la fourniture d'une information de cible en réponse au signal de pseudo- accord, et la préparation pour le transfert de données en réponse à l'information de cible. La présente invention sera comprise de façon plus 20 plus complète d'après la description détaillée donnée cidessous et les dessins annexés, qui sont donnés seulement dans un but d'illustration, et ne limitent donc pas l'invention. Dans les dessins: La figure 1 montre un diagramme temporel classique 25 qui illustre un temps d'attente T. La figure 2 montre un diagramme temporel souhaitable dans lequel le temps d'attente T est éliminé. La figure 3 montre une architecture de bus classique. La figure 4 montre un diagramme temporel d'une architecture de bus classique. La figure 5 montre une structure d'arbitrage de bus conforme à un exemple de mode de réalisation de la présente invention. La figure 6 montre un diagramme temporel conforme à un exemple de mode de réalisation de la présente invention. La figure 7 montre une architecture de bus plus détaillée de la figure 5, conforme à un exemple de mode de réalisation de la présente invention. La figure 8 montre un autre exemple d'architecture 5 détaillée de la technique d'arbitrage de bus générale illustrée sur la figure 5. La figure 9 montre un exemple de diagramme temporel conforme à la présente invention. La figure 10 montre l'interface de maître illustrée 10 sur les figures 7 ou 8, conforme à un exemple de mode de réalisation de la présente invention. La figure 11 montre un organigramme d'une première phase d'un procédé conforme à un exemple de mode de réalisation de la présente invention. La figure 12 montre un organigramme d'une seconde phase d'un procédé conforme à un exemple de mode de réalisation de la présente invention. La figure 5 illustre une structure d'arbitrage de bus conforme à un exemple de mode de réalisation de la 20 présente invention. Comme illustré sur la figure 5, la structure d'arbitrage de bus comprend N dispositifs maîtres 110, 120, 130, le nombre N étant supérieur ou égal à un, un arbitre 140, et M dispositifs esclaves 150, 160, 170, M étant supérieur à un et non nécessairement égal à N. En 25 fonctionnement, chaque dispositif maître 110, 120, 130 envoie une demande HBUSREQN à l'arbitre 140. Le signal HBUSREQ est un signal de demande pour accéder à un esclave cible, par exemple les esclaves 150, 160 ou 170. L'arbitre 140 fournit un signal de pseudo-accord HGRANT à chacun des 30 N dispositifs maîtres 110, 120, 130 effectuant une demande. Le signal HGRANT est un signal pour accorder la possession du bus à un maître. Chacun des N dispositifs maîtres 110, 120, 130 fournit ensuite une information de cible à l'arbitre 140, pour permettre à l'arbitre 140 d'effectuer 35 un arbitrage. Dans l'exemple de mode de réalisation illustré sur la figure 5, l'information de cible est un signal HADDRN. L'arbitre 140 effectue un arbitrage et indique qu'un transfert de données peut avoir lieu en fournissant à chaque maître 110, 120 un signal d'état prêt HREADYN. Lorsque deux ou plus des maîtres 110, 120, 130 demandent l'accès à un bus, les signaux HBUSREQN sont activés. Dans un exemple de mode de réalisation de la présente invention, dans une telle situation, l'arbitre 140 accorde une "fausse" ou "pseudo" possession à tous les 10 maîtres demandeurs 110, 120, 130, en retournant un signal HGRANTN avant l'arbitrage. Les maîtres 110, 120, 130 recevant la possession du bus fournissent l'information désirée concernant l'esclave cible (par exemple HADDRN). L'arbitre 140 utilise cette information et l'information 15 d'esclave cible associée afin d'effectuer l'acte d'arbitrage. Après l'arbitrage et le contrôle de la disponibilité du bus, l'arbitre 140 envoie le signal HREADY actif au maître sélectionné, pour indiquer qui a réellement la possession du bus. De façon classique, un signal d'accord HGRANT est fourni après l'arbitrage. Dans des exemples de modes de réalisation de la présente invention, le signal d'accord HGRANT est fourni après une demande, mais avant l'arbitrage, comme envisagé ci-dessus. La figure 6 illustre un exemple de diagramme temporel de la présente invention. Comme illustré sur la figure 6, le signal HGRANT1 est commuté à l'état haut en réponse au signal HBUSREQ1. En outre, le signal HADDR1 est généré en réponse à une transition vers l'état haut du 30 signal HGRANT1, et est synchronisé avec HCLK. De façon similaire, le signal HGRANT2 est commuté vers l'état haut en réponse au signal HBUSREQ2. En outre, le signal HADDR2 est généré en réponse à une transition vers l'état haut du signal HGRANT2 et est synchronisé avec HCLK. Comme 35 représenté également sur la figure 6, l'information de données HRDATA, incluant DATA1, est générée en réponse au signal HREADY1, et les données, en particulier DATA5, sont générées en réponse au signal HREADY2. Comme représenté sur la figure 6, l'arbitre 140 reçoit le signal HADDR2 à partir du maître 110, 120, 130 plus tôt dans l'exemple de mode de 5 réalisation de la présente invention, ce qui réduit un retard. Sur la figure 7 et/ou 8, les signaux HADDR, HBURST, HWRITE sont respectivement des signaux destinés à activer l'esclave cible. Le signal BIREQD est un signal pour 10 demander à un esclave cible de se préparer pour un accès à des données. Les signaux BIADDR, BIBA, BIRCONT, BICCONT sont tous des signaux incluant de l'information pour commander un esclave cible. Le signal BICONFIRMD est un signal d'acquittement (ACK) pour le signal BIREQD. Les 15 signaux NDCAS, NRAS, NCAS, NDWE sont des signaux d'ordre pour accéder à un esclave cible ou, dans d'autres exemples de mode de réalisation, à un banc de mémoire spécifique particulier. Le signal BA est un signal d'adresse de banc, le signal BIREADYD est un signal qui est déclenché pour 20 être activé lorsqu'un esclave cible est prêt à accepter un transfert de données. Le signal HREADYN est un signal pour indiquer qu'un maître particulier a maintenant la possession du bus pour un transfert de données vers un esclave cible ou à partir de celui- ci. La figure 7 illustre une architecture de bus plus détaillée de la figure 5, conforme à un exemple de mode de réalisation de la présente invention. Comme illustré sur la figure 7, l'rarbitre 550 comprend une interface de maître 552 et une interface de contrôleur d'esclave 554. 30 L'interface de maître 552 interagit avec les N dispositifs maîtres 510, 520, 530 et l'interface de contrôleur d'esclave 554 interagit avec M contrôleurs d'esclave 571, 572, 573. Les M contrôleurs d'esclave 571, 572, 573 commandent un ou plusieurs dispositifs esclaves 541, 542, 35 543. Comme indiqué sur la figure 7, chaque dispositif maître 510, 520, 530 fournit un signal HBUSREQ à l'arbitre 550. L'arbitre 550 génère un signal HGRANT pour chacun des dispositifs maîtres. Chacun des dispositifs maîtres fournit ensuite un signal HADDR, un signal HBURST et/ou un signal HWRITE à l'arbitre 550. Chacun des dispositifs maîtres 510, 520, 530 fournit un signal HWDATAn à un multiplexeur (MUX) 560, et l'un sélectionné des signaux HWDATAn, appelé BIWDATA, est appliqué aux contrôleurs d'esclave 571, 572, 573. Les 10 contrôleurs d'esclave 571, 572, 573 transfèrent des données vers les dispositifs esclaves 541, 542, 543 et à partir de ceux-ci. Les contrôleurs d'esclave 571, 572, 573 fournissent également un signal BIRDATAn à un multiplexeur (MUX) 580, et l'un sélectionné des signaux BIRDATAn, appelé 15 BIRDATA, est appliqué aux dispositifs maîtres 510, 520, 530. La figure 8 illustre un autre exemple d'architecture détaillée de la technique d'arbitrage de bus générale illustrée sur la figure 5. Comme représenté sur la 20 figure 8, l'arbitre 250 comprend une interface de maître 252 et une interface de contrôleur de mémoire SDRAM 254. L'interface de maître 252 interagit avec les dispositifs maîtres 210, 220, 230 et le multiplexeur 260, d'une manière très semblable à celle décrite ci-dessus en relation avec 25 la figure 7. L'interface de contrôleur de mémoire SDRAM 254 fournit des signaux BIREQD, BIADDR, BIBA, BIBE, BIRCONT et BICCONT à un contrôleur de mémoire SDRAM 270 et reçoit un signal BIREADYD et un signal BICONFIRMD provenant du contrôleur de mémoire SDRAM 270. Le contrôleur de mémoire 30 SDRAM reçoit BIWDATA à partir du dispositif sélectionné parmi les dispositifs maîtres 210, 220, 230, du MUX 260, et fournit BIRDATA au dispositif sélectionné parmi les dispositifs maîtres 210, 220, 230. Le contrôleur de mémoire SDRAM 270 fournit les signaux NDCS, NRAS, NCAS, NDWE, BA et 35 ADDR à une mémoire SDRAM 240 et reçoit des données en retour à partir de la mémoire SDRAM 240. Dans un exemple de mode de réalisation, la mémoire SDRAM 240 comprend un ou plusieurs bancs de mémoire, identifiés comme des éléments 241, 242, 243 et 244. La figure 9 illustre un exemple de diagramme 5 temporel conforme à la présente invention. Comme illustré sur la figure 9, le maître est capable d'envoyer de l'information de façon précoce, du fait que l'arbitre permet un envoi précoce par l'intermédiaire du signal de pseudo-accord. L'arbitre peut demander à l'esclave de se 10 préparer pour le transfert de données, par l'intermédiaire des signaux RAS1 et CAS1, du fait que l'arbitre peut recevoir de façon précoce l'information concernant l'esclave cible. La figure 10 illustre un exemple de mode de 15 réalisation de l'interface de maître illustrée sur les figures 7 ou 8. Comme représenté sur la figure 10, l'interface de maître 252, 552 comprend des unités de synchroniseur 1001, 1002, 1003, et chacune d'elles reçoit un signal HBUSREQ provenant d'un dispositif maitre, et émet 20 un signal HGRANT. L'interface de maître 252, 552 comprend en outre des multiplexeurs (MUX) 1005, 1006, 1008 qui reçoivent le signal BIREADYD indiquant que les esclaves cibles sont prêts à émettre des données, et émettent un ou plusieurs signaux HREADY. Comme indiqué sur la figure 10, 25 l'interface de maître 252, 552 n'a pas besoin d'inclure une logique d'arbitrage quelconque. La figure 11 illustre un organigramme conforme à un exemple de mode de réalisation de la présente invention. Comme représenté à l'étape 310, l'arbitre détermine si au 30 moins un maître demande l'accès au bus. Dans la négative, l'arbitre reste dans une boucle d'attente. Dans l'affirmative, l'arbitre envoie un signal HGRANT à tous les dispositifs maîtres demandeurs, à l'étape S320. A l'étape S330, l'arbitre reçoit une information d'activation 35 provenant de tous les dispositifs maîtres demandeurs. A l'étape 340, sur la base de l'information d'activation de bus et de l'information d'état de l'esclave cible, un maître particulier est sélectionné par l'arbitre. A l'étape 350, pour réduire des latences associées à l'esclave cible, indépendamment de la disponibilité du 5 bus, l'arbitre demande à l'esclave cible auquel le maître sélectionné a accédé de se préparer pour le transfert de données. A l'étape 360, le contrôleur d'esclave envoie le signal d'ordre à l'esclave cible. L'organigramme illustré sur la figure 11 peut être considéré comme une première 10 phase de l'exemple de procédé de la présente invention. La figure 12 illustre une seconde phase, dans laquelle l'arbitre détermine à l'étape 410 si des esclaves cibles quelconques ont terminé la préparation du transfert de données. Dans la négative, l'arbitre reste dans la 15 boucle d'attente. Dans l'affirmative, l'arbitre détermine à l'étape 420 si le bus est disponible. Si le bus n'est pas disponible, l'arbitre reste dans une boucle d'attente. Si le bus est disponible, l'arbitre sélectionne l'un des maîtres demandeurs qui tentent d'accéder à des esclaves 20 cibles qui ont terminé la préparation du transfert de données, à l'étape 430. A l'étape 440, des données sont transférées entre le maître de bus sélectionné et l'esclave cible associé, et le processus se répète. Comme décrit ci-dessus, des exemples de modes de 25 réalisation de la présente invention modifient l'ordre de signaux d'arbitrage par rapport à l'ordre classique. En particulier, dans des exemples de modes de réalisation, le signal de pseudo-accord précède l'arbitrage. En outre, dans des exemples de modes de réalisation, le transfert 30 d'information précède l'arbitrage, de façon que l'information contenue dans le transfert de données puisse être utilisée dans la décision d'arbitrage. Des exemples de modes de réalisation de la présente invention réduisent ou éliminent un temps d'attente T et/ou permettent de 35 meilleures décisions d'arbitrage, grâce à l'information supplémentaire disponible. il Bien que les exemples de modes de réalisation de la présente invention décrivent des interfaces de contrôleur et des mémoires spécifiques, on pourrait utiliser n'importe quelles autres interfaces et/ou mémoires, comme il serait 5 connu de l'homme de l'art. En outre, bien que les exemples de modes de réalisation de la présente invention décrivent un conflit de bus particulier, les enseignements de la présente invention pourraient également être utilisés pour résoudre n'importe quel autre conflit de bus, ou n'importe 10 quel autre conflit de ressources, comme il serait connu de l'homme de l'art. Il va de soi que de nombreuses modifications peuvent être apportées au dispositif et au procédé décrits et représentés, sans sortir du cadre de l'invention. REVENDICATIONS 1. Arbitre dans un système, caractérisé en ce qu'il est destiné à générer un signal de pseudo-accord (HGRANT1 HGRANTN) envoyé à tous les dispositifs maîtres demandeurs 5 (110, 120, 130), et à recevoir une information de transaction (HADDR1 - HADDRN) provenant de tous les dispositifs maîtres demandeurs (110, 120, 130) en réponse au signal de pseudo-accord (HGRANT1 - HGRANTN). 2. Arbitre selon la revendication 1, caractérisé en 10 ce qu'il accomplit en outre un arbitrage basé sur l'information de transaction (HADDR1 HADDRN) reçue du dispositif maître demandeur (110, 120, 130). 3. Arbitre selon la revendication 1, caractérisé en ce qu'il comprend une interface de maître (552) pour 15 générer le signal de pseudo-accord (HGRANT1 - HGRANT3) envoyé à tous les dispositifs maîtres demandeurs (510, 520, 530), pour recevoir l'information de transaction (HADDR1 HADDR3) provenant de tous les dispositifs maîtres demandeurs (510, 520, 530) en réponse au signal de pseudo20 accord (HGRANT1 - HGRANT3), et pour générer un signal d'état prêt (HREADY1 - HREADY3) envoyé à l'un sélectionné des dispositifs maîtres demandeurs (510, 520, 530). 4. Arbitre selon la revendication 3, caractérisé en ce que l'interface de maître (552) comprend au moins un 25 générateur pour générer les signaux de pseudo-accord (HGRANT1 - HGRANT3) à partir d'au moins un signal de demande (HBUSREQ1 - HBUSREQ3) provenant de tous les dispositifs maîtres demandeurs (510, 520, 530). 5. Arbitre selon la revendication 3, caractérisé en 30 ce que l'interface de maître (552) comprend au moins un circuit pour convertir un signal d'état prêt d'esclave cible provenant d'au moins un esclave (541, 542, 543) en un signal d'état prêt de transfert de données, pour l'un sélectionné des dispositifs maîtres demandeurs (510, 520, 35 530). 6. Arbitre selon la revendication 3, caractérisé en ce que le signal d'état prêt est destiné au transfert de données. 7. Arbitre selon la revendication 3, caractérisé en ce que le signal d'état prêt indique la disponibilité du bus. 8. Arbitre selon la revendication 1, caractérisé en ce qu'il comprend une interface de contrôleur (554) pour demander à au moins un dispositif esclave (541, 542, 543) de préparer un transfert de données en réponse à 10 l'information cible provenant du dispositif sélectionné parmi les dispositifs maîtres demandeurs (510, 520, 530). 9. Arbitre selon la revendication 8, caractérisé en ce que l'interface de contrôleur est une interface de contrôleur d'esclave (554) qui interagit avec au moins un 15 contrôleur d'esclave (571, 572, 573) de l'au moins un dispositif esclave (541, 542, 543). 10. Arbitre selon la revendication 9, caractérisé en ce que chaque contrôleur d'esclave (270) commande au moins une mémoire esclave (240). 11. Arbitre selon la revendication 8, caractérisé en ce que l'interface de contrôleur est une interface de contrôleur de mémoire SDRAM (254) qui interagit avec au moins un contrôleur de mémoire SDRAM (270) de l'au moins un dispositif esclave (240). 12. Arbitre selon la revendication 11, caractérisé en ce que chaque contrôleur de mémoire SDRAM (270) commande au moins un banc de mémoire SDRAM (241-244). 13. Arbitre selon la revendication 1, caractérisé en ce qu'une demande (HBUSREQ1 - HBUSREQ3) provenant de 30 tous les dispositifs maîtres demandeurs (510, 520, 530) est synchronisée avec une horloge de système (HCLK). 14. Système, caractérisé en ce qu'il comprend au moins un dispositif maître (110, 120, 130) pour générer une demande (HBUSREQ1 - HBUSREQN); un arbitre (140) pour 35 recevoir la demande provenant de l'au moins un dispositif maître (110, 120, 130) et pour générer un signal de pseudoaccord (HGRANT1 - HGRANTN) en réponse à la demande provenant de l'au moins un dispositif maître (110, 120, 130); l'au moins un dispositif maître (110, 120, 130) fournissant à l'arbitre (140) une information de cible 5 (HADDR1 - HADDRN) en réponse au signal de pseudo-accord; et au moins un dispositif esclave (150, 160, 170) se préparant pour le transfert de données en réponse à l'information de cible fournie par l'au moins un dispositif maître (110, 120, 130). 15. Système selon la revendication 14, caractérisé en ce que l'au moins un dispositif esclave (150, 160, 170) achève la préparation pour le transfert des données, et des données sont transférées entre l'un de l'au moins un dispositif maître (110, 120, 130) et l'un de l'au moins un 15 dispositif esclave (150, 160, 170). 16. Système selon la revendication 14, caractérisé en ce que tous les dispositifs maîtres (110, 120, 130) demandeurs dans le système reçoivent le signal de pseudoaccord (HGRANT1 - HGRANTN) provenant de l'arbitre (140) . 17. Système selon la revendication 14, caractérisé en ce que la demande provenant de l'au moins un dispositif maître (110, 120, 130) est synchronisée avec une horloge de système (HCLK). 18. Système selon la revendication 14, caractérisé 25 en ce que le signal de pseudo-accord (HGRANT1 - HGRANTN) provenant de l'arbitre (140) et l'information de cible (HADDR1 - HADDRN) provenant de l'au moins un dispositif maître (110, 120, 130) sont synchronisés. 19. Procédé pour effectuer un arbitrage dans un 30 système, caractérisé en ce qu'il comprend la génération d'un signal de pseudo-accord (HGRANT1 HGRANTN) en réponse à une demande (HBUSREQ1 - HBUSREQN) et la réception d'une information de cible (HADDR1 - HADDRN) en réponse au signal de pseudo-accord. 20. Procédé selon la revendication 19, caractérisé en ce qu'il comprend en outre l'accomplissement d'un arbitrage basé sur l'information de cible (HADDR1 HADDRN). 21. Procédé selon la revendication 19, caractérisé en ce que la demande et l'information de cible proviennent d'une multiplicité de dispositifs maîtres (110, 120, 130). 22. Procédé selon la revendication 19, caractérisé en ce que le pseudoaccord est généré en réponse à toutes les demandes. 23. Procédé selon la revendication 19, caractérisé 10 en ce qu'il comprend en outre une demande de préparation pour le transfert de données en réponse à l'information de cible (HADDR1 - HADDRN). 24. Procédé selon la revendication 19, caractérisé en ce que la demande est synchronisée avec une horloge de 15 système (HCLK). 25. Procédé selon la revendication 19, caractérisé en ce que le procédé est mis en oeuvre par logiciel ou par matériel. 26. Procédé pour effectuer un arbitrage dans un 20 système, caractérisé en ce qu'il comprend la génération d'une demande (HBUSREQ1 - HBUSREQN) ; la réception de la demande et la génération d'un signal de pseudo-accord (HGRANT1 - HGRANTN) en réponse à la demande; la fourniture d'une information de cible (HADDR1 - HADDRN) en réponse au 25 signal de pseudoaccord; et la préparation pour un transfert de données en réponse à l'information de cible. 27. Procédé selon la revendication 26, caractérisé en ce que la demande et l'information de cible proviennent d'une multiplicité de dispositifs maîtres demandeurs (110, 30 120, 130). 28. Procédé selon la revendication 27, caractérisé en ce qu'il comprend en outre l'achèvement de la préparation du transfert de données; et le transfert de données. 29. Procédé selon la revendication 26, caractérisé en ce que la génération, la réception, la fourniture et la préparation constituent une première phase, et l'achèvement et le transfert constituent une seconde phase, et les première et seconde phases ont lieu concurremment. 30. Procédé selon la revendication 29, caractérisé 5 en ce que l'achèvement de la préparation du transfert de données comprend la détermination du fait qu'un bus est disponible ou non, et la sélection de l'un des dispositifs maîtres (110, 120, 130) demandeurs. 31. Procédé selon la revendication 26, caractérisé 10 en ce que le signal de pseudo-accord (HGRANT1 - HGRANTN) est généré en réponse à toutes les demandes (HBUSREQ1 HBUSREQN). 32. Procédé selon la revendication 26, caractérisé en ce que la demande est synchronisée avec une horloge de 15 système (HCLK). 33. Procédé selon la revendication 26, caractérisé en ce que le procédé est mis en oeuvre par logiciel ou par matériel.