Alors voilà...

Vous imaginez sûrement l'intérieur de votre ordinateur comme un condensé de tout ce que l'intelligence humaine a pu produire comme trucs déments et ultraminiaturisés, un maëlstrom de bitoniaux électroniques et autres nanobidules à particules gamma.
C'est vrai qu'un ordinateur est une machine plutôt complexe composée de deux ou trois de ces machins là... Mais n'en déplaise à votre imagination exaltée, un ordinateur, c'est aussi un dédale de petites rues étroites et mal éclairées reliant entre eux tous ces composants insensés.

Mais comment ? Comment ces informations voyagent-elles ainsi au coeur de la machine ? Quelles voies empruntent-elles pour se rendre si rapidement d'un point à un autre ?
Très simple: elles prennent des busNe sourit pas comme ça bêtement, lecteur incrédule..

Mais attention ! Ce terme générique, presque trop simple, masque l'immense diversité des voies zébrant l'intérieur de votre machine. En outre, malgré ce que laisse entendre cette trop légère introduction, nous intéresser aux bus de nos machines nous contraint à aller titiller des domaines aussi hostiles que les théories du signal ou l'étude des transmissions numériques.
Autant dire que la production d'une page commun-des-mortellement bitable sur le sujet tient de la gageure, voire du suicide assisté par HTML.

Allez, courage ! Prenez un ticket...de la Nautamine aussi.
Une pleine caisse. et attachez vos ceintures. Nous allons découvrir ensemble le charme irréel des transports en commun sans odeur de sueur, ni main baladeuse, ni journée-de-mobilisation-pour-la-défense-de-l'immobilisation.

Le voyage va être long, certes, mais vous pouvez parler au chauffeur...l'hygiaphone se trouve en haut à gauche de cette page....

Un bus se présente...

Tant qu'à faire, commençons par très simplement définir ce qu'est un bus. Il sera toujours temps, ensuite, de s'attaquer à ses très nombreuses spécifications techniques.

Un bus électrique

Une fâcheuse métonymie

Voilà. Passé ce titre, nous devrions normalement être débarrassés des touristes, badauds et autres peigne-zizis. Bref, le moyen idéal pour se retrouver entre gens sérieux et courageux, prêts à suer abondamment dans tous ces bus parfaitement non-climatisés.
Le voyage risque d'être long, autant que la compagnie soit bonne...

Répétons-le encore une fois: l'ordinateur raisonne en binaire...un petit lien, juste si vous n'étiez pas au courant.... L'information, quelle que soit sa nature, consiste pour lui en de longues séries de bits généralement organisés en octets.
D'un point de vue très pratique, à l'intérieur de la machine, ces bits se matérialisent par des signaux électriques: à une certaine tension (en volt) correspond un bit de valeur "0", à une autre tension correspond un bit de valeur "1".
 

Ceci rappelé, la définition d'un bus informatique est à peu de chose près celle du Petit Bob:

BUS (nom masculin): véhicule chemin automobile électrique destiné au transport en commun des voyageurs bits, dans les villes ordinateurs.

Oui, bon, à peu de choses près quoi...

Et bien ne cherchez pas plus loin ! Un bus informatique, ce n'est que ça: un simple chemin électrique reliant entre eux des composants électroniques appelés à communiquer.
Ainsi, dès lors qu'un composant émetteur désire transférer une information vers un composant récepteur, il "place" les bits composant celle-ci sur le bus et laisse tranquillement faire la nature conductrice du métalEt oui. Pas de bus sans un excellent conducteur...
Normal. jusqu'à son destinataire.

Alors comme ça "bus = chemin" ?
Et oui. Et vous comprenez maintenant tout le sens du titre énigmatique de ce chapitre. En désignant par "bus" le chemin physique qu'empruntent les informations binaires pour se rendre d'un point à un autre, l'informaticien voulait sûrement prouver au monde que lui aussi était capable de facétie.
Il cherchait une amusante métaphore, il n'a trouvé qu'une fâcheuse métonymie.

Précisons d'emblée que, de par notre définition volontairement minimaliste du bus, il serait tout à fait légitime de qualifier de bus tout support physique de mise en communication d'ordinateurs entre eux. Néanmoins, afin qu'un page exhaustive sur ce sujet ne bouffe à elle seule tout l'espace d'hébergement dévolu au site, nous nous limiterons ici à une interprétation "intimiste" du bus et ne nous intéresserons donc qu'aux bus circonscrits à l'intérieur de l'ordinateur ou reliant celui-ci à ses périphériques...c'est-à-dire tous ces dispositifs qui viennent s'y brancher: clavier, souris, imprimante, etc..

Ligne de bus et caténaire(s)

Bien évidemment, vous vous doutez qu'un bus est un peu plus complexe qu'un bête fil électrique. D'ailleurs, le fil en question est plus élégamment appelé ligne de bus (bus wire).

Tout bus est composé d'un nombre très variable de lignesNous comprendrons pourquoi une telle hétérogéneité demain ou après-demain... - de quelques-unes à plusieurs dizaines - chacune capable de transporter un bit à la fois, la valeur de ce bit se traduisant par l'amplitude de la tension électrique sur cette ligne.

L'activité électrique sur une ligne de bus peut être facilement schématisée à l'aide d'un chronogramme (timing diagram), simple représentation graphique de la variation de la tension en fonction du temps. Ainsi, au gré de la valeur des bits véhiculés sur la ligne, la tension sur celle-ci oscillera entre une valeur haute (bit "1") et une valeur basse (bit "0").

Ce signal transmis sur le bus est qualifié par les experts de signal numérique, car sa caractéristique remarquable est de varier de manière discontinueIci, entre une tension convenue pour un bit "1" et une tension convenue pour un bit "0", sans aucune valeur intermédiaire. au cours du temps.
 

Ligne "simple caténaire"

Il faut bien le reconnaître: notre chronogramme ci-dessus est quand même un peu naïf..."Idéal" diront les diplomates.. Les tensions y sont bien trop lisses, les commutations bien trop nettes pour être honnêtes.

En effet, l'activité électrique réelle sur nos lignes de bus est loin d'être aussi propre que ne le laisse entendre notre chronogramme. Dans la pratique, divers phénomènes perturbateurs viennent déformer notre signal électrique: diaphonie (crosstalk), interférences, bruit, parasites, friture...par ordre décroissant de pouvoir épatogène......

Dès lors, une lourde menace pèse sur nos lignes: si ce bruit est trop important, et si l'écart entre les deux niveaux de tension choisis pour matérialiser les bits "0" et "1" est trop faible, des erreurs d'interprétation du signal sont fortement prévisibles.

Evidemment, les bus conçus sur ce principe de "caténaire unique", ou - plus scientifiquement - de transmission asymétrique (single-ended) sont les plus simples et les moins coûteux à fabriquer, mais ce problème de perturbations parasites reste quand même fort chagrinant...

Fort heureusement, il existe une astuce très simple à comprendre afin de minimiser l'impact du bruit sur nos lignes de bus: il suffit pour cela de doubler le trafic...procédé qui ne marche hélas pas avec les mobylettes... !

Ligne "double caténaires"

En effet, au lieu d'utiliser un seul fil entre notre émetteur et notre récepteur, doublons la ligne. Sur la première, continuons d'envoyer notre signal originel, et sur l'autre, par un habile tour de passe-passe d'électronicien, envoyons un signal complémenté.

En clair, si un bit "1" est transmis sur la première ligne, un bit "0" est simultanément transmis sur la seconde - et vice versa.

De par la proximité des deux lignes, si une perturbation survient, elle touchera celles-ci d'une manière similaire. A l'autre bout du dispositif, il suffira dès lors au récepteur de prendre en compte non plus la tension sur l'une des lignes, mais la différence de tension entre les deux lignes et le bruit sera, comme par magie...oui, bon, une simple soustraction en fait..., quasi gommé.

Sans surprise, ce type de transmission est qualifié de transmission symétrique, ou encore transmission différentielle (differential).
L'ingénieux procédé a, certes, un coût non négligeable...puisqu'il faudra ici doubler le nombre de lignes électriques du bus., mais son immense avantage est qu'il permet de concevoir des bus pour lesquels l'amplitude des deux tensions "utiles" peut être sensiblement moins élevée, écourtant le délai de commutation entre les deux niveaux et, ce qui ne gâche rien, réduisant de manière significative les interférences causées et subies par les lignes.
 

Comme quoi colporter tout et son contraire a parfois du bon...
 

Le bus idéal

Un bus, organe essentiel de communication, se caractérise - comme nous le verrons - par une foultitude de données techniques, mais son efficacité globale peut se jauger à deux simples caractéristiques élémentaires.

Débit de bits, débit de bus

Après la métonymie, l'allitération...

Puisque le seul et unique rôle d'un bus est le transport de bits, il est somme toute logique que son efficacité "brute" puisse être évaluée grâce à son débit binaire (binary throughput) qui mesure la quantité de bits pouvant y transiter par unité de temps.

Tout naturellement, ce débit, rapport d'une quantité d'information par unité de temps, se calculera en bits par seconde, ou en octets par seconde.
...ou en leurs superunités. En effet, la technologie humaine ayant fait quelques progrès ces derniers temps, le débit de nos bus s'exprime désormais plus fréquemment en Mo/s...méga-octet par seconde. Unité, rappelons-le, spécifiquement francophone et donc très mal vue auprès des élites internationales qui lui préfèrent le très consensuel MB/s (megabyte par seconde). - voire même en Go/s...giga-octet par seconde. Oui, verboten aussi....

Notons, en passant, qu'il n'est pas rare de croiser le terme de bande passante (bandwidth...mot anglais lui-même fort mal utilisé puisque correspondant à notre "largeur de bande" française...) utilisé comme synonyme de débit binaire. L'expression, quoique parfaitement mal à propos, est cependant si usuelle que nous nous devions de la mentionner sur cette page...qui, de toute façon, n'est pas un modèle de rigorisme scientifique non plus....

Fourier, Nyquist et toute la bande (passante)

De par votre nature, vous êtes une personne rigoureusement exigeante sur le sens précis des mots et vous ne supportez plus d'entendre parler de "bande passante", grandeur expressément hertzienne, pour évoquer le débit d'un bus.
Vous avez parfaitement raison.
Mais que voulez-vous, l'informaticien est un être un peu foutraque qui ne respecte vraiment rien...ce qui lui a d'ailleurs fermé au nez la porte des grandes écoles....
Une autre preuve ? Lisez cette tentative d'explication quant à la douteuse synonymie entre débit binaire et bande passante...

Joseph Fourier [1768-1830], tueur en séries.

Bon. D'abord un poil d'histoire, ça détendra tout le monde...
Au début du XIXème siècle, le mathématicien français Joseph Fourier [1768-1830] achète un ticket pour la postérité en montrant brillamment, suite à ses expériences...qui ne consistaient aucunement en l'observation de quelconques bits, mais plutôt en l'étude de la propagation de la chaleur dans un solide, le sieur Fourier étant de nature assez frileuse., que toute fonction périodique peut être décomposée en une suite de fonctions trigonométriques...un lien magistral, juste pour les grands déments qui voudraient creuser la chose... dont il va jusqu'à donner l'équation générale. Au fil des années et des génies, la théorie est consciencieusement enrichie, jusqu'à ce que - nirvana mathématique - on finisse par découvrir qu'un poil modifiée...d'où le petit nom de "transformée de Fourier" donné à la chose..., cette vérité première s'étend avec bonheur à toute fonction, même non périodique.

Heu...oui... Et mes bits ?
Mais ne voyez-vous pas, malheureux(se) ? Qu'est-ce donc qu'un transfert de bits sur nos bus si ce n'est la matérialisation d'une fonction associant à chaque instant t une tension électrique V=f(t) ? Conséquence implacable: toute activité sur nos bus peut donc être décrite comme une somme plus ou moins fastidieuse de fonctions sinusoïdales, chacune associée à une fréquence donnée dont l'ensemble constitue le spectre fréquentiel du signal. Ceci compris, on appellera largeur de bande du signal la différence entre la plus haute et la plus basse de ces fréquences...ou du moins, le spectre pouvant être infini, les extrêmes jugés significatifs de celui-ci....

Bien. Rappelons maintenant la définition orthodoxe d'une bande passante: "intervalle de fréquences pour lesquelles la réponse d'un appareil est supérieure à un minimum".
"Intervalle de fréquences". Des hertz, donc. Aucune contestation possible.
Ici, notre appareil a beau être un simple conducteur électrique, celui-ci présente lui aussi une bande passante en bonne et due forme. Par conséquent, tout signal de fréquence extérieure à cet intervalle...c'est-à-dire de fréquences inférieures ou supérieures à cette bande passante. traversant notre support sera mal voire pas du tout transmis. Or, puisque nous venons d'entrevoir que tout signal pouvait être considéré comme une sommation de signaux de fréquences variées, il est légitime de se douter que la bande passante de notre ligne de bus risque de limiter d'une manière ou d'une autre nos vélléités de transmissions binaires...

Harry Nyquist [1889-1976], chef de bande.En 1927, le physicien américano-suédois Harry Nyquist [1889-1976] explicite définitivement la chose en démontrant que la limite maximale théorique de débit binaire sur un support "idéal" est de deux fois la bande passante de ce dernier.
Quelques années plus tard, deux collègues du nom de Ralph Hartley [1888-1970] puis Claude Shannon [1916-2001] reformulent la relation, mais en tenant compte cette fois de l'inévitable "bruit de fond" parcourant tout support de transmission. La conclusion de leur théorème démontre que, en pratique, le débit binaire maximal réel sur un tel support est finalement assez voisin...pour les tâtillon(ne)s que l'adverbe "assez" indisposeraient, la formule exacte:

Débit_max = BP.log₂(1 + S/B)
...avec S/B: rapport signal / bruit de la ligne. de la bande passante de ce dernier.

Et voilà l'informaticien a demi-pardonné...

Temps d'attente

A vrai dire, le débit binaire du bus pourrait sembler suffire à déterminer son efficacité globale. Oui mais voilà, nous verrons qu'un bus est peut-être un peu plus complexe qu'un "simple" chemin électrique et que son utilisation par un composant implique une cascade d'événements électroniques insoupçonnés.

Pour faire très simple...pour le moment., lorsqu'un composant A utilise le bus auquel il est connecté, c'est pour une transmettre une requête à un composant B également relié sur ce même bus. Or, de par le fonctionnement interne du bus...et en particulier une phase amusante que nous verrons ensemble: la phase d'arbitrage du bus., entre l'instant où un composant désire émettre une requête à destination d'un autre composant et l'instant où cette requête est effectivement satisfaite peut s'écouler un certain temps.
Ce délai moyen constitue la latence (latency) du bus.

C'est ainsi, un bus peut très bien luxueusement accueillir 200 personnes mais se faire péniblement attendre aux arrêts...

Vous vous doutez que le bus idéal conjuguerait à la fois débit maximal et latence minimale. Oui mais concilier ces deux impératifs revient à multiplier les prouesses technologiques.
Or, nous verrons que de telles performances n'ont parfois simplement pas lieu d'être...

Voies de circulation

Un bus a beau être un simple chemin électrique, toute voie de circulation, si simple soit-elle, peut néanmoins faire l'objet de quelques questions marquées au coin du bon sens...

Sens unique ou double sens ?

Dans le domaine général des transmissions, quel que soit d'ailleurs leur support...qu'il soit électrique, optique, hertzien ou par signaux de fumée..., il est d'usage de classer en trois catégories distinctes les liaisons entre éléments appelés à communiquer selon le ou les sens possible(s) de leurs échanges.
Ainsi:

• Lorsque les échanges peuvent avoir avoir lieu dans un seul sens, toujours identique, on parle de liaison de type simplex. Dans ce cas fort simple, l'un des éléments est émetteur, l'autre simple récepteur.
• Au contraire, lorsque les échanges peuvent avoir lieu simultanément dans les deux sens, on parle de liaison de type full duplex. Ici, chacun des éléments peut donc être à la fois et en même temps émetteur et récepteur.
• A mi-chemin entre ces deux extrêmes, on parle de liaison half duplex quand les échanges peuvent avoir lieu alternativement dans les deux sens. Dans ce cas, à un instant donné, l'un des éléments est émetteur, l'autre récepteur - les rôles pouvant s'inverser par la suite...à l'image des talkies-walkies de notre enfance....
   

Il y a, à ce stade, une subtilité qu'il nous faut bien comprendre: le type de transmission (simplex, half-duplex ou full-duplex) caractérise moins le support de transmission en tant que tel que la manière de communiquer des éléments qui y sont reliés. En d'autres termes, tout bus, puisque simple...mmmmouais... chemin électrique, peut parfaitement servir de support à une transmission de type full-duplex dès lors que les composants qui lui sont raccordés sont aptes à émettre et recevoir simultanément. Il y a cependant des situations où cette bidirectionnalité n'a simplement pas lieu d'être, comme par exemple la liaison entre l'unité centrale et le moniteur...qui, à moins d'être un écran tactile, n'envoie jamais aucune donnée à l'unité centrale, mais en reçoit quasi continûment. ou la souris...qui, elle, ne reçoit aucune donnée depuis l'unité centrale mais se contente d'en émettre à intervales réguliers.. Les bus mis en jeu dans de tels contextes peuvent donc parfaitement jouer leur rôle en mode simplex.

Pour reprendre la métaphore un peu niaise du chemin, une rue peut être en sens unique alors que sa largeur pourrait tout à fait permettre le croisement de deux véhicules. C'est le plan de circulation plutôt que les caractéristiques de la rue qui détermine la manière dont celle-ci sera finalement empruntée.

Chemin privé ou voie publique ?

Un bus est donc un chemin électrique reliant des composants appelés à communiquer en binaire. Bouleversant de simplicité.
Bon, c'est fini ?
Une petite question quand même, sur le pouce:

Non, vraiment, ne serait-il pas possible d'envisager une vision un peu plus... communiste des choses ?

Si. De manière très facile à comprendre, on peut différencier deux grands types de bus selon le nombre de composants qui s'y trouvent reliés:

• Si le bus est entièrement dédié à la mise en communication de deux composants, on parle alors de bus, ou plutôt de liaison point-à-point (point-to-point link)
• Si un même bus est partagé entre plus de deux composants, on parle dans ce cas de bus multipoint (multipoint bus).
   

Bus multipoint

La philosophie du bus multipoint est simple: tous les composants connectés au bus ont accès aux informations véhiculées sur celui-ci, mais un seul émetteur est autorisé à la fois. En d'autres termes, dès lors qu'une transmission est en cours sur le bus, les autres composants ne peuvent y intervenir jusqu'à ce que celle-ci ne s'achève.
Conséquence inéluctable: le débit total du bus se trouve de fait partagé entre tous les composants qui y sont connectés.

Le concept de bus partagé a néanmoins cet avantage essentiel qu'est la souplesse d'utilisation (versatility). En effet, au fur et à mesure des besoins, il devient tout à fait possible de "brancher" de nouveaux périphériques sur le bus commun, sans avoir à réarranger les composants déjà en place - atout considérable pour une informatique faisant la part de plus en plus belle aux périphériques "plug and play "...mot-à-mot: "branche et utilise". Un concept résolûment révolutionnaire dans un domaine (l'informatique) où très longtemps, la règle était plutôt "Plug and pray"....

Tout naturellement, un bus multipoint se caractérisera également par le nombre maximal de composants pouvant s'y connecter.

Liaison point-à-point

Le très grand avantage de la liaison point-à-point n'est pas une surprise: dédiée à la seule interconnexion de deux composants, la totalité du débit binaire potentiel de la liaison est entièrement dévolue aux transmissions entre ces derniers.
La contrepartie est non moins évidente: la modularité de l'ensemble est réduite à néant, l'ajout d'un composant au duo déjà formé obligeant à créer deux nouvelles liaisons point-à-point entre le nouveau et les anciens éléments.
...à moins de recourir à un dispositif intermédiaire appelé switch, dont le rôle serait d'interconnecter entre elles différentes liaisons point-à-point, sur le principe vieux comme le monde du schéma dit "en étoile".
 

Oui, vous avez raison , une liaison point-à-point n'a plus grand chose à voir avec un moyen de transport "en commun", d'où une légitime réticence à considérer ce type d'interconnexion comme un bus stricto sensu.
Difficile néanmoins de passer outre ce bus particulier de par son succès grandissant dans nos ordinateurs à la mode.

Le grand avantage de cette configuration est que chaque liaison entre composants et switch peut elle-même être formée de plusieurs interconnexions juxtaposées, décuplant d'autant le débit potentiel entre ces derniers. Une solution a priori performante et évolutive, donc, et par conséquent promise à un certain succès...

Nature du trafic

Un bus convoie des bits, ça nous le savons. Mais il y a bit... et bit.

Une vision simpliste des choses consisterait à imaginer un bus comme un simple moyen de permettre à plusieurs composants d'échanger entre eux des informations binaires. C'est oublier que le bus est une structure partagée, et que cet état de fait implique que, outre les bits constituant l'information proprement dite, des bits supplémentaires doivent nécessairement être échangés entre interlocuteurs afin de rendre possibles leurs échanges.

Plus précisément, il est possible de distinguer trois différents types de bits usagers sur un bus:

• les bits de donnée - les plus évidents - constituent l'information proprement dite;
• les bits d'adresse, permettent d'identifier le destinataire réel des informations transmises, plusieurs composants se trouvant connectés au bus;
• les bits de contrôle, véritables "bits administratifs" nécessaires à l'intendance générale du bus regroupent, entre autres, signaux de synchronisation, d'alimentation, d'arbitrage...termes abscons, pour quelques minutes encore..., etc.

Voie ferrée ou autoroute ?

Ainsi donc, dès lors qu'un composant s'adresse à un autre composant sur le bus, de nombreux bits sont échangés entre les deux interlocuteurs.
Mais là, les avis divergent depuis l'invention de la route sur le meilleur moyen de procéder:

• Soit les bits sont convoyés les uns à la suite des autres sur une seule et même ligne...vieille technique indienne également familièrement baptisée "au bit leu leu"...; on parle alors de bus série (serial bus),
• Soit les bits sont véhiculés simultanément sur plusieurs lignes parallèles...principe repris avec un certain lucre par SANEF, COFIROUTE et autres nouveaux bandits de grands chemins., et on parle alors, ô surprise, de bus parallèle (parallel bus).

Voici donc expliquée la si grande variabilité du nombre de lignes sur nos différents bus.
 

 
A bien étudier cette animation décidément fort naïve, il serait somme toute légitime de considérer le bus parallèle naturellement plus performant que le bus série. Or, il semble que les derniers bus à la mode exploitent préférentiellement ces derniers. Voici donc matière à creuser quelque peu le sujet.

Bus parallèle

Rien de plus délicieux pour le néophyte qu'un bus parallèle: tout y est si clair, si visiblement explicite...

Comme nous l'avons vu il y a peu, tout accès au bus entraîne un échange de signaux entre composants interlocuteurs: signaux de donnée, signaux d'adresse, signaux de contrôle. Un bus parallèle a pour philosophie d'assigner une ligne dédiée (dedicated line) à chacun de ces signaux.

De fait, un bus parallèle se trouve donc composé d'un grand nombre de lignes, chacune assignée à un rôle bien déterminé. Le nombre de lignes dédiées aux signaux de donnée constitue la largeur (width) du bus parallèle. Bien évidemment, cette largeur ne s'exprimera pas en centimètre, mais en un simple nombre généralement - devinez-quoi - multiple de huit.
Comme vous vous en doutez, plus un bus parallèle sera large, et plus son débit potentiel sera important.

Ceci dit, on comprend moins encore le succès grandissant des bus de type série, puisqu'on pourrait imaginer accroître à l'envi la largeur de nos bus parallèle pour gagner mathématiquement en débit.
C'est que le bus parallèle souffre, hélas, de quelques tares regrettables dues à sa structure même:

Co-voiturage économique

Dans le but de pallier aux deux premiers ci-contre inconvénients, la tentation est grande pour les constructeurs de recourir au principe de la ligne multiplexée (multiplexed line). Celui-ci consiste à utiliser une même ligne pour transmettre des signaux de nature différente.
Dans le cas du bus parallèle, le multiplexage employé est de type temporel, les signaux étant transmis à tour de rôle sur la même ligne.
Cette technique, qui met en jeu des circuits logiques appelés multiplexeur...attendez-vous à quelques petits schémas électroniques quand même..., est très largement utilisée car très économique d'un point de vue espace et coût de fabrication, mais en contrepartie d'une baisse significative des performances puisque les lignes multiplexées, ainsi assignées à plusieurs fonctions, voient leur débit potentiel partagé en conséquence, sans compter le temps perdu par le bus à gérer les différentes commutations.

• D'un point de vue purement physique, un bus parallèle se révèle assez encombrant...défaut majeur quand on connaît le prix du m² sur une carte électronique...;
• D'un point de vue strictement économique, un bus parallèle est plus coûteux que son homologue série;
• D'un point de vue technologique, un bus parallèle se montre délicat à fabriquer, la longueur et l'intégrité de ses différentes lignes devant être très rigoureusement identiques afin d'éviter la désynchronisation des signaux qui les parcourent;
• D'un point de vue électronique, la concentration de nombreuses lignes parallèles dans un petit espace favorise la survenue d'interférences électromagnétiques susceptibles de perturber l'intégrité des signaux.

Toutes ces raisons concourrent à ce qu'un bus parallèle se révèlera surtout compétitif sur de petites distances, de l'ordre de quelques centimètres.

Bus série

Rien de plus délicieux pour le néophyte qu'un bus série: tout y est si clair, si visiblement dépouillé...

Vous l'aurez compris, le bus de type série prend le contrepied parfait de son homologue parallèle en ne mettant en jeu qu'une seule ligne de transmission pour tous les signaux...ou deux, bien sûr, si le bus est à transmission différentielle..., quelle que soit leur nature.

Les avantages du bus série sur le bus parallèle sont nombreux puisqu'il corrige l'ensemble des défaut recensés chez ce dernier: espace minimal, coût de fabrication moindre, quasi-immunité aux déphasages du signal, faible génération de perturbations diaphoniques.

Evidemment, le bus série n'est pas exempt de certains reproches dûs à sa nature. Le principal est que la fabrication (au départ) et l'analyse (à l'arrivée) de ces "paquets" de signaux nécessite des circuits électroniques supplémentaires, tant au niveau des composants émetteurs qu'au niveau des composants récepteurs.

Ces étapes supplémentaires de traitement des signaux s'ajoutent à ce constat a priori évident: comment le débit binaire d'un bus série - assuré par une seule ligne, donc - peut-il rivaliser avec le débit d'un bus constitué de N lignes parallèles  ?
La réponse est non moins évidente: en transmettant les bits au moins N fois plus rapidement !
...ce que permet un bus série en s'affranchissant des contraintes liées aux désynchronisations inter-lignes du bus parallèle.

Evidemment, être synchro tout seul, c'est tout de suite beaucoup plus simple...

Règles de conduite d'un bus

Cette page s'éternisant de manière dramatique, il semblerait bien que nos bus, si "simples...j'en vois qui commencent à douter..." chemins électriques soient-ils, s'avèrent finalement plutôt délicats à emprunter...

Un bus a une fonction fort simple: la mise en communication de plusieurs composants. Mais ce rôle médiateur implique que certaines règles soient clairement définies et partagées entre ces derniers. L'ensemble de ces règles constitue le protocole du bus (bus protocol), comme le définit fort bien, ici aussi, notre Petit Bob de référence:

PROTOCOLE (nom masculin): recueil de règles à observer en matière d'étiquette, de préséances, dans les relations officielles.

...contentons-nous simplement d'ajouter: "entre composants interconnectés à un même bus", et la définition sera parfaite.

Bon. Tant que nous y sommes, passons en revue quelques-unes de ces règles du code de la ligne.

Priorités adroites

Structure par nature partagée entre plusieurs composants, le premier souci d'un bus est d'éviter la cacophonie entropique ou, en termes clairs, que tout le monde "parle en même temps". Ce souci fort légitime rend indispensable la conception d'un dispositif de contrôle de l'accès au bus, qui soit chargé d'assurer l'arbitrage (arbitration) des différentes demandes d'accès au bus.

Une fois qu'un composant a obtenu l'accès au bus, il devient maître du bus (bus master) le temps de sa requête; il contacte alors son interlocuteur, dès lors réduit au rôle d'esclave (slave) et procède à l'échange d'information prévu.

En théorie, un arbitrage idéal se devrait d'être tout à la fois:

• Hiérarchisé. Certains composants se révélant fonctionnellement plus exigeants que d'autres en terme d'accès au bus, il serait judicieux de pouvoir accorder des niveaux de priorités aux différents composants reliés au bus.
• Juste. Les composants prioritaires ne devraient pas pouvoir accaparer le bus et empêcher toute intervention des composants moins prioritaires sur le bus.
• Fiable. Le contrôleur de bus devrait pouvoir isoler un composant éventuellement défectueux ou déconnecté du bus et poursuivre correctement sa tâche.
• Prompt. La phase d'arbitrage de l'accès au bus ne devrait pas trop pénaliser la fluidité des échanges et, par conséquent, augmenter trop sensiblement la latence du bus.

Différentes techniques d'arbitrage existent, plus ou moins conformes à ce cahier des charges idéal. Elles se déclinent en deux catégories: arbitrage centralisé (centralized) ou arbitrage distribué (decentralized) selon que la gestion des requêtes est assurée par un dispositif matériel particulier - dès lors appelé contrôleur de bus (bus controler) - ou déléguée à chacun des composants par le biais de lignes de contrôle dévolues à cette tâche.
 

Type d'arbitrage	Principes généraux	Avantages et inconvénients
Centralisé par scrutation (polling)	Le contrôleur de bus attribue à tour de rôle à chaque composant un droit d'accès au bus, que celui-ci ait émis une requête ou pas.	Simplicité de conception Aucune prise en compte des priorités
Centralisé par chaînage (daisy chain...littéralement "guirlande de pâquerettes" ou plutôt, dans ce contexte totalement dénué de poésie, "connexion en boucle"...)	Chaque composant du bus est relié au contrôleur par une ligne requête (request), une ligne autorisation (grant) et, éventuellement, une ligne d'occupation (busy). Le composant désirant accéder au bus active la ligne request. Le contrôleur central identifie le demandeur via la ligne grant en débutant sa recherche par le composant le plus prioritaire. Si celui-ci est le composant requérant, il prend le contrôle du bus. Sinon, il transmet l'autorisation au composant suivant dans la chaîne de priorité. [voir animation]	Prise en compte des priorités Assignation physique des priorités (la place du composant sur le bus détermine son niveau de priorité) Equilibre délicat à trouver entre hiérarchie...envers les composants prioritaires. et justice...envers les composants les moins prioritaires..
Centralisé parallèle	Ici, chaque composant possède ses propres lignes request et grant le reliant directement au contrôleur. Celui-ci centralise les différentes requêtes, établit les priorités selon un algorithme qui lui est propre, et accorde directement l'accès au bus aux composants demandeurs, qui activent la ligne busy le temps de l'accomplissement de leur requête.	Prise en compte des priorités Priorités indépendantes de l'assignation physique Multiplication des lignes de contrôle
Distribué par chaînage	Ici, la tâche du contrôleur de bus est déléguée à chaque composant, chaîné au suivant par la ligne grant. Le composant désirant accéder au bus interrompt ce chaînage et, si la ligne d'occupation est libre, prend contrôle du bus. [voir animation]	Prise en compte des priorités Simplicité du câblage Chaque composant doit disposer du circuit d'arbitrage

Bien ! Maintenant que nous avons notre maître et notre esclave, ça va cravacher...
 

Titres de transport

Comme nous l'avons déjà laissé entendre, le transfert de données sur un bus n'est pas une opération "ponctuelle" dans le sens où ce transfert n'est en réalité que la dernière étape d'une succession ultra-codifiée d'échanges de signaux entre le composant maître du bus et son esclave.
L'ensemble de ces échanges impliqués par une requête sur le bus constitue ce qu'on appelle une transaction (transaction).

Le protocole d'un bus définit précisément les différents types de transactions autorisées sur ses lignes. Les transactions de lecture (read) et d'écriture (write) sont bien évidemment les plus fondamentales mais d'autres peuvent également être prévues, comme des transactions combinées...comme par exemple "lecture-modification-écriture" ou encore "lecture-après-écriture"..., ou, très performantes lorsque le volume de données à échanger est important, des transactions de transfert par blocs (block transfer) plus connues sous la belliqueuse expression de mode rafale (burst mode).

Le protocole du bus a charge de définir, pour chacun des types de transactions prévues sur le bus, le séquencement des échanges entre le maître et son esclave.

Et là, pour changer, les avis divergent sur la meilleure façon de procéder...

Bus ou navette ?

Vous n'imaginez pas les trésors d'intelligence que nécessite la tenue d'une simple conversation entre personnes civilisées: politesse dans les présentations, sens de l'écoute et de la répartie, pertinence, psychologie, finesse... bref, tout ce dont est incapable un composant électronique.

Et oui, ce qui semble si naturel à l'être humain constitue de fait le principal souci d'un composant relié à un bus qui s'avère infoutu, malgré les trésors de technologie dont il est truffé, de répondre à cette double mais basiquissime question: "Quand parle-je ? Quand reponds-je ?"

Protocole de type synchrone: Bus tops

Sur un bus synchrone (synchronous bus), tous les échanges sont déclenchés par un "top" délivré par un signal périodique partagé par tous les composants interconnectés.
Dans un ordinateur, ce rôle de métronome ultra-précis est dévolu à l'horloge (clock) du système. Ce signal d'horloge peut être utilisé tel quel mais peut aussi être multiplié ou divisé afin d'obtenir un signal respectivement plus rapide...comme c'est le cas au niveau du bus processeur (nous y viendrons)... ou plus lent...comme c'est le cas au niveau des bus d'extension (nous y viendrons aussi)... qui détermine alors la fréquence de fonctionnement du bus (bus frequency).

Sur un bus de type synchrone, ce signal d'horloge a deux rôles essentiels:

• Tous les composants reliés au bus se servent de ce signal pour connaître le moment précis où ils doivent vérifier l'état des différentes lignes de contrôle du bus. Généralement, ce moment précis correspond au front montant du signal d'horloge;
• Chaque type de transaction réclame un nombre déterminé de cycles d'horloge, généralement un seul dans le cas de transactions simples (lecture ou écriture).

Bon, d'accord... Essayons d'être un moins académique et beaucoup plus explicite.
Imaginons un composant quelconque désirant effectuer une transaction en lecture sur un bus de type parallèle. Celui-ci place les bits de l'adresse désirée sur les lignes d'adresse et active le signal de lecture sur une des lignes de contrôle du bus. Rien ne se passe jusqu'au prochain front montant du signal d'horloge. Ce n'est qu'à cet instant, en inspectant les lignes de contrôle du bus, que les autres composants liés au bus - et plus particulièrement le composant concerné par la requête - prennent effectivement connaissance de la requête.
Une fois sa requête transmise, le composant maître ne se soucie aucunement des états d'âme du composant chargé de lui répondre. Après un nombre de cycles d'horloge expressément défini par le protocole, le composant maître va docilement lire les lignes de donnée du bus. Normalement, si tout fonctionne comme sur des roulettes, le composant esclave les a mis à jour entretemps avec la donnée réclamée.
 

Un bus de type synchrone est fort simple à concevoir, mais il souffre d'un très lourd handicap: sa rigidité. En effet, tous les composants reliés à un tel bus doivent être à même de pouvoir satisfaire toute transaction dans le nombre de cycles d'horloge fixé par le protocole; c'est une exigence minimale. Mais si l'un de ces composants se révèle plus performant que ce minimum requis, il ne peut être exploité à sa pleine puissance, puisque contraint d'obéir aux contraintes temporelles fixées par le protocole.

Il existe un moyen simple de contourner ce problème: il suffit pour cela d'ajouter une ligne de contrôle au bus. Lorsque le composant esclave reçoit une requête, il active cette ligne d'attente et ne l'inactive que lorsqu'il a effectivement achevé la requête demandée. Au prochain front montant du signal d'horloge, le composant maître sait alors que sa requête est satisfaite et qu'il peut lire les données valides sur le bus.

Un tel bus, plus tout à fait synchrone, est alors qualifié de bus semi-synchrone (semi-synchronous) puisque un ou plusieurs cycles d'attente (wait states) peuvent s'écouler entre la formulation d'une requête et sa réalisation effective, mais en contrepartie, des composants de performances sensiblement différentes peuvent désormais partager le même bus, sans que les composants les plus lents n'entravent les composants les plus rapides.

C'est en effet le bon côté du bus parallèle de type synchrone: on peut très facilement calculer son débit maximal théorique par la formule simple:

DMT = Fréquence de fonctionnement x Largeur

...en n'oubliant surtout pas de multiplier par deux cette valeur pour un bus de type DDR, et par quatre pour un bus de type QDR.

Protocole de type asynchrone: Bus tope

Aucune surprise lorsque vous apprendrez que l'alternative au bus de type synchrone est le bus asynchrone (asynchronous bus). Comme son nom l'indique, aucune horloge sur un tel bus pour cadencer les échanges entre ses hôtes. Dès lors privés de cette référence temporelle, ceux-ci doivent s'entendre directement entre eux afin de procéder à tout contact sur le bus.

Comme au bistrot, la meilleure façon de procéder afin de lancer une conversation reste encore la franche poignée de main (handshake) sauf que dans le cas d'un bus, c'est moins une poignée de main que l'on s'échange qu'une poignée de bits, deux pour être précis, et sur deux lignes de contrôle supplémentaires: une ligne "requête" (request) et une ligne "accusé de réception" (acknowledgment).

Dès que le maître a validé sa requête sur les lignes d'adresse et, éventuellement...pour une transaction en écriture., de donnée, il active la ligne request afin de signifier à l'esclave sa demande. Celui-ci en prend connaissance, s'exécute, puis une fois la requête effectivement satisfaite, active à son tour la ligne ackowledgment afin d'avertir le maître que tout est prêt et qu'il peut venir glaner sur le bus les informations désirées.

Comme nous le voyons, le bus de type asynchrone ne repose plus du tout sur un quelconque principe de temporalité, mais bel et bien sur un principe de "cause à effet", tout signal sur le bus étant à la fois la conséquence d'un signal précédent et la cause du signal suivant.
Un bus de type "réaction en chaîne", en quelque sorte.

A l'opposé du bus synchrone, l'immense avantage du bus asynchrone est sa souplesse, des composants de rapidités très variables pouvant partager le même bus sans que les plus lents n'handicapent les plus rapides. En contrepartie, un tel bus s'avère plus délicat à concevoir, de par les lignes de contrôle supplémentaires que son fonctionnement implique.
Autre conséquence accessoire: le débit d'un bus asynchrone n'est plus du tout aussi simple à calculer...
 

Il fait maintenant évoquer un gros défaut inhérent au bus de type asynchrone: tout événement étant déclenché par la survenue d'un événement précédent, un composant particulièrement lent peut dangeureusement augmenter la latence du bus, des transactions étant susceptibles de devoir patienter que la transaction précédente veuille bien s'achever.
Le bus asynchrone à transaction fractionnée (split-cycle), ou encore entrelacée, est une astucieuse réponse à cette terrible menace.

Sur un tel bus, le composant maître n'attend plus que son esclave lui transmette l'information souhaitée; il adresse sa requête, puis libère immédiatement le bus, de telle manière que d'autres transactions puissent éventuellement s'y dérouler. Une fois terminée sa besogne, le composant esclave réclame à son tour le contrôle du bus...et en devient donc le maître... et adresse alors les données désirées à l'ancien composant maître, entretemps devenu esclave.

Comme toujours, ce processus élaboré à une contrepartie technique: tout composant esclave étant susceptible de devenir maître, chacun d'entre eux doit disposer des circuits inhérents à la prise de contrôle du bus, enchérissant en conséquence cette solution néanmoins fort judicieuse.

Bon ! Tout cela est très bien, très passionnant et tout et tout... Mais A S S E Z !
Assez de considérations techniques et autres théories logistico-électroniques ! La mal des transports a vaincu, la nausée monte...
Nous voulons du PRA-TI-QUE, du concret, le plan du réseau, les horaires et le prix du ticket.
Pitié...

Une tour en bus

Bus à impériale

Comme nous l'évoquions dans l'introduction de cette page, un ordinateur est un atelier hétéroclite où les composants les plus high-techs, tels un processeur ou une carte graphique, côtoient des dispositifs aussi frustres qu'une souris à molette ou un lance-misile en mousseGros succès commercial au siège du parti en phase de préparation du prochain congrès.... Or, inutile de dire que tous ce petit monde n'a pas les mêmes exigences en terme de communicabilité...

En effet, comment faire cohabiter sur un même bus un processeur, organe central hypercommunicant...pensez: plusieurs millions de sollicitations à la mémoire chaque seconde... et quasi stérile avec votre clavier, assemblage de plastique et de poussièresSi, si. La preuve: retournez, secouez, aspirez..., tout au mieux percuté cinq fois par seconde ?Sans compter que l'un est fabriqué à Taiwan, l'autre en Chine...

La solution est somme toute évidente: elle consiste à regrouper sur un même bus "haute performance" les éléments les plus rapides et les plus sollicités de l'ordinateur, et reléguer les composants plus frustres ou moins exigeants sur un bus plus pépère relié au précédent par un pont (bridge).
Des bus à plusieurs étages, donc. Il fallait y penser.
 

Promis, c'était là le dernier schéma théorique de cette page...
 

Plan du réseau

Et immédiatement, pour preuve de notre bonne foi, le schéma de l'architecture d'un ordinateur tout ce qu'il y a de plus réel:
 

 
Ce schéma, quoique fort simplifié, va néanmoins nous permettre d'en apprendre de belles sur les bus parcourant nos belles tours blanches et, enfin ! de mettre en pratique nos rutilantes connaissances théoriques sur le sujet.

Les grandes lignes

Première constatation très rapide: la carte mère (chipset) apparaît ici comme une véritable station terminus, tous nos bus venant s'y connecter d'une manière ou d'une autre.
Ceci dit, passons en revue les grandes lignes du réseau ci-dessus illustré:

• Le bus système (system bus) regroupe sous un même terme générique les deux bus les plus rapides de l'ordinateur, à savoir:
• Le bus processeur, également appelé bus frontal (front side bus), qui, comme son nom l'indique, relie le processeur à la carte mère. Ce bus est le plus sollicité de toute la machine, puisqu'y transitent toutes les informations en provenance et à destination du processeur.
• Le bus mémoire (memory bus), qui unit la mémoire vive (RAM) à la carte mère.
• Le bus graphique (graphics bus) relie, lui, la carte graphique à la carte mère. Les applications étant toujours plus exigeantes en termes de graphismes, ce bus voit son débit progresser continûment depuis plusieurs années.

Conformément à nos théories impériales, on remarquera que ces bus les plus rapides se connectent tous trois au même niveau de la carte mère, sur une structure électronique appelé puce northbridge.

Plus bas sur la carte mère, la puce southbridge est le terminus du bus d'extension, également appelé bus d'entrées / sorties (I/O bus) sur lequel viennent se connecter tous les périphériques qui nous sont familiers. Attention toutefois, l'expression pourrait nous faire penser qu'il s'agit là d'un seul très long bus, mais en réalité, ce bus se subdivise lui-même en plusieurs "sous-bus" bien différenciés, comme nous le verrons pour terminer.

Lignes intra-muros et périphériques

A côté de cette nomenclature très géographique des différents bus de la machine, on pourrait en proposer une autre, beaucoup moins académique mais furieusement plus pragmatique, celle qui distinguerait les différents bus de nos ordinateurs selon la réponse à cette question presque bête: "Comment monter dans ce bus là: avec ou sans tournevis ?".

En effet, on peut constater sur le schéma que tous les composants de l'ordinateur ne se branchent pas de la même façon sur leur bus.

• ...des connecteurs de toutes les couleurs...A l'intérieur de la machine, la plupart des connexions aux bus se font par l'intermédiaire de connecteurs (slots), sortes d'encoches mi-plastique mi-métal sur lesquelles viennent s'enficher les composants sous forme de cartes électroniques. Les bus liés à ces encoches portent le délicieux nom de bus de fond de panier...et certains de ces bus sont pourtant de tout premier choix... (backplane bus). Bien évidemment, ces slots sont inaccessibles à moins de dévisser le boîtier de l'unité centrale, ce qui en interdit pratiquement l'accès au commun des mortels...ceux qui considèrent leur belle tour comme un sanctuaire inviolable... ou un sanctuaire sous garantie....
• Fort heureusement, inutile d'ouvrir la bête afin de connecter la multitude de périphériques dont s'entourent nos machines. En effet, tous ces derniers se connectent au bus d'extension par l'intermédiaire de simples prises - ou ports - situées à l'arrière de l'unité centrale voire, luxe suprême, en façade.

Les grands modèles de bus

Voici enfin pour terminer le moment de mettre des noms sur tous ces bus dont nous connaissons maintenant tous les secrets.
Pas trop tôt... Le voyage commençait à devenir franchement pénible...
 

Enfin bref...

"Simple" chemin électrique, n'est-ce-pas ?

Oui, bon, l'épithète n'était peut-être pas le plus judicieux...

Mais avant de vous plaindre, rendez-vous compte ! Vous avez désormais toutes les clefs afin de comprendre, analyser, jauger, tous les bus présents dans votre ordinateur, depuis la souris la plus inoffensive jusqu'à la puce la plus féroce.

Un jour, c'est sûr, vous nous remercierez...
Pas plus tard peut-être que lors de votre prochain achat hardware...