INTEGRAZIONE DEL SOFT PROCESSOR MICROBLAZE NELL ... · politecnico di milano facolta di` ingegneria corso di laurea in ingegneria informatica integrazione del soft processor microblaze

POLITECNICO DI MILANO

FACOLTA DI INGEGNERIA

CORSO DI LAUREA IN INGEGNERIA INFORMATICA

INTEGRAZIONE DEL SOFT PROCESSORMICROBLAZE NELL’ARCHITETTURA

RICONFIGURABILE YaRA

Relatore: Prof. Donatella SCIUTO

Correlatore: Ing. Marco Domenico SANTAMBROGIO

Tesi di Laurea di:Ivan BerettaMatricola n. 662945Stefano BosisioMatricola n. 661865

ANNO ACCADEMICO 2005-2006

alla mia famiglia

Ivan

ai miei genitori

alla mia grande Amica Lara

Stefano

Ivan

Dictionary is the only place that success comes before work.

Vince Lombardi

Stefano

‘Solo gli imbecilli non hanno dubbi.’

‘Ma ne sei proprio sicuro?’

‘Non ho alcun dubbio’

Luciano De Crescenzo, ‘Il Dubbio’

Indice

Sommario 1

1 Riconfigurabilita 31.1 Logiche programmabili . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Programmazione hardware . . . . . . . . . . . . . . . . . . . . . 4

1.3 Tecniche di riconfigurabilita . . . . . . . . . . . . . . . . . . . . 6

1.3.1 Riconfigurabilita statica e dinamica . . . . . . . . . . . . 6

1.3.2 Riconfigurabilita totale e parziale . . . . . . . . . . . . . 7

1.3.3 Riconfigurabilita interna ed esterna . . . . . . . . . . . . 7

1.3.4 Alcuni aspetti critici . . . . . . . . . . . . . . . . . . . . 8

1.4 FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.4.1 Struttura . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.4.2 FPGA e riconfigurabilita . . . . . . . . . . . . . . . . . . 11

1.4.3 Bitstream . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 Gli strumenti utilizzati 172.1 Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.1.1 IBM CoreConnect . . . . . . . . . . . . . . . . . . . . . 18

2.1.2 WISHBONE . . . . . . . . . . . . . . . . . . . . . . . . 22

2.2 PowerPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.2.1 Caratteristiche . . . . . . . . . . . . . . . . . . . . . . . 23

2.2.2 Interfaccia esterna . . . . . . . . . . . . . . . . . . . . . 24

2.3 MicroBlaze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.3.1 Caratteristiche . . . . . . . . . . . . . . . . . . . . . . . 26

v

2.3.2 Interfaccia esterna . . . . . . . . . . . . . . . . . . . . . 27

2.4 Strumenti per implementazione e test . . . . . . . . . . . . . . . . 28

2.4.1 Avnet Virtex II - Pro Evaluation Board . . . . . . . . . . . 29

2.4.2 ISE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.4.3 EDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.5 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3 Caronte e YaRA 37

3.1 Caronte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.1.1 Struttura dettagliata . . . . . . . . . . . . . . . . . . . . . 38

3.1.2 Implementazione e Funzionamento . . . . . . . . . . . . 41

3.1.3 Limiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.2 YaRA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.2.1 Struttura dettagliata . . . . . . . . . . . . . . . . . . . . . 45

3.2.2 WISHBONE e comunicazione . . . . . . . . . . . . . . . 47

3.3 Nuove possibili evoluzioni . . . . . . . . . . . . . . . . . . . . . 48

4 Le innovazioni introdotte 51

4.1 La riconfigurabilita interna . . . . . . . . . . . . . . . . . . . . . 52

4.1.1 ICAP e relativo controller . . . . . . . . . . . . . . . . . 52

4.1.2 Il componente utilizzato . . . . . . . . . . . . . . . . . . 53

4.1.3 Principio di funzionamento . . . . . . . . . . . . . . . . . 54

4.1.4 Implementazione . . . . . . . . . . . . . . . . . . . . . . 54

4.1.5 Verifica del funzionamento . . . . . . . . . . . . . . . . . 56

4.2 L’utilizzo di MicroBlaze . . . . . . . . . . . . . . . . . . . . . . 56

4.2.1 I parametri di configurazione . . . . . . . . . . . . . . . . 57

4.2.2 Le altre modifiche alla parte fissa . . . . . . . . . . . . . 58

4.2.3 Riassemblaggio dell’architettura . . . . . . . . . . . . . . 59

4.2.4 Confronto funzionale . . . . . . . . . . . . . . . . . . . . 61

4.2.5 Verifica del funzionamento . . . . . . . . . . . . . . . . . 61

5 Risultati sperimentali 635.1 Test della riconfigurabilita interna . . . . . . . . . . . . . . . . . 63

5.1.1 L’architettura di test . . . . . . . . . . . . . . . . . . . . 64

5.1.2 Riconfigurazione modulare . . . . . . . . . . . . . . . . . 65

5.1.3 Tempi di riconfigurazione . . . . . . . . . . . . . . . . . 69

5.2 Inserimento di MicroBlaze . . . . . . . . . . . . . . . . . . . . . 71

5.2.1 Parte fissa basata su MicroBlaze e riconfigurabilita . . . . 73

5.2.2 Dati di occupazione . . . . . . . . . . . . . . . . . . . . . 75

5.2.3 Prestazioni del bus WISHBONE . . . . . . . . . . . . . . 76

6 Conclusioni e Sviluppi Futuri 81

Bibliografia 86

Elenco delle figure

1.1 Struttura di una CLB . . . . . . . . . . . . . . . . . . . . . . . . 9

1.2 Collegamento dei blocchi logici all’interno di una FPGA . . . . . 10

1.3 Riconfigurazione per colonne, come imposta dalle FPGA prodotte

da Xilinx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.4 Utilizzo di bitstream differenza con transizione diretta tra due

configurazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.5 Utilizzo di bitstream differenza senza transizione diretta tra due

configurazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.1 Struttura di IBM CoreConnect . . . . . . . . . . . . . . . . . . . 19

2.2 Implementazione del bus OPB prevista dallo standard . . . . . . . 21

2.3 Interfaccia esterna di PowerPC 405 . . . . . . . . . . . . . . . . . 24

2.4 Interfaccia esterna di MicroBlaze . . . . . . . . . . . . . . . . . . 27

2.5 Avnet Virtex II - Pro Evaluation Board. In giallo sono messi in

evidenza i piedini da modificare per abilitare la porta ICAP. . . . . 30

2.6 Interfaccia di ISE . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.7 Interfaccia di EDK, con in evidenza la finestra ‘Add/Edit Cores’. . 35

3.1 Struttura generale dell’architettura Caronte . . . . . . . . . . . . . 39

3.2 Struttura dell’architettura YaRA . . . . . . . . . . . . . . . . . . 45

4.1 Il ruolo del controller ICAP . . . . . . . . . . . . . . . . . . . . . 53

4.2 La nuova parte fissa di YaRA dopo l’inserimento dell’ICAP con-

troller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.3 La nuova parte fissa di YaRA, con l’utilizzo di MicroBlaze . . . . 60

ix

5.1 Parte fissa basata su PowerPC vista da FPGA Editor . . . . . . . . 77

5.2 Parte fissa basata su MicroBlaze vista da FPGA Editor . . . . . . 77

5.3 Grafico delle prestazioni del bus WISHBONE . . . . . . . . . . . 79

6.1 Possibile evoluzione di YaRA per l’utilizzo di memorie esterne . . 82

Elenco delle tabelle

4.1 Confronto tre le varie architetture riconfiguarabili proposte . . . . 62

5.1 Dati di occupazione del controller ICAP . . . . . . . . . . . . . . 65

5.2 Tempi di riconfigurazione in funzione della dimensione del bi-

tstream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

5.3 Dati di occupazione relativi alle parti fisse con PowerPC e Micro-

Blaze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.4 Tempi di lettura e scrittura sul bus WISHBONE nel caso di Po-

werPC e MicroBlaze . . . . . . . . . . . . . . . . . . . . . . . . 78

xi

Sommario

L’obiettivo di questo lavoro di tesi e quello di affinare la struttura di YaRA[1],

un’architettura riconfigurabile recentemente definita dal team D.R.E.S.D. (Dy-

namic Reconfigurability in Embedded System Design), operante all’interno del

µLAB, presso il Politecnico di Milano.

YaRA, acronimo di ‘Yet another Reconfigurable Architecture’, opera nell’am-

bito dei sistemi embedded riconfigurabili dinamicamente. Questi sono dei sistemi

elettronici costruiti appositamente per soddisfare una particolare esigenza, e la

riconfigurabilita dinamica permette loro di modificare il proprio comportamento

durante il funzionamento. In questo contesto, YaRA propone una soluzione molto

flessibile, definendo un’infrastruttura di comunicazione tra le parti riconfigurabili

del dispositivo. In questo modo, vengono superati i limiti evidenziati in passa-

to da Caronte, altra architettura sviluppata dal team D.R.E.S.D., che con YaRA

condivide i principi basilari.

Data la sua recente definizione, YaRA lascia aperte le porte ad alcuni possibili

sviluppi, volti a migliorarne le prestazioni e ad aumentarne le funzionalita. Il la-

voro proposto si inserisce in questo filone, e consiste nell’introdurre il processore

MicroBlaze nell’architettura, con l’obiettivo di incrementare sia la portabilita del

sistema, sia la velocita della struttura di comunicazione definita dallo standard.

Inoltre, verra proposta una soluzione che consente a YaRA di effettuare un parti-

colare tipo di riconfigurazione dinamica gia presente in Caronte, che finora non e

stata implementata.

Nel corso del Capitolo 1 verranno introdotte le basi teoriche relative al conte-

sto in cui opera l’architettura YaRA, partendo dalla riconfigurabilita dinamica fino

1

Sommario

a giungere alle FPGA, i dispositivi hardware sui quali verra implementato tutto il

lavoro. All’interno del Capitolo 2 verranno invece fornite tutte le definizioni rela-

tive agli standard ed agli strumenti hardware e software utilizzati. Questi concetti

saranno utili per capire sia le architetture Caronte e YaRA, esposte nel Capitolo3, sia le novita introdotte all’interno della struttura di YaRA, che verranno invece

descritte nel Capitolo 4. Per validare le scelte fatte, nel Capitolo 5 verra proposta

una serie di test, che consistono nell’implementazione fisica di quanto finora de-

scritto, e nella misura di alcuni valori relativi alle prestazioni. Infine, nel corso del

Capitolo 6, verranno tratte le conclusioni basate su considerazioni teoriche e sui

risultati sperimentali, e verranno inoltre offerti alcuni spunti per possibili sviluppi

futuri.

2

Capitolo 1

Riconfigurabilita

Un dispositivo riconfigurabile e caratterizzato dalla possibilita di modificare il

proprio comportamento, in base alle esigenze dell’utente, senza la necessita di

dover essere sostituito.

Lo scopo di questo capitolo e quello di ripercorrere l’evoluzione che ha per-

messo di passare dai circuiti digitali dedicati, ossia realizzati per una specifica

esigenza, alle logiche riconfigurabili. Verranno inoltre analizzate alcune tecniche

implementative per ottenere dei dispositivi riconfigurabili, con particolare atten-

zione per le FPGA, i supporti hardware utilizzati nel corso di questo lavoro. In-

fine saranno introdotti alcuni concetti utilizzati nel proseguo della trattazione, ed

alcune problematiche da considerare quando si fa uso della riconfigurabilita.

1.1 Logiche programmabili

La programmabilita e una tecnica sviluppatasi negli ultimi decenni, parallelamen-

te alla crescente diffusione dell’elettronica nella vita di tutti i giorni. Fino ad

allora, un circuito elettronico era realizzato ad hoc, in modo da poter implemen-

tare una determinata funzione logica. Reti di questo tipo erano per costruzione

poco riutilizzabili, in quanto la loro struttura non poteva adattarsi nemmeno a pic-

cole correzioni apportate al disegno iniziale. La poca flessibilita di questo tipo

di circuiti entro in contrasto con le esigenze della produzione industriale, in cui

3

CAPITOLO 1. RICONFIGURABILITA

venivano richiesti intervalli sempre minori tra la fase di progetto e quella di com-

mercializzazione del prodotto. Ad esempio, un semplice errore riscontrato nella

fase di test imponeva di ridisegnare il circuito e realizzarlo ex novo prima di po-

ter proseguire. Questo ed altri problemi portarono allo sviluppo delle cosiddette

logiche programmabili.

Le logiche programmabili sono dispositivi che permettono al progettista di

descrivere il comportamento di una rete e di implementarla su alcuni componenti

elementari. In questo modo si elimina la necessita di disegnare manualmente il

circuito, riducendo drasticamente i tempi tra il progetto e la realizzazione fisica.

Un circuito puo essere programmato in due modi: a livello software o a livello

hardware.

La programmazione di un dispositivo mediante un software opportuno e una

pratica molto comune, in quanto rappresenta il principio di funzionamento, ad

esempio, dei personal computer. E’ infatti prevista una parte hardware fissa, al-

tamente performante ed in grado di fornire al programmatore un elevato numero

di funzionalita. Mediante la scrittura di un software, che puo essere fisso o essere

sostituito a seconda delle necessita, e possibile ottenere dalla componente hard-

ware un determinato comportamento. Alcuni esponenti di questa categoria sono

gli hard processor[2], che verranno ripresi in seguito.

Architetture di questo tipo hanno pero costi elevati, ed inoltre le funzionalita

offerte dall’hardware risultano eccessive per molte delle applicazioni piu comuni.

Dunque, un circuito costruito ad hoc per una determinata funzione risulta spesso

una soluzione piu praticabile, in quanto questi puo essere ottimizzato per ottenere

prestazioni migliori rispetto ad un hardware generico. Data la loro importanza

all’interno di questa tesi, i sistemi costituiti da una rete hardware programmabile

dall’utente verranno trattate nel dettaglio nel paragrafo successivo.

1.2 Programmazione hardware

Le logiche programmabili a livello hardware mettono a disposizione del proget-

tista un insieme di componenti elementari che, se opportunamente connessi tra

4


loro, permettono di realizzare un determinato comportamento. Tali componenti

elementari possono spaziare da porte che realizzano le piu semplici funzioni lo-

giche (NOT, AND, OR, eccetera) a dispositivi piu complessi quali ad esempio

multiplexer e registri. Si distinguono varie famiglie di logiche programmabili a

livello hardware, classificate in base alla tipologia di programmazione[3].

La prima categoria e quella delle logiche One-Time Programmable, program-

mabili una sola volta prima che il circuito venga messo in funzione. A questa

classe appartengono, ad esempio, le ROM (Read-Only Memory), le PAL (Pro-

grammable Array Logic), nonche le evoluzioni di queste ultime come le PLA

(Programmable Logic Array). Al programmatore viene offerta la possibilita di

realizzare semplici funzioni combinatorie (nel caso delle ROM) o sequenziali (nel

caso delle PAL e delle PLA) agendo sui collegamenti che portano i segnali prima

ad un certo numero di porte AND, poi ad un insieme di porte OR, ed infine ad

alcuni registri. La loro struttura e semplice, e non consente di implementare in

modo efficiente un gran numero di funzioni logiche. Tuttavia, il loro principa-

le limite risiede nel fatto che la programmazione non puo essere modificata nel

tempo.

Le componenti riprogrammabili nascono per sopperire a questi limiti, in quan-

to possono essere ridefinite in base alle necessita. Esempi di questa categoria so-

no le EPROM (Erasable Programmable Read-Only Memory), e le loro evoluzioni

quali le E2PROM (Electrically Erasable Read-Only Memory), in grado di cancel-

lare i collegamenti programmati rispettivamente per mezzo di raggi ultravioletti

ed elettricamente. L’utilizzo delle logiche riprogrammabili e limitato essenzial-

mente da due cause. La prima, in modo similare a quanto avviene nelle One-Time

Programmable, risiede nel numero ridotto di funzioni logiche che possono essere

realizzate in modo efficiente. Il secondo limite consiste nel fatto che la riprogram-

mazione puo essere realizzata solo in una fase in cui il circuito non e in attivita,

rendendo necessaria un’interruzione del servizio durante le modifiche apportate

all’hardware.

L’ultima categoria di logiche programmabili e rappresentata dalle componen-

ti riconfigurabili. Queste possono, al contrario delle precedenti, essere ridefinite

5


senza che il circuito interrompa il proprio funzionamento. In questo modo e pos-

sibile, rispettando alcuni vincoli che verranno approfonditi in seguito, garantire

una continuita del servizio. Un esempio di dispositivi che possono essere ricon-

figurati anche dinamicamente sono le FPGA (Field Programmable Gate Array),

le quali riescono inoltre ad aumentare la complessita delle funzioni implementa-

bili fino a coprire tutte le piu comuni applicazioni. Le FPGA verranno trattate

nel dettaglio in seguito, dopo aver fornito altre definizioni riguardo al concetto di

riconfigurabilita.

1.3 Tecniche di riconfigurabilita

Le varie tecniche di riconfigurabilita esistenti vengono classificate sulla base di

alcune caratteristiche fondamentali. Esse prendono in considerazione le dimen-

sioni della porzione del dispositivo modificata, i tempi in cui queste modifiche

avvengono e la posizione del componete che attiva e gestisce la riconfigurazione.

Queste considerazioni portano alla definizione di termini specifici discriminati da

questi parametri che sono l’oggetto di questa sezione.

1.3.1 Riconfigurabilita statica e dinamica

La differenza fra riconfigurabilita statica e dinamica si basa sul modo in cui il

processo che introduce le modifiche si relaziona con il normale funzionamento

del dispositivo.

Nel caso statico la riconfigurabilita puo avvenire solo dopo aver spento il di-

spositivo. E’ necessario, quindi, interrompere il funzionamento del sistema per

effettuare le modifiche volute, riavviandolo al termine dell’operazione. E’ be-

ne sottolineare che questa e la tecnica che viene utilizzata dai dispositivi ripro-

grammabili descritti nella parte iniziale di questo capitolo. Il principale vantaggio

di questa tecnica e ovviamente la semplicita, che pero la rende allo stesso tem-

po inapplicabile ove si abbia a che fare con sistemi critici o che comunque non

possono permettersi una pausa di questo tipo.

6


Al contrario, nel caso dinamico non e necessario interrompere il funziona-

mento, in quanto si vanno a modificare solamente singole parti del dispositivo,

che puo quindi continuare il suo lavoro utilizzando i moduli non interessati dai

cambiamenti. Questo risolve i problemi di criticita precedenti, ma richiede una

gestione piu complessa, essendo necessario suddividere il sistema in moduli ben

definiti e verificare, prima di apportare qualunque modifica, che si stia per agire

solo su parti inattive.

In seguito, il generico termine ‘riconfigurabilita’ verra sempre utilizzato per

indicare la riconfigurabilita dinamica.

1.3.2 Riconfigurabilita totale e parziale

La distinzione fra riconfigurabilita totale e parziale e legata alle dimensioni mini-

me della parte di dispositivo che puo essere modificata da una singola operazione

di riconfigurazione.

Nella riconfigurabilita totale e necessario ridefinire sempre l’intera area del

dispositivo. Questa tecnica, alquanto semplice, puo essere utilizzata solo nel caso

statico, in quanto non esistono parti immuni dalla ridefinizione che possono quindi

proseguire nel loro funzionamento.

Nella riconfigurabilita parziale e possibile invece modificare singole porzioni

del dispositivo. Dualmente a quanto accade nel caso totale, questa tecnica si abbi-

na quindi maggiormente alla riconfigurabilita dinamica precedentemnte illustrata,

e ne condivide vantaggi e complicazioni.

1.3.3 Riconfigurabilita interna ed esterna

La riconfigurabilita puo essere classificata come esterna o interna in base alla

posizione del dispositivo che effettua la ridefinizione del sistema, o di una parte di

esso. Tale dispositivo prende il nome di RCD (Reconfigurable Controller Driver),

che puo essere implementato sia attraverso un software, sia mediante una rete

hardware.

7


Il caso piu semplice e costituito dai dispositivi riconfigurabili esternamente,

nei quali l’RCD e al di fuori dell’architettura.

Piu interessante e lo scenario della riconfigurabilita interna, in cui l’RCD e

parte architettura e, in base alle necessita, ne puo ordinare la riprogrammazione.

L’RCD puo essere implementato via software, mediante un codice che viene ese-

guito dal sistema, oppure tramite una rete hardware. In quest’ultimo caso, il fatto

che l’RCD sia fisicamente presente in un’area del dispositivo implica che la ricon-

figurabilita puo essere solamente di tipo parziale, in quanto la parte dove esso e

presente non puo essere soggetta a cambiamenti.

1.3.4 Alcuni aspetti critici

Il progetto di un’architettura riconfigurabile richiede una lunga serie di considera-

zioni dovute alla struttura, per definizione modulare, soggetta a precisi vincoli di

temporizzazione. La fase della specifica dei requisiti e del design vero e proprio

esulano dagli argomenti di questa trattazione. Di seguito viene comunque fatto

qualche cenno relativamente ad alcuni aspetti critici.

Una prima problematica relativa al progetto riguarda l’individuazione dei mo-

duli riconfigurabili. Puo non essere infatti evidente una suddivisione delle funzio-

ni che permetta di avere moduli tra loro bilanciati in termini di velocita e spazio

occupato.

Un secondo aspetto progettuale riguarda la temporizzazione. La fase di ricon-

figurazione, a causa dei limiti fisici del dispositivo, non avviene istantaneamente,

ma fa sı che trascorra del tempo dal momento in cui la riconfigurazione ha inizio

al momento in cui il modulo istanziato inizia la computazione.

La scelta di utilizzare moduli molto grandi, capaci di svolgere un gran numero

di operazioni, permetterebbe di limitare il numero di riconfigurazioni richieste,

riducendo quindi i ritardi da esse introdotti. Una soluzione alternativa, votata al

parellelismo, consiste nella scelta di moduli piccoli, frequentemente sostituiti, ma

che possono operare contemporaneamente. Questa seconda opzione permette di

nascondere i tempi morti dovuti alla riconfigurazione, in quanto le numerose parti

del dispositivo non soggette a cambiamenti continuano nel loro lavoro. Al con-

8


trario, utilizzando dei moduli di grosse dimensioni si riduce il numero di opera-

zioni svolte in parallelo, e dunque durante le riconfigurazioni il dispositivo riduce

considerevolmente la quantita di lavoro svolta.

1.4 FPGA

Le FPGA sono dispositivi riconfigurabili che uniscono i pregi della riprogramma-

zione della reta hardware alla possibilita di utilizzare dei veri e propri processori,

sui quali viene eseguito un software opportuno. Inoltre, esse supportano, a se-

conda delle proprie caratteristiche, tutte o parte delle tecniche di riconfigurazione

citate nella sezione precedente.

1.4.1 Struttura

Dal punto di vista hardware[4], una FPGA e una struttura formata da blocchi logici

configurabili (CLB) che possono essere tra loro interconnessi mediante linee di

comunicazione a loro volta programmabili. Ogni CLB e a sua volta costituita da

un parte combinatoria (LUT - Look Up Table) e da una sequenziale (Flip-Flop), e

dunque puo essere utilizzata per realizzare entrambi i tipi di funzione. Lo schema

concettuale e riportato in Figura 1.1.

Le interconnessioni possono essere programmate utilizzando delle strutture

chiamate ‘switch matrix’, delle matrici nelle quali sono realizzati tutti i collega-

menti ammissibili. Tali collegamenti sono inizialmente inattivi, e vengono abi-

litati a seconda delle necessita. Esistono inoltre delle linee che permettono di

raggiungere gli IOB (Input-Output Block), che forniscono alla FPGA un’interfac-

cia verso il mondo esterno. Gli IOB rappresentano la destinazione di tutti i segnali

Figura 1.1: Struttura di una CLB

9


Figura 1.2: Collegamento dei blocchi logici all’interno di una FPGA

che comunicano con dispositivi posti al di fuori della FPGA, nonche di tutti i se-

gnali non instradati correttamente all’interno dell’architettura. La struttura delle

connessioni e rappresentata in Figura 1.2.

Il funzionamento del circuito e, nella maggior parte dei casi, definito median-

te linguaggi di specifica hardware ad alto livello quali VHDL o Verilog. Il codi-

ce prodotto viene poi sintetizzato mediante software forniti, generalmente, dagli

stessi produttori di FPGA. Partendo dalla sintesi si arriva, attraverso varie fasi

successive, ad ottenere il file binario (bitstream, che verranno ripresi in seguito)

necessario per programmare fisicamente il dispositivo.

Dal punto di vista software, invece, le FPGA permettono di eseguire un codice

scritto dall’utente su un processore, nel caso ve ne sia la disponibilita. A seconda

del processore e del tipo di compilatori da questo supportati, il codice puo essere

scritto mediante diversi linguaggi. Tra questi, uno dei piu comuni e l’ ANSI-C.

I processori eventualmente disponibili sulle FPGA possono essere realizzati in

10


due modi distinti. Una prima tipologia, gia citata nel Paragrafo 1.1, e rappresentata

dagli hard processor, costituiti da reti hardware fisse. Alcune FPGA sono in grado

di fornire un processore di questo tipo, integrandolo direttamente sul silicio che

le compone. In questo modo, all’utente viene offerta la possibilita di sfruttare

questo componente mediante l’esecuzione di un software. Un esempio di questa

categoria e il gia citato PowerPC, distribuito da IBM ed installato su alcune FPGA

prodotte da Xilinx, tra cui le Virtex II - Pro. Una seconda tipologia di processori

sono i soft processor, che risultano realizzabili anche su FPGA non equipaggiate

di un hardware dedicato. Essi infatti sono trattati come dei comuni core, e vengono

sintetizzati sulle celle presenti su tutte le FPGA, opportunamente programmate e

collegate tra loro, risultando quindi una soluzione molto comoda e portabile. Un

esempio di soft processor e MicroBlaze, distribuito da Xilinx. Esso riveste un

ruolo centrale all’interno di questa tesi e dunque verra ripreso nel dettaglio nel

corso dei capitoli successivi.

Tramite una FPGA e quindi possibile realizzare un vero e proprio sistema em-

bedded da utilizzare per una specifica applicazione. Inoltre, e possibile realizzare

architetture piu complesse combinando l’azione di piu FPGA. Proprio per questi

motivi esse sono utilizzate, oltre che per i prototipi necessari per le fasi di test,

anche per la realizzazione di prodotti finiti. Ad esempio esse sono comunemente

utilizzate in molti sistemi di controllo, anche complessi, o in schede per PC che

realizzano funzioni specifiche e molto onerose. Ulteriore campo di applizazione

e costituito dai vari tipi di decoder televisivi, in cui viene ricevuto periodicamente

il bitstream necessario per programmarsi e decodificare cosı la trasmissione rice-

vuta. Questo e, tra l’altro, un esempio pratico di utilizzo delle FPGA in maniera

riconfigurabile [5].

1.4.2 FPGA e riconfigurabilita

Le FPGA possono essere utilizzate per realizzare dispositivi che sfruttano la ricon-

figurabilita di tutte o parte delle tipologie citate nei paragrafi precedenti. Alcune

possibilita, infatti, possono essere precluse per limiti costruttivi. E’ il caso, per

citare un esempio, delle FPGA Spartan-3[6] prodotte da Xilinx, che non consen-

11


tono di effettuare una riconfigurazione dinamica interna. Di seguito, tuttavia, si

fara riferimento a dispositivi capaci di realizzare tutte le tecniche descritte, come

avviene nelle FPGA della famiglia Virtex II - Pro, anch’esse prodotte da Xilinx,

utilizzate in questo lavoro. In questo paragrafo verranno dunque riprese le nozioni

introdotte in precedenza e contestualizzate al caso di architetture realizzate su una

o piu FPGA.

Una FPGA permette di realizzare riconfigurabilita sia di tipo statico, sia di

tipo dinamico. Il dispositivo puo infatti essere riprogrammato prima di entrare

in funzione, utilizzando un file binario detto bitstream, capace di ridefinire l’inte-

ra struttura delle CLB. In alternativa, e possibile realizzare una riconfigurazione

dinamica, ridefinendo solo una parte dei blocchi logici utilizzando un particolare

tipo di bitstream, detto ‘bitstream differenza’, in grado di agire anche a dispositivo

funzionante.

In modo del tutto similare, e possibile sfruttare sia una riconfigurazione totale

sia una parziale. La riconfigurazione totale e attuata tramite i bitstream che, co-

me detto, riconfigurano l’intera FPGA, mentre quella parziale fa uso dei bitstream

differenza, che modificano solo la parte interessata. Nel caso di architetture im-

plementete su piu FPGA le due definizioni cambiano leggermente. In quest’ottica

infatti si indica con ‘riconfigurabilita totale’ la contemporanea sostituzione del

contenuto di tutte le FPGA. Al contrario con ‘riconfigurabilita parziale’ si intende

la sostituzione del contenuto di una delle FPGA. E’ raro, al contrario, il caso in cui

si vada a sostituire un singolo modulo di una singola FPGA a causa dell’overhead

di logica di controllo che sarebbe necessario.

E’ bene illustrare alcune problematiche pratiche relative alla geometria delle

aree oggetto di riconfigurazione parziale. Esse, infatti, sono nella maggior parte

dei casi soggette a vincoli posti, per motivi di semplicita, dai costruttori di FP-

GA. In particolare, le FPGA prodotte da Xilinx possono essere riconfigurate per

colonne, come illustrato in Figura 1.3. Occorre quindi organizzare i vari moduli

secondo questo tipo di geometria, impostando opportuni vincoli tramite gli stru-

menti di sintesi. Ovviamente esistono altri produttori che propongono soluzioni

alternative, ad esempio per righe o per rettangoli di dimensioni qualunque.

12


Figura 1.3: Riconfigurazione per colonne, come imposta dalle FPGA prodotte da Xilinx

Alcune FPGA, tra cui degli esemplari prodotti da Xilinx, consentono di rea-

lizzare riconfigurazioni di tipo interno o esterno. Nel caso di riconfigurabilita

interna, di interesse in questo lavoro, l’RCD procede alla ridefinizione dell’ar-

chitettura prelevando i bitstream necessari da una memoria montata sulla scheda.

Tipicamente, tale memoria e esterna alla FPGA, in quanto i bitstream hanno di-

mensioni troppo elevate al confronto della capienza dei blocchi di memoria della

FPGA. Si parla invece di ‘riconfigurabilita esterna’ quando il bitstream viene in-

viato dall’esterno, ad esempio da un PC, e viene utilizzato per riprogrammare il

dispositivo attraverso delle interfacce opportune, diverse da quelle utilizzate nel

caso di riconfigurabilita interna.

Nel caso di architetture implementate su piu FPGA, infine, si parla di ‘ricon-

figurabilita esterna’ nel caso in cui l’RCD si trovi al di fuori di tutte le FPGA

presenti. Tuttavia, in queste architetture e spesso utilizzata una tecnica alternativa

e gerarchica, nella quale un RCD esterno impone la riconfigurazione di una delle

FPGA, la quale a sua volta si occupa della riconfigurazione delle altre.

1.4.3 Bitstream

Tutte le architetture proposte nel proseguo di questa tesi sfruttano una riconfigu-

rabilita di tipo parziale. Questa tecnica, come gia citato in precedenza nel corso

del Paragrafo 1.3, comporta una serie di problematiche, fra le quali e opportuno

citare l’esistenza di un’area non interessata alla riconfigurazione. Questo fa sı che

13


il tradizionale metodo per la programmazione della FPGA debba essere abbando-

nato, e sostituito con una tecnica che permetta di mantenere inalterata una parte di

dispositivo. Di seguito verra approfondito questo aspetto, partendo dal concetto

di bitstream sino ad arrivare a quello di bitstream differenza.

La riconfigurazione puo essere attuata, come gia detto, mediante l’utilizzo dei

bitstream[7]. Un bistream e un file binario capace di programmare l’intera FPGA,

specificando la funzione di tutte le sue CLB e instradando opportunamente le

linee di collegamento. Ad esempio, siano A e B due generiche configurazioni

che possono essere assunte dalla FPGA. Per ciascuna configurazione, esiste un

bitstream (denotato rispettivamente βA per A, e βB per B) capace di implementare

fisicamente tale configurazione. Tuttavia, questa tecnica non si presta ad essere

utilizzata direttamente nel caso di riconfigurabilita parziale, in quanto il bitstream

per definizione riprogramma l’intera FPGA, e non solo una sua porzione. Inoltre,

l’utilizzo del bitstream implica sempre una fase di interruzione del servizio. Per

realizzare una vera riconfigurabilita parziale, dunque, e necessario accantonare il

concetto di bitstream ed introdurre quello di bitstream differenza.

Un bitstream differenza e un flusso di bit che descrive i cambiamenti da attua-

re sulla FPGA per effettuare una transizione tra una configurazione ed un’altra. Il

vantaggio nell’utilizzo dei bitstream differenza risiede nel fatto che solo una parte

della FPGA diventa oggetto di ridefinizione, mentre quella restante puo continua-

re il suo funzionamento. Riprendendo l’esempio precedente, se l’intento e quello

di caricare alternativamente le configurazioni A e B, e sufficiente definire due

bitstream differenza: uno per passare da A a B (detto βA→B), ed uno per il pas-

sare da B ad A (detto βB→A). Con questi strumenti a disposizione, e sufficiente

in una fase iniziale caricare uno dei due moduli con i bitstream βA o βB, e poi

utilizzare i bitsream differenza: la parte comune alle due configurazioni, cosı fa-

cendo, puo proseguire nella sua computazione. In Figura 1.4 e schematizzato il

funzionamento di questi bitstream differenza.

La principale problematica legata ai bitstream differenza e l’occupazione in

memoria. Per una coppia di configurazioni, come si e visto, sono necessari due

bitstream per gestirne la transizione, ma il numero cresce molto rapidamente con

14


il numero di configurazioni. Ad esempio, la presenza di tre moduli richiederebbe

sei bitstream, ma solo l’aggiunta di un quarto modulo porta il numero di bistream

a dodici. Utilizzando architetture complesse, che comprendono cioe una grande

quantita di moduli, lo spazio richiesto per memorizzare tutti i bitstream differenza

diventa troppo elevato, considerando le limitate disponibilita di una FPGA.

Esiste una soluzione che permette di memorizzare un numero di bitstream dop-

pio del numero di configurazioni, che dunque risulta piu conveniente al crescere

del numero di moduli. Un primo bitstream differenza descrive come istanziare

un componente in un’area vuota della FPGA (denotato come β /0→A), mentre un

secondo flusso descrive come rimuoverlo (detto βA→ /0). In questo modo, se fosse

necessario sostituire il componente A con il componente B, si dovrebbe in una pri-

ma fase rimuovere il componente A utilizzando βA→ /0, e successivamente allocare

B nell’area lasciata libera, utilizzando β /0→B. Il numero di operazioni richieste,

come si puo osservare, e doppio rispetto al caso del singolo bitstream differenza

βA→B. In Figura 1.5 e riproposto questa tecnica di riconfigurazione.

I vantaggi procurati in termini di memoria fanno sı che la seconda soluzione

presentata la piu largamente utilizzata. Tuttavia nel corso di questo lavoro, dato

il limitato numero di moduli a disposizione, verra adottata la prima soluzione,

capace tra l’altro di garantire tempi minori per la riconfigurazione.

15


Figura 1.4: Utilizzo di bitstream differenza con transizione diretta tra due configurazioni

Figura 1.5: Utilizzo di bitstream differenza senza transizione diretta tra due configurazioni

16

Capitolo 2

Gli strumenti utilizzati

Il presente capitolo ha lo scopo di introdurre una serie di definizioni, di concetti

e di tool utili a capire meglio il proseguo di questo lavoro di tesi. Verranno per-

tanto presentati i protocolli di comunicazione utilizzati, i processori presenti in

entrambe le architetture, ed i software utilizzati per realizzare fisicamente quanto

descritto.

In primo luogo vengono presentati i bus utilizzati durante il lavoro, la cui

definizione e soggetta a vincoli imposti da standard gia da tempo utilizzati nel-

la progettazione di sistemi embedded. Successivamente vengono descritti l’hard

processor IBM PowerPC ed il soft processor MicroBlaze, sia da un punto di vista

delle funzionalita offerte, sia dal punto di vista dell’interfaccia di comunicazione.

Nella parte finale del capitolo e fornita una panoramica della FPGA e della scheda

utilizzate per il lavoro, nonche degli strumenti software distribuiti da Xilinx per

poterla sfruttare.

2.1 Bus

Le prime definizioni da introdurre riguardano i bus, ovvero dei canali di comuni-

cazione che permettono lo scambio di dati tra due o piu componenti del sistema

(detti anche ‘IP core’ o ‘core’, a seconda che siano o meno protetti da licenza, an-

che se nel proseguo della trattazione si fara uso del solo termine ‘core’ per indicare

17

CAPITOLO 2. GLI STRUMENTI UTILIZZATI

entrambi) presenti nell’architettura. La scelta del tipo di collegamento, infatti, puo

sia influenzare il tipo di core che possono essere connessi, sia la dimensione finale

di un’architettura. I diversi bus differiscono tra loro per la dimensione dei dati tra-

sportati e per il protocollo di comunicazione, che influenzano il numero di segnali

utilizzati.

Il primo standard di collegamento presentato e l’IBM CoreConnect, che e alla

base di tutte le architetture fondate su PowerPC e MicroBlaze. Di conseguenza, i

bus previsti da tale standard saranno molto ricorrenti all’interno della trattazione.

Successivamente viene descritto lo standard WISHBONE, che definisce il bus che

ha rappresentato l’evoluzione tra l’architettura Caronte e l’architettura YaRA.

2.1.1 IBM CoreConnect

CoreConnect e uno standard semplice e versatile ideato da IBM[8], e fornisce

tutti i mezzi per realizzare un’architettura comprendente un processore ed una

serie di periferiche. Lo standard e utilizzato da un gran numero di processori e

di core esistenti, che dunque possono essere facilmente sostituiti tra loro senza

modificare l’infrastruttura di comunicazione.

IBM CoreConnect, il cui schema e riportato in Figura 2.1, prevede quattro

elementi fondamentali, che verranno di seguito descritti nel dettaglio.

• Processor Local Bus (PLB)Il bus PLB[9] e caratterizzato da una ampiezza elevata e da basse latenze,

e dunque risulta adatto per la connessione di tutti i core altamente perfor-

manti, tra cui il processore. Le alte prestazioni sono dovute a diversi fattori,

tra cui la scelta di utilizzare due linee separate per i dati in lettura ed in

scrittura, che permette il trasferimento di due blocchi di dati per ogni ciclo.

Esistono diverse implementazioni che differiscono per il numero di bit che

compongono le linee di comunicazione, e che arrivano a proporre 64 bit per

gli indirizzi e 128 bit per i dati. Il PLB e un bus sincrono, in quanto esiste

un segnale di clock comune a tutti i core collegati che prende il nome di

SYS PLBCLK. Inoltre, il bus e arbitrato, e dunque e possibile che diverse

18


Figura 2.1: Struttura di IBM CoreConnect

periferiche (fino ad un limite di 16) possano agire da master sul bus. L’ar-

bitro e un core fornito direttamente da IBM, ed ha una struttura flessibile

che permette all’utente di definire diversi schemi di priorita. Tipicamente,

il processore possiede due interfacce master per accedere separatamente ai

dati ed alle istruzioni, ma possono esistere altre periferiche che fungono da

master, come quelle che operano in DMA1.

• On-chip Peripheral Bus (OPB)Il bus OPB[10] e progettato per la connessione di periferiche piu lente, e ti-

picamente non viene utilizzato per la connessione del processore, anche se

questo caso non e escluso. Ha un’ampiezza piu limitata del PLB, in quanto

prevede indirizzi fino a 64 bit e dati da 32 o 64 bit, e non prevede due tra-

sferimenti contemporanei di dati nello stesso ciclo di clock. Tuttavia, fatto

salvo per queste soluzioni che ottimizzano le prestazioni, il protocollo di co-

munizione sul bus OPB e simile a quello previsto per il PLB. Inoltre, anche

OPB e un bus sincrono, ed anche in questo caso e previsto un arbitro di-

stribuito da IBM. La necessita di mantenere i due bus separati, dunque, non

1Il Direct Memory Access (DMA) e una tecnica per trasferire dei dati tra due periferiche senzacoinvolgere il processore.

19


nasce tanto da grandi differenze strutturali, quanto dalla volonta di riservare

il traffico su PLB per alcune periferiche ‘privilegiate’.

• Bridge OPB-PLBI bus PLB ed OPB comunicano attraverso un bridge bidirezionale, anch’es-

so fornito da IBM. Il bridge da PLB ad OPB possiede un’interfaccia slave

sul lato connesso al PLB, agendo invece da master su OPB. Tale dispositivo

permette il trasferimento di dati tra le periferiche connesse come master al

PLB e quelle connesse come slave all’OBP. Dualmente, il bridge da OPB a

PLB, che talvolta puo essere omesso, possiede un’interfaccia slave su OPB

e master su PLB. Questi garantisce un trasferimento di dati tra le periferiche

che agiscono da master su OPB e quelle che operano da slave su PLB.

• Device Control Register (DCR) BusIl bus DCR[11] e utilizzato per accedere direttamente ai registri di stato e di

controllo delle periferiche connesse, il cui contenuto viene trasferito senza

passare attraverso il bus OPB e, soprattutto, il piu efficiente PLB. Al DCR

possono essere connesse periferiche interfacciate sia all’OPB sia al PLB,

in quanto il funzionamento del DCR avviene parallelamente a quello degli

altri due. Da un punto di vista implementativo, il DCR bus e un bus sincrono

con un numero di bit compreso tra 10 e 32 per gli indirizzi, e con 32 bit per

i dati.

Aspetti implementativi Tornando al bus OPB, e bene soffermarsi sulla sua

implementazione fisica, che e univocamente fissata dallo standard. Come si puo

osservare dalla Figura 2.2, tratta dalla documentazione ufficiale di IBM[10], per

ogni periferica connessa all’OPB vengono replicati tutti i segnali previsti dall’in-

terfaccia, sia essa di tipo master o di tipo slave. Questo fatto implica che per ogni

nuovo core connesso al bus debbano essere generate un certo numero di linee, che

tendono ad appesantire il sistema al crescere del numero di periferiche. Questo

aspetto e ancora piu rilevante nel caso in cui esista un limite fisico al numero di

linee istanziabili, come avviene nelle architetture utilizzate in questo lavoro, in cui

20


i bus sono realizzati su piani di silicio separati, dotati di risorse particolarmente

ridotte.

Questo limite implementativo verra ripreso nel corso del Capitolo 3, in quan-

to rappresenta la principale evoluzione dall’architettura Caronte all’architettura

YaRA. Per la realizzazione di quest’ultima, infatti, si e scelto un bus dotato di

una struttura organizzata diversamente, che prende il nome di WISHBONE, e che

viene descritto nel paragrafo successivo.

Figura 2.2: Implementazione del bus OPB prevista dallo standard

21


2.1.2 WISHBONE

Il bus WISHBONE[12] e uno standard con licenza gratuita progettato da Silicore

e adottato da OpenCores.org, la cui caratteristica peculiare e la semplicita. Per

implementare l’interfaccia WISHBONE, infatti, ad un core e richiesto un numero

ridotto di porte logiche, ed e permessa una decodifica parziale degli indirizzi, per

non appesantire i core con la logica ridondante. Il bus e sincrono ed ha un’ampiez-

za variabile, in quanto la dimensione dei dati trasportati non e soggetta a vincoli

imposti dallo standard. E’ permessa inoltre la presenza di piu master in contem-

poranea ma, a differenza di quanto accade per CoreConnect, l’arbitro deve essere

realizzato dall’utente. Infine, l’implementazione del bus non e soggetta a vincoli,

e dunque risulta piu flessibile rispetto ad OPB.

Il bus WISHBONE puo essere interfacciato al bus OPB mediante un apposi-

to bridge bidirezionale, sviluppato nell’ambito del progetto D.R.E.S.D.2 [1]. La

prima componente del bridge, che funge da ponte da OPB a WISHBONE, ha

un’interfaccia slave su OPB, ed agisce da master su WISHBONE. La seconda

componente, che rappresenta il bridge da WISHBONE ad OPB, e dotato di in-

terfaccia slave su WISHBONE e di interfaccia master su OPB. Dal momento che

nelle architetture sviluppate all’interno di D.R.E.S.D. non e ancora stato definito

un arbitro su WISHBONE, il bridge da OPB a WISHBONE rappresenta l’unico

master che puo essere collegato a tale bus.

2.2 PowerPC

Il primo processore trattato in questo capitolo e PowerPC, in quanto tale proces-

sore e stato alla base dell’architettura Caronte, ed e stato riproposto dalla prima

implementazione dell’architettura YaRA. Di seguito ne verra fornita una descri-

zione che vuole mettere in luce sia le funzionalita presenti nel processore, sia la

complessa struttura IBM CoreConnect alla quale PowerPC e collegato.

2D.R.E.S.D. (Dynamic Reconfigurability in Embedded System Design), e un’area di ricercadel Laboratorio di Microarchitetture presso il Politecnico di Milano.

22


2.2.1 Caratteristiche

PowerPC[13] e uno standard di hard processor realizzato agli inizi degli Anni

Novanta da Apple, IBM e Motorola, come esponende di spicco dell’architettura

POWER di IBM. POWER, che sta per ‘Performance Optimization With Enhanced

RISC’, e una famiglia di processori RISC, che dunque offrono un set di istruzioni

ridotto ma capace di far ottenere ottime prestazioni in termini di frequenze di

lavoro.

Tra le varie implementazioni esistenti della specifica PowerPC, si fara ora rife-

rimento a PowerPC 405. Questi e un processore realizzato direttamente sul silicio

di alcune FPGA, comprese quelle utilizzate nel corso di questa tesi. Tuttavia, l’u-

tilizzo di questo processore non e limitato alle sole FPGA, ma arriva anche, ad

esempio, nella telefonia cellulare e nelle videocamere digitali[14]

PowerPC 405[15] e, come da specifica, un processore RISC a 32 bit, capace

di raggiungere performance elevate quantificabili con frequenze di lavoro fino

a 400Mhz e 608 milioni di istruzioni eseguite per secondo. Tali prestazioni si

ottengono grazie alla presenza di una pipeline a cinque stadi, di trentadue registri

da 32 bit, nonche di un moltiplicatore e di un divisore hardware. E’ supportato

anche l’eventuale utilizzo di una FPU (Floating-Point Unit) esterna, per effettuare

i calcoli in virgola mobile.

Dal punto di vista della memoria, PowerPC 405 prevede l’utilizzo di due cache

separate per dati ed istruzioni, al fine di ottimizzare le prestazioni. E’ prevista an-

che un’unita MMU (Memory Management Unit) per la traduzione degli indirizzi

di memoria logici in indirizzi fisici, con una dimensione delle pagine variabile.

Tra le altre caratteristiche di rilievo, infine, vanno citate la presenza di un’u-

nita di supporto per le operazioni di debug (Debug Support Unit, DSU), e un

registro da 64 bit utilizzato come timer. Quest’ultimo registro, come verra spie-

gato nel corso della fase di test, consente tra l’altro di misurare le prestazioni del

funzionamento del sistema durante la fase di riconfigurazione.

Per quanto riguarda la programmazione, PowerPC 405 e in grado di utilizzare

l’intero set di istruzioni previsto dallo standard PowerPC. Grazie a questo fatto

e possibile utilizzare diversi sistemi operativi e compilatori. Con questi ultimi

23


Figura 2.3: Interfaccia esterna di PowerPC 405

l’utente puo scrivere il proprio codice con linguaggi di uso comune quali ANSI-C

e C++.

2.2.2 Interfaccia esterna

L’interfaccia esterna di PowerPC 405, riportata in Figura 2.3, e fedele allo stan-

dard IBM CoreConnect per quanto riguarda la connessione ai bus, e prevede inol-

tre la possibilita di collegare dei core aggiuntivi per incrementare le performance

del processore.

Le prime tre interfacce a cui si fa cenno servono per collegare all’hard pro-

cessor una Auxiliary Processor Unit (APU) o una Floating Point Unit (FPU), un

External Interrupt Controller (EIC), ed infine un’interfaccia per il debug. Come

gia accennato in precedenza, infatti, nell’architettura interna al processone non e

prevista la presenza di un’unita per i calcoli in virgola mobile, ma questa puo esse-

24


re effettuata da un hardware dedicato (detto, appunto, FPU), interfacciato al pro-

cessore tramite un canale privilegiato. Altre funzionalita possono essere aggiunte

da un’unita ausiliaria, detta APU. Tutte queste nuove componenti affiancate al

processore permettono di incrementare il set di istruzioni, introducendo un certo

numero di comandi non previsti dallo standard PowerPC. L’aggiunta dell’EIC, al

contrario, non si riflette sull’istruction set, ma permette di raccogliere i sengnali di

interrupt provenienti dall’esterno. Per concludere, esiste un’interfaccia per il sup-

porto del debug che comprende, al suo interno, l’interfaccia JTAG, molto usata

anche per programmare le FPGA.

Il PowerPC 405 prevede un’interfaccia per la comunicazione compatibile con

lo standard IBM CoreConnect. Sono previsti quindi due collegamenti ai bus PLB

e DCR, mentre non esiste la possibilita di un allacciamento diretto all’OPB, che

e invece accessibile solo attraverso l’uso di un bridge. Appare chiaro che questa

struttura tende a penalizzare l’utilizzo del bus WISHBONE, per il quale e previsto

un bridge collegato all’OPB. Per accedere a WISHBONE, dunque, il processore

deve passare attraverso tre linee diverse che, pur lavorando spesso alla stessa fre-

quenza, tendono ad aumentare i cicli richiesti per la lettura e la scrittura. Un test

per dimostrare questo fenomeno verra presentato nei capitoli successivi.

2.3 MicroBlaze

Dopo aver introdotto le caratteristiche peculiari di PowerPC, l’attenzione si spo-

sta ora su MicroBlaze, al fine di comprendere i vantaggi che questi puo garantire

all’interno dell’architettura YaRA. A livello introduttivo, si puo gia comprendere

come MicroBlaze rappresenti una soluzione piu portabile di PowerPC, in quanto

si tratta di un soft processor, che dunque puo essere implementato sulle compo-

nenti elementari della FPGA, senza bisogno di essere realizzato sul silicio. Di

seguito verranno analizzate le caratteristiche di MicroBlaze, in termini di funzio-

nalita e di interfacce esterne, per confrontarle con quelle precedentemente esporte

per PowerPC.

25


2.3.1 Caratteristiche

MicroBlaze[16] e un soft processor di tipo RISC a 32 bit, prodotto da Xilinx ed

ottimizzato per le FPGA della medesima casa produttrice. L’inserimento di que-

sto core all’interno di un sistema embedded e immediato utilizzando un software

fornito proprio da Xilinx, chiamato EDK, che verra descritto in seguito.

Il principale pregio di MicroBlaze risiede nella sua configurabilita: non essen-

do infatti implementato nel silicio, e possibile definirne alcuni parametri prima di

sintetizzarlo. Esistono tuttavia alcune caratteristiche che non e possibile persona-

lizzare. Tra queste, vale la pena citare il numero di registri a 32 bit presenti, che e

pari a trentadue, come nel caso del PowerPC. Come il PowerPC, anche il Micro-

Blaze utilizza una pipeline che risulta pero limitata al semplice parallelismo delle

tre operazioni fondamentali: fetch, decode ed execute. Questo particolare, unito

al fatto che le performance sono strettamente legate alla FPGA su cui avviene la

sintesi, fa sı che la massima frequenza di funzionamento di MicroBlaze sia quan-

tificabile a circa 150MHz e 138 milioni di operazioni al secondo su una Virtex II

- Pro, simile a quella utilizzata nel corso di questa tesi.

MicroBlaze, in analogia con quanto accade con PowerPC, prevede due me-

morie cache separate per dati ed istruzioni3, che in questo caso sono opzionali.

Non e prevista, almeno fino all’attuale versione 4.00a del soft processor, la pre-

senza della MMU. Tuttavia, come verra approfondito piu avanti MicroBlaze e in

grado di ottimizzare le prestazioni della cache interfacciandosi ad un bus molto

performante prodotto da Xilinx, detto ‘CacheLink’.

Tra le altre funzionalita offerte da MicroBlaze, la cui presenza e sempre la-

sciata alla volonta dell’utente, vi sono un moltiplicatore e un divisore hardware,

un’unita per la gestione delle eccezioni, ed il supporto per il debug. Inoltre, esiste

la possibilita di collegare una FPU per i calcoli in virgola mobile.

In modo simile a quanto accade per PowerPC, anche MicroBlaze puo essere

programmato usando linguaggi comuni quali ANSI-C e C++. Xilinx stessa ha

3Spesso in letteratura si fa riferimento a questo tipo di memoria cache con il nome di ‘HarvardArchitecture’.

26


Figura 2.4: Interfaccia esterna di MicroBlaze

fornito una versione del compilatore gcc con la quale e possibile compilare il

codice sorgente affinche venga eseguito dal soft processor.

In conclusione, e possibile osservare come MicroBlaze paghi rispetto a Power-

PC in termini di prestazioni massime ottenibili. In generale, pero, le funzionalita

offerte dai due processori sono molto simili, e da questo punto di vista il soft pro-

cessor presenta l’indubbio vantaggio di poter essere personalizzato escludendo le

componenti che resterebbero comunque inutilizzate. In questo modo e possibile

ridurre l’impatto di MicroBlaze sull’occupazione dell’architettura complessiva..

PowerPC, al contrario, ha un’occupazione fissa e non modificabile.

2.3.2 Interfaccia esterna

Le interfacce di MicroBlaze, riportate in Figura 2.4, prevedono da una parte un

collegamento con tutte le unita opzionali descritte nel sottoparagrafo precedente,

e dall’altra un collegamento ai bus esterni. Quest’ultimo e classificabile sotto

lo standard IBM CoreConnect, tuttavia presenta alcune fondamentali differenze

rispetto all’interfaccia presentata da PowerPC.

In MicroBlaze non e piu prevista la presenza del bus PLB, mentre esiste un’in-

27


terfaccia che permette al soft processor di comunicare direttamente con il bus

OPB. Questa scelta deriva dal fatto che per l’accesso a dati ed istruzioni vengono

utilizzati delle soluzioni progettate dalla stessa Xilinx, ed ottimizzate per l’utiliz-

zo con MicroBlaze. Il bus LMB (Local Memory Bus), infatti, permette la lettura

in un tempo pari ad un ciclo di clock, dei dati e delle istruzioni presenti sulla me-

moria della FPGA, ossia sulle BRAM. Come gia detto, l’interfaccia verso LMB

e duplice: da un lato, ILMB e utilizzato per l’accesso alle istruzioni, dall’altro

DLMB e utilizzato per l’accesso ai dati. E’ comunque possibile escludere il bus

LMB e memorizzare dati ed istruzioni su una memoria interfacciata al bus OPB,

al quale MicroBlaze accede tramite due interfacce: DOPB per i dati, e IOPB per

le istruzioni.

Altre soluzioni previste nello specifico per MicroBlaze sono i bus XCL (Xi-

linx CacheLink) ed FSL (Fast Simplex Link). XCL e un’ulteriore interfaccia per

l’accesso alla memoria, qualora si volesse accedere a dati ed istruzioni senza uti-

lizzare LMB o OPB. Anche in questo caso l’interfaccia e duplice, ma l’utilizzo e

tipicamente limitato a memorie esterne che adottano specificatamente questo tipo

di trasferimento. FSL[17] rappresenta invece l’alternativa al DCR bus, in quanto

realizza un collegamento diretto tra un registro del processore ed un core presente

sulla FPGA, trasferendo un dato in due cicli di clock.

Come si puo osservare, un’architettura basata su MicroBlaze risulta essere piu

duttile di una basata su PowerPC. Esistono infatti un numero maggiore di solu-

zioni per accedere alla memoria, ed inoltre l’accesso ad OPB non deve sottostare

al passaggio per il bridge da PLB ad OPB. Nell’ottica dell’utilizzo del bus WI-

SHBONE, questo fatto si traduce nella potenziale riduzione dei tempi di accesso

allo stesso WISHBONE, in quanto viene eliminato il passaggio intermedio sul bus

PLB.

2.4 Strumenti per implementazione e test

In questo paragrafo vengono descritti gli strumenti utilizzati nelle fasi di imple-

mentazione e di test.

28


In primo luogo, viene introdotta la FPGA sulla quale sono state sintetizzate le

architetture descritte: una Virtex II - Pro VP7 prodotta da Xilinx. Tale disposi-

tivo ha la peculiarita di integrare un processore PowerPC che, come detto, viene

realizzato direttamente sul silicio della FPGA.

Successivamente vengono descritti i software utilizzati, la cui scelta e diretta

conseguenza della decisione di utilizzare una FPGA prodotta da Xilinx. Il soft-

ware, infatti, e distribuito dalla stessa casa, ed e principalmente costituito da due

componenti: Integrated Software Enviroment (ISE) ed Embedded Development

Kit (EDK).

2.4.1 Avnet Virtex II - Pro Evaluation Board

Tutti i test effettuati durante il lavoro verranno svolti su una FPGA prodotta da Xi-

linx, appartenente alla famiglia delle Virtex II - Pro, chiamata VP7. La VP7xc2vp7

e un dispositivo di piccole dimensioni, costituito da una matrice di 4928 CLB, da

un processore PowerPC 405 e da 44 moltiplicatori hardware di dimensione 16x16.

Inoltre, sono presenti 99 kByte di memoria su scheda (BRAM), quattro blocchi

per il controllo digitare del segnale di clock (Digital Clock Management, DCM),

e 396 Input/Output Block.

La FPGA e inserita in una board che le fornisce un’alimentazione stabile, un

segnale di clock, ed una serie di interfacce per la comunicazione esterna. La board

scelta per il lavoro, illustrata in Figura 2.5, e la Virtex II - Pro Evaluation Board

prodotta da Avnet, che monta una VP7 con package ff896 e uno speedgrade -5.

Le periferiche esterne alla FPGA montate sulla board servono per estendere la

capacita della memoria, tramite moduli flash, DDR e SDRAM, o per le comu-

nicazioni, come nel caso dei LED e dell’interfaccia seriale RS232. Esiste inol-

tre la possibilita di programmare la FPGA dall’esterno, utilizzando un’interfaccia

JTAG.

La VP7, come tutte le FPGA della famiglia Virtex II e Virtex II - Pro, offre

inoltre una particolare porta interna che riveste una notevole importanza: l’In-

ternal Configuration Access Port (ICAP). Tale porta permette al processore del

sistema realizzato sulla FPGA di agire sulla programmazione della stessa, ed

29


Figura 2.5: Avnet Virtex II - Pro Evaluation Board. In giallo sono messi in evidenza ipiedini da modificare per abilitare la porta ICAP.

eventualmente di modificarla. In particolare, il processore puo andare a leggere

la configurazione dell’FPGA operando su una porzione minima di dati chiama-

ta ‘frame’. Allo stesso modo puo scrivere una nuova configurazione trasferendo

sempre un frame alla volta. L’ICAP, sara utilizzato, in questo lavoro, per effettuare

una riconfigurazione dinamica, interna e parziale delle FPGA. Per poter funzio-

nare all’interno di un’architettura, l’ICAP deve essere corredato di un apposito

controller interfacciato ad uno dei bus (tipicamente il PLB), dal quale riceve i

bitstream differenza per effettuare la riconfigurazione. Il funzionamento di tale

controller verra ripreso nel corso dei capitoli successivi. E’ bene sottolineare, da

un punto di vista pratico, che per abilitare la porta ICAP e necessario assicurarsi

che disposizione dei piedini di configurazione M2:M0 della scheda (messi in evi-

denza in Figura 2.5) non corrisponda alla configurazione 101. Tale disposizione

dei pin, normalmente presente, seleziona JTAG o ‘Boundary Scan’ come unica

modalita di riconfigurazione, mentre un diverso posizionamento consente anche

l’uso della porta ICAP, pur non esludendo JTAG.

30


Figura 2.6: Interfaccia di ISE

2.4.2 ISE

Integrated Software Enviroment (ISE) e un insieme di strumenti che permettono

di sintetizzare componente hardware, partendo dalla stesura della sua descrizio-

ne con un linguaggio di alto livello quale VHDL o Verilog, fino a giungere al

download del bistream su scheda. ISE e un software prodotto da Xilinx, e di con-

seguenza la sintesi e ottimizzata per le FPGA prodotte dalla medesima casa. La

versione utilizzata durante il lavoro e la 7.1i, aggiornata con il Service Pack 4.

ISE comprende una serie di processi capaci di eseguire una particolare fase

della sintesi, a partire dalla verifica della sintassi del codice fino ad arrivare alla

generazione del bitstream. L’interfaccia principale del software e detta Project

Navigator, rappresentata in Figura 2.6, che permette di gestire tutte queste fasi.

Tale interfaccia e composta da quattro parti principali, che verranno in seguito

descritte nel dettaglio. In alternativa, e possibile eseguire tutte le fasi tramite una

riga di comando, il che permette di eseguire tutto il flusso di programmazione

senza ricorrere all’interfaccia grafica.

La prima componente di Project Navigator ha proprio il fine di emulare i ri-

sultati che si otterrebbero da riga di comando, ed e detta consolle (contrassegnata

31


con il numero ‘1’ in Figura 2.6). La consolle e quella porzione di interfaccia in

cui vengono riportati i risultati dettagliati di tutte le fasi dei processi. L’utilita di

questa finestra emerge nella fase di debugging, in quanto e possibile identificare

con precisione dove risiede un eventuale errore. In generale, tutto cio che viene

stampato sulla consolle puo essere comunque ritrovato nei file di Log creati da

ISE.

L’editor (corrispondente al numero ‘2’ in Figura 2.6) e la parte di Project Na-

vigator in cui e possibile modificare i file testuali e visualizzare i report generati

dalla sintesi in formato HTML. I file di testo permettono sia di descrivere l’hard-

ware tramite i linguaggi di alto livello, sia di fissare dei vincoli come quelli relativi

alle aree di FPGA in cui puo essere allocato il componente (dette ‘user constrain-

ts’). I report, che vengono visualizzati nella stessa finestra, consentono di ottenere

diverse informazioni, ad esempio la stima delle risorse occupate e della frequenza

di funzionamento del sistema.

L’albero dei sorgenti (vedi la parte ‘3’ in figura 2.6) e la parte di Project Na-

vigator in cui sono contenuti tutti i file correlati con il progetto, gia disposti con

un’organizzazione gerarchica.

Il menu delle funzioni (contrassegnato con il numero ‘4’ in Figura 2.6), infi-

ne, e l’elemento piu importante, perche permette di accedere a tutte le fasi della

sintesi. Per facilitare la navigazione, le funzioni sono raggruppate nelle cinque

categorie a cui si fa cenno di seguito.

Il primo gruppo prende il nome di ‘Design Entry Utilities’ e permette di creare

un template, ossia un file testuale contenente un componente VHDL. Il template

puo essere utilizzato come top-level dell’architettura o puo essere interfacciato ad

altri moduli. In questa sezione, inoltre, e possibile effettuare una simulazione del

componente utilizzando strumenti quali ModelSim4, lasciando ad ISE il compito

di settare tutti i parametri per compiere un’analisi completa.

Il secondo gruppo e chiamato ‘User Constraints’, e consente di indicare allo

strumento di sintesi la posizione e la funzione dei pin della FPGA, nonche i vincoli

4ModelSim e un software prodotto dalla Mentor Graphics Corporation, che permette di simu-lare il comportamento di un componente a partire dalla sua descrizione VHDL e dal valore assuntoda alcuni segnali del sistema.

32


spaziali e temporali che dovranno essere rispettati nei passi successivi. Queste

informazioni vengono salvate in un file chiamato UCF, che puo essere modificato

utilizzando qualsiasi editor di testo.

Il terzo raggruppamento prende il nome di ‘Synthesize-XST’, ed e il primo

che processa la descrizione con il linguaggio di alto livello. In una fase iniziale,

viene verificata la sintassi del codice VHDL. Se questa risulta corretta, nella fase

successiva la descrizione viene sintetizzata, producendo in uscita una rete hard-

ware formata da porte logiche ed opportune interconnessioni. Il file in uscita da

questa sezione prende il nome di NGC e, come si vedra in seguito, allo stesso

risultato si puo pervenire usando EDK. La sintesi avviene utilizzando il Xilinx

Synthesize Tool (XST) o uno strumento equivalente, in quanto la rete prodotta e

ancora indipendente dalla specifica FPGA.

La quarta sezione, ‘Implement Design’, si occupa di mappare il risultato del-

la fase precedente sulla specifica scheda selezionata. Questo significa tradurre le

porte logiche programmando opportunamente le CLB, con un processo chiamato

‘Map’. In un secondo momento, con la fase di ‘Place’ i blocchi di CLB generati

vengono collocati in un’area della FPGA che rispetti i vincoli gia definiti dall’u-

tente. Infine, i vari moduli vengono interconnessi programmando opportunamente

le linee di instradamento, in un processo chiamato ‘Route’.

La quinta ed ultima sezione, ‘Generate Programming File’, permette di ge-

nerare il bitstream per configurare la FPGA. E’ inoltre possibile richiamare un

software capace di inviare il bitstream alla FPGA, chiamato iMPACT e prodotto

dalla stessa Xilinx.

Piu nel dettaglio, iMPACT e un software in grado di riprogrammare una FP-

GA sia staticamente sia dinamicamente, qualora riconoscesse di lavorare con un

bitstream o un bistream differenza. Tuttavia, dal momento che il software e ese-

guito da un comume personal computer, l’unico tipo di riconfigurazione ottenibile

e quella esterna. Per operare una riconfigurazione interna e necessario scaricare i

bitstream sulla FPGA ed utilizzare, ad esempio, la porta ICAP.

Altro strumento di particolare rilevanza in questo lavoro risulta essere FPGA

Editor, un software incluso nella suite ISE. Questo programma e in grado di for-

33


nire un’anteprima dell’architettura realizzata su FPGA, mostrando esattamente

tutte le linee di collegamento, tutte le slice utilizzate, con un livello di dettaglio

capace di arrivare a mostrare i singoli multiplexer o le singole porte logiche. E’

inoltre possibile, accedendo al design originale con permessi di lettura e scrit-

tura, modificarne alcune parti. Questo aspetto risulta particolarmente rilevante

quando e necessario realizzare dei bitstream differenza di dimensioni limitate: in

questo caso, infatti, e sufficiente modificare un numero ristretto di porte o segna-

li sull’architettura originale, ottenendo due file che differiscono solo per pochi

frames.

2.4.3 EDK

Embedded Development Kit (EDK) e un software prodotto da Xilinx che lavora ad

un livello di astrazione piu alto rispetto ad ISE. Questi, infatti, permette di definire

un’architettura a partire da un insieme di core predefiniti o realizzati dall’utente,

attorno ai quali viene definita una rete di collegamenti. Una volta definita, tale ar-

chitettura puo essere sintetizzata fino ad ottenere un bitstream, oppure puo essere

esportata verso ISE, nella quale viene trattata come un componente tradizionale.

Il processo di generazione del bitstream di EDK e basato su XST, e dunque segue

tutti i passaggi gia citati per ISE. L’interfaccia di EDK e riportata in Figura 2.7.

Come si e detto, EDK non lavora al livello di codice VHDL, ma ha come

componente elementare il core (l’elenco dei core nell’architettura sono elencati in

un’area dell’interfaccia di EDK indicata con il numero ‘1’ all’interno della Figu-

ra 2.7). I core definiti dall’utente possono essere importati in EDK attraverso un

programma esterno, chiamato ‘Create/Import Peripheral’. Questi permette all’u-

tente di scegliere il tipo di interfaccia che la periferica deve avere (per esempio,

l’interfaccia slave su OPB), e crea un IPIF, ossia un template scritto in VHDL nel

quale sono presenti i segnali dell’interfaccia e le funzioni piu comuni, come la de-

codifica degli indirizzi. All’interno degli IPIF l’utente puo definire la ‘user logic’,

ovvero la parte di logica specifica di quel componente.

La definizione dell’architettura, una volta importati tutti i core necessari, av-

viene attraverso la finestra ‘Add/Edit Cores’ (messa in evidenza con il numero

34


Figura 2.7: Interfaccia di EDK, con in evidenza la finestra ‘Add/Edit Cores’.

‘2’ in Figura 2.7. Con questo strumento, ogni periferica aggiunta viene collega-

ta ad uno dei bus attraverso l’interfaccia corretta, i sengali in ingresso ed uscita

da essa vengono opportunamente instradati, ed infine le viene assegnato un in-

dirizzo. Tutte queste modifiche vanno a modificare un file, chiamato MHS, nel

quale e presente una descrizione completa di tutti i core e di tutti i parametri che

li caratterizzano.

EDK permette anche lo sviluppo del software che verra eseguito dal proces-

sore inserito nell’architettura, in modo da ottenere un vero e proprio sistema em-

bedded. L’ambiente di sviluppo e basato sul linguaggio ANSI-C, che puo essere

poi trattato da un compilatore predefinito (detto gcc), oppure da un compilato-

re qualsiasi scelto dal programmatore. Una volta compilati i sorgenti, EDK e in

grado di modificare il bitstream dell’architettura in modo che le BRAM vengano

inizializzate con il codice utente.

E’ importante sottolineare come il flusso di sintesi di un’architettura generata

con EDK sia lo stesso utilizzato da ISE. Questo fatto riveste particolare importan-

za parlando di Caronte e YaRA, la cui sintesi avviene invocando delle primitive di

XST mediante riga di comando. La perfetta compatibilita tra EDK ed ISE garanti-

35


sce quindi che le varie parti delle due architetture possano essere sviluppate indif-

ferentemente con uno dei due software, senza che questo vada a compromettere il

buon esito del flusso di sintesi.

2.5 Conclusioni

Le strutture di comunicazione ed i processori introdotti in questo capitolo costi-

tuiscono la base per comprendere le due architetture riconfigurabili che verranno

descritte nel proseguo di questa tesi. Tali architetture, chiamate Caronte e Ya-

RA, sono state infatti costruite a partire da standard gia largamente diffusi. In

questo modo, per lavorare con esse, non saranno richieste conoscenze particolar-

mete nuove,e nemmeno l’utilizzo di flussi di lavoro diversi da quelli normalmente

utilizzati dagli sviluppatori hardware.

Da un punto di vista implementativo, si e scelto di utilizzare gli strumenti

hardware e software forniti da Xilinx, il maggiore produttore mondiale di FP-

GA. Questa scelta si puo spiegare, di nuovo, con il desiderio di garantire alle

architetture la maggior diffusione possibile.

I concetti qui esposti saranno inoltre utili anche per comprendere le modifiche

introdotte all’interno di YaRA ed i test svolti a riguardo, per i quali si rimanda ai

Capitoli 4 e 5.

36

Capitolo 3

Caronte e YaRA

Come gia anticipato nei capitoli introduttivi, questo lavoro si sviluppa attorno al

tema della riconfigurabilita parziale dinamica interna.

In questo capitolo vengono descritte le architetture di Caronte e YaRA che rap-

presentano, rispettivamente, la prima e l’attuale proposta del gruppo D.R.E.S.D.

per l’utilizzo nel campo dei sistemi embedded. Esse costituiscono, nel loro insie-

me, la base di partenza di questo lavoro e proprio per questo motivo e fondamen-

tale comprenderne appieno caratteristiche, peculiarita, vantaggi e limiti, nonche la

stretta correlazione evolutiva esistente fra di esse. L’accento sara posto sulle idee

alla base delle due architetture, sull’organizzazione strutturale e sui principi di

funzionamento. Per alcuni aspetti, anche importanti, si e rimasti volontariamente

su di un livello descrittivo abbastanza alto al fine di evitare di allontanarsi troppo

da quello che deve comunque rimanere una sorta di schema riassuntivo.

Nelle pagine seguenti si evidenziera inoltre come per la realizzazione di que-

ste architetture non si sia fatto ricorso a conoscenze completamente nuove o che

fuoriescano dai normali flussi di lavoro a cui i progettisti HDL sono abituati. Si

ritiene infatti che tale ‘caratteristica’, unitamente alla scalabilita, sia fondamentale

per proporre soluzioni di successo in questo campo, gia di per se per molti aspetti

diverso dagli scenari abituali. A tal fine risultano utili le nozioni introdotte nel

precedente capitolo.

37

CAPITOLO 3. CARONTE E YARA

3.1 Caronte

L’architettura Caronte [19][20] e la prima soluzione realizzata dal team di ricerca

di D.R.E.S.D, operante all’interno del µ-LAB. Nell’introdurre questa particolare

architettura possiamo dire che essa risulta, sotto un certo aspetto, essere una di-

retta implementazione della definizione di riconfigurabilita interna, descritta nel

sottoparagrafo 1.3.3 In Caronte troviamo infatti una parte non modificabile (parte

fissa o modulo fisso), che abbiamo visto essere necessaria per il funzionamento

del sistema, nonche una parte riconfigurabile dinamicamente (parte riconfigurabi-

le) a sua volta formata da una serie di moduli riconfigurabili. Le comunicazioni

fra i moduli avvengono mediante collegamenti punto-punto realizzati mediante

macro-hardware. Lo schema dell’architettura e riportato in Figura 3.1. Caronte

esiste infine in due versioni: dopo una prima realizzazione di tipo stand-alone l’ar-

chitettura e stata infatti integrata all’interno di una versione embedded del sistema

operativo Linux: µClinux.

3.1.1 Struttura dettagliata

In questa sezione vengono descritte nel dettaglio le componenti hardware presenti

nella parte fissa ed in quella riconfigurabile. Per ognuna si specifica la funzione

svolta e si motivano le varie scelte implementative.

Parte Fissa La parte fissa e collocata sulla destra dell’FPGA. E’ intera-

mente realizzata mediante il software EDK (illustrato nel sottoparagrafo 2.4.3),

rispetta gli standard delle architetture IBM CoreConnect, e contiene al suo interno

numerosi elementi.

• PowerPC 405

E’ il processore utilizzato dall’intera architettura. Si occupa pertanto dell’e-

seguzione dell’intera parte software sia per quantio riguarda il codice utente

che per quanto riguarda la gestione della riconfigurazione. Esso e gia pre-

sente sulle FPGA della famiglia Virtex-II Pro che abbiamo a disposizione e

pertanto risulta immediatamente disponibile.

38


Figura 3.1: Struttura generale dell’architettura Caronte

• ICAP e relativo controller

Come gia illustrato all’interno del sottoparagrafo 2.4.1, attraverso questa

particolare porta interna e possibile, tramite il processore del sistema, an-

dare a riconfiguare o riprogrammare l’FPGA. L’ICAP e gestito tramite un

apposito controller munito di interfaccia PLB. Inoltre la sua posizione fissa

all’interno dell’FPGA (parte bassa destra) impone un vincolo preciso sul

posizionamento della parte fissa.

• Moduli BRAM e relativo controller

Formano la memoria del sistema. Contengono, idealmente, le istruzioni e i

dati necessari al processore, Tuttavia, nella maggior parte dei casi, lo spazio

a disposizione risulta insufficente e quindi dati e istruzioni sono sostituiti

dal codice del bootloader necessario a reperire gli stessi esternamente.

• Bus PLB e relativo arbitro

39


E’ il bus ad alta velocita delle architetture basate su PowerPC. Prevede 64

bit dati e 64 bit indirizzi. In questo caso viene utilizzato per collegare il

controller dell’ICAP.

• Bus OPB e relativo arbitro

E’ il bus standard previsto da IBM CoreConnect. Prevede 32 bit dati e 32

bit indirizzi. Ad esso sono collegati, fra l’altro, i moduli riconfigurabili.

• Bridge PLB-OPB

Necessario in quanto il PowerPC si interfaccia direttamente solo al bus

PLB e non all’OPB. Attualmente non e richiesto un bridge che effettui la

conversione nel verso opposto ma, naturalmente, e possibile inserirlo.

Nella parte fissa deve inoltre essere compresa tutta la logica utente la cui presenza

‘permanente’ deve essere garantita per consentire il corretto funzionamento del

sistema.

Parte Riconfigurabile Per quanto appena detto, la parte riconfigurabile e

posta obbligatoriamente sulla sinistra della FPGA. Essa e costituita da vari moduli

che, oltre a garantire la particolare computazione desiderata, devono prevedere al

proprio interno una logica di decodifica degli indirizzi che ne permetta l’attivazio-

ne. Devono inoltre potersi interfacciare ad OPB e ritrasmettere i segnali da esso

ricevuti nel caso in cui questi non siano a loro destinati(ovvero quando il modulo

non e attivo). Tutto cio viene ottenuto mediante l’utilizzo di quelle che vengono

chiamate BlackBoxes. Una BlackBox e un particolare tipo di componente rea-

lizzato mediante due distinti file HDL: uno di essi contiene l’elemento hardware

vero e proprio mentre l’altro contiene l’interfaccia necessaria per la specifica ar-

chitettura. La differenza fra un componente classico e una BlackBox, quindi, e

che quest’ultima non viene vista come un qualcosa di statico ma come un ‘con-

tenitore’ che deve essere mappato sulla FPGA per poi contenere logica di vario

tipo. Sempre grazie a questo tipo di organizzazione durante la riconfigurazione e

possibile modificare solo la logica ‘funzionale’ lasciando inalterate le strutture di

comunicazione e interconnessione.

40


Per concludere,i moduli riconfigurabili rispettano la politica di sostituzione

per colonne prevista da Xilinx e hanno tutti la stessa stessa area (ovvero la stessa

larghezza in termini di numero colonne di CLB) per poter cosı risultare intercam-

biabili.

Macro Hardware di comunicazione Nell’infrastruttura di comunicazione

di Caronte si trova nuovamente traccia di quanto e stato detto all’inizio di questa

descrizione, ovvero del fatto che Caronte e una prima ‘traduzione pratica’ della

definzione teorica di riconfigurabilita parziale. Per le comunicazioni tra i moduli

vengono utilizzate le macro hardware direttamente fornite da Xilinx con le quali

viene realizzato un bus macro1 per trasmessi i segnali del bus OPB, che viene in

questo modo esteso anche al ruolo di bus di comunicazione tra i moduli. Questa

soluzione ha il vantaggio di essere semplice e rapida da implementare. Tuttavia

presenta anche un fondamentale inconveniente: per ogni modulo riconfigurabile

aggiunto all’architettura si ha un notevole aumento del numero di linee totali ne-

cessarie. Questo fatto, come vedremo, porta alla rapida saturazione delle risorse

normalmente presenti sulle piu comuni FPGA e costituira uno dei principali limiti

di Caronte.

3.1.2 Implementazione e Funzionamento

L’implementazione vera e propria di Caronte avviene attraverso un flusso di lavoro

che si articola in tre fasi: innanzitutto si procede con una prima analisi finalizzata

all’identificazione delle funzionalita che devono essere realizzate per mezzo dei

vari moduli. Successivamente si passa alla realizzazione vera e propria dei mo-

duli identificati al passo precedente. Nel fare cio occorre tenere conto anche dei

necessari vincoli d’area. Inoltre, entra in gioco il concetto, precedentemente de-

finito, di BlackBox mediante le quale si va anche ad inserire l’infrastruttura di

comunicazione. L’ultima fase consiste nella generazione dei bitstream necessari

1Un bus macro e una linea di comunicazione fissa tra due punti della FPGA. Essa definisce uncanale di comunicazione preciso, che non puo essere modificato dalla sintesi. Questo e possibilein quanto i bus macro sono delle particolari macro hardware, e come tali sono realizzati su unpiano di silicio separato dal resto della logica.

41


per programmare inizialmente l’FPGA e dei vari bitstream differenza da utilizzare

per la riconfigurazione.

Il bitstream di partenza deve, nel caso piu semplice possibile, comprendere

almeno la parte fissa e il software, potendo i moduli riconfigurabili essere caricati

anche successivamente. Infine dovranno essere memorizzati, in un’opportuna area

di memoria esterna, tutti i bitstream di riconfigurazione necessari.

Completate queste operazioni, il sistema e avviato e diventa quindi indipen-

dente ed autonomo. Il funzionamento successivo e interamente gestito dalla parte

software. Occorre ora trattare separatamente il caso dell’architettura stand-alone

e di quella basata su µClinux.

Nel primo caso, il piu semplice, il codice dialoga a un livello molto basso

con l’hardware. In particolare, si occupa direttamente di prelevare i bitstream

dalla memoria e di gestire l’interfacciamento con l’ICAP per effettuare material-

mente la riconfigurazione. Ne consegue che l’architettura cosı ottenuta risulta,

nell’insieme, meno flessibile e maggiormente legata al singolo problema in esame.

Nella versione basata su GNU/Linux invece, grazie al supporto multitasking,

la riconfigurazione puo essere considerata autonomamente, alla stregua di un qua-

lunque altro thread del sistema. In questo caso, la parte di codice utente che

viene eseguita non ha piu nessun tipo di accesso a basso livello, ma deve basarsi

esclusivamente su delle chiamate al sistema operativo, il quale deve mettere a di-

sposizione un’apposita interfaccia. Non esistendo in Linux alcun driver specifico

per la gestione della periferica ICAP, questo e stato sviluppato ad hoc.

In Linux i programmi utente possono accedere alle periferiche per mezzo di

speciali file presenti nella directory /dev. A ogni periferica e inoltre assegnato un

major number, che indica il driver corrispondente, e un minor number che indica

invece la specifica periferica. Un driver deve, una volta caricato, registrarsi per

uno specifico major number e provvedere poi a gestire tutti gli accessi a quella

periferica che, da quel momento in poi, gli verranno automaticamente rigirati. Per

poter fare cio deve implementere le varie chiamate di sistema quali, ad esempio,

open, close, inizialize, read, write etc.

Questo e cio che, ovviamente, viene fatto anche dall’ICAP driver che, all’at-

42


to del caricamento, provvede inoltre a riservare la memoria necessaria alla sua

periferica.

Infine l’utilizzo di Linux permette una migliore gestione della riconfigurazione

anche dal punto di vista del mutamento dell’insieme delle risorse e delle funzio-

nalita, che risultano essere disponibili o meno a seconda dell’insieme moduli che

sono caricati sull’architettura in un determinato istante. Proprio per questo e pre-

vista la presenza di un modulo del sistema operativo (IPCM - IP Core Manager),

che si occupa di registrare e cancellare le varie perifiriche dopo ogni riconfigura-

zione, caricarne e scaricarne i relativi driver, nonche gestire le chiamate a sistema

indirizzandole al corretto driver di destinazione.

3.1.3 Limiti

I limiti di Caronte sono principalmente dovuti alle scelte effettuate in materia

di canali di comunicazione. In particolare l’utilizzo delle connessioni punto-

punto, imposto dalle macro hardware, si riflette negativamente sulla scalabilita

dell’architettura e sull’affidabilita dei collegamenti durante la riconfigurazione.

La rilevanza del primo problema e immediata. L’uso dello standard OPB pre-

vede, infatti, la totale duplicazione dei segnali per ognuno dei moduli riconfigura-

bili inseriti. Numericamente questo significa l’impiego di piu di settanta linee per

ciascuno di essi. Tenendo presente che le linee disponibili per le macro hardware

sono distinte da quelle normalmente usate per l’instradamento degli altri segnali,

e facile capire come bastino un paio di moduli per superare le risorse disponi-

bili su tutte le FPGA piu comuni. Inoltre occorre tener presente che qualunque

variazione del numero dei moduli riconfigurabili utilizzabili, fra l’altro facilmen-

te prevedibile durante l’analisi e l’ottimizzazione dell’architettura, comporta la

ridefinizione di tutte le interfacce, nonche dei parametri dell’arbitro del bus OPB.

Il secondo problema e ancor piu significativo in quanto condiziona direttamen-

te i tempi e le prestazioni della stessa riconfigurabilita dinamica interna. Osser-

vando la Figura 3.1 si vede come per garantire la comunicazione fra un modulo e

la parte fissa sia necessaria la presenza e il funzionamento di tutti i moduli ricon-

figurabili interposti fra di essi. Infatti la riconfigurazione di uno di questi moduli,

43


nonostante non vada ad intaccare le linee di macro hardware che sono posizio-

nate su un diverso strato di silicio, interromperebbe la ritrasmissione dei segnali

lungo quella che e l’estensione del bus OPB. E’ chiaro come, in un sistema reale,

non e possibile prevedere a priori se un modulo, in un determinato istante, sia o

meno coinvolto in qualche trasmissione. Occorrerebbe quindi fare ricorso a un

elevato numero di segnali di controllo oppure interrompere qualunque comuni-

cazione durante la riconfigurazione. Entrambe queste soluzioni introdurrebbero

pero un pesante collo di bottiglia che potrebbe pesare troppo sulle prestazioni ge-

nerali arrivando, nel caso di sistemi real-time, a far vacillare il concetto stesso di

rinconfigurabilita dinamica.

3.2 YaRA

YaRA (Yet another Reconfigurable Architecture)[1] costituisce la diretta evolu-

zione di Caronte e nasce per cercare una soluzione ai problemi appena descritti.

Tale architettura e di recente realizzazione, ed e tuttora al centro di attivita di

sviluppo e studio.

YaRA condivide l’idea, nonche le caratteristiche di base, di Caronte risultando

pero estremamente innovativa dal punto di vista della struttura di comunicazione.

Per risolvere simultaneamente sia i problemi di duplicazione, sia quelli legati alla

continuita, appare infatti evidente la necessita di ricorrere ad un infrastruttura che

risulti indipendente dai singoli moduli e che non sia influenzata, nel suo funziona-

mento, dalla riconfigurazione. L’analisi compiuta, basandosi sia sulla documenta-

zione ufficiale Xilinx [7] [21] che su recenti studi in ambiti simili [22] ha portato

alla decisione di ricorrere ancora all’utilizzo di macro hardware con l’obiettivo,

pero, di andare a realizzare non piu un bus standard quale l’OPB, bensı un bus piu

specifico appositamente individuato.

Nella scelta di tale bus occorre andare alla ricerca di alcune caratteristiche e

peculiarita, che risultano essere essenziali per il raggiungiumento degli obiettivi

desiderati. Nello specifico, la nuova soluzione deve essere dotata di una struttura

che sia il piu possibile elementare, in modo da limitare le risorse hardware neces-

44


Figura 3.2: Struttura dell’architettura YaRA

sarie. Inoltre deve basarsi su un protocollo che risulti semplice e noto, in modo

da poter aspirare a prestazioni elevate senza la necesita di sforzi eccessivi da parte

degli sviluppatori coinvolti. Infine, per ovvie ragioni gi gestione dell’architettura,

deve essere un bus di tipo sincrono. Tutte queste caratteristiche sono state trovate

nel bus WISHBONE, di cui si e gia parlato nel secondo capitolo.

Nella Figura 3.2 e possibile vedere lo schema a blocchi dell’architettura YaRA.

Prima di passare a fornire ulteriori dettagli sul funzionamento dell’infrastruttura di

comunicazione, si fornisce qui una piu accurata descrizione della parte rimanente

della struttura sottolineando, in particolare, le differenze esistenti con Caronte.

3.2.1 Struttura dettagliata

Parte Fissa La parte fissa di YaRA e, di nuovo, un’architettura IBM Co-

reConnect e ricalca per molti aspetti quella gia vista per Caronte. In particolare,

45


con essa, ha in comune l’utilizzo di PowerPC, e dei bus OPB e PLB con i relativi

bridge. Vi sono poi dei nuovi IP-Core, collegati al bus PLB:

• UART Lite

Gestisce una semplice interfaccia seriale (RS232) che viene utilizzata tipi-

camente per permettere la stampa a video dei messaggi delle applicazioni.

Questa funzione e utilizzata essenzialmente con fini di debug. La presenza

di questa interfaccia e inoltre giustificata dal fatto che per mezzo di essa si

potranno scaricare facilmente i bitstream differenza da inviare poi all’ICAP

nel momento in cui si passera a realizzare la riconfigurabilita di tipo interno.

• OPB to WISHBONE bridge

E’ uno dei componenti di nuova implementazione[1]. Permette l’utilizzo

della nuova infrastruttura di comunicazione traducendo i cicli di singola

lettura e singola scrittura di OPB (su cui agisce da slave) nei corrispondenti

cicli validi su WISHBONE (su cui agisce invece da master).

La parte fissa di YaRA e quindi, nuovamente, un’architettura standard la cui

vera novita, che coincide poi con la principale quanto fondamentale evoluzione

rispetto a Caronte, riguarda la parte di comunicazione con le altre componenti ed

e costituita nello specifico dall’introduzione del bridge appena descritto.

Moduli Riconfigurabili Per quanto riguarda la parte riconfigurabile di Ya-

RA si e dovuto provvedere a una rivisitazione dell’interfaccia dei moduli per con-

sentire loro di interagire con il nuovo bus. Sono stati aggiunti tutti i segnali ri-

chiesti dal nuovo protocollo di comunicazione[12]. Inoltre, come per Caronte, e

necessario tenere conto della politica Xilinx di sostituzione per colonne e del fatto

che la larghezza di ogni modulo deve, a causa della struttura delle FPGA, cor-

rispondere a un multiplo di otto. In YaRA, e stato mantenuto il vincolo di avere

moduli a larghezza costante in modo da rendere immediata la sostituzione. Questa

limitazione, ovviamente, potrebbe essere eliminata a fronte di politiche di sosti-

tuzione piu complesse. Infine, non essendo per ora presente un arbitro per il bus

46


WISHBONE, tutti i moduli riconfigurabili devono essere di tipo slave. L’unico

master presente e invece il bridge.

3.2.2 WISHBONE e comunicazione

La nuova infrastruttura di comunicazione e, come detto, la vera novita introdotta

in YaRA. Si e gia parlato delle scelta di utilizzare il bus WISHBONE e dei motivi

che hanno portato a tale decisione. E’ necessario pero, per poterne comprendere

meglio il funzionamento illustrare anche ulteriori dettagli.

In primo luogo, il tipo di interconnessione utilizzata, fra le varie previste dal-

lo standard, e quella denominata ‘SharedBus’. Per quanto riguarda l’ampiezza

si sono mantenuti 32 bit per i dati (in modo da far sı che un’operazione elemen-

tare su OPB corrisponda a una elementare su WISHBONE) mentre si e ritenuto

sufficente per la parte di indirizzamento l’utilizzo di sole 4 linee a cui vengono

fatte corrispondere, tramite il bridge, le quattro linee meno significative del bus

indirizzi di OPB (OPB Addr).

Per l’instradamento dei segnali si ricorre nuovamente all’utilizzo di una ma-

cro hardware. Tuttavia, a differenza di quanto avveniva per Caronte, questa non e

piu direttamente fornita da Xilinx, bensı definita ad hoc in modo da comprendere,

al suo interno, tutte le linee presenti. La macro si occupa di istanziare le porte

tri-state necessarie alla connessione, nonche un particolare tipo di linee chiamate

TBUFLINE. Queste linee sono interposte a gruppi di quattro fra le linee di CLB

e non non vengono normalmente utilizzate nella fase di Place & Route (si fac-

cia riferimento al sottoparagrafo 2.4.2) per l’instradamento dei normali segnali.

Hanno originariamente una lunghezza pari a quattro colonne di CLB che puo es-

sere aumentata unendole per mezzo di connessioni programmabili. Caratteristica

fondamentale di questo tipo di linee e, ancora una volta, la loro particolare di-

slocazione: essendo posizionate su un piano di silicio differente da quello della

logica programmabile, esse non vengono influenzate dalla riconfigurazione. Uni-

ca eccezione a quanto appena detto si ha per il segnale di clock. Esso coincide

con quello del bus OPB e, nel rispetto delle specifiche di Xilinx [7] viene instra-

47


dato separatamente. In questo modo risulta anche essere l’unico segnale a poter

attraversare i bordi di un modulo riconfigurabile.

Infine, l’ultimo aspetto da considerare e la gestione dei segnali T che sono stati

introdotti con l’uso delle porte tri-state nelle macro hardware. Questi segnali si

aggiungono a quelli normalmente presenti facendo sı che per ogni coppia ingres-

so/uscita (ad esempio DAT I e DAT O) si debba gestire anche un terzo segnale di

controllo (sempre seguendo l’esempio, DAT T).

Per risolvere questo problema, in YaRA si e ricorso a una sorta di evoluzione

del concetto di BlackBox consistente nella creazione di un ‘adattatore d’inter-

faccia’ chiamato WISHBONE Attach. Si tratta di un componente che presenta

due interfacce asimmetriche: una di esse e puramente WISHBONE compatibile,

mentre l’altra presenta, in piu, i segnali T. Sara ora questo nuovo componente ad

andare interfacciarsi al bus WISHBONE. Cosı come in una BlackBox deve esse-

re inserita tutta la logica utente nel WISHBONE Attach deve essere spostata la

parte di logica inerente alla decodifica degli indirizzi nonche quella necessaria ala

gestione dei segnali T a partire dai valori degli altri ingressi.

3.3 Nuove possibili evoluzioni

Dall’analisi compiuta si evidenzia come YaRA abbia provveduto appieno a col-

mare i pesanti problemi che affligevano precedentemente Caronte. Questo fatto

e, ovviamente, estremamente positivo in quanto senza un tale intervento non si

sarebbe potuto compiere nessun altro tipo di evoluzione tecnologica. Allo stesso

modo si vede, pero, come YaRA presenti ancora margini di miglioramento.

Le prime modifiche attuabili riguardano l’introduzione della riconfigurabilita

interna che al momento risulta essere assente. Per far cio sara necessario procedere

all’importazione, all’utilizzo e al test del controller ICAP secondo quanto gia visto

per Caronte.

Una seconda modifica possibile riguarda invece il processore utilizzato. Come

detto, attualmente l’architettura e basata su un PowerPC405. Esso e stato scelto

per motivi di affidabilita, diffusione e anche perche gia fisicamente implemen-

48


tato sulle FPGA della famiglia VirtexII e VirtexII Pro che. Tuttavia, e proprio

quest’ultimo aspetto a introdurre pesanti vincoli di portabilita, in quanto non e

possibile implementare l’architettura su FPGA che non ne sono invece provviste.

Inoltre, l’utilizzo di un componente fisso impone dei limiti ben precisi in termini

di posizionamento e occupazione di risorse.

Proprio per far fronte a queste problematiche, in questo lavoro si andra a so-

stituire il PowerPC con un soft-processor quale il MicroBlaze In questo modo si

otterra il duplice effetto di svincolare l’architettura dalla necessita di hardware

specifico e si potra valutare l’eventuale possibilita di ridurre la quantita di risor-

se utilizzate. Per fare cio sara necessario agire sul modello del soft-processor

includendo solo le componenti che risultano strettamente necessarie. Questo ulti-

mo aspetto e particolarmente interessante in quanto l’eventuale guadagno ottenu-

to facilitera ogni eventuale evuluzione futura che richieda l’inserimento di nuovi

componenti nell’architettura o la modifica, con aggiunta di funzionalita, di quelli

esistenti.

49

Capitolo 4

Le innovazioni introdotte

In questo capitolo verranno descritte nel dettaglio le innovazioni introdotte in Ya-

RA durante lo svolgimento di questo lavoro di tesi, unitamente alle modifiche che

si e reso necessario apportare all’architettura.

Come gia accennato, esse ruotano attorno a due: l’introduzione della ricon-

figurabilita interna, e l’utilizzo del soft processor MicroBlaze in sostituzione del

processore PowerPC 405.

La scelta di concentrarsi su questi due specifici interventi non e ovviamente

casuale, ma e dettata dalla necessita di evolvere, secondo una linea che si puo

definire ‘naturale’, l’architettura esistente. La realizzazione di YaRA ha, infat-

ti, brillantemente risolto i problemi legati alla rigidita dell’infrastruttura di co-

municazione precedentemente rilevati in Caronte, lasciando pero spazio a nuove

possibili migliorie che sono gia state elencate in chiusura del precedente capitolo.

Verranno qui illustrati solamente gli aspetti strettamente implementativi del

lavoro svolto. Successivamente saranno invece riportati i risultati sperimentali

ottenuti dal punto di vista dell’occupazione e della valutazione delle prestazioni.

E’ bene, infine, precisare che tutto quanto segue e stato realizzato sulla ver-

sione stand-alone di YaRA (si faccia per questo riferimento al sottoparagrafo

3.1.2).

51

CAPITOLO 4. LE INNOVAZIONI INTRODOTTE

4.1 La riconfigurabilita interna

L’introduzione della riconfigurabilita interna in YaRA e un passo fondamentale

per rendere questa nuova architettura completamente paragonabile a Caronte, in

cui tale importante funzionalita e da sempre supportata, e poter quindi disporre

di una base di partenza completamente equivalente per le successive evoluzio-

ni. Inoltre, il poter disporre di questo tipo di riconfigurabilita e ovviamente un

elemento essenziale per la realizzazione di sistemi completamente autonomi che

costituiscono, attualmente, uno degli argomenti piu interessanti e promettenti in

questo genere di ricerche. Fino ad ora la riconfigurabilita interna non e mai stata

testata in YaRA, essendo questa architettura di recente creazione e, attualmente,

ancora nel pieno dello svilupppo.

4.1.1 ICAP e relativo controller

Nel secondo capitolo si e gia parlato della particolare porta, chiamata ICAP, pre-

sente sulle FPGA della famiglia VirtexII e Virtex II - Pro il cui modello VP7 e

presente sulla scheda utilizzata in questo lavoro. In particolare si e spiegato come,

attraverso di essa, il processore possa andare a leggere e modificare la programma-

zione dell’FPGA leggendo e scrivendo singoli frame o, in alternativa, scaricandovi

bitstream differenza veri e propri.

Si e altresı accenato al fatto che, per poter utilizzare questa versatile interfac-

cia, e necessario l’utilizzo di uno specifico controller che gestisce il flusso di dati

fra porta e processore. I motivi che rendono necessaria la presenza di un controller

sono quelli che si presentano nella gestione di qualunque tipo di comunicazione.

Il controller ICAP puo svolgere funzioni piu o meno complete e piu o meno

complesse a seconda del contesto in cui viene impiegato. In particolare possiamo

evidenziare:

• selezione, lettura e scrittura di uno specifico frame;

• manipolazione in memoria dei bit costituenti un frame precedentemente

letto;

52


• gestione automatizzata del download su FPGA di un bitstream parziale

proveniente da una memoria interna o da un altro canale di ricezione.

Per utilizzare tali caratteristiche l’utente puo, ovviamente, disporre di funzioni piu

o meno complesse, piu o meno complete e piu o meno amichevoli che gli vengono

direttamente offerte dal driver della periferica.

Inoltre e delegata al controller la gestione, durante l’esecuzione delle opera-

zioni sopra descritte, dei vari problemi di sincronizzazione, di controllo, di attesa

affinche la porta sia libera, nonche di verifica del buon esito.

La realizzazione della configurabilita interna in YaRA consiste nell’inserimen-

to, all’interno dell’architettura esistente, di un controller di questo tipo e succes-

sivamente nella realizzazione una serie di test per validarne il funzionamento e

verificarne le effettive prestazioni.

4.1.2 Il componente utilizzato

Il controller ICAP e, in sostanza, un normale core che svolge le funzioni sopra

descritte. Esso e munito di due interfacce tramite le quali si collega da un lato alla

porta ICAP vera e propria, fisicamente presente sulla FPGA, e dall’altro a un bus

del sistema per dialogare con il processore.

Figura 4.1: Il ruolo del controller ICAP

Per quanto illustrato sopra, non si tratta quindi obbligatoriamente di un com-

ponente standard e predefinito. Ne possono esistere, al contrario, varie versioni

che si differenziano tra loro per qualche particolare legato al funzionamento, per

le funzioni offerte o, elemento fondamentale, per il particolare tipo di bus a cui si

interfacciano.

53


Nonostante alcuni possibili controller siano presenti anche nelle librerie stan-

dard di EDK, nel nostro caso faremo ricorso a un core sviluppato in autonomia

dal team D.R.E.S.D. durante i precedenti studi su Caronte. I motivi di questa scel-

ta sono legati ad un discorso improntato alla continuita, nonche all’esistenza di

documentazione e codice ad hoc facilmente adattabile ai nostri scopi. Esso ha

inoltre il vantaggio di essere stato pensato per interfacciari al bus PLB e risulta

quindi adattabile all’architettura YaRA basata su PowerPC.

Il componente in questione, infine, e stato interamente sviluppato in linguag-

gio Verilog.

4.1.3 Principio di funzionamento

Il controller scelto presenta anche l’indubbio vantaggio di funzionare in maniera

molto semplice. Esso e stato infatti pensato esclusivamente per le esigenze del

progetto D.R.E.S.D e pertanto permette solamente il trasferimento di bitstream

parziali per riconfigurare, tipicamente in maniera consistente, le FPGA. Per utiz-

zarlo in questo senso non e necessario, al contrario di quanto accade, ad esempio,

con i componenti facenti parte delle librerie di EDK, procedere a particolari ini-

zializzazioni o al mantenimento in memoria di un puntatore apposito. Al contrario

e sufficente leggere, da una memoria opportunamente precaricata o da file via se-

riale, il bitstream differenza un byte alla volta ed effettuare una scrittura di quanto

letto sul BASE ADDRESS della periferica.

4.1.4 Implementazione

Il codice Verilog che costituisce il vero e proprio core della periferica, unitamente

ai relativi file necessari per l’interfaccianto al bus, puo essere direttamente impor-

tato in EDK tramite l’apposita utility ‘Create - Import Peripheral’ e successiva-

mente aggiunto alle componenti gia presenti nella parte fissa di YaRA, di cui entra

a tutti gli effetti a fare parte. Una volta fatto cio e possibile ricostruire il sistema

aggiornato. Per poter fare questo e innanzituuto necessario risintetizzare nuova-

mente la parte fissa mediante l’esecuzione del normale flusso previsto da EDK. In

54


Figura 4.2: La nuova parte fissa di YaRA dopo l’inserimento dell’ICAP controller

questo modo si ottiene, nella cartella ’/implementation ’ del progetto, il nuovo file

ngc relativo al componente aggiunto. Tale file va copiato nella cartella contenen-

te gli script che realizzano il normale flusso di YaRA, in modo da poter essere da

questi individuato durante l’esecuzione. Successivamente, rieseguendo per mezzo

degli script suddetti, l’intero flusso normalmente utilizzato per realizzare YaRA,

e possibile ottenere il sistema completo aggiornato.

In linea strettamente teorica, avendo aggiunto un nuovo componente e necessi-

tando quindi di una maggior quantita di risorse, potrebbe essere necessario appor-

tare qualche modifica al file .ucf che contiene i vincoli d’area e di posizionamento

dell’architettura. Tuttavia, nella pratica, il controller ICAP risulta essere molto

piccolo e, pertanto, riesce a essere contenuto nell’area originariamente prevista

per la parte fissa. Le risorse necessarie per il controller, rilevate durante la fase

di sintesi dello stesso, e quindi il corrispondente aumento d’area necessario per

la realizzazione di YaRA, sono riportate successivamente, nella fase della verifica

55


sperimentale.

La nuova parte fissa di YaRA, a seguito del’inserimento dell’ICAP e riportata

in Figura 4.2

4.1.5 Verifica del funzionamento

Terminata la fase di implementazione vera e propria e necessario testare il fun-

zionamento del nuovo core introdotto. Tale funzionamento coincide, ovviamente,

con il piu generale funzionamento della riconfiguarbilita interna in YaRA. Per fare

cio sono stati eseguiti sia test di tipo macroscopico, quali ad esempio la sostitu-

zione di un intero modulo riconfigurabile e la verifica dei nuovi risultati ottenuti

mediante comparazione con il comportamento atteso, che di tipo mirato, mediante

l’utilizzo di piu bitstream di dimensioni ridotte, maggiormente utili per la misu-

razione delle effettive prestazioni. I risultati di tali test, unitamente a maggiori

dettagli sugli stessi, sono riportati nel prossimo capitolo.

4.2 L’utilizzo di MicroBlaze

I motivi che hanno portato alla realizzazione di una versione di YaRA basata su

un soft processor sono essenzialmente legati all’aumento del livello di portabilita

dell’architettura e alla riduzione delle risorse necessarie per l’implementazione

della parte fissa.

Il primo aspetto e fondamentale per poter sperare in una maggiore diffusione

dell’architettura. Solo cosı, infatti, essa potra essere realizzata su FPGA in cui

il PowerPC non e presente oppure, potendo un soft processor essere realizzato

in qualunque contesto implementativo, essere sfruttata all’interno di sistemi che

utilizzano tecnologie differenti.

L’utilizzo di un numero minore di risorse, fatto di per se positivo per definizio-

ne, permette inoltre, in questo contesto, di riservare un’area maggiore alla parte

veramente interessante dell’architettura, ovvero quella riconfigurabile. In questo

modo sara possibile, ad esempio, inserire piu moduli o realizzare funzioni piu

complesse. In alternativa, la richiesta di un’area minore facilitera l’inserimento

56


di YaRA all’interno di sistemi gia esistenti, e in cui il processore principale de-

ve esser dedicato ad altri compiti, per la gestione delle sole funzioni legate alla

riconfigurabilita.

La scelta di utilizzare nello specifico MicroBlaze e giustificata dalla piena

compatibilita di quest’ultimo con le schede e il software di Xilinx, che si traduce

in una perfetta integrazione nel flusso di lavoro a cui si e abituati, nonche dalla

documentazione disponibile.

4.2.1 I parametri di configurazione

Le caratteristiche fondamentali del MicroBlaze sono gia state ampiamente illu-

strate nel secondo capitolo. Si e altresı spiegato come, trattandosi di un soft

processor, esso possa essere personalizzato per rispondere alle proprie esigenze.

La personalizzazione del modello del MicroBlaze avviene direttamente in

EDK, il quale propone un’apposita procedura per la gestione dei principali pa-

rametri di configurazione.

Nel nostro caso, si e proceduto nel rispetto di due precise e ben definite linee

guida: da una parte, al fine di poter paragonare dal punto di vista delle prestazioni

la vecchia versione di YaRA con la nuova da noi realizzata, si e cercato di rendere

la potenza di calcolo dei due processori il piu possibile equivalente. Dall’altra

parte, nell’ottica della riduzione dell’area occupata, si e ricorso all’utilizzo delle

sole componenti strettamente necessarie.

La combinazione di questi due modus operandi, porta all’istanziazione di

MicroBlaze in una configurazione estremente scarna e semplice. Di seguito si

evidenziano le scelte operate evidenziando, tra l’altro, le componenti che e sta-

to possibile eliminare rispetto a quelle presenti alla versione di YaRA basata su

PowerPC.

Innanzitutto, la frequenza di funzionamento del processore e pari a 100 Mhz,

in modo equivalente a quanto accadeva nell’implementazione precedentemente

esistente. Sempre per analogia, si provvede a inserire 32kByte di memoria locale

collegata al bus LMB. Le altre componenti aggiuntive, previste per MicroBla-

ze, vengono invece quasi completamente escluse: non si fa infatti, ad esempio,

57


uso della cache, dell’FPU, e dell’unita per il supporto del debug. E’ bene notare

che tutti questi elementi sono gia integrati in PowerPC e quindi dovevano essere

obbligatoriamente presenti e gestiti nella precedente versione di YaRA.

Anche sotto l’aspetto delle interfacce, la situazione e elementare: per quanto

riguarda i collegamenti esterni viene infatti utilizzato il collegamento diretto con

il bus OPB, mentre internamente si ricorre al gia citato LMB. Non e invece neces-

sario l’utilizzo di soluzioni avanzate quali XCL (mancando, come detto, la stessa

cache) o FSL.

Alla luce di quanto appena detto e possibile effettuare una prima, seppur som-

maria considerazione: l’utilizzo di un processore piu completo, come Power-

PC, risulta essere in un certo senso ‘superfluo’ per le attuali esigenze di YaRA,

almeno inerentemente alla versione stand-alone, in quanto gran parte delle sue

funzionalita rimarrebbero inutilizzate.

4.2.2 Le altre modifiche alla parte fissa

Dopo aver completato la configurazione di MicroBlaze e necessario, sempre tra-

mite EDK, procedere con la ricostruzione della parte fissa di YaRA. Quest’ultima

infatti, sebbene debba svolgere le medesime funzioni che da sempre le competo-

no, necessita di essere in parte ridisegnata per le esigenze del nuovo processore

appena introdotto.

In particolare, grazie all’impiego di MicroBlaze, e possibile introdurre anche

qui delle semplificazioni. Vengono, infatti, definitivamente eliminati il bus PLB in

quanto, come spiegato precedentemente, non e previsto alcun tipo di interfaccia di

collegamento a questo particolare tipo di bus in MicroBlaze, e il bridge PLB-OPB,

come ovvia conseguenza di quanto sopra.

Al contrario, e possibile mantenere il fondamentale Bridge tra OPB e WISH-

BONE, realizzato per YaRA, che collega l’OPB alle macro hardware con cui e

realizato il bus utilizzato nella parte riconfigurabile. Tuttavia, come gia accen-

nato, MicroBlaze puo accedervi direttamente ovvero senza la necessita di dover

passare prima attraverso il bus PLB e ricorrere successivamente, all’intermedia-

zione del bridge PLB-OPB. Questo fatto porta a una sicura riduzione dei tempi

58


necessari per ogni singola comunicazione ed e quindi sicuramente degno di nota.

Per questo motivo sono stati effettuati test specifici per valutare l’effettivo incre-

mento di prestazioni. Maggiori dettagli, unitamente ai dati sperimentali ottenuti,

sono riportati nel capitolo successivo.

Inoltre, per poter completare la nuova parte fissa, e necessario includere nuo-

vamente tutti i componenti ausiliari, che si riveleranno utili nelle fasi di test. Fra

questi e, ancora una volta, essenziale il controller UART per la gestione della co-

municazione tramite seriale. Una novita e invece costituita dall’utilizzo di una

periferica timer esterna da collegare al bus OPB non essendo MicroBlaze, al con-

trario di PowerPC, dotato di un dispositivo di questo tipo. La possibilta di proce-

dere alla misurazione di intervalli di tempo e infatti essenziale per i test finalizzati

alla valuatuzione delle prestazioni. L’utilita di tale periferica e pero limitata a tali

fasi e, pertanto, essa viene successivamente rimossa.

Va infine notato che l’inserimento di MicroBlaze non permette di riutilizzare

immediatamente il controller ICAP testato nella sezione precedente, mancando il

bus PLB. Questo tuttavia non costituisce un grave problema. Infatti, essendo gia

stata dimostrata la funzionalita di tale controller anche all’interno dell’architettura

YaRA sara, in futuro, sufficente modificarne l’interfaccia per adattarlo al bus OPB.

Successivamente, non essendo mutato il core vero proprio della periferica, sara

possibile inserirlo anche in quetsa nuova versione e riutilizzare il codice e i test

che sono stati prodotti durante lo svolgimento di questo lavoro di tesi.

La nuova struttura della parte fissa di YaRA, con l’utilizzo di MicroBlaze e

riporatata in Figura 4.3.

4.2.3 Riassemblaggio dell’architettura

Una volta completata la realizzazione della nuova parte fissa e necessario rico-

struire YaRA nella sua interezza rieseguendo nuovamente l’intero flusso come

precedentemente fatto dopo l’inserimento dell’ICAP.

Per poter fare cio e necessario seguire una procedura simile a quella utilizza-

ta per l’ICAP. In particolare occorre copiare nella cartela che contiene gli script

del flusso tutti i nuovi file ngc generati da EDK. Inoltre, la sostituzione dell’in-

59


Figura 4.3: La nuova parte fissa di YaRA, con l’utilizzo di MicroBlaze

tera parte fissa implica la variazione della mappatura della memoria di sistema

sulle varie BRAM. Le informazioni relative sono contenute nel file bmm che de-

ve, quindi, a sua volta essere sostituito. Infine occorre sostituire i file system.vhd

e system stub.vhd che contengono rispettivamente la descrizione di tutti i core

presenti con le relative porte e collegamenti, e la mappatura dei segnali destinati

all’interfaccia esterna.

Nuovamente, potrebbe essere necessario modificare il file .ucf che contiene

i vincoli. In realta, quello gia utilizzato con PowerPC risulta comunque idoneo.

Cio e una prima conferma del fatto che l’area richiesta per la nuova parte fissa e

minore. Possono essere, tuttavia, apportate modifiche per ottenere una mappatura

ottimale sull’FPGA.

60


4.2.4 Confronto funzionale

Una volta definita la nuova struttura di YaRA e necessario procedere a un con-

fronto delle due versioni anche ad un livello piu elevato, ovvero dal punto di vista

delle funzionalita offerte e supporate.

Sotto questo nuovo punto di vista, l’utilizzo di MicroBlaze non introduce al-

cuna particolare perdita. Infatti, come spiegato nel paragrafo precedente, si e

proceduto all’eliminazione di alcune componenti solamente per il fatto che queste

non avevano, attualmente, una vera e propria utilita. Tuttavia questa non e stata

assolutamente una scelta obbligata, e se queste si rivelassero necessarie in futuro

potrebbero, in qualunque momento, essere reinserite. YaRA si trova inoltre a la-

vorare a 100 Mhz. Questa frequenza, per quanto detto nel capitolo 2, puo essere

tranquillamente raggiunta anche da MicroBlaze sulle FPGA da noi utilizzate. Non

vi sono quindi problemi nemmeno da questo punto di vista.

Infine, anche con MicroBlaze puo essere utilizzato Linux. Sara quindi pos-

sibile, ancora una volta, inglobare YaRA al suo interno creando nuovamente una

versione dell’architettura basata su questo sistema operativo e riutilizzando, fra

l’altro, anche moduli gia creati per la gestione della registrazione e cancellazione

delle periferiche in seguito durante la riconfigurazione.

Un riassunto della comparazione fra le architetture proposte e riportato in

Tabella 4.1.

4.2.5 Verifica del funzionamento

Dopo le considerazioni di carattere teorico, occorre testare l’architettura anche dal

punto di vista pratico al fine di verificarne i reali vantaggi. I test effettuati riguar-

dano innanzitutto la sintesi vera e propria dell’architettura, al fine di valutarne i

vantaggi in termini di occupazione, e la misurazione dei tempi di comunicazione

fra parte fissa e moduli riconfiguarbili, al fine di valutare l’incremento di presta-

zioni ottenute dal bus WISHBONE in assenza del bridge PLB-OPB. Questi test

saranno dettagliatamente descritti nel prossimo capitolo, in cui verranno riportati

anche i dati sperimentali ottenuti.

61


Car

atte

rist

ica

Car

onte

YaR

Aco

nPo

wer

PCY

aRA

con

Mic

roB

laze

Ric

onfig

urab

ilita

Din

amic

aPa

rzia

leE

ster

naSı

SıSı

Ric

onfig

urab

ilita

Din

amic

aPa

rzia

leIn

tern

aSı

SıN

o,oc

corr

epo

rtar

eil

cont

rolle

rIC

AP

suO

PBN

umer

odi

mod

ulir

icon

figur

abili

≤2

dive

rse

deci

nedi

vers

ede

cine

Inte

rruz

ione

della

com

unic

azio

neSı

No

No

dura

nte

lari

confi

gura

zion

eIn

terc

ambi

abili

tade

imod

uli

No

SıSı

Part

eFi

ssa

Tipo

diPr

oces

sore

Har

dPr

oces

sor

Har

dPr

oces

sor

Soft

Proc

esso

rPr

oces

sore

Pow

erPC

405

Pow

erPC

405

Mic

roB

laze

Bus

PLB

,OPB

PLB

,OPB

,WIS

HB

ON

EO

PB,W

ISH

BO

NE

Bri

dge

daPL

Ba

OPB

daPL

Ba

OPB

,da

OPB

aW

ISH

BO

NE

daO

PBa

WIS

HB

ON

EA

rbitr

iPL

B,O

PBPL

B,O

PBO

PBSt

anda

rdC

oreC

onne

ctC

ompa

tibile

SıSı

SıSt

anda

rdW

ISH

BO

NE

Com

patib

ileN

oSı

SıM

odul

iRic

onfig

urab

iliIn

terf

acci

aO

PBSl

ave

WIS

HB

ON

ESl

ave

WIS

HB

ON

ESl

ave

Poss

ibili

tadi

este

nder

ela

SıSı

Sıco

mpa

tibili

taa

mod

ulim

aste

rC

omun

icaz

ione

tra

imod

ulir

icon

figur

abili

SıSı

Sı

Tabe

lla4.

1:C

onfr

onto

tre

leva

rie

arch

itettu

reri

confi

guar

abili

prop

oste

62

Capitolo 5

Risultati sperimentali

Nel capitolo precedente sono state illustrate le due soluzioni proposte per ottimiz-

zare l’architettura YaRA. In questa sezione esse verranno realizzate praticamente,

al fine di poter osservare le eventuali migliorie apportate.

In una prima fase verra verificato il funzionamento della riconfigurazione di-

namica interna, che sfrutta l’ICAP inserito nell’architettura basata su PowerPC.

Nella seconda parte del capitolo verra introdotto MicroBlaze all’interno dell’ar-

chitettura, in sostituzione di PowerPC. Al fine di validare la scelta, verranno con-

frontati sia i dati di occupazione delle due alternative, sia le performance ottenute

nei due casi dal bus WISHBONE.

Gli strumenti utilizzati durante questa fase del lavoro sono gia stati descritti

nel corso del Capitolo 2.

5.1 Test della riconfigurabilita interna

Il test svolto in questa sezione ha lo scopo di validare il funzionamento dell’ICAP,

utilizzato per ottenere la riconfigurazione interna. Verra di seguito descritta, tra

l’atro, l’architettura realizzata per effettuare i test. Il test e diviso in due parti: la

prima, di tipo piu qualitativo, permette di verificare che la riconfigurazione vie-

ne effettivamente realizzata. La seconda parte, piu quantitativa, fornisce invece

i tempi richiesti per completare l’operazione. Queste ultime verifiche, pur po-

63

CAPITOLO 5. RISULTATI SPERIMENTALI

tendo apparire lontane dalla realta dei sistemi embedded, permettono di ottenere

delle interessanti indicazioni sulle potenzialita dell’architettura YaRA, nonche di

valutarne le reali prestazioni.

5.1.1 L’architettura di test

Il sistema utilizzato per in questa fase di test e un’architettura YaRA basata su

PowerPC e contenente il controller ICAP. Di seguito verranno elencati tutti i core

inclusi nella parte fissa, e tutte le loro connessioni ai bus. Per quanto riguarda i

moduli riconfigurabili, al contrario, essi verranno descritti man mano che verranno

utilizzati durante i test.

La parte fissa di YaRA implementata in questa sezione comprende i seguenti

componenti:

• Un hard processor PowerPC 405, operante ad una frequenza di 100 MHz;

• Un modulo DCM per la gestione e la propagazione del segnale di clock

all’interno del sistema;

• Un bus PLB, a cui e collegato il processore;

• Un memory controller interfacciato al bus PLB;

• 32 kByte di memoria su scheda (BRAM) cui si accede tramite il memory

controller di cui sopra;

• Un controller per la porta ICAP interfacciato al bus PLB;

• Un bus OPB;

• Un bridge tra i bus PLB ed OPB;

• Un controller UART Lite che gestisce un’interfaccia seriale RS232, colle-

gato al bus OPB;

• Un bridge tra il bus OPB ed il bus WISHBONE.

64


La parte fissa ottenuta arriva ad occupare, una volta terminata la sintesi, 1198

slice dei 4928 presenti sulla FPGA utilizzata, corrispondenti al 24% del totale.

Inoltre, come previsto, risultano occupati anche gli unici PowerPC ed ICAP di-

sponibili. I dati completi relativi all’occupazione verranno esposti durante il con-

fronto con la parte fissa basata su MicroBlaze. Per il momento, ci si puo limitare

a constatare che, rispetto all’intera architettura, l’occupazione di risorse per l’in-

stanziazione controller ICAP e molto limitata, come mostrano i risultati riportati

in Tabella 5.1.

Risorsa Occupati Totali %Slices 37 4928 0,7

Slices Flip Flop 52 9856 0,54 Input LUTs 66 9856 0,6

Tabella 5.1: Dati di occupazione del controller ICAP

5.1.2 Riconfigurazione modulare

Il primo test relativo all’ICAP ha lo scopo di mostrarne il corretto funzionamento,

e consiste nella sostituzione di un intero modulo riconfigurabile e nell’osservazio-

ne del comportamento ottenuto. La verifica e solamente di tipo qualitativo, e si

basa sul confronto tra il comportamento reale e quello atteso.

L’assenza di veri e propri dati relativi alle prestazioni e giustificata dal fatto

che il trasferimento dei bistream all’ICAP avviene tramite l’interfaccia seriale, la

quale e molto lenta e falserebbe le misurazioni ottenute. Per ottenere delle misure

attendibili, dunque, e necessario innanzitutto trasferire i bitstream tramite inter-

faccia seriale alla FPGA, e memorizzarli all’interno di una memoria su scheda.

Questo modo di operare, tuttavia, non e applicabile in questo contesto: i bitstream

differenza per istanziare i moduli riconfigurabile, infatti, risultano troppo grandi

(oltre 50 kByte) per le risorse a disposizione. Pertanto, la misura dei tempi verra

ripresa nel test successivo, in cui i bitstream in gioco avranno dimensioni molto

ridotte, e saranno dunque memorizzabili temporaneamente nella poca memoria

disponibile.

65


Il codice Il software da eseguire per effettuare la riconfigurazione e le letture

dai moduli e diviso in due parti, eseguite rispettivamente da un comune personal

computer e dal PowerPC presente sulla FPGA. Il codice da eseguire sulla FPGA

viene scritto e compilato all’interno di EDK, mentre quello da eseguire su PC puo

essere scritto con qualsiasi editor di testo utilizzando il linguaggio C++, compilato

con un compilatore quale il gcc, ed eseguito da una shell 1.

Il codice eseguito da PowerPC si occupa, in primo luogo, di inizializzare l’in-

terfaccia seriale. Per semplicita, si suppone che il primo modulo riconfigurabile

venga istanziato con lo stesso bitstream che programma la parte fissa, in modo che

risulti gia disponibile all’avvio del programma. Sotto questa ipotesi, il software

invia due dati verso il modulo riconfigurabile, e successivamente effettua la lettu-

ra. Ovviamente, a seconda del modulo istanziato per primo, gli stessi dati inviati

potrebbero portare a due letture diverse. Inoltre, la coppia di invii e la lettura pos-

sono essere inseriti in un ciclo per effettuare un numero piu elevato di letture. Al

termine di ciascuna lettura, l’esito viene trasmesso sulla seriale. A questo punto

il codice si prepara a ricevere il bitstream differenza, che permette di istanziare il

nuovo modulo. Il trasferimento avviene via seriale, ed ogni parola ricevuta viene

immediatamente indirizzata verso l’ICAP. Una volta terminato il trasferimento,

l’ICAP completa la riconfigurazione dinamica, ed il programma puo effettuare

nuovamente un certo numero di sequenze composte da due invii ed una lettura dal

nuovo modulo, trasmettendo il risultato sulla seriale.

Il codice eseguito dal lato del personal computer e esattamente duale rispetto a

quello sulla FPGA. In primo luogo, viene inizializzata la porta seriale, e successi-

vamente si attende l’esito della prima lettura dal bus WISHBONE. Una volta letti

tutti i valori dalla seriale, il codice si occupa di inviare il bitstream differenza, e si

mette nuovamente in attesa di ulteriori letture.

Va sottolineato come la programmazione iniziale della FPGA non venga ese-

guita dal software scritto dalla parte PC, bensı da uno strumento fornito da Xilinx:

iMPACT. L’interfaccia utilizzata per la programmazione, in questo caso, non e

quella seriale, ma quella JTAG.1E’ possibile utilizzare la shell di Linux o, in alternativa, Cygwin, che simula l’ambiente Linux

all’interno di Microsoft Windows.

66


Moduli riconfigurabili I moduli utilizzati per effettuare la riconfigurazione

dinamica non sono stati creati ex novo, ma erano gia stati usati in test effettuati

in precedenza all’interno del progetto D.R.E.S.D.[1]. La principale caratteristica

posseduta da questi moduli e la loro interfaccia WISHBONE di tipo slave, essen-

ziale in quanto l’unico master del bus deve essere il bridge con l’OPB. Le funzioni

implementate, invece, risultano ancora molto elementari.

Il primo modulo e un accumulatore non resettabile. Durante i cicli di lettura,

il modulo si limita a campionare le linee di WISHBONE contenenti i dati, som-

mando il valore alle letture effettuate in precedenza. Durante un ciclo di scrittura,

invece, l’accumulatore restituisce la somma dei dati letti fino a quel momento.

Il modulo parte da un valore iniziale nullo e, data la sua semplicita, rischia di

generare dopo poche letture un overflow.

Il secondo modulo e un accumulatore resettabile. Il funzionamento e identico

al precedente, con la differenza che esiste un particolare valore che resetta il mo-

dulo, facendo ripartire la somma dal valore zero. Il reset avviene, nella versione

utilizzata, alla ricezione del valore esadecimale 0xDEADBEEF.

Come gia accennato, uno dei due moduli deve essere istanziato nell’architet-

tura YaRA all’avvio, per agevolare il compito del codice eseguito dalla FPGA. Di

seguito, si fara riferimento al test eseguito partendo dal modulo non resettabile,

sostituito dinamicamente da quello resettabile. E’ stato tuttavia eseguito anche il

procedimento inverso, anche in questo caso con risultati positivi.

Dopo aver specificato il funzionamento dei due moduli tramite un codice

VHDL, utilizzando ISE e possibile sintetizzare il componente non resettabile. Ov-

viamente, trattandosi di un sotto-modulo e non di un’architettura top-level, l’interi

flusso di ISE non puo terminare, ma permette di ottenere un file con estensione

ngc, che contiene la descrizione dell’accumulatore. Effettuando le stesse opera-

zioni anche per le altre componenti di YaRA (compresa la parte fissa), si arriva

ad ottenere tutti i sotto-moduli per costruire l’architettura complessiva. Questa si

ottiene tramite il flusso di YaRA che, con una serie di invocazioni ai processi di

ISE, costruisce un’architettura top-level che soddisfa i vincoli spaziali che erano

stati imposti.

67


Ottenuto il bitstream per programmare la FPGA, istanziando direttamente il

modulo non resettabile, e necessario ripetere tutto il flusso, inserendo pero l’accu-

mulatore resettabile. A questo punto e possibile generare un bitstream differenza

tra le due architetture ottenute, che permette di passare dal sommatore non reset-

tabile a quello resettabile. Tale bitstream e quello utilizzato dal codice eseguito

sul PC per riprogrammare la FPGA.

Risultati ottenuti Nel caso di test proposto, ad ogni modulo riconfigura-

bile sono stati inviati due valori pari a 0xDEADBEEF e 0x00000005, prima di

effettuare la lettura. La sequenza di istruzioni e stata ripetuta piu volte, per poter

ottenere un riscontro piu completo. Come gia, detto, si fa riferimento al caso del

passaggio dal modulo non resettabile al resettabile.

Le prime due scritture effettuate sull’accumulatore non resettabile dovrebbero

sortire l’effetto di aggiungere prima 0xDEADBEEF e poi 0x00000005, che ven-

gono sommati per ottenere il valore 0xDEADBEF4. La prima lettura, a livello

teorico, dovrebbe quindi resitituire tale risultato. Ogni successiva iterazione ag-

giunge nuovamente 0xDEADBEF4 al valore gia ottenuto, e dunque, trascurando

gli overflow, i valori attesi sono rispettivamente 0xBD5B7DE8, 0x9C093CDC,

eccetera. L’esito della lettura da WISHBONE conferma appieno queste ipotesi, in

quanto l’output ricevuto da seriale e stampato dal PC e riportato di seguito.

Lettura dato da Modulo su FPGA: DEAD BEF4 ...

Lettura dato da Modulo su FPGA: BD5B 7DE8 ...

Lettura dato da Modulo su FPGA: 9C09 3CDC ...

Dopo la trasmissione del bitstream, l’accumulatore resettabile dovrebbe essere

stato inserito in luogo di quello non resettabile. In questo caso, quindi, il primo in-

vio del valore 0xDEADBEEF ha l’effetto di azzerare il valore accumulato fino al

quel momento, senza essere aggiunto. Il secondo invio, 0x00000005, non ha nes-

sun significato particolare, e dunque viene sommato. La prima lettura dovrebbe

quindi restituire, in linea teorica, 0x00000005. In tutte le iterazioni successive, si

verifica sempre che il primo invio azzera il modulo, ed il secondo viene sommato.

68


Pertanto, in linea teorica, si dovrebbe sempre leggere lo stesso valore. Ancora una

volta, il risultato sperimentale conferma le congetture, come mostrato di seguito.

Lettura dato da Modulo su FPGA: 0000 0005 ...



Dai test effettuati, e possibile concludere che l’ICAP inserito nell’architettura

YaRA e funzionante, e capace di riconfigurare dinamicamente il sistema. Il me-

todo di ricezione del bitstream, tuttavia, risulta ancora piuttosto lento, e rischia

di intaccare le prestazioni del dispositivo. Tuttavia, ora che si e certi dell’avve-

nuta riconfigurazione, e possibile passare a considerare bitstream piu piccoli, che

possono essere trasferiti sulle BRAM.

5.1.3 Tempi di riconfigurazione

Il secondo test effettuato ha lo scopo di rilevare i tempi impiegati dall’ICAP per

riconfigurare il sistema, in funzione della dimensione del bistream differenza e

della frequenza di funzionamento del processore. Il principio consiste nel tra-

sferire il bitstream dal personal computer alla FPGA tramite la porta seriale, e

memorizzarlo sulle BRAM. Questa politica e limitata dalla presenza di soli 32

kByte di memoria all’interno della parte fissa, parte dei quali sono utilizzati per

memorizzare il codice eseguito da PowerPC e i dati.

Il codice utilizzato e pressoche identico a quello descritto nel paragrafo pre-

cedente, con l’unica differenza che il bitstream non viene trasferito direttamente

dalla controller della seriale a quello dell’ICAP. Il file ricevuto viene infatti memo-

rizzato nelle BRAM libere da codice e dati, e una volta terminato il trasferimento

viene inviato all’ICAP. All’inizio di quest’ultima operazione viene inoltre azzera-

to il registro di PowerPC che funge da timer, in modo da poter prelevare il tempo

impiegato a riconfigurazione avvenuta.

I tempi sono stati rilevati in corrispondenza di diverse frequenze di funzio-

namento del processore. Come gia citato nel sottoparagrafo 2.2.1, PowerPC puo

lavorare fino a 400 MHz, anche se nel corso di tutta la trattazione la frequenza

e stata mantenuta costantemente a 100 MHz. In questo caso, tuttavia, verra fatta

69


variare, toccando i 200 ed i 300 MHz, in quanto la FPGA utilizzata non consen-

te di raggiungere performance piu elevate. In questo modo, si vuole dimostrare

come i tempi di riconfigurazione tendano a diminuire in presenza di sistemi piu

performanti.

I bitstream differenza Al contrario di quanto avveniva nel test precedente,

in cui i moduli riconfigurabili dovevano avere un comportamento predicibile, in

modo da poterne valutare il funzionamento, in questo caso l’unica caratteristica

rilevante e la compattezza. Un bitstream differenza capace di istanziare uno degli

accumulatori utilizzati in precedenza, infatti, ha dimensioni troppo elevate per la

memoria del sistema.

Per generare bitstream differenza di piccole dimensioni occorrono due archi-

tetture top-level che differiscano per pochi frame. Per poter ottenere cio si puo far

ricorso a FPGA Editor, descritto nel corso del Capitolo 2, nel quale e possibile

effettuare operazioni come la negazione di una porta o l’eliminazione di un se-

gnale utilizzato per propagare un riporto del sommatore. Combinando operazioni

di questo tipo si sono ottenuti bitstream di varie dimensioni, capaci di riconfigu-

rare fino a 16 frame. Per rendere l’idea della piccola dimensione di questi valori,

basti pensare che per istanziare l’accumulatore resettabile sono necessari oltre un

centinaio di frame.

Risultati ottenuti Il comportamento del sistema riconfigurato, in questo ca-

so, non e piu un indice della corretta riconfigurazione del sistema, in quanto risulta

molto complesso capire a priori quali risultati si dovrebbero ottenere dalla lettu-

ra su WISHBONE dopo la riconfigurazione. Tuttavia, si puo osservare come il

valore letto cambi, segno che l’ICAP ha portato a termine il suo compito.

Molto piu significativi sono i tempi, che vengono riportati in Tabella 5.2, nel-

la quale sono riportati anche le dimensioni dei frame, correlati dai calcoli dei

baudrate stimati, per ciascuna delle frequenze utilizzate.

Si puo osservare come il valore del baudrate sia sempre assestato attorno a tre

valori: 1,02 MByte/s alla frequenza di 100 MHz, 1,15 MByte/s in corrispondenza

di 200 MHz, e di 1,22 MByte/s a 300 MHz. Il baudrate risulta dunque aumentare

70


al crescere della frequenza del processore, ma non linearmente, e risulta indi-

penente dalla dimensione del bitstream utilizzato. Questo secondo fenomeno e

conseguenza del fatto che il baudrate e funzione delle sole performance della me-

moria, del bus PLB e dell’ICAP, e non della lunghezza del dato. La crescita non

lineare con la frequenza, invece, deriva dal fatto che non tutti i core appena citati,

ed in particolare il bus PLB, possono raggiungere le frequenze del PowerPC, e

dunque generano un collo di bottiglia. Questo implica che, con gli strumenti a

disposizione, l’aumento delle prestazioni del processore non procuri dei cospicui

vantaggi in termini di tempi necessari per la riconfigurabilita interna.

Consierando i soli dati ottenuti a 100 MHz, gli unici disponibili per un con-

fronto, le prestazioni ottenute risultano inferiori rispetto a quelle ottenute con l’ar-

chitettura Caronte[23], anche se il confronto risulta falsato dalla differenza di FP-

GA. Caronte, infatti, e stato testato su una Virtex II - Pro VP20, piu performante di

una VP7 e dotata di un maggior numero di risorse. Pertanto, il baudrate risulta co-

munque convincente, e dimostra ancora una volta le potenzialita dell’architettura

YaRA.

5.2 Inserimento di MicroBlaze

In questa sezione viene introdotto il soft processor MicroBlaze all’interno del-

la parte fissa di YaRA, che dunque vedra modificata anche tutta la struttura dei

bus. L’obiettivo e quello di dimostrare, in primo luogo, la possibilita di effettuare

correttamente una riconfigurazione parziale del sistema.

Secondariamente, verranno proposte delle comparazioni tra le architetture ba-

sate su PowerPC e MicroBlaze in termini di risorse occupate e di prestazioni del

bus WISHBONE.

71


Num

ero

Dim

ensi

one

Tem

poB

audr

ate

Tem

poB

audr

ate

Tem

poB

audr

ate

dide

lbits

trea

m(m

s)(M

Byt

e/s)

(ms)

(MB

yte/

s)(m

s)(M

Byt

e/s)

fram

e(B

yte)

Sist

ema

a10

0M

Hz

Sist

ema

a20

0M

Hz

Sist

ema

a30

0M

Hz

114

541,

4256

1,01

991,

2655

1,14

891,

1928

1,21

902

2318

2,27

231,

0201

2,01

721,

1491

1,90

131,

2192

331

823,

1191

1,02

022,

7689

1,14

922,

6098

1,21

9314

1061

010

,398

51,

0203

9,23

251,

1492

8,70

241,

2192

1612

338

12,0

919

1,02

0410

,735

21,

1493

10,1

198

1,21

92

Tabe

lla5.

2:Te

mpi

diri

confi

gura

zion

ein

funz

ione

della

dim

ensi

one

delb

itstr

eam

72


5.2.1 Parte fissa basata su MicroBlaze e riconfigurabilita

Il primo passo del test e la verifica della riconfigurabilita dinamica in un’architet-

tura YaRA basata su MicroBlaze. Il principale ostacolo che si incontra in questo

caso consiste nel fatto che la riconfigurazione puo essere solamente di tipo ester-

no, in quanto il controller della porta ICAP non e piu disponibile. Tale core, infat-

ti, prevede unicamente un’interfaccia PLB, ed al momento non esiste all’interno

del progetto D.R.E.S.D. una versione per il bus OPB. Si rende dunque necessa-

rio l’utilizzo del software iMPACT per inviare il bitstream differenza attraverso

l’interfaccia JTAG, e non e piu richiesta la stesura di un codice da far eseguire al

PC.

La nuova architettura di test ha una parte fissa totalmente diversa da quella

descritta nel sottoparagrafo 5.1.1. Di seguito ne verranno elencati tutti i core,

ricordando che la gran parte delle scelte e votata al risparmio in termini di spazio

occupato. La parte fissa risulta dunque composta da:

• Un soft processor MicroBlaze, operante ad una frequenza di 100 MHz;

• Un memory controller interfacciato al bus LMB;

• 32 kByte di memoria su scheda (BRAM) cui si accede tramite il memory

controller di cui sopra, utilizzata per dati ed istruzioni;

• Un bus OPB;

• Un controller UART Lite che gestisce un’interfaccia seriale RS232, colle-

gato al bus OPB;

• Un bridge tra il bus OPB ed il bus WISHBONE.

La sintesi della parte fissa puo essere svolta utilizzando EDK, che con apposita

procedura (detta Base System Builder) permette di inserire in modo immediato

gran parte dei core citati. Una volta sintetizzata, la parte fissa puo essere introdotta

nel gia citato flusso di YaRA, per realizzare la nuova architettura.

73


Riconfigurabilita esterna E’ ora possibile testare la capacita del sistema

di essere riconfigurato dinamicamente attraverso l’interfaccia JTAG. Per questa

verifica sono stati utilizzati i due moduli sommatori gia descritti nel sottoparagrafo

5.1.2. Anche in questo caso, uno dei due moduli viene istanziato insieme alla parte

fissa durante la programmazione iniziale della FPGA, e il rimanente viene caricato

in modo dinamico attraverso il bitstream differenza.

Il codice eseguito dalla FPGA, in modo del tutto simile a quanto gia fatto in

precedenza, effettua una serie di scritture sull’accumulatore interfacciato al bus

WISHBONE, inviando continuamente i valori 0xDEADBEEF e 0x00000005 pri-

ma di eseguire una lettura. IL risultato di tale lettura e sempre propagato via

seriale, e puo essere raccolto da un terminale in ascolto sul PC. Questo ciclo non

viene interrotto nemmeno durante la riconfigurazione, in quanto questa avviene

indipendentemente dall’attivita della FPGA.

Al solito, si fa riferimento al caso in cui il primo sommatore istanziato sia

quello non resettabile, ma un test analogo e stato eseguito anche con i moduli

introdotti in ordine inverso. Anche in questo caso, i risultati sono stati in linea

con quelli attesi, in quanto le prime letture hanno dato lo stesso comportamento

gia osservato nel sottoparagrafo 5.1.2, con la sequenza di valori 0xDEADBEF4,

0xBD5B7DE8, 0x9C093CDC, eccetera.

Durante la riconfigurazione effettuata tramite iMPACT, i valori restituiti dalla

lettura risultano ovviamente privi di senso. Tuttavia, una volta completata l’ope-

razione, i risultati tornano ad assestarsi, restituendo costantemente 0x00000005.

Tale comportamento e corretto in quanto, come gia noto, il valore 0xDEADBEEF

funge da reset per l’accumulatore, che dunque ad ogni iterazione deve azzerare il

conteggio ed aggiungere 5.

Il comportamento osservabile dal terminale dimostra quindi che la riconfigu-

razione dinamica esterna avviene correttamente. Questo fatto valida il funzio-

namento della nuova architettura basata su MicroBlaze, e permette di passare ai

confronti con quella basata su PowerPC.

74


5.2.2 Dati di occupazione

Dopo aver validato l’architettura fondata su MicroBlaze, e possibile quantificare

i vantaggi che questa porta in termini di spazio occupato rispetto alla soluzione

con PowerPC. I dati che verranno proposti in seguito sono ottenuti invocando i

processi contenuti in ISE: se la chiamata avviene tramite Project Navigator (vedi

Capitolo 2), i dati sono leggibili dalla consolle, mentre se la chiamata avviene da

riga di comando, i risultati sono stampati nella stessa.

In Tabella 5.3 sono riportati i dati che erano stati ottenuti per YaRA nella ver-

sione PowerPC, e successivamente quella ottenuti ora con l’utilizzo di MicroBla-

ze. I valori proposti sono relativi all’occupazione della sola parte fissa al confronto

con le risorse disponibili su tutta la FPGA. E’ bene ricordare inoltre che i vincoli

spaziali sono gli stessi in entrambe le architetture.

Risorsa Disponibili PowerPC MicroBlazeOccupati % Occupati %

Slices 4928 1154 23% 864 17%Slices Flip Flop 9856 1194 12% 703 7%4 Input LUTs 9856 980 9% 982 9%Block RAMs 44 16 36% 16 36%

PPC405s 1 1 100% 0 0%

Tabella 5.3: Dati di occupazione relativi alle parti fisse con PowerPC e MicroBlaze

E’ possibile notare il grande vantaggio che l’architettura basata su MicroBlaze

procura in termini di slice e di flip flop. Inoltre, in questa soluzione non viene uti-

lizzato l’unico PowerPC presente sulla VP7. Non sembrano, al contrario, esserci

particolari guadagni in termini di LUT e di BRAM. La spiegazione relativa alle

BRAM e banale: questi sono infatti funzione della memoria allocata dalla parte

fissa, che in entrambi i casi e stata fissata a 32 kByte.

Va inoltre sottolineato come nel caso di MicroBlaze una parte delle risorse

venga utilizzata per implementare il soft processor, mentre nel caso di PowerPC

tutta l’occupazione e riservata all’infrastruttura di comunicazione ed alle periferi-

che. La reale struttura che circonda MicroBlaze, dunque, risulta essere sufficien-

75


temente semplice da non far pesare la presenza di un processore implementato

sulle slice della FPGA.

Per fornire un’idea visiva dell’occupazione delle due soluzioni, in Figura 5.1

e riportata l’implementazione della parte fissa basata su PowerPC vista ottenuta

con FPGA Editor, mentre in Figura 5.2 e riportato l’equivalente con MicroBla-

ze. E’ possibile osservare come l’architettura basata su MicroBlaze sia molto piu

compatta, tanto da lasciare libera gran parte dell’area riservata alla parte fissa.

In questo modo, se in futuro venissero definiti dei vincoli spaziali piu restritti-

vi, si potrebbe aumentare notevolmente la porzione di FPGA riservata ai moduli

riconfigurabili.

5.2.3 Prestazioni del bus WISHBONE

L’ultimo test proposto in questo lavoro e volto a dimostrare come, in presenza di

un’architettura semplice come quella di MicroBlaze, le prestazioni del bus WISH-

BONE tendano a migliorare. Il fondamento teorico alla base di questa considera-

zione risiede nell’eliminazione del bus PLB e, di conseguenza, del bridge tra PLB

ed OPB. Un dato inviato in scrittura o in lettura verso i moduli riconfigurabili,

quindi, puo essere inviato direttamente sul bus OPB, e successivamente attraverso

il bridge verso WISHBONE, senza dover transitare per il PLB. Di seguito verra

descritta la procedura per confermare sperimentalmente queste considerazioni.

Modifiche alla parte fissa Per ottenere indicazioni sulle prestazioni del bus

WISHBONE, verranno rilevati i tempi impiegati per eseguire un certo numero di

cicli composti da una scrittura ed una lettura. Il numero di cicli misurati verra

via via incrementato, partendo da una sola coppia di operazioni di scrittura e let-

tura sul modulo riconfigurabile, sino ad arrivare a cinque. Per ottenere il valore

del tempo impiegato per eseguire uno o piu cicli, e necessario un timer simile a

quello utilizzato nel sottoparagrafo 5.1.3. Il timer in questione era fornito diretta-

mente dal processore PowerPC, che conteneva al suo interno un registro a 64 bit

utilizzato per il conteggio dei cicli di clock trascorsi. MicroBlaze, al contrario,

non prevede questa funzionalita, e dunque e necessario introdurre un particolare

76


Figura 5.1: Parte fissa basata su PowerPC vista da FPGA Editor

Figura 5.2: Parte fissa basata su MicroBlaze vista da FPGA Editor

77


core presente nelle librerie di EDK. Tale periferica prende il nome di OPB Timer,

ed e dotato di un’interfaccia slave sul bus OPB.

Il codice eseguito e molto simile a quello utilizzato nel test precedente, in

quanto l’unico compito e quello di effettuare letture e scritture sul bus WISH-

BONE, senza eseguire alcuna riconfigurazione dinamica. L’unica differenza so-

stanziale consiste nel fatto che ogni ciclo di scrittura e lettura eseguito sui moduli

riconfigurabili e racchiuso all’interno di due istruzioni che coinvolgono il timer:

prima viene ordinato l’inizio del conteggio, ed al termine viene prelevato il tempo

impiegato. Ovviamente, le invocazioni sono diverse nel caso di PowerPC, in cui

il timer e integrato, e di MicroBlaze, in cui il timer e collegato ad OPB. I valori

raccolti vengono poi inviati via seriale al PC, che li visualizza in un terminale.

Risultati ottenuti Dopo aver eseguito un numero variabile di cicli di scrit-

tura e lettura sul bus WISHBONE, e risultato che i tempi impiegati per un numero

di cicli fissato sono costanti, ed aumentano linearmente con il numero di cicli. In

Tabella 5.4 sono riportati i valori ottenuti, che risultano nell’ordine dei micro se-

condi, sia nel caso di MicroBlaze, sia nel caso di PowerPC. In Figura 5.3, invece,

sono tracciati i grafici con gli andamenti dei tempi in funzione del numero di ope-

razioni. Ovviamente, visto l’andamento lineare, la differenza tra i due processori

tende ad amplificarsi all’aumentare del numero di cicli di scrittura e lettura ese-

guiti, in quanto ad ogni iterazione viene accumulato ulteriore ritardo all’interno

del bus PLB e del bridge.

Numero di cicli di Tempo con PowerPC Tempo con MicroBlazescrittura e lettura (µs) (µs)

1 1,06 0,512 2,16 0,693 3,52 0,884 4,88 1,075 6,24 1,26

Tabella 5.4: Tempi di lettura e scrittura sul bus WISHBONE nel caso di PowerPC eMicroBlaze

I tempi dimostrano che il ritardo introdotto dal bridge che collega i bus PLB

78


Figura 5.3: Grafico delle prestazioni del bus WISHBONE

79


ed OPB non e affatto trascurabile, e le performance dell’infrastruttura di comu-

nicazione risentono molto della sua presenza. La nuova architettura basata su

MicroBlaze ha dunque il vantaggio di sfruttare al meglio le potenzialita di WISH-

BONE, e dunque risulta una scelta indicata per incrementare le performance della

parte riconfigurabile.

Questo test conclude la serie di prove atte a dimostrare la validita delle so-

luzioni proposte per raffinare il funzionamento dell’architettura YaRA. Ulterio-

ri conclusioni e alcuni spunti per sviluppi futuri verranno proposti nel Capitolo

successivo.

80

Capitolo 6

Conclusioni e Sviluppi Futuri

Alla luce di quanto esposto nei capitoli precedenti, si puo affermare che gli obiet-

tivi prefissati sono stati effettivamente raggiunti. Le novita introdotte all’interno

di YaRA, inizialmente frutto di considerazioni teoriche, si sono dimostrate valide

sia a livello implementativo, sia a livello funzionale.

L’introduzione del controller ICAP ha portato ad una perfetta equivalenza tra

YaRA ed il suo predecessore, Caronte, in termini di tecniche di riconfigurazione

supportate e, conseguentemente, di possibili campi applicativi. La riconfigura-

bilita interna si e infatti dimostrata perfettamente funzionante, e le prestazioni

ottenute sono quanto meno paragonabili a quelle dell’architettura Caronte.

L’utilizzo di MicroBlaze si e dimostrato altresı efficente. Infatti, oltre alla

maggiore portabilita auspicata fin dalle fasi iniziali del progetto, si e ottenuto an-

che un notevole vantaggio in termini di prestazioni, che e andato anche al di la

alle aspettative. Pertanto questa nuova soluzione, nonostante sia alla sua prima

implementazione, si dimostra molto promettente e si presta a essere la base di una

serie di sviluppi futuri. Alcuni di questi, maggiormante evidenti e promettenti,

sono elencati di seguito.

In prima istanza e necessario, come gia anticipato, modificare l’interfaccia del

controller ICAP, attualmente collegabile unicamente al PLB, in modo che questo

possa essere utilizzato anche con MicroBlaze. Questa parte non rappresenta una

vera innovazione, trattandosi solamente di un’opera di completamento. Tuttavia,

81

CAPITOLO 6. CONCLUSIONI E SVILUPPI FUTURI

Figura 6.1: Possibile evoluzione di YaRA per l’utilizzo di memorie esterne

essa risulta essenziale per non precludere l’utilizzo della riconfigurabilita interna.

Successivamente, e possibile apportare anche una nuova e piu interessante mi-

glioria, che permettera l’utilizzo, durante la riconfigurabilita interna, di bitstream

differenza di dimensioni maggiori. Essa prevede che la sintesi di MicroBlaze av-

venga sulla parte sinistra dell’FPGA, in quanto in questa posizione sono situati

i piedini per l’accesso alle memorie esterne montate sulla scheda. Ovviamente

dovra essere modificato anche il posizionamento relativo di parte fissa e parte ri-

configurabile. Non potendo modificare la posizione della porta ICAP, che risulta

fissa in basso a destra della FPGA, dovra inoltre essere previsto un ulteriore colle-

gamento, da realizzarsi mediante nuove macro hardware, fra il processore e questa

porta. Uno schema di questa nuova possibile organizzazione e riportato in Figura

6.1.

Concludendo, l’utilizzo i MicroBlaze all’interno di YaRA si e dimostrato una

buona scelta. Essa ha infatti portato numerosi vantaggi senza, per questo, stravol-

gere quanto era stato realizzato fino ad ora. Inoltre, la flessibilita di questo soft

processor potra essere ulteriormente sfruttata per nuovi e interessanti sviluppi.

82

Ringraziamenti

I primi sinceri e sentiti ringraziamenti vanno, ovviamente, a tutte quelle persone

che ci hanno materialmente assistito nella realizzazione di questo lavoro.

In primis, quindi, un doveroso ringraziamento ‘Al Santa’ (al secolo Ing. Marco

Domenico Santambrogio) per il suo indispensabile e insostituibile aiuto ma, so-

prattutto, per la sua infinita pazienza, disponibilita e presenza pressoche costante

in qualunque orario della giornata. A lui va anche riconosciuto l’innegabile meri-

to di trasmettere, prima di ogni altra cosa, l’importanza dello spirito di squadra e

della passione per il proprio lavoro, idee fondamentali che troppo spesso devono

essere accantonate sotto il peso dei ritmi incalzanti imposti dalla vita universitaria.

Il secondo ringraziamento va a tutti i nostri compagni di laboratorio che insie-

me a noi hanno passato l’estate a Milano. A loro va un particolare pensiero, che

sappiamo verra sicuramente ricambiato.

Infine, una doverosa citazione per tutti i docenti incontrati in questi primi tre

anni di vita accademica o, piu precisamente, di vita al Politecnico di Milano. Sa-

rebbe necessario troppo spazio per nominarli tutti singolarmente, tuttavia, ci piace

solo ricordare come ognuno di essi sia stato caratterizzato da un qualche tratto

della propria personalita, che ha contribuito a rendere meno ‘lineari’ le giornate

passate in aula.

IvanIl primo ringraziamento va ai miei genitori, a cui devo praticamente tutto. Il

mio grazie va dunque a loro per tutto quello che mi hanno trasmesso in tutti questi

anni, per la fiducia che hanno sempre riposto in me, e per non aver mai fatto

pressioni nei momenti in cui ho dovuto affrontare delle decisioni difficili.

83

Un ulteriore ringraziamento va al resto della mia famiglia, a tutti i parenti

vicini e lontani, senza esclusione alcuna. A partire da chi, come mio zio Raffaello,

ha iniziato a chiamarmi ‘ingegnere’ con qualche anno d’anticipo. Un paio di righe,

tuttavia, le vorrei spendere per i nonni e per Valentina.

Un grazie dunque a tutti i miei nonni per la loro infinita disponibilita, e per aver

sempre visto il meglio di me. In modo speculare, li ringrazio anche per avermi

intrattenuto con tutti i loro aneddoti, con i pettegolezzi di paese, e con tutte quelle

piccole cose che hanno radicato in me un profondo attaccamento verso la mia terra

e le mie origini.

Altro ringraziamento, che piu che altro e un augurio, e per la piccola cugina

Valentina. L’augurio e ovviamente quello di trovarsi qui, tra vent’anni, in veste di

brillante laureanda.

Un ringraziamento poi a tutti gli amici, ed in particolare a ‘Ul Binda’ (se avessi

scritto Giorgio sicuramente non avrebbe capito), instancabile compagno di tante

trasferte, e fidato consulente in termini musicali.

Infine, un grazie al mio compagno di Tesi, Stefano, per avermi sopporta-

to durante queste interminabili giornate passate in MicroLab. Senza la sua in-

stancabile dedizione al lavoro, probabilmente, a quest’ora non starei scrivendo i

ringraziamenti.

Stefano

Il mio primo ringraziamento personale e per i miei genitori. A loro va innanzi-

tutto la mia piu profonda riconoscenza per avermi permesso di seguire, attraverso

la scuola prima, e l’universita poi, i miei interessi e le mie passioni. Inoltre, e

doveroso ricordare i sacrifici da loro fatti senza i quali non sarei qui, ora, a scrive-

re queste pagine. Infine, un grazie anche per aver scusato la mia scarsa presenza

nella vita di famiglia all’approssimarsi di ogni sessione d’esame e, ancor di piu,

in questo ultimo periodo.

Un grazie speciale alla mia grandissima Amica Lara. Una piccola grande

persona. Servirebbero parecchie pagine per elencarne tutti i meriti, ma sono sicuro

che sia sufficente che questi siano noti a noi due. Mi limito pertanto a ringraziarla

84

per tutto quello che ha fatto per me negli anni passati, per tutto quello che fa

tutt’ora e per tutto quello che sicuramente fara in futuro.

Un altro pensiero va a tutte le altre persone che considero miei Amici, sia-

no essi vicini, lontani, di vecchia o giovane data. Un sincero grazie per il tem-

po che passato insieme finora, e per quello che passeremo in futuro, nonche per

l’impegno profuso nel sopportare un carattere ‘particolare’ come il mio.

Infine grazie anche al mio compagno di tesi, Ivan, per la collaborazione e

l’aiuto, spero reciproci, di questi anni.

85

Bibliografia

[1] Alessio Montone, Antonio Piazzi. YaRA: Un’architettura riconfigurabile

basata sull’approccio monodimensionale.

[2] Wikipedia. Embedded System Design in an FPGA.

[3] Anna Antola. Materiale Reti Logiche A. Dispositivi Logici Programmabili:

Dispositivi Programmabili a due livelli.

[4] Wikipedia. Field-programmable gate array.

[5] Brian Tithecott, SBS Technologies. Why FPGAs are quickly moving into

embedded signal processing systems.

[6] Xilinx Inc. Spartan-3 Advanced Configuration Architecture (XAPP452).

Version 1.0. December 2004

[7] Xilinx Inc. Two Flows for Partial Reconfiguration: Module Based or

Difference Based (XAPP290). September 9, 2004.

[8] IBM. CoreConnect Bus Architecture, A 32-, 64-, 128-bit core on-chip bus

standard.

[9] IBM. 128-bit Processor Local Bus Architecture Specifications, Version 4.6,

July 2004.

[10] IBM. On-Chip Peripheral Bus. Architecture Specifications, Version 2.1.

[11] IBM.Device Control Register Bus 3.5 Architecture Specifications.

87

[12] Silicore OPENCORES.ORG. WISHBONE System-On-Chip (SoC) Archi-

tecture Specification, Revision B.3.

[13] Wikipedia. PowerPC.

[14] IBM. The PowerPC 405(TM) Core. November 1998.

[15] IBM. PowerPC 405 Embedded Core.

[16] Xilinx Inc. MicroBlaze Processor Reference Guide, Embedded Develop-

ment Kit EDK 7.1i. Version 5.1. April 2005.

[17] Xilinx Inc. Fast Simplex Link (FSL) Bus. Version 2.00a.

[18] Xilinx Inc. Virtex-II Pro and Virtex-II Pro X Platform FPGAs: Complete

Data Sheet (DS083). Version 4.5. October 2005.

[19] Fabrizio Ferrandi, Marco D. Santambrogio, and Donatella Sciuto. A desi-

gn methodology for dynamic reconfiguration: The caronte architecture. In

19th International Parallel and Distributed Processing Symposium (IPDPS

2005), 2005.

[20] Alberto Donato, Fabrizio Ferrandi, Massimo Redaelli, Marco D. Santambro-

gio, and Donatella Sciuto. Caronte: a complete methodology to implement

partially dynamically self-reconfiguring embedded systems on modern fpga.

In IEEE Symposium on Field-Programmable Custom Computing Machines

(FCCM 2005), 2005.

[21] Xilinx Inc. FPGA Editor Guide.

[22] Jens Thorvinger. Dynamic partial reconfiguration of an FPGA for compu-

tational hardware support. Master’s thesis, Lund Institute of Technology,

2004.

[23] Alberto Donato, Fabrizio Ferrandi, Marco Santambrogio, and Donatel-

la Sciuto. Operating system support for dynamically reconfigurable SoC

architectures.

88

INTEGRAZIONE DEL SOFT PROCESSOR MICROBLAZE NELL ... · politecnico di milano facolta di` ingegneria corso di laurea in ingegneria informatica integrazione del soft processor microblaze

Text of INTEGRAZIONE DEL SOFT PROCESSOR MICROBLAZE NELL ... · politecnico di milano facolta di` ingegneria...

Slide 1 Topografia – Corso di Laurea in Ingegneria Civile, dell ... · ricavare quelle di elementi finiti tramite integrazione. Slide 4 Topografia – Corso di Laurea in Ingegneria

Lab 4: Simple MicroBlaze Hardware Designumh1759.edu.umh.es/wp-content/uploads/sites/783/2013/02/lab_4_S3E.pdf · Lab 4: Simple MicroBlaze Hardware Design Targeting MicroBlaze™ on

LogiCORE IP MicroBlaze Micro Controller System v1 · MicroBlaze Micro Controller System v1.4 4 PG048 March 20, 2013 Product Specification Introduction The LogiCORE™ MicroBlaze™

Direzione Ingegneria e Verifiche...AGGIORNAMENTO E INTEGRAZIONE LISTINO PREZZI 2016 ANAS S.p.A. - DIREZIONE INGEGNERIA E VERIFICHE NORME TECNICHE E OSSERVATORIO PREZZI Manutenzione

MicroBlaze Micro Controller System v2 - Xilinx · MicroBlaze MCS v2.3 4 PG116 June 24, 2015 Product Specification Introduction The LogiCORE™ IP MicroBlaze™ Micro Controller System

UN MIDDLEWARE JAVA PER L’ INTEGRAZIONE DI … · Seconda Facolt`a di Ingegneria Corso di Laurea in Ingegneria Informatica ... Realizzare una board virtuale che rappresenti i dispositivi

Microblaze Logicore IP Ds865_microblaze_mcs

LogiCORE IP MicroBlaze Micro Controller System v2japan.xilinx.com/.../xilinx2014_4/pg116-microblaze-mcs.pdf · 2020. 10. 14. · MicroBlaze MCS v2.2 5 PG116 April 2, 2014 Chapter

EDK 6.3 MicroBlaze Tutorial in Spartan 3coen.boisestate.edu/smloo/files/2011/11/EDK6.3_Spartan3.pdf · EDK 6.3 MicroBlaze Tutorial in Spartan 3 MicroBlaze System Description In general,

Microblaze MCS Tutorial v3

Bitno o Microblaze Procesoru

MicroBlaze Overview

Microblaze Performance Monitoring Engine

Creating Your First MicroBlaze Design with the Spartan … · Creating Your First MicroBlaze Design with the ... tutorial, the smaller and ... Creating Your First MicroBlaze Design

MicroBlaze Processor Reference Guide

MicroBlaze Tutorial Implementation

Microblaze MCS Tutorial

Microblaze Tutorial

DIBIntegrazione Software via Web-Services - 1 Integrazione Software via Web-Services Tesi di Laurea in Ingegneria del Software Relatori: Prof. Giuseppe

Microblaze loader

Microblaze Soft Processor Core

Integrazione di un protocollo di QKD nella suite IPsec · 2013-07-11 · UNIVERSITA DEGLI STUDI DI PADOVA Dipartimento di Ingegneria dell’Informazione Corso di Laurea in Ingegneria

Embedded Microblaze

Microblaze MCS Tutorial Vivado v1users.wpi.edu/~rjduck/Microblaze MCS Tutorial Vivado v1.pdf · Microblaze MCS Tutorial for Xilinx ... Select IP Catalog from the Project Manager and

MicroBlaze Processor Reference Guide - Xilinx · This guide contains the following chapters: •ter 2, MicroBlaze Architecture, Chap contains an overview of MicroBlaze features as

MicroBlaze Processor Reference Guide - xilinx.com · This guide contains the following chapters: • Chapter 2, MicroBlaze Architecture contains an overview of MicroBlaze features

lab6 microblaze

LogiCORE IP MicroBlaze Micro Controller System (v1.0) · LogiCORE IP MicroBlaze Micro Controller ... LogiCORE IP MicroBlaze Micro Controller System ... EN bit in the PITx Control

MicroBlaze Software Reference Guide - เพื่อแผ่นดินเกิดnarong.ece.engr.tu.ac.th/embedded/document/swref.pdf · · 2007-06-15April 2002 MicroBlaze

Progetto di Integrazione tra ESB Standard · Universita degli` Studi di Bologna Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica Tesi di Laurea in Reti

Documents

INTEGRAZIONE DEL SOFT PROCESSOR MICROBLAZE NELL ... · politecnico di milano facolta di` ingegneria corso di laurea in ingegneria informatica integrazione del soft processor microblaze

Text of INTEGRAZIONE DEL SOFT PROCESSOR MICROBLAZE NELL ... · politecnico di milano facolta di` ingegneria...