- Notes techniques - Télécharger le plug-in Macromedia Flash -

Fonction et Paramètres d'un Bus Informatique

	Le binaire.		Dernière mise à jour 2 Mai 2005
	Adresse (bus d'). Arbitrage. Asynchrone (bus). Bande passante. Bus informatique. Chronogramme. Commande (bus de). Contrôleur de bus. Data Rate. Débit. Dédié (bus). Donnée (bus de). Fréquence de fonctionnement. Goulot d'étranglement. Hiérarchisation. Largeur d'un bus. Latence. Ligne de bus. Multiplexage. Parallèle (bus). Partage. Point-to-Point (bus). Protocole d'un bus. Séquencement. Série (bus). Synchrone (bus). Taux de transfert. Transaction.

Un bus se présente...

Bus et transport en commun de bits

Un simple conducteur de bus...

Répétons-le encore une fois: l'ordinateur "travaille" en binaire. 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 technique, ces bits se matérialisent par des tensions électriques: à une certaine tension 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 automobile électrique pour le transport en commun des voyageurs bits, dans les villes ordinateurs."

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.
Dès lors qu'un composant émetteur désire transférer des données binaires vers un composant récepteur, il "place" les bits sur le bus et laisse tranquillement faire la nature conductrice du métal jusqu'à son destinataire.
 

Bus et couloirs de bus

Bien évidemment, vous vous doutez qu'un bus est un peu plus complexe qu'un bête fil électrique, et vous avez parfaitement raison ! Effectivement, un bus est en réalité constitué de PLUSIEURS bêtes fils électriques, que l'on appelle d'ailleurs plus élégamment des lignes de bus.
Chaque ligne du bus est capable de transporter un bit à la fois, la valeur de ce bit se traduisant par le niveau de tension électrique sur cette ligne.

L'activité électrique sur une ligne de bus peut être facilement schématisée à l'aide d'un chronogramme, 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").

On appellera front montant une transition 0→1 et front descendant la transition inverse 1→0.
 

Mais au fait... Pourquoi PLUSIEURS lignes par bus ?
Parce qu'un bus ne véhicule pas QUE des données; d'autres signaux nécessaires à sa bonne marche cheminent sur des lignes particulières et organisées en véritables "sous-bus" fonctionnellement différents.
Ces (sous-) bus, les voici:
 

Bus de donnée

Bien sûr ! Puisqu'un bus sert à transmettre des données, il faut bien qu'une ou deux de ses lignes servent au transport de celles-ci !

Comme nous venons de le dire, les bits constituant l'information manipulée par l'ordinateur se déplacent généralement en bandes, le plus souvent par groupes de huit individus. Tout bus doit donc s'avérer capable d'assurer ces migrations électroniques collectives.
Et là, les stratégies divergent:
 

• Soit les bits sont convoyés les uns à la suite des autres sur une seule et même ligne; on parle alors de bus série,
   
• Soit les bits sont véhiculés simultanément sur plusieurs lignes parallèles, et on parle, ô surprise, de bus parallèle. Le nombre de ces lignes est généralement un multiple de huit et caractérise alors la largeur du bus parallèle.
   

A admirer cette animation toute en naïveté, on pourrait croire le bus parallèle naturellement plus performant que le bus série. L'intuition n'est pas fausse, mais doit être nuancée. En effet, un bus parallèle s'avère très performant sur des bus de petites distantes, mais dès lors que la longueur du bus augmente, la synchronisation des différentes lignes devient difficile à maintenir sans diminuer la fréquence de fonctionnement du bus.
Ceci explique pourquoi la transmission série reste très à la mode dans nos jolies tours blanches, surtout lorsqu'il s'agira de relier au coeur de la machine nos périphériques externes.

Bus d'adresse

Comme nous le verrons bientôt, plusieurs composants se branchent généralement sur un même bus afin de réduire les coûts de fabrication. On parle alors de bus partagé. Dans ce cas de figure, puisque plusieurs composants ont accès au même bus, tout composant émetteur doit accompagner ses données d'une adresse permettant d'identifier son destinataire.

Bien évidemment, cette adresse est une valeur binaire et donc facilement matérialisable sous forme de bits. Plus le nombre de lignes dédiées à cette adresse sera important et plus important sera le nombre d'adresses identifiables.
Pour être plus précis, n lignes d'adresses permettront d'identifier 2ⁿ adresses différentes.

Bus de commande

En sus des bits de donnée et d'adresse, d'autres bits sont également échangés sur leurs propres lignes. Ces lignes, qualifiées de lignes de commande, servent surtout de support à tous les signaux nécessaires à l'administration technique du bus.

Figurent, entre autres, dans ce bus de commande les lignes de lecture/écriture, les lignes d'arbitrage, de synchronisation, d'activation, d'alimentation...
Bref, l'intendance.
 

Profitons encore un instant de cette décidément très luxueuse animation pour vous asséner une question simple: Combien d'adresses différentes sera-t-il possible de former avec le bus ci-dessus luxueusement schématisé ?

A. 4
B. 16
C. 1111

Mais brisons là cette belle et harmonieuse théorie ! Afin de gagner en place et en coût de fabrication, les mesquins constructeurs ont tendance à vouloir limiter le nombre de lignes de leurs bus. Leur technique favorite pour y parvenir s'appelle multiplexage et consiste à utiliser les mêmes lignes afin de transmettre des signaux de nature différente.

Il existe différentes techniques de multiplexage, mais le multiplexage temporel est le plus fréquemment utilisé au niveau des bus informatiques. Dans ce cas précis, un dispositif particulier appelé multiplexeur se charge de réceptionner les différentes communications à transmettre sur le bus puis attribue à celles-ci des "fenêtres" d'occupation des lignes mises en commun.
Généralement, les cibles favorites du multiplexage temporel sont le bus de donnée et le bus d'adresse car l'un et l'autre sont censés ne pas servir simultanément lors d'un échange sur le bus.

Bus et débit de bits

La fonction essentielle d'un bus, nous l'avons compris, est la transmission de données binaires entre deux points. Sa caractéristique essentielle est donc tout naturellement son débit, également appelé bande passante (bandwidth en US-ien), qui mesure la quantité d'information pouvant y transiter par unité de temps.

Le principal usager d'un bus informatique étant le bit, vous ne serez pas étonné(e) d'apprendre que ce débit se mesure en bits par seconde (bit/s ou b/s) ou en octets par seconde voire, pour les bus plus rapides, en leurs super-unités respectives (Kb/s, Mb/s, Gb/s ou Ko/s, Mo/s, Go/s).

Bien évidemment, ce débit quantifie à lui seul l'efficacité potentielle d'un bus, mais cette valeur dépend de plusieurs paramètres qu'il peut être intéressant de passer en revue.
 

Bus parallèle et bit-étalon

Nous avons vu qu'un bus parallèle pouvait être caractérisé par sa largeur, valeur indiquant le nombre de lignes servant à la transmission des données. Celle-ci ne s'exprime bien sûr pas en centimètre, mais en nombre de bits, chaque ligne assurant le transport d'un seul bit à la fois.
Afin de satisfaire la propension du processeur à manipuler des octets, cette largeur sera bien souvent un multiple de huit.

Comme nous sommes en droit de nous y attendre, plus un bus parallèle sera large, et plus son débit sera élevé.

Ainsi, un mot de 16 bits nécessitera deux passages sur un bus de 8 bits pour être transmis, mais un seul passage sur un bus de 16 bits. De la même manière, un double mot de 32 bits nécessitera quatre passages sur un bus de 8 bits, deux passages sur un bus de 16 bits et un seul passage sur un bus de 32 bits.
Et on vous laisse vous débrouiller avec un quadruple mot de 64 bits...

Mode d'emploi d'un bus

Un transfert de donnée 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 de communications entre le composant émetteur et le composant récepteur, l'ensemble de ces échanges constituant une transaction.

Bien qu'il existe différents types de transactions possibles sur un bus, les transactions de lecture et d'écriture sont les plus fondamentales. De fait, chaque type de transaction déclenche invariablement le même enchaînement - ou plutôt séquencement - d'échanges sur le bus, l'ensemble de ces échanges provoquant inévitablement l'apparition d'un délai de latence entre la formulation d'une requête et son accomplissement effectif.

L'ensemble des séquencements correspondant à chaque type de transactions possibles constitue le protocole du bus, en quelque sorte son "mode d'emploi" complet.
 

Hélas, mille fois hélas pour nous, vis-à-vis du séquencement des transactions sur un bus, les stratégies diffèrent ici encore...

Bus synchrones

Nous venons de parler ci-dessus de "passages" afin d'évoquer le transit des bits sur le bus, mais à quoi cette notion correspond-elle très concrètement ?
Réponse: à une notion plutôt commune en informatique, à savoir une fréquence de fonctionnement.

Petit extrait de notre vieux cahier de science physique de sixième: "Une fréquence caractérise tout événement cyclique, c'est-à-dire tout événement se répétant à l'identique au cours du temps.
On appelle période l'intervalle de temps (en seconde) séparant deux occurences successives de cet événement. La fréquence, qui se mesure en hertz, n'est autre que l'inverse de cette période et quantifie donc le nombre d'événements se produisant le temps d'une seconde."
 

Au sein de l'ordinateur, cet événement cyclique est constitué par la vibration du cristal d'horloge situé sur la carte mère. Ce signal, très minutieusement répétitif, sert de métronome à tous les événements électroniques se déroulant à l'intérieur de la bête, y compris le séquencement de la plupart de ses bus, qualifiés alors de bus synchrones.

En théorie, chaque période de la fréquence cadençant un bus synchrone peut permettre un transfert de données, celui-ci survenant généralement lors du front montant du signal.
La chose à retenir ici est d'une logique implacable: plus un bus fonctionnera à une fréquence élevée, et plus son débit sera important.

Petit exercice de calcul niveau Cours Elémentaire: Quel sera le débit théorique d'un bus parallèle synchrone de 16 bits fonctionnant à une fréquence de 8 MHz ?

A. 16 Mo/s
B. 128 Mo/s
C. 128 MB/s

Bien sûr, rien ne vous choquera lorsque nous dirons que le débit théorique d'un bus parallèle synchrone se calculera par cette très simple formule:

Débit théorique du bus = Largeur du bus x Fréquence de fonctionnement

Rappelons encore une fois que ce débit calculé est un débit théorique. Il faudrait, pour qu'il soit réel, que le bus fonctionne en permamence et à plein régime, ce qui s'avère non seulement rare mais même totalement impossible de par les inévitables "temps morts" engendrés par le séquencement.

Bus asynchrones

Le bus synchrone est bel et bien un bus performant et discipliné, mais il souffre cependant de deux ou trois contraintes de taille. Ainsi:

• Plus un bus synchrone est étiré en longueur et plus le signal d'horloge met de temps pour se propager d'un bout à l'autre du bus, engendrant de gros problèmes de synchronisation;
• Le protocole de fonctionnement du bus synchrone est figée une fois pour toutes à sa conception et ne peut évoluer au gré des améliorations technologiques apportées aux composants qui lui sont connectés.

Afin de dépasser ces fâcheuses contraintes, des bus asynchrones ont très vite été mis au point. Dépourvus de tout signal d'horloge, la longueur de ces bus ne devient plus un problème tandis que débarassés de cette contrainte temporelle fixe, les composants connectés n'ont plus à "attendre leur tour" pour répondre aux sollicitations qui leur sont soumises et placent ainsi leur réponse sur le bus dès que celle-ci est prête.
Cerise sur le gâteau: deux composants travaillant à des fréquences différentes peuvent coexister sur le même bus, chacun continuant de travailler à son rythme.

Contrepartie de ce beau tableau: n'ayant plus de référence temporelle afin de synchroniser requêtes et réponses, les transactions sur ce type de bus nécessitent davantage de lignes de commande, rendant plus complexes sa conception et sa réalisation.
Autre conséquence de la disparition du séquencement temporel, le débit d'un bus asynchrone se révèle plus difficile à calculer que pour un bus synchrone.

Taux de transfert: de Hop ! à Hop, hop ! (voire plus)

Un moyen très évident afin d'augmenter le débit d'un bus serait d'augmenter la fréquence de fonctionnement de ce dernier, mais les contraintes technologiques freinant rapidement l'enthousiasme, les ingénieurs commencèrent déjà par essayer d'améliorer l'existant.

Nous venons d'apprendre il y a peu que les transferts sur un bus synchrone se déroulaient généralement lors du front montant du signal d'horloge. Il serait donc pertinent de penser qu'en exploitant à la fois le front montant ET le front descendant afin de synchroniser les échanges sur le bus, il serait possible de doubler le taux de transfert de celui-ci, c'est-à-dire la quantité de données transférées par cycle d'horloge, et ce, sans toucher à sa fréquence réelle de fonctionnement.

Le fait est que ce bus existe depuis quelques années et qu'il a pris le nom générique et charmant de bus DDR (Double Data Rate) soit, en bon français, "Double Transfert de Donnée".

Plus fort encore, à peine quelques mois plus tard, un bus QDR (Quadruple Data Rate) voyait le jour dans les labos de Monsieur Intel.

Techniquement parlant, ce bus QDR recourait à une belle filouterie technologique puisqu'au lieu d'exploiter bêtement le signal brut de l'horloge, les ingénieurs d'élite de M. Intel se débrouillèrent pour "dédoubler" celui-ci, déphasant le second signal de 90° par rapport au premier. Restait aux ingénieurs subalternes à bêtement exploiter les fronts montant et descendant de chacun de ces signaux jumeaux et hop ! hop ! hop ! hop !... Intel venait d'inventer le bus "quadpumped" !
 

Ce concept de taux de transfert assimilé, il nous est maintenant possible de compléter notre formule de calcul du débit d'un bus parallèle synchrone:

Débit théorique du bus = Largeur du bus x Fréquence de fonctionnement x Taux de transfert

Petit exercice de calcul niveau Cours Moyen: Quel sera le débit théorique d'un bus parallèle synchrone QDR de 64 bits fonctionnant à une fréquence de 100 MHz ?

A. 800 Mo/s
B. 3.200 Mo/s
C. 6.400 Mo/s

Tout ceci dit et assimilé, il nous est maintenant possible d'exprimer le délai réclamé par un transfert de données sur le bus:

Temps de transfert = Latence + (Taille de l'envoi / Débit du bus)

Cette formule, très théorique, nous permet cependant une réflexion puissante et lumineuse sur les besoins et exigences de nos bus. A savoir que:

• Dans le cas de petits transferts sur le bus, la latence est le principal facteur influençant le délai de transmission des données,
• Dans le cas de gros transferts, le débit du bus en devient le facteur essentiel.

Ainsi, selon sa localisation et la nature des composants reliés à lui, il faudra pour chaque bus trouver un compromis optimum entre latence et débit, soit, en d'autres termes, entre réactivité et capacité.

Plan du réseau

Un réseau très dense

Comment vous persuader de l'importance des bus en informatique ? Peut-être en vous précisant qu'on en trouve à tous les niveaux de l'ordinateur, depuis la souris la plus inoffensive jusqu'à la puce la plus féroce.

Ainsi, selon leur localisation au sein de l'ordinateur et, donc, selon la nature des composants qu'ils relient, on distingue:
 

• Le bus processeur, ou bus système, qui relie le processeur à la carte mère et à la mémoire du système, est le plus rapide et le plus sollicité de tous les bus de l'ordinateur;
   
• Les bus d'extension, ou bus d'entrées-sorties, qui relient la carte mère aux différents périphériques de l'ordinateur, qu'ils soient internes, sous forme de cartes, ou externes, reliés au boîtier par un câble.
  De par la grande diversité de ces périphériques, ces bus d'extension existent sous de multiples formats différents aux noms barbares: PCI, AGP, USB, Firewire, SCSI, etc.

Bref, des bus partout !

Organisation du réseau

Des lignes dédiées ou partagées

A lire tranquillement cette page, on pourrait naïvement penser qu'un bus différent relierait comme ça, bien pépère, tout couple d'éléments appelés à s'échanger des informations.
La vision ne manque pas de charme mais constatez le chantier ci-contre...

Hormis le coût exhorbitant engendré par un tel dispositif et une gestion prévisiblement calamiteuse, un autre problème ne manquerait pas de se poser: comment en effet ajouter un élément à ce réseau, devinant que chaque élément déjà connecté ne peut disposer d'un nombre infini de connexions ?

L'idée de dédier un bus tout exprès à la mise en communication de deux éléments reste possible, mais elle doit de fait être réservée à une liaison figée et exclusive, aucun autre dispositif ne pouvant s'y connecter par la suite. Ce bus hyperspécialisé prend alors le nom de bus dédié ou, à l'américaine, de bus Point-to-Point.

Le fait est qu'un ordinateur personnel est une structure "ouverte": vous pouvez en effet lui ajouter une carte son ou un modem, une carte tuner ou un scanner selon vos besoins. Dès lors, le principe du bus dédié devient impossible à conserver, sous peine d'arriver rapidement à la pétaudière ci-dessus décrite.
Heureusement, une alternative très simple à ce réseau inextricable consisterait à prévoir un bus commun sur lequel viendrait se "brancher" tout élément susceptible de communiquer avec les autres.
On parle, dans ce cas plus raisonnable, de bus partagé, sous-entendu partagé par tous les éléments s'y trouvant connectés.

Les limites du collectivisme...

Le bus partagé est certes une belle et grande idée, bien modulaire, bien économique et tout et tout, mais hélas affublé de deux très gros inconvénients:

• Partagé ou pas, une seule transaction ne peut s'établir à la fois sur un bus. Par conséquent, le débit théorique d'un bus se trouve de fait partagé entre tous les composants connectés à lui;
   
• L'accès au bus étant partagé entre différents composants, il ne faudrait pas que l'un d'entre eux ne se l'accapare de manière prolongée, sous peine de pénaliser d'autres transactions, de surcroît susceptibles d'être prioritaires.

Funeste et terrible conséquence de tout cela: si les transactions venaient à se multiplier, des goulots d'étranglement (bottlenecks) seraient susceptibles de se produire pour l'accès à notre bus.

Bon ! Pour le premier point, rien à faire, il faut se résoudre à voir le débit de notre beau bus partagé entre tous ses locataires.
Le second point, en revanche, peut servir de formidable terrain de jeux à nos neurones maintenant bien chauds !
 

Des bus à impériale ?

Bus partagé, bus partagé, d'accord ! Mais à quelle fréquence le cadencer ?
A une fréquence compatible avec les besoins de votre processeur, organe sur-sophistiqué, sur-sollicité et quasi stérile ou à une fréquence compatible avec les besoins de votre clavier, assemblage "made in China" de plastique et de poussière, tout au mieux percuté dix fois par seconde ?
Quelle que serait la fréquence de fonctionnement choisie pour notre bus, celle-ci s'avérerait bien trop lente pour satisfaire les besoins du premier, et bien trop rapide pour les besoins du second.
So ?

Heureusement, une solution très simple est envisageable: 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.
On qualifie de hiérarchisation ce dispositif de bus à étages.
 

Avec ce dispositif de bus étagés, on trouve tout en haut de la hiérarchie le plus rapide et le plus sollicité de tous, le bus processeur, qui se trouve ainsi quasiment dédié à l'interconnexion entre le processeur et la mémoire tandis que les différents périphériques de la machine se partagent le ou les bus d'extension, moins exigeants en terme de communications.

Le poinçonneur des lilas ?

Bien ! Maintenant que nous avons organisé géographiquement nos bus entre composants rapides et composants lents, il est temps désormais de s'atteler à un autre problème susceptible d'entraîner de gros bouchons sur les petites autoroutes de l'information cachées à l'intérieur de nos boîtiers métalliques, à savoir l'accès au bus.

Avec l'apparition de la notion de bus partagé, une tranchante épée de Damoclès plane au dessus des transactions susceptibles de s'y dérouler.

• Tout composant accédant de manière prolongée au bus risque de dangeureusement rallonger le temps de latence des transactions en attente;
   
• Une, voire plusieurs transactions de faible priorité sont susceptibles de bloquer l'accomplissement d'une transaction prioritaire.

Ces deux problèmes, majeurs, rendent absolument nécessaire la conception d'un dispositif de contrôle de l'accès au bus. Ce dispositif, qui serait appelé très logiquement contrôleur de bus, serait chargé de réceptionner les demandes de transactions, établir des priorités et, en fonction de celles-ci, accorder ou retarder l'accès au bus. En un mot: gérer l'arbitrage du bus.

De manière très pratique, un composant qui obtient l'accès au bus devient le temps de sa transaction le maître du bus (bus master), le composant qu'il sollicite à fin de lecture ou d'écriture étant qualifié d'esclave.

Diverses méthodes d'arbitrage sont possibles, plus ou moins complexes et plus ou moins efficaces. Il est cependant possible d'en distinguer deux grands types:

• L'arbitrage centralisé met en jeu, comme nous l'avons détaillé, un contrôleur de bus indépendant chargé de la gestion de tous les composants reliés au bus. Ce type d'arbitrage est généralement celui qui règne sur les bus système et d'extension de nos ordinateurs;
   
• L'arbitrage distribué se passe de ce composant central, chaque composant relié au bus disposant de sa propre logique d'accès au bus. Cet arbitrage "délocalisé" est caractéristique des bus de type réseau et, plus rare dans nos machines d'amateurs, au niveau du bus système en mode multiprocesseur.

Arcana Percipio est un site destiné à aider le plus grand nombre.
Pour cela, vos commentaires, vos réflexions et vos remarques sur son contenu sont indispensables à la qualité générale de ses pages. Dans la limite de l'usage malhabile de ses dix doigts, l'auteur de ce site tâchera de répondre à toute question ou remarque formulée poliment, ou alors moins poliment mais accompagnée d'un billet de valeur non négligeable.

Tous droits réservés Arcana Percipio © 2004-2005.