SLVS-EC sensor interface: how sensor bytes become pixels

A 12 MP global-shutter sensor running 60 frames per second in RAW10 produces about 7.2 Gbit/s of raw data. A parallel sensor bus built from dozens of LVDS pairs cannot move that with a sane trace count, and most legacy sensor interfaces were never sized for it. SLVS-EC is the packetized sensor interface modern high-resolution image sensors use instead: a few differential lane pairs carrying an embedded clock, at up to 10 Gbit/s per lane in version 3.0. The sections below cover the per-lane rates of versions 1.2, 2.0 and 3.0, the byte-to-pixel path an FPGA receiver implements, and the lane-count arithmetic that sizes the link — so you can decide when a sensor-to-FPGA design needs this class of interface, and when a finished camera makes the question disappear.

What the SLVS-EC interface is and where it sits

SLVS-EC is a serial interface standard that connects an image sensor to receiver silicon — an FPGA or SoC in your own electronics. The EC in the name is the embedded clock: instead of routing a dedicated clock pair alongside the data lines, the sensor folds timing into the serial stream, and the receiver recovers it from the data. One consequence drives the whole design: fewer pairs, no length-matched clock routing, and far more tolerance for trace-length mismatch and longer paths than a parallel bus allows.

The sensor chops each frame into packets and stripes them across one or more differential lane pairs. The receiver runs the same path backwards: find the packets, merge the lanes, check the payloads and hand the image pipeline clean pixel rows. That byte-to-pixel conversion is the point of the interface — the sensor outputs bytes, your pipeline wants pixels. For what a raw sensor hands you before any receiver and ISP, see what raw sensor output means.

In a finished camera, this receiver lives inside the camera electronics and you never meet it: the interface you design against is the camera output — GigE Vision, USB3 Vision or CoaXPress. The standard becomes your problem when you mount a raw sensor module on your own carrier board and have to implement the receiver side.

The numbers: versions, lanes and rates

Version 3.0 of the SLVS-EC standard doubles the per-lane rate of version 2.0 and is backwards compatible with the earlier versions, so one receiver design covers sensors built to any of them:

At the top of the range, eight lanes at 10 Gbit/s move 80 Gbit/s of payload through one interface. Pixel depth is configurable across the 8-to-16-bit range, and payload error detection is integral, with error correction (ECC) optional where the link needs it. The standard also defines data handling for overlapping regions of interest (ROIs), and lane configurations are flexible, so the same receiver core serves two-lane and eight-lane sensors.

How the receiver turns bytes back into pixels

1. Lane alignment. Each lane pair recovers its clock from the embedded stream and deskews; packet headers supply the alignment marks.
2. Lane merge. Bytes striped across the lanes are re-ordered into one stream. The receiver supports different lane configurations, so lane count is a configuration, not a redesign.
3. Header parsing. Packet headers carry the framing that marks where lines and frames begin.
4. Payload checking. Every payload is error-checked in flight; where ECC is enabled, correctable errors are fixed instead of flagged.
5. Byte-to-pixel conversion. Packed bytes are re-grouped into pixel values at the configured depth, anywhere from 8 to 16 bits.
6. Raster output. Rows leave in scan order, including the overlap handling that overlapping-ROI readout modes require.

When pixels never arrive at the end of that chain, the fault sits in one of these stages — probe them in order, exactly as you would any acquisition path: blank image, no pixels: probe the pipeline.

The lane-count math

R is the raw payload rate in bit/s, W × H the array in pixels, b the packed bits per pixel, fps the frame rate in frames per second, R_lane the per-lane rate (5.0 or 10 Gbit/s), L the lane count, U the utilisation. Design to U ≤ 0.8: packet headers and clock-recovery margin live inside that headroom.

Worked example: a 12 MP sensor at 60 fps

Take an illustrative 12 MP array, 4,000 × 3,000 pixels, read out in RAW10 at 60 fps.

• Bits per frame: 4,000 × 3,000 × 10 = 120,000,000 bit = 120 Mbit
• Payload rate: 120 Mbit × 60 per second = 7,200 Mbit/s = 7.2 Gbit/s
• Version 3.0: L = 7.2 ÷ 10 = 0.72 → 1 lane pair; U = 7.2 ÷ 10 = 72%
• Version 2.0: L = 7.2 ÷ 5.0 = 1.44 → 2 lane pairs; U = 7.2 ÷ (2 × 5.0) = 72%

Both pass the 80% rule, so the version choice is about pair count, not feasibility: one lane pair at v3.0 does what two do at v2.0.

The same 7.2 Gbit/s over a parallel bus: LVDS pairs in sensor output stages typically carry well under 1 Gbit/s each. At an optimistic 0.5 Gbit/s per pair, 7.2 ÷ 0.5 = 14.4 — call it 15 data pairs plus a clock pair, all length-matched. One SLVS-EC v3.0 pair replaces them.

For scale, the full width of version 3.0 is 8 lanes × 10 Gbit/s = 80 Gbit/s. That moves the 120 Mbit frame at up to 80,000 ÷ 120 ≈ 666 fps — a ceiling before packet-header overhead, and only if the sensor can be read out that fast.

SLVS-EC against parallel buses and MIPI CSI-2

Parallel buses lose on trace count and length matching; that is why high-speed scan designs that once ran dozens of LVDS data lines move to this class of interface.

MIPI CSI-2 is the other packetized high-speed sensor family, and it dominates where the receiver is an embedded host SoC rather than an FPGA. The trade-offs there are lane count and per-lane rate against host receiver support: the MIPI lane-bandwidth guide works that limit in detail, the 2-lane versus 4-lane probe failure article shows what happens when the lane configuration is mis-declared, and the embedded camera interface comparison sets CSI-2 alongside GMSL2 and the rest. If the capture side routes an HDMI source through a CSI-2 input on an embedded host, the CSI-2 capture selection guide walks that hardware decision. The SLVS-EC case is the raw sensor-to-FPGA path at the top of the rate range: 10 Gbit/s per lane and up to eight lanes, with no host receiver standard in the way.

Where this lands in a real machine-vision build

Build the receiver. You put a raw sensor module on your FPGA carrier and provide the receiver: lane merge, byte-to-pixel, ECC, ROI handling. Before wiring anything, run the interface checks in the camera module interface compatibility checklist — the electrical and protocol items there settle most of these projects.

Buy the bridge. A finished board-level camera integrates sensor, receiver and output stage, and hands your host a standard link instead of raw lanes. The LS-BCM-0056 pairs a 12 MP sensor with 1.6 μm×1.6 μm pixels on a 1/2" format and outputs GigE through a C-mount board design. The LS-BCM-0003 runs its 3.1 MP, 1/1.8" global-shutter IMX252 sensor at 120 fps over USB3, receiver and framing included. The MV-CB060-10UM-B is a bare-board 6 MP mono camera on a 1/1.8" rolling-shutter IMX178 sensor, for builds where the housing is yours:

Mind the host side. The 7.2 Gbit/s from the worked example does not ride a single GigE link, which tops out near 1 Gbit/s. A 10GigE uplink carries it; CoaXPress cameras reach comparable rates with multiple connections per camera. On the host side the MV-GT1102P is a dual 10GigE frame grabber, the MV-GE1104 a 4-port GigE frame grabber for distributed multi-camera cells, and the MV-GX1008 an octo CXP-6 frame grabber for CoaXPress cameras — all in the frame grabbers category:

When acquisition outruns processing, the fix is architecture, not more bandwidth: acquisition faster than processing covers that gap. And if the real question is how many pixels the inspection needs, start from how many pixels high-resolution machine vision requires.

Checks before you commit

• Run R = W × H × b × fps at the maximum frame rate and deepest pixel format you will actually use, not the nominal one, then round L up to whole lanes with U ≤ 0.8.
• Match the receiver class to the standard version: a 10 Gbit/s lane needs v3.0-class receiver silicon and transceivers rated for that rate; v2.0-class hardware stops at 5.0 Gbit/s per lane.
• Enable payload error detection by default. Switch ECC on for paths over in-device cables or long board routes; leave it off on short, well-controlled board runs to save FPGA resources.
• Plan pixel depth up front: dynamic switching across 8 to 16 bits only helps if the downstream DMA widths and memory layout follow the new pixel size.
• If the sensor's readout mode uses overlapping ROIs, confirm the receiver implements the standard's overlap data handling before you build the frame buffer around it.

When you do not need SLVS-EC at all

If pixels × bits × fps lands under a few hundred megabits per second, no custom receiver design is warranted: a finished camera with a GigE or USB3 output carries it, and your engineering time goes to optics and lighting instead. Cutting data at the source moves the decision further — ROI cropping at the camera reduces bandwidth before the host sees it, and a slower sensor class often suffices, as the sensor selection for high-speed inspection guide lays out.

SLVS-EC earns its complexity when the array is large, the frame rate high, the bit depth deep and the receiver your own FPGA. Next step: put your own array into R = W × H × b × fps, pick the lane count at U ≤ 0.8, then decide build versus buy. The camera finder filters finished cameras by sensor, resolution and interface, the camera configurator assembles a module-based set-up, and the contact page connects you with an applications engineer for the link budget.