When you integrate an image sensor on an MCU or SoC, a question arrives that, if you get it wrong, makes the whole camera bring-up fail: how many MIPI CSI-2 lanes do you need? Too few and the link can’t carry the throughput — you drop frames, or you don’t even lock sync; too many and you waste precious pins, complicate the differential routing and, on many boards you don’t have them. It’s a calculation we do at the start of every imaging project, before even touching the sensor datasheet in detail. Here is how it is computed, and which margins have to be held beyond the nominal figure.
The basic math: pixels per second, then Gbps
The starting point is the raw pixel flow the sensor has to push out. You multiply three numbers:
pixels/s = width × height × fps
bits/s = pixels/s × bits-per-pixelThe bits-per-pixel depend on the sensor’s output format, and this is where the first error hides. A RAW (Bayer) sensor typically emits 10 or 12 bits per pixel — one pixel, one sample. A YUV 4:2:2 output, instead, carries on average 16 bits per pixel (two bytes per pixel, with subsampled chroma): the payload isn’t “pixels × color bits” as one might think, but follows the format’s convention. Confusing RAW and YUV in the bits-per-pixel count leads to under- or over-estimating the bandwidth by as much as 60-70%, and from there to choosing the wrong lane count.
Once you have the payload bits/s, you divide by the lane rate — the per-lane speed of the physical layer (D-PHY) — to get the number of lanes needed. And this is where the other two cautions come in.
The traps: blanking, lane rate, real payload
The first trap is the blanking overhead. The sensor doesn’t emit pixels as a continuous flow: between one line and the next there’s horizontal blanking, between one frame and the next vertical blanking. This means the active pixels have to be transmitted in a fraction of the frame time, not over all the available time. The instantaneous throughput required on the link is therefore higher than the average value: dimensioning on the average flow leads to a link that, at active-line peaks, goes into underflow. You have to reason on peak bandwidth, with a margin for the blanking the sensor datasheet declares.
The second trap is the lane-rate limit. The lane rate isn’t free: it’s constrained by both the sensor’s D-PHY and the CSI-2 receiver on the MCU/SoC side, each with a maximum (often 1.5, 2.0, 2.5 Gbps/lane depending on the generation). It’s not enough that the math says “2 lanes at 3 Gbps”: if the receiver tops out at 2.5 Gbps/lane, those 3 Gbps aren’t reachable and you need more lanes at a lower speed. Lane count and lane rate have to be chosen together, within the limits of the slower of the two parts.
The third is to remember that the D-PHY also carries protocol overhead (packet header/footer, synchronization) on top of the pixel payload: keep the margin. The rule of thumb we apply is to dimension with a healthy margin above the computed peak throughput, not to chase the fit down to the single Gbps.
To avoid redoing this chain of multiplications and divisions by hand for every new sensor — and to explore on the fly the “what if I go from 2 to 4 lanes” or “what if I drop to 30 fps” scenarios — we put a MIPI CSI-2 bandwidth calculator online; the full reasoning, with the format map and typical limits, is in the dedicated wiki.
A real bring-up case
The scenario we hit most often: a RAW12 sensor at a certain resolution, target at a certain frame rate, to hook up to the CSI-2 receiver of an imaging MCU. The first calculation says “we fit in 2 lanes”. Then you look at the sensor’s blanking and realize the peak bandwidth is higher than the average; then you check the receiver’s maximum lane rate and discover that at that speed 2 lanes aren’t enough at the peaks. The correct conclusion is often 4 lanes at a more relaxed lane rate, which gives margin on the blanking and stays within the limits of both PHYs. Having done this math before layout means having the 4 lanes already routed as length-matched differential pairs, instead of discovering at first power-on that two lines are missing on the connector.
Margin, beyond the nominal arithmetic
Dimensioning the camera link is one of those calculations that costs five minutes at the start and weeks if you get it wrong. The three numbers (resolution, fps, bits-per-pixel) give the bandwidth; blanking pushes it up; the lane rate of the two PHYs sets the ceiling. Getting the RAW vs YUV format wrong or ignoring blanking are the errors we see most often, and both are avoidable with a calculation done at the right time — that is, before layout, not on the bench.
Are you integrating a MIPI CSI-2 sensor in a project and need to dimension the link? Let’s talk.