Abstract

Automating and identifying the impact of a small engineering change in a complex video signal chain can be a thankless task. Evaluating whether a lower cost digital video cable may degrade system performance, whether a power supply tweak has increased the system’s jitter tolerance, or whether an alternate PLL configuration has provided greater power supply noise immunity are all typical challenges that 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 set up, require training to operate properly, and offer results that can be difficult to interpret. A simple error detection algorithm such as a cyclic redundancy check (CRC) can be used as a rough but effective tool in advance of investing significant efforts in perfecting systems using the more complicated and expensive evaluation tools—especially when automation, time to market, and cost 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 superceded 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.65 GHz facilitated the transfer of 1080p video (1920 pixels × 1080 lines) with an 8-bit color depth—a video format offering over 10× 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.25 GHz to 3 GHz with further increases most likely on the cards in future specification revisions (see Figure 1).

 

 

 

The ultraHD 3 GHz maximum video resolution specified in HDMI 1.4a (4k × 2k at 24 Hz, 25 Hz, or 30 Hz) enables cinema style clarity in the home entertainment system. A single frame of 4k × 2k data is comprised of 4096 pixels and 2160 lines with 24 frames being transferred every second, which means that 3 GHz video sources and sinks must be capable of transmitting or receiving over 8 million pixels of active video data every second. No mean feat.

With the increased quantity of data being transferred across the link shrinking the period of each bit transferred, the prospect of bit errors occurring on the link increases. What happens when a series of bit errors occurs? It may be the case that the bit errors occur during the active video region, which results in some pixels that are displayed incorrectly. However, if that series of bit errors occurs during the control period in the HDMI stream, the synchronization data may be disturbed; this could result in a disturbance on the screen such as 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 while it is transmitted between a source device (DVD player or set-top box) and a sink device (such as a television). The time involved in establishing an HDCP link between a source device and a sink device can range from less than a second up to several seconds. Once an HDCP link is established, the picture is made visible on the sink device. The link is maintained by transferring a link integrity check between the sink and source devices every couple of seconds or a certain number of video frames thereafter. Should the aforementioned series of bit errors cause the picture to flash, triggering the authenticated link needed to be reestablished, the user may see snow noise—an indication that HDCP authentication has failed—on their screen (as shown in Figure 2). It could then take up to several seconds for the authenticated link to be reestablished and for the picture to return—contributing to user frustration and to field returns.

 

 

 

Modern video signal chains are typically comprised of a host of different devices. For example, the bill of materials of an audio video receiver (AVR)can include HDMI buffers, HDMI muxes, HDMI and analog video receivers, HDMI transmitters and video signal processors integrating scaling, deinterlacing, and on-screen display functions. To add further complication, these devices can often be sourced from a broad range of semiconductor vendors. Developing a reliable video signal chain incorporating all of these devices and 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 manufacturer easily evaluate the impact of the tweaks to any such system elements?

Cyclic Redundancy Checks

The cyclic redundancy check (CRC) is a redundancy check that was invented by Wesley Patterson in 1961.¹ It can be employed to detect errors in digital data and is used primarily in data transmission systems; for example, a 32-bit CRC is employed in the transmission of data over Ethernet. The 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 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 an inverse of the transmitter side calculation. If the checksum calculated on the receiver side does not match that calculated on the transmitter side, 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 typical data transmitter and receiver pair previously outlined. However, in a video signal chain the link is unidirectional so it is not feasible for a video sink (such as television) to request a video source (such as a Blu-ray player) to retransmit an incorrectly received data frame. To account for this asymmetry, a CRC must be implemented in a slightly different manner. 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—for example, an SMPTE video test pattern or DVD player menu screen.

The CRC is constructed using the known polynomial (for example, x¹⁶ + x¹² + x⁵ + 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 (that is, a static pattern with no bit errors), then the remainder should always be constant (see Equation 1).

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 that yields optimum system performance. If the checksums for subsequent frames do not match, then the frames are different and the system needs to be optimized.

CRCs: The Alternatives

Bit error rate testing is an interesting alternative to CRC testing, with its 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 analyzed in comparison with the reference pattern and the number of differences gives an indication of the number of bit errors that 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 analyze the output against a known pattern is also one of its limitations. 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 ADI’s first complete AV front-end device targeted at the consumer and professional audio/video markets. The part incorporates a 4-input HDMI receiver that supports video resolutions up to 4k × 2k at 30 Hz; a video and graphics digitizer capable of operating at up to 170 MHz; 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 that employs CRCs. The frame checker is located before the ADV7850 output toward the end of the ADV7850’s signal chain (see Figure 3), allowing the entire video path for an 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) that can run at up to 170 MHz.

 

 

 

The frame checker in the ADV7850, utilizing the CRC-16-CCITT polynomial (x¹⁶ + x¹² + x⁵ +1), was designed to analyze a user-configurable number of frames and is enabled via a single I²C bit.² Once enabled, the frame checker computes a checksum for each of a user configurable number of frames (up to 255) by analyzing 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 × 2k). The number of frames to be analyzed is configured via an I²C control.

 

 

 

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 I²C. 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 optimize the system and repeat the test.

The Stages of CRC

The frame checker’s capabilities are all well and good but it is in the application of those capabilities in the real world that the true value can be realized. The ADV7850’s frame checker can be employed throughout the development cycle of a video product and also during its manufacturing cycle.

Development Phase

CRCs can be employed across many facets of the development phase of a video product to assist in automating testing, gauging the performance of the video signal chain, assessing the impact of thermal testing on a system, during power supply testing, or even during cable selection if a cable is to be supplied with the product.

Compliance Testing

Before a video product can be marketed as HDMI compliant and carry the HDMI logo, the product must undergo a series of stringent tests at an officially licensed HDMI approved test center (ATC). These tests ensure that the product meets all of the requirements set out in the HDMI Compliance Test Specification (CTS), which is released in alliance with the main HDMI specification. One of the toughest tests conducted as part of this suite of testing is an analysis of how robust the video receiver is to jitter on both the clock and data channels.

Meeting the criteria outlined in this test is quite often challenging and video product designers and manufacturers frequently send out their prototype systems for expensive precompliance checks, if they do not have in-house access to the equipment specified in the official tests.

The frame checker in the ADV7850 can be used as a low cost substitute for early iterations of precompliance testing if the specified equipment is not available. The frame checker provides an insight into whether the receiver is correctly receiving and decoding the HDMI data (factors that can influence this range from whether the correct configuration writes are being employed to the power supply design), and it allows an engineer to automate such tests. If the specified equipment is available, the frame checker can still be employed as it provides a definitive insight into whether the receiver is correctly receiving and decoding the data—flagging random errors when they occur. This level of analysis goes beyond that mandated by the CTS, which requires only visual checking.

HDMI Cable Selection

Many video product designers and manufacturers, especially in the professional audio/video market, depend on HDMI cables to route video between system components. An HDMI cable is constructed using 19 signal carriers; the HDMI specification outlines five different categories of HDMI cable for varying speed grades.

 

 

 

Cables can impact the signals passing through them in a range of ways. Due to their limited bandwidth, cables typically attenuate the signal passing through them, thus reducing the signal’s vertical eye opening. The eye opening can also be degraded by intersymbol interference (ISI) jitter. Caused primarily by impedance mismatch, ISI jitter typically reduces the signal’s horizontal eye opening. This “blurring” of symbols makes it more difficult for a receiver to decode and interpret the data.

For example, in a video conferencing system, video may be routed around a room from a central console to multiple monitors or projectors via a series of HDMI cables of up to 30 meters in length (see Figure 6). HDMI cables at such lengths, however, can be a significant component of the system cost with prices ranging from tens of dollars to hundreds of dollars; video product designers and manufacturers may choose to evaluate cables from low, medium, and high cost suppliers. Cable suppliers can often justify the costs of the cables that they manufacture through the quality of those cables; video product design and manufacturers, however, must balance the quality and cost of the cables that they choose to supply with their products.

 

 

 

The frame checker can be employed to good effect when assessing the impact of different cables in a system where everything else remains static. The system evaluation engineer must first benchmark a known good cable that is CRC error free. Using the frame checker, this test can be repeated over thousands of iterations autonomously to ensure consistency and the results exported to a data analysis tool.

Once the benchmark has been defined, the system evaluation engineer can substitute in the cheaper or longer cables and repeat the same testing to, at a first degree, assess the impact of the change. The autonomous nature of the frame checker testing means that this activity does not need to tie up valuable engineering time—it can be started and left to run while other tasks are completed. Once the testing has been completed, a first level of analysis to determine whether the substitute cables have introduced bit errors into the system can be completed. If no errors are detected, then the cables may be suitable for further analysis.

Another possible use for the frame checker is assessing the impact of extending the specifications for a product with minimal hardware changes. A typical investigation could be as follows; a video product design and manufacturer is currently using a known good cable that has been characterized with a system and provides a reasonable and trusted level of performance. The data received from the cable is degraded to the extent that it impinges slightly onto the HDMI compliance test specification jitter tolerance mask at 1080p, but not to an extent that would cause any issues for the ADV7850 in recovering the data (see Figure 7)³. Using the frame checker, the performance of the cable can be benchmarked to a certain level in an automated fashion—the test can be run over thousands of iterations and the results recorded.

 

 

 

If, in a product refresh, support for 4k × 2k (double the clock and data rate of 1080p 8-bit) is added to the hardware, an initial effort at revalidating the cable can be completed. Using a simplistic approach of checking the impact of the cable on the 4k × 2k data, a worrying result is recorded using the compliance equipment (see Figure 8). The losses in the cable are now causing a significant degradation of the signal. In functional tests, the ADV7850 may still recover the data, but will all of the data still be fully intact? Will random or series of intermittent bit errors, which could contribute to triggering serious system issues such as HDCP snow noise (as discussed earlier), now exist in the data?

 

 

 

The system evaluation engineer can, to a first degree, determine the answer to this question using the frame checker function in ADV7850. The CRC results can be logged over thousands of tests and compared to the results recorded for the same cable at the lower resolution video standard. This will allow the engineer to roughly determine if the extension of the specification will be technically feasible.

Power Supply Testing

The power supply is one of the most important aspects of a design to be tackled and is considered by many to be one of the most challenging. Many factors can influence the quality of the power supply output and the output of the power supply can influence so many characteristics of the system. Power supplies typically introduce a particular type of noise or jitter into the video stream: periodic jitter.

Designers must choose whether linear dropout regulators (LDOs) or switch-mode power supplies (SMPS) are to be employed; what frequency switch regulators to use and what filters should be employed to suppress any harmonics making it through to the system; whether power supply planes are routed on a single layer or multiple layers; whether it is possible for the planes to overlap on adjacent layers; how the decoupling capacitor architecture is implemented—even the location, the size, and the material of the decoupling capacitors selected; all of these elements and many more can yield a significant influence.

CRC testing can be used when evaluating the impact of power supply design changes both on a single revision of a board and between multiple revisions of a board. By changing the architecture of the decoupling capacitors (for example, values and locations) employed on a system and running a series of automated CRC tests after each change, a system evaluation engineer can benchmark roughly which decoupling architecture assists in achieving the most stable system with the fewest CRC errors. System evaluation engineers can also benchmark changes in subsequent revisions of prototype systems by running CRC tests on them as long as no other significant layout and schematic changes have been made. Finally, CRC tests can be used to access the impact of changes that may occur in the natural tolerances that systems may be subject to—for example, variances in power supply voltage levels through the tolerances of power supply components.

 

 

 

Thermal Testing

Confirming that a video product operates correctly over its specified temperature range is a vitally important phase of evaluation. Video product designers and manufacturers must ensure that the ambient temperature within their product does not exceed the silicon vendors specifications and that, across the ambient temperature range which the product will be subject to (for example, 0°C to +70°C for consumer products or –40°C to +85°C/+105°C for automotive products), the product’s performance is consistent and reliable.

 

 

 

Often in this type of testing, a prototype system is placed in a temperature controlled oven that can be cycled over the product’s specified temperature range—for example, –40°C to +85°C—for thousands of iterations. The output of the system is then observed to ensure that it is stable over the whole range of temperatures, video frequencies, and video patterns. This testing can be automated quite easily using CRC testing and set up to run indefinitely.

By automating the control of the oven, the video generator, and the CRC analysis tool, a system evaluation engineer can easily sweep the temperature, change video formats, and patterns while monitoring the CRC results for frame after frame of video data. If no changes occur when the video pattern and format remain constant, the test can continue; if a change in the CRC occurs when the video pattern and format are constant, the environmental variables should be recorded (for example, the temperature, video format, and video pattern) and the testing can continue. This type of testing can easily be set to run overnight or over a weekend with the result being the unmanned completion of hundreds of hours of robustness testing.

Software Configuration Changes

Certain aspects of a modern semiconductor device need to be tuned depending on the prototype system into which it is incorporated—for example, clock and data relationships may need to be adjusted to accommodate particularly long or short signal routes. A CRC test can be employed in such circumstances to assist in tuning the available controls—for example, equalizer settings, PLL settings, clock, and data phase relationships—to provide the most stable system possible.

Manufacturing Phase

When a video product design and manufacturer needs to verify the consistency and correctness of its manufacturing process by inspecting all or a cross section of its finished products, CRC is a tool that can be employed to gauge the correct soldering of certain connectors (for example, HDMI) and external passive and active devices (for example, HDMI ESD devices).

CRC can be employed at end-of-line testing in a number of ways; a CRC could be implemented in the video product itself or a CRC could be implemented in a discrete standalone end-of-line testing device (see Figure 11). Implementing a CRC in a video product that does not include the ADV7850 may require the inclusion of an FPGA or microcontroller semiconductor solution in the video signal chain that supports the capability of delivering a CRC.

 

 

 

Implementing a CRC in a discrete standalone end-of-line testing device may reduce the BOM cost of the video product but requires the investment in a standalone device. It does, however, offer the benefit of being capable of testing the stability of the entire system—the coverage offered by a CRC test solution embedded into the video signal chain is dependent on the location in the signal chain of that test solution. A CRC test located near the start of the signal chain may offer a low to moderate level of coverage; a CRC test located near the end of the signal chain may offer a moderate to high level of coverage.

The manufacturing quality control can then place acceptance and rejection criteria based on the results of the CRC test performed on the unit; sending failing units back for debug (a process that can also involve CRC tests) and sending passing units onward to packaging and shipping.

Conclusion

The CRC test is a powerful tool in an engineer’s arsenal of system development, manufacture, and debugging test methods. Although it cannot quantify the exact extent to which a system is being degraded by some problem (such as bit error rate testing), it facilitates the automation of a significant number of basic evaluation tasks and can assist in catching those occasional bit errors that visual checks just don’t catch. It is also extremely flexible as it can be run on any static pattern—there is no requirement to know the pattern in advance, and, using the ADV7850, CRC testing can be easily implemented.