• firmware hdl
• fpga flash based
• in-system fpga reprogramming
• remote fpga reprogramming

L’introduzione sul mercato di dispositivi FPGA programmabili basati su memorie cancellabili e riscrivibili in-system da diversi milioni di gates equivalenti ha reso possibile l’implementazione dinamica di algoritmi con complessità sempre crescente e performances vicine a quelle ottenibili con logiche custom (ASIC). La possibilità di riprogrammare questi dispositivi durante la missione operativa permette di poter adattare gli algoritmi implementati ai dati raccolti durante il volo, poter cambiare dinamicamente delle funzioni in modo da fare elaborazioni complesse usando un dispositivo “virtuale” molto più grande e non ultimo poter beneficiare di un work-around per problemi di implementazione o timing che si evidenziassero durante il funzionamento del dispositivo. Lo stato dell'arte per la FPGA oggetto di questa attività (Microchip RTG4) prevede necessariamente l'utilizzo di un programmatore esterno o di una CPU su cui eseguire la procedura messa a disposizione tramite la libreria "DirectC". In certe applicazioni a ridotta complessità e/o potenza disponibile, potrebbe non essere disponibile una CPU o potrebbe non essere possibile inserirla.
Scopo della tesi è quello di creare una logica da implementare in una FPGA secondaria (da usare come “FPGA ausiliaria” di dispositivi riprogrammabili) in grado di gestire la riconfigurazione partendo da un bit-stream ricevuto in blocchi parziali direttamente dalle interfacce del sistema a Terra con il satellite. L'attività ha previsto: lo studio dettagliato della libreria messa a disposizione dal costruttore per la riprogrammazione con CPU esterna, la definizione di un'architettura in grado di replicarne le funzioni indispensabili alla programmazione, lo sviluppo tramite descrizione in linguaggio HDL Verilog, la verifica tramite simulazione di tutte le funzionalità e i meccanismi implementati e la verifica tramite test sul setup appositamente allestito.
Dall'attività iniziale di studio sono state individuate le funzionalità indispensabili al flusso di programmazione da replicare nel sistema in sviluppo. L'architettura definita è stata pensata per realizzare tali azioni in modo efficiente e versatile: si è suddiviso il progetto in un "sistema remoto" (da collocare a Terra), a cui sono affidate le parti del flusso in cui si richiede l’ interazione con il file di programmazione (.dat), e un "sistema in orbita" collocato sul satellite in prossimità della FPGA da riconfigurare, che mette a disposizione del sistema remoto un set di "servizi", ne gestisce le varie fasi e comunica il risultato ottenuto dalle operazioni compiute.
L'interazione tra i due sistemi avviene tramite interfaccia UART: situazione realistica in quanto la comunicazione verso Terra è solitamente gestita da un computer di bordo il quale interagisce con gli strumenti attraverso connessioni di tipo seriale. Parte integrante dell'attività è stata la definizione delle regole di comunicazione tra i due sistemi.
Una comunicazione tra i due sistemi è composta da messaggi di lunghezza fissata per minimizzare gli errori. Ciascun messaggio è lungo 23 byte (23 pacchetti UART) ed è composto da: header[7:0], opcode[7:0], data_index[31:0], data[127:0], checksum[7:0]. Il checksum è calcolato accumulando i byte precedenti su un registro ad 8 bit e negando bit a bit il risultato; in ricezione basterà verificare che la somma di tutti i byte negata bit a bit sia 0.

SISTEMA IN ORBITA
I pacchetti UART ricevuti correttamente vengono inseriti in una FIFO per essere poi interpretati secondo il formato indicato dal protocollo. Il blocco che si occupa di interpretare il messaggio agisce osservando l’opcode e attivando coerentemente la FSM che gestisce l’esecuzione dei “servizi” (Service Controller).
Ciascun servizio disponibile è composto da più “azioni”: ogni azione corrisponde ad uno dei passaggi individuati nella fase di studio della libreria “DirectC”. Le azioni sono gestite da una FSM separata (Action Controller) che configura opportunamente l’interfaccia JTAG per la generazione delle forme d’onda corrispondenti.
Il meccanismo di generazione delle forme d’onda JTAG è basato su tre shift register precaricati con i dati necessari alla generazione delle forme d’onda in uscita (TMS; TCK, TDI) e un ulteriore shift register usato per generare il segnale di abilitazione al campionamento del pin di ingresso TDO (abilitazione di uno shift register in ingresso).
Il pin TRST non necessità alcuna operazione in quanto deve essere mantenuto alto per tutta la durata delle operazioni di programmazione.
Il messaggio di risposta viene generato da un blocco dedicato che assembla opcode e dati nel formato stabilito dal protocollo e lo inserisce in una FIFO da cui sarà estratto, un byte alla volta, dall’interfaccia UART per la trasmissione seriale.
Il caricamento del bitstream avviene per pagine di lunghezza fissata a 64 Frame di 128 bit, è quindi stata inserita un’apposita memoria RAM generata istanziando un blocco RAM di dimensione 1024 byte.

SISTEMA REMOTO
Il “sistema remoto” è stato realizzato con uno script in linguaggio Python. Esso offre all’utente un’interfaccia in cui inserire i comandi relativi alle operazioni permesse, controlla il rispetto del flusso di programmazione, estrae dal file .dat i parametri utili e il bitstream, comunica via UART con il “sistema in orbita”.

SIMULAZIONI E TEST
L'attività ha previsto lo sviluppo blocco per blocco dell'architettura definita e la verifica tramite simulazione Modelsim. Le simulazioni sono state automatizzate con appositi script (file .do) per rendere ripetibile il procedimento.
I test sono stati svolti su un setup di laboratorio costituito dalle Evaluation Board con le rispettive FPGA ausiliaria e riprogrammabile. Le forme d’onda JTAG generate sono state acquisite con i canali digitali di un oscilloscopio.
La strategia adottata ha previsto come obiettivo intermedio lo sviluppo di una versione a ridotte funzionalità per la lettura del Device ID: tale sistema integra tutti i blocchi e fa uso tutti i meccanismi contenuti nel sistema completo, pertanto, ne risulta una validazione del corretto funzionamento.
Per facilitare le simulazioni e il test su FPGA ausiliaria è stato sviluppato un emulatore JTAG in grado di replicare le risposte del sistema alle azioni che compongono il servizio di lettura del Device ID.
Il test sulle Evaluation Boards, con la FPGA RTG4 e la FPGA ausiliaria Artix7, ha restituito un Device ID corrispondente a quello contenuto nel file .dat generato al termine del flusso di progetto su Vivado.
L'attività ha infine previsto lo sviluppo, implementazione e simulazione del sistema completo in grado di gestire tutto il flusso di programmazione. Sono stati sviluppati tutti i “servizi” aggiuntivi (verifica della disponibilità alla programmazione, caricamento del pattern di configurazione del Boundary Scan JTAG, abilitazione dell’ Internal System Controller, caricamento del vettore di configurazione contenente la modalità di programmazione, shift di ciascun Frame del bitstream e verifica dell’esito, procedura di uscita).
Le simulazioni funzionali dei “servizi” restanti hanno restituito un comportamento corrispondente a quello individuato nella fase iniziale di studio della libreria DirectC. Pertanto si è realizzato un sistema che soddisfa i requisiti di progetto.
Il test sul setup allestito ha restituito esito positivo fino all’abilitazione dell’Internal System Controller. In corrispondenza di questa fase la FPGA RTG4 rifiuta l’abilitazione impendendo di proseguire con i passaggi successivi. Trattandosi di un’attività di Reverse Engineering (non è stata fornita documentazione in cui si descrivono i meccanismi interni alla FPGA RTG4) sarà necessaria un’approfondita analisi del problema da rimandare a futuri sviluppi.