Simplify test of embedded video interfaces

Article By : Ayusman Mohanty

Production testing a video interface's complete path from the analog or digital front-end to the digital video input of a processing unit can be challenging, but there is a simpler way.

Video interfaces are common in all types of embedded platforms, from single board computers to IIoT (Industrial Internet of Things) devices. Production testing the interface’s complete path from the analog or digital front-end to the digital video input of a processing unit can be challenging in terms of complexity and time, however, when using traditional methods. There is a simpler way.

The typical video front-end on an embedded platform and data path’s generic flow in a production test setup environment is shown below (Figure 1).

Figure 1 Test setup and video front-end for an embedded platform

The video front-end comprises a video receiver IC, which can be an ASIC or can be implemented as an RTL IP inside an FPGA. The output of this ASIC/FPGA is usually a parallel video bus in BT.1120/BT.656 standard format, connected to a processor video input port. The aim of the production test software is to ensure that the complete video path is free of any assembly related issues, like lines stuck-at-high or stuck-at-low or shorting between multiple signal lines.

Common techniques used for the video interface production testing include subjective evaluation and fixed video data pattern utilization. In subjective evaluation the tester captures several seconds of a test video and visually compares the captured images to the test images. The drawback of this technique is that it needs human intervention and is subject to interpretation. If the lower bit of the video data bus is stuck at low, for instance, then even though pixel values may be reduced by 1 this minor visual change is difficult to perceive by manual inspection.

Using a fixed video data pattern, such as a color bar pattern, coming from the video input source provides an opportunity for a more quantitative test. The system captures a few video data frames and compares them with the fixed video data pattern. Such comparison can be done quickly using checksums such as MD5, since the captured video frame should match pixel-for-pixel with the fixed video data pattern frame being played.

The drawback of this technique is that fixed video pattern sources, such as video players, are not readily available for all the possible front-end video interfaces and standards. The common way around this limitation is to use a player available for one standard and then use a converter to change it to the required standard and interface. These converters alter the pixel values while changing from one standard to another, however. For example, while converting from an HDMI to a 3G-SDI interface the video data is converted from the RGB888 to the YUV422 representation. This results in a change of pixel values that leads to false errors being identified.

There is another way to do a production test of the video path, however. To understand this technique, it is important to first look at some fundamental concepts of the parallel video interface format BT.1120/BT.656 being used in the path.

BT.1120 is a 16-bit parallel interface that uses codes embedded in the video data stream to differentiate between active (visible) and blanking (non-visible) video segments. The same concept applies for BT.656 with only difference being that BT.656 is an 8-bit parallel bus. The below diagram shows the division of pixels in one interlaced video frame.

Figure 2 A complete digital video frame

Each active line of video pixels is demarcated by end of active video (EAV) and start of active video (SAV) codes. These codes are based on the current active line’s values of H (horizontal sync), V (vertical sync) and F (field), also referred as timing synchronization signals. The SAV and EAV codes are four bytes in length with the data pattern ‘FF 00 00 xy’, where ‘FF 00 00’ is the preamble and xy is the status word containing the timing synchronization signals and four error-detection/correction bits. The table below shows how the SAV and EAV codes are generated.

Figure 3 SAV and EAV code generation

These codes are all you need to check the integrity of the video data path; the video itself is unimportant. If there are production errors in the data path such as shorts, opens, or stuck-at faults, the EAV and SAV codes will not match with the expected value.

The above method can be expanded to help test video output interfaces; simply connect them to a video input interface. The drawback with this is that in case of errors we will not know whether the error was in output or input interface path. More tests will be needed to find out the specific interface having the error.

My company has widely used these methods to test video interfaces across the hardware boards it has developed. The approach has significantly reduced the overall testing time for the Video interfaces, resulting in lower board testing costs.

Ayusman Mohanty is a product architect for Ittiam Systems, with a focus on building hardware for video and audio broadcast and surveillance systems.

Leave a comment