Capitolo 4 – Sintesi e test
4.1 FPGA per applicazioni spaziali
L’utilizzo di FPGA in applicazioni spaziali è in rapida crescita dato il loro aumento di competività rispetto ai tradizionali ASIC, esse garantiscono infatti facilità e basso costo di riprogetto. I problemi principali che si presentano nell’utilizzo di dispositivi elettronici in ambito spaziale sono provocati dalle radiazioni; l’esposizione alle radiazioni spaziali produce gli stessi effetti sia sulle logiche dell’FPGA che su quelle degli ASIC, come questi si traducano poi in malfunzionamenti del circuito e come tali problemi possano essere prevenuti o ridotti è complesso e dipende fortemente dalla tecnologia utilizzata e dall’architettura interna del dispositivo.
Negli ambienti spaziali vicino alla terra e nello spazio profondo sono presenti svariate sorgenti di radiazioni, che includono elettroni, protoni e ioni pesanti. Sono presenti ad esempio raggi cosmici che trasportano nuclei atomici ad alta energia, particelle alfa e fotoni altamente energetici provenienti dal sole. Queste radiazioni possono portare a diverse anomalie nei microcircuiti di una FPGA. Gli effetti dovuti all’esposizione alle radiazoni si possono dividere in due gruppi:
• gli effetti dovuti alla dose totale di ioni assorbita (Total Ionized Dose: TID), causati dalla lunga permanenza nello spazio.
• gli effetti dovuti ad un evento singolo (Single Event Effect: SEE) , causati dall’impatto localizzato e istantaneo di radiazioni.
La TID è misurata in quantità di radiazioni assorbita dalla materia la cui unità di misura è il rad (100 rad=1 J/Kg). I produttori di FPGA e di ASIC indicano il livello di TID che i loro dispositivi possono sopportare senza avere problemi di funzionamento. Tuttavia conoscere il livello di radiazioni al quale sarà esposto il dispositivo non è semplice perchè esso dipende dal tempo di missione, dall’esatta traiettoria e dall’orbita del veicolo spaziale.
Per i SEE il livello di radiazione è misurato in termini di radiazione che si deposita per unità di superficie (LET: Linear Energy Transfer), la cui unità di misura è il MeVcm2 / mg di Silicio. Gli effetti provocati da un singolo impatto di una radiazione ionizzante possono essere:
• Single Event Latch-up (SEL), dove si attivano transistor parassiti che causano commutazioni anomale dei transistor nominali e forti correnti che possono danneggiare permanentemente il dispositivo.
• Single Event Upset (SEU), in cui la deposizione di carica causata dalla radiazione produce la commutazione di un elemento di memoria.
• Single Event Transient (SET), dove una corrente o un picco di tensione transitoria viene indotto in un elemento del circuito.
Così come per la TID la scelta del substrato e della geometria delle celle logiche sono i fattori principali per assicurare che l’FPGA sia immune ai SEL.
Per ridurre la probabilità di incorrere in un SEU si usano celle di memoria che sono state protette attraverso appropriate topologie. I produttori di ASIC sono stati i primi ad utilizzare “hardened flip-flop”, ma ora anche i produttori di FPGA per applicazioni spaziali includono queste celle nei loro dispositivi. Inoltre i SEU possono essere ridotti a livello di netlist duplicando o triplicando gli elementi di memoria e filtrando i segnali in caso di divergenza. Differenti codici per l’individuazione e la correzione dell’errore (Error Detection And Correction: EDAC) possono essere utilizzati per identificare commutazioni di bit nei banchi di memoria.
4.1.1 FPGA Actel RTAX2000S
Da due decenni la Actel Corporation è il maggiore produttore al mondo di FPGA per applicazioni aereospaziali; gli stringenti requisiti di qualità e resistenza alle radiazioni che queste applicazioni richiedono ha portato al progetto di dispositivi sempre migliori e oggi utilizzati in progetti per il controllo e l’immagazzinamento dei dati, per le comunicazioni e per la strumentazione scientifica. La famiglia Axcellerator RTAX-S [14] è nuova generazione di FPGA radiation tollerant che offre alti livelli di densità, prestazioni e caratteristiche tali da essere un’alternativa ideale agli ASIC.
Target di questo progetto è l’FPGA RTAX2000S, essa è progettata per sopportare una TID di 330 Krad ed ha un’immunità al SEL per dosi di radiazioni maggiori di 104 MeV·cm2 / mg.
Fig 4.2 FPGA Actel per applicazioni in ambiente radioattivo
L’RTA2000S utilizza inoltre flip-flop hardened che danno immunità al SEU per LET maggiori di 60 MeV·cm2 / mg, questo elimina la necessità di creare strutture ridondanti a livello di netlist. Tali flip-flop sono stati progettati in modo da non variare la funzionalità delle celle rispetto alla versione terrestre dell’FPGA la AX2000. In essi delle voter gate effettuano la media dei valori memorizzati nella struttura ridondante.
Per gli elementi di memoria la Actel offre una IP, generabile con il tool Actel GenerateTM, per l’EDAC con la quale si può ridurre a 10-10
giorno bit⋅
errori
l’impatto dei SEU su tali elementi, arrivando ad un livello di errore pari a quello sui flip flop hardened.
La tecnologia utilizzata per ottenere la programmabilità del dispositivo è antifuse One Time Programmable (OTP); questo elimina i problemi legati agli effetti delle radiazioni che avrei su una FPGA riprogrammabile (SEU sulla SRAM contente il codice possono variare la topologia del circuito), ma ridurrebbe di molto la flessibilità del progetto in fase di testing se non fosse per la possibilità di utilizzare la versione terrestre della RTAX2000. La AX2000, infatti, è funzionalmente corrispondente uno a uno con la sua versione spaziale ma ha un costo pari ad 1/100 della sua versione spaziale; inoltre essa è disponibile con gli stessi package della RTAX2000S. I test su scheda dell’intero sistema saranno quindi eseguiti sull’AX2000 che sarà sostituita poi per la versione fly dall’RTAX2000S.
4.2 Simulazione logica dell’interfaccia AHB per router Spacewire
Per verificare il corretto funzionamento del dispositivo a livello logico è stato realizzato un Test Bench costituito dal Router SpaceWire a 9 porte (8 dedicate alla trasmissione Spacewire e una alla trasmissione sul custom bus) collegato a 8 interfacce SpaceWire e all’interfaccia AHB-custom bus.
Figura 4.4 Schema del Test-Bench per l’interfaccia AHB-custom bus
Come illustrato nella figura 4.3, un’interfaccia Spacewire riceve i dati in ingresso da un apposito file. Inviando pacchetti Spacewire con protocollo RMAP è possibile programmare il router o pilotare l’interfaccia master AHB e, tramite questa, l’interfaccia slave per testare così tutte le funzioni del modulo. I dati ricevuti dalle 8 interfacce Spacewire vengono salvati su file per verificare la corretta programmazione del router e il corretto funzionamento dell’intero sistema; tramite file viene monitorato anche l’operato delle interfacce AHB (master e slave). Per verificare la compatibilità con le interfacce AHB di ICCU esse sono state successivamente aggiunte al Test Bench e l’intero sistema è stato testato analogamente a quanto descritto prima. Con tali test si è arrivati ad una copertura del codice del 97%, essi sono stati ripetuti in seguito per verificare anche la corretta sintesi e il corretto fitting sull’FPGA.
Nome test Descrizione del test Superato Test di reset Si verificano i corretti valori di reset dei registri OK Test di scrittura e lettura sui
registri AHB
Si verifica l’avvenuta scrittura e lettura sui registri
mappati sul bus AHB OK
Test di scrittura e lettura sul buffer dati
Si verifica l’avvenuta scrittura e lettura sul buffer
dati slave
OK Test DMA Si verifica il corretto DMA in lettura e scrittura sul bus
AHB come master OK
Test invio e ricezione dati su slave
Si verifica il corretto scambio dati fra buffer
slave e custom bus
OK
Test comunicazione RMAP
Si testa il controllo remoto, tramite decoder RMAP, del
bus AHB e la corretta risposta sul custom bus
OK
Test di programmazione router via RMAP
Si verifica che ill router venga programmato correttamente utilizzando il
protocollo RMAP
OK
Test timecode Si testa il corretto invio e la corretta ricezione dei timecode sul custom bus
OK Test configurazione router Si testa la corretta lettura e scrittura sul custom bus di
configurazone OK Test errori Si testano le possibili situazioni di errore e se ne verifica la corretta segnalazione OK
Tab 4.1 Test eseguiti sull’interfaccia AHB per router Spacewire
4.2.1 Validazione del protocollo AMBA AHB
Per un’ulteriore validazione del protocollo AMBA implementato si è testata l’interfaccia nell’ambiente di simulazione per il processore LEON [10]. Il processore LEON è descritto tramite il linguaggio VHDL ed è distribuito ed utilizzabile entro i limiti di una GNU Public Licence (GPL) dalla Gaisler Research. Le varie unità funzionali che costituiscono il processore LEON sono interconnesse attraverso l’utilizzo di due bus: l’AMBA AHB e l’AMBA APB. E’ disponibile, insieme al codice del processore e di alcune periferiche, anche tutto un’ambiente di simulazione che invia al processore istruzioni in assembler
SPARC ( Scalable Processor ARChitecture) e ne monitorizza le risposte. E’ bastato inserire il codice dell’interfaccia implementata in tale ambiente e collegarla corretamente al bus AHB del processore per consentirne il test funzionale rispetto ad un bus AMBA già validato. In tal modo è stato possibile correggere alcuni errori di interpretazione dello standard, specie per quanto riguarda il comportamento del master AHB.
4.3 Sintesi logica dell’interfaccia AHB per router Spacewire
I risultati che si ottengono dalla sintesi logica sono:
• L’occupazione di area del dispositivo espressa nel numero totale di celle occupate; per avere una stima di ciò in ASIC-Gate equivalenti (corrispondenti all’occupazione di una porta NAND a due ingressi) basta tener conto che l’intera RTAX2000 ha 250k ASIC-Gate equivalenti.
• Una misura delle prestazioni in termini di velocità max del clock raggiungibile.
Il CAD utilizzato è il LiberoTM 6.1 della Actel con SimplifyTM 7.7.1 per la sintesi
logica e DesignerTM 6.1.1 per il fitting.
Per procedere alla fase di sintesi e al fitting è stato necessario specificare alcuni parametri:
• Dispositivo package e Speed Grade: si è effettuata la sintesi con una RTAX2000 speed grade -1 e con package 624 CCGA.
• Frequenza del clock: 32 MHz.
• Condizioni operative: la sintesi è stata effettuata nelle condizioni peggiori (worst case military) con temperatura max di 125°C e alimentazione minima di 1.425 V che è la minima garantita per l’alimentazione rispetto ai nominali 1.5 V.
path, multicicle path ecc.
I passi successivi sono stati la sintesi logica dell’interfaccia implementata e il fitting sull’FPGA.
La complessità del circuito sintetizzato è di 3172 celle su 32256 cioè il 9.83% di occupazione che corrisponde a circa a 24.6 KGate. Circa l’ottanta per cento di essa è data dal decoder RMAP e dall’interfaccia master AHB.
La frequenza massima è stata valutata intorno ai 40 MHz, più che sufficiente per i 32 MHz richiesti da progetto per il bus AHB.
Per poter valutare il modulo sarebbe necessario un confronto con dispositivi con caratteristiche analoghe ma non esistono implementazioni di decoder RMAP visto che questo protocollo è stato introdotto solo di recente, nel marzo 2005, nello standard spacewire.
4.4 Simulazione logica dell’interfaccia APB - SPI
Per verificare il corretto funzionamento del modulo a livello logico è stato realizzato un Test Bench costituito oltre che dall’interfaccia da testare da un modulo che emula le operazioni di un’interfaccia SPI e da uno che emula le operazioni del bus AMBA APB.
Figura 4.5 Schema del Test-Bench per l’interfaccia APB-SPI
Come illustrato nella figura 4.4, i due emulatori prelevano da file i controlli che indicano loro le operazioni da eseguire sul bus SPI e sul bus APB, il Test Bench monitorizza tali operazioni e il conseguente comportamento dell’interfaccia sotto test generando automaticamente eventuali messaggi di errore. Con tali test si è arrivati ad una copertura del codice del 98%, essi sono stati ripetuti successivamente per verificare la corretta sintesi e il corretto fitting sull’FPGA.
Nome test Descrizione del test Superato Test di reset Si verificano i corretti valori di reset dei registri OK Test di scrittura e lettura sui
registri APB
Si verifica l’avvenuta scrittura e lettura sui registri
mappati sul bus APB OK
Test di comunicazione slave
Si testa la corretta comunicazione SPI come slave per configurazioni e
velocità differenti
OK
Test di comunicazione master
Si testa la corretta comunicazione SPI come master per configurazioni e
velocità differenti
OK
Test di disabilitazione clock interno
Si testa la modalità con clock disabilitato e il corretto rientro in modalità di funzionamento normale OK Test errori Si testano le possibili situazioni di errore e se ne verifica la corretta segnalazione OK
Tab 4.2 Test eseguiti sull’interfaccia APB - SPI
4.4.1 Validazione del protocollo AMBA APB
Analogamente a quanto fatto per l’interfaccia AHB è stato sufficiente inserire il codice dell’interfaccia implementata nell’ambiente di simulazione del processore LEON e collegarla corretamente al bus APB del processore per consentirne il test funzionale rispetto ad un bus AMBA già validato. Non essendo disponibile invece una interfaccia SPI già validata non è stato possibile effettuare un test analogo per il bus SPI.
4.5 Sintesi logica dell’interfaccia APB - SPI
Si è effettuato sintesi e fitting specificando i seguenti parametri:
• Dispositivo e Speed Grade: si è effettuata la sintesi con una RTAX2000 speed grade -1.
• Condizioni operative: la sintesi è stata effettuata nelle condizioni peggiori (worst case military).
• Altri parametri: definizione dei domini di clock, parametri per l’analisi statica ecc.
La complessità del circuito sintetizzato è di 400 celle su un totale di 32256 cioè l’1.24% di occupazione che corrisponde a circa 3.2 KGate. Il bit rate massimo SPI è stato stimato intorno a 85 Mbit/s come master (42.5 Mbit/s come slave).
Per meglio valutare il progetto è stato effettuato un confronto con dispositivi commerciali con caratteristiche analoghe. Si è rieffettuata la sintesi con ISETM 6.2
dove i dispositivi commerciali erano mappati su FPGA della Xilinx.
Interfaccia Occupazione Velocità Dispositivo
Spimaster commerciale
Inicore [17] 8% delle celle occupate 123 MHz di clock
SPI implementata 6% delle celle occupate 97 MHz di clock
Actel Axcelerator AX500 -3
SPI_MS commerciale
ALMA [16]
142 CLB slice 30 Mbit/s di bit rate come slave
SPI implementata 148 CLB slice 26 Mbit/s di bit rate come slave
Xilinx Spartan 2 xc2s200 -6
SPI_MS commerciale
Alma [16] 130 CLB slice
52 Mbit/s di bit rate come slave
SPI implementata 138 CLB slice 46 Mbit/s di bit rate come slave
Xilinx Virtex2 80 -4
SPI commerciale
Cast [15] 143 CLB slice 76 MHz di clock
SPI implementata 148 CLB slice 105 MHz di clock
Xilinx Spartan 2 xc2s200 -6
SPI commerciale
Cast [15] 142 CLB slice 130 MHz di clock
SPI implementata 138 CLB slice 185 MHz di clock
Xilinx Virtex 2 80 -4
Tab 4.3 Confronto di prestazioni e occupazione dell’interfaccia APB-SPI implementata con quelle di dispositivi commerciali
L’interfaccia implementata ha prestazioni e occupazione comparabili, e alle volte migliori, di quelle dei dispositivi commerciali considerati. Le funzionalità sono, per tutte le interfacce commerciali considerate, pressocchè equivalenti; esse non implementano dalla parte opposta all’SPI un’interfaccia APB ma altre semplici interfacce parallele molto simili. Comunque l’interfacciamento sul bus AMBA non pesa che in minima parte sul progetto in termini di occupazione e certamente non influisce in termini di bit rate.
