Linux & FPGA: un connubio perfetto

Linux FPGA

Se siete alla ricerca di un Sistema Embedded open-source che comprenda: un File System, una connettività LAN con Stack IP, una memoria RAM di decine o centinaia di Megabyte, una gestione Multi-Task degli applicativi e prestazioni computazionali di alto livello, allora la vostra scelta potrebbe ricadere su di un modulo Embedded Linux tra quelli disponibili in commercio. Se, inoltre, desiderate sviluppare applicazioni Audio, Video, Radio o altro genere di funzioni strettamente Real-Time, allora questo articolo potrà esservi di aiuto.

 

Che il Kernel Linux sia un prodotto open-source Word Class è ormai un dato di fatto: dai Server Web, all’ultimo SmartPhone, passando per una miriade di applicazioni industriali e domotiche, probabilmente, nelle vostre giornate c’è più Linux di quanto possiate immaginare!

Tuttavia, Linux non è un RTOS (Real Time Operating System – http://it.wikipedia.org/wiki/Sistema_operativo_real-time), almeno nella sua versione “main-stream”, e ciò comporta delle scelte progettuali mirate a mitigare o colmare, questa lacuna.

Personalmente, ritengo che il modo più flessibile e performante, per ovviare a tale inconveniente, sia quello di posizionare un FPGA (Field Programmable Gate Array – http://it.wikipedia.org/wiki/FPGA) in stretto contatto con il Sistema Operativo.

L’utilizzo di tali dispositivi hardware, completamente configurabili mediante codice utente (VHDL e/o Verilog), coniuga il meglio di due mondi complementari:

  • la progettazione circuitale tipica dell’ hardware
  • la metodologia di sviluppo del software

In altri termini, potrete realizzare il vostro schema elettronico …senza effettuare neppure una saldatura e, se qualche cosa non funziona correttamente, grazie all’uso di un simulatore, apportare tutti quei progressivi miglioramenti, fino al raggiungimento di uno schema funzionale ottimale.

Infatti, il flusso tipico di sviluppo di un FPGA è:

  • Codifica HDL o mediante tool Schematici CAD/CAE
  • Simulazione comportamentale
  • Place-and-route con applicazione dei constraint (fase equivalente al classico “sbroglio” del PCB)
  • Simulazione di post-layout (raccomandata, non sempre indispensabile)
  • Download del bitstream
  • Validazione in-circuit

Al termine della fase di design, potrete salvare il bitstream nella PROM di configurazione dell’FPGA o nel File System di Linux, quando necessaria la riconfigurazione dinamica o l’aggiornamento remoto del firmware FPGA.

*-*-*

In questo articolo vedremo alcuni casi d’uso che sono stati da me affrontati nella realizzazione di un progetto sperimentale riguardante l’acquisizione di immagini da un Sensore Video CMOS (es. la classica fotocamera di un cellulare), la generazione di messaggi audio o musicali, e per finire la Radio Trasmissione diretta in banda LF-HF (o banda-base se si utilizza un up-converter) di un pattern video-grafico, mediante l’utilizzo di un Oscillatore a Controllo Numerico (NCO) modulato in FSK (Frequency Shif Keying).

Iniziamo da una fotografia dell’intero sistema, così come assemblato nel prototipo:

 

Vista d’assieme.

 

In alto a sinistra troviamo il sensore video (Image Sensor) ed il relativo obiettivo C-Mount che ne determina il campo inquadrato, il punto focale e la luminosità. Il sensore è racchiuso in una “camera oscura”, ma nella seguente foto è possibile osservare direttamente il chip. Si tratta dell’LM9627 (un sensore prodotto dalla Kodak …azienda ormai estinta!).

 

Sensore LM9627 montato su di un PCB fai-da-te in foto-incisione.

 

Tornando alla foto del sistema, in alto a destra è posizionata la scheda FPGA. Il dispositivo utilizzato appartiene alla serie Xilinx Spartan-II, ma gran parte delle funzionalità sono state già verificate anche su Spartan-3/6 e Virtex-4/5. Con ciò intendo sottolineare che un progetto HDL (Hardware Description Language) può agevolmente migrare da una serie all’altra, anche di differenti costruttori (il progetto in esame è stato comunque sviluppato completamente in VHDL, linguaggio da me preferito).

Su tale scheda, trova posto anche una memoria RAM Statica con tempo di accesso di 10nS, la PROM contenente il bitstream di configurazione dell’FPGA, più alcuni circuiti di supporto.

In basso a destra è posizionala la scheda Embedded Linux. Si tratta di un modulo prodotto dalla Taskit tedesca (http://www.taskit.de), denominato PortuxG20 (nella sezione Linux del Blog ho già inserito alcuni articoli su tale scheda e quindi vi rimando ad essi per ulteriori approfondimenti).

La scheda Linux è direttamente connessa alla scheda FPGA, mediate un bus parallelo asincrono a 8 bit. Tale bus è stato implementato mediante GPIO (General Purpose Input/Output), gestito con apposite funzioni presenti nell’applicazione [es. fpga_read(‘register’), fpga_write(‘register’, ‘value’)] e, pertanto, indipendente dalla specifica configurazione hardware del modulo Linux. Nota: per applicazioni a larga banda è necessario interfacciare direttamente il bus del microprocessore.

 

Diagramma delle connessioni tra la scheda Linux e la scheda FPGA.

 

Per finire, in basso a sinistra troviamo il Display TFT a colori, equipaggiato con Touch Screen resistivo. Tale display è gestito mediante una CPU con core ARM Cortex-M3. La scheda viene prodotta dalla Texas Instruments con il codice MDL-IDM-L35 (rimando al link per maggiori info: http://www.ti.com/tool/mdl-idm-l35).

 

Diagramma delle connessioni tra la scheda Linux e la scheda Display.

 

Diamo ora un sguardo allo Schema a Blocchi dell’intero sistema:

 

Diagramma a blocchi del sistema Linux Image Sensor Processor.

 

Come potete osservare tutte le interfacce high-speed afferiscono al blocco FPGA. Questo componente gioca un ruolo chiave. Vediamo perché, esaminando la logica di funzionamento punto per punto:

  • Il sensore di immagine LM9627, una volta configurato mediante bus I2C, inizia a generare il flusso dati relativo alla matrice APS (Active Pixel Sensor), mediante un bus parallelo a 12bit corredato di segnali di sincronismo verticale e orizzontale (Vsync, Hsync). La quantità di word-12bit prodotta per ciascun secondo è: 664x504x30 …circa 10 Mega-word al secondo!!!

 

Anche il serializzatore I2C è stato implementato in VHDL. Pur non essendo un blocco ad alta velocità, è risultato utile inserirlo nel design FPGA.

  • I dati relativi all’immagine sono strettamente correlati al clock del sensore (CLK=48MHz) e ai sincronismi video.
  • Occorre acquisire un video-frame alla volta, processarlo (es. scalarlo da 640×480 a 320×240, estraendone le componenti colore sottocampionate in base allo schema 4:2:2), visualizzarlo e, poi, ripetere il ciclo per la successiva immagine. Inoltre, durante l’operazione di acquisizione video, è necessario gestire i comandi dell’utente (in locale, mediante Touch Screen; in remoto, mediante Internet/Intranet).
  • Al termine dell’acquisizione deve essere possibile inviare l’immagine processata ad un sistema remoto. La trasmissione può avvenire mediante la porta eth0 (direttamente gestita dallo Stack IP di Linux) oppure mediante la modulazione di un oscillatore a controllo numerico, implementato nell’FPGA con una ROM contenente una funzione sin(x) da 512 campioni di 8bit.
  • L’oscillatore a controllo numerico, utilizza un Accumulatore di Fase a 32bit, con clock di campionamento di 96 MHz derivato dall’oscillatore di sistema (48 MHz) e processato da un blocco DLL (Delay-Locked Loop) presente nella libreria Spartan. La ROM contenente la funzione sin(x) è direttamente indirizzata dall’Accumulatore di Fase e può generare uno stream numerico con frequenza compresa tra 0.02 Hz e 30 MHz. Lo stream è sincronizzato con un DAC (Digital to Analog Converter) per ottenere, finalmente, il segnale analogico sinusoidale in uscita.

 

L’Oscillatore sinusoidale a Controllo Numerico (NCO) può essere agevolmente implementato mediante un blocco RAMB512x8 disponibile nella libreria Spartan.

  • I file audio, memorizzati in un area del File System, sono in formato raw, cioè non compresso (.wav) e contengono i campioni PAM (Pulse Amplitude Modulation) a 16bit, stereo o mono. La frequenza di campionamento può essere anche superiore ai classici 44.1KHz (qualità CD) e, durante la fase di riproduzione, è necessario che tale frequenza sia mantenuta stabile il più possibile, affinché il DAC Audio possa ricostruire il segnale originale senza distorsioni apprezzabili. Anche questo è un compito delicato!

 

Il progettista osserva perplesso alcuni Bad-Pixel.

Nota: Questi sensori vengono normalmente spediti con alcune non-conformità nelle caratteristiche di un limitato numero di Pixel …i cosiddetti Bad-Pixel.

 

  • La correzione dei Bad-Pixel, generalmente presenti in diversa misura su tutti i sensori, è un task che dovrebbe essere effettuato “al volo” durante l’acquisizione del video-frame. Alcuni sensori, compreso LM9627, mettono a disposizione un blocco funzionale interno dedicato a tale operazione. In alternativa occorre implementare un filtro numerico adeguato.
  • Il bilanciamento cromatico, cioè la regolazione fine del guadagno per i singoli canali Red, Green e Blu, rappresenta un task ad elevata intensità computazionale, se affidato alla CPU del sistema. Non tutti i sensori rendono disponibile la regolazione indipendente dei tre canali e, quindi, essa deve avvenire in forma numerica e preferibilmente nell’FPGA.
  • L’aggiunta di stringhe alfanumeriche (es. Data e Ora), l’applicazione di effetti video-grafici e/o di compressione, rappresentano un ulteriore ambito applicativo per l’FPGA.

Come avrete potuto constatare, nei precedenti punti vi sono già molte ragioni che ci obbligano ad un approccio strettamente Real-Time. La gran parte delle funzionalità elencate risulterebbero non fattibili con l’impiego di un “semplice” microprocessore o microcontrollore. L’utilizzo, quindi, di circuiti hardware custom, se pure totalmente configurabili, aggiunge un grado di liberà al design che non trova eguali se non nel ricorso a costosi ASIC (Application Specific I.C.) o Video Processori dedicati.

Per concludere, è bene ricordare che l’implementazione di un File System, un Stack IP e di un Kernel Linux, non rappresentano il territorio ideale per il mondo FPGA (anche se esistono implementazioni di System On Programmable Chip che ne dimostrano la piena fattibilità su dispositivi di fascia alta) e che, quindi, la stretta integrazione tra i due domini risulta estremamente vantaggiosa per applicazioni professionali, anche di costo contenuto e per un’ampia varietà di usi (Slow-scan Television, IP Camera, Video Sorveglianza, Audio-Video Player, ecc.).

*-*-*

Vi invito a guardare il sistema nel suo funzionamento, mediante questi due video amatoriali tratti dal mio canale YouTube.

 

Parte 1 – Embedded Linux Image Sensor Processor 

Parte 2 – Embedded Linux Image Sensor Processor 

Tutto il codice sorgente, gli schemi a blocchi ed esecutivi, saranno resi disponibili per coloro che vorranno proseguire con me nello sviluppo di queste meravigliose tecnologie e creare un prodotto open-source!

Potete contattarmi tramite i commenti.

Grazie e a presto,

Ciro.

 

Quello che hai appena letto è un Articolo Premium reso disponibile affinché potessi valutare la qualità dei nostri contenuti!

 

Gli Articoli Tecnici Premium sono infatti riservati agli abbonati e vengono raccolti mensilmente nella nostra rivista digitale EOS-Book in PDF, ePub e mobi.
volantino eos-book1
Vorresti accedere a tutti gli altri Articoli Premium e fare il download degli EOS-Book? Allora valuta la possibilità di sottoscrivere un abbonamento a partire da € 2,95!
Scopri di più

10 Comments

  1. Piero Boccadoro Piero Boccadoro 5 febbraio 2013
  2. Emanuele Emanuele 5 febbraio 2013
  3. Ciro Tranchino 5 febbraio 2013
  4. Andres Reyes Andres Reyes 5 febbraio 2013
  5. Andres Reyes Andres Reyes 5 febbraio 2013
  6. Boris L. 5 febbraio 2013
  7. Boris L. 6 febbraio 2013
  8. Giorgio B. Giorgio B. 9 febbraio 2013
  9. giuseppeIng84 14 luglio 2014
  10. Tiziano.Pigliacelli Tiziano.Pigliacelli 24 luglio 2014

Leave a Reply