Accelerare il calcolo distribuito con gli FPGA

• 
• Tweet
• Pin It
• Condividi per email

Anziché installare supercomputer più veloci e “affamati” di energia per affrontare algoritmi scientifici sempre più complessi, università e aziende private stanno applicando piattaforme distribuite su cui progetti quali SETI@home calcola propri dati usando migliaia di personal computer. [1,2] Le attuali reti di calcolo distribuito usano tipicamente delle CPU o delle GPU per calcolare i dati di progetto. Anche gli FPGA sono utilizzati in progetti come COPACOBANA, che impiega 120 FPGA di Xilinx per “raccare” i file criptati con algoritmo DES usando la metodologia “brute-force”. [3] Tuttavia in questo caso, gli FPGA sono tutti “raggruppati” in un unico luogo – un approccio senza dubbio costoso per i budget sempre più “stringati” di un’università o di un’azienda.

Attualmente gli FPGA non sono considerati per la funzione di calcolo distribuito perché il loro utilizzo richiede la presenza di un PC dedicato che riconfiguri continuamente l’intero FPGA con un nuovo flusso di bit. Ma ora, con l’applicazione della tecnologia di riconfigurazione parziale di Xilinx, il progetto di client basati su FPGA per una rete di calcolo distribuita è diventato fattibile. Il gruppo presso la Facoltà di Scienze Applicate dell’Università di Amburgo ha creato un prototipo di un simile client e l’ha realizzato in un singolo FPGA. Il progetto è stato strutturato in due sezioni: una parte statica e una dinamica. La parte statica è caricata all’avvio dell’FPGA, mentre il processore realizzato in quest’ultima scarica la parte dinamica da un server di rete. La parte dinamica è la regione di riconfigurazione parziale, che offre risorse FPGA condivise. [4] Con questa configurazione, l’FPGA potrebbe essere situato ovunque nel mondo, offrendo ai progetti di calcolo l’accesso a una grande quantità di risorse di calcolo a fronte di un budget più contenuto.

Una rete distribuita di SoC
Su un processore Microblaze gira il software del client, che gestisce le riconfigurazioni parziali assieme al flusso di bit e agli scambi di dati.
Con le loro risorse di elaborazione parallela dei segnali, gli FPGA forniscono una velocità di trasferimento dati quattro volte superiore rispetto a un microprocessore, usando un clock che è otto volte più lento e a fronte di un consumo otto volte inferiore. [5] Per sfruttare questa potenza di calcolo per velocità elevate di dati in ingresso, i progettisti eseguono tipicamente gli algoritmi in serie, come la cifratura DES. [3] È stato sviluppato il prototipo di una rete distribuita di SoC (DSN) per aumentare la velocità di tali algoritmi, e per elaborare grandi insiemi di dati usando risorse FPGA distribuite. Il progetto di rete adotta un’architettura client-broker, in modo da poter assegnare a tutti i client system-on-chip (SoC) dotati di registro a qualsiasi progetto computazionale di un qualsiasi membro della rete (Fig. 1).

Fig. 1 – Rete distribuita di SoC con client SoC forniti dagli FPGA e gestiti da un server centrale di intermediazione. I client del progetto distribuiscono i moduli di riconfigurazione parziale e gli insiemi di dati. La parte dinamica di un client SoC fornisce le risorse attraverso il PRR, e un microcontrollore contenuto nella parte statica elabora la riconfigurazione

Questo sarebbe impossibile in un’architettura client-server, che connette ogni client SoC a un singolo progetto. Inoltre, è stata scelta questa architettura broker-server per ridurre il numero di connessioni TCP/IP di ciascun FPGA ad appena una. Gli FPGA della DSN calcolano gli algoritmi con un insieme dedicato di dati, mentre il server broker gestisce i client SoC e i client del progetto. Il broker pianifica le attività dei client SoC connessi, in modo che ciascun progetto abbia allo stesso tempo pressoché la stessa potenza di calcolo, o usi lotti di tempo se vi sono meno SoC rispetto ai progetti disponibili con requisiti computazionali. Il client di progetto fornisce il modulo di riconfigurazione parziale (PRM) e un insieme di dati di stimolo in ingresso. Dopo essersi connesso al server broker, il client di progetto invia i file di bit del PRM al server, che li distribuisce ai client SoC con una regione parzialmente riconfigurabile (PRR) libera. La parte statica del client SoC, un microcontrollore basato su architettura MicroBlaze, riconfigura dinamicamente il PRR con il PRM ricevuto.
Nella fase successiva, il client del progetto inizia a inviare insiemi di dati e riceve la risposta calcolata dal client SoC attraverso il server di intermediazione. In relazione alle intenzioni del client del progetto, ad esempio esso confronta diversi insiemi di dati calcolati o li valuta per i propri scopi computazionali.

Il client SoC
È stato sviluppato il client SoC con un FPGA Virtex-6 di Xilinx, il dispositivo XC6VLX240T, disponibile con la scheda di valutazione ML605. Su un processore Microblaze gira il software del client, che gestisce le riconfigurazioni parziali insieme al flusso di bit e con gli scambi di dati (Fig. 2). L’interfaccia fra la parte statica e la parte dinamica è una periferica del Bus Locale del Processore (PLB) che incapsula il PRR nella propria logica utente. Nella parte dinamica risiedono le risorse FPGA condivise, per i core IP di accelerazione forniti dal PRM ricevuto. Per archiviare i dati ricevuti e calcolati, è stata scelta una memoria DDR3 al posto di una CompactFlash, per via della sua velocità superiore di trasmissione dati e per la quantità illimitata di accessi in scrittura. Il PRM è memorizzato in una sezione dati dedicata per controllare le sue dimensioni e per evitare conflitti con altri insiemi di dati. La sezione è impostata a 10 Mbyte, che è abbastanza per archiviare la configurazione completa dell’FPGA. In tal modo, ciascun PRM dovrebbe trovare posto in questa sezione. Sono state anche create delle sezioni dati per gli insiemi di dati ricevuti e per quelli calcolati. Questi hanno dimensioni pari a 50 Mbyte, in modo da assicurare uno spazio degli indirizzi sufficiente per esempio per le immagini o per i file di testo cifrati.

Fig. 2 – Il client SoC è un sistema processore con una parte statica e una periferica bus master, che contiene la regione parzialmente riconfigurabile (PRR). È realizzata con l’ FPGA Virtex-6 XC6VLX240T su una scheda ML605

La gestione di queste sezioni di dati si basa su una matrice di 10 strutture di amministrazione; l’ultima contiene gli indirizzi di inizio e di fine di ciascuna coppia di insiemi di dati e un flag che indica gli insiemi di dati calcolati.
Per connettere la parte statica al PRR, sono state valutate le connessioni IP date dall’EDK di Xilinx, come il Fast Simplex Link (FSL) lo slave PLB e il master PLB. È stata scelta una configurazione master/slave PLB per ottenere un IP semplice da configurare che invia e riceve richieste dati senza il supporto di MicroBlaze, riducendo significativamente il numero di cicli di clock e i trasferimenti di parole. Per la comunicazione client-server, l’IP Ethernet sintetizzato internamente all’FPGA costituisce una periferica essenziale della parte statica del sistema di elaborazione.
Con l’SDMA (soft-direct-memory access) della connessione locale TEMAC al controllore di memoria, i trasferimenti dei dati e del file di bit produce un carico inferiore sul PLB. Dopo aver ricevuto una pagina di 1518 byte, l’SDMA genera una richiesta di interrupt, di modo che la funzione lwip_read() si sblocchi e possa gestire questo dato. La funzione lwip_write() comunica all’SDMA di effettuare un trasferimento DMA al TEMAC attraverso il canale TX.

È stato realizzato il Xilkernel, un kernel per i processori dedicati di Xilinx, come un sistema operativo in tempo reale sottostante al software del client SoC, allo scopo di utilizzare la libreria di strutture LwIP (lightweight TCP/IP) con la modalità a connettore per la connessione server TCP/IP. La figura 3 fornisce una panoramica dell’inizializzazione, della creazione, della trasmissione e delle sequenze di elaborazione dei thread del client. Il thread del client SoC stabilisce una connessione verso il server e riceve un flusso di bit del PRM (“pr”) che esso archivia in una memoria DDR3, applicando il sistema di file XFILMFS. In seguito l’Xps_hwicap (punto di accesso della configurazione interna dell’hardware) riconfigura il PRR con il PRM. Infine, la periferica bus master imposta un bit di stato che istruisce il SoC client di inviare una richiesta al server. Il server risponde con un insieme di dati (“dr”), che sono archiviati anch’essi dal client SoC nella memoria su scheda. Questi file di dati contengono una sequenza di contenuti come lunghezza in uscita+”ol”+dati da calcolare.

Fig. 3 – I cicli di inizializzazione e di elaborazione software del SoC client includono la riconfigurazione del PRR con un PRM, il recupero dell’insieme di dati dal server, l’inizio dell’elaborazione e la restituzione dell’insieme di dati ai thread del server. Le linee in nero indicano la creazione di thread da parte delle chiamate alla funzione sys_thread_new() dalla libreria Xilkernel

La lunghezza in uscita è la lunghezza del byte, che determina l’intervallo di memoria per i dati di risultato seguiti dalla coppia di caratteri “ol”. Con il primo messaggio “dr” ricevuto, viene creato un thread di calcolo e di invio. Il thread di calcolo trasferisce gli indirizzi degli insiemi di dati di ingresso e di risultato verso l’interfaccia slave della periferica PRR e avvia l’elaborazione dell’insieme di dati autonomo del PRM. Una struttura di amministrazione fornisce questi indirizzi per ciascun insieme di dati e contiene un flag “done”, che è impostato dopo che i dati di risultato sono completamente disponibili. Nell’attuale versione del concetto di software del client, i thread di calcolo e quello di invio comunicano attraverso questa struttura, e il thread di invio controlla ripetutamente il bit “done” e applica le chiamate alla funzione lwip_write() sui risultati archiviati in memoria. Quando si effettua il test del client SoC, si è determinato che con tutti gli interrupt abilitati, mentre la riconfigurazione del PRR è in azione, questo processo si blocca in modo casuale dopo che il temporizzatore dello Xilkernel genera una chiamata di pianificazione al MicroBlaze. Questo non è avvenuto con tutti gli interrupt disabilitati o mentre si usa un modulo software indipendente per il processore MicroBlaze del client SoC senza il supporto dello Xilkernel.

Periferica bus master con istanziazione del PRM
Per ottenere dati di stimolo autocontrollati e uno scambio di risultati fra il PRM e la memoria esterna, la periferica bus master è stata strutturata come un elemento processore con un percorso dati e un percorso di controllo (Fig. 4). All’interno del percorso dati, è stata inclusa l’interfaccia del PRM fra due blocchi FIFO con una profondità di 16 parole ciascuno, allo scopo di compensare per i ritardi nella comunicazione e nel trasferimento dati. Entrambe le FIFO dei percorsi dati sono connesse direttamente all’interfaccia bus master del PLB. In questo modo, si ottiene un vantaggio significativo in termini di temporizzazioni da un trasferimento dati diretto eseguito da una macchina agli stati finiti (FSM). Non è richiesto alcun software, di conseguenza non ha luogo alcuna operazione intermedia di memorizzazione dati nel file di registro del MicroBlaze.

Fig. 4 – La periferica del bus master opera come un elemento processore. L’interfaccia del PRM include la parte dinamica con un’istanziazione del componente del PRM

Questa architettura carica-memorizza del processore RISC richiede sempre due cicli di trasferimento sul bus per caricare un registro CPU da una posizione di indirizzo e per memorizzare il contenuto del registro in un altro membro del PLB. Con la connessione alla cache dati DXCL del MicroBlaze al controllore di memoria come alternativa al PLB, la temporizzazione di questi cicli carica-memorizza non migliorerebbe. Questo avviene perché i dati ricevuti e i risultati di calcolo trasmessi sono tutti gestiti in una volta sola, parola per parola, senza utilizzare i vantaggi delle memorie tampone. Di conseguenza, le attività della periferica PRR sono disaccoppiate dall’elaborazione software del master di MicroBlaze. Quindi, il trasferimento dei dati del PRR non causa ulteriori inversioni di contesto nello Xilkernel. Tuttavia si ha ancora la competizione di due master per un accesso al bus, che non può essere evitata. L’interfaccia slave della periferica contiene quattro registri controllati via software che forniscono il percorso di controllo con degli indirizzi di inizio e di fine degli insiemi di dati in ingresso e in uscita. Un altro registro software introduce un bit di “avvio” della FSM, che dà inizio ai cicli di trasferimento dei dati al master. Lo stato di un ciclo completato di elaborazione dati è disponibile con l’indirizzo del quinto registro software verso il software del client. Con il diagramma di stato della FSM del percorso di controllo, la strategia per prioritizzare i cicli di scrittura al PLB diventa chiara (Fig. 5).

Fig. 5 . Diagramma a stati del percorso di controllo della periferica bus master. Le richieste di scrittura dati sul bus sono prioritizzate per evitare che una OUT_FIFO piena arresti gli algoritmi PRM. Stile di modellizzazione UML: uscite Moore con l’etichetta Do/ e uscite Mealy con l’etichetta Exit/

L’estrazione dei dati dalla OUT_FIFO domina sul riempimento della IN_FIFO, per evitare che una OUT_FIFO piena interrompa l’esecuzione dell’algoritmo da parte del PRM. La lettura o la scrittura verso la memoria esterna avviene in sequenze alternate, perché è disponibile solo un tipo di accesso al bus per volta.
Quando una reinizializzazione software dal thread di calcolo del client avvia la FSM (Fig. 3), la prima cosa che accade è una lettura dalla memoria esterna (stato READ_REQ). Da allora, il bus master segue la logica di decisione data
dalle condizioni di transizione dallo stato STARTED (Tab. 1).

Tabella 1 – Le decisioni di controllo della FSM nello stato STARTED con la priorità in scrittura IPIF

Le uscite Mealy della FSM (etichetta Exit/) preparano i contatori degli indirizzi a incrementare quando viene completato un trasferimento su bus. Qui, i due contatori sono introdotti direttamente all’interno del codice della FSM. Generalmente si preferiscono temporizzatori e contatori di indirizzi come processi sincronizzati e separati, attivati semplicemente dalle uscite della FSM, allo scopo di mantenere la logica di transizione del contatore contenuta e libera da uscite multiplexer non necessarie per la risposta sullo stato del contatore. A questo punto, i risultati del compilatore di sintesi dell’XST presentano uno schematico RTL con una chiara estrazione della FSM parallelamente ai contatori caricabili, con uscite di abilitazione del clock pilotate da una logica di decodifica con stato previsto. Malgrado uno stile di codice VHDLX comportamentale più leggibile, le risorse FPGA e le primitive semplici sono utilizzate senza perdite di funzionalità.

La definizione della parte dinamica con PlanAhead
Il flusso di progettazione per la configurazione di una parte statica e di una parte dinamica all’interno dell’FPGA è un processo di sviluppo complesso che comporta diverse fasi con lo strumento PlanAhead di impostazione dei vincoli del progetto fisico. Il primo sforzo è stato un flusso di progettazione per una piattaforma di riconfigurazione dinamica pilotata dal sistema PetaLinux e realizzata su una scheda ML505. [6] Con l’attuale iterazione, le fasi di progettazione per integrare un PRR direttamente all’interno della logica utente di una periferica sono molto più pratiche rispetto al metodo precedente che consisteva nell’aggiungere macro del bus e un registro di controllo del dispositivo (DCR) come un’interfaccia PLB per il PRM e un ulteriore bridge PLBDCR per abilitare le macro del bus. Qui di seguito si può vedere come siano state fissate le dimensioni e la posizione della parte dinamica con i vincoli AREA_GROUP, che sono inclusi nel file UCF del progetto PlanAhead:

Una concatenazione di nomi di istanze specifica la regione di riconfigurazione parziale interna (prm_interface.vhd) con il nome di istanza PRR. Per tutte le risorse FPGA che si vogliono includere nel PRRR desiderato, viene specificata una regione rettangolare con le proprie coordinate inferiore sinistra e superiore destra.
Questa scelta speciale copre solo le slice e la BRAM, perché gli elementi DSP disponibili appartengono alle regioni di clock dedicate e sono utilizzati per la realizzazione del Controllore di Memoria Multiporta (MPMC) (Tab. 2).

Tabella 2 – Risorse allocate per la parte dinamica del client SoC

Per evitare che la netlist PRM generata da ISE usi delle risorse escluse, sono state impostate le opzioni di sintesi a dsp_utilization_ratio = 0; use_dsp48 = false; iobuf = false
Infine, l’Editor FPGA offre una novità: il posizionamento della parte statica è situato in un’area separata completamente dal PRR, che in questo caso particolare usa risorse molto contenute (Fig. 6).

Fig. 6 – Piazzamento di risorse della parte statica (lato destro) e della parte dinamica (lato sinistro, con un ovale bianco) in base alla specifica sull’area per il PRR

Un client SoC con un PRM per l’elaborazione delle immagini
È stato dimostrato il funzionamento del client SoC e la sua comunicazione al server TCP/IP con una combinazione di filtri Sobel/mediani realizzati in un PRM (Fig. 7).

Sono state sviluppate le operazioni attigue all’elaborazione delle immagini con il Xilinx System Generator, che ha fornito il vantaggio della simulazione con Simulink e della generazione automatica del codice RTL.

Un deserializzatore ha convertito il flusso di pixel in ingresso in una matrice da 3 x 3 pixel, che sequenzia come una maschera sull’intera immagine e fornisce l’ingresso alla somma parallela dei prodotti dei filtri o ai confronti successivi del filtro mediano. [7]

Figura 7 – Risultato dell’elaborazione del PRM per il rilevamento dei bordi. L’immagine al PRM degli stimoli in ingresso con scala di grigi è mostrata a sinistra, mentre la risposta da un PRM con una combinazione di filtri Sobel/mediani è visibile a destra

I vettori dei pixel in ingresso e in uscita dei filtri hanno un’ampiezza di 4 bit, così è stato inserito un wrapper PRM che multiplexa gli otto nibble del vettore di ingresso a 32 bit dalla FIFO di sincronizzazione. Con uno script MATLAB è stata convertita un’immagine PNG da 800 x 600 in pixel con una scala di grigi da 4 bit per lo stimolo di ingresso del PRM. All’uscita del filtro otto registri da 4 bit sono riempiti successivamente e sono concatenati per il trasferimento di parole verso la OUT_FIFO (Fig. 4). La tabella 3 riassume i risultati delle misure di temporizzazione effettuate con tre passaggi operativi del client SoC: la ricezione di un file di bit PRM, la riconfigurazione del PRR e le sequenze di elaborazione delle immagini. I cicli in ricezione e in elaborazione delle immagini, dal primo all’ultimo trasferimento dati, sono stati catturati con una misura dell’oscilloscopio digitale a un’uscita GPIO che commuta fra due stati in seguito a chiamate XGpio_WriteReg().

Tabella 3 – Risultati delle misure di temporizzazione; riconfigurazione con gli interrupt disabilitati. Velocità di clock del processore e delle periferiche fclk = 100 MHz

Gli intervalli di riconfigurazione hanno tutti la stessa durata, perché nessun evento di pianificazione Xilkernel ha interrotto il funzionamento HWICAP guidato dal software. Un funzionamento HWICAO controllato da una FSM senza interazione con il processore MicroBlaze offrirà una durata inferiore con una velocità di riconfigurazione di più di 112 kbyte/secondo, anche con gli interrupt abilitati. Durante la trasmissione del PRM dal broker al client SOC, la connessione si è subito interrotta. Con un ritardo di un millisecondo fra ciascun gruppo di 100 byte trasmessi, il client SoC ha effettuato una comunicazione non distribuita. Parallelamente ai cicli di elaborazione delle immagini, il normale threading Xilkernel ha causato una competizione nell’accesso al PLB, di conseguenza, il client SoC ha funzionato in condizioni tipiche. La sequenza di binarizzazione ha il valore di durata di 600 x 800/100 MHz = 4.8 ms, perché solo un singolo confronto è attivo.

Questa sequenza è annidata in due trasferimenti di immagine attraverso il PLB, il quale richiede un minimo di cinque cicli di clock per parola, come estratto da una simulazione funzionale di bus 2 x 5 x 600 x 800/(8 x 100 MHz) = 6 ms. Dato che tutti i numeri della misura per i trasferime
nti dati sono superiori rispetto a quanto delle stime grossolane hanno portato ad attendersi, si sta effettuando un’analisi dettagliata dell’intera catena di temporizzazione realizzata dalla lettura del bus, dal riempimento e dallo svuotamento della FIFO, dalla serie di elaborazioni di immagini e dalla scrittura su bus.

La potenza della riconfigurazione parziale
Per calcolare algoritmi complessi, è conveniente impiegare la potenza delle reti di calcolo distribuito. Realizzazioni allo stato dell’arte di queste reti operano solo con CPU e con GPU.
Questo prototipo di un’architettura di rete distribuita di SoC utilizza la funzionalità di elaborazione parallela dei segnali degli FPGA per calcolare algoritmi complessi. Nella tecnologia di riconfigurazione parziale di Xilinx c’è la chiave per utilizzare risorse FPGA condivise in tutto il mondo. In questa architettura, la parte statica del client SoC riconfigura la parte dinamica dell’FPGA con acceleratori aggiornati in modo auto-controllato. Si deve migliorare il client SoC per far girare l’HWICAP con gli interrupt abilitati, in modo che si mantenga pienamente reattivo.

Un passo in questa direzione è una riconfigurazione controllata da una FSM, che non pone alcun carico sul processore. Tuttavia si deve analizzare l’influenza dei trasferimenti di PLB e anche il collo di bottiglia del MPMC. Per gestire il client SoC, il Xilkernel connesso con l’LwIP assicura la simultaneità con i thread per i driver di riconfigurazione, per l’interfaccia bus della parte dinamica e per altre applicazioni. Si è posta ulteriore attenzione sull’analisi della temporizzazione del sistema client-server e i cicli di elaborazione della parte dinamica allo scopo di identificare la configurazione software/modello RTL con una velocità di trasmissione dati migliore e una comunicazione affidabile. Per la fase successiva del progetto di client SoC, si devono tenere in considerazione le caratteristiche del bus AXI4. In generale, gli scambi PRM possono essere trattati come ulteriori attività su hardware che operano in combinazione con un insieme di funzioni software. Da ultimo, ma non meno importante, il progetto del software del server per arrivare a una maggiore soddisfazione dell’utente è ancora in fase di rifinizione.

Bibliografia

1. Unofficial BOINC Wiki, “Boinc FAQ: Introduction to boinc,” http://www.boinc-wiki.info/
2. Markus Tervooren, all project stats.com, http://www.allprojectstats.com/
3. S. Kumar, J. Pelzl, G. Pfeiffer, M. Schimmler and C. Paar, “Breaking ciphers with COPACOBANA, a costoptimized parallel code breaker, or how to break DES for 8,980 eur,”
http://www.copacobana.org/paper/CHES2006_copacobana_slides.pdf
4. Frank Opitz, “Development of an FPGA-based distributed computing platform.” Master’s thesis, HAW Hamburg, 2011, http://opus.haw-hamburg.de/volltexte/2012/1450/pdf/Masterarbeit_Frank_Opitz.pdf
5. Ivo Bolsens, “Programming Modern FPGAs,” http://www.xilinx.com/univ/ mpsoc2006keynote.pdf
6. Armin Jeyrani Mamegani, “Implementation and evaluation of methods for partial and dynamic reconfiguration of SoC- FPGAs.” Master’s thesis, HAW Hamburg, 2010, http://opus.haw-hamburg.de/volltexte/2010/1083/pdf/MA_A_Jeyrani.pdf
7. Edris Sahak, “Partial reconfiguration of an SoC-based image-processing pipeline.” Bachelor’s thesis, HAW Hamburg, 2011, http://opus.haw-hamburg.de/volltexte/2011/1420/pdf/BA_E_Sahak.pdf

Dott. Frank Opitz, Università delle Scienze Applicate di Amburgo, Facoltà di Ingegneria e Informatica, opitz.frank@googlemail.com, Edris Sahak, Università delle Scienze Applicate di Amburgo, Facoltà di Ingegneria e Informatica, Dipartimento di Informatica, edris.sahak@haw-hamburg.de, Prof. dott. ing. Bernd Schwarz, Università delle Scienze Applicate di Amburgo, Facoltà di Ingegneria e Informatica, Dipartimento di Informatica, schwarz@informatik.haw-hamburg.de

• 
• Tweet
• Pin It
• Condividi per email