Tesi Robotica Un co-processore per Stereo-Matching: Architettura | Page 98

i

i
“LP_Tesi” — 2011/9/9 — 21:20 — page 98 — #98

i

4.9. RISULTATI

i

98

Algoritmo 4.33 Loader: rule requestOfRead+read
rule requestOfRead (readyToRead && readLine && addrRead<=
fromInteger((width*height)-1));
ram.b.put(False, addrRead, Pixel{red:0,green:0,blue:0});
step<=1;
addrRead<=addrRead+1;
modulus<=incr(modulus);
if(modulus==truncate(size-1))
readLine<=False;
endrule: requestOfRead

1

2
3
4
5
6
7
8
9

rule read(step==1);
fin.enq(ram.b.read());
if(addrRead>fromInteger((width*height)-1)) step<=0;
endrule: read

10
11
12
13

4.9

Risultati

Finita la descrizione del codice passiamo ora alla descrizione dei risultati. Come
detto all’inizio, il problema dello stereo matching ha come input una serie di
immagini della stessa scena, prese una leggermente discostata dall’altra. In un
primo momento, per semplificare il lavoro di sviluppo si è deciso di processare
solamente immagini di dimensione potenza di 2, per permettere ai registri di
indirizzamento di andare in overflow ogni volta che la lettura o la scrittura di un
immagine in memoria finiva, in modo da resettarsi automaticamente in attesa
di un nuovo input.
Gli FPGA usati per la sintesi di questo tipo di applicazione sono tutti di fascia bassa (famiglia Cyclon IV E e GX ), comportando così dei grossi limiti di
memoria per un programma che ne fa largo uso, basti pensare alle sole RAM
presenti nel modulo Scoring. Abbiamo un consumo pari a 32bit ∗ n ∗ n per la
matrice dei punteggi (con n larghezza dell’immagine), e 3bit ∗ n ∗ n per le matrici
dei gap e diag, per un costo totale di 35bit ∗ n ∗ n di memoria, ma il più potente
FPGA della famiglia Cyclon IV possiede appena 4 Mb (3,888 Kb) di memoria
interna.
Data la scarsezza di risorse si è pensato di dividere l’immagine originale in chunk
di varie dimensioni, i primi test sono stati eseguiti per chunk di 32x32 pixel,

i

i
i

i