BXELK-TN-003: Video streams integrity verification for Automated Test Equipments (ATE)

Info Box Applies to BORA Xpress

History

Version	Date	Notes
1.0.0	November 2017	First public release

Introduction

This document describes a practical application of BoraX SOM. Specifically, it illustrates the use of such SOM to build a module to be integrated into an Automated Test Equipments (ATE).

The following picture shows a simplified block diagram of the entire system.

Simplified block diagram of the entire ATE

The ATE tests the functionalities of the product–also known as device under test (DUT)–by exchanging data over its numerous interfaces. In this case, the DUT integrates some video outputs (namely HDMI, LVDS0, and LVDS1) that consist of differential pairs. These outputs usually drive LCD screens or HDMI monitors. In order to test them, the easiest solution is to connect such displays and to verify that the test images are visualized properly. Even though this approach is straightforward, it is very economically inefficient because it is slow and error-prone, as it requires a human operator to visually inspect the displays.

The solution described in this technical note addresses this issue. By implementing an automatic test system, it fully releases the operator from this task. Also, the test is much quicker and much more reliable, as it implements a 100% coverage of the pixels the test frames are composed of.

Implementation

The additional test module (VTM) consists of a carrier board hosting the BoraX SOM. This board was designed according to the guidelines detailed here.

Thanks to the rich set of available interfaces of BoraX, the integration of the new module was straightforward. It acts as a slave with respect to the main test module which implements the business logic of the entire ATE.

The video streams are connected to the deserializers which populate the carrier board. They convert the streams into parallel single-ended busses which are fed to the Programmable Logic (PL) of BoraX.

Programmable Logic

The PL integrates the actual test logic, which is depicted in the following image.

Video Test PL Block Diagram

On this specific implementation, the DUT has 3 video output interface: HDMI, LVDS0 and LVDS1.

The VTM is able to verify all the video interfaces at the same time thanks to the BoraX SOM resources disponibility, in term of PL logic resource and pinout. The high pin count permits to connect 3 RGB parallel videos with 24 bit of data.

The Checksum/CRC test logic can elaborate up to 60 frames per second on a Full-HD video flux. This reduces the ATE test time because on a time windows of few seconds the VTM can elaborate several hundred video frames.

All the PL block logic are connected to the AXI bus, and we have also implemented a I2C slave to AXI bridge.

This allows the VTM to works as:

1) stand-alone device - a dedicated SW (bare metal or Linux OS) that runs on PS can setup the PL logic and verify the video streams

2) slave device of the ATE - an external master I2C can setup the PL logic and verify the video streams through an I2C bridge (implemented on PL logic)

This is possible with a single PL configuration bitstream thanks to using of Xilinx® LogiCORE™ IP AXI Interconnect core. It permits to connect one or more AXI memory-mapped master devices to one or more memory-mapped slave devices.

The automatic test procedure

The automatic test procedure consists of the following steps:

• The master test module computes the CRC32 of the test frame (Ref_CRC)
  • The frame is considered as a data sequence where every pixel is composed of 3 bytes: the R-G-B data
• The master test module sends this value to the VTM; this is stored in a register implemented in the PL
• The master test module configures the DUT in order to visualize at the same time the test frame on the video outputs LVDS0, LVDS1, and HDMI
• The master test module enables the testing of the video streams
• The logic implemented in the PL:
  • Synchronizes the video streams and verify the video resolution and synchronism signals of every stream
  • For each stream, it computes the CRC32 for every received frame in real-time. In case the computed value matches Ref_CRC, the counter of valid frames is incremented. Otherwise, the frame of the corrupted frames is increased.
• After a while, the master test module stops the video test and verify the counters. If all of the transmitted frames are good, the test is passed.

Future work

The acquisition of the LVDS/HDMI video streams can be optimized by using the built-in hard SerDes blocks provided by the Zynq SOC. This implementation would allow avoiding the use of the external deserializers.