USB
1.0 → 3.0
Esiste anche una versione 2.0 On The Go che consente il collegamento tra due dispositivi senza la
presenza dell’host controller per applicazioni dedicate.
Questa interfaccia consente il plug and play cioè la capacità del sistema di riconoscere e configurare
la periferica subito dopo il collegamento e la relativa assegnazione delle necessarie risorse.
É in grado di gestire fino a 127 periferiche fornendo (entro certi limiti) anche l’alimentazione.
La lunghezza massima dei cavi di collegamento è di 5 metri con massimo 5 livelli di Hub.
Consente la connessione e disconnessione a caldo delle periferiche.
Supporta applicazione in tempo reale come voce, audio e video.
Comunicazione asincrona ed isocrona half duplex con pacchetti di varie dimensioni.
Dispone di meccanismi di gestione e recupero degli errori.
É in grado di identificare ed isolare dispositivi non funzionanti.
Caratteristiche generali
L’architettura USB prevede la presenza di un solo Host Controller (detto Root) nel PC in grado di
gestire tutti i devices ad esso collegati secondo una topologia a stella.
I devices invece possono essere di due tipi:
Hub: dispositivi che consentono l’incremento del numero di porte disponibili
Periferiche: dispositivi che svolgono specifiche funzioni ed in grado di usare il protocollo USB.
Host Root
Hub1
Compound Device
Dev6
Dev3 Dev4
Rosso VBus
Verde D+
Bianco D-
Nero GND
I dati vengono trasmessi utilizzando una codifica NRZI (Not Return to Zero Invert) con bit stuffing
per assicurare le adeguate transizioni.
Un campo SYNC di 8 bit precede ogni pacchetto per permettere al ricevitore la corretta
sincronizzazione del clock.
L’alimentazione VBus è pari a +5 volt con una corrente massima di 500 mA (2.5 watt).
I cavi sono terminati con opportune resistenze per il riconoscimento del tipo di periferica (Low o
Full Speed) e per il rilevamento della connessione o disconnessione.
• I due estremi del cavo fanno uso di differenti connettori per evitare collegamenti non consentiti.
Il primo descrive il tipo e la direzione della transazione, l’indirizzo del device USB ed il numero di
endpoint. L’endpoint è un indirizzo interno al device USB usato per la scrittura o lettura di
informazioni, ve ne possono essere fino a 16 e sono monodirezionali. L’Endpoint 0 è obbligatorio.
L’associazione tra l’host ed un endpoint è detta pipe.
La sorgente selezionata per la transazione invia poi il pacchetto Data di massimo 1023 byte.
Il destinatario risponde infine con un pacchetto di Hanshake per comunicare la corretta ricezione.
All’interno dei pacchetti esistono altri tipi di campi come EOP (End Of Packet), PID (Packet ID),
ADDR (indirizzo), ENDP (Endpoint), CRC (controllo d’errore), NACK (not acknowledge).
Esistono due tipi di pipe dette stream e message: la prima non ha una definita struttura USB mentre
la seconda si.
L’Endpoint 0 viene associato ad una Control Pipe 0 che deve sempre esistere in quanto all’atto della
connessione l’host vi accede per configurare il device.
• Per garantire una corretta protezione dei dati trasmessi, ogni pacchetto include un campo per il
controllo d’errore, ed in alcuni casi, con la disponibilità di richiesta di ritrasmissione.
Il protocollo include separati CRC per i campi dati e controlli di ogni pacchetto.
Il CRC usato garantisce il 100% di sicurezza per errori su bit singoli e doppi.
In caso di errore l’host effettua fino a tre tentativi di ritrasmissione.
• L’attività di Bus enumeration identifica ed indirizza tutti i devices collegati al bus, queste
operazioni vengono effettuate allo startup con una memorizzazione in tabelle di tipo statico.
Essendo i devices collegabili e scollegabili in ogni istante, l’attività descritta è di tipo dinamico.
L’attività di Bus enumeration include anche gli altri processi conseguenti all’attacco e distacco.
• Dal punto di vista logico tutte le periferiche risultano allo stesso livello e, per mezzo del software
USB di sistema, l’utente vede solo le loro funzioni.
Essendo le comunicazioni sul bus gestite dal software di sistema, queste risultano indipendenti dai
programmi applicativi.
Lo stack software può essere così modellizato:
HOST DEVICE
Pipe
Client SW Funzione Livello
Applicazione funzione
Default pipe
Software USB (Endpoint 0) Livello
Periferica
di sistema logica USB periferica
logica
Interfaccia al Livello
USB Host
bus USB interfaccia
Controller
Cavo USB
Il trasferimento dei dati avviene tra il software dell’host ed uno specifico endpoint del device.
Control transfers É usato per configurare un device dopo il suo iniziale collegamento
Utilizza il 10% della banda utile.
Bulk data transfers É il trasferimento, in modalità burst (sequenziale), di grandi quantità di
blocchi di dati che non hanno vincoli temporali tra loro (stampanti,
scanner ecc). Per la trasmissione viene concessa tutta la banda disponibile.
Viene usato un controllo d’errore in hardware e la ritrasmissione.
Interrupt data L’host, in qualità di master, effettua periodicamente il polling sulle varie
transfers periferiche per verificare la presenza di richieste di asservimento.
Generalmente si tratta di piccole quantità di dati senza un definito timing
rate come nei mouse.Viene usato il 90% della banda utile con controllo
d’errore.
Isocronous or É usato per il trasferimento di dati che devono arrivare con la stessa
streaming cadenza temporale con la quale sono stati generati per cui è necessaria una
real data transfers prenegoziazione della banda necessaria. (audio, video, telefonia ecc.).
Ogni errore in trasmissione non può essere corretto ne ritrasmesso.
• Tutti i devices USB sono utilizzabili per mezzo di un proprio univoco indirizzo.
In più, ogni devices USB dispone di alcuni endpoint con i quali l’host può comunicare.
Tutti i devices USB devono disporre di un particolare endpoint detto Endpoint 0 al quale è collegata
la Control Pipe. Tutti i devices USB supportano un comune metodo di accesso all’Endpoint 0.
L’endpoint 0 contiene tutte le informazioni necessarie alla completa caratterizzazione e
configurazione del device.
Gli hub sono dei concentratori che consentono la connessione di più dispositivi USB.
Più hub possono essere collegati in cascata. La porta di upstream viene connessa all’host.
Upstream
H
HOST Port Hub Hub
Repeater Controller U
B
Le altre porte dell’hub (downstream) possono essere connesse ad altri hub o periferiche.
Gli hub sono in grado di rilevare la connessione o disconnessione di devices sulle loro porte e
provvedere alla distribuzione dell’alimentazione.
Ogni porta può essere singolarmente abilitata e configurata in modo Full Speed o Low Speed.
Tutti gli hub sono costituiti da due parti: Hub Controller ed Hub Repeater.
Il repeater gestisce il protocollo tra la porta di upstream e le porte di downstream come anche i
segnali di reset, di sospensione e di riabilitazione.
Il controller gestisce invece i registri di interfaccia per consentire la comunicazione da o per l’host.
Device: indica il costruttore, la versione USB, la massima grandezza dei pacchetti per l’Endpoint 0.
Configuration: indica il tipo di alimentazione (da Bus o esterna),la corrente assorbita e le interfacce.
Interface: indica il numero di endpoint di ogni interfaccia.
Endpoint: per ogni endpoint indica il tipo di trasferimento usato, la dimensione dei pacchetti, la
direzione, il timing per il polling.
Prima che un dispositivo possa essere usato deve essere configurato dall’host per mezzo
dell’assegnazione delle necessarie risorse.
• Un host interagisce in hardware con i devices per mezzo dell’host controller che provvede alle
seguenti azioni:
Device fisico: una parte dell’hardware della periferica avente specifiche funzioni.
Client software: software applicativo, gestito dal sistema operativo, che comunica con il device.
Software USB di sistema: software che gestisce l’interfaccia USB sotto il sistema operativo
indipendentemente dal particolare device e software applicativo.
USB host controller: Insieme di hardware e software per la gestione del device collegato.
Dal punto di vista topologico l’interfaccia USB è costituita da quattro parti principali:
Dal punto di vista fisico la topologia USB è di tipo a stella (o meglio ad albero se ci sono gli hub).
Dal punto di vista logico invece ogni device viene considerato direttamente connesso all’host.
Host Root
Compound Device
Dev5
Dev1
Dev6
Dev2
Dev3 Dev4
Infine, nell’ambito della relazione esistente tra software applicativo e periferica, il legame esistente
è unico tra i due elementi ed indipendente dagli altri dispositivi connessi al bus.
SW SW SW SW SW SW
client 1 client 2 client 3 client 4 client 5 client 6
Dev1 Dev6
Dev2 Dev5
Dev3 Dev4
numero di endpoint
ampiezza di banda richiesta
frequenza di accesso al bus
modalità di gestione degli errori
dimensione massima dei pacchetti trasferibili
tipo di trasferimento
direzione del trasferimento (bulk e isocrono)
Tutti i devices USB devono disporre di un particolare endpoint detto Endpoint 0 che viene utilizzato
dall’host per inizializzare, configurare e controllare l’accesso al device stesso.
Questo endpoint è sempre disponibile una volta che il device è collegato.
Endpoint addizionali possono essere presenti in un device USB. Massimo 2 per il tipo Low Speed e
fino a 16 per il tipo Full Speed. Gli endpoint aggiuntivi vengono configurati durante il normale
processo di configurazione del device.
• Una pipe è una associazione tra un endpoint di un device ed il software dell’host e consente il
trasferimento di dati tra i due.
Sono possibili due modi di comunicazione mutuamente esclusivi:
Stream: i dati trasferiti attraverso la pipe non hanno una struttura USB
Message: i dati trasferiti attraverso la pipe hanno una struttura USB
Tipologie di trasferimento
Control Transfers
Se il trasferimento in corso utilizza meno del 10% del tempo di frame (frame time), il tempo
restante può essere usato per un trasferimento bulk.
La ripetizione di un trasferimento può essere effettuata nel frame corrente o nel successivo.
Se il tempo disponibile è minore di quello necessario per il trasferimento di controlli ma ci sono dei
frame time non usati da trasferimenti isocroni o interrupt, l’host provvede al trasferimento dei
controlli in attesa.
I sistemi USB dispongono di un buon sistema di rilevazione degli errori e della loro ritrasmissione
durante il trasferimento dei controlli. Il protocollo consente la distinzione tra il pacchetto
ritrasmesso ed il suo originale ad eccezione di quello di setup.
Isochronous transfers
Mentre il trasferimento isocrono è progettato per supportare sorgenti e destinatari isocroni, ciò non
è necessario per il software utilizzato.
Un endpoint configurato per una pipe isocrona specifica anche la massima dimensione del payload
trasferibile. Il sistema USB usa questa informazione per assicurare un sufficiente bus time ai frame
di trasporto. Se il bus time è sufficiente la configurazione è stabilita altrimenti no.
Il sistema USB limita a 1023 byte la massima dimensione del payload per ogni pipe isocrona.
La dimensione del payload trasferito in un certo periodo può essere anche minore di quella
massima prenegoziata. Un errore di trasmissione può modificare la dimensione del payload ricevuto
ma questo fatto sarà rilevato dal controllo CRC.
Il trasferimento isocrono può essere usato solo dai devices Full Speed.
Il sistema USB impone che non più del 90% di ogni frame sia allocato per trasferimenti periodici.
Un endpoint per una pipe isocrona non contiene informazioni circa la frequenza di accesso al bus.
Tutte le pipe isocrone trasferiscono un pacchetto di dati per ogni frame ogni 1 mSec.
Interrupt transfers
Il trasferimento su base interrupt è progettato per quei devices che trasmettono sporadicamente e in
istanti non prevedibili piccole quantità di dati.
Il trasferimento interrupt ha le seguenti caratteristiche:
Il trasferimento interrupt può essere usato dai devices Low Speed e Ful Speed.
Come per il trasferimento isocrono, anche per questo tipo di trasferimento il sistema USB impone
che non più del 90% di ogni frame sia allocato per trasferimenti periodici.
Un endpoint per una pipe interrupt dichiara anche il suo necessario periodo di accesso al bus:
un endpoint Full Speed può specificare un periodo compreso tra 1 e 255 mSec mentre uno Low
Speed tra 10 e 255 mSec. Il periodo assegnato dal sistema sarà compreso tra i due estremi.
La gestione degli interrupt degli endpoint è di tipo polling.
Bulk Transfers
Il trasferimento bulk è progettato per devices che necessitano di trasferire grandi quantità di dati in
tempi altamente variabili in funzione della disponibilità di banda.
Il trasferimento bulk ha le seguenti caratteristiche:
Nel caso di ampia disponibilità di banda, il trasferimento bulk risulta abbastanza veloce mentre nel
caso di limitata disponibilità di banda, il trasferimento bulk potrà essere spezzettato su lunghi
periodi di tempo.
Una pipe bulk è sempre unidirezionale, nel caso in cui il device necessiti di una comunicazione
bidirezionale sarà necessario attivare due pipe bulk per le due direzioni.
Un endpoint configurato per una bulk pipe specifica anche la massima dimensione del payload del
pacchetto dati che può essere trasferito attraverso il bus il cui valore può essere solo di 8, 16, 32 o
64 byte. Se il pacchetto dati è minore del massimo, non è necessario effettuare il padding.
Un payload di dimensioni superiori può essere trasferito per mezzo di transizioni multiple per le
quali ogni payload dovrà avere una dimensione pari alla massima tranne l’ultimo che potrà essere
più piccolo. Nel caso di ricezione di un payload di dimensioni superiori a quelle consentite, la pipe
sarà posta in stallo ed il trasferimento sarà abortito
Il trasferimento bulk può essere usato solo da device di tipo Full Speed.
Un endpoint di una pipe bulk non ha modo di indicare una specifico valore della frequenza di
accesso al bus per cui il sistema USB cercherà di soddisfare le richieste nel modo migliore.
I trasferimenti control hanno priorità sui trasferimenti bulk.
Solo nel caso in cui vi sia una sufficiente ampiezza di banda e dei frame time non usati, questi
vengono assegnati ai trasferimenti bulk.
Più trasferimenti bulk in attesa di un frame time disponibile saranno selezionati secondo criteri
dipendenti dalla direzione e dal system software USB.
Un endpoint ed il suo relativo software applicativo non possono definire alcuna velocità operativa
per il trasferimento bulk in quanto la disponibilità di frame time può cambiare in funzione
dell’inserimento o distacco di altri devices o di altre richieste di trasferimenti bulk.
Transfer Management
Software applicativo: utilizza e genera specifici dati da o per l’endpoint per mezzo delle IRP.
USB Driver: converte i dati in IRP da o per l’endpoint. Un singolo IRP può coinvolgere uno o più
trasferimenti.
Host Controller Driver: converte gli IRP da o per la transizione e gli organizza per la
manipolazione dell’host controller. L’interazione tra l’host controller driver ed il suo hardware non
dipende dalle specifiche USB ma dalla sua implementazione.
Host Controller: gestisce le transizioni e le attività del bus per mezzo dei pacchetti usati per il
trasporto dei dati attraverso il bus per ogni transizione.
2 1
3 4
1 2 3 4
Serie A Serie B
Il cavo USB è costituito da una coppia di fili con AWG (American Wire Gauge) 20-28 per la
distribuzione dell’alimentazione ed una coppia di fili twisted con AWG 28 schermati ed incapsulati
in una guaina. Il periodo di twisted è compreso tra 6 e 8 centimetri.
La resistenza elettrica dei cavi formanti la coppia non può differire di più del 5%.
L’impedenza caratteristica della coppia di cavi dovrà essere di 90Ω ±15% nell’intervallo di
frequenze compreso tra 1 e 16 MHz.
Il tempo di propagazione dei segnali dovrà risultare minore o uguale a 30 nSec nell’intervallo di
frequenze compreso tra 1 e 16 MHz.
Una connessione Full Speed è realizzata per mezzo di una coppia di cavi twisted con impedenza
caratteristica Z0 di 90Ω ed una lunghezza massima di 5 metri.
L’impedenza interna di ognuno dei driver deve essere compresa tra 29Ω e 44Ω.
I tempi di salita e discesa dei segnali di dati dovranno essere compresi tra 4n Sec e 20 nSec.
Le caratteristiche del driver restano le stesse per l’utilizzo in modo Low Speed.
Il circuito di ricezione, anch’esso di tipo differenziale, dovrà avere una sensibilità di almeno 200
mVolt quando entrambe le due linee sono nel range 0.8 ÷ 2.5 volt rispetto a massa.
I devices Low Speed e Full Speed differiscono per il diverso collegamento della resistenza di pull-
up sull’estremo finale (downstream) del cavo.
I devices Full Speed sono terminati con una resistenza di pull-up sulla linea D+ mentre
i devices Low Speed sono terminati con una resistenza di pull-up sulla linea D–.
La resistenza di pull-up ha un valore di 1.5 KΩ ±5% ed è collegata ad una tensione compresa tra 3.0
e 3.6 volt rispetto a massa.
Le resistenze di pull-down, dal lato upstream, sono da 15 KΩ ±5% e collegate a massa.
Come si può notare dal circuito precedente, il cavo USB presenta delle resistenze di pull-down dal
lato host e una resistenza di pull-up dal lato device.
Il collegamento di questa ultima resistenza definisce il tipo di device connesso: i devices Full Speed
hanno la resistenza di pull-up collegata alla linea D+ mentre quelli Low Speed hanno la resistenza
di pull-up collegata alla linea D–.
Nel caso in cui il cavo sia collegato dal lato host ma non dal lato device, le due linee D+ e D– sono
a massa, questo stato è detto Idle.
Quando al cavo è anche collegato un device, attraverso il partitore R1 R2 si viene a formare un
livello di tensione superiore a VSE(max) su una sola delle due linee D+ o D– e rispettivamente su
D+ per un device Low Speed o su D– per un device Full Speed.
Se questa condizione permane per più di 2.5 µSec, l’host riconosce la connessione del device.
Si rammenta che device e hub sono dispositivi passivi per cui non sono in grado di comunicare
l’avvenuta connessione, è quindi l’host che periodicamente interroga il dispositivo per determinare
una eventuale nuova connessione.
In caso di disconnessione, la tensione sulla linea interessata tornerà a zero.
Se la tensione scende al di sotto del valore VSE(min) per più di 2.5 µSec, l’host considererà il device
disconnesso.
Come già detto la trasmissione dei segnali avviene per mezzo di segnali differenziali.
Un 1 è rappresentato da un livello della linea D+ più positivo di almeno 200 mV rispetto a D–
Uno 0 è rappresentato da un livello della linea D– più positivo di almeno 200 mV rispetto a D+.
Il livello di incrocio dei due segnali deve essere tra 1.3 e 2.0 volt.
L’inizio di un pacchetto (SOP) è segnalato dalla commutazione delle linee D+ e D– dallo stato di
idle in quello opposto K. Questa commutazione rappresenta il primo bit del campo SYNC.
La fine di un pacchetto (EOP) è indicata da uno stato 0 single-ended per due bit time seguito da uno
stato idle per un bit time e dal successivo passaggio in 3-state del driver.
Lo stato 0 single-ended è indicato dalla presenza di un livello di tensione minore di 0.8 volt su
entrambe le linee D+ e D–.
Segnale di reset
Un segnale di reset è generato da un host controller o un hub verso un device per mezzo di uno stato
single-ended 0 della durata di almeno 10 mSec.
Dopo la rimozione di un reset, il device sarà ancora connesso ma non ancora indirizzato e
configurato.
Un device attivo, vedendo un single-ended 0 sulla sua porta di upstream per più di 2.5 µSec, potrà
considerare questo segnale come un reset solo dopo 5.5 µSec.
Un hub con bus alimentato che riceve un reset sulla sua porta di upstream, rimuove l’alimentazione
da tutte le sue porte di downstream e le disabilita.
Gli hub devono essere capaci di stabilire una connessione e tutti i devices devono essere capaci ci
accettare un indirizzo per mezzo del SET_ADDRESS command non più tardi di 10 mSec dalla
rimozione del segnale di reset.
Tutti i devices devono poter eseguire il comando di sospensione in qualsiasi stato si trovino.
Si passa nel modo sospensione quando uno stato di idle si presenta sulle linee del bus per più di 3
mSec. Una qualsiasi attività del bus rimuoverà lo stato di sospensione del device.
Quando un device è nello stato di sospensione dovrà assorbire dal bus meno di 500 µA.
Il comando di sospensione può essere globale o selettivo a secondo che agisca su tutti i devices
della rete o solo su alcuni rami della rete.
Segnale di resume
Quando un device è nello stato di sospensione può ritornare attivo (resumed) ricevendo da un host
un qualsiasi segnale che non sia un idle.
L’host dovrà inviare il segnale di resume per almeno 20 mSec seguito da un pacchetto standard
EOP di tipo Low Speed.
Al termine della segnalazione del resume, il device pone le sue linee di dati in 3-state.
Un hub che riceve un segnale di resume, propagherà questo segnale su tutte le sue porte di
downstream entro 50 µSec.
Delay e Turnaround
Premesso che è consentita una sola transizione per volta su un cavo USB.
In considerazione del fatto che la transizione di un segnale Full Speed si deve propagare fino alla
fine del cavo, ritornare ed assestarsi entro un bit time (80 nSec), il massimo ritardo di propagazione
consentito risulterà di 30 nSec.
Indipendentemente dalla velocità di propagazione, la lunghezza massima del cavo sarà di 5 m per il
modo Full Speed e di 3 m per quello Low Speed.
Un nuovo device non può iniziare a pilotare il bus finché il precedente device non avrà completato
la sequenza EOP e disabilitato il suo driver e cioè fino a quando il nuovo device non avrà rilevato
che il bus è nello stato J dopo un SE0 per almeno due bit time.
Se un device è in attesa di rispondere alla trasmissione dell’host, questa risposta deve arrivare sul
lato upstream del cavo entro 7.5 bit time prima del ritorno nello stato J dopo un SE0.
Il massimo tempo di turnaround di un bus Full Speed prevede un time out di 16 bit time.
Il massimo ritardo che un host ha per rispondere a un pacchetto inviato da un device è di 7.5 bit
time.
Un device in attesa di risposta non andrà in time out prima di 16 bit time e non dopo 18 bit time.
Un host non inizierà la trasmissione di un token per la successiva transizione prima di 18 bit time
dopo aver rilevato la fine del pacchetto senza risposta.
Nel collegamento in cascata di più hub fino ad un device il massimo ritardo di propagazione tra gli
estremi è di 70 nSec.
Campo SYNC
Per migliorare la chiarezza, nelle successive rappresentazioni i bit sono visualizzati senza le
codifiche NRZI e bit stuffing.
Le transizioni sul bus sono costituite dalla sequenza dei pacchetti Token, Data, Handshake.
Tutti i pacchetti hanno dei delimitatori di inizio e fine (SOP ed EOP).
Il delimitatore SOP fa parte del pacchetto SYNC.
In ogni pacchetto USB, il campo SYNC è seguito dal pacchetto di identificazione (PID).
Il pacchetto PID, fatto da 8 bit, è costituito da 4 bit che ne identificano il tipo più 4 bit di check
uguali ai precedenti ma complementati al fine così di assicurare l’affidabilità della decodifica.
La ricezione di un PID con un check errato o con una configurazione non definita, implicherà
l’eliminazione di tutto il pacchetto.
Se un device riceve un PID corretto ma che prevede un tipo di transizione o una direzione non
supportata, questo non risponderà.
LSB MSB
PID0 PID1 PID2 PID3 P I D0 P I D1 P I D2 P I D3
Le tipologie di PID sono divise in quattro gruppi: token, data, handshake e special.
I primi due bit (1 e 0) identificano il gruppo di appartenenza.
Gli endpoint dei device sono indirizzati per mezzo di due campi: l’indirizzo del device e l’indirizzo
dell’endpoint. Indirizzi errati o non corrispondenti determinano lo scarto del token come pure
l’accesso ad un endpoint non inizializzato.
Ogni campo address (ADDR) individua un singolo device mentre il fatto che sia il trasmettitore o il
ricevitore dipende dal valore del PID.
Tutti gli indirizzi sono costituiti da 7 bit per un totale di 128 devices indirizzabili.
LSB MSB
Addr0 Addr1 Addr2 Addr3 Addr4 Addr5 Addr6
Il campo ADDR deve essere specificato per i token IN, OUT e SETUP.
Successivamente ad un reset o dopo il power-up, viene assegnato al device un address default 0 per
poter poi eseguire la fase di assegnazione dell’indirizzo di lavoro (enumeration process).
L’address default 0 non può essere assegnato durante la normale attività.
LSB MSB
Endp 0 Endp1 Endp 2 Endp3
Il frame number è un campo di 11 bit che viene incrementato dall’host per il conteggio dei frame.
Il suo massimo valore è 7FFH (204710) ed è inserito solo nel token SOF alla partenza di ogni frame.
Campo dati
Il campo dati può essere costituito da un numero intero di byte variabile da 0 a 1023.
LSB MSB
D0 D1 D2 D3 D4 D5 D6 D7
Le dimensioni del pacchetto dati può variare in funzione del tipo di trasferimento usato.
CRC
Il controllo di ridondanza ciclica (CRC) è usato per il controllo d’errore nei soli pacchetti token e
data. Il PID non è sottoposto al controllo CRC. Il controllo di errore non coinvolge i bit di stuffing.
Il CRC dei pacchetti di token e data assicura il 100% della rilevazione degli errori singoli e doppi.
La ricezione di un CRC errato determina l’eliminazione del campo o dell’intero pacchetto.
Il controllo d’errore sul campo dati utilizza un polinomio generatore del tipo
G(X) = X16 + X15+ X2 + 1
Un pacchetto token consiste di un PID, con la specifica di IN, OUT o SETUP del tipo di pacchetto,
un campo ADDR ed un campo ENDP.
Per le transazioni IN e SETUP, i campi address ed endpoint identificano univocamente l’endpoint
che poi riceverà il pacchetto dati.
Per le transizioni IN, i campi address ed endpoint identificano univocamente l’endpoint che
trasmetterà il pacchetto dati.
Soltanto l’host potrà generare un pacchetto token.
Il pacchetto di token ha 5 bit di CRC i quali controllano solo i campi ADDR ed ENDP in quanto il
campo PID ha un proprio campo di check.
I pacchetti di token e di SOF sono delimitati da un EOP dopo tre byte di campi di pacchetti dati.
Nel caso di assenza di questo EOP, il pacchetto sarà considerato non valido e scartato.
I pacchetti Start of Frame (SOF) sono emessi dall’host ad un rate di uno ogni 1.00 mSec ±0.05.
Un pacchetto SOF è costituito da un PID che indica il tipo di pacchetto seguito poi da 11 bit di
campo per il numeratore di frame.
SOF costituisce solo la transizione che corrisponde alla partenza di ogni frame in precisi istanti di
tempo con in più il numero di frame.
Tutti i devices Full Speed (compresi gli hub) devono ricevere e decodificare i pacchetti SOF.
I pacchetti SOF non determinano la generazione di pacchetti di ritorno (handshake) per cui la loro
consegna non è garantita.
Un device è informato dell’arrivo di uno start of frame quando rileva il suo PID.
I device sensibili alla temporizzazione dei frame devono solo decodificare il campo PID e possono
ignorare i campi Frame Number e CRC. Questi ultimi due campi sono considerati dai devices che
hanno bisogno di tener traccia della numerazione dei frame.
Pacchetto Handshake
8 bit
PID
ACK Indica che il pacchetto dati è stato ricevuto senza bit stuff o senza errori CRC sui campi controllati e
con il PID corretto
NAK Indica che il device non è disponibile ad accettare dati dall’host (OUT) oppure che non ha dati da
inviare all’host (IN). Un host non potrà mai generare un NAK.
NAK è usato dal controllo di flusso per indicare che il device non è temporaneamente disponibile a
trasmettere o ricevere dati.
NAK è anche usato dall’interrupt endpoint per indicare che non ci sono richieste di interrupt pendenti.
STALL STALL indica che il device non è disponibile a ricevere o trasmettere dati e che questa condizione
richiede l’intervento dell’host per la rimozione dello stallo.
Transizioni bulk
Le transizioni bulk hanno la caratteristica di essere prive di errori di trasferimento dati tra host e
devices per mezzo del supporto del controllo d’errore e della possibilità di ritrasmissione.
Quando un host vuole ricevere dei dati bulk, emette un token tipo IN.
L’endpoint del device risponde emettendo un pacchetto DATA oppure, se non è in grado di farlo,
risponde con un handshake tipo NAK o STALL.
Se l’host riceve un pacchetto dati corretto, risponde con un handshake ACK se invece rileva un
errore nei dati non risponde.
Quando un host vuole inviare di dati bulk, emette un token tipo OUT seguito da un pacchetto dati.
Il device potrà rispondere con tre tipi di handshake:
ACK per indicare che il pacchetto è stato ricevuto correttamente e che l’host può inviare
l’eventuale pacchetto successivo della sequenza.
NAK per indicare che i dati sono stati ricevuti senza errori ma che l’host dovrebbe ritrasmetterli
poiché il device non era momentaneamente in condizioni di accettarli (buffer pieno).
STALL per informare l’host di non ritrasmettere i dati a causa di un errore nello stato del device.
Nessun handshake verrà inviato se il pacchetto viene ricevuto con un errore di CRC o di bit stuff,.
L’host inizia sempre la prima transizione sul bus con un PID DATA0, la seconda invece usa un PID
DATA1, le successive saranno alternate in questo modo (data toggle).
Il trasferimento dei controlli avvengono in due fasi di transizione dette Setup e Status.
Durante una fase di Setup, la transizione di Setup è usata per trasmettere delle informazioni
all’endpoint di controllo del device. Nella transizione di Setup si usa sempre un PID DATA0.
Il device che riceve un Setup deve sempre accettare i dati di Setup e rispondere con un handshake
ACK, se corretti, altrimenti ignorare i dati e non inviare alcun handshake.
La fase di Status è l’ultima operazione della sequenza. Questa fase è realizzata con un cambiamento
di direzione del flusso dati rispetto alla fase precedente e usando sempre il PID DATA1.
Il contenuto della fase di Status può essere di tre tipi:
la sequenza dei comandi è stata completata con successo (ACK)
la sequenza dei comandi non viene completata (STALL)
il device è ancora occupato a completare la sequenza dei comandi (NAK)
Transizioni interrupt
Quando un endpoint usa il trasferimento interrupt per i dati relativi all’interrupt, è necessario far uso
del protocollo data toggle che sarà inizializzato con un PID DATA0.
Un interrupt può anche essere usato da un endpoint per comunicare la successiva velocità di ritorno
delle informazioni in modo isocrono, cambiando i bit di data toggle dopo che ogni pacchetto e stato
inviato all’host.
Transizioni isocrone
Data toggle
L’interfaccia USB dispone di un meccanismo per garantire la corretta sincronizzazione tra i dati
trasmessi e ricevuti con delle transizioni multiple, consentendo la corretta interpretazione della fase
di hanshake da parte del trasmettitore e del ricevitore.
La sincronizzazione è ottenuta per mezzo dei PID DATA0 e DATA1 e di separate sequenze di bit
di data toggle per i dati trasmessi e ricevuti.
La sequenza di bit ricevuti viene commutata (toggle) solo quando il ricevitore ha accettato il
pacchetto dati privo di errori con un corretto PID.
La sequenza di bit trasmessi viene commutata (toggle) solo quando i dati trasmessi ricevono un
ACK valido.
I dati trasmessi o ricevuti devono presentare la loro sequenza di bit di sincronizzazione all’inizio
della transizione. La sincronizzazione toggle non è disponibile nel trasferimento isocrono.
Transizioni successive
Un caso particolare è quello relativo alla ricezione di un ACK errato nonostante che il pacchetto
dati sia stato trasmesso, ricevuto e poi accettato correttamente dal device.
Come si può vedere dalla figura, al termine della transizione i-esima vi è una momentanea perdita
di coerenza tra trasmettitore e ricevitore a causa della non corrispondenza tra le sequenze di bit.
Nella successiva transizione, il trasmettitore rimanda il precedente pacchetto di dati facendo uso
dello stesso PID DATA0.
La sequenza di bit ed il data PID non risulteranno coincidenti, da ciò il ricevitore si rende conto di
aver in precedenza già accettato lo stesso pacchetto dati. Di conseguenza ignora il pacchetto
ricevuto e non commuta la sequenza di bit.
A questo punto il ricevitore emette un ACK che permetterà al trasmettitore di capire che la
transizione si è conclusa con successo. Tutto ciò consentirà al trasmettitore di commutare la
sequenza di bit e procedere alla successiva transizione usando un DATA1 PID.
Il trasmettitore deve sempre garantire che il pacchetto dati ritrasmesso risulti della stessa lunghezza
di quello originario. Se il trasmettitore non è in grado di dare questa garanzia (per es. a causa di
buffer underrun), esso deve abortire la transizione generando una violazione di bit stuffing che sarà
interpretata dal ricevitore come un errore.
Un altro tipo di errore è quello di time out che viene segnalato dopo i 18 bit time.
Se l’host vuole indicare un errore di time out, deve aspettare almeno 18 bit time prima di emettere il
successivo token.
Come per le versioni Non Super Speed, utilizza una topologia a stella con un host, che si collega ad
uno o più hub che, a loro volta, connettono uno o più devices.
La compatibilità è mantenuta anche dal punto di vista della connessione meccanica la quale
consente il collegamento di devices Super Speed e Non Super Speed.
I connettori upstream e downstream non sono meccanicamente intercambiabili al fine di evitare
connessioni illegali di loopback sugli hub.
La prima sostanziale differenza risiede nel cavo di collegamento che è costituito da otto conduttori
principali: tre coppie twisted per i segnali che trasportano i dati ed una coppia per l’alimentazione.
Le due nuove coppie per la versione Super Speed (SS), sono usate una per la trasmissione ed una
per la ricezione dei dati operando pertanto in modalità full duplex.
La terza coppia trasporta i dati per le versioni Non Super Speed in modalità half duplex.
Max 5 metri
1 VBus
2 D+
3 D-
9 SSRX+
8 SSRX-
6 SSTX+
5 SSTX-
4 Power GND
7 Signal GND
Shield
Come già esposto, USB 3.0 consente l’attacco e il distacco dei devices in qualsiasi istante, di
conseguenza il system software sarà in grado di riconfigurare dinamicamente tutta la topologia
fisica del bus ad ogni variazione.
Il metodo di rilevazione dell’attacco o del distacco dei devices è identico a quello della USB 2.0.
USB 3.0 ha una architettura a doppio bus che contiene sia il bus USB2.0 che quello USB3.0.
Interconnessioni Super Speed: definiscono le modalità con le quali i devices vengono connessi e
comunicano con l’host attraverso il bus Super Speed. Sono incluse la topologia delle connessioni
dei devices, lo stack di comunicazione, le relazioni tra essi e le interazioni al fine di realizzare lo
scambio di informazioni tra host e devices.
Devices: rappresentano le sorgenti o i destinatari delle informazioni scambiate tra un driver
dell’host e la funzione del device.
Host: rappresenta la sorgente o il destinatario delle informazioni gestendo tutti i devices collegati.
Strato Fisico
Lo strato fisico definisce le connessioni tra la porta di downsteam dell’host o hub e la porta di
upstream del device. La connessione fisica è costituita da due coppie differenziali twisted, una per
la ricezione ed una per la trasmissione con un data rate di 4.8 Gbps.
Il canale di collegamento differenziale è unidirezionale ed è detto differential link.
Ognuno di questi due link è accoppiato in AC per mezzo di condensatori posti nel trasmettitore.
In corrispondenza di un preciso livello di tensione, il link differenziale viene inizializzato abilitando
il ricevitore collegato. Il trasmettitore ha il compito di rilevare la connessione di un ricevitore per
mezzo di una indicazione del bus così da consentirne allo strato link la gestione.
D+ D-
Strato Link
Un link Super Speed rappresenta una connessione logica e fisica di due porte che vengono chiamate
link partners. Una porta è dotata di una parte fisica e una parte logica.
Lo strato link definisce la porzione logica di una porta e la comunicazione tra i link partners.
• Stato macchina: per la gestione della sua parte finale di connessione che comprende
l’inizializzazione e la gestione degli eventi come connessione, distacco e alimentazione.
• Stato macchina e buffer: per la gestione dello scambio di informazioni tra i link partners e
comprende i protocolli per il controllo di flusso, l’affidabile recapito degli header dei pacchetti e
la gestione dell’alimentazione.
• Buffering dei dati e delle informazioni dello strato protocol.
definire il corretto framing della sequenza di byte nei pacchetti durante la trasmissione inserendo i
delimitatori dei pacchetti
rilevare i pacchetti ricevuti e gli eventuali errori negli header
definire una opportuna interfaccia con lo strato protocollo.
Lo stato fisico dota la porta logica di una interfaccia per mezzo della quale:
• Gestisce lo stato della parte fisica con l’inclusione della gestione dell’alimentazione e degli
eventi quali connessione, distacco e uscita dallo stato idle.
• Trasmettere e ricevere la sequenza di byte con i segnali di controllo necessari per differenziare la
sequenza di dati da quella dei controlli. Una porta è abilitata alla simultanea trasmissione e
ricezione di dati e controlli.
Il protocollo tra i link partners usa una specifica codifica per le sequenze di controllo che consente
di tollerare l’errore su un singolo bit.
Strato protocol
Lo strato protocol definisce le regole della comunicazione end to end tra l’host e l’endpoint del
device per mezzo di un canale detto pipe e sotto la supervisione dell’host.
L’USB Super Speed non opera su base polling in quanto ogni device è in grado, per conto di un suo
endpoint, di emettere una richiesta asincrona di asservimento verso l’host.
Tutte le comunicazioni dello strato protocol si realizzano per mezzo dello scambio di pacchetti
costituiti da una sequenza di byte con opportuni controlli che vengono poi gestiti dallo strato link.
I pacchetti trasmessi dall’host sono instradati (routing) attraverso gli hub o direttamente al device.
I pacchetti non attraversano quindi tutti i percorsi ma solo quelli che conducono alla destinazione
definita snellendo così il flusso dati.
I pacchetti hanno dimensioni fisse con header, campi e sottocampi codificati per le specifiche
funzioni.
Un piccolo record con un pacchetto header è utilizzato dallo strato link (port to port) per gestire il
flusso dei pacchetti port to port. I restanti campi sono usati invece dal protocollo end to end.
I dati delle applicazioni Sono trasmessi in un pacchetto payload dotato di una specifico header.
I pacchetti payload non consentono una consegna affidabile attraverso lo strato link (al contrario
dell’header che ha una consegna affidabile).
Lo strato protocol consente però una consegna affidabile dei pacchetti per mezzo dei pacchetti di
acknowledgement e la eventuale ritrasmissione dei pacchetti errati.
Questa tecnica non è disponibile per tutti i tipi di informazioni.
Questo protocollo consente una efficiente utilizzazione del bus per mezzo della contemporanea
trasmissione e ricezione sul link: un trasmettitore può trasmettere una raffica (burst) di pacchetti
multipli di dati mentre il ricevitore trasmettere i vari acknowledgement senza interrompere il burst
dei pacchetti di dati.
Il protocollo in oggetto provvede anche al controllo di flusso per alcuni tipi di trasferimento.
Dal punto di vista dell’integrità dei dati trasmessi, l’interfaccia USB 3.0 è caratterizzata dai seguenti
aspetti:
Lo strato fisico della USB 3.0 consente un bit error rate inferiore a 1 su 1012 bit.
Ogni pacchetto è corredato da un controllo di CRC per la rilevazione di errori multipli e relative
procedure di recupero dell’errore implementate in hardware o software.
Il protocollo prevede l’utilizzo di CRC separati per header e dati ed eventualmente anche per il link
control word. Un errore nell’header o nel link control word è considerato di elevata gravità e
determinerà un intervento del livello link per il suo recupero.
Un errore di CRC nel pacchetto dati sarà gestito dallo strato protocol con una richiesta di
ritrasmissione del pacchetto stesso.
Gli strati link e fisico cooperano per assicurare una affidabile trasmissione dei pacchetti header.
Un host USB 3.0 proverà a ritrasmettere dati risultati errati per tre volte prima di informare il client
del software applicativo del fallimento della consegna.
Power management
L’interfaccia USB 3.0 consente una articolata gestione dell’alimentazione (power management) dei
vari dispositivi connessi a diversi livelli: link, device e function come esposto nel modello.
Questi livelli di gestione dell’alimentazione non sono strettamente collegati ma hanno delle
dipendenze.
Il livello link controlla localmente, in modo asincrono tutti, i link connessi. Le politiche di gestione
a livello link possono essere condizionate dall’inattività del device o della porta di downstream per
mezzo di timer programmati dal software dell’host.
Lo stato dell’alimentazione viene poi propagato verso l’host dagll’hub.
I link che non sono utilizzati per scambio di informazioni, sono posti al più basso livello di
alimentazione.
L’host non ha il diretto controllo dello stato di alimentazione del singolo link, questo implica che
uno o più link nel percorso tra host e device possono trovarsi in uno stato di basso livello di
alimentazione quando l’host inizia la comunicazione sul bus. Esistono pertanto dei meccanismi di
protocollo che forzano questi link a passare nello stato operativo e notificare all’host il passaggio.
La gestione dello stato di sospensione di un device è simile a quello della USB 2.0.
Nei dispositivi multifunzione (compound) ogni funzione può essere indipendentemente posta nello
stato di bassa alimentazione.
Tutti i devices Super Speed condividono la stessa architettura base della USB 2.0
Durante la fase di BUS enumeration, l’host provvede ad assegnare ad ogni devices un proprio
indirizzo.
Ogni devices dispone di una o più pipe attraverso le quali l’host comunica con i devices.
Tutti i devices devono disporre di un Endpoint 0 al quale è collegata la Default Control Pipe.
Tutti i devices devono supportare un comune meccanismo di accesso alla Control Pipe.
-----
Un device USB 3.0 deve disporre del necessario supporto per la comunicazione Super Speed e
NON Super Speed mantenendo così la compatibilità con qualsiasi tipo di host.
La struttura del device deve consentire la piena funzionalità quando opera in modo NON Super
Speed.
Non è consentito ad un device di operare simultaneamente in modo Super Speed e NON Super
Speed.
Come per la USB 2.0, un device USB 3.0 può contenere in un unico package diverse funzioni (2.0 o
3.0) con un unico hub integrato e permanentemente collegato.
--------------
L’hub è un elemento chiave dell’architettura USB in quanto consente un semplice meccanismo di
ampliamento della rete di devices collegabili per mezzo delle sue porte di downstream.
Un hub USB 3.0 è costituito dalla combinazione di due hub: uno USB 2.0 ed uno Super Speed ed
ognuno connesso ad una propria linea dati.
L’hub Super Speed gestisce la porta di downstream della parte Super Speed mentre l’hub USB 2.0
gestisce la porta di downstream della parte USB 2.0.
Ognuna delle due porte ha un proprio registro di controllo e di stato.
Un hub Super Speed consiste di due componenti logici: un controller ed un repeater Super Speed.
Il repeater è un router che controlla il protocollo tra le porte di upstream e downstream e dispone
dell’hardware per le segnalazioni di reset, suspend e resume.
Il controller gestisce i comandi di stato e controllo usati dall’host per configurare l’hub e monitorare
e controllare le sue porte.
L’hub Super Speed concorre alla gestione del protocollo end-to-end con le seguenti attività:
USB Super Speed è molto simile alla USB 2.0 mantenendone l’architettura a strati e gli elementi di
base del flusso di comunicazione(endpoint, pipe e tipi di trasferimento).
Le caratteristiche dell’endpoint sono contenute nel Super Speed Endpoint Conpanion Descriptor.
Come per l’USB 2.0, l’endpoint è identificato per mezzo di un indirizzo triplo (device Addres,
Endpoint Number, Direction). Tutti i devices Super Speed devono disporre di almeno un endpoint
(Default Control Pipe) detto Endpoint 0.
Una pipe Super Speed è una associazione tra un endpoint di un device e il software sull‘host ed ha
la stessa funzionalità di una pipe USB 2.0.
La principale differenza rispetto alla USB 2.0 consiste nel fatto che quando un endpoint non
isocrono è occupato esso risponde con un Not Ready (NRDY) e dovrà poi inviare una notifica di
Endpoint Ready (ERDY) quando avrà bisogno di essere asservito.
Tutti i tipi di trasferimento della USB 2.0 sono supportati dal protocollo Super Speed.
Pur restando compatibile con la USB 2.0, la USB Super Speed presenta le seguenti differenze:
• USB 2.0 usa transizioni fatte da tre parti (Token, Data ed Hadshake) mentre la Super Speed
usa le stesse tre parti ma in modo differente. Per l’OUT il token è incorporato nel pacchetto
dati mentre per l’IN il token è sostituito da un handshake.
• La USB 2.0 non supporta il bursting mentre la Super Speed supporta il bursting continuo.
• La USB 2.0 ha un bus broadcast half-duplex mentre la Super Speed ha un bus unicast-dual
simplex che consente contemporanee transazioni IN e OUT.
• La USB 2.0 usa un modello a polling mentre la Super Speed usa notifiche asincrone.
• La USB 2.0 non ha lo streaming mentre la Super Speed supporta lo streaming per endpoint
bulk.
• Super Speed consente ai device isocroni di entrare autonomamente nello stato di low power
negli intervalli tra i servizi.
• Super Speed dispone di un meccanismo che consente ai devices di informare l’host della
propria tolleranza di latenza per mezzo dei Latency Tolerance Messaging usati dal sistema
delle politiche di gestione dell’alimentazione.
• La USB 2.0 trasmette lo SOF a intervalli fissi di 1 mSec o 125 µSec mentre la USB Super
Speed dispone di un meccanismo con il quale i devices possono inviare un Bus Interval
Adjustment Message che è usato dall’host per calibrare il suo bus interval di 125 µSec fino a
±13.333 µSec.
• La USB 2.0 gestisce la rilevazione di errori, il loro recupero e il controllo di flusso solo al
livello end-to-end per ogni transizione mentre la Super Speed ripartisce queste funzioni tra i
due livelli end-to-end e link.
La USB Super Speed con il suo strato fisico dual simplex consente il simultaneo trasporto di
informazioni nelle due opposte direzioni, questo si traduce nella possibilità, per il trasmettitore, di
inviare pacchetti multipli di dati prima di ricevere i rispettivi handshake.
Per il trasferimento OUT, le informazioni prima contenute nel Token USB 2.0 sono ora incorporate
nell’header del pacchetto dati così da non richiedere un ulteriore Token.
Per il trasferimento IN, un handshake è inviato al device che ha richiesto i dati, il device potrà
rispondere inviando i dati oppure uno STALL handshake o un Not Ready (NRDY) handshake per
differire il trasferimento fino a quando non sarà pronto.
Il metodo polling usato dalla USB 2.0 viene ora sostituito dalla notifica asincrona.
Una transizione Super Speed viene iniziata dall’host per mezzo di una richiesta alla quale
corrisponderà una risposta dal device.
Se il device può asservire la richiesta, accetterà o invierà i dati.
Se l’endpoint è invece in halt, risponderà con uno STALL handshake.
Se il device non è in condizione di asservire la richiesta (perché non dispone di dati o per mancanza
di spazio nel buffer), risponderà con un Not Ready (NRDY). Quando il device sarà poi pronto ad
asservire la richiesta, invierà un Endpoint Ready (ERDY) all’host il quale riavvierà la transizione.
I pacchetti USB Super Speed iniziano con un header da 16 byte (alcuni pacchetti sono costituiti dal
solo header).
Tutti gli header iniziano con delle informazioni descrittive del tipo di pacchetto che ne stabilisce il
tipo di utilizzo.
La parte finale dell’header è costituita da 2 byte di link control e 2 byte di CRC16 di protezione.
In funzione della tipologia, i pacchetti contengono informazioni per il routing (Route String) ed un
triplo indirizzo per il device di destinazione (device address, endpoint num, direction).
La Route String è usata per definire il preciso percorso tra trasmettitore e ricevitore.
Esistono quattro tipi di pacchetti:
• Link Management Packet (LMP) che scorre solo tra una coppia di porte direttamente
connesse ed è principalmente usato per la gestione del link.
• Transaction Packet (TP) il quale attraversa tutti i link lungo il percorso che connette l’host
con il device. È usato per il controllo di flusso dei pacchetti di dati, per la configurazione di
hub e device ecc. Questi pacchetti non hanno dati payload.
• Data Packet (DP) il quale attraversa tutti i link lungo il percorso che connette l’host con il
device. Un Data Packet consiste di due parti: un Data Packet Header (DPH) che è simile ad
un TP ed un Data Packet Payload (DPP) che è costituito da un blocco di dati più 4 byte di
CRC32.
• Isochronous Timestamp Packet (ITP) che è un pacchetto multicast inviato dall’host a tutti i
link attivi.
Data Bursting
Lo scambio dati in modo burst aumenta l’efficienza eliminando i tempi di attesa per gli
acknowledgement dei pacchetti.
Ogni endpoint di un device Super Speed contiene il valore del numero di pacchetti che può inviare
o ricevere (maximum data burst size) senza attendere un esplicito handshake.
Ogni endpoint ha il proprio maximum data burst size.
L’host può modificare dinamicamente la dimensione del burst size per transizione senza però
superare il massimo valore.
Trasferimento IN
L’host inizia un trasferimento inviando una raffica (burst) di pacchetti dati al device.
Ogni pacchetto dati contiene le informazioni di indirizzamento necessarie all’instradamento (route)
del pacchetto verso l’endpoint di destinazione con l’inclusione del numero di sequenza.
Per le transazioni non isocrone, il device risponde con un pacchetto di acknowledgement che
include il numero di sequenza del successivo pacchetto confermando implicitamente il pacchetto
corrente.
Si evidenzia che sebbene il device debba inviare un pacchetto di acknowledgement per ogni
pacchetto dati ricevuto, l’host può comunque inviare al device un numero (fino al maximum burst
size number) di pacchetti dati senza aspettare l’acknowledgement.
Power management
Quando un host invia un pacchetto ad un device attraverso un hub con una porta il cui link è in uno
stato non attivo (low power state), il pacchetto non potrà attraversare il link finché questo non
ritorna nello stato attivo. Nel caso di una transizione IN, l’host non sarà in grado di avviare la
successiva transizione fino al completamento di quella corrente.
L’effetto di questo meccanismo può determinare un grave degrado delle prestazioni.
Per compensare il meccanismo di power management ed ottenere buone prestazioni si utilizza la
tecnica del differimento temporale.
Quando un host inizia una transizione che coinvolge un link non attivo, l’hub intermedio risponde
con una richiesta di differimento della transizione causata dallo stato di low power del device ed
invitando l’host a procedere ad un altra transizione.
Contemporaneamente l’hub comunica al device di aver generato una richiesta di differimento
causata da un tentativo di avvio di una transizione.
Con questo meccanismo è possibile migliorare le prestazioni medie dovute al link power
management.
Controllo di trasferimenti
Il controllo dei trasferimenti nella USB 3.0 è identico a quello della USB 2.0.
Ogni device dovrà disporre di Default Control Pipe usata per l’inzializzazione e gestione del device
per mezzo delle informazioni predisposte nel descrittore del device (Endpoint 0).
Il sistema Super Speed offre il miglior supporto possibile per la consegna dei controlli di
trasferimento tra host e device. Come per la USB 2.0 non è possibili prenegoziare l’ampiezza di
banda per lo scambio dei controlli di trasferimento.
Il massimo valore del payload per i dati del controllo di trasferimento è fisso e pari a 512 byte con
un burst massimo unitario.
Un device Super Speed deve contenere un valore pari a 09H nel campo MaxPacketSise del suo
descrittore di device.
La Default Control Pipe deve poter supportare un valore massimo di sequenza compreso tra 0 e 31.
Gli obiettivi e le caratteristiche del trasferimento bulk USB 3.0 sono simili a quelle della USB 2.0.
Il trasferimento bulk è utilizzato per quei device che scambiano grandi quantità di dati con
temporizzazione altamente variabile con qualsiasi disponibilità di banda.
In pratica garantisce la consegna dei dati ma non garantisce i ritardi e la banda.
Le caratteristiche di una pipe bulk risultano:
nel flusso di comunicazione i dati non hanno alcuna particolare struttura,
una pipe bulk è una pipe di tipo stream e quindi il flusso di comunicazione da o per l’host è
unidirezionale. Se una applicazione richiede un flusso di comunicazione bulk bidirezionale,
dovranno essere usate due pipe bulk una IN ed una OUT.
Un endpoint per un trasferimento bulk fissa nel suo descrittore di endpoint un valore del maximum
data packet payload di 1024 byte. Viene anche specificata la dimensione del burst che l’endpoint
può accettare, questo valore sarà compreso tra 1 e 16.
Tutti gli endpoint bulk dovranno supportare valori di sequenza compresi tra 0 e 31.
L’host dovrà essere in grado di gestire qualsiasi endpoint bulk con qualsiasi dimensione del burst.
L’host dovrà assicurare che nessun payload di dati inviato ad un endpoint con una transizione burst
sia più grande del maximum data packet payload e che non siano inviati più pacchetti di quelli
specificati dal maximum burst size.
Se in un trasferimento bulk vi sono più di 1024 byte di dati, questi saranno suddivisi in blocchi da
1024 byte tranne l’ultimo che conterrà i restanti.
Un trasferimento bulk sarà completato quando per l’endpoint si verifica:
il trasferimento della quantità di dati attesi,
il trasferimento di un pacchetto con meno di 1024 byte,
una risposta con uno STALL handshake.
Come per la USB 2.0, un endpoint bulk non ha alcun modo di indicare un desiderato valore di
ampiezza di banda per la pipe bulk e dovrà far uso della sola banda disponibile.
La USB Super Speed garantisce però un buon risultato per la consegna dei dati bulk.
Come per la USB 2.0, anche la USB Super Speed consente il trasferimento bulk stream per mezzo
di un protocollo che consente il multi stream.
Le stream trasferite tra host e device sono gestite da uno Stream Protocol il quale assegna ad ogni
stream una Stream ID (SID).
Il protocollo stream definisce un handshake il quale consente al device o all’host di definire una
Current Stream (CStream) ID associata ad un endpoint.
L’host usa la CStream ID per selezionare un comando o una operazione su uno specifico buffer
dell’endpoint che sarà usato per il successivo trasferimento sulla pipe.
Il device usa la CStream ID per selezionare il buffer dei dati che sarà usato.
Lo streaming dei dati avverrà quindi con un multiplessaggio dei dati nei vari buffer definiti per
mezzo delle CStream ID degli endpoint.
Un endpoint bulk standard ha un singolo insieme di buffer endpoint ad esso associati.
Lo streaming estende il numero di buffer host accessibili da un endpoint da 1 a 65533 con una
corrispondenza uno a uno tra buffer host e Stream ID.
Le caratteristiche del trasferimento interrupt USB 3.0 sono simili a quelle della USB 2.0.
Il trasferimento interrupt Super Speed è orientato a supportare device che richiedono un
trasferimento molto affidabile di piccole quantità di dati in limitati intervalli di tempo.
I trasferimenti interrupt vengono tentati (in modo isocrono) a intervalli predefiniti dall’endpoint.
Una volta che un trasferimento è stato effettuato con successo, non verrà effettuato un altro
tentativo fino al prossimo intervallo di sevizio.
Se un endpoint risponde con un not ready o con un ACK che indichi l’impossibilità ad accettare
altri pacchetti, l’host non tenterà altri trasferimenti verso l’endpoint fino alla notifica di ready e la
successiva attesa di un tempo pari al doppio dell’intervallo di servizio.
L’intervallo di servizio di un endpoint è riportato nel suo descrittore di endpoint.
Si rammenta che una pipe interrupt è una una pipe stream e pertanto è unidirezionale.
Nel trasferimento interrupt l’endpoint specifica la massima dimensione del pacchetto payload che
può essere movimentata sul bus.
La massima dimensione del payload è fissata a 1024 byte per endpoint che supportano dimensione
del burst maggiore di uno. La massima dimensione del burst per l’interrupt endpoint è pari a tre.
Tutti gli endpoint interrupt dovranno supportare valori di sequenza compresi tra 0 e 31.
Un host dovrà essere in grado di gestire tutte le possibili combinazioni di dimensioni di pacchetti e
dimensioni di burst nei trasferimenti interrupt senza mai superare quelle massime.
Nei trasferimenti di maggiori quantità di dati, tutti i payload dei vari burst dovranno essere della
massima dimensione consentita tranne l’ultimo che conterrà i restanti dati.
Un trasferimento interrupt sarà completato quando per l’endpoint si verifica:
il trasferimento della quantità di dati attesi,
il trasferimento di un pacchetto con un payload avente meno di 1024 byte,
una risposta con uno STALL handshake.
Nel trasferimento interrupt può essere allocata fino all’80% della banda disponibile.
Il descrittore di endpoint di una pipe interrupt specifica la durata dell’intervallo di servizio
desiderato il cui valore è dato da 2(bInterval-1) * 125 µSec con bInterval compreso tra 1 e 16.
Il System Software USB usa questa informazioni in fase di configurazione per definire il periodo di
servizio, il periodo definito dal System Software può essere più piccolo di quello desiderato dal
device fino al valore più piccolo definito dalla USB Super Speed (125 µSec).
Un Super Speed endpoint interrupt può trasferire fino ad un massimo di 3 pacchetti della massima
dimensione (1024 byte) per ogni intervallo di servizio.
Se un interrupt di un endpoint IN non ha dati da trasmettere o un interrupt endpoint OUT non ha
sufficiente spazio buffer per ricevere i dati durante l’accesso da parte dell’host, questo risponderà
con un messaggio di controllo di flusso.
Le caratteristiche del trasferimento isocrono USB 3.0 sono simili a quelle della USB 2.0.
Il trasferimento isocrono è usato per la movimentazione di dati che devono arrivare con la stessa
cadenza temporale con la quale sono stati generati (audio, video, telefonia ecc.).
Ogni errore in trasmissione non può essere corretto ne ritrasmesso.
A differenza della USB 2.0, la USB 3.0 non trasmette il campo di start of frame ma invia al device
le informazioni di temporizzazione per mezzo dell’Isochronous Timestamp Packet (ITP).
Una pipe isocrona Super Speed è una pipe stream e quindi è unidirezionale.
Se il device necessita di un flusso di comunicazione isocrono bidirezionale, si dovranno usare due
pipe isocrone, una per ogni direzione.
Il power management della Super Speed può interferire con il trasferimento isocrono quando i
pacchetti hanno bisogno di attraversare un link non attivo determinando un ritardo che non farà
arrivare i dati nell’intervallo di sevizio.
Questo problema viene risolto per mezzo di un meccanismo di PING e PING RESPONSE.
Prima di iniziare un trasferimento isocrono l’host invia al device un pacchetto di PING al quale il
device risponderà con un pacchetto di PING RESPONSE per confermare all’host che tutti i link
lungo il percorso sono nello stato attivo.
La massima dimensione del payload è fissata a 1024 byte per endpoint che supportano dimensione
del burst maggiore di uno. La massima dimensione del burst per un endpoint isocrono è pari a 16
anche se un endpoint isocrono può richiedere fino tre transizioni burst per ogni intervallo di sevizio.
Il protocollo Super Speed non richiede che il pacchetto dati isocrono sia della dimensione massima,
nel caso di trasferimento di un pacchetto dati di dimensioni inferiori a quella massima, questo non
sarà sottoposto a padding.
Un host dovrà essere in grado di gestire tutte le possibili combinazioni di dimensioni di pacchetti e
dimensioni di burst nei trasferimenti isocroni senza mai superare quelle massime.
L’host deve assicurare che nessun payload di pacchetto dati sia più grande della massima
dimensione consentita e analogamente per la massima dimensione del burst.
Nei trasferimenti di maggiori quantità di dati, tutti i payload dei vari burst dovranno essere della
massima dimensione consentita tranne l’ultimo che conterrà i restanti dati.
Nel trasferimento isocrono può essere allocata fino all’80% della banda disponibile.
Il descrittore di endpoint di una pipe isocrona specifica la durata dell’intervallo di servizio
desiderato il cui valore è dato da 2(bInterval-1) * 125 µSec con bInterval compreso tra 1 e 16.
Il System Software USB usa questa informazioni in fase di configurazione per definire il periodo di
servizio.
Un Super Speed endpoint isocrono può trasferire fino ad un massimo di 3 transizioni burst con un
massimo di 16 pacchetti della massima dimensione (1024 byte) per ogni intervallo di servizio.
Se un endpoint isocrono non ha dati da trasmettere durante l’accesso da parte dell’host, in risposta
alla richiesta invierà un pacchetto di lunghezza nulla.
Un endpoint isocrono trasmette i pacchetti di dati partendo dalla sequenza numero zero per ogni
intervallo di servizio, ogni successivo pacchetto dati trasmesso nello stesso intervallo di sevizio è
inviato con il più alto numero di sequenza, successivamente la numerazione sarà invertita da 31 a 0.
Esistono diversi livelli di protezione per assicurare una affidabile consegna dei dati:
• Lo strato fisico della USB 3.0 assicura un bit error rate minore di 1 bit su 1012.
• Lo strato link della USB 3.0 ha un meccanismo che assicura un bit error rate minore di 1 bit
su 1020 per l’header del pacchetto. Per assicurare la consegna affidabile end to end
dell’header, lo strato link utilizza il framing ordinato dei pacchetti, il controllo di flusso e la
ritrasmissione.
• Lo strato protocol della USB 3.0 utilizza un CRC a 32 bit per il controllo dei dati del
payload ed una ritrasmissione su timeout.
Qualsiasi transizione Super Speed è sempre iniziata dall’host con una richiesta o un invio di dati
all’endpoint di un device e si conclude quando l’endpoint invia i dati o ne conferma la ricezione.
Un host Super Speed può iniziare una o più transizioni OUT verso uno o più endpoint mentre è in
attesa del completamento della transizione corrente.
Per contro, un host Super Speed non potrà iniziare una nuova transizione IN verso alcun endpoint
finché l’host:
• riceve un DP oppure un NRDY oppure uno STALL DP oppure un time out per il corrente
ACK TP inviato ad un endpoint non isocrono
• riceve tutti i DP che erano stati richiesti oppure uno short packet oppure un DP con l’ultimo
pacchetto con il flag di campo settato oppure un time out per il corrente ACK TP inviato ad
un endpoint non isocrono.
Per un trasferimento non isocrono, un endpoint può rispondere ad una transizione valida:
• ritornando un pacchetto di transizione NRDY
• nel caso di una transizione OUT, ritornando un pacchetto ACK
• nel caso di una transizione IN, ritornando uno o più pacchetti dati
• nel caso di un errore interno all’endpoint, ritornando un pacchetto di STALL.
Una risposta con un pacchetto NRDY indica che l’endpoint non è pronto a ricevere o inviare dati.
Ciò implica che non ci potrà essere alcuna attività tra l’host e l’endpoint del device finché
l’endpoint stesso non notifica il suo stato di pronto.
Questa situazione consente al link che collega l’host al device di entrare nello stato di low power
finché l’endpoint non passerà nello stato di pronto.
Quando l’endpoint sarà pronto invierà asincronamente all’host una notifica di ERDY per
comunicare la sua disponibilità a movimentare i dati.
Si noti che nei trasferimenti isocroni non si usano i pacchetti NRDY e ERDY in quanto gli
asservimenti avvengono a intervalli periodici e che i pacchetti inviati o ricevuti non vengono
confermati con un ACK.
Le transizioni non sono broadcast in quanto i pacchetti sono instradati su un percorso che collega
direttamente l’host al device. I link non usati possono essere posti nello stato di low power.
L’interfaccia USB 3.0 utilizza quattro tipi di pacchetti con uno o più sottotipi.
• Link Management Packets (LMP) utilizzato per la gestione del link ed in grado di viaggiare
solo tra coppie di link che connettono due porte.
• Transaction Packets (TP) usati per il controllo di flusso dei pacchetti dati, configurare
device e hub. Viaggiano su tutti i link che connettono host e device.
• Data Packets (DP) viaggiano su tutti i link che connettono host e device. Sono costituiti da
due parti: Data Packet Header (DPH) e Data Pachet Payload (DPP).
• Isochronous Timestamp Packets (ITP).
Tutti i pacchetti sono costituiti da un totale di16 byte dei quali 12 byte di header seguiti da 2 byte di
Link Control Word e conclusi con due byte di CRC 16 calcolati sui 12 precedenti byte e che
consentono un error rate minore di 1020 bit.
Tutti gli header hanno due campi comuni (Revision e Type) usati dal ricevente per stabilire le
modalità di processamento del pacchetto.
Se il valore del campo Type corrisponde a un Transaction Packet o a un Data Packet Header, il
campo Type è successivamente seguito dal campo Route String e dal campo Device Address.
Il campo Route String è usato dagli hub per instradare il pacchetto mentre il campo Device Address
è usato dall’host per conoscere la sorgente del pacchetto.
I pacchetti Data Packets contengono nell’header informazioni aggiuntive che descrivono alcune
caratteristiche del blocco dati.
Il blocco dati (Data Block) è sempre seguito da 4 byte di CRC 32 usati per verificare la correttezza
dei dati. Il Data Block ed il CRC 32 costituiscono il Data Packet Payload (DPP).
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Device Address Route String Type
Reserved Seq Num NumP HE RSVD Ept Num D rty Rsvd Sub Type
Reserved PP Reserved Stream ID / Reserved
Link Control Word CRC 16
Esempio di Transaction Packet
Il campo Type è costituito da 5 bit che identificano il formato del pacchetto con i seguenti valori:
Valore Descrizione
00000 Link Management Packet
00100 Transaction Packet
01000 Data Packet Header
01100 Isochronous Timestamp Packet
Tutti gli altri valori sono riservati
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CRC 5 (bit 0 ... 11) DF DL HUB Depth R Header Seq
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Sub Type Specific Sub Type Type
Sub Type Specific
Sub Type Specific
Link Control Word CRC 16
Link Management Packet
Il pacchetto Set Link Function dell’LMP è usato per configurare la funzionalità senza lasciare lo
stato attivo (U0). Questo pacchetto è inviato dall’hub ad un device connesso ad una specifica porta.
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved Set Link Function Sub Type Type
Reserved
Reserved
Link Control Word CRC 16
Set Link Function LMP
Il campo Set Link Function è costituito da 7 bit ma si usa solo il bit 1 del campo mentre i bit
0,2,3,4,5,6 sono Reserved. Il valore 0 indica De-assert, il vaolore 1 indica Assert.
U2 Inactivity Timeout
Il campo U2 Inactivity Timeout dell’LMP è usato per definire il timeout dallo stato U1 a quello U2
o il timeout dallo stato U0 a quello U2 se lo stato U1 è disabilitato.
Il campo Vendor Device Test dell’LMP è riferito al produttore del device e non è usato durante la
normale attività del link. I 64 bit dei campi Vendor Specific Data sono definiti dal produttore.
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved Vendor Device Test Sub Type Type
Vendor Specific Data
Vendor Specific Data
Link Control Word CRC 16
Vendor Device Test LMP
Port Capability
Il pacchetto Port Capability LMP descrive le capacità di ogni porta del link ed è inviato da
entrambi i link partner dopo l’inizializzazione e avviamento del link.
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved Link Speed Sub Type Type
Reserved Tiebreaker Rserv D Reserved Num HP Buffers
Reserved
Link Control Word CRC 16
Port Capability LMP
Il bit 9 del campo Link Speed se posto a 1 indica che il device supporta segnali a 5 Gbps
Il campo Num HP Buffers specifica il numero di buffer per i pacchetti header, per la USB 3.0 il
valore riportato è 4, tutti gli altri valori sono riservati.
I bit 16 e 17 del campo D (Direction) definiscono la capacità della porta di essere downstream o
upstream per mezzo del settaggio al valore 1 . Un solo bit può essere usato.
Questo campo è valido solo quando entrambi i bit del campo D sono posti a 1. Questo campo è
usato per determinare il tipo di porta quando vengono connessi due device con entrambe le capacità
di downstream e upstream. Quando entrambe le porte sono in downstream, solo quella con il più
alto valore di questo campo sarà effettivamente di downstream.
In tutti gli altri casi questo campo è posto a zero.
I pacchetti transaction (TP) viaggiano direttamente sul percorso che collega l’host al device e sono
usati per il controllo del flusso dati e la gestione della connessione end to end.
Il campo Route String è usato dagli hub per instradare i pacchetti che, arrivando sulla porta di
upstream, saranno canalizzati verso la corretta porta di downstream. Questo campo sarà posto a zero
per un pacchetto TP inviato da un device.
Quando il l’host invia un pacchetto TP, il campo Device Address contiene l’indirizzo del
destinatario.
Quando un device invia un TP all’host, pone il proprio indirizzo nel campo address così che l’host
possa conoscere il mittente.
In un pacchetto TP il campo SubType è usato dal destinatario per determinarne il formato e l’uso.
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Device Address Route String Type
Reserved Seq Num NumP HE RSVD Ept Num D rty Rsvd Sub Type
Reserved PP Reserved Stream ID / Reserved
Link Control Word CRC 16
Transaction Packet
Valore Tipo di TP
0000 Reserved
0001 ACK
0010 NRDY
0011 ERDY
0100 STATUS
0101 STALL
0110 DEV NOTIFICATION
0111 PING
1000 PING RESPONSE
1001 → 1111 Reserved
• per un endpoint IN, questo pacchetto è inviato dall’host per richiedere dati al device oppure
per confermare la ricezione dei precedenti pacchetti.
• per un endpoint OUT, questo pacchetto è inviato da un device per confermare la ricezione
dei precedenti pacchetti di dati inviati dall’host oppure per informare l’host sul numero di
buffer dati disponibili dopo la ricezione del pacchetto attuale.
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Device Address Route String / Reserved Type
Reserved Seq Num NumP HE Rsvd Ept Num D rty Rsvd Sub Type
Reserved PP Reserved Stream ID / Reserved
Link Control Word CRC 16
ACK Transaction Packet
Questo pacchetto può essere inviato solo da un device con un endpoint non isocrono.
Un endpoint OUT invierà questo pacchetto all’host se non dispone di spazio buffer sufficiente per
accettare pacchetti dati inviati dall’host.
Un endpoint IN invierà questo pacchetto all’host se non è in grado di inviare un pacchetto dati in
risposta ad un ACK inviato dall’host .
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Device Address Reserved Type
Reserved Ept Num D Rsvd Sub Type
Reserved Stream ID / Reserved
Link Control Word CRC 16
NRDY Transaction Packet
Questo pacchetto può essere inviato solo da un device con un endpoint non isocrono.
Questo pacchetto è usato per informare l’host che l’endpoint è pronto per ricevere o inviare dati.
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Device Address Reserved Type
Reserved NumP Reserved Ept Num D Rsvd Sub Type
Reserved Stream ID / Reserved
Link Control Word CRC 16
ERDY Transaction Packet
Questo pacchetto può essere inviato solo da un host e solo verso un endpoint di controllo.
É usato per informare l’endpoint di controllo che l’host ha iniziato la fase di Status di un
trasferimento di controllo.
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Device Address Route String Type
Reserved Ept Num D Rsvd Sub Type
Reserved
Link Control Word CRC 16
STATUS Transaction Packet
Questo pacchetto può essere inviato solo da un device in risposta ad un pacchetto PING inviato
dall’host. Per ogni PING ricevuto dovrà essere inviato un corrispondente PING RESPONSE
relativo allo specifico endpoint.
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Device Address Reserved Type
Reserved Ept Num D RsvdP Sub Type
Reserved
Link Control Word CRC 16
PING RESPONSE Transaction Packet
Data Packet
I pacchetti ITP sono usati per la consegna del timestamp dall’host verso tutti i device attivi al fine di
trasferire le informazioni sulla temporizzazione e sincronizzazione.
Il pacchetto, che può essere inviato solo dall’host, non ha indirizzo ne informazioni sul routing ed è
inviato in multicast dagli hub su tutte le porte di downstream aventi il link nello stato attivo U0 e
così pure per l’host. I device non rispondono al pacchetto ITP.
L’host potrà trasmettere un pacchetto ITP nell’intervallo all’interno della tTimestampWindow e
iniziando dal tIsochronousTimestampStart successivo all’attivazione della porta root dell’host
derivante da uno stato di polling.
Il pacchetto ITP può essere trasmesso tra due pacchetti di burst.
Se un device riceve un pacchetto ITP con il flag delay (DL) settato all’interno del campo Link
Control Word, il valore del timestamp può essere impreciso e quindi ignorato dal device.
I 27 bit del campo Isochronous Timestamp identificano il valore corrente del timestamp.
Questo campo è diviso in due sottocampi:
i primi 14 bit (Bus interval counter) rappresentano un contatore a 1/8 di millisecondo, il conteggio
si evolve verso lo zero e poi si incrementa fino al valore 3FFF.
i successivi 13 bit (Delta) rappresentano il numero di unità di tIsochTimestampGranularity e
indicano la risoluzione temporale per l’inizio del bus interval rispetto al clock dell’host.
Se il pacchetto parte esattamente all’inizio del bus interval, il valore del Delta è posto a zero.
Indirizzamento Triplo
Per l’accesso al destinatario, i pacchetti Data e Transaction fanno uso di tre campi indirizzo:
Device Address, Endpoint Number e Direction.
Dopo l’accensione o dopo un reset l’indirizzo del device è posto a zero di default, successivamente,
durante il processo di enumerazione, l’host assegnerà l’indirizzo di lavoro con un valore compreso
nel range 1 – 127.
I devices possono avere fino ad un massimo di 15 endpoint IN e 15 OUT secondo quanto indicato
dal campo Direction.
Route String
Il valore Hub@Tier1 rappresenta il numero di porta di downstream dell’hub connesso alla porta
root dell’host e così via per gli altri campi.
Essendo il numero di porta dell’hub definito da 4 bit, il numero massimo di porte è pari a 15.
Il collegamento elettrico tra host e device o hub è realizzato con il seguente circuito:
TX+ RX+
+ +
_ _
TX- RX-
Host Cable Device
RX+ TX+
+ +
_ _
RX- TX-
Connector Connector
Si evidenzia:
l’accoppiamento in c.a. tramite le due coppie di condensatori
l’utilizzo della modalità differenziale
la comunicazione full duplex
l’utilizzo, per i segnali, di coppie twisted o twinax
Riferimenti bibliografici:
USB 1.0 Specification – Jan 1996 (268pg) - www.usb.org
USB 2.0 Specification – Apr 2000 (650 pg) - www.usb.org
USB 3.0 Specification – Nov 2008 (482 pg) - www.usb.org