bibo01 ha scritto:Caro phaeton (non ironico)
.............................
In definitiva, un FPGA può avere anche un'elevata capacità di calcolo a virgola mobile (tipo il Virtex-7 sopracitato), ma qui non si sta parlando solo di multiplicazioni-addizioni, ma di sen, cos, log, ecc...o XY per numeri complessi... Ti voglio vedere il tempo necessario ad implementare delle funzioni trigonometriche in hardware!
Inoltre, non si parla di farlo off-line, bensì di farlo on-the-fly, in modo asincrono e in maniera distribuita. Addirittura potrebbe essere eseguito in cloud, ma sempre on-the-fly.
vabbe', la vediamo in modo diverso... pazienza, non finisce il mondo per questo e amici come prima!!
mi preme solo sottolineare una cosa: io non ho MAI detto di voler portare un programma complesso come HQP su fpga.... io ho solo detto che le funzioni tipiche di filtro (oversampling, passaggio in dsd, poco altro) sono fatte molto meglio in fpga.....
solo un paio di note (lo so, sono un fottuto ingegnere pedante)
- un FIR adattativo e' implementabile a parita' di struttura, basta modificare i pesi. se invece cambia la struttura occore una riprogrammazione, con una FPGA e' abbastanza semplice ma e' vero che con un DSP ci sono vari da problemi da affrontare per farla real time, non tutti risolvibili. pero' qui mi pareva che stavamo parlando di filtri e/o in generale un algoritmo da applicare ad uno stream di dati. se invece parliamo di una cosa piu' complessa allora sono il primo a dire che una fpga non va bene.
- algebra lineare: e' per questo che sono nati DSP e FPGA!!!!!! in pratica puoi realizzare in hw qualunque algoritmo di algebra lineare (+,-,*,/ e anche pot,sqrt nei chip migliori) in modalita' mimd, molto ma molto piu' velocemente di qualunque cpu.
- calcoli trigonometrici: sono un problema, cosi' come per le cpu general purpose. vengono risolti con una serie di calcoli fp, che una fpga o un dsp possono fare molto piu' velocemente
- riprogrammare al volo: vedi sopra, mi pareva si stesse parlando di un algoritmo da applicare ad uno stream. in ogni caso, parli di riscrittura online del codice macchina? cioe', mi stai dicendo che ci sono sw per uso audio che adottano tecniche di riscrittura online del codice in esecuzione? la vedo piuttosto complicata, per farlo il codice (user) dovrebbe accedere ad aree di ram protette dall'OS (kernel), e inoltre si manderebbe a donnine allegre tutta la ottimizzazione hw delle cache. se invece parli di semplice polimorfismo, qualunque algoritmo, di qulunque complessita', puo' essere portato in FPGA o DSP, anche se usa overloading o polimorfismo (anche se e' un po' piu' complesso).
- ram/cache: vero, c'e' tipicamente poca memoria nei DSP. pero' e' per latenza simile ai registri della cpu, ovvero e' piu' veloce di una L1, non parliamo neppure delle L2 o L3. inoltre le finestre di calcolo real time tipicamente non sono enormi, e i dati sono caricati in modalita' streaming. anche qui mi rifaccio a quanto gia' detto: io parlo di un algoritmo, non di un programma complesso che fa un full scan dei dati in ram......
- vedere un album intero: ??? mi stai dicendo che per fare una operazione real time hai bisogno di caricare in ram l'intero album? per definizione questa non e' una operazione real time, anche se la fai online. inoltre mi sfugge il motivo di fare una cosa del genere, qualuqnue sia il filtro da applicare, a meno che, ancora una volta, stai parlando di cosa diversa da un algoritmo (ovvero ad esempio vuoi calcolare l'RMS dell'album per poi applicare qualche forma di normalizzazione...)
- non mi e' chairo il discorso "l'upsampling è timeless".....
- core i7: i 4 core "ad alta velocita'" fanno molto altro che non solo l'algoritmo da applicare. anche se "snellito", l'OS c'e' sempre. inoltre sono core generici, che possono al massimo fare operazioni simd e sempre utilizzando il modulo fp del core, vai a vedere quanti cicli macchina occorrono per fare una fdiv, non parlaimo poi di un log. inoltre non essendo una struttura intrinsecamente matriciale come appunto una FPGA, hai tutte le lentezze di un sistema seriale. le cache "ad alta velocita'" hai presente che latenza hanno rispetto ai core? non c'e il minimo paragone con la velocita di un registro (che sia fpga o cpu)
- il flac e' sempre decodato dal pc, non ho mai detto di volerlo fare con la fpga...
- discorso flessibilita' e costi: si, in generale sono del tutto d'accordo. DSP e ASIC sono molto "limitati", FPGA e' un po' piu' flessibile, ma ovviamente non si raggiungera' mai una cpu. anche i costi di sviluppo sono piu' alti, basilarmente perche' e' molto piu' complesso creare e manutenere il codice. pero' IMHO i vantaggi, nel caso specifico (ovvero realizzazione di un algoritmo audio) superano di molto le limitazioni.
- VHDL: ??? non serve, anche perche' cosi' fai un hard-coding. non devi progettare un ASIC, devi solo convertire gli algoritmi usati dal programma in una matrice che puo' essere interpretata da una FPGA. non serve VHDL o Verilog, basta un minimo di pazienza....
- 16 Ms a 64b su 8 canali: ??????????? cioe', HQP lavora su finestre di 16 milioni di samples per otto canali indipendenti? cavoli, neppure il mio oscilloscopio digitale ha una finestra simile..... il peggiore stream audio che puo' capitare e' il dxd, 352ks per sec a 24b. tralasciando la profondita' del dato, vuol dire che nel peggiore dei casi HQP ha una finestra del filtro pari a 45s..... per un "semplice" 44ks siamo a 363s
diamine, per segnali audio mi sfugge veramente l'utilita' di una tale finestra......... pero' se e' cosi', allora sono d'accordo, sarebbe praticamente impossibile farlo con una fpga, non tanto per l'elaborazione quanto per la ram.
- funzioni complesse in hw: come gia' detto, e' la stessa identica cosa per la cpu, nessuna cpu general purpose ha una FPU in grado di processare nativamente funzioni complesse, sono sempre risolte con delle approssimazioni successive fatte con fdiv e fmul. tieni conto che ci sono svariati esempi di fpga utilizzate per filtri oversampling anche molto complessi e ad altissima velocita' (1.5MHz a 32b ad esempio nell'Auralic, con varie tipologie di filtro applicabili real time - cioe' con riprogrammazione real time della fpga - con finestre di circa 6s... e gli avanza pure capacita' di calcolo per realizzare il controller USB.....)
ops, mi sa che ho scritto troppo, volevo solo fare qualche nota a latere.... sorry...
again, non credo ci sia giusto o sbagliato, semplicemente la vediamo in modo diverso....
pace e bene!!!!!