Fonctionnement d'un ordinateur/Les bus électroniques

Il y a quelques chapitres, nous avons vu la différence entre bus et liaison point à point : là où ces dernières ne connectent que deux composants, les bus de communication en connectent bien plus. Ce faisant, les bus de communication font face à de nouveaux problèmes, inconnus des liaisons point à point. Et ce sont ces problèmes qui font l'objet de ce chapitre. Autant le chapitre précédent valait à la fois pour les liaisons point à point et les bus, autant ce n'est pas le cas de celui-ci. Ce chapitre va parler de ce qui n'est valable que pour les bus de communication, comme leur arbitrage, la détection des collisions, etc. Tous ces problèmes ne peuvent pas survenir, par définition, sur les liaisons point à point.

L'adressage du récepteur

La trame doit naturellement être envoyée à un récepteur, seul destinataire de la trame. Sur les liaisons point à point, il n'y a pas besoin de préciser quel est le récepteur. Mais sur les bus, c'est une toute autre histoire. Tous les composants reliés aux bus sont de potentiels récepteurs et l'émetteur doit préciser à qui la trame est destinée. Pour résoudre ce problème, chaque composant se voit attribuer une adresse, il est « numéroté ». Cela fonctionne aussi pour les composants qui sont des périphériques.

L'adressage sur les bus parallèles et série

Sur les bus parallèles, l'adresse est généralement transmise sur des fils à part, sur un sous-bus dédié appelé le bus d'adresse. En général, les adresses sur les bus pour périphériques sont assez petites, de quelques bits dans le cas le plus fréquent, quelques octets tout au plus. Il n'y a pas besoin de plus pour adresser une centaine de composants ou plus. Les seuls bus à avoir des adresses de plusieurs octets sont les bus liés aux mémoires, ou ceux qui ont un rapport avec les réseaux informatiques.

Les bus multiplexés utilisent une astuce pour économiser des fils et des broches. Un bus multiplexé sert alternativement de bus de donnée ou d'adresse, suivant la valeur d'un bit du bus de commande. Ce dernier, le bit Adress Line Enable (ALE), précise si le contenu du bus est une adresse ou une donnée : il vaut 1 quand une adresse transite sur le bus, et 0 si le bus contient une donnée.

Un défaut de ces bus est que les transferts sont plus lents, car l'adresse et la donnée ne sont pas envoyées en même temps lors d'une écriture. Un autre problème des bus multiplexé est qu'ils ont a peu près autant de bits pour coder l'adresse que pour transporter les données. Par exemple, un bus multiplexé de 8 bits transmettra des adresses de 16 bits, mais aussi des données de 16 bits. Ils sont donc moins versatiles, mais cela pose problème sur les bus où l'on peut connecter peu de périphériques. Dans ce cas, les adresses sont très petites et l'économie de fils est donc beaucoup plus faible.

Passons maintenant aux bus série (ou certains bus parallèles particuliers). Pour arriver à destination, la trame doit indiquer l'adresse du composant de destination. Les récepteurs espionnent le bus en permanence pour détecter les trames qui leur sont destinées. Ils lisent toutes les trames envoyées sur le bus et en extraient l'adresse de destination : si celle-ci leur correspond, ils lisent le reste de la trame, ils ne la prennent pas en compte sinon.

L'adresse en question est intégrée à la trame et est placée à un endroit précis, toujours le même, pour que le récepteur puisse l'extraire. Le plus souvent, l'adresse de destination est placée au début de la trame, afin qu'elle soit envoyée au plus vite. Ainsi, les périphériques savent plus rapidement si la trame leur est destinée ou non, l'adresse étant connue le plus tôt possible.

Le décodage d'adresse

Le fait d'attribuer une adresse à chaque composant est une idée simple, mais efficace. Encore faut-il la mettre en œuvre et il existe plusieurs possibilités pour cela. Implémenter l'adressage sur un bus demande à ce que chaque composant sache d'une manière ou d'une autre que c'est à lui que l'on veut parler et pas à un autre. Lorsqu'une adresse est envoyée sur le bus, seul l'émetteur et le récepteur se connectent au bus, les autres composants ne sont pas censés réagir. Et pour cela, il existe deux possibilités : soit on délègue l'adressage au composant, soit on ajoute un circuit qui active le composant adressé et désactive les autres.

Avec la première méthode, les composants branchés sur le bus monitorent en permanence ce qui est transféré sur le bus. Quand un envoi de commande a lieu, chaque composant extrait l'adresse transmise sur le bus et vérifie si c'est bien la sienne. Si c'est le cas, le composant se connecte sur le bus et les autres composants se déconnectent. En conséquence, chaque composant contient un comparateur pour cette vérification d'adresse, dont la sortie commande les circuits trois états qui relient le contrôleur au bus. Cette méthode est particulièrement pratique sur les bus où le bus d'adresse est séparé du bus de données. Si ce n'est pas le cas, le composant doit mémoriser l'adresse transmise sur le bus dans un registre, avant de faire la comparaison? Même chose sur les bus série.

La seconde solution est celle du décodage d'adresse. Elle utilise un circuit qui détermine, à partir de l'adresse, quel est le composant adressé. Seul ce composant sera activé/connecté au bus, tandis que les autres seront désactivés/déconnectés du bus. Pour implémenter la dernière solution, chaque périphérique possède une entrée CS, qui active ou désactive le composant suivant sa valeur. Le composant se déconnecte du bus si ce bit est à 0 et est connecté s'il est à 1. Pour éviter les conflits, un seul composant doit avoir son bit CS à 1. Pour cela, il faut ajouter un circuit qui prend en entrée l'adresse et qui commande les bits CS : ce circuit est un circuit de décodage partiel d'adresse.

L'interfaçage avec le bus

Une fois que l'on sait quel composant a accès au bus à un instant donné, il faut trouver un moyen pour que les composants non sélectionnés par l'arbitrage ne puissent pas écrire sur le bus.

Une première solution consiste à relier les entrées/sorties des composants au bus via un multiplexeur/démultiplexeur : on est alors certain que seul un composant pourra émettre sur le bus à un moment donné. L'arbitrage du bus choisit quel composant peut émettre, et configure l'entrée de commande du multiplexeur en fonction. Les multiplexeurs et démultiplexeurs sont configurés en utilisant l'adresse du composant émetteur/récepteur.

Une autre solution consiste à connecter et déconnecter les circuits du bus selon les besoins. À un instant t, seul l'émetteur et le récepteur sont connectés au bus. Mais cela demande pouvoir déconnecter du bus les entrées/sorties qui n'envoient pas de données. Plus précisément, leurs sorties peuvent être mises dans un état de haute impédance, qui n'est ni un 0 ni un 1. Quand une sortie est en haute impédance, elle n'a pas la moindre influence sur le bus et ne peut donc pas y écrire. Tout se passe comme si elle était déconnectée du bus, et dans les faits, elle l'est souvent.

Dans le chapitre sur les circuits intégrés, nous avons vu qu'il existait trois types de sorties : les sorties totem-pole, à drain/collecteur ouvert, et trois-état. Les sorties totem-pole fournissent soit un 1, soit un zéro, et ne peuvent pas être déconnectées proprement dit. Les deux autres types de sorties en sont capables. Et nous allons les voir dans ce qui suit.

L'interfaçage avec le bus avec des circuits trois-états

Le cas le plus simple est celui des sorties trois-état, qui peuvent soit fournir un 1, soit fournir un 0, soit être déconnectées. Malheureusement, les circuits intégrés normaux n'ont pas naturellement des entrées-sorties trois-état. Les portes logiques fournissent soit un 0, soit un 1, pas d'état déconnecté.

La solution retenue sur presque tous les circuits actuels est d'utiliser des tampons trois états. Pour rappel, nous avions vu ce circuit dans le chapitre sur les circuits intégrés, mais un rappel ne fera clairement pas de mal. Un tampon trois-états peut être vu comme une porte OUI modifiée, qui peut déconnecter sa sortie de son entrée. Un tampon trois-état possède une entrée de donnée, une entrée de commande, et une sortie : suivant ce qui est mis sur l'entrée de commande, la sortie est soit en état de haute impédance (déconnectée du bus), soit égale à l'entrée.

Commande	Entrée	Sortie
0	0	Haute impédance/Déconnexion
0	1	Haute impédance/Déconnexion
1	0	0
1	1	1

On peut utiliser ces tampons trois états pour permettre à un composant d'émettre ou de recevoir des données sur un bus. Par exemple, on peut utiliser ces tampons pour autoriser les émissions sur le bus, le composant étant déconnecté (haute impédance) s'il n'a rien à émettre. Le composant a accès au bus en écriture seule. L'exemple typique est celui d'une mémoire ROM reliée à un bus de données.

Une autre possibilité est de permettre à un composant de recevoir des données sur le bus. Le composant peut alors surveiller le bus et regarder si des données lui sont transmises, ou se déconnecter du bus. Le composant a alors accès au bus en lecture seule.

Évidemment, on peut autoriser lectures et écritures : le composant peut alors aussi bien émettre que recevoir des données sur le bus quand il s'y connecte. On doit alors utiliser deux circuits trois états, un pour l'émission/écriture et un autre pour la réception/lecture. Comme exemple, on pourrait citer les mémoires RAM, qui sont reliées au bus mémoire par des circuits de ce genre. Dans ce cas, les circuits trois états doivent être commandés par le bit CS (Chip Select) qui connecte ou déconnecte la mémoire du bus, mais aussi par le bit R/W (Read/Write) qui décide du sens de transfert. Pour faire la traduction entre ces deux bits et les bits à placer sur l'entrée de commande des circuits trois états, on utilise un petit circuit combinatoire assez simple.

L'interfaçage avec le bus avec des circuits à drain/collecteur ouvert

Les sorties à drain/collecteur ouvert sont plus limitées et ne peuvent prendre que deux états. Dans le cas le plus fréquent, la sortie est soit déconnectée, soit mise à 0 par le circuit intégré, mais elle ne peut pas être mise à 1 sans intervention extérieure. Pour compenser cela, le bus est relié à la tension d'alimentation à travers une résistance, appelée résistance de rappel. Cela garantit que le bus est naturellement à l'état 1, du moins tant que les sorties des composants sont déconnectées. Au repos, quand les composants n’envoient rien sur le bus, les sorties des composants sont déconnectées et les résistances de rappel mettent le bus à 1. Mais quand un seul composant met sa sortie à 0, cela force le bus à passer à 0.

Pour le dire autrement, on peut voir le contenu du bus comme un ET des bits envoyés sur les sorties des composants connectés au bus. Ce détail aura son importance par la suite. Le contenu du fil peut être lu sans altérer l'état électrique du bus/fil.

Avec cette méthode, le nombre de composants que l'on peut placer sur le bus est surtout limité par les spécifications électriques du bus, notamment sa capacité. Mais cela a l'avantage que le bus est compatible avec des technologies de fabrication totalement différentes, qu'il s'agisse de composants TTL, CMOS ou autres. En effet, la tension d'alimentation des composants TTL n'est pas la même que celle des composants CMOS. Utiliser des entrées-sorties à drain ouvert fait que l'on peut choisir la tension d'alimentation que l'on veut, et donc que l'on peut choisir entre TTL et CMOS. Par contre, on ne peut pas connecter composants TTL et CMOS avec des tensions d'alimentation différentes sur un même bus.

Il est possible de mélanger sorties à drain/collecteur ouvert, avec des entrées "trois-états" (des entrées qui peuvent soit permettre une lecture du bus, soit être déconnectées). C'est par exemple le cas sur les microprocesseurs 8051.

L'arbitrage du bus

Si plusieurs composants tentent d'envoyer une donnée sur le bus en même temps : c'est un conflit d'accès au bus. Les conflits d'accès au bus surviennent sur la majeure partie des bus, qu'ils soient multiplexés ou non. Sur les bus multiplexés, qui relient plus de deux composants, cette situation est fréquente du fait du nombre de récepteurs/émetteurs potentiels. Mais cela peut aussi arriver sur certains bus dédiés, les bus half-duplex étant des exemples particuliers : il se peut que les deux composants veuillent être émetteurs en même temps, ou récepteurs en même temps.

Et de tels conflits sont censés être évités d'une manière ou d'une autre, vu qu'un bus ne permet pas plusieurs transferts simultanés dans le même sens. Les concepteurs de bus ont inventé des méthodes pour éviter ces conflits d’accès, et choisir le plus efficacement possible l’émetteur : on parle d'arbitrage du bus. L'arbitrage du bus implique qu'il faut répartir l'accès au bus pour n'avoir qu'un émetteur à la fois. On doit choisir un émetteur parmi plusieurs candidats à l'émission. Ce choix sera effectué différemment suivant le protocole du bus et son organisation, mais ce choix n’est pas gratuit. Un seul candidat sera choisit, et les autres devront attendre leur tour pour avoir accès au bus.

Les différents types d'arbitrage de bus

Il existe plusieurs méthodes d'arbitrages, qui peuvent se classer en différents types, selon leur fonctionnement. La première distingue l'arbitrage centralisé de l'arbitrage décentralisé. La seconde distingue l'arbitrage à priorité et à partage égal. Les deux catégories interagissent l'une avec l'autre, comme on le verra dans ce qui suit.

Une première classification distingue l'arbitrage à part égal de l'arbitrage à priorité. La différence est que le second donne la priorité à certains composants sur les autres, alors que l'arbitrage à part égales ne donne aucun traitement de faveur.

L'arbitrage à part égales peut se résumer en une phrase : chacun son tour ! Chaque composant a accès au bus à tour de rôle. Cette méthode fort simple convient si les différents composants ont des besoins approximativement équilibrés. Mais elle n'est pas adaptée quand certains composants effectuent beaucoup de transactions que les autres. Les composants gourmands manqueront de débit, alors que les autres monopoliseront le bus pour ne presque rien en faire.

A l'opposé, l'arbitrage à priorité donne la priorité à certains composants sur les autres. Tous les composants se voient attribuer une priorité, un nombre qui indique s'ils sont prioritaire sur les autres. Plus ce nombre est élevé, plus la priorité est importante (ou inversement). Lorsque plusieurs composants veulent accéder au bus, celui qui a la priorité la plus haute passe devant tous les autres. Certaines méthodes d'arbitrage permettent de libérer le bus de force pour laisser la place à un autre composant. On parle alors de bus mastering. L'idée est de libèrer le bus de force si un composant plus prioritaire veut utiliser le bus.

Les méthodes d'arbitrage à priorité sont nombreuses, alors qu'il n'y a pas 36 façons d'implémenter l'arbitrage à parts égales.

Les deux ne sont pas utilisés dans les mêmes circonstances. Par exemple, imaginons un bus qui relie plusieurs processeurs/cœurs identiques à la mémoire RAM. Un tel arrangement est appelé un bus mémoire partagé (sous-entendu, entre plusieurs processeurs/cœurs). L'arbitrage n'a aucun raison de prioriser un processeur sur un autre, vu qu'ils sont identiques. En conséquence, l'arbitrage à parts égales est parfaitement adapté. Pour un bus système connecté à un processeur rapide, une mémoire et des entrées-sorties lentes, il vaut mieux privilégier le processeur sur les entrées-sorties. Un arbitrage à priorité est alors utilisé.

Une seconde classification nous dit si un composant gère le bus, ou si cet arbitrage est délégué aux composants qui accèdent au bus.

Dans l'arbitrage centralisé, un circuit spécialisé s'occupe de l'arbitrage du bus.
Dans l'arbitrage distribué, chaque composant se débrouille de concert avec tous les autres pour éviter les conflits d’accès au bus : chaque composant décide seul d'émettre ou pas, suivant l'état du bus.

Notons qu'un même algorithme peut être implémenté soit de manière centralisée, soit de manière décentralisée.

Avec l'arbitrage centralisé, l'arbitrage du bus est géré par un contrôleur de bus. Il s'agit d'un circuit qui prend en charge tout ce qui a trait au bus, au minimum l'arbitrage du bus, souvent d'autres fonctions en plus. Il communique avec les composants branchés sur le bus, dans les deux sens. Il reçoit des signaux en provenance des composants connectés au bus, et leur envoie des signaux de commande. Il est typiquement soudé à la carte mère et est surtout utilisé avec des bus système ou des bus présents sur la carte mère.

Sur les premiers PC, le contrôleurs de bus et le circuit d’arbitrage étaient séparés. Il étaient dans deux circuits imprimés différents, tous deux soudés sur la carte mère. Le contrôleur de bus était un Intel 8288, alors que le circuit d'arbitrage était un 8289 d'Intel. Les deux étaient conçus pour fonctionner en tandem, mais ils étaient séparés pour des raisons de budget en transistor. De nos jours, les deux composants sont fusionnés dans le chipset de la carte mère.

L'arbitrage décentralisé est très rarement utilisé. Les exemples les plus connus sont les bus CAN et I²c, qui sont certes très utilisés. Mais la majorité des bus n'utilisent pas cet arbitrage décentralisé. La plupart des bus à arbitrage décentralisé utilisent des circuits imprimés spécifiques, qui ont des sorties à collecteur ouvert. L'arbitrage décentralisé se base sur les propriétés électriques de ce collecteur ouvert, comme on le verra plus bas. Il s'accompagne toujours d'un système de priorité.

	Arbitrage centralisé	Arbitrage décentralisé
Arbitrage à priorité	Possible, courant.	Systématique.
Arbitrage à parts égales	Possible, peu courant.	Impossible.

Dans ce qui va suivre, nous allons voir diverses méthodes d'arbitrage de bus. Nous allons surtout voir des méthodes centralisées, car elles sont nettement plus simples à comprendre. Sauf exception, elles fonctionnent toutes sur le même principe. Les composants envoient une requête au contrôleur de bus, pour demander l'accès au bus. Le contrôleur de bus analyse les requêtes et décide quel composant a l'accès exclusif au bus, à un instant donné. Le composant en question est appelé le bus master, ou maitre du bus. Pour résumer, le contrôleur de bus élit le bus master parmi une liste de candidats, qui ont demandé une requête d'accès au bus.

La sélection du bus master varie d'un bus à l'autre. Certains bus donnent l'accès à chaque candidat à part égale, d'autres ont un système de priorité où certains composants passent avant les autres.

L'arbitrage centralisé à requêtes indépendantes

L'arbitrage par requêtes indépendantes est le plus simple à comprendre, car il applique ce principe de requête et de sélection à la lettre. Chaque composant connecté au bus est connecté au contrôleur de bus, avec une liaison point à point. Chaque composant peut donc candidater pour accéder au bus indépendamment des autres. Et le contrôleur de bus lui communique sa réponse par sa propre liaison point à point.

Dans le détail, les composants sont reliés au contrôleur de bus avec deux fils, chacun transmettant un bit : un fil Request et un fil Grant. Le bit Request permet au composant d'envoyer une requête d'accès au bus : il est mis à 1 quand le composant veut accéder au bus. Il est donc connecté à une sortie du composant, mais est une entrée pour le contrôleur de bus. Le bit Grant est généré par le contrôleur de bus et est envoyé au composant élu, celui auquel il donne l'accès au bus. S'il est à 1, le composant qui reçoit ce signal se connecte au bus, les autres attendent leur tour.

Vous avez sans doute pensé à un détail : que ce se passe-t-il quand le bus est occupé ? Est-ce que les composants sont au courant que le bus est occupé ou non ? La réponse dépend du bus et de la méthode d'arbitrage, mais il y a deux grandes réponses principales. Mais en général, un fil du bus de commande précise si le bus est libre. Il s'agit du bit Busy, qui indique si le bus est libre ou occupé.

Quand un composant reçoit l'autorisation du contrôleur de bus, il met ce fil à 1, ce qui indique au contrôleur de bus que le bus est occupé. Il maintient ce fil à 1 tant qu'il utilise le bus, et le met à zéro quand il libère le bus. Le contrôleur de bus sait donc quand le bus est libre ou occupé, et décide de l'arbitrage en fonction. Pour cela, chaque composant a une sortie Busy, qui indique qu'il utilise le bus. Le fil Busy est obtenu en faisant un OU entre les sorties Busy de chaque composant. Le OU en question est réalisé soit avec une chaine de portes OU, soit avec un OU câblé.

La méthode d'arbitrage dépend du contrôleur de bus utilisé. Il est possible d'utiliser un microcontroleur comme contrôleur de bus, ce qui permet de programmer l’algorithme d'arbitrage. Mais il est aussi possible d'utiliser un circuit dédié. L'arbitrage par requêtes indépendante peut implémenter l'arbitrage à part égale, comme un arbitrage à priorité. L'arbitrage à part égale est implémenté avec un simple compteur couplé à un décodeur. Le compteur indique quel composant a accès au bus, le décodeur traduit ce nombre en signaux Grant. Le compteur est incrémenté lorsqu'un composant libère le bus.

Pour l'arbitrage à priorité, il est possible de l'implémenter avec un encodeur à priorité, dont les entrées sont connectées au signaux Request. Le résultat de l'encodeur à priorité passe dans un décodeur, ce qui donne les signaux Grant adéquats. Bien sur, il y a d'autres circuits autour, qui font en sorte que l'envoi des signaux Grant se fasse seulement quand le bus est libéré, et bien d'autres choses.

Un défaut de cette solution est qu'elle demande de câbler beaucoup de fils. Aussi, les autres méthodes procèdent autrement, afin d'économiser des fils. Les deux méthodes que nous allons voir mutualisent certains fils entre plusieurs composants. Par exemple, avec la méthode du pooling, il n'y a qu'un seul fil Request partagé entre tous les composants. Et avec la Daisy chain, cela va plus loin car tous les fils Grant sont mutualisés.

L'arbitrage centralisé par adressage

Dans la section précédente, le contrôleur de bus doit utiliser N sorties Grant pour sélectionner le composant adéquat. En contrepartie, chaque composant n'a qu'une seule entrée Grant. Une solution intermédiaire réduit le nombre de signaux Grant, au prix d'une augmentation des entrées sur chaque composant. Mais au total, le nombre de fils est grandement réduit.

L'idée est de remplacer les signaux Grant par l'adresse du composant sélectionné. Avec ce système, tous les composants ont une adresse qui permet de les sélectionner. Il est possible de configurer cette adresse pour chaque composant, à savoir que chaque composant mémorise son adresse dans un registre. Il y a un bus d'adresse séparé pour l'arbitrage, qui est commandé par le contrôleur de bus. Le contrôleur de bus envoie l'adresse du bus master sur ce bus. Les composants lisent cette adresse et détectent s'il s'agit de la leur. Si l'adresse ne lui est pas destiné, le composant sait qu'il n'y a pas accès au bus. Mais si c'est le cas, le composant sait qu'il est sélectionné et se connecte au bus.

Au final, au lieu d'avoir N fils Grant pour N composants, le bus d'adresse fait beaucoup moins. Par exemple, pour 16 composants, on passe de 16 fils à 4. Le contrôleur de bus économise donc beaucoup de broches. Mais cela se fait en ajoutant des broches sur les composants, sans compter que ceux-ci doivent mémoriser leur adresse dans un registre. Mais rien d'insurmontable, le cout en circuits est très faible.

Notons qu'un tel arbitrage se marie assez bien avec le Direct Memory Access.

L'arbitrage centralisé à daisy chain

L'arbitrage par daisy chain est un algorithme centralisé, dans lequel tout composant a une priorité fixe. Dans celui-ci, tous les composants sont reliés à un arbitre, qui dit si l'accès au bus est autorisé. Cependant, le système utilise encore moins de fils que les arbitrages précédents. L'arbitre du bus n'a qu'une seule entrée Request, et une sortie Grant. Il y a aussi un fil Busy qui indique si le bus est libre ou non.

Même si le contrôleur de bus n'a qu'une seule entrée Request, les composants ont tous une sortie Request. L'idée est que l'entrée Request du contrôleur de bus est un OU entre toutes les sorties Request. Le contrôleur de bus sait donc qu'un composant a demandé l'accès au bus, mais il ne sait pas lequel. Et la Daisy Chain fait qu'il n'a pas à le savoir. Le OU entre les sorties Request peut se faire de plusieurs manières. Soit avec une chaine de portes OU, soit avec un OU cablé. Le signal Busy est lui aussi généré de la même manière.

Le signal Grant est propagé d'un composant à l'autre, jusqu'à atteindre le premier composant à avoir demandé d'accès au bus. Pour cela, les composants sont reliés en guirlande, à savoir que chacun prend en entrée un signal Grant et fournit un second signal Grant sur une sortie du même nom. Si le composant n'a pas demandé l'accès au bus, il recopie le signal Grant en entrée sur sa sortie, sans le modifier. Mais s'il veut accéder au bus, il force sa sortie Grant à zéro : les composants suivants verront ainsi un 1 sur le fil, mais les suivants verront un zéro (interdiction d'accès). Ainsi, les composants les plus près du bus, dans l'ordre de la guirlande, seront prioritaires sur les autres.

Un composant utilise le signal Grant en entrée pour deux choses : savoir s'il a accès au bus, calculer le signal Grant en sortie. Pour ces deux opérations, le composant combine le signal Grant d'entrée avec le signal Request. Le composant a accès au bus quand : il a demandé l'accès au bus, le signal Grant lui accorde l'accès. La première condition correspond à un signal Request à 1, la seconde à un signal Grant à 1. Une vulgaire porte ET fait l'affaire. Pour générer le signal Grant en sortie, il faut établir sa table de vérité, et il s’avère qu'il s'agit d'une porte XOR entre les deux signaux.

L'arbitrage décentralisé sur les bus à collecteur ouvert

Les bus à collecteur ouvert ont un avantage pour ce qui est de l'arbitrage : ils permettent de détecter les collisions assez simplement. En effet, le contenu du bus est égal à un ET entre toutes les sorties reliées au bus. Si tous les composants veulent laisser le bus à 1 à un instant t, le bus sera à 1 : s'il y a collision, elle n'est pas grave car tous les composants envoient la même chose. Pareil s'ils veulent tous mettre le bus à 0 : le bus sera à 0 et la collision n'aura aucun impact. Par contre, si une sortie veut mettre le bus à 0 et un autre veut le laisser à 1, alors le bus sera mis à 0.

La détection des collisions est alors évidente. Les composants qui émettent quelque chose sur le bus vérifient si le bus a bien la valeur qu'ils envoient dessus. Si les deux concordent, on ne sait pas il y a collision et il y a de bonnes chances que ce ne soit pas le cas, alors on continue la transmission. Mais si un composant envoie un 1 et que le bus est à 0, cela signifie qu'un autre composant a mis le bus à 0 et qu'il y a une collision. Le composant qui a détecté la collision cesse immédiatement la transmission et laisse la place au composant qui a mis le bus à 0, il le laisse finir la transmission entamée.

Un exemple de ce genre est celui du bus CAN, très utilisé dans le domaine automobile. Lorsque le bus est libéré, les composants qui veulent accéder au bus envoient leur adresse sur le bus. La trame CAN est conçue de manière à ce que l'adresse de l'émetteur est transmise en premier. Le bus étant à collecteur ouvert, plusieurs composants pourront envoyer leur adresse sur ce bus en même temps. Tant que les bits d'adresse transmis sont identiques, il n'y a pas de collision. Par contre, le premier composant à forcer le bus à zéro gagnera la compétition et continuera à transmettre son adresse. Les autres auront perdu d'arbitrage. La conséquence est que l'arbitrage utilise l'adresse pour déterminer la priorité. Plus l'adresse d'un composant sera petite, plus il sera prioritaire sur les autres.

◄ Retour vers « Les liaisons point à point »

Sommaire du livre

Continuer vers « Quelques exemples de bus et de liaisons point à point » ►