Progettazione firmware FPGA: quanto è grande è troppo grande?

12

Ho una trasformazione di elaborazione del segnale particolarmente grande che deve essere trasferita da MATLAB a VHDL. Richiede sicuramente una sorta di condivisione delle risorse. Un po 'di calcolo mi ha dato quanto segue:

512 fft di 64 punti
41210 operazioni di aggiunta multipla

Considerando che il più grande FPGA Virtex 6 ha ~ 2000 blocchi DSP48E, so che posso condividere le risorse al fine di riutilizzare le risorse più volte. Il tempo di esecuzione non è in realtà un problema, il tempo di elaborazione può richiedere relativamente lungo in termini di FPGA.

Per quanto riguarda l'utilizzo delle risorse, l'uso dell'architettura radix-2 lite mi dà blocchi 4dsp / operazione FFT = 2048 blocchi DSP, per un totale di ~ 43k. il più grande FPGA Virtex ha 2k blocchi o 20 operazioni / mux.

Ovviamente anche includere mux così grandi nel tessuto occuperà anche delle fette. Dove trovo il limite superiore di questo limite? Non posso condividere all'infinito le risorse FPGA. I moltiplicatori 41210 sono troppo grandi? Come posso calcolare ciò che è troppo grande?

Ho anche esaminato altre risorse (Slices, Brams, ecc.). Radix-2 Lite fornisce anche 4 x 18k brams / fft = 2048 brams il più grande FPGA Xilinx contiene 2128 Brams. molto borderline. Sono preoccupato che il mio design sia troppo grande.

AGGIORNARE:

Qualche informazione in più sul design stesso. Non posso entrare nei dettagli, ma ecco cosa posso dare:

Initial conditions -> 512 ffts -> 40k multipliers ---------|----> output data to host 

                 ^------re-calculate initial conditions----|

output spec datarate: "più veloce della simulazione matlab"

saggi calcoli, ecco dove sono:

Palco FFT: facile. Posso implementare FFT 1/2/4/8, archiviare i risultati in SDRAM e accedervi in seguito. Relativamente piccolo, anche se richiede molto tempo, va bene. usando radix-2 lite posso ottenere 2 DSP48Es e 2 18k BRAMS / FFT. lo streaming dà 6 DSP48Es 0BRAMS / FFT. in entrambi i casi, la FFT a 64 punti è piccola in termini di risorse FPGA.

Moltiplicatori : questo è il mio problema. Gli input di moltiplicazione sono presi dalle tabelle di ricerca o dai dati FFT. È davvero solo un mucchio di moltiplicazioni. Non c'è molto da ottimizzare. Non è un filtro, ma ha caratteristiche simili a un filtro.

Considerando la condivisione delle risorse sull'FPGA, la matematica funziona come segue: un LUT-6 può essere usato come un mux a 4 vie. La formula per un N-way, M bit mux è la seguente:

N*M/3 = number of luts, or N*M/12 = slices (4 LUTS/slice).

scricchiolare i numeri per la mia implementazione non dà buoni risultati. Il 90% della famiglia virtix-6 non ha abbastanza sezioni per condividere le risorse dei propri DSP al fine di eseguire 40.000 operazioni.

fpga vhdl xilinx

— stanri
fonte

Le forme più efficienti di condivisione delle risorse sono la serializzazione parziale in cui è possibile accedere ai dati indirizzando la memoria. Ovviamente, all'estremo di ciò, si ritorna a un processore di programmi memorizzati convenzionale: la mancanza di requisiti di prestazioni elevate inizia a indicare la flessibilità di un'implementazione del software che può essere eseguita in un cloud di calcolo.

— Chris Stratton,

1

Questo non fa parte della tua domanda, ma nel tuo calcolo delle risorse non hai indicato quale operando dimensioni. 512 FFT x 64 punti x quanti bit? In un FPGA la dimensione dell'operando dipende totalmente da te, quindi devi considerarla quando risolvi la dimensione del tuo problema.

— The Photon,

Non so se te ne sei reso conto, ma quei grandi FPGA sono piuttosto costosi. Alcuni possono superare $ 5k. Forse dovresti considerare anche questo, a meno che il costo non sia un problema.

— Gustavo Litovsky,

1

Sfortunatamente, al di là del tipo di suggerimenti di soluzioni alternative che hai ricevuto finora nelle risposte, dubito che possiamo fare molto di più per te. Voglio dire, potresti creare un solo core FFT e far passare i tuoi 512 ingressi uno dopo l'altro, e ovviamente si adatterebbe anche a un FPGA abbastanza piccolo. A metà strada tra questo e fare tutto in parallelo c'è il giusto equilibrio tra velocità e risorse per la tua applicazione ... ma è difficile per chiunque tranne te dire dove dovrebbe trovarsi tale equilibrio.

— The Photon

1

Hai un numero di budget per questo? Come ha sottolineato Gustavo, gli FPGA di fascia alta sono costosi, così come lo sviluppo di un PCB per farli sedere. Considerando che semplicemente raddoppiando (o quadruplicando o ...) la quantità di hardware di calcolo e continuando a utilizzare l'attuale, comprovato (?) Codice Matlab potrebbe probabilmente soddisfare le specifiche di velocità fornite.

— The Photon,

8

Mi chiedo se esiste un altro modo di vedere il problema?

Suonando la tua stima di 512 operazioni FFT (64 punti ciascuna) e 42k operazioni MAC ... Presumo che questo sia quello che ti serve per un passaggio attraverso l'algoritmo?

Ora hai trovato un core FFT usando 4 unità DSP ... ma quanti cicli di clock ci vogliono per FFT? (throughput, non latenza)? Diciamo 64, o 1 ciclo per punto. Quindi devi completare quelle 42k operazioni Mac in 64 cicli - forse 1k MAC per ciclo, con ogni MAC che gestisce 42 operazioni.

Ora è il momento di esaminare il resto dell'algoritmo in modo più dettagliato: identificare non i MAC ma operazioni di livello superiore (filtro, correlazione, qualunque cosa) che possono essere riutilizzate. Costruisci core per ognuna di queste operazioni, con riutilizzabilità (ad es. Filtri con diversi set di coefficienti selezionabili) e presto potresti trovare relativamente pochi multiplexer necessari tra core relativamente grandi ...

Inoltre, è possibile ridurre la forza? Ho avuto alcuni casi in cui sono state necessarie moltiplicazioni negli anelli per generare quadratiche (e superiori). Srotolandoli, potrei generarli in modo iterativo senza moltiplicazioni: sono stato abbastanza soddisfatto di me stesso il giorno in cui ho costruito un motore di differenza su FPGA!

Senza conoscere l'applicazione non posso fornire ulteriori dettagli, ma alcune di queste analisi probabilmente renderanno possibili alcune importanti semplificazioni.

Inoltre, poiché sembra che tu non abbia in mente una piattaforma definita, considera se puoi partizionare su più FPGA ... dai un'occhiata a questa scheda o a questa che offre più FPGA in una comoda piattaforma. Hanno anche una scheda con 100 dispositivi Spartan-3 ...

(ps sono rimasto deluso quando i ragazzi del software hanno chiuso quest'altra domanda - penso che sia almeno altrettanto appropriato lì)

Modifica: ri la tua modifica - Penso che stai iniziando ad arrivarci. Se tutti gli ingressi del moltiplicatore sono uscite FFT o coefficienti di "non filtro", si inizia a vedere il tipo di regolarità che è necessario sfruttare. Un input per ciascun moltiplicatore si collega a un'uscita FFT, l'altro input a un coefficiente ROM (BlockRam implementato come un array costante).

Il sequenziamento di diverse operazioni FFT attraverso la stessa unità FFT eseguirà automaticamente la sequenza delle uscite FFT oltre questo moltiplicatore. Il sequenziamento dei coefficienti corretti nell'altro ingresso MPY ora è "semplicemente" una questione di organizzazione degli indirizzi ROM corretti al momento giusto: un problema organizzativo, piuttosto che un enorme mal di testa di MUX.

Per quanto riguarda le prestazioni: penso che Dave Tweed sia stato inutilmente pessimista: la FFT ha preso n * log (n) operazioni, ma puoi scegliere O (n) unità farfalla e O (logN) cicli, o O (logN) unità e O ( n) cicli o qualche altra combinazione per adattarsi agli obiettivi di risorse e velocità. Una di queste combinazioni può rendere la struttura della moltiplicazione post-FFT molto più semplice di altre ...

— Brian Drummond
fonte

Un FFT implementato con una singola farfalla hardware richiederà il completamento dei cicli di clock NlogN; per 512 punti, sarebbero 256 * 8 farfalle o 2048 orologi. Ciò significa che i MAC 41210 (o 32768?) Richiederebbero solo 8-10 moltiplicatori hardware per essere eseguiti nello stesso periodo di tempo.

— Dave Tweed

Voglio dire, 16-20 moltiplicatori.

— Dave Tweed

Scusa, ho appena capito di averlo fatto al contrario. Gli FFT individuali sono 64 punti, quindi l'implementazione a farfalla singola richiederà 32 * 5 = 160 clock. I MAC possono quindi essere eseguiti con moltiplicatori hardware 200-250.

— Dave Tweed

questo è ciò che mi sorprende. In che modo xilinx è in grado di progettare un core in grado di eseguire fft 16k / 32k che richiedono operazioni di aggiunta multipla di 400k (NlogN) e tuttavia sto lottando con il mio 41k? Ci deve essere un modo!

— Stanni

@Dave: credo che intendi 160 moltiplicazioni, non 160 cicli, sicuramente? Non c'è nulla di così intrinsecamente serializzato in una FFT ...

— Brian Drummond,

2

Se questo problema non ha vincoli duri in tempo reale e sembra che non lo sia - vuoi solo che funzioni "più veloce", allora sembra che potrebbe essere abbastanza suscettibile all'accelerazione su una o più GPU. Esistono diverse librerie di software che rendono questa proposta relativamente semplice, e questo sarebbe circa un ordine di grandezza più semplice che passare direttamente all'hardware FPGA personalizzato.

Per iniziare, basta Google per "libreria abilitata per GPU" o "libreria con accelerazione GPU".

— Dave Tweed
fonte

È interessante notare che ho menzionato le GPU al cliente quando ho sentito parlare di questo progetto e non era interessato.

— Stanni

@StaceyAnneRieck: Ha detto perché?

— Dave Tweed

In realtà non ha detto perché, ma solo che ci aveva esaminato prima di usare un FPGA, a quanto pareva sembrava meno lavoro. Devo richiamare di nuovo.

— Stanni

@stanri: Anche se alla fine finisci con un'implementazione FPGA, mi sembra che la GPU possa essere un buon modo per "basare" l'architettura generale del sistema. Hai (e potresti condividere?) Una sorta di grafico del flusso di dati di alto livello per l'algoritmo e puoi darci un'idea della quantità di dati coinvolti? Senza risposte a domande come queste, sarà davvero difficile darti qualcosa di diverso da una consulenza molto generica.

— Dave Tweed

In realtà è un algoritmo molto molto semplice, è solo la scala che lo rende così complicato. Fondamentalmente come segue: condizioni iniziali -> 512 ffts in parallelo -> 32768 moltiplica le operazioni sull'uscita FFT -> regola le condizioni iniziali -> risciacqua e ripeti

— stanri

1

È possibile utilizzare un hardware specializzato o un FPGA (o anche un CPLD) per accelerare notevolmente determinati tipi di operazioni matematiche. La cosa fondamentale da tenere a mente quando si cerca di progettare hardware (circuiti o logica FPGA) per accelerare le operazioni matematiche è capire quali dati di ordine saranno necessari per entrare e uscire dal dispositivo. Un dispositivo con un layout I / O efficiente può offrire prestazioni molto migliori di uno con un layout inefficiente, anche se quest'ultimo dispositivo richiede molti più circuiti.

Non ho provato a elaborare un progetto di assistenza hardware per un FFT, ma uno che ho visto è l'assistenza hardware per operazioni di moltiplicazione di grandi dimensioni (come potrebbe essere usato per la crittografia RSA). Molti microcontrollori, anche quelli con hardware speciale a moltiplicazione rapida, non sono terribilmente efficienti in tali operazioni perché richiedono un sacco di shuffle di registro. L'hardware progettato per ridurre al minimo lo scambio di registri potrebbe ottenere prestazioni molto migliori con operazioni di moltiplicazione multi-precisione, anche se l'hardware stesso non era così sofisticato. Ad esempio, l'hardware che può eseguire una moltiplicazione 16xN pipeline due bit alla volta (spostando in due bit inferiori di multiplo e spostando due bit superiori di risultato) può ottenere prestazioni migliori rispetto all'hardware che può eseguire una moltiplicazione 8x8 in un ciclo, anche se il primo può richiedere meno circuiti (e, in virtù del pipelining, ha un percorso dati critico più breve). La chiave è capire come sarà il "ciclo interno" del codice necessario e capire se ci sono inefficienze che possono essere facilmente eliminate.

— Supercat
fonte

Quali tipi di operazioni sono particolarmente adatte a questa forma di ottimizzazione? Ho modificato la domanda sopra per dettagliare un po 'di più sulla natura dell'operazione moltiplicare. Il design hardware-assist sembra davvero interessante!

— Stanni

0

Quanto poco tempo di esecuzione ci è stato?

Sembra davvero una situazione in cui dovresti davvero implementare un soft-MCU, un FPGA con un hard-MCU integrato, o anche un dispositivo MCU separato, e serializzare tutte le tue operazioni.

Supponendo che tu abbia il tempo di esecuzione, eseguire i tuoi FFT nel software sarà sia molto più facile da eseguire il debug, sia probabilmente molto più semplice da progettare.

— Connor Wolf
fonte

1

Fare un calcolo pesante in una CPU soft core su un FPGA è sciocco; se hai intenzione di fare il calcolo in un'architettura di programma memorizzata (qualcosa che dovrebbe essere considerato), a causa di cpu ad alte prestazioni / dollaro duro dove non paghi la penalità di velocità della logica flessibile rispetto a comparable-fab- generazione di logica dura.

— Chris Stratton,

@ChrisStratton - Buon punto. Aggiunta una nota aggiuntiva in tal senso.

— Connor Wolf,

1

Anche le CPU rigide integrate non sono in grado di reggere il confronto con i processori / GPU convenzionali di base per le attività basate su software e costeranno drasticamente di più.

— Chris Stratton,

@ChrisStratton - Pensavo che le architetture integrate della CPU più comuni fossero ARM o POWER? In tal caso, si tratta sostanzialmente di una CPU di base.

— Connor Wolf,

1

Data la tua altra domanda FPGA, la costruzione della scheda FPGA è probabilmente un'esperienza di apprendimento che costerà un po 'più del previsto. Penso che la cosa da fare a questo punto sarebbe quella di fornire al cliente alcuni numeri di prezzo / prestazioni duri dalle esecuzioni di cloud di calcolo di prova (che potrebbero eventualmente diventare hardware acquistato), rispetto a un'idea del prezzo più alto e del rischio molto più elevato dello sforzo FPGA .

— Chris Stratton,