CNNECST: an FPGA-based approach for the hardware acceleration of Convolutional Neural Networks

Editor's Notes

• #3: Al giorno d’oggi, uno dei temi di maggior interesse nella ricerca sia accademica che industriale sono gli algoritmi chiamati Reti Neurali Convoluzionali, o brevemente CNN. Le CNN sono uno degli algoritmi del appartenenti al campo del Deep Learning. Negli ultimi anni, data la loro efficacia nel riconoscimento di immagine, le CNN sono usate in svariate applicazioni come l’analisi di Big Data, la visione artificiale, la video sorveglianza e così via.. In questi particolari ambiti, l’enorme mole di dati da analizzare, i requisiti di consumo energetico o di computazione ‘real time’ rendono necessario trovare dei modi per accelerare questo tipo di algoritmi
• #4: Al giorno d’oggi, uno dei temi di maggior interesse nella ricerca sia accademica che industriale sono gli algoritmi chiamati Reti Neurali Convoluzionali, o brevemente CNN. Le CNN sono uno degli algoritmi del appartenenti al campo del Deep Learning. Negli ultimi anni, data la loro efficacia nel riconoscimento di immagine, le CNN sono usate in svariate applicazioni come l’analisi di Big Data, la visione artificiale, la video sorveglianza e così via.. In questi particolari ambiti, l’enorme mole di dati da analizzare, i requisiti di consumo energetico o di computazione ‘real time’ rendono necessario trovare dei modi per accelerare questo tipo di algoritmi
• #5: Per questo motivo, in letteratura sono stati proposti diversi tipi di acceleratori basati su GPU, FPGA ed ASIC. Tra questi, occorre trovare il giusto compromesso considerando diversi aspetti, tra cui: consumo energetico, costo, flessibilità e prestazioni della soluzione ottenuta. Le FPGA rappresentano un ottimo tradeoff tra questi dispositivi, in quanto molto più flessibili e meno costose rispetto a una soluzione ASIC, ma al contempo fornendo alte prestazioni con consumi energetici più contenuti rispetto alle GPU. Tuttavia, il processo di design e implementazione di un acceleratore per questo tipo di dispositivo può avere lunghi tempi di sviluppo, specialmente per sviluppatori non esperti in hardware design
• #6: Per questo motivo, in letteratura sono stati proposti diversi tipi di acceleratori basati su GPU, FPGA ed ASIC. Tra questi, occorre trovare il giusto compromesso considerando diversi aspetti, tra cui: consumo energetico, costo, flessibilità e prestazioni della soluzione ottenuta. Le FPGA rappresentano un ottimo tradeoff tra questi dispositivi, in quanto molto più flessibili e meno costose rispetto a una soluzione ASIC, ma al contempo fornendo alte prestazioni con consumi energetici più contenuti rispetto alle GPU. Tuttavia, il processo di design e implementazione di un acceleratore per questo tipo di dispositivo può avere lunghi tempi di sviluppo, specialmente per sviluppatori non esperti in hardware design
• #7: Per questi motivi, lo scopo di questa tesi è di colmare il divario tra il livello di produttività offerto da linguaggi come python negli odierni framework di machine learning, e il processo di design di acceleratori basati su FPGA. Il contributo portato da questo lavoro è infatti un framework per automatizzare il flusso di implementazione di CNN su FPGA, fornendo delle API di alto livello per il design della rete, una libreria per l’implementazione di acceleratori con un’architettura di tipo dataflow, e l’integrazione con un framework di machine learning per il training della rete.
• #8: Andiamo ora a vedere brevemente il funzionamento delle CNN e del particolare pattern computazionale che permette di accelerarle efficientemente. Come si può vedere dall’immagine, una rete e composta da diversi tipi di livelli messi in serie. Nella prima parte della rete troviamo usualmente i livelli convoluzionali, che contraddistinguono le CNN da altri tipi di reti neurali, e dei livelli di pooling o sub-sampling. Ad alto livello, questa parte della rete applica dei «filtri» a un immagine in input, estraendone caratteristiche via via più complesse. L’ultima parte della rete è invece costituita dai cosiddetti fully-connected o linear layers, dello stesso tipo di una rete neurale standard. Questa parte è responsabile dell’aggregazione dell’informazione estratta dalla parte convoluzionale, e fornisce una specie di punteggio per l’appartenenza di un’immagine a una certa classe di oggetti. Tramite trasformazioni matematiche, come per esempio l’operatore SoftMax, è possibile ottenere in uscita dalla rete un vettore di probabilità di appartenenza alle varie classi, come in questo caso in cui la classe più probabile è rappresentata proprio dalla macchina.
• #9: Vediamo ora più nel dettaglio il funzionamento di un livello convoluzionale, che rappresenta la parte computazionalmente più onerosa della rete in termini di numero di operazioni. Un livello convoluzionale è composto da un numero arbitrario di filtri, o kernel, che applicano un operatore di convoluzione sui pixel dell’immagine in ingresso. Ogni filtro è composto da ‘pesi’ il cui valore viene ‘imparato’ attraverso il processo di training della rete. Come si può vedere dallo pseudocodice, il calcolo effettuato da un livello convoluzionale presenta un alto livello di parallelismo, e si presta quindi molto bene ad un’accelerazione in hardware. Il numero di filtri di un livello convoluzionale, così come le loro dimensioni e il numero stesso di livelli nella rete rappresentano alcuni degli iperparametri configurabili di una rete.
• #10: Come detto in precedenza, il framework proposto è in grado di automatizzare il flusso di generazione dell’acceleratore di una CNN. I diversi moduli che compongono la toolchain svolgono le varie funzioni per l’addestramento della CNN, la generazione del codice dell’acceleratore e delle direttive per la sintesi su FPGA.
• #11: Come input, il framework richiede una descrizione ad alto livello della rete, compatibile con quella del framework Caffe sviluppato da Berkley, come quella in esempio nella slide. Questo tipo di descrizione permette di definire gli iperparametri della rete e dei singoli livelli in maniera immediata. Inoltre la compatibilità con la descrizione di Caffe permette di generare alcune reti precedentemente implementate. Il framework espone poi delle API Python per interagire con i diversi moduli del framework e importare la descrizione stessa.
• #12: Una volta definita la struttura della rete, questa viene tradotta in una rappresentazione intermedia implementata tramite una specifica Protocol Buffer, una rappresentazione di dati simile al JSON sviluppata da Google. Questa rappresentazione incorpora la descrizione della rete vista precedentemente, e aggiunge delle informazioni sui dataset che verrano utilizzati per il training e sul dispositivo finale.
• #13: Lo step successivo è quello del training della rete, ovvero della generazione dei ‘pesi’ che permettono alla rete di filtrare e classificare l’immagine correttamente. Questo passaggio è realizzato tramite un modulo che si integra con il framework TensorFlow, generando il modello della rete a partire dalla rappresentazione intermedia. Il training è effettuato tramite l’algoritmo di apprendimento più comunemente utilizzato, lo SGD, utilizzando la cross entropy come funzione di costo, e parametri come il learning rate specificato dall’utente. Una volta completato l’addestramento, i pesi finali vengono esportati in modo da essere utilizzati durante la generazione del codice dell’acceleratore.
• #14: Infine, il modulo per la generazione dell’acceleratore utilizza le librerie C++ incluse nel framework per l’implementazione di un’architettura di tipo dataflow di una CNN. In particolare, la libreria fornisce delle funzioni che implementano i diversi tipi di layer della rete, e che contengono delle direttive per definire le caratteristiche che l’implementazione hardware dovrà avere, come per esempio il numero di processing elements che devono operare in parallelol. Il passaggio dal codice generato all’effettivo RTL dell’acceleratore è realizzato tramite la Vivado Dsign Suite di Xilinx, che includono gli strumenti per l’High Level Synthesis e la generazione del bitstream per configurare l’FPGA.
• #15: L’architettura dell’acceleratore generato è composta da diversi moduli in cascata che implementano i diversi livelli della rete. La connessione tra i singoli di moduli avviene tramite ‘Stream’ realizzati come FIFO, per ottenere una computazione di tipo dataflow. I dati in input e in output all’acceleratore vengono letti e scritti in memoria tramite un modulo DMA per diminuire la latenza dovuta al trasferimento dei dati, e viene inviato all’acceleratore della CNN tramite interfacce che utilizzano il protocollo AXI-Stream.
• #16: Oltre alle connessioni stream tra i singoli moduli, la realizzazione di un’architettura dataflow è resa possibile dal buffering dei risultati parziali nei moduli che implementano i livelli della parte convoluzionale. Mentre infatti per quanto riguarda il fully connected layer è possibile ottenere un flusso di dati completamente streaming, per quanto riguarda la convoluzione, è necessario salvare i pixel in input in quanto verranno riutilizzati da diverse posizioni dei filtri che compongono il livello. Per questo motivo i livelli convoluzionale e di pooling sono stati implementati con una finestra di shift-registers che possono essere letti e scritti in parallelo. In particolare, come si può vedere dall’immagine, nella window vengono salvati i pixel necessari per calcolare la convoluzione di una prima riga dell’immagine in output. Quando il kernel, in blu, è stato fatto scorrere su tutta la finestra, la window viene fatta virtualmente scorrere in basso, eliminando la prima riga dell’immagine in input, che non sarà più utilizzata, e caricando una nuova riga per proseguire con la computazione. I pesi dei livelli vengono inoltre salvati nelle memorie locali dell’FPGA e non devono essere caricati dalla memoria. In questo modo è quindi possibile ottenere una catena di moduli che lavorano come una pipeline e permettono di avere una computazione di tipo streaming della rete implementata.
• #17: Per validare l’approccio proposto, abbiamo utilizzato due board che montano due diverse FPGA. La prima, la Zedboard qui sulla sinistra, monta un SoC di tipo Zynq, composto da un processore ARM e da una FPGA derivata dalla serie Artix di Xilinx. La seconda invece, è una board che monta una FPGA Virtex-7. Come si può vedere, i due dispositivi presentano un numero molto diverso di risorse disponibili, in particolare per quanto riguarda il numero di LUT e di Digital Signal Processing, che come vedremo saranno la risorsa critica per i design testati.
• #18: Per quanto riguarda invece le reti utilizzate, abbiamo addestrato due coppie di modelli su due diversi datasets di immagini a singolo canale, quindi in bianco e nero, di cifre scritte a mano. Il primo è lo US Postal Service dataset, le cui immagini sono ricavate da codici postali scannerizzati dai pacchi dei servizi postali statunitensi. Il secondo invece è il MNIST dataset, uno dei primi dataset utilizzati quando le CNN sono state proposte da LeCun, e tuttora molto utilizzato in applicazioni di questo tipo. Le reti differiscono per quanto riguarda il numero di livelli che le compongono. In particolare si può vedere come il numero di floating point operations aumenti significaticamente all’aumentare del numero di layer e della dimensione dei dati da classificare. I modelli utilizzati sono stati sviluppati internamente, tranne che per l’ultimo, che consiste in una versione leggermente modificata di LeNet-5, una CNN che è stata proposta dallo stesso LeCun nel primo paper sulle CNN.
• #19: Per quanto riguarda lo USPS dataset, sono state realizzate 4 diverse implementazioni. Una della rete più piccola su Zedboard, quindi implementando l’acceleratore sull’FPGA del SoC Zynq, e altre 3 per le due diverse reti su Virtex-7, di cui una in particolare è stata realizzata con 4 acceleratori della rete in modo da sfruttare il maggior numero di risorse disponibili sulla FPGA e di ottenere una parallelizzazione a grana più grossa per classificare il dataset di test. Inoltre, la maggior velocità di esecuzione ha permesso di ridurre notevolmente il consumo energetico del dispositivo Per quanto riguarda invece il consumo di risorse, in questa tabella sono riportati gli utilizzi per le 4 diverse configurazione. Come si può vedere in particolare dalle due implementazioni dellae reti small e large sulla stessa FPGA, all’aumentare della dimensione della rete, e quindi al numero di operazioni che vengono effettuate in parallelo dall’acceleratore, il numero di LUT e DSP che vengono utilizzati per le unità di moltiplicazione e somma floating point aumentino significaticamente.
• #20: Passando ora al MNIST dataset, date le maggiori dimensioni delle due reti implementate, è stato possibile le due reti solo su Virtex-7