ARCHITETTURE DI SISTEMI INTEGRATI
PER APPLICAZIONI SPECIFICHE
Design Flow
Prof. Luigi Raffo
Dipartimento di ingegneria elettrica ed elettronica
Università di Cagliari
Flusso di progetto classico su silicio
Arch.Sist.Int.App.Spec. a.a 2004/05
Prof. L. Raffo 25-set-04
DF-1
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.
Arch.Sist.Int.App.Spec. a.a 2004/05
Prof. L. Raffo 25-set-04
DF-2
Flusso digitale top-down
Questo e` un dettaglio della progettazione basata su sintesi RTL.
Lo scopo finale puo` anche essere l’implementazione su FPGA.
Arch.Sist.Int.App.Spec. a.a 2004/05
Prof. L. Raffo 25-set-04
DF-3
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).
Arch.Sist.Int.App.Spec. a.a 2004/05
Prof. L. Raffo 25-set-04
DF-4
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.
Arch.Sist.Int.App.Spec. a.a 2004/05
Prof. L. Raffo 25-set-04
DF-5
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`.
Arch.Sist.Int.App.Spec. a.a 2004/05
Prof. L. Raffo 25-set-04
DF-6
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.
Arch.Sist.Int.App.Spec. a.a 2004/05
Prof. L. Raffo 25-set-04
DF-7
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).
Arch.Sist.Int.App.Spec. a.a 2004/05
Prof. L. Raffo 25-set-04
DF-8
