Sistemi Dedicati Multiprocessore: Sincronizzazione ...POLITECNICO DI MILANO Facolta di Ingegneria`...

POLITECNICO DI MILANO

Facolta di IngegneriaDipartimento di Elettronica e Informazione

Sistemi Dedicati Multiprocessore:Sincronizzazione Hardware Tramite

Semafori

Relatore: Prof. Fabrizio FERRANDI

Correlatore: Ing. Marco Domenico SANTAMBROGIO

Tesi di Laurea di:

Alessandro MELE Matr. 651881

Francesca MALCOTTI Matr. 651479

Anno Accademico 2003/2004

POLITECNICO DI MILANO

Facolta di IngegneriaDipartimento di Elettronica e Informazione

Sistemi Dedicati Multiprocessore:Sincronizzazione Hardware Tramite

Semafori

Relatore: Prof. Fabrizio FERRANDI

Correlatore: Ing. Marco Domenico SANTAMBROGIO

Tesi di Laurea di:

Alessandro MELE Matr. 651881

Francesca MALCOTTI Matr. 651479

Tesi di Laurea

Alessandro Mele e Francesca Malcotti

Luglio 2004

Alle nostre famiglie

...con affetto...

Indice

Introduzione 1

1 Definizioni e Stato dell’Arte 4

1.1 Introduzione. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2 Sviluppo Tecnologico e FPGA. . . . . . . . . . . . . . . . . . . 7

1.3 Architetture multiprocessore. . . . . . . . . . . . . . . . . . . . 13

1.3.1 Condivisione dei dati fra processori paralleli. . . . . . . 14

1.3.2 Coordinamento fra processori paralleli. . . . . . . . . . . 17

1.4 Architetture a memoria condivisa centralizzata. . . . . . . . . . . 17

1.4.1 Coerenza della cache in un multiprocessore. . . . . . . . 18

1.4.2 Sincronizzazione. . . . . . . . . . . . . . . . . . . . . . 21

1.5 Sincronizzazione Hardware. . . . . . . . . . . . . . . . . . . . . 23

2 Descrizione della Metodologia 25

2.1 Condivisione delle Risorse. . . . . . . . . . . . . . . . . . . . . 25

2.1.1 Garantire la Mutua Esclusione. . . . . . . . . . . . . . . 27

2.2 Interrupt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.3 Device Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.3.1 Architettura dei Device Driver. . . . . . . . . . . . . . . 32

2.3.2 Scelta del livello di interfaccia. . . . . . . . . . . . . . . 34

3 Implementazione della Metodologia 35

3.1 Introduzione ai tools utilizzati . . . . . . . . . . . . . . . . . . . 36

3.1.1 Xilinx Platform Studio. . . . . . . . . . . . . . . . . . . 36

ii

Indice

3.1.2 ModelSim. . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.2 Architettura multiprocessore di riferimento. . . . . . . . . . . . 41

3.3 Implementazione di un IP core in VHDL. . . . . . . . . . . . . . 44

3.4 Inserimento di un IP core nell’architettura. . . . . . . . . . . . . 49

3.5 Gestione degli interrupt. . . . . . . . . . . . . . . . . . . . . . . 52

3.5.1 Interrupt Controller. . . . . . . . . . . . . . . . . . . . . 53

3.5.2 Esempio di applicazione. . . . . . . . . . . . . . . . . . 55

3.6 Driver per la periferica. . . . . . . . . . . . . . . . . . . . . . . 64

3.6.1 Microprocessor driver definition. . . . . . . . . . . . . . 65

3.6.2 Formato del file adderv2 1 0.mdd. . . . . . . . . . . . . 66

3.6.3 Formato del file adderv2 1 0.tcl . . . . . . . . . . . . . . 69

3.6.4 Makefile e LibGen. . . . . . . . . . . . . . . . . . . . . 69

3.7 Scrittura e gestione della memoria. . . . . . . . . . . . . . . . . 72

4 Conclusioni e Sviluppi Futuri 78

Ringraziamenti 80

Bibliografia 84

iii

Elenco delle figure

1.1 Processor Performance (SPEC). . . . . . . . . . . . . . . . . . . 8

1.2 La struttura riconfigurabile di una FPGA. . . . . . . . . . . . . . 9

1.3 Un blocco logico standard. . . . . . . . . . . . . . . . . . . . . 10

1.4 Vista semplificata di un blocco logico di una FPGA di Xilinx,

serie 4000. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.5 Schema di uno slice. . . . . . . . . . . . . . . . . . . . . . . . . 12

1.6 Struttura di base di un multiprocessore a memoria condivisa cen-

tralizzata. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.7 Architettura di base di una macchina a memoria distribuita. . . . 16

1.8 Multiprocessore a bus singolo che utilizza il protocollo di snoop-

ing per gestire la coerenza della cache. . . . . . . . . . . . . . . 19

1.9 Step necessari ad acquisire un lock (per sincronizzare i processi)

e rilasciarlo al termine della sezione chiave del codice. . . . . . . 22

2.1 Esempio di configurazione hardware in cuie presente la Semaphore

Engine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26

2.2 Memoria Condivisa a cui accedono i processori. . . . . . . . . . 27

2.3 Il Driver come interfaccia tra hardware e software. . . . . . . . . 31

2.4 Strati dell’architettura dei Device Driver. . . . . . . . . . . . . . 32

3.1 Schermata principale di Xilinx Platform Studio. . . . . . . . . . 37

3.2 Visione grafica dell’architettura. . . . . . . . . . . . . . . . . . . 38

3.3 Visione testuale dell’architettura. . . . . . . . . . . . . . . . . . 38

3.4 Finestra Object Properties di un IP core. . . . . . . . . . . . . . 39

iv

Elenco delle figure

3.5 Finestra Software Platform Settings. . . . . . . . . . . . . . . . 39

3.6 Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.7 Schermata principale di Modelsim. . . . . . . . . . . . . . . . . 41

3.8 Segnali del componente selezionato. . . . . . . . . . . . . . . . 42

3.9 Andamento dei segnali del componente nel tempo. . . . . . . . . 42

3.10 System.pbd dell’architettura di riferimento. . . . . . . . . . . . . 43

3.11 Microblaze con relativa memoria. . . . . . . . . . . . . . . . . . 44

3.12 Rappresentazione sintetica dell’architettura di partenza. . . . . . 45

3.13 Componenti dell’adder. . . . . . . . . . . . . . . . . . . . . . . 46

3.14 Interfaccia di Pselect . . . . . . . . . . . . . . . . . . . . . . . . 46

3.15 Ciclo di scrittura o di lettura abilitati da CS. . . . . . . . . . . . 47

3.16 Process di lettura e scrittura. . . . . . . . . . . . . . . . . . . . . 48

3.17 Gerarchia delle cartelle di adderv1 00 a contenuto in pcores. . . 50

3.18 Step 8 del tool “Import peripheral wizard”. . . . . . . . . . . . . 51

3.19 Coerenza nell’impostazione della sensitivity del segnale di inter-

rupt dell’adder e dei microblaze. . . . . . . . . . . . . . . . . . 52

3.20 Adder inserito nei componenti standard di EDK. . . . . . . . . . 52

3.21 Interrupt controller presente nei componenti standard di EDK. . . 53

3.22 Possibile struttura che utilizza l’interrupt controller. . . . . . . . 54

3.23 System.pbd dell’architettura risultante. . . . . . . . . . . . . . . 56

3.24 Sezione object properties di adder1. . . . . . . . . . . . . . . . . 57

3.25 Sezione Interrupt di adder1. . . . . . . . . . . . . . . . . . . . . 58

3.26 Net collegata alla porta Intr dell’opbintc . . . . . . . . . . . . . . 59

3.27 Sezione Interrupt di opbintc . . . . . . . . . . . . . . . . . . . . 59

3.28 Net collegata alla porta Intr dell’opbintc . . . . . . . . . . . . . . 60

3.29 Riassunto delle porte e net settate. . . . . . . . . . . . . . . . . . 61

3.30 Struttura dell’esempio. . . . . . . . . . . . . . . . . . . . . . . . 61

3.31 Metodo che gestisce l’interrupt sollevato dal componente adder. . 62

3.32 Inserimento della funzione diint handler . . . . . . . . . . . . . 64

3.33 Parametri relativi ad adder1 e adder2. . . . . . . . . . . . . . . . 64

3.34 Definizione del driver per il componente adder nel file System.mss65

v

Elenco delle figure

3.35 Scelta del driver per il componente adder nella finestra di dialogo. 66

3.36 adderv2 1 0.mdd. . . . . . . . . . . . . . . . . . . . . . . . . . 67

3.37 Un IP core con driver generic non puo avere una funzione inthandler 68

3.38 Adder non autorizzato ad avere una funzione inthandler . . . . . 68

3.39 adderv2 1 0.tcl . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

3.40 Makefile del componente adder. . . . . . . . . . . . . . . . . . . 70

3.41 Apertura file .tcl. . . . . . . . . . . . . . . . . . . . . . . . . . . 70

3.42 Definizione dei parametri dei due componenti adder1 e adder2. . 71

3.43 Crezione di una sottocartella relativa al driver del componente adder71

3.44 Compiling adder . . . . . . . . . . . . . . . . . . . . . . . . . . 72

3.45 I tre settori della bramblock . . . . . . . . . . . . . . . . . . . . 73

3.46 Settare lo spazio di indirizzamento della memoria. . . . . . . . . 74

vi

Elenco delle tabelle

3.1 Operazioni svolte dall’adder. . . . . . . . . . . . . . . . . . . . 49

vii

Introduzione

Questo lavoro di tesi si propone di fornire una metodologia per la definizione

ed implementazione di un IP core,intellectual property core, che realizzi le fun-

zionalita di un motore di gestione della concorrenza hardware. La metodologia

proposta sara sviluppata con l’ausilio del tool di sviluppo per FPGA di proprieta

della Xilinx, Embedded Development Kit, EDK.

Il tipo di IP core che si vuole realizzaree tale per cui questo possa essere inserito

all’interno di sistemi multiprocessore completamente integrati in un dispositivo

programmabile della famiglia Virtex-II Pro della Xilinx.

La realizzazione di un motore di gestione della concorrenza hardware,Concur-

rency Engine, consiste nella realizzazione di un sistema digitale che esegua una

serie di attivita solitamente svolte da parte del sistema operativo. Queste attivita

consistono fondamentalmente nella gestione dell’accesso concorrente da parte di

piu processi a risorse condivise.

Tale meccanismo di gestione della concorrenzae stata realizzato, precedente-

mente a questo lavoro di tesi, come un IP collegato ad un bus OCP, Open Core

Protocol (si rimanda a [19] per la specifica del bus); quest’ultimo definisce un’in-

terfaccia, ad alte prestazioni e indipendente dal bus, fra diversi IP core, riducendo

tempi e rischi di progettazione, nonche i costi di produzione per sistemi SoC, Sys-

tem on Chip. Il protocollo Open Core definisce un’interfaccia punto a punto tra

due entita comunicanti, come possono essere gli IP core e i moduli di interfaccia-

mento sul bus; una entita agisce come master dell’istanza OCP, l’altra come slave:

solo il master puo presentare richieste in quanto entita di controllo, mentre lo slave

risponde alle richieste pervenute accettando i dati dal master o presentando dati al

1

Introduzione

master. In particolare, nel caso in cui siano presenti due entita che comunichino

tra loro in modalita peer-to-peer e che quindi possano essere sia master che slave,

occorre avere due istanze OCP per connetterle. La specifica “funzionale” del mo-

tore di gestione della concorrenza, nella suo completezza,e stata fornita tramite il

linguaggio di descrizione dello hardware SystemC.

Con riferimento alla specifica menzionata, il presente lavoro di tesi si propone di

realizzare una specifica VHDL sintetizzabile collegata al bus OPB,On-chip Pe-

ripheral BUS; un sistema di questo tipoe composto da master, da slave, da un bus

di interconnessione e da un arbitro.

Un motore di gestione della concorrenza hardware deve fornire il meccanismo di

accesso concorrente a risorse condivise, secondo diverse politiche di sincroniz-

zazione; di seguito si riporta una breve descrizione delle primitive che quest’ulti-

mo dovrebbe rendere disponibili:

1. Semafori: Sono meccanismi per ottenere e segnalare lock sulle risorse con-

divise. Il loro funzionamentoe lo stesso dei semafori dei sistemi operativi

di tipo Unix.

2. Monitor: Apporre un monitor su una risorsa significa porsi in attesa del suo

stato “libero” in modo da potervi accedere. Ogni qual volta una risorsa si

libera, il monitor ad essa associata risveglia uno (o tutti) i processi in attesa

su quella risorsa.

3. Condition: I Processi rimangono in attesa diconditions. Una volta che una

di questee generata, uno o piu processi rimangono in attesa finche tale

condizione none segnalata. IMonitor rimangono in attesa di tali condizioni.

4. Timeout Condition: Condizioni dotate di timeout.

5. Priority Queue: Coda dotata di priorita. Serve per gestire le richieste in at-

tesa su una determinata condizione. Le richieste saranno servite nell’ordine

dato dalla coda e in funzione della loro priorita di esecuzione.

In questo lavoro di tesi viene approfondita la sincronizzazione hardware tramite il

meccanismo dei semafori, ovvero si propone una metodologia che porti alla sintesi

2

Introduzione

di un motore di accesso concorrente per mezzo di semafori, laSemaphore Engine.

La metodologia e la successiva implementazione proposta ricalcano una serie di

passi e studi fondamentali, che sono stati compiuti rigorosamente in successione

e che hanno come fine ultimo quello della sintesi della Semaphore Engine.

La tesi si articola in quattro capitoli: nelCapitolo 1, Definizioni e Stato dell’Arte,

vengono fornite una serie di definizioni e di conoscenze generali, utili per una

migliore comprensione del lavoro di tesi svolto; nelCapitolo 2, Descrizione della

Metodologia, viene approfondita la metodologia secondo cuie stato affrontato il

problema della concorrenza, soffermandosi sui concetti essenziali per il raggiun-

gimento delle funzionalita hardware desiderate; successivamente nelCapitolo 3,

Implementazione della Metodologia, vengono esaminati ed approfonditi i metodi

e gli studi implementativi che hanno, per passi successivi, condotto alla sintesi

dell’architettura proposta; infine, nelCapitolo 4, Conclusioni e Sviluppi Futuri,

vengono commentati i risultati ottenuti durante il lavoro di tesi e, inoltre, vengono

proposti suggerimenti concreti per possibili sviluppi futuri.

3

Capitolo 1

Definizioni e Stato dell’Arte

Negli ultimi anni in molti settori, come quello delle telecomunicazioni, dei si-

stemi di elaborazione e dell’elettronica di consumo, sie assistito in modo sempre

piu crescente alla richiesta e necessita, da parte degli utenti delle moderne appli-

cazioni, di avere a disposizione sistemi molto flessibili, in grado di adattarsi alle

esigenze e ai requisiti del consumatore, spesso variabili nel tempo. Questa carat-

teristicae oggi offerta dai dispositivi programmabili di tipo Field Programmable

Gate Arrays, FPGA, i quali si propongono come una valida ed economica alter-

nativa alle logiche di tipo Application Specific Integrated Circuits, ASIC. Questi

dispositivi hanno il vantaggio di poter essere riprogrammati non solo staticamente

ma anche dinamicamente. Cio significa che una parte di essi puo essere riconfigu-

rata mentre la restante parte di FPGAe operativa.

Questo capitolo ha lo scopo di introdurre alcuni concetti e definizioni necessari

per una efficace e migliore comprensione degli argomenti trattati in questo lavoro

di tesi. Il capitoloe organizzato nel seguente modo:

• Sviluppo Tecnologico e FPGASi discute l’andamento tecnologico dei dispositivi riconfigurabili, analiz-

zando il funzionamento di base delle FPGA.

• Architetture MultiprocessoreVengono introdotte ed analizzate le caratteristiche delle architetture multi-

processore.

4

CAPITOLO 1. DEFINIZIONI E STATO DELL’ARTE

• Architetture a Memoria Condivisa CentralizzataSono analizzati in dettaglio gli aspetti riguardanti le architetture con piu

processori, aventi a disposizione una memoria condivisa, collegati mediante

un unico bus.

• Sincronizzazione HardwareViene introdotto il meccanismo di controllo dell’accesso concorrente da

parte di piu processori a risorse condivise.

1.1 Introduzione

Oggi molte delle applicazioni embedded richiedono un gran numero di com-

ponenti hardware diversi. Per questo motivo le architetture System on Chip, SoC,

stanno prendendo piede come soluzioni per molte di queste applicazioni. Tali piat-

taforme, eliminando quasi completamente la necessita di avere piu componenti

hardware per un solo sistema, danno ai progettisti un grado di liberta impensabile

in precedenza con i sistemi ASIC, riducendo i costi e i tempi di realizzazione.

Tuttavia tipicamente i SoC hanno ancora una sola configurazione per tutte le pe-

riferiche. Attualmente i microprocessori con le piu alte prestazioni sono dotati di

2 o 3 milioni di transistor e includono unita funzionali multiple e grandi memo-

rie on-chip. I microprocessori per sistemi embedded, costruiti per avere un basso

costo, presentano una spinta integrazione delle periferiche, al fine di ridurre il

numero di chip necessari per un sistema completo. Con il continuo e rapido avan-

zamento della tecnologia, si cerca sempre piu di migliorare le prestazioni, con

unita funzionali aggiuntive, e di ridurre i costi integrando una maggiore porzione

del sistema nei circuiti integrati del microprocessore [3].

Tuttavia la semplice aggiunta di funzionalita hardware non sempre produce le

migliori performance per la piu ampia classe di applicazioni e soprattutto non

permette la costruzione di una vasta gamma di sistemi a basso costo. La spin-

ta integrazione di unita funzionali fisse rischia di rendere troppo specializzato il

prodotto, restringendone il campo di utilizzo, e conseguentemente diminuendo il

valore dell’investimento.

5


Per questo tipo di applicazioni i processori futuri tenderanno a dedicare una loro

area a logiche riprogrammabili anziche fisse. La logica programmabile puo essere

specializzata in modo da fornire un’accelerazione per una data applicazione, op-

pure puo servire come supporto per implementare funzioni del sistema.

In questo modo una singola architettura con un processore riprogrammabile puo

essere la base per una svariata quantita di applicazioni diverse, sia specializzate

che di tipo general purpose. Grazie a questa caratteristica le FPGA possono im-

porsi con forza nel mercato delle economie di scala [15].

Per raggiungere un sempre piu elevato grado di soddisfacimento delle aspettative

riguardo alle prestazioni e allo scopo di controllare problemi via via piu grandi

e sempre piu complessi, si puo facilmente osservare come l’architettura dei com-

puter stia facendo ricorso in modo oramai diffuso al calcolo in parallelo, ovvero

ai sistemi multiprocessore.E un dato di fatto che, sebbene i computer diventi-

no sempre piu veloci, le aspettative riguardo alle prestazioni aumentino almeno

altrettanto velocemente; in breve, per quanta potenza computazionale sia disponi-

bile, per alcuni utenti, specialmente in campo ingegneristico, scientifico e indu-

striale, questa non sara mai abbastanza; in questo contesto ben si colloca la nota

legge di Amdahl, secondo la quale introdurre il “parallelismo” in un sistema non

porta sempre ad un aumento di prestazioni proporzionale, soprattutto in presenza

di codice che va eseguito sequenzialmente. Anche se le frequenze di clock sono

continuamente in crescita, la velocita dei circuiti non potra essere aumentata in-

definitamente. La velocita della luce costituisce gia oggi un problema centrale per

i progettisti di computer di fascia alta e in alternativa le prospettive di riuscire a

spingere gli elettroni e i fotoni a muoversi piu velocemente sono di certo molto

deboli. Le problematiche di dissipazione del calore stanno trasformando l’area di

ricerca dei supercomputer nello stato dell’arte della scienza del condizionamento

dell’aria. E, infine, dato che le dimensioni dei transistor continuano a diminuire,

ad un certo punto ogni transistor sara composto da cosı pochi atomi che gli effetti

quantomeccanici (cioe il principio d’incertezza di Heisenberg) si faranno sentire

diventando visibili [17].

In effetti, mentre non sarebbe sicuramente possibile costruire un computer con

6


una unicaCPU dotata di un ciclo di clock di 0,001 nano-secondi, potrebbe essere

invece possibile costruirne uno equipaggiato di1000CPU, ognuna con un ciclo di

clock di 1 singolo nano-secondo. Sebbene quest’ultima architettura usi CPU piu

lente della prima, la capacita computazionale globale di questo sistemae, almeno

dal punto di vista teorico, equivalente. Questa la speranza [17].

1.2 Sviluppo Tecnologico e FPGA

Nella storia degli ultimi cinquanta anni la tecnologia dell’elettronica digitalee

andata migliorando esponenzialmente, raddoppiando le prestazioni ogni 18 mesi

circa, in corrispondenza della crescita delle dimensioni dei dispositivi e dei loro

costi. Nel contempo il numero dei chipe raddoppiato ogni due anni circa [9]. Le

tecnologie dei semiconduttori continuano a svilupparsi e, di conseguenza, la den-

sita e la capacita dei circuiti integrati cresce ad un ritmo esponenziale, permetten-

do la fabbricazione di dispositivi sempre piu piccoli. Questo trend mostra tuttavia

precisi segnali di attenuazione; il progresso dei microprocessori, infatti, ci mostra

come la potenza di calcolo cresca del 60% all’anno, mentre il numero dei gate

aumenti del 25% l’anno. A mano a mano che la densita cresce, molti dei sistemi

di computazione tendono ad essere integrati in un unico processore. Ricordiamo

che i primi processori integravano ALU a 4 bit, mentre oggi arriviamo ad avere

unita funzionali multiple a 64 bit che includono il supporto a calcoli in virgola

mobile. Oggi i microprocessori ad alte prestazioni tendono a migliorare sempre

piu la velocita di esecuzione attraverso l’uso di pipeline molto“aggressive” e

dell’esecuzione superscalare, grazie all’utilizzo di unita funzionali multiple. Si

tende, inoltre, a perfezionare il circuito integrato con l’aggiunta di sempre piu

funzioni, precedentemente svolte da altre periferiche hardware, al fine di ridurre

i costi di produzione e l’assorbimento di potenza [7]. A causa di queste continue

evoluzioni dei componenti, le architetture dei calcolatori devono essere costante-

mente riesaminate e modificate. Nell’arco di tempo di pochi anni, una soluzione

brillante diventa obsoleta e troppo semplicistica, mentre dall’altro lato diventano

economiche tecnologie precedentemente costose [15].

7


Figura 1.1: Processor Performance (SPEC).

Negli ultimi dieci anni i microprocessori superscalari hanno rappresentato lo stan-

dard per i processori dei personal computer. Tuttavia questo tipo di dispositivi non

sara per molto altro tempo in grado di reggere l’avanzamento tecnologico. Avvi-

cinandosi al giorno in cui un singolo chip potra contenere 100 milioni di transis-

tors, sembra improbabile che le architetture superscalari da sole permetteranno di

sfruttare tutto il potenziale disponibile in termini di quantita di componenti com-

putazionali. I microprocessori continueranno la loro crescita integrando sempre

piu memoria, piu unita logiche aritmetiche e sempre piu funzionalita, ma oggi

none ben chiaro se questa tendenza risultera essere il modo migliore di utilizzare

le risorse di silicio che la tecnologia rendera disponibili nel prossimo futuro. L’ag-

giunta di unita funzionali fisse non portera ad una giustificabile accelerazione delle

applicazioni, se paragonata all’area che queste unita occuperanno; ogni classe di

applicazioni richiede diverse unita funzionali ed anche una diversa organizzazione

delle stesse, per avere un certo incremento delle prestazioni. Una soluzione alter-

nativa, che permette un maggior guadagno in prestazioni e costi,e di realizzare

dispositivi specializzati per determinate applicazioni. Tale specializzazione deve,

pero, essere ben bilanciata con la dimensione del mercato, poiche deve sempre

essere mantenuto un buon livello di produzione e vendita se si vuole beneficiare

8


dei vantaggi di un’economia di scala [7]. Una seconda alternativa che puo essere

considerata per lo sviluppo futuro in questo campoe basata sulla tecnologia delle

Field Programmable Gate Arrays, o FPGA.

Le FPGA sono dispositivi caratterizzati dalla possibilita di essere riprogrammati

un qualsiasi numero di volte, la Figura1.2ne mostra la struttura. Durante gli ultimi

anni le tecnologie riconfigurabili sono diventate un bene diffuso e di costo relati-

vamente basso, comparabili alle memorie e ai microprocessori. La struttura delle

FPGA consiste in una serie di array di oggetti molto semplici. Inoltre la regolarita

della loro struttura permette ai progettisti di concentrarsi su come adattare le strut-

ture piu importanti della logica, per sfruttare al massimo la tecnologia disponibile

ed ottenere le migliori prestazioni [7]. Agli albori della tecnologia delle FPGA

Figura 1.2: La struttura riconfigurabile di una FPGA.

riprogrammabili gli algoritmi che potevano essere implementati in un singolo

chip erano molto piccoli. Nel 1995, ad esempio, l’FPGA piu grande poteva es-

sere programmata per circuiti di circa 15.000 porte logiche. L’accelerazione di

applicazioni e l’adattamento dei sistemi puo essere raggiunto specializzando la

logica riconfigurabile per il particolare sistema o applicazione. [7]. Tutto cio ha

portato ad un nuovo concetto di computazione: se un processore include uno o piu

dispositivi riprogrammabili, esso in teoria puo supportare qualunque applicazione

9


specializzata o qualsiasi programma. La possibilita di riconfigurazione illimitata

permette di implementare in continuazione sequenze di circuiti specializzati, cias-

cuno ottimizzato per il compito da eseguire in quel momento. Dunque le FPGA

hanno potenzialmente la possibilita di sfruttare al meglio lo sviluppo tecnologico

futuro [9].

Il blocco logico di base di una FPGA prende il nome di LookUp Table, nota come

LUT. Questa riceve quattro bit in input e genera un bit di uscita, come mostra-

to in Figura1.3. Cambiando il valore della LUT si puo ottenere qualunque fun-

zione a quattro bit, quindie possibile implementare una qualsiasi logica, a patto

di rispettare i vincoli fisici delle risorse disponibili. La scelta di avere una LUT a

quattro bite stata adottata dopo vari studi che hanno evidenziato come questa rap-

presenti un buon compromesso, per questi dispositivi, tra prestazioni e utilizzo. Il

Figura 1.3: Un blocco logico standard.

motivo per cui avere LookUp Table molto grosse none stato ritenuto adeguato, pur

potendo in questo modo implementare funzioni piu complesse utilizzando meno

unita logiche,e dovuto al fatto che per funzioni semplici sarebbe stata effettiva-

mente utilizzata solo una frazione delle capacita di calcolo disponibili [13], [11].

La tendenza attualee pero quella di avere dei blocchi logici piu complessi di una

10


singola LUT. In Figura1.4 e riportato lo schema semplificato di un blocco logico

di una FPGA Xilinx serie 4000, che ha due LookUp Tables con quattro bit di input

e una LUT aggiuntiva a tre ingressi, per un totale di undici bit di input e quattro

di output [16], [21]. Nella parte alta della figura si puo inoltre notare la presenza

Figura 1.4: Vista semplificata di un blocco logico di una FPGA di Xilinx, serie 4000.

di un circuito dedicato alla gestione dei bit di riporto, che rende molto semplice

l’unione di piu blocchi logici per formare un sommatore ad elevato numero di bit.

Un FPGAe un circiuto integrato che puo contenere da 64 a 10000 celle logiche

identiche, che possono essere viste come i componenti standard del dispositivo.

Ogni cella logica puo assumere una specifica funzione, tra le varie possibili. Le

celle infine sono collegate tra di loro da una matrice di connessioni e di interruttori

programmabili. Un blocco logico definito dall’utentee implementato specifican-

do la funzione logica di ogni cella e creando le giuste interconnesioni tra di esse

chiudendo opportunamente gli interruttori della matrice. Combinando piu blocchi

logici tra loro,e possibile realizzare architetture anche molto complesse.

La dicitura Field Programmable sta ad indicare che una particolare funzione che

11


deve essere implementata dall’FPGAe definita da un file di programmazione del-

l’utente finale e non dal produttore del dispositivo. In base al particolare tipo di

chip, inoltre, il programmae scritto in modo permanente o semi-permanente, op-

puree caricato da una memoria esterna ogni volta che il dispositivo viene acceso.

Le FPGA proposte da Xilinx sono composte da tre principali elementi configura-

bili: le CLB, i blocchi di input/output e le interconnessioni. Le CLB costituiscono

gli elementi funzionali per la costruzione della logica. I blocchi di input/output

offrono l’interfaccia tra i contatti del dispositivo e le linee dei segnali interni. Le

interconnessioni programmabili permettono una appropriata rete che connetta op-

portunamente gli ingressi e le uscite delle CLB e dei blocchi di input/output [8].

Ogni CLB contiene quattro celle logiche, organizzate in due slices. La Figura1.5

mostra una visione dettagliata di una singola slice. Per la famiglia di prodotti Vir-

Figura 1.5: Schema di uno slice.

tex di Xilinx i generatori di funzioni sono implementati con LookUp Tables a

quattro bit di input.

Il mercato offre oggi molti differenti tipi di FPGA, caratterizzati da architetture e

12


tecnologie diverse.

Esistono quattro categorie principali di dispositivi attualmente disponibili: Sym-

metrical Array, Row-Based, Hierarchical PLD e Sea-of-Gates. Tra tutti questi tipi

sono presenti delle differenze sulle interconnessioni e su come queste vengono

programmate. A ciascuna di queste categorie corrisponde una particolare tecnolo-

gia impiegata nella fabbricazione: Static RAM Cells, Anti-Fuse, EPROM transis-

tors ed EEPROM transistors. Ne risulta, percio, che ogni FPGA ha delle particolari

caratteristiche che la rendono adatta a certi tipi di applicazioni [20].

1.3 Architetture multiprocessore

Grazie alla continua evoluzione della tecnologia basata su microprocessori,

negli ultimi anni sie assistito alla progettazione di sistemi molto grandi e sofisti-

cati in grado di risolvere problemi complessi. In particolare, grazie alla loro poten-

zialita crescente, i microprocessori sono diventati indispensabili per l’impiego in

un’ampia gamma di applicazioni dedicate. Tali sistemi embedded, pero, presen-

tano dei vincoli di progetto: richiedono la garanzia di un crescente potere com-

putazionale e, allo stesso tempo, il mantenimento di costi relativamente bassi. Il

conflitto che si crea tra tali obiettivi puo essere risolto mediante l’utilizzo dimul-

tiprocessori, cioe impiegando contemporaneamente piu microprocessori su uno

stesso sistema: tali dispositivi infatti sono presenti sul mercato a basso costo e

permettono di incrementare le prestazioni del sistema se utilizzati in parallelo.

“To create powerful computers simply by connecting many existing smaller one”

[5]: questae la visione migliore che sta alla base dei multiprocessori, ovvero

creare un computer potente semplicemente connettendo molti computer piu pic-

coli gia esistenti. Il modo logico per migliorare le prestazioni rispetto a quelle

di un singolo processoree, infatti, quello di collegare insieme piu microproces-

sori: ne deriva il vantaggio offerto dalle macchine parallele, ovvero un rapporto

costo/prestazioni migliore rispetto al progetto di un processore dedicato. Un al-

tro punto a favore dell’impiego di tale strutturae dato dal fatto che vie un lento

ma costante superamento del principale ostacolo all’uso delle macchine parallele,

13


cioe il software. A supporto del fatto che la tecnologia basata su multiproces-

sori offre migliori prestazioni rispetto ad un processore singolo, si puo aggiungere

che se il numero di processori all’interno della struttura puo cambiare, cioe hard-

ware e software sono implementati per essere utilizzati con un numero variabile di

microprocessori, nel multiprocessore puo essere garantito comunque il funziona-

mento anche in presenza di hardware rotto: se infatti uno degli n processori che

compongono il multiprocessore fallisce, il sistema fornisce continuita garantendo

l’esecuzione del software su n-1 processori.

1.3.1 Condivisione dei dati fra processori paralleli

L’idea di usare piu processori per migliorare sia le prestazioni sia la disponi-

bilit a risale ai primi tempi della progettazione di computer elettronici. Circa 30 an-

ni fa, Flynn ha proposto un semplice modello che suddivide i computer in quattro

categorie in base al parallelismo tra le istruzioni e i dati richiesti dalle istruzioni,

[10]:

• SISD - singolo flusso di istruzioni, singolo flusso di dati

• SIMD - singolo flusso di istruzioni, flussi multipli di dati

• MISD - flussi multipli di istruzioni, singolo flusso di dati

• MIMD - flussi multipli di istruzioni, flussi multipli di dati

Negli ultimi anni e emerso che il MIMDe l’architettura preferenziale per

multiprocessori destinati ad applicazioni generiche; tali macchine sono quelle in

cui ogni processore carica le proprie istruzioni e agisce sui propri dati. I fattori

principalmente responsabili dell’ascesa delle macchine MIMD sono due:

• le macchine MIMD sono flessibili. Con un adeguato hardware e software

di supporto, tali macchine possono essere utilizzate sia come computer per

un solo utente, per ottenere prestazioni elevate in un’applicazione, sia come

computer multiprogrammati per eseguire piu task contemporaneamente, o

anche come una combinazione di questi due casi;

14


• le macchine MIMD possono sfruttare i vantaggi in termine di costo/presta-

zioni offerti dai microprocessori comuni; infatti, quasi tutti i multiprocessori

costruiti al giorno d’oggi usano gli stessi microprocessori che si trovano

nelle workstation e nei piccoli server monoprocessore.

Le macchine MIMD attuali si dividono in due categorie in base alla loro organiz-

zazione di memoria [10].

Il primo gruppoe costituito dallearchitetture a memoria condivisa centralizzata. I

Figura 1.6: Struttura di base di un multiprocessore a memoria condivisa centralizzata.

multiprocessori con pochi processori possono condividere un’unica memoria cen-

tralizzata e collegare i processori mediante un bus, come si puo vedere in Figura

1.6; con l’aiuto di cache grandi, un bus e una memoria singola possono soddisfare

le richieste di memoria di un numero limitato di processori. Poiche c’e una memo-

ria principale con un tempo di accesso uguale per ogni processore, queste mac-

chine a volte vengono chiamateUMA, dall’ingleseuniform memory access, cioe

accesso alla memoria uniforme, e rappresentano attualmente l’organizzazione piu

diffusa.

Il secondo gruppo comprende lemacchine con la memoria fisicamente distribui-

ta. In un sistema con un numero elevato di processori una memoria centralizzata

non sarebbe in grado di soddisfare la banda richiesta; in un tale sistema, percio, la

15


Figura 1.7: Architettura di base di una macchina a memoria distribuita.

memoria deve essere distribuita fra i processori. Tale architetturae rappresentata

in Figura1.7.

La distribuzione della memoria tra i nodi ha due vantaggi principali: in primo

luogo, e un modo di aumentare la banda di memoria con un buon rapporto co-

sto/prestazioni, almeno se la maggior parte degli accessi sono alla memoria locale

del nodo; in secondo luogo, riduce la latenza degli accessi alla memoria locale.

Lo svantaggio principale dell’architettura a memoria distribuitae che la co-

municazione dei dati tra i processori diventa piu complicata e ha una latenza

maggiore, perche i processori non condividono piu una memoria centralizzata.

Tipicamente, oltre alla memoriae distribuito tra i nodi del multiprocessore anche

l’I/O, e i nodi possono in realta contenere un piccolo numero di processori col-

legati con una tecnologia diversa. Per quanto questo gruppo di piu processori in

un nodo, insieme con la memoria e l’interfaccia di rete, possa essere positivo dal

punto di vista del rapporto costo/prestazioni, esso esula dallo scopo di questa tesi

e pertanto non sara ripreso piu avanti. Verranno invece considerate e approfondite

le strutture di multiprocessori a memoria condivisa centralizzata.

16


1.3.2 Coordinamento fra processori paralleli

Nei sistemi multiprocessore i vari microprocessori comunicano attraverso va-

riabili condivise in memoria e tutti i processori in questione sono in grado di ac-

cedere a qualunque locazione di memoria tramite “load” e “store”. Quindi, poiche

un processore che opera in parallelo normalmente condivide dati, esso ha bisogno

di essere coordinato quando utilizza tali dati condivisi; nel peggiore dei casi, in-

fatti, potrebbe accadere che un processore inizi a lavorare su un dato prima che

un altro processore abbia terminato di operare con esso. Questo coordinamen-

to e chiamatosincronizzazione. Quando la condivisione dei datie supportata da

architetture con un singolo spazio di indirizzamento, ovvero sistemi a memoria

condivisa centralizzata, vie un separato meccanismo di sincronizzazione; un ap-

proccio tipico utilizza un lock: solo un processore alla volta puo acquisire il lock,

e gli altri processori interessati a condividere il dato devono aspettare fino a quan-

do il processore originale rilascia il lock sulla variabile. Tale meccanismo sara

ripreso in dettaglio piu avanti nella sezione1.4.2.

1.4 Architetture a memoria condivisa centralizzata

Piu microprocessori possono essere utilmente collegati mediante un bus co-

mune, come rappresentato nell’architettura di Figura1.6, per diverse ragioni:

• ciascun microprocessoree molto piu piccolo rispetto ad un processore mul-

tichip, in questo modo piu processori possono essere posizionati su un sin-

golo bus;

• le cache possono ridurre il traffico sul bus;

• i meccanismi implementati per mantenere le cache e le memorie consistenti

per i multiprocessori semplificano la programmazione.

Questa tipologia di architettura prevede che la cache sia usata sia per dati privati

sia per quelli condivisi. Idati privati sono usati da un solo processore, mentre i

dati condivisisono usati da piu processori, e forniscono, in pratica, un mezzo di

17


comunicazione tra processori attraverso le letture e le scritture. Un dato privato,

una volta inserito nella cache, contribuisce a ridurre il tempo medio di acces-

so, oltre che la banda di memoria richiesta; poiche nessun altro processore usa

quel dato, il comportamento del programmae identico a quello che si ha in un

monoprocessore. Quando vengono inseriti nella cache dei dati condivisi, invece,

il valore condiviso puo essere duplicato in altre cache; oltre a ridurre la latenza di

accesso e la banda di memoria richiesta, questa duplicazione consente di ridurre

i conflitti che esistono per dati condivisi che devono essere letti da piu processi

contemporaneamente. L’inserimento nella cache di dati condivisi crea, pero, un

problema: la coerenza della cache.

1.4.1 Coerenza della cache in un multiprocessore

Cosı come nei sistemi di I/O, anche nei multiprocessori l’introduzione della

cache causa problemi di coerenza: questo perche due processori possono vedere

diversamente la memoria attraverso le proprie cache. Due processori, quindi, pos-

sono avere due valori diversi per la stessa locazione di memoria: questa situazione

rappresenta il cosiddetto problema dellacoerenza della cache.

In modo informale, si potrebbe dire che un sistema di memoriae coerente se

qualsiasi lettura di un dato restituisce il valore del dato scritto piu di recente.

In un programma in esecuzione su piu processori puo essere utile avere copie

degli stessi dati in piu cache. In un sistema multiprocessore che garantisce la

coerenza, le cache forniscono sia lamigrazionesia laduplicazionedelle infor-

mazioni condivise. Le cache coerenti forniscono la migrazione, perche le infor-

mazioni possono essere spostate in una cache locale, da dove vengono usate in

modo trasparente; questo riduce la latenza degli accessi ai dati condivisi che sono

allocati in modo remoto. Le cache coerenti forniscono anche la duplicazione dei

dati condivisi in lettura, perche copiano l’informazione nella cache locale. La du-

plicazione riduce sia la latenza degli accessi sia i conflitti nella lettura di infor-

mazioni condivise. Implementare la migrazione e la duplicazionee fondamentale

per garantire buone prestazioni negli accessi a informazioni condivise, in quanto

le performance di un multiprocessore dipendono dalla capacita del sistema di con-

18


dividere i dati; per questo motivo, invece di cercare di risolvere il problema evi-

tandolo con il software, i multiprocessori in piccola scala adottano una soluzione

hardware, introducendo un protocollo per garantire la coerenza della cache.

Un protocollo per mantenere la coerenza in processori multiplie chiamato

protocollo di coerenza della cache: il protocollo e basato sul tenere traccia dello

stato di tutti i blocchi condivisi. Il protocollo piu utilizzato per mantenere tale coe-

renzae chiamatosnooping, letteralmente spione: ogni cache che ha una copia dei

dati prelevati da un blocco della memoria fisica ha anche uno stato della condivi-

sione del blocco; lo stato quindi non viene conservato in modo centralizzato. Le

Figura 1.8: Multiprocessore a bus singolo che utilizza il protocollo di snooping per gestire

la coerenza della cache.

cache sono collegate a un bus di memoria condiviso, e, come si vede in figura1.8,

tutti i controllori delle cache tengono sotto controllo (spiano) il bus, per capire se

possiedono o meno una copia del blocco che viene richiesto sul bus. I protocolli di

snooping si sono diffusi con i multiprocessori che usano microprocessori e cache

collegati a un’unica memoria condivisa, perche possono usare un collegamento

fisico preesistente, cioe quello tra il bus e la memoria, per verificare lo stato della

cache.

Il mantenimento della coerenzae formato da due componenti: la lettura e la scrit-

tura. Mentre non vie alcun problema nella lettura di copie multiple,e invece nec-

essario che un processore abbia l’accesso esclusivo per la scrittura di una parola.

19


Inoltre i processori devono sempre disporre della copia piu recente quando leg-

gono un oggetto, quindi tutti i processori devono ottenere il nuovo valore degli

oggetti dopo una scrittura. Per questo il protocollo di snooping deve localizzare

tutte le cache che condividono un oggetto da scrivere. La conseguenza della scrit-

tura di un dato condivisoe l’invalidazione di tutte le altre copie presenti oppure

l’aggiornamento delle copie condivise al valore scritto.

Ci sono quindi due modi per conservare i requisiti di coerenza descritti:

• protocollo di invalidazione su scrittura(write-invalidate): tale protocollo

garantisce che un processore abbia accesso esclusivo ad un’informazione

prima di scriverla in quanto esso rende non valide le altre copie di un dato in

seguito ad una scrittura. Questoe il protocollo piu diffuso perche l’accesso

in esclusiva assicura che non esistano altre copie ne in lettura ne in scrittura

al momento della scrittura: tutte le altre copie dell’informazione, contenute

nelle cache, sono invalidate. Questo schema garantisce la coerenza: infatti,

se si considera una scrittura seguita da una lettura su un altro processore,

poiche la scrittura richiede un accesso esclusivo, qualsiasi copia esistente

nel processore che deve leggere deve essere resa non valida, e quindi, quan-

do avviene la lettura, si avra una miss nella cache e si dovra caricare una

nuova copia del dato. Per le scritture, invece, si richiede che il processore

che vuole scrivere abbia accesso esclusivo, e quindi si impedisce agli altri

processori di scrivere simultaneamente.

• protocollo di aggiornamento su scrittura(write-update): tale protocollo, in

alternativa al precedente, garantisce l’aggiornamento in tutte le cache delle

copie di un dato quando questo viene scritto. Per limitare la banda richie-

sta da questo protocolloe utile tenere traccia di quali dati in cache sono

condivisi, cioe sono presenti anche in altre cache, perche se un dato non

e condiviso, none necessario eseguire un broadcast o aggiornare le altre

cache.

20


1.4.2 Sincronizzazione

I meccanismi di sincronizzazione di solito vengono implementati con funzioni

software a livello di utente che utilizzano istruzioni di sincronizzazione suppor-

tate dall’hardware. Nei sistemi piu piccoli o in situazioni con pochi conflitti, la

funzionalita essenziale che deve essere garantita in hardwaree il supporto di

istruzioni non interrompibili o di sequenze di istruzioni capaci di prelevare e modi-

ficare un valore in modo atomico. I meccanismi di sincronizzazione software sono

progettati di conseguenza sulla base di queste capacita.

Una delle principali richieste che un multiprocessore a memoria centralizza-

ta deve soddisfaree quella di essere in grado coordinare i processi di uno stesso

programma eseguiti in parallelo sui diversi processori. Tipicamente un program-

matore utilizza dellevariabili di lock, conosciute anche comesemafori, per coor-

dinare o sincronizzare i processi. L’obiettivo che un progettista di multiprocessori

deve raggiungere consiste nel fornire un meccanismo in grado di decidere quale

processore ottiene il lock e nel fornire le operazioni per bloccare una variabile.

L’arbitraggio e semplice per i multiprocessori a memoria centralizzata in quan-

to il bus e l’unico percorso verso la memoria: il processore che ottiene il bus

blocca l’accesso alla memoria a tutti gli altri processori. Per implementare la sin-

cronizzazione in un multiprocessoree indispensabile la presenza di una serie di

primitive hardware per leggere e modificare una locazione di memoria in modo

atomico; un’operazione tipica usata per costruire le funzioni di coordinamentoe

lo scambio atomico (atomic swap), che scambia un valore in un registro con uno in

memoria. Se sia il processore che il bus forniscono questa operazione di scambio

atomico, i programmatori possono creare dei lock nel vero senso della parola, in

quanto qui atomico significa indivisibile e scambio atomico sta ad indicare che il

processore puo leggere la locazione di memoria e inserirla nel valore bloccato nel-

la medesima operazione sul bus, impedendo ad ogni altro processore o dispositivo

di I/O di leggere o scrivere la memoria finche tale scambio none completato.

In Figura1.9 si puo osservare una tipica procedura per bloccare una variabi-

le usando l’istruzione di scambio atomico. Si assuma che 0 significhi sbloccata

(“go”) e 1 significhi bloccata (“stop”). Un processore legge il lock per determi-

21


Figura 1.9: Step necessari ad acquisire un lock (per sincronizzare i processi) e rilasciarlo

al termine della sezione chiave del codice.

narne lo stato e continua a testare finche tale variabile non si sblocca. Successi-

vamente tale processore concorre con gli altri processori in attesa (spin waiting,

ovvero attesa continuando a ciclare) per vedere chi per primo riesce ad aggiudi-

carsi la variabile. Tutti i processori utilizzano un’istruzione di scambio atomico:

leggono il vecchio valore e memorizzano un 1 (“stop”) nella variabile. L’unico

vincitore vedra lo 0 (“go”), mentre i perdenti vedranno l’1 inviato a suo tempo dal

vincitore. Il processore vincente puo quindi eseguire il codice che aggiorna il dato

condiviso. Al termine della propria esecuzione, il processore esce e immagazzina

uno 0 (“go”) nel lock: in questo modo la gara puo ricominciare.

In conclusionee da notare come sia possibile utilizzare meccanismi di coe-

22


renza di un multiprocessore per implementarelock di ciclo (spin lock), ovvero

lock che un processore cerca di acquisire continuando ad eseguire una sequenza

all’interno di un ciclo. Un vantaggio di questo algoritmoe che esso permette ai

processori di attendere ciclando su una copia locale del lock presente nelle loro

cache: questo permette di ridurre la quantita di traffico sul bus.

1.5 Sincronizzazione Hardware

Tutti i moderni computer possono svolgere diverse operazioni allo stesso tem-

po. Mentre esegue un programma, un computer puo anche leggere da un disco e

stampare del testo su un monitor o una stampante. In un sistemamultiprogram-

ming, la CPU puo anche “smistare” da un programma all’altro, eseguendo ciascu-

no di essi per solo una decina o centinaia di millisecondi. Mentre, rigorosamente

parlando, ad ogni istante di tempo, la CPU esegue solo un programma, nel corso

di 1 secondo, essa potrebbe effettivamente lavorare su diversi programmi, dando

cosı all’utente l’impressione del parallelismo. Alle volte, in questo contesto, si

parla dipseudoparallelism, paragonandolo al verohardware parallelismdei si-

stemi multiprocessore (aventi due o piu CPUs che condividono la stessa memoria

fisica) [18].

In riferimento soprattutto ai moderni sistemi operativi,e quanto mai fondamentale

garantire lamutua esclusionefra processi in esecuzione sulla medesima CPU e,

perche no, anche su diverse CPU. Molto frequentemente si parla della necessita

di evitare lecorse critiche; con questa frase si intende il voler sottrarsi a quelle

situazioni in cui, ad esempio, due o piu processi leggono e scrivono contempo-

raneamente su dei dati da loro condivisi e il cui risultato finale dipende da chi

effettivamente sia tra loro in esecuzione prima o dopo. In altre parole cio che

risulta necessarioe garantire la mutua esclusione, ovvero garantire che se un pro-

cesso sta utilizzando una variabile condivisa, o un file, gli altri processi saranno

effettivamente impossibilitati nel fare la medesima operazione.E dunque compi-

to del sistema operativo garantire l’acceso concorrente da parte di piu processi a

risorse condivise.

23


Esistono essenzialmente due approcci, applicati nell’ambito dei sistemi operativi,

per ottenere la mutua esclusione:

• Busy Waiting: come si evince dal nome attribuitogli, questo approccio, pur

se efficace, determina uno spreco della CPU; un processo infatti, riscon-

trando l’impossibilita di effettuare le proprie operazioni su una risorsa gia

occupata, rimane in un loop di attesa mantenendo occupata la CPU fino al

momento in cui non glie permesso di svolgere l’operazione sulla risorsa

richiesta. Inoltre questa inefficienza potrebbe portare ad un ulteriore proble-

ma chiamatoil problema della inversione di priorita (si rimanda a [18] per

approfondimenti sull’argomento).

• Sleep and Wakeup: con questo approccio il processo “escluso” viene sem-

plicemente bloccato (sleep), evitando quindi spreco di CPU, e, successiva-

mente, risvegliato (wakeup) nel momento in cui la risorsa da questo richie-

sta risulta effettivamente libera.

L’approccio utilizzato in questo lavoro di tesi, come sara ben chiaro nei capi-

toli successivi,e quello piu efficiente, ovvero Sleep and Wakeup; in particolare

e stato sfruttato il meccanismo degli interrupt per il risveglio dei processi in ese-

cuzione su due CPU distinte. Si rimanda ai capitoli1 e2, dedicati alla Descrizione

della Metodologia e alla Implementazione, per approfondimenti al riguardo.

Infine e opportuno sottolineare come le premesse sopra enunciate avvalorino ef-

ficacemente il fatto che il presente lavoro di tesi, ovvero realizzare un motore

di gestione della concorrenza hardware tramite un sistema digitale, ha come fine

ultimo quello di sostituire parte delle funzionalita svolte dal sistema operativo.

24

Capitolo 2

Descrizione della Metodologia

Questo lavoro di tesi si propone di fornire una metodologia per la definizione

ed implementazione di un IP core,intellectual property core, che realizzi le fun-

zionalita di un motore di gestione della concorrenza hardware. La metodologia

proposta inoltre sara sviluppata con l’ausilio del tool di sviluppo per FPGAs di

proprieta della Xilinx, Embedded Development Kit, EDK. Il tipo di IP core che si

vuole realizzaree tale per cui questo possa essere inserito all’interno di un sistema

multiprocessore basati su dispositivi programmabili della famiglia Virtex-II Pro di

Xilinx.

2.1 Condivisione delle Risorse

Nei moderni calcolatorie compito del sistema operativo garantire l’accesso

concorrente da parte di piu processi, in esecuzione su diversi processori, a risorse

condivise [18]. Comee stato sottolineato nel capitolo precedente, esistono diverse

modalita con cuie possibile garantire la mutua esclusione tra processi; trasferire

queste complesse e fondamentali funzionalita da un livello puramente software ad

un livello hardware richiede non poche conoscenze e soprattutto un lavoro piut-

tosto complesso nella gestione dei vari processi concorrenti.

In particolare la soluzione al problema richiede una profonda astrazione fra lo

strato software, il modello del programma, e l’hardware, l’implementazione fisica

25

CAPITOLO 2. DESCRIZIONE DELLA METODOLOGIA

del sistema [22], [25]. In questo lavoro di tesi viene proposta una traccia con la

qualee possibile, tramite una opportuna implementazione del sistema, raggiun-

gere l’obiettivo di sintetizzare un sistema dedicato multiprocessore in cui sia pre-

sente un IP, la Semaphore Engine, che garantisca l’accesso concorrente ad una o

piu risorse, come puo essere una memoria, Figura2.1. In questa particolare con-

Figura 2.1: Esempio di configurazione hardware in cuie presente la Semaphore Engine.

figurazione, i processori condividono un certo spazio di memoria, ma non neces-

sariamente tutta. Come si vede in Figura2.2, tutti i processori possono accedere

alla Memoria Condivisa, ma sono anche presenti spazi di memoria in cui l’ac-

cessoe riservato al singolo processore a cui questi si riferiscono. Solitamente la

politica di gestione degli spazi di indirizzamento in cui la memoriae partiziona-

ta, che in particolare ha come obiettivo quello impedire ad un certo processore X

di accedere alla memoria privata di un altro processore Y, viene realizzata e im-

plementata a livello software, si veda il capitolo3, relativo alla Implementazione

della Metodologia, per approfondimenti al riguardo.

26


Figura 2.2: Memoria Condivisa a cui accedono i processori.

2.1.1 Garantire la Mutua Esclusione

Garantire l’accesso concorrente ad una memoria significa garantire la mutua

esclusione tra i processi e quindi tra i processori che la condividono;e qui suppo-

sto infatti il caso piu semplice, ovvero quello in cui su ogni processore sia attivo

un solo processo concorrente. In altre parole l’obiettivoe quello di garantire l’ato-

micita delle istruzioni di scrittura o lettura sulla memoria condivisa; tale obiettivo

e dunque raggiunto integrando nel sistema multiprocessore un “motore” di sin-

cronizzazione hardware.

Per garantire un accesso atomico alla memoria condivisa, tutti i processi devono

seguire alcune semplici regole prima di accedervi, qui viste in maniera semplifi-

cata:

1. Scrivere all’interno dello spazio di indirizzamento relativo alla propria me-

moria privata un messaggio, per brevita chiamato INFO. In riferimento al-

la specifica dell’interfaccia OCP, [4], e in particolare alla sua estensione

27


riguardante l’esecuzione di processi concorrenti, il messaggio INFO con-

tiene:

• un identificativo, ConnID, del processore che esegue la richiesta;

• un ulteriore identificativo, ThreadID, del processo che richiede l’uti-

lizzo della risorsa;

• il tipo di operazione che richiede di effettuare, scrittura (WR) o lettura

(RD);

• lo spazio di indirizzamento, quindi la quantita, della memoria condi-

visa di cui effettivamente necessita.

2. Richiedere la disponibilita della risorsa alla Semaphore Engine, segnalando

l’indirizzo della memoria privata in cui sono contenuti i dettagli, INFO,

dell’operazione da effettuare;

3. Porsi in attesa, in modo simile all’approccio Sleep and Wakeup utilizzato

nei sistemi operativi, di cui sie gia parlato nel Capitolo 1, di un segnale di

Interrupt proveniente dalla Semaphore Engine che risvegli il processo nel

caso in cui la risorsa risulti effettivamente libera.

La Semaphore Engine infatti, ricevuta la richiesta, legge l’INFO all’indiriz-

zo indicato tramite il meccanismo del DMA, accesso diretto alla memoria,

e, in caso positivo, provvede a concedere il lock sulla risorsa, notificandolo

tramite un segnale di Interrupt che risvegliera il processo in attesa;

4. Verificare la consistenza dei valori ThreadID e ConnID contenuti nei registri

della Semaphore Engine, ed eventualmente effettuare l’operazione prece-

dentemente richiesta sulla risorsa;

5. Terminata l’operazione segnalare alla Semaphore Engine che la risorsae

libera, UNLOCK della risorsa.

Quindi la Semaphore Engine risveglia, se presente, un altro processo in

attesa.

28


La sintesi di ogni singolo passo comporta uno specifico lavoro di integrazione

del medesimo nell’ambiente di sviluppo utilizzato, EDK. In particolare, lasciando

al capitolo successivo il compito di una spiegazione piu dettagliata per quanto

riguarda l’effettiva implementazione, verranno presentati nei prossimi paragrafi i

due temi principali che hanno reso possibile l’implementazione della metodologia

proposta: la gestione degli Interrupt e i Device Driver.

2.2 Interrupt

Meccanismo fondamentale per la gestione della concorrenza in una architet-

tura multiprocessoree quello degli interrupt; tale meccanismo, particolarmente

complesso, consente il risveglio dei processi in attesa di poter usufruire di una de-

terminata risorsa solo nel preciso istante in cui questa effettivamente si libera, in-

terrompendo qualsiasi processo in esecuzione in quel momento sulla CPU avente

priorita piu bassa. Qui di seguito si fornisce una definizione formale di interrupt e

una breve e semplificata descrizione di come questo meccanismo operi realmente.

Si chiama interrupt quel meccanismo hardware/software utilizzato nei sistemi pro-

grammabili, ad esempio nei computer, nei microprocessori, o altro, che consente

di modificare il flusso normale di esecuzione delle operazioni svolte dall’unita

centrale, la CPU, in seguito al verificarsi di un evento. Molte periferiche utiliz-

zano questo meccanismo per chiedere l’impiego della CPU; in particolare, quan-

do il processore si accorge del verificarsi di un particolare evento E, esso esegue il

salto all’esecuzione della funzione associata a tale evento, [17], [12]. Gli interrupt

sono veri e propri cambiamenti nel flusso di controllo che non vengono causati dal

programma, ma da qualche evento chee solitamente collegato all’I/O; l’interrupt

interrompe il programma in atto e trasferisce il controllo ad un gestore di interrupt

(come sara approfondito nel capitolo successivo, tale componente fa parte della

libreria standard di EDK e prende il nome di Interrupt Controller) che eseguira le

azioni appropriate. Una volta terminata, secondo una politica di priorita prestabili-

ta, la gestione di un singolo o molteplici interrupt sopraggiunti, il controllo viene

ritornato al programma interrotto. Il processo interrotto deve ricominciare nello

29


stesso stato in cui si trovava quando sie verificato l’interrupt, il che significa che

tutti i registri interni vanno riportati allo stato in cui erano prima dell’interrupt.

Ecco i vari passi, [17]:

Azioni hardware (in forma semplificata)

1. Il controllore del dispositivo attiva il segnale di interrupt sul bus di sistema

per avviare la sequenza di interrupt.

2. Non appena la CPUe pronta a gestire l’interrupt, invia un segnale di ri-

conoscimento dell’interrupt sul bus.

3. Quando il controllore del dispositivo vede che il suo segnale di interrupte

stato riconosciuto, mette un piccolo numero intero sul bus per identificar-

si. Questo numero si chiama vettore dell’interrupt e associa univocamente

l’evento che ha causato l’interrupt.

4. La CPU legge il vettore dell’interrupt dal bus e lo memorizza temporanea-

mente.

5. Poi la CPU mette il program counter e la PSW (Program Status Word) sulla

stack.

6. La CPU calcola il nuovo valore del program counter usando il vettore del-

l’interrupt come indice in una tabella che si trova all’inizio della memo-

ria. Questo nuovo program counter punta all’inizio della routine di gestione

dell’interrupt per il dispositivo che ha causato l’interrupt.

2.3 Device Driver

Un passo necessario ed importante per integrare correttamente un IP core nella

libreria standard di EDKe quello di implementare ildevice driverspecifico per il

core in questione. Soprattutto per la corretta gestione degli interrupt, alla luce del

fatto che la Semaphore Enginee pensata in modo da dover essere in grado di sol-

levare segnali di interrupt, il Device Driver acquista un ruolo fondamentale nella

30


realizzazione del sistema: in particolare grazie a questo accorgimento (si rimanda

al capitolo successivo per un approfondito studio ed analisi del caso) i segnali di

interrupt sollevati dalla Semaphore Engine potranno essere gestiti correttamente

ed in modo efficace a livello applicativo da unaISR, Interrupt Service Routine

(fare riferimento a [2] per approfondimenti al riguardo). Inoltre, gli IP core im-

portati in EDK e aggiunti alla libreria dei componenti standard (riferirsi a [14] per

analizzare i dettagli che consentano l’inserimento corretto di un IP core in EDK)

non sono gestibili dal punto di vista software se prima non viene creato il relativo

Device Driver. Questo perche la descrizione hardware in VHDL dell’IP core non

e sufficiente per poter interfacciare il componente con l’applicazione che lo uti-

lizza; occorre pertanto creare un driver specifico per quell’IP core che implementi

le funzioni necessarie al programma chiamante per gestire il componente dal la-

to software. Un Device Driver, quindi, none altro che il punto di collegamento

Figura 2.3: Il Driver come interfaccia tra hardware e software.

fra il software (quindi l’applicazione utente) ovvero il file.C dell’architettura di

riferimento, e l’hardware (dispositivo di I/O), ovvero l’IP core in questione, Figu-

ra 2.3. In altre parole un Device Drivere parte di un meccanismo di astrazione,

caratterizzato da:

31


• uno strato software ad alto livello in grado di supportare applicazioni utente

capaci di accedere alla funzionalita di I/O in modo indipendente dall’hard-

ware;

• uno strato software a piu basso livello, il Device Driver stesso, progettato

per incapsulare tutte le operazioni strettamente correlate all’hardware, ed in

grado di comunicare con lo strato superiore tramite un’interfaccia standard.

2.3.1 Architettura dei Device Driver

L’architettura dei device driver puo essere rappresentata mediante una strut-

tura a strati, come mostrato in Figura2.4. Questo tipo di architettura incontra tutti i

Figura 2.4: Strati dell’architettura dei Device Driver.

casi d’uso dei device driver, garantendo la portabilita su diversi processori, sistemi

operativi e tool di sviluppo, [24]. L’architettura stratificata fornisce integrazione

con:

• Real Time Operating System, RTOS (livello 2);

• Device driver di alto livello portabili su SO e processori (livello 1);

• Device driver di basso livello per semplici casi d’uso (livello 0).

Nel seguito verranno descritti brevemente i 3 livelli, per ulteriori approfondimenti

si rimanda a [24].

32


• Livello 0: low level driverI device driver di basso livello presenti in questo strato sono implementati

come macro e funzioni, e permettono allo sviluppatore di creare un picco-

lo sistema, “mappabile” nella memoria interna di un FPGA. Secondo una

specifica convenzione utilizzata da Xilinx nelle librerie proprietarie, si veda

il capitolo3 per ulteriori chiarimenti in merito, le funzioni “sviluppate” per

i driver di livello 0 si trovano nel filenomeIp_l.c , con nomeIp si indica

un generico IP, i relativi header si trovano invece nel filenomeIp_l.h ;

il suffisso ‘‘_l’’ sta proprio ad indicare che il drivere di basso livello.

Ovviamente le funzioni messe a disposizione dai Device Driver devono es-

sere importate, come delle vere e proprie librerie, per poter essere utilizzate

all’interno dell’applicazione.

• Livello 1: high level driverI device driver di alto livello presenti in questo strato sono implementati

come macro e funzioni, e sono sintetizzati per permettere allo sviluppatore

di utilizzare tutte le caratteristiche della board a disposizione (nel caso in

esame la scheda di Xilinx, Avnet Virtex II Pro Evaluation Board). In par-

ticolare questi driver sono indipendenti dal SO e dal processore, il che li

rende altamente portabili. Le funzioni implementate per il driver di livello

1 si trovano nel filenomeIp.c , i rispettivi prototipi nel filenomeIp.h .

• Livello 2: RTOS adaptationQuesto livelloe caratterizzato da adattatori per i device driver; tali dispositi-

vi permettono di convertire un’interfaccia driver di livello 1 in un’interfaccia

che soddisfi le richieste degli schemi di un device driver per RTOS. Per ogni

RTOSe necessario un unico adattatore: cio comporta la perdita di portabilita

dei driver di questo livello. Le funzioni implementate per il driver di livello

2 si trovano nel filenomeIp_adapter.c , i rispettivi prototipi nel file

nomeIp_adapter.h . Questi due file, al contrario degli altri device driver

descritti, sono tipicamente collocati in un’altra cartella, specifica per RTOS.

33


Per degli esempi esplicativi e chiarificatori sull’argomento appena affrontatoe

possibile consultare la libreria dei Device Driver fornita da Xilinx presente in

EDK.

2.3.2 Scelta del livello di interfaccia

Mentre fino alla versione 6.1 di EDK era a discrezione dello sviluppatore scegliere

il livello di interfaccia da utilizzare, nella versione 6.2, l’ultima rilasciata da Xil-

inx al momento della stesura di questa tesi, tale scelta non risulta piu possibile; in

particolare i tre livelli sono stati accorpati in un unico livello piu esterno, [1].

Nella fase di sintesi di un IP core, questo comporta per il progettista la neces-

sita di prestare particolare attenzione nella definizione dei Driver, argomento af-

frontato nel Capitolo3; in caso contrario infatti, il componente stesso risulterebbe

inutilizzabile nella maggior parte delle sue funzionalita implementate.

34

Capitolo 3

Implementazione della Metodologia

Per raggiungere lo scopo finale di questo lavoro di tesi, ovvero implementare

un meccanismo che gestisca la concorrenza fra piu processori tramite semafori, si

e lavorato procedendo per piccoli passi:

• inizialmentee stato implementato un semplice IP core, in grado solo di

sommare due numeri, con lo scopo di comprendere le modalita di comuni-

cazione fra i processori e il componente stesso; tale comunicazione avviene

su un bus di tipo OPB;

• successivamentee stato indispensabile capire come il tool utilizzato permet-

tesse la gestione degli interrupt: questo perche il meccanismo di gestione

della concorrenza implementato tramite semafori dispone di unaporta di

interrupt in uscita tramite la quale solleva un segnale quando un particolare

processore puo utilizzare la risorsa condivisa;

• nel momento in cui un IP core deve essere effettivamente impiegato all’in-

terno dell’architettura nella qualee stato inserito,e necessario disporre del

relativo device driver affinche le funzioni richiamate da un processore sul

componente abbiano effetto: un altro passo seguitoe stato percio quello di

comprendere la struttura dei device driver e il metodo con cui essi possano

essere creati per un IP core dedicato;

35

CAPITOLO 3. IMPLEMENTAZIONE DELLA METODOLOGIA

• a questo punto un altro passo fondamentalee quello relativo alla scrittura e

alla gestione di una memoria; ogni processore, infatti, deve poter richiedere

l’utilizzo della risorsa condivisa e questo avviene scrivendo una sequen-

za di dati su una memoria: tale memoria viene poi letta dal meccanismo

che gestisce la concorrenza il quale elabora i dati in modo da soddisfare la

richiesta pervenuta.

3.1 Introduzione ai tools utilizzati

La parte implementativa di questo lavoro di tesie stata sviluppata utilizzando

principalmente due pacchetti di sviluppo:

• Embedded Developement Kit, EDK;

• ModelSim XE II.

Attualmente le versioni di tali strumenti sono la 6.2i per EDK e la 5.7c per Mo-

delsim.

Dell’ambiente di EDKe stato utilizzato il tool Xilinx Platform Studio, XPS: tale

strumento permette lo sviluppo ad alto livello dei sistemi embedded. Per quanto

riguarda la scrittura dei codici in VHDLe stato impiegato un comune editor di

testo, mentre per la validazione del codice stesso e per la verifica dei segnali in u-

scita da ogni IP coree stato utilizzato Modelsim, un valido strumento che permette

di simulare il comportamento di un componente, del qualee fornita la specifica in

VHDL, quando gli ingressi sono forzati ad un determinato valore.

3.1.1 Xilinx Platform Studio

Il tool Xilinx Platform Studio ha come obiettivo primario quello di fornire

al progettista hw/sw un supporto per costruire un “embedded processor system”;

questoe permesso da un ricco set di tools per il design e da un’ampia gamma di IP

core standard a cui attingere. Ne consegue che tale pacchetto di sviluppo fornisce

un modo semplice di progettare un sistema basato su blocchi logici, interconnessi

tra loro in base alle particolari esigenze dell’applicazione.

36


Un progetto Xilinx Platform Studio puo essere aperto tramite il file.XMP,

solitamente chiamatoSystem.xmp, presente nella directory principale del sistema

stesso che si vuole realizzare (per ulteriori informazioni si rimanda a [3]). Al-

l’apertura del progetto desiderato, la schermata standard che si presenta all’utente

e quella rappresentata in Figura3.1. Nel frameA e automaticamente selezionato

Figura 3.1: Schermata principale di Xilinx Platform Studio.

il segnalibro System, che fornisce la lista dei vari componenti hardware presen-

ti nell’architettura e una serie di file di sistema. Tali file rappresentano le varie

componenti del sistema, in particolare sono ora di interesse due di essi:

• il file System.pbdpermette di visualizzare graficamente, nel frameB, la

struttura completa del sistema, come si osserva da Figura3.2;

• il file System.mhspermette sempre di visualizzare la struttura completa del

sistema, ma questa volta in versione testuale, come si osserva da Figura3.3.

Selezionando il segnalibro Applications nel frameA viene fornito l’elenco

delle componenti software del sistema, ovvero i file .C eseguiti dai processori e i

37


Figura 3.2: Visione grafica dell’architettura.

Figura 3.3: Visione testuale dell’architettura.

file .H che essi includono. Il segnalibro Options permette di scegliere varie opzioni

generali relative al sistema, mentre il segnalibro Components offre una lista di tutti

38


gli IP core standard che possono essere aggiunti al sistema.

Figura 3.4: Finestra Object Properties di un IP core.

Figura 3.5: Finestra Software Platform Settings.

In Figura3.4si osserva la finestraObject Propertiesdel componente opbuart-

lite, ovvero l’IP core che fornisce la comunicazione seriale. Tale finestrae speci-

fica per ogni componente contenuto nel sistema e si ottiene selezionando il com-

39


ponente in questione dal file System.pbd; essa permette di selezionare il nome e

la versione del componente, lo spazio di indirizzamento, i parametri, le net alle

quali sono collegate le porte dell’IP core considerato e le informazioni relative

agli interrupt che il componente gestisce.

La finestraAdd/Edit Hardware Platform Specifications, raggiungibile dal menu

dei comandi seguendo il percorso Project⇒ Add/Edit Cores, permette di avere

un quadro riassuntivo delle principali proprieta degli elementi che compongono

l’architettura.

La Figura 3.5 mostra la finestraSoftware Platform Settingsche si ottiene

selezionando un componente qualsiasi del sistema dall’elenco proposto nel se-

gnalibro System del frame di sinistra del tool. Tale finestra riassume tutte le im-

postazioni relative ai driver scelti per i componenti, alle librerie incluse, alle fun-

zioni di interrupt handler e ai parametri dei processori.

Nella parte superiore della schermata, il tool Xilinx Platform Studio offre di-

verse toolbars, utili per le operazioni piu comuni. Di particolare interesse risultano

i pulsanti mostrati in Figura3.6. I primi due servono, rispettivamente, a generare

Figura 3.6: Toolbar.

le librerie di sistema (ad esempio la compilazione dei driver dei componenti) e ad

effettuare la compilazione della parte software del sistema. Il terzo ed il quarto

pulsante permettono di generare la netlist, cioe la struttura delle interconnessioni

che formano l’architettura, e di creare il bitstream, chee il file contenente tutte

le informazioni per la configurazione della FPGA. Gli ultimi due pulsanti infine,

permettono di inizializzare la BRAM del sistema e di scaricare il bitstream di

configurazione sulla FPGA.

40


3.1.2 ModelSim

Il tool Modelsim ha come obiettivo primario quello di fornire al progettista

hw/sw un supporto per la simulazione del comportamento di un componente, del

qualee fornita la specifica in VHDL oppure in Verilog. La schermata principale

che si ottiene all’apertura del programmae mostrata in Figura3.7: nella sezione di

sinistra sono visualizzati i file appartenenti al progetto da simulare, mentre nella

parte destra si trova la shell dei comandi.

Figura 3.7: Schermata principale di Modelsim.

Le finestre piu significative di questo ambiente di sviluppo sono due, denomi-

nate Signals e Wave, e sono mostrate in Figura3.8e Figura3.9rispettivamente.

La prima finestra visualizza i segnali in ingresso ed uscita dal componente se-

lezionato, nonche i segnali interni; per ogni segnalee indicato il relativo valore,

il quale puo essere forzato dal progettista. La seconda finestra mostra invece l’an-

damento nel tempo dei segnali selezionati in conseguenza della variazione degli

ingressi, e il relativo valore per ogni istante temporale.

3.2 Architettura multiprocessore di riferimento

L’architettura multiprocessore mostrata in Figura3.10rappresenta il punto di

partenza di questo lavoro di tesi. Ad essa infatti si andranno ad aggiungere tutti

i componenti necessari affinche il meccanismo di gestione della concorrenza im-

41


Figura 3.8: Segnali del componente selezionato.

Figura 3.9: Andamento dei segnali del componente nel tempo.

plementato mediante semafori possa eseguire correttamente la propria funzione.

Tale architettura basee composta da:

• 2 Microblaze (indicati con la lettera A)

• 1 opbgpio (indicato con la lettera B)

• 1 opbuartlite (indicato con la lettera C)

• 3 bramblock (indicati con la lettera D)

• 4 lmb bram if cntlr (indicati con la lettera E)

42


Figura 3.10: System.pbd dell’architettura di riferimento.

• 1 opbbram if cntlr (indicato con la lettera F)

• 1 dcmmodule (indicato con la lettera G)

In particolare, ognuno dei due Microblaze dispone di una propria memoria

BRAM, alla qualee connesso mediante due lmbbram if cntlr, come mostrato

in dettaglio in Figura3.11. I due moduli LMB sono dei particolari bus che con-

sentono di connettere rispettivamente le porte di istruzioni e dati del Microblaze

adhigh speed peripherals, come ad esempio una memoria BRAM.

Dire che ogni processore dispone di una propria memoria puo pero far pensare ad

una contraddizione, in quanto sie supposto che l’architettura cui si fa riferimento

in questo lavoro di tesi sia di tipo a memoria centralizzata. Tale ambiguita viene

risolta con una semplificazione: la memoria condivisa riguarda soltanto la parte

dati, per la parte del codice vie invece un’area di memoria dedicata per ogni pro-

cessore.

I componenti opbgpio, opbuartlite e opbbram if cntlr hanno in comune il fatto

di essere collegati ai due processori mediante un bus di tipo OPB; a sua volta il

componente opbbram if cntlr e collegato ad una bramblock, ovvero la memo-

43


Figura 3.11: Microblaze con relativa memoria.

ria condivisa fra i due processori che il meccanismo di gestione della concorren-

za dovra gestire. Pertanto l’architettura mostrata in Figura3.10, che rappresenta

il file System.pbd del sistema, puo essere schematizzata in modo piu semplice,

come mostra la Figura3.12.

Il modulo aggiuntivo denominato DCM, Digital Clock Manager, serve a con-

trollare la frequenza di Clock del sistema; in particolare, tramite il settaggio di

opportuni parametri, esso permette di regolare la frequenza in ingresso al sistema

in modo tale che essa non superi la frequenza critica di soglia, oltre la quale la

logica del sistema non garantisce piu un corretto funzionamento.

3.3 Implementazione di un IP core in VHDL

Tramite la codifica in linguaggio di descrizione dello hardware, un IP core puo

essere creato fisicamente, in quanto vengono fissati tutti gli ingressi e le uscite del

blocco e vengono definite le funzioni che l’IP core stesso deve implementare.

Seguendo la metodologia di lavoro descritta in precedenza, tralasciando pero la

traduzione in linguaggio di descrizione dello hardware delle funzionalita che il

44


Figura 3.12: Rappresentazione sintetica dell’architettura di partenza.

meccanismo di gestione della concorrenza dovra effettivamente implementare, si

focalizza ora l’attenzione sulla codifica di un semplicissimo IP core, che fungera

poi da contenitore per le operazioni del meccanismo da implementare. In questo

modoe possibile chiarire tutti gli aspetti che riguardano i segnali in ingresso e in

uscita da un IP core collegato su un bus di tipo OPB, e le componenti di base che

costituiscono tale elemento.

Nel seguito si fara riferimento ad un IP core chiamato ADDER. Tale compo-

nente, nel momento in cui riceve tre serie di dati (due numeri e un comando di

somma), restituisce la somma dei due valori e solleva un segnale di interrupt per

avvertire il processore che l’operazione sie conclusa. Essoe composto da due

macro blocchi, come si vede in Figura3.13:

• adder core - nucleo effettivo del componente, esso contiene l’implemen-

tazione delle funzioni di base;

45


Figura 3.13: Componenti dell’adder.

• P select- componente aggiuntivo, il suo compitoe quello di “selezionare

la periferica” (peripheral select), ovvero abilitare l’IP core e renderlo attivo;

in particolare esso alza il segnale CS, per fornire al componente una sorta di

“enable” grazie al quale esso risulta sensibile ad eventuali dati provenienti

dal bus o viceversa; la sua interfacciae rappresentata in Figura3.14.

Figura 3.14: Interfaccia di Pselect.

Nel codice VHDL del componenteadder, si vede che i cicli di scrittura o di

lettura sono abilitati solo nel caso in cui CS risulta attivo (Figura3.15, notare che

CS⇒ chip select):

46


Figura 3.15: Ciclo di scrittura o di lettura abilitati da CS.

Il segnale CS viene attivato nel momento in cui lo spazio di indirizzamento

del bus utilizzato coincide con lo spazio di indirizzamento assegnato all’IP core.

Per quanto concerne il segnale di interrupt, esso viene portato a livello logico

alto nel momento in cui l’applicazione chiede di effettuare la somma dei valori

contenuti in register0 e register1 mediante l’invocazione della funzione di scrit-

tura di un registro contenuta nel driveradder l.h; tale segnale in seguito viene

resettato nella funzione diint handler, sempre tramite la funzione di scrittura di

un registro, che in questo casoe quello di stato degli interrupt. Per una migliore

comprensione si riportano i due processi, di lettura e scrittura dei registri, in Figura

3.16. In tale Figura si nota il mapping dei registri nella memoria: l’offset assegnato

ad ogni registroe di 4 bit.

Un processore puo scegliere fra due tipologie di richiesta nei confronti di un

IP core quale l’adder:

• richiesta di lettura - process readregister dell’adder in esecuzione: il pro-

cessore invia all’adder solamente un address (che rappresenta l’effettiva lo-

cazione in memoria del registro a cui vuol far riferimento, questo particolare

meccanismoe noto anche comeMemory Map), i cui ultimi 8 bit indicano

quale informazione il processore vuole conoscere; tale informazione viene

memorizzata nel registro interno all’adder denominatoreg data chee as-

sociato al segnaleReadData in uscita dall’adder e corrisponde al valore

spedito al processore tramite il bus OPB;

47


Figura 3.16: Process di lettura e scrittura.

• richiesta di scrittura - process writeregister dell’adder in esecuzione: oltre

ad address, il processore invia all’adder anche un’informazione aggiunti-

va (segnaleWrite Data in ingresso all’adder), che nel caso in esame cor-

risponde ad uno dei due valori da sommare (memorizzati inregister0 e

register1) oppure al comando di somma (memorizzata inresult): negli ul-

48


timi 8 bit del segnaleaddressil processore indica quale dei tre possibili dati

sta inviando all’adder.

Process Bit da 24 a 31 del

campoaddress

Operazione

readregister x“08” a regdata viene assegnato il valore di

result (somma dei due numeri)

readregister x“0C” i primi 31 bit di regdata sono posti a ze-

ro, mentre l’ultimo assume il valore di

reg intr (1 se viene sollevato l’interrupt,

0 altrimenti)

write register x“00” a register0 viene assegnato il valore di

Write Data

write register x“04” a register1 viene assegnato il valore di

Write Data

write register x“0C” viene abbassato il segnale di interrupt

(reg intr e posto a 0)

write register x“08” a result viene assegnato il valore della

somma di register0 e register1

Tabella 3.1: Operazioni svolte dall’adder.

Nella Tabella3.1si possono vedere in modo dettagliato tutte le operazioni che

l’adder svolge in base al valore che assumono gli ultimi 8 bit del segnaleaddress

e in base al tipo di richiesta del processore (lettura o scrittura); si ricorda che al

segnale interno all’adder denominatoreg intr e associato il segnale diinterrupt in

uscita dall’adder.

3.4 Inserimento di un IP core nell’architettura

Un altro passo importante per integrare le funzionalita dell’IP core all’interno

del sistema, riguarda il corretto inserimento del componente medesimo mediante

49


l’utilizzo del Wizard di EDK (per informazioni piu dettagliate a riguardo, si faccia

riferimento a [6]).

La prima operazione da eseguire in questa fase consiste nell’aprire il sistema

costituito dall’architettura iniziale, entrare nel menuTools, scegliere la voceIm-

port Peripheral Wizard...e seguire poi le varie istruzioni proposte. Si prosegue

scegliendo le opzioni che riguardano l’inserimento della periferica (intesa come

IP core) in un progetto XPS esistente: in questo modo tutti i file che riguardano

l’IP core in questione verranno salvati nella cartella\pcoresdella directory prin-

cipale del sistema di riferimento secondo la struttura mostrata in Figura3.17. La

Figura 3.17: Gerarchia delle cartelle di adderv1 00 a contenuto in pcores.

gerarchia di cartelle contenute in pcores descrive un IP core nella sua completez-

za; allo stato attuale sono gia stati analizzati solamente i fileaddercore.vhdle

50


adder.vhdlcontenuti nella sottocartellahdl\vhdl, per tutti gli altri file si rimanda

alle sezioni successive.

Ritornando all’inserimento guidato dell’IP core, dopo aver digitato il nome

e la versione desiderati (in questo casoadder versione v100 a) e dopo aver

specificato che l’implementazionee scritta in VHDL,e possibile importare i file

addercore.vhdl e adder.vhdl, che identificano l’adder, e le librerie relative al com-

ponente aggiuntivo PSelect, contenute nella directoryproc commonv1 00 b che

si trova in una sottocartella di EDK. A questo punto si sceglie il bus di interconnes-

sione fra IP core e processore, ovvero il bus OPB, e si indica che tale componente

e unoslave(OPB Slave, SOPB). La fase piu delicata della procedura si presenta

Figura 3.18: Step 8 del tool “Import peripheral wizard”.

nel momento in cui EDK chiede se siano presenti segnali di interrupt: in questo

caso tale opzione va selezionata, come mostrato in Figura3.18, e va indicato che

tale segnalee High level sensitive, in modo da rendere coerenti le impostazioni

settate per i due microblaze del sistema, come mostrato nella finestraAdd/Edit

Platform Specificationdi Figura3.19.

Una volta terminata la procedura di inserimento guidato dell’adder, tale com-

51


Figura 3.19: Coerenza nell’impostazione della sensitivity del segnale di interrupt

dell’adder e dei microblaze.

ponente entra a far parte dell’elenco degli IP core standard di EDK, la cui listae

presente al segnalibro Components del frame di sinistra nella schermata principale

del programma, come mostrato in Figura3.20.

Figura 3.20: Adder inserito nei componenti standard di EDK.

3.5 Gestione degli interrupt

Lo scopo di questa sezionee quello di analizzare il comportamento degli IP

core che sollevano interrupt, valutare il modo con cui essi devono essere gestiti e,

52


soprattutto, capire come il tool EDK consente lo sviluppo di tali procedure; per

maggiori dettagli si veda il documento [2].

3.5.1 Interrupt Controller

EDK distingue due casi di gestione degli interrupt. Il primo caso, piu semplice,

non prevede nessun componente intermediario tra l’IP core che solleva l’interrupt

e il processore; questo caso si riconduce alla situazione in cui l’IP coree unico e

puo sollevare un solo interrupt alla volta.

Il secondo caso riguarda le seguenti situazioni:

• quella con un solo IP core che puo sollevare piu interrupt;

• quella con piu IP core concorrenti.

Quest’ultimoe gestito da EDK utilizzando un controllore di interrupt, che si

trova nella lista dei componenti standard di EDK (Components, vedi Figura3.21),

ede stato implementato per essere utilizzato su un bus di tipo OPB. Tale control-

Figura 3.21: Interrupt controller presente nei componenti standard di EDK.

lore presenta una porta di interrupt in Input, che riceve in ingresso gli eventuali

segnali provenienti dagli IP core che li sollevano, e una porta di Output dalla quale

il solo segnale di interrupt prescelto si propaga verso la risorsa.

Compito del controlloree quindi quello di ricevere i segnali e mappare al-

l’interno di un vettore (vettore di interrupt) l’interrupt che l’IP core ha solleva-

to, secondo una politica di priorita stabilita precedentemente. L’allocazione della

53


memoria necessaria, l’inizializzazione statica del vettore di interrupt e la confi-

gurazione delle funzioni di interrupt, denominate interrupt service routines, ISR,

sono operazioni affidate al tool di EDK chiamato Libgen, il quale si occupa anche

di generare le librerie utilizzate dagli IP core presenti nel sistema e i vari “device

drivers”. L’IP core con livello di priorita maggiore accede dunque per primo alla

risorsa. L’interrupt controller (per brevita in seguito chiamato intc) segnala al-

lora alla risorsa, tramite la propria porta di Output, che tale IP core richiede “la

sua attenzione”. Affinche l’int c rilevi il segnale di un IP core in un certo istante,

occorre che questo possieda una porta di interrupt (con polarita Output) connessa

alla net della porta d’ingresso dell’intc (con polarita Input); il nome della nete

dato dall’and logico fra le net connesse alla porta di uscita di ogni singolo IP core

che si interfaccia all’intc (in Figura3.22 e mostrato l’esempio di una struttura

possibile).

Figura 3.22: Possibile struttura che utilizza l’interrupt controller.

E importante segnalare una sostanziale differenza nella gestione degli inter-

rupt nel caso sia presente nell’architettura un processore di tipo PPC oppure Mi-

54


croblaze (una breve guida su tali differenzee presente piu avanti in questo lavoro

di tesi; si consiglia comunque di fare riferimento al cap. 23 di [23] per un ulte-

riore approfondimento sull’argomento). Infatti, nel caso di PPC, vero e proprio

“hard processor” (cioe processore implementato fisicamente sulla FPGA)e nec-

essario gestire “manualmente” gli interrupt, in particolare la sezione relativa alla

exception handling, e la gestione della memoria ad essi associata. Nel caso del

Microblaze,soft processor(cioe processore che utilizza la logica riconfigurabile),

la gestione della memoria avviene invece in modo automatico; occorre semplice-

mente abilitare la CPU alla gestione degli interrupt, e vanno omessi i metodi per

inizializzare l’exception handling.

Entrambi i processori necessitano di una o piu memorie esterne, bramblock,

che contengano il vettore degli interrupt, il codice compilato, i dati, ecc. La ge-

stione di tali memorie puo essere “descritta” all’interno di un file di nome Linker

Script (fare riferimento al cap 22 di [23] per un ulteriore approfondimento sul suo

utilizzo).

3.5.2 Esempio di applicazione

Si aggiungano ora tre componenti all’architettura di riferimento mostrata nella

sezione3.2:

• due adder, che avranno il compito di sollevare segnali di interrupt;

• un interrupt controller, con il compito di incanalare i vari segnali di inter-

rupt sollevati dagli IP core abilitati verso i due microblaze presenti.

Il file System.pbd del sistema risultante, che implementa due ISR relative ai

due possibili interrupt sollevati rispettivamente dal primo e dal secondo adder, si

presenta in forma sintetica come mostrato in Figura3.23.

Seguendo una descrizione di tipo passo-passo verranno ora descritti i punti piu

significativi e rilevanti della sintesi:

Passo 1

55


Figura 3.23: System.pbd dell’architettura risultante.

56


Definizione della struttura desiderata, cioe come configurare i parametri dei

componenti aggiunti alla architettura base (per i passaggi da seguire va fatto rife-

rimento a [14]). Nel caso in esame, come gia anticipato, i due IP core che sollevano

segnali di interrupt sono adder1 e adder2, i quali sono connessi all’opbintc che a

sua voltae collegato ai due processori di tipo microblaze (Figura3.23).

Figura 3.24: Sezione object properties di opbtimer.

Per ogni componente citato (in object properties, si veda ad esempio il caso del

componente adder1 in Figura3.24) vanno configurate opportunamente le porte, le

net a cui queste sono connesse e i vari parametri relativi agli interrupt come, ad

esempio, le net da cui l’intc rileva l’interrupt di una periferica e le ISR.

• Componente adder1:

– Sezione ports:la porta di nome Interrupte collegata alla net adder1in-

terrupt;

– Sezione interrupts:tale componente non ha interrupt (non li gestisce,

cioe non deve preoccuparsi se qualche net puo sollevare interrupt,e lui

stesso che li solleva).

• Componente adder2:

57


Figura 3.25: Sezione Interrupt di adder1.

– Sezione ports:la porta di nome Interrupte collegata alla net adder2in-

terrupt;

– Sezione interrupts: tale componente non ha interrupt (come sopra,

non li gestisce, li solleva).

• Componente opbintc:

– Sezione ports:la porta di nome Irq (in Output)e collegata alla net

interrupt, la porta di nome Intr (in Input)e collegata alla net di nome

adder1interrupt & adder2interrupt, come da Figura3.26;

– Sezione interrupts:alla porta Intr sono associati due interrupt drivers,

i quali indicano che sono stati definiti dei metodiint handler, il cui

significato sara chiarito al Passo 2, per la gestione degli interrupt prove-

nienti dagli IP core connessi all’intc tramite le net indicate (in questo

caso la net adder1interrupt per gli interrupt sollevati da adder1 e la net

adder2interrupt per quelli di adder2, come si vede dalla parte sinistra

della Figura3.27).

• Componente microblaze1:

58


Figura 3.26: Net collegata alla porta Intr dell’opbintc.

Figura 3.27: Sezione Interrupt di opbintc.

– Sezione ports:la porta di nome Interrupt (in Input)e collegata alla net

interrupt;

– Sezione interrupts: in riferimento alla Figura3.28 alla porta Inter-

rupt e associato un interrupt driver, quello riguardante la net interrupt,

l’unica da cui puo sopraggiungere un segnale di interrupt.

59


Figura 3.28: Net collegata alla porta Intr dell’opbintc.

• Componente microblaze2:

– Sezione ports:la porta di nome Interrupt (in Input)e collegata alla net

interrupt;

– Sezione interrupts: come per il microblaze1, alla porta Interrupte

associato un interrupt driver, quello riguardante la net interrupt, l’unica

da cui puo sopraggiungere un segnale di interrupt.

Riassumendo:tutti i parametri settati sono visibili in modo schematizzato

nella finestra di dialogo raggiungibile da Project⇒ add/edit cores⇒ ports.

Le voci di interesse sono quelle che nella colonna class hanno indicato In-

terrupt (vedi Figura3.29). Si raccomanda di prestare particolare attenzione

ai nomi delle net e alla polarita delle porte; tutto deve corrispondere in modo

analogo allo schema illustrato in Figura3.30(sul modello di Figura3.22).

Passo 2

Si analizza ora il filemain.ccontenuto nella cartellaSourcesrelativa al mi-

croblaze 1 (la situazionee analoga per il microblaze 2). Tale file contiene tutti i

metodi, interrupt service routine, ISR, che gestiscono gli interrupts sollevati dagli

IP core che ne fanno uso; queste funzioni possono, come nell’esempio, essere

60


Figura 3.29: Riassunto delle porte e net settate.

Figura 3.30: Struttura dell’esempio.

scritte in C come una qualsiasi funzione e devono avere il nome nella formanome-

funzioneint handler in modo tale che in fase di compilazione e di generazione

61


delle librerie (comandomb-gccdi Libgen) vengano riconosciute come “interrupt

handler”.

Figura 3.31: Metodo che gestisce l’interrupt sollevato dal componente adder

In questo caso il metodoadder int handler(si veda figura Figura3.31) e quel-

lo relativo al componente adder generico, senza specificare di quale dei due si

tratta; questo perche alla funzione di int handlere passato come parametro il

baseAddr dell’IP core cui si riferisce: in tal modo la gestione dell’interrupte in-

dipendente dall’istanza del componente, la qualee racchiusa nel baseaddr pas-

sato al processore dal componente stesso. Il codice che implementa tale funzione

costituisce la routine di gestione dell’interrupt.

Si noti che, per un corretto funzionamento, devono essere importate le librerie

fondamentali relative all’intc e agli IP core che sollevano interrupt; tali librerie

contengono nel proprio nome un suffissol.h. In questo caso vengono importate

due librerie fondamentali:

• #include “adderl.h” //relativa all’adder;

• #include “xintc l.h” //relativa all’opb intc.

Si riportano ora alcune righe di codice, per sottolineare alcune sostanziali

differenze nel caso di impiego di un processore Microblaze oppure di tipo PPC:

62


• nel caso in esame il processoree di tipo Microblaze, pertanto la configu-

razione delle funzioni di gestione degli interrupte automatica, con la sola

condizione di abilitare il processore mediante il comando:

/∗ Enable MB interrupts ∗/microblaze enable interrupts();

• piu complessoe il caso in cui si utilizzi un processore di tipo PPC; in que-

sta situazione infatti Libgen non configura automaticamente le funzioni di

interrupt come “exception handler” per il PPC, mae il progettista a dover

registrare ogni singola funzione di handler ad essere una “exception hand-

ler”.

/∗ Initialize exception handling ∗/XExc Init();

/∗ Register external interrupt handler ∗/XExc RegisterHandler(XEXC ID NON CRITICAL INT,

(XExceptionHandler)XIntc LowLevelInterruptHandler, (void ∗)0);

/∗ Enable PPC non-critical interrupts ∗/XExc mEnableExceptions(XEXCNON CRITICAL);

Passo 3

Perche i due IP core possano effettivamente sollevare l’interrupt, e quindi per-

mettere all’opbintc di richiamare le funzioni sopra citate,e necessario impostare

in Software Platform Settings, segnalibroProcessor and Driver Parametres, come

mostrato in Figura3.32, l’Interrupt Handler Function di ciascun componente in-

teressato (e quindi nel caso in esame quelle relative ai due adder). Sia per adder1

che per adder2 viene impostata la medesima funzione, adderint handler, in quan-

to, come sie gia detto, questae resa parametrica dal valore del baseaddr passato,

chee univoco per ogni istanza di componente.

Passo 4

63


Figura 3.32: Inserimento della funzione diint handler

Come ulteriore verifica di correttezza, si apra il filesystem.msse si osservi

che i driver relativi ai due IP core adder1 e adder2 contengono fra i parametri

tutte le impostazioni relative alla gestione degli interrupt. In Figura3.33, le righe

Figura 3.33: Parametri relativi ad adder1 e adder2

evidenziate specificano che sia il componente adder1 che il componente adder2

possiedono una porta (intport) attraverso la quale possono sollevare eventuali

segnali di interrupt e che tali segnali vengono gestiti mediante la funzione di

handler denominata adderint handler.

3.6 Driver per la periferica

In questa sezione verranno descritti in dettaglio tutti i file necessari alla crea-

zione di un device driver per un dato IP core, [1], nel caso in esame per l’adder.

Si faccia riferimento alla Figura3.17per comprendere al meglio la gerarchia di

64


cartelle che sta alla base di tali file: essa, infatti,e particolarmente importante in

quanto il meccanismo di compilazione dei driver/librerie, LibGen, richiede una

ben definita struttura delle cartelle affinche i file in esse contenuti possano essere

debitamente trovati e compilati. LibGen ricerca i driver e le librerie seguendo una

politica di priorita, come indicato di seguito, [23]:

1. ricerca nella directorypcorescontenuta nella cartella principale del proget-

to;

2. ricerca in un particolareLibrary pathspecificato;

3. ricerca nella sottocartellaswcontenuta nella cartella principale di EDK;

3.6.1 Microprocessor driver definition

Ogni device drivere associato ad un fileMDD (microprocessor driver defi-

nition) e ad un fileTCL (tool command language), i quali si trovano all’interno

della cartelladata, come mostra la Figura3.17. Il file .mdd contiene le direttive

per creare dei driver specifici per l’IP core custom; tale filee utilizzato dal file .tcl

per customizzare i driver in base a differenti opzioni configurate nel file .mss del

sistema, come si puo vedere dalla Figura3.34; ad esempio quie possibile indicare

Figura 3.34: Definizione del driver per il componente adder nel file System.mss

il nome del driver (riga 100), la versione (riga 101) e l’istanza del componente

che ne fa uso (riga 102). Inoltree possibile configurare la porta per mezzo della

quale la periferica puo sollevare segnali di interrupt e la funzione che il processore

deve eseguire nel momento in cui riceve tali segnali (riga 103). Alcuni di questi

parametri possono essere settati anche tramite la sezione Software Platform (fine-

stra di dialogo Software Platform Settings); in questa finestra, infatti,e possibile

65


scegliere il driver relativo a ciascun componente dell’architettura; in Figura3.35

si nota come per l’adder siano disponibili tre scelte: nessun driver, driver generico

oppure driver specifico per il componente adder.

Figura 3.35: Scelta del driver per il componente adder nella finestra di dialogo

La definizione di un driver per un IP core generico comporta la stesura del file

adderv2 1 0.mdd, che contiene i parametri configurabili, e del fileadderv2 1 0.tcl,

che utilizza i parametri relativi al driver configurati nel file System.mss per la

generazione dei dati, quali header files e C files.

3.6.2 Formato del file adderv2 1 0.mdd

In Figura3.36 e riportato il testo del file .mdd del componenteaddercui si

riferisce questo capitolo.

L’istruzione BEGIN DRIVER definisce l’inizio del driver denominatoadder,

tale driver si concludera con l’istruzione END DRIVER. L’istruzione successiva

indica a quale IP core il drivere associato, dopodiche vengono configurati alcuni

parametri: nel caso in esame il parametro LEVEL, che rappresenta proprio il livel-

lo di interfaccia del driver,e nello statodeprecated: questo perche le funzionalita

dei driver sia di livello 0 che di livello 1 vengono implementate automaticamente

nella libreria target del componente.

L’operazione OPTION COPYFILES indica i file che Libgen copia nella di-

rectory del progetto per creare un driver per il componente adder. Nella parte di

codice racchiusa fra l’operazione BEGIN ARRAY interrupthandler e END AR-

RAY sono contenute le istruzioni standard per indicare che l’IP coree abilitato ad

avere una funzione di interrupt handler per la gestione dei segnali di interrupt.

66


Figura 3.36: adderv2 1 0.mdd

A questo puntoe opportuno osservare la presenza di due diversi casi che

possono generare errori in riferimento alla funzione di interrupt handler:

• Caso 1:Omettendo dalla cartella dell’IP core (si veda Figura3.17) tutti i

file relativi ai driver, e cioe la sottocartellasrc al completo e i file.mdde

.tcl nella sottocartelladata, none piu possibile gestire i segnali di interrupt

sollevati da questo IP core. LibGen infatti vieta agli IP core privi di driver

propri, e che quindi adottano il driver generic, di disporre di una fuzione di

interrupt handler. Questo perche il file .mdd del driver generic non contiene

il blocco relativo agli interrupt. Come si vede in Figura3.37, se il driver scel-

to e generic l’IP core none presente nella sezionedriver parametresdella

finestra di dialogoSoftware Platform Settings, e pertanto none nemmeno

possibile settare alcuna funzione di interrupt handler.

67


Figura 3.37: Un IP core con driver generic non puo avere una funzione inthandler

• Caso 2: Omettendo dal file .mdd il codice relativo alla gestione dell’in-

terrupt handler (BEGIN ARRAY. . . END ARRAY) e mantenendo inal-

terati tutti i file dell’adder relativi ai driver il comportamento di LibGen

non cambia molto rispetto al caso precedente: none possibile associare al-

l’IP core con driver adder una funzione di interrupt handler poiche manca

la parte di codice che lo autorizza. Come si vede in Figura3.38se manca la

dichiarazione dell’interrupt handler nel file MDD la perifericae comunque

presente nella sezionedriver parametresdella finestra di dialogoSoftware

Platform Settings(in quanto il driver settatoe diverso da generic) ma non

vi e alcuna casella per l’inserimento della funzione di interrupt handler.

Figura 3.38: Adder non autorizzato ad avere una funzione inthandler

68


3.6.3 Formato del file adderv2 1 0.tcl

In Figura3.39e riportato il testo del file .tcl dell’IP coreaddercui si riferisce

questo capitolo. Il file .tcl qui riportato fa riferimento al file .mdd descritto nella

Figura 3.39: adderv2 1 0.tcl

precedente sezione.

La routine GENERATE crea in un header file, xparameters.h, e in un C file le

costanti per il driver relativo all’adder; tale creazionee basata sulla configurazione

dei parametri del driver presenti nel file System.mss.

3.6.4 Makefile e LibGen

In Figura 3.40 e riportato il testo delMakefiledell’IP core cui si riferisce

questo capitolo, che si trova nella cartellasrc come si vede in Figura3.17.

Il makefile e utilizzato da LibGen per compilare i driver e le librerie dell’ad-

der; tale file deve necessariamente contenere i comandiincludee libs, tramite i

quali si ricollega al driver dell’IP core da compilare. Mediante il comandoECHO

e possibile inserire una stringa di testo che verra visualizzata durante la compi-

lazione.

A conclusione di questa sezione si mostrano i passaggi che LibGen compie

durante la creazione delle librerie e dei device driver, in riferimento al componente

adder. Dopo aver inserito la cartella completa dell’adder mostrata in Figura3.17

nella cartella pcores di un’architettura di riferimento, inserito correttamente uno o

piu componenti collegandoli al bus opb, [14], e successivamente inclusa la libreria

adderl.h nel file System.c, si da il via alla generazione delle librerie tramite il tool

69


Figura 3.40: Makefile del componente adder

LibGen. In Figura3.41e mostrata la fase di apertura del file .tcl, tramite il quale

LibGen crea i parametri necessari alla periferica nel file xparameters.h, come da

Figura3.42.

Figura 3.41: Apertura file .tcl

70


Figura 3.42: Definizione dei parametri dei due componenti adder1 e adder2

Successivamente LibGen genera le librerie e i device driver, fra i quali si

notano anche quelli relativi all’adder: infattie stata creata nelle due directory

C:\architetturabase\microblaze1\libsrc\ e C:\architetturabase\microblaze2\libsrc\la cartella adderv1 00 a, dove sono stati copiati tutti i file relativi al driver, come

si vede da Figura3.43.

Figura 3.43: Crezione di una sottocartella relativa al driver del componente adder

Quando tutti i file relativi all’adder e al proprio driver sono stati copiati cor-

rettamente nella cartella mostrata, LibGen compila i file adderl.h e adderl.c; al

71


termine di questa operazione viene visualizzata sulla shell di EDK, Figura3.44,

la stringa inserita nel makefile indicante l’avvenuta compilazione.

Figura 3.44: Compiling adder

3.7 Scrittura e gestione della memoria

Passo fondamentale per portare a termine l’implementazione e poter effettiva-

mente sintetizzare, secondo la metodologia proposta, il meccanismo di gestione

della concorrenza fra piu processori tramite semafori,e quello di capire come

possano essere realizzate con EDK le funzionalita di gestione di una memoria,

che sara in parte condivisa tra i due processori. Le funzionalita ricercate sono

principalmente quelle di scrittura e lettura di una memoria, unabram block, che

in questo caso risulta partizionata in tre settori, Figura3.45: due sono rispetti-

vamente adibiti ai due processori e uno in condivisione tra i due. La memoria

72


Figura 3.45: I tre settori della bramblock.

utilizzata ha dimensione, come risulta evidente dallo spazio di indirizzamento as-

segnato in Figura3.45, di 8192 Byte (8KB); questae suddivisa in tre partizioni,

rispettivamente:

• la prima, dall’indirizzo 0x00000000 (Base Address) all’indirizzo 0x000007FF,

ha dimensione di 2048 Byte, ede riservata al processore1.

• la seconda, riservata al processore2, di dimensione 2048 Byte, dall’indiriz-

zo 0x00000800 all’indirizzo 0x00000FFF.

• la terza, che costituisce la risorsa condivisa, ha dimensione di 4096 Byte, va

dall’indirizzo 0x00001000 all’indirizzo 0x00001FFF.

Assegnare uno spazio di indirizzamento ad una memoria, all’interno di una ar-

chitettura in EDK, significa assegnarne l’effettiva dimensione/capacita, in termini

di Byte. Con EDKe possibile effettuare tale operazione semplicemente settando

il Base Address e l’High Address di un modulo denominato opbbram if cntlr,

73


OPB Block RAM (BRAM) Interface Controller, che, come evidenziato dal nome,

rappresenta l’interfaccia attraverso la quale la memoria, Block Ram, viene colle-

gata al bus OPB, Figura3.46. Una volta che la memoria risulta opportunamente

Figura 3.46: Settare lo spazio di indirizzamento della memoria.

inserita all’interno dell’architettura di riferimento e sono stati settati in modo cor-

retto i parametri relativi allo spazio di indirizzamento, risulta necessario gestire

le funzionalita di scrittura, lettura e condivisione; queste funzionalita vengono

gestite tramite software. In particolare sono state implementate due funzioni che

forniscono rispettivamente le procedure di scrittura e lettura e che, inoltre, ge-

stiscono la politica di accesso alla memoria nella partizione corretta, ovvero im-

pedendo l’accesso di un processore allo spazio di indirizzamento privato di un

altro processore. A titolo di esempio, viene riportato qui di seguito il codice della

funzione di scrittura, writeBRAM.

unsigned int write_BRAM(unsigned int* bram_base_addr,

unsigned int* bram_location, unsigned int* info){

int i=0;

unsigned int* p1_addr;

74


unsigned int* p2_addr;

unsigned int* shared_addr;

p1_addr = (unsigned int*) p1_bram_addr;

p2_addr = (unsigned int*) p2_bram_addr;

shared_addr = (unsigned int*) shared_bram_addr;

xil_printf("bram_base_addr = %x

\n\rp1_addr = %x\n\n", bram_base_addr, p1_addr);

if (bram_base_addr == p1_addr) {

if ((bram_location >= p1_addr) &&

(bram_location < p2_addr)){

for (i = 0;i<16;i++){

*bram_location =(unsigned int) info[i];

bram_location += 1;

}

}

else

xil_printf("\n***P1***ERRORE: indirizzo di

scrittura non consentito\n");

}

else if (bram_base_addr == p2_addr){

if ((bram_location >= p2_addr) &&

(bram_location < shared_addr)){

for(i=0;i<16;i++){

* bram_location = info[i];

bram_location += 1;

}

}

else

xil_printf("\n***P2***ERRORE: indirizzo di

scrittura non consentito\n");

}

75


else

xil_printf("\nERRORE: si vuole accedere ad

uno spazio della BRAM non corretto\n");

return (unsigned int) bram_location;;

}

Tale funzione, che risulta in effetti speculare a quella di lettura, riceve in

ingresso tre parametri, rispettivamente:

• bram baseaddr, e il Base Address della memoria in cui si vuole scrivere.

• bram location, e l’effettiva locazione/indirizzo della memoria da cui si vuole

cominciare a scrivere.

• info, e un array, che rappresenta il dato che andra scritto effettivamente nella

memoria.

In dettaglio, l’operazione di scrittura consiste in un ciclofor che scandisce il con-

tenuto di INFO e lo copia nella zona di memoria a cui il puntatorebram location

fa riferimento; si nota che, ad ogni iterazione, tale puntatore viene incrementato di

uno, il che corrisponde ad un incremento di 32 bit dello spazio di memoria refe-

renziato: tale spazio none altro che la quantita di memoria necessaria per scrivere

un dato di tipounsigned int.

Il parametro di ritorno della funzione rappresenta la prima cella di memoria disponi-

bile per una successiva scrittura: in questo modoe garantito che i dati precedente-

mente salvati in memoria non vengano sovrascritti.

E importante chiarire il significato delle tre variabili: p1bramaddr, p2bramaddr

e sharedbramaddr; queste sono definite come costanti:

#define p1_bram_addr XPAR_OPB_BRAM_IF_CNTLR_0_BASEADDR

#define p2_bram_addr

XPAR_OPB_BRAM_IF_CNTLR_0_BASEADDR + 0x00000800

#define shared_bram_addr

XPAR_OPB_BRAM_IF_CNTLR_0_BASEADDR + 0x00001000

76


Il parametroXPAROPB BRAMIF CNTLR0 BASEADDRnone altro che il

Base Address dell’opbbram if cntlr di cui sie parlato sopra, a cui viene sommato

un OFFSET, relativo allo spazio effettivo che si vuole riservare alle tre partizioni

della memoria.

77

Capitolo 4

Conclusioni e Sviluppi Futuri

Il lavoro svolto e l’esperienza acquisita con i tool di sviluppo utilizzati, hanno

contribuito in modo determinante alla realizzazione di una metodologia adegua-

ta al raggiungimento dello scopo di questa tesi; le numerose difficolta incontrate,

concentratesi soprattutto nella fase di integrazione delle varie funzionalita dell’IP

core in EDK, sono state superate per gradi, spesso mediando tra le molteplici

scelte progettuali, per cercare il giusto compromesso tra esigenze ed effettiva fat-

tibilit a.

La metodologia proposta in questa tesi costituisce una solida base da cui poter

proseguire, per portare a termine la sintesi della Concurrency Engine; rimane da

completare e analizzare con maggiore dettaglio lo studio per la realizzazione del

meccanismo di accesso diretto alla memoria, DMA, fondamentale nella metodolo-

gia introdotta. Quest’ultimo, in particolare, costituisce un valido punto di partenza

per possibili lavori futuri in cui, grazie alle conoscenze ed esperienze qui illustra-

te, gli sforzi potrebbero convergere verso una fase prettamente implementativa,

magari trascurando, limitatamente ad una fase iniziale, alcuni aspetti relativi al-

lo studio delle varie casistiche architetturali e logiche, gia affrontati nel corso di

questa tesi.

Una ulteriore ed interessante estensione del lavoro sin qui svolto,e quella di

progettare una architettura multiprocessore “mista”, ovvero in cui siano presen-

ti processori “soft”, qualee il Microblaze, e processori “hard”, come ilPowerPC;

78

CAPITOLO 4. CONCLUSIONI E SVILUPPI FUTURI

tale estensione porterebbe alla ribalta varie problematiche dovute all’integrazione

e dialogo di processori dissimili e inoltre problematiche prettamente legate alla

capacita effettivamente resa disponibile dalle FPGA di ultimissima generazione.

L’FPGA di cui e dotata la scheda a disposizione e supporto del presente lavoro

di tesi, la Avnet Virtex II Pro Evaluation Board, potrebbe contenere infatti sino a

quattro processori Microblaze.

Le ampie conoscenze acquisite nel corso di questo lavoro di tesi, costituiscono

dunque delle buone fondamenta per un possibile lavoro di ricerca nel campo delle

tecnologie e degli studi sin qui affrontati.

79

Ringraziamenti

Beh non si possono considerare ringraziamenti conclusivi, perche siamo solo a

meta dell’opera, ma siamo sulla buona strada! Un “piccolo” traguardo l’abbiamo

raggiunto, cronometro alla mano, grazie alle nostre forze sı, ma grazie anche a

tante persone che ci hanno sostenuto e che hanno creduto in noi.

Siamo a luglio, il lavoro di tesi sie concluso. . . pero e bello ripensare anche a

quando l’avventurae iniziata:

. . .primo giorno di lezione del corso di Reti Logiche, aula T.0.1 strapiena con

gente seduta anche sulle finestre, il professor Ferrandi che introduce gli argomenti

nuovi e parla di questo particolare progetto da 2,5 cfu. . . tutti che si guardano

attorno e dicono: “non fatelo, l’anno scorsoe stato difficilissimo!”. . . ma noi ci

siamo guardati e abbiamo deciso in un istante: “bellissimo, questoe il progetto

giusto per noi! magari da estendere a tesina!”. . .

. . .e cosı e stato! Un grazie grandissimo va al professor Ferrandi che ci ha ispirato

fiducia sin dal primo giorno, che ci ha assegnato questo interessante lavoro di

tesi e che ci ha permesso di entrare a far parte di un gruppo stupendo, quello del

µ-Lab, dove il lavoro, pur rimanendo lavoro (serio!) diventa allegria, simpatia e

complicita!

Ed e proprio una persona all’interno delµ-Lab quella che intendiamo ringra-

ziare con particolare attenzione: Marco. . . il “Santa”. . . sempre disponibile, sem-

pre gentile, sempre presente!E il nostro nuovo amico: sı proprio amico; strano

pensarlo in universita, o comunque in un ambiente di lavoro, eppure questa sua

idea di “fare gruppo” ci ha uniti sul serio! Ci ha fatto scoprire il “lato umano”

dell’universita. . . grazie davvero!

80

Ringraziamenti

Siamo un po’ stanchini di fare avanti e indietro da Milano, cari mamma e papa

(mamma Rita e papa Gimmy per la Fra, mamma Lucia e papa Gino per l’Ale), ma

alla fine ce l’abbiamo fatta! Un grazie grande va soprattutto a voi, che col vostro

appoggio morale, affettivo (ed economico. . . non ce lo dimentichiamo!) ci avete

permesso di superare alla grande questi primi tre anni di universita e soprattutto

quelle due settimane infernali dei compitini. . . 2 settimane interminabili, per 4

volte l’anno, per 3 anni. . . beh, nee valsa la pena!! (pero dall’anno prossimo si sta

a Milano. . .)

Poi ci sono i fratellini da ringraziare. . . l’elenco e lunghino. . . 3 per la Fra

(Vale, Roby, Ale) e 3 per l’Ale (Simo, Massi, Bea). . . non vanno dimenticati

perche anche loro sono grandi: “Ale ma come fai a studiare quella roba?!” op-

pure “Fra ma ci capisci davvero?!”. Che forza, ci tengono su di morale quando

stiamo studiando! (per il resto sono fratelli come tutti i fratelli del mondo. . . la

parola si commenta da sola!)

Grazie anche ai nostri amici dell’universita, nostri compagni d’avventura. . .

siamo tutti nella stessa barca e remiamo insieme alla grande! Gran parte di loro,

infatti, ha tagliato il traguardo con noi, e se none luglio sara ottobre, ma poco

importa: quando le lezioni riprenderanno saremo lı ancora tutti insieme ad allietare

con la compagnia anche le lezioni piu noiose.

Bene, dovremmo aver ringraziato proprio tutti, ma se ci siamo dimenticati

qualcuno e quel qualcuno pensa di meritarselo. . . grazie anche a lui!

Per concludere pero riteniamo doveroso ringraziarci a vicenda: io ringrazio

te e tu ringrazi me. . . e bello aver lavorato ed aver raggiunto questo importante

traguardo. . . ede ancora piu bello perche l’abbiamo fatto insieme. . . io e te. . . gra-

zie di cuore. . .

Grazie ancora,

Francesca & Alessandro

81

Bibliografia

[1] Francesca Malcotti Alessandro Mele.Definizione e utilizzo dei DRIVER

in EDK. Politecnico di Milano - Laboratorio di Microarchitetture, maggio

2004.

[2] Francesca Malcotti Alessandro Mele.Gestione degli interrupt con EDK.

Politecnico di Milano - Laboratorio di Microarchitetture, 2004.

[3] Roberto Saini Alessandro Prete.Metodologia per la realizzazione di Peri-

feriche Custom orientate alla Riconfigurazione Embedded. Politecnico di

Milano - Laboratorio di Microarchitetture, marzo 2004.

[4] OCP-IP Association.Open Core Protocol Specification. 2003.

[5] John L. Hennessy David A. Patterson.Computer Organisation and Design.

The hardware/software interface, 2000.

[6] Stefano Orlandi Davide Murrai, Diego Nichetti.Import a Peripheral Wizard.

Politecnico di Milano - Laboratorio di Microarchitetture, maggio 2004.

[7] Andre DeHon. DPGA-Coupled Microprocessors: Commodity ICs for the

Early 21st Century.

[8] Jean-Jacques Quisquater Jean-Didier Legat Gael Rouvroy, Francois-

Xavier Standaert. Design Strategies and Modified Descriptions to Opti-

mize Cipher FPGA Implementations: Fast and Compact Results for DES

and Triple.DES. UCL Crypto Group, Laboratoire de Microelectronique,

Universite catholique de Louvain.

82

Bibliografia

[9] John Reid Hauser. Augmenting a Microprocessor with Recon-figurable

Hardware. 2000. A dissertation submitted in partial satisfaction of the

requirements for the degree of Doctor of Philosophy.

[10] David A. Patterson John L. Hennessy.Architettura dei computer: un

approccio quantitativo. 2001.

[11] David Lewis Jonathan Rose, Robert Francis and Paul Chow.Architecture

of field programmable gate arrays: The efect of logic block functionality on

area eficiency. IEEE Journal of Solid-State Circuits, October 1990.

[12] G. Pelagatti.INFORMATICA II, sitema operativo linux e TCP/IP. 2002.

[13] Michael Rencher and Brad L. Hutchings.Automated target recognition on

SPLASH-2. April 1997. Proceedings of the IEEE Symposium on FPGAs for

Custom Computing Machines.

[14] Marco D. Santambrogio. Come aggiungere una periferica in un progetto di

edk. Dicembre 2003.

[15] Marco D. Santambrogio.A methodology for dynamic reconfigurability in

embedded system design. Politecnico di Milano-MicroLab, 2004.

[16] Khue Duong Steve Trimberger and Bob Conn.Architecture issues and

solutions for a high capacity FPGA. February 1997.

[17] Andrew S. Tanenbaum.Architettura Dei Computer. 2000.

[18] Andrew S. Tanenbaum.Modern Operating Systems. 2002.

[19] www.ocpip.org. Specifiche del bus ocp.

[20] www.vcc.com. Virtual computer corporation. 2000.

[21] Xilinx. The Programmable Logic Data Book. 1994.

[22] Xilinx. Muliprocessor systems. Aprile 2003.

83

Bibliografia

[23] Xilinx. Embedded System Tools Guide, versione 6.2, gennaio 2004.

[24] Xilinx. Processor ip reference guide. Gennaio 2004. cap.10.

[25] Xilinx and Steve Trynosky. Serial backplane interface to a shared memory.

Luglio 2003.

84

Sistemi Dedicati Multiprocessore: Sincronizzazione ...POLITECNICO DI MILANO Facolta di Ingegneria`...

Documents

Transcript of Sistemi Dedicati Multiprocessore: Sincronizzazione ...POLITECNICO DI MILANO Facolta di Ingegneria`...