Quando si integra un sensore d’immagine su un MCU o un SoC arriva una domanda che, se sbagliata, fa fallire il bring-up dell’intera camera: quanti lane MIPI CSI-2 servono? Troppo pochi e il link non regge il throughput, perdi frame o non agganci affatto la sincronizzazione; troppi e sprechi pin preziosi, complichi il routing differenziale e, su molte board non li hai. È un calcolo che facciamo all’inizio di ogni progetto imaging, prima ancora di toccare il datasheet del sensore in dettaglio. Vediamo come si calcola, e quali margini vanno tenuti oltre al conto nominale.
Il conto di base: pixel al secondo, poi Gbps
Il punto di partenza è il flusso di pixel grezzo che il sensore deve scaricare. Si moltiplicano tre numeri:
pixel/s = larghezza × altezza × fps
bit/s = pixel/s × bit-per-pixelI bit-per-pixel dipendono dal formato di uscita del sensore, ed è qui che si annida il primo errore. Un sensore in RAW (Bayer) emette tipicamente 10 o 12 bit per pixel — un pixel, un campione. Un’uscita YUV 4:2:2, invece, trasporta in media 16 bit per pixel (due byte ogni pixel, con il croma sottocampionato): il payload non è “pixel × bit del colore” come verrebbe da pensare, ma segue la convenzione del formato. Confondere RAW e YUV nel conteggio dei bit/pixel porta a sottostimare o sovrastimare la banda anche del 60-70%, e da lì a scegliere il numero di lane sbagliato.
Una volta ottenuti i bit/s del payload, si dividono per il lane rate — la velocità per singolo lane del physical layer (D-PHY) — per ottenere il numero di lane necessari. Ed è qui che servono le altre due cautele.
Le insidie: blanking, lane rate, payload reale
La prima insidia è l’overhead di blanking. Il sensore non emette pixel a flusso continuo: tra una riga e l’altra c’è l’horizontal blanking, tra un frame e l’altro il vertical blanking. Significa che i pixel attivi vanno trasmessi in una frazione del tempo di frame, non in tutto il tempo disponibile. Il throughput istantaneo richiesto sul link è quindi più alto del valore medio: dimensionare sul flusso medio porta a un link che, nei picchi di riga attiva, va in underflow. Bisogna ragionare sulla banda di picco, con un margine per il blanking che il datasheet del sensore dichiara.
La seconda insidia è il limite di lane rate. Il lane rate non è libero: lo vincolano sia il D-PHY del sensore sia il ricevitore CSI-2 sul lato MCU/SoC, ciascuno con un massimo (spesso 1.5, 2.0, 2.5 Gbps/lane a seconda della generazione). Non basta che la matematica dia “2 lane a 3 Gbps”: se il ricevitore tira al massimo 2.5 Gbps/lane, quei 3 Gbps non sono raggiungibili e servono più lane a velocità inferiore. Il numero di lane e il lane rate vanno scelti insieme, dentro i limiti del componente più lento dei due.
La terza è ricordare che il D-PHY trasporta anche overhead di protocollo (packet header/footer, sincronizzazione) oltre al payload pixel: il margine va tenuto. La regola pratica che applichiamo è dimensionare con un margine sano sopra il throughput di picco calcolato, non inseguire l’incastro al singolo Gbps.
Per non rifare questa catena di moltiplicazioni e divisioni a mano a ogni nuovo sensore — e per esplorare al volo gli scenari “se passo da 2 a 4 lane” o “se scendo a 30 fps” — abbiamo messo online un calcolatore di banda MIPI CSI-2; il ragionamento completo, con la mappa dei formati e i limiti tipici, è nella wiki dedicata.
Un caso di bring-up reale
Lo scenario che ci capita più spesso: un sensore RAW12 a una certa risoluzione, target a un certo frame rate, da agganciare al ricevitore CSI-2 di un MCU imaging. Il primo calcolo dice “ci stiamo in 2 lane”. Poi guardi il blanking del sensore e ti accorgi che la banda di picco è più alta della media; poi controlli il lane rate massimo del ricevitore e scopri che a quella velocità i 2 lane non bastano nei picchi. La conclusione corretta è spesso 4 lane a un lane rate più rilassato, che dà margine sul blanking e sta dentro i limiti di entrambi i PHY. Aver fatto questo conto prima del layout significa avere i 4 lane già instradati come coppie differenziali con lunghezze appaiate, invece di scoprire al primo power-on che mancano due linee sul connettore.
Il margine, oltre al conto nominale
Il dimensionamento del link camera è uno di quei calcoli che costa cinque minuti all’inizio e settimane se lo sbagli. I tre numeri (risoluzione, fps, bit/pixel) danno la banda; il blanking la spinge in alto; il lane rate dei due PHY mette il tetto. Sbagliare il formato RAW vs YUV o ignorare il blanking sono gli errori che vediamo più spesso, e sono entrambi evitabili con un conto fatto al momento giusto — cioè prima del layout, non al banco.
Stai integrando un sensore MIPI CSI-2 su un tuo progetto e devi dimensionare il link? Parliamone.