How Prototyping Increases Interoperability Success

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.

Solving issues during the test event itself is critical. From unclear specifications to backward-compatibility issues, plugfests can reveal issues between the devices that didn’t occur prior to the event. The plugfest may provide the only opportunity to correct specific, corner-case issues. As the objective is to ensure delivery of a high-quality product to the customer, debugging during a session is always stressful. In these events, designers need to do a set of specific steps to get their product working, which takes a lot of time and effort, taking the team away from the event itself. Even after the product is working, designers may be required to bring the product back a second time.

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.

What happened was a classic case of compatibility issues in the presence of new features. Because the EDID of HDMI 2.0 RX blocks were unknown to the transmitter (as those types of blocks did not exist in the 1.4 version of the HDMI spec), the transmitter considered the EDID information to be unreliable and it was discarded, therefore commuting to DVI mode. This unwanted behavior occurred despite the fact that none of the devices were acting contrary to the HDMI specification. It could only be discovered by trying multiple configurations in quick succession at the plugfest, which the IP Prototyping Kit facilitated.

Interoperability testing is critical to solving specific functional issues, and participation in plugfests is extremely important to proving/debugging issues that products will encounter in the market. Situations like these arise in almost every event, with some of them leading to more in-depth debug using the FPGA hardware build instrumented view, or even changes in the FPGA build itself. For example, the IP Prototyping Kit offers nine switch positions that can offer nine different pre-loaded configurations, making testing different designs extremely quick. Using IP Prototyping Kits, designers can easily experiment with different issues and scenarios. In seconds, they can test against current or older versions of the FPGA build or software image. Using the kit, designers can check if an interoperability issue is caused by a new version of the hardware/software, or if it is caused by a separate device in the test sessions.