Verifying Display Standards – A Comprehensive UVM-based Verification IP Solution

The display protocol IP market is growing at a very fast pace. This is chiefly the outcome of the incredible increase in popularity of a wide variety of display source devices: such as DVD players, computer systems, and display sink/receiver devices: such as televisions, projectors, and display instruments. End users, the consumers, have also become more technologically savvy, increasing the demand for more and better products.

With this rapid growth in sophisticated display-dependent devices, there is an even faster rate of growth required in the field of verification of such devices. The verification of these devices must occur within very tight schedules, which demands a user-friendly solution so verification engineers can spend verification cycles in a productive and effective manner. This paper provides a unique solution that is far superior to other solutions present in the industry. It allows engineers to design structured, reusable VIP that is easy-to-use and makes it easy to debug issues.

Technology Overview

The display IP segment involves transferring images and in some cases audio of various types and dimensions. Protocols like HDMI, Embedded DisplayPort, VbyOne, and others, as defined by multiple organizations, fall
under this category. Along with these, there are various content protection mechanisms specified by various HDCP versions.

The basic versions of the protocols discussed in this paper began to emerge in the early part of 2002 and have grown in variety and complexity at a very fast pace since then. Many new features, support for more types of images and audio, and various other information have been game changers.

The basic function of any display specification is to send an image from a source or transmitter and receive it via a sink or receiver. Since all of the protocols have the purpose of sending images (a video is also an image sent at a high rate), there are inherent similarities in their nature.

The similarities of the specifications start from the fact that all of them have a period of active pixels (which are eventually bytes of data) during which pixels of the image are sent. Also, there is a period of blanking, which usually carries definite control and/or audio/secondary data (which are again bytes of data), as shown in Figure 1. Different specifications support different ranges of pixel format; for example, RGB and YCbCr.