Arbitraggio del Bus

Arbitraggio centralizzato parallelo: il bus PCI.

      Finora abbiamo visto schemi di arbitraggio del bus di tipo daisy chaining. L’alternativa a questa configurazione è data da una connessione dei dispositivi in parallelo. Iniziamo analizzando un sistema di arbitraggio di un bus molto diffuso: il bus PCI⁶ .
      L’arbitraggio del bus PCI è centralizzato. L’arbitro, nella maggior parte delle architetture è integrato nel chip bridge comunemente chiamato chipset⁷ presente sulla scheda madre.
      Come è riportato in figura 6 tutti i dispositivi sono collegati all’arbitro tramite una coppia di linee, REQ#⁸ e GNT#. Quando un dispositivo richiede il controllo del bus non deve far altro che asserire REQ# e attendere finché l’arbitro non lo avrà autorizzato all’accesso tramite la linea GNT#. Il dispositivo potrà così pilotare il bus per il prossimo ciclo.
      Nella letteratura relativa all’architettura PCI, il dispositivo che prende il controllo del bus è detto initiator, mentre quello a cui è indirizzata la transizione dell’initiator è detto target. In una transazione PCI, l’initiator è sempre il master e il target è lo slave. E’ usato anche il termine agent per indicare un generico dispositivo, sia esso master che slave, che entra in gioco nella transazione.

Figura 6 Schema di arbitraggio del bus PCI

      E’ interessante conoscere quali sono i segnali coinvolti durante un trasferimento dei dati una volta che il master ha accesso al bus. La transazione ha inizio con l’asserzione da parte del initiator del segnale FRAME#. Questo sarà mantenuto attivo fino al termine del trasferimento. Il master dichiara con quale target vuole comunicare specificando il suo indirizzo su AD e il tipo di transazione da effettuare su C/BE# (lettura o scrittura). Il target risponderà asserendo DEVSEL# in modo da essere individuato sul bus PCI, in caso contrario la transazione viene annullata. Due segnali, IRDY# sull’initiator e TRDY# sul target indicano lo stato di pronto dei due agents e la loro comune asserzione a ogni impulso di clock, abilita il trasferimento del singolo dato. Se anche solo uno dei due segnali è negato non avviene il passaggio del dato e si genera uno ciclo di wait. Quando il trasferimento è quasi alla fine viene disasserito FRAME# proprio sul penultimo dato, quindi, dopo l’ultimo dato viene disasserito IRDY#. I segnale FRAME# e IRDY# entrambi disasseriti indicano che il bus è a riposo (idle).

      Le specifiche del bus PCI lasciano al progettista la scelta della strategia di arbitraggio: sono consentite tecniche di priorità dinamica o di round robin. L’unico requisito da rispettare è quello che l’arbitro deve favorire quanto più possibile la politica del fairness tra le periferiche, evitando lunghe attese per la concessione del bus.
      Una possibile soluzione è quella in cui l’arbitro del bus è programmato dal sistema. In questo modo ad ogni avvio il software di startup può determinare le priorità da assegnare ad ogni singolo master sulla base delle proprie caratteristiche tecniche. Il sistema può, inoltre, decidere di gestire i dispositivi PCI suddividendoli in due categorie. Nella prima sono inseriti quegli agents che richiedono un accesso veloce al bus o necessitano di una larghezza di banda maggiore per raggiungere un livello di utilizzo ottimale (vedi schede video o adattatori di rete ATM), nel secondo gruppo tutti gli altri che non hanno particolari necessità di funzionamento (schede SCSI o altre interfaccie di espansione del bus). Per la scelta del master successivo, l’arbitro dovrà quindi considerare il primo gruppo, a priorità rotante, che comprende gli elementi a priorità più alta è un elemento del secondo gruppo che varia ad ogni cambio delle priorità.
      Per comprende meglio il modo in cui variano le priorità dell’esempio proposto, si possono considerare i master A e B facenti parte del primo gruppo e X, Y e Z i master del secondo gruppo. Riferendoci alla figura 7 si comprende quale sarà l’ordine col quale i master potranno accedere al bus:

      A – B – X – A – B – Y – A – B – Z – A – B – X – …

Figura 7 Esempio di un possibile schema di arbitraggio.

       In questo modo i master del primo gruppo possono accedere al bus più frequentemente rispetto a quelli del secondo soddisfacendo così il requisito di fairness.

       Una volta che un dispositivo ha accesso al bus potrà utilizzarlo per effettuare una singola transazione e successivamente dovrà attendere per favorire eventuali altre richieste. In assenza di richieste da parte di altri dispositivi potrà continuare a utilizzare il bus ma ad ogni transizione dovrà seguire una fase di inattività.
      In situazioni particolari un master può continuare a mantenere asserito REQ# e se l’arbitro mantiene GNT# per mancanza di altre richieste a priorità più alta, può effettuare una serie di transizioni consecutive, impiegando al massimo il bus in una sequenza di cicli cosiddetti back-to-back. Nel momento in cui un secondo dispositivo fa una richiesta del bus l’arbitro nega il grant del master corrente, il quale campionando costantemente il proprio segnale di autorizzazione, è costretto a rilasciare il bus al termine della transazione in corso.
      Diversamente da altri schemi di arbitraggio quello del PCI è nascosto, cioè avviene durante il trasferimento precedente, in modo che nessun ciclo di bus venga penalizzato.

      Come nell’arbitraggio del Multibus I anche per il PCI è possibile implementare la tecnica del bus parking. Se il progettista ha implementato uno schema di bus parking, l’arbitro sarà in grado di indicare un master del bus al quale, in assenza di altre richieste, sarà sempre garantito il segnale GNT# asserito. Quindi, in assenza di altre linee REQ# attive, il bus master scelto per default avrà sempre immediato accesso al bus. Se il dispositivo su cui è “parcheggiato” il bus volesse effettuare una transazione può farlo immediatamente senza la necessità di asserire il segnale di REQ#, l’unica condizione è che il bus sia nello stato di idle (FRAME# e IRDY# disasseriti) e ovviamente GNT# asserito.
      La scelta del master su quale effettuare il parking deve essere compiuta in sede di progettazione. Si può optare di scegliere l’ultimo master che ha utilizzato il bus, o sceglierne uno predefinito per default.
      Un punto importante da evidenziare è che la scelta di implementare una tale tecnica delega al master candidato al bus parking la responsabilità della gestione dei segnali di indirizzamento quando il bus è idle. Potrebbe infatti verificarsi che, durante uno stato di idle, l’arbitro tolga il GNT# ad un master per assegnarlo ad un altro, e nello stesso istante il primo agents asserisca il segnale FRAME#. In questo caso il master continuerà la transazione andando a scrivere l’indirizzo del target su AD. Il secondo master che vede lo stato di idle ed ha ottenuto il GNT#, inizia anch’esso la comunicazione col suo slave. Questa situazione che in assenza del bus parking è gestita dall’arbitro, in questo caso è affidata al park master che dovrà garantire che tra la revoca del GNT# e la sua riassegnazione esista un ritardo (arbitration latency) di almeno un ciclo di clock⁹ .

      Concludiamo questa panoramica sull’arbitraggio del bus PCI analizzando il caso di due agents che concorrono per l’uso del bus.
      Consideriamo due master A e B e supponiamo che A debba effettuare due transazioni mentre B debba compierne solo una. Supponiamo inoltre che B abbia una priorità più alta di A o che lo schema delle priorità sia rotazionale e che B sia quindi il successivo ad utilizzare il bus.

Figura 8 Arbitraggio del bus PCI tra due master. Mostra come l’arbitro alterna il controllo del bus tra i due agents.

      Nella figura 8 è riportato l’andamento dei segnali durante la fase di arbitraggio tra i due initiator, ovvero il passaggio del controllo da un master ad un altro a priorità maggiore. Tutti i segnali sul bus PCI sono campionati sul fronte di salita del clock.

      Riferendoci alla figura 1-8 abbiamo la seguente successione di eventi di clock:

1. Il master A antecedentemente al clock 1 aveva già asserito il suo segnale di REQ# per cui l’arbitro,monitorando la richiesta, gli assegna il bus asserendo GNT#. Nello stesso periodo di clock il master B attiva il suo segnale di REQ#, indicando il desiderio di eseguire una transazione.

2. Durante il secondo ciclo di clock il master A campiona il suo GNT# asserito e lo stato idle del bus (FRAME# e IRDY# disasseriti). A questo punto A inizia la transazione asserendo FRAME# ma non disattiva REQ# in quanto deve effettuare una seconda transazione. L’arbitro, monitorando le richieste di A e B, inizia la fase di arbitraggio per determinare chi sarà il prossimo master. Questa fase avviene parallelamente al trasferimento dei dati di A (arbitraggio nascosto).
3. Sul fronte di salita del terzo ciclo di clock, l’arbitro rimuove il grant dal master A e lo assegna al master B. Il master B non pùò comunque usare il bus finché questo non torna nello stato di riposo. Nel frattempo A disasserisce FRAME# perché sta per trasferire l’ultimo gruppo di dati.

4. Durante il clock 4 il master A conclude il suo primo trasferimento e riporta il bus nello stato di idle (disasserisce IRDY#).

5. Sul fronte di salita del clock 5 il master B vede il bus a riposo e asserisce FRAME# avviando la sua transazione.

6. Sul fronte di salita del sesto clock il master B disasserisce FRAME# perché sta per teminare il suo trasferimento. L’arbitro disasserisce il grant di B e, poiché A ha mantenuto la sua richiesta sempre attiva, asserisce GNT# di A.

7. Sul settimo fronte di salita di clock il master B riporta il bus nello stato di idle. Il master A monitorando il bus libero ne riprende il controllo.