1 LE BUS PCI 4 ième partie: L ’arbitrage Sommaire - Repère zQuatrième partie:L ’Arbitrage yPrincipes généraux yPrise du bus yChronogrammes ySynthèse yRetour sur les fins de transaction Cours_bus_PCI_3_02

2 LE BUS PCI 4 ième partie: L ’Arbitrage Principes généraux zLa phase d ’arbitrage pour le transfert (n) est généralement masquée par la fin du transfert (n-1) Turn around Maître demande bus Maître envoie adresse et commande Cible décode adresse et commande Écriture Lecture Envoi données Envoi données Envoi données Fin du cycle (n-1) Début du cycle n

3 LE BUS PCI 4 ième partie: L ’Arbitrage Principes généraux zArbitre yCentralisé xReçoit tous les signaux REQ# et émet les signaux GNT# yBien que non obligatoire, souvent intégré au bridge reliant le processeur au bus PCI yLa norme n ’impose pas d ’algorithme particulier yPlusieurs niveaux de priorité peuvent être définis yLa norme attire l ’attention sur l ’importance à ce que le bus ne soit pas monopolisé par un maître détenant la plus haute priorité: xLes Maîtres disposent d ’un Latency Timer pour éviter qu ’ils ne monopolisent le bus trop longtemps. yL ’algorithme peut tirer bénéfice des espaces de configuration des Initiateurs

4 LE BUS PCI 4 ième partie: L ’Arbitrage Principes généraux

5 LE BUS PCI 4 ième partie: L ’Arbitrage Prise de bus zFonctionnement: yLe maître cherchant à prendre le bus active son signal REQ# yL ’arbitre le lui accorde en activant le signal GNT# correspondant yLe maître venant d ’acquérir le bus attend que ce dernier soit inoccupé (Idle state) yUne fois le bus inoccupé ET SI l ’arbitre n ’a pas désactivé GNT#, le maître prend le bus zPossibilité d ’implémenter des process type « bus parking »: Si aucune demande n ’a été émise par un autre maître, celui disposant du bus le garde

6 LE BUS PCI 4 ième partie: L ’Arbitrage Chronogrammes CLK REQ#_A REQ#_B GNT#_A GNT#_B FRAME# IRDY# Transfert de B Transfert de A

7 LE BUS PCI 4 ième partie: L ’Arbitrage Chronogrammes zLe maître garde la main yLe maître garde la main dès qu ’il a activé FRAME# et pour toute la durée du transfert yUne fois FRAME# activé, GNT# peut être désactivé yGNT# est généralement désactivé en cas de demande du bus par un autre maître CLK REQ#_A REQ#_B GNT#_A GNT#_B FRAME# IRDY# Arbitre informe B qu ’il sera le prochain maître A garde la possession du bus =0 Arbitre informe A qu ’il sera le prochain maître B a le bus

8 LE BUS PCI 4 ième partie: L ’Arbitrage Synthèse Phase d ’arbitrage PCI typique entre 2 maîtres et l ’arbitre

9 LE BUS PCI 4 ième partie: L ’Arbitrage Retour sur les fins de transaction zInitialisée par le Maître: Fin Normale yLe Maître a transféré toutes les données correctement Arrêt de la possession du bus yLe maître désactive REQ# ySi GNT# était encore activé, l ’arbitre le désactive

10 LE BUS PCI 4 ième partie: L ’Arbitrage Retour sur les fins de transaction zInitialisée par le Maître: Timeout yLe Maître a encore des données à transférer, mais le laps de temps accordé est terminé ySi: - L ’arbitre a désactivé le GNT# à la suite d ’une demande d ’un autre maître - Le Latency timer (LT) du maître, déclenché lors de l ’activation de FRAME#, est à « 0 » yAlors le maître désactive FRAME#

11 LE BUS PCI 4 ième partie: L ’Arbitrage Retour sur les fins de transaction zInitialisée par le Maître: Master Abort yAucune cible (target) n ’a décodé le bus: DEVSEL# reste inactif (6 cycles d ’horloge après le passage à l ’état actif de Frame#) CLK FRAME* IRDY* 1234 DEVSEL* TRDY* Rapide Moyen Lent Subtractive Phase adresses Aucun