ARCHITETTURE DI SISTEMI INTEGRATI PER APPLICAZIONI SPECIFICHE. Design Flow

Transcript

1 ARCHITETTURE DI SISTEMI INTEGRATI PER APPLICAZIONI SPECIFICHE Design Flow Prof. Luigi Raffo Dipartimento di ingegneria elettrica ed elettronica Università di Cagliari

2 Flusso di progetto classico su silicio Prof. L. Raffo 25-set-04 DF-1

3 Descrizione del design-flow classico Quello che si vede e` il classico approccio Top-down alla progettazione (o anche a cascata, water-fall). Identifichiamone le parti principali: Progetto di sistema/architetturale: sviluppo dell idea di sistema e verifica del modello, identificazione dei sottoblocchi principali. Realizzazione dei blocchi: a seconda delle esigenze si puo` decidere di implementare tali blocchi direttamente a livello circuitale (progettazione full-custom) oppure attraverso la sintesi RTL (progettazione standard-cells). Realizzazione fisica: i blocchi progettati vengono messi assieme nel modo piu` conveniente per temporizzazioni e prestazioni (placement and routing). Viene stabilito il layout fisico determinando un subset delle maschere necessarie (file GDSII) che messe assieme alle informazioni sulla tecnologia determinano in maniera univoca la struttura del chip finale. Nello schema non si vedono dei ricircoli, ma ogni passo deve avere un punto di simulazione e verifica che si sta procedendo come previsto. Di solito ogni parte ha esperti specializzati che non si occupano del restante flusso di progetto. La parte piu` cruciale per la riuscita del progetto (anche in relazione all importanza che normalmente si da ad essa) e` sicuramente quella di definizione del sistema. Prof. L. Raffo 25-set-04 DF-2

4 Flusso digitale top-down Questo e` un dettaglio della progettazione basata su sintesi RTL. Lo scopo finale puo` anche essere l implementazione su FPGA. Prof. L. Raffo 25-set-04 DF-3

5 Progettazione di sistemi su chip (SoC) Il design-flow top-down e` perfetto per chip/sistemi che devono essere sviluppati completamente da zero. Questo e` il caso di moduli specifici (un moltiplicatore, un sommatore per esempio) ben definiti come interfaccia e prestazioni e di complessita` limitata. Le capacita` di integrazione su silicio hanno portato a mettere su un singolo pezzo di silicio dei sistemi anche molto complessi per esempio della complessita` di un semplice computer o di un modulo base di un cellulare. Questi sistemi (system-on-chip) non sono progettati completamente, ma utilizzano in gran parte moduli gia` disponibili sul mercato (IP), limitandosi quindi al progetto di alcuni moduli specifici e dell assemblaggio dei vari moduli. Deve essere chiaro che il risultato finale e` comunque un unico chip. Gli IP (intellectual property) sono forniti in una forma adatta alle esigenze di progettazione, possono essere di tipo: Soft-IP: viene fornita una versione RTL sintetizzabile Hard-IP: vengono fornite le maschere dell oggetto Nel primo caso ci deve essere una compatibilita` con la tool-chain usata dal progettista. Nel secondo deve essere usata per la specifica tecnologia utilizzata. La progettazione per SoC non puo` quindi essere globalmente di tipo top-down perche` deve tenere conto che alla base ci devono essere il piu` possibile blocchi gia` disponibili sul mercato. Tale esigenza e` l unica compatibile con il time-to-market richesto attualmente. La progettazione quindi diventa quasi spiroidale: parte dalle esigenze di sistema (top) ma anche dagli IP disponibili (bottom). Prof. L. Raffo 25-set-04 DF-4

6 Design flow a spirale Quello che segue e` un design flow tipico della progettazione di un SoC in cui tutti gli aspetti del progetto sono tenuti in considerazione parallelamente. Questa tecnica permette di avere subito una valutazione di come una scelta architetturale incida sul progetto fisico finale. Prof. L. Raffo 25-set-04 DF-5

7 Progetto di un modulo-design for reuse In questo contesto e` ovvio che se lo scopo e` quello di progettare un blocco comune puo` essere vantaggioso progettarlo per essere riusabile (Design for reuse). Un modulo per essere semplicemente usabile deve essere: ben documentato ben commentato scritto in un codice comprensibile ben determinata la procedura di verifica Un modulo per essere anche riusabile deve essere: progettato per risolvere un problema generale progettato per funzionare con diversi simulatori progettato con interfacce standard verificato separatamente dal chip per il quale e` stato progettato verificato in modo estremamente accurato completamente documentato indicando possibili applicazioni e limitazioni Di solito il progettista e` soggetto a scadenze molto stringenti, quindi non e` facile convincerlo a sviluppare design-for-reuse (si stima che si impieghi fino a 2/3 volte il tempo necessario per sviluppare un progetto non riusabile), daltronde si stima che il vantaggio di riutilizzare un modulo non sviluppato per esserlo e` irrisorio (1/2, 1/3 del tempo necessario a svilupparlo da zero). A prescindere comunque dalle considerazioni di convenienza, e` certo che lo sviluppo di moduli da usare in sistemi complessi/soc richiede la capacita` di maneggiare due principi che sono ormai cardine: riusabilita` e verificabilita`. Prof. L. Raffo 25-set-04 DF-6

8 La definizione del problema (specification) La prima parte della progettazione consente di sviluppare, verificare e rifinire fino a che non si ottengano delle specifiche sufficientemente dettagliate per permettere la codifica RTL. Questa prima parte e` di solito la piu` delicata e la piu` sottovalutata. In generale questa fase chiede che vengano definite: Funzionalita` Interfacce esterne ad altro hardware Interfacce verso il software Temporizzazioni Prestazioni Vincoli sull implementazione fisica come area e potenza Se il sistema ha una parte software: Funzionalita` Temporizzazioni Prestazioni Interfaccia con l hardware Struttura del software Le specifiche possono essere: Formali Esistono linguaggi specifici che definiscono funzionalita` e vincoli Eseguibili Un programma C, C++ o SystemC che implementa la funzionalita` del sistema richiesta. Questo metodo e` molto utile/utilizzato, ma specie se si usa C e C++, non permette di mettere vincoli su temporizzazioni e dissipazione di potenza per esempio. Prof. L. Raffo 25-set-04 DF-7

9 Progettazione di sistema La progettazione di un sistema SoC deve determinare tra l altro: cosa va su software cosa va su hardware se utilizzare un processore, quale e quanti che blocchi devono essere sviluppati, quali acquistati Si procede con: determinazione delle specifiche di sistema sviluppo di un modello comportamentale raffinare il modello comportamentale attraverso il test determinare cosa mettere su harware, cosa mettere su software sviluppare un modello architetturale raffinare il modello architetturale attraverso il test specificare i blocchi da implementare. La progettazione di un chip deve prevedere quindi una ampia parte di investigazione a livello di sistema/architetturale che deve essere affrontata con mezzi che non sono tipici della progettazione classica. Servono quindi linguaggi di programmazione (C/C++) o linguaggi specifici (SystemC) o tools di sviluppo (ad esempio Simulink per il Digital Signal Processing). Prof. L. Raffo 25-set-04 DF-8