Architettura dei calcolatori/Alcuni bus commerciali

Alcuni bus commerciali

\section{Il bus SCSI} \subsection{Caratteristiche} Il bus SCSI (\emph{small computer system interface}) è stato progettato per avere: \begin{itemize} \item molte unità connesse, fino ad 8; \item estensione fisica fino a 6 metri, estendibile a 25 se si pilotano le linee in modo differenziale; \item ridotto numero di linee (50) con multiplexing; \item velocità di trasferimento fino a 4 Mb/s; \item trasferimenti a burst; \item arbitraggio software distribuito; \item indipendenza dall'architettura del processore; \item linee di segnale pilotate con porte open collector e terminate; \item controllo della parità ad un bit; \item una linea di massa per ogni linea di segnale. \end{itemize}

Ogni unità deve essere dotata di un microprocessore (controller) che gestisce il protocollo di accesso al bus.

Le periferiche hanno una priorità fissa stabilita da ponticelli prima di connettere l'unità al bus; questa è determinata dall'indirizzo della periferica (0-7).

Le linee possono avere terminazione resistiva ($330 \Omega$ verso massa e $220 \Omega$ verso la tensione positiva, detta terminal power) o attiva.

Il protocollo SCSI prevede quattro fasi: bus free, arbitraggio, selezione dati, trasferimento.

L'unità master si dice \emph{initiator}, lo slave \emph{target}.

Le 50 linee di segnale del bus hanno il seguente significato: \begin{itemize} \item $/BSY$ -- busy, pilotata dal target; \item $/SEL$ -- selection, pilotata dal target, con la precedente indicano la fase in cui ci si trova; \item $/ATN$ -- attention, indica l'inizio di una nuova operazione, è pilotato dall'initiator; \item $/RESET$ -- reset, reset asincrono; \item $TERMPOWER$ -- terminal power, 20 V; \item $/D0 \ldots /D7$ -- data, 8 linee dati; \item $/DP$ -- data parity, parità delle linee dati; \item $/REQ$ -- request, pilotata dal target; \item $/ACK$ -- acknowledgement, pilotata dall'initiator, con la precedente consente la comunicazione con protocollo asincrono; \item $/I-O$ (target), indica la direzione del trasferimento, se alta il trasferimento è supposto dall'initiator al target, output; \item $/C-D$, indica se si sta trasferendo comandi o dati (target); \item $/MSG$, indica se si sta trasferendo o meno messaggi (target); \end{itemize}

\subsection{Le fasi del protocollo}

\begin{figure} \centering \intincludegraphics{scsiarb} \caption{Temporizzazione della fasi di bus free, arbitraggio e selezione} \end{figure}

\subsubsection{Bus free} Il bus è considerato libero quando $/BSY$ e $/SEL$ sono inattivi per un tempo maggiore del \emph{settle time} (400 ns); questo indica che è possibile iniziare una nuova operazione.

\subsubsection{Arbitraggio} Se si è nello stadio di bus free e ci sono dei moduli che vogliono utilizzare il bus si attendono 800 ns (\emph{wait for all time}) e quindi ognuno di questi pilota la linea dati corrispondente alla sua priorità (il modulo 0 pilota $/D0$, il modulo 1 $/D1$, \ldots) e $/BSY$. Dopo 2,4 $\mu$s ogni modulo verifica se esistono altre richieste di priorità maggiore della propria; il modulo a priorità maggiore diventa l'initiator e pilota $/SEL$, gli altri rilasciano alte le linee $/BSY$ e $/Dn$; si possono avere dei glitch da or cablato nella linea $/BSY$, per far esaurire i transitori si attendono 800 ns;.

\subsubsection{Selezione} Questa fase inizia con $/BSY$, $/SEL$ e $/D_{initiator}$ attivi; l'initiator seleziona il target attivando la linea dati corrispondente $/D_{target}$ e la linea $/ATN$, si attendono 90 ns e l'initiator rilascia $/BSY$. A questo punto il target ha dai 0,4 ai 200 $\mu$s per pilotare $/BSY$ (turn-over sulla linea $/BSY$ tra initiator e target); si attendono 90 ns e l'initiator rilascia la sua linea dati e $/SEL$, quindi anche il target rilascia la sua linea dati e si passa alla fase successiva.

Le attese sono necessarie affinché tutti i moduli osservino le varie fasi nell'ordine corretto.

\subsubsection{Trasferimento dati} Il target regola il tipo di trasferimento pilotando le linee $/I-O$, $/C-D$ e $/MSG$ secondo la tabella:

\begin{tabular}{cccll} $/I-O$ & $/MSG$ & $/C-D$ & tipo di trasferimento & destinazione \\ 1 & 0 & 0 & message out & target \\ 0 & 0 & 0 & message in & initiator \\ 1 & 1 & 0 & command & target \\ 0 & 1 & 0 & status & initiator \\ 1 & 1 & 1 & data out & target \\ 0 & 1 & 1 & data in & initiator \\ \end{tabular}

Un \emph{messaggio} è una comunicazione tra i controllori che serve a specificare i parametri del trasferimento.

Il trasferimento dati è a burst e può avvenire in modalità asincrona (utilizzando le linee $/REQ$ e $/ACK$) o in modalità sincrona (non è esattamente sincrona in quanto non c'è un clock, ma una serie di trasferimenti, fino a 255, senza acknowledgement esplicito). Messaggi, comandi e stato sono sempre trasferiti in modalità asincrona.

Il termine della fase di trasferimento è determinato dal target che riporta alto $/BSY$.

\section{Il bus PCI} \subsection{Caratteristiche} Il bus PCI (\emph{pheripheral component interconnect}) è stato progettato per avere: \begin{itemize} \item molte unità connesse, fino a 256 (fino a 32 dispositivi fisici ognuno con fino ad 8 dispositivi logici); \item basso consumo di corrente \item trasferimenti a burst; \item indipendenza dall'architettura del processore; \item velocità fino a 33 MHz per secondo (estesa a 66 nello standard 2.1); \item possibile estensione a 64 bit; \item basso numero di pin per dispositivo (47 o 49 per un initiator); \item possibilità di accessi concorrenti nei vari livelli del bus; \item supporto per rilevamento e configurazione automatica delle periferiche (plug-n-play) \item fase di arbitraggio nascosta che si svolge contemporaneamente all'utilizzo del bus e non causa ritardi; \item controllo della parità di indirizzi, comandi e dati. \end{itemize}

Tutti i segnali sono sincronizzati con il clock che è spesso sottomultiplo del clock di sistema.

Tutti i trasferimenti sono a burst e possono essere di qualunque lunghezza.

L'arbitraggio è svolto su linee dedicate e può aver luogo separatamente dall'utilizzo del bus; la tipologia di arbitro non è specificata e dipende dalla piattaforma; l'arbitro può assegnare il bus ad un altro master mentre quello che utilizza il bus non ha ancora segnalato $/RQ$ alto (arbitro preemptive), in questo caso il master attuale termina il suo ciclo di bus mantenendo la richiesta e quando l'arbitro rileva $/FRAME$, $/IRDY$ e $/TRDY$ disattivati concede il grant all'altro master.

Le linee del bus hanno il seguente significato: \begin{itemize} \item $AD0 \ldots AD31$ -- address/data, indirizzi o dati: ; \item $/C-BE0 \ldots C-BE3$ -- command, comandi; \item $PAR$ -- parity, parità: è pilotato basso o alto per fare si che i bit $AD$ e $C-BE$ abbiano somma pari; \item $/FRAME$ -- frame, indica l'inizio e la fine di un frame; \item $/TRDY$ -- target ready; \item $/IRDY$ -- initiator ready; \item $/STOP$ -- stop, lock del bus; \item $/DEVSEL$ -- device selected; \item $/REQ$ -- request e $/GNT$ -- grant: controllano l'arbitraggio e ne sono presenti una coppia per ogni device master; \item $CLK$ -- clock: fino a 33 MHz; \item $/SBO$, $SBDONE$, $IDSEL$, solo nei target \item $/RESET$ -- reset asincrono; \item $/PERR$, $/SERR$, per segnalare gli errori; \item $/INTA$, $/INTB$, $/INTC$, $/INTD$ -- interrupt request; \item $TDI$, $TDO$, $TCK$, $TMS$, $/TRST$, jtag; \item $/LOCK$ -- lock: pilotato dall'initiator per richiedere l'accesso esclusivo al target (ma non blocca l'intero bus); \item $/CLKRUN$ -- clock control; \item $AD32 \ldots AD63$, $/C-BE4 \ldots /C-BE7$, $PAR64$, $REQ64$, $ACK64$, sono opzionali e servono per estendere il bus a 64 bit di indirizzamento. \end{itemize}

Le linee del bus PCI non sono terminate ($\Gamma_L \approx 1$), i generatori sono a resistenza interna elevata per avere bassi consumi di energia ($R_G > R_0$ e quindi $\Gamma_G \approx 1$); in questo modo il bus è lento ma dopo attendendo alcuni cicli di clock si giunge a tensioni elevate e ben campionabili.

\subsection{Le transazioni} Ad ogni trasferimento partecipano due dispositivi: l'\emph{initiator} (master) e il \emph{target} (slave); il primo è quello che inizia il trasferimento dati.

\subsubsection{Indirizzamento (address phase)} Ogni transazione comincia con una \emph{fase di indirizzamento} che dura un ciclo di clock (PCI CLK); l'initiator identifica il dispositivo target (con $AD$) e il tipo della transazione stessa (con $/C-BE$) e contemporaneamente attiva $/FRAME$ indicando l'inizio della comunicazione; il target deve memorizzare l'indirizzo in un suo registro interno.

Il target che riconosce di essere stato selezionato deve attivare $/DEVSEL$, se l'initiator non rileva $/DEVSEL$ attivo dopo un certo periodo di tempo si ha un errore e la transazione è interrotta, altrimenti si passa alla fase di trasmissione dati.

\subsubsection{Trasferimento dati (data phase)} Il numero di byte trasferiti è determinato dai bit associati a $/C-BE$ pilotati dall'initiator.

L'initiator segnala il termine dei dati disattivando $/FRAME$ e attivando $/IRDY$, il target segnala anch'esso la fine della fase attivando $/TRDY$; quando entrambi hanno segnalato il termine la fase di trasferimento è completata, quindi se l'arbitro del bus ha assegnato il grant ad un altro master questi può iniziare a pilotare il bus.

\subsection{Temporizzazioni}

\subsubsection{Lettura} \begin{figure} \centering \intincludegraphics{pciread} \caption{Temporizzazione della fase di lettura} \end{figure}

\begin{enumerate} \item l'arbitro concede il grant $/GR$, l'initiator scelto attiva $/FRAME$ e pilota $AD$ (indirizzo della prima locazione) e $/C-BE$ (comandi); \item il target decodifica e memorizza in un registro interno gli indirizzi ed i comandi ricevuti; \item l'initiator rilascia le linee $AD$, pilota in $/C-BE$ i byte enable, attiva $/IRDY$; \item il target selezionato attiva $/DEVSEL$ (se non lo fa entro alcuni cicli di clock si ha un errore) e quando è pronto (si possono attendere alcuni cicli di clock) attiva $/TRDY$ e trasmette i primi dati in $AD$; \item l'initiator legge i dati e se non è pronto per una nuova lettura disattiva $/IRDY$ riattivandolo dopo il numero di clock necessari; \item il target disattiva $/TRDY$ se non è pronto (attesa) e poi lo riattiva e contestualmente pilota in $AD$ i dati successivi, quindi si torna alla fase precedente; \item quando l'initiator ha finito di richiedere dati disattiva $/FRAME$ indicando che i prossimi dati sono gli ultimi; \item l'initiator legge gli ultimi dati e disattiva $/IRDY$, il target disattiva $/TRDY$ e $/DEVSEL$. \end{enumerate}

\subsubsection{Scrittura} \begin{figure} \centering \intincludegraphics{pciwrite} \caption{Temporizzazione della fase di scrittura} \end{figure}

\begin{enumerate} \item l'arbitro concede il grant $/GR$, l'initiator scelto attiva $/FRAME$ e pilota $AD$ (indirizzo della prima locazione) e $/C-BE$ (comandi); \item il target selezionato decodifica e memorizza in un registro interno gli indirizzi ed i comandi ricevuti, attiva $/DEVSEL$ (se non lo fa entro alcuni cicli di clock si ha un errore) e quando è pronto (si possono attendere alcuni cicli di clock) attiva $/TRDY$; \item l'initiator pilota i dati in $AD$ e in $/C-BE$ i byte enable, attiva $/IRDY$; \item il target legge i dati e se non è pronto per una nuova lettura disattiva $/TRDY$ riattivandolo dopo il numero di clock necessari; \item l'initiator disattiva $/IRDY$ se non è pronto (attesa) e poi lo riattiva e contestualmente pilota in $AD$ i dati successivi, quindi si torna alla fase precedente; \item quando l'initiator ha finito di scrivere dati disattiva $/FRAME$ indicando che i prossimi dati sono gli ultimi; \item il target legge gli ultimi dati e disattiva $/TRDY$ e $/DEVSEL$, il target disattiva $/IRDY$. \end{enumerate}

Durante la fase del trasferimento dati si ha un trasferimento per ogni ciclo di clock a meno che o l'initiator o il target richiedano l'attesa di alcuni cicli disattivando $/IRDY$ o $/TRDY$.

\subsubsection{Arbitraggio} \begin{figure} \centering \intincludegraphics{pciarbit} \caption{Temporizzazione della fase di arbitraggio} \end{figure}

\begin{enumerate} \item l'arbitro ha concesso il grant con $/GNTA$ ad un dispositivo A che ha attivato $/REQA$; \item A comincia la sua transazione attivando $/FRAME$, durante la transazione inoltre il master ed il target attivano e disattivano $/IRDY$ e $/TRDY$; \item un master a priorità maggiore B attiva $/REQB$; \item l'arbitro toglie il grant ad A ($/GNTA$ disattivato) e lo da a B attivando $/GNTB$; \item A termina il corrente ciclo di bus disattivando $/FRAME$ (ma continua a richiedere l'uso del bus attraverso $/REQA$); \item quando B rileva $/FRAME$, $/IRDY$ e $/TRDY$ contemporaneamente inattivi attiva $/FRAME$ e prende il controllo del bus cominciando la sua transazione; \item la prima dell'ultima transazione B disattiva $/REQB$; \item l'arbitro toglie il grant a B e lo assegna ad A (disattiva $/GNTB$ e attiva $/GNTA$); \item B termina la transazione disattivando $/FRAME$; \item quando A rileva $/FRAME$, $/IRDY$ e $/TRDY$ contemporaneamente inattivi attiva $/FRAME$ e prende il controllo del bus cominciando la sua transazione. \end{enumerate}

\subsubsection{Locking}

\begin{figure} \centering \intincludegraphics{pcilock} \caption{Temporizzazione della fase di locking, lettura di master non autorizzato e accesso al lock} \end{figure}

\section{Il bus USB} L'USB è un complesso costituito da un sistema di interconnessione, un protocollo di comunicazione seriale ed un software di gestione, le cui caratteristiche salienti sono: la capacità di collegare un numero elevato di periferiche attraverso una singola porta del sistema host, l'elevata velocità di trasmissione e la presenza imprescindibile del software di gestione.

I requisiti di progetto sono stati la possibilità di costruire un bus formato in base alle necessità e la possibilità di connessioni e disconnessioni a caldo, con il riconoscimento della periferica automatico all'atto della connessione.

Il protocollo è in grado di gestire fino a 127 periferiche (versione 1.1) in grado di scambiare dati ad una velocità di 12 Mb/s per le perifecriche veloci e 1,5 Mb/s per le periferiche lente (con l'USB 2.0 si arriva a 480 Mb/s); questa banda è condivisa tra tutte le periferiche connesse e la priorìtà di ciascuna dipende dalla posizione nella catena del dispositivo.

Il bus USB fornisce alimentazione a periferiche con piccolo assorbimento di potenza (0,5 W).

Il cavo USB è composto da quattro fili, due per i dati (D+ e D-) a doppino intrecciato, l'alimentazione (5 V) e la massa.

Il protocollo USB è organizzato a pila: \begin{itemize} \item a livello fisico, o \emph{livello di interfaccia al bus} (LIB) c'è il cavo USB, il controllore USB e l'interfaccia al bus USB (o \emph{serial interface engine}, SIE), è uguale per tutte le periferiche USB; \item a livello intermedio, o \emph{livello di periferica logica} (LPL), c'è il software USB di sistema (SWU) collegato dal collegamento di default (\emph{default pipe}) alla periferica logica USB (\emph{terminatore 0}, un registro o area di memoria indirizzabile dall'host), servono per le fsi iniziali di riconoscimento e configurazione della periferica; \item a livello dell'applicazione, o \emph{livello funzione}, ci sono i collegamenti (\emph{pipes}) con le funzioni (\emph{terminatori}) della periferica che sono specifiche. \end{itemize}

Le periferiche devono essere provviste di un microcontrollore per gestire la comunicazione; possono essere pure o essere hub (dotate di una o più porte downstream per il collegamento di altre periferiche).

Un pc ha un solo bus USB, connesso al bus PCI tramite il southbridge, che è spesso connesso ad un hub per fornire due o più porte USB.

Esiste un driver che si occupa della configurazione di tutte le periferiche che si connettono o disconnettono.

Tutte le periferiche si comportano come slave rispetto all'host, è l'host che si occupa di interrogarle ogni tanto (polling).

Al momento della connessione di una periferica, questa collega con una resistenza di pull-up (deve essere un decimo della resistenza di D+ verso massa) il cavo D+ all'alimentazione (valido per le periferiche veloci, quelle lente collegano D-); la caduta di tensione, se perdura per più di 2,5 $\mu$s, è riconosciuta dall'host (o dall'hub) come il collegamento di una nuova periferica.

Periodicamente l'host interroga tutti gli hub inviando un messaggio SOF (\emph{state of frame}), se c'è stata una variazione di stato l'hub lo comunica, quindi l'host interroga di nuovo chiedendo la porta di connessione, si è nello \emph{stato di default}.

Successivamente il SWU assegna un indirizzo univoco a 7 bit alla periferica, la interroga e ne legge il descrittore determinando i parametri delle risorse; la periferica è nello \emph{stato configurato}; a questo punto interviene il software utilizzatore che configura i parametri.

\subsection{Le modalità di trasferimento}