POLITECNICO DI MILANO

BSSBitstream Sharing

System

Filippo Sironi: filippo.sironi@dresd.org

DDynamic ynamic RReconfigurability econfigurability inin EEmbeddedmbedded SSystemsystems

DDesignesign

3dDRESD 2008 3dDRESD 2008 –– Goglio Goglio (Baceno)(Baceno)

2

MotivazioniMotivazioni

Le FPGA sono dispositivi che stanno guadagnando i consensi di molte compagnie

Le FPGA offrono la flessibilità che gli ASIC non potranno mai offrire

La possibilità di affiancare un sistema operativo alle FPGA ne incrementa in modo esponenziale le potenzialità

3

IndiceIndice

IntroduzioneDescrizione del ProblemaObiettivi del Progetto

Stato dell’ArteSoluzione

HardwareSoftware

RisultatiConclusioniSviluppi FuturiDomande

4

Descrizione del ProblemaDescrizione del Problema

La problematiche sono individuabili sia a livello di configurazione hardware che a livello software

Considerando il caso di studio dei sistemi Inpeco è possibile riscontrare i tipici problemi che affliggono i sistemi completamente centralizzati:

Difficoltà di fronteggiare gli errori e i guasti che si verificano nei nodi periferici o, nel caso peggiore, nel nodo centrale che costituisce un single-point-of-failure

Difficoltà di gestione nel caso in cui i nodi debbano essere aggiornati, aggiunti o eliminati

5

Descrizione del ProblemaDescrizione del Problema

Considerando una possibile soluzione che prevede l’utilizzo di un sistema operativo con supporto alla riconfigurazione on-demand è facile individuare due punti deboli:

È possibile che le funzionalità richieste dalle applicazioni non siano locali al nodo in uso e quindi raggiungibili dal sistema operativo (Disponibilità)

È difficile sfruttare in modo adeguato un nodo collegato ad un sistema complesso, sistema che ha lo scopo di portare a termine un determinato compito (Scalabilità)

6

Obiettivi del ProgettoObiettivi del Progetto

Migliorare la capacità di far fronte ai problemi scatenati dai nodi distribuendo il controllo su tutti i nodi che diventano così nodi intelligenti

Migliorare la disponibilità del singolo nodo andando ad ampliare le possibilità di reperire le funzionalità richieste dalle applicazioni

Aumentare la flessibilità del sistema proponendo una nuova architettura per i nodi

Aumentare la scalabilità del sistema proponendo un modello di collaborazione tra i nodi

Stato dell’ArteStato dell’Arte

Dispositivo riconfigurabile: FPGAFlessibile

Sistema operativo: LinuxFlessibileModificabileLibero

Riconfigurazione: IP-Core Manager (IPCM)ParzialeDinamica

Riconfigurazione on-demand: Reconfiguration Manager

DemoneApplicazione User Space

7

Soluzione (1/9) Soluzione (1/9)

L’introduzione di nodi basati su FPGA permette di raggiungere un elevato grado di flessibilità per ogni singolo nodo.

L’utilizzo di nodi flessibili ci permette di far fronte alle differenti evoluzioni, anche impreviste (guasti), del sistema

8

Soluzione (2/9) Soluzione (2/9)

L’utilizzo di nodi flessibili ci permette di elevare il grado di disponibilità del nodo che è in grado di portare a termine un insieme di funzionalità, funzionalità che possono essere reperite da altri nodi collegati al sistema

L’utilizzo di nodi flessibili ci permette inoltre di garantire un più elevato livello di scalabilità grazie alla possibilità di configurare più nodi per svolgere la medesima funzionalità

9

Soluzione (3/9) Soluzione (3/9)

La naturale evoluzione del sistema prevede l’introduzione di un repository di funzionalità distribuito tra i vari nodi collegati alla rete cooperativa

Il concetto di rete cooperativa ci permette di introdurre il concetto di classe di funzionalità.

Da un punto di vista strettamente pratico è inutile che un nodo progettato per supportare una certa classe di funzionalità cooperi con altri nodi che si supportano una seconda classe di funzionalità

10

Soluzione (4/9)Soluzione (4/9)

Livello hardwareFPGANetwork

Livello softwareLinux (sistema operativo)IPCM (riconfigurazione dinamica e parziale)Reconfiguration Manager (riconfigurazione on-demand)BSS (repository distribuito)

BSSFunctionalities ManagerFunctionalities DatabaseConsole

11

Soluzione (5/9)Soluzione (5/9)

Functionalities ManagerGestisce le richieste

LocaliRemote

Coopera con il Functionalities DatabaseRecupero delle funzionalità

Condivide le funzionalità locali con i nodi che appartengono alla rete cooperativa

12

Soluzione (6/9)Soluzione (6/9)

Il Functionalities Manager prevede due tipi di comunicazioni

Interne (tra Reconfiguration Manager e Functionlities Manager)Esterne (tra Functionalities Manager collegati alla rete cooperativa)Il protocollo applicativo utilizzato per le comunicazioni interne ed esterne è il medesimo e si ispira al protocollo HTTPLe comunicazioni interne si basano sullo stack TCP/IPLe comunicazioni esterne possono operare attraverso vari mezzi di comunicazione (Ethernet, WiFi, Bluetooth, IrDA, ecc…)

13

Soluzione (7/9)Soluzione (7/9)

Functionalities DatabaseServe le richieste del Functionalities ManagerEsegue i comandi della ConsoleMantiene la struttura dati che permette di immagazzinare le funzionalità e di effettuarne un filtraggio

14

Soluzione (8/9)Soluzione (8/9)

ConsoleOpera con il Functionalities Database attraverso il Functionalities ManagerPermette di aggiungere funzionalità al Functionalities DatabasePermette di eliminare funzionalità dal Functionalities DatabaseLe comunicazioni tra Console e Functionalities Database rientrano nella categoria delle comunicazioni interne e si basano quindi sullo stack TCP/IP

15

Device 0

Soluzione (9/9)Soluzione (9/9)

16

Network

Cooperative Network

Operating System& Reconfiguration Manager

Functionalities Manager

FunctionalitiesDatabase

Console

Device 1

Device 2

Device 3

17

RisultatiRisultati

L’architettura proposta per il nodo elaborativo è stata riprodotta con successo facendo uso di:

Avnet Xilinx Virtex-II Pro Evaluation KitEthernet EMAC ControllerµCLinux 2.4IPCMAccess Point WiFi 802.11b/gSemplice applicazione dimostrativa che consente di accende e spegnere i LED utilizzando riconfigurazione interna, dinamica e parziale attraverso l’approccio smallbit

18

RisultatiRisultati

Requisiti di area

Risorsa Utilizzata Disponibile %

Slice 4926 4928 99

Flip-Flop 5217 9856 52

4-input LUT 6974 9856 70

19

ConclusioniConclusioni

In seguito a questa analisi disponiamo di un buon punto di partenza che ci permette di capire se tenere in considerazione un sistema basato su FPGA piuttosto che su ASIC, sistema che ci permette di risolvere una parte dei problemi individuatiL’architettura di rete proposta è completamente indipendente dalla soluzione hardware adottata e permette di risolvere i problemi individuati che non possono essere risolti direttamente dalle FPGAL’architettura generale proposta permette di esplodere la complessità di un sistema mantenendo limitata la complessità delle componenti basi che risultano più semplici

20

Sviluppi FuturiSviluppi Futuri

L’architettura proposta è stata provata su reti Ethernet e WiFi. Uno dei possibili sviluppi futuri potrebbe consistere nel portare il progetto su reti Bluetooth o IrDA andando ad implementando le interfacce già proposte

Le comunicazioni interne si basano sullo stack TCP/IP. Questa soluzione introduce un certo overhead che può essere sensibilmente ridotto utilizzando il sistema di messaggistica che tutti i sistemi operativi mettono a disposizione

DomandeDomande

21