What’s New in CLHS Version 1.2?

For many years, CMOS imaging technology has enabled low-power, low-cost, and high-speed imaging across a wide range of vision applications. These faster image sensors enable increased inspection rates and more productivity on the factory floor and drive demand from machine vision customers.  The telecom market has ever-increasing bandwidth requirements driving fiber optic technology to higher bandwidth and lower power. And FPGA vendors develop technology to meet the ever-increasing telecom bandwidth needs. Camera Link High Speed  (CLHS) version 1.2 recognizes the cost improvements and the market need for speed and, as a result, has introduced the 25 Gbps speed for its X protocol. With this speed increase, CLHS is the only standard that offers 0 jitter bidirectional triggers and very low latency (<0.5 µs) bidirectional general purpose input/output (GPIO).

Backward Compatibility with 10G

The even better news is that CLHS 25 Gbps (25G) is backward compatible to 10 Gbps (10G) CLHS. The optical engines that work at 25G also work at 10G, and the CLHS discovery process is defined to start at the 10G speed.  At power on, the camera and frame grabber begin at 10G and establish a command channel. The frame grabber then reads the mandatory register list and learns that the camera supports the 25G speed.  The frame grabber follows the defined procedure to command the camera to 25G and drops the link and then the camera and frame grabber reestablish the link at 25G. If the link fails to establish after a time, the two devices revert to 10G and reestablish the link in a fail-safe manner.

The Intellectual Property (IP) core, or chunks of reusable logic, remains unchanged from 10G to 25G, and all the rules in version 1.2 remain unchanged from previous versions. CLHS is a very stable platform to develop products on. This backward compatibility means that 25G products can be developed and used with proven 10G products, reducing the risk of debugging two new products having new protocol technology.  For customers with installed 10G products, either the camera or frame grabber can be upgraded while still using the old device and installed fiber optic cables. 10G products will continue to be lower cost and can be mixed and matched with 25G CLHS products by users of the technology. CLHS 1.2 includes the SFP+ (10G), QSFP+ (10G), SFP28, and QSFP28/MPO optical connectors to support the 25 Gbps speed. The telecom market continues to reduce the price and power of the SFP28 and QSFP28. Available off-the-shelf, MPO (QSFP+/28) to quad LC cables allow cameras using the QSFP/MPO connector to hook up to existing quad SFP+ frame grabbers.

CLHS is designed to support up to eight cables, which for QSFP28 would be 800 Gbps, roughly 96 GByte/sec of effective data throughput. CLHS also supports sending data to individual processing engines by providing extra data at the image seams so that parallel processing can be carried out independently.  Facilities in the protocol synchronize multiple frame grabbers to ensure the lower bandwidth processed images can be brought back together correctly to form complete images.

The CLHS PCS uses 64/66 encoding with forward error correction. This approach results in an effective bandwidth of 1200 Mbyte/sec/lane at 10G and 3 GByte/sec/lane at 25G. CLHS has one of the lowest protocol overheads of any packet-based standard and the forward error correction can correct up to a burst of 11 bits in 2000 bits. Each message type is assigned a priority, with higher priority messages interrupting lower priority messages, and once the higher priority message completes the lower priority message continues. This behavior optimizes bandwidth utilization and reduces latencies for the trigger and GPIO signals.

FPGA Implementation

CLHS product is very easy to develop using the IP core available from A3 (Ann Arbor, MI, USA; www.automate.org). The core (www.automate.org/a3-content/vision-standards-camera-link-hs) is delivered as VHDL source code and supported by dedicated volunteers. The core consists of the X IP core and PCS (Physical Coding Sublayer) for both the camera and the frame grabber. The figure below shows the overview of the hookup and the FPGA operating frequencies for 10G and 25G. FPGAs with 25G serdes can close timing at the 402 MHz operating rate used by the forward error correcting PCS.

CLHS IP core top level overview with FPGA fabric operating at speeds for 10G and 25G.Courtesy of Teledyne Dalsa

The core and PCS do not include any manufacturer-specific modules and infer block rams for video and command channels. The CLHS IP has been compiled in Xilinx (San Jose, CA, USA; www.xilinx.com) (AMD), Altera (Santa Clara, CA, USA; www.intel.com), and PolarFire (Chandler, AZ, USA; www.microchip.com) FPGAs. The user is responsible for instantiating phase-locked loops (PLLs) and the transceiver function. A more detailed look at the features of the core and the user responsibilities is shown in Figure 2.

As mentioned earlier, discovery at power on occurs at 10 Gbps and can be negotiated to 25 Gbps if both ends of the cable are capable. At the FPGA implementation level, this means that the 64-to-1 transceiver first is run with a fabric interface speed of 161.13 MHz, and when the higher speed is negotiated and the link dropped, the fabric interface speed becomes 402.83 MHz on reconnection. Different FPGAs offer different methods to achieve the change in speed, but the interface remains 64-to-1. Usually, a PLL is needed to take the 161.13 and create a 156.25 MHz clock. The PLL will need to be reset once the new fabric speeds are stable.

IP Core Features Remain the Same

As shown in Figure 2, the core exposes five virtual channels to the user’s logic. If a user doesn’t need a function, like a camera sending GPIO back to the host, then the module inputs can be tied low, and the send request tied low, and the synthesis tool eliminates those resources. The Pulse (trigger), GPIO, and revision message are synchronous to the TX/RX clock space (156/390 MHz) and present parallel input/output (I/O) ports asserting a single bit for one clock when it is desired to send the data, or the data is received on the associated channel.

The video and command channel operate on a user-defined clock I/O, which can be defined optimally for the user’s system. The command channel has a “guaranteed” delivery feature and is flow controlled at the link layer. The PCS has error correction, but a throwback to the M protocol that only had error detection with data resend, the X protocol also includes CRC error detection and automatic data resend for the command channel, up to 10 tries to send the command message. The user will write generic control protocol  (GenCP ) and GenIcam data into the command buffer using the command channel’s write enable control, and when the command is finished, assert the command send request input for one command clock period. The CLHS IP core will assert the TXcommandBusy signal and will schedule the command message for transmission after Pulse (trigger), link layer acknowledge, GPIO, and video messages.  When the receiver gets the message without error, the CLHS IP returns an acknowledge message, which tells the transmitter to cancel the resend timeout and wait. The transmitter will retransmit the message should the receiver return a not-acknowledge message. The receiving microcontroller was alerted to a new message by the message valid strobe and reads the message from the command buffer, which causes the CLHS IP to send the buffer an empty acknowledge message. This causes the TXcommandBusy signal to be reset ensuring flow control at the link layer. GenCP also states that only one message should be in progress at any one time and a transaction completes with a GenCP status acknowledgment or requested data. 

Video messages also use buffers, and write/read enables to store/retrieve messages to/from the core. Like the command message, a send request or new message ready pulse is asserted. Unlike the command channel, video doesn’t have automatic resend as the forward error correction is sufficient to handle occasional transmission errors.

CLHS Rev 1.2 allows for the use of 25G telecom technology to meet customer demands for increased speed. Backward compatibility enables developers to debug 25G with reduced risk as proven 10G products can be used to verify the new product operation before switching to higher speeds. Customers can optimize inspection system costs, by mixing lower-cost 10G products with 25G products. In the future, the CLHS committee has plans to move to 50G using the existing X core as the base technology, maintaining a low-risk development path.