SLVS-EC sensor to FPGA design-in: lanes, bytes and pixels

Your next high-speed global-shutter sensor probably arrives with an SLVS-EC output, and the sensor is the easy half of the design. The interface — Scalable Low-Voltage Signaling with an Embedded Clock — drives up to eight differential serial lanes into your board, and the FPGA has to catch every byte, rebuild the pixels and hand clean images to your processing logic. This explainer gives the lane-count arithmetic, the byte-to-pixel conversion plan, the transceiver and PCB checks, and a committed choice between licensing receiver IP, building the logic yourself, or skipping the design-in with a finished board-level camera.

What the sensor hands your FPGA

SLVS-EC replaced the S-LVDS outputs of the previous sensor generation. Each lane is a differential serial pair with the clock embedded in the data itself, so there is no dedicated clock lane and no clock-to-data skew to budget between lanes; every receiver lane recovers its own timing from the transitions it sees. The lane structure and the reason the embedded clock matters are covered in SLVS-EC lanes and the embedded clock.

Version 1.2 of the interface runs 1, 2, 4 or 8 lanes at 2.376 Gbit/s per lane, which is 19.008 Gbit/s of raw line rate on an 8-lane part. Against S-LVDS that is double the total output speed and more than three times the bandwidth per lane — the reason the same sensor generation runs faster on fewer lanes and tolerates longer cables. Receiver IP built to version 2.0 pushes the per-lane rate to 4.752–5 Gbit/s, and one receiver overview adds a 6-lane option to the usual set. A version 3.0 of the interface exists; your sensor's data sheet fixes the version, lane count and bit depth you design to.

The numbers that set your lane count

Payload is pure image data. Overhead is the sync words and the ECC/CRC checking that commercial receivers support; a 10% planning allowance covers both with room to spare. Pixel formats run from 8 to 14 bits, and payload scales linearly with depth — the same sensor at 8-bit moves 80% of its 10-bit payload.

Two lanes at the version 2.0 rate (row five) equal four lanes at version 1.2 (row three): the same aggregate on half the pins.

Worked example: 16 MP, 10-bit, 60 fps

Take a representative third-generation sensor: 5328 × 3040 pixels, 10-bit output, 60 frames per second. These are worked numbers, not one catalog part.

• Pixels per frame: 5328 × 3040 = 16,197,120 ≈ 16.2 MP
• Bits per frame: 16,197,120 × 10 = 161,971,200 bit
• Payload at 60 fps: 161,971,200 × 60 = 9,718,272,000 bit/s ≈ 9.72 Gbit/s

A 4-lane version 1.2 link carries 4 × 2.376 = 9.504 Gbit/s raw, or 8.55 Gbit/s after the allowance — 12% short of what the sensor produces. It does not close. Three configurations do:

1. 8 lanes at 2.376 Gbit/s. 19.008 Gbit/s raw, 17.1 Gbit/s usable; the sensor loads it to 57% (9.72 ÷ 17.1 = 0.57), leaving headroom for a faster mode later.
2. 4 lanes at 4.752 Gbit/s. The same 19.008 Gbit/s on half the pins, if both sensor and receiver support the version 2.0 rate.
3. 4 lanes at 2.376 Gbit/s with 8-bit output. 16,197,120 × 8 × 60 = 7.77 Gbit/s, which fits under 8.55 Gbit/s with 10% headroom.

The decision: on a version 1.2-only sensor, take option 1 and pay for eight transceivers, or option 3 if the algorithm tolerates 8-bit pixels. On a sensor that supports the doubled per-lane rate, option 2 is the clean design — the throughput of eight lanes on four pairs.

On the output side, 16.2 Mpixel at 60 fps is 971.8 Mpixel/s. As 4-pixel words that is 971.8 ÷ 4 = 243 MHz in the fabric; as 8-pixel words, 971.8 ÷ 8 = 121.5 MHz. Plan the 8-pixel path: 243 MHz is reachable but leaves little margin for everything else you will add.

Byte to pixel: what the receiver logic must do

How the sensor packs pixels into bytes is covered in how sensor bytes become pixels, and the general rule — decode before you process — is the subject of image bytes versus pixel data. On the FPGA side, each lane hands you a byte-aligned stream. At 2.376 Gbit/s that is 2376 ÷ 8 = 297 Mbyte/s per lane, and 1.188 GByte/s arriving across four lanes.

The receiver block does four jobs, in this order:

1. Deserialize each lane and align it to a byte boundary.
2. Reorder the lane-interleaved bytes back into the sensor's pixel sequence.
3. Unpack 8- to 14-bit pixels from the byte stream. A 10-bit pixel spans five bytes per four pixels, so this is repacking, not truncation.
4. Emit pixels with line-valid and frame-valid strobes, plus per-lane ECC/CRC status.

Commercial cores add dynamic mode changes and an AXI4 control interface, so your software reconfigures the sensor through the same block that receives it.

The transceiver's parallel width sets the fabric clock: at 2.376 Gbit/s, an 8-bit width means 2376 ÷ 8 = 297 MHz, a 16-bit width 148.5 MHz, and a 20-bit width 118.8 MHz. Take the 16-bit crossing and let the byte-to-pixel block widen to the 8-pixel output word.

Once pixels exist, handle black level before anything else: as black level in raw 12-bit images shows, darkness is not 0 DN, and the offset must be subtracted on your side.

Transceiver, clocking and PCB checks

• One transceiver per lane. Eight lanes consume eight multi-gigabit transceivers plus a reference-clock plan; that count, not logic cells, usually decides the FPGA part.
• Layout. Because every lane carries its own clock, lane-to-lane skew is absorbed by the receiver's alignment rather than by your trace matching — which is what lets SLVS-EC run longer cables than S-LVDS. Impedance-controlled pairs and length matching within each pair still matter.
• At 4.752 Gbit/s the margins halve. Keep traces short, return paths disciplined, and use connectors rated for the rate.
• Bring-up instrumentation. Enable the CRC/ECC checking and read the per-lane error counters before trusting a single image; a marginal lane shows up as one counter climbing while the others stay flat.

Buy the receiver IP or build the logic

Documented receiver cores cover version 1.2 with 1, 2, 4 or 8 lanes and 8- to 14-bit pixel output, version 2.0 at up to 5 Gbit/s per lane, and ports to low-power FPGA families running 2, 4 or 8 lanes at up to 4.752 Gbit/s with RAW 8/10/12 output. Evaluation packages bundle the core with a sensor board, a simulation environment and source-code examples, so the first image on your bench comes from reference code rather than a blank project.

Build the logic yourself only when two things are true at once: your team has brought up multi-gigabit serial links before, and the production volume pays for the time. Otherwise license the core. The risk is asymmetric — a first-time clock-recovery and word-alignment design debugs from zero, while a licensed core arrives against a known-good reference. If you have not committed to a sensor generation yet, compare the MIPI route first: checking lanes on a MIPI carrier board is the same design-in problem for CSI sensors, with cheaper IP and less throughput per lane.

When to skip the design-in and buy a camera

The design-in earns its cost when the sensor is the product: custom timing and sync, a size or power target no module meets, or a volume that repays the engineering. If the goal is images in your software, a finished board camera has already done everything above once. The build-vers-buy trade for modular camera modules works the same decision for volume products, and board-level camera sensor compatibility lists what to match before ordering.

Two ready-made routes from the board-level cameras range:

The USB3 module pairs a 1/1.8-inch global-shutter sensor with 120 fps output; the GigE module brings an M12 lens mount for compact builds. To compare sensors across finished cameras, start from USB3 machine vision camera selection.

If your system ends at a 10GigE area-scan camera instead of a custom sensor, the host still needs the card. The frame grabbers and interface cards category covers every camera link in the shop, and the finder at the accessories shop filters by interface and port count. A quad-port copper 10GbE NIC like the MV-GT2104 covers the host end.

Checklist before you commit

• The sensor data sheet states the SLVS-EC version, lane count, per-lane rate and bit depth; design to those numbers, not to the standard's maximums.
• Payload arithmetic redone at the maximum frame rate, with the 10% allowance.
• Transceiver count, reference-clock plan and fabric-clock plan written down before the FPGA is chosen.
• Receiver route chosen: a licensed core with its reference design, or a build plan with simulation from day one.
• Bring-up plan includes per-lane CRC/ECC counters and a short flex cable first.
• The finished-camera alternative priced, not just considered.

Next step: put the sensor's lane count and pixel rate through the system configurator, or bring the data sheet to our support and the decisions above become an orderable parts list.