PROGETTO DI SISTEMI DI DSP Cosimo Stallo & Paolo Emiliozzi- Modulo di Elaborazione dei Segnali, a.a. 2009/2010

2 METODOLOGIA di PROGETTO SVILUPPO del PROGRAMMA CORREZIONE del PROGRAMMA SVILUPPO dello SCHEMA PROTOTIPO software APPLICAZIONE DEFINIZIONE dei REQUISITI di SISTEMA SELEZIONE del DISPOSITIVO DSP INTEGRAZIONE del SISTEMA TEST e CORREZIONE del SISTEMA hardware Cosimo Stallo & Paolo Emiliozzi- Modulo di Elaborazione dei Segnali, a.a. 2009/2010

3 APPLICAZIONE: da qui ci si muove per progettareAPPLICAZIONE: da qui ci si muove per progettare DEFINIZIONE REQUISITI: e’ una fase cruciale, da cui dipendono tempi, efficacia e complessita’ del progetto DEFINIZIONE REQUISITI: e’ una fase cruciale, da cui dipendono tempi, efficacia e complessita’ del progetto SELEZIONE DISPOSITIVO: una fase importante anche per i costi dell’oggetto da progettare SELEZIONE DISPOSITIVO: una fase importante anche per i costi dell’oggetto da progettare SVILUPPO PROGRAMMA/SCHEMA: e’ la fase realizzativa del S/W e dell’H/W SVILUPPO PROGRAMMA/SCHEMA: e’ la fase realizzativa del S/W e dell’H/W CORREZIONE/PROTOTIPO: e’ la fase di emendamento di possibili bachi progettuali a livello S/W o H/W CORREZIONE/PROTOTIPO: e’ la fase di emendamento di possibili bachi progettuali a livello S/W o H/W INTEGRAZIONE: il S/W e l’H/W vengono interfacciati a comporre l’oggetto con le funzioni richieste INTEGRAZIONE: il S/W e l’H/W vengono interfacciati a comporre l’oggetto con le funzioni richieste TEST e DEBUGGING: verifica ed eventuale correzioni sul sistema integrato TEST e DEBUGGING: verifica ed eventuale correzioni sul sistema integrato Cosimo Stallo & Paolo Emiliozzi- Modulo di Elaborazione dei Segnali, a.a. 2009/2010

4 Il processore che viene selezionato necessita di un insieme di strumenti di sviluppo, qui suddivisi in requisiti di base e opzionali. REQUISITI di BASE: Documentazione progettuale dettagliata. Strumenti per lo sviluppo del Programma (S/W) a livello ASSEMBLER oppure ad alto livello. Strumenti per la verifica funzionale del Progetto. Note applicative oppure altro tipo di assistenza per il progetto Cosimo Stallo & Paolo Emiliozzi- Modulo di Elaborazione dei Segnali, a.a. 2009/2010

5 REQUISITI OPZIONALI: Compilatori di linguaggi ad alto livello per Software modulare (p.e. C, FORTRAN) Librerie applicative Sistemi operativi in tempo reale Strumenti a basso costo per accettare l’appropiatezza del dispositivo. Possibilità di verificare l’intero sistema in tempo reale e di correggere l’hardware prototipazione a basso costo Basso “time-to-market” attraverso supporti avanzati Ambiente di sviluppo basato su workstation Cosimo Stallo & Paolo Emiliozzi- Modulo di Elaborazione dei Segnali, a.a. 2009/2010

6 OBIETTIVO: selezione di un dispositivo che consenta di: rispettare la tempisitica del progetto realizzare la soluzione più efficace dal punto di vista del costo R APPLICAZIONNI AD ALTO VOLUME: la scelta cade probabilmente sul dispositivo meno caro in grado di effettuare quanto richiesto. R PER APPLICAZIONI A MEDIO E BASSO VOLUME: la scelta è dettata da un compromesso tra costo dello strumento di sviluppo e efficacia/costo del dispositivo. R PER APPLICAZIONI A BASSISSIMO VOLUME: è spesso ragionevole scegliere un dispositivo facile da progettare oppure uno con i costi più bassi per gli strumenti di sviluppo. Cosimo Stallo & Paolo Emiliozzi- Modulo di Elaborazione dei Segnali, a.a. 2009/2010

7 IN AMBIENTE PC: la scelta migliore consiste, in genere, nell’acquisto di schede standard (disponibili da case costruttrici come ATLANTA SIGNAL PROCESSOR oppure LOUGHBOROUGH SOUND IMAGES) perchè tale approccio consente: –Riduzione del processo di sviluppo al solo progetto di software; –Possibili benefici dall’uso di sistemi operativi, compilatori C e librerie di routine standard fornite con la scheda stessa. Cosimo Stallo & Paolo Emiliozzi- Modulo di Elaborazione dei Segnali, a.a. 2009/2010

8 ATTENZIONE A... E’ possibile che la scelta del dispositivo per il progetto diventi un processo iterativo. Dunque, la prima scelta effettuata può rivelarsi non opportuna per vari motivi: –Problemi imprevisti con il programma –Scoperta di poter impiegare un dispositivo meno caro e meno potente. –Modifica delle specifiche di progetto, con conseguente necessità di rivisitazione della realizzazione prescelta I casi 1. e 2. possono essere evitati con una ricerca profonda e meditata dei dispositivi disponibili. Cosimo Stallo & Paolo Emiliozzi- Modulo di Elaborazione dei Segnali, a.a. 2009/2010

9 Nel progetto di qualsiasi applicazione di DSP, la progettazione software e hardware segue percorsi paralleli. Pertanto: – se come accade in progetti di dimensioni medie o grandi, il S/W e lo H/W non sono responsabilità dello stesso ingegnere, è importante uno scambio continuo ed efficace di informazione tra i due gruppi –quando l'intera fase di progettazione ha avuto inizio, tutti coloro che lavorano nel progetto devono possedere piena conoscenza del dispositivo DSP scelto, in particolare dei suoi: –punti di forza –punti deboli –caratteristiche specifiche Questo può ad esempio ottenersi seguendo corsi di addestramento sul dispositivo, organizzati da molte delle case costruttici (il costo di “training” è compensato dalla riduzione del “time-to-market”, che può essere discriminante sull’efficacia o meno del progetto). Cosimo Stallo & Paolo Emiliozzi- Modulo di Elaborazione dei Segnali, a.a. 2009/2010

10 COME SCRIVERE UN PROGRAMMA DSP Ci sono due metodi per scrivere un programma per dispositivi DSP: –impiego del linguaggio “assembler” –impiego del linguaggio ad alto livello Spesso la soluzione ideale è di lavorare con una miscela dei due metodi. Cosimo Stallo & Paolo Emiliozzi- Modulo di Elaborazione dei Segnali, a.a. 2009/2010

11 Un linguaggio quale il C è comprensibile per molti ingegneri. Questo rende il programma comprensibile assai di più che scrivendolo in un particolare linguaggio “ASSEMBLER” I linguaggi assemblativi tendono a essere di tipo mnemonico (sebbene stiano prendendo piede tipologie diverse) Con poche modifiche i linguaggi in C sono “trasportabili” tra DSP di diversa matrice. I linguaggi ad alto livello offrono un ambiente strutturato per lo sviluppo del software (diposnibilità di funzioni, strutture di dati, tipologie di variabili che portano ad muna soddisfacente intellegibilità e mantenibilità del software). Il linguaggio ad alto livello più utilizzato per applicazioni di DSP è il C (altri compilatori disponibili sono: ADA, FORTRAN) Perché è attraente l’impiego di linguaggi ad alto livello? Cosimo Stallo & Paolo Emiliozzi- Modulo di Elaborazione dei Segnali, a.a. 2009/2010

12 Perché è attraente l’impiego di linguaggi assemblativi? L’uso del compilatore C porta ad una penalizzazione in termini di velocità. Per progettare, infatti, un sistema di DSP il più efficace possibile dal punto di vista del costo è spesso necessario “spremere il dispositivo fino all’ultima goccia” dal punto di vista prestazionale. Questo richiede un software strettamente sagomato sul particolare dispositivo, e dunque, l’impiego di un linguaggio più vicino alla macchina. Cosimo Stallo & Paolo Emiliozzi- Modulo di Elaborazione dei Segnali, a.a. 2009/2010

13 I moderni compilatori C, benchè molto efficienti, non possono sostituire un assembler “sagomato”. (p.e. un algoritmo di codifica della voce basato su predizione lineare (LPC) può subire una penalizzazione di un fattore 1.5 se realizzato con compilatore C invece che in ASSEMBLER, pur adottando un compilatore C molto efficiente!) La penalizzazione in velocità può essere accettabile o meno, dipende dal particolare sistema. Tipicamente, non è accettabile quando le velocità di campionamento sono alte e/o tra campioni successivi sono necessari parecchi calcoli. LA SOLUZIONE? Una sapiente miscela di C e ASSEMBLER! Cosimo Stallo & Paolo Emiliozzi- Modulo di Elaborazione dei Segnali, a.a. 2009/2010

14 Tutti i compilatori C per DSP generano uno stadio intermedio in linguaggio assemblativo. Dunque tutte le routine critiche dal punto di vista temporale possono essere editate a questo punto, ad esempio. L’uso combinato di C e linguaggio assemblativo è diventato il modo più diffuso per scrivere il software di un sistema di DSP di larghe dimensioni. L’uso combinato di C e linguaggio assemblativo è diventato il modo più diffuso per scrivere il software di un sistema di DSP di larghe dimensioni. Nel tipico software per DSP, la percentuale necessaria di “sagomatura” può essere anche solo del 5 %. Tale percentuale corrisponde, però, alla parte del software dove il processore trascorre la maggior parte del tempo, cioè il cuore dell’algoritmo di DSP. Nel tipico software per DSP, la percentuale necessaria di “sagomatura” può essere anche solo del 5 %. Tale percentuale corrisponde, però, alla parte del software dove il processore trascorre la maggior parte del tempo, cioè il cuore dell’algoritmo di DSP. Cosimo Stallo & Paolo Emiliozzi- Modulo di Elaborazione dei Segnali, a.a. 2009/2010

15 –Esistono una gran quantità di compilatori C per dispositivi DSP, non tutti soddisfacenti –E’ comunque necessario l’uso di una assemblatore e linker nell'ambito dello sviluppo di software con linguaggio ad alto livello. Pur tenendo conto della semplicità nella stesura del software utilizzando un compilatore C, va comunque ricordato che: Pur tenendo conto della semplicità nella stesura del software utilizzando un compilatore C, va comunque ricordato che: Cosimo Stallo & Paolo Emiliozzi- Modulo di Elaborazione dei Segnali, a.a. 2009/2010

16 TEST DEL SOFTWARE SVILUPPATO Ci sono due metodologie di base per provare il software per DSP sviluppato: 1 - SIMULATORE Gira su PC o workstation e imita il comportamento del dispositivo DSP. L'interfaccia d’utente mostra tutti i registri interni I/O, etc, nonché l’effetto su di essi prodotto dall’esecuzione di ogni istruzione Svantaggio (ovvio!): non succede niente in tempo reale ; dunque il software non può essere provato come nell’applicazione finale. Le operazioni di I/O sono simulate usando file su disco che possono essere scomodi da inizializzare e richiedere parecchia interpretazione. Svantaggio (ovvio!): non succede niente in tempo reale ; dunque il software non può essere provato come nell’applicazione finale. Le operazioni di I/O sono simulate usando file su disco che possono essere scomodi da inizializzare e richiedere parecchia interpretazione. Cosimo Stallo & Paolo Emiliozzi- Modulo di Elaborazione dei Segnali, a.a. 2009/2010

17 2 -PIATTAFORMA Può essere sia un “modulo di valutazione” che un vero emulatore, dove: MODULO DI VALUTAZIONE = è una piattaforma hardware di tipo standard, che generalmente contiene un processore, memoria e I/O analogici, ma che ha possibilità limitate di espansione. E’ uno strumento appropriato per: EMULATORI= consentono una prova del software in tempo reale nel suo vero contesto di sistema, fornendo una elevata sicurezza sulla correttezza del comportamento. Sono generalmente utilizzati per provare il software sullo hardware prototipale (cioè nella fase di integrazione di sistema) EMULATORI= consentono una prova del software in tempo reale nel suo vero contesto di sistema, fornendo una elevata sicurezza sulla correttezza del comportamento. Sono generalmente utilizzati per provare il software sullo hardware prototipale (cioè nella fase di integrazione di sistema) prove in tempo reale del software prima che sia disponibile prove in tempo reale del software prima che sia disponibile qualunque prototipo hardware del sistema qualunque prototipo hardware del sistema casi di forti limitazioni del budget casi di forti limitazioni del budget Cosimo Stallo & Paolo Emiliozzi- Modulo di Elaborazione dei Segnali, a.a. 2009/2010

18 La scrittura e la prova di un software per DSP è un procedimento altamente iterativo: L’impiego di un simulatore o di una scheda di valutazione con un PC abbastanza potente consente di provare il software regolarmente man mano che viene scritto. L’impiego di un simulatore o di una scheda di valutazione con un PC abbastanza potente consente di provare il software regolarmente man mano che viene scritto. La scrittura del software in moduli o sezioni aiuta la valutazione regolare, dal momento che ciascun modulo può essere valutato separatamente, aumentando così la probabilità che l’intero sistema funzioni correttamente nella fase di integrazione La scrittura del software in moduli o sezioni aiuta la valutazione regolare, dal momento che ciascun modulo può essere valutato separatamente, aumentando così la probabilità che l’intero sistema funzioni correttamente nella fase di integrazione E’ allora opportuno controllare che il DSP da impiegare abbia un ASSEMBLER e un LINKER in grado di supportare un software modulare, librerie a oggetti, etc. E’ allora opportuno controllare che il DSP da impiegare abbia un ASSEMBLER e un LINKER in grado di supportare un software modulare, librerie a oggetti, etc. E’ anche importante fare attenzione a quanto è user-friendly il simulatore e le schede di valutazione (interfaccia d’utente). E’ anche importante fare attenzione a quanto è user-friendly il simulatore e le schede di valutazione (interfaccia d’utente). Cosimo Stallo & Paolo Emiliozzi- Modulo di Elaborazione dei Segnali, a.a. 2009/2010

19 PROGETTO HARDWARE I principali requisiti sulla velocità del processore La dimensione di memoria Specifiche su I/O Il supporto di un processore “host” Vengono esaminati nelle fasi di iniziali di sviluppo Cosimo Stallo & Paolo Emiliozzi- Modulo di Elaborazione dei Segnali, a.a. 2009/2010

20 La realizzazione dell’applicazione attorno a un particolare DSP è molto dipendente dal tipo di dispositivo e va, dunque analizzata caso per caso. Alternative Hardware Gli algoritmi di DSP possono essere realizzati in modo diverso a seconda del tipo di applicazione: applicazione in tempo reale non in tempo reale - Chip di DSP “General Purpose” - Chip di DSP “General Purpose” - Chip DSP “Special Purpose” - Chip DSP “Special Purpose” - Processori BIT-Slice - Processori BIT-Slice - Microprocessori - Microprocessori (+ PC, etc) Piattaforme H/W Cosimo Stallo & Paolo Emiliozzi- Modulo di Elaborazione dei Segnali, a.a. 2009/2010

21 General Purpose DSP General Purpose: Dispositivi completamente programmabili e, dunque, molto flessibili. Hanno cicli realizzativi rapidi e loro versioni più veloci vengono realizzate a intervalli regolari, in accordo con gli avanzamenti tecnologici e delle tecniche progettuali. Vengono prodotti in grande quantità, portando un basso costo per unità. Cosimo Stallo & Paolo Emiliozzi- Modulo di Elaborazione dei Segnali, a.a. 2009/2010

22 Esempi di dispositivi “GENERAL PURPOSE” della TEXAS INSTRUMENTS ( Famiglia TMS 320) Processore in virgola fissa a 16 bit con architettura Harward (spazi separati per programma e memoria dati) TI TMS320C25 G.P. DEVICE Cosimo Stallo & Paolo Emiliozzi- Modulo di Elaborazione dei Segnali, a.a. 2009/2010

23 Esempi di dispositivi “GENERAL PURPOSE” della TEXAS INSTRUMENTS ( Famiglia TMS 320) Processore in virgola mobile a 32 bit (no Harward arc.) TI TMS 320C30 G.P. DEVICE Cosimo Stallo & Paolo Emiliozzi- Modulo di Elaborazione dei Segnali, a.a. 2009/2010

24 (p.e. filtri FIR, dispositivo per FFT, dipsositivo per convoluzioni, etc.) Prodotti da alcune case costruttrici (p.e. ZORAN; PLESSEY, SGS; THOMSON MICROELECTRONICS (STM), etc.) Si utilizzano quando è richiesto di effettuare una specifica operazione elaborativa con tempistica ridotta. DSP Special Puropose: DISPOSITIVI FINALIZZATI A COMPITI PREFISSATI S.P. DSP più veloci di G.P. DSP avendo un’architettura dedicata Lo svantaggio di tale approccio è la mancanza di mezzi di sviluppo di tipo standard, il conseguentemente lungo ciclo progettuale, il costo dei componenti….. Cosimo Stallo & Paolo Emiliozzi- Modulo di Elaborazione dei Segnali, a.a. 2009/2010

25 BIT-SLICE COMPONENT: Approccio più di tipo G.P. per il progetto di DSP ad alta velocità (caso intermedio). Tali componenti sono dei blocchi di base (componenti moltiplicatori, ALU, etc.) che vengono connessi tra loro per costituire una specifica architettura DSP. MICROPROCESSORI: Ogni Computer per essere utilizzato per DSP e questo, dunque, vale anche per i comuni microprocessori (come i Motorola e gli Intel i86). Tali dispositivi non hanno l’architettura e le caratteristiche “on chip” richieste per un DSP efficiente (in particolare mancano di un moltiplicatore hardware)! NON SONO UNA SOLUZIONE EFFICACE! NON SONO UNA SOLUZIONE EFFICACE! Cosimo Stallo & Paolo Emiliozzi- Modulo di Elaborazione dei Segnali, a.a. 2009/2010

26 INTEGRAZIONE DI SISTEMA E’ una fase chiave per ogni SISTEMA. Costitiusce, infatti, la prima opportunità di provare il S/W con l’H/W applicativo E’ una fase chiave per ogni SISTEMA. Costitiusce, infatti, la prima opportunità di provare il S/W con l’H/W applicativo Un emulatore globale è il migliore strumento per provare e correggere H/W e S/W, anche se molti progetti perfettamente riusciti sono stati portati a temine senza un emulatore. Cosimo Stallo & Paolo Emiliozzi- Modulo di Elaborazione dei Segnali, a.a. 2009/2010

27 Ci sono due tipi base di emulatori: I TRADIZIONALI “IN CIRCUIT” (per dispositivi di DSP progettati prima del 1988) I TRADIZIONALI “IN CIRCUIT” (per dispositivi di DSP progettati prima del 1988) I NUOVI “IN - SYSTEM” (emulatore si comporta da controllore di un dispositivo con possibilità emulative “on chip”). Adatti per alte velocità. I NUOVI “IN - SYSTEM” (emulatore si comporta da controllore di un dispositivo con possibilità emulative “on chip”). Adatti per alte velocità. Cosimo Stallo & Paolo Emiliozzi- Modulo di Elaborazione dei Segnali, a.a. 2009/2010