Generate Camera Link FVAL LVAL DVAL timing for a frame grabber

You have image bytes sitting in FPGA memory — say a compressed file plus a header — and the device on the far side speaks Camera Link. The frame grabber on that side expects a camera: a pixel clock, three enable signals and a steady stream of pixel bytes on a schedule it can follow. This guide gives you the timing contract behind FVAL, LVAL and DVAL, the byte-packing arithmetic for the Base configuration, the serializer wiring and a bring-up sequence that ends with the grabber holding your exact bytes in host memory.

What do FVAL, LVAL and DVAL tell the frame grabber?

FVAL high marks the lines that belong to one frame, LVAL high marks the pixels that belong to one line, and DVAL high marks clocks whose data is new — the grabber counts LVAL-high periods as lines and pixel-clock edges inside them as pixels. In the Base configuration the three enables and one spare ride inside the same 28-bit word as the pixel data, so they are serialized, recovered and presented to the grabber's logic together with the bytes they qualify. Generate them from registers clocked by the same pixel clock as your data; never let a state machine on an unrelated clock drive them. The grabber's DMA turns LVAL-gated clock edges into a width × height window in host memory — how a frame grabber acquires an image follows that path step by step.

How many image bytes cross Base Camera Link per clock?

Three: the Base word carries three 8-bit pixel ports on every pixel clock, so a grabber running at its standard 66 MHz maximum can take up to 198 MB/s of pixel payload, and one-tap packing moves 66 MB/s at the same clock. The arithmetic: 24 pixel bits × 66,000,000 clocks/s = 1,584 Mbit/s = 198 MB/s across ports A, B and C together; one port alone is 8 bits × 66 MHz = 66 MB/s. Which bytes the grabber stores is set by its tap format, so the format you configure must match the packing you generate — that pairing is the core of what must match between a Camera Link source and a grabber. Bit order inside the word is fixed by the standard, but the order the three taps arrive in host memory is a per-grabber convention; get it wrong and the image slices, which is why the pixel-mapping checks for parallel camera buses apply here too.

Can I hold FVAL, LVAL and DVAL high until the image is done?

DVAL yes, FVAL and LVAL no: tie DVAL high and let FVAL and LVAL do the work, because a grabber that sees LVAL high for a whole frame counts the entire frame as one line of millions of pixels and the grab either fails or wraps. FVAL rises before the first active line and falls after the last, and that falling edge defines the end of the frame. LVAL high frames the active pixels of each line, and each LVAL-high period must be exactly one line of the configured width. DVAL exists for sources whose data is not fresh on every clock — very slow pipelines, gated architectures. Once your pixel clock is at least 20 MHz, every LVAL-high clock carries fresh data by construction, so tying DVAL high is standard practice, and most grabbers offer an ignore-DVAL option. Set that option before the first capture; a grabber left waiting for DVAL gating shows a grab that never completes.

What pixel clock and blanking should my FPGA generate?

Generate a free-running pixel clock between 20 and 66 MHz (85 only on full-rate-capable hardware), blank 10-20% of each line with LVAL low and keep at least one line period idle between frames — the clock never stops, the enables do. Below about 20 MHz the serializer/deserializer pair stops locking reliably, so do not slow the clock to match a slow payload; pad with blanking instead. Blanking is signalled by LVAL low while data sits at any value, never by gating the clock: a gated clock drops the receiver out of lock.

The 10-20% blanking figure is a starting point, not a limit written in the standard: the real requirement is clean LVAL edges and room for the grabber's line counter and DMA to reset between lines. Shrink the blanking while the grabbed width and height still come out exact; grow it the moment lines drop.

What about my JPEG 2000 bytes instead of raw pixels?

The grabber stores bytes, it never decodes: you can stream JPEG 2000 codestream bytes as pseudo-pixels and reassemble the file in host memory, but if the far end must show or measure real pixels you have to decompress before the serializer. Decision one — the far end stores or forwards the file: set the grabber's width and height so width × height covers the file, pad the last line to full width, and rebuild the file from the grabbed buffer. Put the metadata header in the first bytes of the frame, or send it over the Base serial channel, a low-rate asynchronous port intended for camera control — fine for a few hundred bytes, useless for payload. Over the 26.0 MB/s example stream, a 2.0 MB file lands in 2,000,000 / 26,000,000 = 77 ms. Decision two — the far end processes pixels: decompress upstream on a host and store raw pixels in the FPGA. JPEG 2000 is wavelet-based, and a full decoder in FPGA fabric is a serious project. Mind the memory bill either way: a raw 1024 × 768 frame is 786,432 bytes, beyond most FPGA block RAM, so buffer in external memory or stream straight from storage.

Do I need a serializer chip between the FPGA and the cable?

In practice yes: the grabber's input is a Camera Link deserializer expecting four LVDS data pairs plus a clock pair, so you either hang a Camera Link serializer chip off a 28-bit parallel bus or replicate the 7:1 serialization in FPGA LVDS logic. The chip route is the fast one: the serializer takes your 28-bit word plus the pixel clock and emits the four data pairs, and the bit-to-pair assignment is fixed — copy the table from the Camera Link standard and your serializer's datasheet rather than improvising one. The logic route works too: each pair carries 7 bits per pixel clock, so 462 Mbit/s per pair at 66 MHz, within reach of ordinary LVDS output banks, but then you own the mapping, the levels and the timing, and the grabber will not forgive a wrong assignment. The signaling fundamentals are the same ones that matter for an LVDS line scan camera on a frame grabber. Either way, connect through a standard Camera Link cable and keep the first bring-up cable short.

What is the build sequence, step by step?

Bring the clock up first, prove one line, then one frame, then the payload: sequencing the bring-up this way isolates a missing lock, a width mismatch and a byte-order fault to different steps instead of one opaque failure. You need the FPGA source (with serializer or LVDS logic), a Camera Link cable, a Camera Link frame grabber and its SDK on a host PC.

1. Fix the pixel clock at 33 MHz, free-running, and confirm the grabber's status view reports the detected clock before you attempt a grab.
2. Configure the grabber: one-tap 8-bit mono (or three-tap if you pack three bytes per clock), ignore DVAL, width 1024, height 768.
3. Send a one-line frame: FVAL high for exactly one LVAL period carrying a repeating 0-255 byte ramp. If the grabbed line shows the ramp in order, your per-clock bit mapping is right.
4. Extend to the full frame: FVAL high across 768 LVAL periods with your blanking, and check the grabber reports exactly 768 lines.
5. Swap in the real payload — raw pixels or packed compressed bytes — and pad the final line to full width.
6. Compare a checksum of the grabbed buffer against the source bytes; only then call the transport done.

How do I verify the stream before I trust it?

Trust three numbers: the grabber's detected pixel clock within 1% of your setting, a grabbed width and height exactly equal to your configuration, and a host-side checksum that matches the source file — then the transport is proven end to end. The byte ramp diagnoses most faults by eye: a stuck data bit shows as vertical banding with a one-byte period, a swapped port pair shows as periodic slicing, and missing blanking shows as short or dropped lines. Read back the detected pixel clock and LVAL rate from the grabber's status view and compare them with your settings. If the grabber reports no signal at all, work the physical chain — cable seating, power, clock presence — as in what to check when a frame grabber cannot detect a video source. If it detects the signal but refuses to configure, the detection path is usually waiting for a camera to answer a serial query, which Camera Link frame grabber detection and integration explains.

Which frame grabber should I stream into?

Any frame grabber whose Camera Link input matches your configuration works as the receiver — set its tap format, width, height and clock range to what you generate — and the Hikrobot MV-GC1102IOL is the Camera Link card in the frame grabbers category for bench bring-up. For other interfaces and port counts, the acquisition accessories finder sorts the cards by protocol.

Once one frame lands intact, everything downstream — display, decode, measurement — is ordinary host work. If you are planning the whole acquisition chain rather than one link, the systems topic page collects the signal-level guides, and the configurator's extras step pairs the card with cables and host-side parts.