FMC-CLV: the Camera Link bridge you need when the next generation of FPGAs won’t talk to your old camera

Camera Link has been the default for fast, high-resolution imaging for a long time. Defense, scientific, and high-end industrial imaging all have a big installed base of it. Those cameras are still making pictures; they’re still pulling their weight, and in most shops they’re cheaper to keep than to replace.

The problem is the other half of the system. The processing side has moved on. AMD Versal and the newer low-voltage FPGAs are exactly where you want to be. But the I/O voltages those parts run at are different from what Camera Link LVDS was designed around. That one detail has stopped a lot of projects in their tracks, and it’s the reason we built the FMC-CLV.

The short version: the FMC-CLV is an HPC FMC mezzanine card that takes three Camera Link cameras on the front, and hands clean 80-bit pixel streams to the carrier over four serial transceivers. An on-board Artix-7 FPGA does the deserialization. Your main FPGA never has to do it. It just receives data. That’s the whole point of the card.

A lot of the “you should move to the newer standard” advice out there is right, and a lot of it is also quietly wrong. It’s right in spirit. It falls apart when you have a working system and a production line that depends on it.

Camera Link is a direct, low-latency, non-packet protocol. It separates video from control, it doesn’t put packet overhead on top of every pixel, and it was built with deterministic triggering in mind. For a lot of line-scan and high-area-scan work, that’s still the cleanest answer we know.

Camera Link bandwidth by mode:

Mode Image throughput Cables
Base 255 MB/s 1
Medium 510 MB/s 2
Full 680 MB/s 2
80-bit 850 MB/s 2

That’s the range from Automated Imaging Association’s own standard brochure.

The camera that fits your sensor, your frame rate, and your trigger discipline today is the one you should keep running. The interface question is really about the rest of the board, not the camera.

Here’s the honest comparison, and it’s worth laying out in one place because most write-ups skip one of the three or quietly conflate them.

Camera Link CoaXPress (CXP) GigE Vision
Max single-link throughput 850 MB/s, 80-bit mode 12.5 Gbit/s per lane, up to 50 Gbit/s with four lanes 115 MB/s on 1 GigE, up to 1.1 GB/s on 10 GigE
Practical cable length 4 to 10 m on 44-pin, under a meter on Mini-CL 25 to 60 m on coax 100 m on Cat 5e/6
Frame grabber required? Yes, or an FPGA deserializer Yes No, runs on a standard NIC
Power over cable Yes, PoCL Yes, PoCXP Yes, PoE
Where it wins High frame rates, low latency, wide installed base in embedded defense and imaging Highest bandwidth, longest cable, simplest cabling Multi-camera over switches, long runs, low cost

The three aren’t fighting over the same job. GigE Vision is the right answer when you have a lot of cameras, a long cable run, and the bandwidth works for your sensor. CoaXPress is the right answer when you need more bandwidth than anything else on the bus and the cable is long enough to matter. Camera Link is still the right answer when you’re doing what a lot of people actually do: high frame rates, low latency, tight trigger timing, and a sensor and interface that already work.

What Camera Link doesn’t have going for it right now is a modern frame grabber that works with modern FPGAs. That’s the gap, and it’s a gap that has very little to do with the camera.

It’s a gap in the processing side.

What the FMC-CLV actually does

Open the product page and the bullet list looks straightforward: an HPC FMC, three full 80-bit Camera Link interfaces, 6 independent PoCL channels, Camera Link v2.1 compliant, one EEPROM for VITA 57.1.

The interesting bit is what’s underneath that.

The card has an AMD Artix-7 FPGA on board (XC7A15T-1FGG484). Its job is to do the low-level Camera Link work: clock recovery, deserialization from the LVDS pair into the 80-bit parallel stream the camera is sending, and then to re-serialise that stream over four high-speed transceivers to the carrier.

That re-serialisation is the part that changes the integration. The carrier FPGA never has to speak LVDS. It receives a clean stream on a standard serial link. Which means it doesn’t matter what I/O voltage the carrier runs at, or what family it’s in. Versal and other low-I/O-voltage parts just work.

If you need the card to just pass the stream through, it ships in that mode. If you want it to pre-process the pixels before they hit the carrier, that firmware loads on the Artix-7, and the firmware itself is open so you can extend it: crop, filter, do a bit of analysis, whatever makes sense for your sensor. That moves a real chunk of your data budget out of the carrier and into the place where it belongs.

Three things to know about the front panel:

  • One interface comes in on a Mini-CameraLink connector.
  • Two interfaces come in on 5034803200 Molex FPC headers, pinout-compatible with the FMC-CL-AUX card we’ve shipped for years.
  • All three connectors carry PoCL. Six channels, each up to 0.5 A. That’s 3 W per camera, safely isolated.

The card is built in the US, and we made the connector pinout compatible with the older FMC-CL and FMC-CL-AUX hardware. If your lab already has that ecosystem, the cameras, cables, and brackets all keep working.

Why the new card makes development considerably easier

This is the part that we think is going to land with you, because it’s not a spec improvement; it’s a workload removal.

With the older FMC-CL, the deserialization lives on the carrier FPGA. You have to build the Camera Link receiver in your design. You have to make sure it fits the family, the I/O voltage, the timing closure, the clock recovery. If you’ve ever done that on a new FPGA, you know it’s not a small piece of RTL, and it’s not the piece you wanted to spend your quarter on.

The vendor IP for that job (our FC-CL core) exists, but it’s a core you have to integrate, test, and own. It’s a lot easier than writing it from scratch, and a lot harder than not having to do it.

The FMC-CLV flips that around. The deserialiser is on the mezzanine. Your carrier receives a clean 80-bit stream over a serial link, and it can be on virtually any modern carrier FPGA. The porting work is gone. The RTL you’d have written is off the bill.

The practical result is:

  • You can put the FMC-CLV on a Versal carrier board without writing a Camera Link receiver.
  • The Versal’s AI Engines and adaptive compute are available for the work your project actually cares about, instead of being spent on LVDS deskew and clock recovery.
  • If you need to pre-process on the card, the Artix-7 firmware is open, so your team can extend it without waiting on us to ship a change.

That last one is not a marketing line. The firmware is a real, editable artifact, and we’d rather have our customers put their own logic in there than wait on us to guess what their sensor needs.

FMC-CLV vs. FMC-CL, side by side

If you’re already using the FMC-CL, the upgrade is not a “newer is better” pitch. The two cards do different jobs, and you should pick the right one for the board you’re actually putting it on.

Aspect FMC-CL (current) FMC-CLV (new)
Where deserialisation happens On the carrier FPGA (via an IP core) On the FMC itself, on an on-board Artix-7
Link to carrier Parallel LVDS straight through the FMC connector Four serial transceivers, proprietary protocol
Carrier I/O voltage requirements Must match the camera’s LVDS voltage Agnostic. The serial link handles it.
Camera interfaces 2 full/Extended (up to 4 base connectors when you add the AUX card) 3 full 80-bit (1 Mini-CL, 2 Molex FPC, pinout-compatible with FMC-CL-AUX)
PoCL 12 V per interface 6 independent channels, 0.5 A each
Standard level Camera Link 1.x, VITA 57.1 Camera Link v2.1 with PoCL, VITA 57.1 EEPROM
Extra I/O 2× SATA-3 for direct disk None listed (pure CL translator)
Firmware options Frame-grabber IP on the carrier Pass-through or on-board frame grabber, chosen at order time

If your carrier FPGA is a Kintex or other 7-series part and the CL IP already fits, the FMC-CL is still a fine part and we still ship it. The FMC-CLV is the right answer when:

  • The carrier is a Versal or a similar low-I/O-voltage device.
  • You want the deserialiser to be off your critical path.
  • You want to pre-process on the card and free up the carrier for its real job.
  • You’re standardising on new carrier hardware and want the camera side to just work.

What we’re not going to do

We’re not going to tell you the FMC-CLV will replace the next CoaXPress card for a 16K line-scan sensor at 50 kHz. It will not. That’s a different problem, and the honest answer to that one is “coax is where you want to be.”

What the FMC-CLV does is protect the investment you already have. The camera that came with your sensor and is already integrated into your enclosure. The trigger logic that’s been in production for a year. The cable length that works in your rig.

Camera Link is not dead. It’s a working interface, and it still wins on a lot of the specs that matter in embedded imaging. The part of it that has been getting old is the interface to the processing side, and that’s what this card is for.

How to order

You can take the FMC-CLV in one of two modes. The default is a pass-through: the Artix-7 deserialises the Camera Link stream and puts it in a clean form on the carrier’s serial links. The other mode adds full frame-grabber firmware on the Artix-7, chosen at order time as the “G” option. Both are built in the US and ship with the VITA 57.1 EEPROM loaded.

The ordering format on the product page covers the rest. If you’re not sure which of the three camera interfaces to use, or which firmware mode fits your project, reach out to the team at Sundance DSP. We’d rather look at your sensor and trigger discipline before you commit to a firmware path than not.

Sources