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.