Politecnico di Milano · 2007-10-24 · Politecnico di Milano Facolt a di Ingegneria...

Politecnico di Milano

Facolta di Ingegneria dell’Informazione

Corso di Laurea in Ingegneria Informatica

Dipartimento di Elettronica e Informazione

Flusso per la Generazione Automatica di

Controllori per la Riconfigurazione Dinamica

Relatore: Prof. Donatella Sciuto

Correlatore: Marco Domenico Santambrogio

Tesi di Laurea di:

Paolo Roberto GRASSI matr. 669971

Andrea CUOCCIO matr. 669004

Anno Accademico 2006-2007

Per Marco:

”Se non vale la pena fare una ricerca,

non vale neanche la pena farla bene”

Prima legge di Gordon

Per Vincenzo:

”Non replicare mai un esperimento riuscito”

Legge di Fett

Ringraziamenti

I primi ringraziamenti vanno a Marco Santambrogio e Vincenzo Rana, per

averci seguito con incredibile pazienza e dedizione. Grazie veramente, niente

di tutto cio sarebbe stato possibile senza di voi: il vostro entusiasmo ha man-

tenuto vivo il nostro.

Grazie a tutti i ragazzi di DRESD e tutti coloro che lavorano nel MicroLab.

E stato un onore e un piacere lavorare con tutti voi. Ci avete fatto crescere

professionalmente e umanamente. La nostra speranza e di poter collaborare

assieme nei prossimi anni.

Infine, grazie a tutti coloro che ci hanno permesso di arrivare a questo primo

traguardo universitario.

Andrea

Alla mia famiglia che mi ha continuamente sostenuto e incoraggiato fino a

questo momento.

Agli amici compagni di corso con i quali si e passati attraverso questi tre duri

anni.

Agli amici al di fuori dell’universita indispensabile fonte di svago.

Alla promessa fatta sette anni fa, mantenuta fino a questo momento e alla

quale non verro mai a meno.

Paolo

Ringrazio Dio per avermi donato una famiglia che mi ha sostenuto e dato la

possibilita di studiare. Grazie ad Andrea, fedele e operoso compagno in tutto il

percorso in DRESD. Spero, in futuro, di poter ancora lavorare con lui in questo

magnifico gruppo. Un grazie di cuore a Sara per essere riuscita a strapparmi

un sorriso tutte quelle volte che avrei voluto piangere, per avermi fatto capire

quanto sia importante amare ed essere amati. Grazie a tutti i coloro che ho

conosciuto al Politecnico. Senza di loro non sarebbe stato tutto cosı bello. Un

v

vi

ultimo ringraziamento va a Biasi, Luca e Valerio, fedeli compagni delle mie ore

fuori dal Politecnico.

Milano, Settembre 2007

Indice

1 Riconfigurabilita 3

1.1 Field Programmable Gate Array . . . . . . . . . . . . . . . . . . 4

1.2 Caratteristiche di Riconfigurazione . . . . . . . . . . . . . . . . 6

1.2.1 Riconfigurabilita Totale o Parziale . . . . . . . . . . . . . 7

1.2.2 Distinzione in base alla granularita del processo . . . . . 9

1.2.3 Distinzione in base allo stato del dispositivo durante il

processo di riconfigurazione . . . . . . . . . . . . . . . . 10

1.2.4 Distinzione in base alla locazione del dispositivo che

effettua la riconfigurazione . . . . . . . . . . . . . . . . . 11

1.3 Porta ICAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.3.1 Descrizione componente . . . . . . . . . . . . . . . . . . 12

1.3.2 Implementazione . . . . . . . . . . . . . . . . . . . . . . 13

1.3.3 Utilizzo . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.4 Bitstream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.5 IBM CoreConnect . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.6 Software utilizzati . . . . . . . . . . . . . . . . . . . . . . . . . . 19

1.6.1 ISE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

1.6.2 EDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2 Stato dell’Arte 21

2.1 OPB HWICAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.1.1 Interfaccia, struttura e funzionamento . . . . . . . . . . . 22

2.1.2 Pro e contro . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2 ICAP DRESD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24


2.2.2 Pro e Contro . . . . . . . . . . . . . . . . . . . . . . . . 25

vii

viii INDICE

2.3 PLBICAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26


2.3.2 Pro e Contro . . . . . . . . . . . . . . . . . . . . . . . . 26

3 DRC 29

3.1 Problematiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.2 Il controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.2.1 Struttura interna . . . . . . . . . . . . . . . . . . . . . . 31

3.2.2 Funzionamento . . . . . . . . . . . . . . . . . . . . . . . 32

3.2.3 Implementazione Hardware . . . . . . . . . . . . . . . . 33

3.3 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4 DRCgen 41

4.1 Analisi dei requisiti e modellizzazione . . . . . . . . . . . . . . . 41

4.1.1 Grandezze descrittive del DRC . . . . . . . . . . . . . . 41

4.1.2 Relazioni descrittive del DRC . . . . . . . . . . . . . . . 44

4.2 Flusso operativo di DRCgen . . . . . . . . . . . . . . . . . . . . 49

4.2.1 Ricerca della soluzione ottimale . . . . . . . . . . . . . . 49

4.2.2 Funzionamento . . . . . . . . . . . . . . . . . . . . . . . 51

4.2.3 Generazione dell’output . . . . . . . . . . . . . . . . . . 56

4.2.4 Utilizzo dei files di output in EDK . . . . . . . . . . . . 56

5 Risultati Sperimentali 59

5.1 Validazione del modello . . . . . . . . . . . . . . . . . . . . . . . 59

5.2 Test DRCgen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.2.1 Specifica del Solo Vincolo sul Throughput . . . . . . . . 62

5.2.2 Specifica del Solo Vincolo di Area . . . . . . . . . . . . . 62

5.2.3 Specifica di Entrambi i Vincoli . . . . . . . . . . . . . . . 64

5.3 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6 Conclusioni e Sviluppi Futuri 67

6.1 Sviluppi Futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Bibliografia 71

Sommario

Questo lavoro di tesi si colloca all’interno del progetto DRESD (Dynamic Re-

configurability in Embedded System Design) presso il Laboratorio di Microar-

chitetture del Politecnico di Milano.

Con Sistema Embedded [14] (sistema incapsulato) si identificano genericamente

dei sistemi elettronici a microprocessore progettati appositamente per una

determinata applicazione, spesso con una piattaforma hardware ad hoc in-

tegrata nel sistema che controlla e in grado di gestirne tutte o parte delle

funzionalita. Tra le tante applicazioni e implementazioni che rigurdano i sis-

temi embedded, DRESD si colloca nello scenario dei sistemi riconfigurabili su

Field-Programmable Gate Array (FPGA). Questi sistemi hanno la capacita di

modificare nel tempo sia la propria struttura che la propria funzionalita.

Nelle FPGA della famiglia Xilinx [8], la riconfigurabilita e garantita dalla

presenza dell’ICAP (Internal Configuration Access Port) che, tramite un op-

portuno controller, riceve i file di configurazione (Bitstream) e riconfigura il

dispositivo.

Obiettivo generale di questo lavoro di tesi e la creazione di un flusso di

generazione automatica di controllori per la riconfigurazione dinamica.

Da uno studio dello stato dell’arte in materia di controllori di riconfigurabilita,

ci si e accorti che un riconfiguratore muta le sue prestazioni in funzione dello

scenario in cui e immerso. Da qui l’idea di creare un controllore di riconfig-

urabilita seguendo una strada differente. I controllori esistenti sono in grado

di garantire buone prestazioni in una grande vastita di scenari. Dato che lo

scenario e noto a priori, e nata l’idea di construire un riconfiguratore ad hoc,

in modo che esso garantisca ottime prestazioni spaziali e temporali.

Il raggiungimento di questo obiettivo e stato raggiunto a fronte dello sviluppo

del DRC (DRESD Reconfiguration Controller). Questo controllore e dotato di

1

2 INDICE

un buffer di dimensioni arbitrarie ed e interfacciabile su piu bus. Il DRC ha

permesso, quindi, di portare avanti uno studio formale sugli scenari di ricon-

figurabilita in cui esso potrebbe trovarsi. Dopo una accurata modellizzazione

del sistema che sta alla base del DRC, e stato sviluppato DRCgen, un software

in grado di configurare il DRC in base allo scenario in cui esso dovra essere

collocato.

Nel Capitolo 1 verra presentata una panoramica dei sistemi riconfigurabili

introducendo tutte le nozioni di base che serviranno alla comprensione dei

successivi concetti. Nel Capitolo 2 si analizzera lo stato dell’arte in mate-

ria di controllori di riconfigurabilita con un confronto dei pregi e dei difetti.

Finalmente nel Capitolo 3 si presentera la struttura e il funzionamento del

DRC mettendolo a confronto con i controllori esposti al capitolo precedente.

Nel Capitolo 4 si affrontera la modellizzazione del DRC e la sua diretta im-

plementazione: DRCgen. Il Capitolo 5 contiene i test condotti sul DRC e su

DRCgen. Conclusioni e sviluppi futuri sono collocati nel Capitolo 6.

Capitolo 1

Riconfigurabilita

Un dispositivo riconfigurabile ha come caratteristica principale la possibilia

di cambiare comportamento (riconfigurarsi) nel corso del suo utilizzo, senza

dover essere sostituito, in base alle esigenze dell’utente.

In sistemi di questo tipo, le funzioni che devono essere svolte dal dispositi-

vo possono essere divise in moduli, che verranno caricati quando si riterra

necessaria la funzione che implementano. Dispositivi che presentano questa

caratteristica sono ad esempio le Field Programmable Gate Array (FPGA), che

verranno utilizzate in questo lavoro e descritte nel corso del primo paragrafo.

Per poter configurare questi dispositivi ci si serve di un file binario chiamato

Bitstrem che verra creato dopo varie fasi di sintesi. La parte riconfigurabile

piu piccola dell’FPGA viene chiamata frame.

Quando si parla di riconfigurazione e necessario chiarire cosa si intende, infatti

non esiste un unico modo per riconfigurare il dispositivo, ne esistono diversi e

ognuno con delle caratteristiche ben precise, che possono dare indicazioni sulle

modalita e sui problemi legati a quel tipo di riconfigurazione.

Quando si crea un’architettura, uno dei problemi principali e quello di creare

l’infrastruttura di comunicazione. Ad oggi uno standard e rappresentato dal

CoreConnect del’IBM, che presenta una struttura composta da tre bus : Pro-

cessor Local Bus , On-chip Peripheral Bus e Device Control Register bus.

Solitamente le case produttrici delle FPGA mettono a disposizione del proget-

tista i software per poter utilizzare le caratteristiche di questi dispositivi.

Nel corso di questo capitolo verranno descritti gli argomenti appena esposti,

ritenuti importanti per la comprensione dei successivi capitoli.

3

4 CAPITOLO 1. RICONFIGURABILITA

1.1 Field Programmable Gate Array

Una Field Programmable Gate Array (FPGA) [12] e un dispositivo a semi-

conduttore che contiene logica e interconnessioni programmabili che possono

essere configurate in maniera tale da svolgere le operazioni logiche, da quelle

piu elementari come AND,OR,NOT,XOR, a funzioni piu complesse, come ad

esempio funzioni matematiche. Inoltre nella maggior parte delle FPGA questa

logica programmabile include anche elementi di memoria, che vanno dai sem-

plici flip-flops fino a banchi di memoria veri e propri.

I blocchi di logica programmabile (CLB) sono formati da una parte combina-

toria a 4 ingressi (Lookup table) e da una parte sequenziale formata da un

flip-flop. Un esempio di questa struttura e rappresentato in figura 1.1

I blocchi di logica programmabile hanno come ingresso 4 segnali e un segnale

Figura 1.1: schema di una CLB su FPGA della famiglia delle Virtex II

di clock.

Le interconnessioni vengono create tramite apposite strutture chiamate ”

switch matrix ”, che permettono di creare tutti i collegamenti possibili. Tali

collegamenti sono disabilitati inizialmente, poi verranno attivati secondo ne-

cessita.

Inoltre ci sono dei collegamenti che permettono di raggiungere gli Input-Output

Block (IOB), che sono l’interfaccia del dispositivo con il mondo esterno. In

figura 1.2 e rappresentata la struttura delle interconnessioni dei blocchi appe-

na descritti.

1.1. FIELD PROGRAMMABLE GATE ARRAY 5

Figura 1.2: struttura della FPGA

Per specificare il comportamento di questi dispositivi, generalmente il pro-

gettista ne fornisce una descrizione tramite un linguaggio di hardware descrip-

tion language (HDL). I linguaggi HDL piu conosciuti sono il VHDL e il Verilog.

Dopo aver creato un design, per poterlo effettivamente utilizzare, si deve pas-

sare attraverso una serie di passi che dalla descrizione in VHDL/Verilog portera

al bitstream.

Si parte da un processo di sintesi, che verifica la sintassi del codice e analizza la

gerarchia del design, assicurandosi di ottimizzarlo per il dispositivo su cui deve

essere implementato. Viene cosı creato un file .NGC che contiene la netlist1

del design.

Si passa poi ad una fase di translate, che unisce la netlist con eventuali vincoli

posti al design. I vincoli vengono specificati sottoforma di testo in un file

.UCF (User Constraint File) [7]. Tali vincoli possono essere spaziali,temporali

o di sintesi e andranno a determinare come il design verra implementato: ad

esempio un vincolo spaziale indica l’area entro la quale usare la logica per

1La netlist e una descrizione testuale dei collegamenti del circuito. Fondamentalmente

contiene una lista di connettori e una lista di istanze tale che, per ognuna di esse, si ha una

lista di segnali connessi ai suoi terminali.


implementare.

La fase di translate produce un file .NGD (Native Generic Database) che

descrive la logica ridotta a primitive del dispositivo, che serve come input al

processo di mapping. Tale processo ”mappera” la logica definita nel .NGD in

elementi della FPGA, come CLB e IOB. L’output prodotto e un file .NCD

(Native Circuit Description) che fisicamente rappresenta il design mappato sui

componenti dell’FPGA.

Si giunge poi al place & route che istanzia i componenti e instrada le con-

nessioni.Si viene cosı a creare un opportuno NCD che viene utilizzato per la

generazione dei bitstream, che verranno utilizzati per (ri)configurare il dispo-

sitivo.

Infine, sulle FPGA e possibile utilizzare uno o piu processori che permettono

l’esecuzione di programmi scritti in un normale codice ad alto livello come

l’ANSI-C.

Si possono distinguere due diversi tipi di processori:

• hard-processor : sono processori gia presenti fisicamente nel dispositivo,

integrati nel silicio, come il POWER-PC405 nella famiglia di VIRTEX

II Pro della Xilinx [5].

• soft-processor : sono processori che vengono sintetizzati come un nor-

male core e vanno ad utilizzare la logica programmabile presente sul

dispositivo. Un esempio di questo tipo di core e il MicroBlaze [4].

1.2 Caratteristiche di Riconfigurazione

Esistono diversi tipi di riconfigurazione, distinti tra loro da diverse caratteris-

tiche, ognuna della quali porta vantaggi e svantaggi con se. Tali caratteristiche

possono essere divise in base alla globalita o meno della superficie interessata

dalla riconfigurazione, alla granularita della riconfigurazione, se questo avviene

a run-time oppure off-line, e in base alla presenza o meno sul dispositivo del

componente che effettua la riconfigurazione.

La prima caratteristica suddivide la riconfigurazione in totale o parziale, la

seconda in Module-based e Difference-based, la terza in statica o dinamica e

l’ultima in interna ed esterna.

1.2. CARATTERISTICHE DI RICONFIGURAZIONE 7

1.2.1 Riconfigurabilita Totale o Parziale

In base alla totalita o meno della parte interessata dalla riconfigurazione,

si puo distinguere tra riconfigurazione totale, che prevede la riscrittura del

circuito dell’intero dispositivo, o riconfigurazione parziale, che prevede la

riscrittura di singole parti del dispositivo.

Riconfigurabilita Totale: questo e il caso piu semplice di riconfigura-

zione, dato che l’operazione prevede il solo caricamento di un intero bitstream

per aggiornare il dispositivo. Tuttavia in questa operazione si hanno due

inconvenienti non trascurabili: ad ogni riconfigurazione, anche di una piccola

parte, si deve per forza riconfigurare tutto il dispositivo e, durante il processo

di riconfigurazione, si ha una interruzione del servizio.

Riconfigurabilita Parziale: un passo avanti si ha con la riconfigurazione

parziale, che permette di riconfigurare aree del dispositivo dove necessario.

Questo approccio e particolarmente potente, poiche potendo cambiare anche

solo una funzione, si riduce il tempo di riconfigurazione che e legato alla

lunghezza del bitstream.

Per contro la riconfigurazione parziale fa sorgere un nuovo problema, che

si presenta in fase di sintesi dei moduli riconfigurabili e nella creazione dei

bitstream: dato che si ha la possibilita di cambiare i moduli di calcolo in

modo dinamico, non si potra avere la certezza della posizione finale dei moduli

di calcolo duraznte l’utilizzo del dispositivo riconfigurabile. Inoltre bisogna

stare attenti a non riconfigurare parti del dispositivo che sono in uso in quel

momento.

Alcune FPGA della Xilinx permettono solo la riconfigurazione dei moduli

per colonne, come le Virtex II e Virtex II-Pro (altri venditori producono dis-

positivi configurabili per righe), ovvero di aree rettangolari di altezza pari a

quella del dispositivo. Vale a dire che per riconfigurare un modulo bisogna

riconfigurare l’intera colonna che lo contiene, andando ad influenzare tutta la

logica contenuta nel rettangolo. Per quanto riguarda la riconfigurazione per

colonne (o righe), si parla di approccio monodimensionale alla riconfigurabilita.

Infatti anche se e permesso dare vincoli di piazzamento in 2D dei moduli (sotto


opportuni vincoli), non e possibile fare lo stesso per la riconfigurazione. Men-

tre in altre FPGA come la Virtex-4 e la Virtex-5 sono permessi piazzamenti e

riconfigurazione sia in 1D che in 2D.

Vediamo un po’ piu in dettaglio cosa si intende: un vincolo di piazzamento

va ad identificare l’area entro la quale un modulo deve essere mappato. Se

quest’area ha la stessa altezza del dispositivo si parla di vincolo 1D, mentre se

non si e obbligati a raggiungere una tale altezza si puo parlare di vincolo 2D.

Nel caso in cui si ha anche un solo modulo con una altezza minore di quella

del dispositivo, si parla di vincolo 2D.

Parlando di riconfigurazione si e nel caso 1D se l’area piu piccola che puo es-

sere riconfigurata copre comunque in altezza il dispositivo, altrimenti si parla

di riconfigurazione 2D.

Nella Figura 1.3 si possono vedere diversi casi i diversi casi di piazzamento

e riconfigurazione 1D e 2D. In figura 1.3 (1) si ha il caso di piazzamento

e riconfigurazione entrambe 1D: i moduli in verde indicano una situazione

permessa, mentre quelli in rosso indicano una irregolarita nel piazzamento

e/o nella riconfigurabilita. Nel dettaglio in Figura 1.3 (1.a) si puo vedere un

piazzamento 1D permesso, mentre in Figura 1.3 (1.b) si ha un piazzamento

irregolare perche le due aree si sovrappongono. In Figura 1.3 (2) si ha il caso di

piazzamento 2D e riconfigurazione 1D, il quale mostra che in alcuni casi, anche

se si ha la liberta del paizzamento 2D, non e permesso riconfigurare un’area

con un’altezza minore di quella del dispositivo. La Figura 1.3 (2.a) mostra un

caso permesso, mentre la Figura 1.3 (2.b) ne mostra uno irregolare. Infatti

anche se le due aree espresse nei vincoli non si sovrappongono, lo fanno le aree

riconfigurabili il che non e permesso nella riconfigurazione 1D. Infine in Figura

1.3 (3) si possono vedere entrambe: riconfigurazione e piazzamento 2D. Ambo

i casi sono considerati validi.


Figura 1.3: Vincoli 1D e 2D combinati con riconfigurazione 1D e 2D in

differenti scenari appplicativi

1.2.2 Distinzione in base alla granularita del processo

In base alla granularita del processo si puo distinguere l’approccio Module-

based, a grana meno fine in quanto agisce a livello di colonne, e l’approccio

Difference-based, a grana piu fine in quanto agisce a livello di singoli bit.

Approccio Module-based: questo approccio prevede la creazione

dei vari moduli, ognuno dei quali implementa una diversa funzionalita sul

dispositivo. Ciascuno di questi moduli ha la possibilita di essere aggiunto o

rimosso dal sistema individualmente. In questo caso si prevede che se si avvia

il processo di riconfigurazione si abbia l’aggiunta o la rimozione di uno o piu

moduli dal sistema. Allo stato attuale la gestione dei moduli avviene per

colonne (o per righe) e ogni modulo viene allocato in un gruppo di colonne

libere, scrivendo i dati di configurazione frame per frame. Va notato che la

porzione minima su cui e possibile effettuare delle modifiche a questo livello

non e il frame, ma l’intera colonna che e composta da un numero di frame

dipendenti dal tipo di scheda sulla quale si sta lavorando.

Approccio Difference-based: questo approccio puo avvenire a due di-

versi livelli: front-end oppure back-end

Nel primo caso si va a modificare il VHDL/Verilog oppure lo schematico, poi

si deve risintetizzare il progetto che va reimplementato su scheda. Nel secondo

caso le modifiche si fanno sul NCD, che contiene le informazioni del routing

e della logica utilizzati, tramite tool quali FPGA editor e BitGen, con i quali


e possibile la creazione di bitstream che andranno a modificare solo la parte

richiesta. Questa operazione e generalmente molto veloce, in quanto i bit-

stream differenza (vedi 1.4) sono in genere molto piu piccoli di quelli totali di

configurazione.

1.2.3 Distinzione in base allo stato del dispositivo du-

rante il processo di riconfigurazione

Questa caratteristica distingue riconfigurazione statica, ovvero a dispositivo

inattivo, e riconfigurazione dinamica, ovvero si permette alle parti non

interessate dal processo di riconfigurazione di continuare a computare.

Riconfigurazione statica: questo e un approccio molto semplice di

riconfigurazione, in quanto prevede l’aggiunta e la rimozione di moduli

solo quando il dispositivo e inattivo; qualora ci siano delle elaborazioni in

corso e il processo inizia, tali elaborazioni devono essere terminate perche la

riconfigurazione vada a buon fine.

Per contro presenta il grosso svantaggio che, per sostituire anche solo un

modulo, bisogna disattivare il dispositivo per un certo periodo di tempo prima

che riprenda a lavorare con la nuova configurazione. Inoltre non e possibile la

sostituzione di un modulo necessario a supportare una computazione in atto,

poiche si dovrebbe disattivare anche la parte richiedente del nuovo modulo.

Riconfigurazione dinamica: piu complessa e la riconfigurazione

dinamica, che permette la riconfigurazione senza la necessita di disattivare

l’intero dispositivo. Questo permette l’allocazione dei moduli che servono

alla computazione, nel momento in cui servono, garantendo piu flessibilita al

sistema.

Sicuramente presenta aspetti implementativi da non sottovalutare sin dalla

fase di sintesi, nella quale si dovranno creare un gran numero di bitstream,

per poi utilizzarli quando lo si terra necessario.

Nella gestione del processo di elaborazione si dovra tener conto dello stato

in cui si trova la scheda, poiche si sappia quali risorse sono effettivamente

presenti in un determinato momento. Inoltre si dovra garantire l’accesso a


quei moduli non interessati dalla riconfigurazione.

1.2.4 Distinzione in base alla locazione del dispositivo

che effettua la riconfigurazione

Questa caratteristica indica la presenza o meno di quel componente, hardware

o software o una combinazione di entrambi i moduli, atto alla gestione del

processo di riconfigurazione all’interno dell’architettura.

In qualsiasi modo venga implementato, non si pongono restrizioni sul dove

verranno salvati i bitstreams. Solitamente vengono salvati all’esterno del

dispositivo riconfigurabile (ad esempio su delle RAM esterne), poiche la sua

memoria interna disponibile e piuttosto limitata.

Riconfigurazione esterna: il caso piu semplice e quello di avere il gestore

all’esterno del dispositivo, ruolo che puo essere svolto da un computer che ha

senz’altro capacita di calcolo maggiori. In questo caso l’architettura diventa

di fatto una periferica riconfigurabile, gestita da un calcolatore che permette

controlli sulla riconfigurazione anche molto complessi data la potenza di

calcolo maggiore.

Tuttavia questo approccio ha di negativo il fatto che ogni volta che si necessita

di una riconfigurazione si perde molto tempo nel trasferimento dei file di

riconfigurazione. Questo tempo, che comunque puo essere ridotto da strutture

di comunicazione migliori, e comunque una grave perdita per quei sistemi che

richiedono riconfigurazioni piuttosto ravvicinate, poiche bisognera attendere

ogni volta i dati dal sistema esterno.

Riconfigurazione interna: questo e un caso piu interessante da analizza-

re, data la presenza del gestore della riconfigurazione all’interno dell’architet-

tura. Esempi di questo dispositivo sono analizzati nel capitolo 2.

In questo caso si dovra predisporre un’area all’interno del dispositivo dove

collocare il sistema che si occupera del processo di riconfigurazione. Tale area

non dovra essere interessata da tale processo per non comprometterne la fun-

zionalita.

Percio si dovra suddividere il dispositivo in due tipi di aree distinte: una che


si occupera della riconfigurazione del dispositivo, quindi sara una parte fissa

(non interessata dalla riconfigurazione), e una composta da uno piu moduli

riconfigurabili.

Anche se la riconfigurazione interna e piu difficile da realizzare rispetto a

quella esterna ha comunque l’indubbio vantaggio di creare un dispositivo

riconfigurabile stand-alone, che non necessita di supporti esterni.

1.3 Porta ICAP

Nel corso di questo lavoro di tesi prenderemo in considerazione le FPGA

che supportano la riconfigurazione interna. Nella famiglia delle Virtex-II e

Virtex-II Pro e Virtex-4 esiste un componente che prende il nome di Internal

Configuration Access Port (ICAP) che permette di farlo. L’ICAP permette

l’accesso al registro di configurazione del dispositivo, nonche il trasferimento

dati con tale registro, tramite un protocollo che e un subset del protocollo

della SelectMap[3]. Anche l’interfaccia e semplificata rispetto alla SelectMap,

permettendo comunque le operazioni di lettura e scrittura. Tramite la porta

ICAP il richiedente delle riconfigurazione ha la possibilita di intervenire sul-

la configurazione della stessa ed eventualmente modificarla. In particolare, il

processore puo andare a leggere la configurazione dell’FPGA, lavorando su una

porzione minima di dati chiamata ”frame” . Allo stesso modo puo scrivere una

nuova configurazione trasferendo sempre un frame alla volta, oppure passando

un bitstream differenza vero e proprio.

1.3.1 Descrizione componente

Passiamo ora ad illustrare brevemente il significato delle varie porte dell’inter-

faccia:

• I/O: sono rispettivamente le porte di input e output. Il bit 0 e il bit piu

significativo. Vengono selezionate in base al segnale presente sulla porta

WRITE.

• WRITE: questa porta viene utilizzata per discriminare il tipo di opera-

zione in corso. Se e Low indica che e un’operazione di scrittura, percio

1.3. PORTA ICAP 13

viene letto il dato presente sulla porta I . Se e High indica un’operazione

di lettura, percio il dato viene scritto sulla porta O.

• CE: chip enable, abilita le porte di lettura o scrittura. Se e Low abilita la

porta scelta in base al segnale presente su WRITE. Se e High disabilita

le porte di lettura e scrittura.

• BUSY: quando CE e Low, questa porta indica se l’ICAP puo accettare

un altro dato oppure no. Se Busy e Low indica che il prossimo dato

verra accettato sul fronte di salita del Clock quando entrambi CE e Write

saranno Low. Se e High allora l’ICAP rifiuta il dato attuale che dovra

essere ricaricato al prossimo fronte di salita del Clock. Comunque se si

usa il componente con una frequenza inferiore ai 50 MHz il Busy puo

essere ignorato, mentre e indispensabile al di sopra di 50 MHz.

• CCLK: e il clock entrante nel componente che si occupa della sincroniz-

zazione di tutte le operazioni di lettura e scrittura.

1.3.2 Implementazione

Virtex-II e Virtex-II Pro: in queste famiglie la porta ICAP e situata solo

nell’angolo in basso a destra dell’ FPGA.

Va sottolineato che qui le porte di input e di output funzionano solo ad 8-bit.

Tramite VHDL/Verilog e accessibile attraverso la primitiva ICAP VIRTEX2.

Virtex-4: a differenza delle due precedenti famiglie,qui si puo trovare la

porta ICAP sull’FPGA in due locazioni differenti, una in alto e una in basso.

L’implementazione ha due interfacce che condividono la stessa logica di

base. La sola differenza tra le due e la loro posizione sulla FPGA, e le

interconnessioni alle quali possono essere connesse. Da notare che le due

interfacce non devono mai essere attive allo stesso istante [6]. La presenza di

due accessi a tale porta, permette sia una maggiore flessibilita su dove poter

collocare il controller che si interfaccera con l’ICAP, sia la possibilita di poterli

utilizzare contemporaneamente in modo alternato.

Un’altra differenza e che le porte di input ed output sono a 32-bit.

Cio non esclude la possibilita di poter usare l’ICAP a 8-bit: infatti e presente


un opportuno parametro, che puo essere settato durante l’istanziazione, che

permette di specificare la grandezza del dato che si vorra mandare.

Infine, tramite VHDL/Verilog e accessibile attraverso la primitiva

ICAP VIRTEX4.

Figura 1.4: Interfaccie dell’ ICAP VIRTEX2 e ICAP VIRTEX4

1.3.3 Utilizzo

Va notato che per poter utilizzare questo componente, bisogna dotarlo di un

opportuno controller che sia in grado di interfacciarsi sul bus utilizzato per

poter dialogare con questa interfaccia. Oltre a funzioni di dialogo con il bus,

questo controller deve poter svolgere altre funzioni come la gestione del flusso

di dati, la lettura e scrittura di uno specifico frame.

Per poter ignorare il segnale di Busy esistono due alternative possibili:

• Free runnig Clock: si utilizza come clock per il componente quello

utilizzato per il bus. In questo caso il bus non deve avere una frequenza

maggiore di 50 MHz

• Controlled CCLK: si utilizza il clock del bus per controllare una

macchina a stati che genera, in maniera opportuna, il clock adatto per il

funzionamento dell’ICAP

1.4. BITSTREAM 15

Nota bene: sulle schede che usano dispositivi della famiglia delle Virtex 2

e Virtex 2Pro sono presenti dei pin che permettono di abilitare o disabilitare de-

terminati metodi di riconfigurazione. Per poter utilizzare il componente ICAP,

tali pin non devono trovarsi nella configurazione 101, che rende disponibile solo

le modalita JTAG o Boundary Scan , disabilitando l’ICAP.

Figura 1.5: Configurazione dei pin per utilizzo ICAP

1.4 Bitstream

Le FPGA possono essere utilizzate per creare dispositivi capaci di riconfigu-

rare tutta, o parte, della propria architettura al fine di modificare il proprio

comportamento a seconda delle esigenze dello sviluppatore. Una FPGA e in

grado di implementare al suo interno sia la riconfigurabilita di tipo statico

che quella di tipo dinamico. Come gia accennato, l’FPGA puo essere ricon-

figurata utilizzando il file binario generato dai software di sintesi. Tale file,

chiamato bitstream, e in grado di riconfigurare il dispositivo sia totalmente

che parzialmente, specificando la funzione di tutte le sue CLB e instradando

correttamente le linee di collegamento. Ad esempio supponiamo che esistano

due moduli che possono essere usati all’interno dell’architettura. Esisteran-

no percio un bitstream βA che configurera il dispositivo con il modulo A e

un bitstream βB che lo configurera con il modulo B. Pero l’utilizzo dei bit-

stream comporta la riconfigurazione dell’intero dispositivo, con conseguente


interruzione del servizio da parte del dispositivo durante il processo di riconfi-

gurazione. Questo e il caso della riconfigurazione statica. Per poter utilizzare

la riconfigurazione parziale si introduce il concetto di bitstream differenza: tale

file contiene solo le informazioni per passare da una configurazione all’altra del

dispositivo. L’utilizzo di questi bitstream comporta percio la modifica di solo

una parte del dispositivo, mentre l’altra puo continuare a lavorare. Inoltre

hanno il vantaggio di essere di dimensioni molto ridotte rispetto a quelli totali.

Tornando all’esempio precedente, esisteranno un bitstream βA−>B che perme-

ttera di passare dalla configurazione con il modulo A a quella con il modulo

B; esistera poi il bitstream βB−>A, che permettera il passaggio inverso.

Figura 1.6: Bitstream differenza e riconfiguarbilita parziale

Con due moduli ci saranno solo due bitstream differenza, ma con tre mo-

duli il numero cresce a sei, per poi passare a dodici con quattro moduli. Si

ha quindi il problema dell’elevato numero di bitstream differenza da conser-

vare in memoria. Anche con un numero di moduli piuttosto basso, e data la

scarsa disponibilita di memoria sulla FPGA, questo potrebbe diventare una

forte restrizione. Un altro approccio sarebbe quello di avere un bitstream che

istanzia il modulo in un’area vuota dell’FPGA (rappresentato da β−>A) e un

altro che rimuove il modulo dall’area in cui si trova (detto βA−>). In tal caso

ogniqualvolta si debba sostituire un modulo A con B, in una determinata area,

prima la si rende vuota con βA−> poi la si istanzia con B utilizzando β−>B.

1.5. IBM CORECONNECT 17

Figura 1.7: Bitstream differenza sbiancante

Questo procedimento prevede solo due bitstream differenza per ogni

modulo, il che si traduce in un notevole risparmio di spazio di memoria;

tuttavia si raddoppiano i tempi di riconfigurazione. Quindi in fase di

progettazione si dovra trovare un opportuno trade-off in base alle esigenze.

1.5 IBM CoreConnect

La tecnologia CoreConnect sviluppata da IBM e un sistema per la gestione

delle comunicazioni per applicazioni on-chip. A questa struttura vengono at-

tacati dei core, ovvero componenti che implementano unita a se stante di

logica2, provenienti da parti diverse per formare diverse architetture.

Come si puo vedere da figura 1.8, in questa tecnologia vengono implemen-

tati tre bus : Processor Local Bus (PLB),On-Chip Peripheral Bus (OPB) e

Device Control Register (DCR). Solitamente le periferiche piu veloci vengono

attaccate al PLB che presenta una maggiore velocita e minor latenza, mentre

all’OPB vengono attaccati i core piu lenti per ridurre il traffico sul PLB.

2Ad esempio un filtro, un DSP, un controllore della memoria, DMA . . .


Figura 1.8: Struttura della tecnologia CoreConnect dell’IBM

Processor Local Bus (PLB), e un bus sincrono caratterizzato da alte

prestazioni a cui solitamente si collega il processore dell’architettura (da qui il

Processor nel nome). Le sue implementazioni sono caratterizzate dalla possi-

bilita di avere il bus dei dati a 32, 64 o 128 bit, anche se il bus degli indirizzi

rimane sempre a 32 bit per tutte e tre le implementazioni. Oltre a prevedere le

normali operazioni di lettura e scrittura vi e anche la possibilita di effettuarle

in modalita burst, ovvero una volta ricevuta l’autorizzazione dall’arbitro, il

richiedente puo inviare o ricevere un pacchetto di dati ad ogni ciclo di clock.

On-Chip Peripheral Bus (OPB), bus sincrono piu lento e meno com-

plesso del precedente. Anch’esso ha la possibilita di essere usato a 32, 64 e 128

bit, permette le semplici operazioni di lettura e scrittura e in una modalita

burst semplificata rispetto a quella del PLB.

OPB-PLB bridge, e un bridge bidirezionale con un’unica limitazione

(prevista nello standard): il rapporto tra la frequenza di clock del PLB e quella

del OPB e una potenza (ovviamente intera) di due. Spesso nelle architetture

su FPGA si prende un esponente uguale a 0 in modo che i due bus risultino

isocroni e in questo caso si puo notare come, nonostante le prestazioni offerte

dai due bus siano comparabili in condizioni di lavoro medie, si voglia comunque

mantenerli separati per suddividere il traffico delle periferiche piu veloci da

quello delle piu lente.

OPB e PLB arbiter, entrambi i due arbitri hanno una struttura molto

simile, infatti li si puo vedere come due grossi multiplexer. Hanno in ingresso

tutti i segnali dei vari master e in uscita i segnali del bus verso i vari slave,

1.6. SOFTWARE UTILIZZATI 19

che vengono controllati da un master alla volta, dopo che essi hanno ricevuto

l’autorizzazione dall’arbitro.

Esiste una limitazione del numero di master che possono essere connessi all’ar-

bitro, dato che ogni master ha le sue linee dedicate per parlare con l’arbitro,

il che comporta linee dei dati indirizzi e controllo per ogni master, mentre non

si prevede una limitazione per quanto riguarda gli slave dato che condividono

lo stesso canale di comunicazione.

Device Control Register Bus (DCR), anch’esso e un bus sincrono con

10 bit per gli indirizzi e 32 per i dati. Permette il trasferimento dei dati

contenuti nei registri general purpose del processore alla logica slave connessa

al DCR, in questo modo si evita di salvare i registri di configurazione in

memoria, riducendo il carico sugli altri bus.

1.6 Software utilizzati

Nello corso di questo lavoro di tesi sono state usate le FPGA della Xilinx,

percio durante la fase implementativa sono stati utilizzati i software da loro

creati. In questo paragrafo verranno descritti brevemente.

1.6.1 ISE

ISE (Integrated Software Enviroment), e una suite di programmi che permet-

te lo sviluppo completo di un design partendo dallo schematico o dal codice

VHDL/Verilog. Programma centrale e senz’altro Project Navigator, attraverso

il quale e possibile gestire passo per passo il processo di implementazione con

la possibilita di richiamare tutti gli altri programmi della suite.

Principalmente e formato da:

• un editor che permette di lavorare con il codice, schematici o vincoli

fisici. Il piu utilizzato e l’editor di testo che permette la visualizzazione,

nonche la scrittura e modifica del codice VHDL/Verilog.

• una console nella quale si possono leggere tutte le informazioni relative

ai vari passi dell’implementazione, nonche eventuali messaggi di errore e

di warning


• un albero delle risorse nel quale e possibile vedere la struttura del com-

ponente sul quale si sta lavorando, nonche il dispositivo sul quale verra

implementato

• un menu delle funzioni dal quale e possibile accedere a tutte le funzioni di

ISE. Tramite esso si possono lanciare le varie fasi descritte nel paragrafo

1.1 e i relativi programmi che le svolgono.

E importante citare FPGA editor, utile per visualizzare il risultato del

processo di Place & Route in un disegno elettronico che mostra come verranno

effettivamente programmate e interconnesse le singole CLB e Switch Matrix.

Mette inoltre a disopsizione delle funzioni per la modifica del design anche se

le modifiche normalmente fatte sono molto piccole.

1.6.2 EDK

EDK(Embedded Development Kit), e un programma utilizzato per la gestione

degli IP-CORE, gia esistenti o creati e importati dall’utente, al fine di creare

un’architettura CoreConnect desiderata.

Per l’utilizzo delle sue funzioni si appoggia su ISE. Importanti da citare sono:

• Create/Import peripheral, tramite la quale e possibile gestire la creazione

di un nuovo IP-CORE oppure l’importazione di uno gia esistente, rifer-

endosi ad un progetto di ISE oppure ai file di codice e gli NGC che

formano il core.

• Application, tramite il quale e possibile aggiungere e gestire i sorgenti

software che gireranno sul processore (PowerPC o MicroBlaze). Il lin-

guaggio riconosciuto e l’ANSI-C. Una volta compilato, EDK provvedera

ad unirlo al bitstream che descrive l’architettura creata.

E importante citare anche SDK, un ambiente di sviluppo che si appoggia

ad Eclipse per la gestione delle librerie e i file .h usati nei programmi che poi

gireranno sulla FPGA. Tra queste e importante xparameters.h che contiene

tutti i parametri dei vari IP-CORE dell’architettura, tra cui anche lo spazio

degli indirizzi a loro riservato.

Capitolo 2

Stato dell’Arte

Per poter utilizzare la porta ICAP, non la si puo collegare semplicemente al

bus del sistema, infatti si deve creare un componente opportuno che ha come

compito essenziale quello di permettere il dialogo tra i due. Principalmente

come struttura di collegamento tra i vari core dell’architettura viene usato il

CoreConnect dell’IBM (vedi paragrafo 1.5) che mette a disposizione i bus OPB

e PLB per l’interfacciamento.

Le interfaccie sul bus possono essere slave o master : solitamente le slave per-

mettono funzioni limitate al solo dialogo che e permesso nel momento in cui un

master le designa tramite il bus degli indirizzi; le interfacce master presentano

il vantaggio di poter richiedere i bus quando lo ritengono necessario, percio

olter ad essere piu complesse, mostrano anche funzioni migliori rispetto alle

slave.

Oltre alle interfacce, alcune volte si ritiene necessario l’utilizzo di una memoria

interna per poter gestire il flusso dei dati oppure anche un protocollo di comu-

nicazione che mette a disposizione funzioni piu complesse rispetto alle normali

funzioni di lettura e scrittura.

Nel corso di questo capitolo verranno presi in analisi tre core gia esistenti che

si interfacciano con il componente ICAP, spiegandone il funzionamento, pregi

e difetti di ognuno.

I core che prenderemo in considerazione saranno:

• OPB HWICAP reperibile nella libreria di EDK della Xilinx [11]

• ICAP DRESD sviluppato nel laboratorio di microarchitetture presso

il Politecnico di Milano dal gruppo D.R.E.S.D. . [9]

21

22 CAPITOLO 2. STATO DELL’ARTE

• PLBICAP sviluppato presso la Technische Univetsitat Munchen[2]

2.1 OPB HWICAP

In questo paragrafo verra preso in considerazione un componente gia esistente

nella libreria di EDK : l’OPB HWICAP; ne verranno analizzate l’interfaccia su

bus, struttura interna e funzionamento, terminando con conclusioni sui pregi e

difetti di questo dispositivo. Tramite il dispositivo e possibile effettuare sia la

configurazione, sia readback, cioe la possibilita di leggere lo stato del registro

di configurazione. Questo permette di verificare la correttezza della corrente

configurazione di ogni CLB e IOB, nonche il valore corrente nelle LUT RAM

e nelle BRAM.

2.1.1 Interfaccia, struttura e funzionamento

Interfaccia su bus: come si puo subito capire dal nome, l’HWICAP ha una

interfaccia slave sul bus OPB. Questa parte del dispositivo si occupa solamente

di tradurre i segnali che arrivano dal bus, in segnali interpretabili dalle parti

piu interne.

Figura 2.1: Interfaccia dell’OPB HWICAP

2.1. OPB HWICAP 23

Struttura interna: oltre all’interfaccia e alla porta ICAP, questo

dispositivo e anche composto da:

• un controllore che si occupa di decodificare i comandi che gli vengono

comunicati da bus, occupandosi della gestione del flusso di dati da e/o

verso la BRAM con il Bus

• una memoria costituita da una Block RAM (capacita 512 Byte),

che permette l’interfacciamento con i dati sia a 8 che a 32 byte

contemporaneamente

• un controller che si occupa della gestione dei dati da e/o verso l’ICAP

con la BRAM

Figura 2.2: OPB HWICAP

Funzionamento: il processo di riconfigurazione e portato a termine da

un meccanismo di lettura-modifica-scrittura. Per modificare il circuito del-

l’FPGA, la periferica determina quali frame di configurazione devono essere

modificati, poi legge il contenuto di ogni frame, uno alla volta da una BRAM.

Il contenuto di ogni frame e modificato prima di essere scritto dall’ICAP. Il

meccanismo di lettura-modifica-scrittura e effettuato un singolo frame alla vol-

ta. Per quanto riguarda il readback, i frame sono riletti dentro la BRAM e poi

estratti i bit che interessano.


2.1.2 Pro e contro

Una buona caratteristica di questo componente e la possibilita di trasferire

blocchi di 4 byte per volta dal bus, pero dato il funzionamento a singoli byte

della porta ICAP, si e riscontrata la necessita di inserire un dispositivo che

permettesse sia la lettura che la scrittura a 8 e 32 bit contemporaneamente.

Questo componente e stato implementato tramite un controllore di bram che

si occupa della gestione degli indirizzi.

L’utilizzo di bram come memoria fa in modo che solo la restante parte del

core venga implementata in slice, il che rende l’occupazione d’area per questo

componente trascurabile. Tuttavia la sua modalita di funzionamento lo rende

particolarmente lento e la mancanza di segnali di interrupt implica il fatto che

per tutto il tempo in cui e in funzione esso tiene occupato anche il bus che non

puo rendersi disponibile per altri scopi.

Infine la sua interfaccia e solo sul bus OPB, il che lo rende ancora piu lento in

una architettura che usa il PowerPc: infatti in una architettura di questo tipo,

i controller delle bram si trovano sul bus PLB, percio, per trasferire dei dati

verso l’HWICAP, si rende necessario attraversare anche un bridge PLB-OPB.

Inoltre la scarsa documentazione messa a disposizione della stessa Xilinx ne

rende difficile l’utilizzo.

2.2 ICAP DRESD

Questa versione del gestore della riconfigurabilita e stato sviluppato nel labo-

ratorio di microarchitetture del Politecnico di Milano, all’interno del gruppo

D.R.E.S.D. . Questo componente presenta enormi differenze rispetto all’HW-

ICAP e, nonostante sia piu semplificato rispetto a quello precedente, permette

sia la riconfigurazione sia il readback.


Interfaccia: una prima differenza risiede nel fatto che presenta un’interfaccia

sul bus PLB anziche sull’OPB, seppur rimane un’interfaccia slave. Questa

parte del componente permette sempre di dialogare con il bus, anche se

questa volta risulta un po’, ma non molto, piu complesso. Va notato che

normalmente il bus PLB trasferisce 64 bit alla volta, per questo all’interno

2.2. ICAP DRESD 25

dell’interfaccia e predisposta una parte apposita per la selezione della word

d’interesse, scelta fatta in base al valore del segnale Byte enable del PLB.

Struttura interna: la struttura interna e molto semplice, dato che e

composta solamente dall’interfaccia IPIF e da una macchina a stati che serve

per il trasferimento dei dati da e verso l’ICAP. Questa macchina a stati non

prevede l’utilizzo del segnale di busy dell’ICAP, percio, come gia accennato,

si dovra o far funzionare il PLB a 50 MHz oppure si deve controllare il Clock

dell’ICAP, in modo tale da farlo andare al massimo a 50 MHz.

Funzionamento: l’utilizzo di questo componente e molto semplice: si

invia il bitstream in blocchi di 8 bit per volta (la posizione del byte deve essere

quella meno significativa), utilizzando la funzione XIo Out8(Address,Data)

della libreria xio messa a disposizione da SDK. Nel campo Address si deve

indicare il BASEADDRESS del componente che si puo o inserire di vol-

ta in volta nel programma, una volta assegnati gli indirizzi con EDK, op-

pure importando la libreria xparameters e richiamando il base address at-

traverso XPAR BASEADDR NOMEDELL’ISTANZA. Ad esempio se il com-

ponente si chiamasse ICAP CORE 0 (lo 0 indica il numero dell’istanza una

volta che verra usato in EDK) esistera in xparameters una costante di nome

XPAR BASEADDR ICAP CORE 0 che conterra il suo base address. Come

Data bisognera inserire il Byte da passare.

2.2.2 Pro e Contro

L’occupazione di questo componente e relativamente piccola rispetto all’HW-

ICAP, grazie alla sua semplicita, dovuta soprattutto al suo funzionamento a 8

bit che rende il componente libero di dialogare direttamente con l’ICAP senza

l’utilizzo di registri che permettano il passaggio da 32 bit a 8 bit. Inoltre, come

appena descritto, e anche molto piu facile da utilizzare rispetto al precedente.

Comunque questa semplicita viene pagata proprio dal suo funzionamento a

8 bit, che rallenta in modo considerevole la velocita di trasferimento verso

l’ICAP. Inoltre, ignorando il segnale di busy dell’ICAP, si rallenta ancor di piu

la velocita di trasferimento. Un’altra limitazione e determinata dalla sua sola

interfaccia sul bus PLB che ci riporta al problema analogo, ma sul versante


opposto, che ha l’HWICAP : in una architettura con MicroBlaze si dovra

passare per un Bridge per arrivare sul PLB e infine a questo componente.

2.3 PLBICAP

Nella creazione di questo componente e stato preso in considerazione lo spinoso

problema dell’accelerazione del processo di riconfigurazione.

Accelerazione raggiunta sia dalla presenza di un DMA nell’interfaccia del com-

ponente, sia soprattutto alla compressione dei bitstream legata allo sviluppo

di questo componente.


Interfaccia: come appena accennato, questo controller ha un DMA (Direct

Memory Access) presente nella sua interfaccia che deve essere, ovviamente,

master sul bus PLB.

Struttura interna: oltre al gia citato DMA, l’interfaccia master, e un con-

troller per l’ICAP, e presente anche un registro di tipo FIFO, per la corretta

gestione del flusso di dati.

Funzionamento: data la presenza del DMA, il processore deve solo indi-

care l’indirizzo iniziale e finale dove andare a prendere il bitstream, che dovra

gia essere memorizzato in una parte accessibile dall’architettura. Una volta

che il processo di riconfigurazione ha inizio, il DMA continuera a fare dei

trasferimenti in modalita burst 1 sul bus.

2.3.2 Pro e Contro

L’indubbio vantaggio di questo componente e la presenza del DMA. Essa per-

mette al processore di poter lavorare senza doversi occupare del trasferimento

dati, aumentandone anche la velocita. Difatti in questo caso i dati vengono

presi direttamente dalla memoria, anziche passare prima dal processore,

inoltre la modalita burst permette di evitare la richiesta di utilizzo del bus

ogniqualvolta si richieda un trasferimento di dati. Da notare che i tempi di

1si indica con burst un trasferimento che non richiede piu di chiedere all’arbitro il

permesso per utilizzare il bus

2.3. PLBICAP 27

riconfigurabilita raggiunti da questo componente sono in maggior parte legati

alla compressione dei bitstream che ne riduce la grandezza in percentuale

maggiore rispetto ai bitstream differenza.

In tabella 2.1 sono riassunte le principali caratteristiche tecniche dei core

visti in questo capitolo:

Caratteristiche/Core OPB HWICAP ICAP DRESD PLBICAP

Interfaccia OPB slave a 32 bit PLB slave a 8 bit PLB master DMA(bus width n.d.)

Memoria SI NO SI

Dimensione memoria 512 byte / 1024 byte

Implementazione memoria 1 BRAM / 2 BRAM

Gestione handshaking icap SI NO SI

Frequenza funzionamento ICAP OPB CLK ≤ 50MHz PLB CLK

Tabella 2.1: Riassunto delle caratteristiche principali dei core di

riconfigurazione visti in questo capitolo

Capitolo 3

DRC

Nel capitolo precedente sono stati analizzati dei controllori dell’ICAP tuttora

esistenti, che tuttavia presentano lo svantaggio di non utilizzare la velocita

dell’ICAP al massimo delle sue capacita. Per tempo di riconfigurazione si

intende l’intervallo di tempo tra il passaggio del primo frame all’ICAP, fino

alla computazione dell’ultimo. Un problema molto spinoso nei sistemi riconfi-

gurabili e l’accelarazione del processo di configurazione. Questo e un aspetto

molto importante, in quanto permette di creare architetture piu complesse e

di aumentare l’affidabilita di quei sistemi che per vari motivi richiedono una

veloce risposta. Tutti i controller visti nel Capitolo 2 presentano la possibilita

di essere interfacciati solo su un determinato bus e utilizzano sempre la stessa

quantita di memoria, rendendoli poco adattabili alle varie architetture.

In questo capitolo verra analizzato il controller di riconfigurabilita creato nel

corso di questo lavoro di tesi.

29

30 CAPITOLO 3. DRC

3.1 Problematiche

Tutti i controller tuttora esistenti presentano varie caratteristiche che rallen-

tano il processo di riconfigurazione, talvolta queste caratteristiche negative

vengono controbilanciate dalle semplicita implementative di questi core. Si

e visto che l’HWICAP ha come inconveniente il suo protocollo di modifica

del registro di configurazione: infatti legge la configurazione esistente tramite

l’ICAP e la salva su una sua cache interna, il processore la modifica e la ri-

manda all’ICAP. L’inconveniente dell’ICAP DRESD e il suo lavorare a 8 bit

e vincolare il clock dell’ICAP a meta del clock del processore: questo aspetto

rallenta molto sia il throughput dell’ICAP, sia quello del bus che deve ogni

volta aspettare che l’ICAP abbia finito di lavorare. Del terzo core non si puo

dire molto date le scarse informazioni a disposizione. Tuttavia si puo notare

che oltre la presenza del DMA e all’utilizzo del segnale di busy dell’ICAP,

non si e fatto niente dal punto di vista hardware per velocizzare il processo di

riconfigurazione, aspetto preso in considerazione con la sola compressione del

bitstream.

Infine tutti controller esaminati finora hanno l’interfaccia su un unico bus,

quindi, per poter essere usati, si deve prevedere l’utilizzo di bridge da un bus

ad un altro, ove quella richiesta per il controller non sia presente nell’architet-

tura. Questo comporterebbe un grosso svantaggio in quanto il passaggio per il

bridge rallenterebbe il trasferimento dei dati sul bus, dunque anche il processo

di riconfigurazione, impedendo anche l’uso del bus ad altri core che necessitano

del bus.

Vari aspetti devono essere presi in considerazione nella creazione di un con-

troller che deve da un lato velocizzare il processo di riconfigurazione, dall’altro

non deve occupare un eccessivo numero di risorse.

L’unico modo per velocizzare il processo di riconfigurazione e tentere di utiliz-

zare il 100% del throughput dell’ICAP: questa e la massima velocita con cui

si potra riconfigurare.

Il secondo aspetto deve tenere in considerazione parametri come l’overhead sul

bus e l’occupazione di area sulla scheda. Un modo per aumentare il through-

put del bus puo essere quello di inviare pacchetti da 32 bit invece che da 8 bit,

tuttavia bisogna tenere conto che l’ICAP funziona a 8 bit: questo comporta

l’ulteriore problema di introdurre una coda che divida i 32 bit in quattro pac-

3.2. IL CONTROLLER 31

chetti da 8 bit da passare all’ICAP.

L’introduzione di questo meccanismo puo portare a pensare che il throughput

del bus si maggiore di quello con cui puo lavorare l’ICAP: questo non e del tutto

vero. Infatti si deve tenere conto che i dati vengono inviati dal processore che

deve prima reperirli dalle memorie oppure dalla porta seriale, invece l’ICAP

puo accedere direttamente ai dati che saranno gia presenti nella coda. Percio,

anche se si e aumentata sensibilmente la velocita di riconfigurazione, si ha

ancora una grande percentuale di throughput dell’ICAP inutilizzato.

Si puo quindi pensare di trasferire una parte del bitstream in una apposi-

ta memoria interna al controllore, memoria che comunque sara minore della

grandezza del bitsream, e poi far partire il processo di riconfigurazione una

volta che la memoria sia stata riempita per una certa percentuale. Si viene a

creare cosı una sorta di ”vantaggio” a favore del bus, che permette ad entrambi

di lavorare al massimo del loro potenziale.

Detto questo bisogna tener conto che la grandezza della memoria non dovra

occupare una percentuale rilevante della FPGA, altrimenti non varrebbe la

pena l’utilizzo di un tale controller.Per quanto riguarda la versatilita sul bus,

basta creare delle interfaccie intercambiabili in modo tale da poter avere la

massima liberta possibile nella creazione dell’architettura.

3.2 Il controller

Nel corso di questo paragrafo verra esposto nel dettaglio il controller DRC:

si procedera alla descrizione della struttura interna e del funzionamento del

componente, concludendo con la spiegazione delle sue implementazioni.

3.2.1 Struttura interna

Il DRC e composto da tre parti principali:

• l’interfaccia IPIF che puo essere sia su bus PLB che su bus OPB;

• il controller vero e proprio che comprende :

– una buffer a 32 bit di grandezza variabile

32 CAPITOLO 3. DRC

– una coda a 8 bit per l’invio dei dati all’ICAP

– registri di controllo

– due macchine a stati: una per la lettura e una per la scrittura su

buffer

• e l’ICAP vero e proprio.

Figura 3.1: Struttura interna DRC

3.2.2 Funzionamento

Prima di passare a descrivere l’implementazione nel dettaglio, verra prima

analizzato il funzionamento genereale del DRC.

Come gia accennato, la velocita con cui l’ICAP processera i dati sara mag-

giore della velocita con cui il bus riuscira a passarglieli, quindi si e prevista

una memoria tampone che verra precaricata prima di iniziare il processo di

riconfigurazione. Comunque non verra riempita totalmente, si arriva fino ad

una percentuale della memoria (denominata l), in modo tale da permettere

al bus di continuare con l’invio del bitstream mentre l’ICAP ha iniziato a

lavorare.

In tal modo si ottiene che per un certo lasso di tempo, sia bus che ICAP

lavorano al massimo possibile, garantento un aumento nella velocita di ricon-

figurazione. Una volta che l’ICAP ha ”raggiunto” il bus, smette di lavorare

in attesa di altre ”l” word. Quando la soglia verra superata ancora, l’ICAP

riprendera a lavorare.


Tuttavia va notato che non sempre accade che l’invio dell’ultimo pacchetto si

ha mentre l’ICAP e in funzione. Si ha quindi la possibilita di trovarsi in una

situazione tale per cui l’ICAP abbia raggiunto il bus, e che stia aspettando

altre ”l” word, mentre la rimantente parte del bitstream sia minore di l: ci

si troverebbe quindi ad aspettare indefinitamente l’arrivo di un numero di

pacchetti che permettano il superamento della soglia.

Si e quindi previsto un flag che indichi la presenza dell’ultimo pacchetto in

memoria e che, quando viene attivato, fara partire il processo di riconfigu-

razione anche se nel buffer ci saranno meno di l pacchetti. Un bitstream,

tuttavia, non e sempre multiplo di quattro byte: si ha quindi un problema

nella gestione dell’ultimo pacchetto che puo avere una lunghezza variabile tra

uno e tre byte.

Per evitare di passare all’ICAP piu byte di quelli contenuti nel bitsream, com-

promettendo il processo di riconfigurazione, si e pensato di inviare l’ultimo

pacchetto specificando nell’indirizzo che e l’ultimo, indicando anche quanti

sono i byte effettivi che deve leggere.

Questo e l’unico caso in cui si utilizza il bus degli indirizzi per indicare qual-

cosa di diverso dal solo BASEADDRESS: l’onere dell’indirizzamento del buffer

e lasciato a dei registri ad auto incremento che indicheranno gli indirizzi da

cui leggere e scrivere, e previsto anche un registro addizionale per indicizzare

i singoli byte all’interno di una word (dipende dall’implementazione, guardare

paragrafo successivo). Nel controller e inoltre presente un una coda che ha il

compito, data una word, di passare all’ICAP i singoli byte. Va infine detto che

il buffer a 32 bit ha la possibilita di poter variare la sua grandezza in modo

tale da permettere di adattarlo all’architettura sulla quale prestera servizio.

3.2.3 Implementazione Hardware

Esistono diverse implementazoni del DRC, ognuna delle quali presenta

modalita di funzionamento leggermente diverse dalle altre, anche se manten-

gono lo stesso comportamento generale. Tutti i file che lo compongono sono

stati scritti in VHDL.

Sono due le principali caratteristiche che differenzaino le varie implementazioni

di questo controller :

• il tipo di interfaccia sul bus :

34 CAPITOLO 3. DRC

– PLB

– OPB

• dove viene allocato il buffer interno al controllore :

– in Slice

– in BRAM

La possibilita di cambiare l’interfaccia permette al DRC di connettersi a

qualsiasi bus si voglia; tuttora vengono usati principalmente i bus PLB e OPB

del CoreConnect dell’IBM, ma nulla vieta di poter creare un’altra interfaccia

su un altro bus che possa essere aggiunta alle altre purche mantenga lo stesso

protocollo con il controller. Anche se su bus diversi, le due interfaccie presen-

tano le stesse funzionalita, infatti entrambe hanno un’interfaccia slave sul bus

e il loro unici compiti sono quelli di ricevere i pacchetti dal bus e/o l’invio di

pacchetti e ackwnoledge dal controller. Va notato che come occupazione di

area sul dispositivo, l’interfaccia PLB sara sempre maggiore di quella su OPB,

dato il maggior numero di segnali e un protocollo un po’ piu complesso da

gestire.

Tuttavia la differenza sostanziale esistente tra le varie implementazioni e nella

scelta del tipo di memoria usata per il buffer : si puo scegliere se utilizzare

le Slice come memorie oppure utilizzare direttamente le BRAM. Entrambe

hanno lo stesso funzionamento anche se i sistemi per la gestione degli indirizzi

e nell’implementazione della coda che effettua la conversione da 32 a 8 bit sono

leggermente diversi.

L’interfaccia del controller e la stessa per entrambe le implementazioni:

• Input

– Data : std logic vector (0 to 31);

– Address : std logic vector(0 to 31);

– reset : std logic;

– Enable : std logic;

– Clk : std logic;

– RNW : std logic;


• Output

– read data : std logic vector(0 to 31);

– buffer ack : std logic

Ora si passera a descrivere in dettaglio i due file VHDL che descrivono il

comportamento dei due controller:

slice : il buffer viene implementato tramite un array di larghezza 32

bit e di profondita pari ad un generico chiamato BUFFER SIZE. La coda

viene realizzata nello stesso modo, ma ha una larghezza da 8 bit e una

profondita di 4, ovvero e una coda di 4 byte. Gli indirizzi vengono gestiti da

tre registri:

• NAW che indica il prossimo indirizzo dove scrivere

• CAR32 che indica la posizione corrente di dove andare a leggere la word

nel buffer

• CAR8 che indica quale byte inviare all’icap della coda

A parte l’ultimo che e di tipo integer in un range da 0 a 4, i primi due sono

di tipo integer di lunghezza compresa tra 0 e BUFFER SIZE, in modo tale da

occupare solo le risorse strettamente necessarie.

La gestione dell’ultimo pacchetto e affidato a tre registri :

• last byte che indica la presenza dell’ultimo pacchetto nel buffer

• last address che indica la posizione dell’ultimo pacchetto nel buffer

• LAST che indica il numero di byte da leggere dall’ultima word

Infine il registro rec permission indica se procedere o meno alla fase di

riconfigurazione.

Il buffer ha un comportamento di tipo FIFO che viene realizzato tramite

un’apposita gestione dei registri di indirizzamento: innanzitutto sono registri

che vengono autoincrementati ogni volta che c’e una operazione di lettura

e scrittura e, una volta terminato lo spazio di indirizzamento, ripartono

36 CAPITOLO 3. DRC

dal primo indirizzo in modo tale da ottenere un indirizzamento ciclico. Nel

controller sono presenti due macchine a stati, che hanno il compito di gestire in

modo distinto le operazioni di lettura e di scrittura. Entrambe hanno la stessa

struttura di base, che poi si differenziera nella operazione di memoria svolta

determinando un differente incremento di registro. Questa differenziazione dei

processi di lettura e di scrittura e quello che permette al controller l’accesso

della memoria sia in letura che in scrittura contemporaneamente. All’inizio le

macchine si troveranno in uno stato di RESET, che ha il compito particolare

di azzerare i registri di indirizzamento e di inizializzare gli altri. Si passera poi

in un altro stato dove si attendera la richiesta di scrittura di un pacchetto da

bus oppure la richiesta di lettura di un byte dall’ICAP.Nello stato successivo si

esegue l’operazione richiesta e l’invio dell’ackwnoledge del suo completamento,

per poi passare direttamente ad uno stato in cui si aggiornano i contatori

e infine si arriva ad uno stato nel quale si attende che la richiesta venga

terminata. Poi si ritorna nello stato di attesa della richiesta. In figura 3.2

viene rappresentato schematicamente lo schema della macchina a stati.

Figura 3.2: Gestione delle operazioni di lettura e scrittura


Infine la gestione del flusso dei dati verso l’ICAP puo essere schematizzata nel

modo segnuente:

1. pacchetti da 32 bit arrivano dal bus e vengono salvati nel buffer, nella

locazione indicata da NAW

2. quando si raggiunge la condizione di start, rec permission viene imposta-

to a 1 e ha inizio il processo di riconfigurazione

3. se il processo di riconfigurazione e attivo viene prelevata la word indicata

da CAR32 e viene messa nella coda a 8 bit

4. se il processo di riconfigurazione e attivo il byte indicato da CAR8 viene

passato all’ICAP

5. quando CAR8 ha passato tutti e 4 i byte contenuti nella coda, ritorna a

segnare la posizione zero e si incrementa CAR32 di uno

In figura 3.3 si puo vedere la struttura del buffer implementato in slice.

Figura 3.3: Flusso dati verso l’ICAP

38 CAPITOLO 3. DRC

bram : in questo caso sia il buffer a 32 bit che quello a 8 bit sono imple-

mentati nelle BRAM, ognuna delle quali puo contenere fino a 512 Byte. In

quasto caso si ha il vantaggio di poter creare delle interfaccie alla memoria

tramite le quali si ha la possibilita di accedervi sia a 32 bit che a 8 bit con due

porte differenti, ovvero queste interfaccie prevedono una gestione di uno stesso

spazio di memoria con accessi sia a 32 bit che a 8 bit. In questo caso sia il

buffer da 32 che la coda da 8 sono la stessa entita, quindi in lettura non si avra

piu il problema di estrarre i singoli byte dalle word, dato che in questo caso

vi si puo accedere direttamente. Anche in questa implementazione si hanno

le due macchine a stati per la gestione della lettura e della scrittura, e si ha

lo stesso modo di segnalazione dell’ultimo pacchetto. Differenza sostanziale

si ha nella gestione del flusso dei dati verso l’ICAP, infatti esisteranno solo

due registri degli indirizzi, uno per scrivere a 32 bit e l’altro per leggere a 8

bit.Questo permette nella gestione dell’ultimo pacchetto di specificare diretta-

mente la posizione dell’ultimo byte, in quanto si puo direttamente calcolare il

suo indirizzo, che verra segnato come ultimo byte da leggere.

In questa implementazione non c’e un buffer size che indica indica la grandezza

della memoria, infatti usando un certo numero di BRAM, non avrebbe alcun

senso sfruttarle solo in parte. Infatti in questo caso si avranno dei generics

relativi alla grandezza dei bus degli indirizzi e quanto sono grandi NAW e

CAR8, che saranno multipli di 512. Da notare che in questo caso CAR8 sara

sempre 4 volte NAW e gli indirizzi della parte a 8 bit avranno sempre 2 bit in

piu rispetto alla parte a 32.

3.3. CONCLUSIONI 39

3.3 Conclusioni

Nel corso di questo capitolo si sono descritti gli aspetti implementativi del

DRESD Riconfigurable Controller, in Tabella 3.1 lo si puo confrontare con i

core esaminati nel capitolo precedente.

Si nota che il DRC presenta una vasta gamma di possibili implementazioni, sia

sul fronte delle interfaccie che sul fronte della memoria, il che lo rende molto

piu versatile rispetto agli altri.

Nel capitolo 4 verra fatta un’analisi del funzionamento di questo componente

e verra spiegato il modo con cui verra generata la soluzione migliore rispetto

alle richieste del progettista.

Caratteristiche/Core OPB HWICAP ICAP DRESD PLBICAP DRC

Interfaccia OPB slave a 32 bit PLB slave a 8 bit PLB master DMA(bus width n.d.) PLB/OPB slave a 32 bit

Memoria SI NO SI SI

Dimensione memoria 512 byte / 1024 byte Variabile all’implementazione

Implementazione memoria 1 BRAM / 2 BRAM Slice o BRAM

Gestione handshaking icap SI NO SI SI

Frequenza funzionamento ICAP OPB CLK ≤ 50MHz PLB CLK Bus Clock

Tabella 3.1: Il DRC confrontato con i core del Capitolo 2

Capitolo 4

DRCgen

DRCgen e uno strumento software che ha il compito di trovare la migliore con-

figurazione del DRC, adattandone le caratteristiche allo scenario in cui dovra

essere collocato, e garantendo, ad esempio, i vincoli su throughput e l’area

imposti dall’utente. DRCgen basa la sua efficacia su un modello formale del

DRC, che consiste in una modellizzazione dei parametri che ne caratterizzano

il funzionamento. La modellizzazione garantisce una stretta affidabilita dei

risultati al mondo con cui il DRC dovra relazionarsi.

4.1 Analisi dei requisiti e modellizzazione

DRCgen e un software sviluppato in linguaggio C che ha la capacita di generare

il miglior DRC possibile nei confronti dello scenario di riconfigurazione in cui

esso dovra essere utilizzato. Prima di sviluppare DRCgen, e stato necessario

modellizzare il DRC in modo da comprendere come le sue grandezze descrittive

siano fra loro relazionate. Una corretta modellizzazione del sistema e con-

dizione necessaria al raggiungimento della aderenza dei risultati del software

al mondo reale.

4.1.1 Grandezze descrittive del DRC

Un sistema dinamico[13] e un sistema che evolve nel tempo, indicando con

questo termine che sia l’ingresso che l’uscita si sviluppano nel tempo. In gen-

erale l’uscita all’istante t di un sistema dinamico non dipende solo dall’ingresso

del sistema allo stesso istante, ma da una grandezza, detta stato, che rappre-

41

42 CAPITOLO 4. DRCGEN

senta la storia passata degli ingressi del sistema.

Il DRC e, a tutti gli effetti, un sistema dinamico in quanto e dotato di un

ingresso, di un uscita e di uno stato. L’ingresso e rappresentato dalle linee

che dal bus arrivano al DRC, l’uscita dalle linee che dal DRC vanno verso

l’ICAP, mentre lo stato e rappresentato dal buffer. Visto che i dati sul bus, nel

buffer e verso l’ICAP variano nel tempo, si puo considerare il DRC un sistema

dinamico.

Fatte queste considerazioni, non resta altro che identificare quali grandezze

governano il sistema e come sono correlate tra loro.

Il DRC e caratterizzato da due principali parametri:

• TDRC = Throughput di riconfigurabilita [MBytessec

]

• A = Area occupata [slices]

Molte applicazioni richiedono dei thruoughput di riconfigurabilita alti con il

minor consumo di area possibile, quindi si puo subito affermare che un otti-

mo DRC e quello che riesce a massimizzare il throughput di riconfigurabilita,

minimizzandone l’area occupata. Ovviamente le tendenze sono opposte, cioe

al crescere del throughput di riconfigurabilita, l’area occupata tende a crescere

e viceversa, ma comunque e possibile trovare la soluzione che ottimizza il rap-

porto tra il throughput che si vuole ottenere e l’area che si vuole occupare.

Prima di addentrarsi nelle relazioni che governano questo meccanismo, e

opportuno e necessario introdurre altri parametri:

• Tbus = throughput del bus [MBytessec

]

• Ticap = throughput della porta ICAP [MBytessec

]

Questi due parametri descrivono l’ingresso e l’uscita del sistema. Il primo

parametro dipende fortemente dallo scenario in cui si trova il DRC, come il tipo

di bus scelto e il numero di periferiche collegate, mentre il secondo identifica il

throughput della porta ICAP, che e noto a priori e non dipende dallo scenario.

Prima di continuare nella analisi formale, e necessario considerare che vale la

seguente relazione:

Tbus < Ticap (4.1)

4.1. ANALISI DEI REQUISITI E MODELLIZZAZIONE 43

Modellizzazione del buffer: Il buffer ha il compito di salvare i dati in arrivo

da bus prima di passarli all’ICAP. Raggiunta una soglia di attivazione l’ICAP

si attiva e inizia a processare i dati mentre il bus continua a caricarli. L’ICAP

interrompera il lavoro solo se raggiunge la cella in cui deve scrivere il bus. Se

il buffer e sufficientemente grande da non interrompere mai il funzionamento

dell’ICAP il vantaggio ottenuto sara tale da invertire la Relazione 4.1.

Una volta invertita la 4.1, non sara piu necessario aumentare la dimensione

del buffer in quanto il throughput di riconfigurabilita non migliorerebbe. Pos-

siamo quindi anticipare che la grandezza del buffer non deve superare quella

grandezza capace di invertire la 4.1.

In definitiva il buffer e modellizzabile come in Figura 4.1:

Figura 4.1: Buffer del DRC

Esso e dotato di un ingresso che trasferisce dati con un throughput di Tbus e

una uscita che estrae dati dal buffer ad una velocita di Ticap. A questi due

parametri, che sono gli stessi visti in precedenza, e possibile aggiungere:

• L = dimensione del buffer in byte

• l = livello di attivazione dell’icap, cioe il livello dal quale inizia il

trasferimento dei dati, quindi la riconfigurazione.

• α = lL

= indice del margine di occupazione dei dati nel buffer


Una corretta modellizzazione di questi parametri garantisce prestazioni

elevate al DRC. α indica di quanto margine e dotato il buffer. In linea del

tutto teorica, si potrebbe impostare α a 1, in quanto Tbus < Ticap ma, dato

che questa relazione non si puo considerare valida in ogni singolo istante, si

munisce il buffer di una area tampone per evitarne il piu possibile un completo

riempimento. Risultati sperimentali mostrano che un valore di α compreso

tra 0,8 e 0,9 e una buona scelta.

Occupazione di Area: Un sistema embedded e caratterizzato dall’avere

poche risorse di area e memoria, pertanto e importante tenere conto dell’oc-

cupazione di area del DRC nelle diverse configurazioni che lo caratterizzano.

Ricordando che esso e caratterizzato da una componente fissa (la logica di

controllo del bus e dell’ICAP) e da una variabile (la logica di controllo del

buffer), definiamo:

• Af = area occupata dalla parte fissa in slices

• Av = area occupata dalla parte variabile per Byte del buffer in slicesbyte

Dopo aver introdotto tutti i parametri, possiamo passare alla stesura delle

prime relazioni.

4.1.2 Relazioni descrittive del DRC

Occupazione di area: come gia accennato nel paragrafo precedente, il DRC

e composto da una parte fissa ed una variabile. La prima rappresenta la logica

di controllo del bus ed e indipendente dal tipo e dalla dimensione del buffer,

mentre la seconda rappresenta la logica del buffer, che e strettamente legata

al tipo e dimensione del buffer scelto.


Per comprendere come e legata l’occupazione di area alla dimensione del

buffer sono state eseguite le seguenti prove (effettuate usando il DRC con buffer

in slice e interfaccia OPB):

Dimensione Buffer (Bytes) Occupazione di Area (slices)

4 79

8 119

16 161

32 275

64 525

128 981

Tabella 4.1: Occupazione Area Soluzione Buffer in Slices con interfaccia su

OPB

Interpolando i valori di Tabella 4.1, si e capito che la parte variabile del DRC

ha un andamento lineare, quindi e corretto descrivere l’occupazione di area

come segue:

A = Af + Av ∗ L (4.2)

Dove Af e l’occupazione della parte fissa in slices, Av e l’occupazione della

parte variabile in slices per byte e L e la grandezza (in byte) del buffer.

I valori di Af e Av sono legati al tipo di bus e buffer scelti. In particolare,

una scelta di un buffer piuttosto che di un altro, influisce sulla occupazione

della parte fissa, mentre la scelta del tipo di buffer (slices o BRAM) determina

l’occupazione della parte variabile.

Throughput: con la presenza del buffer, il throughput di trasferimento

dei dati verso l’ICAP migliora rispetto alla soluzione priva di buffer. Questo

miglioramento e determinato sia dalla grandezza del buffer, che dalla grandezza

del bitstream (che identificheremo con B). Tenendo presente la Relazione 4.1,

e immediato ricavare:

TDRC =B

B − lTbus (4.3)

Esiste, quindi, un fattore che indica di quanto e accelerato il throghput di ri-

configurabilita rispetto al throghput del bus. La funzione e monotona crescente

per l < B con un asintoto in l = B, in quanto B − l < B. Tali considerazioni

fanno capire che Tbus < TDRC e che TDRC cresce al crescere di l. Cio dimostra


che il miglioramento delle prestazioni e determinato dalla presenza del buffer,

senza il quale non sarebbe possibile aumentare il throughput di riconfigura-

bilita.

La Relazione 4.3 e espressa graficamente in Figura 4.2. I valori scelti per

la costruzione di questo grafico (giustificati da prove sperimentali [1]) sono

Tbus = 50MBytessec

e B = 20KBytes .

Figura 4.2: Throughput in funzione della dimensione del buffer

La Relazione 4.3, illustrata in Figura 4.2, non e del tutto esatta, in quanto

in essa non compare Ticap. Questo e ragionevole perche Tbus < Ticap, ma puo

creare non poche inaderenze alla realta. La Relazione 4.3 suppone che Ticap

sia grande a piacere, il che e inesatto. Ad esempio: si supponga di possedere

un buffer che sia delle dimensioni del bitstream. Una volta partita la riconfi-

gurazione, il processore passera al DRC il bitstream, il quale sara interamente

caricato nel buffer prima che l’ICAP parta con la riconfigurazione. Secondo la

Relazione 4.3 si ha che TDRC = ∞, quindi il processo di riconfigurazione del

dispositivo risulta immediato, quando, in realta, sappiamo essere pari al tempo

che l’ICAP impiega a leggere il bitstream dal buffer, ottenendo TDRC = Ticap.

Cio e interessante e ci obbliga a ridefinire la Relazione 4.3 nel modo seguente:

TDRC =

{BB−lTbus, se l < B(1− Tbus

Ticap)

Ticap, altrimenti(4.4)


Figura 4.3: Throughput del DRC

La Relazione 4.4 e espressa graficamente nella Figura 4.3. Il valore di l,

che causa una saturazione del throughput di riconfigurabilita, e pari a l =

B(1 − Tbus

Ticap). Non conviene avere dimensioni del buffer maggiori del punto

di saturazione, in quanto non si avrebbe un miglioramento del throughput di

riconfigurabilita.

Una volta vista la Relazione 4.4, e importante osservare come la dimensione del

bitstream influisce sul throughput. Proviamo ad esaminare come si comporta

il throughput di riconfigurabilita al crescere della dimensione del bitstream con

un limite:

TDRC = limB→∞

B

B − lTbus = Tbus (4.5)

Come si puo vedere nell’Equazione 4.5, il throughput di riconfigurabilita

peggiora all’aumentare della dimensione del bitstream. Dato che la di-

mensione del bitstream dipende da quanto e grande l’area che si vuole

riconfigurare, si deduce che maggiore e l’area da riconfigurare, a pari DRC,

peggiore sara il throughput di riconfigurabilita. Si faccia attenzione al fatto

che non si sta parlando di peggioramenti sui tempi di riconfigurabilita (che

necessariamente peggiorano all’aumentare della dimensione del bitstream),

ma di peggioramenti del throughput di riconfigurabilita.

Fatte queste premesse, vediamo graficamente quanto detto nella Figura 4.4

Le curve che saturano prima, sono quelle curve che hanno bitstream di

dimensioni piu ridotte. Da sinistra verso destra si e imposto B pari a: 15

KBytes, 16 KBytes, 18 KBytes, 20 KBytes, 23 KBytes e 25 KBytes. Questi


Figura 4.4: Throughput del DRC al variare della dimensione del Bitstream

valori sono stati scelti in quanto rappresentano dimensioni di bitstream

differenza piuttosto reali.

Prima di arrivare ai primi confronti, e necessario disporre di relazioni dirette

tra area e throughput. Queste relazioni saranno utili anche per studiare quale

configurazione si adatta meglio ai vincoli imposti dall’utente. Unendo le

equazioni del paragrafo precedente si ottiene:

Dimensione del buffer in funzione dell’area occupata:

l =A− AfAv

α (4.6)

Dimensione del buffer in funzione del throughput:

l = B(1− TbusTDRC

) (4.7)

Throughput del DRC in funzione dell’area occupata:

TDRC =Tbus

1− αB

(A−Af

Av)

(4.8)

Area occupata in funzione del throughput:

A =B

αAv(1−

TbusTDRC

) + Af (4.9)

La modellizzazione del DRC e terminata. Ora si hanno tutti gli strumenti che

permettono di identificare la migliore configurazione del DRC in funzione dello

scenario in cui esso si trova.

4.2. FLUSSO OPERATIVO DI DRCGEN 49

4.2 Flusso operativo di DRCgen

Come gia accennato ad inizio capitolo, DRCgen utilizza il modello del DRC

al fine di individuare la configurazione che meglio si adatta ai vincoli posti

dall’utente, essi sono:

• Vincolo di Area: specifica quanto deve occupare l’intero DRC.

• Vincolo sul Throughput: specifica quanto deve essere il throughput

del DRC.

Questi vincoli possono anche essere espressi contemporaneamente, ma almeno

uno di essi deve essere specificato. In caso di mancanza di entrambi i vincoli, il

software restituisce un DRC di default. Oltre ai vincoli su throughput e area,

DRCgen tiene conto di altri parametri quali:

• Throughput Bus

• Throughput ICAP

• Dimensione Bitstream

• Tipo di Bus

• Famiglia FPGA

I primi tre parametri servono per individuare (assieme ai vincoli) la dimensione

del buffer e il tipo, il quarto definisce l’interfaccia su bus e l’ultimo serve al

software nella verifica dei risultati ottenuti. Questa verifica cerca di capire se la

soluzione trovata e o meno implementabile e, nel caso lo fosse, quanto occupa

su scheda.

4.2.1 Ricerca della soluzione ottimale

Lo studio del problema e differente nel caso in cui si stia specificando un solo

vincolo o entrambi. Questo perche con un solo vincolo, la soluzione ottimale

al problema e unica. Nello specifico, data l’area, si identifica immediatamente

il throughput e quindi la dimensione del buffer, oppure, dato il throughput,

si identifica univocamente l’area e quindi la dimensione del buffer. Questo e

garantito dal fatto che la relazione che lega il throughput e l’area e monotona.


Essendo monotona, l’inversa, esiste ed e comunque monotona.

Nel caso di specifica contemporanea di entrambi i vincoli, la soluzione non

e sempre unica. Questo tipo di vincolo identifica un punto nel piano

Throughput/Area che puo trovarsi in 3 zone (Vedere Figura 4.5)

1. (a) Il punto si trova al di sopra della curva

2. (b) Il punto giace sulla curva

3. (c) Il punto si trova al di sotto della curva

Figura 4.5: Possibili vincoli

Se il punto giace sulla curva, le due soluzioni possibili (data la presenza di due

vincoli) coincidono, quindi la soluzione e univocamente determinata.

Negli altri due casi si identificano le due soluzioni come segue:

1. Calcolo il Throughput tenendo fisso il vincolo di Area

2. Calcolo l’Area tenendo fisso il vincolo sul Throughput

In questo modo si hanno due soluzioni che godono di proprieta differenti a

seconda che il punto del vincolo si trovi al di sopra o al di sotto della curva:

se il punto si trova sotto la curva, entrambe le soluzioni rispettano entrambi i

vincoli, mentre se il punto si trova al di sopra della curva, entrambe le soluzioni

non rispettano tutti e due i vincoli. Cio succede perche in un caso si sta


chiedendo al generatore un DRC con basso throughput con alta area, mentre

nell’altro un DRC con alto throughput con una bassa area.

Un altro problema si presenta quando si impongono dei vincoli su throughput

o area che escono dal range di valori di accettabilita. Se cio dovesse verificarsi,

prima di effettuare qualsiasi considerazione, il generatore impone i valori di

default secondo le seguenti regole:

• TDRC = Tbus se TDRC < Tbus

• TDRC = Ticap se TDRC > Ticap

• A = Af + Av se A < Af + Av

Queste regole sono continuamente tenute sott’occhio dal software in modo da

convergere verso la soluzione ottimale.

Dopo aver introdotto la metodologia di ricerca delle soluzioni ottimali di DRC-

gen, passiamo ad analizzare l’intero flusso operativo che esso segue per imple-

mentare la suddetta metodologia. Questo servira a comprendere fino in fondo

tutti i suoi comportamenti.

4.2.2 Funzionamento

DRCgen segue fedelmente la metodologia di ricerca delle soluzioni proposta

nel paragrafo precedente. Vista la grande diversita tra la specifica di un solo

vincolo e quella con piu vincoli, esso segue strade differenti che saranno esa-

minate separatamente.

Nello pseudocodice e nei grafici che seguiranno, e da applicare la seguente

legenda:

• T = Vincolo Throghput

• A = Vincolo Area

• Tbus = Throghput del bus

• Ticap = Throughput dell’ICAP

• Lslice = Dimensione buffer implementato in slice

• Lbram = Dimensione buffer implementato in bram


• Aslice = Area occupata dal DRC implementato in slice

• Abram = Area occupata dal DRC implementato in bram

• Aminf = Area della parte fissa nella configurazione che occupa di meno

• Aminv = Area della parte variabile nella configurazione che occupa di

meno

• AFPGA = Area massima della FPGA scelta

• Tarea = Throughput calcolato mantenendo fisso il vincolo di area

• Athr = Area calcolata mantendo fisso il vincolo sul throughput

Ora che tutti i termini sono stati introdotti, e possibile esaminare lo

pseudocodice che descrive il funzionamento di DRCgen.


Specifica del solo vincolo sul Throughput: in input al programma si

ha il solo vincolo sul throughput. L’algoritmo procede come segue:

1: if T > Ticap then

2: T = Ticap

3: end if

4: if T < Tbus then

5: T = Tbus

6: end if

7: Calcolo Lslice da T

8: Calcolo Aslice da Lslice

9: Calcolo Lbram da T

10: Calcolo Abram da Lbram

11: if Aslice > Abram then

12: Scelgo la soluzione in bram

13: else

14: Scelgo la soluzione in slice

15: end if

16: Validazione dei risultati

17: Generazione del VHDL


Specifica del solo vincolo sull’area: in input al programma si ha il solo

vincolo sull’area. L’algoritmo procede come segue:

1: if A < Aminf + Aminv then

2: A = Aminf + Aminv

3: end if

4: if A > AFPGA then

5: A = AFPGA

6: end if

7: Calcolo Lslice da A

8: Calcolo Lbram da A

9: if Lslice > Lbram then

10: Calcolo T da Lbram


12: T = Ticap

13: Ricalcolo Lbram

14: end if

15: end if




Specifica del vincolo sull’area e del vincolo sul throughput: in

input al programma si ha sia il vincolo sull’area che quello sul throughput.


2: T = Ticap

3: else if T < Tbus then

4: T = Tbus

5: end if

6: if A < Aminf + Aminv then

7: A = Aminf + Aminv

8: else if A > AFPGA then

9: A = AFPGA

10: end if

11: Calcolo Tarea da A

12: Calcolo Athr da T

13: if Tarea > Ticap then

14: TArea = Ticap

15: Ricalcolo A dato Tarea

16: end if

17: Proposta delle due soluzioni

18: if Scelta soluzione A Fissa

then

19: T = Tarea

20: else if Scelta soluzione T Fisso

then

21: A = Athr

22: end if




4.2.3 Generazione dell’output

Dopo che il software ha identificato la soluzione migliore in base ai vincoli posti

dall’utente, nota l’interfaccia su bus e la famiglia di FPGA sulla quale si vuole

utilizzare, passa ad una fase di validazione finale dei risultati con generazione

dei files di output.

La validazione dei risultati consiste in un controllo di fattibilita della soluzione

su FPGA. Nel dettaglio controlla che l’area occupata dal DRC non sia superiore

all’area che l’FPGA scelta dispone, oppure, nel caso di buffer in BRAM, che

l’FPGA disponga di tutte le BRAM che il DRC richiede.

La validazione e l’ultima operazione che deve essere fatta in quanto solo a

flusso terminato si conosce la configurazione finale del DRC. Si noti che il

controllo sul vincolo di area e una tra le prime operazioni che DRCgen svolge,

quindi non e possibile immettere, come vincolo, un’area superiore a quella che

l’FPGA scelta dispone.

Se la validazione non fosse superata, il programma interrompe il flusso con un

errore che ne specifica la natura. Se, invece, la validazione viene passata con

successo, il programma genera in output:

• in base al bus: icap opb.vhd e pselect.vhd (se il bus e l’OPB) o solo

icap plb.vhd (se il bus e il PLB)

• icap buffer.vhd

• bram wrapper.vhd e bram wrapper.ngc nel caso in cui abbia un

buffer implementato in BRAM

Infine DRCgen, al termine della generazione di files di output, stampa a video

un resoconto finale dove l’utente puo controllare una serie di parametri quali:

tipo di buffer scelto dal generatore, prestazioni temporali, occupazioni di area,

ecc...

4.2.4 Utilizzo dei files di output in EDK

L’utilizzo dei files di output di DRCgen in una architettura che necessiti il

DRC e semplice. La scelta di creare i files sorgente e orientato ad un utilizzo

il piu vario possibile, tra i quali l’importazione in EDK.

L’importazione del DRC in un progetto EDK segue la stessa procedura di


qualsiasi importazione di periferica: una volta aperto EDK si apra ”Create or

Import Peripheral” che si trova sotto il menu ”Hardware” e procedere come

segue:

• in ”Peripheral Flow” selezionare ”Import Existing Peripheral”

• in ”Name and Version” inserire ”icap opb” se il bus e l’OPB e ”icap plb”

se il bus e il PLB

• in ”Source File Types” spuntare ”HDL source files” e ”Netlist Files” (se

il buffer e implementato in BRAM)

• in ”HDL Source Files” spuntare ”Browse to your HDL source and

dependent library files”

• in ”HDL Analysis Information” cliccare su ”Add Files” e selezionare tutti

i .vhd generati da DRCgen

• proseguire fino alla fine selezionando il bus corretto e, nel caso di buffer

in bram, aggiungere il file .ngc generato

Una volta che il DRC e stato importato in EDK, puo essere utilizzato alla pari

di tutte le periferiche di EDK.

Capitolo 5

Risultati Sperimentali

Dopo aver presentato nel dettaglio la struttura del DRC e del suo generatore,

e necessario controllare tutta la metodologia tramite una serie di simulazioni.

Obiettivo del capitolo e quello di estrarre dalla simulazione tutti i valori neces-

sari alla validazione del modello del DRC. Solo dopo tale validazione si potra

essere certi della correttezza formale del flusso la cui diretta implementazione,

DRCgen, dovra essere sottoposta ad una serie di test al fine di verificarne il

corretto funzionamento.

5.1 Validazione del modello

Come abbiamo visto nel Capitolo 4, Area e Throughput sono strettamente

collegati fra loro. Per mostrare che questa relazione non e solo teorica, prima

calcoleremo i coefficienti Af e Av che caratterizzano le due implementazioni,

poi calcoleremo i throughput teorici e infine verificheremo questi throughput

mediante una simulazione, andando a dimostrare tutte le relazioni enunciate

nel Capitolo 4. Questa prova verra effettuata su tutte e 4 le categorie di DRC.

Nella implementazione del buffer in slice sono stati scelti dei valori modesti, in

quanto tale implementazione richiede molta area.

La Tabella 5.1 e la Tabella 5.2 mostrano le occupazioni di area delle diverse

implentazioni del DRC. Come si e gia avuto modo di vedere nel Capitolo 4,

occupazione di area e dimensione del buffer sono legati da due parametri: Af

59

60 CAPITOLO 5. RISULTATI SPERIMENTALI

Dimensione Buffer Occupazione di Area (OPB) Occupazione di Area (PLB)

(Bytes) (slices) (slices)

4 79 95

8 119 130

16 161 179

32 275 300

64 525 543

128 981 990

Tabella 5.1: Occupazione Area Buffer in Slice

Dimensione Buffer Occupazione di Area (OPB) Occupazione di Area (PLB)

(Bytes) (slices) (slices)

512 (1 BRAM) 106 120

1024 (2 BRAM) 116 131

2048 (4 BRAM) 120 141

4096 (8 BRAM) 129 144

8192 (16 BRAM) 154 169

Tabella 5.2: Occupazione Area Buffer in BRAM

e Av. E, quindi, possibile linearizzare i risultati ottenuti al fine di identificare

il preciso valore dei due parametri nelle quattro configurazioni:

• Buffer Slice, interfaccia OPB: Af = 44,33 , Av = 7,46

• Buffer Slice, interfaccia PLB: Af = 71,2 , Av = 7,4

• Buffer BRAM, interfaccia OPB: Af = 100 , Av = 0,01

• Buffer BRAM, interfaccia PLB: Af = 113 , Av = 0,011

L’identificazione di questi parametri, pero, non e sufficiente a validare il mod-

ello in quanto sono necessarie delle prove di validazione piu generali. Queste

prove devono mirare a dimostrare che il throughput di riconfigurabilita cal-

colato dal modello, corrisponde a quello del componente. Solo dopo questa

verifica sara possibile affermare che il modello del DRC e corretto.

Considerando che il DRC e un componente scritto in VHDL il cui compor-

tamento, fissata la dimensione del bitstream e del buffer, non e aleatorio, ha

senso condurre la prova con un simulatore. Cio garantisce dati precisi e non

affetti da rumore. Per questa simulazione si e scelto ModelSim 1, un software

1http://www.model.com

5.1. VALIDAZIONE DEL MODELLO 61

Figura 5.1: Screenshot di una simulazione in ModelSim

della Mentor Graphics che permette di simulare passo passo il comportamento

di qualsiasi core scritto in VHDL o Verilog.

La simulazione consiste in una analisi temporale di una riconfigurazione. Al

termine della simulazione verra confrontato il throughput di riconfigurabilita

con quello teorico al fine di validare le formule del Capitolo 4.

Per la prova si e imposto il throughput del bus a 50MBytessec

e il throughput del-

l’ICAP a 100MBytessec

, facendo variare la dimensione del bitstream e del buffer.

La Tabella 5.3 mostra i risultati di tale simulazione (visibile in Figura 5.1).

Tbus B L T simDRC T theorDRC

(MBytes/sec) (Bytes) (Bytes) (MBytes/sec) (MBytes/sec)

50 4000 400 55,7 55,62

50 4000 1000 66,76 66,70

50 8000 400 52,62 52,63

50 8000 2500 72,74 72,72

50 16000 400 51,29 51,28

50 16000 5000 72,74 72,72

50 16000 10000 100 100

Tabella 5.3: Risultati della simulazione condotta con ModelSim del DRC

I throughput ottenuti dalla simulazione ricalcano perfettamente quelli teorici.

Tale scenario afferma la correttezza del modello e delle metriche che sono state

definite.

Passiamo quindi alla verifica di funzionamento di DRCgen al fine di validarne

l’approccio.


5.2 Test DRCgen

Ora che la validazione del modello e stata conclusa, si sottoporra il software a

diverse prove sperimentali, al fine attraversare tutti i rami del flusso operativo.

Verranno effettuate 3 prove con il solo vincolo di throughput, 4 prove col

solo vincolo di area e, infine, 8 prove con entrambi i vincoli. Tutte le prove

sono state effettuate considerando Tbus = 50MBytessec

, Ticap = 100MBytessec

, B =

20KBytes, su bus OPB impostando come FPGA la Virtex-II Pro VP7.

5.2.1 Specifica del Solo Vincolo sul Throughput

Prova 1

Vincolo sul Throughput = 20MBytessec

:

./DRCgen.exe -throughput 20

Il software ha risposto correttamente imponendo il vincolo a 50MBytessec

,

restituendo cosı un DRC con buffer di 4 Bytes implementato in slices.

Prova 2


:


Il software ha dapprima imposto il vincolo al massimo possibile (100MBytessec

) e

successivamente calcolato il DRC che e risultato possedere un buffer formato

da 25 BRAM.

Prova 3


:


Il DRC trovato contiene 9 BRAM.

5.2.2 Specifica del Solo Vincolo di Area

Prova 1

Vincolo di Area = 30slices:

./DRCgen.exe -area 30

5.2. TEST DRCGEN 63

DRCgen ha risposto alzando il vincolo da 30slices a 51slices che e corretto in

quanto corrisponde al piu piccolo DRC generabile, cioe quello con 4 Bytes di

buffer implementato in slices e interfacciato su OPB.

Prova 2



Il software non controlla se l’area richiesta e disponibile nella FPGA, ma resti-

tuisce il miglior DRC possibile, cioe il DRC che corrisponde al punto di sat-

urazione del throughput. Per raggiungere tale obiettivo, impone un vincolo

sul thoughput pari a quello dell’ICAP e ricalcola l’area. Nel caso specifico

la soluzione restituita e uguale alla Prova 2 dei test condotti sul vincolo di

throuhgput.

Prova 3



Il valore e accettabile, cosı il software inizia a computare. L’area richiesta e

tale da non poter istanziare il DRC con buffer in BRAM, ma solo quello in

slices. Identificato il tipo di soluzione, il buffer e di 20 Bytes.

Prova 4



La soluzione, in questo caso, prevede un buffer con 5 BRAM. Dato che,

come noto dal Capitolo 4, l’istanziazione di una nuova bram non ha costo

rilevante in termini di area, e sempre consigliabile inserire anche il vincolo

sul throughput al fine di evitare l’istanziazione di un numero spropositato di

BRAM.


5.2.3 Specifica di Entrambi i Vincoli

Prova 1

Vincolo di Area = 80slices, Vincolo sul Throughput = 70MBytessec

./DRCgen.exe -area 80 -throughput 70

Le due soluzioni proposte dal software sono:

• Area: 80 slices / Throughput: 50 MBytes/sec


Che sono due soluzioni corrette. Nessuna delle due soluzioni e in grado di

soddisfare ambo i vincoli.

Prova 2






Entrambe corrette. Qui tutte e due le soluzioni soddisfano entrambi i vincoli.

Prova 3






Che, coincidendo, danno la configurazione del DRC con buffer dotato di 14

BRAM.

La validazione di DRCgen e stata portata a compimento in quanto tutte le

prove hanno dato esiti positivi. E quindi possibile esaminare i risultati di

tutte le prove sperimentali cercando di analizzare il problema da un punto di

vista piu generale.

5.3. CONCLUSIONI 65

5.3 Conclusioni

Tutti i test condotti in questo capitolo hanno dato esito positivo. Si e quin-

di potuto dimostrare che il modello del DRC e corretto in tutti i suoi aspetti.

Inoltre i test sono stati utili a comprendere un altro fatto rilevante nella model-

lizzazione del DRC: l’assoluta indipendenza che esso ha dalla implementazione

su FPGA. La linearizzazione delle occupazioni di area prima e la simulazione

dopo sono un esempio di questo fatto. Nella simulazione la scelta dei valori

di Tbus e di Ticap, difatti, e irrilevante purche Tbus < Ticap. L’innovazione

introdotta da questo lavoro di tesi e, appunto, la completa indipendenza del

modello dal dispositivo su cui sara fisicamente implementato il riconfiguratore.

Inoltre e possibile applicare la modellizzazione del Capitolo 4 a riconfiguratori

diversi dal DRC purche sia presente un buffer e sia possibile identificare il

throughput del bus e quello dell’ICAP (o della porta di riconfigurazione del

dispositivo).

Capitolo 6

Conclusioni e Sviluppi Futuri

DRCgen, il software che e stato sviluppato, nasce da una esigenza precisa: la

necessita di adattare il riconfiguratore allo scenario da riconfigurare. In questo

modo il progettista potra generare, ogni volta che lo necessita, il controllore

con le caratteristiche che meglio si adattano al contesto in cui si trovera ad

operare.

Tutti i riconfiguratori analizzati nel Capitolo 2 hanno prestazioni medie molto

interessanti. Si puo dire che si adattano bene a moltissime applicazioni

pratiche, ma peccano in flessibilita.

Si supponga di avere un sistema riconfigurabile che si occupa di monitorare

una serie di temperature in un impianto industriale. Si capisce fin dal

principio che non e importante disporre di un riconfiguratore che goda di alte

prestazioni (dato che le temperature variano molto lentamente), ma piuttosto

di un riconfiguratore molto piccolo, in quanto molta logica della FPGA sara

utilizzata per il recupero dei dati. Allora che senso avrebbe utilizzare, ad

esempio, l’OPB HWICAP quando una BRAM intera non serve?

Oppure, si supponga di avere un sistema riconfigurabile che si occupa di fare

editing video. Questo sistema, invece, ha bisogno di avere un riconfiguratore

capace di garantire le piu alte prestazioni possibili (in termini di throghput) a

scapito di una occupazione di area maggiore.

Infine, si supponga di avere un sistema implementato su un’architettura con

Microblaze. In questa architettura non e presente il bus PLB. Per poter

utilizzare periferiche interfacciate su PLB, sara necessario mettere un bridge

tra il bus PLB e quello OPB. La presenza di questo bridge causa un crollo

67

68 CAPITOLO 6. CONCLUSIONI E SVILUPPI FUTURI

delle prestazioni (oltre ad una maggiore occupazione di area), che potrebbe

essere evitato avendo a disposizione un riconfiguratore su OPB.

L’innovazione introdotta da questo lavoro di tesi riguarda l’approccio,

del tutto nuovo, al problema della definizione e implementazione di un

riconfiguratore.

L’automazione assoluta del flusso di generazione permette di concentrare

tutte le attenzioni del lavoro su quello che l’utente desidera avere. Infatti

la riconfigurazione della FPGA non e lo scopo di un sistema embedded, ma

un meccanismo utilizzato per aumentare l’utilizzabilita di tali dispositivi.

Pertanto non deve essere l’applicazione a costruirsi attorno al riconfiguratore,

adattandosi ai suoi limiti, ma deve essere il riconfiguratore a configurarsi nei

vincoli richiesti dalla applicazione.

6.1 Sviluppi Futuri

Le attenzioni per il futuro sono da rivolgere in larga misura verso il DRC.

Esso, infatti, e ampiamente sviluppabile. Ogni sviluppo, pero, non deve essere

inteso come una miglioria rispetto alla soluzione precedente, ma come una va-

lida alternativa che, modellizzata corretamente, puo essere inserita nel flusso

come ulteriore soluzione. Pertanto una modifica del DRC causa una modifica

a DRCgen che dovra essere in grado di adattarsi alle tutte le innovazioni.

Uno tra i primi sviluppi del DRC e l’inserimento di un meccanismo di DMA.

Tale meccanismo deve, pero, rispettare a pieno la modularita del DRC, cioe

deve essere possibile eliminarlo qualora non fosse necessario. Il DMA e in gra-

do di incrementare il throughput in ingresso al DRC causando un decremento

delle memorie richieste (e quindi dell’area).

Un altro interessante sviluppo e legato all’interazione del DRC con il core di

BiRF [10]. BiRF e un componente capace di modificare i bitstream al fine di

riallocare un core in una posizione diversa da quella per cui e stato progettato.

Questa funzionalita e in grado di far risparmiare molto spazio di memoria,

altrimenti occupato da tutti i bitstream differenza.

L’idea e di includere BiRF nel DRC anteponendo tra i due una cache. Tale

cache conterra il bitstream che descrive il componente da riconfigurare. Se il

6.1. SVILUPPI FUTURI 69

componente necessita di una rilocazione, allora il bitstream sara prima mod-

ificato dal core di BiRF, salvato in cache e, succesivamente, passato al DRC.

Infine si possono utilizzare degli algoritmi di compressione in modo tale da ot-

tenere bitstream di dimensioni ancora piu ridotte di quelli parziali. Cosı si ha

la possibilita di ridurre la dimensione della memoria richiesta dal DRC oppure

usare la stessa quantita ed ottenere prestazioni migliori. Si noti che prima

di utilizzare questi bitstream, devono essere decompattati da un opportuno

decompressore prima del passaggio di questi all’ICAP.

Bibliografia

[1] Antonio Piazzi Alessio Montone. Yara: Un’architettura riconfigurabile

basata sull’approccio monodimensionale.

[2] Johannes Zeppenfeld Christopher Claus, Florian H. Muller and Walter

Stechele. A new framework to accelerate Virtex-II Pro dynamic partial self

reconfiguration.

[3] Xilinx XAPP138. Virtex FPGA Series Configuration and Readback.

[4] Xilinx Microblaze Processor Reference Guide.

[5] Xilinx PowerPC Processor Reference Guide.

[6] Xilinx UG071. Virtex-4 Configuration Guide.

[7] Xilinx User Constraint File Guide.

[8] Xilinx Site: http://www.xilinx.com.

[9] Stefano Bosisio Ivan Beretta. Integrazione del soft processor microblaze

nell’architettura riconfigurabile yara.

[10] M. Novati M.D. Santambrogio-D. Sciuto P. Spoletini S. Corbetta,

M. Morandi. Internal and external bitstream relocation for partial

dynamic reconfiguration.

[11] Xilinx OPB HWICAP Product Specification.

[12] Wikipedia. Fpga.

[13] Wikipedia. Sistema dinamico.

[14] Wikipedia. Sistema embedded.

71

Politecnico di Milano · 2007-10-24 · Politecnico di Milano Facolt a di Ingegneria...

Documents

Transcript of Politecnico di Milano · 2007-10-24 · Politecnico di Milano Facolt a di Ingegneria...