Frame grabber FPGA types: what the chip does for your acquisition

A frame grabber's spec sheet leads with interface, ports and bandwidth, and often stays quiet about the FPGA that actually runs the card. The chip is what decodes the camera stream, times your triggers, applies lookup tables and shading correction before a frame reaches RAM, and moves everything into host memory by direct memory access. That makes the chip type a purchasing decision, not a curiosity: choose the card by link budget and documented features, and the family follows. This page gives you the per-link rates, the arithmetic to size a card, a worked line-scan example, and three ways to identify the chip without opening the PC.

What the FPGA does during acquisition

The FPGA sits between the camera cable and the PCIe bus. Four of its jobs decide whether your images arrive intact and on time:

• Decoding. It deserializes the incoming link — CoaXPress connections, Camera Link channel pairs or Ethernet packets — and rebuilds the pixel stream at line rate. The full decode-to-DMA path is walked stage by stage in frame grabber image acquisition for Camera Link and CoaXPress.
• Timing. It debounces trigger inputs and issues exposure or line triggers from hardware, on a microsecond scale, no matter how busy the host CPU is. The grabber can even generate the camera's pulse train itself, as frame grabber trigger pulse trains without a function generator shows.
• Preprocessing. Lookup tables, flat-field shading correction, gamma, thresholding and line averaging run on the pixel stream in real time, so the corrected image is what lands in memory. Lookup-table control can travel over the grabber's serial line to the camera, as camera lookup table control through frame grabber serial details.
• DMA. It writes frames straight into host memory, and on some paths onward to GPU memory, so the CPU never copies pixels and the load on the host drops.

A standard network port accepts a GigE camera but does none of this. The difference between a plain NIC and a frame grabber is almost entirely the FPGA and the firmware compiled into it.

Why the chip family matters, and why the name should not decide

An FPGA family is a generation of silicon, and it bounds three things:

• Transceiver rate. Each high-speed transceiver carries a fixed maximum per lane, and carrying CoaXPress at CXP-12 rates (12.5 Gbit/s per connection) takes a faster transceiver class than CXP-6 (6.25 Gbit/s per connection).
• Logic and on-chip memory. The vendor compiles its preprocessing applets against these resources; a bigger family holds deeper pipelines at full line rate.
• Headroom. A newer family leaves the vendor room to add functions in firmware later.

What the family does not set is your feature list. Two cards on the same chip can expose different applets, because firmware, not silicon, defines what runs. Filter on the documented bandwidth and the documented function list, and treat the family as headroom rather than a feature. If the data sheet prints the bandwidth and the functions you need, you have found your card.

The numbers that decide: link rates and the 80 percent rule

Every sizing decision reduces to one comparison: the camera's data rate against the link's usable budget. The rate is fixed by the camera. The budget is the link rate with 20 percent set aside for control traffic, packet gaps and short bursts:

Camera Link assumes the standard's 85 MHz maximum pixel clock; the other rates come from the interface standards themselves. Every card in the frame grabber category prints its interface and port count, and those two values set the budget you can actually buy.

Worked example: links for an 8192-pixel, 12-bit line-scan camera at 80 kHz

Inputs, and where each comes from:

• 8,192 pixels per line at a 12.5 µm pitch — a typical wide line-scan sensor; substitute your camera's numbers.
• Transport speed of 1 m/s — the web moves one metre per second under the camera.
• Line rate of 80,000 lines/s — from the rule above: 1 m/s ÷ 12.5 µm = 80,000 lines/s; the line-scan camera line rate calculator runs this from your own speed and pitch.
• 12 bits per pixel — the camera's 12-bit output mode.
• Link candidates of CXP-6 (6.25 Gbit/s per connection) and CXP-12 (12.5 Gbit/s per connection) — from the CoaXPress standard.

The rule in words: multiply pixels, bits and lines to get the camera's data rate, then compare it with the 80 percent budget of the connection count you plan to use.

The arithmetic:

• Field width: 8,192 × 12.5 µm = 102.4 mm
• Bits per line: 8,192 × 12 = 98,304 bit
• Data rate: 98,304 bit × 80,000 lines/s = 7,864,320,000 bit/s ≈ 7.86 Gbit/s ≈ 983 MB/s
• One CXP-6 connection: 0.8 × 6.25 Gbit/s = 5.0 Gbit/s; 7.86 > 5.0, so it fails
• Two CXP-6 connections: 2 × 5.0 = 10 Gbit/s; 7.86 ≤ 10, so it passes with about 21 percent of the budget unused
• One CXP-12 connection: 0.8 × 12.5 = 10 Gbit/s, so it passes the same way
• Host side: 983 MB/s fits a PCIe Gen2 x4 slot (about 2 GB/s payload), and two such cameras use half of a Gen3 x4 path (about 3.9 GB/s)

Decision: above 5.0 Gbit/s of camera data, a single CXP-6 connection is out. At 7.86 Gbit/s, run the camera as two CXP-6 connections, or on one connection if the camera supports CXP-12.

An octo-connection CXP-6 card carries this camera with room to spare:

Six connections stay free for further cameras, each sized the same way. Fix the port map in software so every camera lands on the port you planned, the way assign cameras to ports reliably in a multi-camera system describes.

How to find the FPGA type without opening the PC

The family is documented, not something to discover with a screwdriver. Try these in order:

1. The card's data sheet. Vendors print the FPGA family there, plus the more useful line beside it: the firmware or applet feature list, which is what actually runs on your images.
2. The SDK's board information. A grabber's device query reports the card name, firmware and applet versions at runtime; the release notes map those versions to functions. When an update adds a preprocessing step, it shows here first.
3. The part number. Grabber part numbers encode interface, memory and variant; identify a frame grabber model from its part numbers decodes the scheme.

What the FPGA does not change

• The link ceiling. Silicon never lifts a link above its standard: a CXP-6 connection carries 6.25 Gbit/s on every card that has it.
• Host processing limits. If frames arrive faster than your software digests them, that is a pipeline problem: acquisition faster than processing: fix the frame rate gap works the fix, and camera burst capture faster than link bandwidth covers short overruns.
• Whether the card has an FPGA at all. A card built on a standard Ethernet controller, such as the LS-FGB-0004 PCIe x4 card with 4 PoE Gigabit ports, moves frames and leaves every pixel operation to the host. That is the right part when a GPU does the processing and you need PoE; confirm what your port provides with does my camera support PoE.

The decision, per case

With the budget computed, the common cases resolve quickly:

• A line-scan camera around 7.9 Gbit/s: two CXP-6 connections. The octo-connection MV-GX1008 carries it with six connections to spare.
• Several high-bandwidth cameras on one card: the MV-GS1104F-DF supports 40G total bandwidth across its 4 ports, with a DataForwarding function for pipelines that pass data onward. Four cameras at 7.86 Gbit/s each total 31.4 Gbit/s, inside the 32 Gbit/s that 40G leaves at 80 percent.
• One or two 10GigE cameras: the MV-GT1102P, a dual 10GigE frame grabber with 2 ports, runs one camera per port.
• A cluster of GigE cameras: the MV-GE1104, a 4-port GigE frame grabber, puts four GigE links and their DMA in one slot.
• Camera Link cameras: grabbers such as the MV-GC1102IOL serve that path; match the supported configuration width to the camera, then check the camera-side requirements in Camera Link camera and frame grabber compatibility.

The same three cards side by side:

Checks before you order

• Compute the camera data rate (pixels × bits × lines per second) and apply the 80 percent budget; write down the connection count the result forces.
• Check that the camera's multi-connection or link-aggregation mode splits the stream the way the grabber's ports expect.
• Check the host slot's generation and free lanes: a 983 MB/s camera needs PCIe Gen2 x4 or better, and two of them fit a Gen3 x4 path with margin.
• List the preprocessing functions you actually run, and match them to the card's documented firmware feature list.
• Count the trigger needs: inputs, debounce, encoder support, and outputs if the grabber must generate pulse trains.
• Confirm the SDK supports your operating system before the card arrives; a firmware and runtime mismatch is a known first-boot failure, as frame grabber initialization failure: fix firmware and runtime details.

For the wider camera-to-card questions — resolution upgrades, interface chains, driver layers — start from will your camera work with a frame grabber and browse the acquisition guides under the systems topic. Filter the frame grabber finder by interface and ports, or run the system configurator from the extras step once the camera side is fixed; free expert support with every order covers the cases that sit between two cards.