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

– Sono rappresentazioni del sistema durante le diverse fasi di

sviluppo

• Dalla descrizione iniziale verso la la fabbricazione si hanno modelli

più dettagliati/complessi e meno leggibili e/o modificabili a mano

• Metriche

– A ogni passo bisogna valutare la qualità della soluzione ottenuta

• La valutazione è molto importante se vista come relativa a soluzioni

alternative

• Strumenti

– Il flusso si compone di trasformazioni che, sotto la guida di

metriche, arricchiscono i modelli di dettagli

• Tali trasformazioni comportano di solito computazioni al di fuori

della portata di un essere umano

Sistemi Embedded 5

2010/2011 Flussi di progettazione

• Lo sviluppo di un sistema embedded inizia con la sua

concezione e la valutazione di aspetti economici e di

mercato e si conclude con la sua fabbricazione

– Questo processo si svolge attraverso moltissimi passi successivi

che possono essere raggruppati per classi nelle seguenti fasi:

• Ideazione e concezione del sistema

• Descrizione del sistema e dei requisiti

• Specifica a livello di sistema

• Definizione dell'architettura di sistema

• Progettazione

• Validazione e verifica

• Fabbricazione

– Test post-produzione

Sistemi Embedded 6

2010/2011 3

Flussi di progettazione

Modelli

Sistemi Embedded 7

2010/2011 Flussi di progettazione

• Modelli

– Un modello consiste in una opportuna semplificazione di

un'entità originale (fisica oppure un altro modello) realizzata con

lo scopo di cogliere solo alcuni aspetti specifici e ben definiti e

ignorare altre proprietà che non risultano d'interesse

• Un modello di un sistema non è qualcosa di assoluto o generale,

ma piuttosto una visione relativa e specifica, costruita con l'obiettivo

di rispondere a una ben precisa domanda o esigenza

– Un secondo aspetto importante di un modello è la sua capacità

di fornire un adeguato supporto ai processi di elaborazione

propri delle diverse fasi di un flusso di progettazione

• Modelli eseguibili/simulabili

Sistemi Embedded 8

2010/2011 4

Flussi di progettazione

• Modelli (obiettivi)

– Un modello fornisce un supporto per rispondere a una specifica

domanda a proposito di un dato sistema o parte di esso e

costituisce un supporto alla sua elaborazione e trasformazione

• Si possono individuare diversi obiettivi perseguibili da un modello

– Esplorazione architetturale

» Analisi rispetto a diverse scelte architetturali, costi e tempi di sviluppo

– Valutazione delle prestazioni

» Informazioni rilevanti relative alle “prestazioni” di un sistema (modelli di

area, tempo, costo, dissipazione di potenza e altri ancora)

– Analisi funzionale

» Ha lo scopo di catturare la funzionalità di un sistema a prescindere da ogni

dettaglio di tipo implementativo (simulabilità)

Sistemi Embedded 9

2010/2011 Flussi di progettazione

• Modelli (obiettivi)

– …

– Sintesi

» Un modello per la sintesi deve cogliere tutti gli aspetti funzionali (e a volte

non) rilevanti a un livello tale da consentire agli strumenti automatici di

procedere al suo raffinamento

– Validazione e verifica

» Queste due attività richiedono prevalentemente modelli simulabili, simili a

quelli usati per l'analisi funzionale, ma generalmente più ricchi di dettagli

(una eccezione sono i modelli utilizzati per la verifica formale)

– Mapping

» Dato il modello di un sistema e un insieme di modelli di entità di base, il

problema del mapping consiste nel determinare come combinare tali entità

elementari in modo da realizzare il sistema richiesto

– Testabilità

» L'analisi della testabiltà di un sistema è mirata a comprendere quale

porzione degli eventuali guasti hardware è rilevabile in fase di testing post-

produzione oppure durante il normale funzionamento del sistema stesso

(modello di guasto)

Sistemi Embedded 10

2010/2011 5

Flussi di progettazione

• Modelli (proprietà)

– Un modello, a prescindere dai suoi obiettivi, è caratterizzato da

un insieme di proprietà, ovvero di caratteristiche inerenti e

indipendenti dal dominio applicativo

– Molto spesso le caratteristiche di un modello non sono

immediatamente evidenti nel formalismo o nel linguaggio

utilizzato per esprimerlo

• Tali proprietà sono in questi casi da attribuirsi ai modelli di calcolo

sottostanti, ovvero alla semantica del corrispondente linguaggio

– Accade spesso, infatti, che linguaggi molto diversi condividano uno

stesso modello di calcolo e pertanto siano semanticamente equivalenti

» VHDL RT e SystemC 1.0

Sistemi Embedded 11

2010/2011 Flussi di progettazione

• Modelli (proprietà)

– Un aspetto essenziale di un modello di calcolo risiede nel

modello del tempo cui fa riferimento

• Modelli a tempo continuo

– Il tempo è una variabile reale

• Modelli a tempo discreto

– Il tempo è una sequenza discreta e infinita di istanti

– Nei modelli a tempo discreto si hanno due sotto-casi

• Istanti sono originati dallo scorrere del tempo: modelli time-driven

• Gli eventi determinano lo scorrere del tempo: modelli event-driven

– Una differenza sostanziale tra i due modelli sta nell'efficienza della

simulazione

Sistemi Embedded 12

2010/2011 6

Flussi di progettazione

• Modelli (proprietà)

– Un'ultima ma importante proprietà dei modelli riguarda il loro

determinismo

• Modelli deterministici, non deterministici, stocastici

– Nella progettazione dei sistemi embedded è molto raro

incontrare sistemi stocastici o non deterministici per cui la

maggior parte dei modelli utilizzati in quest'ambito ricade nella

classe dei modelli deterministici

Sistemi Embedded 13

2010/2011 Flussi di progettazione

• Modelli (astrazione e linguaggi)

– Il livello di astrazione a cui si pone un dato modello determina

alcuni aspetti del modello stesso

• Quantità di dettagli rappresentati, accuratezza, generalità,

flessibilità, leggibilità e manutenibilità, possibilità di essere utilizzato

da strumenti automatici di sintesi o di simulazione e così via

– Secondo una classificazione tipica e ampiamente condivisa si possono

identificare sostanzialmente cinque livelli

Sistemi Embedded 14

2010/2011 7

Flussi di progettazione

• Modelli (astrazione e linguaggi)

– Il più astratto è il livello di sistema che ha lo scopo di descrivere

la struttura generale, non sempre necessariamente in termini

funzionali e completi

• Spesso, questo tipo di modelli ha come obiettivo prevalente quello

di fungere da documentazione e da specifica del problema,

piuttosto che come soluzione implementativa

– In alcuni casi tali modelli possono essere simulabili, ma molto

raramente sintetizzabili SysML

Sistemi Embedded 15

2010/2011 Flussi di progettazione

• Modelli (astrazione e linguaggi)

– Immediatamente al di sotto, si colloca il livello di astrazione

comportamentale detto anche algoritmico o behavioral

• Lo scopo è cogliere gli aspetti funzionali del sistema, quali, per

esempio, gli operatori, i dati e i meccanismi di comunicazione

– Nel caso HW, una visione algoritmica del sistema, in generale, non

contiene informazioni sul modo in cui le funzionalità saranno realizzate

» Limita l'utilizzabilità come punto di partenza per la progettazione automatica

– Nel caso SW, invece, il livello algoritmico è per sua natura il punto di

partenza di ogni flusso di progetto

Sistemi Embedded 16

2010/2011 8

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


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