La gestione di un sensore d’immagine CMOS

L’articolo tratta le possibili alternative a disposizione di un progettista per realizzare un'interfaccia verso un sensore d’immagine CMOS. In questa seconda parte ci si occuperà dell’interfaccia tra sensore e logiche programmabili mettendo in evidenza i pregi e i difetti di una soluzione di questo tipo.

La prima parte di questo articolo esaminava la possibilità di realizzare un interfaccia verso un sensore d’immagine CMOS utilizzando microcontrollori dotati di un interfaccia diretta verso il sensore. L’altra possibile alternativa per realizzare un’interfaccia ad alta velocità, in grado di catturare i dati provenienti dal sensore CMOS, è utilizzare logiche programmabili o ASIC (Application Specific Integrated Circuit), realizzare quella che viene definita una “glue logic” ossia una logica che basandosi sulle caratteristiche del sensore permetta di sfruttarlo a pieno.

Perché  scegliere  una  logica “customizzabile”?

Scegliere un ASIC o una logica programmabile per realizzare un’interfaccia diretta al sensore CMOS significa in molti casi arrivare ad ottenere delle prestazioni superiori rispetto alla semplice interfaccia con un microprocessore. Si pensi, per esempio, ad uno dei fattori determinanti per quel che riguarda la velocità d’acquisizione ossia il clock fornito al sensore genericamente chiamato in precedenza pixel clock (parte I  dell’articolo). Dal pixel clock dipende la durata del frame, quindi anche il  tempo necessario per avere a disposizione l’immagine e di conseguenza il numero d’immagini che possono essere prelevate in un secondo. Molto spesso è il sensore  CMOS che introduce il vincolo  sul massimo valore di pixel clock tollerabile. Nel caso si realizzi un’interfaccia utilizzando un microprocessore la periferica dedicata alla gestione del sensore CMOS viene comunemente classificata ad “alta velocità”, così come il gestore della memoria e l’interfaccia LCD. Il fatto che tutte queste periferiche appartengano allo stesso gruppo significa che utilizzano un clock comune che, in alcuni casi, può essere solamente diviso per 2 o per 4 e che raramente arriva a sfruttare al massimo le potenzialità del sensore CMOS. Si può comprendere bene quest’aspetto con un esempio, se un processore accede alla memoria SDRAM con un clock di 96MHz al sensore possono essere forniti o 48 o 24MHz (supponendo una divisione per 2 o per 4). Se il sensore in esame supporta un pixel clock limite di 27MHz, chiaramente non lo stiamo sfruttando al massimo. Un ASIC o una logica programmabile sia essa FPGA o CPLD è tipicamente dotata di uno o più PLL interni che permettono di generare clock d’uscita praticamente a qualsiasi frequenza risolvendo il  problema evidenziato in precedenza. In figura 1 è rappresentato schematicamente  il collegamento tra sensore CMOS e logica programmabile.

Figura 1: collegamento tra sensore d’immagine CMOS e logica programmabile

Figura 1: collegamento tra sensore d’immagine CMOS e logica programmabile

Uno degli aspetti principali che orienta le preferenze dei progettisti verso le “glue logic” preferendole alle CPU dedicate, è dovuto al fatto che queste possono lavorare a velocità elevata, catturare tutti i frame del sensore e renderli disponibili in memoria senza l’intervento del microprocessore. Tutto questo significa risparmiare la potenza di calcolo del processore per altre applicazioni e un possibile ridimensionamento verso il basso di specifiche e costo della CPU.

ASIC o logica  programmabile?

Il dubbio del progettista in questi frangenti è spesso scegliere tra la realizzazione di un ASIC o l’utilizzo, per esempio, di una FPGA o di una CPLD. La sigla ASIC è l’acronimo di Application Specific Integrated Circuit, ossia un circuito integrato progettato per applicazioni specifiche piuttosto che per una funzionalità generica. Gli ASIC sono attualmente considerati come una tecnologia in grado di garantire performance elevate dal punto di vista dei consumi energetici e della velocità d’elaborazione,  tuttavia il processo di sviluppo e produzione è estremamente costoso. Gli alti costi determinano l’utilizzo degli ASIC solamente per produzioni in volumi elevati, specifica questa non sempre presente tra i  requisiti di progetto. Gli FPGA (Field Programmable Gate Array) sono una sorta di compromesso tra la progettazione completamente personalizzata di ASIC e le prestazioni offerte dalla tecnologia disponibile sul mercato delle logiche programmabili. Una FPGA è un dispositivo digitale la cui funzionalità è programmabile via software, solitamente per lo sviluppo si utilizza il  linguaggio VHDL o VERILOG, entrambi sono abbastanza complessi e non sempre graditi ai progettisti di sistemi embedded. Le FPGA sono dei dispositivi “RAM based” ossia basate su memoria volatile, ad ogni power-up del sistema necessitano di essere riprogrammate. Le CPLD (Complex Programmable Logic Device) al contrario sono dispositivi “Flash based”, basati su memoria non volatile che impedisce la perdita della programmazione in assenza della tensione d’alimentazione. Seppur per molte applicazioni l’utilizzo di una FPGA o di una CPLD sia equivalente, a parità di logica, la CPLD è più costosa e viene spesso realizzata in tagli di dimensione ridotta, adatti per applicazioni generalmente dedicate all’interfacciamento tra due dispositivi complessi. FPGA e CPLD offrono la possibilità di una progettazione dedicata e personalizzabile, in più sono riconfigurabili perciò si evitano gli elevati costi di realizzazione che limitano lo sviluppo degli ASIC. In figura 2 viene schematizzato il flusso di progetto per la realizzazione di un ASIC, mettendo in evidenza gli step non necessari se invece si utilizza una FPGA.

Figura 2: flusso di progetto per la realizzazione di un ASIC.

Figura 2: flusso di progetto per la realizzazione di un ASIC.

Dopo questa premessa la domanda, cosa è meglio? La risposta non è sempre banale ma gli aspetti di cui si è discusso e riassunti in tabella 1 possono aiutare il progettista a fare una scelta mirata.

Tabella 1: Confronto tra ASIC e FPGA

Tabella 1: Confronto tra ASIC e FPGA

Proprio perché una volta che il progetto è maturo gli ASIC non sono più modificabili i progettisti tendono ad acquistare IP (Intellectual Property) da integrare ampiamente testati e controllati. In questo modo si cerca di ridurre la possibilità d’errore penalizzando pero i costi del progetto. La caratteristica delle FPGA di poter essere riprogrammate in ogni fase dello sviluppo le rende invece una soluzione più flessibile e a basso costo. Se durante la progettazione sono richiesti cambiamenti nelle specifiche, negli algoritmi, o per una qualsiasi esigenza supplementare  è possibile farlo senza ritardare pesantemente il progetto. In più gli sviluppi tecnologici recenti hanno notevolmente incrementatole prestazioni delle FPGA riducendo il gap con gli ASIC. Un ultimo aspetto che può facilitare la scelta consiste nel valutare se in un sistema sono necessarie più funzionalità distinte che agiscono alternativamente, in questo caso la scelta di un dispositivo riprogrammabile è sicuramente la migliore. Variando
run-time la programmazione ma mantenendo un’unica unità d’elaborazione è possibile risparmiare spazio sulla scheda riducendo costi e consumi d’energia.

L’importanza di un progetto modulare

Realizzare l’interfaccia tra un sensore d’immagine CMOS e un qualsiasi circuito d’acquisizione dell’immagine (frame grabber) non è una cosa estremamente complessa. Una volta definite le caratteristiche del sensore e stabilite le modalità e il protocollo di comunicazione, non resta che passare alla progettazione.  Per garantire tuttavia che il progetto risulti robusto è bene considerare l’importanza di realizzare un progetto modulare. Solitamente un dispositivo che adotta un sensore d’immagine è costruito in maniera tale che il sensore, l’ottica e la relativa circuiteria elettronica dedicata siano collocati direttamente su una scheda che possiamo chiamare genericamente scheda sensore. L’elettronica destinata all’operazione di frame grabbing è invece sistemata su un’altra scheda elettronica, che possiamo genericamente chiamare d’acquisizione. Ovviamente tra la scheda sensore e la scheda d’acquisizione dovrà esserci necessariamente una comunicazione basata su un numero fisso di segnali stabiliti in fase di design. Come spesso accade però lo sviluppo di un prodotto e la sua stessa permanenza sul mercato devono scontrarsi con una serie di problematiche che ne richiedono la riprogettazione. Si pensi per esempio ad una possibile obsolescenza del sensore, visto gli attuali sviluppi di questo mercato non è facile prevedere la vita di un componente. Durante la stessa fase di sviluppo può capitare che le specifiche di progetto siano stravolte per esigenze commerciali, come potrebbe essere l’utilizzo di un sensore dotato di una maggiore risoluzione. La scelta della componentistica per la realizzazione della scheda e determinate precauzioni in fase di sviluppo possono essere determinanti per un prodotto. Tornando al nostro esempio della comunicazione tra scheda sensore e scheda d’acquisizione, la scelta di inserire una serie di segnali supplementari, anche se inutilizzati, potrebbe essere importante per non dover riprogettare entrambe le schede in seguito alla necessità di sostituire il sensore d’immagine. La possibile scelta di utilizzare una FPGA per l’interfaccia rappresenta una scelta d’elevata modularità, essendo questa riprogrammabile rende completamente modificabile la comunicazione tra scheda sensore e scheda d’acquisizione. L’aspetto appena citato non è da sottovalutare e può rappresentare uno dei punti chiave per la realizzazione di un buon progetto, bisogna sempre pensare al futuro o come dicono gli americani, think forward!

Progetto di una fotocamera digitale utilizzando una logica programmabile

Affrontiamo ora un semplice progetto di una fotocamera digitale. Scegliamo di utilizzare un sensore “intelligente”, un sensore equipaggiato anche con processore digitale di immagini in grado di elaborare i frame provenienti dal sensore e trasferirli secondo gli standard più diffusi. Utilizziamo come interfaccia per il sensore una CPLD della Xilinx, uno dei maggiori produttori di logiche programmabili, in particolare scegliamo un dispositivo CoolRunner-II. Decidiamo poi di visualizzare le immagini provenienti dal sensore su un display LCD. L’architettura del nostro sistema è quella schematizzata in figura 3.

Figura 3: schema a blocchi della fotocamera digitale

Figura 3: schema a blocchi della fotocamera digitale

Come sensore utilizziamo il MI-SOC-0343 un vecchio sensore prodotto dalla Micron Tecnology, ora il settore imaging dell’azienda ha cambiato nome diventando Aptina Imaging. Buona parte dei sensori CMOS attualmente commercializzati dalla Aptina e classificati come camera-on-chip derivano dal sensore preso in esame e con poche semplici modifiche possono essere impiegati in sostituzione. In figura 4 abbiamo lo schema a blocchi del sensore CMOS, si può vedere come sia presente la parte supplementare di IFP (Image Flow Processor) che permette di realizzare una serie di elaborazioni supplementari sull’immagine tra cui il bilanciamento dei bianchi, la regolazione dell’esposizione e la regolazione del colore.

Figura 4: schema a blocchi dell’MI-SOC-0343.

Figura 4: schema a blocchi dell’MI-SOC-0343.

Il sensore MI-SOC-0343 ha una risoluzione di 640x480 VGA è può arrivare fino a 30 frame per secondo. All’interno contiene una serie notevole di registri che consentono di programmare una infinità di parametri. La scrittura nei registri interni avviene  attraverso un interfaccia seriale molto simile ad una I2C chiamata SHIP (Serial Host interface Protocol) dove la CPLD è il dispositivo master. Per il progetto decidiamo di utilizzare un flusso di dati in formato 4:4:4 RGB565, il registro del sensore (IFP08) dovrà essere programmato in tal senso. La CPLD, per quel che riguarda la parte di acquisizione dal sensore dovrà essere organizzata come in figura 5.

Figura 5: schema a blocchi dell’interfaccia verso il sensore.

Figura 5: schema a blocchi dell’interfaccia verso il sensore.

La logica di controllo di alto livello non farà altro che prelevare  i dati dal sensore e trasferirli una volta completi al display LCD, la rappresentazione della macchina a stati che gestisce questa operazione è visibile in figura 6.

Figura 6: macchina a stati della logica di controllo

Figura 6: macchina a stati della logica di controllo

La parte sicuramente più interessante è la logica di controllo dell’image grabbing. Nel momento in cui termina la ricezione completa del frame avviene la sua memorizzazione nella memoria SRAM il flusso delle operazioni anche in questo caso è comandato da una macchina a stati. In figura 7 è rappresentato il flusso delle operazioni, una volta richiesta l’acquisizione del frame si passa dallo stato di IDLE a quello di attesa per un fronte di salita  del  segnale  di  frame  valid  (stato WAIT_FV).

Figura 7: macchina a stati della logica di image grabbing.

Figura 7: macchina a stati della logica di image grabbing.

Quando arriva il fronte di salita sul segnale di frame valid si attende quello di line valid (stato CAP_FV) per far partire l’acquisizione (CAP_LDATA e CAP_UDATA). La cattura dei dati viene interrotta temporaneamente quando line valid cambia stato ed in maniera definitiva quando frame valid ha un fronte negativo.  Sul sito sono disponibili  i sorgenti VHDL che permettono di realizzare  il blocco di Image grabbing. Tutti i file di progetto possono essere reperiti insieme ad una descrizione più dettagliata sul sito della Xilinx (application note 390).

Conclusioni

Con la seconda parte dell’articolo abbiamo visto come un progettista possa realizzare un interfaccia verso un sensore CMOS utilizzando una logica programmabile o un ASIC, mettendo in risalto possibili vantaggi e svantaggi legati al tipo di architettura adottata. Poiché la tecnologia con cui vengono realizzati i sensori d’immagine si evolve rapidamente e le applicazioni sul mercato sono in costante aumento è stato sottolineato come sia importante realizzare un design modulare. Con un esempio si è poi entrati nel dettaglio realizzativo di una semplice interfaccia verso un sensore d’immagine CMOS affrontando, speriamo in maniera esaustiva, l’argomento.

 

 

Scrivi un commento

EOS-Academy
Abbonati ora!