Capitolo 2 - Progettazione di un’interfaccia
AMBA AHB per router Spacewire
2.1 Il progetto IPPM
Il progetto IPPM (Integrated Payload Pocessing and storage system Module) dell’ESA in collaborazione con l’Università di Pisa si propone di implementare una piattaforma hardware per l’immagazzinamento e il processamento dei dati a bordo di satelliti. Tale piattaforma comprende un processore LEON2 [10], vari moduli di memoria e due moduli di interfacciamento: l’ICCU (IPPM Control & Communication Unit) e un router spacewire ad otto porte capace di bit rate fino a 100 Mbit/s, macrocella di Proprietà Intellettuale (IP) e realizzata presso l’Università di Pisa. La struttura di tale router è riportata in figura 2.0.
Come bus principale per il modulo ICCU è stato scelto un bus AMBA AHB, dato che l’interfaccia Spacewire è un’interfaccia high speed (2-100 Mbit/sec) non si poteva scegliere un bus periferico a bassa velocità, come può essere l’AMBA APB. Router e ICCU sono descritti in linguaggio VHDL (Very High Speed Integrated Circuit Hardware Description Language) e saranno mappati su FPGA Actel Radiation Tollerant della famiglia Axcelerator (RTAX2000). Oggetto del lavoro di tesi era far sì che i due moduli potessero scambiare dati tra loro; inoltre si doveva far sì che il router e le sue otto interfacce potessero essere configurate da IPPM e che IPPM potesse gestire anche i timecode ricevuti o inviati dal router stesso. La struttura dei moduli di interfacciamento di IPPM è riportata in Fig 2.0.
Fig 2.0 Struttura interna del router Spacewire
2.2 Il custom bus per la comunicazione fra router e ICCU
Per problemi di occupazione i due moduli contenenti le interfacce esterne di IPPM sono stati progettati in modo da essere fittati su due FPGA distinte; inizialmente, per la comunicazione off-chip fra le due FPGA, si era pensato ad un bus totalmente custom, in seguito l’ESA ha dato indicazione affinchè ci si interfacciasse tramite un bus compatibile con quello utilizzato dallo spacewire router ASIC in via di sviluppo presso EADS Astrium.
Per il partizionamento del progetto bisognava, quindi, tener conto di: • Compatibilità con router ASIC Astrium
• Problemi di occupazione: prima di ottimizzare il router ad otto porte per l’RTAX2000S (di capacità 250K equivalent ASIC gates) esso occupava circa il 90% delle risorse
• Problema di separazione dei domini di clock dei due moduli: il bus AMBA lavora a 32 MHz, la parte che tratta i dati paralleli del router a 50 MHz Per questo sono state prese in considerazione tre soluzioni:
Soluzione 1: modificare un'interfaccia Spacewire del router in modo che possa
mandare dati anche verso ICCU tramite il bus custom. Un arbitro e uno switch permettono il riconoscimento dei dati destinati ad ICCU e il conseguente invio.
• Pro: E’ la soluzione con meno impatto da un punto di vista di area occupata (3-4%), infatti viene ad aggiungersi sull’FPGA del router solamente la logica per lo switch e per la macchina a stati finiti (FSM) che realizza l’arbitro.
• Contro: ICCU è raggiungibile e può inviare dati solo tramite una delle otto interfacce spacewire del router, quella modificata in tal senso. Inoltre non si raggiunge una compatibilità totale con il bus del router ASIC, infatti si ha bisogno di segnali extra, per esempio per richiedere all’arbitro l’utilizzo
non è immediata: i buffer di ricezione e trasmissione, ideali per una separazione dei domini, devono lavorare al clock del router per ovvie ragioni.
Fig. 2.3 Soluzione per la comunicazione sul bus custom con arbitro e switch
Soluzione 2: realizzare un router a 9 porte con 8 interfacce Spacewire e una porta
dedicata interamente alla comunicazione sul bus custom.
• Pro: ICCU è raggiungibile e può inviare dati su tutte e otto le porte Spacewire del router. Si raggiunge inoltre una completa compatibilità con il router ASIC, visto che non servono più segnali extra (l’instradamento verso ICCU viene eseguito dal router). Inoltre i segnali del bus custom del router ASIC sono proprio quelli usati generalmente per leggere e scrivere nelle FIFO; è sufficiente quindi rimuovere l’encoder decoder Spacewire della porta dedicata alla comunicazione con ICCU e utilizzare direttamente i segnali provenienti dai buffer di trasmissione e ricezione. In questo modo si realizza anche una separazione dei domini di clock dei due moduli.
• Contro : L’impatto sull’area è alto, le dimensioni del router infatti aumentano di circa un 10% se da otto si passa a nove porte.
Fig. 2.4 Soluzione per la comunicazione sul bus custom con porta del router dedicata
Soluzione 3: modifcare sempre una sola porta dello spacewire router con arbitro e
switch per i dati verso ICCU aggiungendo in più due buffer per la divisione dei domini di clock, è una soluzione ibrida delle prime due che ne riflette vantaggi e svantaggi.
• Pro: L’impatto sull’area è equivalente a quello della soluzione 1 quindi basso; infatti l’uso di FIFO non comporta l’utilizzo di risorse programmabili dell’FPGA. Inoltre si ha una migliore divisione dei domini di clock e una maggiore compatibilità con il router ASIC uscendo sempre verso il custom bus con i segnali delle FIFO.
• Contro: ICCU è comunque raggiungibile solo tramite l’interfaccia Spacewire del router modificata in tal senso. Non si raggiunge piena compatibilità con il bus di Astrium dato che sono presenti, come per la
Fig. 2.5 Soluzione per la comunicazione sul bus custom con switch, arbitro e buffer
Inizialmente dato il forte impatto sull’area della soluzione 2 ci si era orientati verso la prima soluzione. In seguito si è proceduto ad un’ottimizzazione del router operando un re-design specifico per Actel, mappando i buffer interni (FIFO) su risorse dedicate e non sulle celle logiche dell’FPGA e ottimizzando l’utilizzo delle risorse di clock. In questo modo si è arrivati ad un’occupazione del 60% circa dell’FPGA e si è riindirizzato il progetto verso la soluzione 2 che offriva maggiori vantaggi per compatibilità e comunicazione Spacewire.
Sull’impronta del bus Astrium oltre ai segnali di lettura e scrittura nei buffer dati, il custom bus deve contenere i segnali per la gestione dei timecode nel router e quelli per la lettura e la scrittura nei registri di stato e configurazione del router e delle interfacce spacewire. I segnali del custom bus, la loro funzione e la loro direzione rispetto al modulo ICCU sono descritti in tabella 2.1
Segnale Direzione Descrizione
EXT_OUT_DATA IN Ingresso dati dal buffer di trasmissione della porta dedicata alla comunicazione con ICCU
EXT_OUT_EMPTY_N IN Segnale di empty dal buffer di trasmissione
EXT_OUT_READ_N OUT Abilitazione per la lettura sul buffer di trasmissione
EXT_IN_DATA OUT Uscita dati verso il buffer di ricezione della porta dedicata alla comunicazione con ICCU
EXT_IN_FULL_N IN Segnale di full dal buffer di ricezione
EXT_IN_WRITE_N OUT Abilitazione per la scrittura sul buffer di ricezione
EXT_TICK_IN OUT Il fronte in salita di tale segnale porta il router a campionare EXT_TIME_IN
EXT_TIME_IN OUT Fornisce il valore del timecode inviato al router
SEL_EXT_TIME OUT Se alto sul fronte in salita di EXT_TICK_IN il router invierà il time code ad esso inviato, altrimenti invierà il timecode contenuto in un apposito contatore interno
TIME_CTR_RST OUT Reset per il contatore dei timecode del router
EXT_TICK_OUT IN Il fronte in discesa di tale segnale indica la ricezione di un timecode da parte del router, sul successivo fronte in salita il valore di tale timecode è posto in EXT_TIME_OUT e inviato sul bus.
EXT_TIME_OUT IN Fornisce il valore del timecode ricevuto dal router
Data_conf INOUT Dati per i registri di stato/configurazione del router e delle interfacce spacewire
Control_conf OUT Indirizzi per i registri di stato/configurazione
WE_conf OUT Write enable per le linee Data_conf
OE_conf OUT Output enable per le linee Data_conf, se alto la linea è in ingresso ad ICCU
Tab 2.1 Descrizione dei segnali del custom bus
2.3 L’interfacciamento col bus AMBA AHB
Le specifiche imponevano che l’interfaccia verso bus AMBA AHB fosse in grado di:
• Scambiare dati fra ICCU e il router Spacewire operando sul bus AMBA sia come master che come slave
• Effettuare DMA (Direct Memory Access) per rendere più efficiente lo scambio dati tra i due moduli, senza impegnare in questo il processore • Controllare da remoto ICCU, per un eventuale boot remoto, per l’update
remoto del codice del kernel o in caso di guasto del processore interno Per prima cosa, in accordo con ESA si è stabilita una sottoversione del protocollo AMBA AHB per l’utilizzo specifico su IPPM, secondo le necessità del progetto. Ciò ha permesso di snellire un po’ le interfacce e guadagnare in occupazione e prestazioni. In particolare è stato deciso di:
• Effettuare trasferimenti 32 bit alla volta, per semplificare la gestione degli indirizzi ecc.
• Non implementare slave con capacità di split • Non gestire il segnale di protezione hprot
In accordo a questo si è giunti ad una matrice di compatibilità fra le funzionalità master / slave dell’interfaccia AHB per router implementata e lo standard AMBA [1].
SPECIFICHE AMBA FUNZIONALITA’ SUPPORTATE Trasferimento base:
Fase di indirizzamento e fase dati il ciclo
successivo. OK
Trasferimento con stati di wait :
se hready va basso controlli, indirizzo e hwdata rimangono costanti, il master non campiona hrdata finche’ hready non torna alto.
OK
Tipo di trasferimento, gestione del segnale htrans:
Quando inizia un trasferimento htrans viene posto=NONSEQ poi, se il trasferimento prosegue (burst), htrans viene posto =SEQ. Se invece non vi e’ alcun trasferimento htrans =IDLE anche se hgrant va alto (vedi master di default nelle specifiche).
In caso di perdita del bus durante un trasferimento quando il master riacquista il controllo del bus il trasferimento riprende con htrans=NONSEQ seguito da SEQ se serve. In caso di risposta RETRY da parte dello slave quando hresp torna =OK il trasferimento riprende con htrans =NONSEQ come sopra.
OK
Non vengono inseriti mai cicli di BUSY
Tipo di burst, gestione del segnale hburst : Hburst puo’ assumere i valori :
SINGLE
INCR (e’ accettabile anche per un dato solamente, non si puo’ superare 1Kb di limite per gli indirizzi)
WRAP4 INCR4 WRAP8 INCR8 WRAP16 INCR16
Vengono eseguiti solo trasferimenti di tipo BURST INCR di N parole con 1<=N<=256 In caso di perdita del bus durante il trasferimento, quando il master riprende il controllo dello stesso il trasferimento prosegue con un burst INCR della dimensione opportuna.
Dimensione dei dati, gestione del segnale hsize Hsize puo’ assumere i valori :
Byte, Halfword, Word, 4 word-line, 8 word-line
Hsize costante = WORD. Sono effettutati solo trasferimenti con dati di tipo word.
I segnali di controllo devono avere lo stesso
timing degli indirizzi. OK
Protezione, gestione del segnale hprot : hprot(0) : Opcode_ / Data
hprot(1) : User_ / Privileged
hprot(2) : Not bufferable_ / Bufferable hprot(3) : Not cacheable_ / Cacheable
(per gli slave le specifiche sconsigliano di far uso di tale segnale perche’ non tutti i master sono in grado di inviarlo correttamente)
Si e’ deciso di non gestire tale segnale
Risposta dello slave, gestione del segnale hresp OKAY : se hready alto segnala che il trasferimento e’ avvenuto
ERROR : segnala in due cicli di clock un errore nel trasferimento
RETRY : segnala in due cicli clock che il master deve ritentare da capo il trasferimento. SPLIT : come sopra solo che al master e’ tolto il controllo del bus
Le risposte OKAY, RETRY e SPLIT sono trattate come da specifica (RETRY e SPLIT nello stesso modo: il master ritenta il trasferimento dopo avere richiesto e riottenuto il controllo del bus)
In caso di ERRORE il trasferimento e’ interrotto e il buffer interno svuotato (le specifiche lasciano liberta’ in tal senso)
Allineamento degli indirizzi :
gli indirizzi devono essere allineati al tipo di dati (vedi segnale hsize)
Non vi e’ controllo interno di tale specifica va rispettata a monte quando si indica al master il primo indirizzo del prossimo trasferimento. Gestione del segnale hlock :
Serve per richiedere un utilizzo esclusivo del bus.
Hlock costante a 0.
Non sono mai richiesti trasferimenti locked.
Segnali hmasterlock, hsplit Non vengono considerati visto che non si prevedono ne’ risposte split ne’ si richiedono mai trasferimenti locked.
Gestione del segnale hburstreq nel burst INCR: Per burst di lunghezza indefinita deve rimanere alto finche’ non e’ iniziato l’ultimo trasferimento.
Rimane alto fin quando inizia l’ultima fase di indirizzamento.
SPECIFICHE AMBA FUNZIONALITA’ SUPPORTATE Trasferimento base:
Fase di indirizzamento e fase dati il ciclo
successivo. OK
Trasferimento con stati di wait :
se hready va basso controlli, indirizzo e hwdata rimangono costanti, il master non campiona hrdata finche’ hready non torna alto.
Lo slave ha anche un hready in ingresso : se e’ 0 non deve campionare gli indirizzi.
Lo slave puo’ mandare basso hready in uscita per prolungare la fase dei dati.
OK
Sono inseriti cicli di wait con hready=0 solo se si inviano risposte RETRY o ERROR
Tipo di trasferimento, gestione del segnale htrans:
Quando inizia un trasferimento htrans viene posto=NONSEQ poi, se il trasferimento prosegue (burst), htrans viene posto =SEQ. Se invece non vi e’ alcun trasferimento htrans =IDLE anche se hgrant va alto (vedi master di default nelle specifiche).
In caso di perdita del bus durante un trasferimento quando il master riacquista il controllo del bus il trasferimento riprende con htrans=NONSEQ seguito da SEQ se serve. In caso di risposta RETRY da parte dello slave quando hresp torna =OK il trasferimento riprende con htrans =NONSEQ come sopra
OK
Perché si avvii il trasferimento ha bisogno che htrans=NONSEQ.
Poi segue correttamente un trasferimento burst SEQ senza pero’ piu’ controllare hsel (nessun problema se il decoding degli indirizzi e’ fatto bene).
I cicli di BUSY del master sono gestiti correttamente
Tipo di burst, gestione del segnale hburst : Hburst puo’ assumere i valori :
SINGLE
INCR (e’ accettabile anche per N=1, non si puo’ superare 1Kb di limite per gli indirizzi) WRAP4 INCR4 WRAP8 INCR8 WRAP16 INCR16
Non vengono sfruttate le informazioni legate al segnale hburst. Comunque tutti i burst sono gestiti in modo corretto sfruttando il segnale haddr.
Dimensione dei dati, gestione del segnale hsize Hsize puo’ assumere i valori :
Byte, Halfword, Word, 4 word-line, 8 word-line
Hsize deve essere = WORD quando inizia il trasferimento se no viene segnalato ERRORE. Infatti sono supportati solo trasferimenti con dati di tipo word.
Protezione, gestione del segnale hprot : hprot(0) : Opcode_ / Data
hprot(1) : User_ / Privileged
hprot(2) : Not bufferable_ / Bufferable hprot(3) : Not cacheable_ / Cacheable
(per gli slave le specifiche sconsigliano di far uso di tale segnale perche’ non tutti i master sono in grado di inviarlo correttamente)
Si e’ deciso che non deve sfruttare tale segnale
Risposta dello slave, gestione del segnale hresp OKAY : se hready alto segnala che il trasferimento e’ avvenuto
ERROR : segnala in due cicli di clock un errore nel trasferimento
RETRY : segnala in due cicli clock che il master deve ritentare da capo il trasferimento. SPLIT : come sopra solo che al master e’ tolto il controllo del bus
Se si cerca di scrivere con buffer pieno o leggere con buffer vuoto viene segnalato un RETRY.
Se si inizia un trasferimento con hsize diverso da WORD o con haddr non allineato alla parola o haddr differente dagli indirizzi su cui e’ mappata l’interfaccia esse segnala ERROR e cancella i buffer
Negli altri casi hresp e’ costante ad OKAY Non supporta risposte SPLIT
Allineamento degli indirizzi :
gli indirizzi devono essere allineati al tipo di dati (vedi segnale hsize)
Nel caso in cui gli indirizzi non siano allineati con la WORD segnala ERRORE e cancella i buffer
Segnali hmasterlock, hmaster :
indicano quale master detiene il bus e se il trasferimento e’ locked
Non sono usati
Non é quindi presente controllo hardware per le risposte di RETRY
Tab 2.3 Standard AMBA vs funzionalità slave AHB implementate
2.4 Il problema del controllo remoto e il protocollo RMAP
L’interfaccia AMBA con capacità master doveva poter essere pilotata, oltre che tramite il controllore DMA, anche dal lato dello Spacewire router; per far questo c’era prima di tutto bisogno di un protocollo di comunicazione che doveva essere distinto dagli altri pacchetti dati, per permetterne il processamento hardware. Per questo lo standard Spacewire fornisce nel capitolo 5 (Protocol Identification normative) [11] una normativa che indica come identificare i protocolli di comunicazione; ciò permette a protocolli differenti di operare contemporaneamente sulla rete Spacewire senza interferire l’uno con l’altro.
nodi spacewire devono processare e rispondere ai pacchetti che ricevono in accordo al protocollo specificato da tale identificativo. Quando arriva a destinazione il pacchetto spacewire deve iniziare con un singolo byte, contenente l’indirizzo logico del destinatario. L’indirizzo logico 254 può essere usato come indirizzo di default quando la sorgente non conosce l’indirizzo logico del destinatario o quando esso non ne ha uno. Un nodo può decidere di ignorare i pacchetti con indirizzo logico 254 o di processarli. Subito dopo l’indirizzo logico nel pacchetto segue un byte detoo protocol ID che identifica il protocollo di comunicazione.
Fig 2.6 Indirizzo logico e identificativo del protocollo
L’identificativo 0 può essere usato inoltre per estendere di altri due byte l’identificativo del protocollo.
Lo standard Spacewire è uno standard ancora in via di definizione, specialmente per quanto riguarda i protocolli di comunicazione di alto livello. Quando è stato iniziato il progetto mancavano indicazioni su protocolli standard adatti ad un accesso remoto, quindi si era pensato di implementare un protocollo custom assegnandogli un identificativo per uso generale (compreso tra 240 e 254). In
seguito è stato definito dall’ESA un protocollo per l’accesso remoto l’RMAP (Remote Memory Access Protocol) [12] e aggiunto allo standard Spacewire nel capitolo 6. Considerando i problemi che l’implementazione di un protocollo custom comporta, contro i vantaggi dati da un protocollo riconosciuto dallo standard ufficiale ci si è orientati verso quest’ultima soluzione. Per il controllo da remoto del bus AHB si aveva bisogno di un protocollo che:
• indicasse quale tipo di operazione il master doveva eseguire sul bus AHB (lettura o scrittura)
• fornisse l’indirizzo AHB al quale tale operazione doveva essere compiuta • fornisse l’indentificativo di chi aveva inviato la richiesta da remoto, per
l’eventuale risposta
• fornisse un qualche tipo di controllo delle informazioni inviate
Il protocollo RMAP soddisfa tutti questi requisiti esso infatti è stato pensato per la scrittura e lettura in remoto di memorie, registri, FIFO e mailbox. Il suo proposito primario è quello di configurare una rete Spacewire, controllarne le unità e scambiare dati con esse. Esso può essere anche usato per configurare i router spacewire; per questo motivo la realizzazione di un controllore hardware per tale protocollo oltre che permettere un accesso remoto standard a ICCU aggiunge valore tecnico al router che ne era sprovvisto.
Tutti i registri, FIFO e mailbox acceduti sono pensati mappati su uno spazio di memoria, come può essere il bus AHB. Implementazioni parziali del protocollo RMAP sono permesse dallo standard nel momento in cui solo alcuni comandi o alcune opzioni di essi siano necessarie. Nel nostro caso è stata implementata una versione parziale di tale protocollo secondo le necessità del progetto; ciò ha permesso di snellire il decoder e guadagnare in termini di occupazione e prestazioni.
In riferimento alla descrizione dell’RMAP in [12] il paragrafo 6.5
Read-Modify-Write Command non è supportato mentre gli altri paragrafi 6.1, 6.2, 6.3, 6.4, 6.6,
6.7, 6.8 e 6.9 sono supportati con alcune note.
Write Command Format (paragrafo 6.3.1)
Opzioni del comando write Supportato Non supportato
Acknowledge X
Non-acknowledge X
Verified X
Non-Verified X
Incremental X (allineato alla word di 32 bit) Non-Incremental X (solo per una singola word di 32 bit)
Tab 2.4 Opzioni del comando write supportate in IPPM
Per ciò che riguarda il logical address del nodo IPPM esso è supposto avere valore di default pari a 254. Il primo comando di scrittura (programmazione del router) conterrà il nuovo logical address di IPPM. Dopo che il nuovo logical address viene settato, a seconda del valore di un flag, l’indirizzo logico 254 sarà riconosciuto oppure no. In ogni pacchetto ricevuto da IPPM si decodifica il protocol ID, se questo non è 1 cioè l’identificativo dell’RMAP, l’intero pacchetto viene passato al software per una decodifica. In tal caso una richiesta di interruzione è inviata al processore. Il campo Extended write address non è
utilizzato visto che IPPM è basato su uno spazio di memoria con indirizzi a 32 bit e non a 40. Il campo Write address viene usato dall’interfaccia AHB per trasferire dati all’appropriata destinazione. Un indirizzo specifico è riservato per lo Spacewire router per permettere la programmazione della router table attraverso il protocollo RMAP. E’ da notare che in questa fase gli indirizzi logici associati nella router table alla porta dedicata ad ICCU (porta 9) saranno gli indirizzi logici di IPPM. La Destination key è una maschera di 8 bit il cui valore è immagazzinato in un apposito registro. Si presenta un errore se la destination key inviata col pacchetto non corrisponde a quella contenuta nella maschera. Anche l’Header
CRC viene verificato: in caso esso non corrisponda a quello valutato internamente
il trasferimento viene interrotto. In caso di errore nell’Header CRC non c’è risposta perchè non è noto il coretto indirizzo logico della sorgente. Il campo Data
length viene usato per tenere il conto dei dati ricevuti prima dell’EOP. In caso di
EOP ricevuto troppo tardi il resto del pacchetto è ignorata. Il Data CRC non viene controllato.
Infine, la dimensione della parte dati in un singolo comando write deve essere compresa fra un minimo di 4 byte fino ad un massimo dipendente dalle risorse di immagazzinamento disponibili sull’FPGA target.
Write Reply Format (paragrafo 6.3.2)
In caso di risposta il pacchetto è creato con copie delle informazioni ricevute nella richiesta con l’eccezione del campo status che dipende dal tipo di errore, del campo reply CRC che viene generato internamente e del destination logical
address che è l’LA di IPPM. Write Errors (paragrafo 6.3.4)
Write error diagnostic Supportato Non supportato
Command X
Authorization X
Data X
Reply Non applicabile Non applicabile Tab 2.5 Diagnostiche di errore supportate per il comando write
Read Command Format (paragrafo 6.4.1)
Il trattamento del comando di read è simile a quello del comando di write e descritto in tabella 2.6.
Opzioni del comando
read Supportato Non supportato
Acknowledge X
Incremental X (allineato alla word di 32 bit) Non-Incremental X (solo per una singola word di 32 bit)
Read Errors (paragrafo 6.4.4)
Le diagnostiche di errore supportate sono indicate in tabella 2.7
Read error diagnostic Supportato Non supportato
Command X
Authorization X
Data X
Reply Non applicabile Non applicabile Tab 2.7 Diagnostiche di errore supportate per il comando write
Error Codes (paragrafo 6.6)
I codici di errore che IPPM può generare nella risposta sono 0 (O.K.) o 1, 2, 3, 5 e 10. Il loro significato è esplicitato nella tabella 2.8.
Tipo di errore Codice di errore
Destination key non valida 3
Comando RMAP da IPPM 2
Data length > dimensione max FIFO
(per trasferimenti incrementali) 2 Dati non allineati ai 32 bit 2
Data lentgh > 4 bytes
(per trasferimenti non incrementali) 2
Early EOP durante la ricezione dei comandi Non viene inviata risposta FIFO full durante la scrittura 10
DMA in atto durante scrittiura o lettura 10 Early EOP durante la ricezione dei dati 5
Errori interni della FSM
1 se la FSM entra in stato di errore dopo la ricezione dei comandi RMAP, sennò non viene
inviata risposta
Tab 2.8 Codici di errore generati da IPPM
Command Summary (paragrafo 6.9)
In conclusione i comandi che richiedono un read-modify-write o un write con verifica dei dati non sono supportati. Tutti gli altri sono supportati, i trasferimenti non incrementali sono limitati a trasferimenti di 4 byte alla volta.
Codici di comando RMAP Bit 5 Bit 4 Bit 3 Bit 2 Command Field Write/ Read Verify Data Before Write
Ack Increment Address Funzione
Supportato Supportato Non
0 0 0 0 Non utilizzato
0 0 0 1 Non utilizzato
0 0 1 0 Read single address X
0 0 1 1 Read incrementing address X
0 1 0 0 Non utilizzato
0 1 0 1 Non utilizzato
0 1 1 0 Read-Modify-Write single address X
0 1 1 1 incrementing address Read-Modify-Write X 1 0 0 0
Write, single address, don’t verify before
writing, no acknowledge
X
1 0 0 1
Write, incrementing address, don’t verify before writing, no
acknowledge
X
1 0 1 0
Write, single address, don’t verify before
writing, send acknowledge
X
1 0 1 1
Write, incrementing address, don’t verify before writing, send
acknowledge
X
1 1 0 0 Write, single address, verify before writing,
no acknowledge X
1 1 0 1
Write, incrementing address, verify before
writing, no acknowledge
X
1 1 1 0 Write, single address, verify before writing,
send acknowledge X
1 1 1 1
Write, incrementing address, verify before
writing, send acknowledge
X
IPPM reagisce all’arrivo di un pacchetto Spacewire a lei destinato secondo il diagramma di flusso di figura 2.7
2.5 Flusso di progetto
La figura 2.8 mostra il flusso di progetto seguito.
in linguaggio VHDL; ogni blocco è stato testato per verificarne la corretta funzionalità. In seguito è stato effettuato l’assemblaggio e sono stati eseguiti vari test funzionali sull’intero sistema costituito dall’interfaccia, dal router e da alcune interfacce AMBA di ICCU (master e slave); tali test sono stati effettuati successivamente anche per verificare la corretta sintesi e la corretta mappatura su FPGA. Per la descrizione dei test e per i risultati di sintesi si rimanda al capitolo 4.
2.6 Struttura dell’interfaccia AHB per router spacewire
L’interfaccia progettata comunica da un lato con un bus AHB, il cui comportamento è descritto nel capitolo 1 e il cui standard è descritto in [1], operando sia come master che come slave, dall’altro con il router Spacewire attraverso il bus custom sopra descritto.
Fig 2.9 Ingressi e uscite dell’interfaccia AHB per router Spacewire
Essa è costituita dai seguenti blocchi:
• Una FSM (Finite State Machine) per lo scambio dei dati tra il buffer dell’interfaccia slave AHB e il custom bus
• Un decoder RMAP per il controllo remoto (da spacewire) del bus AHB • L’interfaccia verso il custom bus, con una parte per il controllo dei
timecode e una per la configurazione delle interfacce spacewire del router.
2.7 Interfaccia AMBA AHB slave
La parte slave dell’interfaccia AHB implementata è composta essenzialmente di: • I registri di configurazione, stato e controllo dell’intero modulo
• Un buffer dati (FIFO)
• Una FSM per il controllo delle operazioni AHB slave
2.7.1 Registri accesibili dal bus AHB
Nome N bit Descrizione
DMA_address_reg 32 Registro contenete l’indirizzo di accesso per il DMA ROC_reg 32 Registro per l’accesso al bus di configurazione del router e al bus dei timecode
LA_reg 32 Registro di controllo del decoder RMAP e di gestione dell’indirizzo logico 254 Scontrol_reg 32 Registro di controllo delle operazioni slave e del DMA
Sflag_reg 32 Registro dei flag
Strx 32 Buffer dati dello slave (profondità 256 word)
DMA_address_reg :
Bit 31 - 0
R
W DMA address
[31:0] : DMA address – Indirizzo del trasferimento DMA
LA_reg :
Bit 31 - 24 23 - 16 15 - 10 9 8 7- 0
R PID counter 254 counter
W RMAP Dkey Unused Unused
DIS RMAP
ACC
254 Unused [31:24] : RMAP Dkey - Contiene la destination key RMAP accettata da IPPM [9] : DIS RMAP - Se alto disabilita il decoder hardware del protocollo RMAP [8] : ACC 254 - Se alto accetta sempre l’indirizzo logico 254
[7:0] : Unused
[23:16] : Protocol ID counter - Contatore dei protocolli ricevuti diversi dall’RMAP
[15:10] : Logical address 254 counter - Contatore dei pacchetti Spacewire con indirizzo logico 254 scartati
Scontrol_reg :
Bit 31- 24 23-17 16 15-8 7 6 5 4 3 2 1 0
R
W IMask Un CR counter DMA Un Un DMA R/W DMA CI Un FoT FiR [0] : FiR - Fifos software Reset. Reset attivo alto dei buffer dati master e slave [1] : FoT - Force Spacewire interface Transmission. Se messo a uno il controllere del buffer interno invia i dati contenuti nel buffer slave al router (per l’invio su Spacewire o per la programmazione del router a seconda del primo byte del pacchetto)
[2] : Unused
[3] : CI - Clear all Interrupts. Cancella le interruzioni: ETA, ECA, ERR, EOER, EOT, EOD attivo alto.
[4] : DMA - Da il via ad un trasferimento DMA se messo a uno
[5] : DMA R/W - Stabilisce il verso del trasferimento DMA (1=W, 0=R) [6] : Unused
[15:8] : DMA counter - Lunghezza dati del trasferimento DMA (in numero di word)
[16] : CR - Counter Reset: Resetta i contatori nell’LA_reg [23:17] : Unused
Sflag_reg :
Bit 31 - 12 11 10 9 8 7 6 5 4 3- 0
R Fifo Count Unused ETA ECA ERR Un EOER EOT EOD FSF W
[3:0] : FSF - Fifo Status Flags. Indicano lo stato del buffer dati slave: [3] afull, [2] aempty, [1] full, [0] empty
[4] : EOD - End Of DMA interrupt. Va alto generando un’interruzione ogni volta che si è concluso un DMA
[5] : EOT - End Of Transmission interrupt. Va alto generando un’interruzione alla fine dell’invio dei dati contenuti nel buffer al router (vedi bit FoT in Scontrol_reg) [6] : EOER - End Of External Reception interrupt. Va alto generando un’interruzione ogni volta che è stato immesso un pacchetto Spacewire sul buffer dati per il processamento software
[7] : Unused
[8] : ERR - Error interrupt: Va alto generando un’interruzione quando avviene un errore nell’FSM di controllo del buffer dati slave
[9] : ECA - End of router or spacewire interfaces Configuration Access interrupt. Va alto generando un’interruzione ogni volta che si è concluso un trasferimento sul custom bus di configurazione (vedi ROC_reg)
[10] : ETA - End of router Timecode Access interrupt. Va alto generando un’interruzione ogni volta che si è concluso un trasferimento sul custom bus dei timecode (vedi ROC_reg). Cioè ogni volta che si è inviato un timecode al router e ogni volta che il router ha inviato un timecode a ICCU.
[11] : Unused
[31:12] : Fifo Count - Contatore del buffer dati slave
ROC_reg :
Bi
t 31-24 23 22 21 20-14 13 12-8 7-0
R TC read Un Un Un Unused R data
W TC write STC RTC ETC Un R/W Internal address W data [31:24] : Time code da inviare al router (write only) e time code letto (read only) [23] : STC - Select Time Code. Se a uno il router campiona il timecode inviatogli sul custom bus e lo invia a sua volta, se a zero il router invia il timecode che ha calcolato internamente. Questo avviene ogni volta che si ha un’accesso in scrittura a ROC_reg con ETC settato
[22] : RTC - Reset Time Code. Il router resetta il proprio registro interno dei timecode, è attivo alto
altrimenti abilita l’accesso al bus di configurazione. Ad ogni accesso in scrittura su ROC_reg corrisponde un accesso sul bus dei timecode o sul bus di configurazione.
[13] : R/W - Stabilisce la direzione dell’accesso al bus di configurazione : write se alto, read se basso
[12:8] : Internal address - Indirizzo interno sul bus di configurazione (vedi segnale control_conf del custom bus)
[7:0] : Dato da scrivere sul bus di configurazione (write only) e dato letto sul bus di configurazione (read only)
2.7.2 Controllo delle operazioni AHB slave
L’FSM che controlla scrittura e lettura dell’interfaccia AHB slave evolve negli stati descritti nella tabella 2.11
Stato Descrizione
Not_selected La macchina attende che l’interfaccia venga selezionata
Data_cycle Stato attivo dell’interfaccia, in cui si accede ai registri o al buffer dati
Be_cycle Stato di attesa al termine di un’accesso in scrittura al buffer dati che il controller di tale buffer lo svuoti
Pre_retry_cycle, Retry_cycle
Stati in cui l’interfaccia manda una risposta RETRY al master che l’ha acceduta. Ciò accade se si cerca di scrivere con buffer pieno o leggere con buffer vuoto
Pre_error_cycle, Error_cycle
Stati in cui l’interfaccia manda una risposta ERROR al master che l’ha acceduta. Tale risposta viene data se si inizia un trasferimento con hsize diverso da word o con haddr non allineato alla parola o con haddr differente dagli indirizzi su cui e’ mappata l’interfaccia
2.8 Interfaccia AMBA AHB master
La parte master dell’interfaccia AHB implementata è composta essenzialmente di: • Una FSM per il controllo delle operazioni AHB master
• Un controllore di DMA • Un buffer dati (FIFO)
2.8.1 Controllo delle operazioni AHB master
L’FSM che controlla scrittura e lettura dell’interfaccia AHB master evolve negli stati descritti nella tabella 2.12
Stato Descrizione
Idle_phase Insieme con lo stato Wait_phase, è lo stato in cui la macchina attende i comandi per avviare una trasmissione master
Wait_phase Secondo stato di attesa
Req_phase La FSM attende che l’arbitro AHB le assegni il controllo del bus
Addr Stato in cui si invia l’indirizzo del primo trasferimento
Addr_data Stato in cui ha luogo il trasferimento dei dati
Data Il master trasferisce l’ultimo dato
Retry_phase La macchina gestisce un’eventuale risposta di RETRY
Error_phase La macchina gestisce un’eventuale risposta di ERROR
Be_phase Stato di attesa che il buffer dati sia svuotato completamente dal controller interno dopo una lettura su bus AHB
2.8.2 Controllore DMA
Il controllore DMA viene gestito tramite i registri DMA_address_reg e Scontrol_reg. Esso permette essenzialmente di:
• Trasferire direttamente sul bus AHB (su locazioni di memoria consecutive) una parte o l’intero contenuto del buffer dati slave
• Inviare direttamente il contenuto di locazioni consecutive di memoria al router Spacewire
L’FSM che controlla il DMA evolve negli stati descritti nella tabella 2.13
Stato Descrizione
DMA_IDLE Il controllore attende che venga dato lo start al DMA
START_DMA Il controllore avvia l’AHB master
WAIT_DMA_END La macchina attende che il master AHB abbia terminato il trasferimento
2.9 Interfaccia AHB master - slave
Le due interfacce AHB, master e slave, sono contenute nel blocco ahb_mstslv.
Fig 2.11 Ingressi e uscite del blocco AHB_mstslv
Segnale Direzione Descrizione Slv_in, Slv_out,
Mst_in, Mst_out
Record comprendenti ingressi e uscite AHB slave e master
Slv_int OUT Richiesta di interruzione (vedi bit EOX nel Sflag_reg)
M_start_in, M_wrap_in, M_wrap_out
Record di segnali che servono al decoder RMAP per pilotare il master AHB
EOT_int OUT Indica al decoder RMAP che la trasmissione AHB master in corso è terminata
S_wrap_in, S_wrap_out
Record di segnali che servono per pilotare il buffer dello slave AHB
Force OUT Comanda al controllore del buffer dello slave di inviarne i dati al router spacewire (vedi bit FoT nell’Scontrol_reg)
DMA_on_out OUT Indica al decoder RMAP che il master AHB è impegnato in un DMA
LA_out, RMAP_DIS, dest_key
OUT Campi ACC_254, DIS_RMAP e dest_key dell’LA_reg per la configurazione del decoder RMAP
W_ro_config_reg OUT Indica alle macchine che controllano gli accessi sul bus custom di configurazione e su quello dei timecode che è avvenuta una scrittura sul registro ROC_reg che li gestisce To_ro_config_reg,
To_timecode_reg
IN All’ingresso del registro ROC_reg che memorizza il dato letto sul bus di configurazione e il timecode ricevuto sul bus dei timecode
From_ro_config_reg, From_timecode_reg
OUT Dall’uscita di quelle parti del registro ROC_reg che memorizzano il dato da inviare sul bus di configurazione e il timecode da inviare sul bus dei timecode
INC_XX_counter IN Comandi per l’incremento dei contatori in LA_reg
Set_EOX IN Comandi per il set dei flag EOX in Sflag_reg Slave_control_work IN Indica al controllore di DMA che il buffer
slave è impegnato
2.10 Controllore del buffer dell’AHB slave
Una macchina a stati finiti controlla lo scambio dei dati fra AHB slave e custom bus, essa è contenuta nel blocco slave_control.
Fig 2.12 Ingressi e uscite del blocco Slave_control
Tale macchina trasferisce i dati dal buffer dell’AHB slave se le viene inviato un comando dall’apposito registro o dal controllore DMA. Invece trasferisce i dati dal custom bus al buffer dell’AHB slave ogni volta che un pacchetto Spacewire di ICCU viene inviato al software.
Segnale Direzione Descrizione
Data_out_rx IN Corrisponde al segnale EXT_OUT_DATA del custom bus. E’ il decoder RMAP che decide chi fra lui e il controllore del buffer dell’AHB slave ha il controllo delle linee dati del custom bus.
Empty_rx IN Corrisponde al segnale EXT_OUT_EMPTY del custom bus.
Read_rx OUT Corrisponde al segnale EXT_OUT_READ del custom bus.
Data_in_tx OUT Corrisponde al segnale EXT_IN_DATA del custom bus.
Full_tx IN Corrisponde al segnale EXT_IN_FULL del custom bus.
Write_tx OUT Corrisponde al segnale EXT_IN_WRITE del custom bus.
Set_flag OUT Comandi per il set di alcuni dei flag EOX in Sflag_reg
Force IN Comanda al controllore del buffer dello slave di inviarne i dati al router spacewire
Slave_control_work OUT Indica al controllore di DMA che il buffer slave è impegnato
S_wrap_out IN Record di segnali che servono per pilotare il buffer dello slave AHB
S_wrap_in OUT Record di segnali che servono per pilotare il buffer dello slave AHB
Mux_control IN Segnale che indica chi fra decoder RMAP e controllore del buffer dell’AHB slave ha il controllo delle linee dati del custom bus.
Relase_slv OUT Segnala al decoder RMAP che la trasmissione dati in atto è terminata
2.14
Stato Descrizione
IDLE La FSM attende i comandi per un trasferimento dati
WAIT_MUX La macchina attende di avere il controllo del custom bus dati
CONTROL_EMPTY, WAITING_READ
Il dispositivo da inizio alla ricezione dei dati dal custombus
WAIT_RX_DATA, TAKE_RX_DATA
Il dispositivo trasferisce dati dal custom bus al buffer dell’AHB slave
WAIT_TX_DATA, TAKE_TX_DATA
La macchina trasferisce dati dal buffer dell’AHB slave al custom bus
WAIT_TX_EOP, TAKE_TX_EOP
La macchina conclude il trasferimento dati al custom bus inviando un EOP
RELASE Il dispositivo cede il controllo del custom bus dati
2.11 Decoder RMAP
Il decoder dei pacchetti Spacewire RMAP è contenuto nel blocco master_control.
Fig 2.13 Ingressi e uscite del blocco Master_control
Segnale Direzione Descrizione
Data_out_rx IN Corrisponde al segnale EXT_OUT_DATA del custom bus. E’ il decoder RMAP che decide chi fra lui e il controllore del buffer dell’AHB slave ha il controllo delle linee dati del custom bus
Empty_rx IN Corrisponde al segnale EXT_OUT_EMPTY del custom bus
Read_rx OUT Corrisponde al segnale EXT_OUT_READ del custom bus
Data_in_tx OUT Corrisponde al segnale EXT_IN_DATA del custom bus
Full_tx IN Corrisponde al segnale EXT_IN_FULL del custom bus
Write_tx OUT Corrisponde al segnale EXT_IN_WRITE del custom bus
Eot_int IN Indica che la trasmissione AHB master in corso è terminata
M_start_in, M_wrap_in, M_wrap_out
Record di segnali che servono al decoder RMAP per pilotare il master AHB
DMA_on_out IN Indica che il master AHB è impegnato in un DMA
ACC_254, RMAP_DIS, dest_key
IN Dai rispettivi campi dell’LA_reg per la configurazione del decoder RMAP
INC_XX_counter OUT Comandi per l’incremento dei contatori nell’LA_reg
Mux_control OUT Segnale che indica chi fra decoder RMAP e controllore del buffer dell’AHB slave ha il controllo delle linee dati del custom bus
Relase_slv IN Segnala che la trasmissione dati in atto che coinvolge il controllore del buffer dell’AHB slave è terminata
Force IN Richiede al decoder di cedere il controllo delle linee dati del custom bus al ontrollore del buffer dell’AHB slave
Tale decoder è costituito da una macchina a stati finiti che decodifica i pacchetti Spacewire presenti sul custom bus e pilota di conseguenza l’interfaccia master AHB. L’evoluzione di tale macchina all’arrivo di un pacchetto Spacewire è descritta nel diagramma di flusso di figura 2.7.
2.12 Interfaccia dei timecode
L’interfaccia verso la parte dei timecode del bus custom è contenuta nel blocco timecode_FSM.
Fig 2.13 Ingressi e uscite del blocco Timecode_FSM
Segnale Direzione Descrizione
EXT_TICK_IN OUT Alla corrispondente uscita del bus custom EXT_TIME_IN OUT Alla corrispondente uscita del bus custom SEL_EXT_TIME OUT Alla corrispondente uscita del bus custom TIME_CTR_RST OUT Alla corrispondente uscita del bus custom EXT_TICK_OUT IN Dal corrispondente ingresso del bus custom EXT_TIME_OUT IN Dal corrispondente ingresso del bus custom
W_timecode_reg IN Indica che è avvenuta una scrittura sul registro ROC_reg
To_timecode_reg OUT All’ingresso del registro ROC_reg che memorizza il timecode ricevuto
From_timecode_reg IN Dall’uscita di quella parte del registro ROC_reg che memorizza il dato da inviare sul bus dei timecode
Set_ETA OUT Comando per il set del flag ETA in Sflag_reg che indica il termine di un accesso sul bus dei timecode
ETC IN Dal corrispondente campo dell’ ROC_reg che abilita l’accesso al bus dei timecode
Tab 2.17 Descrizione degli ingressi e delle uscite del blocco Timecode_FSM
All’interno di tale blocco, oltre a vari registri di sincronizzazione vi è una FSM che controlla l’invio dei timecode sul custom bus, essa evolve negli stati descritti nella tabella 2.18.
Stato Descrizione
IDLE La macchina attende che si acceda in scrittura a ROC_reg con accesso al bus dei timecode abilitato (vedi ETC)
WAIT_SETUP La macchina attende un determinato tempo di setup prima di mandare alto EXT_TICK_IN affinchè il router campioni il timecode inviatogli
WAIT_HOLD La macchina attende un determinato tempo di hold prima di rimandare basso EXT_TICK_IN e di ritornare nello stato di IDLE
I timecode ricevuti invece sono campionati sul fronte in salita di EXT_TICK_OUT e sincronizzati rispetto al clock di sistema; ne viene poi data segnalazione al sistema tramite il bit ETA in Sflag_reg.
2.13 Interfaccia per la configurazione del router
L’interfaccia verso la parte di configurazione del bus custom è contenuta nel blocco config_FSM.
Fig 2.14 Ingressi e uscite del blocco Config_FSM
Segnale Direzione Descrizione
Data_conf INOUT Dati per i registri di stato/configurazione del router e delle interfacce spacewire
Control_conf OUT Indirizzi per i registri di stato/configurazione
WE_conf OUT Write enable per le linee Data_conf
OE_conf OUT Output enable per le linee Data_conf, se alto la linea è in ingresso ad ICCU
W_ro_config_reg IN Indica che è avvenuta una scrittura sul registro ROC_reg
To_ ro_config _reg OUT All’ingresso del registro ROC_reg che memorizza il dato ricevuto sul custom bus di configurazione
From_ ro_config _reg IN Dall’uscita di quella parte del registro ROC_reg che memorizza il dato da inviare sul bus di configurazione del router
Set_ECA OUT Comando per il set del flag ECA in Sflag_reg che indica il termine di un accesso sul bus di configurazione
ETC IN Dal corrispondente campo dell’ ROC_reg che abilita l’accesso al bus dei timecode o a quello di configurazione
Tab 2.18 Descrizione degli ingressi e delle uscite del blocco Conf_FSM
All’interno di tale blocco vi è una FSM che controlla i segnali sul custom bus di configurazione, essa evolve negli stati descritti nella tabella 2.19.
Stato Descrizione
IDLE La macchina attende che si acceda in scrittura a ROC_reg con accesso al bus dei configurazione abilitato (vedi ETC) WAITING_TRI Il dispositivo aspetta che le tristate, del router e di ICCU,
della linea dati del bus custom di configurazione commutino secondo la direzione del trasferimento
WRITE Il dispositivo aspetta che il router campioni il dato contenuto nel campo W data dell’ROC_reg
WRITE_IDLE Stato ponte necessario per fare sì che il router campioni correttamente i segnali di controllo del bus di configurazione READ La macchina invia il dato dal router sul campo R data
dell’ROC_reg
