XII Master in Tecnologia dell'Informazione

CEFRIEL - Politecnico di Milano

Area EDA - Electronic Design Automation

Analisi dei Costi di Progettazione

dei Sistemi Digitali

Umberto Bondi

Edi Magini

15 Giugno 2000

Prefazione

La crescente complessit�a dei sistemi digitali e la necessit�a di far fronte al ra-pido evolversi del mercato suggeriscono il riuso di componenti sia a livello diarchitettura sia in termini di funzionalit�a, per ridurre i costi ed i tempi disviluppo. Come conseguenza, risulta indispensabile stabilire delle metodologiedi progettazione e dei criteri di valutazione con cui rendere pi�u e�ciente larealizzazione e l'integrazione delle varie parti. Tale strategia infatti si proponedi garantire maggiore qualit�a, e�cienza e produttivit�a e va ad a�ancare quel-la dell'innalzamento del livello di astrazione per la descrizione del sistema alivello di speci�ca e codice. Nonostante la consapevolezza di tali vantaggi, gliaspetti legati al riuso, che vanno a�rontati e risolti, sono molti.

L'obiettivo del presente lavoro di tesi �e quello di studiare le problematicherelative al riuso di componenti IP (Intellectual Properties) a livello funzionale(soft IP) progettati in VHDL. In particolare, vengono analizzate le strategieper una corretta progettazione e proposte alcune metriche con cui valutare ilcosto delle diverse metodologie di progetto da scegliere nella realizzazione delsistema.

Viene inoltre studiato l'impatto economico delle diverse metodologie diprogetto attraverso una modellizzazione del problema che considera in modoparticolare i rischi ed i costi di una politica basata sul riuso. Le metodo-logie analizzate si riferiscono ai seguenti contesti: progettazione del sistemadigitale per uso singolo; progettazione di componenti a�nch�e possano essereriusati e progettazione del sistema con integrazione di componenti riusabili.Per scegliere se sia conveniente riusare o meno, vanno considerati i costi com-plessivi del sistema per poter e�ettuare un'analisi del rapporto costi-bene�cie valutare cos�� se sia pi�u conveniente una progettazione per uso singolo o unaprogettazione orientata al riuso.

Pertanto, risulta opportuno de�nire un approccio rigoroso nella fase diprogetto che permetta di valutare la possibilit�a di adottare opportune tecni-

i

che, quali ad esempio quelle orientate al riuso di funzionalit�a, e calcolare losforzo indispensabile per raggiungere tali risultati: diventa allora necessarioformalizzare un modello e quindi analizzarne i paramentri di ingresso ovverole variabili predittive. Nel caso del presente modello di analisi economica levariabili predittive derivano da economie e diseconomie di scala, da fattori re-lativi all'ambiente di progetto e di produzione, tra i quali assume particolarerilevanza la dimensione del progetto. Quest'ultima viene valutata in terminidi linee di codice della descrizione VHDL. Tale valutazione viene e�ettuata de-�nendo delle tecniche e delle metriche per misurarla: la metrica pi�u semplicesi basa sul numero delle linee di codice, ottenuta considerando la struttura ela natura del progetto; una seconda possibilt�a consiste nel misurare le funzio-nalit�a espresse dal sistema: l'esigenza di tale metrica nasce dalla di�colt�a deiprogettisti nell'utilizzo del primo metodo.

La tesi �e strutturata nel seguente modo: nei primi tre capitoli vengono analiz-zate e descritte le problematiche inerenti a questo lavoro; nei capitoli quattro,cinque e sei viene presentato il modello economico nelle sue linee pi�u generali;negli ultimi due capitoli vengono descritti strumenti e metriche necessarie perla valutazione di variabili del modello. Il contributo originale alle tematicheconsiderate si esplica nell'adattamento di tecniche tipiche dell'Ingegneria delSoftware ad applicazioni di progettazione Hardware ovvero ad un ambientecaratterizzato da una forte concorrenzialit�a degli eventi, condizione insolita ri-spetto alle pi�u usuali applicazioni software; in particolare si sono formalizzatele metriche per il calcolo dei \Function Point" e delle righe di codice; sonostate valutate caratteristiche della progettazione orientate al riuso e il loro im-patto sullo stile di scrittura del codice; �e stato in�ne considerato un progettoreale per la validazione dei risultati teorici. Pi�u in dettaglio la distribuzionedel contenuto �e la seguente:

� Primo capitolo. Vengono introdotte le principali problematiche che han-no condotto al riuso di componenti nella progettazione dei sistemi digita-li. Tali problematiche vengono a�rontate dall'Industria Microelettronicaconsiderando le precedenti esperienze di riuso di codice provenienti daaree tipiche di Ingegneria del Software, dove la progettazione orientataal riuso �e ormai consolidata.

� Secondo capitolo. Vengono descritte le fasi che caratterizzano la progetta-zione dei sistemi digitali. In particolare, viene sottolineata l'importanzadi strumenti, modelli formali e descrizioni ad alto livello, per trattarnela complessit�a, garantirne la veri�ca mediante simulazione, e la sintesiautomatica. Sono inoltre identi�cate tre fasi principali del usso di pro-

ii

getto, ovvero il progetto funzionale, architetturale/logico ed il mappingtecnologico.

� Terzo capitolo. Dopo una breve introduzione relativa ai rischi di progetto,sono descritte le quattro aree principali che concorrono alla loro gestio-ne durante l'intero sviluppo: identi�cazione, quanti�cazione, strategia epiani�cazione.

� Quarto capitolo. In questo capitolo dopo una breve analisi dei costi direalizzazione di un sistema digitale , viene proposto il modello di va-lutazione dello sforzo e dei tempi di realizzazione. Vengono presentatii principali fattori che in uenzano i costi di progettazione e sviluppo,ovvero quelli su cui il riuso in uisce maggiormente. Per determinarnel'impatto, viene fatta un'analisi dei fattori che in uiscono su di esse eviene proposta la versione a priori del modello. Tale impostazione �e fat-ta sulla base delle similitudini esistenti tra il progetto funzionale e losviluppo di un'applicazione software vera e propria. I valori dei para-metri del modello proposto sono gli stessi del modello per la stima dellosforzo di sviluppo di grandi applicativi software (COCOMO 2.0 ). Sitratta infatti di una prima versione che necessita di essere opportuna-mente calibrata sulla base di informazioni oggettive derivanti da progettiesistenti (calibrazione del modello).

� Quinto capitolo. In questo capitolo viene a�rontato il concetto di proget-tazione orientata al riuso di un sistema digitale. Vengono descritte le at-tuali tecniche di riuso, sottolineando le propriet�a che un componente devesoddisfare. Poich�e rendere un componente riusabile impone comunquedei costi aggiuntivi, sono approfondite le attivit�a su cui il riuso in uiscemaggiormente e come ci�o si ripercuota sullo sforzo di progettazione.

� Sesto capitolo. In questo capitolo viene formalizzato il bene�cio economi-co derivante dal riuso di componenti. Sono de�niti il costo di progetta-zione per riusare un componente, il costo di progettazione di un sistemain assenza di riuso e quello nel caso un modulo venga riusato. Si sotto-lineano i costi aggiuntivi ed in bene�ci derivanti dal riuso, in termini dicosti di sviluppo e Time to Market, e viene fatta una stima del ritornodi investimento nel caso uno stesso modulo venga riusato pi�u volte inun'analisi riferita ad un determinato periodo di tempo.

� Settimo capitolo. Per attribuire un valore ad uno dei parametri del mo-dello �e necessario \dimensionare" il progetto. In questo capitolo vienedescritta la metrica, gi�a consolidata, di stima delle linee di codice e ne

iii

vengono de�nite le linee guida nel caso di analisi di un linguaggio per ladescrizione dell'hardware. Successivamente viene introdotta la metricadi stima indiretta, attraverso l'attribuzione di una dimensione al proget-to sulla base delle funzionalit�a descritte nella speci�ca. Si tratta dellametrica Function Point applicata al VHDL. Vengono de�niti i criteriguida di analisi, alla luce di quanto presente in letteratura e di aspettitecnici e realizzativi legati al VHDL stesso. All'interno di questo capitolovengono riportati i risultati sperimentali ottenuti per la validazione delletecniche di dimensionamento del progetto, facendo riferimento al codiceVHDL per lo sviluppo di un processore (LEON ). A partire dalle infor-mazioni derivabili dalla speci�ca �e stata fatta una stima della dimensionedel progetto con la metrica Function Points VHDL, sulla base dei criteriguida de�niti. I valori trovati sono stati confrontati con quelli e�ettiviricavabili da misurazioni dirette sul codice.

� Ottavo capitolo. Viene presentato lo strumento \PROTON " per l'analisidella descrizione del progetto in VHDL, sia sintattica sia semantica. Contale strumento �e stato possibile realizzare una validazione automatica del-la metriche proposte per il dimensionamento di un progetto, mediantela stima della quantit�a di codice VHDL associato e l'estrazione di infor-mazioni sulla qualit�a del codice e sulle caratteristiche implementative diprogetto. Con lo strumento PROTON, �e possibile inoltre veri�care che ilcodice rispetti un'insieme di linee guida che permettono al progettista didescrivere un componente hardware garantendone alcune caratteristichetra cui, in particolare, la riusabilit�a almeno in determinati contesti.

Da ultimo vengono poi esposti le conclusioni ed alcuni possibili sviluppi futuri.

iv

Indice

1 La strategia del Riuso 11.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Il riuso in Ingegneria del Software . . . . . . . . . . . . . . . . . 41.3 Come �e impostato attualmente il Riuso . . . . . . . . . . . . . . 5

1.3.1 I componenti IP . . . . . . . . . . . . . . . . . . . . . . 61.4 Il mercato dei componenti IP . . . . . . . . . . . . . . . . . . . 7

2 Analisi del usso di progetto 112.1 La metodologia di progettazione . . . . . . . . . . . . . . . . . . 11

2.1.1 Il VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2 Il usso di progetto . . . . . . . . . . . . . . . . . . . . . . . . . 132.3 Il Progetto Funzionale . . . . . . . . . . . . . . . . . . . . . . . 162.4 Il Progetto Architetturale/Logico . . . . . . . . . . . . . . . . . 182.5 Mapping Tecnologico . . . . . . . . . . . . . . . . . . . . . . . . 23

3 La gestione del progetto 293.1 La gestione dei rischi . . . . . . . . . . . . . . . . . . . . . . . . 293.2 Identi�cazione e quanti�cazione dei rischi . . . . . . . . . . . . . 313.3 Strategia e piani�cazione . . . . . . . . . . . . . . . . . . . . . . 363.4 La gestione dei tempi . . . . . . . . . . . . . . . . . . . . . . . . 38

4 Il modello di analisi economica 434.1 Identi�cazione dei costi . . . . . . . . . . . . . . . . . . . . . . . 434.2 Stima dello sforzo e del tempo di sviluppo . . . . . . . . . . . . 46

4.2.1 Stima delle ore lavorative . . . . . . . . . . . . . . . . . 474.3 I parametri del modello . . . . . . . . . . . . . . . . . . . . . . . 474.4 Fattori moltiplicativi . . . . . . . . . . . . . . . . . . . . . . . . 494.5 Economie e diseconomie di scala . . . . . . . . . . . . . . . . . . 51

5 L'impatto economico del riuso 555.1 L'esigenza di un modello �nanziario . . . . . . . . . . . . . . . . 55

vi

5.2 Riusabilit�a di un progetto . . . . . . . . . . . . . . . . . . . . . 575.2.1 Come riusare i progetti . . . . . . . . . . . . . . . . . . . 585.2.2 Ostacoli al Riuso di progetti . . . . . . . . . . . . . . . . 59

5.3 Propriet�a di un componente riusabile . . . . . . . . . . . . . . . 595.4 Tecniche di riuso per la progettazione V LSI . . . . . . . . . . . 62

5.4.1 Progettazione dei componenti riusabili . . . . . . . . . . 625.5 Il modello esteso al riuso . . . . . . . . . . . . . . . . . . . . . . 64

6 Modello complessivo dei costi 676.1 Evoluzione della produttivit�a . . . . . . . . . . . . . . . . . . . 67

6.1.1 La produttivit�a per sistemi digitali . . . . . . . . . . . . 686.1.2 La produttivit�a nei componenti riusabili . . . . . . . . . 69

6.2 Time to Market e Riuso . . . . . . . . . . . . . . . . . . . . . . 716.3 Stima dei costi . . . . . . . . . . . . . . . . . . . . . . . . . . . 736.4 Costi e bene�ci del riuso . . . . . . . . . . . . . . . . . . . . . . 756.5 Ritorno d'investimento (ROI) . . . . . . . . . . . . . . . . . . . 77

6.5.1 Stima del ritorno d'investimento (ROI) . . . . . . . . . . 78

7 Calcolo della dimensione del progetto 817.1 Concetto di metrica . . . . . . . . . . . . . . . . . . . . . . . . . 817.2 Il progetto \LEON " . . . . . . . . . . . . . . . . . . . . . . . . 827.3 La metrica delle lines of code . . . . . . . . . . . . . . . . . . . 84

7.3.1 Descrizione e validazione della metrica delle \lines of code" 857.3.2 Costrutti concorrenti . . . . . . . . . . . . . . . . . . . . 85

7.4 La metrica dei Function Points VHDL . . . . . . . . . . . . . . 887.4.1 La speci�ca e le unit�a funzionali . . . . . . . . . . . . . . 887.4.2 Calcolo dei \Punti Funzione VHDL" . . . . . . . . . . . 907.4.3 Legame tra FPV HDL e LOC . . . . . . . . . . . . . . . . 94

7.5 Validazione della metrica FPV HDL . . . . . . . . . . . . . . . . 95

8 Strumenti di valutazione del codice 998.1 L'impego di strumenti automatici . . . . . . . . . . . . . . . . . 998.2 Codi�ca standard, stili di codi�ca . . . . . . . . . . . . . . . . . 1018.3 La struttura di LVS . . . . . . . . . . . . . . . . . . . . . . . . . 103

8.3.1 La base di dati VHDL . . . . . . . . . . . . . . . . . . . 1048.4 ProVHDL: Programmable V HDL design rule checker . . . . . 105

8.4.1 ProVHDL overview . . . . . . . . . . . . . . . . . . . . . 1078.4.2 ProVHDL Specifier . . . . . . . . . . . . . . . . . . . . 1088.4.3 VRSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1088.4.4 ProVHDL Checker . . . . . . . . . . . . . . . . . . . . . 112

8.5 Regole per riuso . . . . . . . . . . . . . . . . . . . . . . . . . . 114

vii

8.6 Vantaggi e svantaggi di ProVHDL . . . . . . . . . . . . . . . . . 117

Bibliogra�a 123

viii

Capitolo 1

La strategia del Riuso

1.1 Introduzione

L'Industria Microelettronica, basata sull'uso dei semiconduttori, ha subito unaprofonda evoluzione negli ultimi decenni, dando luogo ad una crescente di�u-sione di dispositivi e sistemi digitali, in settori caratterizzati spesso da volumidi produzione anche elevati: dal campo multimediale e delle telecomunicazioniai sistemi di elaborazione, dalla elettronica di consumo all'automotive. Da unlato, i miglioramenti tecnologici hanno determinato una crescita esponenzialedel numero di transistor sul singolo chip, migliori prestazioni ed una riduzionedell'area di silicio; dall'altro, il maggiore livello di integrazione ha determinatouna maggiore complessit�a dei sistemi, una riduzione dei costi ed una maggiorea�dabilit�a.Tutto ci�o ha condotto a profondi cambiamenti. Lo sforzo richiesto per proget-tare e produrre circuiti integrati cos�� complessi �e decisamente aumentato conil rischio di prolungare troppo il ciclo di sviluppo; altrettanto �e avvenuto perla qualit�a richiesta al prodotto da parte degli utenti sia intermedi sia �nali.Inoltre la rapida evoluzione tecnologica rendendo molto presto un dispositivoobsoleto, ha imposto l'introduzione di nuove \generazioni" in tempi semprepi�u brevi. Contemporaneamente, la crescente competitivit�a e le pressioni delmercato hanno condotto a vincoli sempre pi�u stringenti sui costi di sviluppo.�E stato quindi necessario adottare una metodologia che consentisse contem-poraneamente di ridurre il tempo del ciclo di progettazione ed i costi su cui

1

fosse possibile intervenire. Tali costi si sono rivelati essere i costi di progetto esviluppo, dato che le attuali tecnologie di fabbricazione sempre pi�u so�sticatenon possono far altro che aumentare quelli relativi invece alla realizzazione�nale del dispositivo. Tra le principali conseguenze di questa nuova realt�a, c'�estata la consapevolezza da parte di tutti gli addetti al settore dell'importanzastrategica assunta dall'aumento della qualit�a del progetto, della produttivit�ada parte dei progettisti e della predicibilit�a dei risultati [Girc 93]. La qua-lit�a di progetto deve essere interpretata sia in termini di \performance", perrendere il prodotto competitivo, sia in termini di \correttezza", per evitareall'azienda di impegnare tempi, costi e risorse nella correzione degli errori diprogettazione. Allo stesso tempo, l'aumento della produttivit�a da parte deiprogettisti, non corrisponde soltanto alla riduzione del tempo complessivo disviluppo e ad una conseguente entrata del prodotto sul mercato in tempi pi�urapidi (Time-to-Market), ma anche alla possibilit�a di sfruttare pienamente ilsilicio che l'industria microelettronica mette a disposizione. Anche la predi-cibilit�a dei tempi di progetto risulta ormai essere un requisito essenziale perpiani�care l'introduzione dei prodotti sul mercato.La prima soluzione individuata dai progettisti �e stata quella di spostare il pro-getto verso livelli di astrazione pi�u alti, e di automatizzarne le varie fasi conl'ausilio dei tool EDA, (\Electronic Design Automation"), proponendosi di:

� ridurre il tempo e lo sforzo manuale richiesto per progettare, analizzaree veri�care il singolo IC;

� migliorare le performance e la densit�a di progetti complessi;

� incentivare l'a�dabilit�a del processo di progetto e realizzazione.

In questo modo migliora la produttivit�a perch�e i progettisti operano ad un livel-lo pi�u concettuale, generando descrizioni pi�u sintetiche del problema e la qua-lit�a aumenta perch�e �e possibile esplorare pi�u scelte progettuali e commetteremeno errori.

Attualmente per�o tutto questo non �e pi�u su�ciente. Nonostante gli stru-menti e le nuove metodologie a disposizione abbiano dato comunque la possi-bilit�a di lavorare ad un livello di astrazione pi�u alto, con il modello economicoattuale e le usuali scelte progettuali, i tempi e i costi per lo sviluppo di talisistemi sarebbero insostenibili da qualsiasi azienda del settore. La legge di Mo-ore, secondo la quale la densit�a dei chip raddoppia ogni diciotto mesi, �noranon �e mai stata disattesa. Dal 2001 i circuiti integrati pi�u complessi conter-ranno 12 milioni di gate e opereranno a velocit�a superiori a 600 Mhz, con untempo di progetto pari approssimativamente a 400 anni uomo. Uno studio diSemantech, [RASSP], mostra come la produttivit�a, espressa in numero di ga-te, cresca ogni anno di un fattore pari al 21% rispetto ad una crescita del 50%

2

Figura 1.1: \Productivity Gap" e soluzioni.

del numero di gate disponibili su silicio. La rapida evoluzione nell'industriamicroelettronica ha quindi contribuito sia al cosiddetto \Designer ProductivityGap" sia al \Silicon Performance Gap".Il primo dipende dal fatto che la capacit�a del chip sta crescendo molto pi�uvelocemente dell'uso che un progettista riesce a farne, il secondo tiene invececonto del divario esistente tra le performance potenzialmente raggiungibili gra-zie alle innovazioni nel processo di fabbricazione del silicio e quelle che in realt�aun progettista pu�o realmente ottenere. Negli ultimi anni si �e dunque di�usa laconvinzione tra i principali produttori di silicio, circuiti integrati e strumentidi sviluppo della necessit�a di un approccio complementare al precedente.Si tratta di una metodologia di progetto basata sul Riuso, quale metodo pi�upromettente per migliorare l'e�cienza di progettazione dei circuiti integrati.Con esso la produttivit�a aumenta in quanto il progettista pu�o utilizzare partigi�a progettate in modo accurato. La qualit�a, a sua volta, aumenta sia in ter-mini di correttezza, perch�e parti di progetto riusate sono gi�a state testate, siain termini di performance dal momento che il progettista ha accesso a nuoveimplementazioni. Altrettanto accade per la predicibilit�a: essendo gi�a note lecaratteristiche in termini di performance e tempo, non ci si aspettano grossesorprese dai componenti riusati.Tale idea non �e certamente una novit�a: un progettista di norma ha sempreriusato, quando possibile, i propri progetti, in termini di codice HDL (Hard-ware Description Language), netlist o layout. Ma se pensiamo al riuso come lasoluzione, forse unica, per aumentare la produttivit�a, tutto questo non �e pi�usu�ciente.Per far fronte alla crescente complessit�a dei sistemi digitali, i progettisti hannodovuto automatizzare il pi�u possibile le fasi di progetto, in particolare la sin-tesi RTL (Register Transfer Level) e l'ottimizzazione logica. Inoltre, le parti

3

riusabili possono essere automaticamente ricavate dal codice HDL e, esistendopi�u versioni, sar�a pi�u facile scegliere l'implementazione appropriata. Avere adisposizione codice HDL sempli�ca sia il mantenimento in librerie sia le even-tuali modi�che per adattare uno o pi�u moduli ad una particolare applicazione.Un secondo fattore che ha in uenzato il riuso �e l'aumento del livello di inte-grazione e la conseguente importanza attribuita sia al consumo di potenza siaall'occupazione d'area. Un componente per essere riusabile deve essere proget-tato e poi integrato insieme ad altri sullo stesso pezzo di silicio con la minoredi�colt�a possibile.In�ne, cambiano le strategie di mercato: cresce il numero di progetti sviluppaticontemporaneamente da gruppi che cooperano tra loro condividendo attivit�a,competenze e propriet�a intellettuali.Il risultato di queste nuove tendenze �e da ricercarsi nel passaggio della proget-tazione orientata al riuso dal paradigma hardware a quello software. Mentrein passato si trattava di acquistare un pezzo di silicio, attualmente �e la descri-zione di un componente in forma sintetizzabile ad essere riusata in un progettoFPGA (Field Programmable Gate Array) o in un ASIC (Application Speci�cIntegrated Circuit) e non l'implementazione �sica.Del resto, la crescente programmabilit�a consente di gestire al meglio sia l'ade-guamento del progetto ad applicazioni di�erenti, sia le richieste di cambiamentinegli standard o di introduzione di nuove funzionalit�a, riducendo lo sforzo nellemodi�che del codice, nella correzione di eventuali errori e quindi nei costi.Il riuso pertanto coinvolge l'intero progetto e, in quanto tale, deve essere inter-pretato non solo come una tecnica di progettazione ma anche come l'obiettivodell'intero processo di sviluppo. Ovviamente, a�nch�e possa a�ermarsi nell'in-dustria microelettronica, gli studi sono diretti in varie direzioni, cercando dia�rontare il problema da pi�u punti di vista, per de�nire \quali" componentiriusare e \come" intervenire in fase di progetto per riusare nel migliore deimodi.

1.2 Il riuso in Ingegneria del Software

Nel mondo industriale manifatturiero l'approccio al riuso �e stato pi�u semplice�n dall'inizio poich�e si trattava di utilizzare componenti prefabbricate, pre-realizzate ed interscambiabili.Questo non �e stato altrettanto estendibile al riuso di software. In Ingegne-ria del Software si �e cercato infatti di sviluppare ed utilizzare paradigmi chepermettessero di ridurre lo sforzo di progetto delle applicazioni software, diaccrescerne la qualit�a e ridurne il time-to-market. A partire dagli ultimi anniOttanta, �e stata introdotta la progettazione con il riuso, riconoscendone, con

4

l'ausilio di modelli, sia la necessit�a sia i meriti: dalla riduzione dei costi e deirischi, a cicli di progetto pi�u veloci, ai miglioramenti delle funzionalit�a e dellaqualit�a, [SRBM 95a] e [SRBM 95b]. I linguaggi ed i tool non hanno risoltotutti i problemi, tantomeno �e stato quindi possibile limitare il riuso alle solecomponenti di codice. �E stata invece dimostrata la necessit�a di adottare inmodo sistematico una strategia, durante tutto il ciclo di sviluppo, includendoil riuso dei requisiti, delle speci�che, dei documenti, del codice e dei piani diveri�ca e validazione.Ci�o ha signi�cato adottare quindi non soltanto nuove tecnologie ma anche unnuovo approccio manageriale ed organizzativo, maggiori investimenti ed unapiani�cazione a lungo termine.Teg Biggersta� (Microsoft) lo ha cos�� de�nito: \It's like a savings bank ac-count". �E stato quindi importante prima di tutto, riuscire a capire l'esigenzadi investire, di realizzare piani accurati per sviluppare e mantenere moduli ri-usabili in librerie, ed �e stato riconosciuto lo sforzo aggiuntivo per le di�erentirichieste in fatto di performance, documentazione e qualit�a, [Boeh 98]. Seun'azienda sceglie di realizzare sistematicamente il riuso, ci sar�a infatti unosforzo ulteriore da sostenere qualora l'obiettivo sia quello di introdurre i pro-dotti sul mercato pi�u rapidamente di quanto non lo sia adottando uno stile diprogettazione per una sola implementazione. Si �e quindi rivelato determinanteprogettare per il riuso e con il riuso ed i criteri per uni�care questi due approccisi sono rivelati dunque essere di tipo manageriale, progettuale, architetturalee implementativo. Lo stessa strada �e stata intrapresa anche nel momento incui �e stato deciso di introdurre il riuso nella progettazione di SoC (System onChip).

1.3 Come �e impostato attualmente il Riuso

Le principali domande a cui �e necessario rispondere sono: quali tecniche adot-tare per progettare per il riuso, come garantire una progettazione e�ciente diblocchi riusabili e come ristrutturare il usso di progetto per riusare al meglioi componenti. Le risposte vanno ricercate nella giusta combinazione di fattoritra i quali: l'organizzazione del gruppo di progetto, la facilit�a di scambio delleinformazioni, decisioni appropriate e l'impiego di standard.Attualmente, viene attribuita maggiore enfasi al riuso interno. Il usso di pro-getto, nel quale hanno un ruolo centrale i linguaggi di descrizione dell'hard-ware, �e fortemente automatizzato dal livello RT �no a quello gate e layout. Inparticolare, le descrizioni RTL, indipendenti dai tool e dalle tecnologie, sonobuoni candidati per essere riusati. I tool di sintesi invece supportano sottoin-siemi di linguaggi e stili di codi�ca leggermente diversi e quindi raggiungerne

5

una completa indipendenza �e di�cile. Al pi�u dei risultati accettabili possonoessere ottenuti a�ancando degli script al progetto RTL. Per questo motivo,le aziende sottolineano l'esigenza di linee guida con cui migliorare la porta-bilit�a e l'interoperabilit�a dei progetti a livello RT, incentivando un lavoro distandardizzazione.

1.3.1 I componenti IP

Se l'evoluzione nelle tecnologie di lavorazione del silicio permette di realizzaresistemi altamente complessi su un singolo die, manca l'abilit�a di progettazionein un tempo ragionevole.La pi�u promettente metodologia di progetto in grado di risolvere questo pro-blema �e quella che ha come obiettivo il riuso di componenti IP o IntellectualProperty : moduli preimplementati, riusabili che, in teoria, possono essere velo-cemente assemblati, simulati, veri�cati ed implementati. Detti anche \Core",\Virtual Component", \Megacelle", questi componenti sono prodotti, la cuimaggior qualit�a �e da ricercarsi nell'abilit�a di coloro che li hanno realizzati,[Bigg 97]. Legalmente, tutto ci�o �e considerato propriet�a intellettuale e cometale protetto da brevetti e copyright. In particolare, le due attivit�a che con-traddistinguono un componente IP sono il progetto architetturale/algoritmicoda un lato, il progetto �sico e l'ottimizzazione dall'altro ed �e in funzione diesse che possono essere cos�� classi�cati:

� Soft : sono descrizioni in HDL comportamentale e sintetizzabile. Hannoil vantaggio di essere estremamente essibili e portabili e lo svantaggio dinon essere predicibili in termini di prestazioni (area, velocit�a e potenza).Poich�e, in caso di riuso, si tratta di utilizzare direttamente il codicesorgente, c'�e il problema della protezione della propriet�a intellettualeoltre ad un notevole sforzo aggiuntivo per l'integrazione.

� Hard : si tratta in questo caso di avere a disposizione una netlist conplacement e routing ottimizzata rispetto ad una speci�ca libreria tecno-logica, un layout �sico oppure entrambi. Essendo quindi ottimizzati inarea, prestazioni e potenza, sono molto predicibili ma, allo stesso tempo,molto meno portabili e essibili a causa della dipendenza dal proces-so tecnologico. Non richiedendo il codice RTL, non hanno problemi diprotezione legale, [Syno 98a].

� Firm : rappresentano un compromesso tra i due tipi precedenti trat-tandosi di componenti soft ottimizzati in performance, potenza ed area,mediante oorplanning e placement con l'uso di una libreria generica.

6

Sono una combinazione di RTL sintetizzabile, librerie tecnologiche diriferimento, oorplan dettagliato e netlist parziale o completa. In que-st'ultimo caso sono richieste anche le liste dei test mentre manca sempreil routing. Sicuramente pi�u predicibili dei componenti soft, non hannoneanche problemi di protezione delle propriet�a intellettuali qualora nonsia presente il codice sorgente RTL.

Portable Layout

Fixed Layout

Gates

RTL

Gates + Floorplan

Behavioral

Fle

ssib

ilità

Firm

Hard

Soft

Pre

dic

ibilità

Figura 1.2: Livelli di integrazione dei componenti IP .

Un altro fattore non trascurabile all'interno di ogni classe �e il fatto che pi�u unprodotto non �e presente sul mercato, nonostante la domanda, maggiore sar�ail prezzo, indipendentemente da quelli che sono stati i costi di produzione.In particolare, parlare di scarsit�a dei componenti IP vuol dire far riferimen-to alla complessit�a sia funzionale, cio�e quanto siano so�sticati l'algoritmo el'architettura sia �sica, cio�e quanto siano facilmente implementabili su silicio.

1.4 Il mercato dei componenti IP

Virtualmente ogni prodotto elettronico �e il risultato di una combinazione diprodotti standard. Poich�e la maggior parte di essi sono poi utilizzati non sulla

7

Integrazione Rappresentazione Librerie Tecnologia Portabilit�a

\Soft"Progetto di sistema Comportamentale Non applicabile Indipendente Illimitata

Flessibilit�a elevata Livello RTL RTLPredicibilit�a assente

\Firm" LibrerieSintesi & RTL & vincoli di riferimento. Generica Mapping

Flessibilit�a buona Floorplanning Netlist Modelli temporali, di libreriaPredicibilit�a buona di collegamento

\Hard"Routing & Livello Librerie speci�che Pre�ssata Process

Flessibilit�a assente Veri�ca geometrico PortingPredicibilit�a elevata

Tabella 1.1: Di�erenze tra le tipologie di componenti IP .

board ma sul singolo chip, ogni azienda tende ad acquistare, progettare e ve-ri�care blocchi standard di varia natura, nella maniera pi�u veloce ed e�cacepossibile. Ormai, con le crescenti pressioni di Time to Market e di cicli disviluppo sempre pi�u ridotti, nessuna compagnia pu�o permettersi di progettareinteramente from scratch. Per restare competitivi l'unica soluzione �e riusarecomponenti IP gi�a esistenti che diventano dunque il veicolo ideale per promuo-vere il riuso e lo strumento essenziale per progetti estremamente complessi. Sein molti casi quello che viene fatto �e uno sviluppo interno di componenti IP ,a causa della rapida evoluzione delle tecnologie e dei tool, sono poche le azien-de che possiedono su�cienti risorse economiche per sostenere il progetto ed ilmantenimento di tutti i blocchi di cui hanno bisogno.Grazie agli emergenti standard, ( [VSIA 97]), per facilitarne l'interoperabilit�a,ogni gruppo di progetto pu�o diventare esso stesso fornitore di blocchi funziona-li, dando agli altri la possibilit�a di scegliere se comprarli, produrli o scambiarli.I bene�ci di un tale mercato sono indiscutibili: colui che deve integrare com-ponenti IP potr�a valutare e selezionare quelli gi�a esistenti e ridurre i tempi ecosti di progetto; colui che fornisce IP riduce costi e tempi di sviluppo mini-mizzando la ridondanza dei prodotti; i fornitori di tool EDA potranno, a lorovolta, ridurne la complessit�a facilitandone l'integrazione con interfacce stan-dard.I fornitori di silicio si trovano dunque di fronte ad un problema: come garantireIP ai propri clienti, tenendo conto che i componenti richiesti non sono di ununico tipo e tantomeno hanno la stessa complessit�a?In mancanza sia di tempo sia di esperienza, un'azienda pu�o al pi�u specializzarsinel fornirne soltanto alcuni e decidere se e quali sia invece necessario comprare,[Lewi 97]. Tra coloro che usano componenti IP le esigenze non sono le stesse

8

per tutti. Da un lato vi sono le aziende che si appoggiano a pi�u di una fonderiae si dedicano ad una tipologia speci�ca di progetti e quindi richiedono pochicomponenti predicibili e portabili. Dall'altro esistono compagnie con esigen-ze opposte: fabbricando i propri progetti presso una sola fonderia richedonocomponenti ottimizzati sia �sicamente sia elettricamente. Se un fornitore com-merciale provvede al 100% dei propri bisogni, un fornitore di semiconduttorideve investire comunque molto per rendere i propri componenti utilizzabili.Questo accade maggiormente nel caso di componenti soft, in quanto l'algorit-mo e l'architettura sono speci�cati ma non implementati e quindi �e richiestauna maggiore attenzione alla trasformazione del componente soft in hard.Del resto la maggior parte dei componenti disponibili sono soft, e di�cilmenteuna compagnia investir�a soltanto su quelli hard. Un fornitore di semicondut-tori pu�o anche richiedere al proprio cliente di implementarli in fase di proget-tazione ma ci�o riduce il valore stesso del componente in termini di time tomarket. Idealmente quindi dovranno essere valutati gli elementi ed i compo-nenti disponibili, dalle standard cell ai core pi�u complessi, dovr�a essere fattaun'analisi di tutti gli aspetti legati alla produzione di un componente quando�e realizzato internamente o proviene dall'esterno, ed in�ne comprendere qualisiano le aspettative, in relazione al tipo di componente in questione. Certa-mente i criteri alla base della scelta tra comprare o produrre sono molteplici:capacit�a di eseguire determinate attivit�a piuttosto di altre (implementazioneRTL, testing, produzione); esperienza e mezzi per realizzare componenti �sici,piuttosto che generatori di memoria; valutazione del rischio: (se il componen-te esiste gi�a, ma non viene acquistato, andr�a realizzarlo meglio e nei tempiprevisti); costi di realizzazione dovranno essere comunque inferiori al costo sulmercato del prodotto; di�erenziazioni richieste al prodotto non disponibili peril componente gi�a esistente.Si stima che il mercato degli IP possa diventare superiore a quello dei toolEDA o comunque pari a quello degli ASIC. Come si pu�o intuire le maggioridi�colt�a sono rappresentate dagli aspetti legali, tanto che la maggior partedelle compagnie evitano di acquistare IP \o�-the-shelf " da piccoli venditoriindipendenti, preferendo lavorare invece con un numero ridotto e ben stabilitodi collaboratori.

9

Capitolo 2

Analisi del usso di progetto

Negli ultimi venti anni la nascita dei linguaggi per la descrizione dell'hard-ware (HDL), in concomitanza con l'introduzione della tecnologia submicron,ha determinato sostanziali cambiamenti nella sequenza di fasi che vanno e�et-tuate per la progettazione dei sistemi digitali, dando pi�u enfasi ed importanzaad alcune di esse. Mentre alcune sono state quasi interamente automatizzate,le prime diventate oggi molto pi�u astratte ed allo stesso tempo cruciali per tut-te le altre. Allo stesso tempo, sono state introdotte nuove problematiche legatealla sintesi automatica ed alla ottimizzazione, all'adattamento alla tecnologiadigitale sottostante ed alla portabilit�a della descrizione hardware.

2.1 La metodologia di progettazione

Per sistema digitale, alcuni intendono semplicemente un circuito VLSI, altri ildispositivo completo. Parlando di progettazione, includeremo nella de�nizioneogni circuito digitale che elabora e/o immagazzina informazioni, considerando,in seguito, sia il sistema nel suo complesso, sia le singole parti di cui �e com-posto. Pertanto la de�nizione di sistema digitale �e molto ampia, e copre unavasta gamma di sistemi, dal livello gate, il pi�u basso per le singole componenti,a quello pi�u alto, speci�co delle unit�a funzionali.Negli ultimi anni, la complessit�a che caratterizza questi sistemi �e diventatatale da richiedere l'adozione di una sistematica metodologia di progetto. �E di-ventato necessario de�nire dapprima i requisiti generali del sistema digitale inmodo astratto e, successivamente, i componenti che ne costituiscono la strut-tura. Per ognuno di essi, si procede con una ulteriore decomposizione, �no a

11

raggiungere un livello tale da descrivere i componenti primitivi che realizzanole funzionalit�a richieste. Il vantaggio di una tale decomposizione gerarchica,sta nella indipendenza di progettazione dei singoli sottosistemi e nella possi-bilit�a di focalizzare soltanto le informazioni che sono e�ettivamente rilevanti.In questo contesto, giocano un ruolo essenziale i modelli con cui quelle stesseinformazioni possono essere rappresentate.Le motivazioni che hanno condotto a formalizzare la progettazione dei sistemidigitali sono molteplici [Ashe 98]. In primo luogo, per realizzare un sistemadigitale, c'�e bisogno di speci�carne i requisiti, senza ambiguit�a, ma in manieratale da consentire di esplorare diverse alternative di progetto. In secondo luo-go, i modelli formali sono necessari per comunicare all'utente le funzionalit�aed i possibili comportamenti del sistema stesso e, pertanto, rappresentano unvalidissimo strumento di documentazione. Una terza motivazione �e legata allapossibilit�a di fare una veri�ca del progetto attraverso la simulazione. Parten-do dai requisiti del sistema, �e possibile simularne il comportamento con degliopportuni ingressi, confrontando le uscite ottenute con quelle desiderate. Unavolta fatto questo per i singoli componenti, �e poi possibile, integrandoli, andarea veri�care il comportamento complessivo. Successivamente, gli stessi ingressipossono essere impiegati per valutare i primi prototipi �sici. Inoltre, i modellisono l'unico strumento che permette una veri�ca formale della correttezza delsistema, data la necessit�a di una descrizione matematica delle funzionalit�a.In�ne, un'altra motivazione, altrettanto importante, �e quella di poter gestirela sintesi automatica dei circuiti. Speci�cando a livello formale le speci�che, inteoria, queste potranno essere tradotte nelle descrizioni circuitali che andrannoad implementarle. Il vantaggio di questo approccio �e una riduzione dello sfor-zo di progetto, la possibilit�a di esplorare varie alternative, e introdurre menoerrori possibile.In ogni caso, l'elemento uni�cante di queste motivazioni, resta l'esigenza diraggiungere il massimo pro�tto con il minore costo e tempo di progettazione.

2.1.1 Il VHDL

Per descrivere le funzionalit�a di un sistema, senza indicazioni sulla implemen-tazione, sono necessari dei linguaggi di speci�ca [Gajs 94]. Nel 1981, �e statosviluppato, dal Very High Speed Integrated Circuit (VHSIC) Program O�cedel Dipartimento della Difesa Americano, il VHDL (VHSIC Hardware De-scription Language), a�nch�e esistesse un linguaggio standard nella comunit�ascienti�ca, per la descrizione della struttura e funzionalit�a dei circuiti integra-ti. Attraverso una serie di cambiamenti e revisioni da parte di IEEE (Istituteof Electrical and Electronic Engineers), viene adottato come Standard IEEE1076 nel 1987.

12

Il VHDL rappresenta un passo signi�cativo per l'evoluzione dei linguaggi disupporto per il progetto hardware e per l'impiego di una metodologia di pro-getto top-down. �E un linguaggio che contiene una vasta gamma di costruttiche permettono la descrizione di reti a livelli di diversa complessit�a (sistema,board, chip, gate). I costrutti del linguaggio sono classi�cabili in tre livelli diastrazione: comportamentale, data ow (RTL), e strutturale.Nel caso di progetti ASIC �e preferibile quello a livello RT perch�e �e codice chepu�o essere sintetizzato. Questa de�nizione non �e rigorosa perch�e i program-mi di sintesi possono di�erire tra loro per quanto riguarda i tipi di dato ed icostrutti del linguaggio che sostengono.

2.2 Il usso di progetto

Come per un qualsiasi altro prodotto, coinvolgendo pi�u gruppi di persone, ilprocesso di sviluppo di un sistema digitale inizia con una concettualizzazio-ne delle funzionalit�a, per terminare con la realizzazione �sica vera e propria.Possiamo riassumere le varie fasi nel seguente modo:

� Progettazione;

� Fabbricazione delle maschere e dei wafer;

� Testing;

� Packaging.

Restringeremo il nostro interesse alla progettazione: il settore marketing ana-lizza le esigenze di mercato ed i requisiti del prodotto, alcuni tecnici sonocoinvolti nella scelta della tecnologia da utilizzare, dei possibili componenti edeventuali fornitori, mentre altri ancora sono gli addetti alla gestione dei tool.Un gruppo di progettisti in generale �e impegnato nella descrizione di come re-alizzare il dispositivo nella tecnologia prescelta: ci sono coloro che sviluppanoil codice, gli addetti al testing, mentre altri ancora si occupano di de�nire leoperazioni per la realizzazione �sica �nale.Ognuno di questi gruppi pertanto guarda allo sviluppo di un sistema digitaleda un proprio punto di vista, dipendente dal modello che si vuole realizzare.Possiamo classi�care i possibili modelli secondo tre domini di rappresentazione,che di�eriscono l'uno dall'altro per il tipo di informazione trattata e prodotta.Si tratta esattamente dei domini che enfatizzano gli aspetti comportamentali,strutturali e �sici del sistema stesso.Una rappresentazione comportamentale descrive il sistema come una sorta di

13

\black box", caratterizzandone le funzionalit�a e trascurandone i dettagli imple-mentativi; una rappresentazione strutturale, al contrario, ne descrive la compo-sizione in termini di componenti interconnessi tra loro; una rappresentazione�sica ne caratterizza l'implementazione, speci�candone le caratteristiche �si-che, in termini ad esempio di tecnologie e dimensioni.Ognuno di questi domini, a sua volta, pu�o essere suddiviso in pi�u livelli diastrazione o granularit�a, come indicato nella �gura 2.1. Partendo da quellopi�u alto, dove viene presa in considerazione una caratterizzazione molto gene-rale della funzionalit�a, della struttura o della geometria, si scende poi verso ilivelli pi�u bassi introducendo sempre maggiori dettagli [Gajs 94]. Ad esempio,

Standard Cells

Sticks

Floorplan

Polygons

Register-Transfer Language

Differential Equation

Boolean Equation

AlgorithmProcessor-Memory-Switch

Transistor

Gate

Register-Transfer

Geometric

Structural Functional

Figura 2.1: Domini e livelli di astrazione, rappresentati rispettivamente conassi radiali e cerchi concentrici.

consideriamo un microcontrollore, utilizzabile come uno strumento in grado direalizzare delle misurazioni: a livello pi�u alto ne verr�a descritto l'algoritmo inmaniera molto astratta (modello comportamentale), alla pari di un program-ma che, iterativamente, per ogni dato di ingresso, ne legge il valore, realizzauna eventuale conversione e lo invia in uscita. A questo livello la struttura pu�oessere descritta come componenti interconnesse tra loro, quali un processore,una memoria, l'ingresso e l'uscita; la geometria sar�a descritta con un modellodi oorplan. Il livello successivo �e quello RTL: il modello funzionale descrivein questo caso il sistema in termini di unit�a per immagazzinare e trasformarel'informazione, usando variabili di registro ed operatori logici ed aritmetici.Ad esso corrispondono, nel dominio strutturale, data path e control section

14

descrivibili, a loro volta, in quello geometrico, con celle di libreria standard.Il terzo livello di astrazione �e quello logico: in esso la funzionalit�a �e modellatacon equazioni booleane e tabelle di verit�a e la struttura usando porte logicheinterconnesse. Ad un livello ancor pi�u dettagliato, esse saranno in�ne rispet-tivamente descritte con equazioni di�erenziali e transistor. Oggigiorno, vistaanche la complessit�a dei sistemi, i progettisti non hanno bisogno di lavorare adei livelli cos�� dettagliati, essendo a�ancati da tool che automatizzano i varipassaggi a partire da quello pi�u alto. Potremmo dunque dire che la progetta-zione di norma avviene seguendo un approccio \high level", cio�e viene seguitoun metodo di progetto incrementale, di ra�namento successivo dove, partendoda una descrizione ad un elevato grado di astrazione, se ne raggiunge un'al-tra tale da permettere il processo di fabbricazione. L'innalzamento del livellodi astrazione si �e reso necessario per far fronte alla crescente complessit�a diprogetto, permettendo, da un lato, di speci�care e veri�care gli obiettivi diprogetto prima ancora che siano raggiunti livelli di dettaglio implementativitroppo avanzati e diminuendo, dall'altro, il numero di iterazioni.Le varie fasi possono essere cos�� de�nite: concettualizzazione e modellizzazio-ne, sintesi ed ottimizzazione ed in�ne validazione. La prima fase prevede diesprimere le funzionalit�a che il circuito dovr�a realizzare, avvalendosi di model-li concettuali che permettono di decomporle in sottofunzionalit�a pi�u semplici.Gli strumenti sono essenzialmente i linguaggi HDL ma anche formalismi gra-�ci come i diagrammi di usso, schematici o gra� di transizione dello stato(STG).Segue un ciclo di sintesi e ottimizzazione che realizza un ra�namento suc-cessivo del modello �no a raggiungere descrizioni sempre pi�u dettagliate, intermini di tecnologie utilizzate, stile di implementazione, ottenendo un livellodi qualit�a sempre maggiore. In�ne la validazione, con metodi di simulazione everi�ca, �e motivata dalla necessit�a di essere ragionevolmente sicuri della cor-rettezza del modello originale e della consistenza dei modelli sviluppati nellesuccessive fasi di sviluppo. Il usso di progetto di circuiti integrati quindi non�e un semplice usso in cascata, in quanto sono richiesti alcuni cicli di sintesied ottimizzazione per passare da un modello ad un altro pi�u dettagliato. Unastessa operazione viene cio�e ripetuta pi�u volte con la sola di�erenza che cambiail livello di astrazione a cui �e applicata. Pu�o tuttavia avere senso dividere il usso di progetto in tre fasi:

� Progetto Funzionale: vengono indicati a livello sistema e comporta-mentale i requisiti e ci�o che il dispositivo deve fare, cio�e le funzionalit�ache deve realizzare.

� Progetto Archit./Logico: come a livello architetturale e logico ilcircuito implementa l'insieme di funzioni logiche, sopra de�nite.

15

� Mapping Tecnologico: il circuito viene descritto a livello geometrico,come un insieme di entit�a geometriche.

Requisiti di sistema

Specifiche di progetto

Modello comportamentale

Progetto dei componenti

Sintesi logica /VHDL

Simulazione

Layout fisico

Progetto

funzionale

Progetto

archit./logico

Mapping

tecnologico

Figura 2.2: Fasi principali del usso di progetto.

2.3 Il Progetto Funzionale

Per \Progetto Funzionale" si intende l'insieme di tutte le attivit�a che condu-cono alla de�nizione delle speci�che del dispositivo, attraverso un processo dipiani�cazione. Come accade in vari settori di sviluppo, la piani�cazione ha loscopo di de�nire gli obiettivi, le strategie, secondo cui il progetto verr�a con-dotto e sviluppato. Devono cio�e essere de�niti e preparati gli ambienti peril progetto logico e la simulazione e le strategie di test. Ovvero va de�nitol'insieme dei programmi software di Design Automation che dovranno essereimpiegati. Al �ne di comprendere meglio il contesto di lavoro, ne vengono diseguito brevemente descritti i momenti essenziali [Bull 99a].

� Raccolta dei requisiti ASIC . Sebbene i requisiti generali sianodi norma forniti dal cliente, �e tuttavia necessario de�nire, partendo da

16

essi, quelli a livello di progetto/sistema, a livello di scheda e in�ne a livellodispositivo. In particolare, �e importante dare una descrizione di massimadel circuito, una lista delle interfacce con il sistema, una stima di alcuniparametri e l'indicazione di aspetti critici che potrebbero presentarsi nellarealizzazione.

� Analisi di fattibilit�a . Sulla base delle informazioni raccolte alpasso precedente, occorre valutare se il tipo di dispositivo sia realmenterealizzabile con le tecnologie esistenti, quali siano le alternative possibiliper valutarne costi e bene�ci, e quindi fare le scelte pi�u ragionevoli peradottare le risorse �nanziare ed umane necessarie. Sono pertanto utilisia le conoscenze da parte dei gruppi di Progetto e Metodologie sulletecnologie e strumenti esistenti, sia le richieste di informazioni presso ifornitori per veri�carne la disponibilit�a. Questa fase pu�o comportare unaccurato studio del mercato per scegliere, ad esempio, se sia pi�u conve-niente uno sviluppo autonomo piuttosto che l'utilizzo di componenti gi�adisponibili sul mercato, (\Make or Buy"). In particolare vanno presi inconsiderazione:

{ Trade-o� tecnologico. Va valutato prima di tutto quale prodottoscegliere: Gate Array, Cell Based Array, FPGA o Customer De-�ned Array. Inoltre andranno valutati i tempi, le performance, icosti, lo spazio sulla board, la qualit�a e l'a�dabilit�a richieste, i toolsupportati.

{ Scelta del fornitore. Anche per valutare il fornitore devono esse-re considerati una serie di aspetti, tra i quali: la complessit�a delprogetto, l'e�cienza del silicio, costi non ricorrenti, rischi di inven-tario e di progetto, cos�� come i tempi di realizzazione dei prototipio l'ampiezza del portfolio prodotti.

Il risultato �e spesso un documento con una de�nizione preliminare delprogetto, le possibili alternative, costi, tempi e modalit�a di sviluppo diognuna.

� Speci�che tecniche . Noti i requisiti vanno generate le speci�chetecniche. In questo modo �e a disposizione un insieme dettagliato dispeci�che funzionali, di prestazione e di test del dispositivo. Occorrequindi prestare particolare attenzione alla descrizione che dovr�a essereprecisa, esaustiva e non ambigua per guidare il lavoro di sviluppo deiprogettisti, il lavoro di test e di integrazione del dispositivo nel sistemasuperiore. In particolare una speci�ca comprende:

17

obiettivo: de�nizione del documento, indicazione di cosa copre la spe-ci�ca e come va usata.

convenzioni: elenco delle notazioni e acronimi utilizzati.

chip overview: de�nizione dell'architettura e breve descrizione dellefunzioni e caratteristiche dell'ASIC. Comprende un diagramma ablocchi del dispositivo e la descrizione delle interfacce con il restodel sistema.

interfacce esterne: informazioni descrittive sui segnali di interfacciaesterna del dispositivo (funzione, direzione e stato attivo).

descrizione funzionale: descrive le funzioni dell'ASIC, di solito in stilegerarchico. Si ha pertanto una descrizione di ogni modulo e sotto-modulo, inclusi control e data ow, bus e registri interni e i varimodi di funzionamento.

timing: descrive tutti i diagrammi temporali interni ed esterni.

caratteristiche elettriche con indicazione dei parametri che devono opossono essere misurati.

testabilit�a: test di funzionalit�a, test parametrici, test dinamici e onboard.

pin-out e caratteristiche �siche.

� Analisi formale . Al �ne di permettere una stesura delle speci-�che pi�u precisa e favorire, allo stesso tempo, una tecnica di progettopi�u rigorosa, possono venir utilizzati metodi di analisi formale applicatiall'architettura del sistema, chiarendo cos�� ambiguit�a e possibili frain-tendimenti. Essi aumentano la con�denza sulla integrit�a del sistema esulle performance previste, mitigando in parte la limitazione del testingin quanto quest'ultimo non pu�o comunque dimostrare l'assenza di errori,e, allo stesso tempo, costituiscono comunque un ausilio alla generazionedelle sequenze di test per la simulazione. Il processo avviene in tre passi:

{ Modellizzazione del sistema.

{ Esplicazione delle richieste di speci�ca.

{ Veri�ca.

Con l'analisi formale si riesce a provare se il progetto funzionale �e formal-mente corretto e se le richieste di speci�ca sono da esso esaustivamentesoddisfatte.

18

2.4 Il Progetto Architetturale/Logico

Il \Progetto Archit./Logico" segue essenzialmente un approccio top-down epu�o essere interpretato come un processo di ra�namento successivo con il qua-le, partendo da una descrizione di progetto ad un elevato grado di astrazione,viene raggiunta una descrizione che permette al produttore di ASIC l'attivit�a�nale di place & route. Il team di progetto, a fronte delle speci�che di proget-to, esegue il partizionamento della logica da implementare ed inizia la stesuradel codice in linguaggio VHDL, a livello RT. Contemporaneamente, il teamdi metodologie struttura in modo adeguato l'ambiente software, [Bull 99b].Le attivit�a, che contraddistinguono il Progetto Archit./Logico, vanno sotto ilnome di \Front End Design". Questa fase si conclude quando il sistema �esimulato e risulta conforme alle speci�che, privo di qualsiasi errore e testabile.Gli output di questa fase sono infatti: la netlist, che fornisce una descrizionefunzionale del circuito referenziando le macrocelle di libreria e de�nendone leinterconnessioni, i pattern di simulazione e di test, il pinout ed una stima deiritardi.

� Schematic entry e VHDL. Per Schematic entry si intende l'at-tivit�a che porta alla costruzione di un database simulabile. In questa fasebisogna trovare un compromesso tra l'esigenza di una descrizione del cir-cuito, con un dettaglio tale da escludere ogni ambiguit�a e, allo stessotempo, un buon livello di astrazione per garantirne la leggibilit�a. Lespeci�che possono essere tradotte in schemi elettrici, a gate, oppure condescrizioni gra�che: diagrammi di stato o a blocchi, ow chart che cat-turano il comportamento e la parte algoritmica del progetto, macchine astati �niti (macchine di Mealy, di Moore o miste) oppure tabelle di ve-rit�a per speci�carne la logica sequenziale e combinatoria. A fronte dellacomplessit�a dei progetti attuali, �e indispensabile una descrizione gerar-chica con un linguaggio ad alto livello, come Verilog o VHDL. Questoapproccio consente di gestire infatti la complessit�a attraverso una sintesiautomatica ed inoltre permette un facile riadattamento su altre tecnolo-gie.Poich�e �e fondamentale una buona documentazione, il primo passo pu�oessere un diagramma a blocchi astratto che rappresenta segnali tra ussifunzionali, poi decomposto in diagrammi di livello pi�u basso che rap-presentano blocchi o componenti a loro volta riutilizzabili. Ognuno diessi viene ulteriormente decomposto ed il suo comportamento descrittoda un diagramma di stato, una ow chart, una tabella di verit�a o unavista comportamentale HDL. Attualmente, nei progetti ASIC, �e comun-que indispensabile una descrizione dei singoli componenti in codice RTL,

19

essendo per sua natura sintetizzabile. Ci�o signi�ca avere a disposizio-ne una descrizione in cui tutti i registri sono istanziati (come processitemporizzati da segnali di clock) ed una simulazione accurata ciclo perciclo.

� Simulazione funzionale (RTL). L'obiettivo della simulazio-ne �e la veri�ca funzionale del componente ed il rispetto delle speci�chedella descrizione fatta al passo precedente, senza informazioni di timinge prescindendo dalla tecnologia di implementazione. La veri�ca a livelloRTL ha pertanto dei vantaggi indiscutibili: pu�o essere svolta in anticipo,prima di dover fare la sintesi e di dover scegliere il target ASIC ven-dor; il debug �e pi�u facile in quanto �e eseguito ad un livello di astrazionepi�u elevato rispetto al livello gate; le prestazioni sono migliori perch�e lasimulazione RTL �e pi�u veloce. Essa rappresenta il primo passo che per-metter�a poi di veri�care tutto il sistema. In generale �e gerarchica ed �eaccompagnata dalla realizzazione dei Test Bench, cio�e programmi scrittiin VHDL, che hanno lo scopo di emulare l'ambiente in cui il singolo com-ponente funzioner�a. Sono preparati facendo un largo uso di costanti eparametri per facilitare eventuali modi�che, a seguito di variazioni dellespeci�che, ed in prospettiva di una simulazione che preveda le condizionidi timing pi�u sfavorevoli o comunque estreme. Rappresentano gli stimoliapplicati interattivamente alle porte di ingresso per valutare, successi-vamente, i segnali interni ed alle porte di uscita. Gli errori trovati sonoanalizzati e corretti sui modelli sorgente VHDL che costituiscono il riferi-mento principale per il progetto. Occorre notare che se i Test Bench sonoaccurati, allora possono essere riusati, con un opportuno programma ditraslazione, per veri�care possibili inconsistenze con l'implementazione alivello gate. In generale, i blocchi logici RTL, una volta simulati, sono poicollegati tra loro per formare l'intero componente ASIC. Il componente�e poi inserito in un modulo o sotto-sistema, che deve essere a sua voltaveri�cato.

� Sintesi . Dopo una prima e consistente attivit�a di veri�ca, i modelliVHDL dei componenti ASIC sono sintetizzati cio�e ottimizzati, compilatie mappati, utilizzando opportuni parametri, su librerie relative alla tec-nologia target. Con degli speci�ci strumenti software cio�e, la descrizioneRTL viene analizzata ed elaborata per essere poi implementata con unarete logica ridotta ed ottimale, cio�e una netlist di celle logiche dipendentidalla tecnologia messa a disposizione dalla foundry. Il processo di sinte-si, che permette l'attuazione di una metodologia top-down ed un facileriutilizzo di logica gi�a progettata, �e guidato da script �le, in cui si de�-

20

niscono gli attributi di tipo geometrico ed elettrico come le dimensionie la potenza della cella, il modello capacitivo di interconnessione (wireload model) ed i vincoli temporali come periodo di clock, il disallineamen-to temporale massimo dei segnali ed i ritardi di propagazione minimi emassimi. Sono creati per rendere il processo ripetibile e documentatooltre a permettere il lancio di lunghe sessioni di sintesi in batch mode. Ilprocesso di sintesi VHDL ha due fasi:

{ traslazione ed ottimizzazione: a livello RTL la descrizione VHDLviene convertita in una rete booleana, mentre viene ottimizzato ilnumero ed il tipo di blocchi.

{ ottimizzazione logica e mapping: con i vincoli di area e timingavviene una minimizzazione della logica nella rete ed ilmapping conla libreria.

Le ragioni di una sintesi accurata certamente non mancano: la produtti-vit�a aumenta perch�e i progettisti non devono introdurre una descrizionea livello gate; viene garantita una consistenza tra livelli di astrazione; ledescrizioni ad alto livello sono indipendenti dalla tecnologia e sono cos��facilmente adattabili a pi�u target, favorendo il cambiamento di tecnolo-gia e/o fornitore di silicio; il riuso �e facilitato dato che le descrizioni RTLsono pi�u facili da leggere della netlist; inoltre aumenta il livello di qua-lit�a grazie al raggiungimento di una ottimizzazione automatica ed allapossibilit�a di esplorare diverse alternative di progetto.Al termine di questa fase sono disponibili: i report di timing, ottenutidall'analisi statica e che speci�cano i path critici sulla base di una stimadelle capacit�a distribuite sulle linee (o sulla base del loro valore calco-lato dai tool di oorplan o layout) e misure statiche generali (es. celleutilizzate, attributi tecnologici).

� Analisi temporale statica . L'analisi di timing e la sua corre-lazione con gli obiettivi di prestazioni attese vengono ricercate �n dalleprime fasi del processo di sintesi. Se infatti, la stima delle temporizzazio-ni produce dei valori non accettabili, �e necessaria una iterazione, ancheparziale, del processo di sintesi e, nel caso in cui ci�o non sia risolutivo, �enecessaria una rimodellazione del blocco circuitale. Sicuramente l'analisidi timing fornisce un risultato pi�u accurato quando viene rieseguita coninformazioni derivanti dal oorplan, ovvero informazioni pi�u attendibi-li sulla lunghezza delle linee di interconnessione. Il tool �e in grado diseguire ogni percorso all'interno della logica analizzata e di accumulareil ritardo massimo di tutti i gate ai di�erenti livelli, che concorrono a

21

formarlo. Viene impiegato per realizzare sia un'analisi globale sia par-ziale del progetto. In quest'ultimo caso, tutti i percorsi che eccedonol'obiettivo de�nito, sono valutati in una singola esecuzione, richiedendocomunque un processo lento soprattutto nel caso di progetti complessi.In questo caso non tutti i dati sono direttamente utilizzabili, in quantodei percorsi multiciclo possono nascondere dei reali percorsi critici che de-vono essere preventivamente rimossi. Con l'analisi parziale, sono invecevalutati soltanto dei percorsi speci�ci che, partono da speci�ci ingressie attraversano determinate porte logiche �no a delle uscite, anch'esseprede�nite, per un controllo mirato e pi�u rapido.

� Veri�ca del sistema . L'obiettivo della veri�ca logica �e di fornireuna elevata con�denza sul progetto logico nel rispetto delle speci�chefunzionali, prima che avvenga l'implementazione �sica delle varie partidel sistema (ASIC e Board). L'intera metodologia di progetto �e strut-turata in modo tale da focalizzarne i problemi chiave e renderla il pi�uveloce e semplice possibile. Per raggiungere questi obiettivi, l'attivit�a diveri�ca �e realizzata a diversi livelli di complessit�a durante il processo diprogettazione ed �e, in termini di tempo, una delle pi�u onerose da ese-guire. Il codice che deve essere sviluppato �e uno a uno con quello per ilprogetto �nale. Allo stesso tempo per�o, �e anche una delle attivit�a pi�uimportanti: �e infatti impensabile progettare un componente ASIC senzainserirlo all'interno del sistema e simulare l'ambiente nel quale dovr�a es-sere collocato, cio�e gli altri componenti e le interfacce del sistema.Durante la fase di progettazione ciascun blocco di logica di una certadimensione, descritto in VHDL, �e stato testato dal progettista per lesue funzionalit�a di base (Block Veri�cation). Nella fase di simulazionefunzionale, ciascun ASIC �e poi veri�cato indipendentemente con l'ausi-lio dei Test Bench, (Single Chip Veri�cation), per la valutazione dellefunzionalit�a elementari. A questo punto andranno a�rontate, con un ap-proccio incrementale, problematiche diverse ed a complessit�a crescente,sviluppando degli ambienti con cui estendere il grado di copertura deltest, attraverso una veri�ca logica, gestita con simulazione software, sudue possibili livelli (SIM1, SIM2).

{ Primo livello di simulazione del sistema (SIM1). In questafase le funzionalit�a delle diverse parti logiche sviluppate, non sonopi�u veri�cate singolarmente, ma vengono integrate tra loro in unambiente pi�u esteso. L'obiettivo �e quello di raggiungere un ragio-nevole livello di copertura dell'intero set di interazioni sul bus tra imicroprocessori, le memorie, l'input e l'output. Gli elementi sepa-

22

ratori a questo livello sono modelli comportamentale di interfaccia,chiamati bus model, in grado di gestire le operazioni e le transazionia livello bus, senza che vengano e�ettuate delle reali operazioni diCPU. In questo modo viene veri�cata una con�gurazione di sistemacontenente uno o pi�u ASIC tramite dei tool in grado di registrare su�le il tra�co osservato sui bus. La correttezza funzionale delle ope-razioni viene poi veri�cata da opportuni programmi post-processingcon cui si valuta se i risultati sono congruenti a quanto descrittonelle speci�che. I test sono di norma organizzati in tre parti:

� Test dedicati per veri�care le funzioni base del sottosistema;

� Test strutturati per veri�care il sistema valutando il compor-tamento di ogni modulo (funzioni normali, casi al contorno,condizioni di collisione);

� Test Pseudo Random per veri�care combinazioni delle funzio-nalit�a di base, variando la con�gurazione del sistema ed i modioperativi.

I test sono eseguiti in sequenza, partendo da quelli pi�u semplici; nonappena viene individuato un errore, viene noti�cato ai progettistiche provvedono alle opportune modi�che direttamente sul codiceVHDL.

{ Secondo livello di simulazione del sistema (SIM2). Questafase di simulazione �e la pi�u completa. Tutti i modelli funzionalicontenuti nel sistema sono collegati tra loro, eliminando i modellibus di interfaccia. Impiegano dei modelli full functional, rendendo lasimulazione del sistema estremamente e�cace. Con tale obiettivo,essi sono cos�� suddivisi:

� Test Deterministici permettono la veri�ca dei meccanismi fon-damentali ed aspetti del progetto pi�u di�cilmente manipolabili.

� Test in ambiente monoprocessor veri�cano le operazioni ese-guite in una singola CPU, considerata indipendentemente dallealtre o dagli altri moduli.

� Test in ambiente multiprocessor veri�cano le operazioni esegui-te da due o pi�u CPU all'interno di uno speci�co modulo delsistema.

Viene inoltre adottato uno speci�co ambiente di co-simulazione conil quale poter interfacciare anche modelli scritti in linguaggi diversi(DSL, VHDL, C) e simulatori di�erenti.

23

2.5 Mapping Tecnologico

Le netlist prodotte dal processo di sintesi sono utilizzate nell'ambiente CADproprio del fornitore di silicio, o comunque interfacciato con esso. I vetto-ri logici, de�niti durante la simulazione funzionale, possono essere impiegatiper veri�care il progetto a livello gate dopo una opportuna trasformazione diformato.

� Floorplan . Con programmi software adeguati, i progettisti possonosperimentare diverse strutture di oorplan per il componente in sviluppo,per avere una stima pi�u accurata delle performance e della routability.�E l'anello di congiunzione tra il Front End ed il Back End. Sull'areadi silicio le varie unit�a funzionali appaiono come rettangoli e viene datauna prima indicazione di massima delle zone dedicate alle connessioni.Il oorplan consente quindi la de�nizione di gruppi di celle e del loropiazzamento, una ottimizzazione della sintesi. Questa fase pu�o essererealizzata molto \in alto" nel usso di progetto. Ci�o dipende dal fattoche, con l'avvento delle nuove tecnologie submicron, i ritardi dovuti alleinterconnessioni superano il 50% del ritardo complessivo di una cella ed �equindi importante stimare accuratamente la lunghezza delle connessionitra i blocchi stessi, per evitare interventi successivi e in generale troppeiterazioni del progetto prima di arrivare ad una mappatura ottimale.

� Inserzione di elementi per la testabilit�a . L'inserimentodelle cosiddette \catene di scan" prevede delle trasformazioni sul circuitoper generare poi i test in modo pi�u semplice. Si aggiunge cio�e logica perassegnare, in fase di test, valori noti a parti non direttamente raggiun-gibili dagli ingressi. Creando delle particolari connessioni tra registri,realizzandone alcuni molto lunghi (catene di scan), gli e�etti di eventua-li guasti del dispositivo possono essere propagati alle uscite, rendendolicos�� osservabili.

� Testabilit�a . I vettori di simulazione sono i pattern di test generatida ATPG (Automatic Test Pattern Generation) ed una serie di patterndi test funzionali derivati dalla simulazione del sistema. Questi servi-ranno per l'attivazione dei test funzionali e parametrici sui componenti�sici, per rilevarne gli eventuali guasti �sici post produzione. �E impor-tante una veri�ca della conformit�a del circuito alle regole del generatoreautomatico dei vettori di test. Inoltre i vettori di test possono esserecreati sotto alcune ipotesi restrittive che variano fortemente con il tipodi circuito; a tale proposito esistono dei programmi in commercio, (rulechecker), in grado di valutare la conformit�a del progetto ad alcune regole

24

di collaudabilit�a �n dalla fase di speci�ca del VHDL. Si determina inoltrese il pattern di test esercita interamente il circuito, cio�e se ogni nodo delcircuito cambia stato (Toggle checker), e si veri�ca il livello di copertura(Fault grading). In generale si ritiene accettabile un livello di coperturadal 95% al 98%.

Ha inizio ora il "Back End Design", ovvero l'insieme dei processi che trasfor-mano la netlist ed il database associato, in una rappresentazione del dispositivo�sico, ne veri�cano la consistenza con la netlist logica e la realizzazione.

� Review del progetto . Il processo di revisione con il fornitore com-prende generalmente: la veri�ca del circuito, l'identi�cazione delle lineesovraccaricate, la revisione dei ritardi e le problematiche di routability ;la revisione dei risultati delle simulazioni, la veri�ca funzionale, i vincolidi timing e la veri�ca del pinout.

� Emulazione e Mappatura . L'emulazione hardware �e una tec-nica di veri�ca che permette di mappare della logica in hardware riu-tilizzabile, per fornire una prima rappresentazione �sica del progetto.L'attivit�a di mappatura si svolge a partire dalla netlist, eseguendo unpartizionamento della logica ed utilizzando i tool di place & routing delsistema di emulazione oppure direttamente dei componenti programma-bili (PLD, FPGA). Al termine dei processi di compilazione, mappatura epartizionamento, che portano ad avere una \copia" hardware della netlistiniziale, si esegue un test opportuno con cui veri�care se la funzionalit�adel circuito HW �e congruente a quella della netlist iniziale. Se il confronto�e corretto si passa alla fase vera e propria di prototipazione.

� Place & Route . Il layout �sico �e normalmente realizzato dal forni-tore. In questa fase viene e�ettuato il piazzamento in base al oorplan-ning, si calcolano accuratamente le lunghezze delle interconnessioni realitra elementi logici, vengono connessi i pad di ingresso e uscita dell'interochip e viene fatta la sintesi del clock tree. Ovviamente il risultato �nalesar�a ottenuto mediante una serie di iterazioni. Questo processo ha deigrossi vantaggi, specialmente se il circuito da emulare non �e estremamen-te complesso (in termini di numero di interconnessioni) e non necessitadi continui aggiornamenti. La disponibilit�a di un prototipo di sistema suun ambiente hardware e software reale permette infatti di rinforzare laveri�ca.

� Back Annotation e Simulazione post layout . Al ter-mine del layout il progettista riceve un database per il processo di back-annotation che permetter�a di mettere a punto le interfacce, evidenziare

25

le criticit�a del usso e veri�care la validit�a delle strategie adottate. Do-vranno essere rieseguite le simulazioni, oltre ad un'ulteriore analisi deitempi, sulla base delle informazioni sulla lunghezza reale delle connes-sioni. In particolare vengono rie�ettuate le simulazioni funzionali e deipattern di test, almeno nei casi best e worst.

� I.P.O. ed E.C.O. Non sempre con il primo layout si ottengono leprestazioni richieste, tipicamente possono insorgere violazioni di timing odi overload. Nelle fasi di ottimizzazione, I.P.O. (In Place Optimization)ed E.C.O. (Engineering Change Order), si e�ettuano una serie di tra-sformazioni automatiche su regioni circoscritte del layout. Da un puntodi vista logico, pu�o essere necessaria una sostituzione di una cella conuna pi�u potente o la ricomposizione di una parte del circuito, oppure,da un punto di vista �sico, le modi�che si possono tradurre o in unaoperazione \taglia e cuci" sul layout o addirittura su un nuovo layout.Sicuramente quest'ultima soluzione �e da evitare perch�e dovrebbe richie-dere una revisione di tutte le fasi precedenti, mentre la prima richiededi ridurre comunque al minimo le modi�che apportate alla netlist. Inquesto modo vengono analizzate le di�erenze e si procede con i tool adun re-place e re-route delle parti modi�cate.

� Sign-o� �nale . Con l'approvazione dei dati relativi alla simulazionepost-layout, il fornitore di silicio potr�a generare le maschere e costruire iprototipi, formalmente noti come Engineering Samples (ES ).

26

Raccolta dei requisiti

Analisi di fattibilitá

Scelta del fornitore

Trade off tecnologico

Specifiche tecnicheAnalisi formale

Progetto ad alto livello

partizionamento del sistema

Scrittura del codice VHDL

Schematic Entry

Simulazione di moduli/sistema

Sintesi logica ed ottimizzazione

Analisi temporale

Floorplan

Pianificazione del test

Generazione dei casi di test

Place & RouteMappatura

Verifica Sviluppo del testATPG/SCAN

Backannotation

Figura 2.3: Flusso di progetto.

27

Capitolo 3

La gestione del progetto

Il termine \gestione di progetto", (Project management), �e usato per indicareun approccio organizzativo alla gestione delle varie fasi, attraverso l'applicazio-ne di conoscenze, informazioni storiche, tecniche e tool alle attivit�a del progettoin modo da soddisfare tutte le esigenze di coloro che ne sono coinvolti. Tale ge-stione impone di trovare un giusto equilibrio tra pi�u aspetti: obiettivi, tempi,costi, qualit�a, requisiti pi�u o meno de�niti, (needs & expectations), e individuie/o gruppi coinvolti (stakeholders). La gestione del progetto �e suddivisibilein pi�u aree ognuna delle quali �e composta da processi [Dunc 96]. L'area diRisk Management si occupa della gestione dei rischi legati allo sviluppo, conopportune tecniche e metodologie che vengono impiegate gi�a nelle prime fasi.Va infatti tenuta presente la possibilit�a che si possano veri�care delle condi-zioni o eventi che non sono stati anticipati e che impediscono di raggiungeregli obiettivi pre�ssati. Se le cause non possono essere totalmente eliminate, �econveniente e necessario riuscire a controllarle.

3.1 La gestione dei rischi

La gestione dei rischi rappresenta un'attivit�a interna, ed allo stesso tempocentrale, alla gestione del progetto (Project Management) [Simm 98].Un'unica de�nizione di rischio non esiste. Con tale termine infatti, ci si pu�oriferire alla possibilit�a di una perdita, alla perdita e�ettiva che risulterebbenel caso in cui si manifestasse il rischio, ad un fattore associato ad un threat,ad una circostanza che contribuisce alla possibilit�a di una perdita. Il rischio

29

dunque, �e un elemento intrinseco del progetto e nel suo signi�cato generale, �eappunto de�nito come:

a possibility of loss, the loss itself, or any characteristic, object oraction that is associated with that possibility.

Pertanto, per rischio si intende ogni fattore, legato alle attivit�a ed alle risor-se, non direttamente controllabile, non completamente prevedibile ma con unimpatto rilevante sugli obiettivi e con la possibilit�a di perdita. In ogni caso,la probabilit�a e la perdita sono i due principali attributi che vengono presi inconsiderazione.Gli approcci alla gestione del rischio sono molti. Sicuramente aspettare chesorgano i problemi per reagire pu�o essere fallimentare, poich�e introdurre corre-zioni in fasi avanzate del progetto �e costoso. Al contrario, �e preferibile interve-nire in anticipo, sebbene prevenire i rischi, o addirittura eliminarli, prima dellosviluppo di un progetto, possa richiedere tempo ed abbia comunque un costo.�E dunque possibile reagire ai rischi dopo che si sono manifestati (correzionedegli errori) e fornire risorse per mitigarli nel caso dovessero concretizzarsi(compensazione dei rischi), ma soprattutto sono necessarie sia la prevenzionesia l'eliminazione delle cause alla radice. Queste due ultimi approcci rientranonel metodo per la gestione dei rischi che include tutti quei processi rivolti al-l'analisi, alle risposte ai rischi ed al loro controllo nel ciclo di sviluppo. Questeattivit�a, a loro volta, non sono a�atto indipendenti l'una dall'altra, si evolvonodurante tutte le varie fasi del usso di progetto e sono dirette alle principaliaree di rischio nello sviluppo di un sistema digitale: il software, l'hardware, latecnologia impiegata, i costi, i tempi ed le risorse. La gestione del rischio pi�uin dettaglio coinvolge:

� Identi�cazione. Consiste nella determinazione di quali rischi siano as-sociabili al progetto e nel fornire una documentazione sulle caratteristichedi ognuno. Alla base di questo approccio c'�e il principio della anticipazio-ne dei vincoli e delle opportunit�a legate al progetto. I rischi infatti posso-no essere interpretati come i vincoli e le opportunit�a a�ette da incertezza,di cui non �e possibile prevedere in prima istanza il comportamento.

� Quanti�cazione. Consiste nella valutazione dei rischi e delle loro pos-sibili iterazioni. In particolare andranno prese in considerazione la pro-babilit�a di accadimento e gli e�etti attesi sugli obiettivi speci�ci (tempi,costi e qualit�a).

� Strategia. Prevede la de�nizione delle possibili scelte in fase progettualeper contrastare i rischi attraverso una serie di interventi correttivi.

30

� Monitoraggio. Rappresenta l'analisi dei cambiamenti ed evoluzionedegli eventi di rischio nel corso dello sviluppo del progetto, con unaconseguente revisione di quanto fatto ai passi precedenti.

Risk

Management

infrastructure

Risk

Analysis

Risk

Control

Risk

Control

Planning

of risk

Changed state

Prioritized risk

scenarios

Expected results,

projected data

Risk monitoring

metrics

Risk

Monitoring

Risk MgmtMandateDefinition

Revision to

stakeholdersProject

authorization

Changes in situation

Problem indicators,

List of "raw"

results

goals, new goals

Revisions to

actionsSelected

Stakeholder’s

expectations

Methods, tools,

guidelines Changes in

situation

Risk

management

mandate

Risk

Identifica-

tion

Goal Review

Goals definitions

Figura 3.1: Risk Management.

3.2 Identi�cazione e quanti�cazione dei rischi

L'identi�cazione dei rischi consiste nel determinare quali siano i rischi che pi�uverosimilmente possono riguardare il progetto e nel documentarne al meglio lecaratteristiche [Dunc 96].Tutto questo ha il �ne ultimo di produrre delle informazioni che siano gliingressi per le successive attivit�a, interpretabili sia come vincoli sia come daticerti (costraints & assumptions). I possibili rischi sono classi�cabili in generalein due categorie: i rischi legati al prodotto e quelli dipendenti dalla gestione.I primi sono quelli con un impatto pi�u diretto sui costi e sui tempi:

� Variabilit�a dei requisiti.

� Il grado di innovazioni tecniche e tecnologiche.

31

� Un'analisi non troppo esauriente delle speci�che e delle caratteristiche dimercato.

� Errori di progetto, omissioni.

� L'integrazione con altri progetti.

� Le performance attese rispetto agli standard.

Al secondo gruppo appartengono:

� Una stima non adeguata della attivit�a di sviluppo.

� Una stima in eccesso delle competenze.

� Le conoscenze del gruppo di progetto.

� Risorse insu�cienti.

� Ruoli e responsabilit�a non ben de�nite.

I rischi possono inoltre essere suddivisi in interni ed esterni. I primi sono quelliche il gruppo di sviluppo pu�o comunque controllare o in uenzare, ad esempiocambiamenti troppo rapidi nei requisiti espressi dal cliente, l'assegnamentodelle risorse o la stima dei costi; quelli esterni invece non sono altrettantocontrollabili, come nel caso di cambiamenti a livello legislativo o fattori diret-tamente legati al mercato.Per identi�care i rischi va quindi prima di tutto considerata la speci�ca, tenen-do conto della tipologia e dei requisiti del progetto. Prodotti che coinvolgonotecnologie gi�a note e sicuramente disponibili, hanno meno rischi di quelli cherichiedono comunque delle innovazioni.Nella loro identi�cazione, sono altrettanto importanti sia le stime e�ettuate inaltre aree sia le informazioni storiche. Nel primo caso potrebbero essere fontidi rischio stime dei costi e dei tempi e�ettuate troppo velocemente in manieranon accurata oppure la scelta delle risorse con conoscenze troppo speci�che equindi di�cilmente sostituibili. Nel secondo caso sono sorgenti di informazionile conoscenze del gruppo di progetto acquisite nel corso degli anni, i databasecommerciali, l'evoluzione di progetti a�ni. In base a questi dati, l'obiettivo diquesta fase �e indicare le principali sorgenti di rischio, cio�e quelle categorie dieventi che possono incidere negativamente sullo sviluppo, e di esse dare unastima di alcune caratteristiche, avvalendosi di stime sia con funzioni continuesia mediante valori discreti. In generale la descrizione riguarda pi�u direttamen-te la probabilit�a che si possa veri�care e la perdita che ne deriva, ma hanno unruolo essenziale anche la frequenza, nel caso in cui possano ripetersi pi�u volte, e

32

di conseguenza i tempi, entro cui si potrebbero manifestare. Ha inoltre impor-tanza stimare i possibili sintomi (trigger). Ad esempio, uno scarso entusiasmoda parte dei progettisti potrebbe essere sintomo di ritardo o overrun dei costi.

La quanti�cazione dei rischi coinvolge la valutazione ed un'analisi delle possibi-li interazioni degli eventi di rischio per poi adottare le opportune strategie. Inbase alle informazioni, per ogni sorgente di rischio, cio�e l'evento che potrebbeincidere negativamente sullo sviluppo, dovr�a essere fatta una stima di alcunecaratteristiche tra le quali la probabilit�a, la perdita e la frequenza.Una possibile tecnica per la gestione dei rischi, prevede di quanti�carne lapriorit�a attraverso la stima delle seguenti caratteristiche:

O =Occurrence;S = Severity;D =Detectability.

Nelle tabelle 3.1, 3.2 e 3.3, �e utilizzata una scala da 1 a 10, ed in funzione diessa, viene calcolata la priorit�a di rischio (Risk Priority Number, RPN), comesegue:

RPN = O � S �D (3.1)

Essa pu�o variare da 1 a 1000 con il seguente signi�cato:

Da 301 a 1000 Rischio critico.Da 101 a 300 Rischio alto.Da 51 a 100 Rischio medio.Da 1 a 50 Rischio basso.

I valori assoluti dei punteggi non sono rilevanti di per s�e. �E importante com-prendere quali siano quelli su cui sia importante focalizzare maggiormentel'attenzione e quelli su cui vale la pena non intervenire in anticipo, data unaminore probabilit�a di accadimento o la non gravit�a degli e�etti.Come �e stato osservato, il rischio �e un concetto relativo del quale possono esserecaratterizzati molti aspetti. Una valutazione come questa permette di identi-�care i rischi maggiori e proporre poi delle azioni per il controllo, anche senzaun valore esatto della probabilit�a e della perdita che, peraltro sarebbe di�ciledare. Molti approcci di gestione dei rischi prevedono di associare la perditaad uno speci�co attributo del progetto come il costo, il ritardo di immissionesul mercato oppure metriche di qualit�a che tengono conto dei requisiti che ilsistema deve soddisfare. Avvalendosi della notazione UML, �e possibile de�niremeglio i di�erenti aspetti del rischio nel \Risk Analysis Graph", sviluppatoda Rowe, [Kont 94], e di cui ne viene presentata un'estensione in �gura 3.2,[Kont 98].

33

Criteri Occurrence Probability

Remota probabilit�a di occorrenza. 12

Bassa probabilit�a di occorrenza. 3Processo sotto controllo. 4

5Moderata probabilit�a di occorrenza.Legame con processi che hanno registrato 6gi�a dei fallimenti in passato.Processo non completamente sotto controllo.Alta probabilit�a di occorrenza.Legame con processi che hanno registrato 7frequentemente dei fallimenti in passato. 8Processo non sotto controllo.Probabilit�a di occorrenza molto alta. 9Certezza di almeno un fallimento. 10

Tabella 3.1: Criteri e valori di Occurrence.

Criteri Severity

Non in uenza performance di prodotto e/o servizi 1Degrado estremamente limitato delle performance di prodotto 2e/o dei servizi (non percepibile dal cliente)Degrado limitato delle performance di prodotto 3e/o dei servizi (percepibile dal cliente ma accettabile)Degrado rilevante delle performance di prodotto 4e/o dei servizi (percepibile dal cliente e 5richiede interventi di correzione) 6Degrado alto delle performance di prodotto 7e/o dei servizi (di�colt�a di impiego) 8Prodotto inutilizzabile 9, 10

Tabella 3.2: Criteri e valori di Severity.

Vista concettuale del \Risk analysis graph"

Un \risk factor" �e un fattore che in uenza la probabilit�a di occorrenza di unevento di rischio (risk event). In quanto tale, esso descrive delle caratteristichedell'ambiente, senza avere associata alcuna probabilit�a.

34

Criteri Detectability

Sicuramente individuabile poich�e 1il problema o errore �e ovvio 2Il problema �e estremamente evidente 3e pu�o essere individuato facilmente 4

5Il problema/errore �e facilmente individuabile 6con uno speci�co controllo 7

8Il problema/errore �e di�cilmente individuabile 9nonostante uno speci�co controllo�E estremamente di�cile individuare il 10problema ed �e impossibile eseguire dei controllo

Tabella 3.3: Criteri e valori di Detectability.

EventRisk Risk

OutcomeFactorRisk

influences

probability of

influences the

probability of

RiskEffect set

UtilityLoss

valued

through

Reaction*1 1..* 1 1..* 1..*

* *

changes status of

changes status of

influences probability of

* * * *

1 1..*

prompts result in

results in

1

1

Figura 3.2: Vista concettuale degli elementi della analisi dei rischi.

I fattori di rischio segnalati sono quelli che aumentano la probabilit�a che unevento accada, ma potrebbero essere presi in considerazione anche i \successfactors" per il progetto, come lo sviluppo di progetti analoghi. L'obiettivonon �e di individuarli tutti, ma documentare quelli principali dell'ambiente di

35

sviluppo, e specialmente quelli che si allontanano dai requisiti interpretabilicome \normali".Un \risk event" rappresenta un condizione associabile a circostanze sfavore-voli. Si tratta di un fenomeno stocastico. All'incertezza che lo caratterizza �eassociabile una probabilit�a. Ciascun evento di rischio pu�o essere in uenzatoda pi�u fattori e pu�o a sua volta in uenzare le probabilit�a di altri eventi.Un \risk outcome" rappresenta la situazione nella quale si trova lo sviluppo diun progetto quando �e accaduto un evento di rischio ma non sono state ancoraintraprese delle azioni correttive. In questo modo vengono documentate le con-dizioni immediatamente successive all'evento e sulla base della loro descrizione�e pi�u semplice considerare le possibili risposte, pi�u obiettivamente di quantonon accadrebbe se ci si basasse direttamente sull'evento.Una \risk reaction" descrive una possibile azione per ridurre l'impatto dell'e-vento di rischio. La reazione pu�o essere unica, ed allora dovr�a essere l'unicapossibile, oppure possono esistere delle alternative. In ogni caso le reazionipossono in uenzare la probabilit�a degli eventi di rischio.Il \risk e�ect set" rappresenta l'impatto �nale dell'evento sul progetto, cio�e do-cumenta quali caratteristiche o requisiti sono pi�u o meno compromessi, tenendoanche conto delle reazioni. Gli e�etti sono espressi esplicitamente attraversogli obiettivi disattesi.Mentre l'e�etto rappresenta l'impatto che un rischio ha avuto su un obiettivo,il concetto di \utility loss" cattura la severit�a dell'impatto stesso. Basandosisulla teoria dell'Utilit�a, [Carr 93], considerando contemporaneamente pi�u cri-teri di stima seguiti da di�erenti stakeholders. In tabella 3.4 ne sono riportatialcuni esempi per ogni classe.

3.3 Strategia e piani�cazione

Una volta quanti�cati e confrontati i rischi per comprenderne meglio la na-tura, vanno sviluppate le possibili soluzioni, tenendo conto delle principaliripercussioni quali, ad esempio, il pagamento di penalit�a, una minor qualit�adel prodotto e soprattutto un'eventuale perdita economica. Le possibili scelteper gestirli e/o ridurli sono cos�� classi�cabili:

� Avoidance - �e possibile intervenire tempestivamente eliminando la pos-sibile causa. Ad esempio, pu�o essere necessario evitare le soluzioni pi�urischiose o rivolgersi a fornitori a�dabili.

� Mitigation - riduzione della perdita economica.

36

Elemento di rischio Esempi nello sviluppo

Inesperienza del personaleRisk Factor Impiego di nuove metodologie

Impiego di nuovi toolRequisiti instabiliAssenza di una persona chiave

Risk Event Tempo richiesto per apprendere nuovi metodiCambia un requisito importanteScarsit�a di competenze

Risk Outcome Richiesta di nuove attivit�aTempi non rispettatiRevisione di quanto �e stato fatto

Risk Reaction Ristrutturazione dell'organigrammaCosti aggiuntivi

Risk E�ect Ritardo nell'entrata su mercatoMancato rispetto dei requisitiDanno all'immagine dell'azienda

Utility Loss Insoddisfazione degli stakeholder

Tabella 3.4: Esempi degli elementi del rischio.

� Acceptance - accettare le inevitabili conseguenze, soprattutto in terminidi una riduzione del pro�tto, o al pi�u rispondere con la de�nizione dei\Contingency Plan".

Per la riduzione degli e�etti del rischio potrebbe ad esempio essere utile: tra-sferire il rischio su aree non rilevanti, o comunque meno critiche; irrobustireil sistema ed elevare la capacit�a di reazione. Si tratta cio�e di isolare il rischiotramite soluzioni modulari, assegnare risorse ridondanti o migliori alle aree pi�ucritiche e, soprattutto per rischi critici, de�nire in anticipo i piani di contingen-za, cio�e le soluzioni alternative che dovranno essere costantemente controllateed aggiornate. Si tratta, ad esempio, di de�nire le possibili modi�che da ap-portare a quanto piani�cato in precedenza nella gestione dei tempi (ProjectScheduling) per le varie fasi del usso di progetto nel caso in cui accada unevento di rischio. Ci�o signi�ca gestire le varie attivit�a, la loro durata, identi-�cando attivit�a parallele o possibili sequenze critiche (path). Questa attivit�asegue ovviamente l'intero ciclo di sviluppo dell'applicazione. Il controllo deirischi in�ne �e l'attivit�a con cui si tenta di monitorare l'evoluzione dei potenzialirischi, soprattutto quelli critici, durante il ciclo di sviluppo. Ogniqualvolta siveri�ca un cambiamento, i passi de�niti precedentemente vanno ripetuti. Ci�o

37

Analisi del rischio

Esistono azioni

preventive?

Identificare la data

per la preparazione

del Contingency Plan

e per la valutazione

dell’impatto del rischio

Verificato

l’impatto?

Project Planning

Mantenimento del

Piano di gestione

del rischio

nosi

siContingency Plan

no

Figura 3.3: Processo di gestione del \Contingency Plan"

dipende dal fatto che quasi sempre non si riesce all'inizio a valutare tutti ipossibili rischi e, tantomeno, ad attribuire loro la corretta probabilit�a che siveri�chino. Al contrario, sono pi�u spesso, necessarie delle iterazioni.Pertanto, se un evento non �e stato anticipato o se il suo e�etto �e peggiore diquanto si credesse, il piano realizzato potrebbe rivelarsi inadeguato, richieden-do cos�� un'ulteriore elaborazione di una risposta e talvolta una revisione dellaquanti�cazione fatta in precedenza. In generale, i possibili comportamenti sonorappresentati da azioni correttive, ad esempio con nuovi piani di contingenza,oppure con degli aggiornamenti sulla gestione complessiva dei rischi.

3.4 La gestione dei tempi

La piani�cazione dei tempi di sviluppo di un progetto si basa su quattro fasiprincipali: la de�nizione delle attivit�a, delle relazioni e dei vincoli temporaliche intercorrono tra le stesse, la stima della durata, lo sviluppo ed il controllodello scheduling.

38

De�nizione delle attivit�a

Il processo di de�nizione delle attivit�a che costituiscono il usso di progettoconsiste nella loro identi�cazione e documentazione. Per fare questo �e neces-sario tenere in considerazione la \work breakdown structure", gli obiettivi delprogetto, le informazioni storiche su progetti equivalenti, vincoli ed eventualifattori che si possono assumere come informazioni certe. Le principali tecnicheche vengono impiegate sono la decomposizione e il template. La prima gestiscele attivit�a suddividendole in sottocomponenti che possano essere gestite pi�ufacilmente, e la seconda consiste nell'adattare e impiegare quanto fatto in unprogetto precedente, appunto come template per quello in corso. Lo scopo inentrambe �e di de�nire una lista di attivit�a che includa una propria documen-tazione, soprattutto sui vincoli e le ipotesi, ed eventualmente, di aggiornarela piani�cazione iniziale, ad esempio con chiarimenti, correzioni o aggiunta diparti tralasciate.

Relazioni temporali tra le attivit�a

Una volta de�nite le attivit�a, vanno stabilite le relazioni temporali. In partico-lare va de�nito l'ordine con cui esse devono essere realizzate ai �ni di supportareuno scheduling, quanto pi�u possibile vicino alla realt�a dei fatti.A tale proposito vanno tenute presenti le possibili dipendenze: quelle legatealla natura del progetto (mandatory dependancies o hard logic), quelle de�nitedal project manager (discretionary dependancies o soft logic) e quelle ester-ne (external dependancies). Un possibile metodo (Precedence diagrammingmethod, PDM) segue un approccio gra�co con cui indicare la durata, la se-quenza temporale ed eventuali con itti. Sono quattro le possibili relazioni trale attivit�a:

� Finish to Start (FS): l'attivit�a, (P ), deve �nire prima che l'altra, (N),possa iniziare.

� Finish to Finish (FF): l'attivit�a, (P ), deve �nire prima che l'attivit�a,(N), possa terminare.

� Start to Start (SS): l'attivit�a, (P ), deve iniziare prima che possa iniziarel'altra, (N).

� Start to Finish (SF): l'attivit�a, (P ), deve iniziare prima che l'altra possaterminare.

Il \lag time" �e il ritardo temporale o l'anticipo dell'inizio o della �ne dell'atti-vit�a, rispetto ai vincoli imposti di quelle che la precedono.

39

Attivitá P

Attivitá N

Attivitá P

Attivitá N

Figura 3.4: Relazioni FS e FF .

Attivitá P

Attivitá N

Attivitá P

Attivitá N

Figura 3.5: Relazioni SS e SF .

Attivitá N

Attivitá P

Lag

Figura 3.6: \Lag time" tra due attivit�a.

Stima della durata delle singole attivit�a

Bisogna poi stimare il periodo lavorativo entro il quale ogni attivit�a possa esse-re completata. Ovviamente va identi�cata adeguatamente la scala temporaledel progetto, tenendo presenti eventuali ipotesi e vincoli iniziali, le informazio-ni storiche ed i requisiti e le capacit�a delle risorse. Ad esempio due persone chelavorano insieme dovrebbero impiegare la met�a del tempo che impiegherebbe-ro se lavorassero ognuna singolarmente, oppure si pu�o supporre che una stessaattivit�a venga svolta in minor tempo da una persona con pi�u esperienza. Latabella 3.5 ne d�a un esempio.

Lo scheduling delle attivit�a

Il primo passo dello scheduling consiste nel de�nire le \Milestone" del proget-to, ovvero gli eventi rilevanti nel ciclo di sviluppo del progetto, che devonoessere de�niti per segnalare il raggiungimento di importanti obiettivi e meglio

40

Tabella delle attivit�a

Attivit�a Durata Precedente Relazione Lag timea) alph 3 - - -b) beta 4 a FS -c) gamma 3 b FF 1d) delta 2 c FS -1e) eta 5 d FS -f) phi 2 d, e FS -

Tabella 3.5: Tabella della attivit�a.

comprendere come si evolvono le varie attivit�a. La loro de�nizione prevedealcune linee guida: devono essere facilmente comprensibili ad ogni livello orga-nizzativo, la loro successione deve rispettare alcuni vincoli logici, deve esserechiaro il legame con le decisioni che sono state prese alla loro base.Le tipologie di strumenti che permettono di rappresentare i tempi di un pro-getto sono il diagramma Gnatt e le tecniche reticolari.

� Il diagramma Gnatt. Si tratta di un diagramma a barre che d�a unavisione rapida del piano temporale del progetto, in cui sono indicati ladurata delle attivit�a, con linee, e la loro sequenza temporale. Ovviamentela durata delle singole attivit�a pu�o essere nota oppure stimata. Il metodoGnatt prevede i seguenti passi: viene identi�cata una scala temporaleche permette sia di rappresentare l'intero progetto sia di distinguere lesingole attivit�a; viene de�nita una tabella come quella in �gura 3.5 eviene realizzato il diagramma con in ordinata le attivit�a ed in ascissala scala temporale. In particolare, �e possibile identi�care i possibili \lagtime" e quelle attivit�a il cui ritardo, per l'esistenza di determinati vincoli,potrebbero causare un ritardo complessivo per l'intero progetto detto\critical path".

� Nel caso di progetti complessi, nei quali �e importante tenere in consi-derazione le relazioni di precedenza tra le attivit�a, si utilizzano tecnichereticolari poich�e si prestano meglio per identi�care le sequenze logiche trale varie attivit�a e la durata e�ettiva di ognuna. Inoltre �e ancora possibilecomprendere i lag time ed un eventuale cammino critico. Si basano suconcetto di predecessore, cammino e oat, ovvero attivit�a non criticheche pur ritardando, non hanno un impatto sul tempo complessivo dellosviluppo del progetto. Tra queste tecniche le pi�u usate sono:

41

{ CPM, \Critical Path Method". Questa tecnica �e usata quando ladurata delle attivit�a �e nota a priori e spesso a�anca il precedentemetodo. Permette di valutare la migliore allocazione delle risorse al�ne di ridurre la lunghezza del cammino critico e quindi la duratadel progetto. Nel caso di attivit�a non critiche, �e de�nibile il oatdi ognuna e due possibilit�a (\Earliest Time" e \Latest Time"). Apartire da una tabella delle attivit�a, viene realizzato un grafo i cuinodi rappresentano le attivit�a e gli archi le relazioni temporali.

{ PERT, \Program Evaluation Review Technique". �E impiegata nelcaso si abbiano soltanto delle stime sulla durata, de�nendo la pro-babilit�a di terminare un progetto entro una data �ssata, oltre avalutare le conseguenze di ritardi che occorrono sulle attivit�a cri-tiche e non. In particolare, prevede, per ogni attivit�a di forniretre stime: ottimistica, pessimistica e la pi�u probabile e di deriva-re in funzione di esse la durata attesa, la varianza e la deviazionestandard, tenendo conto che le attivit�a con deviazione standard pi�ualta sono quelle maggiormente soggette ad incertezza. Data una sti-ma sulla durata di ogni attivit�a, si pu�o determinare la probabilit�adi terminare il progetto entro una data certa, calcolando la devia-zione standard associata al cammino critico, in funzione di quelledelle attivit�a componenti. Bisogna comunque osservare che la tec-nica PERT si basa sull'ipotesi che le attivit�a siano stocasticamenteindipendenti ed �e applicabile nel caso il numero delle attivit�a.

42

Capitolo 4

Il modello di analisi economica

I progettisti di sistemi digitali, caratterizzati da volumi di produzione ancheelevati, si trovano ad a�rontare nuove s�de dettate da speci�che di performan-ce sempre pi�u stringenti, requisiti funzionali e di timing estremamente avanzatie da una maggiore rigidit�a sui vincoli �sici.Nella gestione di un progetto assume un ruolo centrale la gestione dei costi.Per darne una stima, vanno in primo luogo valutati l'e�ort ed il tempo disviluppo. Ci�o �e possibile grazie ad un modello nel quale le variabile predittiverisultano essere \dimensione del progetto", economie e diseconomie di scala efattori moltiplicativi.

4.1 Identi�cazione dei costi

Per stimare i costi che intervengono nella realizzazione dei sistemi digitali esi-stono varie tecniche che sfruttano l'esperienza, l'analogia con progetti a�ni, unapproccio top-down o bottom-up oppure modelli parametrici. Volendo seguirequest'ultima soluzione, �e necessario:1) Identi�care quali siano i fattori che in uiscono sulle quantit�a che si voglionostimare. �E importante, a tale proposito, de�nire le voci di costo nel usso diprogetto ed i parametri (variabili predittive) che in uiscono sulle grandezzeche si vogliono stimare (variabili in uscita).2) Fare una analisi per determinare l'impatto dei fattori di costo sulle quantit�ada determinare.3) Formulare una versione a-priori del modello. Per quanto riguarda la primafase del usso di progetto, lavorando ad un livello di astrazione molto alto,�e possibile trovare dei forti parallelismi tra lo sviluppo di sistemi hardware e

43

quelli software. Per questo motivo possiamo fare riferimento al modello CO-COMO 2.0, (COstructive COst MOdel) [COCO 97], poich�e esistono alcunifattori di costo che in uiscono esattamente allo stesso modo anche nel caso diprogettazione dei sistemi digitali. In realt�a sono necessari tre modelli:- per la stima dei costi nel caso di progettazione senza riuso (design from-scratch);- per la stima dei costi per il progetto di componenti riusabili (design for reu-se);- un terzo modello per la stima dei costi nel caso di progetti che riusano com-ponenti gi�a disponibili (design with reuse), dove dovranno essere analizzati icosti di integrazione dei blocchi riusabili e quelli di progettazione della partedi logica speci�ca del sistema.Sono molti i costi che intervengono nella realizzazione di un sistema digitale eche devono essere analizzati per adottare una buona strategia di implementa-zione ed eventualmente per scegliere se sia conveniente o no riusare. Alla basedi qualsiasi decisione, ad esempio il prezzo di vendita, devono essere considera-ti i costi complessivi del sistema. Di seguito, verranno descritti quelli relativial usso di progetto di sistemi digitali e di essi verranno presi in considerazionequelli su cui il riuso in uisce maggiormente, [West 94]:

� Costi non ricorrenti (NRE). Si tratta dei costi che compa-iono una sola volta e che normalmente vengono interpretati come uninvestimento per il quale �e richiesto un certo ritorno. In generale sonoammortizzati sul numero di circuiti che verranno venduti. Essi includono:

{ Costi di progetto e sviluppo.

{ Costi di fabbricazione del prototipo.

I primi sono i costi riconducibili alle risorse impiegate nel processo disviluppo, ed includono:

{ Personale tecnico. I costi sono quelli relativi alle risorse impegnatenelle attivit�a che costituiscono il usso di progetto:

� Analisi di mercato, speci�ca dei requisiti e analisi di fattibilit�a.

� Stesura delle speci�che tecniche.

� Progetto architetturale.

� Progetto logico.

� Simulazione a livello funzionale.

� Layout di moduli e chip.

� Veri�ca temporale.

44

� Generazione del test.

{ Risorse e prodotti di supporto.I costi relativi alle risorse di supporto, ammortizzati durante l'interociclo di vita del progetto, includono:

� Costi di ammortamento e manutenzione dell'hardware.

� Costi di ammortamento e manutenzione di programmmi CAD.

� Costi per la formazione e l'aggiornamento del personale.

� Costi di acquisizione o adeguamento \tool".

I tool possono essere sia sviluppati internamente sia acquisiti al-l'esterno [Bull 99b]. I primi sono opportunamente documentati emessi a disposizione per l'uso; i secondi richiedono un'analisi pre-ventiva delle necessit�a del gruppo di progetto coinvolto, la sceltadelle possibili alternative, i contatti con i vendor ed in generaledelle valutazioni preventive. All'inizio di un nuovo progetto, paral-lelamente alla de�nizione preliminare delle speci�che, vanno infattimessi a disposizione dei progettisti tutti gli strumenti necessari allosviluppo.Le principali attivit�a coinvolte sono:

� Aggiornamento delle release dei tool software commercia-li o interni, sulla base degli aggiornamenti degli stessi o deicambiamenti nel sistema operativo utilizzato. Ovviamente talivariazioni dovranno essere comunicate ai progettisti.

� Acquisizione dei nuovi tool sia per eventuali necessit�a diprogetto, sia per migliorarne in generale l'e�cacia.

� Studio e proposte di nuove tecniche applicative di parti-colare importanza per il progetto in corso, ad esempio tecnichedi veri�ca formale e di prototipazione.

� Supporto diretto per l'impiego dei tool.

� Organizzazione di training sui tool commerciali impiegati,sul linguaggio di descrizione dell'hardware, emissioni di manualiper tool o per i modelli di simulazione sviluppati internamente.

� Costi ricorrenti . Si tratta dei costi che si presentano ogni voltavenga prodotto un sistema digitale.

� Costi �ssi .

� Costi legati al time to market . Alla luce della valutazionedell'impatto che ha il riuso sulla riduzione dei costi, �e lecito prendere

45

in considerazione anche quei costi sui quali pu�o in uire la scelta di unadeterminata strategia o metodologia in fase di progetto. Un ingresso sulmercato in ritardo rispetto ai tempi previsti pu�o causare una perdita delleentrate, interpretabile anch'essa come \costo" aggiuntivo, oltretutto trai pi�u onerosi da sostenere.

4.2 Stima dello sforzo e del tempo di sviluppo

L'analisi dei costi prevede, in primo luogo di e�ettuare le seguenti stime:

� lo sforzo di sviluppo, (E�ort, Eff), necessario per realizzare una deter-minata applicazione, esprimibile in mese-persona (pm). Il mese-persona�e la quantit�a di tempo che una persona dedica ad una speci�ca attivit�anell'arco di un mese.

� il tempo (T ), espresso in mesi. Si tratta della quantit�a di tempo neces-saria allo sviluppo del progetto, ipotizzando che il lavoro venga svolto atempo pieno.

Assumiamo per la stima dell'e�ort l'equazione di base del modello di analisieconomica COCOMO 2.0 :

Eff = A � SB (4.1)

I parametri, o variabili predittive, sono:

� S: la dimensione del progetto che si sta trattando, in funzione della qualevariano i costi.

� A: un coe�ciente impiegato per considerare i possibili fattori moltipli-cativi sullo sforzo.

� B: un fattore di scala che tiene conto delle economie e diseconomie discala incontrate nello sviluppo di progetti di dimensioni diverse.

Un aspetto ulteriore del modello di analisi economica �e la stima dei tempi disviluppo, ovvero quanto tempo dovr�a essere dedicato allo sviluppo complessivodel progetto ed in particolare alle principali attivit�a o fasi che lo costituiscono.L'equazione per la stima del tempo �e la seguente:

T = A2 � (Eff)B2 �

PSCHED%

100(4.2)

dove A2 e B2 hanno un signi�cato analogo a quello di A e B e PSCHED%

46

rappresenta un fattore correttivo per indicare in che percentuale possa variare,per compressione o espansione, lo scheduling di sviluppo nominale che �e statopre�ssato per lo sviluppo.

4.2.1 Stima delle ore lavorative

Un obiettivo del modello �e riuscire a stimare l'e�ort ed il tempo che ogni at-tivit�a richiede. Un possibile approccio per la stima delle ore lavorative �e ilseguente.Sia Eff la stima dello sforzo associato al progetto, calcolata in base all'equa-zione 4.1 e sia F l'insieme di attivit�a che compongono il usso di progetto.Valgono allora le seguenti:

8A 2 F EffA = �A � Eff (4.3)

XA2F

�A = 1 (4.4)

dove i pesi �A dovranno essere de�niti in base di informazioni storiche e diprogetti a�ni. Indicato allora con R l'insieme di risorse che partecipano ad A,ne sia Ri il sottoinsieme tale che:

8i 2 gradesA Ri = frj : j = 1; : : : ; nig (4.5)

Allora il tempo Tj che la risorsa rj dedica alla propria attivit�a �e:

Tj =�i � EffA

ni(4.6)

Xi2A

�i = 1 (4.7)

dove i pesi �i dipendono dai grades che caratterizzano la singola attivit�a.

4.3 I parametri del modello

�E possibile attribuire dei valori ai parametri del modello, in funzione dellamodalit�a di sviluppo del progetto, come indicato in tabella 4.1. Tale modalit�a�e a sua volta legata alla di�colt�a dell'applicazione, ovvero ai vincoli pi�u o menostringenti e al grado di novit�a dell'applicazione, [COCO 81].Le modalit�a di sviluppo sono tre:

47

MODE A B A2 B2

Organic Mode 2.4 1.05 2.5 0.38Semi-Detached Mode 3.0 1.12 2.5 0.35Embedded Mode 3.6 1.20 2.5 0.32

Tabella 4.1: Valori dei parametri in funzione della modalit�a di sviluppo.

1. Organic Mode. Appartengono a questa classe progetti relativamente sem-plici, di limitate dimensioni e con requisiti non troppo stringenti. Ilgruppo di lavoro �e piccolo e l'esperienza media del personale �e medio-alta. L'ambiente di sviluppo �e molto stabile e sono quasi nulli i vincolisui tempi di consegna.

2. Semi-Detached Mode. Le applicazioni hanno di�colt�a e dimensioni in-termedie. Coloro che le sviluppano hanno gi�a una certa esperienza conaltre a�ni. L'ambiente di sviluppo �e mediamente stabile e i vincoli suitempi di consegna non sono particolarmente stringenti.

3. Embedded Mode. In questa classe si collocano le applicazioni pi�u com-plesse, di dimensioni medio-grandi, con vincoli stringenti, che richiedonoun attento controllo del processo di sviluppo ed una elevata qualit�a. Losviluppo �e molto strutturato, l'esperienza del personale �e diversi�cata esono presenti forti vincoli sui tempi di consegna.

Dimensione del progetto

Per stimare la dimensione del progetto, ad alto livello, esistono varie metriche.Si tratta di strumenti utili, non soltanto, a migliorare le stime dei costi e deitempi di un progetto, ma anche a comprendere meglio e monitorare il processodi sviluppo e piani�carne cos�� la gestione.Nella maggior parte dei modelli per la stima della produttivit�a e dei costi ladimensione del \software" �e il fattore pi�u importante.Nel caso speci�co di sviluppo di sistemi digitali, la fase di progettazione fun-zionale permette di passare dalle speci�che alla scrittura del codice. Operandoad un alto livello di astrazione viene utilizzato il VHDL per la descrizionecomportamentale e strutturale del sistema. Pertanto, avendo assunto comemodello di riferimento il COCOMO 2.0 [COCO 97], S rappresenta il numerodi linee di codice [Ghez 94].Tuttavia il dimensionamento del progetto, nel caso speci�co del modello pro-posto, pu�o essere realizzato principalmente secondo due prospettive, ovveroattraverso:

48

� Misure tecniche che dipendono dallo sviluppo e dalle scelte nella fase discrittura del codice. �E il caso della metrica basata sulle \linee di codice"con cui si ottiene direttamente il valore di S.

� Misure funzionali che tengono conto delle funzionalit�a attese dal sistema.Si tratta della metrica dei \Function Point". In questo caso ottenuta lastima, viene impiegato un fattore di conversione per derivare S.

Nell'equazione 4.1, S viene espresso in linee di codice dell'applicazione.La strategia di calcolo viene illustrata nei dettagli nella seconda parte del pre-sente lavoro di tesi. Essa costituisce parte originale del lavoro svolto poich�e inletteratura non �e possibile reperire una documentazione adeguata, consideran-do il particolare ambiente di sviluppo, cio�e la progettazione di sistemi digitali,e le caratteristiche del linguaggio impiegato il VHDL.

4.4 Fattori moltiplicativi

I fattori di costo (cost driver), sono quei parametri o caratteristiche nel pro-cesso di sviluppo che hanno l'e�etto di in uenzare i costi di progetto, gli stessisui quali il Riuso in uisce maggiormente.Per ognuno di essi, anche in questo caso, come alternativa all'impiego dellatabella 4.1, possono essere de�niti dei livelli che ne misurano l'impatto sul-lo sforzo di sviluppo [COCO 97]. Da un punto di vista quantitativo, hannoanch'essi associato un peso la cui media �e 1. Superiore ad uno signi�ca unincremento dello sforzo, al contrario, se �e inferiore ad 1, lo sforzo potr�a essereridotto. Il coe�ciente A �e pari al prodotto di tali pesi.I fattori di costo possono essere raggruppati nelle seguenti categorie:

Fattori relativi al personale. Si intendono in questo caso quei fattori chetengono conto delle caratteristiche di coloro (analisti, programmatori, sistemi-sti, tecnici) che lavorano nel gruppo di progetto e sviluppo. Non vi �e dubbio,infatti, che la loro capacit�a professionale, cos�� come l'esperienza nel dominiodi applicazione o la familiarit�a ad un particolare ambiente di lavoro, possanoin uire sui tempi di sviluppo. In particolare possiamo individuare:

� Capacit�a di analisi. Si tratta di considerare l'abilit�a, l'e�cienza, la ca-pacit�a di cooperare e comunicare di coloro che lavorano all'analisi difattibilit�a ed alla speci�ca dei requisiti, quindi al progetto ad alto livello.

� Capacit�a dei programmatori. Anche in questo caso si valutano le stessecaratteristiche per coloro che progettano il dispositivo a livello compor-

49

tamentale. Ovviamente, si tratta di tener conto dei gruppi di personeche cooperano tra loro, piuttosto che delle qualit�a individuali.

� Esperienza nel tipo di applicazione. Questo fattore tiene conto dellafamiliarit�a con la tipologia di progetti che si stanno sviluppando. Si vada un'esperienza inferiore ai due mesi �no ad una superiore ai sei anni.

� Esperienza con gli strumenti usati. Con questo fattore si vuol valutare illivello di programmazione con il linguaggio di speci�ca, l'esperienza coni vari formalismi ed i tool impiegati.

� Continuit�a del personale. Si deve tener conto di quanto possa incidereun ricambio annuale del personale (turnover): dal 3%, se molto alto, al48%, in caso sia molto basso.

Fattori relativi al progetto. Si tratta in questo caso di considerare lecondizioni nelle quali il progetto viene portato avanti.

� Impiego di strumenti di sviluppo. L'uso di tool CAD/CAE disponibili,pi�u o meno avanzati, incide signi�cativamente sullo sforzo di progetto.�E il caso di tool speci�ci o critici per il design come per oorplan o lagestione del pinout, di quelli per il calcolo dei ritardi e stima dei parassiti,o le prestazioni del design rule checker.

� Vincoli sui tempi di sviluppo. Stima i vincoli imposti sui tempi di conse-gna ed �e de�nito proprio in funzione di quanto, in percentuale, vengonoridotti i tempi standard di sviluppo dell'applicazione. Ridurre i tempidi consegna pu�o determinare un aumento delle sforzo soprattutto nelleultime fasi dello sviluppo, quando, per a�rontare determinate problema-tiche, i tempi a disposizione sono pi�u brevi. Quando c'�e la possibilit�a chei tempi di sviluppo siano particolarmente lunghi, con il rischio, ad esem-pio, di entrare tardi sul mercato, �e possibile ridurre i tempi di sviluppocon l'impiego di maggiori risorse. La �gura 4.1 evidenzia il legame trale variazione sullo scheduling ed il fattore moltiplicativo corrispondente.Si pu�o notare come ci sia un e�etto negativo sull'e�ort, legato ad unascelta come la precedente, imputabile, ad esempio, alle maggiori di�-colt�a di comunicazione tra pi�u persone e, conseguentemente, ad errori oine�cienze da parte del gruppo di progetto [Boeh 81].

Fattori relativi al prodotto. Incide sui costi anche una serie di vincoli erequisiti direttamente legati sia al dispositivo �nale, sia ai prodotti intermediche vengono realizzati nelle varie fasi dello sviluppo.

� Complessit�a.

50

Figura 4.1: La relazione tra la compressione dello scheduling ed i possibilivalori del corrispondente fattore moltiplicativo.

� Tipologia di progetto.

� Livello di riusabilit�a richiesto. Qualora si decida che uno o pi�u modulidovranno essere riusati, ci sar�a sicuramente uno sforzo aggiuntivo ri-chiesto per garantire una maggiore qualit�a, da una documentazione pi�uelaborata ad un testing pi�u esaustivo.

� Livello di documentazione richiesto.

� Performance. I due parametri sono velocit�a e potenza, ognuno dei qualicomporta un'analisi accurata in tutte le fasi di progetto.

� A�dabilit�a richiesta.

� Tecnologia richiesta.

4.5 Economie e diseconomie di scala

In ogni modello per la stima dei costi, �e necessario tener conto delle economiee diseconomie di scala che caratterizzano progetti di dimensioni diverse. Comesi �e indicato sopra B rappresenta proprio questo.

51

Se B < 1, il progetto presenta economie di scala: se avesse una dimensio-ne doppia, lo sforzo risulterebbe minore della met�a. Pu�o esserne un motivol'ausilio di opportuni tool (in fase di simulazione o di test), anche se �e unacondizione di�cile da veri�carsi.Se B = 1, economie e diseconomie si bilanciano, come accade, almeno in ge-nerale, per piccoli progetti.Se B > 1, il progetto presenta invece diseconomie di scala imputabili essen-zialmente a due fattori. Da un lato, vanno considerate le di�colt�a legate allecomunicazioni interpersonali, dato che la realizzazione di progetti di vaste di-mensioni richiede infatti un maggior numero di risorse e quindi pi�u scambidi informazioni. Dall'altro, c'�e l'aumento dell'overhead dovuto al problemadell'integrazione di sistemi: allo sviluppo del modulo che dovr�a essere inte-grato, va aggiunto lo sforzo per progettare e testare le interfacce con il restodel sistema. Per cercare di ridurre tali di�colt�a, �e buona norma riuscire adeliminare errori e rischi con opportune scelte manageriali, a partire dall'uso direquisiti pi�u che mai stabili e speci�che corrette e complete. Tra i fattori discala �gurano:

� Familiarit�a. Valuta l'esperienza con progetti analoghi o se c'�e invecequalcosa di innovativo che deve essere a�rontato.

� Flessibilit�a di progetto. Esprime la conformit�a del progetto a possibilirequisiti prede�niti o interfacce esterne.

� Risoluzione dei rischi. La capacit�a di stimare i possibili inconvenienti.

� Coesione di gruppo. Tiene conto delle di�colt�a che possono sorgere acausa della scarsa esperienza delle persone ad operare in gruppo.

� Maturit�a dell'intero processo usato nella produzione di una determinataapplicazione.

Come si �e precedentemente indicato, B assume un valore assegnato che variada 1.05 a 1.20, in funzione della tipologia del progetto. Una seconda possibilit�a,[COCO 97], �e data dall'attribuzione, a ciascun fattore di scala, di sei possibililivelli a ciascuno dei quali �e associato un peso (Wi), che contribuisce al valore�nale di B, calcolato come segue:

B = 1:01 + 0:01 �X

Wi (4.8)

Ad esempio, nel caso ci siano forti di�colt�a di interazione nel gruppo di proget-tisti allora verr�a assegnato al fattore \coesione", il livello pi�u basso, al contrariose c'�e una forte cooperazione, il livello sar�a alto, come indicato nella tabella

52

4.2.Ovviamente, questo secondo approccio conduce ad a�rontare un livello digranularit�a �n troppo eccessivo e pertanto non verr�a al momento adottato.

Coesione del gruppo

Very Low very di�cult interactions 0.0494

Low some di�cult interactions 0.0395

Nominal basically cooperative interactions 0.0297

High largely cooperative 0.0198

Very High highly cooperative 0.0099

Extra High seamless interactions 0.00

Tabella 4.2: Scala con i livelli associati al fattore di scala \coesione" ed i pesicorrispondenti.

53

Capitolo 5

L'impatto economico del riuso

La progettazione di moduli o sottosistemi a�nch�e possano essere riusati inpi�u applicazioni richiede in media un tempo 2.5 volte superiore a quello diuna progettazione per uso singolo. Ovviamente se il riuso �e la soluzione perprogettare chip con milioni di gates, �e altrettanto vero che serve una metodo-logia di supporto e soprattutto degli investimenti pi�u ingenti rispetto ad unaprogettazione from scratch, [Mouss 99]. Altrettanto accade se si vuole riusareun componente. In particolare, esistono delle fasi dello sviluppo che richiedonotempi pi�u lunghi quali: un'analisi pi�u accurata del blocco e dei suoi potenzialidomini di applicazione, lo sviluppo di un ambiente di test bench pi�u completoe robusto e la realizzazione di una documentazione pi�u esauriente.

5.1 L'esigenza di un modello �nanziario

Il fattore chiave che determina il successo di un sistema digitale, in un mercatosempre pi�u competitivo, �e la riduzione del time-to-market e dei costi associatial ciclo di vita del progetto. I venditori di semiconduttori sono consapevoli chesoltanto una metodologia di progetto basata sul riuso, applicato in modo siste-matico ed e�cacie, possa migliorare la qualit�a del progetto e parallelamenteridurre lo sforzo di sviluppo, per essere pi�u competitivi sul mercato [Keat 98].Il grado di riusabilit�a di un progetto non �e tuttavia unico: i fornitori di semi-conduttori forniscono blocchi hard, come microprocessori o DSP, mentre quellidi IP commerciano essenzialmente sia componenti soft sia �rm. In generale,la maggior parte delle aziende si �e rivolta al riuso interno dei propri progetti,prestando particolare attenzione al raggiungimento di una sempre pi�u elevataqualit�a sia dei progetti realizzati sia di quelli comprati.

55

Figura 5.1: Evoluzione dei costi.

L'esperienza di Synopsys, [Sava 98], nello sviluppo di progetti riusabili per leproprie librerie e macrocelle, dimostra che il costo per il riuso pu�o essere da2.5 a 5 volte quello per uso singolo e varia in base all'uso del componente IP.Nel caso infatti di riuso interno, il costo �e minore, sebbene sia circa il doppiodel costo di progetto di un blocco non riusabile poich�e non c'�e da tener contodella variabilit�a di utilizzazione esterna. In generale per�o, il costo complessivodel riuso �e funzione diretta sia della complessit�a sia del grado di riusabilit�a delprogetto ed in quanto tale pu�o variare considerevolmente.Inoltre, se viene adottata una strategia di riuso parziale infatti, non �e richiestoun particolare investimento per il riuso; nel caso invece di uno scenario di riusocompleto, non solo �e necessario investire, ma soltanto un numero su�ciente-mente elevato di riusi potr�a garantire un buon margine di pro�tto e giusti�caredei costi iniziali pi�u alti.In questo scenario, maggiori saranno le informazioni disponibili sul riuso nel-l'Industria Microelettronica, migliori potranno essere gli investimenti di dena-ro, tempo e risorse da parte delle aziende. Se per le maggiori case produttricidi semiconduttori infatti, sono dati di fatto la necessit�a di adottare il riuso ed ivantaggi che ne derivano, pu�o comunque essere utile stimare, ad esempio, i li-velli di riuso che dovranno essere raggiunti per realizzare chip nei prossimi annio il numero dei riusi minimo di uno stesso componente. Con questo obiettivo,una comprensione ed una stima dei fattori coinvolti nel riuso di componentiIP , permetteranno di identi�care quelle attivit�a tecniche e non, necessarie peradottare un nuovo approccio manageriale e progettuale per la piani�cazione ela gestione del riuso stesso.

56

5.2 Riusabilit�a di un progetto

Prendiamo ora in considerazione alcuni aspetti speci�ci della progettazionedei sistemi digitali, analizzando i requisiti che il riuso impone nello sviluppo dicomponenti IP soft.L'uso di linguaggi HDL infatti non garantisce da solo la riusabilit�a di uncomponente. �E necessario prima di tutto che siano presenti:

� Funzionalit�a comuni ad altre applicazioni.A�nch�e un progetto sia realmente riusabile, dovr�a essere richiesta alme-no una funzionalit�a in esso realizzata: il progetto cio�e dovr�a realizzare,almeno in parte, una funzionalit�a comune ad altre applicazioni, altrimen-ti non ha senso investire tempo e costi aggiuntivi. Sono essenzialmentetre le classi di progetto per cui tale propriet�a �e veri�cata:

1. progetti contenenti componenti con funzionalit�a standard, come adesempio sommatori aritmetici.

2. progetti che implementano standard, come un'interfaccia Etherneto un protocollo ISDN .

3. progetti che subiscono una reimplementazione con l'arrivo di nuovetecnologie o per una richiesta di un maggiore livello di integrazioneo performance, per renderli pi�u competitivi sul mercato.

� Adattabilit�a.La riusabilit�a di un progetto �e strettamente dipendente anche dalla es-sibilit�a, ovvero dal grado di parametrizzazione delle funzionalit�a. Ci�o �evero principalmente nel caso di:

{ Parametrizzazione strutturale. �E strettamente legata alla imple-mentazione. Un sommatore a k bit �e sicuramente pi�u essibile equindi riusabile di uno a due bit. Questo �e importante soprattuttoper componenti progettati per essere riusati.

{ Parametrizzazione funzionale. Richiede necessariamente una speci-�ca metodologia di progetto ed in quanto tale �e pi�u complessa daottenere della precedente, ma garantisce un livello di riuso estrema-mente elevato. Ne sono esempi un dispositivo la cui funzionalit�aopera a frequenze di�erenti oppure un dispositivo con pi�u funzio-nalit�a attivabili o meno in base alla categoria di utenti a cui verr�arivolto.

57

5.2.1 Come riusare i progetti

Il riuso si �e estremamente evoluto negli ultimi anni grazie ai nuovi strumentie metodologie. Sono essenzialmente tre le possibili strategie:

1. Interscambio dei progetti.La forma pi�u semplice di riuso �e rappresentata dall'interscambio dei dati.Per riusare un componente �e, prima di tutto, necessario poterlo ricollo-care facilmente in un nuovo ambiente. Ci�o impone che il formato deidati sia fedele a degli standard comuni sia al progettista sia a colui chelo riuser�a. In questo senso ogni generazione di \design automation" hail proprio standard: a livello di layout esiste il formato GDSII e per ladescrizione comportamentale vengono adottati linguaggi quali Verilog esoprattutto VHDL. In questa direzione non tutto �e risolto, basta con-siderare la scelta da parte di molte case produttrici di software di faradottare formati standard proprietari.

2. Evoluzione dei progetti.Per ogni nuova generazione di sistemi, i progetti relativi a quella pre-cedente sono senza dubbio un valido punto di partenza, soprattutto sesi tiene conto della richiesta di compatibilit�a all'indietro in molti setto-ri dell'hardware. L'evoluzione di progetto �e forse la strategia di riusodi maggiore successo, come implicazione diretta dell'impiego degli HDL.Aziende che investono maggiormente su questo tipo di descrizioni, av-valendosi di librerie di componenti per estrarre eventualmente le singolefunzionalit�a, potrebbero ridurre i tempi di progetto di tre volte, oltread ottenere una migliore qualit�a soprattutto in termini di correttezzafunzionale.

3. Incapsulamento delle conoscenze di progetto. Un ge-nere di riuso emergente �e da ritrovarsi nell'incapsulamento dei dati, dellespeci�che e dell'implementazione secondo una metodologia che faccia usodi standard e tutelare la propriet�a intellettuale della prima realizzazionee quindi la sicurezza del prodotto stesso. L'idea della standardizzazionecoivolge essenzialmente gli elementi pi�u critici del riuso stesso:

� gli aspetti chiave delle funzionalit�a realizzate e le direttive dell'im-plementazione;

� l'interazione con il processo realizzativo;

� un approccio uniforme per selezionare l'implementazione �nale;

� la protezione, che potr�a essere garantita con metodi di cifratura.

58

Si tratta di un riuso con due principali vantaggi: da un lato le miglioriprestazioni e riduzione dei costi, poich�e il progettista d�a ottimi risultatiper l'impiego futuro delle tecnologie ASIC o nel rispetto dei vincoli im-plementativi, dall'altro c'�e il bene�cio della correttezza per la preveri�cadei componenti stessi.

5.2.2 Ostacoli al Riuso di progetti

Nonostante quanto descritto in precedenza, il riuso non si �e ancora completa-mente a�ermato come strategia di successo e le motivazioni sono da ricercarsiin una serie di fattori non a�atto trascurabili.Ci sono fattori culturali tra i quali una scarsa �ducia nel lavoro realizzato daaltri. Come sosteneva Boehm, gi�a a livello universitario, dove il riuso vienescoraggiato, pu�o nascere la sindrome del \Not Invented Here" in coloro chesaranno i futuri progettisti.Le informazioni che i progettisti hanno a disposizione per decidere se adottareo meno una strategia di progetto basata sul riuso non sono ancora totalmen-te a�dabili: mancano spesso le realizzazioni dei dispositivi e quindi non �epossibile e�ettuare confronti tra le varie implementazioni. Sia la portabilit�adei progetti, nonostante la standardizzazione dei linguaggi, Verilog e VHDL,sia l'indipendenza dallo strumento di progettazione sono aspetti tutt'altro chescontati. Studi dimostrano che, qualora il tempo richiesto per riusare un pro-getto o una sua sottoparte, sia superiore del 30% al tempo necessario ad unaimplementazione ex novo, c'�e il rischio di non trarre alcun bene�cio dal riu-so. A questo proposito va considerato il tempo impiegato per comprendere ladocumentazione, determinare quale parte sia riusabile, realizzare le modi�chenecessarie ed integrarla nel nuovo progetto.Un altra motivazione �e da ricercarsi nella consapevolezza che i costi aggiuntivipotranno essere ammortizzati solo con un adeguato numero di riusi. A taleproposito va sottolineata l'esigenza da parte dei progettisti di modelli in gradodi stimare la complessit�a del componente che si vuole riusare, i costi aggiuntiviper renderlo riusabile e, allo stesso tempo, la riduzione complessiva degli stessinel caso venga riusato.

5.3 Propriet�a di un componente riusabile

Una strategia di progetto orientata al riuso riguarda le descrizioni a livelloRTL, scritte in Verilog o VHDL. Sebbene il concetto di progetto riusabile,possa variare da compagnia a compagnia, qualunque de�nizione deve include-re alcuni requisiti elementari:

59

� Garanzia di un corretto funzionamento. Bench�e ovvia, tale propriet�anon �e facilmente veri�cabile. L'inserimento di uno o pi�u componenti all'inter-no di un progetto, realizzati in un altro contesto, comporta necessariamentel'introduzione di qualche elemento non perfettamente controllabile in quantonessun progettista del gruppo conosce esattamente tali componenti e la �lo-sia stessa del riuso pretende che si spenda il minor tempo possibile sul codiceriusato. Non potendo quindi veri�care completamente il componente, occorreche la fonte stessa del codice sia degna di �ducia da parte del gruppo di pro-getto. Se il componente �e acquistato esternamente, esisteranno accordi di tipocommerciale. Una forte garanzia di correttezza pu�o essere l'appartenenza delmodulo riusato ad un progetto �sicamente gi�a realizzato.

� Comprensibilit�a . La descrizione di un componente progettato per la ri-usabilit�a deve essere facilmente comprensibile. Il livello di comprensibilit�a �estrettamente legato alla dimensione del componente che si vuole riusare. Nelcaso di celle molto grandi bisogna prestare attenzione ad una schematizzazionedel funzionamento, mentre per piccoli componenti la comprensibilit�a �e diret-tamente legata alla qualit�a del codice.

� Flessibilit�a e generalit�a . Ogniqualvolta viene deciso di riusare un compo-nente, vanno sostenuti dei costi aggiuntivi che possono incidere pesantementesui costi globali. Per garantire una corretta strategia del riuso ogni compo-nente dovr�a essere riusato il maggior numero di volte. Sebbene possa andarea discapito della comprensibilit�a, �e necessario rendere il componente il pi�u ge-nerale e essibile possibile, riducendo i possibili vincoli imposti dal particolaredominio applicativo.

� Indipendenza dal CAD . Per evitare che l'obsolescenza degli strumentisoftware renda pressoch�e inutilizzabile un componente, �e auspicabile una pro-gettazione che sia il pi�u possibile indipendente dal CAD. In questa direzionesi stanno muovendo i comitati internazionali per uni�care i linguaggi con unastandard.

� Documentazione. Una documentazione di elevata qualit�a �e di fondamen-tale importanza, soprattutto per rendere pi�u facile l'utilizzo di un progettoesistente. Gli elementi essenziali di una documentazione esauriente, rigoro-sa e corretta sono: diagrammi a blocchi, speci�che funzionali, descrizione deiparametri e del loro uso, descrizione dei segnali di interfaccia, diagrammi tem-porali, strategia di veri�ca e i vincoli di sintesi. In particolare le speci�chedevono essere costantemente aggiornate: ad ogni utilizzo di un blocco �e buona

60

regola documentare il progetto nel quale viene collocato, descrivere ci�o cheviene testato, la tecnologia usata, i risultati di area e timing, la storia dellerevisioni. In ogni caso saranno necessarie la conoscenza dei test ai quali talecodice �e stato sottoposto per la sua validazione, una documentazione compostada una parte generale per una prima, veloce comprensione delle funzionalit�ae da una pi�u dettagliata da consultare nel caso sorgano dei problemi di im-plementazione; un'attivit�a di consulenza dell'ente fornitore del codice riusatosar�a certamente di particolare aiuto.

� Organizzazione del progetto. Ogni progetto per essere riusato devepresentare interfacce e con�ni dei blocchi logici al giusto livello di astrazio-ne. I progettisti devono essere in grado di identi�care le sezioni del progettoche possono essere riusate, evitando che il componente riusabile usufruisca diservizi o�erti dalla parte che �e invece speci�ca della applicazione in corso. Inparticolare, le interfacce devono essere progettate per de�nire chiaramente learee funzionali del progetto.

� Parametricit�a . Pi�u un componente �e parametrico pi�u vasto �e il conte-sto del riuso. Tuttavia non bisogna trascurare le problematiche connesse allaimplementazione hardware derivanti da una eccessiva parametrizzazione delprogetto.

� Stile di codice coerente. Uno stile di progetto coerente permette diottenere un codice che potr�a essere usato pi�u facilmente in seguito. Una talecoerenza nel codice a livello RTL pu�o ritrovarsi adottando tutta una serie diaccorgimenti, ad esempio delle convenzioni sui nomi dei segnali. Ovviamenteogni gruppo di progetto potr�a decidere il livello di consistenza che riterr�a pi�uidoneneo alla propria attivit�a. Nella peggiore delle ipotesi, dovr�a essere garan-tita almeno la coerenza all'interno del singolo progetto.

� Veri�ca . Una veri�ca accurata �e una qualit�a essenziale ogni volta ven-gano ipotizzati dei riusi del progetto. Sono pertanto necessari dei documenticon i test e�ettuati ed i risultati ottenuti. In particolare sono utili tool dicopertura del codice per valutare l'e�cacia dei test ed eventualmente, qualoraesistano parti non coperte, l'uso di test random. Anche i risultati di sintesidevono essere veri�cati. In�ne �e auspicabile avere un ambiente automatico perfacilitare la riveri�ca del progetto, dopo eventuali modi�che, per mantenerealto il livello di qualit�a.

61

5.4 Tecniche di riuso per la progettazione V LSI

Il riuso si �e estremamente evoluto negli ultimi anni grazie ai nuovi strumenti emetodologie. I primi risultati ottenuti riguardano il livello di astrazione �sico,[Mead 80]; successivamente sono stati introdotti concetti e strategie per facili-tare la riusabilit�a dei componenti a di�erenti livelli di astrazione, [Kiss 97]. Ilprincipale inconveniente, evidenziato �n dall'inizio, ovvero la scarsa essibilit�adei macroblocchi riusati, �e stato successivamente analizzato da Preis, il qualeha proposto una libreria di componenti parametrizzabili, [Prei 95]. allo stessomodo, Bluml ha sviluppato un workbench per lo sviluppo di celle V HDL es-sibili, ed ha proposto un metodo per il riuso di blocchi complessi, [Blum 93].Un altro passo in avanti �e stato l'introduzione di tool in grado di gestire lariusabilit�a, sfruttando modelli behavioral per i componenti che vengono usatimaggiormente, considerando, in ambiente CAD solo moduli generici e unit�amultifunzionali, [Alme 94]. Allo stesso tempo il riuso ha coinvolto sistemi ba-sati su microprocessore che includono RAM, ALU, I/O e componenti datapath.Attualmente, con l'introduzione della programmazione ad oggetti [Schu 98],le tecniche stanno coinvolgendo anche il riuso di dati interni, rendendone pi�uveloce e facile l'accesso [Seep 96].

5.4.1 Progettazione dei componenti riusabili

Una delle metodologie di progettazione impiegate per progetti particolarmentecomplessi �e quella strutturata. Introdotta da S. Trimberger, [Trim 81], �e basa-ta su un approccio gerarchico che prevede, in primo luogo, un partizionamentodel sistema in moduli.Un partizionamento appropriato permette di preservare l'indipendenza trablocchi di�erenti attraverso una decomposizione guidata da regole strutturali.L'obiettivo �e di rimandare le decisioni \locali" di realizzazione e di rendere vi-sibili soltanto le interfacce di ogni modulo. Detta anche metodologiamodulare,consiste di una serie di regole di progettazione espresse in termini di vincolitemporali, \design gerarchico" e \ oor-planning". Questa metodologia �e inogni caso quella che riesce ad ottimizzare al meglio l'integrazione dei blocchiriusabili.Il sistema infatti pu�o essere visto come un insieme di blocchi sviluppabili condi�erenti approcci ed obiettivi quali la riusabilit�a e la progettazione per ununico impiego dei componenti. Una volta che i singoli blocchi sono stati pro-gettati e veri�cati funzionalmente, si passa alla fase di integrazione, medianteuna top level netlist che li istanzia e crea le interconnessioni.La richiesta di qualit�a in queste due attivit�a impone ai progettisti una buonaconoscenza dei componenti riusabili.

62

Pi�u in generale, progettare per riusare impone delle attivit�a aggiuntive, o inogni caso pi�u accurate, per garantire moduli che siano facilmente integrabili e essibili.Prima ancora di investire nella progettazione vera e propria, �e necessario ana-lizzare gli ambienti e stimare il numero di applicazioni in cui quel componenteverr�a o potr�a essere collocato.Nel ciclo di sviluppo, il riuso coinvolge pi�u direttamente le seguenti fasi:

� Analisi del dominio di applicazionePrima ancora di investire nella progettazione vera e propria, �e necessarioanalizzare gli ambienti e stimare il numero di applicazioni in cui quelcomponente verr�a o potr�a essere collocato.La fase di analisi del dominio �e critica poich�e coinvolge tutti gli aspettifunzionali e tutte le funzionalit�a attese dal modulo, non soltanto nelsistema per il quale �e sviluppato ma anche in quelle successive in cuiverr�a integrato.

� Modellizzazione VHDL ed astrazione del componentel'approccio pi�u seguito a livello di modellizzazione V HDL per il riu-so �e la parametrizzazione, cio�e il controllo con parametri della maggiorparte delle funzionalit�a richieste. Si tratta di un'attivit�a che richiedemaggior tempo nel caso di componenti progettati per essere riusati vi-sto che vanno comunque garantite delle funzionalit�a generiche. Facendocos�� infatti viene migliorata la riusabilit�a proprio perch�e pu�o essere fattaun'astrazione concisa, espressiva e chiara del componente riusabile.

� Sintesi del componenteAdottando una tecnica modulare, il passo della sintesi �e indipendenteper ognuno dei moduli, restringendo cos�� l'attenzione e la soluzione diproblemi che si possono veri�care su ogni modulo.

� Veri�ca del componente e generazione dei testbenchLa fase prevede una simulazione delle funzionalit�a. In caso di riuso vannoprevisti tutti i possibili scenari nei quali il componente pu�o essere utiliz-zato, richiedendo molto pi�u tempo rispetto ad una veri�ca di componentispeci�ci. In genere vengono impiegati test bench basati su un modellolineare che permette la generazione essibile di test suites.

� Documentazione�E necessaria una documentazione completa per facilitare il pi�u possibileil riuso dei componenti. Rispetto ad una progettazione per uso singolo,in cui documentare signi�ca introdurre dei commenti con cui indicare la

63

funzionalit�a del modulo, il riuso impone la stesura vera e propria di unmanuale.

5.5 Il modello esteso al riuso

Il principio alla base della strategia del riuso �e che riusare un modulo gi�a dispo-nibile costa meno che progettarlo dall'inizio. Nel momento in cui per�o verr�aintegrato, nel caso sia ad esempio soft, la dimensione del progetto o del singolomodulo subir�a in generale delle modi�che per essere adattato al nuovo ambien-te. A tale proposito, un'analisi svolta presso la NASA Software EngineeringLaboratory, indica inoltre che il costo associato al riuso non �e funzione linearedella quantit�a modi�cata [COCO 97].Le ragioni sono due. Inizialmente c'�e un costo aggiuntivo necessario per sele-zionare e valutare il modulo per capire se sia appropriato o meno. Inoltre, ilmodulo va compreso e vanno controllate le interfacce; in�ne ci sono le modi�-che da apportare a�nch�e sia realmente riusabile. Il tutto con una ripercussionesui costi. Studi, nel caso di mantenimento del software, stimano che il 47%dello sforzo sia associato proprio alla comprensione del modulo che dovr�a es-sere riusato. Inoltre, se le modi�che coinvolgono k moduli su un totale di m,allora le interfacce da controllare, saranno:

N = k � (m� k) + k � (k � 1)=2 (5.1)

Tenendo conto di attivit�a quali il progetto, la codi�ca, l'integrazione ed iltest dei componenti, una chiara ed esaustiva documentazione cos�� come unastruttura gerarchica ridurr�a notevolmente lo sforzo legato al riuso. Seguendoquanto visto in [COCO 97], il modello per il riuso richiede, pertanto, unastima della dimensione equivalente, ~SM , che deve essere riusata, a partire daquella e�ettiva SM del modulo. Riportiamo di seguito, per le tre attivit�a, ifattori che in uiscono su ognuna di esse:

� Selezione del modulo

Assessment & Assimilation, (AA). Esiste uno sforzo prima di tutto percapire se il modulo �e appropriato per l'applicazione che si sta sviluppan-do. AA �e espresso in percentuale, in corrispondenza con i possibili livellidello sforzo richiesto, come evidenziato nella tabella 5.1.

64

� Comprensione del codice

Code Understanding, (CU). Indica, in percentuale, l'incremento nelladimensione del codice dovuto alla sua comprensione ed al controllo del-le interfacce. Se il modulo �e ben strutturato, documentato e con unachiara correlazione con l'applicazione in corso, sar�a pari al 10%; nel casoopposto sar�a del 50%. In tabella 5.2 sono indicati dei parametri, la cuimedia contribuisce a de�nire il valore �nale di CU .Unfamiliarity, (UNFM). Tiene conto della familiarit�a del progettista conil modulo che vuole riusare. In particolare, nel caso in cui, ad esempio,UNMF = 0, non ci sar�a neanche un incremento dello sforzo per la com-prensione del modulo. Mentre invece, se non lo conosce a�atto allora,l'incremento CU sar�a massimo. I valori sono riportati in tabella 5.3.

� Modi�ca del modulo

Il contributo, indicato con (AAF ), alle modi�che da apportare al modu-lo, dipende da:Percent Design Modi�ed, (DM). Percentuale del progetto del modulo chedeve subire delle modi�che per adattarsi al nuovo ambiente ed obiettivi.�E una quantit�a soggettiva.Percent Code Modi�ed, (CM). Percentuale del codice del modulo che de-ve essere modi�cato per le stesse ragioni.Percent of Integration Required for Modi�ed Code, (IM). Percentuale del-lo sforzo richiesto per l'integrazione ed il test del modulo modi�cato nelsistema complessivo, rispetto a quello necessario nel caso di progettazionefrom scratch di un altro di pari dimensione.

AA Increment Level of AA E�ort

0 None2 Basic module search and documentation4 Some module Test and Evaluation (T&E), documentation6 Considerable module T&E, documentation8 Extensive module T&E, documentation

Tabella 5.1: Corrispondenza tra i valori di AA e livelli.

Tenendo conto delle precedenti de�nizioni, valgono dunque le seguenti:

AAF = 0:4(DM) + 0:3(CM) + 0:3(IM) (5.2)

65

Code Commentary and documentationVery Low Low Nominal High Very High

50 40 30 20 10

GuidelinesNo Partially Yes50 30 10

Testbench (easy to use)No Medium Yes50 30 10

Tabella 5.2: Livelli e valori per CU .

textbfUNFM Increment Level of Unfamiliarity

0 Completely familiar0.2 Mostly familiar0.4 Somewhat familiar0.6 Somewhat UNfamiliar0.8 Mostly UNfamiliar1 Completely UNfamiliar

Tabella 5.3: Livelli e valori per UNFM .

~SM =

8>>><>>>:

SM [AA+ AAF + (1 + 0:02(CU))(UNMF )]

100AAF � 0:5;

SM [AA+ AAF + (CU)(UNMF )]

100AAF � 0:5:

(5.3)

66

Capitolo 6

Modello complessivo dei costi

I costi associati al ciclo di sviluppo del sistema e quelli legati al time to marketcostituiscono il fattore chiave nel determinare il successo di un prodotto in unmercato sempre pi�u competitivo, acquisendo un ruolo determinante sin dallafase di piani�cazione del progetto.Il modello economico per la stima dei costi associati alla progettazione di SoC�e basato sul modello per la stima dello sforzo di sviluppo proposto nel capi-tolo 4 e tiene in considerazione l'evoluzione della produttivit�a dei progettistidi sistemi digitali. L'obiettivo �e quello di stimare i costi di progettazione edil potenziale impatto che su di essi ha il riuso, dando una stima quantitativadell'aumento esponenziale dei costi nella progettazione di SoC e di come es-si possano essere ridotti con una corretta metodologia, che preveda crescentilivelli di riuso [Keat 98].

6.1 Evoluzione della produttivit�a

La produttivit�a dei progettisti �e de�nita come il numero medio di gate (testati),relativi al lavoro di una persona in un mese. Per un generico progetto vale cio�e:

Pr =gate

Eff(6.1)

Possono essere fatte le seguenti ipotesi:

1. In base alla legge di Moore, la complessit�a media di un chip raddoppiaogni diciotto mesi.

2. Analoga ipotesi pu�o essere fatta per il singolo modulo riusabile.

67

3. Il numero medio di gate testati da una persona nell'arco di un mese �ecostante.

4. La produttivit�a nella progettazione della parte di logica speci�ca delsistema aumenta negli anni.

5. Anno dopo anno, la produttivit�a nella progettazione con il riuso aumentasigni�cativamente.

Secondo le prime due ipotesi dunque, i gate sul sistema digitale i-esimo e suun generico componente riusabile M , tra t anni saranno:

Git = 1:588t �Gi0 (6.2)

GMt= 1:588t �GM0 (6.3)

dove Gi0 e GM0 indicano i valori medi relativi all'anno in corso.La quarta ipotesi �e quella forse pi�u suscettibile a variazioni a causa di una seriedi fattori che vengono descritti nel paragrafo successivo.

6.1.1 La produttivit�a per sistemi digitali

I miglioramenti, raggiunti anno dopo anno, nei tool di sviluppo hanno garantitouna crescita della produttivit�a per sistemi digitali, sebbene non sia stata maitale da tenere il passo con la legge di Moore. Nello stesso tempo per�o, �e undato certo la di�colt�a della fase di veri�ca: con circuiti di maggiore densit�ainfatti, l'insieme dei vettori di test e il tempo necessario ad eseguirli cresconoesponenzialmente. Stiamo assistendo attualmente a fasi operative in cui circail 65% del tempo richiesto allo sviluppo viene \speso" proprio nella fase chegestisce, appunto, sia la veri�ca funzionale dell'interazione tra i vari blocchi,sia la veri�ca della corretta implementazione del sistema. In questo scenario, �eallora possibile esprimere una visione ottimistica, pessimistica o pi�u probabiledella evoluzione della produttivit�a per sistemi digitali, (Pri), cambiando leipotesi sul valore della variazione annuale stimata che verr�a indicato con qi%.

� Miglioramento dei tool di sviluppo. Secondo una prima ipotesi pos-siamo assumere che i miglioramenti dei tool EDA permettano un aumen-to annuo della produttivit�a del 25% nella progettazione della parte di lo-gica speci�ca del sistema. Di conseguenza, a partire da una produttivit�amedia attuale, Pri0, tra t anni avremo:

Prit = (1 + qi)t � Pri0 (6.4)

68

� Crescita delle di�colt�a nella veri�ca funzionale. Se riteniamoinvece che le di�colt�a incontrate dai progettisti nella veri�ca funzionalecrescano pi�u rapidamente, nonostante i miglioramenti dei tool, potrem-mo allora ipotizzare una diminuzione del 5% annuo della produttivit�a.Questo corrisponde ad avere qi = �5% nell'equazione 6.4.

� Equilibrio tra evoluzione dei tool e di�colt�a di veri�ca . Inquesto caso possiamo ipotizzare una produttivit�a costante negli anni, equindi avere qi = 0%.

Seguiremo la prima ipotesi, quella pi�u ottimistica.

6.1.2 La produttivit�a nei componenti riusabili

Per quanto riguarda invece la produttivit�a PrM , per la progettazione di uncomponente riusabile M , l'acquisizione di una e�ettiva strategia del riusopermette di ipotizzare che vi possa essere un aumento annuale, esprimibilecome:

PrMt= (1 + qM)t � PrM0 (6.5)

dove qM = 30%.Per stimare l'evoluzione dello sforzo di progetto, �e necessario introdurre duecoe�cienti che tengano conto dell'in uenza del riuso sulla progettazione di uncomponente e sulla sua integrazione in pi�u sistemi.

Design for Reuse Factor

�E possibile de�nire un coe�ciente, DFRF (Design For Reuse Factor), concui esprimere il rapporto esistente tra lo sforzo, (EffFRM ), per realizzare uncomponente a�nch�e possa essere riusato e quello, (EffFSM ), per progettare lostesso modulo per \uso singolo". Nel caso del software riusabile la percentualedi sforzo addizionale, associato ad alcune attivit�a, �e quella riportata in tabella6.1. L'industria stima un valore compreso tra 1.5 e 4.0, cio�e:

1:5 � DFRF =EffFRM

EffFSM

� 4:0 (6.6)

Assumiamo DFRF pari a 2.5. Ovviamente tale valore �e minore nel caso diblocchi pi�u semplici, in termini di complessit�a.Potremmo allora prevedere l'andamento dello sforzo di progettazione dei siste-mi digitali in base alle equazioni 6.1 e 6.2. Sia EffFSi0

la stima attuale.

69

E�ort addizionale Attivit�a

25% Generalizzazione15% Documentazione10% Testing5% Supporto di libreria e mantenimento

Tabella 6.1: Attivit�a nelle quali il riuso richiede un maggiore sforzo.

Tra t anni avremo:

EffFSit=

G

(1 + qi)t � Pri0(6.7)

= (1 + qi)�t � EffFSi0

Per l'evoluzione dello sforzo EffFRMt, per la progettazione del modulo riusabile,

in base alle equazioni 6.1 e 6.6, vale invece la seguente:

EffFRMt= (1 + qM )�t � EffFRM0

(6.8)

= DFRF � (1 + qM )�t � EffFSM0

Design of Integration Factor

Un altro aspetto da tenere in considerazione �e l'andamento dello sforzo di in-tegrazione del modulo nel sistema �nale.Si introduce, a tale proposito il coe�ciente DOIF , (\Design of IntegrationFactor"), compreso tra 0.1 e 0.3, per esprimerne la relazione con quello soste-nuto nel caso in cui venisse progettato per uso singolo. Tale coe�ciente indicail rapporto tra lo sforzo per riusare un componente senza alcun tipo di modi-�ca e quello normalmente richiesto per svilupparlo from scratch. Si tratta ditener conto di attivit�a quali la comprensione ed integrazione dei componentiriusabili nel sistema i-esimo. Attualmente si stima che la fase di integrazionerichieda il 10% dello sforzo che dovrebbe essere sostenuto nel caso di una corri-spondente progettazione from scratch. Tale rapporto, strettamente legato alla

70

complessit�a del progetto, viene calcolato sulla base di esperienze precedenti odi analogie con altri progetti ed in generale si ha

0:1 � DOIF � 0:3 (6.9)

Questo in uenza l'e�ort associato alla progettazione del sistema con il riuso,nel momento in cui avviene l'integrazione di moduli gi�a disponibili. Vale cio�ela seguente equazione:

EffWRM =

EffFSM

DOIF(6.10)

Inoltre, nulla vieta di ipotizzare che l'adozione di una metodologia e�ciente esistematica permetta in realt�a di ottenere un miglioramento nella progettazionebasata sul riuso. In questo caso, sia lo sforzo per progettare per il riuso uncomponente sia quello per integrarlo decrescono anno dopo anno. Questocorrisponde analiticamente a far variare nel tempo sia DFRF sia DOIF :

DFRFt = 0:95t �DFRF0 (6.11)

DOIFt = 0:95t �DOIF0 (6.12)

dove DFRF0 e DOIF0 indicano i valori riferiti all'anno in corso.Tutto questo determina quindi quattro possibili scenari:

1. Il progetto a livello di sistema diventa pi�u e�ciente.

2. Il progetto a livello di sistema diventa meno e�ciente.

3. Il Riuso diventa pi�u e�ciente e la progettazione a livello di sistemadiventa meno e�ciente.

4. Il Riuso e la progettazione a livello di sistema diventano pi�u e�cienti.

6.2 Time to Market e Riuso

Una entrata sul mercato in ritardo rispetto ai tempi previsti incide pesante-mente, in termini di perdite, sui costi complessivi dell'applicazione [Deba 97].Un ritardo, ad esempio, di sei mesi pu�o comportare in media una perdita deipro�tti del 33%. �E stato calcolato che un aumento del 9% dei costi di pro-duzione pu�o determinare una perdita del 21% e che, se i costi di sviluppoaumentano del 50%, la perdita dei pro�tti stimata �e del 3%, [RASSP 98].

71

Tali valori fanno capire l'importanza dell'introduzione sul mercato di un pro-dotto nei tempi attesi.Esistono due modelli quantitativi che permettono di stimare le ripercussionieconomiche di un ritardo su mercato in termini di perdita economica:

� Modello triangolare sempli�cato, [Liu 95].

� Modello GSD, (Growth Stagnation Decline), [Levi 92].

Nelle �gure 6.1 e 6.2, ne vengono date le rispettive rappresentazioni gra�che.Sia 2W la �nestra di mercato stimata e sia D il ritardo di immisione. SianoR0 il ritorno atteso se il prodotto venisse immesso regolarmente sul mercato(D = 0), e sia RL, il ritorno che si ottiene con il ritardo D. La regione nonombreggiata (R0 � RL) rappresenta dunque la perdita corrispondente, \Lossin Revenue".

Figura 6.1: Modello triangolare.

Secondo il modello triangolare, relativamente alla �gura 6.1, vale la seguenterelazione:

R0 � RL = R0 �R0

2W 2� (W �D)(2W �D) (6.13)

Dalla equazione 6.13 si ottiene:

R0 �RL = R0 �D(3W �D)

2W 2(6.14)

72

Figura 6.2: Modello GSD.

Con il modello GSD, la presenza del prodotto sul mercato �e suddivisa intre fasi. La prima, W1, corrisponde ad una crescita del mercato, (marketgrowth phase). La seconda, S, �e la fase di maturit�a del prodotto, (stagnation),nella quale si suppone che le vendite si mantengano stabili. La terza fase,W2, �e associabile alla diminuzione delle vendite per l'introduzione di nuovegenerazioni e porter�a a interromperne l'immissione, (market decline).La perdita in questo caso �e:

R0 �RL = R0 �D(2W1 �D + 2S +W2)

W1(W1 +W2 + 2S)(6.15)

6.3 Stima dei costi

Prenderemo ora in considerazione i costi associati allo sviluppo di sistemi digi-tali. Supponiamo che il sistema i-esimo sia progettato from scratch e sia Sila sua dimensione espressa in SLOC. Ipotizzeremo inoltre che esista un modu-lo M , di dimensione SM , progettato per essere riusato (for reuse), che potr�aessere adattato e modi�cato, di volta in volta, in base alle esigenze. Valutere-mo inoltre la variazione dei costi nel caso si decida di realizzare quello stessosistema, andando ad integrare M con una progettazione with reuse. Vienedata una valutazione di come possano essere ridotti, adottando una strategiaorientata al riuso. In�ne, per avere una stima complessiva, verranno aggiuntianche i costi associati al Time to Market .A partire dal costo per anno-persona di $150k=anno [Keat 98], sia k un coe�-ciente espresso in $=pm associato al costo di una persona in un mese. Tenendo

73

conto dello sforzo Eff , dato dall'equazione 4.1, per sviluppare un genericoprogetto, il costo ad esso associato �e:

C = k � Eff (6.16)

Indichiamo allora con:

CFSi il costo di progettazione del sistema i senza riuso;

CRFM il costo per progettare il modulo M a�nch�e sia riusabile;

CWRi il costo di progettazione del sistema i, riusando M .

� Il costo per lo sviluppo del sistema in assenza di riuso.

CFSi = k � EffFSi

= k � A � (Si)B (6.17)

� Il costo per lo sviluppo del singolo modulo riusabile.

CFRM = k � EffFRM

= k � (DFRF ) � A � (SM)B (6.18)

� Il costo per lo sviluppo del sistema con il riuso.Nel caso di progetto con il riuso possiamo distinguere due fasi, a ciascunadelle quali �e associabile un costo. Vi �e infatti lo sviluppo della partespeci�ca del sistema, che deve essere progettata from scratch, e di quellache viene riusata e che richiede eventuali modi�che per l'integrazione.Indichiamo con �R la percentuale del sistema (in termini di linee dicodice) corrispondente a quest'ultima parte. Valgono allora le seguenti:

1. Costo di progettazione della parte speci�ca del sistema.

CFSi;sp = (1� �R) � C

FSi (6.19)

Se SM �e la dimensione della parte che non verr�a progettata fromscratch, grazie al riuso, l'equazione 6.19, pu�o essere riscritta come:

CFSi;sp = k �A � (Si � SM)B (6.20)

74

2. Costo di integrazione del componente riusabile.

CWRi;rp = k �EffWR

M

= k �A � ( ~SM)B (6.21)

Pertanto si ha:

CWRi = CFS

i;sp + CWRi;rp (6.22)

6.4 Costi e bene�ci del riuso

Fattori organizzativi, progettuali, cos�� come le caratteristiche speci�che deicomponenti, determinano il costo di un investimento nel riuso. I costi associa-ti all'analisi di dominio sono quelli che caratterizzano i processi e le attivit�acon cui �e possibile de�nire gli obiettivi dei componenti riusabili. Essi contri-buiscono alla loro realizzazione per classi di sistemi e ri ettono l'ampiezza ela maturit�a dell'area di applicazione speci�ca. Pi�u ampio e meno maturo �e ildominio, maggiore dovr�a essere l'investimento.Determinare l'architettura dei componenti riusabili impone di stabilirne i prin-cipi progettuali, la struttura e le reciproche relazioni. Nel caso esista unanotevole presenza sul mercato di componenti IP , l'investimento sar�a minore,sebbene, nel caso di una strategia interna del riuso esso dipenda direttamentedagli obiettivi pi�u o meno a lungo termine. Inoltre l'investimento riguardaanche la reingegnerizzazione dei moduli riusabili, in relazione con la loro strut-tura, documentazione e la facilit�a di comprensione. In�ne l'intero processo disviluppo per il riuso richiede un investimento maggiore quanto pi�u �e maturo ilprocesso stesso.Va inoltre considerata la necessit�a di investire nella creazione e mantenimentodi una libreria, tenendo conto che soprattutto quest'ultima attivit�a richiederisorse, in base alla stabilit�a dell'applicazione, alla tecnologia, all'ambiente edall'infrastruttura disponibili.Riepiloghiamo i costi associati al riuso, per darne poi una quanti�cazione eco-nomica [Hunt 96]. Un elemento importante �e rappresentato dal costo di man-tenimento (mantenance), considerato come bene�cio (in termini di costi nonsostenuti) quando lo si confronti con i costi di un nuova progettazione, svilup-po, documentazione, test.

Costi aggiuntivi del riuso

� Costi di analisi del dominio.

75

� Costi di individuazione (locating & assessing) dei componenti riusabili.

� Costi di modi�ca dei componenti riusabili.

� Costi di integrazione dei componenti riusabili.

� Costi di mantenimento dei componenti riusabili. I costi variano inversa-mente con la stabilit�a del settore, la tecnologia, l'ambiente e l'infrastrut-tura.

� Costi della veri�ca dei componenti modi�cati.

� Costo per lo sviluppo ed il supporto di tool EDA specializzati per ilriuso;

� Acquisto dei componenti riusabili.

� Costo per le \royalties" dei componenti riusabili.

� Costi per l'orientamento del personale al riuso.

Gli ultimi quattro punti sono spesso noti come costi aggiuntivi a livello \cor-porate". I bene�ci economici del riuso che un'azienda si aspetta di ottenere,non mancano. Sono essenzialmente coinvolgono l'aumento della qualit�a delprodotto �nale, una riduzione dei costi, dei tempi e dei rischi di progetto, unpi�u rapido ingresso sul mercato e dei costi di mantenimento inferiori.

Bene�ci del riuso

� Riduzione dei costi di progettazione.

� Riduzione dei costi di documentazione (interna).

� Riduzione dei costi di implementazione.

� Riduzione dei costi per la veri�ca del modulo.

� Riduzione dei costi di progettazione dei test bench.

� Riduzione dei costi di documentazione dei test bench.

� Riduzione dei costi per la veri�ca del modulo.

� Riduzione dei costi di mantenimento.

� Riduzione dei costi dei tool.

76

� Riduzione dei costi del personale.

� Riduzione dei costi di gestione.

� Riduzione del Time to Market.

� Prestigio aziendale sul mercato.

6.5 Ritorno d'investimento (ROI)

La consapevolezza dei costi aggiuntivi derivanti da una progettazione per ilriuso, impone di stimarne i bene�ci con un'analisi a medio e lungo termine. Ingenerale infatti, un ritorno di investmento, (ROI, Return of Investment), signi-�cativo �e raggiungibile soltanto con lo sviluppo di una linea di applicazioni oprodotti che preveda, un numero opportuno di riusi di uno stesso componente.Per fare un'analisi del rapporto Costi-Bene�ci, sono stati seguiti diversi ap-procci [Poul 97], ma, in ogni caso, il ROI �e interpretabile come una metrica,che o�re i seguenti vantaggi:

� Permette di valutare i bene�ci economici di una linea di sviluppo, e quindidi misurarne il successo dato che, nel caso speci�co, il riuso garantisceuna riduzione dei costi.

� Fornisce un modo per trovare la migliore alternativa nel caso esistanopi�u soluzioni ad uno stesso problema, ognuna con un proprio ROI. Ci�opu�o essere utile nel caso di stesura dei contratti, dove le decisioni devonoessere prese in base non soltanto ai costi ma anche ai bene�ci.

� Permette di giusti�care gli investimenti. Il riuso infatti \costa" pi�u diuna progettazione from scratch ed il ritorno non �e quasi mai immediatoma va visto a lungo termine.

I seguenti passi caratterizzano una decisione che si vuol prendere sulla basedel ritorno d'investimento migliore, associato ad una determinata scelta.

1. selezionare le probabili soluzioni sulla base delle alternative. La primaconsiste nell'avvalersi di sistemi \o� the shelf", se questo implica unrisparmio di tempo e denaro. Un'altra soluzione consiste nel riusarecomponenti soft, senza alcuna modi�ca, richiedendo per�o lo sviluppo edil mantenimento in librerie o direttamente l'acquisto. Una terza soluzione�e la modi�ca di componenti gi�a esistenti per adattarli alla nuova funzione,con i costi aggiuntivi derivanti da essa. Un altro approccio �e lo sviluppo

77

from scratch del componente di cui si ha bisogno e l'ultimo �e invece losviluppo a�nch�e possa essere riusato.

2. Determinare gli obiettivi prioritari. Ad esempio, �e pi�u utile realizzareuna libreria piuttosto che realizzare pi�u prodotti dello stesso tipo.

3. Determinare il periodo di tempo dell'analisi. Un progetto pu�o durare alungo, pertanto va tenuto presente il valore del denaro (time value of themoney).

4. Identi�care e quanti�care i costi ed i bene�ci per ognuna delle alternative,tenendo presente che ne esistono alcuni non immediatamente evidenticome il time to market, il mantenimento in librerie, e la qualit�a delcodice.

6.5.1 Stima del ritorno d'investimento (ROI)

Per valutare il ritorno di investimento, innanzitutto vanno calcolati i bene�ciderivanti dal riuso, cio�e Ca, \Cost Avoidance".Si calcola sottraendo dal costo relativo allo sviluppo nel caso di assenza di riusoquello che viene invece speso per il riuso. Il limite superiore �e rappresentatodalla \Riduzione di Costo Potenziale" (Ca�pot), determinata assumendo che ilcosto di integrazione (ed eventuale modi�ca) sia nullo.

Ca = CFSi � CWR

i (6.23)

Nella valutazione della 6.23, pu�o essere compresa anche la riduzione associataal mantenimento dei moduli riusabili, \Service Cost Avoidance" (Cs). Ipotiz-zando infatti che i moduli riusabili siano correttamente testati e sviluppati, sipotrebbe assumere che sia nulla la presenza di errori e quindi che il costo dimantenimento sia nullo. Pertanto il riuso, in questo caso, pu�o far risparmiareil costo richiesto per individuare l'eventuale errore ed eliminarlo:

Cs = ~SM � (Error Rate) � (Error Cost) (6.24)

dove Error Rate �e pari a 150 per KLOC e Error Cost �e di 100$ per errore.Bisogna per�o tener conto dei costi addizionali derivanti dallo sviluppo di moduliriusabili, sottraendo CFR

M .Poulin de�nisce il ROI, come la di�erenza tra il costo evitato grazie al riuso equello aggiuntivo. Esso �e noto anche come \Riduzione di Costo Netta (Ca�net).Riassumendo avremo:

ROIProject = Ca � CFRM (6.25)

78

Un seconda de�nizione si basa sul modello Henderson-Seller che rappresentauna estensione di quello di Barns e Bollinger, [Ouya 98]. Quest'ultimo de�-nisce un'equazione molto semplice per misurare l'investimento nel riuso sullabase di un'analisi del rapporto costi bene�ci. Si tratta di considerare la qualit�adel riuso (Q) esprimibile direttamente come:

Q =B

R(6.26)

ovvero come il rapporto tra il bene�cio del riuso B e l'investimento o costocorrispondente R. Pertanto, a Q < 1 corrisponder�a una perdita netta (\NetLoss"), mentre se Q > 1 il riuso �e un buon investimento in quel particolareprogetto.Il ROI, anche in questo caso, �e strettamente dipendente dai costi preceden-temente de�niti; costo del progetto complessivo in assenza di riuso, costo percercare componenti riusabili e modi�carli, costo di sviluppo di nuove compo-nenti e per produrre componenti riusabili.Il modello Henderson-Seller si basa sul concetto, peraltro intuitivo, secondocui:

\�e conveniente adottare una determinata strategia se i costi, adessa associati, sono inferiori ai bene�ci."

D�a una indicazione per calcolare investimento e bene�ci ed �e esprimibile, inpercentuale, come il rapporto tra risparmio e costo:

ROIProject =Ca

CFRi

(6.27)

Noi ci baseremo sulla de�nizione 6.25. Una valutazione complessiva del ROIdeve per�o essere fatta attraverso un'analisi a lungo termine e che coinvolgamolti progetti.

Poich�e pu�o estendersi a molti anni, ha senso introdurre la \Net Present Value"(NPV ), per calcolare i costi, nel caso non di un singolo progetto ma di unalinea di prodotti sviluppabile per almeno tre, cinque o pi�u anni.

NPV = �C0 +NXi=1

(Ri � Ci)

(1 + k)i(6.28)

dove:C0 rappresenta l'investimento iniziale nel riuso ;

79

Ri indica il ritorno d'investimento complessivo, esteso eventualmente a pi�uprogetti realizzati nell'anno i; Ci �e il costo aggiuntivo derivante dal riusocor-porate reuse cost in year I;N indica il periodo di tempo a cui si estende l'analisi;k rappresenta il discount rate (es: 15%).Pi�u in dettaglio, in base alla equazione 6.25, ipotizzando che lo stesso moduloM venga riusato n volte, potremmo anche scrivere:

ROIProduct Line =nXi=0

(CFSi � CWR

i )� CFRM (6.29)

Se poi, introduciamo nuovamente la variabile tempo, stimando di prolungarel'analisi per N anni, vale:

ROIProduct Line =NXt=0

(ntXi=1

(CFSi;t � CWR

i;t ))� CFRM (6.30)

Quest'ultima equazione deve essere completata sommando i costi relativi altime to market. Tale contributo, TTM , �e stato calcolato in [Marc 99]. sitratta di stimare la riduzione per un solo progetto. Dopodich�e, introducendola variabile temporale, vengono stimate complessivamente le entrate che nonandranno perse grazie ad una metodologia del riuso, in termini di ingressi sulmercato in tempi pi�u ridotti. Complessivamente dunque vale:

ROIReuse = ROIProduct Line + TTM (6.31)

80

Capitolo 7

Calcolo della dimensione del

progetto

Una metrica per stimare la dimensione del progetto �e uno strumento utilenon soltanto a migliorare le analisi dei costi e dei tempi di un progetto, maanche a comprendere meglio e monitorare il processo di sviluppo e piani�carnecos�� la gestione. Le metriche ritenute pi�u idonee per la stima della dimensionedi un progetto sono la metrica delle \Lines of Code" e quella dei \FunctionPoint".Il particolare ambiente di lavoro, cio�e la progettazione di sistemi digitali, e lecaratteristiche del VHDL, non consentono l'impiego di queste metriche cos��come sono presenti in letteratura.Per avere risultati corretti, vanno rivisti i criteri di valutazione delle speci�checalibrandoli attraverso un'analisi di progetti esistenti.

7.1 Concetto di metrica

La piani�cazione del progetto impone di realizzare delle stime, tra le quali laprima e pi�u importante �e misurare il progetto per stimarne la dimensione.Misurare, infatti, rappresenta il primo passo per dare una predizione dei costi edei tempi di sviluppo ma anche per migliorare il processo produttivo, valutarel'e�cacia del gruppo di lavoro, confrontare tra loro i progetti e identi�care queifattori che in uenzano la produttivit�a. Le maggiori problematiche sono, peral-tro, riconducibili al fatto che spesso la stima non �e su�cientemente accurata ed�e, al contrario, al di sotto della misura del progetto realmente raggiunta, una

81

volta sviluppato. La maggior parte degli esperti infatti tende a sottostimare,dal 50% al 150%, il valore dei progetti soprattutto se di grandi dimensioni,rischiando cos�� di scoprire di non poter completare il progetto nei tempi e costiprevisti, con pesanti ripercussioni da un punto di vista economico, tecnico emanageriale.Nella maggior parte dei modelli per la stima dello sforzo di sviluppo per grandiapplicativi software, la dimensione del codice �e il fattore pi�u importante.Il dimensionamento del progetto, nel caso speci�co del modello proposto, pu�oessere realizzato principalmente secondo due prospettive, ovvero attraverso:

� misure tecniche che dipendono dallo sviluppo e dalle scelte nella fase discrittura del codice, come nel caso della metrica basata sulle \linee dicodice";

� misure funzionali che tengono conto delle funzionalit�a attese dal sistema,come per la metrica dei \punti funzione".

7.2 Il progetto \LEON"

Per avere la stima dello sforzo di sviluppo di un progetto, si pu�o utilizzarel'equazione 4.1, riportata sotto:

Eff = A � SB (7.1)

Un elemento fondamentale di tale stima �e la dimensione del codice indicatacon il parametro S che esprime il numero di linee di codice dell'applicazione.Come espresso nel paragrafo precedente, tale stima viene ottenuta con l'uti-lizzo di una delle due metriche citate. Poich�e in letteratura non �e possibilereperire una documentazione adeguata, considerando il particolare ambientedi sviluppo, cio�e la progettazione di sistemi digitali, e le caratteristiche dellinguaggio impiegato, il VHDL, abbiamo considerato per la validazione dellemetriche il progetto \LEON ".

Descrizione funzionale di LEON-1

LEON-1 �e un processore a 32 bit che implementa l'architettura SPARC V8. �Eprogettato per applicazioni embedded ed ha le seguenti caratteristiche: istruc-tion e data cache separati, bus di memoria con supporto EDAC a 32 bit,PROM e SRAM, un interrupt controller, due timer a 24 bit, due UARTs, unafunction power-down ed un watchdog. Il diagramma a blocchi corrispondente�e riportato in �gura 7.1 mentre, per una descrizione completa delle singolefunzionalit�a, si rimanda a [LEON a].

82

L'analisi del codice VHDL corrispondente, [LEON b], �e stata realizzatacon il tool commerciale \PROTON " proposto da LEDA (Synopsys) che verr�adescritto nel capitolo 8. Nella tabella 7.1, per ogni �le �e riportato il numero

Entity/Package File Name LOC e�ettive Funzionalit�a

LEON leon.vhd 219 LEON top level entity

LEON PCI leon pci.vhd 211 LEON/PCI top level entity

LEON CLOCKGEN clkgen.vhd 75 Clock generator

LEON MCORE mcore.vhd 241 Main core

LEON MCORE RSTGEN rstgen.vhd 61 Reset generator

LEON MCORE DMA dma.vhd 138 DMA controller

LEON MCORE MCTRL mctrl.vhd 1103 Memory controller

LEON MCORE PROC proc.vhd 166 Processor core

LEON MCORE PROC CACHE cache.vhd 112 Cache module

LEON MCORE PROC CACHE CACHEMEM cachemem.vhd 228 Cache ram

LEON MCORE PROC CACHE DCACHE dcache.vhd 508 Data cache controller

LEON MCORE PROC CACHE ICACHE icache.vhd 341 Instruction cache controlle

LEON MCORE PROC IU iu.vhd 2255 Processor Integer unit

LEON MCORE PROC REGFILE reg�le.vhd 204 processor register �le

LEON MCORE PERI peri.vhd 162 Peripherical module

LEON MCORE PERI IRQCTRL irqctrl.vhd 143 Interrupt controller

LEON MCORE PERI IOPORT ioport.vhd 180 Parallel I/O port

LEON MCORE PERI TIMER timer.vhd 227 Timers & watchdog

LEON MCORE PERI UART uarts.vhd 395 UARTs

LEON PADS pads.vhd 840 I/Opads

Tabella 7.1: LEON: Modello VHDL.

di righe e�ettive e la funzionalit�a corrispondente.

83

ICACHE DCACHE

IRQCTRL

TIMERS

UARTS

WDOG

IOPORT

PROM SRAM I/O

LEON IU

MEIKO FPU

DMA

BUS I/F

EDAC

Wdog

I/O

RxTx

Reset

Clk

LEON-1

Figura 7.1: Diagramma a blocchi di LEON-1.

7.3 La metrica delle lines of code

La stima della dimensione del progetto viene a�rontata in funzione del nu-mero di linee scritte in codice VHDL, corrispondenti sia alla descrizione dellefunzionalit�a del sistema, sia ai test-bench impiegati nella simulazione, ovvero:

S = SFunctionalities + STest�Bench (7.2)

L'obiettivo �e misurare la quantit�a di lavoro intellettuale e viene qui risoltoosservando il problema dal punto di vista del progettista e quindi assumeparticolare importanza la modalit�a di stesura del codice.

Le di�colt�a nel de�nire una misura consistente di un'applicazione, in ba-se alle linee di codice nei vari linguaggi sono state minimizzate dal SoftwareEngineering Istitute (SEI ), che ne ha dato una checklist per il conteggio.

La dimensione S dell'applicazione, indicativamente, si ottiene sottraendodal numero totale delle linee, comprese le dichiarazioni, quelle di commento equelle appartenenti ad altri programmi, inseriti senza alcuna modi�ca.I vantaggi di questa scelta devono essere ricercati prima di tutto nella facilit�adi stimare il numero di LOC (Lines Of Code) di un programma, dato che si

84

basano su concetti comunque familiari agli sviluppatori. Allo stesso tempo �ela metrica pi�u di�usa, per la quale esiste il maggior numero di dati storici.Non vi �e dubbio per�o, che altrettante critiche potrebbero esserle rivolte: di-pende fortemente dalla capacit�a del programmatore; non tutte le istruzione dicodice hanno la stessa complessit�a e potenza, soprattutto in linguaggi come ilVHDL; in�ne esistono delle libere interpretazioni sulla gestione delle istruzionispezzate su pi�u linee.La valutazione della dimensione, inoltre, si basa su stime fornite dai progetti-sti e, in quanto tale, non pu�o esserne trascurata l'alta variabilit�a. Pertanto, �epreferibile ridurre il margine di errore assumendo una speci�ca densit�a di pro-babilit�a per ricavarne la dimensione attesa sulla base dei dati forniti. A taleproposito, esistono due metodi principali, [Ghez 94]. Il primo prevede che ladimensione abbia una densit�a di probabilit�a normale e, quindi, richiede unastima iniziale della dimensione minima e massima (Smin e SMAX). Il secondoinvece consente una stima pi�u accurata, avvalendosi di una distribuzione diprobabilit�a beta. In questo caso �e richiesta, oltre alle precedenti, anche unastima della dimensione verosimile (Sv).

7.3.1 Descrizione e validazione della metrica delle \linesof code"

La stima delle righe di codice necessarie per la descrizione di un progetto vie-ne realizzata avendo a disposizione le speci�che e soprattutto, dal un puntodi vista del progettista. �E necessaria una partizione del progetto in diverseunit�a a partire dallo stile di codi�ca (ovvero behavioral o RT). Si tratta diun'operazione precedente alla scrittura del codice che permette la suddivisionein moduli (�le) mediante de�nizione della gerarchia e della implementazione�nale degli algoritmi. �E possibile valutare il numero delle righe che compon-gono un modulo analizzando diversi aspetti della sua architettura ricavabilidirettamente dalle speci�che di progetto.

� port (IO)

� signal

� concurrent statement ;

� package, library.

7.3.2 Costrutti concorrenti

I concurrent statement sono:

85

� cuncurrent assertion statement;

� block statement;

� conditional signal assignement;

� generate statement;

� procedure call statement (contributo negativo)

� process statement

� select signala ssignement

� component instantiation assignement

In particolare, trattandosi di un linguaggio strutturato, potremmo ipotizzarelo sviluppo delle entity che potremmo associare ad un grafo dove i componentrappresentano i nodi ed i process le foglie.

Process

Il costrutto process bench�e normalmente sintetizzabile presenta una descrizionecomportamentale; contiene normalmente le parti implementative algoritmichedel progetto. Le sue dimensioni sono fortemente dipendenti dal numero deisegnali trattati, di cui quelli presenti nella sensitivity list sono solo una parte.Dato il carattere comportamentale del costrutto, le operazioni vengono svoltesu dati omogenei, indipendentemente dalla loro dimensione e dalla loro na-tura, semplice o strutturata. Quindi vettori e variabili (o segnali) elementarihanno lo stesso peso (1), mentre i record ovvero i tipi di dato strutturato nonomogenei vanno decomposti in vettori e segnali. Da analisi e�ettuate sul co-dice di \LEON ", il numero di righe e�ettive costituenti un process �e legato alnumero di segnali trattati al suo interno con una legge di tipo parabolico. Irisultati ottenuti sono riportati nella tabella 7.2. La curva ottenuta rappresen-ta l'andamento del numero di righe di codice in funzione dei segnali trattati.Nella �gura 7.2 sono indicati i punti sperimentali e la curva di interpolazione,ottenuta con la stima dei minimi quadrati, la cui equazione �e:

y = 0:0784x2 � 0:3777x+ 27:133 (7.3)

86

Process Elementi della Elementi della Bit Elementi della S. L. \estesi" Linee di

Sensitivity List S. L. \estesi" utilizzati codice

fetch stage 5 42 418 13 43

decode stage 13 162 1218 109 900

execute stage 9 155 1044 80 567

memory stage 9 139 793 45 161

write stage 7 115 806 66 292

Tabella 7.2: Analisi dei process nel �le \iu.vhd".

0 20 40 60 80 100 1200

200

400

600

800

1000

1200

Figura 7.2: Curva di interpolazione.

Component

L'istanza di un component �e un'operazione che rivela una visione gerarchicadella realizzazione del progetto. Del component sostanzialmente viene ripor-tata l'interfaccia, sia nella parte dichiarativa dell'architecture che in quellaimplementativa con il costrutto port map.Il numero delle righe sar�a quindi dello stesso ordine di grandezza del numerodei segnali trattati, indicati dalla dichiarazione di interfaccia del component.

87

7.4 La metrica dei Function Points VHDL

La metrica dei \Function Points VHDL" permette una misura della dimensio-ne del progetto che si sta realizzando in termini delle funzionalit�a che andrannoimplementate, indipendentemente dal linguaggio, dalla metodologia di svilup-po e dalla tecnologia [Cape 97]. Questa metrica, utilizzata a partire dallespeci�che e non dal codice, ha diversi obiettivi, tra i quali la stima dell'im-pegno di sviluppo del progetto, la valutazione dei componenti esistenti ed ilconfronto di qualit�a tra gli stessi. Il calcolo pu�o essere realizzato per tipologiediverse di applicazione:

� Sviluppo di nuovi progetti.

� Manutenzione dei progetti gi�a esistenti.

� Modi�ca di progetti gi�a esistenti.

Restringeremo l'attenzione allo sviluppo di nuovi progetti, descrivendo unametrica che si basa direttamente su quella dei \Function Points" per lo svi-luppo di applicazioni in Ingegneria del Software, opportunamente estesa allaprogettazione di sistemi digitali.Essa si basa sulla de�nizione di classi, o categorie funzionali le cui istanze cor-rispondono alle entit�a della speci�ca del sistema, che verranno descritte nelparagrafo successivo. Ad ogni istanza di una classe funzionale viene attribuitoun peso dipendente dalla sua complessit�a. Calcolato il peso di ognuna di esse,�e possibile convertire il valore F nel corrispondente, S, in termini di linee dicodice, che verr�a utilizzato nell'equazione 4.1 del modello di stima.

7.4.1 La speci�ca e le unit�a funzionali

La speci�ca pu�o essere descritta da viste di�erenti, comportamentale e struttu-rale, ed a pi�u livelli, secondo il modello descritto nel paragrafo 2.2. Rispetto atale impostazione, potremmo ipotizzare che esista un livello superiore a quellofunzionale.Si tratta del livello concettuale, nel quale collochiamo la speci�ca di ingressoalla metrica dei Function Point VHDL. A tale livello, secondo una rappresen-tazione comportamentale, la descrizione delle funzionalit�a non �e unica. Infatti,per gestirne al meglio la complessit�a �e possibile descrivere la stessa speci�caper:

� livelli di astrazione, in modo da caratterizzare con un approccio top-down maggiori dettagli.

88

� livelli di completezza, attraverso una caratterizzazione a partire daglielementi pi�u importanti �no a quelli marginali.

� livelli di rigorosit�a, con una serie di ra�namenti successivi che per-mettano di ridurre la genericit�a della descrizione.

� livelli di risoluzione, con cui abbassare il livello di granularit�a delladescrizione.

In questo modo, si pu�o giungere, attraverso una serie di ra�namenti successivi,a de�nirne lo spazio delle possibili soluzioni secondo la vista strutturale.Ipotizzeremo di trattare, sfruttando i livelli precedentemente indicati, una spe-ci�ca che sia completa, consistente, rigorosa e realizzabile.La speci�ca concettuale descrive le funzionalit�a proprie del sistema che deveessere realizzato [Mezz 99].Tale descrizione riguarda le seguenti entit�a:

� Aspetti temporali cio�e il comportamento temporale di stati, di eventi edelle correlazioni tra questi.

� Oggetti cio�e i dispositivi o componenti atomici, che lo costituiscono.

� Interazioni interne ed esterne, ovvero rispettivamente i collegamenti tragli oggetti, e le interfacce con gli altri componenti.

� Sottosistemi cio�e gruppi di oggetti connessi tra loro che presentano unbuon grado di autonomia.

� Sistemi cio�e gli aggregati con elevata autonomia.

Vanno ovviamente considerate le entit�a che andranno realmente sviluppateall'interno del progetto e che realizzano tutte le funzionalit�a attese per:

� acquisizione dell'informazione;

� elaborazione sequenziale e combinatoria dell'informazione;

� accesso alla memoria;

� emissione dell'informazione.

89

7.4.2 Calcolo dei \Punti Funzione VHDL"

Per calcolare i Function Points VHDL, si fa appartenere ogni entit�a descrittanella speci�ca ad una delle seguenti Unit�a o Categorie Funzionali :

� Ingressi primari

� Uscite primarie

� Blocchi basici

� Segnali interni

� Segnali di interfaccia

Per calcolare il valore FPV HDL per un sistema che si vuol realizzare, va calcola-to il contributo di ogni unit�a in funzione della propria complessit�a [EFPA 99].Si procede come segue:

Unit�a funzionali Molto bassa Bassa Media Alta Molto altaVL L A H VH

Ingressi Primari 1 3 4 6 10Uscite Primarie 2 4 5 7 11Blocchi Basici 2 5 7 10 13Segnali Interni 2 5 7 10 13Segnali di Interfaccia 2 5 7 10 13

Tabella 7.3: Pesi associati alla complessit�a delle Unit�a Funzionali.

1. Presa un'unit�a, ad ogni suo elemento viene attribuito un peso in base allapropria complessit�a . In riferimento alla tabella 7.3, ogni elemento pu�oavere complessit�a molto bassa, bassa, media, alta e molto alta. Tale peso�e funzione di alcune caratteristiche e parametri derivabili a partire dallaspeci�ca. Pertanto, data l'unit�a funzionale k, contenente mk elementivale la seguente:

FPk =

Pmk

i=1(ek;i � wk;i)

mk

(7.4)

dove wk;i �e il peso corrispondente alla i-esimo elemento della classe k,ek;i.Il contributo dell'unit�a viene cio�e stimato considerando la media deicontributi dei suoi elementi. La metrica infatti richiede un valore cheriassuma la complessit�a globale delle entit�a descritte nella speci�ca.

90

2. Allora, il valore FPV HDL associato al sistema descritto nella speci�ca �e:

FPV HDL =5X

k=1

FPk (7.5)

Descriviamo meglio le caratteristiche ed i parametri con i quali viene associatoun grado di complessit�a ad ogni elemento di una unit�a funzionale.Il usso di informazione, dati e controllo, avviene in VHDL attraverso un ussodi variabili e segnali. Questi possono essere elementari, raggruppati in vettorio strutturati in record.De�niamo dato omogeneo una variabile o un segnale elementare, un vettorese il codice �e behavioral o se tale �e il costrutto che lo contiene (process). Seinvece il codice �e RT, il vettore contiene tanti dati omogenei quanti sono i suoicomponenti elementari. Nel caso in cui l'informazione sia rappresentata da unrecord, questo andr�a valutato come somma dei suoi campi.

Ingressi Primari

L'unit�a funzionale \Ingressi primari" contiene gli ingressi provenienti dal con-�ne del sistema in oggetto. Sono cio�e gli ingressi provenienti dal con�ne delsistema in oggetto sia di controllo come clock e reset sia dati che provengonodall'esterno [EFPA 99].Il grado di complessit�a di un elemento dell'unit�a \Ingressi primari" dipende

Componenti Daticoinvolti omogenei

1-2 3-4 5-11 12-19 20-

1 VL VL L L A2 VL L A A H3-4 L A A A H5-6 L A A H VH7 - A H H VH VH

Tabella 7.4: Complessit�a della classe \Ingressi Primari".

da:

� gruppo omogeneo di dati che costituisce l'ingresso; cio�e dalla sua dimen-sione e dalla sua natura (variabile, vettore, record).

91

� numero di blocchi raggiunti; cio�e dal suo contributo alla comunicazioneinterna del sistema e quindi all'aggiornamento dei segnali in seguito adun evento sull'ingresso considerato.

Il contributo dell'unit�a \Ingressi Primari" viene stimato considerando la mediadei contributi dei suoi elementi.

Uscite Primarie

Con l'unit�a funzionale \Uscite Primarie" si considera l'uscita del sistema. Sitratta cio�e di determinare i segnali diretti all'esterno del con�ne del sistema,la cui complessit�a, analogamente a quelli di ingresso, �e funzione di

� gruppo omogeneo di dati che costituisce il segnale di uscita;

� numero di blocchi che sono necessari per produrla.

Componenti Daticoinvolti omogenei

1-4 5-10 11-18 19-26 27

1 VL VL L L A2-3 VL L A A H4-5 L A A A H6-9 L A A H VH10- A H H VH VH

Tabella 7.5: Complessit�a dell'unit�a \Uscite Primarie".

Il contributo dell'unit�a \Uscite primarie" viene stimato considerando la mediadei contributi dei suoi elementi. La metrica infatti richiede un valore cheriassuma la complessit�a globale delle uscite del sistema.

Segnali Interni

La classe funzionale \Segnali Interni" comprende gruppi omogenei di dati edinformazioni di controllo scambiati tra i componenti ed i sottosistemi. Il gradodi complessit�a di un segnale interno �e funzione del numero di dati omogeneiche lo costituiscono, come riportato in tabella 7.6.

92

Dati omogenei

1-3 4-6 7-16 17-35 36-VL L A H VH

Tabella 7.6: Complessit�a della classe \Segnali Interni".

Segnali di Interfaccia

La classe funzionale \Segnali di interfaccia" comprende gruppi omogenei didati ed informazioni di controllo scambiati tra il blocco basico che si sta ana-lizzando e gli altri. In particolare, appartengono a questa classe anche i segnalidel sistema e altri sistemi o dispositivi esterni. Il grado di complessit�a di questaclasse �e funzione del numero totale di dati omogenei, come riportato in tabella7.7.

Dati omogenei

Numero di segnali 1-4 5-9 10-30 31-60 61-Complessit�a VL L A H VH

Tabella 7.7: Complessit�a della classe \Segnali di Interfaccia".

Blocchi basici

La classe funzionale \Blocchi basici" ha come istanze i blocchi individuabilidalla speci�ca. Si considerano blocchi basici, ad ognuno dei quali viene at-tribuita una complessit�a: il sistema, i sottosistemi in cui �e decomposto e isottocomponenti atomici di questi ultimi. Si tratta cio�e di individuare tutte lefunzionalit�a del sistema, alle quali corrisponder�a successivamente, nella fase disviluppo, la scrittura in VHDL delle entity con component e/o process. Inoltredeve essere considerato blocco basico il sistema \aggiunto" la cui funzionalit�acorrisponde ai test bench del sistema di partenza.La complessit�a di ogni blocco basico �e espressa sulla base di:

� numero dei sottoblocchi concorrenti che lo costituiscono;

� livello di comunicazione tra sottoblocchi, esprimibile in funzione dellacomplessit�a dei segnali interni ed esterni.

Il grado di complessit�a �e determinabile attraverso la tabella 7.8, [EFPA 99].

93

Sottoblocchi Livello di comunicazioneconcorrenti Molto basso Basso Medio Alto Molto Alto

1-2 VL VL L L A3-4 VL L L A A5-6 L L A A A7-9 L A A H VH10- A A H H VH

Tabella 7.8: Complessit�a della classe \Blocchi Basici".

7.4.3 Legame tra FPV HDL e LOC

Language Level LOC=FPV HDLC 2.5 128Ada83 4.5 71Ada95 6.5 49Lisp 5 64VHDL 17 19

Tabella 7.9: Conversione delle metriche e livelli.

Language Level Productivity averageper sta� month

1-3 5 to 10 FPV HDL4-8 10 to 20 FPV HDL9-15 16 to 23 FPV HDL16-23 15 to 30 FPV HDL24-55 30 to 50 FPV HDL56- 40 to 100 FPV HDL

Tabella 7.10: Produttivit�a media dei \Function Point".

Il livello numerico di un linguaggio di programmazione rappresenta il fattoredi conversione per passare dal numero di linee di codice di un linguaggio i adun altro j, in base alla seguente proporzione:

LOCj = LOCi �livilivj

(7.6)

94

Inoltre il livello di un linguaggio �e in relazione, peraltro non lineare, con laproduttivit�a associata alla scrittura del codice, come indicato nella tabella7.10. In Ingegneria del Software, si stima che il 30% dell'e�ort complessivoper lo sviluppo di un'applicazione, sia destinato a questa fase. Se, ad esempio,confrontiamo due linguaggi, di livello 3 e 6, allora l'e�ort di codi�ca potrebbeessere ridotto del 50% ma quello corrispondente all'intero sviluppo del progettopotrebbe migliorare del 15%.

7.5 Validazione della metrica FPVHDL

Trattiamo ora direttamente la validazione della metrica Function Point VHDL,con esempi di stima applicati a moduli del progetto LEON; di questo sono stateanalizzate alcune entit�a funzionali alle quali �e stata applicata la metodologiaproposta nel paragrafo 7.4.2. Si utilizzano per l'assegnazione dei pesi le tabelle7.4, 7.5, 7.6, 7.7, 7.8 e 7.3.

Timer & Watchdog

L'unit�a \Timer & Watchdog" implementa due timer da 24 bit, un watchdog da24 bit ed un prescaler condiviso da 10 bit di cui ne �e data una rappresentazionein �gura 7.3. Nella tabella 7.11 sono riportati i valori numerici relativi al

prescaler value

prescaler reload

-1

-1

timer1 reload

timer2 reload

timer2 value

timer1 value

watchdogtick WDOG

irq 9

irq 8

Figura 7.3: Diagramma a blocchi dell'unit�a TIMER.

calcolo dei FPV HDL corrispondenti.L'unit�a \Ingressi Primari" contiene: due ingressi elementari che coinvolgonoun sottocomponente (complessit�a molto bassa) ed un record composto da seisegnali elementari diretto al componente di interfaccia formato da tre registridi reload (complessit�a molto bassa).L'unit�a \Uscite Primarie" contiene due record, di due e tre campi, entrambi

95

Unit�a funzionale Complessit�a Peso

Ingressi Primari 1�(V L=1)+1�(V L)+1�(V L)3

1

Uscite Primarie 1�(V L=2)+1�(V L)2

2

Segnali interni 2�(V L=2)+2�(A=7)4

4.3

Segnali di interfaccia assenti

Sottocomponenti: 3Blocco basico Liv. di comunicazione: basso 5

FPV HDL = 12:3

LOC = 12:3 � 19 �= 230

Tabella 7.11: Calcolo dei FPV HDL associati alla entit�a della speci�ca \Timerunit".

prodotti da un solo componente.L'unit�a \Segnali interni" contiene due record con pi�u di 36 elementi (com-plessit�a media) e un vettore di tre elementi ed un segnale standard logic(complessit�a molto bassa).

UARTs

In LEON sono presenti due UARTs per la comunicazione seriale, [LEON a].La �gura 7.4 ne d�a una rappresentazione.Dall'analisi della speci�ca si ottengono le informazioni riportate in tabella

7.12.L'unit�a \Ingressi Primari" contiene: tre ingressi elementari che coinvolgono tresottocomponenti (complessit�a media) e due ingressi strutturati (record) direttiad un solo sottocomponente (complessit�a media).L'unit�a \Uscite Primarie" contiene due elementi, entrambi di complessit�a bas-sa.

96

receiver shift register

Transmit holding register

Trasmitter shift register

Baud-rate

generator

Serial Port

Controller

Receiver holding register

Internal I/O bus

8*bitclk

TXDRXD

CTSN

RSTN

Figura 7.4: Diagramma a blocchi di UART.

Classe funzionale Complessit�a Peso

Ingressi primari 1�(A=3)+1�(A)+1�(A)+1�(A)+1�(A)5

3

Uscite primarie 1�(L=4)+1�(L)2

4

Segnali Interni 1�(V L=2)+2�(H=10)3

7

Segnali di Interfaccia assenti

Blocco Basico Sottocomponenti: 6Liv. di comunicazione: media 7

FPV HDL = 21

LOC = 21 � 19 = 399

Tabella 7.12: Calcolo dei FPV HDL associati alla entit�a \UART unit".

L'unit�a \Segnali interni" contiene un vettore (complessit�a molto bassa) e duerecord ognuno da 34 elementi (complessit�a alta).

97

Capitolo 8

Strumenti di valutazione del

codice

La progettazione di sistemi di grandi dimensioni viene a�rontata con lin-guaggi di descrizione ad alto livello di astrazione quali il VHDL. La potenza ditali linguaggi si ri ette nella loro complessit�a e nella molteplicit�a dei costruttiche supportano. La gestione del codice diventa quindi un'operazione non fa-cile e comunque dispendiosa soprattutto se svolta manualmente. D'atra parteil rigore intriseco in tali descrizioni consente un approccio automatico, nonsolo in fase di simulazione o sintesi, ma anche per una valutazione di alcunecaratteristiche del codice.

8.1 L'impego di strumenti automatici

Nel capitolo 7 sono state esposte due tipologia di metriche per il dimensiona-mento del progetto in temini di linee di codice: la metrica dei punti funzioneVHDL e la metrica delle linee di codice.

La prima ri ette una visione delle funzionalit�a del progetto e procede dal-l'analisi delle speci�che: viene svolto un partizionamento del progetti in unit�afunzionali e ne viene data una stima riassunta in una serie di valori numerici.Il codice non viene quindi preso in considerazione direttamente, anche se �epossibile comunque stimarne le dimensioni.

La metrica delle linee di codice procede anch'essa dalle speci�che di proget-to ma �e strettamente legata all'implementazione e�ettiva, alle strategie scelte,dalla struttura gerarchica alle tipologie degli algoritmi implementati; anzi do-vrebbe essere calcolata immediatamente o contemporaneamente all'organizza-zione stessa di progetto.

99

Esiste quindi un forte legame fra tale metrica e l'implementazione del progetto,quindi anche per quanto concerne i costrutti sintattici e la semantica.

Tali metriche possono essere in parte automatizzate (validate) attraversol'uso di un Rules Checker come ProVHDL.

VHDL �e attualmente usato come linguaggio di speci�ca in ingresso a di-versi tipi di tool. Tali strumenti vengono usati in un numerosi domini diapplicazione: veri�ca di qualit�a, del corretto utilizzo di determinate metodo-logie, testabilit�a, veri�ca formale, compatibilit�a con strumenti CAD, sintesi esimulazione.

Questo avviene per due ragioni: VHDL �e uno standard de�nito dalla IEEEe in secondo luogo �e un linguaggio di descrizione molto potente in grado disoddisfare le richieste di modellizzazione dei domini di applicazione sopracitati.La singola applicazione non richiede normalmente la completa potenzialit�aespressiva del VHDL: accade in genere che venga utilizzato solo un sottoinsiemedel VHDL; a questo proposito la sintesi rappresenta un esempio signi�cativo.

Sebbene il VHDL sia uno standard a�ermato, lo stesso non si pu�o diredei suoi sottoinsiemi: per le singole applicazioni esistono invece, per ragionicommerciali, diversi standard de � facto; questo rende di�coltoso scriverecodice VHDL che sia portabile e riusabile, anche all'interno del singolo dominioe il problema diventa anche maggiore quando una stessa descrizione deve essereusata in diverse applicazioni, come nel caso di un modello che debba essere siasintetizzabile sia formalmente veri�cabile.

A�ermate compagnie operanti nel settore EDA a�ancano Rules Checkera strumenti di traduzione per velocizzare il processo di progettazione ed incre-mentare il livello di condivisione fra fornitori di celle IP. Attualmente esiste un\productivity gap" tra le tecnologie di speci�ca ad alto livello, dove le celle IPsono concepite per essere riusate e le correnti tecnologie di sintesi. Per colmarequesto divario possono essere forniti ai progettisti degli insiemi di regole chepermettano il riuso di celle IP veri�candone la compatibilit�a con un progettooppure uno standard.

Qui e nelle pagine seguenti si �e scelto di mantenere in inglese le parole chiaveinerenti alla descrizione di questo strumento per avere una maggior aderenzacon i comandi presenti nelle interfacce e con i manuali.

Il problema iniziale che si pone non appena si vuole fare un qualsiasi tipodi analisi su una descrizione in VHDL �e quello dell'interpretazione del codicescritto e del riconoscimento dei costrutti fondamentali del linguaggio.

Occorre eseguire il "parsing" del �le di partenza per potere acquisire leinformazioni necessarie per le analisi che si devono svolgere successivamente.Quest'ultima operazione, almeno a livello concettuale, non presenta di�colt�a,considerando nota la grammatica del linguaggio. Le complicazioni si incon-

100

trano quando si voglia realizzare lo strumento software che esegue l'analisisintattica di un codice scritto, in particolare in VHDL.

Data la complessit�a e la variet�a dei costrutti presenti in VHDL, si �e deci-so di utilizzare uno strumento gi�a presente sul mercato che esegua un'analisisintattica e semantica di un �le scritto in VHDL: \LEDA VHDL System":in seguito LVS, [Leda 99] che �e un prodotto commerciale utilizzato anche inmolti strumenti EDA sul mercato.

8.2 Codi�ca standard, stili di codi�ca

Uno stile di codi�ca viene de�nito attraverso diversi tipi di regole che com-prendono anche convenzioni e semplici raccomandazioni.

I diversi stili nascono come soluzione a determinati problemi che si incon-trano nella gestione dei programmi e spesso costituiscono la formalizzazionedi tali soluzioni; le diverse modalit�a con cui produrre codice, insieme ad al-tre tematiche tipiche dell'ingegneria del software consentono di ottenere uncodice di maggiore qualit�a, pi�u e�ciente o almeno meglio utilizzabile all'in-terno di un progetto. Lo stile di codi�ca diventa allora uno degli strumenticon cui realizzare un progetto e la scelta dipende dal contesto, dall'ambientedi sviluppo e dalle risorse disponibili, dalle dimensioni del progetto e dal tipodell'applicazione che tale progetto implementa.

La de�nizione di linee guida per la codi�ca non �e in grado di garantirne tut-tavia il rispetto, anzi spesso queste vengono ignorate; il singolo programmatoreavr�a infatti comunque un proprio stile di codi�ca che dipende da caratteristi-che personali e da esperienze pregresse. Gli strumenti di veri�ca diventanoindispensabili per garantire il rispetto delle linee guida: innanzitutto quandosi utilizza un tool di questo tipo le regole non possono pi�u essere espresse sem-plicemente in linguaggio naturale ma devono venire formulate in modo precisonel linguaggio previsto dallo strumento veri�catore, perdendo in questo modola potenziale ambiguit�a insita nel liguaggio naturale stesso; la veri�ca �e unaoperazione veloce e pu�o essere inserita in diversi punti del usso di progettosenza particolari inconvenienti; inoltre non viene richiesto al programmatoredi stravolgere il proprio stile di programmazione ma di vincolarlo al rispettodelle norme comuni a tutto l'ambiente di sviluppo del progetto.

Le cause che portano a scegliere un certo stile di codi�ca VHDL sono molte-plici e alcune in contrapposizione: Design Methodology, Modeling Guidelines,Quality Assurance, Reuse, Guidelines for Documentation & Readability, Syn-thesis Modeling Rules, Design for Testability Rules, Cycle-based SimulationConstraints.

101

Le regole che determinano una codi�ca standard si possono classi�care comesegue:

� Regole generali: relative alla necessit�a di un buon stile di programma-zione, valide per qualsiasi tipo di linguaggio, quindi anche per VHDL.

� Regole V HDL: impongono vincoli sull'uso del VHDL dal punto divista semantico e sintattico. Ne sono esempi: includere il divieto dielse clauses negli ifstatements. Questo tipo di regole viene in ge-nere imposto per aumentare la qualit�a e riusabilit�a del codice oppureper assicurare la compatibilit�a con tool per il usso di progetto. Inparticolare possono essere determinate regole relative a codice RTL ocomportamentale.

� Regole relative all'Applicazione: impongono vincoli sulla semantica VHDLpermessa da certe applicazioni come sintesi o simulazioni cycle-based. Inparticolare queste regole implementatano i vincoli imposti dai diversitool.

� Regole relative ai File: impongono restrizioni sulle caratteristiche dei�le come numero di unit�a VHDL per �le, nomi, inclusioni di partico-lari header o commenti. Tali restrizioni aumentano la leggibilit�a e lariusabilit�a del codice.

� Regole relative ai Commenti: trattano il contenuto dei commenti; adesempio gli header comment di un'entity devono contenere l'elenco delleporte dichiarate nell'entity. Sono regole per migliorare la produzione didocumentazione del software.

� Regole di Layout: impongono restrizioni sulla presentazione del codiceVHDL. Ad esempio si pu�o imporre che sia permesso un solo statementper riga e che ogni indentazione sia di tre spazi o che il �le abbia unnumero massimo di righe. Le regole di layout essentialmente miglioranola documentazione e la leggibilt�a del modello. In particolare possonoessere implementati standard relativi all scrittura di header di blocchi,entit�a, etc.

� Regole Linguistiche: vincoli sui nomi degli identifier che migliorano laleggibilit�a del codice; spesso nomi particolari sono richiesti dalle fonde-rie stesse per identi�care determinati oggetti presenti nelle librerie, (es:CLOCK, RESET...).

� Si possono prevedere insiemi di regole relative alla programmazioneOO�V HDL.

102

8.3 La struttura di LVS

Il tool LVS �e un front end per il linguaggio VHDL completamente aderenteagli standard IEEE-1076. LVS �e parte di un ambiente di sviluppo pi�u vasto,LV 2S, che contiene anche un front end per il Verilog IEEE-1364.

Il concetto fondamentale del pacchetto applicativo LV 2S �e la costruzionea partire dai sorgenti VHDL, o Verilog, o entrambi, di due basi di dati notecome VIF, VHDL Intermediate Format, e VeIF, Verilog intermediate format.

In LVS, dopo che il �le di origine �e stato analizzato, l'utente ha la possibilit�adi interagire con il database generato da LVS, attraverso un'interfaccia chepermette di consultare il database mediante un ampio numero di procedurescritte in linguaggio C: l'insieme delle procedure �e chiamato LPI, (LEDAProcedural Interface).

In �gura 8.1 �e rappresentata la struttura di LV 2S in cui �e mostrato siail parser VHDL, rappresentato con il piccolo cerchio che contiene la v, che ilparser Verilog, rappresentato con il cerchio ve.

V IF2������������������������������������������������������������������

������������������������������������������������������������������

LVS LVeS

LPI

VeIFVIF

v ve

Figura 8.1: Struttura interna di LVS.

Come si pu�o notare in �gura 8.1 le basi di dati VIF e VeIF sono parzialmentesovrapposte cio�e gli elementi comuni alle due basi di dati sono condivisi, comela gestione delle library e dei tipi fondamentali.

103

8.3.1 La base di dati VHDL

A livello astratto si pu�o pensare che il database formi un grafo che intercon-nette le strutture fondamentali chiamate nodi. Ciascun nodo �e costituito daun insieme di attributi che possono essere: tipi di dato primitivi (quali interi,stringhe, numeri reali, tipi enumerativi), puntatori ad altri nodi oppure punta-tori a liste di altri nodi. Ogni nodo possiede una serie di attributi che puntanoa valori che possono rappresentare tipi built�in del VHDL, altri nodi o lista dinodi. Anche i nodi a loro volta sono organizzati in classi, utili per speci�caregli insiemi di nodi cui possono puntare taluni attributi.La struttura di nodi eclassi viene denominata Schema. I nodi di LVS sono strutturati all'interno diun albero di classi.

La gerarchia di classi in cui sono contenuti i nodi determina anche gliattributi di ogni nodo. Prendendo come esempio il nodo binary operation,che rappresenta nel database l'uso di uno degli operatori binari prede�niti nelVHDL, esso �e costituito dai seguenti attributi:

� has tmp: attributo di tipo intero che pu�o essere usato per conteneretemporaneamente informazioni utili al programmatore;

� has evaluation time: attributo di tipo enumerativo che indica se il nodo,nel corso di una simulazione, �e valutato staticamente o dinamicamente;

� has constraint: attributo che punta a un nodo di classe CONSTRAINTche indica eventuali vincoli applicabili all'oggetto;

� has srcpos: attributo costituito da una stringa di caratteri che indica laposizione dell'operatore nel �le originale;

� has left exp: attributo che punta a un nodo di classe NAME EXP cherappresenta l'espressione a sinistra dell'operatore;

� has right exp: attributo che punta a un nodo di classe NAME EXP cherappresenta l'espressione a destra dell'operatore;

� has value: attributo che punta a un nodo di classe STATIC VALUE cherappresenta, se pu�o essere calcolato, un valore di tipo statico associabileal nodo;

� has func name: attributo che punta a un nodo di classe FUNC DEFche rappresenta la de�nizione della funzione corrispondente all'operatorebinario.ls.

104

La struttura del database pu�o essere consultata attraverso un insiemedi routine scritte in linguaggio C, che nel loro complesso costituiscono lacosiddetta Leda Procedural Interface (LPI).

Queste routine possono essere genericamente raggruppate in: proceduredi gestione delle librerie di design unit compilate, trattamento di nodi e loroattributi, visita di liste e sottoalberi. Ogni attributo, nella sua de�nizione,pu�o presentare la caratteristica di essere primary o alternate e anche di essererequired o optional. In particolare la visita di sottoalberi attraversa tutti esoli gli attributi di tipo primary, in questo modo il database �e visto come ungrafo diretto aciclico ed �e visitato completamente. Viceversa tutti gli attributiche non sono primary sono etichettati come alternate. Per quanto riguardala seconda distinzione, attributi sicuramente non nulli all'interno di un certonodo sono required, mentre gli altri sono optional.

Un'importante caratteristica messa a disposizione dal tool LVS �e la possibi-lit�a di estendere quello che �e chiamato \schema", ovvero l'insieme dei possibilinodi che possono formare il database. L'utente, se lo reputa necessario, pu�o,seguendo una opportuna procedura, aggiungere dei nuovi attributi nella de�-nizione di nodi presistenti nello schema, oppure pu�o anche de�nire nuovi nodiraggruppandoli in classi da lui de�nite.

Un ultimo aspetto da mettere in luce �e la possibilit�a di visitare il databasein tutte le sue parti, incluse quelle derivanti da una estensione dello schema,con un browser, potendo cos�� anche \vedere" su video il contenuto dei nodi,oltre che \trovarlo" con la LPI.

Un esempio molto semplice di superclasse pu�o essere VHDL STATEMENTche contiene diverse sottoclassi.

8.4 ProVHDL: Programmable V HDL design rule

checker

ProVHDL (conosciuto anche come PROTON) fu presentato a Parigi al DATE-98 nel Febbraio 1998; ProVerilog nel giugno 1999 al DAC-99 a New Orlean:sono strumenti presenti sul mercato che consentono di operare una selezionefra insiemi di regole programmabili e di adattarli al progetto o al livello diastrazione.

Questi innovativi Design Rule Checkers per VHDL, o Verilog, sono stru-menti programmabili che rendono capace il progettista di validare, prima dellasimulazione, i modelli VHDL o Verilog rispetto ad uno stile o uno standard diprogrammazione (Policy) o pi�u semplicemente rispetto ad un ristretto insiemedi regole di progettazione.

105

Entrambi sono membri della famiglia di code checkers PROTON sviluppatida LEDA. Il ProV HDL Checker compie un'analisi semantica e sintatticatenendo come riferimento il VHDL LRM. Questi strumenti, prima di veri�careil rispetto dei vincoli in oggetto, devono operare una compilazione del codice ericavare un albero sintattico equivalente. Per questa operazione viene utilizzatoLVS, strumento gi�a presente sul mercato da tempo.

Piuttosto che essere gi�a codi�cate all'interno di un checker le regole posso-no essere completamente de�nite, modi�cate e aggiornate dall'utente; essendoprogrammabili, ProVHDL e ProVerilog le regole possono essere completamen-te de�nite, modi�cate e aggiornate dall'utente; essendo programmabili, Pro-VHDL e ProVerilog permettono infatti che lo stile di codi�ca venga adattatoad ogni sistema, progetto, usso di progetto o azienda. Tale programmazioneavviene in modo semplice e su�cientemente essibile. Queste regole vengo-no compilate e da queste possono essere con�gurati automaticamente tantirule checker quanti sono quelli necessari.

L'utilizzo di Proton dunque pu�o assicurare che i modelli VHDL siano com-patibili con una data metodologia, un'applicazione o un dato ambiente di svi-luppo determinato ad esempio da strumenti CAD o dalla librerie della fonderiache realizza i circuiti.Questo risultato viene raggiunto de�nendo un insieme di regole di codi�castandard (Coding Standard Rules) [PRSP 99] con le quali viene poi con�gu-rato uno strumento automatico di veri�ca; in questo modo Proton permettedi utilizzare VHDL come un standard e�ciente della speci�ca dell'hardwarein quanto consente di veri�care il rispetto, da parte dei progettisti, di regole emetodologie.

Questo porta ad avere progetti scritti uniformemente all'interno di un certoambiente di lavoro, quindi pi�u facilmente leggibili, compatibili e quindi riusa-bili; in queste condizioni ogni progettista utilizzer�a il VHDL in modo simile equesto rende facilitata la rivelazione e la correzione degli errori da cui consegueun aumento della qualit�a.

Being programmable means that coding standards can easily be rede�nedto cater for new criteria such as changes in the tools being used or in thegeneral design ow.

ProVHDL viene fornito con annesso il sottoinsieme prede�nito di rego-le relativo alla sintesi che veri�ca la compatibilit�a del codice con lo stan-dard IEEE � 1076:6 RTL synthesis subset. Altre policy gi�a disponibili,ma soggette a licenza, sono relative a

� la veri�ca delle regole de�nite nella codi�ca standard OMI326 VHDL.

� la veri�ca delle regole de�nite nel capitolo \RTL Coding Guidelines" del"Reuse Methodology Manual for System�On�A� Chip Designs"

106

di Michael Keating (Synopsys Inc) e Pierre Bricaud (Mentor GraphicsCorp.).

Se con�gurato con il sottoinsieme prede�nito relativo alla sintesi logica e con ilsottoinsieme opzionale relativo alle metodologie di riuso, ProVHDL completapi�u di 650 veri�che.

8.4.1 ProVHDL overview

ProVHDL consta di due strumenti separati: Rule Specification Tool, ProSpec[PRSP 99], e Generic Rule Checking Tool, ProCheck [PRCH 99].

Il primo �e uno strumento di speci�ca con cui si de�niscono le regole chedeterminano la codi�ca standard voluta: queste regole vengono poi compilate eda queste possono essere con�gurati automaticamente tanti rule checker quantisono quelli necessari: con tali regole quindi si parametrizza la versione delchecker �nalizzata allo stile di codi�ca in oggetto. Una volta parametrizzatoil generico rule checker ha come ingresso �le di codice VHDL e come uscitamessaggi di errore che segnalano le discrepanze con lo stile di codi�ca scelto.

DESIGN RULE CHECKER

DESIGN RULE SPECIFIERdesignmethodology

design fortestabilityrules

VHDL source file design flow

cycle basedsimulationconstraints

syntesysmodelingrules

qualityassurance

guidelines fordocumentation& readability

modeling guidelines

Figura 8.2: Schema di ProVHDL.

Le regole gi�a presenti nel database sono facilmente modi�cabili: le regolemodi�cate vengono poi ricompilate ed ogni rule checker viene ricon�guratoautomaticamente.

Lo Specifier viene presentato isolato dal Checker, in realt�a non si tratta distrumenti che presentano due interfacce tanto diverse. Lo Specifier contieneal suo interno anche il Checker, �e quindi uno strumento completo dedicato

107

a coloro che implementano una politica prede�nita potendo scrivere regolenuove e modi�care quelle gi�a esistenti. Tale politica �e generalmente de�nitain prima sede in linguaggio naturale in base a particolari esigenze. Viene poiinplementata utilizzando il meta-linguaggio VRSL: �e quindi necessario che ilpersonale che utilizza il ProVHDL Specifier abbia una buona conoscenza delVHDL.

Il Checker �e invece destinato a personale che debba solo veri�care la com-patibilit�a del codice scritto con la politica scelta. In tale strumento mancaquindi la parte destinata alla stesura ed alla modi�ca delle regole. La di�eren-za fra i due strumenti ri ette quella fra le tipologie di utenti di ProVHDL: gliimplementatori della policy e coloro che devono veri�care che il codice rispettiquest'ultima.

8.4.2 ProVHDL Specifier

Il ProVHDL's Speci�er pu�o essere utilizzato solo in modo interattivo: Prospec�e il nome dell'eseguibile del ProVHDL Specifier ed �e lo strumento per crearele librerie di regole; �e possibile scegliere la con�gurazione VHDL'87 o VHDL'93aderente ai corrispondenti VHDL Language Reference Manuals (LRM).

Esse possono essere scritte con un qualsiasi text editor e devono esserecontenute in �le con su�sso .rl.

Tali regole sono analizzate e immagazzinate in una policy library, allaquale viene associato un �le di testo, creato da Prospec con un nome del tipo< policy name > :pol. La creazione e la gestione di tutti questi �le e libreriee' completamente e�ettuata da Prospec, tranne ovviamente la scrittura dei�le di testo contenenti le regole. Queste sono raggruppate in insiemi di regole(ruleset) ed ognuno costituisce un �le di testo. Una politica �e costituita daun certo numero di insiemi di regole (al massimo 32 rulesets). Attraversotali insiemi di regole �e possibile dare una rappresentazione, secondo i modelliproposti da PROTON di una parte o di tutto un determinato stile di codi�ca(o di una codi�ca standard).

8.4.3 VRSL

Lo strumento di speci�ca utilizza per la stesura dei ruleset un particolaremetalinguaggio: VRSL (PROTON 0s V HDL Rule Specification Language).

Un �le scritto con VRSL contiene una parte inclusiva, una dichiarativa euna di comandi; per una corretta gestione diventa necessario anche un headerparticolarmente dettagliato. La parte inclusiva permette che siano incorporatealtre regole, standard o precedentemente de�nite dall'utente. Nella parte di-

108

Policy file<policy_name>.pol

Rules Library

PROTON_POLICY-LIB-LVS

PROTON_POLICY-LIB

VRSL Rule File<nome_file>.rl

PROTON

Figura 8.3: Schema di Prospec.

chiarativa vengono scritti template che impongono restrizioni sulle regole perVHDL ed ai quali ci si riferisce nella parte di comandi.

Il linguaggio di speci�ca delle regole per VHDL, VRLS (PROTON 0s V HDLRule Specification Language) si propone di realizzare diversi obiettivi:

� ri ettere la grammatica VHDL;

� speci�care delle regole in maniera chiara, concisa e non ambigua;

� speci�care un ampio spettro di regole sintattiche e semantiche;

� permettere di speci�care la semantica di un'applicazione (ad esempio lasintesi o la testabilit�a) attraverso la scelta di una particolare policy;

� consentire di aggiornarsi a nuovi standard VHDL

� supportare costrutti speci�ci per determinate applicazioni (come la se-mantica di clock e sincronizzazione);

� de�nire un grande numero di regole (in�nito, almeno in linea teorica).

VRSL contiene pochi comandi e dichiarazioni ma molte keywords; la maggiorparte corrisponde a regole di grammatica VHDL che possono essere trovate nelVHDL LRM (V HDL Language Reference Manual). Per evitare la stesuradi regole eccessivamente lunghe, ad esempio per alcune strutture VHDL, non

109

sempre si segue la grammatica dell'LRM. Altre keywords sono introdotte perpermettere di speci�care applicazioni facilmente. Ad esempio nella sintesipu�o essere richiesto di distinguere fra processi combinatori o sequenziali o dilimitare il numero di clock in un processo.

VRSL contiene due tipi di unit�a: templateset e ruleset. Un templatesetpu�o essere considerato come un package VHDL: contiene un insieme di dichia-razioni di template e non sono ammessi al suo interno comandi, pu�o richiamarea sua volta altre unit�a templatesetUn ruleset pu�o essere visto come una architettura VHDL, pu�o contenere di-chiarazioni di template, template e comandi.Una linea di comando VSRL �e costituita da 5 parti, di cui le ultime tre sonoopzionali:command, attribute, [context], [message], [severity].Vediamo in dettaglio le singole parti.Esistono sei tipi di command:

� No: viene segnalato un errore se una certa V HDL clause �e presente;

� Force: la V HDL clause deve essere presente;

� Limit: una V HDL clause deve corrispondere ad almeno un elemento diun certo insieme di istruzioni;

� Set: assegna un valore �sso che deve essere ritrovato nella [V HDL clause];

� Max/Min: massimo/minimo numero di volte con cui pu�o apparire unadeterminata V HDL clause;

Attribute rappresenta la V HDL clause che deve essere controllata.ContextMessageSeverityAlcuni esempi di ruleset vengono qui illustrati:

ruleset CONCURRENT_STATEMENTS is

-- inclusive part

use templateset CLOCK_EDGES

-- declarative part

template PSS_1 is process_statement

force combinatorial

110

end

-- command part

limit process_statement in all to PSS_1

message ``ERROR : Illegal process statement''

severity ERROR

end ruleset

Avendo un'interfaccia facilmente utilizzabile, ProSpec permette una ge-stione semplice dei ruleset: sono incluse facility per la creazione di nuoveregole, le modi�che, la loro compilazione e la parametrizzazione e generazionedel Checker corrispondente.I nomi e i simboli delle icone associate alle regole possono essere scelti dall'u-tente.Ogni template pu�o appartiene a una o pi�u classi.Altro esempio di codice:

ruleset SYNTH is

-- declarative part

use templateset EDGES

template Wait_In_Process is wait_statement

force label

no sensitivity

limit condition to Rising_Edge

no timeout

end

-- command part

limit wait_statement in process_statement to Wait_In_Process

message "CS8.1-1: Illegal wait statement in process"

severity ERROR

no wait_statement in subprogram_body

message "CS8.1-2: No wait statement in subprogram"

severity WARNING

end ruleset

111

8.4.4 ProVHDL Checker

Il Checker di PROTON �e (ProCheck) ed �e caratterizzato da tre modi di esecu-zione: interattivo (GUI: Graphic User Interface), batch e core. La seguentedescrizione tratta principalmente l'esecuzione interattiva.

Figura 8.4: Interfaccia Checker con implementazione delle regole di sintesi.

Un beautifier paramentrizzabile �e incluso nello strumento per migliorare ouniformare il layout del codice.

Le caratteristiche principali sono:

� source library manager.

� VHDL project manager con generatore di Make�le.

� Possibilit�a di integrare il checker prede�nito relativo alla sintesi.

� Accesso diretto al codice sorgente mediante browser.

� Il Checker pu�o essere eseguito automaticamente o su richiesta.

� Possibilit�a di selezionare le regole, ma non di modi�carle.

Se la politica non viene rispettata apparir�a l'icona barrata relativa alla regolaviolata. If the policy is not respected, the same icon will appear but this timeit will have a red cross indicating failure. If another icon is to be used to

112

indicate failure, it must be added to the directory and it must have the namefalse icon.bmp (and .msk). Note the bmp and msk su�xes are always assumedto be present. Execute speci�er This is done by typing prospec Create PolicyOpen the Policy Manager through the Speci�er Specify Policies menu.

VHDL Projects

Prima di essere veri�cato dal Checker, il codice VHDL deve essere ordinato inun Project. Un Project �e l'insieme completo di unit�a VHDL, immagazzinatein librerie, richieste per compilare ogni unit�a: �e quindi un ambiente utilizzatodal progettista dove organizzare un insieme di librerie VHDL proprietarie eun insieme di librerie di risorse, compreso il logical=physical mapping. Pi�uspeci�catamente

Seguendo la formulazione dell'LRM le VHDL working libraries sono le libre-rie utilizzate dall'utente, quelle dove vengono immagazzinate le unit�a VHDLche risultano dalla compilazione, per le quali esiste permesso di lettura escrittura; l'utente �e l'unico responsabile della loro gestione.

Un Project contiene le seguenti informazioni:

� l'elenco dei nomi delle working library che contengono le unit�a o librerieproprietarie che si vogliono veri�care;

� l'elenco dei nomi delle resource library e il nome logico associato (logi-cal/physical library mappings); librerie necessarie alla compilazione dellediverse unit�a.

� il nome della working library corrente;

� per ogni working library, un elenco di �le VHDL sorgenti compilati o dacompilare nella working library (con il compilatore LVS VHDL);

� per ogni working library, un elenco delle unit�a VHDL analizzate con ilcompilatore LVS;

� per ogni unit�a analizzata di ogni working library la lista delle regolecontrollate passate dall'unit�a;

� dipendenze: per ogni unit�a analizzata di ogni working library, la listadelle altre unit�a da cui essa dipende (informazione usata per generare edeseguire i Make�les sulle working libraries del progetto VHDL.

Ovviamente, non sar�a necessario veri�care con il Checker tutte le librerie etutte le unit�a: ad esempio le librerie IEEE o STD sono richieste normalmente

113

per formare un Projectma non devono essere veri�cate con Checker in quantolibrerie standard.

Il Checker in modo interattivo ha due metodi per la creazione di unprogetto:

� From Scratch che realizza un approccio manuale dove le dipendenzesono stabilite dall'utente;

� From Source F iles che estrae le dipendenze all'interno di un insieme di�le VHDL e genera un Make�le, il quale, quando viene eseguito, crea ilprogetto al meglio quindi un progetto non ottimizzato. Le dipendenzesono estratte solo attraverso l'uso di clauses: questo comporta che nontutte le dipendenze possono essere estratte, comunque nella maggioran-za dei casi �e su�ciente. Quando si realizza un progetto �e consigliatoutilizzare questo secondo approccio.

Nelle �gure 8.5 e 8.6 sono ra�gurate le interfacce di ProCheck e Prospec.Come si vede non hanno di�erenze salvo la presenza fra i comandi di Prospecdella voce Specifier. Nelle due �gure viene illustrato il comportamento el'aspetto delle interfacce prima e dopo il controllo sul codice.

Working Libraries

Seguendo la formulazione dell'LRM le VHDL working libraries sono le librerieutilizzate dall'utente, quelle dove vengono immagazzinate le unit�a VHDL cherisultano dalla compilazione, per le quali esiste permesso di lettura e scrittura;l'utente �e l'unico responsabile della loro gestione.

Resource Libraries

Le V HDL resource libraries sono le librerie richiamate dall'utente, da dovevengono lette le unit�a VHDL con permesso di sola lettura; per essere coerenticon l'LRM, queste librerie vengono chiamate resource libraries of the VHDLProject ; queste includono anche le working libraries del VHDL Project edanche altre librerie utilizzate da altri utenti; ogni resource library ha unlogical name associato e il logical=physical mapping �e utilizzato per ognicompilazione in ogni working library.

8.5 Regole per riuso

Come �e stato pi�u volte a�ermato sopra, �e possibile de�nire insiemi di regole perde�nire una politica di riuso. Le regole hanno in generale un impatto di�erente

114

Figura 8.5: Interfaccia ProCheck.

Figura 8.6: Interfaccia Prospec.

115

sul codice: alcune possono essere considerate come condizioni necessarie per lariusabilit�a, altre come su�cienti, altre come norme di buona programmazio-ne sia dal punto di vista della strutturazione del sistema che della immediatacomprensione della funzionalit�a implementata. Vengono qui riportati alcuniesempi; per una visione pi�u completa delle caratteristiche che rendono un mo-dulo riusabile si rimanda al RMM [RP]. In particolare una politica relativa alriuso riunisce diversi aspetti della programmazione: vi sono aspetti semantici,aspetti relativi alla facile comprensione come documentazione, header, label ecommenti, aspetti relativi alla compatibilit�a del codice per i diversi tool(quindiil massimo rispetto degli standard riconosciuti).

� Generic Existence: viene veri�cata la presenza di costrutti generic; ta-le costrutto �e uno dei mezzi pi�u potenti per progettare un dispositivoriusabile. L'uso viene raccomandato quasndo si voglia incrementare lariusabilit�a del progetto.

� Simulation or Syntesis Architecture: viene veri�cato il rispetto di unparticolare template nella scrittura dell'architettura approntata per lasimulazione del dispositivo. Tale template de�nisce la dichiarazione dicostanti, tipi, segnali, funzioni e procedure, l'assegnazione di segnali con-correnti, la de�nizione dei generate e l'instanziazione di componenti.Allo stesso modo pu�o essere organizzato un template per architettureadatte alla sintesi

� Procedure Function and Component Declaration: questi costrutti van-no raccolti all'interno di package per facilitarne l'individuazione e lariusabilit�anche all'interno dello stesso progetto.

� Signal parameter in subprogram: un subprogram �e considerato una par-te sequenziale del codice; l'utilizzo di segnali al suo interno introduceelementi e costrutti parallelli i cui e�etti possono darte dei problemi seconsiderati a prescindere dal contesto in cui sono inserito. Sempre aquesto proposito timing e event non devono essere presenti in costruttisubprogram: questi ultimi supportati dagli strumenti di sintesi

� Layout code Particolarmente importante ai �ni del riuso �e l'immediatacomprensione del codice: questa �e fortemente agevolata da standard nellascelta dei nomi di variabili e sagnali, nel tipo delle informazioni raccoltenegli header e da una forte strutturazione del sistema.

� Line of code Limitare il numero ad esempio delle linee di codice in un�le porta a gestire un numero maggiore di �le ma spinge anche versouna maggiore modularizzazione del progetto, quindi verso la tendenza di

116

avere oggetti di dimensioni ridotte, non troppo specializzati e quindi pi�ufacilemte riusabili. Riusare �le che implementano un elevato numero difunzionalit�a o comunque funzionalit�a troppo complesse porta alla neces-sit�a di uno strumento di estrazione del codice voluto dal �le originario,oppure alla presenza di una elevata quantit�a di codice inutile qualora nonsi voglia o non si possa e�ettuare l'estrazione di una parte del codice dal�le di origine.

In ogni caso il solo utilizzo di ProVHDL non garantisce una completa co-pertura di tutte le regole pensabili per la completa riusabilit�a del modulo inoggetto: come ogni programma applicativo ha comunque delle limitazioni.

Una estensione delle regole implementabili con ProVHDL pu�o essere otte-nuta agendo direttamente sul database LVS costruendo funzioni in C. Esistonogi�a ad esempio procedure in grado di seguire la propagazione del segnale anchese staticamente [Mino 99] operazione impossibile utilizzando semplicementeProVHDL.

8.6 Vantaggi e svantaggi di ProVHDL

L'utilizzo di ProVHDL permette un rapido esame del codice nei confrontidi alcune caratteristiche che questo deve possedere in base all'uso che se neprevede.

Il tipo di valutazione �e oggettivo in quanto non dipende da un unico esami-natore (umano), ma tale valutazione viene e�ettuata sulla base di una meto-dologia prede�nita sia a proposito dei vincoli che comporta, sia per il livello digravit�a che il mancato rispetto di tali vincoli comporta: la presenza di livellidi severity consente la segnalazione non solo di errori ma anche di costrutti,che pur non essendo errati, possono comunque essere cause di altro tipo diproblemi.

Se le regole di interesse sono implementabili con ProVHDL la program-mazione dello specifier �e rapida e automaticamente con�gura o aggiorna ilchecker; non �e posto limite al numero delle regole inseribili.

La essibilit�a e la velocit�a di ProVHDL favoriscono la sua integrazione al-l'interno del usso di progetto anche a diversi livelli, ogniqualvolta le speci�chesono espresse da una descrizione VHDL; in base al livello e alla applicazioneverr�a utilizzato il checker che implementa la policy opportuna: questa non soloappartiene a un preciso contesto (testabilit�a piuttosto che sintesi) ma, essendotale strumento programmabile, potr�a essere ottimizzata in base al progetto.

Lo specifier viene presentato come isolato dal checker, consentendo che laspeci�ca delle regole sia riservata a particolari gruppi il cui compito sia quello

117

di de�nire stili di codi�ca e linee guida per la qualit�a del codice.

La veri�ca pu�o esser eseguita in modo interattivo o in modo batch.

Sono inclusi beautifier e browsers.Essendo programmabile, ProVHDL �e molto essibile e robusto verso l'ob-

solescenza: �e possibile riadattarlo alle esigenze del usso di progetto. Rulescan be speci�ed to control the syntax and semantics of the VHDL input, thestyle of the VHDL code and unit-wide rules normally imposed by application-speci�c VHDL-based tools (e.g., synthesis, test, cycle-based simulation).L'utilizzo di strumenti come ProVHDL incrementa il livello di coordinamentofra i diversi gruppi di progetto e aumenta il livello di standardizzazione, con-tribuendo cos�� ad ottimizzare i tempi di progetto e quindi riducendo il time tomarket.

In particolare pu�o dimostrarsi uno strumento di notevole interesse nellaveri�ca della compatibilt�a di celle IP acquisite esternamente all'ambiente diprogetto: diventa quindi uno strumento potente dove si voglia implemetareuna metodologia di progetto di SoC orientata al riuso.

I vantaggi derivanti dall'uso di ProVHDL, in generale in ambiente di pro-gettazione, si riferiscono dunque a tematiche di largo respiro e riguardano inparticolare l'introduzione nel usso di progetto. Tuttavia, soprattutto perl'utente esistono anche alcuni problemi.

In ProVHDL non viene chiaramente speci�cato il concetto di �le: vienepittosto visto come attributo di VHDL unit.

L'output non permette facilmente successive elaborazioni: �e costituito es-senzialmente da una successione di messaggi di errore ed eventualmente vieneconsentito di salvare tali risultati in una serie di tabelle immagazzinate in un�le di testo. Tali tabelle non sono comunque particolarmente ricche, a�erma-no solo quali errori si sono riscontrato ma non �e speci�cato dove nel testo n�equante volte.

Il problema maggiore all'apprendimento dell'uso di ProVHDL rimane co-munque il manuale: manca un indice analitico completo, un help in linea;inoltre gli elementi che compongono la grammatica vengono semplicementeelencati e non ne viene data una de�nizione esaustiva.

Esistono limitazioni nelle attuali versioni di ProVHDL, manca in VSRL uncostrutto che corriponda ad un contatore, ed esistono di�colt�a nel seguire lapropagazione di segnali sia attraverso la gerarchia.

118

Conclusioni e Sviluppi futuri

Le principali problematiche che caratterizzano la progettazione dei sistemi di-gitali sono riconducibili alla crescente complessit�a ed alle richieste del mercatoquali l'aumento del livello di qualit�a e la riduzione dei costi e dei tempi disviluppo.

La soluzione, che si sta consolidando negli ultimi anni, �e rappresentatadal riuso di componenti gi�a realizzati, da integrare nel sistema che si staprogettando.

Il lavoro svolto evidenzia come la progettazione orientata al riuso impon-ga l'impossibilit�a di una conoscenza completa del componente riusato: questocomporta una diminuzione della controllabilit�a del processo di progettazione,soprattutto in termini di prestazioni, sicurezza e garanzia del prodotto �nale.Tutto questo pu�o essere evitato solo se il componente ha maggiori caratteri-stiche intrinseche di sicurezza e testabilit�a rispetto a quelle richieste nel casodi una progettazione from scratch; il maggiore sforzo richiesto per la progetta-zione del componente riusabile deve anche essere in grado di coprire richiestedi adattabilit�a, essibilit�a e parametricit�a.

Inoltre, il riuso resta un'operazione non facile che impone di adottare spe-ci�ci modelli, livelli di standardizzazione e criteri di progettazione che permet-tano al progettista di garantire ed ottimizzare la comprensione, la modi�ca el'integrazione del componente.

Nella tesi �e stato proposto un modello di valutazione dei costi di progettoe sviluppo di un sistema digitale, mediante il quale �e possibile ottenere del-le stime sullo sforzo di progettazione. Il lavoro svolto si �e articolato in pi�ufasi. Dapprima sono stati identi�cate le attivit�a che caratterizzano il ussodi progetto ed i costi associati. La loro analisi ha riconosciuto nei costi diprogetto e sviluppo quelli su cui il riuso in uisce maggiormente. Il modelloeconomico prevede il riuso di componenti IP soft, pertanto si basa sul modellodi stima dello sforzo e dei tempi di sviluppo associato ad applicativi software.

119

Tale modello ha una propria consistenza logica ed �e stato ricavato a partire damateriale gi�a disponibile in letteraura, opportunamnete adattato all'analisi inoggetto.

�E stato inoltre approfondito l'impatto economico del riuso: in particolaresono state de�nite le tecniche di progettazione volte al riuso, decritti i requisitie le propriet�a che un componente riusabile deve presentare ed �e stato rilevato,a tale proposito, l'esistenza delle attivit�a che richiedono un maggior impegno etempi pi�u lunghi, quali l'analisi del dominio del modulo riusabile, lo sviluppodi un ambiente per una veri�ca pi�u completa e robusta, un codice che rispettidei precisi criteri e sia a�ancato da una documentazione esauriente. Inoltre �estato quanti�cato lo sforzo aggiuntivo per rendere riusabile un componente e,allo stesso tempo, i bene�ci che ne derivano.

Si �e evidenziato come l'operazione di scelta debba necessariamente richie-dere un tempo particolarmente breve pur essendo un punto particolarmentecritico del usso di progettazione. Questo comporta l'utilizzo di strumenti au-tomatici di valutazione che diano le informazioni richieste a partire sia dallespeci�che, se il componente �e ancora da progettare, sia dalle caratteristichedichiarate (presenti nella documentazione), o addirittura dal codice, se il com-ponente deve essere semplicemente riusato. A tale prosito �e stato sperimentatol'uso di uno strumento per la de�nizione di regole di programmazione e veri�cadelle stesse (ProVHDL) con cui �e possibile garantire alcune caratteristiche diriusabilit�a nella codi�ca.

�E stata riconosciuta l'importanza dello stile di codi�ca del codice e comequesto in uisca sullo sforzo di progettazione; sono state individuate regole perlo sviluppo di componenti riusabili e sono state provate su codice mediantel'utilizzo di strumenti automatici commerciali.

Si �e dimostrato come alla base della gestione dei rischi e soprattutto dellaprogettazione dell'hardware vi sia la valutazione dello sforzo di sviluppo. Asua volta il modello richiede che tale sforzo sia funzione della dimensione delprogetto in termini di codiche prodotto; sono state quindi analizzate due di-verse metriche in grado di valutare la dimensione del progetto a partire dallesua caratteristiche iniziali: speci�che piuttosto che organizzazione di progettoda cui si sviluppano rispettivamente la metrica dei Functikon Point e quellaLines of code. Per ognuna di queste sono state proposti dei criteri di calcolospeci�ci per una descrizione del progetto in codice VHDL ed �e stata a�rontatauna iniziale validazione e�ettuata sul progetto LEON.

Gli sviluppi futuri del lavoro sono di seguito elencati:

� �E possibile fare una stima a posteriori dei valori delle variabili predittivedel modello, ad esempio con un approccio bayesiano, che tenga conto

120

delle conoscenze a priori e delle informazioni raccolte. In questo modosi pot�a calibrare il modello, consolidando o eliminando alcuni fattori dicosto, oppure aggiungendone altri che potrebbero rivelarsi signi�cativiper uno speci�co dominio applicativo, [Chul 98].

� Proseguire la validazione delle metriche ai �ni di ottenere dei criteri gui-da che consentano ai progettisti di derivare informazioni fondamentalia partire dalle speci�che di progetto. Inoltre, la speci�cit�a del domi-nio applicativo impone di rivedere criticamente quanto gi�a presente inletteratura per le stime di applicativi puramente software.

� Individuazione di una metodologia per la gestione dei rischi legati al ri-uso, utilizzando le metriche studiate come uno dei possibili strumenti.La progettazione di un componente riusabile richiede, come evidenzia-to, uno sforzo maggiore. Allo stesso tempo d�a garanzie sulla qualit�a delcodice e riduce i rischi legati ad una errata implementazione della fun-zionalit�a attese, oltre ad una riduzione dei possibili difetti presenti sucodice, maggiore essibilit�a e robustezza.

� Estensione delle metriche alla progettazione di componenti riusabili daa�ancare ad altre per valutare il grado di riusabilit�a in funzione dellefunzionalit�a.

� Utilizzo delle metriche in ambiente di codesign. Occorre infatti un ap-proccio uni�cato nella stima dei costi della parte e hardware e softwaredel sistema che si sta realizzando. Tale strategia infatti, detta cost-drivensystem level design, fa convergere gli sforzi di progettazione hardware esoftware in un'unica metodologia che migliora il costo, i tempi e la qualit�aed allo stesso tempo incentiva l'esplorazione dello spazio delle possibilisoluzioni.

121

Bibliogra�a

[Alme 94] J. Almeyer, S. Ohsorge, B. Schurmann \Reuse of Design Object inCAD Framenworks". Proceedings of the ICCAD'94,

[Ashe 98] Ashenden, \The Student's Guide to VHDL". Morgan KaufmannPublishers, Inc., 1998.

[Bigg 97] J. Biggs, \Design Reuse with Virtual Components".http://www.ECSI.org/ecsi/Doc/OtherDoc/IPreuse/default.html, 1997.

[Blum 93] M. Bluml et al. \A workbench for Generation of ComponentsModels". In Proceeding of EURO-DAC'95, 1995.

[Boeh 81] B. Bohem, \Software Reuse Economics". DARPA Workshop,http://sunset.usc.edu, January 1981.

[Boeh 97] B. Bohem, \Software Engineering Economics". Prentice-Hall, Inc.Englewood Cli�s NJ, 1997.

[Boeh 98] B. Bohem, H. Harvey-Horn, \Reusing Software-based IP: AnEconomic Perspective".http://www.virtualchipdesign.com/Editorial/1998/feature9811.html,1998.

[Boul] D. W. Bouldin, \Reusing Intellectual Property Blocks in ASIC ".

[Bull 99a] \Sviluppo Progetto Logico \ASIC"". Documento Interno Bull,codice SQN-97-24, 1999.

[Bull 99b] \Gestione Progetto Logico e Simulazione \ASIC"". DocumentoInterno Bull, codice SQP-04-04, 1999.

[Cape 97] J. Capers,\What are Function Points?". Software ProductivityResearch, http://www.spr.com/library/functmet.htm, 1997.

123

[Cape 96] J. Capers,\Programming Languages Table". Software ProductivityResearch, http://www.spr.com/library/0langtbl.htm, 1996.

[Carr 93] M. J. Carr et al. \Taxonomy-Based Risk Identi�cation, SEIThecnical Report SEI-93-TR-006". Pittsburgh, PA: SEI, 1993.

[Chul 98] S. Chulani, B. Boehm, B. Steece, \Calibration Software ModelsUsing Bayesian Analysis". USC-CSE, 1998.

[COCO 81] \COCOMO Reference Manual". http://sunset.usc.edu, 1981.

[COCO 97] \COCOMO 2.0 Model De�nition Manual". Version 1.2, 1997.

[Deba 97] J. A. Debardelaben, V. K. Madisetti, A. J. Gadient, \Incorpora-ting Cost Modeling in Embedded-System Design". IEEE Design & Test ofComputers, 1997.

[Dunc 96] W. R. Duncan, \A Guide to the Project Management Body ofKnowledge". PMI Standards Committee, 1996.

[EFPA 99] \Experience Function Point Analysis".http://www.sttf.�/html/ant expefpa.html, 1999.

[Fent 96] N.E. Fenton, S.L. P eeger \Software Metrics. A practical andRigorous Approach", International Thomson Computer Press, 1996.

[Gajs 94] D. D. Gajski, F. Vahid, S. Narayan, J. Gong, \Speci�cation andDesign of Embedded Systems". PTR Prentice Hall, 1994.

[Ghez 94] C. Ghezzi, A. Fuggetta, S. Morasca, A. Morzenti, M. Pezz�e, \In-gegneria del Software. Progettazione, Sviluppo e Veri�ca". MondadoriInformatica, 1994.

[Girc 93] E. Girczyc, S. Carlson, \Increasing Design Quality and EngineeringProductivity through Design Reuse". ACM/DAC, pp. 48-53, 1993.

[Hunt 96] A. Hunt, \Estimating the Cost of Software Reuse with Predic-tive Defect Data". Texas Instruments Incorporated, Systems Group,http://www.asset.com/WSRD/conferences/proceedings/papers/hunt,1996.

[IEEE 94] \IEEE Standard VHDL Language Reference Manual", IEEE Std1076-1993, New york, 1994.

[Keat 98] M. Keating, \A Financial Model for Design Reuse". ht-tp://www.synopsys.com, 1998.

124

[Kiss 97] P. Kission, A.A. Jerraya, I. Moussa \Hardware reuse". 2nd Wor-kshopo on Libraries, Component, Modeling and Quality Assurance,1997.

[Kont 94] J. Kontio \Software Engineering Risk Management: A TecnologyReview Report". PI 4.1, A Proprietary Nokia Research Center projectdeliverable, 1994.

[Kont 98] J. Kontio, V. R. Basili \Experiences in Improvements Manage-ments Processes Using the Concepts Riskit Method". Proceedings of theProceedings of the Sixth International Symposium on the FSE6, 1998.

[Leda 99] http://www.leda.fr, sito internet di LEDA S. A., 1999.

[LEON a] J. Gaisler \LEON-1 Functional Description". TOS-ESD/JG/501,Issue 2.1, European Space Agency, May 2000.

[LEON b] J. Gaisler \LEON-1 VHDL Model Description". TOS-ESD/JG/501, Issue 2.1, European Space Agency, May2000.

[Levi 92] M. Levitt, \Economic and Productivity Considerations in ASIC Testand Design for Test". Digest of Papers: Compcon 92, Spring 1992.

[Lewi 97] J. Lewis, \Intellectual Property (IP) Components", (ArtisanComponents, Inc.). http://www.ireste.fr/fdl/vcl/ip/ip.htm, 1997.

[Liu 95] J. Liu, \Detailed Model Shows FPGAs' True costs". EDN, May, 1995.

[Marc 99] \Impatto economico del riuso nella progettazione di SoC ". TesiMaster Cefriel, area EDA, 1999.

[Mead 80] C. A. Mead, L. A . Conway, \Introduction to VLSI Systems".Addison-Wesley Publishing Company, 1980.

[Medi 97] D. Medina, \Design for Reuse: A Telecom Company Perspective".http://www.ECSI.org/ecsi/Doc/OtherDoc/IPreuse/default.htm, 1997.

[Mezz 99] L. Mezzalira \Tecniche descrittive, modelli e formalismi". Dispensedi Informatica Industriale-DU-3, 1999.

[Mino 99] D. Minonne \Tecniche di progettazione orientate al riuso basate sulVHDL". Tesi Master CEFRIEL, Area EDA, 1999.

125

[Mouss 99] I Moussa, M.Diaz Nava, A.A. Jerraya \Analyzing the Cost of Reu-se". Cap. in \Reuse Techniques for V LSI Design"., Ed. R. Seepold,Kluwer Academic Publisher, 1999.

[Ouya 98] S. Ouyang \Evaluating the ROI of reuse".http://www.sern.enel.ucalgary.ca/Charmi/Courses/97-98/SENG609.07-public/ShengRoi/Roi.htm, 1998.

[Para 87] D. Paraskevopoulos, C. Fey, \Studies in LSI Technology EconomicsIII: Design Schedules for Application-Speci�c Integrated Circuits". IEEEJournal of Solid-State Circuits, Aplril 1987.

[Poul 97] J. S. Poulin, \The Economics of Product Line Development". Inter-national Journal of Applied Software Technology, Vol. 3, No. 1, pp. 24-34,March 1997.

[Prei 95] V. Preis et al. \A Reuse Scenario for the VHDL-Based HardwareDesign Flow". Proceeding of the EURO-DAC'95, 1995.

[PRCH 99] \PROTON Rule Checker User's Manual" LEDA, 1999.

[PRSP 99] \PROTON Rule Speci�er User's Manual". LEDA, 1999.

[RP] K.O'Brien, S.Maginot, \Reusability and Portability Improvementsthrough User-De�ned VHDL Subsets",In Proceedings, Workshop on Li-braries, Component Modelling and Quality Assurance'97 in TOLEDOVUFE, April 97.

[RASSP 98] \Cost Modeling for Embedded Digital Systems desi-gn". Module 57, Education & Facilitation Program Module,http://www.cedcc.psu.edu/ee497i/rassp 57, June 1998.

[RASSP] \Education & Facilitation Program Module". Module 35,http://rassp.scra.org.

[Sava 98] W. Savage, \Want Design Reuse? Change the Process".http://www.virtualchipdesign.com/Editorial/1998/Feature59802.html,1998.

[Schu 98] G. Schumacher, W. Nebel \Object Oriented Modelling of parallelHardware Systems". In Proceeding of the DATE'98, 1998.

[Seep 96] R. Seepold, A. Kunzmann, W. Rosenstiel \Hardware design Metho-dology for e�cient Reuse". 2nds Conference of Integrated Design andProcess Technology, 1996.

126

[Simm 98] \Risk Management". http://www.airtime.co.uk/users/wysywig/risk 1.htm, 1998.

[SRBM 95a] \Software Reuse Business Model (SRBM) Thecnical Report: Ap-pendix E Cost/Economic Mechanisms". Prepared for DoD Software ReuseInitiative, 1995.

[SRBM 95b] \Selection Criteria for Reuse Business Strategy Archetypes: Ap-pendix C Cost/Economic Mechanisms". Prepared for DoD Software ReuseInitiative, 1995.

[Syno 98a] \Bringing Portability to Hard IP - The Advantage of CBA forDesign Reuse". http:/www.synopsys.com, March 1998.

[Syno 98b] \Design Environment for System-on-a-Chip".http:/www.synopsys.com, 1998.

[SNUG 98] M. Keating, \Design Reuse. The Necessary Next Step in DesignerProductivity". http://www.synopsys.com, 1998.

[Trim 81] S. Trimberger et al. \A Structural Design Methodology and As-sociated Software Tools". IEEE Transactions on Circuits and Systems,1981.

[VSIA 97] \VSI Alliance, Architecture Document". Version 1.0,http://www.vsi.org, 1997.

[West 94] N. H. E. Weste, K. Eshraghian, \Principles of CMOS VLSI Design".Second Edition, Addison-Wesley, 1994.

127