CRC testing in video applications
Introduction
Quantifying the impact of a small engineering change in a complex video signal chain can often be a thankless task; evaluating whether a lower cost digital video cable has degraded system performance; whether a power supply tweak has increased the system’s jitter tolerance; whether an alternate PLL configuration has provided greater power supply noise immunity; typical challenges which the design and production engineers of today’s video product design and manufacturers must overcome.
Although numerous video evaluation tools are available to assist in such activities, these often consume significant portions of capital budgets, take time to setup, require training to operate properly, and offer results which can be difficult to interpret. A simple error detection algorithm such as a Cyclic Redundancy Check (CRC) can be used as an effective tool, despite a number of limitations, in advance of investing significant efforts in perfecting systems using the more complicated and expensive evaluation tools; especially when time to market, cost and resources are important considerations.
Digital Video Systems
The proliferation of digital video transmission media for consumer, professional and automotive applications in recent years has triggered a change in the focus for many video product design and manufacturers; the requirement to achieve superior analog performance has plateaued and has been superseded with a demand to achieve the highest possible digital data rates possible. These transmission media include DVI, HDMI, LVDS, MHL and APIX.
The growth of HDMI has been one of the primary drivers in this race to higher data rates. At its inception, support for video transmission at up to 1.65GHz facilitated the transfer of 1080p video (1920 pixels x 1080 lines) with an 8-bit colour depth – a video format offering over ten times the video resolution of analog NTSC video. Further developments to the HDMI specification in recent years have seen the data rate of the maximum supported video resolution stretched through 2.25GHz to 3GHz with further increases most likely on the cards in future specification revisions (see Figure 1).
The Ultra HD 3GHz maximum video resolution specified in HDMI 1.4a (4k x 2k @ 24 Hz, 25 Hz or 30 Hz) enables cinema style clarity in the home entertainment system. A single frame of 4k x 2k data is comprised of 4096 pixels and 2160 lines; with 24 frames being transferred every second, 3GHz video sources and sinks must be capable of transmitting or receiving over 8 million pixels of active video data every second. No mean feat…
Figure 1: The Evolution of Video Formats
With the increased magnitude of data being transferred across the link shrinking the period of each bit transferred across the link, the prospect of bit errors occurring on the link increases. But what of the occasional random bit error? It may be the case that the random bit error occurs during the active video region which results in an incorrect pixel on the display.
However, if that random bit error occurs during the control period in the HDMI stream, the synchronisation data may be disturbed which could result in a disturbance on the screen (e.g. a horizontal or vertical streak or picture flash). This risk is compounded when considered in conjunction with the data encryption protocol employed by the HDMI specification; High Definition Content Protection (HDCP).
HDCP is employed to protect high-value video content as it is transmitted across a video link, preventing the unlawful copying of movie and television content whilst it is transmitted between a source device (e.g. a DVD player or set top box) and a sink device (e.g. a television). Establishing a HDCP link between a source device and sink device can take over 2 seconds and is maintained by transferring a key between the source and sink devices every 2 seconds.
Should the aforementioned random bit error cause the picture to flash triggering a break in the authenticated link, the user may see "snow noise" (an indication that HDCP authentication has failed – see Figure 2). It could then take over 2 seconds for the authenticated link to be re-established; a contributor to user frustration and to field returns.
Figure 2: A Sample of Original Content and HDCP Snow Noise
Modern video signal chains can be comprised of a host of different devices. For example, the bill of materials of a Audio Video Receiver (AVR) can include a HDMI buffers, a HDMI mux, a HDMI and analog video receiver, a HDMI transmitter and a video
signal processors integrating scaling, de-interlacing and on-screen display functions. To add further complication, these devices can also often be sourced from a broad range of semiconductor vendors.
Developing a reliable video signal chain incorporating all of these devices, supporting video formats with such high data rates, is becoming a significant challenge for video product design and manufacturers. Cable quality, power supply design, signal integrity, PCB quality, and silicon settings need to be at their absolute optimum to successfully support such video formats. But how can a video product design and manufacturer easily evaluate the impact of the tweaks to any of the previously mentioned system elements?
Cyclic Redundancy Checks
The Cyclic Redundancy Check (CRC) is a redundancy check which was invented by W. Wesley Patterson in 1961.1 It can be employed to detect errors in digital data and is used primarily in data transmission, e.g., a 32-bit CRC is employed in the transmission of data over Ethernet. Limitations of the CRC are that a CRC can only detect errors in digital data; it cannot correct them once detected; this capability is confined to more complicated algorithms such as the Error Correcting Code (ECC) or the Forward Error Correction (FEC); and that a CRC cannot identify the number of errors in the received data.
Many different CRC implementations exist but the same basic premise persists; the data transmitter calculates and appends a number of check bits (often referred to as a checksum) to the data before it is transmitted. This is often implemented by dividing the data to be transmitted by a fixed binary number; the remainder of the division then forms the checksum. The receiver can determine whether or not the check bits agree with the data using a reverse of the transmitter side calculation.
If the checksum does not agree with the data received, the receiver can conclude that an error occurred in the data transmission and request a retransmission of the data.
A video signal chain does not mimic the data transmitter and receiver pair outlined above; it is unidirectional and so it is not feasible for a video display (e.g. television) to request a video source (e.g. a Bluray player) to re-transmit an incorrectly received data frame. To account for this asymmetry, a CRC must be implemented in a slightly different manner to suit a video signal chain. The obvious location in the video signal chain to perform the analysis is in the video receiver given the limitation already outlined. The video receiver can apply a CRC to subsequent frames of incoming video data with the only caveat being that the incoming video data must be static in its content, e.g., a SMPTE video test pattern or DVD player menu screen.
The CRC is constructed using the known polynomial (e.g. x16 + x12 + x5 + 1) as the divisor, the video data for the selected frame or number of frames as the numerator and the remainder as the means of testing whether the video data has changed. The
known polynomial never changes; If the incoming video doesn’t change (i.e., a static pattern with no bit errors), then the remainder should always be constant (see Equation 1).
Equation 1: Video CRC Calculation
If the remainder stays the same for subsequent frames, then the frames are the same and the system is operating at what can be referred to as a "sweet spot"; a combination of hardware and software settings which yields optimum system performance. If the checksums for subsequent frames do not match, then the frames are different and the system needs to be optimised.
CRCs – The Alternatives
Bit error rate testing is an interesting alternative to CRC testing, it’s major benefit being the fact that it can assist in quantifying the extent to which data has been compromised. A bit error rate test requires a reference pattern to be input into a system; the output of the system is analysed in comparison with the reference pattern and the number of differences gives an indication of the number of bit errors which have occurred. If the output pattern matches the reference pattern exactly, no bit errors have occurred and the system is performing at its "sweet spot"; if the output pattern differs from the reference pattern, the number of differences provides some indication of the extent to which the data has been compromised.
Although bit error rate testing is a very powerful tool, the requirement to input and be able to analyse the output against a known pattern is also one of its major weaknesses. The need for a reference pattern, which provides the ability to quantify the level of data degradation, reduces its flexibility significantly. A bit error rate test can only be applied to a known pattern; a CRC can be applied to any static data pattern meaning that it can employed on the fly in the range of situations.
These situations range from the development and evaluation of a prototype system, through to the end of line testing of a product and to the in-field debug of customer issues returns.
The ADV7850
The ADV7850 is Analog Devices’ first complete AV front end device targeted at the consumer and professional audio/video markets. The part incorporates a 4-input HDMI receiver which supports video resolutions up to 4k x 2k @ 30 Hz; a video and graphics digitizer capable of operating at up to 162MHz; a high-speed serial video output; a 3D comb video decoder and an audio codec.
In addition to being a comprehensive single-chip audio/video front end, the ADV7850 also incorporates a frame checker which employs CRCs. The frame checker is located before the ADV7850 output towards the end of the ADV7850’s signal chain (see Figure 3) allowing the entire video path for a HDMI input to be checked; this feature is not available for analog inputs due to least significant bit (LSB) errors introduced by the analog-to-digital converters (ADCs) which can run at up to 170MHz.
Figure 3: ADV7850
The frame checker in the ADV7850 was designed, utilising the CRC-16-CCITT polynomial (x16 + x12 + x5 + 1), to analyse a user configurable number of frames and is enabled via a single I2C bit.2 Once enabled, the frame checker computes a checksum for each of a user configurable number of frames (up to 255) by analysing every data pixel on each video channel; green, red and blue (ranging from 300,000 pixels for 480p to 8,000,000 pixels for 4k x 2k). The number of frames to be analysed is
configured via an I2C control.
Figure 4: CRC Computation
When the frame checker has completed its analysis, it reports a set of results for each of the channels (HDMI transfers data on red, green and blue channels) via I2C.2 As already outlined, for a static input, performing multiple iterations of the CRC should provide a consistent result; a single pixel difference between two frames (up to 16,000,000 pixels of data), will cause different checksum results. Whether the pixel difference occurs due to noise on the source, noise induced intermittently in the transmission medium or due to the incorrect configuration of the ADV7850, the error will be indicated.
The system designer can then optimise the system and repeat the test.
1 Peterson, W. W. and Brown, D. T. (January 1961). "Cyclic Codes for Error Detection". Proceedings of the IRE 49 (1): 228-235
2 I2C refers to a communications protocol originally developed by Phillips Semiconductors (now NXP Semiconductors).
About the authors
Michael Corrigan, Senior Design Evaluation Engineer
Michael Corrigan is a Senior Design Evaluation Engineer within the DVP group of Analog Devices. He qualified with an honours Bachelor’s Degree in Electrical and Electronic for Cork Institute of Technology in 2002. Michael joined Analog in 2007 having previously worked in EMC and GE security.
Joe Triggs, Applications Engineer
Joe Triggs is an applications engineer in the Digital Video Products group at Analog Devices (Limerick, Ireland). He has worked for the company since 2007 and is responsible for HDMI receiver, transmitter, transceiver and video signal processor
products. He earned his primary BEng degree from University College of Cork in 2002 before continuing to complete his MEng through research at the University of Limerick in 2004. He recently completed his MBA at the University of Limerick’s Kemmy
Business School.
If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :
