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 article 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.
The display IP segment involves transferring images and in some cases audio of various types and dimensions. Protocols like HDMI, Embedded DisplayPort, V-by-One, 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 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.
Figure 1: Frame structure.
To understand the verification challenges involved and arrive at the best solution, we must answer two questions.
- Why is it difficult to verify this kind of a display protocol?
- Should there be a common solution for the verification of these industry standards?
The major challenges in the functional verification of display protocols are as follows:
- Initially a verification engineer may want to do a simple pipe-cleaning. Bring up takes a big part of the verification cycle due to the inherent complexity of the protocols.
- Due to the large frame size, generally a lot of data needs to be handled.
- Different specifications provide a variety of secondary data, with different flavors within each of them. In order to completely verify all of these, support for different combinations is required.
- There are various types of encoding/decoding and scrambling/descrambling and other techniques like encryption involved. This further makes the debug of issues difficult as the data on the interface is not the actual pixel/secondary data.
- Due to the large size of the frames (each targeting different features of pixel/secondary data), the pixel depth supported, and the combination of frame formats, it can be difficult to generate frame stimulus without easy-to-use APIs.
Considering these and other challenges confronting the fast growing display industry, it is inevitable that a good verification solution is needed. Such a solution must support reuse at a protocol-independent, higher-level for basic testing/pipe-cleaning and then address the intricacies of individual specifications as a separate step using a separate API. These intricate APIs verify features at a fine-tuned level and, hence, will vary from specification to specification.
When a design under test (DUT) is a source (or transmitter), it needs to correctly transmit the supported formats, making sure no protocol timing and compositions are violated. Correct and timely reading (or writing whenever required) of display capability memories is also essential. Further, all supported types must be verified thoroughly along with a check on the content of the audio/video data. Link set up/trainings steps should be complied as per the specification.
When a DUT is a sink (or receiver), it is necessary to receive all the supported types of frames/images and, side-by-side, correctly handle the ones not supported. Proper maintenance of display capability memories is also needed. Moreover, any link training or bring up as per the specification should be adequately supported as well.
This article goes through a solution provided by display family of Questa® Verification IP (QVIP) that targets all the issues specified above so that a verification engineer is able to verify the design effectively. The display family QVIP provides solution for verification of many display protocols which are industry standard, such as DisplayPort, HDMI, V-by-One.
CREATING THE TESTBENCH
The first and foremost requirement for a verification engineer is to set up a testbench that can verify their DUT. QVIP provides easy bring up components and APIs for this testbench. Connection modules are provided that take away the pain (and potential mistakes) of having to remember the directions of the signals when doing the signal assignment. A user simply selects the module that reflects the way they want the QVIP to behave. For example, if the QVIP is to be a source, select the source QVIP component. Then the engineer just passes the signals via the port list and the connections are handled by the QVIP itself. See Figure 2.
Figure 2: Connecting the DUT with QVIP.
The next step is to set up a UVM environment. The protocol specific agents make this simpler. QVIP provides protocol specific agents for each protocol, which is controlled by simple configuration switches. Refer to Figure 3 for details.
Figure 3: Protocol specific QVIP agent.
Various static time functionalities are easily controlled via the agent itself. For example, in order to configure the QVIP to behave as a display source, a simple setting of a configuration does the work. Further, examples are present with the QVIP to explain all use cases. Using the connection module and protocol specific agent, the basic testbench set up is performed with ease. Although, this is a generic step for any verification, it is still an important one, as spending a lot of time here is not justified when there is a lot to be done elsewhere.
While verifying a sink or receiver DUT, one of the major efforts in verification has to do with writing the perfect stimulus to check all possible scenarios. The steps to generate the stimulus should be simple enough so that engineers can focus more on thinking of interesting scenarios rather than spending time and effort on how to code those. To verify a sink DUT, the engineer needs to transmit the frame/image through a source VIP.
As a first step of verification, a user may want to perform basic pipe-cleaning. This is basic verification that does not involve detailed protocol knowledge or specific pixel data values. Only a basic level of timing and dimension checks for the image kick-start the verification. A verification engineer does not want to spend a lot of time bringing up this level of stimulus generation. All that is needed is a very simple API, which sends some non-zero, random pixel data. QVIP targets this requirement very cleanly. It provides an easy to use API called send_frame.
The user follows a two-step process (see Figure 4):
- Create a sequence extended from protocol_source_seq
- In the body task of the sequence, call the API send_frame()
Figure 4: Sending basic stimulus.
Starting this sequence on the agent’s sequencer sends a frame with random values in active pixels. Such a clean API provides a hassle free solution.
At this point, the user may want to check some timing with some audio (or secondary) data. This again requires some easy steps to fill the various attributes from a large variety of audio data and to place them at a particular frequency in the blanking period.
The APIs set_audio does the work here. It contains arguments as simple enumeration values for packet types (as per the specification) and other detailed fields. A user may want to set the packet types at the broad level, allowing QVIP to set the other detailed fields as per the specification (at the same time randomizing the ones which have multiple options). They can leave the arrays for the detailed attributes empty in such a case.
Alternatively, a user may want to fine tune the various attributes by themselves. If this is the case, they can set the required fields with a variety of set attribute APIs. Thus, using the set_audio API, various combinations of audio (or secondary) data can be verified.
In the next step, the verification engineer needs to verify the pixel data by sending a particular value of pixel data.
- The pixel data may be directly available to the user. If so, the set_video API can be used directly.
- A png image of the intended frame may be available instead of direct pixel data values.
In the second case, the image is converted from an image format to a pixel format using an image convertor sequence. The converter sequence is started inside an image sequence (which is extended from the protocol_source_seq) and the pixel file is created. The pixel file is read and pixel components are extracted from the file.
Source sequence APIs are used to set the frame formats and send the frame. The image components are provided through the send_frame API to sequence the item. The BFM then does the necessary calculations to send the bytes to the correct wires of the interface connected to the DUT. The DUT (sink/receive, in this case) may extract the pixels and convert them to the image format for comparison purposes (the transmitted and received images can then be compared); see Figure 5.
Various other components of a frame (e.g., color depth
and pixel format) can be set through the attributes API present in the source sequence.
Figure 5: Steps for transferring an image.
USING QVIP AS A RECEIVER/SINK
The stimulus generation discussed in the previous section pertains to the use case when the DUT is a sink. In the other use model, where the DUT is the source, the challenges discussed earlier are handled very gracefully. The frame of an image can be easily received by the sink sequence and an actual image generated out of it. A comparison of this image can then be done with the image that the source DUT initiated. This kind of scoreboard makes it easier to verify the data to ensure that the DUT is functionally correct.
In some display specifications, a secondary channel is used to read/write display capabilities (DDC/EDDC, CEC) and requires HDCP operations that need to be responded to by the sink (or receiver). These are done by the QVIP along with various configurability options, which are present in order to vary the responses where the specification allows. Along with this, the user may vary signals, such as hot plug detect (or other sink end signals), which tells whether a sink is actually connected or not.
Once a user starts writing the test cases, the question arises: “when is it time to say that the verification is complete?” The coverage collector plays a critical role here. QVIP Coverage collector targets the specification extensively and makes sure that the design can be called completely verified if it achieves 100% coverage. The QVIP also provides an example that runs stimulus sequences to achieve 100% functional coverage and also a verification plan in the form of an XML file, which clearly maps individual sections of the respective protocol specifications. The Questa Verification Manager can be used for tracking the bins of the various coverpoints and crosses, as shown in Figure 6 and 7.
Figure 6: Coverage window.
Figure 7: Tracker window.
CHECKERS AND ASSERTIONS
The first and foremost purpose of verification IP is to check for protocol compliance and give an error message when any protocol violation occurs. To fulfill this basic requirement, the QVIP contains assertions to check interface activity for protocol compliance. The assertions are structured with:
- The ability to enable/disable each assertion individually. By default, all assertions are enabled.
- Specific error messages that give a detailed description for the protocol violation along with the respective specification reference and make it easy to cross check and understand the reason for a violation.
- SystemVerilog Assertion (SVA) capabilities such as wave-level debug and assertion coverage.
A sample assertion firing is shown in Figure 8.
Figure 8: Assertion snapshot.
Although these features are a generic component to all QVIPs, in the display family QVIPs, the most important aspect becomes the debuggability of the assertions. This is because the large amount of data makes it practically impossible for a verification engineer to debug the cause of the issue. With intuitively structured error messages and high debuggability, the QVIP makes it very easy to understand the issues.
As already discussed above, display protocols are inherently difficult to debug due to the huge amount of data. Over and above this, the data is not a direct reflection of its true value. The data is scrambled, encoded, encrypted in some cases, and then sent on the interface wires. By the time data reaches the interface, it’s completely different.
QVIP hides these intricacies of the functionality, but it does not compromise debuggability. Whenever something wrong happens on the bus, appropriate assertions are given along with the detail about the place of error. Then the sequence item at the point of error can be seen at various abstraction levels.
Even more, the performance and efficiency are very high, and frames of even very large dimensions can be easily executed on the interface at an efficient rate.
The large amount of data also makes it difficult to print out the active video, audio (or secondary) data, and users may want to observe various proceedings of a frame at a regular interval of time.
For this purpose, the QVIP provides a configurable control to print the timing of important events in the proceedings of the frame. For example, debug messages are seen when a vertical blanking completes, when each video line completes, when audio (or secondary) data packets are seen, and so on. Figure 9 shows a sample debug message.
Figure 9: Debug messages.
Additionally, the basic feature of transaction viewing and transaction linking in the GUI makes the debug easier by many folds. This is again a feature common with all QVIPs but holds more importance in this context as it allows the user to find the issues in the sea of data that is available here. Lastly, the SVA features make it easier to debug the root cause of any protocol violation.
Considering all the above points, it is obvious that verifying a display component is not an easy task. But the Questa Verification IP provides easy-to-use, highly organized steps that make the verification experience more productive and ensures that the protocols have been implemented correctly, providing a high confidence in design quality.
Back to Top