12
l’utilizzo del risultato intermedio, per le nuove operazioni nella pipe, prima che sia
terminata la fase di write-back nel registro destinazione (result forwarding). La
prestazioni nella scrittura in memoria, punto dolente di ogni architettura, sono state
aumentate introducendo un buffer che esegue velocemente l’operazione salvando
temporaneamente il valore del dato prima di riversarlo autonomamente, in un secondo
tempo, in memoria.
Il numero degli stadi di pipe legati alle funzionalità espresse nelle unità, e quelle insite
nei componenti della Data Alu sono state trasmesse al nuovo progetto come specifiche
portanti della ricerca sviluppata nelle tesi precedenti.
La codifica ridondante, pur avendo contribuito alla espansione dello spessore dei
collegamenti interni (la codifica raddoppia la word dei dati e indirizzi), ha comunque
permesso l’abbattimento del tempo medio d’esecuzione delle operazioni, sia nella Data
Alu che nelle Address generation unit, orientando l’architettura alle applicazione in cui
fosse marcata, sopra ogni altra, la specifica prestazionale.
Specifiche aggiuntive
Il progetto del DSP asincrono è stato sviluppato per venire incontro anche alle
specifiche di consumo della macchina, e alla sua applicabilità su sistemi portatili che
richiedono, in maniera determinante, il requisito della potenza assorbita. Nel lavoro
svolto si è cercato, nei limiti del possibile, di mantenere un discreto livello di
prestazioni ed una elevata compatibilità con la struttura delle unità importate dal
progetto preso come punto di partenza.
Riassumendo, le specifiche aggiuntive che si sono introdotte sono state le seguenti:
- Modalità di comunicazione completamente asincrona per le unità e per le intime
sezioni in cui ciascuna risulta divisa.
- Versatilità ed espandibilità dell’architettura.
- Mantenimento del livello delle prestazioni.
- Basso consumo.
L’assunzione delle specifiche di progetto aggiuntive, in particolare l’implementazione
delle comunicazioni asincrone, hanno proiettato la progettazione dell’architettura e dei
13
suoi componenti in un ambito di ricerca, per certi versi, ancora più spinto. Le
metodologie di progettazione dell’unità di controllo e della pipe dei componenti delle
unità e delle modalità di comunicazione tra i blocchi sono state completamente
ripensate, e riorganizzate senza l’ausilio della conoscenza dello stato globale, sia futuro
che presente, dell’architettura completa, come avviene invece nell’implementazione
sincrona dello stesso progetto. L’assunzione della temporizzazione asincrona,
nell’intimo scambio di informazione tra due blocchi qualsiasi, si realizza associando ad
ogni canale una linea di sincronia (formata da due segnali contrapposti) che unisce un
blocco all’altro e che trasporta gli eventi attraverso cui si sciorina il protocollo di
comunicazione, mediante il quale si garantisce il corretto passaggio di un dato da un
blocco ad un altro.
La variazione del progetto dei singoli componenti della Data Alu ereditati (data path) è
stata leggera: la pipe sincrona è sostituita da una micropipeline (asincrona) con lo stesso
numero di stadi, che adotta le caratteristiche modalità, per trasferire il dato (Boundled
Data) e per propagare il ritardo (Boundled Delay), consolidate nella realizzazione di una
catena asincrona di percorsi d’elaborazione fisicamente disaccoppiati.
La gestione del controllo globale e delle comunicazioni ha invece costituito la vera e
propria sfida architetturale, visto che, attraverso la modalità di comunicazione
asincrona, non si riesce a tradurre la struttura dell’architettura nella classica pipe lineare
sincrona a controllo centralizzato (data-path, control-path). La frammentazione
dell’esecuzione in stadi d’elaborazione sequenziali delle istruzioni non è facilmente
gestibile, in quanto non sono prevedibili i momenti in cui si è certi della validità dei dati
all’ingresso dei blocchi, mancando una sincronizzazione globale non si riesce a
ricostruire deterministicamente l’informazione sullo stato di tutti gli stadi
dell’architettura.
quanto cosa che nel progetto asincrono non è ammissibile
ed è stata risolta rispettando anche la specifica di versatilità e espandibilità. Il basso
consumo è una specifica raggiungibile poiché connaturata all’assenza del clock e alla
problematica legata alla sua distribuzione. Una successiva valutazione accurata dei
consumi può avvenire solo prima della fase di sintesi.
14
Definizione dell’ISA della architettura
Ogni istruzione Assembler comunque complessa si può sempre suddividere in una serie
di sotto operazioni elementari (atomiche) nelle quali sono evidenti le unità e le rispettive
funzionalità coinvolte. Proprio su questo concetto si basa la prima sorta di
formalizzazione che prelude lo studio e la progettazione dell’architettura di un
dispositivo per l’elaborazione delle informazioni. Formalizzando l’Instruction Set
Architecture (ISA) si riesce ad offrire un valido supporto all’interfacciamento delle
relazioni simboliche presenti nell’istruzione con le funzionalità dell’Hardware
sottostante. Il quale è sede di tutte le elaborazioni aritmetiche, degli accessi in memoria,
del trasferimento tra i registri, ossia dell’implementazione del controllo
dell’elaborazione e della trasmissione dei dati tra i componenti dell’architettura.
L’implementazione dell’ISA, nel livello hardware sottostante, vincola in modo
determinante la strutturazione dell’architettura e soprattutto il design delle unità e della
sezione dedicata al controllo.
Innovazione introdotta dal progetto
Il progetto sviluppato in questa tesi supporta tra la definizione dell’ISA e la sua
implementazione di un’ulteriore livello di astrazione. La logica divisione delle
competenze, rispetto all’esecuzione di una istruzione del set, per le diverse unità
dell’architettura ha reso possibile la definizione, per ciascuna, di un µ ISA proprietario.
Nel quale sono riportate tette le istruzioni elementari è in grado di essere eseguite. Le
unità, opportunamente organizzate come in una classica rete di comunicazione, mettono
in atto lo scambio dei dati e le elaborazioni del caso come effetto della programmazione
predisposta da un controllore globale. Il quale sovrintende alla traduzione e alla
schedulazione delle µ istruzioni e alla gestione dei canali di comunicazione. In questo
modo si riesce a separare la definizione dell’ISA di sistema dal design delle unità che
devono implementarlo, demandando all’unità di controllo l’onere della traduzione e
gestione dell’iterfacciamento tra l’ISA globale e i µ ISA delle unità.
La separazione della definizione dell’ISA di sistema dal design delle unità sulle quali si
implementa, in altre parole svincola il controllo globale della macchina dal sistema di
temporizzazione utilizzato per sincronizzare gli eventi. Si è in grado, quindi, di gestire
15
la realizzazione dell’architettura asincrona come l’integrazione dei supporti fisici che
implementano le sezioni di programmazione di controllo e di comunicazione delle
unità.
I supporti gestiti nel progetto sono:
- Rete di programmazione delle unità.
- Rete di controllo delle risorse strutturali comuni.
- Rete di comunicazione delle unità.
La rete di programmazione, con la tipologia a stella, raggiunge tutte le unità
programmabili ed è in grado di servire la programmazione a più unità
contemporaneamente. La rete di controllo dirama gli eventi di sincronia che di fatto
abilitano l’utilizzo delle risorse strutturali condivise come i bus dati, ecc. Si riescono a
gestire anche più risorse contemporaneamente. La rete di comunicazione delle unità ha
la tipologia di una rete a multi bus comune dove la definizione del canale avviene
mediante la sincronizzazione delle unità sorgenti con quelle destinazioni in modo
completamente autonomo.
La definizione e la caratterizzazione dei i supporti di sviluppo implicitamente orienta
anche la costruzione delle interfacce (sync-in, sync-out) mediante le quali le unità
possono integrarsi ed interagire come parti vitali della struttura.
Il µ ISA di ciascuna unità si implementa nella sezione che costituisce il nocciolo (core)
dell’unità, la cui organizzazione e design deve solamente rispondere alle specifiche di
elaborazione di personale competenza e alla compatibilità con le interfacce con le reti di
programmazione controllo e comunicazione.
L’unità di controllo è il cuore dell’architettura in quanto esegue il caricamento e la
traduzione dell’istruzione programma scritto nell’ISA di sistema nella serie di µ
istruzioni scritte ognuna secondo il µ ISA delle unità a cui sono destinate. Inoltre
gestisce la rete di programmazione e quella di controllo mediante la quale garantisce la
correttezza del protocollo della comunicazione tra le unità funzionali.
16
Riassumendo i task paralleli di cui si compone l’unità di controllo sono:
- Caricamento istruzione programma.
- Traduzione dinamica da ISA a µ ISA.
- Completamento della µ istruzione con i riferimenti delle interfacce delle reti di
comunicazione.
- Gestione della rete di programmazione delle unità.
- Gestione della rete di controllo.
La µ istruzione inviata ad una determinata unità si compone, oltre della sezione dedicata
alle elaborazione interna dei dati, appartenenti al proprio µ ISA, anche delle sezioni
dedicate unicamente alle interfacce di rete, mediante le quali si completa il corpo della
processione dell’informazione che conta la lettura dei dati da elaborare e il trasferimento
dei risultati elaborati.
17
1 Capitolo
Progettazione di sistemi digitali integrati
(Synchronous Vs Asynchronous)
1.1 Livelli di astrazione di un sistema digitale
integrato
La progettazione dell’architettura di un sistema elettronico abbraccia idealmente gli
ultimi livelli di astrazione con cui è possibile descrivere una macchina elaboratrice.
Fig 1.1 Livelli di astrazione di una macchina elaboratrice
La programmazione di un DSP avviene direttamente accedendo al livello di astrazione
del linguaggio Assemblato. In maniera completamente trasparente al programmatore
l’implementazione del linguaggio di basso livello ISA, che contiene tutte le istruzioni
elementari che è in grado di eseguire il processore, viene prodotto dall’assemblatore.
High level language
Assembly language
ISA
(Instruction Set Architecture)
HARDWARE
Compiler
Assembler
18
Per definizione, l’Instruction Set Architecture separa il passo della scrittura del
compilatore dal passo del progetto ed organizzazione di un processore. La scelta del
dominio delle applicazioni dovrebbe contribuire a rendere la codifica efficiente
(misurabile attraverso l’Instruction Count ossia il numero di istruzioni dinamicamente
eseguite). La misura del tempo e energia richiesta per eseguire una determinata
elaborazione (tempo medio d’esecuzione per istruzione), è parametro importante per la
determinazione delle prestazioni di un processore. Queste specifiche sono in grado di
influenzare la progettazione dell’ISA e la successiva implementazione nell’architettura.
1.2 Flusso di progettazione di un sistema digitale
La progettazione di un sistema elettronico implica l’astrazione del suo comportamento
in una precisa descrizione ( in C++, VHDL o Verilog), nella quale sono chiaramente
evidenti le strategie di implementazione; si riporta, in una serie di livelli di astrazione, il
flusso di progettazione dalla specifica del sistema alla sua implementanzione. I livelli di
astrazione potrebbero variare da problema a problema e dagli stili di progetto, ma
ciascuno raggruppa almeno parte dei dettagli e funzionalità del sistema che si ha sotto
esame.
19
Fig 1.2 Diagramma di flusso di progettazione di sistemi
n Specification. Racchiude la descrizione generale del sistema nel rispetto della
specificata applicazione. A questo livello, il sistema è descritto come una “scatola
nera” e le funzionalità sono date usando un semplice linguaggio descrittivo o
utilizzando un linguaggio di programmazione.
n Architecture. Il sistema è decomposto in una serie di scatole nere; ognuna con la
propria funzionalità e con un definito interfacciamento con le altre. Nessuna
assunzione è fatta sulla implementazione e la comunicazione tra le scatole.
L’architettura dei sistemi è usualmente espressa utilizzando un linguaggio
dedicato (hardware-description Languages), corredato dal proprio ambiente di
sviluppo e simulazione.
n Functional Block. Ogni blocco dell’architettura è successivamente decomposto
nei suoi più intimi blocchi funzionali (idealmente) dipendenti dalle strategie di
implementazione. Si scelgono due caratteristiche di progetto: lo schema di
comunicazione e lo stile di progettazione. La comunicazione attraverso i blocchi
può essere sincronizzata su un clock globale (synchronous design) o localmente
Specification Architecture
Functional Blocks
Logical Model
Circuital Model
Physical Model
Implementation
Product
Not Possible
HDL and programming
languages
HDL and programming
languages
HDL languages and
switch simulator
Switch and analog
simulator
Layout CAD
Fabbrication
Programming languages
20
sincronizzate mediante handshaking (asynchronous design). Lo stile di
progettazione ha a che fare con la futura decomposizione della nostra descrizione,
che può coinvolgere solo la progettazione logica (semi-custom o automated
design) o la progettazione fisica (full-custum design)
n Logical model. Una volta scomposto in una collezione di blocchi funzionali di
ridotta dimensione, ogni blocco deve essere descritto usando (Boolean) operatori
logici. A questo livello di astrazione si decide la tecnologia da adottare per la
realizzazione (semiconduttori o elettronica quantistica e mappare le equazioni
logiche con questa tecnologia).
n Circuit model. Ogni operatore logico è descritto in termini di dispositivi
elettronici cosi che la simulazione del comportamento del sistema possa essere
effettuata.
n Physical model. Il sistema è descritto con sufficente dettaglio per la
fabbricazione (layout)
n Implementation. Il sistema è realizzato, testato e le prestazioni misurate.
Il flusso di progetto segue un approccio gerarchico, se mediante la simulazione delle
caratteristiche di ogni livello si riscontrasse una decomposizione non ammissibile, si
ritorna indietro nel flusso di progetto finché il problema non si risolve fino alla
decisione di abbandonarlo.
1.3 Progettazione sincrona e asincrona
La progettazione di una architettura asincrona incontra lo sfavore del principale
fondamento della teoria stessa: la continuità del tempo. Rispetto alla progettazione
sincrona, nella quale la discretizzazione del tempo è alla base della definizione dello
spazio degli eventi, quella asincrona non riesce a definire lo stato del sistema in ogni
istante, ne ad avere una visione globale del flusso delle informazioni e dei dati al suo
interno. Grazie al clock, infatti, si può diffondere una sincronia che temporizza gli
eventi del sistema mentre in sua assenza questa è generata dagli stessi eventi, ossia da
segnali di sincronizzazione che definiscono il canale tra un blocco e l’altro.
21
Fig 1.3 sincronia dei blocchi in un sistema sincrono e in un sistema asincrono
La mancata conoscenza dello stato globale rende difficile la gestione delle
comunicazioni tra unità condivise e la gestione delle risorse comuni a ciascuna unità
(Bus dati, Bus indirizzi). Il passaggio di informazioni, fra un unità e l’altra mediante un
bus di comunicazione, si scompone logicamente in due sotto operazioni: scrittura del
bus e lettura del bus. In una architettura sincrona la conoscenza esatta dello stato
dell’unità scrivente, del bus e dell’unità ricevente, risolve l’intera operazione con
l’invio, dopo un numero finito di quanti temporali (colpi di clock), dell’opportuno
controllo rispettivamente ai driver (dell’unità scrivente) e ai multiplexer (dell’unità
ricevente). Il clock quantizzando il tempo pone le basi per la conoscenza dello stato
futuro della macchina garantendo, nei limiti della buona progettazione, il corretto fluire
dei dati all’interno della pipe dell’architettura.
Dall’altro fronte, per garantire una corretta comunicazione, un corretto utilizzo del bus,
un coerente flusso dei dati nell’architettura asincrona, si dove cambiare completamente
approccio al problema. L’introduzione del nuovo concetto di controllo deve garantire
DATA
PATH
DATA
PATH
CONTROL
PATH
CLOCK
DATA
PATH
DATA
PATH
Produttore Consumatore
Stadi di pipe sincronizzati
Sistema Sincrono:
Il metronomo
propaga la sincronia
in tutto il sistema.
Sistema Asincrono:
La sincronia è legata
al tempo di latenza
del singolo stadio.
22
oltre alla corretta elaborazione dei dati, all’interno di ciascuna unità, anche un corretto
passaggio di dati tra le unità sventando i possibili conflitti sul bus di comunicazione, sia
in lettura che scrittura.
La differenza sostanziale che distingue la progettazione sincrona da quella asincrona è
l’organizzazione della Pipe nella realizzazione dell’architettura. La rivoluzione epocale
che portò alla divisione della macchina in stadi contigui, simili ad una catena di
montaggio, porta con se immancabilmente dei conflitti strutturali. L’evidente vantaggio
è quello di iniziare, mentre sono in esecuzione o si concludono, diverse operazioni
contemporaneamente, incrementando notevolmente le prestazioni della macchina
elaboratrice.
Il problema di una struttura di questo tipo è a monte per quanto riguarda la coerenza dei
dati e a valle per quanto riguarda i conflitti di sistema. Intendendo come monte il luogo
nel quale vengono impartite le istruzione, e come valle il luogo dove fisicamente si
realizzano. Nel mezzo nasce quindi l’esigenza di organizzare l’esecuzione, rispettando
l’ordine logico delle istruzioni e la propria coerenza matematica, senza trascurare le
leggi che regolano il reale utilizzo dei dispositivi elettronici che le implementano.
1.4 Generalità sulla progettazione sincrona
Qualsiasi evento dentro l’architettura è legato allo stato di un unico elemento
sincronizzante: il clock. Per evento si intende l’atto di memorizzazione, presente
all’ingresso di ogni stadio, delle informazioni elaborate da quello precedente, che
garantisce la fisica stabilità del dato per il blocco successivo. Una sequenza ordinata di
blocchi costituiscono una pipe sincrona quando dopo un lavoro di calibratura, si
introduce un segnale che abilita il passaggio del dato da un blocco al successivo. Se il
segnale sincronizzante si decide di farlo periodico, nei limiti di una buona
progettazione, il ritardo che ogni blocco deve introdurre deve essere al massimo più
piccolo del periodo fissato. Lo svantaggio sopracitato è il dazio da mettere in conto al
grande vantaggio che un’architettura complessa può sfruttare. Nella semplice pipe
lineare, dove ogni blocco contiene tutta la logica necessaria all’elaborazione, non viene
23
sfruttata affatto. Si prenderà, comunque, questo tipo di pipe come oggetto delle nostre
seguenti discussioni. Avendo introdotto il segnale di clock come temporizzatore degli
eventi, ora, si dispone di un metro per misurare lo stato di avanzamento dell’istruzione
nella pipe.
Ad ogni ciclo di clock si permette l’ingresso di una nuova operazione nella coda;
contemporaneamente tutte avanzano di un posto all’interno della pipe stessa, mentre
l’ultima è pronta ad uscire. In modo deterministico si riesce a prevedere quando (in
numero di cicli di clock) un dato entrato uscirà dalla coda oppure quando si troverà in
un determinato punto. La cinematica delle istruzioni basata sulla discretizzazione del
dominio tempo è il fondamento della teoria che sta alla base dell’approccio sincrono.
Un controllore, che con opportuni segnali raggiunge i blocchi funzionali della pipe,
riesce ad organizzarsi l’invio dei comandi poiché è a conoscenza dello stato in cui si
trova ed in cui si troverà la pipe ad ogni colpo di clock.
Se si complica la struttura da studiare rimane inalterato il vantaggio di poter prevedere
deterministicamente la forma che mano a mano andrà ad assumere la pipe
nell’architettura. Per esempio, si analizzino i 13 stadi di pipe in cui risulta diviso il dsp
sincrono del progetto di partenza.
N° stadio Descrizione
1 Fetch I
2 Fetch II
3 Fetch III
4 Decode I
5 Decode II
6 Address Generation I
7 Address Generation II
8 Address Generation III
9 Address Generation IV
10 Memory Access I
11 Memory Access II
12 Execute
13 Write back
Le parti funzionali che lo compongono sono le Memorie Dati, quelle programma, la
Data ALU, la Address ALU, il Register File, ecc.
24
La sezione di controllo deve essere in grado di comandare contemporaneamente tutti gli
stadi di pipe e risolvere tutti i conflitti strutturali che sopraggiungono quando la pipe è a
regime. Si deve fare attenzione alle risorse condivise dai vari stadi per non incorrere in
erronee letture o incaute scritture. Non devono verificarsi, quindi, conflitti sul bus, ne
conflitti sulla memoria, come letture di dati non scritti o conflitti sui registri, come
letture di dati non ancora aggiornati. Per semplificare la spiegazione riporto, per le
operazioni più consuete, quali sono gli stadi di pipe interessati dai possibili conflitti.
STRUTTURA DELLA PIPE
F
E
T
C
H
I
F
E
T
C
H
II
F
E
T
C
H
III
D
E
C
O
D
E
I
D
E
C
O
D
E
II
A
D
D
R
G
N
I
A
D
D
R
G
N
II
A
D
D
R
G
N
III
A
D
D
R
G
N
IV
M
E
M
O
R
Y
I
M
E
M
O
R
Y
II
E
X
E
C
U
T
E
W
R
I
T
E
B
A
C
K
Descrizione
dell’operazione
Note
X X X X X X X X X � X ∼ ∼ Read Memory �1
X X X X X X X X X � X ∼ ∼ Write Memory �2
X X X X X ∼ ∼ ∼ ∼ ∼ ∼ � X ALU �2
�1 : Memory - Memory (RaW)
Durante un’operazione di lettura della memoria si deve controllare che non si
stia leggendo una locazione interessata da una precedente scrittura non ancora
ultimata.
�2 : Register - Memory (WaW)
Durante la scrittura di un registro in memoria si deve attendere che il dato sia
pronto ossia che sia stato precedentemente aggiornato.
�3 : Register - Register (RaW)
Prima del caricamento degli operandi sorgente si deve controllare la loro bontà,
assicurandosi che siano aggiornati e non sia in corso un precedente
aggiornamento.
Controlli supplementari vanno effettuati anche sulle risorse condivise in lettura e
scrittura, come i bus utilizzati da entrambi le unità per il passaggio di informazioni.
Si evince quindi, che con l’aumentare del numero di stadi di pipe aumenta anche la
frequenza dei possibili conflitti e proporzionalmente il carico per l’unità di controllo.
Per gestire la sequenza dei controlli da effettuare nella pipe, l’unità di controllo si
avvale di un tabella rappresentante lo stato complessivo che mano a mano viene a
25
profilarsi. Ogni istruzione pone i riferimenti di cui dispone e di cui vorrebbe disporre in
futuro in questa tabella, che ciclo dopo ciclo aggiornerà dinamicamente la condizione di
necessità e disponibilità delle risorse del sistema.
L’unità preposta al controllo, consultando la tabella, ha in tempo reale la condizione
della pipe ed è in grado di rilevare staticamente i conflitti prima che sorgano, ponendoci
il rimedio opportuno.
In un progetto sincrono si conosce con nitida certezza lo stato presente passato e futuro
di ogni singolo stadio di pipe della macchina. La finestra temporale, che
ragionevolmente si apre dal presente verso il futuro, è limitata superiormente dal
numero massimo di stadi di pipe o da eventi accidentali (interrupts) o programmati che
ridisegnano il fluire delle operazioni. Coadiuvando la deterministica sequenza di eventi
con la conoscenza mirata delle risorse e delle funzionalità necessarie al completamento
dell’istruzione in ogni singolo stadio di pipe, si riesce a realizzare un efficiente
sfruttamento della pipe al riparo da Hazard e conflitti strutturali.
1.5 Generalità sulla progettazione asincrona
Il paradigma della progettazione asincrona assume che il tempo non è discreto, ma
denso o continuo. Così, invece di guardare allo stato globale del sistema ad un
determinato istante alcuni sistemi aspettano degli eventi: “Event Driven”.
L’informazione è comunicata senza alcuna temporizzazione esterna. Questo è possibile
impiegando meccanismi di Pronto e Ricevuto (Request / Acknowledge) in protocolli di
scambio dati. Il sistema sincrono può essere considerato come un caso speciale di quello
asincrono dove è presente un segnale periodico chiamato clock.
La logica asincrona è guidata, attivata dagli eventi. Il livello di voltaggio sulla linea non
ha importanza, come non c’è un particolare momento in cui il sistema guarda i propri
inputs. Per questo motivo in un sistema asincrono, dato che, chi invia il dato non ha idea
di quando il ricevente è pronto per il dato o se invece lo sta attendendo, si introduce una
comunicazione ad hoc che definisce il canale. Ci si avvale dei meccanismi che
Ricevi informazioni sui nostri servizi, sulle offerte e non perdere news e consigli su università e lavoro.
