Metodologie per la realizzazione hardware di specifiche di sistema descritte in Occam

Introduzione 
 2 
interagendo. Nelle automobili, per esempio, coesistono pi� sistemi dedicati che si occupano del 
controllo (elettronico) dell�iniezione, del cambio automatico, delle sospensioni attive, dell�ABS, 
dell�airbag, dei pretensionatori delle cinture di sicurezza e altro ancora. 
L�architettura di un sistema dedicato � di tipo eterogeneo, includendo un processore sul quale 
viene eseguito il software ad alte prestazioni, e alcuni moduli hardware dedicati che interagiscono 
con l�ambiente esterno e con il processore. La tecnologia attuale permette di realizzare, per sistemi 
di piccole dimensioni, un singolo ASIC (Application Specific Integrated Circuit) con logica dedicata, il 
microprocessore per il controllo e le parti di interfacciamento con i segnali derivanti dall�ambiente. 
Dato l�utilizzo finale a cui sono destinati i sistemi dedicati, � indispensabile riuscire ad ottenere un 
buon compromesso tra i costi dovuti alle componenti hardware e le prestazioni fornite dal 
software. 
Per raggiungere soluzioni ottimali di integrazione tra i vari componenti che costituiscono il sistema 
sarebbe necessario esplorare un numero notevole di configurazioni architetturali, con una 
conseguente perdita di tempo, proporzionale alle soluzioni esplorate. Tuttavia la forte 
competizione del mercato costringe a completare in tempi rapidi la realizzazione di un sistema, 
forzando i progettisti a fermarsi non appena viene raggiunto un raffinamento accettabile delle 
specifiche con processori pi� veloci e memorie pi� grandi del necessario. Inoltre, lo studio e 
l�analisi di un sistema embedded vengono effettuate nella primissima fase di progettazione, 
dopodich� lo sviluppo della parte software e della parte hardware procedono parallelamente ma 
senza una significativa interazione, con problemi notevoli nella fase finale di integrazione. 
Da quanto detto risulta chiara la necessit� di un nuovo flusso di progettazione che utilizzi 
metodologie e strumenti in grado di evitare i problemi legati ad uno sviluppo non integrato delle 
parti hardware e software, fornendo la possibilit� di una progettazione concorrente e la valutazione 
di soluzioni differenti di allocazione delle funzionalit� nelle due partizioni, oltre alla simulazione 
dell�intero sistema e alla valutazione dei costi di implementazione prima della realizzazione finale. 
Il co-design ha come scopo l�unificazione della progettazione hardware e software ad un unico livello 
di astrazione, prescindendo dalla reale tecnologia implementativa e permettendo l�acquisizione 
delle funzionalit� dell�intero sistema (co-specifica). Inoltre fornisce un�alta flessibilit� nell�allocazione 
delle risorse (partizionamento), la possibilit� di ottimizzare la specifica del sistema tramite una 
ristrutturazione basata sul calcolo di metriche statiche e dinamiche e la verifica delle funzionalit� del 
sistema tramite la simulazione ad alto livello o la co-simulazione delle sezioni hardware e software 
sintetizzate. Il co-design permette quindi: 
Introduzione 
 3 
- la riduzione dei tempi di progettazione e sviluppo di un sistema dedicato; 
- l�esplorazione di un vasto numero di soluzioni implementative, ricercando l�allocazione dei 
moduli che minimizzi opportuni parametri di costo come l�area o il consumo energetico; 
- la verifica funzionale della specifica di sistema senza arrivare ad una implementazione finale; 
- la definizione di strategie standard per la sintesi delle sezioni hardware e software; 
- l�automazione della documentazione del codice e l�aggiornamento delle versioni. 
Negli ultimi cinque anni � aumentato moltissimo l�interesse nel settore di ricerca del co-design e tra 
i numerosi lavori presenti si inserisce il progetto TOSCA (TOols for System Co-design 
Automation), in sviluppo presso l�area EDA (Electronic Design Automation) del centro di ricerca 
CEFRIEL (CEntro per la ricerca e la FoRmazione in Ingegneria ELettronica del Politecnico di 
Milano), il cui obiettivo � la definizione di una metodologia e di un ambiente per la progettazione 
di sistemi misti hardware/software. 
Il presente lavoro di tesi, inserito nell�ambito del progetto TOSCA, affronta le problematiche 
legate alla sintesi delle sezioni hardware. In particolare vengono presentate due strategie alternative 
di sintesi hardware che si basano su architetture circuitali differenti. La prima architettura � 
costituita da un insieme di moduli gerarchicamente innestati che implementano i singoli processi 
del linguaggio di specifica, mentre la seconda, costituita da una macchina a stati finiti con unit� di 
elaborazione, si basa sulla separazione della parte di controllo da quella di elaborazione dei dati. 
Tali strategie sono state sviluppate in modo da poter essere facilmente integrate nel flusso di 
sviluppo di sistemi dedicati realizzati in un ambiente di progettazione concorrente hardware-
software ed in particolare nell�ambiente TOSCA. Viene inoltre affrontato lo studio della 
valutazione della bont� di tali strategie e, nell�ultima parte, viene presentato un confronto tra le due 
soluzioni. 
Il capitolo 1 introduce al settore della ricerca sul co-design e analizza le caratteristiche pi� 
significative dell�ambiente TOSCA e presenta il linguaggio di specifica OCCAM, utilizzato per la 
descrizione dei moduli che costituiscono il sistema dedicato, evidenziando le restrizioni e le 
estensioni apportate per un migliore utilizzo nell�ambiente di sviluppo. Viene inoltre descritto il 
modello interno adottato per rappresentare le funzionalit� specificate dal progettista. 
I capitoli seguenti costituiscono il contributo originale della tesi. Il capitolo 2 evidenzia gli obiettivi 
del presente lavoro di tesi e descrive l�approccio alla sintesi hardware, specificando il particolare 
livello descrittivo selezionato. 
Introduzione 
 4 
Il capitolo 3 presenta una descrizione delle architetture di riferimento selezionate. Viene inoltre 
descritto il progetto reale utilizzato per confrontare i risultati ottenuti mediante le due metodologie 
di sintesi proposte. 
Nel capitolo 4 vengono descritti gli algoritmi che consentono l�automazione della sintesi che fa 
riferimento all�architettura H.M.A., modulare e gerarchica, evidenziandone pregi e difetti. Il 
capitolo si conclude con la presentazione e validazione dei risultati ottenuti nel caso di studio 
presentato nel precedente capitolo. 
Nel capitolo 5, dopo un�iniziale presentazione dei metodi descritti in letteratura, vengono 
introdotti gli algoritmi proposti per la generazione automatica di un�architettura del secondo tipo 
(F.S.M.D.). Anche il capitolo 5 si conclude con la presentazione e validazione dei risultati ottenuti 
nel caso di studio. 
Il capitolo 6 confronta i risultati ottenuti individuando la strategia F.S.M.D. come la pi� adatta ad 
essere integrata nel flusso di sviluppo dell�ambiente TOSCA. 
Il capitolo 7 conclude il lavoro mettendo in evidenza alcune possibili direzioni di sviluppo. 
 5 
2. Il co-design e l’ambiente TOSCA 
Capitolo 1 
Il co-design e l’ambiente TOSCA 
2.1 Introduzione 
I sistemi embedded costituiti da moduli hardware dedicati e da processori programmabili per 
l�esecuzione di moduli software, sono largamente impiegati in numerosi campi applicativi, dalle 
telecomunicazioni all�elettronica di largo consumo. Le architetture miste hardware/software 
rappresentano in generale un buon compromesso tra la flessibilit� funzionale e i costi di sviluppo e 
realizzazione. La disciplina nascente che si occupa della progettazione di sistemi eterogenei � 
rappresentata dal co-design che ha come obiettivo lo sviluppo concorrente di moduli hardware e 
software. Attualmente la ricerca in tale campo � finalizzata alla realizzazione di strumenti 
automatici che supportino le varie fasi del ciclo di sviluppo della progettazione di sistemi misti. Il 
flusso di progetto tipico di un ambiente di co-design ha inizio con la specifica delle funzionalit� 
dell�intero sistema (co-specifica). Il modello cos� ottenuto costituisce la base per l�esplorazione del 
progetto a livello di sistema che a sua volta consiste nella sperimentazione e nella valutazione di 
diverse soluzioni architetturali che produranno due sottosistemi, uno da realizzare hardware e uno 
software (partizionamento e binding). La fase successiva prevede la sintesi delle parti 
precedentemente individuate (co-sintesi). Tra gli elementi principali da considerare in un 
ambiente di co-design vi sono: 
• la capacit� di stimare, nelle prime fasi del progetto, il risultato finale della sintesi: a tale scopo � 
possibile definire un insieme di metriche che consentono di stimare i costi in termini sia di 
area sia di tempo di esecuzione delle parti hardware e software. Attraverso tale processo si 
Capitolo 1 Il co-design e l'ambiente TOSCA 
 6 
pu� valutare la bont� del partizionamento effettuato e verificare se sono soddisfatte le 
specifiche e i vincoli di progetto senza dover attendere le fasi di sintesi logica per i moduli 
hardware e la compilazione del codice per i moduli software; 
• la possibilit� di effettuare una analisi formale a livello globale e una simulazione dell�intero 
sistema (co-simulazione): terminata la fase di sintesi hw e sw � opportuno simulare il sistema 
nella sua globalit� per verificare il corretto funzionamento delle singole parti che lo 
compongono, nonch� la corretta interazione tra le stesse, attraverso la verifica dei meccanismi 
di comunicazione e di interfacciamento realizzati; 
• la capacit� di valutare varie alternative di progetto: deve essere possibile esaminare diverse 
alternative di partizionamento del sistema per stabilire quale combinazione di moduli hw e sw 
soddisfi al meglio i vincoli e le specifiche indicate dal progettista; 
• la riusabilit� delle varie parti del sistema.  
Al paragrafo 2 verr� presentata una rassegna delle principali ricerche nell�ambito del co-design; per 
ciascun ambiente di sviluppo verr� descritto il flusso di progetto adottato evidenziando in 
particolare gli aspetti relativi alla sintesi hardware, che costituisce l�obiettivo del presente lavoro di 
tesi. 
Al paragrafo 3 verr� illustrato in dettaglio l�ambiente TOSCA, nel cui ambito si inserisce il presente 
lavoro. 
2.2 Ambienti di ricerca nell’ambito del co-design 
Nel presente paragrafo verranno presentati i principali ambienti di sviluppo nell�ambito del co-
design: per ognuno di essi verr� descritto il flusso di progetto e ci si soffermer� in modo 
particolare sugli aspetti della sintesi hardwre. 
2.2.1 Polis 
L�ambiente Polis [Polis], [BaChJu97], sviluppato presso l�Universit� della California, Berkeley, si 
propone come ambiente di co-design per lo sviluppo di sistemi dedicati orientati al controllo. Il 
sistema viene rappresentato attraverso C.F.S.M. (Co-design Finite State Machine) che, rispetto alle 
tradizionali macchine a stati finiti, realizzano le comunicazioni tra i moduli con tempi non nulli e 
non limitati. 
Capitolo 1 Il co-design e l'ambiente TOSCA 
 7 
Formal
Languages
System
Behaviour
Partitioning
SW Sinthesis HW Synthesis
Interface
Synthesis
S-graph
Verification
of the
synthesized
component
OS-Synthesis
C Code
OS-Synthesis
Optimized
Hardware
 
Figura 1: Ambiente di sviluppo di Polis. 
Il flusso di progetto si articola nei seguenti punti (Figura1): 
• Traduzione dei linguaggi di specifica nel modello C.F.S.M. e verifica formale 
I vari linguaggi di specifica adottati per la descrizione del sistema vengono tradotti nel 
formalismo C.F.S.M., il sistema finale sar� composto da una rete C.F.S.M. in cui ogni elemento 
rappresenta un componente del sistema. Il modello C.F.S.M. viene poi verificato riportando 
(attraverso una traduzione automatica) il sistema in un formalismo F.S.M. a cui si applicano 
metodologie di verifica gi� collaudate. 
• Partizionamento 
Ad ogni C.F.S.M. viene assegnata una partizione software o hardware; essendo la 
rappresentazione indipendente dalla realizzazione, risulta agevole il passaggio da una all�altra 
partizione e quindi l�esplorazione dello spazio delle soluzioni. 
 
 
Capitolo 1 Il co-design e l'ambiente TOSCA 
 8 
• Sintesi software 
La realizzazione della componente software � ottenuta associando una procedura ad ogni 
C.F.S.M. marcata software oltre ad una parte di sistema operativo che permetta la gestione del 
sistema. Il sintetizzatore software consente di stimare le caratteristiche di velocit� e di 
occupazione di memoria del codice; ci� permette al progettista di valutare le caratteristiche 
della sintesi e, se i risultati non sono soddisfacenti, di modificare il modello. 
• Sintesi hardware e generazione delle interfacce 
La sottorete di C.F.S.M. che � etichettata hardware viene realizzata e ottimizzata attraverso le 
tecniche di sintesi logica presenti nell�ambiente SIS [SSL+92]. Ogni C.F.S.M., interpretata 
come specifica a livello RT, pu� essere tradotta in BLIF, XNF, VHDL o Verilog, e, attraverso 
gli strumenti di sintesi, il sistema finale viene realizzato su FPGA (XILINX). Inoltre, � stato 
realizzato un sistema per la generazione automatica delle interfacce tra i domini hw e sw. 
• Co-simulazione 
Una volta definite le caratteristiche di partizionamento del sistema � possibile selezionare il 
processore e la modalit� di schedulazione, ed eseguire la co-simulazione dell�intero sistema. 
2.2.2 Ptolemy 
Sviluppato presso l�Universit� della California, Berkeley, Ptolemy rappresenta un ambiente per la 
simulazione e la prototipazione di sistemi dedicati [BHLM92], [Ptolemy]. 
Il sistema � incentrato su una collezione di oggetti che, attraverso differenti formalismi, 
permettono la descrizione del sistema da realizzare. Tali oggetti vengono strutturati 
gerarchicamente e ogni livello gerarchico rappresenta un diverso livello di astrazione del sistema.  
In particolare, ogni livello di astrazione (dominio) riunisce gli oggetti atomici del sistema (stelle) 
che rappresentano le primitive per la descrizione del sistema. La comunicazione tra stelle � di tipo 
punto a punto e fa uso di code; inoltre ogni dominio include uno scheduler che definisce l�ordine 
di esecuzione degli oggetti che contiene. Infine i diversi domini sono raccolti in galassie che 
permettono di strutturare gerarchicamente il sistema. 
In questo modo � possibile raccogliere in un unico formalismo una grande variet� di oggetti 
differenti e applicare ai diversi domini gli strumenti pi� idonei all�implementazione delle varie parti. 
L�acquisizione del sistema avviene attraverso un linguaggio orientato agli oggetti (C++). Terminata 
questa fase, Ptolemy permette di analizzare lo spazio di progetto per determinare il 
partizionamento del sistema: il risultato ottenuto consiste in sottosistemi hardware, software, 
Capitolo 1 Il co-design e l'ambiente TOSCA 
 9 
interfacce, logica di controllo delle parti hw nonch� nel sistema operativo per lo scheduling delle 
parti sw e il controllo dell�intero sistema. 
La fase successiva riguarda la sintesi di tali sottosistemi: per le parti sw viene generato un codice C 
generico, successivamente tradotto nel linguaggio assembler del processore specifico, mentre la 
sintesi hw avviene attraverso la generazione di una descrizione sintetizzabile ed indipendente dalla 
tecnologia, tipicamente in linguaggi come il VHDL, e la successiva sintesi attraverso strumenti 
commerciali. 
La fase di sintesi delle interfacce, della logica di controllo e della parte di sistema operativo sono 
strettamente correlate e coinvolgono l�utilizzo di diversi strumenti. L�obiettivo finale � quello di 
arrivare ad automatizzare la sintesi di questi sottosistemi in modo da ottenere in tempi rapidi tutte 
le parti di supporto e di collegamento alle parti hw e sw. 
In particolare, per quanto concerne le parti hardware, l�approccio seguito in Ptolemy prevede i 
seguenti punti [Ka95]: 
• la rappresentazione iniziale del sistema viene tradotta in un grafo aciclico diretto (DAG) che 
rappresenta le dipendenze tra i dati ed � indipendente dalla particolare implementazione 
(hardware o software); 
• per ogni nodo del DAG marcato hardware viene generato un grafo hardware separato; poich� 
ogni nodo, nella descrizione originaria, poteva essere esploso in una gerarchia di nodi, il grafo 
hardware pu� contenere vari sottonodi; 
• i nodi hardware nel DAG vengono sostituiti da una rappresentazione equivalente, dipendente 
dalla tecnologia; tale rappresentazione, decisa nella fase di partizionamento, pu� essere in 
VHDL o in SILAGE (SILAGE [Hi85], � un linguaggio applicativo che ben si presta alla 
descrizione di sistemi per applicazioni DSP); 
• l�implementazione di ogni nodo viene affidata a uno strumento di sintesi hardware ad alto 
livello, allo scopo di generare datapath e unit� di controllo. In particolare lo strumento 
attualmente usato � HYPER [Rabaey91] che riceve in ingresso una descrizone in SILAGE. �� 
stato inoltre sviluppato un meccanismo automatico di generazione del codice SILAGE a 
partire da un grafo hardware. 
Capitolo 1 Il co-design e l'ambiente TOSCA 
 10 
2.2.3  System-Level Synthesis Group 
Sviluppato presso il Politecnico di Grenoble, SLS si compone di tre moduli principali coordinati 
da un quarto, che insieme costituiscono l�ambiente di co-design [SLSG],[JeOBr92]. 
COSMOS 
Costituisce il modulo di gestione e di coordinamento dell�ambiente di sviluppo; in particolare, 
partendo da una specifica a livello di sistema, COSMOS permette di arrivare alla sintesi delle parti 
hardware e software costituenti. 
Il sistema � costruito attraverso l�unificazione di tre domini differenti (Figura 2): 
• un dominio che produce una rappresentazione VHDL della parte hw; 
• un dominio che produce una rappresentazione C della parte sw; 
• un dominio che produce una rappresentazione intermedia per la comunicazione e 
l�interconnessione dei due domini precedenti. 
COSMOS utilizza i moduli VCI, AMICAL e SOLAR per realizzare tutte le fasi di sviluppo 
richieste. 
VCI 
� un sistema per la generazione automatica delle interfacce tra moduli descritti in VHDL e moduli 
descritti in linguaggio C. Le interfacce si basano sul meccanismo di comunicazione Unix IPC 
(Unix Interrupt Procedure Call). Il sistema genera automaticamente le interfacce VHDL/IPC e 
C/IPC e sfrutta le primitive di In/Out del protocollo IPC per realizzare la comunicazioni tra le 
parti. Una volta generate le interfacce di comunicazione tra le parti, VCI costituisce un ambiente 
idoneo per la cosimulazione in quanto pu� raccogliere e permettere lo scambio dei segnali 
provenienti dal simulatore VHDL, per la parte hw, e dall�esecuzione del programma C, per la parte 
sw. 
AMICAL 
La sintesi hardware avviene attraverso lo strumento interattivo AMICAL; esso consente il 
riutilizzo di componenti preesistenti e permette di affiancare una metodologia di progetto manuale 
ad una automatica. 
La descrizione in ingresso � fornita in VHDL comportamentale: su tale descrizione viene 
effettuata la fase di schedulazione e allocazione, generando una architettura composta da un 
datapath e una unit� di controllo. Il prodotto di tale sintesi viene tradotto automaticamente in 
Capitolo 1 Il co-design e l'ambiente TOSCA 
 11 
VHDL mediante lo strumento PAT (Programmable Architecture Translator) per poi essere passato a 
strumenti di sintesi come Synopsys, Synergy o Autologic, che lavorano a livello RT o logico. La 
descrizione in ingresso prevede l�uso di una libreria esterna di unit� funzionali che contiene 
operatori elementari, memorie, memorie cache, unit� di I/O, ma anche componenti molto 
complessi come DSP, nuclei CPU, periferiche intelligenti. Le operazioni svolte da tali componenti 
vengono referenziate nella descrizione VHDL attraverso funzioni e procedure. 
SOLAR 
SOLAR riceve in ingresso la struttura generata da AMICAL e produce due differenti architetture: 
• una descrizione del modello nel formato VHDL direttamente interpretabile dagli strumenti di 
sintesi commerciali; 
• una struttura (sempre in un linguaggio tipo VHDL) che viene utilizzata per la fase di 
simulazione del sistema. 
System
Description Language
AMICAL
Resources
Allocation
FU
Library
Statistic
Evaluation
Scheduling
Architecture
Interface
Generator
VCI
VHDL
Library
SOLAR
Logic
Synthesis
LAYOUT
Co-simulation
environment
COSMOS
 
Figura 2: L�ambiente di sviluppo SLS. 
2.2.4 Chinook 
Il progetto di ricerca Chinook, [COBo94], [CWBo94], sviluppato presso l�Universit� di 
Washington, Seattle, ha come principale obiettivo la sintesi delle interfacce hw e sw necessarie per 
integrare i componenti di un sistema di controllo dedicato. Il flusso di progetto si articola nel 
seguente modo (Figura3): 
Capitolo 1 Il co-design e l'ambiente TOSCA 
 12 
• Specifica ad alto livello: l�ingresso del sistema � una descrizione in Verilog, costituita da una 
parte strutturale, in cui vengono instanziati il/i processore/i e i dispositivi impiegati nel sistema 
(devices), e da una parte comportamentale, in cui vengono descritte le funzionalit� ad alto livello del 
sistema e possono essere fissati i vincoli temporali. � prevista una libreria di processori e 
componenti in cui sono fornite le specifiche di interfaccia (mediante diagrammi temporali) e i 
modelli di simulazione. 
• Partizionamento: la separazione delle funzionalit� tra hardware e software e tra i processori 
viene effettuata, di default, realizzando in hw i componenti istanziati nella descrizione 
strutturale e in sw le istruzioni presenti nella descrizione comportamentale. Il progettista pu� 
inserire delle etichette nella descrizione ad alto livello per modificare la partizione di default 
indicando quali funzionalit� e/o componenti realizzare secondo una delle due modalit�. 
• Sintesi automatica dei driver per i componenti: le funzionalit� dei dispositivi (devices) 
istanziati nella descrizione strutturale vengono incapsulate nei device drivers, costituiti 
dall�insieme delle istruzioni software per il microcontrollore e dall�hardware di interfaccia tra 
quest�ultimo e i dispositivi stessi. I driver dei dispositivi sono necessari per generare 
l�appropriata sequenza di segnali che consente al microprocessore di interagire correttamente 
con i dispositivi stessi. Chinook consente la sintesi automatica di tali driver, generando le 
procedure software corrispondenti alle operazioni del dispositivo, e la specifica delle macchine 
a stati finiti necessarie per interfacciare il processore al dispositivo e realizzare, mediante 
strutture hardware, le funzionalit� che non possono essere gestite direttamente dal software 
[WaBo94].  
• Allocazione delle porte di I/O e sintesi automatica delle interfacce: Chinook genera 
automaticamente le interfacce che connettono il processore ai dispositivi che esso controlla. 
Se presenti, vengono usate le porte di I/O del processore, aggiungendo dell�hardware per il 
multiplexing se il numero di porte non � sufficiente, altrimenti viene implementato uno 
schema memory mapped aggiornando le procedure dei driver. 
• Scheduling ad alto livello: completato il collegamento delle risorse di sistema, viene 
effettuato lo scheduling necessario per serializzare l�iniziale specifica comportamentale che 
pu� contenere elementi concorrenti, cercando di soddisfare i vincoli temporali. Nel caso in 
cui i vincoli non possano essere soddisfatti, il sistema viene ripartizionato. 
• Prodotto finale del sistema: Chinook fornisce in uscita le netlist dei componenti 
(dispositivi, processore, e logica sintetizzata per le interfacce) e il codice C per il processore.  
Capitolo 1 Il co-design e l'ambiente TOSCA 
 13 
Verilog
Specification
Timing
Constraints
Processor
&
Device
Library
Partitioner
Port
Allocation
&
Interface
Generator
Device
Driver
Generator
Scheduler
Netlist
Generator
And
Interface
Hardware
Generator
Code
Generator
and
Performance
Estimator
(C, Assembly)
input
output
 
Figura 3: Flusso di progetto in Chinook. 
Per quanto concerne la sintesi hardware dei dispositivi, si considerano gi� disponibili in libreria i 
modelli dei componenti hardware da usare, mentre per la sintesi automatica delle parti hardware 
dei driver e delle interfacce vengono realizzate delle macchine a stati finiti (F.S.M.) a partire dalla 
specifica degli eventi sui segnali. I metodi di sintesi impiegati sono quelli classici e vengono scelti 
algoritmi pi� o meno sofisticati a seconda della complessit� e della rigidit� dei vincoli temporali. In 
particolare, in fase di partizionamento, si cerca di minimizzare la dimensione delle macchine a stati 
e il numero di segnali che compaiono nella logica di interfaccia e, al posto di generare una F.S.M. 
dedicata per ogni funzionalit� di un dispositivo, si cerca di unire le F.S.M. in un�unica pi� grande. 
Non viene realizzata la sintesi logica delle F.S.M. poich� si presuppone l�uso di strumenti di sintesi 
commerciali. 
2.2.5  Cosyma 
Il progetto di ricerca Cosyma [BEKSS], [BeHeEr], sviluppato presso il Politecnico di 
Braunschweig, ha come obiettivo la co-sintesi di controllori per sistemi dedicati, di piccole 
dimensioni. Il flusso di progetto si articola nel modo seguente (Figura 4): 
• Specifica ad alto livello: la descrizione del sistema viene fornita in linguaggio C
x
, un superset 
del C, che consente di indicare i vincoli temporali e rappresentare parallelismo e 
comunicazione tra processi. 
Capitolo 1 Il co-design e l'ambiente TOSCA 
 14 
• Compilazione della descrizione, simulazione e profiling del sistema: la descrizione di 
ingresso viene tradotta, attraverso un compilatore C
x
, in un grafo sintattico esteso (ES graph) 
che viene utilizzato per la simulazione della descrizione ad alto livello tenendo conto del 
parallelismo. Il profiling permette di raccogliere le informazioni necessarie per l�analisi 
temporale del sistema. 
• Partizionamento: la descrizione mediante ES graphs viene partizionata a livello di blocchi 
base, utilizzando un algoritmo di simulating annealing basato su una stima della velocit� del 
sistema, del tempo necessario per eseguire la comunicazione tra processi nonch� del carico 
costituito dalle parti hardware. Cosyma cerca inizialmente di attribuire i blocchi base alla 
partizione software e, quando non riesce a soddisfare i vincoli temporali, destina parte della 
descrizione del sistema ad ASICs; tra i vari moduli che possono essere spostati nella partizione 
hardware, la scelta cade su quelli che presentano il costo minore. 
• Sintesi software: i moduli che devono essere realizzati software vengono estesi aggiungendo i 
protocolli di comunicazione e successivamente sono tradotti in linguaggio C e compilati. 
• Sintesi hardware: i moduli hardware sono generati mediante strumenti di sintesi ad alto 
livello; possono essere usati il sistema Olympus, sviluppato all�Universit� di Stanford, che 
prende in ingresso una descrizione in HardwareC o il tool BSS, sviluppato in Cosyma, che 
prende in ingresso dei CDFG. 
• Analisi e verifica dei vincoli: i prodotti delle due sintesi vengono analizzati per stimare 
accuratamente il tempo di esecuzione. Se i vincoli temporali sono rispettati il sistema di sintesi 
hardware genera una netlist a livello logico costituita da una unit� di controllo e da un datapath 
in formato SLIF (Stanford Logic Intermediate Format) o Verilog. 
• Cosimulazione: la co-verifica del sistema ottenuto viene effettuata sviluppando un sistema di 
prototipizzazione hardware dedicato, costituito da tre diverse piastre sincronizzate dal clock di 
sistema. 
L�architettura di riferimento scelta in Cosyma � costituita da un singolo processore (Sparc), da uno 
o pi� coprocessori e da periferiche specificate dall�utente. 
Per quanto riguarda la sintesi hardware, [HEHB95], il partizionamento del grafo determina i 
diversi segmenti di codice da realizzare hardware, che possono essere mappati su differenti 
funzionalit� del medesimo coprocessore. Risulta quindi necessaria una procedura di traduzione che 
assegni ogni chiamata del software alla corrispondente funzione hardware. Sono possibili due 
Capitolo 1 Il co-design e l'ambiente TOSCA 
 15 
strategie di sintesi: la prima fa uso dello strumento di sintesi hardware Olympus che riceve in 
ingresso una descrizione in HardwareC strutturata come un costrutto case; ogni qual volta il 
coprocessore � chiamato dal software viene trasferito un indice, che rappresenta la funzione che 
deve essere eseguita. L�alternativa � rappresentata dal sistema di sintesi per coprocessori dedicati 
BSS (Braunschweig Synthesis System). 
C
x
system
description
C
x
compiler
Compiler
Object code
Run
time
analysis
  HW/SW
partitioning
Prototyping
transformation
CPU
MEM
FPGA
FPGAFPGAFPGA
Logic netlist
HL-Synthesis
(BSS/OLYMPUS)
Logic synthesis
HW
description
SW
description
Communication
protocol
Communication
protocol
to ASIC design
ALU
models
 
Figura 4: Il flusso di progetto in Cosyma. 
Tra i requisiti che Cosyma si propone di soddisfare vi sono: 
• realizzazione del parallelismo oltre l�ambito rappresentato dai cicli (le parti del sistema da 
implementare hardware sono cicli o contengono funzioni con cicli);