Safe Dual Boot. Introduzione Ci sono vari sistemi di programmazione on-line di una FPGA, alcuni di questi setup prevedono:

Transcript

1 Safe Dual Boot Scopo: possibilità di eseguire l aggiornamento on-line del firmware di una FPGA in modo sicuro senza l utilizzo di DSP o CPLD aggiuntivi, ottenendo un risparmio nei consumi senza perdite in termini di affidabilità. Introduzione Ci sono vari sistemi di programmazione on-line di una FPGA, alcuni di questi setup prevedono: FPGA, prom(fpga), DSP, prom(dsp) FPGA, 2 prom e 1 CPLD La nostra soluzione invece prevede solo FPGA, 2 PROM piccoli componenti MSI La riprogrammazione on-line è un passaggio molto delicato in quanto si va ad eliminare tutta la logica digitale del firmware di una scheda per sostituirlo con una versione aggiornata. Il problema nasce quando il firmware che deve essere aggiornato è responsabile della comunicazione attraverso cui passa il nuovo stream di programmazione (come è nel nostro caso). Nel eventualità infatti che il programma che è stato trasmesso contenga degli errori gravi, una volta che l FPGA si resetta l intera scheda perde qualsiasi contatto col mondo esterno e quindi la possibilità di essere recuperata via software senza un recupero fisico dell elettronica. Per questa ragione nelle soluzioni sopra indicate vengono aggiunti dei componenti come DSP, microcontrollori, CPLD ecc. Si cerca in diversi modi risolvere il problema della affidabilità del sistema relegando ad una intelligenza esterna alcuni compiti durante la delicata fase di riprogrammazione del cervello centrale della scheda. Attraverso un DSP si può mantenere il contatto col mondo esterno; man mano che da terra giungono le informazioni di riprogrammazione esse vengono caricate all interno della prom di programmazione della FPGA, dopodichè lo stesso DSP può ordinare il reboot alla FPGA. Nel caso in cui questa non dovesse riprendersi correttamente, basterà avere istruito il DSP a rieseguire tutta l operazione finchè non giunge un OK dalla FPGA stessa. Un altra soluzione può essere quella di utilizzare due prom distinte che supportino due modalità di programmazione diverse dell FPGA, una di queste funge da prom iniziale e di backup, la seconda è quella su cui si possono caricare dati-utente o anche un nuovo firmware. In questa soluzione l FPGA è responsabile della comunicazione con l esterno ma c è on board anche un piccolo CPLD in aiuto ad essa. Immaginiamo per esempio che la prom di backup sia collegata all FPGA in modo da programmarla in modalità master serial, la seconda in modalità SPI. L FPGA ha tre terminali dedicati che va a leggere quando le arriva l impulso di program, a seconda del valore che questi assumono lei utilizza una modalità di programmazione diversa. Il CPLD gestisce solo la fase di riprogrammazione dettando all FPGA attraverso quei piedini la modalità con cui riprogrammarsi; se la riprogrammazione fallisce (non arriva un ok dalla FPGA stessa) il CPLD opta per un nuovo boot, questa volta dalla prom di back-up originale. La soluzione che incorpora il DSP risulta piuttosto dispendiosa sia economicamente che in termini di consumo; la seconda d altra parte, inserisce un elemento che seppur a basso cansumo e basso costo risulta comunque sfruttato al di sotto dell 1% delle sue caratteristiche, rivelandosi quindi un spreco evidente. La nostra soluzione invece consente di avere una piattaforma riprogrammabile on-line al minimo costo e caratterizata dalla stessa affidabilità delle soluzioni precedenti.

2 La soluzione somiglia alla seconda di quelle illustrate precedentemente. Sono presenti due prom, una di default o di back-up, la cui configurazione sicuramente funzionante rimane fissa, ed una seconda identica alla prima che serve per ospitare le nuove configurazioni inviate. Abbiamo al momento provato che la spartan 3E è in grado di inviare a se stessa il segnare di re-boot e di interpretarlo correttamente; è una prova molto semplice da eseguire ed è stata verificata su una demoboard. A questo punto è verificato che almeno l ultima operazione prima del salto nel buio è possibile, anche senza una logica esterna. Esendo l ultima banale, e allo stesso tempo cruciale, operazione se non avesse funzionato era inutile perdere tempo studiando ciò che deve avvenire prima del self-re-boot. Appunto e prima? Andando un passo per volta di seguito riporto il diagramma di funzionamento di questa soluzione: 1. primo power up: programmazione attraverso la back-up prom (primaria) in master serial mode, prom secondaria vuota. 2. normale funzionamento della FPGA secondo il default program. 3. arriva da remoto l istruzione di caricare nella prom secondaria un nuovo programma. 4. il firmware precedentemente caricato gestisce la ricezione del nuovo programma e attraverso il jtag programma la seconda prom con i dati che arrivano da terra. 5. da terra arriva il comando di riprogrammare la FPGA secondo le nuove direttive 6. il firmware precedentemente caricato gestisce questo comando multiplexando le linee dedicate alla programmazione che congiungono l FPGA dalla prom primaria alla secondaria e latchando questa configurazione con un latch esterno. 7. il firmware precedentemente caricato invia un segnale self-re-boot 8. salto nel buio: tutta l elettronica esterna alla FPGA resta momentaneamente da sola ma sotto tensione sperando che torni i funzione il controllo centrale. 9. il programma dalla prom 2 è stato passato in modalità master serial alla FPGA, le possibilità sono 2 (forse 3) I. tutto ok=> vai al punto 10. II. Il segnale done della FPGA non si alza, programmazione non riuscita; non si riesce più a comunicare con la nostra scheda, il modulo non risponde => vai al punto 11. III. Sembra tutto Ok, qui bisognerà fare attenzione => i. Errore logico umano: improbabile ma pur sempre verificabile. Nonostante le verifiche e i test a terra magari il nuovo firmware ha modificato qualcosa di necessario alla corretta acquisizione degli eventi. Magari ha rallentato alcuni processi per cui si alza troppo il tempo morto ecc => vai al punto 11 che è la via più sicura. ii. Errore di compilazione, di trasmissione o di immagazzinamento nella prom: improbabile anche questo (se consideriamo che l FPGA, bene o male funziona!) cosa è stato modificato? Si riesce ad accorgersene? Se si punto Si va avanti col nuovo firmware. Se arriva un nuovo segnale di programmazione si va al punto Dopo un tempo di speranza stabilito si procede al reset fisico della scheda togliendole completamente l alimentazione. Il latch che trattiene il mux direzionato verso la prom2 viene rilasciato nella posizione originale (prom1) al Power On Reset della scheda. Il ciclo di vita si ripete ripartendo dal punto 1. In realtà il segnale multiplexato è solo quello seriale dei dati che vanno dalle due prom alla FPGA secondo lo schema seguente.

3 Di seguito sono descritte in ordine le fasi attraverso cui si procede per riprogrammare l FPGA con un nuovo firmware. 1- Trasmissione on-line dei bit di programmazione Le prom della Xilinx presenti sulla scheda sono memorie Flash da 4Mb che supportano diverse modalità di programmazione della FPGA, tuttavia esse sono programmabili esclusivamente via JTAG. La programmazione JTAG permette, come è giusto che sia, di scrivere un certo dato ad un certo indirizzo della memoria, la sua particolarità sta nell interfaccia utilizzata, essa è diversa rispetto a quelle più tradizionali che prevedono un address e un data bus. Innanzitutto questa interfaccia è di tipo seriale, ed inoltre il processo di scrittura, di cancellazione, o di read-back della memoria avviene controllando una macchina a stati interna alla prom stessa chiamata TAP controller. Non è quindi possibile utilizzare una logica di controllo (per il caricamento dei dati nella prom) semplice come nel caso tradizionale in cui alla frequenza del clock di scrittura si pongono i dati sul data-bus e con un contatore incrementale si controlla l address bus. È necessario invece mantenere il controllo del TAP controller, i cui stati sono uno standard definito dal JTAG stesso, attraverso degli opportuni controlli. L interfaccia prevede in ingresso un solo bit di input per dati, indirizzi e quant altro, un segnale di clock e un bit di controllo per la macchina a stati. Controllando la macchina a stati del TAP controller è possibile decidere quali registri verrano caricati con i bit che scorrono nell input seriale. È inoltre previsto un canale seriale di output: man mano che un registro viene scritto facendo scorrere i dati in ingresso, l uscita del registro a sorrimento è portata sul canale seriale di output. Facciamo a questo punto anche un altra considerazione: Una spartan3e500 necessita di più di 2 milioni di bit di configurazione, la prom minima che è in grado di contenere questo volume d informazioni è la xcf04 da 4Mb. Questa mole di dati non può

4 essere ospitata sulla FPGA man mano che viene trasferita da terra affinchè poi venga eseguita un unica operazione di scrittura sulla prom. Le risorse di memoria allocabile su una spartan3e500, per quanto vaste, non raggiungono questa portata (block-ram + distributed-ram <500Kb), è evidente quindi che ci sono due strade percorribili, una è quella di comprimere i dati, la seconda è quella di alternare fasi di scrittura alle fasi di ricezione (le due soluzioni ovviamente non sono mutuamente esclusive). È necesario dunque studiare un protocollo dati per la trasmissione dei bit di programmazione che preveda un certo grado di interattività con il modulo ma che allo stesso tempo non intasi le linee di trasmissione del rivelatore (più di 5000 moduli). Per quanto riguarda la compressione dei dati, essa è tanto più efficace tanto più è basso l uso delle risorse della FPGA previsto nel programma stesso. In altre parole, se il firmware che vogliamo trasmettere implementa sulla FPGA è un contatore a 4 bit, è chiaro che bisognerà programmare solo una parte quasi trascurabile dell FPGA stessa. Questo implica che anche il file di programmazione sarà più snello, o meglio sarà formato quasi esclusivamente da zeri. In questo caso una compressione che elimini l inutile trasferimento di una lunga sequenza di zeri risulta molto efficace. Ovviamente man mano che espandiamo il firmware le zone vuote del file di programmazione tenderanno a diminuire sempre di più fino a rendere inutile, o addirittura sconveniente, questo tipo di compressione. C è da dire inoltre che la prom xcf04 è sovrabbondante di spazio (4 Mbit) rispetto ai bit di configurazione necesari alla FPGA (circa 2,17 Mb). La prom è organizzata in 1024 righe da 4096 bit ciascuna (tot 4 Mb), di cui ne risultano occupate per la programmazione solo 555. Il padding degli zero nella zona non interessata alla programmazione può essere automatizzato o addirittura non eseguito. Poter alternare le fasi di scrittura a quelle di ricezione implica l invio in entrambi i sensi di alcuni comandi di hand-shaking. Per questo motivo si rischia di intasare le linee di trasmissione del rivelatore, normalmente utilizzate per l invio di eventi, con una notevole quantità di comandi di controllo. Bisogna quindi cercare una soluzione che richieda una banda di trasferimento il più piccola possibile ma che allo stesso tempo consenta di gestire attivamente la fase di programmazione. 2- La scrittura della Prom tramite JTAG Come accennato prima, la scrittura della prom avviene tramite il protocollo JTAG, il quale prevede il controllo della macchina a stati del TAP controller (Test Access Port). Il JTAG nasceva come strumento di debug per l analisi dei segnali interni di un chip anche una volta montato sul PCB, in seguito, quando se ne apprezzarono e compresero le potenzialità, questo protocollo venne utilizzato anche dai dispositivi a logica programmabile. In questo modo si ottengono le cosiddette piattaforme ISP (In System Programmable), ovvero logiche programmabili dotate di una tecnologia che permette la loro programmazione anche una volta saldate sul PCB di destinazione; in precedenza era infatti necessario posizionare i chip da programmare sulla piazzola del programmatore e una volta saldati non era più possibile programmarli. Riporto di seguito il diagramma degli stati del TAP controller

5 Questa macchina a stati è standard, ed ogni dispositivo con interfaccia JTAG contiene al suo interno un TAP controller identico a questo. Come si può notare, oltre allo stato di reset ci sono tre strade principali da percorrere. run-test/idle è lo stato in cui cisi trova mentre il diapositivo è in fasi di run. La catena che parte con lo stato select-dr-scan serve per gestire la lettura/scrittura di un registro dati, mentre la catena a fianco è dedicata alla scrittura dell instruction register. Per rispettare lo standard ci dovrà dunque essere un instruction register e almeno un data register, tuttavia il progettista del circuito integrato che vuole includere una archiettura JTAG è lascito libero di scegliere quanti data register utilizzare e, addirittura, è libero di stabilire la lunghezza dei registri, compreso l instruction register. Il JTAG è quindi solo uno standard di interfaccia che rimane estremamente flessibile rispetto alle caratteristiche dell hardware che lo ospita. Per procedere alla programmazione della prom XCF è quindi indispensabile che sull FPGA sia presente un controllore JTAG. Questo controllore deve prevedere delle routine prestabilite che per esempio eseguano l operazione di erase della prom ogni volta che la si deve riprogrammare. 3- Selezione della Prom di programmazione Quando è stato caricato il file di programmazione nella prom di configurazione secodaria, è necessario che al re-boot dell FPGA quest ultima venga programmata con il nuovo firmware e quindi non dalla prom di back-up. La modalità con cui si è deciso che l FPGA deve programmarsi è il master serial mode. In questa modalità il ruolo di master è ricoperto dall FPGA stessa, ovvero è lei che genera il clock di lettura per la prom; la prom interpreta dunque il ruolo di slave nella comunicazione. La modalità di configurazione è la medesima per entrambe le prom, quindi i segnali da utilizzare sono gli stessi e possono essere per la maggior parte condivisi da entrambe le prom. In particolare tutti i segnali di output dalla FPGA necessari alla programmazione master serial, (cclk, init_b e done) vengono condivisi da entrambe le prom. Ciò che viene multiplexato è il segnale in uscita da ognuna delle due memorie (D0), decidendo quale dei due canali dati deve essere convogliato verso l FPGA. Il ruolo del flip-flop D presente sul piedino di selezione del MUX è quello di mantenere la selezione anche mentre la logica si sta riprogrammando; in questa fase infatti tutti i piedini dell FPGA (tranne quelli di programmazione) vengono posti in uno stato di alta impedenza. Il flip-flop invece, mantiene la selezione anche quando l FPGA si sta riprogrammando. Il passo successivo quindi, dopo aver ricevuto e caricato tutto il nuovo programma nella prom, è quello di settare il FF affichè sul mux venga selezionata l uscita desiderata. L unica condizione necessaria al FF affiché mantenga il suo stato di uscita è che non venga meno l alimentazione alla scheda. Questa condizione è quella che ci consente, nel caso in cui qualcosa vada storto dopo la programmazione, di ripristinare il sistema anche dopo che se ha perso la capacità di comunicare col centro di comando.

6 Dall esterno dopo il camando di re-boot ci si aspetta un segnale di lock della scheda, ovviamente questa risposte giunge solo nel caso che la peogrammazione si avvenuta correttamente. In caso contrario è necessario procedere con la procedura di ripristino, la quale consiste nel rimuovere la tensione di alimentazione alla scheda per qualche secondo; in questo modo il latch torna allo stato definito di power on reset, cioè riporta la selezione del mux al canale dati della prom di back-up dalla quale l FPGA può riprogrammarsi con il default-firmware sicuramente funzionante. A questo punto il modulo è nuovamente in grado di comunicare con l esterno e si può procedere ad un nuovo tentativo di programmazione. 4- Comando di self-re-boot L FPGA in uso, come molte altre, può essere indotta a ripetere il ciclo di programmazione da prom, sia attraverso un reset fisico (rimozione della tensione di alimentazione) sia attraverso un impulso particolare su un piedino dedicato del chip (prog_b). L impuso di reboot deve essere un impulso attivo basso, quindi la linea deve essere in condizioni normali allo stato logico alto. Essendo una linea che deve poter essere pilotata da più dispositivi (una o più prom, un pulsante, un microcontrollore.) deve essere pilotata da driver tipo open-drain e dotata di un pull-up esterno verso l alimentazione dei banchi di I/O. Le prom possono pilotare questo segnale di re-boot per esempio; se si è collegati alla scheda tramite un programmatore JTAG si può infatti inviare loro un comando che impone una nuova programmazione dell FPGA. In questo caso la prom che ha ricevuto l ordine pone la linea prog_b nello stao logico basso (nel nostro caso non è detto che se il comando viene impartito dalla prom uno allora l FPGA si programma da essa, la prom che invia il comando fa solo in modo che l FPGA inizi un nuovo ciclo di programmazione, da chi dipende solo dallo stato della selezione del MUX precedentemente impostato). Se inoltre si ha un accesso fisico alla scheda è possibile inviare l impulso basso su prog_b tramite un push button configurato allo stesso modo di un driver open-drain. E se non c è possibilità di accesso alla scheda né tramite il cavo programmatore né tantomeno fisicamente come nel caso della scheda del modulo ottico è possibile utilizzare il firmware della FPGA stessa per impartire un segnale di self-re-boot? I modi sarebbero due, il primo consiste nell inviare alla prom secondaria cui si è collegati anche con il bus JTAG ed inviarle il comando di riprogrammazione dell FPGA. Il secondo modo consiste nel collegare un piedino di I/O alla linea prog_b e configurarlo come driver tri-state. In questo modo l FPGA diventa un ulteriore dispositivo in grado di pilotare la linea che impartisce l ordine di reboot.