Banda di un'interfaccia camera MIPI CSI-2

Quando colleghi un sensore camera a un microcontrollore o a un SoC, prima di scegliere quante lane usare e a che velocità farle andare devi rispondere a una domanda semplice: quanti bit al secondo produce il sensore, e l’interfaccia li regge? Questo strumento risponde a quella domanda; questa pagina spiega il calcolo.

Cos’è MIPI CSI-2

CSI-2 (Camera Serial Interface 2) è il protocollo con cui, nella stragrande maggioranza dei dispositivi moderni, un sensore d’immagine parla con il processore. Definisce come i pixel vengono impacchettati e marcati (inizio/fine riga, inizio/fine frame, canali virtuali), ma non come viaggiano fisicamente sul filo: quello è compito del livello fisico, di norma D-PHY.

Su D-PHY i dati scorrono su lane differenziali in parallelo — tipicamente 1, 2 o 4 — affiancate da una lane di clock. Ogni lane gira a un certo lane rate (es. 800, 1500, 2500 Mbps). La banda complessiva è la somma delle lane.

Come si calcola la banda

Il flusso video grezzo è un getto continuo di pixel. La banda richiesta è il prodotto di quanti pixel al secondo e quanto pesa ogni pixel:

$$\begin{array}{rlrl}\text{pixelRate}& =\text{larghezza}\cdot \text{altezza}\cdot \text{fps}& & [\text{pixel/s}]\\ \text{dataRate}& =\text{pixelRate}\cdot \text{bit-per-pixel}& & [\text{bit/s}]\\ \text{capacity}& =\text{numero-lane}\cdot \text{lane-rate}& & [\text{Mbps}]\\ \text{util}\%& =\frac{\text{dataRate}}{\text{capacity}}\cdot 100& & \end{array}$$

Un esempio: 1920×1080 a 30 fps in RAW10. Il pixel rate è 1920 · 1080 · 30 ≈ 62,2 Mpixel/s; a 10 bit per pixel il data rate è ≈ 622 Mbps. Su 2 lane a 1500 Mbps la capacità è 3000 Mbps, quindi l’occupazione è ≈ 21%: c’è ampio margine.

La regola di lettura dell’occupazione:

• sotto ~80% — c’è margine;
• 80–100% — si è al limite (poco spazio per blanking, overhead, tolleranze);
• oltre 100% — le lane non reggono il flusso: serve più lane, un lane rate più alto o un formato più leggero.

Quella soglia dell’80 % non è arbitraria e non viene dalla specifica: è il blanking del sensore letto al contrario, come si vede più sotto.

Un caso opposto: 3840×2160 a 60 fps in RAW12. Il pixel rate è 3840·2160·60 ≈ 498 Mpixel/s; a 12 bit/pixel il data rate è ≈ 6,0 Gbps. Sulle stesse 2 lane a 1500 Mbps (3000 Mbps) l’occupazione sarebbe ~199% — impossibile; servono 4 lane a 1500 Mbps (6000 Mbps), e anche così si è al ~99,5%, al limite. È il tipico punto in cui conviene salire di lane rate o passare a un formato più leggero.

I formati pixel e i bit/pixel

A parità di risoluzione e frame rate, il formato è ciò che fa cambiare la banda:

Passare da RAW10 a RGB888 quasi triplica la banda (da 10 a 24 bit/pixel): è il motivo per cui le pipeline ad alta risoluzione preferiscono trasferire il RAW e fare l’elaborazione a valle.

Overhead: due meccanismi diversi, spesso confusi

Il data rate dei pixel è il pavimento, non il soffitto. Ma le due cose che alzano il soffitto sono di natura diversa, e vanno tenute separate: pesano in modo molto diverso.

La packetizzazione, calcolata: meno dell’1 %

Un long packet CSI-2 porta un Packet Header di 4 byte (Data Identifier, Word Count su due byte, ECC) e un Packet Footer di 2 byte di checksum; a questi si aggiungono i short packet di Frame Start e Frame End (4 byte ciascuno) e, se abilitati, quelli di Line Start e Line End. Il payload di una riga è width · bpp / 8 byte, quindi:

$${\text{overhead}}_{\text{pkt}}=\frac{6+8_{(\mathrm{LS}+\mathrm{LE})}}{\text{width}\cdot \text{bpp}/8}$$

I byte di controllo sono una costante per riga, il payload cresce con la larghezza: l’overhead è quindi inversamente proporzionale alla risoluzione orizzontale, e sui formati veri è minuscolo.

Su un 1080p in RAW10 la packetizzazione vale 0,25 % — o 0,58 % con i sincronismi di riga attivi. Diventa significativa solo dove il payload è minuscolo: a 160×120 in RAW8 sono 3,8 %, e con LS/LE 8,8 %. È il caso dei sensori di visione a bassa risoluzione e alto frame rate, dove però il collo di bottiglia è di solito il tempo LP fra pacchetti, non i byte.

Quindi: la packetizzazione non è il 10–20 %. Chi cita quella cifra sta parlando di un’altra cosa.

Il blanking, che è il vero 10–30 %

Il blanking non aggiunge byte: comprime gli stessi byte in una finestra più corta. Un sensore trasmette una riga durante il tempo attivo, poi resta zitto per il blanking orizzontale; alla fine del frame resta zitto per il blanking verticale. Il link, però, deve reggere il rate istantaneo durante la riga attiva, non la media sul frame.

Detti b_h e b_v i blanking relativi (i registri line_length_pck e frame_length_lines del sensore diviso l’area attiva, meno uno), la riga attiva dura 1/((1+b_h)(1+b_v)) del tempo che avrebbe senza blanking, quindi:

$$\frac{R_{\text{picco}}}{R_{\text{medio}}}=(1+b_h)(1+b_v)⟹{\text{util}}_{\text{max}}=\frac{1}{(1+b_h)(1+b_v)}$$

I valori tipici di un sensore CMOS stanno fra il 5 % e il 30 % per asse:

Ed è qui che la soglia dell’80 % smette di essere una convenzione: 80 % di utilizzo medio corrisponde esattamente a un rapporto picco/medio di 1,25, cioè a circa il 12 % di blanking su ciascun asse — un sensore assolutamente ordinario. La soglia non è prudenza generica: è il blanking tipico, letto al contrario. Con un sensore a blanking più largo (14 %/13 %, rapporto 1,288) il tetto scende al 77,6 %, e con uno stretto (5 %/3 %) sale al 92,5 %.

Cosa mettere nel campo overhead

Lo strumento espone il dato netto (i soli pixel) e, se imposti un overhead, anche l’effettivo, ed è su quello che calcola l’occupazione. Il numero da metterci è quindi il blanking, non una stima di packetizzazione: (1+b_h)(1+b_v) − 1, che per il caso 14 %/13 % fa 28,8 %. La packetizzazione, se si vuole essere pignoli, si aggiunge sopra e vale qualche decimo di punto.

Quando servono più lane

Se l’occupazione supera la soglia, hai tre leve:

1. Più lane — raddoppiare da 2 a 4 lane raddoppia la capacità. È la leva più diretta, se il sensore e il SoC le espongono.
2. Lane rate più alto — D-PHY più recenti raggiungono lane rate più elevati; spesso però è il sensore o il PCB a porre il limite. E il lane rate non è continuo: nasce da un PLL con divisori interi, quindi i valori realmente selezionabili sono una griglia. Chiedere «1500 Mbps» può significare ottenere 1440 o 1584, ed è un motivo in più per non progettare a filo di capacità.
3. Formato più leggero — scendere di profondità di bit o sottocampionare riduce il data rate alla fonte.

Lo strumento calcola anche il numero minimo di lane per stare sotto la soglia a quel lane rate, così vedi subito quanta interfaccia serve.

Un po’ di casi, netti e con blanking

Gli stessi collegamenti visti prima, calcolati dal motore, con e senza il 28,8 % di blanking del caso 14 %/13 %:

L’ultima riga è il punto interessante: 4K a 60 fps in RAW12 su 4 lane a 2500 Mbps sta al 59,7 % sul netto — rassicurante — ma al 76,9 % con il blanking, cioè a un passo dalla soglia. È esattamente il caso in cui ragionare sul solo netto porta a un progetto che non funziona.

I limiti del calcolo

È un calcolo di banda, non di temporizzazione. Dice se il flusso ci sta nelle lane; non valida il timing, il clock training, lo skew tra lane, l’equalizzazione, né la distinzione tra clock continuo e discontinuo. Non modella l’ISP né la compressione, e usa la sola area attiva: il blanking non è dedotto dai registri del sensore ma va inserito a mano nel campo overhead, come spiegato sopra, e vale il 20–30 %. Per il dimensionamento reale di un link camera restano indispensabili i datasheet del sensore e del SoC e la specifica MIPI.

E se il PHY è C-PHY

Il calcolo assume D-PHY, dove ogni lane trasporta un bit per tempo di bit e la capacità è la somma delle lane. Il C-PHY funziona in modo diverso: lavora a trio invece che a coppia differenziale e codifica più di un bit per simbolo — 16 bit ogni 7 simboli, cioè 2,286 bit/simbolo. Un trio a un dato symbol rate porta quindi più di quanto suggerisca il numero:

Per usare questo strumento con un link C-PHY basta convertire: numero di trio × symbol rate × 16/7 dà la capacità equivalente in Mbps, da confrontare col data rate. Restano fuori i casi multi-canale-virtuale, dove più flussi condividono le stesse lane e la somma dei rate va fatta prima del confronto.

Riferimenti

• MIPI Alliance — mipi.org, ente che pubblica e mantiene le specifiche CSI-2 e D-PHY.
• x-cube-n6-camera-capture-nucleo — il nostro progetto di acquisizione camera UVC su STM32N6 (IMX335 via MIPI-CSI2 + ISP), da cui nasce questo strumento: github.com/stefanofante/x-cube-n6-camera-capture-nucleo.
• Strumento correlato — il calcolatore di banda MIPI CSI-2 mette in pratica tutto questo: inserisci risoluzione, formato e lane e leggi data rate e occupazione.