41 / 86
DIGITAL
FPGA
41
- ELETTRONICA OGGI 451 - GENNAIO/FEBBRAIO 2016
sviluppatori devono anche adottare un certo nume-
ro di tecniche già note come ad esempio retiming
dei registri, pipelining e ottimizzazione del progetto.
All’aumento delle prestazioni concorrono sia l’uso
di queste tecniche sia i miglioramenti apportati
a livello architetturale. Per quando concerne l’ar-
chitettura, la modifica più importante è l’aggiunta di
un gran numero di registri (denominati Hyper-Reg-
ister) in ogni segmento di routing delle interconnes-
sioni e agli ingressi di ogni blocco funzionale. L’imp-
iego di questi registri consente agli sviluppatori di
effettuare il retiming dei percorsi critici e di utilizza-
re registri di pipeline per eliminare i ritardi dovuti
al routing. Con questo approccio i registri per il re-
timing e il pipelining di tipo bypassabile di fatto “in-
terrompono” il collegamento tra i registri funzionali
presenti nei moduli ALM (Adaptive Logic Module) e
i registri utilizzati per il retiming e il pipelining.
Tutti i segmenti di routing hanno un Hyper-Register
opzionale integrato nel multiplexer di routing pro-
grammabile che consente al segmento di routing di
essere di tipo registrato o combinatorio. Questi Hy-
per-register sono disponibili ovunque nella struttu-
ra del nucleo dell’FPGA come riportato in figura 1.
Gli Hyper-Registers sono rappresentati dal piccolo
quadrato posti all’intersezione di ogni segmento di
routing orizzontale e verticale.
Con un’architettura di questo tipo non è necessario
ricorrere a un ALM solamente per utilizzare un regi-
stro di pipeline. Ciascuna linea di interconnessione orizzontale
e verticale presente nel dispositivo contiene un Hyper-Regis-
ter che può essere attivato o disattivano configurando l’FPGA.
Gli Hyper-Register sono registri di tipo bypassabile a un in-
gresso e un’uscita senza multiplexer di instradamento in in-
gresso controllabili mediante bit di configurazione. Si tratta di
dispositivi economici che occupano un’area limitata di silicio.
Poiché gli Hyper-Register sono dovunque nella struttura del
core, i progettisti non hanno alcun limite per quanto riguar-
da il numero di registri da impiegare. Essi possono effettuare
operazioni di retiming e pipelining quando necessario senza
consumare risorse aggiuntive dei LAB (Logic Array Block). In
molti casi il progetto utilizza un numero inferiore di risorse di
un LAB poiché si utilizzano i registri per implementare gli Hy-
per-Register invece di utilizzare parzialmente un modulo ALM
(ovvero solamente per utilizzare il suo registro).
Retiming…
Nelle architetture di tipo tradizionale il software esegue il re-
timing individuando un registro di un ALM non utilizzato che
si trova nelle vicinanze per includerlo nel circuito. I limiti di
questa tecnica sono imputabili alla granularità del posizion-
amento del registro del modulo ALM in quanto quest’ultimo
può essere ubicato in una posizione non particolarmente van-
taggiosa, provocando in tal modo un ritardo addizionale che
quindi deve essere contemplato nel progetto. Inoltre è nec-
essario tener contro del ritardo imputabile all’instradamento
dall’ALM al registro.
Nella figura 2 è riportato un esempio di routing prima e dopo
il retiming nel caso di un’architettura di tipo tradizionale.
Nel caso dell’architettura Hyperflex il retiming dei registri, de-
nominato Hyper-Retiming, è caratterizzato da una granularità
è estremamente fine, essendo riconducibile al ritardo di un
singolo filo di routing, che può essere stimato dell’ordine di
poche decine di picosecondi. E’ quindi possibile eliminare i
compromessi richiesti quando si cerca di individuare i regi-
stri di retiming nelle architetture tradizionali (si faccia riferi-
mento alla Fig. 2) e i percorsi brevi (dell’ordine di alcuni na-
nosecondi) possono essere suddivisi senza problemi durante
l’Hyper-Retiming, come riportato in figura 3.
Poiché l’Hyper-Retiming non ha alcuna influenza sui blocchi
LAB e sui moduli ALM, non è necessario eseguire operazioni
Fig. 2 – Esempio di routing prima e dopo il retiming nel caso di architetture di tipo
tradizionale
Fig. 3 – L’operazione di Hyper-Retiming nell’architettura HyperFlex