Che materia stai cercando?

Flussi progettazione Appunti scolastici Premium

Con il termine flusso di progettazione (design flow) si indica l'intero processo che parte dalla concezione e descrizione di un sistema a un livello sufficientemente formale e preciso e giunge fino al passo immediatamente precedente alla sua realizzazione fisica.
Un flusso di progettazione si compone concettualmente dei seguenti tre tipi di entità ben distinte:
–... Vedi di più

Esame di Sistemi embedded docente Prof. L. Pomante

Anteprima

ESTRATTO DOCUMENTO

Flussi di progettazione

• Modelli (astrazione e linguaggi)

– Il livello dataflow fornisce una visione molto più completa e

dettagliata del sistema

• Nel caso HW, vengono definiti l'architettura d'insieme, l'architettura

dei singoli blocchi, natura e dimensione degli operatori

• Nel mondo del software, questo livello fornisce una descrizione del

programma in termini di operazioni elementari

– Tipicamente coincide con il codice assembly simbolico

– I modelli a questo livello, soprattutto nel dominio hardware, sono

quelli più comunemente utilizzati come punto di partenza dei

flussi automatici di supporto alla progettazione

Sistemi Embedded 17

2010/2011 Flussi di progettazione

• Modelli (astrazione e linguaggi)

– A livello logico, ogni parte di un sistema è descritta in termini

funzionalmente non ambigui

• Questo comporta che nessuna informazione aggiuntiva può

modificare la rappresentazione funzionale data

– Nel dominio digitale questo significa descrivere il sistema in termini di

netlist e di componenti elementari la cui funzionalità è nota e fissata

– Nel caso del software, il programma è descritto come una sequenza di

istruzioni assembly specifiche di un dato microprocessore

Sistemi Embedded 18

2010/2011 9

Flussi di progettazione

• Modelli (astrazione e linguaggi)

– A livello fisico, la descrizione dei sistemi HW ha lo scopo di

fornire indicazioni di carattere geometrico (posizione celle,

dimensione celle, percorsi delle net) e fisico/chimico (drogaggi,

resistività, capacità, e molti altri)

• A tale scopo sono molti i formalismi utilizzati, spesso legati ai

fornitori della tecnologia realizzativa finale

– Nel mondo del software, non esistendo una fase di

fabbricazione, il livello fisico coincide con il prodotto finito e,

pertanto, è costituito da uno o più file binari

Sistemi Embedded 19

2010/2011 Flussi di progettazione

• Modelli (astrazione e linguaggi)

– Visione più articolata:

Diagramma a Y

Sistemi Embedded 20

2010/2011 10

Flussi di progettazione

Metriche

Sistemi Embedded 21

2010/2011 Flussi di progettazione

• Metriche

– Nelle varie fasi del flusso di progettazione è necessario valutare

quantitativamente la qualità del sistema descritto da un modello

• Funzione di un insieme di grandezze misurabili del sistema stesso

– Es: qualità di un sistema digitale = f(ritardo, dimensione, potenza)

• Una metrica, permette di ricavare da un modello una grandezza

fisica esprimendola tramite una qualche unità di misura

– Es: per un sistema digitale, una metrica di ritardo potrebbe essere il

numero di livelli di logica ed essere esprimibile con un numero puro

» Tale grandezza non è un tempo, ma una rappresentazione indiretta

– In un flusso di progetto eterogeneo ed articolato come quello per

i sistemi embedded sono molte le metriche che si possono

incontrare

Sistemi Embedded 22

2010/2011 11

Flussi di progettazione

• Metriche

– Prestazioni

• Principale metrica di prestazioni: tempo di esecuzione (ritardo)

– Nel dominio software le grandezze di uso più comune sono il tempo di

esecuzione, i dati di profiling, il tempo di risposta, l'overhead

» A livello più basso (assembly) si usano misure più puntuali quali i CPI o IPC,

il numero medio di stalli, l'hit/miss rate, ecc…

– Nel campo dell‘HW digitale le metriche sono essenzialmente: il ritardo

combinatorio, la frequenza di clock e la latenza

– Nel caso dei circuiti analogici dedicati, tali metriche dipendono

marcatamente dalla tipologia di sistema in esame

» Alcune tipiche metriche sono la frequenza di taglio, la banda, il guadagno, il

rapporto segnale/rumore, la linearità, e così via

Sistemi Embedded 23

2010/2011 Flussi di progettazione

• Metriche

– Dimensioni (SW)

• La misura è diversa a seconda che sia di natura statica o dinamica

– La dimensione statica del codice è comunemente detta footprint e

indica la quantità di memoria necessaria a contenere tutto il codice più i

dati statici

» Questa misura vincola la dimensione dei supporti di memoria permanente,

mentre non fornisce indicazioni sulla dimensione della memoria RAM

– Metriche più astratte, utilizzate a livelli di astrazione più alti, sono, per

esempio, i LOC, i function point, il numero di task e così via

Sistemi Embedded 24

2010/2011 12

Flussi di progettazione

• Metriche

– Dimensioni (HW)

• Per quanto riguarda invece il dominio hardware, le metriche di area

sono le più disparate, data la natura estremamente eterogenea dei

modelli che si incontrano nel flusso ai diversi livelli di astrazione

– Nel caso di circuiti analogici: die size o il numero di transistor

– Per i circuiti digitali si usano spesso gli equivalent gate

– Nel caso di dispositivi programmabili si preferisce indicare l'area di un

circuito in termini di numero di celle o numero di look-up table

» Si tenga però presente che le look-up table e, ancor di più, le celle relative a

diverse tecnologie e diversi fornitori possono differire significativamente

Sistemi Embedded 25

2010/2011 Flussi di progettazione

• Metriche

– Potenza

• La potenza dissipata da un sistema è una misura dinamica,

dipendente dai dati e viene in genere fornita come valor medio

– La potenza è misurata in Watt, ma le metriche HW forniscono misure

indirette quali la switching activity e la capacità effettiva

– Per il SW, la potenza assorbita è spesso misurata come corrente

media per ciclo di clock o di corrente media per istruzione

» Metriche meno raffinate usano il valor medio della potenza dissipata dal uP

– Esistono poi alcune metriche relative di potenza

» Le più comuni sono la potenza media in funzione della frequenza

(mW/MHz) e la potenza media relativa alla potenza di calcolo di un

processore (mW/MIPS)

Sistemi Embedded 26

2010/2011 13

Flussi di progettazione

• Metriche

– Testabilità

• La testabilità è una proprietà delle reti digitali ed è misurata

attraverso un'unica metrica: la copertura

– In generale, comunque, è una misura della percentuale dei potenziali

guasti rilevabili in fase di test post-produzione

• Dato che si tratta di una misura utile al testing post produzione, non

esiste un analogo nel dominio del software

– Il concetto esiste solo nelle classiche fasi di verifica e validazione

Sistemi Embedded 27

2010/2011 Flussi di progettazione

• Metriche

– Affinché le metriche siano utili e di supporto al flusso di sviluppo,

deve essere possibile valutarle a partire da un modello

– Questo implica che

• Il modello deve contenere tutte le informazioni necessarie al calcolo

• Deve esistere uno strumento automatico in grado di effettuare tale

calcolo a partire dal modello

Sistemi Embedded 28

2010/2011 14

Flussi di progettazione

Strumenti

Sistemi Embedded 29

2010/2011 Flussi di progettazione

• Strumenti

– La complessità dei sistemi embedded è tale che difficilmente

modelli e metriche sono sufficienti da soli per ottenere risultati

• Per un loro concreto uso è indispensabile ricorrere a strumenti

software di supporto alla progettazione

– CAD, CAE, EDA

– Tali strumenti hanno caratteristiche e funzionalità molto diverse

• Dominio

– HW/SW

• Livello di astrazione

• Tipo di funzionalità svolta

– Strumenti di compilazione/sintesi, strumenti di verifica/test, librerie

Sistemi Embedded 30

2010/2011 15

Flussi di progettazione

• Strumenti

– Classificazione

Sistemi Embedded 31

2010/2011 Flussi di progettazione

• Strumenti

– Classificazione

Sistemi Embedded 32

2010/2011 16

Flussi di progettazione

• Strumenti

– Compilazione e sintesi

• I processi di compilazione e di sintesi, benché molto diversi in

quanto inerenti ai due domini dell'hardware e del software, hanno in

comune alcune caratteristiche fondamentali

• Entrambi partono da una specifica, o modello, a un dato livello di

astrazione e producono come risultato un nuovo modello,

funzionalmente equivalente a quello iniziale, ma a un livello di

astrazione più basso

– Arricchimento del modello con una serie di dettagli aggiuntivi

» Tali dettagli provengono da informazioni predefinite contenute nelle librerie

di supporto o dalla logica sottostante agli algoritmi di sintesi e di

compilazione

Sistemi Embedded 33

2010/2011 Flussi di progettazione

• Strumenti

– Compilazione e sintesi

• Livello sistema

– Gli unici strumenti disponibili per la compilazione e per la sintesi a

livello di sistema sono i code generators

– Esempi tipici sono sistemi quali Synplify DSP di Synplicity, Matlab e

Simulink di The MathWorks, System Generator di Xilinx e altri analoghi

» La specifica consiste in uno schema grafico in cui blocchi funzionali

predefiniti sono connessi attraverso linee o canali di comunicazione

» Il processo di generazione si limita ad accorpare opportunamente porzioni di

codice (C, C++, assembly o VHDL/Verilog) e a generare una infrastruttura

di controllo derivata dalla topologia del modello originale

Sistemi Embedded 34

2010/2011 17

Flussi di progettazione

• Strumenti

– Compilazione e sintesi

• Livello algoritmico

– A livello algoritmico, si trovano strumenti di generazione automatica del

codice e strumenti di sintesi comportamentale (per le sole sezioni HW)

» La sintesi comportamentale è scarsamente utilizzata a livello industriale

– Eccezioni: strumenti specifici di un ristretto campo applicativo

» Protocol Compiler di Synopsys: a partire da una descrizione grafica simile ai

timing diagrams genera il codice VHDL/Verilog necessario per le

interfacce corrispondenti

» Processor Designer di CoWare e XPRES Compiler / Xtensa Processor

Generator di Tensilica: a partire da una descrizione di un instruction set

producono come risultato una descrizione VHDL/Verilog di un

microprocessore custom e l'intera catena di sviluppo del software

Sistemi Embedded 35

2010/2011 Flussi di progettazione

• Strumenti

– Compilazione e sintesi

• Livelli inferiori

– A tutti i livelli inferiori si trova, invece, una moltitudine di strumenti

estremamente efficienti, generali e flessibili

» Strumenti di sintesi e ottimizzazione logica, per l'hardware

» Compilatori e assembler, per il software

– Dato che per tali strumenti i modelli d'ingresso e di uscita nonché la

tipologia di elaborazione effettuata sono praticamente standardizzati,

un'analisi più approfondita è rimandata alla analisi dei singoli flussi

Sistemi Embedded 36

2010/2011 18

Flussi di progettazione

• Strumenti

– Compilazione

e sintesi

• Retrospettiva

storica

Sistemi Embedded 37

2010/2011 Flussi di progettazione

• Strumenti

– Classificazione

Sistemi Embedded 38

2010/2011 19

Flussi di progettazione

• Strumenti

– Verifica e validazione

• A fianco del flusso di compilazione e sintesi si colloca un flusso

parallelo che ha l'obiettivo di verificare che i modelli, a ogni stadio di

sviluppo, siano corretti, ovvero che soddisfino tutte le proprietà

richieste dalla specifica

• Da un'analisi delle problematiche legate alla verifica si possono

individuare tre tematiche principali

– Determinare se un modello del sistema soddisfa una o più proprietà

richieste dalla specifica

– Verificare che modelli relativi a due fasi distinte del flusso siano

equivalenti rispetto a uno o più criteri predefiniti

– Test post-produzione dell’hardware

Sistemi Embedded 39

2010/2011 Flussi di progettazione

• Strumenti

– Verifica e validazione

• Determinare se un modello del sistema soddisfa una o più

proprietà richieste dalla specifica

• Caso SW

– Esecuzione del codice sul processore target

– Esecuzione su Instruction Set Simulator

» Code Composer Studio per i DSP di Texas Instrument, CodeWarrior o

MetaWare per lo sviluppo con processori Motorola Freescale, RealView

Development Suite per lo sviluppo con processori ARM Ltd

– Profiler e i tool di code coverage

» gprof e gcov di GNU, IBM Rational PurifyPlus

Sistemi Embedded 40

2010/2011 20


PAGINE

27

PESO

191.28 KB

AUTORE

Atreyu

PUBBLICATO

+1 anno fa


DESCRIZIONE DISPENSA

Con il termine flusso di progettazione (design flow) si indica l'intero processo che parte dalla concezione e descrizione di un sistema a un livello sufficientemente formale e preciso e giunge fino al passo immediatamente precedente alla sua realizzazione fisica.
Un flusso di progettazione si compone concettualmente dei seguenti tre tipi di entità ben distinte:
– Modelli
– Metriche
– Strumenti.


DETTAGLI
Corso di laurea: Corso di laurea magistrale in ingegneria delle telecomunicazioni
SSD:
Università: L'Aquila - Univaq
A.A.: 2011-2012

I contenuti di questa pagina costituiscono rielaborazioni personali del Publisher Atreyu di informazioni apprese con la frequenza delle lezioni di Sistemi embedded e studio autonomo di eventuali libri di riferimento in preparazione dell'esame finale o della tesi. Non devono intendersi come materiale ufficiale dell'università L'Aquila - Univaq o del prof Pomante Luigi.

Acquista con carta o conto PayPal

Scarica il file tutte le volte che vuoi

Paga con un conto PayPal per usufruire della garanzia Soddisfatto o rimborsato

Recensioni
Ti è piaciuto questo appunto? Valutalo!

Altri appunti di Sistemi embedded

Programmazione concorrente
Dispensa
Sistemi Embedded
Dispensa
SystemC
Dispensa
Real-time and embedded operating systems
Dispensa