CLHS Standard Development for MV Delivers its Own Lessons.

By my own admission, and as an engineer with more than a few years of design experience, I recognize there are always opportunities for learning. I’d like to share with you my most recent schooling – it was around CRC codes.

According to Wikipedia, “A Cyclic Redundancy Check (CRC) is an error-detection and correction code commonly used in digital networks”. CLHS includes CRC32 so the CLHS receiver can immediately ask for data resend if an error occurs. This same CRC is used in HSLINK, the proprietary protocol developed by Teledyne DALSA and on which Camera Link HS (CLHS) is based. The CRC has been used without issue during the development and deployment of HSLINK.

During the hardware verification of the CLHS IP core, I used a new hardware platform running a modified HSLINK design, and a proven platform running an early version of the committee CLHS IP core. Strange, the only packets I’m seeing are ones with CRC errors. Huh? What happened? Fortunately, the serdes device says there are no errors so we can rule out the new hardware platform. So, why are there CRC errors?

After many lab experiments and hours spent in an attempt to characterize and understand the problem, a midnight breakthrough…..there are no CRC errors when all the values sent in the packet are the same value! After my morning coffee, a colleague asks, “How useful is sending a single value per packet?” More digging, more web research, more CRC language learning (generator polynomial, degree n, quotient, etc) – deeper and deeper down the rabbit hole.

Here’s what I learned. CRCs are defined for single bit calculations but common calculation widths 8, 16, 32 or 64 bit wide implementations. Many free VHDL CRC code generators are available on the internet. Some feature controls for:

  • Input bit width
  • CRC calculation polynomial
  • Reverse calculation polynomial
  • Reverse input bit stream
  • Invert the CRC
  • Reverse the CRC
  • Initial value
  • Finish value.

Of course, the first CRC calculator I used didn’t have these features. Also, none of the calculators make it clear what the reference point is, so what does reverse really mean? The CRC used in the camera is 8 bit wide. My colleagues working on the IP core chose a 32-bit wide CRC implementation which was implemented in the frame grabber. The different widths, vague CRC requirements, and incomplete nature of some CRC code generators only compounded the problem of understanding how to fix the issue.

While CRC provided a challenge for me and my colleagues, in the end, this is a good thing. By spending the time to get it right prior to specification release, it means a more robust standard for the industry and less headache for those who adopt it. And in the end, isn’t that exactly what a committee delivering a “standard” should provide?



[Editor’s Note: This post was written prior to the May 8th specification release. Please visit the AIA website to learn more about the newly released Camera Link HSTM standard  and IP core. The CLHS specification  clarified the CRC requirements so that implementers who choose CRC algorithms of 8, 16, 32 or 64 bit input widths will end up with a link working the first time. Of course, an easier and faster method to a first-time-right solution is to license the AIA CLHS core which includes the CRC calculation.]


About Mike

Mike joined DALSA in 1989 and developed the company’s first generation cameras using only 32 flip flops for line scan or 64 flip flops for area array. Some of Mike’s designs are out of this world, including cameras on the International Space Station’s Canadarm2. Closer to home, Mike contributed to the initial development of Camera Link and now chairs the Camera Link HS committee. Seems Mike has a passion for camera to frame grabber communications and pioneering new ideas.
Posted on by Mike. This entry was posted in Cameras, Frame grabbers, Interface Standards, Machine Vision and tagged , , . Bookmark the permalink.

Comments are closed.