Bandwidth of a MIPI CSI-2 camera interface

When you connect a camera sensor to a microcontroller or a SoC, before choosing how many lanes to use and how fast to run them you must answer one simple question: how many bits per second does the sensor produce, and can the interface carry them? This tool answers that question; this page explains the calculation.

What MIPI CSI-2 is

CSI-2 (Camera Serial Interface 2) is the protocol by which, in the vast majority of modern devices, an image sensor talks to the processor. It defines how pixels are packetized and marked (line start/end, frame start/end, virtual channels), but not how they physically travel on the wire: that is the job of the physical layer, usually D-PHY.

On D-PHY data flows over differential lanes in parallel — typically 1, 2 or 4 — alongside a clock lane. Each lane runs at a given lane rate (e.g. 800, 1500, 2500 Mbps). The overall bandwidth is the sum of the lanes.

How the bandwidth is computed

The raw video stream is a continuous jet of pixels. The required bandwidth is the product of how many pixels per second and how much each pixel weighs:

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

An example: 1920×1080 at 30 fps in RAW10. The pixel rate is 1920 · 1080 · 30 ≈ 62.2 Mpixel/s; at 10 bits per pixel the data rate is ≈ 622 Mbps. On 2 lanes at 1500 Mbps the capacity is 3000 Mbps, so utilization is ≈ 21%: plenty of headroom.

How to read the utilization:

• below ~80% — there is headroom;
• 80–100% — it is tight (little room for blanking, overhead, tolerances);
• above 100% — the lanes cannot carry the stream: you need more lanes, a higher lane rate or a lighter format.

That 80 % threshold is neither arbitrary nor taken from the specification: it is the sensor’s blanking read backwards, as shown further down.

The opposite case: 3840×2160 at 60 fps in RAW12. The pixel rate is 3840·2160·60 ≈ 498 Mpixel/s; at 12 bits/pixel the data rate is ≈ 6.0 Gbps. On the same 2 lanes at 1500 Mbps (3000 Mbps) utilization would be ~199% — impossible; you need 4 lanes at 1500 Mbps (6000 Mbps), and even then you are at ~99.5%, at the edge. This is the typical point where you raise the lane rate or move to a lighter format.

Pixel formats and bits/pixel

For a given resolution and frame rate, the format is what changes the bandwidth:

Going from RAW10 to RGB888 nearly triples the bandwidth (from 10 to 24 bits/pixel): this is why high-resolution pipelines prefer to transfer the RAW and process it downstream.

Overhead: two different mechanisms, often conflated

The pixel data rate is the floor, not the ceiling. But the two things that raise the ceiling are different in nature, and worth keeping apart because they weigh very differently.

Packetization, computed: less than 1 %

A CSI-2 long packet carries a 4-byte Packet Header (Data Identifier, a two-byte Word Count, ECC) and a 2-byte Packet Footer checksum; to those add the Frame Start and Frame End short packets (4 bytes each) and, if enabled, the Line Start and Line End ones. A line’s payload is width · bpp / 8 bytes, so:

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

The control bytes are a per-line constant while the payload grows with width: the overhead is therefore inversely proportional to horizontal resolution, and on real formats it is tiny.

On 1080p RAW10 packetization is worth 0.25 % — or 0.58 % with line sync enabled. It only becomes significant where the payload is tiny: at 160×120 RAW8 it is 3.8 %, and 8.8 % with LS/LE. That is the case of low-resolution high-frame-rate vision sensors, where the bottleneck is usually the LP time between packets rather than the bytes.

So: packetization is not 10–20 %. Anyone quoting that figure is talking about something else.

Blanking, which is the real 10–30 %

Blanking does not add bytes: it squeezes the same bytes into a shorter window. A sensor transmits a line during the active time, then goes quiet for the horizontal blanking; at the end of the frame it goes quiet for the vertical blanking. The link, however, has to carry the instantaneous rate during the active line, not the average over the frame.

With b_h and b_v the relative blanking figures (the sensor’s line_length_pck and frame_length_lines registers divided by the active area, minus one), the active line lasts 1/((1+b_h)(1+b_v)) of the time it would take without blanking, so:

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

Typical CMOS sensor values sit between 5 % and 30 % per axis:

And this is where the 80 % threshold stops being a convention: 80 % average utilization corresponds exactly to a peak/average ratio of 1.25, that is about 12 % blanking on each axis — an utterly ordinary sensor. The threshold is not generic caution: it is typical blanking, read backwards. With a wider-blanking sensor (14 %/13 %, ratio 1.288) the ceiling drops to 77.6 %, and with a narrow one (5 %/3 %) it rises to 92.5 %.

What to put in the overhead field

The tool exposes the net figure (pixels only) and, if you set an overhead, the effective one too, and it bases utilization on the latter. So the number to put there is the blanking, not a packetization guess: (1+b_h)(1+b_v) − 1, which for the 14 %/13 % case is 28.8 %. Packetization, if you want to be pedantic, goes on top and is worth a few tenths of a point.

When you need more lanes

If utilization exceeds the threshold, you have three levers:

1. More lanes — doubling from 2 to 4 lanes doubles the capacity. It is the most direct lever, if the sensor and SoC expose them.
2. Higher lane rate — newer D-PHY reach higher lane rates; often, though, it is the sensor or the PCB that sets the limit. And the lane rate is not continuous: it comes from a PLL with integer dividers, so the values actually selectable are a grid. Asking for “1500 Mbps” may mean getting 1440 or 1584, which is one more reason not to design at the edge of capacity.
3. A lighter format — dropping bit depth or subsampling reduces the data rate at the source.

The tool also computes the minimum number of lanes to stay below the threshold at that lane rate, so you immediately see how much interface you need.

A few cases, net and with blanking

The same links as above, computed by the engine, with and without the 28.8 % blanking of the 14 %/13 % case:

The last row is the interesting one: 4K at 60 fps in RAW12 over 4 lanes at 2500 Mbps sits at 59.7 % on the net figure — reassuring — but at 76.9 % with blanking, one step away from the threshold. That is exactly the case where reasoning on the net figure alone leads to a design that does not work.

The limits of the calculation

It is a bandwidth calculation, not a timing one. It tells whether the stream fits in the lanes; it does not validate timing, clock training, lane skew, equalization, nor the distinction between continuous and discontinuous clock. It does not model the ISP nor compression, and it uses only the active area: blanking is not inferred from the sensor registers but has to be entered by hand in the overhead field, as explained above — and it accounts for 20–30 %. For real camera-link sizing the sensor and SoC datasheets and the MIPI specification remain indispensable.

And if the PHY is C-PHY

The calculation assumes D-PHY, where each lane carries one bit per bit time and the capacity is the trivial sum of the lanes. C-PHY works differently: it operates on trios rather than differential pairs and encodes more than one bit per symbol — 16 bits every 7 symbols, that is 2.286 bits/symbol. A trio at a given symbol rate therefore carries more than the number suggests:

To use this tool with a C-PHY link, just convert: number of trios × symbol rate × 16/7 gives the equivalent capacity in Mbps, to be compared against the data rate. Multi-virtual-channel cases stay out of scope, where several streams share the same lanes and the rates have to be summed before the comparison.

References

• MIPI Alliance — mipi.org, the body that publishes and maintains the CSI-2 and D-PHY specifications.
• x-cube-n6-camera-capture-nucleo — our UVC camera-capture project on the STM32N6 (IMX335 over MIPI-CSI2 + ISP), which this tool grew out of: github.com/stefanofante/x-cube-n6-camera-capture-nucleo.
• Related tool — the MIPI CSI-2 bandwidth calculator puts all this into practice: enter resolution, format and lanes and read the data rate and utilization.