[Questo post nasce da una serie di precisazioni formulate dall'amico Gianfranco a margine del mio precedente post dedicato, tra l'altro, alla lezione sulle FPGA tenuta da Nico Palermo al decimo convegno sulla radio digitale di Renon, il 4 e 5 ottobre 2008. Gianfranco ha rilevato alcune imprecisioni di natura terminologica che questo nuovo intervento cerca di risolvere. Sentitevi liberi di scrivermi o di commentare direttamente per segnalare eventuali nuove imprecisioni.]
Ho ricevuto dall'amico Gianfranco una serie di precisazioni terminologiche che mi sento in dovere di riportare perché in queste cose la terminologia è tutto e io mi rendo conto di averla utilizzata un po' a vanvera in un mio post recente. Spero questa volta di riuscire a interpretare bene le osservazioni di Gianfranco, che giustamente rileva come la "logica programmata" è quella dei processori che programmiamo attraverso un linguaggio. Un processore è un circuito logico molto complesso che il programmatore governa attraverso un set di istruzioni di livello molto evoluto. A livelli molto inferiori troviamo sì delle funzioni implementate con "porte logiche" , ma per certi versi quando programmiamo non ce ne accorgiamo neppure, o comunque non dobbiamo pensarci troppo, avendo come strumenti di base delle istruzioni predefinite. Quando si ha a che fare con un componente come le FPGA, si finisce invece per lavorare direttamente con dei circuiti elettrici, le porte logiche; anzi con una lavagna vergine di celle tutte uguali che permettono di implementare le operazioni dell'aritmentica binaria. La lavagna ci dà in più la possibilità di effettuare delle connessioni tra queste celle. Quando "programmiamo" una FPGA in realtà programmiamo le connessioni (dentro le FPGA moderne in realtà ci sono anche altre cose che ci aiutano a ottimizzare il numero di porte impegnate e a facilitare operazioni binarie di un certo tipo). L'alternativa alla FPGA, la cui logica, dice giustamente Gianfranco, è "cablata" *non* "programmata" (la logica programmata è quella del firmware eseguito da un microcontrollore) è un circuito specializzato che dobbiamo progettare ex novo con le porte logiche che vogliamo.
Perché ce bisogno di questa logica dedicata? Perché ci sono operazioni di trattamento numerico del segnale che i processori o i controllori programmabili - con il loro set di istruzioni predeterminato - non potrebbero eseguire o che riuscirebbero a eseguire in tempi troppo lunghi. Da cui la necessità di mettere insieme, con l'elettronica, dei circuiti molto mirati e ottimizzati, con dentro solo le operazioni necessarie. In un certo senso è come se dovessimo implementare i nostri algoritmi con un set di istruzioni che dobbiamo definire noi, non il chi ha progettato il microprocessore. E qui cominciano i problemi, perché se dovessimo implementare le stesse operazioni con dei singoli circuiti integrati non la finiremmo più e occuperemmo un mare di spazio; e se dovessimo progettare un unico circuito integrato complesso e specializzato ("application specific") ci costerebbe troppo: la FPGA è una straordinaria scorciatoia perché la sua matrice di porte ("gate array") vergine può diventare - attraverso un tipo di "programmazione" basato su linguaggi dichiarativi molto particolari - un circuito di porte logiche capace di eseguire esattamente le operazioni che vogliamo eseguire e solo quelle (la bravura di chi "programma" la logica cablata sta nell'ottimizzare l'uso delle celle, cioè nel realizzare con dieci o cento celle ciò che una programmazione meno intelligente realizzerebbe con mille o diecimila celle. Se poi riuscissi a individuare un potenziale di mercato sufficiente potrei anche tentare di investire un sacco di soldi per passare dalla FPGA a un integrato specifico, ma questo a livello amatoriale non può succedere così facilmente.
La distinzione tra hardware e software, come vedete, diventa molto sottile. Una software defined radio è "software" perché la demodulazione, l'estrazione delle informazioni di un segnale viene eseguita dal microprocessore del computer. Ma la FPGA che effettua la downconversion del segnale analogico acquisito numericamente, è a tutti gli effetti un circuito elettrico, un hardware molto specializzato che opera in regime non lineare (a differenza di un transistor che amplifica un segnale analogico) ed esegue operazioni in aritmetica binaria. E' vero che per programmare la FPGA, per trasformare la lavagna vergine della FPGA in una serie di operazioni svolte su operandi binari, vengono utilizzati dei linguaggi ma una volta "cablata" la nostra logica, il lavoro di fatto viene svolto da circuiti elettrici, non da un computer che esegue un programma. L'algoritmo è fisicamente rappresentato dai circuiti. Sono questioni di natura anche epistemologica che rendono ancora più affascinanti certi discorsi. Chiunque voglia contribuire, anche correggendo questa mia correzione, è caldamente invitato a farlo.
Ho ricevuto dall'amico Gianfranco una serie di precisazioni terminologiche che mi sento in dovere di riportare perché in queste cose la terminologia è tutto e io mi rendo conto di averla utilizzata un po' a vanvera in un mio post recente. Spero questa volta di riuscire a interpretare bene le osservazioni di Gianfranco, che giustamente rileva come la "logica programmata" è quella dei processori che programmiamo attraverso un linguaggio. Un processore è un circuito logico molto complesso che il programmatore governa attraverso un set di istruzioni di livello molto evoluto. A livelli molto inferiori troviamo sì delle funzioni implementate con "porte logiche" , ma per certi versi quando programmiamo non ce ne accorgiamo neppure, o comunque non dobbiamo pensarci troppo, avendo come strumenti di base delle istruzioni predefinite. Quando si ha a che fare con un componente come le FPGA, si finisce invece per lavorare direttamente con dei circuiti elettrici, le porte logiche; anzi con una lavagna vergine di celle tutte uguali che permettono di implementare le operazioni dell'aritmentica binaria. La lavagna ci dà in più la possibilità di effettuare delle connessioni tra queste celle. Quando "programmiamo" una FPGA in realtà programmiamo le connessioni (dentro le FPGA moderne in realtà ci sono anche altre cose che ci aiutano a ottimizzare il numero di porte impegnate e a facilitare operazioni binarie di un certo tipo). L'alternativa alla FPGA, la cui logica, dice giustamente Gianfranco, è "cablata" *non* "programmata" (la logica programmata è quella del firmware eseguito da un microcontrollore) è un circuito specializzato che dobbiamo progettare ex novo con le porte logiche che vogliamo.
Perché ce bisogno di questa logica dedicata? Perché ci sono operazioni di trattamento numerico del segnale che i processori o i controllori programmabili - con il loro set di istruzioni predeterminato - non potrebbero eseguire o che riuscirebbero a eseguire in tempi troppo lunghi. Da cui la necessità di mettere insieme, con l'elettronica, dei circuiti molto mirati e ottimizzati, con dentro solo le operazioni necessarie. In un certo senso è come se dovessimo implementare i nostri algoritmi con un set di istruzioni che dobbiamo definire noi, non il chi ha progettato il microprocessore. E qui cominciano i problemi, perché se dovessimo implementare le stesse operazioni con dei singoli circuiti integrati non la finiremmo più e occuperemmo un mare di spazio; e se dovessimo progettare un unico circuito integrato complesso e specializzato ("application specific") ci costerebbe troppo: la FPGA è una straordinaria scorciatoia perché la sua matrice di porte ("gate array") vergine può diventare - attraverso un tipo di "programmazione" basato su linguaggi dichiarativi molto particolari - un circuito di porte logiche capace di eseguire esattamente le operazioni che vogliamo eseguire e solo quelle (la bravura di chi "programma" la logica cablata sta nell'ottimizzare l'uso delle celle, cioè nel realizzare con dieci o cento celle ciò che una programmazione meno intelligente realizzerebbe con mille o diecimila celle. Se poi riuscissi a individuare un potenziale di mercato sufficiente potrei anche tentare di investire un sacco di soldi per passare dalla FPGA a un integrato specifico, ma questo a livello amatoriale non può succedere così facilmente.
La distinzione tra hardware e software, come vedete, diventa molto sottile. Una software defined radio è "software" perché la demodulazione, l'estrazione delle informazioni di un segnale viene eseguita dal microprocessore del computer. Ma la FPGA che effettua la downconversion del segnale analogico acquisito numericamente, è a tutti gli effetti un circuito elettrico, un hardware molto specializzato che opera in regime non lineare (a differenza di un transistor che amplifica un segnale analogico) ed esegue operazioni in aritmetica binaria. E' vero che per programmare la FPGA, per trasformare la lavagna vergine della FPGA in una serie di operazioni svolte su operandi binari, vengono utilizzati dei linguaggi ma una volta "cablata" la nostra logica, il lavoro di fatto viene svolto da circuiti elettrici, non da un computer che esegue un programma. L'algoritmo è fisicamente rappresentato dai circuiti. Sono questioni di natura anche epistemologica che rendono ancora più affascinanti certi discorsi. Chiunque voglia contribuire, anche correggendo questa mia correzione, è caldamente invitato a farlo.
4 commenti:
visto che c'e' la disponibilita' di esperti, posso fare invece una domanda da Pierino ?
Che cosa impedisce con le FPGA di fare anche la demodulazione oltre alla conversione ?
Cosi' la radio digitale ce la "programmiamo" in casa ... se aspettiamo gli ASIC di ST o chi altri stiamo freschi :-)
Al di là del non trascurabile aspetto della capacità di programmare una FPGA, non è un percorso così immediato. Questa è la prima domanda che abbiamo posto a Nico alla fine della sua lectio magistralis. Ci sono problemi di natura algoritmica, per cui implementare processi di demodulazione in logica cablata può essere molto dispendioso e banali problemi di spazio. Le FPGA costano e consumano corrente, si possono utilizzare quando ciò rientra in un budget complessivo. E poi c'è il banale problema delle dimensioni dell'array. Per quanto ottimizzato sia il "codice" (anche qui uso il termine con le molle) FPGA del Perseus, le celle sono in numero finito e alcune di esse ovviamente sono state utilizzate per la downconversion.
Se la domanda è: riusciremo mai ad avere radio digitali indipendenti dal pc? la risposta è sì, ci si riesce già adesso con le radio DAB. Ma anche nei piccoli volumi che ci interessano le FPGA potrebbero essere proibitive o complessivamente più onerose rispetto, poniamo, a un normale processore programmabile, magari dedicato al DSP (quindi con le istruzioni e i registri adatti)
Si Andrea , se può aiutare, si può aggiungere, estremizzando il concetto tra logica cablata e programmata che :
Coloro che “smanettano” sul SW senza cognizione di un programma, non potranno mai distruggere l’HW di un PC o il microcontroller. Al massimo Il PC si blocca e resettando è nuovo come se nulla fosse stato fatto.
Coloro invece che “smanettano “ sul SW di una FPGA, possono distruggere il componente.
Se poi l’FPGA è su un package BGA ( Ball Grid Array ) il povero sperimentatore dilettante può gettare tutto l’oggetto che ha acquistato.
Essendo logica cablata l’assorbimento e quindi la temperatura del componente dipende dalla quantità di celle che lavorano alle piu alte frequenze alte. Non è molto difficile distruggere l’FPGA da chi non si sa muovere con padronanza HW e SW..
Esempio, se l’incauto sperimentatore alterasse i sorgenti del SW della FPGA in modo tale di interconnettere centinaia di celle che erano progettate esempio per una frequenza di Clock minima ad una frequenza di Clock molto alta . L’FPGA aumenta la potenza dissipata ,sale di temperatura rapidamente ,distruggendosi .
Che ha progettato l’apparecchio ha dimensionato il raffreddamento in base alla potenza assorbita dal dispositivo che era funzione del suo progetto di logica cablata.
Come vedi è molto di più di una differenza epistemologica.
Grazie per le bellissime discussioni nella due giorni di Renon
Gianfranco Verbana
Grazie a te. Avevo infatti concluso il post scrivendo che nella sottile distinzione tra hardware e software si può porre *anche* una questione epistemologica. Quello che scrive Gianfranco sull'aspetto della "reversibilità" è un punto importantissimo. Sarebbe errato presumere che essendo l'FPGA equiparabile a un concetto di lavagna vergine, la riscrittura di una implementazione errata possa essere del tutto triviale. Per le ragioni che ha sapientemente evidenziato Gianfranco, non è affatto così. Un software sbagliato si limita a non produrre il risultato voluto. Se l'errore è sintattico, si può arrivare al reset del sistema operativo o del processore. Quello che otteniamo in una FPGA, una volta "cablata" la nostra logica, è un circuito che deve rispettare anche precisi criteri di carico e dissipazione, non solo essere coerente con l'aspetto algoritmico.
Posta un commento