UNA METODOLOGIA PER LA STIMA DELLE RISORSE HARDWARE IN ARCHITETTURE RICONFIGURABILI

1. UNA METODOLOGIA PER LA STIMADELLE RISORSE HARDWAREIN ARCHITETTURE RICONFIGURABILI Relatore: Prof. Fabrizio FERRANDI Correlatore: Ing. Marco Domenico SANTAMBROGIO Tesina di Laurea di Marco MAGNONE Matr. 640006

2. Sommario • Introduzione • Sistemi dedicati • Obiettivi • Framework • PandA • Flusso di sviluppo • Estrazione delle metriche • PDG • Vettore di caratterizzazione • Implementazione • Parametrizzazione delle metriche • Struttura di CLB e slice • Test e risultati • Esempi • Risultati • Conclusioni e sviluppi futuri

3. Introduzione • Introduzione • Sistemi dedicati • Obiettivi • Framework • PandA • Flusso di sviluppo • Estrazione delle metriche • PDG • Vettore di caratterizzazione • Implementazione delle metriche • Parametrizzazione delle metriche • Struttura di CLB e slice • Test e risultati • Esempi • Risultati • Conclusioni e sviluppi futuri

4. Sistemi dedicati Stato: .:: Introduzione > Sistemi dedicati > Obiettivi .:: Framework > PandA > Flusso di sviluppo .:: Estrazione delle metriche > PDG. > Vettore di caratterizzaz. > Implementaz. >Parametr. > CLB e slice .:: Test e risultati > Esempi > Risultati > Conclusioni e sviluppi futuri • Creazione del modello • Generazione della descrizione Descrizione a livello di sistema Analisi Valutazione del progetto ed esplorazione dello spazio delle soluzioni sulla base di prestazioni, dimensioni, consumo e costo Verifica Partizionamento HW/SW Minimizzazione di una cifra di merito rispettando i vincoli di progetto. E’ necessario disporre di strumenti di stima della qualità del sistema per la parte hardware e quella software Descrizione HW Descrizione SW Sintesi HW Generazione SW Sintesi Interfacce Tecniche per la sincronizzazione tra hardware e software (scambi di segnale, schemi in interrupt..) Integrazione + Valutazione vincoli Verifica del comportamento del sistema da un punto di vista funzionale e di timing sia per validare la specifica iniziale sia il partizionamento introdotto Simulazione + Validazione Sistema Integrato

5. Obiettivi Ricerca di metriche che permettano una stima affidabile dell’area occupata e del tempo di esecuzione dei singoli componenti in un’architettura riconfigurabile utilizzando descrizioni semi formali quali PDG e SDG Stato: .:: Introduzione > Sistemi dedicati > Obiettivi .:: Framework > PandA > Flusso di sviluppo .:: Estrazione delle metriche > PDG > Vettore di caratterizzaz. > Implementaz. >Parametr. > CLB e slice .:: Test e risultati > Esempi > Risultati > Conclusioni e sviluppi futuri Analisi di varie strutture dati (PDG e FGPDG) e validazione dei risultati tramite flusso automatico con l’utilizzo di EDK • SVANTAGGI DELLE METRICHE PRESENTI IN LETTERATURA • Limitazione a funzioni combinatorie ad un solo ingresso (Nemani e Najm) • Orientamento ad un solo dispositivo obiettivo, quindi in caso di differente architettura è necessario rifare tutto (Kulkarni, Najjar, Rinkel) • Errori medi di stima alti (intorno al 20-25%) • Sostanziale dipendenza tra implementazione delle metriche e dispositivo obiettivo scelto

6. Framework • Introduzione • Sistemi dedicati • Obiettivi • Framework • PandA • Flusso di sviluppo • Estrazione delle metriche • PDG • Vettore di caratterizzazione • Implementazione delle metriche • Parametrizzazione delle metriche • Struttura di CLB e slice • Test e risultati • Esempi • Risultati • Conclusioni e sviluppi futuri

7. PandA Stato: .:: Introduzione > Sistemi dedicati > Obiettivi .:: Framework > PandA > Flusso di sviluppo .:: Estrazione delle metriche > PDG > Vettore di caratterizzaz. > Implementaz. > Parametr. > CLB e slice .:: Test e risultati > Esempi > Risultati > Conclusioni e sviluppi futuri • Progetto nato all’interno del DEI del Politecnico di Milano che mira a sviluppare un framework per la progettazione di sistemi dedicati • Struttura del progetto modulare, composta da sottoprogetti che interagiscono tra di loro, raggruppati in varie categorie: • Livello di gestione di descrizioni comportamentali • Livello di gestione di grafi e descrizioni strutturali • Livello di sintesi ad alto livello • La struttura interna si chiama IR: tree ed è un grafo i cui nodi sono istanze di classi C++ appartenenti ad un’unica gerarchia, mentre gli archi sono implicitamente definiti come riferimenti tra coppie di nodi. E’ composto da due sotto-moduli: IR: graph e IR: circuit Le metriche introdotte verranno implementate all’interno di PandA considerando il sotto-modulo IR: graph

8. Flusso di sviluppo Stato: .:: Introduzione > Sistemi dedicati > Obiettivi .:: Framework > PandA > Flusso di sviluppo .:: Estrazione delle metriche > PDG > Vettore di caratterizzaz. > Implementaz. > Parametr. > CLB e slice .:: Test e risultati > Esempi > Risultati > Conclusioni e sviluppi futuri Descrizione ad alto livello PandA GCC Parser IR: graph Metriche IR: tree Partizionamento HW/SW IR: circuit EDK System Creator bitstream IP CoreGen VHDL C Tool che collega automaticamente il generico IP-Core e un dato sistema con architettura EDK-compatibile Tool che crea automaticamente un core compatibile con EDK partendo da una generica funzionalità VHDL

9. Estrazione delle metriche • Introduzione • Sistemi dedicati • Obiettivi • Framework • PandA • Flusso di sviluppo • Estrazione delle metriche • PDG • Vettore di caratterizzazione • Implementazione delle metriche • Parametrizzazione delle metriche • Struttura di CLB e slice • Test e risultati • Esempi • Risultati • Conclusioni e sviluppi futuri

10. PDG Stato: .:: Introduzione > Sistemi dedicati > Obiettivi .:: Framework > PandA > Flusso di sviluppo .:: Estrazione delle metriche > PDG > Vettore di caratterizzaz. > Implementaz. > Parametr. > CLB e slice .:: Test e risultati > Esempi > Risultati > Conclusioni e sviluppi futuri ENTRY Sa Sb Sc S:for(a=ref; a<b; a++){ S1:..........;} P:..........; P Sa a,li,- Archi di dipendenza di controllo X,Y,Z Archi di dipendenza dal flusso di dati a,li,o Sb XVariabile interessata alla dipendenza T a,lc,a li loop indipendent lc loop carried a,lc,- R1 Y a,lc,o do def-order dependency o output dependency a anti-dependency - nessuna delle tre precedenti Z Sc S1 R1Nodo regione

11. Vettore di caratterizzazione Il processo di stima esplora progressivamente l’intero grafo per arrivare a determinare le caratteristiche dell’intera applicazione. Stato: .:: Introduzione > Sistemi dedicati > Obiettivi .:: Framework > PandA > Flusso di sviluppo .:: Estrazione delle metriche > PDG > Vettore di caratterizzaz. > Implementaz. > Parametr. > CLB e slice .:: Test e risultati > Esempi > Risultati > Conclusioni e sviluppi futuri Si considera il PDG di ogni task presente nell’applicazione e si compila una lista di tutti i tipi di operazioni presenti, determinando un vettore di caratterizzazione del tipo: Unità funzionaleCoefficiente C1-C4 C5-C6 C7-C14 C15-C17 C28-C33 C34-C38 Sommatori – Sottrattori - Contatori Array Multiplier Comparatori Moltiplicatori - Moltiplicatori per costante Operazioni Logiche MUX - Shifter

12. Implementazione delle metriche Stato: .:: Introduzione > Sistemi dedicati > Obiettivi .:: Framework > PandA > Flusso di sviluppo .:: Estrazione delle metriche > PDG > Vettore di caratterizzaz. > Implementaz. >Parametr. > CLB e slice .:: Test e risultati > Esempi > Risultati > Conclusioni e sviluppi futuri Una volta che il PDG è stimato, si considerano le dipendenze di controllo, quali loop o branch, e si costruiscono dei macro-nodi fondendo insieme due o piu’ nodi, e si ripete il procedimento per i nuovi nodi. ENTRY ENTRY ENTRY S S3 S3 S3 S S T T T F F F S1 S2 S1 S2 S1 S2 Allo stesso modo si valutano gli SDG, cioè considerando i singoli PDG come macro-nodi e valutando le dipendenze che intercorrono tra essi (esecuzione parallela, sequenziale..)

13. Parametrizzazione delle metriche • L’area e il ritardo di propagazione di ogni unità funzionale sono stati ottenuti • attraverso una serie di passi: • Generazione del learning-set • Sintesi del learning-set • Analisi del rapporto di sintesi • Estrazione della metrica dall’analisi del rapporto di sintesi • Validazione della metrica Stato: .:: Introduzione > Sistemi dedicati > Obiettivi .:: Framework > PandA > Flusso di sviluppo .:: Estrazione delle metriche > PDG > Vettore di caratterizzaz. > Implementaz.> Parametr. > CLB e slice .:: Test e risultati > Esempi > Risultati > Conclusioni e sviluppi futuri Per rendere le metriche adattabili ad un certo numero di dispositivi, si sono introdotti dei parametri, S e L, indicanti rispettivamente il numero di slice e di LUT all’interno di una singola CLB. Quindi prima di applicare le metriche è necessario ottenere il valore di tali costanti, in base all’architettura di volta in volta presa in considerazione. Xilinx FPGASL Virtex II Pro – Virtex II – Virtex IV 4 8 Virtex V 2 8 Virtex 2 4 Spartan 3/3L – Spartan 3E 4 8

14. Struttura di CLB e slice L’architettura obiettivo di questo lavoro è la Virtex II Pro di Xilinx, che ha all’interno di ogni CLB 4 slice (S=4) e 4x2=8 LUT (L=8) Stato: .:: Introduzione > Sistemi dedicati > Obiettivi .:: Framework > PandA > Flusso di sviluppo .:: Estrazione delle metriche > PDG > Vettore di caratterizzaz. > Implementaz. > Parametr. > CLB e slice .:: Test e risultati > Esempi > Risultati > Conclusioni e sviluppi futuri COUT Slice X1Y1 Slice X1Y1 LUT G FF/ latch Slice X1Y0 Slice X1Y0 CY COUT Switch Matrix CIN CIN SHIFT Slice X0Y1 LUT F FF/ latch CY Slice X0Y0 CIN • Ogni slice è composta da: • 2 generatori di funzioni logiche (LUT a 4 ingressi) • 2 elementi di memorizzazione funzionanti in modalità sincrona (FF) o asincrona (latch) • Ogni CLB è composta da: • 4 slice • 2 buffer 3-state

15. Test e risultati • Introduzione • Sistemi dedicati • Obiettivi • Framework • PandA • Flusso di sviluppo • Estrazione delle metriche • PDG • Vettore di caratterizzazione • Implementazione delle metriche • Parametrizzazione delle metriche • Struttura di CLB e slice • Test e risultati • Esempi • Risultati • Conclusioni e sviluppi futuri

16. Esempi (1): unità funzionali • Alcuni esempi di metriche ottenute per la SINGOLA unità funzionale, per le famiglie Virtex II e Spartan, per le quali il potere espressivo di una CLB equivale ad un byte: • Sommatori – Sottrattori • CLB=N Slice=S*N LUT=L*N N dimensione in byte degli addendi • Moltiplicatori Stato: .:: Introduzione > Sistemi dedicati > Obiettivi .:: Framework > PandA > Flusso di sviluppo .:: Estrazione delle metriche > PDG > Vettore di caratterizzaz. > Implementaz. > Parametr. > CLB e slice .:: Test e risultati > Esempi > Risultati > Conclusioni e sviluppi futuri N2/2 [(N1=1), V N2] N1*N2 [(1<N1<16), V N2] V [N1>16, N2>50] CLB= 2 (N1+N2) [(N1>16), (1<N2<50)] 4 N1, N2 dimensione in byte delle due variabili da moltiplicare Quindi per l’intero PDG si avranno le seguenti metriche per i sommatori e moltiplicatori: ASomm[CLB] = C1*C2 C1 num. Sommatori, C2 dim.media addendi AMol1[CLB] = C15*C16*0.5 C15 num. Molt. con N1=1, C16 dim.media N2 AMol2[CLB] = C17*C18*C19 AMol3[CLB] = C20*(C21+C22)*0.25 AMol4[CLB] = C23*C24*C25

17. Esempi (2): unità funzionali Quindi l’area espressa in CLB dell’intero PDG è pari a: A[CLB] = ASomm + ACont + AArrMul + AComp1 + AComp2 + AComp3 + AComp4 + AMol1 + AMol2+ + AMol3 + AMol4 + AMolK + AOpLog1 + AOpLog2 + AOpLog3 + AMux Stato: .:: Introduzione > Sistemi dedicati > Obiettivi .:: Framework > PandA > Flusso di sviluppo .:: Estrazione delle metriche > PDG > Vettore di caratterizzaz. > Implementaz. > Parametr. > CLB e slice .:: Test e risultati > Esempi > Risultati > Conclusioni e sviluppi futuri Per quanto riguarda il timing, si è proceduto nello stesso modo e si è ottenuto ad esempio per gli addizionatori: TAdd[s] = NumAdd * [(LungMediaAddendo*dr)+dc] dr e dc sono rispettivamente il ripple line delay e il combinatorial delay e sono ricavabili dal data sheet della scheda Quindi il ritardo di propagazione è dato dalla somma dei singoli contributi, pesati da un fattore empirico 1.5 necessario per tenere in considerazione l’influenza del routing e dal fattore (1/LP) necessario per pesare la somma dei singoli contributi in relazione alla struttura del task. T[s] = (1.5/LP) (TAdd + TMol + TMux + TLog) Una volta che il PDG è stimato, costituisce un nodo, quindi si considerano le dipendenze di controllo, si formano i macro-nodi e si combinano le stime di area e tempo. Ad esempio nel caso di nodi eseguiti in PARALLELO con area (A1,A2) e timing (T1,T2), il macro nodo risultante ha: A = A1 + A2T = MAX (T1,T2)

18. Risultati (1): unità funzionali Stato: .:: Introduzione > Sistemi dedicati > Obiettivi .:: Framework > PandA > Flusso di sviluppo .:: Estrazione delle metriche > PDG > Vettore di caratterizzaz. > Implementaz. > Parametr. > CLB e slice .:: Test e risultati > Esempi > Risultati > Conclusioni e sviluppi futuri Errore medio stima FF sempre nullo tranne Molt. e MUX Errore medio % Errore medio stima tempo di esecuzione al di sotto del 5% (problema wiring) Errore medio stima CLB intorno al 2% Stima CLB Stima FF Stima tempo

19. Risultati (2): il filtro FIR Il sorgente C del filtro è costituito dalla funzione clear, che pone zeri nella delay line e dalla funzione fir-basic, che immagazzina i campioni di ingresso e calcola i campioni di uscita. Stato: .:: Introduzione > Sistemi dedicati > Obiettivi .:: Framework > PandA > Flusso di sviluppo .:: Estrazione delle metriche > PDG > Vettore di caratterizzaz. > Implementaz. > Parametr. > CLB e slice .:: Test e risultati > Esempi > Risultati > Conclusioni e sviluppi futuri Errore medio stima CLB tra il 12% e il 18% Area [CLB] 100 95 90 85 80 75 Stima Implementazione Errore medio stima temporale 7% Frequenza [Mhz] Stima Implementazione

20. Conclusioni e sviluppi futuri Stato: .:: Introduzione > Sistemi dedicati > Obiettivi .:: Framework > PandA > Flusso di sviluppo .:: Estrazione delle metriche > PDG > Vettore di caratterizzaz. > Implementaz. > Parametr. > CLB e slice .:: Test e risultati > Esempi > Risultati > Conclusioni e sviluppi futuri • Errori medi di stima per le singole unità funzionali soddisfacenti, intorno al 2% per le CLB e al 5% per il tempo di esecuzione • Facilità nell’adattare le metriche ad architetture differenti • Errori medi di stima per benchmark complessi tra il 12% e il 18% • Problemi riscontrati con il wiring delay In futuro.. • Maggiore utilizzo dei PDG a granularità fine • Integrazione automatica nel flusso di sviluppo delle stime ottenute • Maggiore indipendenza dai coefficienti di delay nelle stime del tempo di esecuzione