Referenti: Prof. Anna Antola Ing. Marco Domenico Santambrogio

Presentazione sul tema: "Referenti: Prof. Anna Antola Ing. Marco Domenico Santambrogio"— Transcript della presentazione:

1 SINTESI DI IMMAGINI FRATTALI ATTRAVERSO CALCOLI IN MULTITHREAD SU DIOPSIS 740
Referenti: Prof. Anna Antola Ing. Marco Domenico Santambrogio Candidato: Falcetti Massimo matr A.A. 2005/2006

2 Obiettivi Partecipazione al DIOPSIS 740 – DSP Contest 2005
Studio dell’architettura del D740 Scelta di un’applicazione che sfrutti l’architettura e ne esalti le qualità di multithreading (processori disaccoppiati) Applicazione di test per il profiling (Scelta partizionamento) – In C standard Ideazione algoritmo per l’architettura del D740 Scambio di valori float tra le due CPU (non previsto dall’architettura) Metodo di sincronizzazione tra i due processori (coda ciclica) Analisi dei risultati ottenuti Questo lavoro di tesi è stato sviluppato in occasione del Design DSP Contest 2005 indetto da Atmel. Questo concorso, aperto a tutte le università del mondo, prevedeva la realizzazione di un’applicazione capace di sfruttare al massimo le caratteristiche di un nuovo componente integrato, appunto il DIOPSIS 740. Questa particolare architettura prevede la coesistenza nello stesso chip di due processori, una CPU ARM serie 7 e un potente DSP progettato per lavorare nativamente con i numeri in floating point a 40 bit e i numeri complessi. Il lavoro di tesi si è quindi sviluppato attorno a questa architettura, dapprima studiandone a fondo le caratteristiche e il funzionamento. Successivamente il problema che si è dovuto affrontare è stato quello di trovare un’applicazione che sfruttasse l’enorme potenza di calcolo del DSP integrato e potesse allo stesso tempo far operare parallelamente i due processori. Lo scopo di questa tesi è quindi stato quello di dimostrare la possibilità di avere un effettivo multithreading su questo tipo di architettura. I passi che si sono seguiti nel processo di progettazione e sviluppo sono stati la creazione di un programma in ansi c che riproducesse l’algoritmo della generazione del frattale di mandelbrot per poi analizzarne, attraverso un’attenta fase di profiling, il peso in termini di tempo d’esecuzione delle istruzioni. Questa analisi ha messo in evidenza come la causa della generazione dei frattali si sposasse bene con l’architettura a disposizione per mettere in evidenza le potenzialità multithread del D740. Durante la fase di sviluppo si sono inoltre incontrati dei problemi d’implementazione che facevano riferimento alla gestione della memoria condivisa tra le due CPU (metodo di sincronizzazione) e il passaggio di variabili in virgola mobile nella memoria condivisa tra le due CPU. L’implementazione completa dell’algoritmo sulla scheda di test JTST ha prodotto dei risultati che hanno dimostrato l’effettiva bontà dell’applicazione sviluppata rispetto agli obiettivi posti all’inizio. - Falcetti Massimo –

3 Diopsis 740 Overview Dual inter operating processors for silicon systems
Struttura biprocessore dotata di una normale CPU RISC a 32 bit (ARM), accoppiata ad un DSP - VLIW (mAgic) ottimizzato per lavorare in campo complesso e con numeri floating point a 40 bit. Architettura di DIOPSIS740: Essenzialmente D740 consiste in un componente integrato che contiene al suo interno due CPU: Un microcontrollore ARM serie 7 (quindi una cpu RISC standard a 32 bit) e un DSP floating point a 40bit denominato mAgic. Lo schema in figura rappresenta come sono interconnessi tra loro i componenti all’interno del chip, e mette in evidenza come le due cpu si interfacciano al mondo esterno. Si nota subito come mAgic non abbia diretto accesso alle periferiche di I/O, ma che si deve sempre e comunque appoggiare alla gestione di quest’ultime da parte del processore ARM. Tra ARM e mAgic esiste una memoria condivisa che permette alle due CPU di parlarsi. Il metodo di sincronizzazione ideato per far operare in parallelo i due processori è il cuore di questo lavoro di tesi, sarà dunque spiegato meglio in seguito. - Falcetti Massimo –

4 mAgic Funzionamento: RUN MODE – SYSTEM MODE
Arm System 32K ARM Memory mAgic DSP core Shared Amba ASB Data Memory (6k+6k) x 40 bit Double Bank Double Port mAAr 8Kx128 bit Program In questa slide si può vedere la memoria che vede la CPU mAgic durante il funzionamento. mAgic è un DSP floating point a 40 VLIW. Le VLIW sono istruzioni macchina a 128bit che permettono una forte ottimizzazione del codice da eseguire. La semplicità di programmazione di questo componente però è assicurata da un’estensione del linguaggio C messo a disposizione da Atmel che con opportune modifiche permette utilizzare mAgic quasi come se fosse un normale processore. mAgic può lavorare in due stati “RUN MODE” e “SYSTEM MODE”. Nel primo caso la prima figura rappresenta effettivamente come il DSP vede la memoria, due blocchi (per rappresentare i valori vettoriali a 2 dimensioni (come i numeri complessi)) composti da più banchi. P0, P1 e P2 sono le parole in cui mAgic allora le proprie variabili locali e lo stack, P3 è un buffer per eventuali memorie esterne e P4 (PARM) è la memoria che condivide con ARM. La seconda figura invece rappresenta lo stato di mAgic in System Mode, quando cioè non è operativo. In questo caso è ARM (che ha il ruolo di periferica master) che deve predisporre l’ambiente per il funzionamento di mAgic RUN MODE – effettivo funzionamento di mAgic (accesso da parte di mAgic della sola memoria PARM) SYSTEM MODE – mAgic in attesa - Falcetti Massimo –

5 Scambio di float tra ARM e mAgic
Lettura da ARM di un float di mAgic  NON PREVISTO DALL’ARCHITETTURA  Recupero puntatore a cella base Cast al tipo di dato opportuno Conversione puntatore a long long* (x avere il mappaggio come sopra) Unione delle due parti e shift a destra di 8 posizioni Per utilizzare il dispositivo è necessario che i due processori si parlino. Ecco che entra quindi in gioco la memoria condivisa PARM. In questa zona di memoria possono leggere e scrivere entrambi i processori. In figura è rappresentato come vengono mappate le celle a 40bit di mAgic su quelle a 32 di ARM. E’ facile intuire come sia un’operazione “semplice” per D740 far scrivere un intero a mAgic e andare a leggerlo con ARM o vicecersa.. Il procedimento consiste semplicemente in un troncamento degli 8 bit più a sinistra (non utilizzati nemmeno da mAgic, poiché rappresenta anch’esso gli interi con 32bit). Molto più interessante è il passaggio tra i processori di valori float per il quale non esiste una procedura nativa. Si è dovuto quindi implementare una funzionalità simile studiando le diverse rappresentazioni dei valori in virgola mobile. La procedura ottenuta è mostrata nel grafico visualizzato e consiste, dopo aver recuperato le due word (64bit) che contengono il dato a 40 bit, in uno shift verso sinistra della parola, perdendo quindi gli 8 bit LSB della parola a 40 bit. In fase di progetto questa cosa non si è subito resa nota poiché mancava la documentazione dove era spiegato che ARM riproducesse i float in normale notazione a 32bit. Aggiunta dell’offset della cella a cui accedere Recupero del valore delle due word - Falcetti Massimo –

6 L’Applicazione – schema ideale
JTST Board System User ARM Fractal request Bitmap mAgic USB Richiesta immagine frattale da PC a JTST (via USB) Presa in carico della richiesta da parte della scheda JTST (ARM gestisce le connessioni) Calcolo frattale secondo i parametri richiesti (mAgic + ARM) Invio dei dati elaborati (immagine bitmap) al chiamante (via USB) NB – note reale implementazione In figura si può avere una visione d’insieme del sistema. Un computer Genera Purpose (chiamato System User) provvederà a richiedere al sistema (D740 - JTST) attraverso il canale USB un’immagine frattale, descritta da vari parametri. Diopsis 740, provvederà a elaborare la richiesta e a fornire sempre sul canale USB i risultati della computazione. E’ da subito chiaro come ARM sarà incaricato di gestire gli I/O del dispositivo. A mAgic invece sarà delegato il compito di eseguire la pesante computazione matematica del calcolo del frattale. Il multithread entra in gioco in questa fase poiché l’applicazione sarà sviluppata in modo che mentre mAgic esegui i calcolo per calcolare i vari punti del frattale, ARM prenderò i risultati delle computazioni precedenti e li rispedirà indietro al System User. - Falcetti Massimo –

7 Scheda di sviluppo JTST su cui è implementata l’applicazione
CLK DIV 3.3V LED IRQ BUTTON PIO CONN SRAM ARM DATA L 128Kx8 ARM DATA H FLASH ARM PRG 1Mx16 SSRAM MAGIC DATA L 128Kx36 EXTCLK CONN DIP SWITCH SPI-0 CONN M-ICE JTAG CONN Diopsis 740 PIO USARTs RST XMA XMD[15:0] CLKs CNTRLs SPIs ADDA ARMD PLL ICE ARMC ARMA XMD[55:40] XMD[31:16] XMD[71:56] XMD[39:32] XMD[79:72] DATA H DATA E USB CNTRL EXT PSU CONN CODEC 25 MHz OSC RS 232 BUFF USART 0 CONN 1 CONN 7-SEG DISPLAY GND RESISTOR NETWORK 6 MHz D-9 RS232 VREG 5-1.8 SPI-1 CONN VREG 5-3.3 POW-ON RST AUDIO OUT IN JP8 JP9 JP5 JP4 JP11 JP7 JP2 JP3 JP6 JP10 JP1 TP5 TP2 TP1 TP4 TP3 TP7 TP8 TP6 TP9 TP10 TP11 Porta seriale Periferiche utilizzate per l’implementazione di questa applicazione Presenza di altri componenti per adattare la scheda a qualsiasi utilizzo USB Chip Diopsis 740 In figura è rappresentata la scheda di test JTST. Questa board è progettata per offrire agli sviluppatori il massimo interfacciamento col mondo esterno in quanto sono disponibili svariate periferiche di I/O. E’ da subito chiaro però come la scheda sia incentrata all’elaborazione dei segnali audio, essendo presenti 4 connettori di input e 4 di output per i segnali audio, nonché 4 decodificatori A/D – D/A. In ogni caso l’applicazione ha comunque cercato di sfruttare al meglio le caratteristiche offerte dalla scheda, utilizzando, oltre alla seriale necessaria per il deploy e il debug dell’applicazione, la porta USB 2.0 a disposizione. Questa interfaccia infatti essendo molto più veloce delle porte seriali standard permette di non preoccuparsi di eventuali colli di bottiglia dal lato della scheda. - Falcetti Massimo –

8 Sincronizzazione – Coda Ciclica
punt ARM = punt mAgic ARM  Run, mAgic  Wait (mAgic non ha ancora pronti i dati da processare perché ARM non ha ancora terminato l’inserimento dei valori in memoria) |Punt ARM| > |Punt mAgic| ARM  Run, mAgic  Run Questa è la condizione normale di operatività: ARM riempie le pagine vuote della memoria ciclica e mAgic esegue la computazione matematica, che essendo molto dispendiosa, lo fa rimanere sempre qualche cella di memoria indietro. |Punt ARM| <> |Punt mAgic| (DISCORDI) ARM è una pagina avanti a mAgic. Anche in questa situazione il funzionamento delle CPU è quello normale poiché entrambi i processori hanno qualcosa da fare. ARM  Run, mAgic  Run |Punt ARM| = |Punt mAgic| (DISCORDI) ARM ha raggiunto la cella di memoria che mAgic sta elaborando, è stato quindi così veloce da essere esattamente una pagina avanti rispetto al DSP. ARM  Wait, mAgic  Run Sincronizzazione tra i due processori – PARM come CODA CICLICA Per ovviare al problema della memoria finita a disposizione è stato pensato e poi implementato un metodo di sincronizzazione che prevede l’utilizzo della memoria PARM come coda ciclica. In pratica si tratta di scorrere le celle complesse di questa memoria con due puntatori, uno della CPU ARM, l’altro della CPU mAgic. Le condizioni di funzionamento sono visibili su questa slide - Falcetti Massimo –

9 Partizionamento 1 ARM mAgic D E F
Possibilità di due partizionamenti dell’algoritmo sulle due cpu a disposizione. Cambia la cpu che esegue il mappaggio dei punti del piano complesso. PRIMO METODO: Apertura canale di comunicazione (da parte dell’ARM) Generazione dell’header della bitmap (ARM) Generazione della palette per la bitmap (ARM) Mappaggio di ciascun pixel nel piano complesso (ARM) Calcolo effettivo del frattale (mAgic) Determinazione del colore per ogni pixel (ARM) Chiusura del canale di comunicazione (ARM) Im ARM mapping Color Write D F mAgic Definito il metodo di sincronizzazione si può passare a descrivere come l’algoritmo verrà partizionato tra i due processori per avere le massime prestazioni e un effettivo utilizzo del dispositivo in multithreading. In figura è rappresentato il primo metodo di partizionamento che consiste nel delegare ad ARM tutte le operazioni di I/O, il mappaggio dei punti del piano complesso in pixel e la determinazione del colore di ogni pixel. Questa operazione (definizione colore) consiste nel leggere il valore d’uscita dal cerchio di raggio 2 da parte del ciclo principale del calcolo frattale e associare a quel pixel un colore di una tonalità proporzionale al valore d’uscita. In questo modo si possono ottenere tutte le sfumature tipiche del frattale di Mandelbrot. Re Shared mem used as FIFO Fractal calc E Bitmap - Falcetti Massimo –

10 Partizionamento 2 mAgic ARM D E F SECONDO METODO: Im Re Fractal calc
Apertura canale di comunicazione (da parte dell’ARM) Generazione dell’header della bitmap (ARM) Generazione della palette per la bitmap (ARM) Mappaggio di ciascun pixel nel piano complesso (mAgic) Calcolo effettivo del frattale (mAgic) Determinazione del colore per ogni pixel (ARM) Chiusura del canale di comunicazione (ARM) Im mAgic D mapping ARM Re In questo secondo metodo di sincronizzazione, la gestione dell’I/O è sempre compito di ARM (non potrebbe essere altrimenti), cambia solo il fatto che la fase di mapping dei pixel diventa prerogativa di mAgic. Con questo tipo di partizionamento viene effettivamente sfruttata la possibilità da parte di mAgic di operare su numeri in virgola mobile a 40 bit. Nel caso precedente infatti mAgic effettuava calcoli complessi su valori floating point a 32 bit. Shared mem used as FIFO F Color Write Fractal calc E Bitmap - Falcetti Massimo –

11 Confronto prestazioni
Il primo metodo di partizionamento, quello cioè che lascia la fase di mapping dei pixel ad ARM, risulta leggermente più rapido se l’algoritmo prevede un alto numero di iterazioni per uscire dal cerchio di raggio 2, e quindi un’elevata precisione nella creazione dell’immagine bitmap. Il secondo metodo di partizionamento, invece, permette una miglior precisione nei calcoli. In questo caso infatti i valori float calcolati nella fase di mapping hanno una precisione calcolata su 40 bit (32 bit nel caso di mappaggio da parte di ARM). Implementati e testati entrambi i metodi è possibile analizzare come si differenziano i due tipi di partizionamento. Nel primo caso la computazione è più precisa in termini di definizione dell’immagine, ovvero è possibile avere un’immagine più dettagliata con buone prestazioni, nel secondo caso invece i valori calcolati saranno più precisi, ma non si potrà avere una troppo alta definizione dell’immagine o si perderà in prestazioni. Quale dei due metodi sia il migliore, dipende molto dalle esigenze che l’applicazione deve soddisfare. Per quanto riguarda l’obiettivo di questo lavoro di tesi, cioè dimostrare l’effettiva possibilità di avere i processori contemporaneamente funzionanti (multithread vero) il miglior metodo di partizionamento è il primo, che permette infatti di ottenere immagini ben definite in tempi molto ristretti rispetto a un normale processore general purpose. Scelta metodo in base alle esisgenze - Falcetti Massimo –

12 Stato Attuale e Lavori futuri
Visualizzazione bitmap a mezzo di printf e predisposizione del codice alla comunicazione USB Possibilità di eseguire l’algoritmo nei due metodi di sincronizzazione, ma anche esclusivamente su ARM LAVORI FUTURI: Implementazione completa della comunicazione USB con le nuove librerie funzionanti fornite da ATMEL Lo stato attuale dell’applicazione implementata è quello di visualizzare correttamente a mezzo di printf una bitmap che rappresenta il frattale di mandelbrot. In pratica è possibile visualizzare il valore numerico che dovrebbe essere memorizzato in ogni singolo byte che costituisce la bitmap. Non è possibile avere direttamente l’immagine bitmap poiché manca un driver per l’USB della JTST che funzioni correttamente. Quello fornito da ATMEL in un primo momento infatti presentava dei bachi poiché doveva funzionare con una versione di eCos non inclusa nel pacchetto di svluppo. Il codice sviluppato però è già pronto per supportare questa funzionalità, basta sostituire le printf della funzione che scrive i pixel con una write sul canale di comunicazione USB. Sarà poi il pc a occuparsi del riordino dei byte ricevuti per ottenere un’immagine bitmap visualizzabile. In particloare sarà sufficiente che il personal computer inverta i byte ricevuti dal canale USB per avere un file bitmap corretto. - Falcetti Massimo –

13 Fine presentazione - Falcetti Massimo –