SLVS-EC lanes and the embedded clock: why the interface matters

A new sensor's data sheet lists its output as SLVS-EC, not the 10-bit parallel bus you carried over from the last board. You now have to size the lane count, work out what an embedded clock means for your layout, and decide whether a finished camera would do the job with less engineering. Here are the numbers that decide it: up to 8 lanes at 4.752 Gbps per lane in version 1.2, the 8b/10b code that turns payload into wire rate, a worked example for a 4000 × 3000 RAW-10 sensor at 60 fps, and the checks to run before you commit hardware. Everything here is the physical link; the byte-to-pixel decode is covered separately.

What is SLVS-EC, and what does embedded clock mean?

SLVS-EC stands for Scalable Low Voltage Signaling with Embedded Clock, a serial interface that moves raw pixel data from a sensor die to a receiver ASIC or FPGA over up to 8 lanes at rates reaching 4.752 Gbps per lane in version 1.2.

Each lane is a differential pair driven at a rate the sensor sets. The name spells out both ideas that matter. Scalable Low Voltage Signaling is the electrical layer: a small-swing differential signal that is kinder to power and noise than a full logic swing. Embedded Clock is the protocol part: no clock pair runs beside the data, because each lane's timing is recovered from its own transitions.

The receiver's clock-data-recovery circuit locks onto each lane independently, then the logic re-aligns the lanes using packet markers embedded in the stream. So a two-lane link is four signal pins and nothing else, where a parallel bus of the same bandwidth needs a clock line length-matched to every data trace. What happens after recovery — how packed bytes become a usable image — is covered in SLVS-EC sensor data: how sensor bytes become pixels.

How many lanes does SLVS-EC use, and how fast is each lane?

Version 1.2 scales to 8 lanes at 4.752 Gbps per lane — 38.016 Gbps on the wire and about 30.4 Gbps of payload after 8b/10b decoding — and receiver cores document lane rates up to 9.504 Gbps.

Lane rates come in defined baud grades rather than arbitrary values. One documented receiver core lists Baud Grade 1 at 1188 Mbps and support up to 9504 Mbps per lane; another terminates 5 Gbps per lane across all 8 lanes and handles RAW-8 and RAW-10 pixel formats. That spread is the practical point: the standard defines the protocol, but your receiver silicon and IP decide which grades you can actually terminate.

The arithmetic that sizes a link is three lines:

The 0.8 factor is the 8b/10b code. Every 8 payload bits travel as 10 wire bits, which keeps the signal DC-balanced and guarantees transitions for clock recovery even through long runs of identical bytes.

Why embed the clock in the data lanes?

An embedded clock removes the dedicated clock line and the skew budget that comes with it: every lane recovers its own timing with a clock-data-recovery circuit, so lane-to-lane skew stops being a setup-and-hold problem and becomes a packet-alignment step the logic handles.

A parallel bus fails in a specific way. If a data trace and the clock trace drift apart by a fraction of a clock period, the receiver samples the wrong bit and you get a bad pixel with no flag. Per-lane clock recovery cannot fail that way, because each lane carries its own timing reference and tracks it continuously.

Skew between lanes still exists, but it stops being a timing budget. Each lane is recovered on its own and re-aligned against packet markers, so no skew adjustment between lanes is needed. Track lengths can differ by far more than a parallel layout would tolerate, and that is what frees the mechanical design: the sensor sits where the optics need it, not where a clock tree puts it.

The benefits stack up in four places:

• Bandwidth that scales with lanes: 2, 4 or 8 pairs instead of a wider bus.
• Fewer pins: 4 signal pins for a 2-lane link against 13 for a 10-bit parallel bus.
• Noise behaviour: small-swing differential pairs reject common-mode noise, and error detection in the packet stream flags corruption instead of letting it pass as pixel data.
• Power per bit: a couple of low-swing drivers replace a wide full-swing bus and its clock tree, which is why compact and battery-powered designs prefer it.

How much SLVS-EC bandwidth does your sensor need?

Multiply pixels per frame by frames per second by bits per pixel, then divide by 0.8 for the 8b/10b code: a 4000 × 3000 sensor in RAW-10 at 60 fps needs 7.2 Gbps of payload, which two 4.752 Gbps lanes cover with 5.6% headroom.

Worked example, step by step:

1. Pixels per frame: 4000 × 3000 = 12,000,000.
2. Pixel rate: 12,000,000 pixels × 60 fps = 720 Mpixels/s.
3. Payload: 720 Mpixels/s × 10 bits = 7.2 Gbps.
4. Wire rate: 7.2 Gbps ÷ 0.8 = 9.0 Gbps.
5. One lane at 4.752 Gbps carries 3.802 Gbps of payload — not enough.
6. Two lanes: 9.504 Gbps of wire rate carries 7.603 Gbps of payload, and (7.603 − 7.2) ÷ 7.2 = 5.6% headroom. The link fits at 60 fps.
7. Those two lanes cap this sensor near 63 fps, because 7.603 Gbps ÷ 0.12 Gbit per frame = 63.4.

5.6% headroom is workable for one fixed mode and thin for a roadmap. Four lanes at the same grade carry 15.206 Gbps of payload: 120 fps with the same 5.6% margin, a ceiling near 126 fps, or a slower sensor with room to grow.

What does SLVS-EC change on your PCB?

For the same 720 Mpixels/s RAW-10 stream, a parallel 10-bit bus spends 10 data lines plus a clock and two sync lines and pushes every data line to 720 Mbps — a 720 MHz pixel clock — while SLVS-EC covers it with two differential pairs, four pins, and no lane-to-lane skew adjustment.

That 720 MHz figure is the arithmetic, and it is the problem. Parallel sensor buses are built for pixel clocks in the tens to low hundreds of MHz, so a real 720 Mpixels/s parallel output would need bit multiplexing, double-data-rate tricks or a lower frame rate. SLVS-EC spreads the same stream over pairs at 4.752 Gbps each and lets the clock recovery handle the timing.

Power moves the same direction: two low-swing differential pairs replace ten full-swing lines and a 720 MHz clock tree, so switching energy per transmitted bit drops and the sensor package runs cooler. The interface is chip-to-chip by intent — sensor to receiver across one board or a short flex. For a metre of cable you leave SLVS-EC inside the device and put GigE, USB3 or CoaXPress on the wire, which is also why a shop frame grabber terminates those interfaces and not SLVS-EC.

How does SLVS-EC compare with MIPI CSI-2?

Both are serial sensor interfaces, but CSI-2 over D-PHY still runs a dedicated clock lane while SLVS-EC recovers the clock from every data lane, and SLVS-EC's 8-lane, 4.752 Gbps per lane scaling targets the higher resolutions industrial sensors ship at.

CSI-2 is the interface you meet when the destination is an application processor or embedded SoC with a native camera input; SLVS-EC is what you meet when the sensor is the fast part and an FPGA-style receiver is the destination. Both are packetised serial links, so the lane-bandwidth arithmetic has the same shape — the MIPI lane bandwidth limit math applies to CSI-2 lanes as well, and the embedded interface comparison from CSI-2 to GMSL2 sets both against the longer-distance options.

Rule of thumb: choose CSI-2 when your processor already contains the receiver. Choose SLVS-EC when the sensor offers it and you need more lanes, higher per-lane grades, or the sensor exposes its fastest readout modes only through SLVS-EC.

When should you skip SLVS-EC and buy a finished camera?

If your pixels per second fit a standard camera interface — up to about 3.6 Gbps of payload, where a 12 MP USB3 camera streams 4000 × 3000 at 30 fps — buying finished removes receiver design, driver work and sensor bring-up from the project.

The sensor inside a finished camera still talks SLVS-EC. The camera is the receiver, and you are buying its receiver design, its drivers and its bring-up time. A finished 12 MP USB3 camera like the LS-CMR-0166 streams 4000 × 3000 at 30 fps. That is 3.6 Gbps of RAW-10 payload, inside USB3's roughly 4 Gbps budget after its own 8b/10b overhead; the per-camera arithmetic is in reduce USB3 camera bandwidth.

If you want sensor-level mechanics without writing a receiver, the middle ground is a board-level module that already converts to GigE or USB3 — the board-level cameras range exists for exactly this. The LS-BCM-0020 carries a 6.3 MP rolling-shutter IMX178 sensor behind a CS-mount on GigE at 18 fps. The MV-CB060-10UM-B ships as a bare board with a 6 MP mono IMX178 sensor on USB3. The MV-CB016-10GM-M-W pairs a 1.6 MP IMX296 global-shutter sensor with an M12 mount on GigE.

Build the link yourself when pixels × fps × bits per pixel outgrows those interfaces — past about 33 fps at 12 MP in RAW-10 you exceed USB3's payload, and a 60 fps mode needs the two-lane SLVS-EC link from the worked example — or when you need sensor modes a finished camera does not expose, custom optics, or a board shape no camera comes in. Buy when the numbers fit and the schedule is the scarce resource: the area scan cameras and the camera finder are the fast path.

What should you check before committing to SLVS-EC hardware?

Four checks decide it: the receiver's lane-rate grades, its lane count and pixel formats, your FPGA transceivers' reach, and the margin over the sensor's maximum sustained payload — one documented receiver starts at Baud Grade 1, 1188 Mbps, tops at 9504 Mbps, and lists RAW-8 and RAW-10.

Run the list before ordering either side of the link:

• Protocol revision: the sensor's SLVS-EC revision against the revisions the receiver core supports.
• Lane-rate grades: the sensor's configured grade must fall inside the receiver's documented set. A 9504 Mbps grade runs on the receiver that tops at 9504 Mbps and misses the one capped at 5 Gbps per lane.
• Pixel format: RAW-8 and RAW-10 are what these receivers list; your sensor's output format must appear in the core's list.
• Transceiver reach: the FPGA family's serial transceivers must run the per-lane grade — protocol support without a PHY is a paper design.
• Margin: lanes × grade × 0.8 at least 10% above the sensor's maximum sustained payload.
• Decode path: recovering lanes is half the work; plan the unpacking stage from packet stream to pixel array before the PCB goes out.

The decision reduces to one division: payload ÷ (lanes × grade × 0.8). Under 1 with margin, the link holds; over it, add lanes or move to a higher grade. Two lanes at 4.752 Gbps carry 7.603 Gbps of payload, four carry 15.206 Gbps, and eight at the 9504 Mbps grade carry 60.826 Gbps — beyond any GigE or USB3 camera link. If the finished-camera path covers your pixels per second, start there and save the receiver design for the sensor that genuinely needs it. More interface arithmetic lives on the systems topic page, and the applications team will sanity-check a lane count or a camera shortlist — contact us.