matite e gomma

Logo di Conformità WCAG-1 di Livello Tripla A, W3C-WAI Web Content Accessibility Guidelines 1.0

Validazione XHTML 1.0 Validazione CSS 3
Logo del Dipartimento di Matematica e Informatica, Insegnamento di Sistemi dedicati, link al Forum

Sviluppo di SoC su FPGA con profiling dell'applicazione

Esercitazione 10 di Sistemi dedicati

Docente: Giuseppe Scollo

Università di Catania
Dipartimento di Matematica e Informatica
Corso di Laurea Magistrale in Informatica, AA 2019-20

Indice

  1. Sviluppo di SoC su FPGA con profiling dell'applicazione
  2. argomenti dell'esercitazione
  3. integrazione di sistema nello sviluppo di SoC
  4. strumenti per il profiling di un'applicazione software
  5. costruzione di un sistema Nios II con performance counter
  6. un esempio semplice e ben noto
  7. uso del performance counter nell'applicazione software
  8. generazione del BSP e integrazione HW/SW
  9. debugging ed esecuzione
  10. esperienza di laboratorio
  11. riferimenti

argomenti dell'esercitazione

in questa esercitazione si trattano:

integrazione di sistema nello sviluppo di SoC

lo sviluppo di un SoC con applicazioni è una tipica attività di codesign HW/SW

lo strumento di Quartus usato in questa esercitazione per l'integrazione di componenti hardware nello sviluppo di SoC è Qsys

un esempio un po' più complesso è oggetto di questa esercitazione:

strumenti per il profiling di un'applicazione software

profiling di un programma: misura del tempo speso in diverse parti del programma, per identificarne quelle critiche per la velocità di esecuzione

tre strumenti considerati nel documento (datato) Profiling Nios II Systems :

  • GNU gprof : misura software, alto sovraccarico di risorse software, alta distorsione della misura
  • Interval Timer : misura hardware, minimo sovraccarico di risorse, distorsione limitata
  • Performance Counter Unit : misura hardware, significativo sovraccarico di risorse hardware, distorsione minima, limite (7) sul numero di sezioni misurabili

in questa esercitazione usiamo il terzo metodo, che dà la precisione migliore, l'uso più semplice nel programma, e poiché il detto limite non è un problema per l'applicazione in gioco

costruzione di un sistema Nios II con performance counter

la figura mostra lo schema Qsys del sistema Nios II con Performance Counter Unit

Schema Qsys di sistema Nios II con Performance Counter Unit

un esempio semplice e ben noto

la funzione C in figura è una realizzazione software del calcolo del delay di una traiettoria di Collatz di dato inizio

direttive CPP e funzione C per il calcolo del delay di una traiettoria di Collatz

uso del performance counter nell'applicazione software

a differenza delle precedenti esperienze di laboratorio relative a realizzazioni hardware della funzione considerata, qui l'input di utente determina la lunghezza della sequenza di traiettorie da generare nel programma principale, ovvero il numero di invocazioni della funzione

programma principale dell'applicazione per il profiling del calcolo del delay di traiettorie di Collatz

generazione del BSP e integrazione HW/SW

le direttive di preprocessing mostrate prima abilitano l'uso dell'API del performance counter e di altri simboli (SWITCHES_BASE in questo caso) definiti nell'interfaccia software del sistema costruito con Qsys

l'interfaccia è fornita dal BSP, la cui costruzione è qui automatizzata dal Monitor Program, in seguito alla scelta del tipo di programma Program with Device Driver Support

scelta del tipo di programma dell'applicazione nel Monitor Program

ulteriori aspetti del BSP (e.g. opzioni di compilazione, di linking ecc.) possono essere specificati fornendo uno script Tcl custom

  • in particolare, mentre il livello di ottimizzazione di default stabilito dal Monitor Program è -O1, un livello diverso, e.g. -O3, può aversi creando uno script (con estensione .tcl) di una sola riga:
    set_setting hal.make.bsp_cflags_optimization -O3
    e indicandone il percorso nella input box BSP settings Tcl script (optional) delle impostazioni Program Settings

debugging ed esecuzione

il debugging nel Monitor Program può essere condotto anche al livello del sorgente C (visualizzazione dei valori delle variabili)

rimane comunque accessibile il disassembly del programma, in cui porre breakpoint ed esaminare lo stato dell'esecuzione in punti critici per la verifica della sua correttezza

...

dopo la rimozione di tutti i breakpoint, reset del sistema e rilancio dell'esecuzione, il modulo di profiling genera il performance report mostrato in figura

Performance Report prodotto dal profiling con esecuzione senza breakpoint

esperienza di laboratorio

si propone di progettare e realizzare un sistema HW/SW con struttura e caratteristiche simili a quelle dell'esempio mostrato in questa esercitazione, adoperando gli stessi strumenti di sviluppo e profiling, ma per un'applicazione diversa; precisamente, il lavoro consiste di:

riferimenti

letture raccomandate:

letture per ulteriori approfondimenti:

materiali utili per l'esperienza di laboratorio proposta: