MIPI CSI-2 to USB bridge bandwidth: sizing the data path

A sensor speaks MIPI CSI-2 across short traces on a board, and a PC speaks USB 3.0 across a cable. A bridge chip sits between them, and the two sides are not symmetrical: four CSI-2 lanes at 1.5 Gbps each move 6 Gbps, while the USB 3.0 side sustains about 3.2 Gbps of usable payload. Projects stall less because a bridge is misconfigured than because the stream was never sized against the smaller pipe. Here are both capacities, the stream-rate formula, a worked 13 MP example with the arithmetic shown, and the order in which to cap frame rate, bit depth and window when the numbers do not close. Run the math before you open any bridge configuration tool; it tells you which configuration to aim for.

Two links, one bottleneck: the capacities that matter

Size the CSI-2 side first, because it is the easy one. Line rate equals lanes times per-lane data rate, and classic sensor designs clock four D-PHY lanes at 1.5 Gbps each: 4 × 1.5 Gbps = 6 Gbps on the wire, with newer PHY generations stretching a single lane to 2.5 Gbps. Pixel data does not use all of that. Every line travels inside packets with a 4-byte header, a 2-byte CRC and a footer on long packets, with sync periods between lines, so budget 15-20% for framing. A 6 Gbps link therefore carries roughly 600 MB/s of real pixel data.

The USB 3.0 side is smaller, and the gap is what sinks schedules. The bus signals at 5 Gbps, loses 20% to 8b/10b encoding, and bulk framing, packet headers and retries take most of what is left: about 3.2 Gbps, or 400 MB/s, sustained. That is roughly half the raw rate of the 4-lane link above, and it is the number every later decision hangs on. Design each camera against 320 MB/s, 80% of the ceiling, so the host controller keeps margin for enumeration and anything else sharing the bus.

The sensor side gets its own treatment in MIPI camera lane bandwidth: what limits frame rate, and what CSI-2 compatibility guarantees beyond the connector covers what a link promises before the first frame moves.

How the bridge moves a frame (and where it stalls)

The bridge deserializes CSI-2 packets into line buffers, assembles frames in memory, then chops each frame into USB bulk packets that the host pulls at its own pace. Two clocks are configured independently and must each be sized on its own. The CSI-2 receiver has to be clocked for the lane rate the sensor drives; that is the bridge's MIPI CSI-2 clock-rate configuration, and when it is wrong the link fails at probe time, not mid-stream. The USB side advertises frame descriptors, resolution and frame-interval pairs, and the host picks one and expects the pipe to carry it continuously.

If a descriptor promises a 13 MP, 30 fps stream that needs 394 MB/s and the pipe sustains 320 MB/s, the host still tries: frames come out torn, skipped or stalled. Until you do the math, that symptom is indistinguishable from a cable or exposure fault, which is why the frame-rate drop triage for exposure and USB link bandwidth belongs in the same drawer as this page.

The stream-rate formula and a worked example

Take an illustrative 13 MP sensor, 4208 × 3120 pixels, streaming mono RAW8 through four 1.5 Gbps CSI-2 lanes into a USB 3.0 bridge:

• Pixels per frame: 4208 × 3120 = 13,128,960.
• RAW8 is 1 byte per pixel: 13,128,960 B ≈ 13.13 MB per frame.
• At 30 fps: 13.13 MB × 30 = 393.9 MB/s, which is 393.9 × 8 = 3,151 Mbit/s ≈ 3.15 Gbps.
• Load on the USB ceiling: 393.9 ÷ 400 = 98%. Nothing else may touch that controller; the first hub or disk sharing the bus starts eating frames.
• The CSI-2 side, for contrast: 3.15 Gbps of payload needs 3.15 ÷ 0.83 ≈ 3.8 Gbps of line rate. Four 1.5 Gbps lanes carry that at 63% utilization; two lanes, 3 Gbps, cannot. USB binds, not MIPI.
• The same sensor delivering 10-bit data in 16-bit containers, which is what USB hosts normally receive: 13,128,960 × 2 B ≈ 26.26 MB per frame, and 26.26 × 30 = 787.7 MB/s ≈ 6.3 Gbps. That is 197% of the USB ceiling and, after packet overhead, 6.3 ÷ 0.83 ≈ 7.6 Gbps of line rate, more than the 4-lane link itself.

Three ways to close the gap, each with its arithmetic:

• Keep full frame at 8-bit and drop to 24 fps: 13.13 × 24 = 315.1 MB/s, a 79% load. Passes.
• Keep 16-bit data and drop to 12 fps: 26.26 × 12 = 315.1 MB/s, 79%. Passes.
• Keep 30 fps at 8-bit and window to 1920 × 1080 at 60 fps: 1920 × 1080 = 2,073,600 B ≈ 2.07 MB per frame, and 2.07 × 60 = 124.4 MB/s, a 31% load. Comfortable.

Compute every descriptor you intend to advertise. The combinations over 320 MB/s are configurations you will never make stable, however carefully the bridge tool is driven.

What to cap first: frame rate, bit depth, or window

Cap frame rate first: it scales the whole stream linearly, and most inspection tasks need 15-60 fps rather than the sensor maximum. The process sets that number, not the data sheet. Bit depth comes second: moving from 16-bit containers to 8-bit halves the stream. Note that 10-bit sensors normally arrive on the host as 16-bit planes, as this unpack of 10-bit RGB camera data shows, unless the bridge offers packed RAW10, four pixels in five bytes, which you size at 1.25 bytes per pixel. Window comes third: cropping scales with area and binning divides it by four, at the cost of a larger effective pixel that changes your optics math; how sensor resolution modes work shows what the sensor itself can be told to output.

When a finished camera is the better tool

If the deliverable is inspection frames rather than an embedded integration exercise, skip the bridge project. A camera whose sensor and USB3 link were matched at the design stage advertises descriptors its pipe actually sustains. Board-level cameras suit short runs of 3 m or less; for longer distances, GigE board cameras hold about 120 MB/s over 100 m of copper, and 2.5 and 5GBASE-T hardware multiplies that on structured cabling. Start from board-level cameras and area scan cameras, or go straight to the camera finder and configure a camera.

Board-level cameras with the sensor-to-host link already engineered in:

For full-size inspection frames, the integrated option in this class streams 12 MP (4000 × 3000) at 30 fps over USB3:

Checks before you commit the design

1. Compute stream and load for every mode you will advertise, and delete anything over 320 MB/s before it reaches a configuration file.
2. Check the CSI-2 side the same way: payload ÷ 0.83 must stay at or under lanes × lane rate.
3. Give each camera its own host controller at these rates. A hub shares its 400 MB/s across every port behind it, which is why two USB3 cameras at full resolution need the host buffer raised and why hub bandwidth budgeting comes first.
4. Measure the rate the link actually delivers after bring-up, not the descriptor's promise; measuring camera frame rate reliably shows the method.
5. If the numbers fit and frames still stall, the fault sits between layers rather than in the budget. Work through layer-by-layer MIPI CSI-2 bring-up checks before touching bandwidth again.

Cable is its own check: passive SuperSpeed runs at 3 m or less, drag-chain-rated flex on moving axes, never a charge lead, which negotiates and then fails under load. The camera cable category lists rated lengths; on a moving axis this 3 m high-flex USB 3.0 cable is the standard pick:

Where the simple math bends

• Decimation and packing change the input. If the bridge skips lines or packs RAW10 on the fly, apply the formula to the bytes leaving the bridge, not the pixels leaving the sensor.
• The sensor side can bind first. The 16-bit, 30 fps example needed 7.6 Gbps of line rate, which no lane count at 1.5 Gbps carries; lane-mode mismatch is also behind why a sensor probes in one lane mode and fails in the other.
• RAW sensors stream RAW. A sensor without an ISP sends its raw output regardless of the display format you would prefer, as what raw output with no ISP means explains, so bytes per pixel is fixed upstream of the bridge.
• Compression breaks the linear formula. A bridge that compresses before transmission moves fewer bytes than pixels; size that link from measured throughput instead of pixel rate.

Size the stream first, then pick hardware: one design point under 320 MB/s, every descriptor closed on paper, and a shortlist from the categories above. If the path still will not close, tell us the sensor, its modes and the frame rate the process needs on the contact page and we will size it with you. More camera-interface reading sits on the cameras topic page.