• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
3rd 3DDRESD: BSS
 

3rd 3DDRESD: BSS

on

  • 642 views

 

Statistics

Views

Total Views
642
Views on SlideShare
641
Embed Views
1

Actions

Likes
0
Downloads
2
Comments
0

1 Embed 1

http://www.dresd.org 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    3rd 3DDRESD: BSS 3rd 3DDRESD: BSS Presentation Transcript

    • BSS Bitstream Sharing System Filippo Sironi: filippo.sironi@dresd.org D ynamic R econfigurability in E mbedded S ystems D esign 3dDRESD 2008 – Goglio (Baceno)
    • Motivazioni
      • 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à
    • Indice
      • Introduzione
        • Descrizione del Problema
        • Obiettivi del Progetto
      • Stato dell’Arte
      • Soluzione
        • Hardware
        • Software
      • Risultati
      • Conclusioni
      • Sviluppi Futuri
      • Domande
    • Descrizione 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
    • Descrizione 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à )
    • Obiettivi 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’Arte
      • Dispositivo riconfigurabile: FPGA
        • Flessibile
      • Sistema operativo: Linux
        • Flessibile
        • Modificabile
        • Libero
      • Riconfigurazione: IP-Core Manager (IPCM)
        • Parziale
        • Dinamica
      • Riconfigurazione on-demand: Reconfiguration Manager
        • Demone
        • Applicazione User Space
    • 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
    • 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à
    • 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à
    • Soluzione (4/9)
      • Livello hardware
        • FPGA
        • N etwork
      • Livello software
        • Linux (sistema operativo)
        • IPCM (riconfigurazione dinamica e parziale)
        • Reconfiguration Manager (riconfigurazione on-demand)
        • BSS (repository distribuito)
      • BSS
        • Functionalities Manager
        • Functionalities Database
        • Console
    • Soluzione (5/9)
      • Functionalities Manager
        • Gestisce le richieste
          • Locali
          • Remote
        • Coopera con il Functionalities Database
          • Recupero delle funzionalità
        • Condivide le funzionalità locali con i nodi che appartengono alla rete cooperativa
    • 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 HTTP
        • Le comunicazioni interne si basano sullo stack TCP/IP
        • Le comunicazioni esterne possono operare attraverso vari mezzi di comunicazione (Ethernet, WiFi, Bluetooth, IrDA, ecc …)
    • Soluzione (7/9)
      • Functionalities Database
        • Serve le richieste del Functionalities Manager
        • Esegue i comandi della Console
        • Mantiene la struttura dati che permette di immagazzinare le funzionalità e di effettuarne un filtraggio
    • Soluzione (8/9)
      • Console
        • Opera con il Functionalities Database attraverso il Functionalities Manager
        • Permette di aggiungere funzionalità al Functionalities Database
        • Permette di eliminare funzionalità dal Functionalities Database
        • Le comunicazioni tra Console e Functionalities Database rientrano nella categoria delle comunicazioni interne e si basano quindi sullo stack TCP/IP
    • Soluzione (9/9) Device 0 Network Cooperative Network Operating System & Reconfiguration Manager Functionalities Manager FunctionalitiesDatabase Console Device 1 Device 2 Device 3
    • Risultati
      • L’architettura proposta per il nodo elaborativo è stata riprodotta con successo facendo uso di:
        • Avnet Xilinx Virtex-II Pro Evaluation Kit
        • Ethernet EMAC Controller
        • µCLinux 2.4
        • IPCM
        • Access Point WiFi 802.11b/g
        • Semplice applicazione dimostrativa che consente di accende e spegnere i LED utilizzando riconfigurazione interna, dinamica e parziale attraverso l’approccio smallbit
    • Risultati
      • Requisiti di area
      Risorsa Utilizzata Disponibile % Slice 4926 4928 99 Flip-Flop 5217 9856 52 4-input LUT 6974 9856 70
    • Conclusioni
      • 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 individuati
      • L’architettura di rete proposta è completamente indipendente dalla soluzione hardware adottata e permette di risolvere i problemi individuati che non possono essere risolti direttamente dalle FPGA
      • L’architettura generale proposta permette di esplodere la complessità di un sistema mantenendo limitata la complessità delle componenti basi che risultano più semplici
    • Sviluppi 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
    • Domande