sistemi efficienti per calcolo ad alte prestazioni e ...per prima cosa, ringrazio nelson davide...

UNIVERSITÀ DEGLI STUDI DI PAVIA

FACOLTÀ DI INGEGNERIA

DIPARTIMENTO DI INFORMATICA E SISTEMISTICA

SISTEMI EFFICIENTI PER CALCOLOAD ALTE PRESTAZIONI EINTEROPERABILITÀ

Relatore: Prof. Giovanni Danese

Correlatore: Prof. Francesco Leporati

Tesi di Dottorato

diMauro Giachero

Dottorato di Ricerca in Ingegneria Elettronica, Informatica ed ElettricaXXI Ciclo / VII Ciclo Nuova Serie (2005�2008)

Alla mia famiglia

A Simona

Ringraziamenti

Per prima cosa, ringrazio Nelson Davide Nazzicari per avere un secondo nome

che rende bu�o l'inizio dei ringraziamenti e per essere stato l'alter ego di cui

ho sempre avuto bisogno, oltre che per essersi preso la sedia vicino al telefono.

Ci sono tanti altri motivi per ringraziarlo, ma a me basta ricordare la bottiglia

d'acqua lanciata, piena e aperta, durante una lezione � sono passati più di

6 anni, ma il pensiero mi fa ancora ridere. E già che ci sono ringrazio anche

Davide Martino Raimondo (a.k.a. �Mondo�), per aver dato a Nelson l'idea di

fare ringraziamenti chilometrici (che io ho poi copiato spudoratamente) e per

aver preso al volo quella bottiglia. . .

Ringrazio Simone Marini (a.k.a. �Maro�) per avermi fatto scoprire quanto

può essere davvero piccante una fagiolata, e perché col suo dottorato a Hong

Kong mi ha fatto apprezzare ancora di più quello italiano.

Ringrazio i mitici Prinz, in tutte le varie versioni che si sono susseguite nel

tempo, per avermi regalato serate indimenticabili.

Ringrazio Lorena Nicoli (a.k.a. �Lola�) per la sua simpatia e per avermi

deriso più e più volte per le mie stranezze. E anche perché ora grazie a lei

sorrido tutte le volte che penso a Indiana Jones.

Ringrazio gli innumerevoli tesisti che sono passati per il Laboratorio, non

solo per il lavoro che hanno fatto (togliendomelo dai piedi), ma perché molti di

loro si sono rivelati persone piacevoli e disponibili.

Ringrazio i miei professori, Gianni Danese e Francesco Leporati, per essere

sempre stati presenti quando c'è stato bisogno di loro, e anche quando capitava

un'occasione mangereccia. Non capita spesso di avere un rapporto di familiarità

così stretto coi professori � di sicuro a me non era mai capitato.

Ma soprattutto, ringrazio le persone che più mi sono state più vicine, e non

solo per il Dottorato.

Ringrazio Simona per essere stata un infaticabile sostegno durante tutti que-

sti anni e per essersi o�erta più e più volte di leggermi la Tesi (non sai cosa t'ho

risparmiato. . . ).

Ringrazio mio fratello Sergio perché, in fondo, se sono Ingegnere è anche

colpa sua. Non temere, te la farò pagare quando meno te lo aspetti.

Ringrazio Lorena (Marmetto) per essere sempre stata presente quando ne

ho avuto bisogno.

Ringrazio Marco e Elena per la loro simpatia e la loro vitalità.

In�ne, ringrazio la mia mamma Elsa e il mio papà Giovanni. Solo voi potete

sapere cosa avete fatto per me.

Indice

Introduzione 5

I Un'architettura per il riconoscimento di dermatogli� 7

1 Introduzione 9

2 Le impronte digitali 13

2.1 Caratteristiche delle impronte digitali . . . . . . . . . . . . . . . 13

2.2 Sistemi per identi�cazione automatica . . . . . . . . . . . . . . . 16

3 Matching di impronte digitali 19

3.1 Algoritmi basati sulle minuzie . . . . . . . . . . . . . . . . . . . . 19

3.2 Algoritmi basati sulle caratteristiche globali delle creste . . . . . 20

3.3 Algoritmi basati sulla correlazione . . . . . . . . . . . . . . . . . 20

4 L'algoritmo implementato 23

4.1 Discrete Fourier Transform (DFT) . . . . . . . . . . . . . . . . . 23

4.2 Phase-Only Correlation . . . . . . . . . . . . . . . . . . . . . . . 24

4.3 Band-Limited Phase-Only Correlation . . . . . . . . . . . . . . . 25

4.4 Calcolo dell'indice di corrispondenza . . . . . . . . . . . . . . . . 26

5 Implementazione hardware della DFT 27

5.1 Fast Fourier Transform (FFT) . . . . . . . . . . . . . . . . . . . . 27

5.1.1 Fast Fourier Transform in 2 dimensioni . . . . . . . . . . 27

5.2 L'Algoritmo di Cooley-Tukey . . . . . . . . . . . . . . . . . . . . 28

5.3 Struttura del componente di calcolo della FFT . . . . . . . . . . 30

5.4 L'ambiente di esecuzione . . . . . . . . . . . . . . . . . . . . . . . 32

5.5 Un approccio alternativo: il compilatore C2H . . . . . . . . . . . 36

6 Risultati 39

1

2 INDICE

II Double-Precision Floating-Point Accelerator 41

1 Introduzione 43

1.1 L'algoritmo di simulazione . . . . . . . . . . . . . . . . . . . . . . 44

1.2 Il modello �sico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

1.3 Un acceleratore per la virgola mobile . . . . . . . . . . . . . . . . 46

2 L'architettura di DPFPA 49

2.1 Unità di Calcolo . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

2.2 Sequenziatore di microistruzioni . . . . . . . . . . . . . . . . . . . 51

2.3 Unità Aritmetico-Logica (ALU) . . . . . . . . . . . . . . . . . . . 52

2.4 Gestore di Memoria . . . . . . . . . . . . . . . . . . . . . . . . . 53

2.5 Gestore di Cache Virtuali . . . . . . . . . . . . . . . . . . . . . . 54

2.6 Unità di Controllo . . . . . . . . . . . . . . . . . . . . . . . . . . 56

2.7 L'integrazione dell'acceleratore . . . . . . . . . . . . . . . . . . . 59

3 Strumenti sviluppati 61

3.1 Il linguaggio di programmazione . . . . . . . . . . . . . . . . . . 61

3.2 Un ambiente integrato . . . . . . . . . . . . . . . . . . . . . . . . 64

4 Risultati ottenuti 67

III Innovazione calzaturiera 71

1 Introduzione 73

2 La moderna produzione calzaturiera 75

2.1 La calzatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

2.2 Dall'idea al progetto . . . . . . . . . . . . . . . . . . . . . . . . . 76

2.3 Dal progetto alla scarpa . . . . . . . . . . . . . . . . . . . . . . . 77

2.4 Preparazione di forme e tomaie . . . . . . . . . . . . . . . . . . . 78

2.4.1 La forma . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

2.4.2 La tomaia . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

2.4.3 Il sottopiede . . . . . . . . . . . . . . . . . . . . . . . . . . 83

2.5 Montaggio della tomaia sulla forma . . . . . . . . . . . . . . . . . 84

2.6 Condizionamento igrotermico . . . . . . . . . . . . . . . . . . . . 84

2.7 Preparazione del fondo e della suola . . . . . . . . . . . . . . . . 85

2.8 Applicazione della suola sulla tomaia . . . . . . . . . . . . . . . . 85

2.9 Scalzatura e operazioni di �nissaggio . . . . . . . . . . . . . . . . 87

INDICE 3

3 Lo standard JANE CAD-CAM 89

3.1 Obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

3.2 Considerazioni sull'accettazione . . . . . . . . . . . . . . . . . . . 89

3.2.1 Aspetti commerciali . . . . . . . . . . . . . . . . . . . . . 89

3.2.2 Aspetti legati al processo di de�nizione . . . . . . . . . . 90

3.2.3 Modi di accettazione . . . . . . . . . . . . . . . . . . . . . 91

3.3 Altri standard e ricerche nel settore . . . . . . . . . . . . . . . . . 91

3.4 Lavorazioni descritte . . . . . . . . . . . . . . . . . . . . . . . . . 92

3.5 Introduzione al formato . . . . . . . . . . . . . . . . . . . . . . . 93

3.5.1 Il linguaggio XML . . . . . . . . . . . . . . . . . . . . . . 93

3.5.2 L'archivio compresso . . . . . . . . . . . . . . . . . . . . . 94

3.5.3 Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

3.5.4 manifest.xml . . . . . . . . . . . . . . . . . . . . . . . . 95

3.5.5 general.xml . . . . . . . . . . . . . . . . . . . . . . . . . 95

3.5.6 2d.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

3.5.7 assembly.xml . . . . . . . . . . . . . . . . . . . . . . . . 97

3.5.8 3d.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

3.5.9 materials.xml . . . . . . . . . . . . . . . . . . . . . . . . 100

3.5.10 production.xml . . . . . . . . . . . . . . . . . . . . . . . 100

3.5.11 Note conclusive . . . . . . . . . . . . . . . . . . . . . . . . 101

3.6 Il visualizzatore . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

3.7 Stato dell'implementazione . . . . . . . . . . . . . . . . . . . . . 102

3.8 Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

4 Lo standard CAD-CAD 105

4.1 Contesto applicativo . . . . . . . . . . . . . . . . . . . . . . . . . 105

4.2 Informazioni rappresentate . . . . . . . . . . . . . . . . . . . . . 106

4.3 Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

5 Attribuzione del marchio di conformità 111

IV Altre attività 113

1 Telemetria termogra�ca di pneumatici 117

2 Controllo di vettura in galleria del vento 123

3 Caratterizzazione e ricerca di oggetti 127

4 INDICE

V Appendici 131

A Tecnologia FPGA 133

A.1 Natura dei dispositivi . . . . . . . . . . . . . . . . . . . . . . . . 133

A.2 Le Altera Development Board . . . . . . . . . . . . . . . . . . . . 134

A.2.1 L'Altera Nios Development Kit (Stratix 1S40) . . . . . . 134

A.2.2 L'Altera Nios II Development Kit (Stratix II 2S60) . . . . 139

A.3 I softcore Altera . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

A.3.1 Il processore Nios . . . . . . . . . . . . . . . . . . . . . . . 142

A.3.2 Il processore Nios II . . . . . . . . . . . . . . . . . . . . . 142

B L'ambiente di sviluppo 145

B.1 Sviluppo hardware . . . . . . . . . . . . . . . . . . . . . . . . . . 145

B.1.1 Quartus II . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

B.1.2 SOPC Builder . . . . . . . . . . . . . . . . . . . . . . . . 147

B.2 Sviluppo software . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

B.2.1 Nios II EDS . . . . . . . . . . . . . . . . . . . . . . . . . . 148

C Pubblicazioni 149

Epilogo 151

Conclusioni 153

Bibliogra�a 155

Introduzione

La ricerca scienti�ca è un'attività che mira alla scoperta, interpretazione o

revisione di fatti e teorie relative alla realtà che ci circonda.

La ricerca di base, o ricerca pura, mira alla riduzione dell'incertezza nell'am-

bito delle scienze naturali. La ricerca di base vede allora come sua primaria

espressione la formulazione di teorie e la scoperta di relazioni che consentano

alle persone di descrivere, prevedere e controllare un numero sempre maggiore di

fenomeni naturali. Lo sfruttamento pratico dei risultati della ricerca non delle

preoccupazione di chi si occupa di ricerca pura: l'obiettivo è la conoscenza, il

resto verrà di conseguenza.

L'ingegnere però non si occupa di questo.

L'ingegnere usa la creatività, la tecnologia e la conoscenza scienti�ca per

risolvere problemi pratici.

La ricerca a�rontata da un ingegnere è pertanto di tipo diverso. Il suo scopo

è esplorativo: di fronte a una gamma enorme di problemi insoluti (o risolti in

modo insoddisfacente), l'ingegnere a�ronta alcuni temi e li esplora cercando di

portare avanti lo stato dell'arte nelle loro implementazioni.

Un tema di grande interesse applicativo è quello dello sviluppo di architetture

hardware dedicate alla soluzione di problemi computazionalmente onerosi. Due

di queste architetture sono state sviluppate durante il mio corso di Dottorato,

e sono presentate nelle Parti I e II della presente Tesi.

Un altro tema importante è quello dell'interoperabilità tra sistemi di pro-

duttori diversi. Si tratta di un argomento complesso, che occorre a�rontare con

molta cautela per evitare che soggetti importanti possano negare la loro appro-

vazione e vani�care gli sforzi profusi. I risultati di un'opera di standardizzazione

che ha visto il Laboratorio protagonista sono presentati nella Parte III.

Come spesso accade, un intero corso di Dottorato è caratterizzato anche

da attività minori o che non hanno ancora prodotto risultati tangibili. I più

signi�cativi tra questi sono raccolti nella Parte IV. Seguono le Appendici, che

includono l'elenco delle pubblicazioni delle quali sono coautore, le Conclusioni

e la Bibliogra�a.

5

Parte I

Un'architettura per il

riconoscimento di dermatogli�

7

Capitolo 1

Introduzione

Nella società moderna è comune la necessità di accertare l'identità di una

persona, al �ne di consentire (o inibire) l'accesso a risorse a ben determinati

individui.

Esistono storicamente 3 approcci (non esclusivi) che consentono l'identi�ca-

zione automatica di un individuo, basati su:

� something you know (knowledge-based), cioè che veri�cano che l'individuo

sia in possesso di un'informazione riservata e nota solo a lui (tipicamente,

una password o un codice PIN);

� something you have (token-based), cioè basati su un oggetto che è (o do-

vrebbe essere) in possesso solo del titolare del diritto di accesso (tipica-

mente è una chiave di qualche tipo);

� something you are, cioè basati su una caratteristica �sica o comportamen-

tale dell'individuo.

Lo sviluppo di sistemi del terzo tipo, basati sulle caratteristiche �siche o com-

portamentali dell'individuo, pone particolari di�coltà e per questo non sono

di�usi come quelli knowledge- o token-based. Tuttavia proprio nelle di�coltà

nascono anche quelle caratteristiche di particolare interesse, quali il loro non

essere soggetti a rischi di furto, smarrimento o replicazione.

La biometria [Mai2005] è la scienza che ha come oggetto di studio i dati

�sionomici di un individuo al �ne di estrarre quelle caratteristiche anatomiche

e comportamentali tali da renderlo unico e utilizzarle come strumento di ri-

conoscimento. Tali dati possono essere di qualsiasi genere, purché godano dei

requisiti di:

� universalità (ogni persona � salvo casi patologici � deve possederli);

9

10 CAPITOLO 1. INTRODUZIONE

� univocità (devono essere distinti per individui distinti);

� persistenza (devono resistere essenzialmente immutati nel tempo, anche a

fronte di deliberati tentativi di modi�ca da parte dell'individuo stesso);

� misurabilità (la misura delle grandezze necessarie all'identi�cazione deve

essere possibile e non deve creare ingiusti�cati disagi).

Una delle opzioni più comunemente adottate nell'ambito della scelta delle carat-

teristiche biometriche da utilizzare è quella delle impronte digitali o dermatogli�

(le cui caratteristiche essenziali sono illustrate nel Capitolo 2). Tali impronte

godono delle proprietà sopra elencate e, anche grazie alla relativa semplicità di

acquisizione [Jai2004], sono state da lungo tempo studiate e quindi o�rono una

generosa letteratura sulla loro caratterizzazione e analisi.

In base al contesto dell'applicazione, i sistemi biometrici si possono sud-

dividere in sistemi di autenticazione e identi�cazione [Jai2000]. Nei primi la

veri�ca dell'identità avviene confrontando (operazione di matching) i dati bio-

metrici acquisiti con un singolo riferimento (template) contenuto nel sistema

stesso; ci si riconduce quindi ad un confronto di tipo �uno a uno�, e la risposta

del sistema è essenzialmente di tipo binario (l'individuo è/non è chi sostiene di

essere). Nei sistemi di identi�cazione invece la ricerca è e�ettuata all'interno di

un database di template, e la risposta del sistema è l'identità dell'individuo (se

nota) o un'a�ermazione di non identi�cabilità.

Questo lavoro [Dan2007b] intende o�rire un sistema basato su hardware

dedicato per il matching di impronte digitali, coprendo i 2 settori più critici:

� quelli nei quali il database di template è composto da milioni di impronte,

come nel caso degli archivi ad uso investigativo;

� quelli nei quali occorrono soluzioni a basso costo e minime dimensioni, che

promettono di entrare a far parte della vita quotidiana delle persone:

� la possibilità di memorizzare l'impronta digitale sulle carte di credito

e la disponibilità di POS dotati di lettore di impronte porterebbe a

un notevole aumento della sicurezza nelle transazioni elettroniche;

� l'integrazione di lettori compatti in serrature elettroniche consenti-

rebbe la realizzazione di alberghi privi di chiavi nei quali l'autoriz-

zazione all'accesso è fornita esclusivamente tramite il riconoscimento

delle impronte digitali.

Lo sviluppo di hardware dedicato oggi passa sempre più spesso attraverso lo

sfruttamento delle potenzialità o�erte da dispositivi programmabili quali le

11

FPGA (Field Programmable Gate Array), che rispetto alle soluzioni ASIC (Ap-

plication Speci�c Integrated Circuits) consentono tempi e costi notevolmente ri-

dotti a fronte di prestazioni che, pur non potendo eguagliare un design ASIC otti-

mizzato, sono spesso largamente superiori a quelle ottenibili con microprocessori

general-purpose.

Questa parte della Tesi è dedicata alla progettazione e all'implementazione

di un'architettura in grado di calcolare in hardware la funzione di Phase-Only

Correlation, utilizzata in alcuni algoritmi per il matching di impronte digitali e

che meglio di altre tecniche si presta all'implementazione su hardware dedicato.

Capitolo 2

Le impronte digitali

Per l'individualità e la persistenza che le contraddistinguono, le impronte di-

gitali sono l'identi�catore biometrico che ha trovato il più vasto impiego e, se

inizialmente venivano impiegate solo da parte delle forze dell'ordine, ora il cre-

scente bisogno di tecnologie biometriche per il riconoscimento ha portato tale

strumento ad a�ermarsi anche in numerose altre applicazioni [Jai2000].

Un'impronta digitale (Figura 2.1) è la riproduzione dell'epidermide di un

polpastrello prodotta nel momento in cui il dito e�ettua pressione su di una

super�cie liscia. Il pattern caratteristico di un'impronta digitale consiste nel-

l'alternarsi di creste e valli, rappresentate nelle immagini rispettivamente come

zone scure e chiare.

Generalmente si ritiene che le impronte digitali siano uniche non solo per

ogni persona, ma anche per ognuna delle dita; per�no quelle dei gemelli sono

di�erenti, sebbene certi studi abbiano mostrato che tra queste esiste un signi�ca-

tivo livello di correlazione [San2003]. Inoltre, danni quali bruciature super�ciali,

abrasioni o tagli, non compromettono la struttura sottostante delle creste e la

trama originale, con le sue proprietà, viene replicata ad ogni rigenerazione della

pelle1.

2.1 Caratteristiche delle impronte digitali

Per stabilire in modo a�dabile se due impronte digitali provengano dallo stesso

polpastrello o meno, è necessario identi�care alcune caratteristiche invarianti

nella loro rappresentazione. In particolare si individuano sia caratteristiche lo-

cali, cioè caratteristiche di una piccola area dell'impronta, sia globali, relative

1Questa capacità delle impronte di �resistere� anche a forti aggressioni è particolarmentesigni�cativa perché impedisce alle persone di cambiare le proprie impronte in modo signi�-cativo. Purtroppo capita che talune persone tentino comunque (e inutilmente) di sfuggire aicontrolli provocandosi gravi lesioni ai polpastrelli.

13

14 CAPITOLO 2. LE IMPRONTE DIGITALI

Figura 2.1: Un'impronta digitale

all'impronta nella sua interezza. Normalmente le caratteristiche globali sono

sfruttate per la classi�cazione delle impronte, utile al �ne di ridurre la dimen-

sione dello spazio di ricerca [Kar1995, Wan2002, Zha2004], mentre quelle locali

sono usate per l'individuazione e�ettiva del template corrispondente.

La caratterizzazione globale delle impronte passa attraverso l'osservazione

che le creste tendono a formare aree di forma distinguibile (regioni singolari).

Queste a loro volta sono caratterizzate da punti (punti singolari) noti come core

e delta (Figura 2.2) [Baz2002]. Il core rappresenta il centro dell'impronta, ed è

normalmente de�nito come il punto di massima curvatura delle creste concave.

Il delta è il punto su una cresta in corrispondenza o nei pressi del punto di

divergenza di due creste che si dividono dopo aver corso parallelamente. Visto

che l'individuazione di questi punti è robusta a fronte di trasformazioni geo-

metriche, la loro posizione è sfruttata da molti degli sistemi di classi�cazione

[Nyo2004, Zha2004].

Uno dei principali schemi di classi�cazione, dovuto a Edward Henry e sir

Francis Galton, e per questo noto come �schema di classi�cazione di Galton-

Henry�, de�nisce cinque classi principali: arch, tented arch, right loop, left loop

e whorl (Figura 2.3) [Mai2005].

Left/right loop: questo tipo di impronta è caratterizzata da una o più cre-

ste che entrano da un lato, curvano formando una sorta di �U� (loop) e

tornano indietro, per poi fuoriuscire lungo la stessa direzione di ingresso.

La distinzione left/right identi�ca il lato dal quale entrano ed escono le

creste.

Arch: in queste impronte le creste cominciano da un lato del polpastrello, con-

tinuano assumendo curvature smussate senza formare loop né delta, e

2.1. CARATTERISTICHE DELLE IMPRONTE DIGITALI 15

Figura 2.2: Punti singolari

(a) Arch (b) Right loop (c) Left loop (d) Tented arch (e) Whorl

Figura 2.3: Classi di impronte

fuoriescono dal lato opposto rispetto a quello di ingresso.

Tented arch: questa tipologia è simile alla arch ma qui almeno una cresta è

caratterizzata da curvatura abbastanza stretta e sono presenti un loop e

un delta.

Whorl: impronte di questa classe presentano almeno una cresta il cui cam-

mino compie una rotazione completa attorno al core. Questa classe è in

e�etti molto variegata, e spesso le impronte che la compongono vengono

ulteriormente suddivise.

A livello locale, sono state identi�cate numerose caratteristiche particolari delle

creste, chiamate anche minuzie, cioè piccoli dettagli che corrispondono a ir-

regolarità nell'andamento delle creste. L'a�dabilità dell'individuazione delle

minuzie è fortemente in�uenzata dalla qualità dell'impronta; se troppo bassa,

può diventare impossibile distinguere le irregolarità dell'epidermide da quelle

dell'acquisizione.


Figura 2.4: I tipi di minuzia più comuni

Nonostante siano state individuate molti tipi diversi di minuzia, normalmen-

te si fa riferimento a un numero molto ridotto di classi perché di fatto a volte

le di�erenze tra due classi possono essere così piccole da rendere impossibile

una classi�cazione certa di impronte acquisite in condizioni non ottimali. In

Figura 2.4 sono mostrati alcuni tra i più comuni tipi di minuzia.

Generalmente si fa riferimento ad una particolare minuzia in termini di posi-

zione e orientamento relativo rispetto all'andamento della cresta (o delle creste)

di appartenenza [Baz2002].

2.2 Sistemi per identi�cazione automatica

L'identi�cazione tramite analisi manuale è un processo particolarmente oneroso,

in particolare in quei contesti che prevedono l'utilizzo di grandi database di

template. Proprio per questo nel tempo si è cercato di rendere il processo più

e�ciente sviluppando sistemi di classi�cazione che consentissero di partizionare

lo spazio di ricerca e quindi di ridurre il numero di confronti necessari per

l'identi�cazione di una singola impronta.

Esiste tuttavia un limite alla dimensione del database dei template perché

l'approccio manuale all'identi�cazione sia accettabile in termini di personale e

risorse richiesti per avere risposte in tempo utile. Per superare questo problema,

a partire dagli anni '60 alcune delle più famose polizie del mondo iniziarono ad

investire risorse economiche ed umane nello sviluppo di sistemi automatici per

il riconoscimento delle impronte digitali (Automated Fingerprint Identi�cation

Systems, AFIS) [Mai2005]. Oggi le tecnologie di riconoscimento automatico

delle impronte digitali sono utilizzate in numerose applicazioni civili e presso le

polizie di tutto il mondo, con conseguenti vantaggi sia in termini di e�cienza

2.2. SISTEMI PER IDENTIFICAZIONE AUTOMATICA 17

nell'identi�cazione dei criminali sia in termini di riduzione della dipendenza sulle

capacità di personale altamente specializzato.

Chapter 3

Matching di impronte digitali

L'operazione di matching consiste nel valutare il �grado di somiglianza� tra due

impronte. Normalmente gli algoritmi di matching possono essere visti come

delle black-box con 2 immagini in ingresso e uno scalare (il grado di somiglian-

za) in uscita, mentre la decisione di corrispondenza è lasciata a una sogliatura

e�ettuata a valle.

Spesso gli algoritmi richiedono che le due immagini subiscano un'elabo-

razione preliminare in modo da essere più facilmente confrontabili [Mai2005,

Nyo2004]. Di solito in queste elaborazioni si fa in modo che le immagini siano

ruotate e posizionate nello stesso modo (allineamento), e vengono eliminate le

aree dell'immagine nelle quali non è presente l'impronta (segmentazione).

Il matching può essere fatto in molti modi diversi, normalmente riconducibili

a 3 approcci distinti: basato su minuzie, sulle caratteristiche delle creste o sulla

correlazione [Mai2005, Mun2004, Nan2004].

3.1 Algoritmi basati sulle minuzie

In questo tipo di algoritmi si cerca una corrispondenza tra le minuzie rilevate

nelle due impronte.

Il primo passo consiste normalmente (ma non sempre) in un'ulteriore serie

di elaborazioni preliminari volte a sempli�care il rilevamento delle minuzie. Tra

queste troviamo:

� la binarizzazione, nella quale l'impronta acquisita in scala di grigio viene

trasformata in un'immagine binaria. La binarizzazione delle impronte digi-

tali è normalmente a�rontata con cura e con algoritmi più complessi rispet-

to alla classica sogliatura, il più semplice dei quali consiste nell'adottare

una sogliatura dinamica basata sulla luminosità locale dell'immagine;

19

20 CHAPTER 3. MATCHING DI IMPRONTE DIGITALI

� l'assottigliamento (thinning), nel quale le creste nell'immagine binaria ven-

gono assottigliate �no ad avere lo spessore di un solo pixel, in modo da

perdere la dipendenza dell'immagine da caratteristiche dello stato del pol-

pastrello al momento dell'acquisizione quali il grado di sudorazione e la

forza applicata sul sensore.

Il matching basato sulle minuzie è ritenuto molto e�cace anche grazie alla sua

secolare storia, ed è utilizzato in molti sistemi di identi�cazione delle impronte

digitali. Algoritmi di questo tipo rappresentano i punti in cui sono localizzate le

minuzie con un vettore contenente per ciascuna i propri parametri caratteristici

(posizione, orientamento e tipo) eventualmente insieme ad altre informazioni

locali, quali il numero di creste e la qualità della regione intorno ad essa.

L'operazione di matching delle minuzie si presenta essenzialmente come un

problema di corrispondenza puntuale di un certo tipo di pattern [Jai1997], uni-

voco per ogni impronta digitale. I problemi essenziali di questo approccio ri-

siedono nella necessità di individuare con buona accuratezza le caratteristiche

delle minuzie, mentre la realtà è che due acquisizioni dello stesso polpastrello

possono presentare grandi di�erenze a causa di cambiamenti �siologici (diverso

grado di costrizione dei vasi sanguigni, sudorazione, eventuali nuove lesioni, . . . )

o dovuti al processo di misura (allineamento diverso del dito, pressione diversa,

diversa deformazione subita dal polpastrello nell'appiattirsi sul sensore, . . . ).

Per questo sono stati proposti algoritmi basati su approcci di�erenti.

3.2 Algoritmi basati sulle caratteristiche globali

delle creste

Questa classe di algoritmi tenta di trarre la massima quantità di informazioni

possibili analizzando l'andamento complessivo delle creste. Rientrano in que-

sta categoria l'analisi del loro orientamento, della loro frequenza spaziale e dei

disegni che vanno a formare.

Nonostante le caratteristiche misurate da questi algoritmi siano più �stabili�

rispetto alle minuzie, cosa che peraltro li rende adatti all'analisi di impronte

di scarsa qualità, la loro capacità discriminatoria è scarsa. Pertanto queste

tecniche sono raramente usate da sole, e si preferisce a�ancarle a tecniche di

tipo diverso.

3.3 Algoritmi basati sulla correlazione

La terza categoria di algoritmi si basa sul calcolo di cross-correlazione spaziale (o

di altre funzioni ad essa riconducibili) tra i pixel corrispondenti di due immagini

3.3. ALGORITMI BASATI SULLA CORRELAZIONE 21

sovrapposte [Nan2004].

Si può ottenere così un indice quantitativo che può essere utilizzato come

misura del grado di somiglianza. Nonostante la presenza di rumore e di distor-

sioni non lineari riduca il valore di correlazione globale tra due impronte dello

stesso polpastrello, questi algoritmi sono noti per la loro robustezza e per la loro

capacità di lavorare anche con immagini di scarsa qualità.

Questa classe di algoritmi può anche essere considerata una sottoclasse di

quella presentata nel Paragrafo 3.2, ma è normalmente considerata come un'en-

tità a sé stante in letteratura in quanto coinvolge algoritmi di tipo sensibilmente

diverso.

22 CHAPTER 3. MATCHING DI IMPRONTE DIGITALI

Capitolo 4

L'algoritmo implementato

L'algoritmo per il matching di impronte digitali analizzato nel seguito rientra

nell'insieme di quelli basati sulla correlazione (Paragrafo 3.3). La scelta è caduta

su questo tipo di algoritmo per via della sua robustezza e per il fatto che ben si

presta a implementazioni su hardware dedicato e a implementazioni parallele.

Premessa indispensabile per la sua trattazione è la conoscenza della trasfor-

mata discreta di Fourier, più comunemente nota come DFT, che verrà breve-

mente illustrata nel prossimo paragrafo.

4.1 Discrete Fourier Transform (DFT)

La trasformata di Fourier discreta (Discrete Fourier Transform, DFT) è la ver-

sione della trasformata di Fourier applicabile a funzioni complesse di variabile

intera.

Data una sequenza {fn}N−1n=0 di N numeri complessi, la sua DFT è a sua

volta una serie di N valori Fk de�nita come:

Fk =

N−1∑

n=0

fnWnkN , k ∈ [0;N − 1]

mentre la trasformata inversa (Inverse Discrete Fourier Transform, IDFT) è

de�nita come:

fn =1

N

N−1∑

k=0

FkW−nkN , k ∈ [0;N − 1]

con WN = e−2πi

N .

È de�nita anche la trasformata di funzioni di più variabili. In particolare, per

questa trattazione è di interesse la trasformata bidimensionale (DFT2), de�nita

23

24 CAPITOLO 4. L'ALGORITMO IMPLEMENTATO

come:

Fk,h =

M−1∑

m=0

N−1∑

n=0

fn,mW knN Whm

M , (k, h) ∈ [0;N − 1] × [0;M − 1]

che verrà utilizzata nella de�nizione dell'algoritmo di matching.

4.2 Phase-Only Correlation

L'algoritmo Phase-Only Correlation (POC) [Ito2004, Ito2005] propone una tec-

nica di matching che utilizza la sola informazione di fase contenuta nelle tra-

sformate discrete di Fourier bidimensionali (DFT2) delle due impronte digitali

analizzate.

L'algoritmo parte da due impronte, indicate con i nomi di template e input ,

entrambe di dimensioni N1 × N2 con N1 = 2M1 + 1 e N2 = 2M2 + 1. Tali im-

magini sono rappresentate come due funzioni bidimensionali discrete di variabili

discrete f (n1, n2) e g (n1, n2) de�nite per ni ∈ [−Mi;Mi].

Il primo passo dell'algoritmo consiste nel calcolo delle DFT2 delle due im-

magini, che indichiamo con F (k1, k2) e G (k1, k2):

F (k1, k2) =

M1∑

n1=−M1

M2∑

n2=−M2

f (n1, n2) W k1n1

N1W k2n2

N2

= |F (k1, k2)| ejΘF (k1,k2)

G (k1, k2) =

M1∑

n1=−M1

M2∑

n2=−M2

g (n1, n2) W k1n1

N1W k2n2

N2

= |G (k1, k2)| ejΘG(k1,k2)

dove ΘF (·) e ΘG (·) rappresentano le componenti di fase delle due trasformate

di Fourier 2D discrete.

A questo punto, la funzione di cross-correlazione è de�nita come l'antitra-

sformata (IDFT2) della funzione

RFG (k1, k2) = F (k1, k2) G∗ (k1, k2)

= |F (k1, k2)| |G (k1, k2)| ej(ΘF (k1,k2)−ΘG(k1,k2))

La funzione di Phase-Only Correlation (POC) prevede invece di antitrasfor-

mare la funzione:

R̂FG (k1, k2) =RFG (k1, k2)

|RFG (k1, k2)|= ej(ΘF (k1,k2)−ΘG(k1,k2))

4.3. BAND-LIMITED PHASE-ONLY CORRELATION 25

Figura 4.1: Confronto tra la correlazione ordinaria (a) e la POC (b)

ottenendo:

r̂fg (k1, k2) =1

N1N2

M1∑

k1=−M1

M2∑

k2=−M2

R̂FG (k1, k2) W−k1n1

N1W−k2n2

N2

In Figura 4.1 è mostrato un confronto tra la correlazione ordinaria e la POC

applicate alla stessa coppia di impronte digitali provenienti dallo stesso dito,

dalle quali traspare come la seconda abbia migliori capacità discriminatorie (il

picco centrale è molto più evidente).

4.3 Band-Limited Phase-Only Correlation

I risultati della POC sono soddisfacenti, ma possono essere ulteriormente mi-

gliorati osservando che le impronte digitali hanno un contenuto informativo solo

�no a una certa (modesta) frequenza spaziale, che è quella caratteristica della

distanza tra le creste. Includere nel calcolo di r̂fg (·) anche le componenti a fre-

quenza maggiore ha il solo e�etto di introdurre una componente di solo rumore

ai calcoli, e necessariamente peggiora i risultati.

Quest'osservazione è alla base della Band-Limited Phase-Only Correlation

(BLPOC), che prevede di escludere dal calcolo le componenti ad alta frequenza

dell'immagine.

Modi�care l'algoritmo della POC per introdurre la limitazione di banda è

semplice. Si tratta di determinare l'area (centrata) delle DFT2 contenenti un

contributo di fase signi�cativo, che supponiamo essere di dimensioni L1 × L2

26 CAPITOLO 4. L'ALGORITMO IMPLEMENTATO

Figura 4.2: Confronto tra la POC (a) e la BLPOC (b)

con Li = 2Ki + 1 e de�nire la funzione BLPOC come:

r̂K1,K2

fg (n1, n2) =1

L1L2

L1∑

k1=−L1

L2∑

k2=−L2

R̂FG (k1, k2) W−k1n1

N1W−k2n2

N2

de�nita per (n1, n2) ∈ [−K1;K1] × [−K2;K2].

Un confronto tra la POC e la BLPOC è mostrato in Figura 4.2.

4.4 Calcolo dell'indice di corrispondenza

Dalle sezioni precedenti è risultato che il risultato della (BL)POC consiste in

una funzione che, quando le due immagini di input sono �simili�, ha un marcato

picco positivo.

Più formalmente, la (BL)POC di due immagini identiche è una delta di

Kronecker:

δ (n1, n2) =

1 n1 = n2 = 0

0 altrimenti

mentre per immagini diverse risulta comunque che r̂fg (·) abbia norma unitaria.

La posizione e il numero di picchi di tale funzione dipende dalla posizione relativa

delle due immagini, tenendo conto che parti diverse possono avere spiazzamenti

diversi a causa delle deformazioni elastiche della cute sul sensore. Per questo

normalmente non si fa a�damento né sulla posizione né sul numero di picchi, e si

calcola il grado di somiglianza combinando i picchi più signi�cativi o applicando

una funzione di media che privilegi i valori elevati.

Capitolo 5

Implementazione hardware

della DFT

5.1 Fast Fourier Transform (FFT)

Un'implementazione diretta delle de�nizioni di DFT e IDFT, come mostrate

nel Paragrafo 4.1, richiederebbe un tempo proporzionale a O(

N2)

. Per ridurre

il numero di operazioni sono stati sviluppati algoritmi più e�cienti del calcolo

diretto, noti come Fast Fourier Transform (FFT) [Qua2000].

FFT è una denominazione generale per indicare una famiglia di algoritmi per

il calcolo della DFT più veloci rispetto all'applicazione della de�nizione. Tali

algoritmi generalmente lavorano col principio del divide et impera, e traggono

le loro caratteristiche dalla possibilità di dividere gli N campioni in gruppi più

piccoli. Il modo in cui N è fattorizzabile è dunque un elemento critico per tali

algoritmi.

Nel caso applicativo in analisi, è stato possibile decidere di utilizzare un

valore di N pari a una potenza di 2. In questo caso, i più veloci algoritmi

applicabili (e in particolare l'algoritmo di Cooley-Tukey, di cui al Paragrafo 5.2)

hanno un costo computazionale pari a O(N log N).

5.1.1 Fast Fourier Transform in 2 dimensioni

Quanto detto sinora vale per le trasformate unidimensionali, cioè per la trasfor-

mazione di funzioni con un solo argomento scalare intero. Tuttavia l'obiettivo

nell'ambito della POC (Paragrafo 4.2) è quello di trasformare immagini, che sono

intrinsecamente a due dimensioni. Si pone dunque il problema di implementare

una trasformata in due dimensioni.

27

28 CAPITOLO 5. IMPLEMENTAZIONE HARDWARE DELLA DFT

Figura 5.1: La trasformata bidimensionale come composizione di trasformateunidimensionali

Elaborando la de�nizione di trasformata bidimensionale data nel Paragra-

fo 4.1, possiamo giungere a una rappresentazione alternativa:

F (n, m) =

M−1∑

y=0

N−1∑

x=0

f (x, y) WnxN Wmy

M

=

M−1∑

y=0

(

N−1∑

x=0

f (x, y) WnxN

)

WmyM

=

M−1∑

y=0

Q (n, y) WmyM , Q (n, y) =

N−1∑

x=0

f (x, y) WnxN

nella quale si osserva che F (·) è calcolabile prima facendo la trasformata di

f (·) rispetto a x, e poi trasformando quanto ottenuto rispetto a y. Gra�camen-

te, questo è equivalente a trasformare indipendentemente le righe, comporre

le trasformate ottenute a formare una nuova �immagine� a valori complessi, e

trasformare questa �immagine� per colonne (Figura 5.1).

La cosa essenziale è che in questo modo la trasformata bidimensionale è

espressa come insieme di trasformate unidimensionali, e diventa giusti�cato

concentrare gli sforzi analitici e implementativi su quest'ultima.

5.2 L'Algoritmo di Cooley-Tukey

Il più noto algoritmo per il calcolo della FFT è quello proposto da J. W. Cooley

e J. Tukey (e per questo noto come algoritmo di Cooley-Tukey, nel seguito C-T),

che lavora scomponendo ricorsivamente la DFT in un certo numero di DFT più

piccole, con l'obiettivo di ridurre la complessità del calcolo.

Tecnicamente, dato che l'algoritmo di C-T scompone DFT in altre DFT,

è possibile combinarlo con qualsiasi altro algoritmo per il calcolo delle DFT,

dando vita a numerose varianti. Nel seguito farò riferimento all'incarnazione più

comune dell'algoritmo, nota come radix -2 DIT (basata su decimazione binaria

5.2. L'ALGORITMO DI COOLEY-TUKEY 29

nel tempo), veloce e facilmente implementabile in hardware a patto che N sia

una potenza di due, basata sul progressivo dimezzamento del vettore di dati in

ingresso [Smi1997].

Si consideri una successione di N = 2S campioni. Sia Fk = F (k) la DFT di

tale successione.

Essendo N pari, è possibile suddividere la sommatoria in due sommatorie

distinte, una per i termini in posizione pari (2α) e una per i campioni in posizione

dispari (2α + 1):

F (k) =

N−1∑

n=0

fnWnkN

=

N/2−1∑

α=0

f2αW 2αkN +

N/2−1∑

α=0

f2α+1W(2α+1)kN

=

N/2−1∑

α=0

f2αW 2αkN + W k

N

N/2−1∑

α=0

f2α+1W2αkN

= G (k) + W kNH (k)

Così riscritta, la DFT iniziale risulta composta dalla somma di due DFT,

G (k) e H (k) (questa moltiplicata per il cosiddetto twiddle factor , ovvero per

l'esponenziale immaginario W kN ), entrambe di lunghezza N

2 . Una trasformata di

costo ∝ N2 risulta dunque scomposta in un'espressione di costo ∝(

N2

2 + 2N)

,

in cui il termine quadratico (le due DFT) può essere ricorsivamente scomposto

�no ad ottenere la trasformata banale dopo S = log2 N passi.

In termini operativi, occorre sottolineare che le due trasformate G (·) e H (·)

hanno lunghezza N2 , ma è possibile calcolare F (k) sfruttando le proprietà della

trasformata di Fourier:

G (k + N/2) = G (k)

H (k + N/2) = H (k)

Wk+N/2

N = −W kN

⇒ F

(

k +N

2

)

= G (k) − W kNH (k)

L'espressione di F (k) può essere quindi rappresentata gra�camente utiliz-

zando il diagramma di �usso riportato in Figura 5.2, noto come butter�y , nel

quale i nodi con due linee entranti sono nodi di somma. Il singolo elemento but-

ter�y rappresenta l'unità di elaborazione elementare dell'algoritmo C-T, nella

quale i risultati di DFT di piccole dimensioni sono combinati in una DFT di

lunghezza maggiore.

Lo schema butter�y resta valido anche per il calcolo dell'antitrasformata

(Inverse Fast Fourier Transform, IFFT), a patto di coniugare i coe�cienti di

twiddle e di dividere il risultato per N .


Figura 5.2: Elemento butter�y

Figura 5.3: Scomposizione di un vettore di 16 elementi

5.3 Struttura del componente di calcolo della FFT

Come detto nel Paragrafo 5.2, l'algoritmo di Cooley-Tukey si basa sulla de-

composizione ricorsiva del vettore da trasformare (di lunghezza N = 2S) �no a

ottenere un insieme di N vettori di lunghezza 1, la cui trasformazione è banale

(F1 = f1). Il primo passo dell'implementazione deve allora consistere nel deter-

minare quali siano le coppie di dati da porre in ingresso a ciascuno stadio della

catena butter�y.

Per �ssare le idee, si osservi la Figura 5.3, nella quale si è posto N = 16.

A partire dal vettore completo (in alto), la scomposizione procede separan-

do via via gli elementi in posizione pari da quelli in posizione dispari �no ad

arrivare (in basso) a un insieme di vettori di un solo elemento. Letto a ritroso,

il diagramma mostra come combinare i singoli elementi del vettore in ingresso

per trovare la trasformata del vettore originale.

Volendo �ssare la struttura della Figura 5.3, il problema dell'individuazio-

ne degli elementi da fornire ai primi stadi della catena può essere visto come

un problema di riordinamento dei dati, e così è stato e�ettivamente a�rontato

nell'implementazione.

La regola di riordinamento è nota come bit reversal , cioè la posizione di

ciascun elemento è ottenuta leggendo al contrario la rappresentazione binaria

della sua posizione originale (Tabella 5.1).

5.3. STRUTTURA DEL COMPONENTE DI CALCOLO DELLA FFT 31

NormaleDecimale Binario

0 00001 00012 00103 00114 01005 01016 01107 01118 10009 100110 101011 101112 110013 110114 111015 1111

⇒

Bit reversalDecimale Binario

0 00008 10004 010012 11002 001010 10106 011014 11101 00019 10015 010113 11013 001111 10117 011115 1111

Tabella 5.1: Un esempio di bit reversal

Per convincersene, è su�ciente osservare come al primo livello sia il bit meno

signi�cativo a discriminare tra i due insiemi, così che gli insiemi contengano ele-

menti col medesimo bit in ultima posizione; ai livelli successivi la discriminante è

data dai bit via via di signi�catività superiore, �no ad arrivare all'ultimo livello

nel quale la scelta avviene in base al bit più signi�cativo. Si tratta esattamente

del processo che si sarebbe potuto usare per associare un pro�lo di 4 bit alla sua

posizione, solo che in questo caso i bit sono letti da destra invece che da sinistra.

La trasformazione di un vettore di 16 elementi sarà quindi quella mostrata

in Figura 5.4 e, più nel dettaglio, in Figura 5.5.

Nell'implementazione proposta si è voluto costruire un blocco logico per la

trasformazione di vettori di 256 elementi (FFT256) usando come elemento base

una singola istanza di butter�y per la trasformazione di vettori di 64 elementi

(FFT64) [Bro2007, Mat2008]. Per questo il blocco FFT64 è stato contornato da

una logica ulteriore perché gli venissero fornite le 4 sequenze parziali corrette1

seguita dagli ultimi due stadi del butter�y.

Per contenere la complessità dell'hardware si è scelto di sviluppare unità

butter�y operanti in virgola �ssa. Volendo mantenere una ragionevole preci-

sione nei risultati nonostante le limitazioni insite nell'uso della virgola �ssa, e

considerato che i dati in ingresso per l'applicazione di interesse sono da 8 bit, si

è deciso di lavorare con parole da 32 bit espresse in modulo e segno2. I dati in

1È evidentemente stato necessario un ulteriore riordinamento.2Rispetto al più convenzionale complemento a 2, la rappresentazione in modulo e segno

ha il vantaggio di consentire l'implementazione delle divisioni per potenze di 2 come tra-


Figura 5.4: La catena butter�y per trasformare un vettore di 16 elementi

ingresso sono stati traslati di 23 posizioni a sinistra, è stato aggiunto uno `0' più

signi�cativo (per lavorare sempre con numeri positivi) ed è stata aggiunta una

parte immaginaria nulla.

Gli elementi butter�y sono stati implementati con un set di 6 sommatori,

4 moltiplicatori3 (Figura 5.6) e una ROM contenente i coe�cienti di twiddle

con parole da 18 bit (9 per la parte reale e 9 per quella immaginaria, con 8 bit

di modulo e 1 di segno). I risultati di somme e moltiplicazioni sono stati via

via privati dei bit meno signi�cativi per mantenere �ssa a 32 la lunghezza delle

parole elaborate.

5.4 L'ambiente di esecuzione

Il modulo FFT sviluppato, per quanto funzionante, non è autonomo. Occorre

inserirlo in un'infrastruttura che si occupi delle comunicazioni tra l'acceleratore

e il mondo esterno, e che si faccia carico di fornire al modulo i dati che questo

richiede.

Per ottenere questo risultato all'acceleratore è stata a�ancata una istan-

slazione a destra del modulo, anche quando il numero è negativo. Considerato il grandenumero di traslazioni necessarie all'interno dell'architettura, questo vantaggio è stato valutatocome largamente superiore rispetto al disagio indotto dal dover aggiungere un po' di logicasupplementare per la corretta gestione dei segni.

3Sommatori e moltiplicatori scalari � si ricorda che il butter�y opera su valori complessi.

5.4. L'AMBIENTE DI ESECUZIONE 33

Figura 5.5: La catena butter�y per trasformare un vettore di 16 elementi (indettaglio)


Figura 5.6: Elementi computazionali del blocco butter�y

za del microprocessore Nios II, un softcore fornito da Altera come elemento

istanziabile nelle proprie FPGA4. L'interfacciamento tra il processore e le pe-

riferiche è stato a�rontato utilizzando l'interfaccia Avalon e il SOPC Builder

(Figura 5.7), un'infrastruttura sviluppata da Altera per sempli�care la con�gu-

razione di sistemi complessi5 alla quale il modulo FFT si è dovuto conformare.

L'architettura complessiva (Figura 5.8) è risultata al�ne composta dal processo-

re, da un insieme di periferiche di sistema (memorie, timer, dispositivi di I/O e

PLL) e dal modulo FFT con�gurato come una periferica mappata in memoria.

L'interfacciamento della FPGA col mondo esterno si è così ridotto alla scrit-

tura di un programma per il processore, in grado di comandare una delle porte

di I/O a disposizione per ottenere i dati da elaborare e avviare il modulo FFT.

Questo è stato fatto in linguaggio C utilizzando il Nios II IDE e usando sia

l'interfaccia JTAG (per le fasi di sviluppo e diagnostica) sia la porta di rete

Ethernet. Un altro programma, sviluppato in Java�, è stato sviluppato per il

computer host per inviare alla scheda le immagini da trasformare e gestire i

risultati.

4Per maggiori dettagli, si veda l'Appendice A.5Per maggiori dettagli, si veda l'Appendice B.

5.4. L'AMBIENTE DI ESECUZIONE 35

Figura 5.7: Il SOPC Builder

Figura 5.8: L'architettura complessiva dell'acceleratore FFT


Figura 5.9: Accelerare con C2H

5.5 Un approccio alternativo: il compilatore C2H

In alternativa allo sviluppo tradizionale degli acceleratori, Altera mette da qual-

che tempo a disposizione un'estensione dell'ambiente Nios II IDE (il compilatore

C-to-Hardware, o più brevemente C2H) capace, stando a quanto dichiarato, di

tradurre codice scritto in �ANSI/ISO C� (cioè C89) in un acceleratore, con le

sole eccezioni di codice contenente operazioni in virgola mobile o ricorsioni. In

altri termini, usando questo strumento sarebbe in linea di principio possibi-

le scrivere una funzione C di calcolo della FFT per il processore Nios II, dire

all'ambiente di sviluppo di accelerare quella speci�ca funzione (Figura 5.9) e ot-

tenere in tempi relativamente brevi un acceleratore alternativo a quello descritto

al Paragrafo 5.3.

Le potenzialità di questo strumento sono state esplorate e si sono dimostrate

inferiori alle aspettative [Mer2008]. È di gran lunga troppo semplice scrivere

codice C corretto ma che il compilatore C2H:

� non compila (l'elaborazione si blocca, e anche attendendo giorni interi non

giunge al termine), oppure

� genera un risultato non funzionante.

Come esempio, una funzione come

int f(int a, int b, int c) {

int d, e;

d = a * b; /* Queste moltiplicazioni possono */

e = a * c; /* essere fatte in parallelo */

return d + e;

}

può essere in grado di mandare in crisi il compilatore C2H a causa della presenza

di due moltiplicazioni che è possibile fare in parallelo, perché il compilatore non

riesce a decidere se sia meglio farle e�ettivamente in parallelo (istanziando due

moltiplicatori) o in successione risparmiando risorse hardware. Deve pertanto

5.5. UN APPROCCIO ALTERNATIVO: IL COMPILATORE C2H 37

essere il programmatore a costruire il codice in modo da eliminare l'ambiguità.

Ad esempio, per fare le due operazioni in serie, il codice dovrebbe essere riscritto

come

/* La moltiplicazione è confinata a una funzione */

int mul(int x, int y) {

return x * y;

}


int d, e;

d = mul(a, b); /* Le due chiamate alla stessa funzione */

e = mul(a, c); /* devono essere fatte in serie */

return d + e;

}

o, in alternativa,

/* La prima moltiplicazione */

int mul1(int x, int y) {

return x * y;

}

/* La seconda moltiplicazione */

int mul2(int x, int y) {

return x * y;

}


int d, e;

d = mul1(a, b); /* Le due chiamate a funzioni diverse */

e = mul2(a, c); /* possono essere fatte in parallelo */

return d + e;

}

per l'esecuzione parallela.

Da questo esempio appare del tutto evidente come in realtà il codice C �ac-

celerabile� debba essere scritto con particolare cura e spesso in modo diverso da

come sarebbe stato scritto da un programmatore C per un'esecuzione software.

Una implementazione C �accelerabile� della FFT è stata comunque scritta,

e l'adattamento di una funzione scritta per un'esecuzione software6 ha richiesto6Considerando che il valore reale del prodotto dipende anche dalla possibilità di utilizzare


comunque meno tempo rispetto alla scrittura ex-novo dell'acceleratore, dimo-

strando quindi che tale strumento è in grado di ridurre davvero i tempi di

sviluppo dell'hardware � a patto che Altera continui a investire risorse nel suo

a�namento.

algoritmi non ottimizzati per l'hardware � perché altrimenti si starebbe semplicemente de-scrivendo l'hardware in C, e per tale attività esistono linguaggi migliori � l'algoritmo è statoscelto tra quelli e�cienti per un'esecuzione software. In particolare, non è stato utilizzatol'algoritmo di Cooley-Tukey.

Capitolo 6

Risultati

L'acceleratore è stato collaudato in prima istanza su una scheda di sviluppo

basata sulla FPGA Stratix1 1S40 (Appendice A, Paragrafo A.2.1), e una volta

veri�cata la correttezza delle operazioni è stato fatto il porting a una più recente

scheda di sviluppo basata su FPGA Stratix II 2S60 (Paragrafo A.2.2). Per

entrambe le soluzioni sono state valutate le prestazioni ottenute.

L'acceleratore sintetizzato dal compilatore C2H è stato collaudato sulla sola

scheda Stratix, mentre il porting su Stratix II è stato rimandato a causa di

di�coltà tecniche.

Il confronto tra le varie implementazioni di DFT256 è sintetizzato in Tabel-

la 6.1.

Implementazione Clock Tempo % LE % DSP % RAM

C su Pentium IV 2.4GHz 292µs � � �C-T su Stratix 50MHz 87µs 42% 100% 7%C-T su Stratix II 100MHz 32µs 32% 44% 9%

C su Nios II e Stratix 50MHz 1.2 s 9% 7% 1%C2H su Stratix 50MHz 32ms 22% 36% 17%

Tabella 6.1: Prestazioni delle implementazioni della DFT256

Dall'analisi dei risultati è possibile trarre numerose conclusioni interessanti:

1. un'implementazione su FPGA della FFT è potenzialmente molto più ve-

loce (un ordine di grandezza) rispetto a una esecuzione software su un

calcolatore domestico contemporaneo;

2. l'esecuzione del software sul processore Nios II è estremamente più lenta

rispetto a quella sul PC e, per quanto e�cace, l'ottimizzazione indotta dal

compilatore C2H non riesce a rendere la soluzione su FPGA competitiva;

1Stratix è la famiglia di punta delle FPGA Altera.

39

40 CAPITOLO 6. RISULTATI

3. il cambio di generazione di FPGA ha più che dimezzato il tempo di ese-

cuzione della trasformata e consente di istanziare un secondo acceleratore

sul chip in modo da poter procedere a due trasformate in parallelo.

L'utilizzo di FPGA come alternativa a cluster di calcolatori si rivela in questo

caso vincente, perché consente di raggiungere prestazioni di ordini di grandezza

superiori pur richiedendo un costo che, nel caso del sistema di sviluppo utilizza-

to, sono nell'ordine del doppio rispetto a quello del PC, ma che per produzioni

in volumi medio-grandi può ridursi notevolmente grazie alla progettazione di

schede dedicate che eliminino le componenti non utilizzate delle schede di svi-

luppo. Ulteriori incrementi di prestazione sono altresì ottenibili utilizzando i

modelli più capaci di FPGA, che consentirebbero di ospitare un numero ancora

maggiore di acceleratori.

La valutazione sperimentale utilizzando FPGA Stratix III non è stata pos-

sibile a causa della mancanza di schede di sviluppo2; vale tuttavia la pena di

sottolineare che il confronto dovrebbe sempre essere fatto con hardware contem-

poraneo, e che quindi un'implementazione su Stratix III andrebbe confrontata

con i più veloci processori multicore sul mercato. Questo porta a concludere

che probabilmente, anche se la sperimentazione fosse stata a�rontata usando

l'hardware più recente a disposizione, le relazioni emerse non sarebbero mutate

signi�cativamente.

2Le schede con Stratix III sono state di recente messe in commercio, ma non è stato co-munque possibile procedere alla sperimentazione sia a causa dei costi ancora molto elevati siaa causa dei tempi che sarebbero comunque stati insu�cienti.

Parte II

Double-Precision

Floating-Point Accelerator

41

Capitolo 1

Introduzione

DPFPA (Double-Precision Floating-Point Accelerator, [Dan2007a]) è un accele-

ratore per calcoli in virgola mobile, sviluppato presso il Laboratorio di Micro-

calcolatori a partire dall'anno 2000 e giunto a una soluzione stabile durante il

mio corso di Dottorato.

L'obiettivo principale del progetto DPFPA è quello di valutare l'applicabilità

di acceleratori hardware dedicati a problemi di meccanica statistica, nei quali si

tenta di calcolare lo stato �sico di un sistema di particelle adottando un approc-

cio simulativo statistico piuttosto che uno analitico/deterministico, che per la

sua complessità (prevalentemente dovuta all'elevato numero di particelle) risul-

ta normalmente intrattabile anche con problemi di medie dimensioni [Fre1996].

L'applicazione di acceleratori si contrappone all'utilizzo di cluster di calcolato-

ri comuni e alla possibilità di acquistare tempo di calcolo su supercalcolatori

(costoso e normalmente non immediatamente disponibile).

Le particelle analizzate sono normalmente �sicamente organizzate in reticoli,

strutture di varia complessità la cui regolarità aiuta a mantenere la richiesta di

risorse di calcolo entro limiti accettabili. L'assunzione di struttura reticolare non

è però solo una sempli�cazione algoritmica: molti materiali, e in particolare i

cristalli, sono naturalmente reticolari, e per questo l'analisi condotta su strutture

reticolari trova riscontro nelle misure sperimentali.

Dei vari possibili reticoli, per DPFPA è stato scelto quello cubico per la sua

semplicità. È tuttavia possibile riprogrammare l'acceleratore in modo da gestire

reticoli più complessi, al prezzo di un maggiore tempo di calcolo.

Nell'analisi di sistemi di particelle si pone anche il problema di scegliere la

dimensione del reticolo. Nei sistemi �sici i reticoli sono composti da innumere-

voli particelle, di dimensioni paragonabili a quelle degli atomi, e non è realistico

pensare di simulare un sistema con un numero così grande di particelle. Per que-

sto si preferisce simulare il comportamento di un reticolo relativamente piccolo

43


applicando le condizioni periodiche al contorno (Periodic Boundary Conditions,

[All1987]) per le quali le particelle ai lati opposti del reticolo sono considerate

adiacenti. In questo modo si eliminano gli e�etti di bordo dovuti alla �nitezza

del reticolo, diventa possibile ottenere buoni risultati in tempi ragionevoli e si ha

una sempli�cazione del codice di gestione dovuto all'uguaglianza tra le particelle

(le particelle sul bordo non ricevono un trattamento diverso da quelle interne).

Il reticolo analizzato con DPFPA tratta l'ordine orientazionale delle parti-

celle del reticolo, caratterizzate da un campo di dipolo e soggette a un campo

elettrico esterno. È questo un caso di particolare interesse nello studio dei

cristalli liquidi e delle soluzioni colloidali [Dan2001].

1.1 L'algoritmo di simulazione

Per questa simulazione si è utilizzato un algoritmo di tipo Monte Carlo. Si

tratta questa della classe più ampia e importante di metodi numerici utilizzati

per risolvere problemi di meccanica statistica [Met1953, Bin1988, New1999],

e metodi di questo tipo sono tra i più utilizzati per la soluzione di problemi

complessi.

La �loso�a dei metodi Monte Carlo è la seguente: dato un sistema arbi-

trariamente complesso e �ssato uno stato iniziale casuale, se ne sceglie a caso

una possibile evoluzione (una mossa o move) coinvolgente una sola particella. Il

nuovo stato viene valutato secondo una cifra di merito (En+1, spesso correlata

con l'energia totale del sistema) e confrontato con lo stato di partenza (En) per

ottenere una misura di �plausibilità� ∆En+1 = En+1 −En. Il nuovo stato viene

accettato come evoluzione �valida� del sistema se e−β∆En+1 > rnd (), dove rnd ()

è una funzione che restituisce un numero casuale in [0; 1) con probabilità unifor-

me e β > 0 è un opportuno coe�ciente di dimensionamento. Conseguenza della

regola di accettazione è che se ∆En+1 < 0 allora il nuovo stato è �sicamente

più �plausibile� del precedente e viene sempre accettato, mentre se ∆En+1 > 0

l'accettazione è fatta su base probabilistica, cioè esiste sempre una probabilità

non nulla di accettazione del nuovo stato. Questo criterio consente all'algoritmo

di uscire da eventuali minimi locali, aumentando così la probabilità che al ter-

mine dell'elaborazione lo stato del sistema sia quello corrispondente al minimo

globale (o almeno a un buon minimo locale). L'entità delle move scelte duran-

te l'elaborazione viene mantenuta tale da rendere la probabilità di accettazione

media attorno al 50%, con conseguente graduale stabilizzazione del sistema man

mano che questo si avvicina allo stato �nale.

L'operazione di generazione e valutazione delle move (nel suo complesso nota

come step) deve avvenire un numero elevato di volte per consentire a tutte le

particelle del sistema di evolvere. Dato un reticolo con N particelle, e consi-

1.2. IL MODELLO FISICO 45

derato che la probabilità di accettazione di una move è attorno al 50%, perché

lo stato di ciascuna particella venga mediamente cambiato una volta occorrono

2N step, quantità alla quale viene dato il nome di macrostep. Normalmente una

simulazione completa richiede almeno 104 macrostep, così che la probabilità che

una particella resti al suo stato iniziale risulti trascurabile.

1.2 Il modello �sico

Le equazioni per il calcolo dell'energia del singolo dipolo derivano direttamente

dalla soluzione delle equazioni che regolano l'interazione tra i vari dipoli ricavata

da uno studio e�ettuato su un sistema di N dipoli posizionati su un reticolo

cubico.

Il momento di dipolo indotto pi sul dipolo i-esimo risulta essere

pi = αiEloci

dove αi rappresenta la polarizzabilità del dipolo considerato mentre Eloci è il

campo locale

Eloci = E0 +

∑

j 6=i

Ej→i

con Ej→i che rappresenta il campo dovuto all'interazione tra i dipoli pi e pj .

Sviluppando i conti (per i quali si rimanda a [Spe2004]), si ottengono le equazioni

da implementare nell'algoritmo di calcolo.

Occorre notare che al �ne di determinare l'energia associata al dipolo pi

andrebbero calcolate le Ej→i per tutti i dipoli che compongono il sistema esa-

minato, con un costo computazionale notevole anche dovuto alla necessità di

utilizzare numeri in virgola mobile a doppia precisione. Considerato però che

l'intensità dell'iterazione tra dipoli è inversamente proporzionale alla distanza

fra di essi, si ritengono signi�cative solo le interazioni con i dipoli cosiddetti

�primi vicini�, cioè i 6 dipoli che condividono con quello in esame un cubo del

reticolo.

Anche in considerazione della restrizione dell'interazione dipolare ai soli 6

dipoli più vicini, il calcolo dell'energia totale richiede un approccio iterativo per

consentire agli e�etti delle move di propagarsi �no ai dipoli più lontani. Dai dati

sperimentali risulta che la propagazione del campo elettrico all'intero reticolo

ripetuta per 8 volte garantisce che l'energia calcolata sia su�cientemente stabile

(con variazioni tra le iterazioni entro un fattore 10−6) per poter e�ettuare il test

Monte Carlo.


1.3 Un acceleratore per calcoli in virgola mobile

a doppia precisione

In tutte le applicazioni in cui le prestazioni rappresentano un requisito parti-

colarmente importante si rende necessario trovare strumenti e�caci in grado

di misurare il tempo di calcolo richiesto dalle diverse sezioni di un programma

per poter focalizzare gli sforzi di ottimizzazione sulle parti più onerose, senza

perdere tempo nel tentativo di ottimizzare quelle parti che incidono in maniera

trascurabile sui tempi di esecuzione.

Misurando con un pro�ler i tempi di esecuzione impiegati nel corso delle

simulazioni, si è visto che oltre l'85% del tempo di calcolo è utilizzato dalla

funzione che si occupa del calcolo dell'energia. Si è pertanto deciso di realizzare

un sistema in grado di eseguire questo calcolo in modo più veloce di un normale

computer.

Questo progetto prevede quindi di realizzare un'unità di calcolo che si occupi

di eseguire il calcolo dell'energia. Questo dispositivo, o più dispositivi di questo

tipo, verranno quindi interfacciati con un PC che si occuperà di controllarli e di

fornirgli i dati da elaborare.

Dopo una prima fase di progetto nella quale si è lavorato con l'intenzione

di realizzare un acceleratore per il calcolo dell'energia in sistemi dipolari, è

risultato evidente che a fronte di una modesta complicazione dell'architettura

sarebbe stato possibile realizzare un acceleratore di applicabilità più generale.

Questa considerazione ha portato alla progettazione di un acceleratore per i

calcoli in virgola mobile applicabile a qualsiasi algoritmo.

Il dispositivo è costituito da due unità di calcolo (ALU), dotate di un mol-

tiplicatore, un sommatore e un comparatore ciascuno con una propria pipeli-

ne, che lavorano parallelamente. Un'unità di divisione non è stata inclusa in

quanto non necessaria all'implementazione delle funzioni alla cui accelerazione

è dedicato questo progetto.

Alle unità di calcolo si a�anca una memoria di tipo dual-port in grado di

memorizzare 32 768 dati in virgola mobile a doppia precisione (64 bit). Con

questa memoria il dispositivo risulta, in una certa misura, indipendente dal

PC, con conseguente riduzione delle comunicazioni che avrebbero costituito un

problematico collo di bottiglia. La memoria è stata partizionata in 4 blocchi

(denominati cache) che vengono gestiti, direttamente dall'hardware, in modo

similare a pagine di memoria virtuale. Questo consente di assegnare e anche di

riassegnare durante l'esecuzione le varie pagine in lettura e/o scrittura a una

delle due ALU o al PC che controlla il dispositivo.

L'architettura risultante garantisce una grande versatilità, consentendo di

creare catene di elaborazione in cui le due unità di calcolo lavorano su passi

1.3. UN ACCELERATORE PER LA VIRGOLA MOBILE 47

successivi dell'elaborazione. Inoltre si rende possibile usare una delle cache per

caricare i dati da PC mentre le altre vengono utilizzate dalle unità di calcolo per

l'elaborazione, in modo da gestire elaborazione e I/O in parallelo, consentendo

così alle ALU di lavorare senza interruzioni.

Ovviamente inserendo una memoria a bordo del dispositivo è stato necessario

dotare il dispositivo stesso di due unità (una per ciascuna ALU) incaricate di

gestirne l'accesso. Tali dispositivi prendono il nome di Gestori di Memoria

(GM).

Capitolo 2

L'architettura di DPFPA

La progettazione del sistema di calcolo in oggetto ha seguito un approccio

top-down, nel quale si è proceduto a partizionare il progetto �no a ottenere

la de�nizione di un insieme di blocchi funzionali �base�. A questo punto la rea-

lizzazione e il collaudo delle unità funzionali è proceduta dal basso, iniziando

dalle foglie dell'albero di partizionamento e risalendo verso la radice. I collaudi

sono stati a�rontati utilizzando un simulatore per quanto riguarda i blocchi più

semplici, mentre il dispositivo completo è stato collaudato direttamente imple-

mentandolo sulla scheda, per contenere i tempi di esecuzione (la simulazione è

un processo oneroso) e risolvere il problema della generazione del vettore degli

ingressi, la cui complessità cresce con quella dell'architettura simulata.

Nelle prossime pagine illustrerò le componenti principali dell'architettura

realizzata, rimandando a [Spe2004] per una descrizione di maggiore dettaglio.

In Figura 2.1 è riportato lo schema generale dell'architettura, che come si

può vedere si compone di un'Unità di Controllo e di due acceleratori composti da

un'unità di calcolo, un gestore di memoria (GM) e da un gestore di cache virtuali

(GCV). Tutte queste unità sono programmabili tramite il Sub Bus, attraverso

il quale il dispositivo si interfaccia col mondo esterno.

La funzione delle unità implementate è la seguente:

� le cache sono 4 memorie di tipo dual-port da 64KiB ognuna, organizzate

in parole da 64 bit, per uno spazio di indirizzamento di 8 192 posizioni

(13 bit di indirizzo) con possibilità di essere lette o scritte con parole a

32 bit;

� l'unità di calcolo si occupa di eseguire tutte le operazioni in virgola mobile

a doppia precisione ed è stata pensata per elaborare un �usso di dati in

ingresso (a 64 bit) e fornire i risultati tramite un �usso di dati in uscita;

49

50 CAPITOLO 2. L'ARCHITETTURA DI DPFPA

Figura 2.1: Il dispositivo di calcolo

� il Gestore di Memoria (GM) si occupa di decidere quali dati fornire al-

l'unità di calcolo e in quale ordine, e si occupa anche di decidere dove

memorizzare i risultati da essa forniti. Praticamente il gestore di memoria

si occupa di creare un �usso di indirizzi (a 15 bit) con i relativi segnali

di controllo che verranno poi utilizzati dal Gestore di Cache Virtuali per

gestire i �ussi di dati da e per l'unità di calcolo;

� il Gestore di Cache Virtuali (GCV) si occupa di prendere gli indirizzi for-

niti dal GM e i dati in uscita dall'unità di calcolo e dopo aver deciso quale

sia l'operazione più conveniente da fare (lettura o scrittura) la esegue.

Inoltre si occupa della mappatura nello spazio d'indirizzamento virtuale

dei due acceleratori delle 4 cache �siche;

� l'Unità di Controllo si occupa di generare le istruzioni per l'unità di calcolo

e per il gestore di memoria dei due acceleratori. Inoltre si occupa di gestire

i risultati delle operazioni di confronto sui numeri in virgola mobile.

Si entrerà ora nel dettaglio dei vari blocchi qui brevemente presentati partendo

dall'unità di calcolo che è il cuore dell'acceleratore.

2.1. UNITÀ DI CALCOLO 51

Figura 2.2: Unità di calcolo

2.1 Unità di Calcolo

Come detto l'unità di calcolo si occupa di eseguire i calcoli in virgola mobile a

doppia precisione. Essa si compone, come si vede in Figura 2.2, di 5 blocchi:

� una Unità Aritmetico-Logica (ALU) che esegue i calcoli;

� 3 code FIFO che si occupano di memorizzare i dati in ingresso, i dati in

uscita e i risultati dei confronti sui numeri in virgola mobile eseguiti dalla

ALU;

� un sequenziatore che si occupa di generare i segnali di controllo per la

ALU.

2.2 Sequenziatore di microistruzioni

Questa unità è essenzialmente un'unità di controllo microprogrammata, che pe-

rò a di�erenza di quanto disponibile nell'ambito delle CPU general-purpose non

prede�nisce un set di istruzioni. L'utente deve pertanto stabilire e programmar-

vi un set di istruzioni prima di poterla utilizzare. È possibile implementare �no

a 64 istruzioni che verranno poi identi�cate tramite un codice operativo a 6 bit.

Ogni istruzione si compone di una sequenza di parole codi�cate, che chiame-

remo microistruzioni, eseguite in un unico ciclo di clock. È possibile utilizzare

un massimo di 1 000 microistruzioni, ma questo limite può essere aumentato

cambiando un parametro nel progetto.

Una volta programmato, il sequenziatore si occupa, partendo dal codice della

istruzione da eseguire (6 bit) datogli dall'unità di controllo, di fornire alla ALU

una dopo l'altra tutte le microistruzioni in microcodice necessarie ad eseguirla.


Figura 2.3: Sequenziatore di microistruzioni

Il sequenziatore gestisce inoltre gli stalli per assenza di dati o istruzioni o nel

caso la FIFO in uscita sia piena.

Come si vede nello schema in Figura 2.3, i codici delle istruzioni forniti

dall'unità di controllo vengono memorizzati in una FIFO da cui poi vengono

richiamati ogni volta che è necessario eseguire una nuova istruzione (quando

quella precedente viene completata).

Questi codici vengono quindi decodi�cati da una lookup table che forni-

sce al sequenziatore vero e proprio l'indirizzo di partenza della sequenza di

microistruzioni relativa all'istruzione da eseguire.

2.3 Unità Aritmetico-Logica (ALU)

La ALU è stata pensata per eseguire sequenze di operazioni complesse su grandi

insiemi di dati. Per questo si è fatto in modo che potessero essere fatte più

operazioni simultanee nell'ambito di una singola microistruzione, e dunque nel

singolo ciclo di clock.

Un insieme di 3 banchi di 4 registri è a disposizione di sommatore e mol-

tiplicatore. Ciascun registro può essere usato per fornire un operando, per un

totale di 12 possibili operandi, cui si a�ancano 4 operandi �immediati� (il da-

to attualmente in ingresso alla ALU, l'elemento neutro per l'operazione e gli

ultimi risultati in uscita a sommatore e moltiplicatore). La scrittura sui 3 ban-

chi pone invece una limitazione diversa: un banco può essere scritto solo con

2.4. GESTORE DI MEMORIA 53

Figura 2.4: Schema del gestore di memoria

i dati in ingresso alla ALU, uno coi risultati del sommatore e uno con quelli

del moltiplicatore. È inoltre possibile applicare operazioni di cambio di segno

e di moltiplicazione o divisione per 2 agli operandi senza l'onere di operazioni

aggiuntive.

Moltiplicatore e sommatore hanno pipeline di lunghezza diversa. Per favorire

la sincronizzazione dei risultati, è possibile bloccare l'avanzamento delle pipe-

line tramite un'operazione di NOP, mentre l'avanzamento della pipeline quan-

do non vi siano più dati utili da elaborare deve essere a�rontato comandando

l'esecuzione di calcoli inutili dei quali verrà poi ignorato il risultato.

2.4 Gestore di Memoria

Come si vede in Figura 2.4 il gestore di memoria ha uno schema simile a quello

dell'unità di calcolo. Anche qui è presente un sequenziatore, che è del tutto simile

a quello dell'unità di calcolo con le sempli�cazioni indotte dal non richiedere la

gestione di dati provenienti dall'esterno.

Anche il gestore di memoria, come la ALU, non ha un set di istruzioni

precostituito, ma ha un set di istruzioni programmabile che deve essere de�nito

dall'utente. Come per la ALU è possibile implementare �no a 64 istruzioni che

verranno poi richiamate tramite un codice a 6 bit. Ogni istruzione si compone di

una sequenza di parole codi�cate (microistruzioni) eseguite in un unico ciclo di

clock. È possibile memorizzare �no a un totale di 1 000 microistruzioni (limite

facilmente modi�cabile tramite opportuni parametri).

Il codice delle microistruzioni viene memorizzato all'interno del sequenziatore

di microistruzioni che si occupa, partendo dal codice operativo dell'istruzione

da eseguire, di fornire al Gestore di Memoria le microistruzioni, una ad ogni

ciclo di clock, necessarie a realizzare l'istruzione richiesta.

Il Gestore di Memoria vero e proprio, invece, si occupa di generare un �usso

di indirizzi di lettura e scrittura, in base a quanto speci�cato dalla sequenza di

microistruzioni, i quali vengono poi mandati al Gestore di Cache Virtuali che si

occupa di realizzare �sicamente la lettura o la scrittura in memoria.


Il Gestore di Memoria è stato pensato per addattarsi bene a problemi in

cui i dati siano strutturati in forma matriciale. In quest'ottica è stato deciso di

organizzare la memoria come una grande matrice a 4 dimensioni: le dimensioni

X, Y e Z faranno riferimento alle dimensioni �siche di generiche matrici a 3

dimensioni, mentre la quarta dimensione (T) verrà usata per selezionare una

tra le diverse matrici tridimensionali allocate.

L'accesso alla memoria viene a questo punto gestito utilizzando direttamente

una notazione matriciale. Per far riferimento a uno speci�co elemento occorre

dunque speci�care 5 valori: le tre coordinate X, Y e Z, la matrice a cui ci si

riferisce (T) e la cache virtuale da utilizzare. Due di questi valori, la matrice di

riferimento (T) e la cache virtuale da utilizzare, vengono forniti esplicitamente

all'interno delle microistruzioni. Le tre coordinate invece possono essere fornite

sia direttamente (indirizzamento assoluto), sia tramite un puntatore e uno spiaz-

zamento, fornito separatamente sulle 3 coordinate (indirizzamento relativo). In

quest'ultimo caso il puntatore può essere selezionato tra uno dei 64 puntatori di

cui GM è fornito; lo spiazzamento può essere 0, +1 o −1 su qualsiasi coordinata;

quindi se il puntatore usato valesse (X, Y, Z) sarebbe possibile indirizzare i dati

all'interno del cubo di lato 3 (X ± 1, Y ± 1, Z ± 1), pertanto 27 possibili valori

(il GM gestisce in modo trasparente le condizioni periodiche al contorno, quindi

non occorre trattare in modo particolare i bordi delle matrici).

È possibile cambiare il valore corrente di un qualunque puntatore sia inizia-

lizzandolo direttamente ad un nuovo valore sia calcolando il nuovo valore par-

tendo da un qualunque puntatore e applicandogli uno spiazzamento in maniera

similare a quanto fatto per gli indirizzi.

Questo sistema a puntatori, apparentemente macchinoso, è particolarmente

adatto per la classe di applicazioni pensate per questo dispositivo (la propa-

gazione delle move e il calcolo dell'energia) perché consente di mantenere una

stretta corrispondenza tra il codice della ALU e quello del GM, caratteristica

chiave per l'ottenimento di elevate prestazioni.

Anche il Gestore di Memoria è realizzato in modo pipeline, con 4 stadi per

la generazione di un indirizzo di lettura o scrittura e 3 stadi per la modi�ca dei

puntatori. Quest'ultimo comporta peraltro che esista una latenza di 3 cicli di

clock tra la microistruzione di modi�ca del puntatore e l'e�ettiva disponibilità

del nuovo valore.

2.5 Gestore di Cache Virtuali

Come detto, il dispositivo implementato è dotato di 4 memorie dual-port da

64KiB ognuna con parole da 64 bit; ogni memoria può pertanto contenere 8 192

numeri in virgola mobile.

2.5. GESTORE DI CACHE VIRTUALI 55

Questa memoria non è stata pensata per contenere tutti i dati necessari

all'elaborazione di un certo problema, ma come memoria temporanea atta a

contenere una parte dei dati relativi al problema da elaborare. Il problema do-

vrebbe pertanto essere diviso in blocchi e i dati relativi ad un blocco dovrebbero

essere caricati in una o più di queste memorie a�nché il dispositivo possa ela-

borarli; mentre il dispositivo elabora un blocco di dati, il sistema che lo ospita

dovrebbe quindi provvedere a caricare una nuova porzione di dati in un'altra di

queste memorie in modo che sia pronta a elaborazione ultimata.

La presenza di più blocchi di memoria consente, in linea di principio, l'utiliz-

zo dei due acceleratori in cascata. Per essere e�ciente, tuttavia, gli acceleratori

non dovrebbero essere riprogrammati ad ogni passo ma dovrebbero poter riu-

tilizzare inde�nitamente lo stesso programma. Questo solleva la questione di

mappare dinamicamente gli indirizzi di memoria richiesti dai gestori di me-

moria (sempre gli stessi) a blocchi diversi, così da consentire l'elaborazione di

un nuovo blocco non appena è terminata l'elaborazione del blocco precedente

semplicemente facendo accedere l'elaboratore a un'altra area di memoria.

Il Gestore di Cache Virtuali (GCV) si occupa proprio di quest'operazione

di mappatura dinamica. Come illustrato in Figura 2.5, il GCV crea 4 spazi di

indirizzamento virtuali (i Canali 1, 2, 3 e 4) ognuno dei quali ha la dimensione

dell'intero spazio di memoria (256KiB). Ognuno di questi spazi di indirizza-

mento è a sua volta suddiviso in 4 aree a ciascuna delle quali può essere asse-

gnata una qualunque delle 4 cache reali (Cache 1, 2, 3 e 4), potenzialmente con

assegnazioni diverse per quanto riguarda la lettura e la scrittura.

I Canali 1 e 2 sono associati al primo acceleratore, mentre i Canali 3 e 4 sono

relativi al secondo acceleratore. Più precisamente, i canali dispari sono collegati

direttamente agli acceleratori mentre quelli pari sono ad uso del dispositivo

ospitante, che adotta un bus di accesso a 32 bit e pertanto richiede che gli accessi

a parole da 64 bit siano opportunamente spezzati.

È possibile assegnare alla stessa area �sica più cache in scrittura, ottenendo

in questo modo di avere due cache che contengono gli stessi dati (modalità mir-

ror). L'utente può de�nire �no a 16 (anche questo è un parametro modi�cabile

del dispositivo) assegnazioni diverse delle cache e passare dall'una all'altra in

un'unica operazione della durata di un ciclo di clock.

In Figura 2.6 è riportato lo schema funzionale di uno dei due gestori di cache

virtuali.

Come si vede per ogni cache reale esiste un blocco (Selettore di lettura e

scrittura) che si interfaccia direttamente con essa e che si occupa di creare i due

canali separati. Il canale 2 è quindi connesso direttamente al Sub Bus tramite

cui il sistema che ospita il dispositivo può accedervi.

Invece gli indirizzi per il canale 1, quello connesso ad uno degli accelera-


Figura 2.5: Schema di interfacciamento con le cache

tori, vengono memorizzati in due code FIFO separate (una per gli indirizzi di

lettura e l'altra per quelli di scrittura). Quindi un apposito blocco (Gestore

di Letture/Scritture e Port Map), dopo aver deciso quale operazione (lettura o

scrittura) è meglio fare al �ne di minimizzare gli stalli dell'acceleratore, si occu-

pa di eseguirla fornendo ai blocchi di controllo delle cache i segnali di controllo

appropriati e applicando l'opportuna traduzione tra indirizzi virtuali e indirizzi

�sici.

Per quanto riguarda i Selettori di lettura e scrittura, si tratta di disposi-

tivi semplici costituiti prevalentemente da una cascata di multiplexer per la

selezione degli opportuni segnali da inviare alle cache �siche e la gestione del-

l'interfacciamento tra il mondo a 32 bit del sistema ospitante e quello a 64 bit

degli acceleratori.

2.6 Unità di Controllo

Ricapitolando quanto �nora detto, il dispositivo realizzato funziona in questo

modo: sono presenti 2 acceleratori ognuno composto da un Gestore di Memoria

(GM), da un'Unità di Calcolo (UC) e da un Gestore di Cache Virtuali (GCV).

Al �ne di poter utilizzare il dispositivo l'utente deve creare un proprio set di

istruzioni in grado di realizzare tutte le funzioni necessarie per risolvere il pro-

blema considerato. A questo punto, dopo che sia la UC che il GM sono stati

programmati con il nuovo set di istruzioni, è necessario stabilire quali istruzioni

eseguire, in quale ordine e quante volte un'istruzione vada ripetuta.

Va quindi realizzata una sequenza di istruzioni che una volta eseguita porti

2.6. UNITÀ DI CONTROLLO 57

Figura 2.6: Schema del Gestore di Cache Virtuali

alla risoluzione del problema considerato. In realtà, vanno generate 4 sequenze

di istruzioni distinte (una per ciascuna unità: i 2 GM e le 2 UC), anche se,

in pratica, visto che ad ogni istruzione della ALU corrisponde un'istruzione

complementare del GM, è possibile inviare la stessa istruzione alla ALU e al

GM dello stesso acceleratore. Inoltre se i due acceleratori vengono usati per

eseguire la stessa operazione su porzioni di dati diverse (funzionamento di tipo

SIMD), la stessa istruzione verrà inviata ad entrambi gli acceleratori e quindi

sarà su�ciente generare un'unica sequenza di istruzioni.

Chi si occupa di generare queste sequenze di istruzioni è l'unità di controllo.

Anch'essa deve quindi essere programmata al �ne di realizzare la sequenza di

istruzioni desiderata.

Il programma dell'unità di controllo consiste in una serie di istruzioni a 32 bit

che verranno esaminate ed eseguite, in modo seriale, una alla volta. Il set di

istruzioni, delineato in Tabella 2.1, prevede 7 tipologie di istruzioni:

� WAIT: questa istruzione serve per porre l'unità di controllo in uno stato

d'attesa, in cui non esegue alcuna operazione e da cui uscirà solo quando

le condizioni speci�cate dall'istruzione di WAIT non si saranno veri�cate

(ad esempio si potrebbe dire all'unità di controllo di attendere un segnale

di sincronizzazione dal sistema esterno);

� JUMP: lo scopo di questa istruzione è quello di modi�care il �usso di

esecuzione delle istruzioni dell'unità di controllo, consentendo di saltare

ad altre parti del programma. È possibile eseguire sia salti incondizionati


Istruzione Descrizione

WAIT Attende �nché non si veri�cano le condizioni richiesteJUMP Esegue un salto condizionato o incondizionatoIST Programma le istruzioni per le ALU e per i GM

COUNT Controlla o inizializza i contatoriTEST1 Controlla varie con�gurazioni degli status dell'Acceleratore 1TEST2 Controlla varie con�gurazioni degli status dell'Acceleratore 2GVB Esegue operazioni logiche sulle variabili booleane

Tabella 2.1: Istruzioni dell'unità di controllo

che salti condizionati, questi ultimi controllati dal valore di un �ag interno

all'unità di controllo;

� IST: questa è l'istruzione con cui l'unità di controllo dice alle UC e ai GM

quali istruzioni eseguire;

� COUNT, TEST 1, TEST 2, GVB sono tutte istruzioni che hanno come

obiettivo quello di in�uenzare il �ag usato per la valutazione dei salti

condizionati.

In Figura 2.7 si può vedere uno schema funzionale dell'Unità di Controllo.

La RAM Istruzioni serve a contenere il programma che l'unità di controllo

deve eseguire, e che viene memorizzato al suo interno tramite il Sub Bus.

Il blocco Decodi�catore si occupa di analizzare un'istruzione e generare i

segnali di controllo necessari per portarla a compimento.

Il blocco denominato Sequenziatore di Istruzioni genera l'indirizzo corrente

per la RAM Istruzioni, da cui verrà prelevata l'istruzione corrente da inviare al

Decodi�catore. Questo blocco riceve dall'esterno un segnale di start e un segnale

di reset, mentre dal Decodi�catore riceve un eventuale indirizzo di salto con il

relativo segnale di abilitazione e un segnale di wait che serve per sospendere

l'esecuzione.

Il blocco TEST decide, in base ai segnali di controllo forniti, quale delle 4

operazioni di test è stata eseguita e seleziona quindi il rispettivo segnale tramite

un multiplexer. Lo stato del �ag di test viene imposto a uno tra 4 possibili

valori (segnale in ingresso dritto o negato, AND o OR logico del valore corrente

con quello in ingresso) e viene usato per la decisione dei salti condizionati.

Il blocco di Gestore Contatori è costituito essenzialmente da 64 contatori

utilizzabili per implementare iterazioni, cioè per fare in modo che la medesima

istruzione sia inviata automaticamente più volte agli acceleratori.

I blocchi Test Acceleratore rendono possibile veri�care lo stato corrente del-

l'acceleratore corrispondente; si può veri�care ad esempio che l'acceleratore ab-

bia terminato di eseguire i calcoli e che le FIFO dei dati e delle istruzioni siano

2.7. L'INTEGRAZIONE DELL'ACCELERATORE 59

Figura 2.7: Schema dell'unità di controllo

vuote; oppure si può veri�care quale con�gurazione delle Cache Virtuali sia

attualmente in uso o valutare il risultato di un confronto.

In�ne il blocco Gestore Variabili Booleane consente il calcolo di espressioni

booleane binarie (AND, OR, XOR e loro negazioni) e la loro memorizzazione

all'interno di un vettore di 64 posizioni, a disposizione del blocco di TEST.

2.7 L'integrazione dell'acceleratore

DPFPA è stato implementato e collaudato utilizzando una scheda di prototi-

pazione realizzata da Altera, che oltre alla FPGA include tutta una serie di

periferiche tra cui anche un'interfaccia LAN. Al �ne di gestire tutte queste peri-

feriche, all'interno della FPGA è stato istanziato anche il microprocessore RISC

a 32 bit Nios, un softcore fornito da Altera. Si faccia riferimento all'Appendice A

per maggiori dettagli.

In Figura 2.8 è schematizzato il sistema realizzato. Esso si compone della

scheda Altera su cui è montata la FPGA (Stratix 1S40) in cui sono ospitati

l'acceleratore e il processore Nios che si connette all'acceleratore tramite un

apposito blocco di interfacciamento.


Figura 2.8: Schema generale dell'acceleratore

Il processore Nios usa, come periferica di input/output prede�nita, la porta

seriale che viene impostata come terminale del processore. Essa può essere

quindi usata per monitorare il sistema e leggere eventuali messaggi di errore o

conoscitivi inviati dal Nios; inoltre tramite essa è possibile controllare il Nios e

con�gurare l'interfaccia di rete, nonché e�ettuare il debug dei programmi scritti

per il Nios. La porta seriale non è però utile per il trasferimento dei dati diretti

agli acceleratori perché troppo lenta.

Capitolo 3

Strumenti sviluppati

Verranno ora illustrate brevemente le principali componenti dell'ambiente di

sviluppo software realizzato per sempli�care l'utilizzo di DPFPA. Prima di ad-

dentrarsi però vale la pena ricordare che la ALU, in un ciclo di clock, può

e�ettuare diverse operazioni contemporaneamente:

� una somma tra numeri;

� un prodotto tra numeri;

� 3 scritture nel banco di registri;

� lettura di un dato in ingresso;

� scrittura di un risultato.

Le microistruzioni della ALU speci�cano i parametri per tutte queste azioni.

3.1 Il linguaggio di programmazione

Il linguaggio che si utilizza per scrivere le sequenze di microcodice è di ti-

po assemblativo e tiene conto dei seguenti aspetti relativi alla gestione delle

istruzioni:

� una sequenza è composta da diverse microistruzioni;

� la programmazione di una sequenza avviene mediante parole a 38 bit;

� una microistruzione consente di speci�care più operazioni eseguibili in

parallelo;

61

62 CAPITOLO 3. STRUMENTI SVILUPPATI

� ogni microistruzione viene eseguita in un ciclo di clock, e quindi tut-

te le operazioni e�ettuate nella medesima microistruzione sono eseguite

simultaneamente.

Per indicare la �ne di una microistruzione e l'inizio della successiva all'interno

di una sequenza, occorre separarle con un asterisco. Ad esempio, le cinque istru-

zioni seguenti formano due microistruzioni, la prima costituita da due istruzioni

e la seconda da tre.

Op1

Op2

*

Op1

Op2

Op3

Un programma utilizza quasi sempre diverse sequenze di microcodice. Per de�-

nire l'inizio e la �ne di una sequenza all'interno di un programma del linguaggio

si usano le parentesi tonde aperta e chiusa. Inoltre subito dopo la parentesi

aperta occorre inserire il nome della sequenza racchiuso tra doppi apici, come

in:

(

"seq 1"

...

)

(

"seq 2"

...

)

All'inizio di un programma, costituito da un insieme di sequenze, si deve inserire

la parola chiave INIZIO, mentre dopo l'ultima istruzione del programma occorre

inserire la parola chiave FINE.

INIZIO

(

"Nome"

...

)

FINE

3.1. IL LINGUAGGIO DI PROGRAMMAZIONE 63

Registri Nome collettivo Descrizione

IA, IB, IC, ID Ix destinazione per il dato in ingressoSA, SB, SC, SD Sx destinazione per il risultato del

sommatoreMA, MB, MC, MD Mx destinazione per il risultato del

moltiplicatoreOR primo operando del sommatoreSR ultimo risultato del sommatoreMR ultimo risultato del moltiplicatore

Tabella 3.1: Registri

Parola chiave Scopo

MOV Scrittura nei registriSUM Calcolo di una sommaMUL Calcolo di una moltiplicazioneOUT Scrittura di un dato in uscitaCOMP Valutazione di un confronto

Tabella 3.2: Elenco delle istruzioni

Anche per quanto riguarda i parametri delle varie istruzioni, la corrispondenza

tra il linguaggio e l'hardware è pressoché completa. Questa caratteristica con-

sente di sfruttare a fondo tutte le caratteristiche della scheda senza però aver a

che fare direttamente con sequenze binarie.

La nomenclatura utilizzata per l'identi�cazione dei registri è riportata in Ta-

bella 3.1, mentre l'insieme di istruzioni che compongono il linguaggio è riportato

in Tabella 3.2.

Ogni istruzione è terminata da un punto e virgola (�;�) ed è caratterizzata

da un certo numero di parametri che possono essere i registri, costanti, l'ultimo

risultato di moltiplicatore o sommatore, oppure il dato in ingresso. Le com-

binazioni possibili sono riportate nelle Tabelle 3.3 e 3.4. Si noti che, qualora

non riportate, le costanti cx sono assunte pari a 1 mentre gli operandi op sono

assunti pari alla costante invariante dell'operazione relativa. L'operazione NOP

bloccante del moltiplicatore o sommatore si suppone selezionata quando non è

presente, in quel ciclo di clock, un'istruzione di somma o di moltiplicazione.

Per quanto riguarda le scritture sui registri, si fa uso di un'unica istruzione:

MOV. Il parametro di questa istruzione, che rappresenta il registro destinazione

per la scrittura, può quindi assumere dodici valori corrispondenti alle combi-

nazioni di quattro registri per ognuno dei tre banchi possibili. Il parametro

che rappresenta l'operando sorgente è implicito, avendo ogni banco dei registri

solamente un ingresso.


Sintassi Note

MOV mreg

SUM c1 op c2 op È obbligatoria la presenza di almeno unoperando

MUL c op op È obbligatoria la presenza di almeno due traoperandi e costante

OUT oreg

COMP op op

Tabella 3.3: Sintassi delle istruzioni

Tavola degli operandi

mreg = Ix , Sx , Mxoreg = SR, OR, MRop = mreg , oregc1 = -, PER2, -PER2 (cambio di segno e moltiplicazione per 2)c2 = -, DIV2, -DIV2 (cambio di segno e divisione per 2)c = DIV2, PER2, -DIV2, -PER2

Tabella 3.4: Operandi utilizzabili per le varie istruzioni

È prevista anche la possibilità di inserire commenti su singola riga. In manie-

ra analoga a quanto previsto nel linguaggio ISO C99, una coppia di barre (�//�)

e tutto ciò che la segue �no alla �ne della riga sono ignorati dal traduttore.

3.2 Un ambiente integrato

Tutti gli strumenti di sviluppo descritti possono essere utilizzati in maniera au-

tomatica e coordinata grazie ad un IDE (Integrated Development Environment),

le cui principali caratteristiche sono [Ber2005]:

� è dotato di un'interfaccia gra�ca �user-friendly� per sempli�care tutte le

operazioni di scrittura, traduzione e simulazione del codice;

� permette di attivare i diversi strumenti necessari utilizzando pulsanti e

selezionando opzioni all'interno di menù, senza dover ricordare la sintassi

di ognuno;

� è dotato di un editor interno per scrivere il codice sorgente con alcuni

strumenti per la facilitazione del debugging;

� è dotato di una �nestra per la visualizzazione di eventuali errori o avver-

timenti;

� comprende un simulatore (Figura 3.1) per la veri�ca del codice.

3.2. UN AMBIENTE INTEGRATO 65

Figura 3.1: Il simulatore

Sono inoltre gestiti in maniera trasparente tutti gli strumenti accessori, tra

cui alcuni generatori di sequenze, necessari per la generazione completa di un

programma per DPFPA.

Capitolo 4

Risultati ottenuti

La scrittura delle sequenze per il calcolo dell'energia nel reticolo dipolare è

un'operazione complessa, a�rontata in [Dan2003, Sca2002]. I risultati ottenuti

in questo senso sono stati di grande pregio, perché si è riusciti ad utilizzare

appieno le potenzialità dell'acceleratore, e i risultati ottenuti sfruttando l'acce-

leratore si sono dimostrati accurati quanto quelli ottenuti usando un semplice

PC.

Per quanto riguarda la valutazione delle prestazioni, usando un insieme

di contatori e conoscendo il clock della FPGA è stato possibile misurare con

estrema precisione il tempo necessario al calcolo dell'energia.

Lo stesso algoritmo è stato eseguito su un computer basato su un Intel

Pentium IV a 3GHz con 1GiB di RAM; qui i tempi sono stati rilevati usando

le funzioni di misura dei tempi di calcolo fornite dal linguaggio C.

I dati ottenuti sono riportati in Tabella 4.1, dove oltre ai tempi di calcolo

misurati sono stati riportati anche i relativi speedup dell'acceleratore rispetto

al PC. Gli stessi dati sono illustrati gra�camente in Figura 4.1.

I tempi di calcolo riportati si riferiscono alla singola esecuzione della funzione

di calcolo dell'energia; questa funzione, che è appunto la parte computazional-

mente più onerosa dell'algoritmo, nel corso dell'esecuzione dell'intero algoritmo

viene richiamata centinaia di migliaia di volte.

Quindi complessivamente è possibile a�ermare che l'acceleratore implemen-

tato ha uno speedup rispetto al Pentium IV in esame che oscilla attorno al valore

2.

Va comunque considerato che la FPGA utilizzata è stata sfruttata per circa

il 50% delle sue potenzialità, e che evidentemente inserendo altri 2 acceleratori

sarebbe possibile ottenere speedup sensibilmente più elevati. Ulteriori migliora-

menti sono possibili sintetizzando l'architettura per FPGA Stratix II, grazie al

67

68 CAPITOLO 4. RISULTATI OTTENUTI

Dipoli DPFPA 100MHz Pentium IV 3GHz Speedup

64 5.71·10−6 s 1.07·10−5 s 1.87216 2.08·10−5 s 3.63·10−5 s 1.75512 4.74·10−5 s 8.63·10−5 s 1.821 000 9.15·10−5 s 1.66·10−4 s 1.818 000 7.20·10−4 s 1.31·10−3 s 1.8213 824 1.25·10−3 s 2.47·10−3 s 1.9827 000 2.43·10−3 s 4.93·10−3 s 2.0339 304 3.54·10−3 s 6.99·10−3 s 1.9864 000 5.75·10−3 s 1.12·10−2 s 1.9485 184 7.65·10−3 s 1.55·10−2 s 2.03125 000 1.13·10−2 s 2.62·10−2 s 2.33

Tabella 4.1: Confronto tra DPFPA e calcolatori general-purpose

Figura 4.1: Tempi di esecuzione e speedup al variare del numero di dipoli

69

maggior numero di unità di calcolo integrabili e alle maggiori frequenze di clock

ammissibili.

70 CAPITOLO 4. RISULTATI OTTENUTI

Parte III

Innovazione calzaturiera

71

Capitolo 1

Introduzione

In questa parte della tesi discuterò di un argomento che ha costituito una parte

essenziale del percorso formativo del mio corso di dottorato: l'introduzione di un

insieme di standard volti a migliorare il trasferimento di informazioni all'interno

del mondo meccano-calzaturiero.

La produzione di una calzatura richiede varie fasi di lavorazione per passare

dal progetto al prodotto �nito, spesso eseguite da aziende diverse ciascuna spe-

cializzata in un tipo di lavorazione. Ogni fase del processo produttivo richiede

la disponibilità di parecchie informazioni, sia di prodotto (come colore e tipo di

materiale) sia di processo (come la qualità desiderata per alcune operazioni).

La produzione calzaturiera attuale prevede che a ciascun macchinario venga

fornito l'insieme di informazioni elementare che gli occorre per portare a termine

il proprio lavoro, e molto spesso questo passaggio di informazioni non avviene

per via informatica (tramite generazione automatica a partire dal progetto)

bensì manualmente tramite apprendimento a partire da un esempio. Anche se

accettabile per alcune lavorazioni, questo modo di procedere nel quale ciascuna

macchina vive nel suo microcosmo tende a impedire trasferimenti di informazioni

importanti, con l'e�etto �nale che alcune parti della lavorazione sono caratte-

rizzate da un avanzamento �alla cieca� che comporta alle volte problemi in sede

produttiva.

Il problema del frazionamento delle informazioni è ulteriormente aggravato

dal fatto che le aziende specializzate in speci�che fasi di lavorazione lavorano

per più clienti, i quali forniscono loro le informazioni minime necessarie spesso

usando protocolli e rappresentazioni diverse e tra loro incompatibili. Chi riceve

queste informazioni a questo punto può solo:

1. convertire manualmente e di volta in volta i dati ricevuti in uno usato

internamente, con tutti i problemi legati al tempo di conversione e a for-

73


mati non riconducibili l'uno all'altro con precisione (ad esempio perché

adottano curve parametriche di�erenti per la descrizione delle linee);

2. limitarsi ad accettare lavori solo da chi usa un formato supportato dai

propri macchinari, con conseguente limitazione del mercato utile e dei

pro�tti a meno di acquistare un macchinario per ciascun tipo e ciascun

produttore;

3. usare un formato noto a tutti, come il DXF di AutoCAD, adottando con-

venzioni per consentire la rappresentazione di quelle informazioni di pro-

cesso non previste dal formato scelto utilizzando spazi riservati ad altri

tipi di informazione (un esempio tipico consiste nella codi�ca del tipo di

lavorazione come colore o layer della linea rappresentata); quest'approccio

porta naturalmente i produttori ad adottare convenzioni diverse, tenden-

do a richiedere comunque una conversione verso un formato interno, e

alimenta comportamenti scorretti nei quali il DXF esportato non contiene

su�cienti informazioni.

Vale la pena sottolineare che alcuni produttori fanno della chiusura un punto di

forza per il proprio mercato (tentano di mantenere i clienti con strategie di lock-

in), per cui non sempre esistono soluzioni alternative all'acquisto di macchinari

di quello speci�co produttore per poter procedere alla lavorazione.

Per dare un forte contributo alla soluzione di questi problemi, il Laboratorio

di Microcalcolatori in collaborazione con Assomac1 ha lavorato allo studio e alla

realizzazione di un set di standard che consenta una più agevole comunicazione

tra le varie fasi della produzione delle calzature e, a livello di progettazione,

tra CAD di produttori diversi. Grazie al patrocinio di Assomac è stato possi-

bile instaurare una pro�cua collaborazione con una selezione delle aziende del

settore (principalmente Comelz, Atom e Torielli, ma anche Newlast, Molina e

Bianchi, Cerim, Sabal, Elitron e Moreschi), col compito di dare un contributo

di competenza, revisionare le proposte e/o validare operativamente lo standard

adottandolo su alcuni dei loro macchinari.

1Assomac è l'associazione che rappresenta i costruttori italiani di macchine per calzaturi�ci,pelletteria e conceria. Le aziende che aderiscono ad Assomac sono leader a livello mondialee coprono oltre il 50% del fabbisogno mondiale di macchine per calzature e per pelletteria, eoltre l'80% del fabbisogno di macchine per conceria.

Capitolo 2

La moderna produzione

calzaturiera

2.1 La calzatura

Per comprendere quanto verrà detto nei capitoli seguenti è importante avere una

conoscenza di base su quelle che sono le componenti principali delle calzature.

Tomaia: è la parte superiore della calzatura, attaccata al sottopiede e alla suola

per mezzo di cuciture o colla. Può essere realizzata in diversi materiali

(come pelle, tessuto, gomma o altro).

Sottopiede: è la base su cui si costruisce la calzatura, ed è uno dei componenti

più delicati da un punto di vista funzionale (Figura 2.1). Su di esso poggia

la pianta del piede, e una sua corretta conformazione è un requisito essen-

ziale perché la calzatura sia comoda e, nel caso delle scarpe con tacco alto,

il piede non tenda a scivolare verso la punta. Normalmente è realizzato in

cartone �brato.

Suola: è la parte che poggia sul terreno. È costituita da una sagoma di cuoio,

gomma, plastica o altri materiali meno comuni, ed è applicata alla tomaia

per mezzo di chiodi, colla e/o cuciture.

Tacco: è un rialzo applicato sull'estremità posteriore della suola, con l'e�etto

di sollevare il tallone anche di diversi centimetri. Oltre a sostenere il piede,

caratterizza l'aspetto della calzatura e costituisce un essenziale elemento

stilistico.

Forma: è una struttura portante che richiama la forma di un piede stilizzato,

necessaria per la realizzazione �sica della calzatura perché su di essa ven-

75

76 CAPITOLO 2. LA MODERNA PRODUZIONE CALZATURIERA

Figura 2.1: Alcuni sottopiedi

(a) Una scarpa assemblata... (b) ... e le sue componenti

Figura 2.2: Una scarpa e le sue componenti

gono montati i pezzi. Le forme di produzione sono ad oggi realizzate in

materiali plastici, per via del loro basso costo e della possibilità di riciclare

facilmente il materiale.

Le componenti elencate sono rappresentate gra�camente in Figura 2.2, assem-

blate a sinistra (senza la forma) e separate a destra.

2.2 Dall'idea al progetto

La scarpa nasce dalla matita (o dal pennello) dello stilista. Quello che si ha a

questo punto è un'idea della resa estetica e stilistica della scarpa, ma è larga-

mente insu�ciente per poter passare alla produzione. Per questo un'altra �gura,

il modellista, a partire dal bozzetto procede alla progettazione della calzatura.

I processi di progettazione e produzione nascono da una radice squisitamen-

2.3. DAL PROGETTO ALLA SCARPA 77

te artigianale, e le calzature realizzate solo pochi decenni or sono potrebbero

essere considerate opere di grande integrazione artistica e ingegneristica. Solo

di recente la necessità di ridurre i tempi e gli scarti di produzione, a�ancata a

quella di non fare a�damento sulle capacità di un singolo lavoratore, ha portato

le aziende a lavorare verso un approccio più semplice e, per quanto possibile,

automatizzato. Il processo di conversione è nato da poco, e anche a causa della

notevole inerzia di alcune parti del settore calzaturiero non è ancora giunto a

compimento; per questo non è infrequente scoprire che dietro la realizzazione di

una calzatura si sono mescolati processi completamente automatici all'arte di

un singolo mastro con esperienza trentennale.

Le tecnologie CAD (Computer Aided Design) e CAM (Computer Aided Man-

ufactoring), ovvero la progettazione e la produzione assistita da calcolatore, sono

parte essenziale di questo processo innovativo. Introdotte a partire dagli anni

'80, rappresentano un nuovo strumento progettuale che può rendere più competi-

tivi i calzaturi�ci che le utilizzano e la loro di�usione rappresenta il presupposto

indispensabile per l'evoluzione tecnologica dei processi produttivi calzaturieri

da cui dipende in ultima analisi il futuro di questo comparto produttivo.

Esistono due tipi di CAD calzaturieri:

� bidimensionali (2D), nei quali il processo di progettazione al calcolatore è

relativo soltanto alla tomaia già sviluppata manualmente sul piano (nor-

malmente dopo essere stata disegnata �sicamente su un foglio di carta che

riveste la forma);

� tridimensionali (3D), che permettono al modellista di interagire anche con

gli elementi tridimensionali quali forma, tomaia, tacco e suola.

I CAD 3D sono di concezione più recente e notevolmente più complessi delle

loro controparti 2D. Non tutti i produttori di tecnologia o�rono ai loro clienti

CAD 3D, e quelli che lo fanno normalmente o�rono anche soluzioni di minor

costo includenti la sola parte 2D.

2.3 Dal progetto alla scarpa

In considerazione della modesta automatizzazione del settore, non stupisce la

presenza contemporanea sul mercato di macchinari con gradi di automatizzazio-

ne molto diversi. Per sempli�care la trattazione, in questo elaborato le macchine

saranno raggruppate secondo 3 classi:

� macchine manuali, che di fatto sono una implementazione dedicata al

settore calzaturiero dei classici attrezzi del fabbro o del sarto;


� macchine assistite o semiautomatiche, che prevedono un'importante con-

tributo da parte dell'operaio ma automatizzano parte del processo;

� macchine automatiche, che richiedono al più un modesto intervento ma-

nuale.

Il processo di produzione della calzatura può essere diviso in sei macrofasi:

1. preparazione di forme e tomaie;

2. montaggio della tomaia sulla forma;

3. condizionamento igrotermico;

4. preparazione del fondo e della suola (cardatura e incollaggio);

5. applicazione della suola sulla tomaia;

6. scalzatura e operazioni di �nissaggio.

I dettagli all'interno di ciascuna macrofase variano tuttavia in maniera marcata

sia in funzione del tipo di scarpa sia in base alla qualità (e al prezzo) desiderati

per il prodotto �nito. Quello che segue è un elenco di massima delle più comuni

lavorazioni.

2.4 Preparazione di forme e tomaie

In questa fase vengono prodotti separatamente tutti gli elementi necessari alla

costruzione della calzatura.

2.4.1 La forma

L'operazione di assemblaggio della calzatura (in gergo montaggio) avviene su di

una forma che assolve al compito di porta pezzo (Figura 2.31). La forma, come

dice il nome, serve ad imprimere alla tomaia la sagoma tridimensionale voluta;

la tomaia infatti, ricavata da pellame piano, viene costretta a mezzo di pinze

e altri dispositivi di a�erraggio a deformarsi e chiudersi in modo permanente

attorno ad essa �no ad avvolgerla completamente.

La forma costituisce dunque un elemento base della calzatura: un errato pro-

getto di questa può dar luogo a calzature scomode o a problemi di fabbricazione

compromettendo la bontà del prodotto �nale.

Un tempo realizzata in legno in pochi esemplari, la forma viene oggi realiz-

zata in materiali sintetici stampati e poi torniti. Il prototipo di forma tuttavia

1Immagini prese dal sito del Formi�cio Meridionale dei F.lli Manfredini,http://www.formi�ciomeridionale.com/

2.4. PREPARAZIONE DI FORME E TOMAIE 79

(a) Da donna, liscia (b) Da donna, con cuneo

(c) Da uomo, con snodo (d) Da uomo, con tacco ferrato

Figura 2.3: Alcuni esempi di forme

viene ancor oggi realizzato in legno da mastri modellisti. Solo negli ultimi anni

si sono iniziate a realizzare forme campione con sistemi CAD/CAM a mezzo di

torni di opportuna concezione.

La forma contiene normalmente anche cunei o snodi che fanno le veci della

naturale �essibilità del piede e consentono la scalzatura della scarpa una volta

terminata la lavorazione.

Le forme, ultimata la calzatura, vengono riutilizzate; quando questo non è

più possibile o necessario vengono fuse, e il materiale è riciclato per la produzione

di nuove forme.

2.4.2 La tomaia

Il disegno del modello viene fatto dal modellista seguendo quanto prodotto dallo

stilista direttamente sulla super�cie della forma o su un suo sottile rivestimen-

to. A questa operazione, fatta a mano o a CAD 3D, segue lo spianamento, cioè

la trasformazione della tomaia tridimensionale in una sagoma bidimensionale.

L'operazione di spianamento è senz'altro una delle più critiche nella progettazio-

ne della calzatura, e se non eseguita correttamente ne compromette la qualità.

Queste operazioni sono fatte su una singola misura (la cosiddetta taglia base,


scelta attorno al valor medio per la clientela prevista), mentre l'ottenimento del-

le altre taglie è fatto in modo automatico (prima della spianatura se si utilizza

un CAD 3D, dopo se si importa lo spianamento manuale in un CAD 2D). Le al-

tre parti della scarpa (come il tacco e il sottopiede) sono normalmente prodotte

da ditte esterne specializzate, e non presentano altrettante criticità.

Si procede a questo punto a una prototipazione, spesso fatta utilizzando ma-

teriali non pregiati (come il cartone) per veri�care che e�ettivamente le tomaie

ottenute siano assemblabili attorno alla forma da cui si era partiti.

Quando il progetto è considerato completo, si passa alla produzione dei vari

componenti.

Il taglio della pelle, che avviene manualmente per piccole produzioni o auto-

maticamente per grandi produzioni, può essere eseguito in due modi principali:

� a fustella;

� senza fustella.

Il taglio a fustella richiede la produzione di dime di metallo con la forma dei pezzi

da produrre che vengono usate insieme ad una pressa. È un sistema di taglio

di�uso ed a�dabile, semplice da utilizzare, produce pezzi di eccellente qualità e

richiede un investimento contenuto; per contro, richiede molta manodopera, che

deve anche essere dotata di grande esperienza per evitare sprechi di materiale, e

richiede tempo per la produzione delle fustelle. Esistono sia fustellatrici manuali

(Figura 2.4) che a controllo numerico (Figura 2.5).

Il taglio senza fustella può essere e�ettuato a mano, usando un coltellino

e una sagoma di cartone (è un approccio ancor oggi usato nelle produzioni di

piccole dimensioni, ad esempio nel caso di scarpe commissionate in singolo paio),

o a macchina, usando plotter con particolari teste di taglio.

Per il taglio automatico senza fustella (Figura 2.6), il controllo del macchi-

nario avviene tramite un computer con appositi programmi che permettono di

disporre (virtualmente) sulla pelle i pezzi da tagliare, visualizzando il lavoro

con un proiettore posto sopra il tavolo di taglio. La tecnologia di taglio può

essere di vari tipi, ma nel caso del taglio della tomaia quello a lama oscillante è

certamente il più di�uso. Il taglio senza fustella, a fronte dell'elevato costo del

macchinario, ha il vantaggio di essere molto �essibile e di eliminare i tempi di

produzione delle fustelle: questo permette di preparare rapidamente i prototipi e

di cambiare in ogni momento il modello prodotto; inoltre, grazie ai software più

recenti, non richiede personale esperto per l'ottenimento di un buon risultato.

Finito il taglio, nel caso la pelle non fosse di spessore uniforme, è necessario

eseguire l'operazione di spaccatura, processo di assottigliamento della pelle; alcu-

ni componenti della tomaia inoltre richiedono che venga eseguita la scarnitura,


Figura 2.4: Una fustellatrice manuale

Figura 2.5: Una fustellatrice automatica


Figura 2.6: Un plotter di taglio a lama oscillante

Figura 2.7: Alcune lavorazioni ornamentali

processo di assottigliamento di parte dei bordi atto a facilitare le ripiegature e

le cuciture.

A volte vengono eseguite anche altre lavorazioni, per lo più a �ne ornamen-

tale, come la bucatura e la dentellatura (Figura 2.7).

Terminata la realizzazione dei pezzi, la tomaia viene assemblata per mezzo di

cuciture: questa operazione (indicata anche con i termini orlatura e giunteria)

può essere fatta in molti modi diversi per la varietà di �lati utilizzati, per i

materiali di cui può essere fatta la tomaia nonché per i diversi e�etti estetici che

si vogliono ottenere. È spesso fatta manualmente (quasi sempre con macchine

da cucire, in rari casi a mano), ma esistono macchine da cucire a controllo

numerico adatte a produzioni in grandi volumi2.

2Queste macchine non sono molto di�use anche perché la produzione in grandi volumi èspesso �esportata� in paesi con basso costo della manodopera, nei quali non è un problema


Figura 2.8: Una garbasperoni a caldo

A lavorazione terminata, vengono eseguite la garbatura dello sperone (in cui

viene accoppiata la tomaia con un rinforzo per il tallone) e la sagomatura a

caldo della tomaia (Figura 2.8).

2.4.3 Il sottopiede

Il primo passaggio per l'assemblaggio è quello dell'applicazione del sottopiede

alla forma (che avviene mediante con nastro di carta oppure chiodini3) e la

eventuale ri�latura dello stesso, a�nché segua il pro�lo della forma nel caso non

fosse preciso.

avere interi capannoni pieni di personale addetto alla cucitura.3L'uso dei chiodi è curiosamente di�uso nonostante le gravi conseguenze in caso questi

venissero dimenticati nella calzatura (si è veri�cato). Parte di questo atteggiamento sembraessere dovuto al fatto che molti calzaturi�ci non sono a conoscenza delle macchine per il�ssaggio a nastro del sottopiede.


Figura 2.9: Una ribattitrice a controllo numerico

2.5 Montaggio della tomaia sulla forma

Il montaggio della scarpa (punta, �anchi e boetta4) avviene mediante l'impiego

di due macchine (generalmente assistite) in grado di applicare la tomaia con

adesivo o chiodi. Tipicamente la punta è montata con adesivo mentre i �anchi

e la boetta, secondo il tipo di calzatura, possono essere montati con adesivo e/o

chiodi.

Segue l'operazione di ribattitura (Figura 2.9) che conferisce al fondo del-

la scarpa la perfetta aderenza alla forma, in vista dell'applicazione della suo-

la; questa lavorazione può avvenire con macchine manuali, semiautomatiche o

automatiche.

2.6 Condizionamento igrotermico

A�nché la scarpa non si deformi è necessario lasciarla montata sulla forma per

un certo tempo cosicché i materiali ne assumano la curvatura.

Per diminuire il tempo di attraversamento della calzatura lungo la linea

di produzione sono stati introdotti sistemi per il condizionamento forzato delle

scarpe che, sottoponendole a stress igrotermici, riducono i tempi di assestamento

(Figura 2.10).

4La boetta è la parte posteriore della calzatura, nella zona del tallone.

2.7. PREPARAZIONE DEL FONDO E DELLA SUOLA 85

Figura 2.10: Caricamento delle scarpe in un'unità per il condizionamentoigrotermico

2.7 Preparazione del fondo e della suola

Seguono al condizionamento igrotermico le operazioni di cardatura (una raschia-

tura del fondo con lo scopo di rendere la super�cie più adatta all'incollaggio,

Figure 2.11 e 2.12) e incollaggio del fondo che preparano la scarpa per l'ac-

coppiamento con la suola; queste azioni vengono e�ettuate alternativamente

da macchine manuali, semiautomatiche o automatiche; in taluni casi una sola

macchina provvede sia alla cardatura che all'incollaggio.

Prima di procedere con l'applicazione della suola può rendersi necessaria l'e-

vaporazione del solvente che può avvenire in aria libera durante il transito dalla

stazione di incollaggio a quella dell'applicazione della suola oppure all'interno

di appositi tunnel con aspirazione dei vapori. Per evitare i problemi connessi

all'uso di solventi tossici, spesso vengono usate colle termiche o a base di acqua.

2.8 Applicazione della suola sulla tomaia

In questa fase (Figura 2.13) vengono unite la suola e la scarpa (che è ancora

sulla forma). È importante che questa operazione venga eseguita con grande

precisione, perché gli adesivi usati sono molto forti e il riposizionamento non è

semplice.


Figura 2.11: Una cardatrice a controllo numerico

Figura 2.12: Tomaia e sottopiede prima della cardatura (in alto) e dopo lacardatura (in basso)

2.9. SCALZATURA E OPERAZIONI DI FINISSAGGIO 87

Figura 2.13: Applicazione della suola alla tomaia

2.9 Scalzatura e operazioni di �nissaggio

Una volta �ssata la suola la calzatura è completa. Si procede allora alla scalza-

tura, in cui la scarpa viene tolta dalla forma.

Per ultimo viene applicato il tacco per mezzo dell'inchiodatacchi e vengono

eseguite le operazioni di �nissaggio, come l'inserimento della soletta e la luci-

datura. Se a questo punto la scarpa supera i controlli di qualità si procede al

confezionamento e alla distribuzione.

Capitolo 3

Lo standard JANE per la

comunicazione CAD-CAM

3.1 Obiettivi

L'obiettivo dello standard CAD-CAM [Dan2008b], noto nel seguito come JANE,

è quello di rompere il vincolo esistente che costringe gli utenti a restare legati a

uno speci�co fornitore di tecnologia, ed eliminare per i produttori la necessità

di spendere risorse per implementare �ltri di importazione/esportazione (mai

perfetti, con conseguenti perdite ulteriori di tempo e denaro) in modo da rendersi

per quanto possibile compatibili con gli altri.

Un obiettivo secondario è quella di porre le basi per un nuovo passo evolutivo

nel settore. Ad oggi molte macchine semiautomatiche non hanno fatto il balzo

dell'automazione completa perché non esistono CAD 3D capaci di esportare le

informazioni che occorrono loro, né macchine in grado di salvarle e recuperar-

le usando rappresentazioni �neutre� (cioè non legate alla macchina speci�ca).

Fornire un modo per la gestione di queste informazioni è un elemento essenziale

perché quest'area del processo diventi tecnologicamente migliore.

3.2 Considerazioni sull'accettazione

3.2.1 Aspetti commerciali

L'adozione di uno standard di questa portata ha senza dubbio grandi vantaggi,

ma anche alcuni svantaggi che possono pesare grandemente sulla possibilità che

quelle aziende che hanno fatto della chiusura una strategia di mercato decidano

di adottarlo. Per costoro, l'adozione di uno standard implicherebbe la perdita

89

90 CAPITOLO 3. LO STANDARD JANE CAD-CAM

del vantaggio competitivo dovuto al lock-in dei clienti attuali e di quelli futuri,

che una volta scelto un loro macchinario si troverebbero vincolati ad acquistarne

un'intera gamma per garantirsi l'interoperabilità.

D'altro canto far fronte alla concorrenza adottando strategie di chiusura,

al di là delle questioni etiche, non sempre è una scelta vincente. Sono molti i

casi storici nei quali la chiusura da parte di aziende (non già praticamente mo-

nopoliste) le ha condotte alla rovina, mentre l'apertura di altre ha generato un

mercato di dimensioni tali da consentire loro di espandersi assieme a molte altre.

Per questo l'introduzione di uno standard di comunicazione potrebbe indurre

una nuova apertura del mercato, con vantaggi sia sociali sia legati alla migliore

circolazione delle idee. Nel lungo periodo, l'attribuzione di una connotazione di

�alta qualità� a quei prodotti che aderiscono allo standard potrebbe anche es-

sere la leva necessaria a contenere l'espansione nei mercati occidentali di quelle

macchine prodotte in paesi in via di sviluppo caratterizzati da bassi costi ma

potenzialmente anche da bassa qualità.

3.2.2 Aspetti legati al processo di de�nizione

Uno dei problemi legati alla de�nizione di uno standard è legato al fatto che

sul mercato esistono numerose solide aziende con una buona base di clienti e

di installazioni. Queste aziende non hanno la minima intenzione di cambiare

radicalmente il loro modo di lavorare, né sono disposte ad accettare uno standard

nato come la rati�ca del modo di lavorare di un concorrente.

Per questi motivi lo standard è nato dal niente a partire da numerosi colloqui

con un esteso gruppo di aziende del settore, le quali hanno mostrato i loro

problemi e il loro modo di lavorare, e hanno consentito al gruppo di lavoro di

comprendere quali e quante siano le di�erenze che li caratterizzano e quindi i

limiti della standardizzazione.

La generazione del documento di descrizione dello standard è stata quindi

per sua natura iterativa, con frequenti proposte e loro analisi critiche, e laddove

esistevano molti modi di fare la stessa cosa si è scelto di adottare almeno il

minimo comune denominatore supportato da tutti e/o un modo semplice e non

supportato da nessuno, così da porre tutti sullo stesso piano senza cercare di

forzare un'azienda nel modo di lavorare di un'altra.

Questo modo di procedere tuttavia potrebbe non risultare così chiaro ai

rappresentanti di aziende non direttamente coinvolte nella sua de�nizione, e

contestazioni del tipo �questo standard risolve i problemi delle aziende X e Y

ma non i miei� (pronunciate da persone che non hanno mai letto lo standard)

si sono sentite e senz'altro si sentiranno in futuro. Resta a carico del gruppo di

3.3. ALTRI STANDARD E RICERCHE NEL SETTORE 91

lavoro l'opera di conversione di costoro, a�nché l'adozione dello standard non

risulti frenata da ingiusti�cati pregiudizi.

3.2.3 Modi di accettazione

Adottare uno standard esteso come quello proposto non è semplice, né tanto-

meno lo è adattare macchine e CAD esistenti in modo da poterlo usare.

Esistono tuttavia modi per limitare l'adozione dello standard a quelle sole

parti essenziali per l'interoperabilità, tralasciando le aree dedicate a funzionalità

accessorie. Particolare cura è stata posta nello standard proprio in quest'ottica,

così che fosse possibile pensare a strategie di adozione sempli�cate per le fasi

iniziali della sperimentazione.

Il primo passo consiste nella scrittura di traduttori stand-alone che converta-

no da un formato generato dai CAD al formato JANE e da questo a un formato

accettato dalle macchine. Questa operazione in linea di principio potrebbe non

richiedere nemmeno l'assistenza da parte dei produttori di CAD o macchine, ma

ha il signi�cativo svantaggio di introdurre due ulteriori passi nel processo che

porta i dati dal CAD alla macchina. Una coppia di convertitori di questo tipo

è stato implementato da Andrea Gri�ni di Comelz, uno dei principali partner

aziendali del progetto, per la traduzione da un formato generato dal CAD a

JANE e da JANE a CMZ (formato proprietario accettato dalle loro macchine).

Il passo successivo consiste nell'integrazione di questi convertitori nei CAD e

nei CAM. Pur mantenendo le loro limitazioni (partendo da un formato limitato

non possono usare tutte le funzionalità dello standard), questo passo consenti-

rebbe di introdurre una prima soluzione volta all'interoperabilità utilizzabile in

modo trasparente, e quindi accettabile per i clienti.

La massima integrazione, e la possibilità di sfruttare tutte le potenzialità

o�erte dal nuovo formato, impone un'esportazione diretta dalle strutture dati

del CAD al formato JANE e la sua importazione priva di intermediari. Questa

soluzione, per quanto impegnativa, è la chiave per l'apprezzamento del nuovo

formato e per l'agognato abbandono dei vecchi modi di comunicare.

3.3 Altri standard e ricerche nel settore

L'argomento della standardizzazione delle comunicazioni nel settore meccano-

calzaturiero non è nuovo1. L'esito complessivo è stato che mentre alcune pro-

poste hanno avuto successo e sono state adottate, le proposte legate alla comu-

nicazione CAD-CAM e CAD-CAD, spesso nate senza una reale collaborazione

dalle aziende, non sono state ricevute con favore o perché insu�cienti o perché

1Spiccano i progetti SHOEML e EFNET 1, 2 e 3.


troppo complesse ed espressive per poter essere realmente utilizzate. Lo stan-

dard JANE per la comunicazione CAD-CAM è il primo di questo tipo ad aver

ricevuto commenti positivi dalle aziende e a contare almeno un'implementazione

parziale.

L'opera di standardizzazione qui a�rontata non è nemmeno l'unica attività

volta alla modernizzazione del settore: in tutto il comparto è in atto un proces-

so di innovazione tecnologica della produzione. I macchinari sono già da anni

allineati ai vertici della tecnologia elettronica e informatica esistente [Can2006],

ma il metodo di produrre la scarpa e di organizzare l'attività produttiva all'in-

terno dell'azienda segue ancora un approccio tradizionale che non lascia spazio

a miglioramenti.

Sono in corso progetti a livello europeo per preservare le attività produttive

legate alle calzature attraverso lo sviluppo di sistemi avanzati di produzione. Ad

esempio si stanno progettando sistemi di controllo distribuiti per l'ottimizzazio-

ne dei passaggi di materiali da una macchina all'altra [Car2004, Col2006]. Anche

la logistica e l'organizzazione interna dell'azienda sono attualmente oggetto di

studi.

Un altro studio2 particolarmente innovativo riguarda il tentativo di ottenere

calzature personalizzate (sulla forma, non sullo stile) a prezzi paragonabili a

quelli della produzione di massa.

In altri settori �vicini� per le tematiche da a�rontare la standardizzazio-

ne è già avvenuta. Il settore meccano-calzaturiero risulta tuttavia essere più

problematico degli altri sia per la quantità sia per la tipologia dei processi

coinvolti.

3.4 Lavorazioni descritte

L'attuale stesura dello standard prevede la descrizione di:

� forma (descrizione tridimensionale e aree di lavorazione);

� pelle (descrizione bidimensionale, caratteristiche, taglio, marcatura, scar-

nitura);

� assemblaggio delle parti (incluse le cuciture);

� materiali (le combinazioni di materiali utilizzate);

� altre informazioni di carattere generale sulla calzatura.

2EuroSHOE, http://www.euro-shoe.net/

3.5. INTRODUZIONE AL FORMATO 93

Oltre a quelle elencate, è inclusa una voce relativa agli ordini di produzione

(quantità da produrre per ogni pezzo/taglia). Tuttavia l'opinione del grup-

po di lavoro è che tali informazioni debbano essere escluse dallo standard e,

eventualmente, essere normate in un documento autonomo.

3.5 Introduzione al formato

3.5.1 Il linguaggio XML

L'XML (eXtensible Markup Language) è un linguaggio molto adatto alla de-

scrizione di documenti strutturati. In questo paragrafo se ne dà una breve

descrizione perché tutti i �le contenuti nell'archivio sono in formato XML (con

la possibile eccezione di alcuni �le non normati ma previsti).

Un �le XML è un documento contenente testo. L'elemento strutturale

essenziale di XML è il tag, un marcatore di sezione caratterizzato da:

� un nome;

� un insieme di attributi (coppie nome-valore);

� un contenuto, che può includere sia testo libero sia altri tag.

L'inizio e la �ne dei tag sono individuati rispettivamente da stringhe del tipo:

<nome attributo1="..." attributo2="..." ...>

e

</nome>.

L'elenco degli attributi è opzionale e ha lunghezza arbitraria. Qualora un tag

fosse completamente de�nito dalla sua presenza e dall'elenco dei suoi attributi

è possibile adottare la forma contratta:

<nome attributo1="..." attributo2="..." .../>

che de�nisce in modo compatto sia l'apertura sia la chiusura.

La scelta di XML come formato per la rappresentazione dei dati è stata

dettata da alcune considerazioni, tra cui:

� essendo testuale, è possibile (anche se non piacevole) leggerlo anche per

una persona;

� XML è adatto alla rappresentazione di dati ben strutturati, come dimostra

la sua adozione in progetti di grandi dimensioni (tra cui il formato Open-

Document per la rappresentazione di documenti e i �le di con�gurazione

del K Desktop Environment e di Mozilla);


� esistono numerose librerie per la lettura dell'XML, talmente tante da aver

dato luogo a diverse interfacce standard grazie alla quali è possibile rea-

lizzare programmi che usano �le XML senza legarli ad una particolare

implementazione.

3.5.2 L'archivio compresso

Considerata la lunghezza e l'eterogeneità insita nell'elenco delle lavorazioni pre-

viste, per ottenere un formato dati ordinato e utilizzabile si è ritenuto opportuno

rappresentare informazioni concettualmente disgiunte in �le distinti. Considera-

te però le complicazioni insite nel dover gestire più �le per il medesimo progetto,

si è convenuto di racchiudere tutti i �le in un singolo archivio. In questo modo

si mantengono sia la separazione e l'indipendenza tra informazioni disgiunte sia

la comodità indotta dall'avere un singolo �le da gestire.

Esistono molti tipi di archivio che consentono di racchiudere più �le in uno

solo, ma non sono tutti equivalenti:

� alcuni formati, come RAR o ACE, non contano implementazioni libere

e come tali non sono adatti nella de�nizione di uno standard basato su

tecnologie accessibili;

� altri non sono compressi, come TAR o CPIO. Per quanto liberi, abbiamo

ritenuto che la compressione fosse un parametro di scelta importante (più

di quanto si possa aspettarsi il trasferimento dei �le verso la macchina

è basato sui vecchi �oppy-disc da 1.44MiB), e l'aggiunta di un layer di

compressione (come GZIP o BZIP2) avrebbe reso l'archivio di�cile da

gestire;

� altri ancora sono gravosi sulla CPU (come 7-ZIP) o non contano imple-

mentazioni sotto Windowsr (come SquashFS).

La scelta di ricorrere al formato ZIP è parsa un ottimo compromesso: è un

formato ben noto, compresso, leggero sulla CPU (PKZIP, una popolare imple-

mentazione, girava senza problemi su un i80286) e facilmente utilizzabile grazie

alla disponibilità di numerose librerie che lo implementano sia in lettura sia in

scrittura. Si è poi ritenuto che fosse opportuno speci�care che i �le avessero

estensione .jane invece che .zip in modo da evitare confusione negli utenti

(poco interessati ai dettagli tecnologici) e per favorire la gestione automatica da

parte degli ambienti desktop.

L'archivio ha la struttura interna mostrata in Figura 3.1. I prossimi paragra�

entreranno nel merito delle varie componenti.


Figura 3.1: Struttura interna dell'archivio JANE

3.5.3 Directory

Il formato JANE prevede la presenza di 2 directory all'interno dell'archivio.

La directory META-INF ha il solo compito di contenere il �le manifest.xml.

Si tratta di una collocazione convenzionale molto comune, ed è sembrato oppor-

tuno mantenerla nel nuovo formato dati.

La directory EXTRA è stata concepita come supporto alla documentazione. Lo

standard prevede la possibilità di includere documentazione HTML per facilitare

l'interpretazione di alcune parti del �le o per consentire di speci�care documenti

da stampare o visualizzare a bordo macchina di buona qualità, e la directory

EXTRA è a disposizione per ospitare immagini, fogli di stile o quant'altro (ma

non contenuto informativo � i documenti HTML devono essere autonomi e

utilizzabili anche con un terminale non gra�co).

3.5.4 manifest.xml

Il �le manifest.xml è adibito alla memorizzazione di informazioni riguardanti

l'archivio stesso, quali il nome e la versione dello standard implementato. Il

formato del �le è il seguente:

<?xml version="1.0" encoding="ISO-8859-1"?>

<manifest>

<fileEntry mediaType="assomac/jane" versionString="0.7.0"/>

</manifest>

3.5.5 general.xml

Il �le general.xml contiene generalità sul progetto. Questo include una descri-

zione del modello di scarpa rappresentato, l'autore e altre informazioni testuali


che non sono soggette a particolari elaborazioni. Una scarpa è considerata uni-

vocamente speci�cata dal nome del modello e dalla variante (che non include la

variante di materiale ma solo varianti geometriche).

Il formato è il seguente:

<rootGeneral>

<description field="author" value="Nome dell'autore"/>

<description field="baseModel" value="Nome modello base"/>

<description field="variant" value="Nome variante"/>

{... altre descrizioni ...}

<info id="Informazioni aggiuntive">

<![CDATA[

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html>

<head>

<title>Informazioni extra sul progetto</title>

</head>

<body>

{... testo contenente le informazioni, formattato XHTML 1.0 Strict ...}

</body>

</html>

]]>

</info>

</rootGeneral>

3.5.6 2d.xml

Il �le 2d.xml contiene le informazioni relative alle lavorazioni alle quali deve

essere sottoposta la pelle (o in generale il materiale che compone la tomaia).

Questo include il taglio, la scarnitura e ripiegatura dei bordi, e tutte quelle

lavorazioni accessorie o quelle informazioni supplementari (come riferimenti da

proiettare sulla pelle a bene�cio dell'operaio addetto al taglio) che fanno comodo

in sede di produzione. Uno degli aspetti innovativi dello standard rispetto allo

stato dell'arte è che in questo �le è possibile speci�care più volte in modi diversi

le medesime geometrie, così da consentire sia la più comune rappresentazione

campionata (già supportata da tutte le macchine) sia rappresentazioni vettoriali

e, dove possibile, semantiche, che consentono ai CAM di adottare strategie per

l'ottimizzazione della produzione più e�caci e meno soggette ad errori rispetto a

quelle applicate oggi3. Inoltre si è lavorato molto a�nché diventasse meccanica

e facile la veri�ca di alcuni abusi che hanno luogo durante le esportazioni a DXF

(come la presenza di percorsi dichiarati chiusi ma la cui descrizione conduce a

un percorso aperto).

La struttura di alto livello del �le è la seguente:

3Ad oggi l'esportazione di DXF è particolarmente problematica, anche a causa del com-portamento in mala fede di alcune aziende, e non consente l'interpretazione univoca di alcuneinformazioni geometriche con conseguente necessità di interventi manuali a bordo macchina.


<root2d>

<componentDependent id="1" materialClassId="23" rightCount="1" leftCount="1"

side="left/right" direction="45" directionTolerance="10">

<description field="name" value="Tomaia I"/>

{... altre descrizioni ...}

<slicing depth="10" lift="0.3" angle="20" visibleSide="yes/no"

folding="none/simple/reinforced">

<slicedTract id="0"/>

{... altri tratti di perimetro da scarnire in questo modo ...}

</slicing>

{... altre scarniture di tipo diverso ...}

</componentDependent>

{... altre intestazioni di componente ...}

<geometryDependent id="3142" sizeUnit="eu" sizeValue="37" footLength="370"

toeWidth="10" foreFit="22" heelFit="20"/>

<component id="1">

<perimeter/closedPath/openPath/area id="1"

action="cut/etch/mark/show/quality" toolSide="0"

mechanicalQuality="high/low" aestheticQuality="high/low">

<point x="0" y="10"/>

<tract id="0" smoothness="high/low" fidelity="high/low" maxToolSize="2">

<sampled/vector/...>

{... direttive dipendenti dal tipo di descrizione ...}

</sampled/vector/...>

{... altre descrizioni, di altro tipo ...}

</tract>

<point x="10" y="10" flags="smooth/sharp"/>

<tract id="1" smoothness="high/low" fidelity="high/low">

<sampled/vector/...>

{... direttive dipendenti dal tipo di descrizione ...}

</sampled/vector/...>

{... altre descrizioni, di altro tipo ...}

</tract>

{... coppie punto-tratto completanti il percorso ...}

</perimeter/closedPath/openPath/area>

{... altri percorsi per questo componente ...}

</component>

<component id="2">

<sameAsGeometry id="1"/>

</component>

{... altri componenti per questa taglia ...}

</geometryDependent>

{... geometrie per taglie diverse ...}


{... informazioni aggiuntive ...}

</info>

</root2d>

3.5.7 assembly.xml

Il �le assembly.xml descrive come assemblare (cucire) i pezzi tagliati. La de-

scrizione è particolarmente adatta all'interpretazione da parte di macchine da

cucire a controllo numerico, ma può anche essere usata per fornire agli addetti

alla giunteria una rappresentazione gra�ca di quanto dovrebbero ottenere.

Secondo la proposta di standard corrente, il formato del �le è il seguente:

<rootAssembly>


<geometry id="3">

<stitching id="1">

<components>

<component id="0" flipX="yes/no" rotation="20" offsetX="10"

offsetY="-30"/>

{... altre componenti da cucire assieme ...}

</components>

<path id="1">

<strictSample>

<point x="2" y="3"/>

{... altri punti di cucitura ...}

</strictSample>

<openStitchPath/closedStitchPath width="0" length="3" swingPoints="0"

beginBackTackingCount="2" beginBackTackingLength="3"

endBackTackingCount="2" endBackTackingLength="3">

<point x="4" y="5" flags="smooth"/>

<tract id="2">

<sampled>


{... altri campioni della linea di base ...}

</sampled>

<vector>

<arc bulge="0"/>

<point x="5" y="0" flags="sharp"/>

<bezier></bezier>

{... altri curve analitiche ...}

</vector>

</tract>


</openStitchPath>

</path>

{... altre cuciture per queste componenti ...}

</stitching>

{... altre cuciture per questa taglia ...}

</geometry>

{... cuciture per altre taglie ...}

</rootAssembly>

3.5.8 3d.xml

Il �le 3d.xml contiene le informazioni relative al dominio tridimensionale, che

includono:

� geometrie della forma (che devono essere de�nibili in più livelli di dettaglio

diversi, ad uso di formi�ci e calzaturi�ci);

� de�nizione delle linee di lavorazione (che consentono il posizionamento

automatico degli utensili);

� speci�ca delle direttive per il �ssaggio del tacco (per l'utilizzo con inchio-

datacchi a controllo numerico, non così lontane dall'essere prodotte).

Il formato del �le è:

<root3d>


<geometry id="37a">

<description field="name" value="Forma bella"/>

<coordinatesTransformation reference="anchorage" alpha="0" beta="30"

gamma="-10" offsetX="" offsetY="" offsetZ=""/>

{... altre trasformazioni per altri punti di interesse ...}

<sample id="flat" error="0.007">

<ring id="1">

<surfacePoint id="1" x="0.1" y="0.2" z="1" surface="top/upper/bottom"/>

{... altri punti ...}

</ring>

{... altri anelli, con punti con id omologo ai precedenti ...}

</sample>

{... altri campionamenti ...}

<work id="1" action="card/nail/glue">

<workPath id="1" label="fore/back/left/right/bottom/side">

<allowedMaterialsCombinations>

<materialsCombination id="102"/>

{... altre combinazioni di materiali così lavorabili ...}

</allowedMaterialsCombinations>

<workPoint x="0" y="0.8" z="0.01" theta="0" phi="0" size="10"/>


</workPath>

{... altri percorsi di lavorazione ...}

</work>

{... altre lavorazioni ...}

<heel>

<coordinatesTransformation reference="heel" alpha="0" beta="30"

gamma="-10" offsetX="10" offsetY="-20" offsetZ="2"/>

<heelFastening>

<fastenMode name="glue" value="yes/no"/>

<fastenMode name="nail" value="yes/no"/>

</heelFastening>

<insoleNailArea>

<insoleArea id="0" nailsAllowed="yes/no">

<basePoint x="0" y="0"/>


</insoleArea>

{... altre aree ...}

</insoleNailArea>

<heelGeometry id="0">

<heelArea id="0" nailsAllowed="yes/no">

<basePoint x="0" y="0"/>


</heelArea>

{... altre aree ...}

<volume>

<cone height="0.03">

<vertex id="0" x="0" y="0" z="1"/>

{... vertici delle altre aree ...}

</cone>

{... altri coni ...}

</volume>

<nailProfile id="0">

<nail x="1" y="3" z="3" theta="0" phi="10" length="12"/>

{... altri chiodi per questo profilo ...}

</nailProfile>

{... altri profili di inchiodatura utilizzabili ...}

</heelGeometry>

</heel>


</geometry>



</info>

</root3d>

3.5.9 materials.xml

Il �le materials.xml speci�ca tutte le combinazioni di materiali che sono state

proposte per il modello/variante in oggetto. Essenzialmente questo �le crea

una corrispondenza tra i materiali (individuati con un identi�cativo de�nito

esternamente, ad esempio a livello di magazzino) con un identi�catore speci�cato

a livello di geometrie bidimensionali. Questo consente di imporre che alcune

parti della calzatura siano realizzate con lo stesso materiale pur lasciando ad

una sezione apposita la speci�cazione di quale questo debba essere.

È lasciata a questo �le l'onere di rappresentare la spaccatura, che è un tipo

di lavorazione dipendente dal materiale.

La struttura del �le è:

<rootMaterials>

<materialsCombination id="102">

<description field="name" value="Coccodrillo verde"/>

<materialDefinition materialClassId="23">

<description field="name" value="Coccodrillo - fianco"/>

<material id="10" thickness="1.5"/>

</materialDefinition>

{... altre definizioni di materiale ...}

</materialsCombination>

{... altre combinazioni di materiale ...}



</info>

</rootMaterials>

3.5.10 production.xml

Il �le production.xml contiene informazioni relative a quante scarpe o com-

ponenti singole debbano essere prodotte. Come già detto, è opinione di�usa

all'interno del gruppo di lavoro che questo �le debba cessare di far parte del-

lo standard ed eventualmente entrare a far parte della de�nizione di un nuovo

standard indipendente. In ogni caso, il �le proposto ha il seguente formato:

<rootProduction>

<order id="1" materialsCombinationId="102">

<quantity>

<geometry id="3710" leftCount="3" rightCount="3">

<additional componentId="2" side="right" count="1"/>

{... altre componenti extra ...}

<except componentId="2" side="right" count="1"/>

{... altre componenti escluse ...}

</geometry>

3.6. IL VISUALIZZATORE 101

{... quantità da produrre per altre taglie ...}

</quantity>

<info id="Note">

{... note ...}

</info>

</order>

{... altri ordini ...}



</info>

</rootProduction>

3.5.11 Note conclusive

A chiusura di quanto detto, occorre sottolineare che un archivio JANE valido

include al più i �le descritti in questa sezione, ma lo standard norma l'obbli-

gatorietà dei soli manifest.xml e general.xml. Gli altri �le sono opzionali,

anche in considerazione del fatto che non sempre tutte le informazioni saranno

accessibili �n dall'inizio (ad esempio, informazioni come le traiettorie dei becchi

per la colla delle premonte potrebbero nascere a bordo macchina per autoap-

prendimento ed essere memorizzate per gli usi successivi, così che il �le diventi

una sorta di �archivio dinamico� capace di tenere traccia delle informazioni che

vengono via via generate).

Questo conclude la panoramica relativa al formato JANE, per i cui dettagli

si rimanda al PDF u�ciale presente nel CD allegato.

3.6 Il visualizzatore

Il visualizzatore JANE è un ottimo strumento per la visualizzazione della par-

te 2D dello standard. Attraverso la sua implementazione è stato possibile sia

validare il contenuto dello standard (che più volte è stato cambiato per elimi-

nare scelte che causavano di�coltà ingiusti�cate nell'implementazione del soft-

ware) sia i �le di esempio che sono stati scritti a mano (nelle fasi iniziali) o dal

convertitore automatico di DXF del quale si è parlato nel Paragrafo 3.2.3.

Il visualizzatore è uno strumento tecnico per gli addetti ai lavori, non qual-

cosa che vuole sostituirsi ai CAD già usati o a�ancarsi a essi nelle lavorazioni

quotidiane. Il suo scopo è quello di aiutare nell'implementazione dello standard

sia evidenziando eventuali errori sia fornendo un'implementazione di riferimento

completa. Per questo vengono visualizzate informazioni tecniche normalmente

non direttamente a disposizione dei modellisti, e non ne vengono mostrate altre

che sono magari normalmente fornite dai CAD calzaturieri.

La descrizione dettagliata del visualizzatore, che ha seguito un iter proget-

tuale straordinariamente accurato ed è stato scritto con particolare cura, esula


decisamente dagli scopi di questa tesi e si rimanda a [Gar2007] chi volesse entra-

re in questi dettagli. Per quanto di interesse in questa trattazione vale la pena

citare quelle che sono le più importanti caratteristiche del visualizzatore:

� è multipiattaforma, con supporto nativo per tutti i principali sistemi

operativi (GNU/Linuxr, OpenBSDr, FreeBSDr, NetBSDr, Microsoftr

Windowsr da 98 a Vista�, Macr OS-X dalla versione 10.3 e altri ancora)

sia nelle versioni a 32 che in quelle a 64 bit;

� ha un'interfaccia gra�ca moderna e consente di abilitare funzionalità avan-

zate come l'antialiasing e l'accelerazione gra�ca basata su OpenGL;

� dispone di un sistema di plugin per la scelta della libreria per la lettura

dell'XML;

� è multilingua (sono disponibili le localizzazioni inglese e italiana, ma è

possibile realizzarne altre e aggiungerle al programma senza ricompilazio-

ne).

Anche per via dell'utilizzo della libreria Qt/Free, il programma è stato rilasciato

dall'autore sotto la licenza GNU/GPL versione 2. Secondo questa licenza è con-

sentito a chiunque distribuire copie del programma, eventualmente modi�cato,

a patto di di�ondere con esso anche il codice sorgente. In questo modo è garan-

tita la libera circolazione del software e delle sue modi�che, con la possibilità

per tutti di contribuire a quanto disponibile al �ne di ottenere un prodotto via

via migliore.

Uno screenshot del programma in azione è visibile in Figura 3.2.

3.7 Stato dell'implementazione

Lo standard JANE è giunto a un punto di sviluppo tale da giusti�carne l'im-

plementazione all'interno di CAD e macchine esistenti al �ne di validarne sul

campo l'e�cacia.

Comelz ha annunciato il supporto per la versione corrente (0.7.0) dello stan-

dard nella prossima release del suo CAD. La stessa Comelz ha sviluppato i primi

convertitori da e verso il formato JANE che hanno posto le basi per l'iniziale

validazione e adozione dello standard. L'implementazione del �ltro in lettura

nei banchi da taglio Comelz è stata completata a un livello su�ciente a garantire

l'interoperabilità.

Atom ha già sviluppato un �ltro per l'importazione dell'attuale versione dello

standard nelle sue macchine da taglio.

3.8. SVILUPPI FUTURI 103

Figura 3.2: Il visualizzatore in azione

3.8 Sviluppi futuri

Non tutte le parti dello standard sono state validate nella stessa misura. Limi-

tandosi a quelle sezioni per le quali esistono macchine potenzialmente in grado di

supportarlo, l'ambito tridimensionale legato alla forma non ha ancora ricevuto

l'attenzione che merita anche a causa dell'inerzia di alcune aziende.

Un tema che vorremmo a�rontare prima della release 1.0 dello standard

è quello della veri�ca degli sviluppi. In sintesi, la questione è che la scarpa

viene progettata su una taglia (la taglia base) e poi scalata (sviluppata) sulle

altre in modo automatico. Purtroppo la forma e la tomaia sono sviluppate da

persone diverse con algoritmi diversi, per cui capita che si veri�chino problemi

di montaggio o di altro tipo perché la tomaia è stata tagliata per una forma

diversa.

Uniformare gli algoritmi per lo sviluppo è fuori questione: tutti quelli che

sviluppano lo fanno in modi completamente diversi, chi produce CAD 2D ad-

dirittura lavora sul piano, e tutti sostengono a gran voce che il loro modo di

sviluppare è il migliore e che non sono disposti a cambiarlo.

L'unica via per una standardizzazione accettabile dalle aziende è quella di

de�nire un insieme di criteri per la veri�ca a posteriori della corrispondenza degli

sviluppi. Questo è un lavoro ancora in corso ma ritenuto di importanza essen-

ziale in quanto fornirebbe un valore aggiunto immediatamente percepibile dai

clienti, che quindi potrebbero far pressione sui fornitori perché questi forniscano

prodotti conformi.

Capitolo 4

Lo standard per la

comunicazione CAD-CAD

4.1 Contesto applicativo

Il tema dell'interoperabilità tra CAD calzaturieri è particolarmente spinoso e

pone nuove di�coltà tecniche. Se lo standard JANE deve la sua complessità

alla necessità di garantire un e�ciente passaggio di informazioni tra molti in-

terlocutori diversi ma con caratteristiche ben de�nite, uno standard CAD-CAD

mira a fornire un livello base di interoperabilità tra sistemi che fanno più o meno

le stesse cose ma in modo diverso.

È importante sottolineare che l'interoperabilità di cui si parla in questo con-

testo non è quella data da un formato universale che potrebbe sostituire quelli

nativi dei CAD: si tratta di una strada già percorsa senza alcun successo1.

Quella che si vuole ottenere è invece un'interoperabilità su�ciente a consentire

ai clienti di migrare da un CAD a un altro senza dover rifare completamente il

progetto delle calzature.

Ad oggi la migrazione avviene in maniera di�coltosa. Spesso i calzaturieri

si riducono a importare con uno scanner la sagoma dei pezzi tagliati nel nuovo

CAD, ricomponendoli a mano in un progetto completo e speci�cando nuova-

mente le regole per gli sviluppi (che consentono di generare l'intera numerata2

a partire dal progetto fatto su una sola taglia). Lo standard CAD-CAD vuole

evitare queste fatiche inutili, limitando l'intervento manuale ad aggiustamenti

di minore entità.

L'introduzione di uno standard di questo tipo è stata introdotta come un

1Si tratta del progetto EFNET 3, che ha prodotto un formato dati estremamente complessoche nessuna azienda della quale siamo a conoscenza ha mai implementato.

2La numerata è l'insieme delle taglie o�erte per un modello di calzatura.

105

106 CAPITOLO 4. LO STANDARD CAD-CAD

obiettivo all'interno del gruppo di lavoro dopo che da oltre un anno era in

lavorazione lo standard JANE, per cui non stupisce che il livello di sviluppo

raggiunto sia molto diverso. Tuttavia le parti essenziali dello standard sono già

de�nite e hanno ricevuto commenti positivi dagli altri membri del gruppo di

lavoro, per cui la de�nizione di uno standard utilizzabile richiede solo un po' di

tempo e di lavoro da parte di tutte le persone coinvolte.

4.2 Informazioni rappresentate

I CAD calzaturieri, come s'è detto, si dividono in CAD 2D e CAD 3D. Vista

l'evidente impossibilità insita nell'instaurare una comunicazione tra due mondi

così diversi, ma considerato che i CAD 3D hanno un soprainsieme delle funzio-

nalità dei CAD 2D, si è deciso di limitarsi a scambi di informazioni in ambito

bidimensionale.

L'entità di base per la de�nizione di una tomaia bidimensionale è la camicia,

che si può immaginare come lo spianamento della tomaia stessa.

Sulla camicia si individuano alcune linee, dette linee base, che sono utilizzate

per la de�nizione della forma dei pezzi. Vale la pena sottolineare che le linee

base non sono i bordi dei pezzi, ma sono piuttosto linee sulle quali i pezzi si

�appoggiano�. Quindi ad esempio una linea di base può essere utilizzata in tratti

diversi per la de�nizione del bordo di pezzi diversi, e modi�candola risultano

modi�cati tutti i pezzi che a lei fanno riferimento. Non solo, ma le �tacche�

tecniche che possono marcare i bordi dei pezzi non fanno parte della geometria

delle linee della camicia.

Le linee della camicia possono essere de�nite in più modi:

� direttamente, tramite un campionamento o altre tecniche;

� come o�set, traslazione o specchiatura di una linea già de�nita;

� come unione di linee già de�nite;

� sottoinsieme di una linea già de�nita;

� come insieme di linee già de�nite.

Una linea può essere anche marcata come congiungente di altre linee, ma questa

marcatura può solo a�ancarsi ad una de�nizione diretta.

I pezzi sono de�niti solo successivamente utilizzando linee già de�nite come

parti del perimetro e linee interne. Si noti che stante la possibilità di de�nire una

linea come un sottoinsieme di un'altra, i pezzi possono limitarsi a far riferimento

a linee intere.

4.2. INFORMAZIONI RAPPRESENTATE 107

Eventuali tacche di varia natura possono essere de�nite successivamente as-

sociandole ai punti (i punti relativi ad intersezioni sono marcati esplicitamente a

livello di camicia per rendere e�ciente la gestione di tacche da usare in giunteria

come riferimento per l'allineamento dei pezzi).

La struttura di massima del �le secondo la proposta 0.1 è la seguente:

<standard id="...">

<size id="3142" sizeUnit="eu" sizeValue="37" footLength="370"

toeWidth="10" foreFit="22" heelFit="20"/>

<lines>

<line id="..." hidden="true|false" auxiliary="true|false">

=======( ALTERNATIVE )=======

--------- BASE LINE ---------

<sample>

<point id="..." x="..." y="...">

<crossing lineId="..."/> {opzionale}

</point>

... {2+}

</sample>

<join lineId1="..." terminal1="begin|end" lineId2="..."

terminal2="begin|end"/> {opzionale}

<parametric id="...">

***

</parametric>

... {possono essere specificate più varianti parametriche (0+)}

DESCRIZIONE PARAMETRICA: PROPOSTA UNO


<parameter terminalReferenceId="|1|2" id="...">

<data name="..." value="..."/>

...

</parameter>

...

</parametric>

DESCRIZIONE PARAEMETRICA: PROPOSTA DUE


<parameter id="..." x="..." y="..." weight="..." angle="..."

terminalReferenceId="|1|2" />

...

</parametric>

---------- CIRCLE -----------

<circle x="..." y="..." radius="..."/>

{campionamento opzionale, solo per avere gli id di punto se occorrono}

---------- UNION ------------

<union>

<lineRef lineId="..."/>

...

</union>

---------- SUBSET -----------

<subset lineId="..." startPointId="..." endPointId="..."/>

-------- TRANSLATION --------

<translation lineId="..." deltaX="..." deltaY="..."/>

------ VARIABLE OFFSET ------

OFFSET VARIABILE: PROPOSTA UNO (LIBERO)

<offset lineId="...">

<target pointId="..." x="..." y="..."/>

</offset>

OFFSET VARIABILE: PROPOSTA DUE (ORTOGONALE)

<offset lineId="...">


<distance pointId="..." value="..."/>

...

</offset>

---------- MIRROR -----------

<mirror lineId="..." radius="..." angle="..."/>

--------- COLLECTION --------

<collection supportLineId="..." templateLineId="..."

minCount="..." maxCount="..."

minDistance="..." maxDistance="..."

modulo="..." offset="..."

angle="..." tangent="true|false" />

=============================

</line>

</lines>

</standard>

<piece id="...">

<perimeter>


<connection type="round|flat" radius="..."/> {opzionale}

... {coppia ripetuta 1+}

</perimeter>

<closedPath>




</closedPath>

...

<openPath>





</openPath>

...

<referenceNotches>

<referenceNotch pointId="..." height="..." angle="..."

baseRadius="..." topRadius="..."/>

...

</referenceNotches>

<symbolicNotches>

***

</symbolicNotches>

</piece>

Al solito, si rimanda all'accluso CD per il testo completo della proposta di

standard CAD-CAD.

4.3 Sviluppi futuri

Come nel caso dello standard JANE, il tema degli sviluppi resta da a�rontare.

Nonostante lo scetticismo dei partner aziendali, è mia opinione che sia possi-

bile raggiungere un accordo su un modo semplice ma utilizzabile per trasferire

direttive di base sugli sviluppi.

La validazione sul campo resta uno dei passi essenziali per veri�care il rag-

4.3. SVILUPPI FUTURI 109

giungimento degli obiettivi. Si tratta di un passo ancora prematuro, ma che

contiamo di fare entro l'anno 2009.

Capitolo 5

Attribuzione del marchio di

conformità

Sia per lo standard CAD-CAM sia per quello CAD-CAD si pone il problema di

decidere quali siano i criteri da adottare in merito all'attribuzione del marchio

di conformità.

Durante le numerose discussioni sul tema, sono emerse all'interno del gruppo

di lavoro due alternative principali sulla condotta che Assomac dovrebbe tenere

in merito:

1. attribuirsi il ruolo di certi�catore (eventualmente delegando un ente ester-

no), e concedere i diritti di sfruttamento del marchio di conformità ai soli

prodotti che superano un insieme di test;

2. comportarsi da garante e arbitro, concedendo �su richiesta� i diritti di

sfruttamento del marchio ma riservandosi, in caso di problemi di compati-

bilità, il diritto di veri�care eventuali di�ormità e di revocare al produtto-

re del sistema di�orme il diritto di sfruttamento del marchio qualora non

provvedesse tempestivamente alla risoluzione dei problemi a sue spese.

Entrambe le soluzioni hanno punti di forza e di debolezza, e ad oggi i produt-

tori non hanno ancora raggiunto un accordo (si tratta, evidentemente, anche e

soprattutto di una questione politico-strategica e di immagine). La seconda so-

luzione appare tuttavia quella più praticabile, soprattutto in forza delle seguenti

considerazioni:

� de�nire un insieme di test completo è un lavoro molto esteso;

� non sempre è semplice decidere se un test è superato � ad esempio, nel

caso di macchine per il taglio del pellame, può essere di�cile distinguere

111

112 CAPITOLO 5. ATTRIBUZIONE DEL MARCHIO DI CONFORMITÀ

le di�ormità dovute a una errata interpretazione dello standard da quelle

legate a problemi di scarsa qualità del taglio;

� non è chiaro come comportarsi di fronte ad aggiornamenti software;

� anche supposto di aver risolto i problemi elencati, Assomac metterebbe

la propria immagine a garanzia del lavoro di altri, e questa eventualità è

osteggiata (non senza ragione) da più persone.

Per contro, un marchio così de�nito sarebbe �debole�, proprio per l'assenza di

un ente che garantisca al compratore l'interoperabilità con gli altri sistemi.

Compito del gruppo di lavoro è stato far emergere la questione e aiutare a

chiarire gli aspetti che caratterizzano i vari modi di a�rontarla. Alla dirigenza

di Assomac è lasciato l'onere di prendere una decisione informata.

Parte IV

Altre attività

113

115

Durante il triennio di dottorato ho avuto modo di o�rire il mio contributo in

numerose attività, normalmente associate a interessanti lavori di Tesi di Laurea

triennale o specialistica.

Questa parte della Tesi è dedicata a una selezione di quei lavori che hanno

avuto una particolare rilevanza.

Capitolo 1

Telemetria termogra�ca di

pneumatici

Il monitoraggio costante della temperatura degli pneumatici di una vettura di

Formula 1 è una di quelle innovazioni che, sorprendentemente, non sono ancora

state raggiunte nonostante le grandi risorse e gli enormi interessi in gioco.

La misura accurata della temperatura degli pneumatici è estremamente im-

portante per poter regolare in maniera ottimale le vetture da corsa. Ad oggi

l'unica misura a disposizione è fatta staticamente ai box dopo il rientro della

vettura, e come tale non fornisce informazioni sullo stato della gomma durante

il giro.

Obiettivo di questo progetto, sviluppato nell'ambito della tesi di laurea di Mi-

chele Nobis [Dan2008a, Nob2007] in collaborazione con la divisione Motorsport

di Magneti Marelli, è quello di consentire l'installazione di 4 termocamere sulla

vettura di Formula 1 (Figura 1.1) e registrare l'evolvere termico della gomma,

inviando attraverso la stretta banda telemetrica informazioni sintetiche.

La piattaforma hardware utilizzata è la Freescale MPC8349E MDS, mostrata

(a) Posizionamento della termocame-ra per le ruote posteriori

(b) Posizionamento della termocame-ra per le ruote anteriori

Figura 1.1: Posizionamento delle termocamere

117

118 CAPITOLO 1. TELEMETRIA TERMOGRAFICA DI PNEUMATICI

in Figura 1.2.

Le principali caratteristiche della scheda sono le seguenti:

� processore PowerPC:

� Freescale e300@667MHz;

� FPU IEEE-754 a doppia precisione;

� 64 kiB di cache (32 kiB dati, 32 kiB istruzioni);

� tre bus indipendenti:

� bus per l'accesso alla SDRAM DDR a 64 bit@333MHz;

� bus per la connessione di periferiche a 32 bit@133MHz;

� interfaccia PCI duale (32 bit) o singola (64 bit) @33/66MHz;

� controller PCI;

� controller DMA a quattro canali;

� due controller Ethernet triple-speed (10/100/1000Mb/s);

� due porte seriali UART;

� interfaccia SPI;

� doppia interfaccia I2C (modalità master o slave);

� interfaccia USB2.0.

La telecamera termica usata (Figura 1.3) è la FLIR Micron A10, capace di

generare �lmati termici alla risoluzione di 160x128 pixel misurando temperature

�no a 200°C.

La telecamera è stata scelta sulla base di criteri di compattezza (considerata

l'applicazione obiettivo), prestazioni e facilità d'interfacciamento, in questo caso

particolarmente agevole grazie a un'interfaccia Ethernet.

Il principale problema da risolvere nella gestione della termocamera è stato

l'ottenimento dell'associazione luminosità-temperatura. Tale informazione non

è fornita da FLIR, perché la termocamera è concepita per visori a infrarossi e

altri sistemi di visione nei quali l'immagine termica è usata direttamente da una

persona e non è usata per misure oggettive.

Fortunatamente esiste la possibilità di con�gurare la termocamera in modo

da disabilitare tutte le funzionalità di adattamento alle condizioni ambientali,

ed è stato possibile quindi fare misure di temperatura oggettive e ricavare una

relazione sperimentale tra luminosità e temperatura (Figura 1.4). Si noti che

119

Figura 1.2: La scheda Freescale MPC8349E MDS

Figura 1.3: La termocamera FLIR Micron A10


Figura 1.4: La relazione temperatura-colore misurata

la legge è lineare nonostante la risposta dei sensori a infrarossi sia fortemente

nonlineare: questo è dovuto alla presenza (ineliminabile) di tabelle di lineariz-

zazione interne alla termocamera che nascondono all'utente i dettagli sulla �sica

del sensore.

Ottenuto un modello per il sensore termico, il passo successivo consiste nella

regolazione del frame-rate (funzionalità questa o�erta dalla termocamera) in

modo da non saturare la potenza di calcolo del processore impegnata nella

compressione video.

La regolazione è stata a�rontata descrivendo il sistema come una coda di

fotogrammi, alimentata dalla termocamera e svuotata dal processore. Impo-

stando come set-point un particolare livello di riempimento della coda, è stato

possibile garantire che il frame-rate in ingresso non eccedesse le capacità della

CPU anche a fronte di disturbi (come ad esempio altri processi indipendenti o

anomalie di schedulazione).

Tutto il software usato per la conduzione di questo lavoro è rilasciato sotto

licenze libere. Questo include:

� Linux kernel (fortemente modi�cato da Freescale);

� uclibc e glibc;

� Busybox;

� U-Boot;

121

Figura 1.5: Il diploma rilasciato dalla Altran Engineering Academy

� Jasper (libreria per la compressione JPEG-2000, usata nelle fasi iniziali

del lavoro);

� XviD (libreria per la compressione video MPEG-4).

Al termine del nostro lavoro la scheda era in grado di acquisire e memorizzare

su memoria di massa USB i �lmati termici, al massimo frame rate consentito

dalla potenza di calcolo del processore (attorno ai 20 fps). Ritenendo buoni

i risultati conseguiti, i tecnici della Marelli Motorsport hanno provveduto a

proseguire le attività integrandole con i sistemi telemetrici (che non erano a

nostra disposizione).

Questo progetto ha avuto la possibilità di partecipare al concorso Altran

Engineering Academy 20081, patrocinato da Renault con l'obiettivo di premiare

le idee innovative nel settore dell'automotive. Al concorso hanno partecipato

persone di varia nazionalità con applicazioni che spaziavano dalla meccanica

all'elettronica, e dopo aver vinto la selezione italiana questo lavoro è giunto sino

alla �nale mondiale a Enstone, UK (Figura 1.5), con grande soddisfazione per

Michele e per tutto il Laboratorio.

1http://www.altran-academy.com/

Capitolo 2

Controllo del modello di una

vettura di Formula 1 in

galleria del vento

Questo lavoro di tesi, sviluppato da Marco Piccio [Pic2007] in collaborazione con

la Direzione Tecnica-Aerodinamica di Ferrari, è consistito nello sviluppo di un

sistema di controllo per il posizionamento dei modelli (accurate riproduzioni in

scala 1:2) di vetture di Formula 1 in galleria del vento. In tali tunnel (Figura 2.1)

questi modelli sono immersi in un forte �usso d'aria regolare e uniforme che

consente di studiare il comportamento delle vetture in condizioni analoghe a

quelle incontrate in pista.

Il progetto nasce dalla decisione di Ferrari di sostituire il sistema di controllo

attualmente impiegato (PI Mistral, Figura 2.2) con un nuovo sistema sviluppato

internamente sotto il nome di Prometheus.

Le ragioni per questa decisione sono:

� PI Mistral a breve verrà reso obsoleto dall'introduzione di PI Diablo;

� a causa delle risorse che PI dedica allo sviluppo del nuovo sistema, è diven-

tata di�cile la collaborazione di cui Ferrari ha bisogno per la personaliz-

zazione di Mistral, e quando Diablo verrà u�cialmente commercializzato

si teme che il supporto per Mistral venga meno del tutto;

� in prospettiva, non è certo che PI sia disponibile a personalizzare Diablo

(sviluppato secondo un approccio modulare) come ha fatto per Mistral

(monolitico);

� Ferrari negli anni di utilizzo di Mistral ha acquisito grande esperienza in

123

124CAPITOLO 2. CONTROLLODI VETTURA IN GALLERIA DEL VENTO

Figura 2.1: La galleria del vento di Ferrari

Figura 2.2: PI Mistral

125

Figura 2.3: La scheda di prototipazione usata

quest'ambito e ha anche sviluppato software di alto livello per l'interfac-

ciamento con Mistral, per cui c'è la percezione che le nuove competenze a

disposizione siano su�cienti per tentare di rompere la dipendenza da PI.

In galleria del vento, il modello è sospeso tramite un supporto collegato nella

zona del roll-bar. Le ruote sono staccate e comandate (in rotazione e, per quelle

anteriori, in sterzata) usando supporti assiali esterni. Soggetto alla spinta del

vento, il modello �appeso� a un supporto passivo tende a spostarsi in modo

diverso da come fa la vettura in pista. Per questo invece di un supporto passivo si

utilizza un supporto attivo, con un controllo in anello chiuso capace di mantenere

il modello nella corretta posizione.

Questo lavoro di tesi è stato dedicato alla sintesi di questo sistema di con-

trollo.

La scheda usata per lo sviluppo è mostrata in Figura 2.3. L'elemento inte-

ressante è il microcontrollore scelto, il Freescale 56F8323, visibile al centro della

scheda in alto a sinistra.

Tale dispositivo è stato scelto da Ferrari in quanto più che adatto alle ne-

cessità di questo progetto sia in termini di potenza di calcolo sia in termini di

periferiche integrate, che includono un processore PowerPC a 60MHz contor-

nato da abbondanti memorie sia volatili che non, un generatore di clock, ADC

per la lettura dello stato analogico, PWM per la generazione del segnale di con-

trollo (di tipo ON-OFF per esplicita richiesta di Ferrari) e timer per la misura

accurata delle basi tempi.

Sono stati sviluppati sistemi di controllo per la limitazione della corrente

126CAPITOLO 2. CONTROLLODI VETTURA IN GALLERIA DEL VENTO

assorbita dal motore controllato e per i controlli in posizione (con l'obiettivo

di tenere fermo il motore) e velocità che hanno usato come sensore un enco-

der incrementale a 2 bit collegato direttamente all'asse del motore. In tutte le

prove l'errore si è mantenuto entro ±2∆, dove con ∆ ho indicato la risoluzione

dell'encoder.

I risultati sono stati ritenuti soddisfacenti sia dai tecnici Ferrari sia dai com-

ponenti del Laboratorio, e ha dimostrato ancora una volta che i lavori del nostro

Laboratorio sono apprezzati non solo a livello accademico ma anche da aziende

di grande prestigio.

Capitolo 3

Caratterizzazione e ricerca di

oggetti

Questo lavoro, di estrazione calzaturiera, è nato dalla collaborazione del Labo-

ratorio di Microcalcolatori con l'azienda Brustia Alfameccanica di Vigevano, ed

è stato condotto nell'ambito della tesi di laurea di Sara Rampazzi [Ram2007].

Le formelle sono oggetti derivati da mezze forme (area della punta o del

tacco, Figura 3.1), usate nelle macchine garbasperoni per sagomare i rinforzi

applicati alla punta o al tallone.

Per sagomare i rinforzi, le formelle vengono scaldate o ra�reddate (ce n'è

una per tipo sulle macchine) e la scarpa viene posizionata prima su quella calda

e poi su quella fredda.

Il problema che si pone con le formelle è che, per via dei requisiti termici,

sono prodotte in alluminio da uno stampo che deve essere fatto su misura ed è

molto costoso.

La considerazione che Brustia ha fatto è che, se la parte anteriore della calza-

tura varia molto con lo stile, quella posteriore è molto più �stabile�. Considerata

l'abbondanza di stampi già presenti in magazzino per via della lunga storia del-

l'azienda, un signi�cativo risparmio sia per l'azienda sia per i clienti potrebbe

essere dato dalla possibilità di riutilizzare i vecchi stampi.

Purtroppo proprio la grande dimensione del magazzino, privo di qualsivoglia

forma di catalogazione più evoluto di un numero seriale, crea la necessità di

sviluppare un sistema per il matching automatico, a partire dalla forma e dal

sottopiede del cliente, dello stampo più simile.

Questo lavoro è scomponibile in 3 parti:

� acquisizione delle formelle già disponibili, con estrazione di un vettore di

parametri caratteristici;

127

128 CAPITOLO 3. CARATTERIZZAZIONE E RICERCA DI OGGETTI

Figura 3.1: Una formella per la garbatura dello sperone

� acquisizione della forma del cliente con posizionato il sottopiede;

� de�nizione di un algoritmo per il matching, cioè di una funzione che misuri

la �somiglianza� tra la forma fornita dal cliente e ciascuna delle formelle

in archivio.

L'acquisizione �sica è stata a�rontata con un scanner tridimensionale entrato

in nostro possesso come parte della collaborazione con Assomac (Figura 3.2).

Il problema principale in questa fase è che lo scanner è stato concepito per

la scansione di forme e, essendo a contatto, i supporti rendono l'acquisizione

alle estremità imprecisa. Questo problema puramente meccanico è stato risolto

con la realizzazione di un supporto aggiuntivo che consente il �ssaggio della

formella in una posizione che consente l'acquisizione precisa delle sue parti più

importanti.

L'acquisizione della forma col sottopiede non è stata a�rontata perché Bru-

stia nonostante i solleciti non ci ha fornito sottopiedi ma solo forme. In ogni caso

il problema è limitato al �ssaggio del sottopiede in modo che sia solidale alla

forma, con un'eventuale riempitivo per l'eliminazione di eventuali irregolarità.

Il calcolo dei vettori di parametri è stato a�rontato per passi:

� prima la forma o formella digitalizzata viene �tagliata� virtualmente usan-

do un programma scritto in codice Java;

� poi un set di funzioni Matlab allinea la forma secondo l'asse di minima iner-

zia, in modo da eliminare per quanto possibile l'e�etto di posizionamenti

leggermente diversi delle forme o formelle nello scanner;

129

Figura 3.2: Lo scanner per forme Newlast NL-DGT/C

� il vettore dei parametri è stato calcolato dividendo il solido ottenuto con

un numero costante di piani ortogonali all'asse inerziale e calcolando i

momenti di inerzia delle �fette� rispetto a tale asse. Questa misura ha

il vantaggio di essere insensibile alla rotazione del pezzo e consente facil-

mente di confrontare un solido con un'altro �capovolto� (il calcolo dell'asse

inerziale al punto precedente ammette due soluzioni);

� la funzione di merito è calcolata come una norma della di�erenza tra

due vettori di parametri o come un prodotto scalare dei due vettori. I

parametri di tali operazioni verranno de�niti in sede di sperimentazione.

Allo stato attuale il lavoro è considerato su�cientemente avanzato da richiedere

una sperimentazione a partire da dati reali, essenzialmente per validare la scelta

del vettore di parametri. La richiesta di un numero di campioni su�ciente è stata

fatta a Brustia, che ha dato risposta positiva e sta provvedendo al reperimento

del materiale.

130 CAPITOLO 3. CARATTERIZZAZIONE E RICERCA DI OGGETTI

Parte V

Appendici

131

Appendice A

Tecnologia FPGA

A.1 Natura dei dispositivi

I Field Programmable Gate Array1 (FPGA) nascono nel 1984 come nuovo para-

digma per la realizzazione di logiche programmabili. In quegli anni le migliori lo-

giche programmabili a disposizione erano i CPLD (Complex Programmable Logic

Devices), il cui funzionamento era basato sulla personalizzazione di un prodotto

di somme. Le FPGA invece sono ricche di interconnessioni programmabili, che

danno loro una ben maggiore �essibilità a fronte di un'elevata complessità di

programmazione.

Un chip FPGA è formato2 da un elevato numero di elementi logici program-

mabili (PLB), ognuno comprendente una piccola lookup table (per la realizza-

zione di funzioni logiche arbitrarie) e un �ip �op di tipo D.

La comunicazione tra i PLB è a�rontata su due livelli. PLB adiacenti posso-

no comunicare tra loro usando linee dedicate, mentre la comunicazione tra PLB

non adiacenti è normalmente a�data a bus di comunicazione programmabili che

creano un �tto reticolo sull'intera super�cie del chip.

Nelle FPGA più recenti i PLB sono stati a�ancati da altri elementi logici

più specializzati, in modo da fornire un migliore supporto per le applicazioni più

comuni. Tra questi, spiccano sicuramente i blocchi di memoria (per rendere più

e�ciente l'allocazione di quantità signi�cative di RAM, che altrimenti avrebbero

1I gate array sono chip nei quali il silicio ha struttura (drogaggio) de�nito, ma ancora prividi interconnessioni. L'uso dei gate array consente di ottenere dispositivi logici con prestazioniprossime a quelle di un ASIC in una piccola frazione del tempo e del costo, ma comunquenell'ambito di un impianto produttivo di circuiti integrati. La scelta del nome per le FPGA èstata dettata da una logica puramente commerciale, perché l'idea di poter programmare deigate array sul campo era considerata rivoluzionaria, ma a livello tecnologico si tratta di duefamiglie di dispositivi completamente distinte.

2La descrizione è per forza di cose generica, e va presa come una panoramica introduttivaalla tipica struttura di una semplice FPGA.

133

134 APPENDICE A. TECNOLOGIA FPGA

richiesto un numero molto elevato di PLB) e i blocchi contenenti moltiplicatori

e/o sommatori (per consentire la realizzazione di DSP e�cienti).

La memoria usata per tenere traccia della con�gurazione ha subito cambia-

menti signi�cativi nel tempo. Inizialmente, gli elementi programmabili erano

costituiti da fusibili (anche in versioni normalmente aperte), e le transizioni di

questi elementi da uno stato all'altro erano permanenti. Non occorreva in questi

dispositivi una memoria aggiuntiva per la con�gurazione, ma non era neanche

possibile modi�care l'architettura una volta programmata.

Il passo successivo è stato rendere le connessioni programmabili associandole

a celle di RAM. Perché questa soluzione (molto comune anche oggi) funzioni

occorre però a�ancare alla FPGA un dispositivo contenente una memoria non

volatile che ne carichi la con�gurazione a ogni accensione, con un aumento dei

costi di produzione e dei tempi di accensione. Questa soluzione è però eccellente

in fase di sviluppo, perché consente di riutilizzare la FPGA con architetture

diverse e quindi abbattendo i costi di prototipazione.

Negli ultimi anni sono state introdotte sul mercato FPGA che integrano

memorie non volatili, che uniscono i vantaggi delle due soluzioni precedenti.

A.2 Le Altera Development Board

Le FPGA sono dispositivi complessi, ed è di�cile anche per tecnici esperti pro-

gettare e realizzare schede che consentano loro di funzionare3. Altera mette

a disposizione alcuni tipi di scheda contenenti la FPGA e tutto un insieme di

periferiche di uso generale per consentire agli sviluppatori di lavorare con un

sistema hardware sicuramente funzionante.

Il Laboratorio di Microcalcolatori ha a disposizione 2 tipi di scheda, che

sono state usate nell'ambito dei progetti a�rontati durante il Dottorato e che

verranno di seguito presentate.

A.2.1 L'Altera Nios Development Kit (Stratix 1S40)

Il Nios Development Kit basato su FPGA Stratix 1S40 (Figura A.1) è il prodotto

più piccolo a nostra disposizione. La scheda ospita:

� 2 porte seriali (J19, J27);

� un connettore RJ-45 per la connessione via rete (RJ1);

� due porte JTAG (J5 e J24);

3Ad esempio, i requisiti sulla monotonicità e sui tempi di salita della tensione di alimenta-zione sono talmente critici che gli stessi produttori di FPGA producono anche i regolatori ditensione adatti ad alimentarle.

A.2. LE ALTERA DEVELOPMENT BOARD 135

Figura A.1: La scheda Altera 1S40

� uno slot di espansione per CompactFlash (CON3), dove è inserita una

memoria �ash da 16MiB;

� un connettore per alimentare la scheda (J26).

La scheda è inoltre dotata di diversi pulsanti con cui l'utente può interagire per

fornire dei comandi al sistema, come:

� ricaricare la con�gurazione della FPGA salvata in memoria �ash (SW10);

� programmare la FPGA con la con�gurazione prede�nita (SW9).

Ci sono poi 5 pulsanti gestibili dall'utente: SW0, SW1, SW2, SW3 e SW8, que-

st'ultimo solitamente usato come reset hardware per il processore Nios; questi 5

pulsanti sono connessi direttamente alla FPGA, pertanto l'utente può utilizzarli

nel progetto come meglio crede.

Sulla scheda sono anche presenti diversi LED:

� 1 vicino al connettore di alimentazione (J26) che indica che la scheda è

alimentata;


� 2 vicini a ciascuna porta seriale (J19 e J27) che indicano la ricezione e

l'invio di dati;

� 4 vicini al pulsante per il ripristino della con�gurazione prede�nita della

FPGA (SW9), che indicano quale con�gurazione è attualmente in uso ed

eventuali errori di con�gurazione;

� 8 sono localizzati sopra i pulsanti SW0, SW1, SW2 e SW3 e sono gestibili

dall'utente, in quanto connessi direttamente alla FPGA;

� sono presenti anche 2 display a 7 segmenti ed è possibile connettere tra-

mite il connettore J12 un display alfanumerico da 2 linee per 16 caratteri;

entrambi i display sono connessi direttamente alla FPGA e quindi gestibili

dall'utente.

Sulla scheda sono in�ne presenti:

� una SRAM da 2MiB;

� una memoria �ash da 8MiB in cui vengono memorizzate le con�gurazioni

della FPGA (quella di default e quella utente);

� il chip per la gestione dell'interfaccia Ethernet (U4);

� la FPGA (U53);

� un oscillatore da 50MHz (Y2) per la generazione del clock.

In�ne è presente il chip FPGA (U53) vero e proprio, una Stratix EP1S40F780C5.

La famiglia Stratix è quella di maggior pregio prodotta da Altera (cui si con-

trappone la famiglia Cyclone, più economica), e nonostante siano nel tempo

nate più evoluzioni (ad oggi esiste la Stratix III), anche quello utilizzato resta

un dispositivo caratterizzato da buone prestazioni.

La struttura interna di una FPGA Stratix 1S40 è riportata in Figura A.2,

mentre le sue caratteristiche essenziali sono riportate in Tabella A.1 assieme a

quelle della FPGA più piccola e di quella più grande della stessa famiglia.

Queste FPGA sono dotate di tre tipologie di blocchi atti ad implementare

memorie sia single port che dual port:

� M512: blocchi di memoria da 576 bit complessivi che possono implemen-

tare memorie con parole da 1 a 18 bit e rispettivamente da 512 a 32 parole.

Sono i blocchi di memoria più veloci a disposizione;

� M4K: blocchi di memoria da 4 608 bit complessivi che possono implemen-

tare memorie con parole da 1 a 36 bit con un numero di parole rispettiva-

mente da 4 096 a 128;


Figura A.2: Struttura interna di una FPGA Stratix 1S40

� M-RAM: blocchi di memoria da 589 824 bit complessivi con parole che

possono variare da 8 a 144 bit con un numero di parole rispettivamente da

65 536 a 4 096. Si tratta di elementi di memoria relativamente lenti, ma

indispensabili quando occorrono signi�cative quantità di memoria.

Questi blocchi possono essere usati sia per implementare memorie RAM che

ROM, code FIFO o altre logiche contenenti dispositivi di memorizzazione.

Sono presenti anche blocchi DSP che possono essere utilizzati per implemen-

tare, ad esempio, moltiplicatori e�cienti.

Caratteristiche EP1S10 EP1S40 EP1S80

Logic Element 10 570 41 250 79 040M512 RAM (32x18 bit) 94 384 767M4K RAM (128x36 bit) 60 183 364M-RAM (4K 144 bit) 1 4 9Bit totali di RAM 920 448 3 423 744 7 427 520Blocchi DSP 6 14 22Moltiplicatori 9x9 48 112 176PLL 6 12 12Pin di I/O 426 822 1.24

Tabella A.1: Caratteristiche delle FPGA Stratix


In questa FPGA i logic element sono organizzati in gruppi di 10 che formano i

cosiddetti Logical Array Block (LAB). La struttura generale è di tipo matriciale,

con i vari blocchi (LAB, DSP e memorie) disposti su di una griglia e intervallati

dai bus.

Come si può vedere, i pin utilizzabili dall'utente (IOE) sono posti sul bordo

del dispositivo così come i PLL, anche se non visibili in �gura.

Le interconnessioni tra i diversi blocchi vengono realizzate tramite un sistema

a vari livelli:

� le connessioni locali, all'interno di un singolo LAB, sono realizzate tramite

un sistema di interconnessione molto veloce;

� blocchi adiacenti possono comunicare tra loro tramite appositi canali pri-

vilegiati;

� per distanze più lunghe è presente una rete di interconnessioni organizza-

ta a righe e colonne che serve per collegare qualunque blocco della FPGA

con qualunque altro; queste interconnessioni sono divise in tre categorie

in base alla massima distanza di interconnessione che possono implemen-

tare; ovviamente quella con distanza maggiore è anche quella che presenta

maggiori tempi di ritardo sul segnale;

� in�ne, sono presenti linee di interconnessione globali caratterizzate da un

ritardo costante su tutto il dispositivo e che servono per i segnali di clock

e di enable.

La struttura del singolo logic element è mostrata in Figura A.3.

Nello schema si possono distinguere:

� il blocco necessario per l'implementazione delle logiche combinatorie co-

stituito dalla lookup table in cui entrano i segnali di ingresso Data;

� un blocco speci�co per ottimizzare la propagazione dei riporti (Carry

Chain), che consente di propagare �no a tre riporti in parallelo, e quindi

di implementare sommatori e sottrattori a tre operandi;

� un �ip �op che serve come unità di memoria base con cui realizzare logiche

di tipo sequenziale;

� una logica per gestire il reset e la memorizzazione di dati sincroni con il

clock all'interno del �ip �op (Synchronous Load and Clear Logic);

� una logica per gestire il reset e il set asincrono, nonché de�nire lo stato

iniziale del �ip �op (Asynchronous Clear/Preset/Load Logic);


Figura A.3: Struttura dei Logic Element di una FPGA Stratix 1S40

� una logica per gestire i clock e i segnali di enable;

� diversi multiplexer;

� numerosi segnali globali comuni a tutti i LE del LAB e segnali per la

comunicazione con altri LE.

La con�gurazione dei singoli LE è a�rontata automaticamente via software,

senza possibilità di intervento da parte dell'utente4.

A.2.2 L'Altera Nios II Development Kit (Stratix II 2S60)

Il Nios II Development Kit basato su Stratix II 2S60 (Figura A.4) è l'evoluzione

del kit 1S40 appena illustrato. La scheda ha una dotazione del tutto simile alla

precedente:

� 16MiB di memoria Flash;

� 2MiB di memoria sincrona SRAM;

� 32MiB di memoria SDRAM di tipo DDR;

� oscillatore a 50MHz;

4Altera (come i suoi concorrenti, peraltro) non fornisce dati su�cienti perché sia possibileprogrammare una loro FPGA senza usare i loro strumenti di sviluppo.


Figura A.4: La scheda Altera 2S60

� interfaccia Ethernet;

� display a sette segmenti;

� otto led;

� quattro pulsanti;

� interfaccia JTAG.

Ciò che più distingue i due kit è proprio la FPGA di livello superiore. Nono-

stante condivida con la precedente versione la struttura di base (Figura A.5), i

suoi LAB sono più grandi rispetto a quelli delle Stratix (indicativamente di un

fattore 20), per cui il dispositivo è in grado di ospitare architetture notevolmente

più grandi. Inoltre, grazie ai passi in avanti nell'ambito della realizzazione di

circuiti integrati sempre più veloci, è in grado di sopportare frequenze di clock

3�5 volte superiori per il medesimo progetto.

La FPGA Stratix II 2S60 è di livello intermedio all'interno della sua cate-

goria. La Tabella A.2 mostra le sue caratteristiche essenziali a confronto con

quelli degli esponenti più piccoli e più grandi della sua famiglia.

A.3 I softcore Altera

È spesso indispensabile disporre di un microprocessore sulla FPGA. Un mi-

croprocessore è infatti lo strumento più adatto per a�rontare l'integrazione del

sistema e per gestire le periferiche e le comunicazioni col mondo esterno.

A.3. I SOFTCORE ALTERA 141

Figura A.5: Struttura interna di una FPGA Stratix II 2S60

Caratteristiche EP2S15 EP2S60 EP2S180

Logic Element equivalenti 15 600 60 440 179 400M512 RAM 104 329 930M4K RAM 78 255 768M-RAM 0 2 9Bit totali di RAM 419 328 2 544 192 9 383 040Blocchi DSP 12 36 96Moltiplicatori 48 144 384PLL 6 12 12Pin di I/O 366 718 1 170

Tabella A.2: Caratteristiche delle FPGA Stratix II


I produttori di FPGA hanno essenzialmente due strade possibili per fornire

questo strumento ai loro clienti:

� alcuni integrano un processore nella FPGA;

� altri forniscono il processore come elemento istanziabile sulla scheda come

un qualsiasi altro dispositivo logico (un softcore).

Ambedue le soluzioni vantano punti di forza e di debolezza. Implementare un

microprocessore �sico consente di ottenere prestazioni più elevate, perché il posi-

zionamento �sico delle componenti e l'instradamento dei segnali possono subire

ottimizzazioni �ni e prive dell'overhead dovuto alla programmabilità delle con-

nessioni5. D'altro canto, eventuali difetti del processore non sono più correggibili

una volta che il chip è stato realizzato, e in progetti nei quali il processore non

è necessario la sua presenza costituisce un innegabile spreco. I softcore godono

inoltre della possibilità di essere con�gurati in modo da includere solo le com-

ponenti di interesse, nel tentativo di ottenere il miglior rapporto tra prestazioni

e risorse impiegate.

Altera segue la seconda via e fornisce ai suoi clienti dei softcore di architet-

tura proprietaria, noti col nome di Nios e Nios II.

A.3.1 Il processore Nios

Il Nios è un processore di tipo RISC istanziabile nelle versioni a 16 e 32 bit, la

cui struttura è riportata in Figura A.6.

Nios è dotato di un'unica unità di calcolo in virgola �ssa operante con lo

stesso numero di bit del processore e di un banco di registri (�no a 256).

L'ISA del Nios è costituita da 70 istruzioni ed è adeguata per le esigenze per

le quali questo processore è stato ideato.

L'interfacciamento del Nios con altri elementi logici presenti sulla FPGA è

possibile a patto di con�gurare tali elementi in modo da poterli presentare al

processore come elementi di memoria (in altri termini, la logica supplementare

viene mappata nello spazio di memoria del Nios). È anche possibile realizzare

periferiche che accedono autonomamente al bus di sistema tramite la tecnica

del DMA, ed è implementato un controller per le interruzioni.

A.3.2 Il processore Nios II

Il softcore Nios II è la naturale evoluzione del più datato Nios, ed è disponibile

solo in versione a 32 bit. Le sue principali caratteristiche sono:

5Le connessioni programmabili hanno un costo in termini di prestazioni, e proprio perquesto i maggiori produttori di FPGA danno ai propri clienti la possibilità di realizzare versioni�specializzate� delle loro FPGA con le connessioni �ssate in base al loro progetto.

A.3. I SOFTCORE ALTERA 143

Figura A.6: La struttura interna del processore Nios

� ISA composta da 103 istruzioni, che include:

� moltiplicazione e divisione;

� operazioni �oating point in singola precisione;

� shift;

� 32 registri general purpose;

� 32 possibili sorgenti di interrupt.

Tra gli elementi che più caratterizzano il Nios II rispetto al Nios è la possibilità

di estendere il set di istruzioni con le cosiddette custom instruction. All'interno

dell'architettura di Nios II è infatti possibile inserire elementi logici personaliz-

zati in parallelo alla ALU, e l'ambiente di sviluppo mette a disposizione questi

elementi in forma di macro C. Indubbio vantaggio di questa possibilità è che

consente di accedere a periferiche personalizzate senza dover occupare il bus

di sistema (che, in sistemi complessi con molti accessi DMA, può comportare

un notevole vantaggio) e con un'interfaccia simile a quella di una chiamata a

funzione, che seppur in linea di principio meno potente, quando applicabile è

senz'altro più comoda e intuitiva.

Appendice B

L'ambiente di sviluppo

B.1 Sviluppo hardware

Vista la complessità della tecnologia delle FPGA, appare chiara l'importanza

di un buon ambiente di sviluppo che sia in grado di coordinare e agevolare le

numerose fasi di progettazione.

Lo sviluppo dell'hardware è un processo complesso, che normalmente è af-

frontato seguendo i seguenti passi:

1. analisi dei requisiti;

2. de�nizione dell'interfaccia del dispositivo;

3. de�nizione di massima della struttura interna del dispositivo;

4. per ciascuna unità funzionale:

(a) scomposizione eventuale in unità funzionali più semplici;

(b) stesura degli schemi dell'unità, spesso (ma non necessariamente) per

via gra�ca;

5. compilazione e simulazione (test di unità);

6. composizione delle unità più semplici a formare quelle più complesse;

7. compilazione e simulazione (test dell'architettura completa);

8. veri�ca del funzionamento sulla scheda.

Fatta eccezione per i primi 3 punti, il resto può e deve essere supportato e

agevolato il più possibile dall'ambiente di sviluppo.

145

146 APPENDICE B. L'AMBIENTE DI SVILUPPO

Altera mette a disposizione dei suoi clienti Quartus II, un ambiente di svi-

luppo completo giunto alla versione 8.01 e descritto brevemente nei prossimi

paragra�.

B.1.1 Quartus II

Quartus II è un software disponibile per Windowsr e per GNU/Linuxr2 in

versioni a 32 bit e a 64 bit. Quartus II copre tutte le fasi della progettazione

hardware, ed è strutturato con un nucleo per la progettazione hardware cor-

redato da una miriade di strumenti aggiuntivi che includono tra gli altri un

simulatore e uno strumento per il trasferimento dell'architettura progettata alla

scheda.

La progettazione avviene in maniera gra�ca, posizionando e collegando i

blocchi funzionali su uno spazio di lavoro simile a quello o�erto dai CAD bi-

dimensionali. È importante sottolineare che blocchi funzionali per la maggior

parte delle funzionalità di base (operazioni logiche o aritmetiche, memorie e

quant'altro) sono fornite in forma di libreria, e consentono di ridurre in modo

apprezzabile il tempo necessario alla de�nizione di architetture complesse. Altre

unità più complesse (i softcore, blocchi per l'interfacciamento col bus PCI, . . . )

sono disponibili come pacchetti supplementari (a pagamento). Le architetture

disegnate sono tradotte automaticamente in �le HDL3 per poter essere utilizzati

ai passi successivi.

Una volta progettata l'architettura (di un blocco interno o complessiva), è

necessario e�ettuare una traduzione che porti dall'HDL a uno schema dell'as-

segnazione delle risorse della FPGA. Lo strumento che si occupa di questo è

il compilatore, che come spesso accade è in realtà un oggetto che coordina più

strumenti ciascuno dedicato a una fase dell'elaborazione:

� la prima fase è quella di Analysis and Synthesis, che consiste nell'anali-

si delle strutture disegnate e nell'assegnazione delle risorse della FPGA

(senza considerarne il posizionamento �sico o le interconnessioni) agli ele-

menti del progetto. In questa fase vengono portati alla luce gli errori di

progettazione più frequenti, quali ad esempio la mancata connessione un

segnale;

1Le versioni di Quartus II seguono i cicli annuali. La versione 8.0 è la prima del 2008, e saràprobabilmente seguita nello stesso anno dalla versione 8.1, mentre la prima versione rilasciatanel 2009 sarà la 9.0.

2La versione GNU/Linuxr di Quartus II è semplicemente la versione per Windows ricompi-lata utilizzando Winelib, la libreria fornita dal team di Wine per la traduzione delle chiamatedi sistema da Win32/GDI a Posix/X11. Per maggiori informazioni, http://www.winehq.org

3Hardware Description Language. Quartus II supporta sia il proprietario AHDL sia i piùcomuni VHDL e Verilog.

B.1. SVILUPPO HARDWARE 147

� seguono all'analisi il processo di Place and Route, che assegna �sicamente

le risorse della FPGA (Logic Element e interconnessioni). Si tratta di un'o-

perazione delicata, perché un piazzamento mal fatto implica prestazioni

inferiori;

� ora che l'architettura è de�nita completamente l'Assembler genera un �le

per la programmazione della scheda, che racchiude in sé tutte le strutture

necessarie (anche quelle non architetturali, come il contenuto iniziale di

una memoria);

� a questo punto il Timing Analyzer , che include un modello dettagliato

della �sica della FPGA, valuta i tempi di propagazione e determina i

parametri temporali che caratterizzano l'architettura, tra cui la massima

frequenza di clock ammissibile e l'indicazione del segnale caratterizzato

dal più alto tempo di propagazione (utile qualora si volesse ulteriormente

ottimizzare l'architettura).

Ottenuta un'architettura soddisfacente si può procedere alla programmazione

della scheda. Quindi il �le generato dalla compilazione viene consegnato al

Programmer che si occupa di inviarlo alla memoria di con�gurazione della FPGA

che da quel momento si comporterà come deciso dal progettista.

B.1.2 SOPC Builder

SOPC Builder (System on Programmable Chip) è lo strumento a contorno di

Quartus II che si occupa della connessione di più blocchi complessi.

L'idea alla base del SOPC Builder è la seguente: visto che la connessione

di molti blocchi complessi è a sua volta complessa, è opportuno de�nire un'in-

terfaccia comune per l'interconnessione (nota come Avalon) e costruire automa-

ticamente la trama delle interconnessioni e la struttura di controllo di tutte le

componenti conformi che si vogliono interfacciare.

L'uso dell'interfaccia Avalon è il modo normale per collegare ad esempio un

softcore a uno o più acceleratori hardware, ai PLL, alle memorie, ai timer, all'in-

tefaccia JTAG e a tutte le altre periferiche di contorno. Salvo diversa imposta-

zione, il SOPC Builder si occupa di assegnare automaticamente gli intervalli per

la mappatura in memoria e gli IRQ in modo da evitare con�itti e consententire

al progettista di modi�care facilmente la dimensione dello spazio di indirizzi

usato da una periferica senza doversi preoccupare della nuova organizzazione

risultante. Tutte le assegnazioni di risorse sono poi messe a disposizione del

programmatore in forma di macro, così che a seguito di una nuova assegnazione

di risorse (che non è univoca) il codice scritto continui a funzionare.

148 APPENDICE B. L'AMBIENTE DI SVILUPPO

B.2 Sviluppo software

Una volta che un'architettura contenente un processore è stata trasferita sulla

scheda è necessario metterla in condizione di eseguire del software. Nel seguito si

fa riferimento alla suite per il processore Nios II, ma esiste una suite equivalente

per il precedente processore Nios.

B.2.1 Nios II EDS

Nios II EDS è un ambiente di programmazione basato sulla piattaforma Eclipse4

comprendente anche un port per Nios II della catena di compilazione di gcc5 e

in grado di integrarsi con le precedenti fasi di sviluppo hardware.

La scrittura del software parte dal caricamento di un �le generato dal SOPC

Builder che contiene i riferimenti alle risorse del sistema (come la mappatura di

memorie e IRQ). Questo �le viene interpretato e usato per generare un insieme

di header C contenenti macro che consentono l'accesso alle risorse hardware

tramite nomi simbolici invece che tramite esplicito riferimento alla mappatura

delle risorse utilizzate.

A questo punto è possibile scrivere il programma in codice C senza particolari

restrizioni, compilarlo e trasferirlo sulla scheda per procedere alla sua esecuzione.

Il modo più semplice per trasferire dati da e verso il Nios II è tramite lo

standard input e lo standard output, che come impostazione prede�nita sono

collegati all'interfaccia JTAG e che quindi consentono di avere l'equivalente di

un terminale a disposizione all'interno dell'ambiente di sviluppo. Naturalmente

è anche possibile associare tali �ussi a risorse hardware diverse, come la porta

seriale (che consente di interfacciarsi alla scheda senza aver bisogno dell'intera

suite di programmazione).

4http://www.eclipse.org5http://www.gnu.org

Appendice C

Pubblicazioni

In questa appendice riporto i riferimenti alle pubblicazioni delle quali sono

coautore.

� G. Danese, M. Giachero, F. Leporati, G. Matrone, N.D. Naz-

zicari, FPGA based coprocessor for �ngerprint matching, Proceedings of

DSD 2006, IEEE-Euromicro Conference on Digital System Design, Cavtat

(Croazia), Settembre 2006, pp. 51�52, ISBN 3-902457-11-2

� G. Danese, F. Leporati, M. Bera, M. Giachero, N.D. Nazzicari,

A. Spelgatti, An Application Speci�c Processor for Montecarlo Simula-

tions, Proceedings of the 15th IEEE-Euromicro Conference on Parallel and

Distributed Processing (PDP'07), Napoli, Febbraio 2007, pp. 262�269,

ISBN 0-7695-2784-1

� G. Danese, M. Giachero, F. Leporati, N.D. Nazzicari, A. Sar-

tori, E�cient Data Feeding for Smart Vision System, Proceedings of

DSD 2005, IEEE-Euromicro Conference on Digital System Design, Porto

(Portogallo), Settembre 2005, ISBN 3-902457-09-0


A. Spelgatti, An Accelerator for Physic Simulations, IEEE - Computing

in Science and Engineering (CiSE), sept/opt 2007


A. Spelgatti, High performance computing through SoC coprocessors, In-

ternational Journal on Computational Science and Engineering, accettato

per la stampa

� G. Danese, M. Giachero, F. Leporati, G. Matrone, N.D. Naz-

zicari, A Dedicated Hardware for Fingerprint Authentication, Lecture

149

150 APPENDICE C. PUBBLICAZIONI

Notes in Computer Science, 12 settembre 2007, pp. 117�124, ISBN 978-

3-540-74826-7

� G. Danese, M. Giachero, F. Leporati, G. Matrone, N. Nazzi-

cari, A dedicated hardware for �ngerprint authentication, Proceedings of

KES 2007, Knowledge based Intelligent Information and Engineering Sys-

tems, Vietri sul Mare, Settembre 2007, pp. 117�124, LNAI 4693 part II,

Springer-Verlag ed., ISBN 3-540-74826-1

� G. Danese, M. Giachero, F. Leporati, N. Nazzicari, M. Nobis,

An embedded acquisition system for remote monitoring of tire status in

F1 race cars through thermal images, Proceedings of DSD 2008, IEEE-

Euromicro Conference on Digital System Design, Parma, Settembre 2008,

pp. 432�437, Computer Society Press ed., Los Alamitos (CA-USA), ISBN

978-0-7695-3277-6

� G. Danese, S. Dulio, M. Giachero, F. Leporati, N. Nazzicari, G.

Cioccarelli, M. Nobis, A technological standard for shoe machineries

interfacing, Proceedings of MITIP 2008, 10th International Conference on

the Modern Information Technology in the Innovation Processes of the

Industrial Enterprises, Praga, Novembre 2008, in corso di stampa

Epilogo

151

Conclusioni

Nel periodo del mio Dottorato ho avuto la possibilità di a�rontare 2 temi

principali:

� lo sviluppo di architetture hardware dedicate per la soluzione di problemi

complessi;

� la collaborazione con numerose aziende per il miglioramento dei prodotti

e dei processi nel loro comparto industriale.

Ambedue i temi sono stati a�rontati a partire da necessità reali e portati a

conclusione.

L'ambito architetturale ha condotto alla realizzazione di due acceleratori

hardware implementati su FPGA, entrambi sensibilmente più veloci rispet-

to a calcolatori general-purpose. Merita però considerazione un altro aspetto

interessante: la scelta del termine di paragone.

Normalmente, quando si parla di elaborazione �ad alte prestazioni� si pensa a

supercalcolatori o acceleratori con prestazioni particolarmente elevate, e questo

è e�ettivamente un aspetto importante un cui esempio è trattato nella Parte II.

È tuttavia corretto parlare di �alte prestazioni� quando queste sono più ele-

vate di quelle delle alternative ammissibili per una data classe di applicazioni.

Quindi perché un sistema dedicato sia �ad alte prestazioni� è rilevante che sia

veloce rispetto alle alternative � ad esempio, un sistema dedicato fortemente

miniaturizzato è a buon conto �ad alte prestazioni� se è molto più veloce delle

soluzioni basate su microcontrollore. L'architettura presentata nella Parte I ben

si presta a tali considerazioni, perché oltre a essere applicabile a sistemi veloci

�in assoluto� riveste particolare rilevanza nell'ambito di soluzioni miniaturizzate.

Il tema dell'interoperabilità è stato trattato nella Parte III. In questo caso,

l'obiettivo del lavoro era mettere un insieme di produttori di tecnologia nelle con-

dizioni di trasferire per via informatica la maggior parte dei dati che coinvolgono

i loro CAD e i loro macchinari. Lungi dall'essere puramente implementativo,

questo lavoro è stato possibile solo dopo mesi di analisi dello stato dell'arte e di

studio delle soluzioni migliori non solo da un punto di vista tecnico, ma anche dal

153

punto di vista dell'accettabilità politico-strategica. Il valore di quanto ottenuto

è testimoniato dalla decisione dei partner industriali principali di implementare

le nostre soluzioni nei loro prodotti per la progettazione e nei loro sistemi CAM

� considerata la naturale inerzia del settore, di�cilmente si poteva sperare di

ottenere un risultato migliore. L'accoglienza da parte di soggetti esterni non è

ancora stata veri�cata, perché l'articolo di esordio diretto a riviste specializzate

nell'evoluzione dei sistemi informatici industriali è ancora (al momento in cui

scrivo queste righe) in fase di preparazione.

Una selezione degli altri lavori che hanno costellato gli anni del Dottorato

è stata presentata nella Parte IV, a testimonianza ulteriore dell'apprezzamento

che aziende anche prestigiose hanno dimostrato nei confronti delle attività del

Laboratorio.

Nel complesso i miei 3 anni di Dottorato sono stati segnati dalla parteci-

pazione a numerosi progetti che, senza eccezione, sono stati apprezzati dalla

comunità scienti�ca o dai partner industriali che con noi hanno collaborato.

Per questo considero il mio percorso soddisfacente, oltre che conforme a quelli

che sono gli obiettivi e lo spirito del Dottorato di Ricerca.

Bibliogra�a

[All1987] M.P. Allen, D. J. Tildesley, Computer Simulation of Liquids,

Oxford Science, 1987

[Baz2002] A.M. Bazen, S.H. Gerez, Systematic Methods for the Computa-

tion of the Directional Fields and Singular Points of Fingerprints,

IEEE Transactions on PAMI, vol. 24, n. 7, pp. 905�919, 2002

[Ber2005] M. Bera, Un elaboratore basato su di un acceleratore dei calco-

li in virgola-mobile, Tesi di Dottorato in Ingegneria Informatica,

Università degli Studi di Pavia, 2005

[Bin1988] K. Binder, D.W. Heermann, Monte Carlo Simulation in

Statistical Physics � An Introduction, Springer-Verlag, 1988

[Bro2007] M. Broglia, Progetto e Realizzazione di un Core Computazionale

FFT a una Dimensione per Elaborazione di Immagini Biometriche,

Tesi di Laurea in Ingegneria Informatica, Università degli Studi di

Pavia, 2007

[Can2006] V. Cantoni, A. Zucchella, F. Leporati, S. Denicolai, Inno-

vazione tecnologica e nei processi: analisi/diagnosi dello stato del

settore meccano-calzaturiero, Vigevano, settembre 2006

[Car2004] E. Carpanzano, A. Cataldo, A. Lacasella, Development of

manufactoring automation systems through object oriented concepts

and international standards, INDIN 2004

[Col2006] M. Colla, A. Brusaferri, E. Carpanzano, Applying the IEC-

61499 Model to the Shoe Manufactoring Sector , ETFA 2006, Praga

[Dan2001] G. Danese, I. De Lotto, A. De Marchi, F. Leporati,

T. Bellini, M. Buscaglia, F. Mantegazza, Monte Carlo-

Metropolis simulation of interacting anisotropic polarizable spins

on a lattice, Computer Phys. Communications, vol. 134/1, Febbraio

2001, pp. 47�57

155

156 BIBLIOGRAFIA

[Dan2003] G. Danese, I. De Lotto, F. Leporati, M. Scaricabarozzi,

A. Spelgatti, An Accelerator for Double Precision Floating Point

Operations, Proceedings of the 11th Euromicro Conference on Par-

allel and Distributed Processing (PDP), Genova, Febbraio 2003, pp.

57�63

[Dan2007a] G. Danese, F. Leporati, M. Bera, M. Giachero, N.D. Naz-

zicari, A. Spelgatti, An Accelerator for Physic Simulations,

IEEE Computing in Science and Engineering (CiSE), sept/opt 2007

[Dan2007b] G. Danese, M. Giachero, F. Leporati, G. Matrone, N.

Nazzicari, A dedicated hardware for �ngerprint authentication,

Proceedings of KES 2007, Knowledge based Intelligent Infor-

mation and Engineering Systems, Vietri sul Mare, Settembre

2007, pp. 117�124, LNAI 4693 part II, Springer-Verlag ed., ISBN

3-540-74826-1

[Dan2008a] G. Danese, M. Giachero, F. Leporati, N. Nazzicari, M.

Nobis, An embedded acquisition system for remote monitoring of

tire status in F1 race cars through thermal images, Proceedings of

DSD 2008, IEEE-Euromicro Conference on Digital System Design,

Parma, Settembre 2008, pp. 432�437, Computer Society Press ed.,

Los Alamitos (CA-USA), ISBN 978-0-7695-3277-6

[Dan2008b] G. Danese, S. Dulio, M. Giachero, F. Leporati, N. Nazzi-

cari, G. Cioccarelli, M. Nobis, A technological standard for

shoe machineries interfacing, Proceedings of MITIP 2008, 10th

International Conference on the Modern Information Technology

in the Innovation Processes of the Industrial Enterprises, Praga,

Novembre 2008, in corso di stampa

[Fre1996] D. Frenkel, B. Smit, Understanding Molecular Simulation,

Academic Press, 1996

[Gar2007] A. Garberi, Progetto e realizzazione di un tool per l'utilizzo e

la validazione di uno standard di comunicazione dati tra macchi-

ne del comparto meccano-calzaturiero, Tesi di Laurea in Ingegneria

Informatica, Università degli Studi di Pavia, 2007

[Ito2004] K. Ito, H. Nakajima, K. Kobayashi, T. Aoki, T. Higuchi,

A Fingerprint Matching Algorithm Using Phase-Only Correlation,

IECE Transactions Fundamentals, vol. E78-A, n. 3, pp. 682�691,

2004

BIBLIOGRAFIA 157

[Ito2005] K. Ito, A. Morita, T. Aoki, T. Higuchi, H. Nakajima, K.

Kobayashi, A Fingerprint Recognition Algorithm Using Phase-

Based Image Matching for Low-Quality Fingerprints, Proceedings

of IEEE Conference on Image Processing, vol. 2, pp. 33�36, Genova,

2005

[Jai1997] A.K. Jain, L. Hong, R. Bolle, On-Line Fingerprint Veri�-

cation, IEEE Transactions on PAMI, vol. 19, n. 4, pp. 302�314,

1997

[Jai2000] A.K. Jain, S. Pankanti, Fingerprint Classi�cation and Match-

ing , Handbook for Image and Video Processing, Academic Press,

2000

[Jai2004] A.K. Jain, S. Pankanti, S. Prabhakar, L. Hong, A. Ross,

Biometrics: a Grand Challenge, Proceedings of the 17th IEEE

ICPR, vol. 2, pp. 935�942, Cambridge, 2004

[Kar1995] K. Karu, A.K. Jain, Fingerprint Classi�cation, Pattern

Recognition, vol. 29, n. 3, pp. 389�404, 1995

[Mai2005] D. Maio, D. Maltoni, A.K. Jain, S. Prabhakar, Handbook

of Fingerprint Recognition, Springer, 2005

[Mat2008] G. Matrone, Un nuovo algoritmo per il riconoscimento di im-

pronte digitali e sua implementazione su logica programmabile di

tipo FPGA, Tesi di Laurea Specialistica in Ingegneria Biomedica,


[Mer2008] E. Merlino, Analisi di un compilatore per acceleratori hardware

basati su logiche programmabili attraverso implementazione di DFT,

Tesi di Laurea in Ingegneria Informatica, Università degli Studi di

Pavia, 2008

[Met1953] N. Metropolis, A.W. Rosenbluth, M.N. Rosenbluth,

A.H. Teller, E. Teller, Equation of State Calculations by Fast

Computing Machines, Journal of Chemical Physics 21, 1953, pp.

1087�1092

[Mun2004] M.U. Munir, M.Y. Javed, Fingerprint Matching Using Gabor

Filters, National Conference on Emerging Technology, pp. 147�151,

2004

[Nan2004] K. Nandakumar, A.K. Jain, Local Correlation-based Fingerprint

Matching , Proceedings of the 4th ICCVGIP, pp. 503�508, Kolkata,

2004

158 BIBLIOGRAFIA

[New1999] M.E. J. Newman, G.T. Barkema, Monte Carlo Methods in

statistical Physics, Oxford Clarendon Press, 1999

[Nob2007] M. Nobis, Acquisizione, compressione, elaborazione di immagini

termiche e visive di pneumatici tramite sistema embedded per tele-

metria F1, Tesi di Laurea Specialistica in Ingegneria Informatica,


[Nyo2004] H.O. Nyongesa, S. Al-Khayatt, S.M. Mohamed, M. Mah-

moud, Fast Robust Fingerprint Feature Extraction and Classi�ca-

tion, Journal of Intelligent and Robotic Systems, Springer, vol. 40,

n. 1, pp. 103�112, 2004

[Pic2007] M. Piccio, Un sistema embedded per il posizionamento del proto-

tipo di monoposto di F1 in galleria del vento, Tesi di Laurea Spe-

cialistica in Ingegneria Informatica, Università degli Studi di Pavia,

2007

[Qua2000] A. Quarteroni, R. Sacco, F. Saleri, Matematica Numerica,

Springer, 2000

[Ram2007] S. Rampazzi, Digitalizzazione e riconoscimento di forme 3D in

ambito calzaturiero, Tesi di Laurea in Ingegneria Informatica,


[San2003] F. Santini, Implementazione di un Nuovo Algoritmo di Finger-

print Matching e sua Integrazione in Ambiente Smart Card , Uni-

versità di Pisa, Facoltà di Scienze Matematiche, Fisiche e Naturali,

A.A. 2002�2003

[Sca2002] M. Scaricabarozzi, Calcolo dell'energia di sistemi dipolari tra-

mite acceleratore per calcoli in virgola mobile, Tesi di Laurea in

Ingegneria Informatica, Università degli Studi di Pavia, 2002

[Smi1997] S.W. Smith, The Scientist and Engineer's Guide to Digital Signal

Processing, California Technical Publishing, cap. 12, 1997

[Spe2004] A. Spelgatti, Progetto e Implementazione di un acceleratore per

calcoli in virgola mobile a doppia precisione, Tesi di Dottorato in

Ingegneria Informatica, Università degli Studi di Pavia, 2004

[Wan2002] S. Wang, W.W. Zhang, Y. S. Wang, Fingerprint Classi�cation

by Directional Fields, Proceedings of the 4th IEEE ICMI, pp. 395�

399, Pittsburgh, 2002

BIBLIOGRAFIA 159

[Zha2004] Q. Zhang, H. Yan, Fingerprint Classi�cation Based on Extraction

of Singularities and Pseudo Ridges, Pattern Recognition, Elsevier,

vol. 37, n. 11, pp. 2233�2243, 2004

sistemi efficienti per calcolo ad alte prestazioni e ...per prima cosa, ringrazio nelson davide...

Documents