91³Ô¹ÏÍø

Product manufacturers play a constant game of catch-up to support the latest standards, protocols, requirements, and features, even before they have been completely established by standards bodies. To help ensure seamless interoperability with the new and existing hosts and devices on the market for any given protocol, designers participate in plugfest interoperability events, where their latest products are tested against the gold standards as well as other new products. It¡¯s at these events where designers may learn that despite the weeks of preparation, it¡¯s impossible to anticipate all the possible configurations that they will face.

Unexpected behavior can occur due to interaction between devices implementing new features, especially in older equipment or devices implementing older features. Even when a design team is focused on one version of the specification, a non-certified product interacting with a certified product can reveal unexpected issues. Interoperability testing is the most common way to run a product through a myriad of real-life connection scenarios before a product is widely deployed.

Interoperability testing in these conditions can lead to unexpected system behaviors, ranging from a simple lack of robustness to completely different interpretations of an IP specification. Engineers then endure stressful debugging sessions to try to resolve the issues in a 30-minute timeslot to pass the test. On-the-spot debug requires the ability to quickly make changes to the hardware and software. Using a complete, well thought-out prototyping platform with software/hardware co-design in mind can make a difference in high-pressure situations like interoperability events.

Testing for Interoperability at Plugfests: An HDMI Example

Designers of electronic equipment and software participate in plugfests to test the interoperability of their products or designs with those of other manufacturers. For example, the USB-IF hosts plugfests for USB, the SCSI Trade Association hosts Serial Attached SCSI plugfests, and VESA organizes plugfests for DisplayPort device designers and vendors. In addition, the CEA Technology and Standards program, in conjunction with the HDMI LLC and HDMI Forum, conduct plugfests to help designers ensure that their products will operate smoothly with other HDMI-enabled products on the market. These events allow manufacturers to test interfaces against other products in a semi-private, round-robin fashion. Designers can sort out connectivity issues between different manufacturers before products get in consumers¡¯ hands (Figure 1).

Interoperability in the plugfest involves all products in the HDMI chain, from the IP, to the SoC/system manufacturers (including the test and certification equipment), and final products. Testing in such a diverse environment can lead to unexpected system behavior and stressful debugging. Debugging requires as much information on the system behavior as possible, so the ability to quickly adapt and modify the hardware and software is essential. When interoperability fails, information is shared between the two product providers, while avoiding disclosure of confidential information. Debugging the issue is made in cooperation between the two teams, requiring test equipment and on-the-spot changes to the software and hardware.

Synopsys has used the DesignWare HDMI 2.0 IP Prototyping Kits in plugfests many times due to their quick debug and reconfiguration abilities. For example, the kits can support a high number of video modes that, in most cases, go beyond the supported video modes of other products, enabling a larger number of interoperability tests. The kits also enable fast reconfiguration to a specific video mode with a specific color depth, HDCP encryption version, scrambling, and so on.

Practical Plugfest Interoperability

Plugfests offer a practical method to discovering potential interoperability issues that otherwise would have been discovered only by the end user. For example, imagine that one product¡¯s design is decoding Limited RGB but it is incorrectly identified by the sink (in this case a TV) as Full RGB. It is difficult to detect the difference by eye, so how can you ensure accuracy? During the plugfest, cycling through Limited RGB and Full RGB on the TX product or debug console and the identifications are mismatched, you know something is not right and can debug it. However, since there are no products using Full RGB encoding in the session, it is likely that the issue will go unnoticed unless you have access to a product that can offer multiple modes and settings, like an IP Prototyping Kit.

Another example involves compatibility and robustness issues around new features within a specification. At a recent plugfest, Synopsys was testing an HDMI 2.0 capable receiver, using an IP Prototyping Kit, with another company¡¯s HDMI 1.4 transmitter (Figure 4). By connecting the cable to the receiver and reading the Extended Display Identification Data (EDID) from it, the transmitter acquires knowledge about the receiver and how to configure itself for compatibility. For example, if the preferred video mode of the receiver is 4K (the highest resolution video mode supported by our IP Prototyping Kit) and the transmitter is able to send only full HD 1080p, then the transmitter should configure itself for 1080p. However, during the plugfest, the transmitter system unexpectedly reconfigured itself for 480p DVI mode. Why? By scrolling through the logs and changing the verbosity output level during the execution of the software, the IP Prototyping Kit user was able to get critical information: The transmitter supported only HDMI 1.4 and the EDID sent from the receiver was HDMI 2.0, containing HDMI 2.0 specific data blocks with the HDMI 1.4 blocks and structure as required by the spec). To debug the issue, the Synopsys designer loaded a new EDID (by loading a recompiled software binary using an SD card into the IP Prototyping Kit) that removed the HDMI 2.0 specific blocks. This modification was possible to complete in about five minutes because the kit supports fast recompilation of the HDMI RX Linux driver, removal from the kernel, and loading of the recompiled driver. The designers plugged the cable back in and the transmitter product started outputting 1080p, showing how the flexible IP Prototyping Kit enabled a critical step in the debug process.

Beyond Interoperability

While the IP Prototyping Kits can be very useful in interoperability testing, they provide benefits that range through all phases of the IP development cycle. Even to get products to the plugfest, designers can use the kits¡¯ well defined prototyping flow, Linux drivers, proven reference designs, and debug and configuration tools to accelerate their development. Using IP Prototyping Kits helps you develop the software needed to release your product quickly, getting you to and through interoperability testing for faster time-to-market.